みなさん、こんにちわ。本記事は｢実況中継!? VSAN 6.2 中の人によるふかーい話｣の続編にあたります。
以前の記事はこちらです。
本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。
実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる～い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。
障害発生時のパフォーマンス
上手く動いている時の話はすべてお話してきました。ここからは壊れた時の話です。
非常にシビアな状況を作り出しました。Writeキャッシュが埋まってしまうような負荷をかけ続けました。これには一定の時間(今回の場合60分)がかかります。Writeキャッシュが埋まってしまうと、デステージ(キャパシティディスクへのデータの書き出し)が始まります。これを表しているのは青のラインです。一貫したパフォーマンスが出ていますが、デステージが並行して走ることで少しガタガタしています。これがベースラインです。さて、障害を起こします。デステージが始まった瞬間、ホストを落とします。
念のためですが、今回はDVD Storeを利用していますですのでこの縦軸はユーザーが実際に体感するアプリケーションのOPM(毎分の処理数=多いほどパフォーマンスが高い)です。また、Y軸の一番下は0ではなく100で、通常状態では160の数字が出ています。
障害が発生した直後、一時的に158から112ほどまで低下しますが、130～140ぐらいに安定します。この間隔が落ちたホスト上にあったデータを生き残ったホスト内のデータから復元している期間です。この時に発生した再同期のためのトラフィックがグレーで表示されています。
ここで言えるのは一時的にパフォーマンスが劣化しますが、上手く保てています。最大でも25%しか劣化しませんし、殆どの期間は10%程度の劣化で済んでいます。
そして再同期が終わればオレンジのラインは標準のガタガタに戻っています。これはDVD Storeのワークロードでデータベースがどんどん膨らんでいるため、デステージが常に行われている状態だからです。
VSANはシステム内に分散スケジューラーを持っており、再同期のための帯域が25%未満になるように調整するようになっています。うまいことにちょうどこの例でも25%でしたね。とにかく、通常のIOのためのトラフィックを出来る限り邪魔しないようにしています。つまり出来る限り早く再同期を終わらせるということと、アプリケーションへの影響を最小にしようという2つのトレードオフを行っているのです。
会場より : どっちを優先したいというユーザーが居るのではないですか?
そのための詳細設定を提供しています。標準は20か25ですが、変更できます。
ビジネスクリティカルアプリケーションでのパフォーマンス
驚くべきことに、今日VSANで最も広く利用されているアプリケーションはビジネスクリティカルアプリケーションなのです。SAPやMicrosoftやOracleですね。様々なホワイトペーパーを提供しており、多くのお客様環境で利用されています。SAPとは緊密に活動しており、SAP HANAの認定検証を行いましたが、VSANはそれをすべてクリアしました。公に書くことは出来ませんが、レイテンシは600～650マイクロ秒程度でした。
これはOracle RACの実際のワークロードで、4ノードのハイブリッド構成での結果です。私だったらオールフラッシュで構成しますが･･･まぁ、見てみましょう。 Oracle RACでそれぞれのノードで1台ずつ仮想マシンが動作しています。パフォーマンスは素晴らしいです。平均で287,000TPM(毎分処理されるトランザクション数)で、最大で331,000TPMを記録しています。これは非常に嬉しいことです。ハイブリッド構成であっても一貫したパフォーマンスが得られていることの証ですから。また1ノードだけでは155,000TPMだったトランザクション数も4ノードで287,000TPMまでスケールしています。
ストレッチクラスタでのパフォーマンス
多くの顧客はこうしたアプリケーションをストレッチクラスタで動作させています。理由は高い可用性を得たいがためです。ストレッチクラスタはどのようにパフォーマンスに影響するのでしょうか?
今回も前のスライド(Oracle RAC)とお同じベンチマークを利用しています。Oracle RACによるSwingベンチです。正確なノード数を忘れてしまいましたが、ベースラインとしては同じデータセンタ内での値、1msのレイテンシのストレッチクラスタ、2.2msのストレッチクラスタ、4.2msのストレッチクラスタを比較しています。TPS(毎秒のトランザクション数)はそのレイテンシに対して、妥当なレベルでの劣化が見えています。つまり、データセンタの距離に応じてパフォーマンスにペナルティが生まれているということです。いわゆるメトロクラスタの距離であればラウンドトリップタイムは1ms程度でしょう。その環境ならもともとの環境の80%のパフォーマンスで利用が可能です。そして、RPOはゼロです。障害時にデータを失うことはありません。
いかがでしたでしょうか?キャパシティ･パフォーマンス、ストレッチクラスタと優れた技術がふんだんに盛り込まれたVSANはなんとただのx86サーバで動作するのです。まさにストレージの革命ですね。また面白い内容があればご紹介していきます。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
