OpenShiftこんにちは、レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。Climaxも終わりましたね。今年のG1は矢野が盛り上げてくれたおかげで...ってプロレスの話じゃなくて。3話目ですね、1クール13話やるまでは打ち切りにならないようがんばります。前回は、実際にRookを使ってKubernetes(k8s)クラスター上にCephストレージをデプロイして使ってみました。Volume(PV)を使っているアプリケーションのI/Oにどのような影響が起きるかを見てみましょう。Meetupは#4からcrash.academyさんに録画をお願いしていて、リプレイを観ることができるんです!#5の動画はまだですが#4はもう公開されてます。#4で宇都宮がRookとCephについて話してた動画もあるのでユーザー登録して観てみてね!あと勝手にRookの日本コミュニティを立ち上げました。コンテンツはまだ何もないけど、ぼちぼちイベントをする段取りができたらここで告知しまーす。nodeの追加はいそれでは本題に入ります。nodeが3台でこいつらをapp用とCeph用で兼用してたのですが、今回はCephのノード障害を起こすためにapp用のworkerを分けておきたいと思います。nodeを追加して適当にlabelを振って、こんな感じでいきます。appちなみに、各ノードたちはus-east-1a〜us-east-1cのAZに散らばっています。CephもAZをまたいでクラスターになっています。今の状況を絵で書いてみるとこんな具合です。OperatorとCephをデプロイしてblock用のpoolとstorageclassを作ります。この時に使ったyamlはgistに上げてますのでよろしければどうぞ。1.00000はい、Cephクラスターできてますね。後はアプリなんですが今回はdateをビシバシ叩く奴では面白みがないので、portworxのfio-toolsを使ってfioを走らせてみましょう。writeをかけてみます。ベンチ目的じゃないのでそんなに高い負荷はかけません。12sはい、それではこの間に障害を起こしてみます。デバイス障害まずは手始めにデバイス障害を引きおこしてみましょう。Detachすればいいですかね。osd.7に相当するEBSをブッコ抜きます。1.00000サヨウナラosd.7。Detachした時のI/Oを見てみましょう。fioの方で1秒ごとのIOPSとlatencyのログを吐くようにしてるので、それらからグラフを書いてみます。6-7msecって意外と良いlatencyでwriteするのね。AZ跨ぎのCephなら10msec以上は覚悟だと思ってたけど。それは良しとして、左側の赤い点線がEBSをブッコ抜いた瞬間です。ログを見ると50〜52秒の3秒間はIOPSもlatencyも全く記録がありません。latencyのログで53秒目に4000msecほどの記録があるので、4,5秒ほどwriteが止まってたって事ですね。4,5秒のI/O停止は大抵のアプリケーションでは問題ないでしょう。一般的に、環境によって程度の差はあれ、ストレージで障害が起きると幾ばくかのI/O停止は発生します。I/O完全無停止を保つことは難しい。そのため、アプリに数秒のI/O停止も許容されないような要件がある場合は、例えばデータパス上にI/Oをキャッシュするレイヤーをはさむなどして、I/O停止を吸収できるようなアーキテクチャーのアプリを開発することが必要になります。次はノード障害を引きおこしてみましょう。nodeをstopしちゃいます。osd.7をもう一回戻して、ip-172-20-71-77-ec2-internalノードを落とします。1.00000アヒャヒャヒャ。4d6hip-172-20-71-77-ec2-internalで動いてたosd.[1,3,7]とmon-d(mon-cに代わって上がろうとしてる)がPendingになってます。復活しようとしてもScheduleできるノードがないから復活できない感じですね。魂と精神はあるけど生き返れないとはハガレン的。後で人体錬成(ノード追加)するから待っててね。それではさっきと同じ様にIOの様子を見てみましょう。ノード障害はデバイス障害とは違って長くなりますね。ログを見ると75〜100秒までIOPSの記録がないので、ざっくり30秒くらいしてから戻ってます。group(pg)はread/writeすることができなくなります。osdを生きているosdになるようにremapするんですが、remapのpeeringが終わるまではそのpgはI/Oできません。よってpeeringのpgへのfioのwriteが待たされて、結果長いこと待つことになったのではないかと想像します。mapの更新を始めるのに時間がかかったこともあるのではないかと。ブロックストレージが30秒停まるというのはおっさんの宇都宮的にはそんなもんかなという気分です。時代錯誤かもしれんけど。Cephのパラメータを調整すればもっと早く戻せるのかとか、たくさん考察できそうですが、ちょっと長くなりそうなのでやめときます。ちなみに、I/Oが復活してからIOPSとlatencyがほんのり良くなってますよね。requestに対するCephクラスター内でのwrite量が減ったためです。まとめそういうわけで今回はRook-Cephのクラスターで障害が起きるとI/Oにどんな影響があるのか調べてみました。次回はRook-Cephのアーキテクチャを説明していこうと思います。今回RWXできなかったので次回おまけでできたらいいな。いうわけで、今回はここまで。CephFSの脅威まいど。トリプル・ポッドまいど。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。