はじめに
InfoScale は、Azure上のRHELでの動作を保証しており、主なメリットとして以下2点が挙げられます。事実、オンプレミスの世界では、下記のメリットを享受する為に多くの企業がInfoScaleを導入しています。
１．独自のストレージ管理機能により、ストレージ（Azureの場合は Standard SSD 等のブロックストレージ）メンテナンス時のダウンタイムや作業工数を削減
２．独自のクラスタリング機能により、アプリケーションやOSレベルの障害をカバーできる可用性の向上
しかし「クラウド上のI/Oパフォーマンス管理はオンプレと違って難しいのに、Azure上にInfoScaleを導入する事によって、さらに複雑になるのでは？」という懸念が根強いのが実情です。本記事では、そのような不安を払しょくするために、InfoScale7.4.2 RHEL版を Azure上に構築した代表的な構成におけるI/Oパフォーマンステスト結果を公開します。また、ストレージ管理やクラスタリングを行う為にInfoScaleを導入する事の妥当性を構成毎に考察します。I/Oパフォーマンスを向上させるための簡単なチューニングについても説明します。
パフォーマンステストを実施した5つの構成
構成1 シングルノード構成
本書における基準となるべき構成です。Azure上の非クラスター構成のインスタンスにInfoScaleを導入してブロックストレージを管理対象にすると、ブロックストレージの拡張・追加時のファイルシステムの拡張がサービス停止を伴わず、もしくはより短いサービス停止時間で行える等のメリットがあります（詳しくは、こちらとこちらをご参照ください）。Azure上の非クラスター構成のインスタンスにInfoScaleを導入した場合に実現できるI/O性能の基準としてご活用ください。また、この構成で得られたI/Oパフォーマンスに対して、他の４つの構成がどれだけ劣るかを比べる事で、クラスター構成毎のI/Oパフォーマンスに関する留意点が明らかになります。
構成2 共有ディスク型クラスター構成
構成1に対してどれだけI/O性能が劣化するかを考察する事で、クラスター化に伴うオーバーヘッドの度合いを把握する事ができます。構成1と構成2では、1つのインスタンスが1つのブロックストレージに専用アクセスする事は変わりませんので、理論上はクラスター化のオーバーヘッドのみが顕著化します。尚、上記構成の構築方法についてはこちらをご参照ください
構成3 VVRを用いたAZ跨ぎクラスター構成
AzureのAZを跨いでクラスターを構成する場合、構成2のような共有ディスクは使用できません。その場合、クラスターの各ノードのローカルストレージのデータを同期する必要がありますが、その手法としてVVRによる同期モードのレプリケーションを用いたのが上記の構成3です。構成2に対してどれだけI/O性能が劣化するかを考察する事で、VVRによる同期レプリケーションのオーバーヘッドの度合いを把握する事ができます。尚、上記構成の構築方法については、こちらをご参照ください。
構成4 FSSを用いたAZ跨ぎクラスター構成（ハートビートはUDP使用でチューニング無し）
AZを跨いだクラスターを構築する手法として、レプリケーションではなく仮想ミラーを使用する事も可能です。FSSを用いた仮想ミラーによってクラスターの各ノードのローカルストレージのデータを同期するのが上記の構成4です。レプリケーションを用いた構成3とI/O性能を比較する事で、仮想ミラーとレプリケーションの違いがI/O性能に与える影響を比較する事ができます。尚、上記構成の構築方法については、こちらをご参照ください。
構成5 FSSを用いたAZ跨ぎクラスター構成（ハートビートはUDP使用でチューニング有）
上記構成5は、構成4にハートビートの性能を向上させる為にLLTフロー制御のチューニングを施しています。ベリタスが過去にAWS上で行ったパフォーマンス検証では、AZを跨いだ仮想ミラー型クラスターのパフォーマンスが、LLTフロー制御のチューニングによって向上する事が分かっているからです。この2つのI/O性能を比較する事で、AWSでは有効だった「AZを跨ぐクラスターのチューニング方法」がAzure上でも有効かどうかを把握する事ができます。尚、AWS上でのパフォーマンス検証及びチューニング方法については、こちら をご参照ください。
使用するブロックストレージの種類
今回の検証で使用するブロックストレージは「Standard SSD」です。Standard SSDを選択した理由はバースト機能が無い事です。バースト機能は、一定時間のみ一定のIOPSやスループットを保証する事が可能です。例えば、バースト機能が有効な「Premium SSD」の場合、30分間は 3500IOPSと170Mbyte/secのスループットが保証されます。本書では、継続的に同じパフォーマンスが発揮される環境での検証を行う事が目的であるため、バースト機能の無い Standard SSD を使用しました。尚、AWS上ではありますが、バースト機能によって高い性能を発揮する環境で検証を行った記事も公開しています。こちらに関しては、こちらを参照してください。
マシン環境
本検証の環境情報は以下の通りです
OS：RHEL7.7
InfoScale 7.4.2
インスタンスタイプ：Standard A4_v2（4Core, 8Gbyteメモリ）
ブロックストレージ： Standard SSD 5Gbyte（IPOS上限 500）
5つの構成のパフォーマンステスト結果の比較
各構成の比較においては、下記9種類のいずれでも概ね同じ傾向となりました。本書では、最も代表的な「I/Oサイズ4Kbyte、Read/Write比率5対5、ランダムアクセス」についての結果を紹介し、考察を述べます。
・I/Oサイズ4Kbyte Read/Write比率10対0、ランダムアクセス
・I/Oサイズ4Kbyte Read/Write比率5対5、ランダムアクセス
・I/Oサイズ4Kbyte Read/Write比率0対10、ランダムアクセス
・I/Oサイズ4Kbyte Read/Write比率10対0、シーケンシャル
・I/Oサイズ4Kbyte Read/Write比率5対5、シーケンシャル
・I/Oサイズ4Kbyte Read/Write比率0対10、シーケンシャル
・I/Oサイズ64Kbyte Read/Write比率10対0、シーケンシャル
・I/Oサイズ64Kbyte Read/Write比率5対5、シーケンシャル
・I/Oサイズ64Kbyte Read/Write比率0対10、シーケンシャル
IOPS
IOPSに関しては、シングル構成が最も優れており、他のクラスター構成は2割程度劣る結果となりました。共有ディスククラスター構成が最もシングル構成に近いパフォーマンスだったのは想定通りです。全体的なIOPSは低い値ですが、Standard SSDのIOPSの上限値が500である事を考えると、想定通りと思われます。また、AZ内のクラスター（構成２）とAZ跨ぎのクラスター（構成3～5）の違いが顕著化しないのは、Standard SSD のIOPSが低いため AZ間のネットワーク遅延によるデータ同期のオーバーヘッドが顕著化しなかった為と考えられます。尚、構成3～5の比較では、チューニングを施したFSSが最も優れており、次にVVR、最後にチューニング無しのFSSという順番で、FSSのチューニングは有効である事が分かりました。
スループット
スループットに関しては、IOPSと全く同じ比較結果となりました。これは、スループットはIOPSにI/Oサイズを乗算したものだからです。具体的なスループット値も、例えばシングルノード構成に着目した場合、前ページのIOPSが250だったので、それにI/Oサイズである4Kbyteを乗算すると1Mbyteになり、上記のグラフと一致します。
CPU使用率
CPU使用率に関しては、IOPSやスループットとは全く異なる比較結果となりました。I/Oパフォーマンスが低いパターン（構成4等）でCPU利用率が低く抑えられているのは、I/O待ち時間が比較的長いためと考えられます。全体的にはどの構成でもCPU使用率は低く抑えられており、個々の値のバラツキは誤差の可能性もあります。
考察
シングルノード構成
Azure上のシングルノード（非クラスター構成）のRHELインスタンス上に、ストレージの管理性向上を理由にInfoScaleを導入する場合、InfoScaleの導入によるCPUオーバーヘッドは誤差の範囲であり、I/O性能もネイティブ環境と大差ないと言えます。
共有ディスク型のクラスター構成（AZ内でのクラスター）
InfoScaleを用いた共有ディスク型のクラスター構成のI/O性能やCPUオーバーヘッドは、非クラスター構成と大差ない値でした。従って、AZ内でのクラスター構成を検討する際は、パフォーマンスの観点では共有ディスク型のクラスターを選択される事をお勧めします。
AZを跨ぐクラスター構成
AZを跨いでクラスターを構築した場合、クラスターの各ノードのローカルストレージのデータ同期のオーバーヘッドにより、前述の2つの構成よりも大きく性能で劣る事を予測していましたが、劣ってはいるものの、予想に反してその程度は軽微なものでした。これは、Standard SSD のIOPSが低いため AZ間のデータ同期のオーバーヘッドが顕著化しなかった為と考えられます。尚、構成3～5の比較では、チューニング（LLTフロー制御の閾値変更）を施したFSSが最も優れており、次にVVR、最後にチューニング無しのFSSという順番で、FSSのチューニングは有効である事が分かりました。尚、FSSのチューニング方法については、下記で説明します。
仮想ミラーのパフォーマンスを向上させるチューニング
仮想ミラー型クラスターのI/Oパフォーマンスを向上させるには、ハートビートのチューニングが効果的です。なぜなら、仮想ミラー型のクラスターは、個々のクラスターノードのローカルディスクの同期をハートビート経由で行うからです。ハートビートのチューニングは、以下の３つの方法があります。
１．MTUサイズ拡張
２．RHELの通信バッファサイズ拡張
３．InfoScaleのハートビートドライバーであるLLTのフロー制御閾値の拡張
それぞれ向き不向きがありますので、個別に説明します。
MTUサイズ拡張によるパフォーマンス向上
ローカルディスクの同期をハートビート経由で行う際、MTUサイズが大きければデータ転送の単位が大きくなるので、転送効率が良くなります。ただし、データの書き込みサイズが小さい場合は、逆に転送効率が悪くなるので注意が必要です。以下のようなケースでチューニングが有効です。
１．バッチ系の処理
２．シーケンシャルアクセス
３．書込みが多い
例えば、NICのMTUが1500バイトで、ファイルシステムのブロックサイズが8Kである場合、MTUサイズを8Kより大きくする事で、パフォーマンス向上が期待できます。
RHELの通信バッファサイズ拡張によるパフォーマンス向上
ローカルディスクの同期をハートビート経由で行う際、RHELの通信バッファサイズが大きければデータ転送の効率が向上するパフォーマンスが良くなります。ただし、バッファサイズが使用できるメモリ量を上回らないようにする必要があります。以下のようなケースでチューニングが有効です。
１．バッチ系の処理
２．クラスターのハートビートにUDPを選択している
３．書込みが多く且つI/Oブロックサイズが大きい
RHELの通信バッファとチューニング方法についての詳細は、Red Hat社のドキュメントを参照してください。
LLTフロー制御閾値の拡張によるパフォーマンス向上
InfoScaleのハートビートは、LLTという独自のプロトコルで行われています。LLTは送信キューに大量のデータが溜まる事を防止するためにフロー制御を行っています。フロー制御には閾値があり、キューに溜まったデータの量がハイウォーター値を超えると、溜まったデータの量がローウォーター値を下回るまで、キューの受付を停止します。従って、バースト的にデータ転送が発生する場合は、フロー制御によってデータ転送効率が低下します。逆に言うと、フロー制御閾値（ハイウォーター値）を拡張する事で、データ転送の効率が向上しパフォーマンスが良くなります。ただし、キューのサイズが使用できるメモリ量を上回らないようにする必要があります。以下のようなケースでチューニングが有効です。
１．AZ跨ぎなど、ネットワークのLatencyが大きい
２．書込みが多い
LLTフロー制御閾値とチューニング方法についての詳細は、InfoScaleのマニュアルの1155ぺージを参照してください。
尚、ここで説明したチューニング方法の詳細を含むパフォーマンステスト全般に関するホワイトペーパーがベリタスより公開されています。是非こちらをご参照ください！
おわりに
如何でしたでしょうか？ 今回の記事と記事中に紹介したホワイトペーパーによって、Azure上のRHELにInfoScaleを導入する際の懸念点が減ったのではないでしょうか？ 今後も、Azure上のInfoScaleにご期待ください！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。