本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。
本記事の原文はPart 3 - Data path is not managed as a clustered resourceで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
従来型ストレージによる仮想化データセンタの拡張性の問題シリーズのパート3へようこそ。先日渡しはFASTプレゼンテーションについての記事 ｢FAST '15 での FVPの耐障害性Write-Backについてのプレゼンテーション｣を公開しました。Ian Forbes氏がホスト間ネットワークと従来型SANがいずれも似たようなネットワークスピードで接続されている場合についてのスループットとレイテンシについての疑問を投げかけています。
パート 1: イントロダクション
パート 2: ストレージエリアネットワークのトポロジー
ESXiホスト間でのIOPSの分散
このシリーズの以前の記事で、アレイから提供されるIOPSはESXiホスト間で平等に分割されるとお伝えしました。実際には通常のアプリケーションの場合、そのアプリケーションの要求に応じてI/Oは様々になります。そしてそのせいでI/Oの要求はクラスタ内のすべてのホストで均一にバランスされることはありません。
仮想化データセンターはそれぞれのコンポーネントの異なるリソースのレイヤーから構成されており、それぞれでロードバランスアルゴリズムが利用されています。2009年にChad氏が典型的なストレージ環境におけるすべてのキューやバッファを表した素晴らしいダイヤグラムを公開しています。この素晴らしい記事をご参照ください。｢VMware I/O queues, micro bursting and multipathing(VMwareのI/O キューと局所的なバースト、マルチパス-リンク先は英語)｣
どのように仮想マシンの要求や重要度に応じて利用できるアレイに対するパスがロードバランスされていると保証できるのでしょうか?残念なことに今日の仮想化データセンターはこれらの異なるレイヤーに対するロードバランスの機能を持ちあわせておらず、ホットスポットを減らすことや、適切なワークロードの分散を行うことができません。それでは現在既存の仮想化データセンタ環境で利用可能なアルゴリズムの全てを詳しく見て行きましょう。
クラスタ化ロードバランサー
クラスタ全域に渡るロードバランスツールはDRSとStorage DRSです。どちらもクラスタリソースをプールとして一元化し、要求と優先順位に応じてワークロードに分配します。現在のホストが割り当てられたリソースを仮想マシンの要求に提供できなくなると、仮想マシンは別のホストもしくはデータストアに移行させます。DRSはCPUとメモリのリソースを配分しますし、Storage DRSは仮想マシンのI/Oとキャパシティの供給をデータストアのI/Oとキャパシティの余剰を最適化しようとします。
コンピューティングとデータストアの間のレイヤは非常に重要ですが、ネットワークの帯域とデータパスはクラスタ化リソースとして管理されてはいません。ロードバランスはホスト内で、外へ流れ出すデータに注目して行われます。
データパスのロードバランシング
IPベースのストレージネットワークでは、外向けのポートをロードバランスするいくつかの方法があります。iSCSIではVMKernelのNICを複数バインドしてワークロードに分散することが可能です。いくつかのストレージベンダーは複数のVLANをストレージのポートのロードバランスに利用するという構成をとることも可能です。NFSを利用している場合、ロードバランスチーミング(LBT)で複数のNIC間でロードバランスを行うこともできます。
残念なことに、これらのソリューションは最初のスイッチのポートより後ろのパスを考慮することができません。すでに動作しているワークロードは利用可能なアップリンクを可能な限り効率的に利用できるように分散されますが、クラスタ内のホストに接続されたパスをプール化し、ホストごとのワークロードに応じて分散することができるソリューションはありません。仮想マシンに対して非常に少ないデータパスを効率よく、自動的で、シンプルに分散させるソリューションというのは存在しないのです。
分散I/Oコントロール
ストレージI/Oコントロール(SIOC)はデータセンタ全体のスケジューラーで、データストアに接続されている様々なホスト上の仮想マシンに対して分散したキュー優先順位を提供します。SIOCは競合が起こった状態に対応するように設計されています。必要があれば、ホストをまたいで仮想マシンの優先順位に応じてI/O要求を満たすようにキューのスロットを分割します。SIOCはカーネル内からストレージ内部のディスクの(データストアとなる)デバイス間のレイテンシを計測します。仮想マシンを他のクラスタ内のホストへ移行させ、データパスからくるレイテンシや帯域の制限を回避するようには設計されていません。ネットワークI/Oコントロールは同じようなフレームワークをベースとしています。特定のホストのNICを利用している仮想マシンの帯域を割り当て分散させます。仮想マシンをクラスタ内の他の帯域をさほど利用していないホストを考慮して、移行させるということは行いません。
マルチパスソフトウェア
VMwareのプラガブルストレージアーキテクチャ(PSA)は興味深いものです。PSAはサードパーティベンダーが彼ら自身のネイティブマルチパスソフトウェア(NMP)を提供することができるようにする機構です。PSA内部では、パス選択プラグイン(PSP)が実行され、I/Oリクエストの際にどの物理的なパスを利用するかを選択する事ができます。VMwareのネイティブマルチパスプラグインフレームワークは3つの種類のPSPをサポートしています。最近利用したパス(MRU)、固定(FIXED)、そしてラウンドロビン(RR)です。ストレージアレイタイププラグイン(SATP)がNMPと一緒に動作し、ストレージ固有の操作を管理します。SATPはストレージ固有の特性、例えば、Active/Activeであったり、Active/Passiveであったりということを理解しています。つまり、ストレージが(ALUA - Asymmetric LUN Unit Access - 非同期でのLUN単位のアクセス)を利用していれば、どのパスがコントローラーを管理しているポートなのかを知ることができます。
ラウンドロビンのPSPはデータストアに対するI/Oをコントローラーが管理しているすべてのパスに対して分散することができ、必要なI/O操作を特定の1つのパスで処理します。ワークロードをすべての(最適化された)パスに分散することはできますが、スループットが一定であることは保証ができません。ホストのI/Oのプロファイルに対する最適化は行えないのです。ロードバランスのアルゴリズムは利用可能なパスの純粋なI/Oの数をベースとしており、I/Oのブロックサイズは考慮に入れていないのです。結果としてアプリケーションのワークロードの特性や既存の帯域の利用状況に応じて特定のパスを負荷分散することはできません。SIOCやNetIOCと同様、NMPもデータパスをクラスタリソースとして取り扱うようには設計されておらず、クラスタ内の利用可能な接続にワークロードを分散する能力は持ち合わせていないのです。
EMCのPowerPathはサードパーティのNMPで、現在のパスの帯域の使用状況や仕掛りのI/Oの種類かを考慮したアルゴリズムを利用可能です。特定のストレージコントローラーでは統計を利用し、パスを定常的に切り替えることでの好ましくない影響を避ける事ができるようになっています。PowerPathはホストからバックエンドのサポートされるストレージまでの接続を確認し、それに応じて決定を下すため、ストレージのパスから可能な限り(そして、利用可能な限り)のパフォーマンスを絞り出すことが可能です。しかし、PowerPathを利用するホスト同士はホストごとにはコミニュケーションしておらず、I/O負荷をホスト単位でバランスすることはしません。この段落はEMCのソリューションにフォーカスしましたが、他のストレージベンダーも類似の機能を持つNMPソフトウェアをリリースしています。残念なことに、すべてのベンダーが自身のソフトウェアを提供しているわけではありません。そしてEMC PowerPathはEMC自身のストレージ製品以外にはほんの僅かなストレージしかサポートしていないのです。
データパス上のQoS(サービス品質)
データパス上のサービス品質(QoS)はカスマシンからデータストアに至るまでの全体のQoSを提供しているという点で非常に興味深いソリューションです。ハイパーバイザーは状況がよく理解できている環境です。カーネルサービスはどのI/Oがどの仮想マシンのものであるかを理解しています。しかし、I/Oがホストを通りすぎて、ネットワークに入ると、ホストから送り出した宛先のアドレスしかわからなくなります。ホストレベル以外での優先順位付け以外は行えなくなってしまうのです。すべてのアプリケーションがビジネスにおいて同様に重要であるということはないので、全体のQoSでビジネスクリティカルアプリケーションが必定なリソースを利用できることを保証することはとても重要なのです。ストレージコントローラーのポートの拡張性の制限がQoS全体に影響を与えます。ほとんどのアルゴリズムと同様、利用可能なデータパスの利用状況をバランスすることを目的としておらず、リソースの競合時の優先順位にのみ対応しているのです。
ストレージアレイ層
Storage DRSは仮想マシンファイルをそのリソース要求で移行させることが可能です。Storage DRSは仮想マシンから見た際のレイテンシを監視しており、これはカーネルとデータパスのレイテンシを合算したものです。Storage DRSは移行元と移行先のデータストアのすべてのレイテンシを監視し、移行による変更でのメリットを計算します。カーネルとデータパスのレイテンシを別々に利用し、コンピューティングのレベルでの移行を実行するわけではありません。Storage DRSはStorage vMotionのあとに、新しいVMXファイルの読み込みのために自身にvMotionを実行しますが、仮想マシンは同じホスト上に残ります。言い方を変えると、Storage DRSは帯域の偏りを正すために仮想マシンをコンピューティングレイヤーもしくはストレージレイヤー上で移行させるようには設計されていないのです。
ほとんどの利用されているストレージは非同期LUN単位アクセスを提供しています。ストレージコントローラー上のすべてのポートは入ってくるReadとWriteの操作を受け入れますが、LUNを管理しているコントローラーが常にRead操作を管理しています。コントローラー間でLUNを分散してしまうので、ストレージコントローラーのCPUの利用率やポートの利用率が簡単に偏ってしまいます。LUNはCPUの利用率の改善のためにマニュアルで変更しなくてはなりませんが、残念なことに、動的に行うことはできません。マニュアルでの検知と管理はそれを見ている人間にとっては良いのですが、多くの組織はこのような精緻なレベルで常時環境を監視しているわけではありません。LUNを自動的に切り替えるストレージについての議論はありますが、それは一定の量の｢プロキシリード｣が検出された場合のことです。これはI/Oが最適化されていないパスを通って転送されたか、PSPがさほど良い仕事をしていないような場合か、すべての最適化されたアクティブなパスが死んでしまったような場合のことです。いずれも健全性の危険信号でも、そして環境が適切に設計されていないということでもありません。
オーバーサイズは解決になるのか?
一時的には帯域をオーバーサイズにすることが役に立ちます。というのも、ワークロードの肥大化や重要性の多様化を予測することは難しいからです。全くもって新しいアプリケーションを導入することは既存の設計に非常に大きな影響をもたらします。開発業界を見ていると、ほとんどのデータセンターはこれらの新しいアプリケーションを吸収することを余儀なくされています。既存の従来型のストレージ上のソリューションでそれが要求するサービスを提供し、必要なリソースを拡張して提供することはできるのでしょうか?
包括的なロードバランサーが利用できない
基本的に、コンピューティングのレイヤーとデータストアのレイヤーの間のデータパスはクラスタリソースとして取り扱われていません。仮想マシンを配置するホストはコンピューティングリソースの利用状況と割り当てによって決定され、ストレージレイヤとの間にあるデータパスは無視されています。これはクラスタ内にホットスポットを生じさせる可能性があります、他のホストでは十分に余裕があるのに、特定のホストではデータパスを使いきってしまうということです。データパスを使いきってしまうとアプリケーションのパフォーマンスに影響が出てしまいます。
残念なことに、今日、仮想マシンが要求する様々なリソースを考慮できるメカニズムは存在しません。他のボトルネックや不都合を生み出すことなく、インテリジェントにこれらのリソースを管理できるソリューションはないのです。
この記事は既存のソリューションにケチをつけることが目的ではありません。これの問題を解決するのはとてもむずかしい上に、様々なベンダーの様々なコンポーネントが適切に配置され統合してうまく動くことを期待されている業界ではなおさらです。さらに、他のベンダーからそれがリリースされれば新しいテクノロジーの進化を取り入れテイク必要がある状況なのです。後方互換性も忘れてはいけません。世界平和のほうが簡単かもしれない!
このデータパスがコントロール出来ないという問題、スイッチ間の接続の多重化の問題、そしてアプリケーションを考慮できないという問題を考えに入れ、多くのソリューションは今日では十里型のストレージアーキテクチャのパラダイムから離れていこうとしています。選択的なパフォーマンスの提供とポリシーによる管理を目指し、様々なコンポーネントが一括集中したコントロールプレーンを持たない新しいアーキテクチャが台頭し始めています。 PernixData FVP、VMware VSAN、そしてハイパーコンバージドシステムは一貫した制限のないネットワークパフォーマンスを提供するクロスバースイッチのアーキテクチャのP2P接続ネットワークを拠り所として、ストレージのパフォーマンスとストレージサービスの堅牢性の要求に答えています。
P2P接続と、ハイパーバイザーが状況をよく理解しているという点を活用して、拡張が簡単であるというだけではなく、一貫した、選択的なパフォーマンスレベルを提供できる環境を作ることができるようになるのです。未来のデータセンターがまた一歩近くなります!
パート 4ではストレージコントローラーのアーキテクチャを取り上げ、なぜホスト間の通信とホストリソースの利用が拡張性の問題を解決するのかをご紹介します。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
