2021/02 site24x7 でのSLA状況・統計データ

じゃんくはっく
じゃんくはっく

ついに99.95%以上を達成したよ!

きたー!おめでとうー

ぴー
ぴー
じゃんくはっく
じゃんくはっく

2月のダウンタイムは3 分 29 秒でした

スマホサーバなのにがんばったね!

ぴー
ぴー

site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していましたが、ついに達成できました!

稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

LINK

ちなみに、先月は97.42%で無理でした。site24x7の監視サービスは強力ですが、まだ自動的に復旧する仕組みを作っていないので、再起動は人力となっています。これができれば常に目標SLAを達成できそうです。

2021・02のSLA

さて、今月の結果から!
ダウンタイムの3 分 29 秒で、SLAは99.991%となり今月は目標の99.95%に届きました! やったー!

ツイッターで、呟いていたらSite24x7の中の人がうれしいメッセージを送ってくれました。

嬉しいツイート、ありがとうございます!

少しダウンした原因は?

毎回、いいところでダウンするので今月は意図的に再起動を手動でしておきました。毎回、ある程度時間が経過すると「Bad Gateway」が出てしまうんです。とりあえず、再起動を少し入れて様子見をしてたんですが、それが良かったようです。赤い部分は再起動を入れたので、そのダウンタイムです。

まとめ

今回の教訓は以下となります。

・再起動は有効だった
・根本原因はまだ未調査。対処療法で再起動して対応
・再起動を自動化するには、スマホのリセットを外部から行う仕組み作りが必要
・実験用で、UmidigiF2にその仕組みを模索したい

あとがき

前回から、スマホを意図的に再起動させる仕組みをどうするか考えています。ハードウェア的に再起動を行うには、バッテリーを外して、電源をリモートからコントロールするようにするとか考えていましたが、root化してある端末ですので、他にも方法がありそうです。それにハードウェア的にリブートさせてもandroidシステムのいろいろな問題(例えば再起動後はロック解除しないとホーム画面まで行けないなど)があります。

ソフトウェア的には、以下コマンドでシステムが瞬時にシャットダウンします。

$ tsu
# reboot -p
Done

-pオプションを取れば、リブートします。しかし、このリブートだとWiFi接続に自動的に接続しなかったり、再起動時はロック解除をしないとHOME画面まで行かないのでTermux bootが動作しなかったりと問題があります。

そこで、以下を試しています。

Google Play : MacroDroid – デバイス自動化

https://play.google.com/store/apps/details?id=com.arlosoft.macrodroid

このアプリはよく出来ていて、これを使うことにより、以下のような事ができることがわかりました。

・一定曜日の特定時刻にソフトリブート(要root化必要)
・起動時にWiFiの特定APへ接続(ヘルパーアプリ使用)
・起動時に特定アプリを強制起動(termuxを起動させる)

このリブートだと、ロック解除しなくても特定アプリが動かせるし、WiFiへの接続も問題なさそうです。

termux が動作すれば termux boot でtermux内部のソフトウェアは起動します。今は、テストでdnsmasqやsshdを自動起動させていますが問題なさそうです。とりあえずは、一定間隔でリブートさせることは出来そうです。

site24x7の障害検知サービスをどのように受けて、このシステムと切り離してトリガーしてリブートできるよう、何か良い方法はないかなと考えているところです。トリガーはいろいろあるので、その方法を模索中です。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

    XIAOとスマホだけでnode.jsのJohnny-Fiveを動かす最短コースをご案内!

    じゃんくはっく
    じゃんくはっく

    きたきたきたー!

    なんか興奮してますね!w

    ぴー
    ぴー
    じゃんくはっく
    じゃんくはっく

    スマホとXIAOだけでNodeのJohnny-Fiveを動かせるようになったよ!

    NodeとかJohnny-Fiveとか何それ?

    ぴー
    ぴー

    はい、ちょっと興奮気味なんですが今日のネタは、

    「XIAOとスマホを接続して、それだけでXIAOを制御する!」

    ってことがメインテーマです。物理的な接続イメージは図に書くとこんな感じです。node.js実行環境をtermuxに作り、johnny-fiveというnode環境で動作するものをFirmataプロトコルでXIAOとやりとりします。もっと簡単にいえば、

    JavaScriptでXIAOを操る ですね。

    通常、node.js実行環境はPCに作ったりしますので、物理的な接続イメージは以下のようになるかと思います。

    JavaScriptでXIAOのGPIOを操作するのですが、まだこの構成のメリットがよくわかっていませんので、触ってみようと思いました。

    物理的に用意するもの

    (1) Androidスマホ
    (2) Seeed XIAO
    (3) ケーブル(Type-C x Type-C)

    Androidスマホは手持ちのものでも、余ったものでもOKです。XIAOは3個入りで1800円くらいでアマゾンから購入できます。ケーブルは100円ショップですね。

    Androidスマホ の必要アプリ

    GoogleStore : Termux

    https://play.google.com/store/apps/details?id=com.termux

    まず、Androidスマホのアプリを入れておきます。あと、もう一つ有償アプリですが以下を入れておきます。日本円で190円です。

    GoogleStore : BT/USB/TCP Bridge Pro

    https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro

    これはブリッジアプリで、今回の用途ではXIAOのUSB接続のシリアル通信をTCP上にブリッジする用途で使います。シリアルTCPのブジッジアプリは他にもいろいろありますが、XIAOと接続できた勇逸の神アプリです。

    Termuxのセットアップ

    アプリを入れたら、パッケージをアップデートしておきます。Termuxのコンソールからタイプするのが面倒なら、PCからSSHして作業するといいかもです。

    pkg update
    pkg upgrade

    以下が今回必要なものです。

    pkg install nodejs python clang make openssh -y

    手持ちの環境、HUAWEI P20 liteでは以下が入りました。

    $ dpkg --list | egrep 'node|python|clang|make|openssh' | cut -b 5-50
    clang              11.1.0         aarch64     
    make               4.3-1          aarch64     
    nodejs             14.15.4-1      aarch64     
    openssh            8.4p1-1        aarch64     
    python             3.9.2          aarch64     
    termux-exec        1:0.8          aarch64 

    nodejsはもう14なんですね。速すぎる!ぜんぜんついていけないです。

    サンプルソースとインストール

    まず、termuxでの操作です。コピペしやすいよう$ は省いておきます。

    cd
    mkdir j5
    cd j5
    wget https://github.com/take-i/j5-termux/archive/main.zip

    まだ説明も何も書いていませんがそのうち、簡単に書いておきます。

    サンプルソース

    https://github.com/take-i/j5-termux

    サンプルソース解凍しインストール

    example にLEDが光るサンプルソースが入っています。

    unzip main.zip 
    cd j5-termux-main/example/
    npm install

    IPアドレスを修正

    WiFiに接続していると思いますので、termux上でIPを確認しておきます。

    ifconfig | grep inet

    以下のようなIPv4が出ますので、それをメモしておきます。この場合は、192.168.1.36が自分のスマホのIPですね。

    inet 192.168.1.36  netmask 255.255.255.0  broadcast 192.168.1.255

    サンプルソースのIPを修正します。portは、あとでブリッジアプリで設定しますので、1024番〜の適当なポートにしておきます。1234でもOKです。

    ------- example/index.js
    ::
    var options = {
      host: '192.168.1.36',  //host name or IP
      port: 1234  // port
    }

    XIAOにFirmataをセットアップ

    この記事を書いている時はまだ、XIAOはFirmataのコードをビルドするとエラーになりますが、以下を適用すればOKです。そのうち、masterにマージされると思うので、ビルドエラーが出なければOKです。

    add seeedunio xiao to boards.h please #475

    https://github.com/firmata/arduino/issues/475

    具体的には、以下からFirmataをダウンロードします。

    firmata/arduino Releases
    Arduino-1.0.x-Firmata-2.5.8.zip

    https://github.com/firmata/arduino/releases/

    先ほどのFixをBoards.hに反映し、ArduinoIDEからインポートします。

    スケッチ例>Firmata>StandardFirmata のスケッチをXIAOに書込みます。

    エラーなく書き込めたらOKです。

    スマホでブリッジアプリを設定

    次はスマホで BT/USB/TCP Bridge Pro のアプリを設定します。このアプリはDevceAとBをブリッジしますので画面のように設定します。

    XIAOをUSB接続するとアクセス許可がでますのでOKします。「このUSBデバイスをデフォルトにする」はチェックしておいたほうがいいですね。

    USBデバイスに接続(USB connect)し、TCP Serverをスタートさせます。2つ上の画像、右側のようになっていればOKです。

    起動!

    Termuxのindex.jsがある場所で以下のコマンドを実行すると動作します。

    node index.js

    成功すれば、以下のようにターミナルに表示されているはずです。

    Connected to USB2TCP Bridge
    IO ready!
    1614296838868 Available Firmata  
    1614296838874 Connected Firmata  
    1614296838882 Repl Initialized  
    >> Board connected!

    XIAOの青色LEDが光っていれば成功です。写真では青色LEDが光っているタイミングを写せなかったので光っていませんが、チカチカしているはずです。

    お疲れ様です。

    まとめ

    今回、なんとなくわかったのは以下となります。

    ・Termux上でJ5を使う時は、USBに接続したボードを認識しないので、別アプリでUSBをTCPにブリッジさせて使う
    ・ブリッジさせるアプリはたくさんあるが、J5からXIAOと通信できたのはこれだけ
    ・実際に開発するときは、スマホ充電しながらUSB接続しないと電池持ちが。
    ・J5の使い所がまだよくわかっていないので、例をこなしながらどんなメリットがあるのか体験してみる

    あとがき

    node.js実行環境をTermuxに作ってそこから有線USB接続したXIAOを操れることがわかりました。まだ、どんなことができるのか、そしてどんなメリットがあるのかまーったく分かっていませんが今後、面白い活用方法などがあれば紹介、DIYしたいなと思います。

    著者にメッセージ

    間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

      2021/01 site24x7 でのSLA状況・統計データ

      じゃんくはっく
      じゃんくはっく

      もう少しだったのにー!

      また落ちたのね?

      ぴー
      ぴー
      じゃんくはっく
      じゃんくはっく

      そうなのよー、1月2日にねー。

      正月だから寝てたのね!

      ぴー
      ぴー

      site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

      稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

      LINK

      ちなみに、先月は99.368%で無理でした。かなり惜しかったんですよ!site24x7の監視サービスは強力です。これがなければ、もっとダウンタイムは長かったです。

      2021・01のSLA

      さて、今月の結果から!
      ダウンタイムの合計19 時間 12 分あって、SLAは97.42%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。正月早々に、監視のお知らせはきていたのですが、寝ていて気がつかず! この1日がなければ達成していたんですよー。

      原因は?

      今月も設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。

      ちょっと回避が難しいので、運用でカバーしようと思っているんですがやっぱり寝てるときとか無理ですね。

      まとめ

      今回の教訓は以下となります。

      ・UmidigiF2に載せ替えようとおもっている。
      ・4月から仕事先が変わるんで、再起動が難しいかも。何か作戦を練らねば。
      ・バッテリー無くして電源管理と連動する仕組みとか考えないと。

      あとがき

      現在リモート勤務なので、まぁ気がつけばすぐに再起動かけられますがこの先仕事のライフワークが変わる可能性が大なので、再起動がむずかしくなりそうです。バッテリーを外して、電源をリモートからコントロールするとかちょっと工夫しないといけないですね。

      著者にメッセージ

      間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

        2020/11と12 site24x7 でのSLA状況・統計データ

        じゃんくはっく
        じゃんくはっく

        だいぶ遅れましたがSLAデータ報告です!

        99.95%は達成できた?

        ぴー
        ぴー
        じゃんくはっく
        じゃんくはっく

        ・・・

        また来月がんばりましょう!

        ぴー
        ぴー

        site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

        稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

        LINK

        先月は、99.567%で無理でした。

        2020・11のSLA

        まずは結果から。ダウンタイムの合計17 時間 30 分あって、SLAは97.565%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。

        原因は?

        今月のは設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。

        ちょっと回避が難しいので、運用でカバーしようと思っていましたが夜間にダウンするともう無理ゲーです。

        まとめ

        今回の教訓は以下となります。

        ・サーバが1つだとやっぱりきびしい。多重化が必要だがそこまでコストをかけたくない。
        ・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明
        ・運用でカバーしようと思ったが、夜間にダウンするともう無理です。

        あとがき

        目標がクリアできなかったので、記事を更新するのも面倒になっていますが記録だけでも採っていこうかと。ちなみに、12月も無理でしたので、この記事にはりつえておきます。99.368%という結果。

        かなり惜しかったんすが、今回もNGINXがBadGatewayを出してしまいました。17日の少し止まった部分はSSLの更新に伴うWEB再起動ですのでこれはまぁ許容。19日のがなければクリアしていました。NGINXがBadGatewayを出す根本原因を探らないとなのですが、腰が重いです。

        著者にメッセージ

        間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

          内部DNSをTermuxのDNSMASQで動かす!

          じゃんくはっく
          じゃんくはっく

          内部ネットワークから参照するDNSを作ったよ!

          それって、どんなDNSなの?

          ぴー
          ぴー
          じゃんくはっく
          じゃんくはっく

          例えば、example.jpだと192.168.1.1にアクセスできるようにするとかできるよ

          UターンNAT対策?

          ぴー
          ぴー

          そうなんですよねー。UターンNAT対策で内部DNSが欲しかったんです。

          内部DNSを低消費電力サーバのスマホtermuxで動かしたいなと思って、いろいろ格闘していました。先日はOpenWrtというルータ上で動かしていましたが、今回は、root化したスマホ上のtermuxで動かしてみました。53ポートで動かすのでroot化が必要ですが、termuxのrootパッケージの1つ、dnsmasqを使って内部DNSを作ろうと思います。

          dnsmasqとは?

          公式:Dnsmasq

          http://www.thekelleys.org.uk/dnsmasq/doc.html

          比較的、軽量でDHCP、BOOTPやPXEにも対応しているDNSサーバでOpenWrtにも使われていたります。自ドメイン以外は指定のDNSに転送して応答してくれます。内部ネットワーク向けの簡易なDNSとしては十分な機能をもっていますね。

          今回は、IPv4で自ドメインの応答とそれ以外は8.8.8.8のDNSにフォワードして応答してもらうだけのシンプル設定です。DHCPなどそれ以外の機能はつかいません。

          Termuxのdnsmasqは?

          ポート53で動かすので、root化したスマホにtermuxを動かしている必要があります。1024番ポート以下はrootじゃないとバインドできません。パッチ内容は以下から参照できます。

          termux-root-packages:dnsmasq

          URL

          やってみましょうか!

          ステップ1 インストール

          インストール自体は簡単です。root-repoパッケージを入れてから、dnsmasqを入れるだけです。

          $ pkg install root-repo -y
          $ pkg install dnsmasq -y

          本体とmanなどが入ります。サイズは264Kと小さいですね。

          $ ll /data/data/com.termux/files/usr/bin/dnsmasq
          -rwx------ 1 u0_a143 u0_a143 264K Aug 17 02:40 /data/data/com.termux/files/usr/bin/dnsmasq*

          ステップ2 設定

          Termuxのdnsmasqだと、設定ファイルはデフォルトで無いので作ります。

          $ cd $PREFIX/etc
          $ vi dnsmasq.conf 

          内容は以下です。ほどよく読み替えてください。

          ホスト設定:$PREFIX/etc/hosts-dnsmasq
          ログ:$PREFIX/var/log/dnsmasq.log
          このホストIP:192.168.1.38
          Termuxユーザ:u0_a143
          ドメイン:gpl.jp
          フォワードするDNS:8.8.8.8

          listen-address=127.0.0.1,192.168.1.38
          port=53
          bind-interfaces
          user=u0_a143
          group=u0_a143
          no-poll
          # プライベートIPアドレスの逆引きを上位DNSサーバに転送しない
          bogus-priv
          # ドメインの無いホスト名のみ問い合わせの場合、上位DNSサーバに転送しない
          domain-needed
          # ローカルエリア内のドメインを指定
          local=/gpl.jp/
          # ホスト名で問合せされた時、下記のdomain=で指定されたドメイン名を補完
          expand-hosts
          # 補完するドメイン名
          domain=gpl.jp
          
          # LocalDNS
          addn-hosts=/data/data/com.termux/files/usr/etc/hosts-dnsmasq
          server=/gpl.jp/192.168.1.38
          server=/1.168.192.in-addr.arpa/192.168.1.38
          log-queries
          log-facility=/data/data/com.termux/files/usr/var/log/dnsmasq.log
          
          server=/localnet/192.168.1.38 # change ip for your ip-server
          server=8.8.8.8
          no-resolv 

          ホスト設定:$PREFIX/etc/hosts-dnsmasq は以下となります。

          192.168.1.38    f2
          192.168.1.47    p3
          192.168.1.47    hack
          192.168.1.47    junkhack

          resolvファイルは自サーバを参照するよう以下にしておきます。

          $ cat resolv.conf 
          #nameserver 8.8.8.8
          nameserver 192.168.1.38

          ステップ3 起動

          53ポートでバインドさせるので、rootで起動します。

          $sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

          ステップ4 確認

          確認です。明示的に dig @hostip domain と@でdnsを指定するとより良いです。

          $ dig f2 +short
          192.168.1.38
          
          $ dig -x 192.168.1.38 +short
          f2.gpl.jp.
          
          $ dig www.gpl.jp +short
          192.168.1.47
          
          $ dig yahoo.co.jp +short
          182.22.59.229
          183.79.135.206

          ホスト名のみでも大丈夫ですね。FQDN自ドメインも引けますし、逆引きもできます。管理外はフォワードして応答してきました。

          例えばまったく違うドメインを指定

          $ cat hosts-dnsmasq
          192.168.1.38    f2
          192.168.1.47    p3
          192.168.1.47    hack
          192.168.1.47    junkhack
          192.168.1.111   test.example.jp

          このように、違うドメイン名をFQDNで記載したら参照できるのでしょうか?

          設定変更・再起動

          $ sudo killall dnsmasq
          $ sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

          参照できるか引いてみます。

          $ dig test.example.jp +short
          192.168.1.111
          
          $ dig -x 192.168.1.111 +short
          test.example.jp.

          参照できますね。これって設定ファイルのserver行でドメイン指定しなくてもいいんですかね? 設定項目はもっとシンプルにできるのかもしれませんが、追求するのはヤメにしておきます。

          まとめ

          同じ設定を、UmidigiF2では動きましたが、Pixel3ではフォワーダーが動かなかったです。

          ・UmidigiF2では動作し、Pixel3ではフォワーダーが動かない原因は不明
          ・機会があれば、BOOTPやPXEも試してみたい
          ・FQDNで記載すれば違うドメイン名でもOK
          ・MXやテキストレコードなどはどうやって指定するのだろう?

          あとがき

          今の所不具合はなさそうです。もう1週間ほど動かして問題なさそうであれば今のWordPressサーバを統合しようかなと思います。メインPCからもこのDNSを参照していますが速度的にも特に問題はない感じです。

          著者にメッセージ

          間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

            2020/10 site24x7 でのSLA状況など統計データ

            じゃんくはっく
            じゃんくはっく

            引っ越ししてからのSLAデータ報告です!

            site24x7のレポート?

            ぴー
            ぴー
            じゃんくはっく
            じゃんくはっく

            そうそう。有料会員になったんでとりあえず使っています!

            99.95% って難しそうだね!

            ぴー
            ぴー

            site24x7のスターターパックというのを10月から始めてみました。いわゆる監視サービスなんですが10ドルで契約できるので、ちょっと使い始めています。

            稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

            LINK

            とりあえず、SLAレポートが出せるのでこれを月末に出していこうかなと思います。

            2020・10のSLA

            まずは結果から。ダウンタイムの合計3 時間 5 分あって、SLAは99.567%となり目標の99.95%には届きませんでした。99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。しかし、3時間も止めてしましました。

            原因は?

            5日の停止はDNSの設定ミスです。27日と28日は内部ネットワークを少し変更してその影響で少し止まってしまいました。30日は、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。これはなんとかしないとだめですね。設定関連での停止は、今後以下のように対策しようと思います。

            ・設定変更後、5分は監視レポートが飛んでくるか確認する。

            なかなか設定ミスの間違いには気がつきにくいです。とりあえず何か変更したら、5分は監視サービスの動きを見ることで対応しようと思います。

            まとめ

            今回の教訓は以下となります。

            ・引っ越し当初なんで設定することがたくさんあった
            ・設定変更後は、監視サービスの動きを5分は見て見ることにする
            ・サーバ1つだとやっぱりきびしい。多重化が必要。
            ・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明

            あとがき

            UmidigiF2をroot化したので、とりあえずこっちに戻して様子を見ようと思いますが、めんどくさいのでちょっと作業は中断。スマホサーバを安定して動かすのは難しいです。

            著者にメッセージ

            間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。