TL;DR Gitで設定バージョン管理 実家から自宅のサーバへ接続 同セグメントのルータへTFTP設定流し込み 流し込みファイルを誤選択 設定保存コマンド入り 自宅接続断発生 今後の対策 死活監視 設定保存コマンドを確認するまで流さない 死亡時の復旧手法確立 設定を保存しない PDUによるリブート 最終生存時の設定から復旧するバッチ Raspberry Pi設置 LTE回線接続端末として利用 バッチ動作ノードとして利用 背景 自宅,実家,祖母宅の3拠点にRTX810を導入しており、各々設定ファイルを RTX810-(設置場所市名) で同じディレクトリに配置し、Gitでバージョン管理。 設定変更時は、設定ファイルを編集してコミットの後、Githubへプッシュ。tftpで転送して、問題なければルータにて設定保存していた。 事故内容 事故直前までの経緯 実家から実家と自宅、2拠点間のIPsec-VPNの設定を試みていた。 実家から自宅拠点のサーバServer-AへSSHでアクセスし、その環境にて自宅ルータRTX810-A, 実家ルータRTX810-Bの設定ファイルを編集。コミットを重ねていた。 tftpで設定を流し込む際、RTX810-AにはServer-Aを用いて、RTX810-Bには手元端末Client-Bを用い、設定ファイルの融通にはGithubを利用していた。 その際、同じディレクトリにRTX810-Aの設定とRTX810-Bの設定を配置した状態であった。 事故 Server-AからRTX810-Aへの設定流し込み時に、tftpのコマンドを間違え、RTX810-Bの設定をRTX810-Aへ流し込んでしまった。 復旧不可 RTX810-Aの設定ミスによる接続断は想定されており、RTX810-AのLTE回線からGoogleCloudPlatformへ張られたVPNを用いての復旧が想定されていた。 しかし、その設定も含めて書き換えられてしまったため、完全に遠隔からの復旧は不可能になってしまった。 今回は、自宅拠点に人が居なかったため影響しなかったが、転送した設定ファイルは保存コマンドが有効になっていた。 これは、オペレータでない第三者による電源操作を利用した復旧さえ不可能にしてしまう。 対策 そもそも死活監視をしていないので、死活監視を開始して、死亡時になんらかの処理をできるようにする。 復旧手法として、直前の設定を流し込む方式と、単純に設定転送時には保存コマンドを入れずに、PDUを用いて電源断を行う手法がある。 いずれも、意図しない設定の巻き戻りや、意図しない電源断を招く可能性があるので、死活判定時の死亡判定、復旧実行頻度をよく検討する必要がある。 1番簡単な手法として、各拠点にモバイル回線を用意したRaspberry Piを置くことだという指摘を頂いた。確かにそう。確かにそうだが。追加で月額800円(SIM追加2枚)を払うのは、上記に挙げた仕組みをラズパイで実現し維持するコストとどちらが安いのだろうか……。たしかに、仕組みの維持に1時間取られただけでパートタイム時給ですらペイできてしまう。うーむ。

読む前に この記事はkstmアドベントカレンダーの2日目です。 尚、下記の記事の続きのようなもので、内容は実質ポエムなので注意されたし。 仮想化以前に構築した自宅インフラをDockerとOpen vSwtichで何とかする話 - Qiita 何故続いたか 下記に上げる既存手法は、帯に短し襷になんちゃらということで、あがく、放置する、を繰り返し結果、1年経ったが結局救われていないことに気付いたので記事にすることにした。 現状、Hostアダプタとdocker-composeでの自動立ち上げで多少幸せになったが、ホストマシンのOSインストールが終わったら、自宅インフラを一発で復旧できるような状態には未だなっていない。 ovs-dockerの運用をやめてしまった要因として以下のものがある 1. 再起動耐性がない 2. あくまでシェルスクリプト 現状、Hostアダプタを運用していて発生してる問題としては以下のものがある 1. Rawソケットを使うデーモンをTagVlanで使えない 2. ホストの構成、IP変更に振り回される そして、一時期検討した、kubernetes等の基盤とかの問題点として以下のものがある 1. アカウンティング、テナンティング、クラスタリングしないので機能の8割が邪魔 2. L2でひっぱりだすのが大変(contivとかあるらしいけどまだ熟れていない) つまり、既存手法にはほぼ救いがない。 Dockerのネットワークドライバを実装しようとした話 Go言語でOVSDBを叩くDockerのネットワークドライバがあれば最高じゃないかと思って、libnetworkのドライバのコード・リーディングを進めているが、さっぱりわからん。 特に、OSのネットワーク周りに対応して秘匿し、互換性を持たせる機能も読み込まなければならず、早々簡単に読めるものではなかった。 手段として大きくなりすぎている気がするので、勉強としては多少読み続けるが、実装しようとは思わなくなった。 kea-dhcp on Dockerの話 Rawソケットを使うデーモン、それはkea-dhcpである。 kea-dhcpをホストアダプタのVlanなI/Fに割り当てると、見事にコケる。 理由はとても簡単、Rawソケットを使っているため、カーネルドライバであるVlanを認識しない。 つまりVlanなI/Fを仮想スイッチで「剥く」ことができるOpen vSwitchは非常に魅力的なのだ。 詳細はここに書かれている。 [Kea-users] (Can’t get KEA to work here - VLAN issues 他にも、HostアダプタでVlanなI/Fを掴んだ場合、Rawソケットを使っているデーモンは全て死亡することになる。 ovs-dockerに再起動耐性をつける話 ovs/ovs-docker at master · openvswitch/ovs この実装を読んでみたが、ovs-dockerの実装であるシェルスクリプトがステートレスなのが問題であって 手前味噌ではあるが、インターフェイスとDockerのコンテナIDあたりの整合性を保持するDBを持っていれば、 もしかしたらなんとかなるんじゃないかと思った。 シェルスクリプトではなくツールとして再実装したら美味しいのでは。 こんなポエムを書いている間に、上記のような着想を得たので、アドベントカレンダー期間内に実装し、 成果が出たら記事として公開しようと思った。 おわり。

問題 リアルタイム協力クッキークリッカー風味ゲーム Chair Constructer Online roomと呼ばれる概念があり、協力してひたすら椅子を生産する部屋を作れる。 roomに入るとWebSocketでリアルタイム通信が発生する。 このゲームの処理を、4台(いずれもCPU 2Core 2.3GHz, MEM 2GB)のサーバーで捌かなければならない。 回線に関しては、参加者がアクセスするグローバル系統、サーバー間の通信とベンチマーカーの通信が流れるローカル系統がある。 それぞれの系統は同じスイッチに収容され、各々帯域制限があるので、後々それも問題になったであろうが、そこまでパフォーマンスが上がらなかった。 問題の詳細に関しては後々公開されるであろうイメージを参照されたし。 結果 学生中4位、12位(kstm) 振り返り 構成把握、ユーザの振る舞いの想定が非常に甘かった。 特にWebSocketの中身。メッセージの分布なり統計なりきちっと出せていればroom毎の分散はしなかった可能性がある。 ところが、かなり早い段階でWebSocketの負荷分散単位をroom単位と決めてしまった。 メリットとしては、roomに関する情報をサーバー間で同期性、一貫性を担保する必要がないところ。 デメリットは、1台のサーバーで支えられる以上の負荷がroomにかかっていた場合、それ以上捌けないところ。 セッション数を見たところ、 この分散方式だとセッションが集中するサーバーとそうでないサーバーが出てしまった。 数字としては、 ss -to state established あたりで監視していたが、4台中2台が暇な状態であった。 一番混み合っているサーバは90〜100セッションを捌いていたが、暇なサーバに至っては、10セッションに満たない。 アプリケーションが負荷を十分に発生できなかったという話もあるが、 私は、2年前のISUCONから人間タスクランナと、ネットワーク、インフラ担当なので、 アプリケーションのパフォーマンスが上がらなかった原因などの解説はチームメイトに譲ることにする。 参照URL ISUCON7本戦で惜敗してきた - Goryudyuma’s blog