Zenlogic障害報告書がリリースされる
本日、2018年7月17日（月）に、かなりの世間の関心ごととなった、Zenlogic高付加障害についての報告が出稿されています。
報告書（全文）
Web
https://zenlogic.jp/news/status/syogai/cause/
https://zenlogic.jp/pdf/report/20180717.pdf
障害の原因（転記）
ストレージシステムを含む、クラウド基盤を提供・管理するヤフー株式会社から、高負荷状態に陥った原因として、以下の報告を受けております。
[概要]
事象A：ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態
事象B：事象Aへの対応に伴い、二次的に生じた長期間にわたる高負荷状態
[原因]
事象Aに対する原因
（1）2018年6月からストレージシステムに対する負荷が想定より高くなったことにより一時的な高負荷が発生し、サービス利用が困難となる状態が不定期に発生しました。
事象Bに対する原因（2）ストレージシステム最適化処理などで発生するシステム内部通信がネットワーク全体を飽和させる状況を回避するために、システム内部通信に対してネットワークトラフィック制限を実施しましたが、この際のネットワーク設定が一部、不適切な設定となっていたことにより、ストレージシステム全体がスローダウンしました。
（3）複数回のストレージシステム増強や、設定値変更に伴い、ストレージシステム内部でこれまでになく大量のデータ移動が発生したこと、および2項のネットワーク設定の一部が不適切な設定となっていたことにより、データ移動完了まで時間を要しました。このため、ストレージシステムの高負荷状態が当初見込みより長期化しました。
考察
一貫して報告書においては、Cephの存在を明かしておりませんが、前回の記事の通りCephを使っていることは間違いないと考えています。
ASCII.jp：サーバーを捨てたファーストサーバ、「Zenlogic」で再始動
Cephとは何か、簡単に概要をつかんだ上で、上記原因を当て込んでみたいと思います。
Cephを学ぶためにまずは入門記事へアクセス
Cephについて学ぶために、＠ITの4本の入門記事にアクセスします。
上記に、
・分散ストレージCeph/RADOSとは？
・Ceph/RADOSの実装から動作の仕組みを理解する
・Ceph/RADOSのインストール、環境構築と接続テストまで
・Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装
4本の記事がアップされています。これらをゆっくり読むことにより、機能的な概要を把握することができます。まず把握しました。
上記記事を読んだうえで、仮説を立てる
ここからは推測です。どうやったらCephで今回のような問題が起こるのか考えてみました。
・あるオブジェクトのレプリカを置くOSDセットのパターンPG（Placement Group）は、初期構築時に現在のOSDの数によって自動生成される。
・その後にOSDを増やしたとしても、PGの数は増えない。これにより初期に追加したOSDに偏ってデータが保管されていく。
・6/19の段階で、偏りのあった特定のOSDを動かしていたサーバーが高負荷で再起動を起こすようになり、特定のPGがstale状態になるようになった。
・6/23、6/27、6/29にファーストサーバーは、OSDの追加（ストレージサーバーの増強）を行った。
・6/29に、PGの追加およびリバランスを行った。「パラメーター変更」と言っているものはPGの数ではないかと推測する。リバランス自体はPGの数と関係なく可能だが、PGの数を最適化してから実施したほうが好ましいと思う。
・6/29にリバランスを実施したところ、報告書にあるように、OSD間で大量のデータ移動が発生し、ストレージ用のネットワーク帯域が枯渇してしまった。かつ、仮想サーバーとのストレージ通信のための帯域を確保すべく行っていた帯域制限が不適切であり、結果としてceph全体がスローダウンしてしまった。また、リバランス処理自体も遅延していってしまった。
・7/6に、根本対策として、全サービスの停止を実施。リバランス処理の完結を目指した。7/9にこれが完了した。
これらは一旦フィクションと捉えてください。Cephの概要と報告書を合わせ読んだ場合に、つなぎ合わせると上記のようなシナリオが出来上がっただけです。
感想
結構、Cephのセットアップ方法は簡単で、これならCentOS7を何台か並べれば実装できそうです。しかも、ホストからファイルシステムとしてマウントできるところまで整備されていて、魅力的であることもわかります。
ストレージサーバー不要で、x86の物理サーバーを横に並べていけば簡単に分散ストレージが作れる、これはいい、とも思いました。
ただ、Zenlogicの障害事例を見ると、初期構築の難易度と、その後の運用の難易度が全然違うのが分かります。ディスク追加すればスケールアウトできると思いきや、リバランスを手動で行わねばならず、かつその帯域でストレージシステムがスローアウトするという悪夢。
できれば、Cephも絡めた技術的な報告を、ファーストサーバーがやってくれると、日本の運用畑にもナレッジとなるのではないかな‥と思いました。
おそらく、今後はOSDを動かすサーバーの監視を厳しくして、リバランスやOSDスケールアウトのタイミングを前倒ししていくんだろうなと思いましたが、なんともこのあたり、横にOSDを追加するだけでインテリジェントに最適化してくれるといいのになと思いました。仮説立てながら、これじゃあハマるよなあ・・と思いました。
ちなみに、私の仮説はフィクションです。念のため・・。
追記（2018/7/18 9:00）
仮説のまま放っておくのも忍びないので、時間があるときにCephの環境を作って試してみようかと思います。
・OSDを追加したら、勝手にリバランスされるのか？
・PGの数を増やしたら、直後にどうなるのか？
・初期OSDが小さいクラスタで、あとからがっつりOSD増やすと、やっぱり初期OSDに偏るのか？
このあたりの試験をまずやってみるべきかなあと思いますが、どうなることやら。
追記（2018/7/18 17:45）
Azureに環境を用意しました。明日はcephをいよいよ入れて検証するつもり。
追記（2018/7/19 12:27）
Azure上で構築作業やってみたのですが、結論としては中止します。
各種、構築事例を見てコマンドを叩いてみるのですが、どうにもcephやcepy_deployのの内部バージョンが上がってしまっていて、事例通りにコマンド通り動きません。また、pythonの環境構築も結構ハマりどころが生まれていました。
※pythonについては、pyenvは使ったらダメで、yumから入れてpython3コマンドをシンボリックリングで作ったりと、なかなか一筋縄ではいかなかったです・・（この件だけは自力解決できましたが）
最新バージョンでは事例通り動かないとなると、古いバージョンを持ってきたり原典にあたるなどが必要となりますが、個人の検証の範疇を超えるので一旦終わりにします。仕事でやっているわけではないので、ここらが潮時かなと。
こうなると、HCIであったり有償のSDSであったりは、至れり尽くせりだな・・と痛感しました。
するっと動いてくれれば、事例にして出す予定だったのですが・・。残念。
Learning Ceph - Second Edition (英語)
