ファーストサーバのZenlogic、ストレージ障害の原因は「想定以上の負荷」：対策したはずの設定にもミスが（2/3 ページ）

[新野淳一，Publickey]

　まず、同社のストレージ障害の直接的な原因は「ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態」と報告されています。ストレージに求められる性能と容量をあらかじめ予測するキャパシティプランニングは簡単なものではありません。ましてや、顧客がどんな用途で利用するか分からないレンタルサーバでのキャパシティプランニングは非常に難しいでしょう。

　だからこそ、後からストレージの性能や容量をスケールできるスケールアウトストレージをZenlogicのバックエンドに採用したのではないかと考えられますが、その予想を上回る負荷が発生したことが今回の障害の発端でした。

　同社は今回の長期メンテナンスに入る前に、何度か障害対策としてストレージの増強とネットワークパラメータの調整などを行ってきたことを明らかにしています。恐らくこれは予想を超えたストレージへの負荷を、Cephのスケールアウト機能を用いて対応させるためにストレージサーバを増やし、それにあわせて分散ストレージの構成について調整を行ったものと推測されます。

ネットワークの飽和を防ぐための設定にミス

　しかし、これでは障害が解消しませんでした。

　分散ストレージにおいてストレージサーバを増やすと、ストレージサーバ間で処理を平均化するために、追加したストレージサーバへ既存のサーバ群からのデータ移動が行われます。この大量のデータ移動でネットワークが混雑し、今度はそれが新たな課題となるのです。

　Zenlogicでもそれが起きていたようです。当然同社はその対策を行ったはずで、次のように報告されています。

ストレージシステム最適化処理などで発生するシステム内部通信がネットワーク全体を飽和させる状況を回避するために、システム内部通信に対してネットワークトラフィック制限を実施しましたが、

　しかし「このネットワーク設定にミスがあった」と報告は続いています。

この際のネットワーク設定が一部、不適切な設定となっていたことにより、ストレージシステム全体がスローダウンしました。

　ストレージサーバ間のネットワークが十分に機能しなければ、分散ストレージはいつまでたって本来の性能を発揮できません。Zenlogicもそうした状況になっていたのではないでしょうか。