HCI導入後に注意すべきリスクとは

従来のHCIアーキテクチャはトラブルシューティングの複雑さを増し、メンテナンス時にリスクを伴う可能性があります。

従来のHCIの最も多く主張されている利点の1つとして、HCIアーキテクチャは複雑さを軽減させると言われています。HCIはシンプルですが、実はあとで高く付くことがあります。

• トラブルシューティングの複雑さが増加
• より大きなオペレーショナルリスク

長年にわたって安定稼働しなければならない重要なインフラストラクチャの決定を行う際に、これらの要素を見落とさないようにしましょう。

問題のトラブルシューティング

HCIの緊密に結合されたアーキテクチャが仇となって、パフォーマンスの問題のトラブルシューティングが難しくなることがあります。すべてが各ノードで階層化されているため、パフォーマンスのボトルネックの原因を切り離すことがほとんど不可能になるのです。もしVMのメモリとCPUリソースを増やしても問題が解決しない場合は、問題がIOであると仮定することになりますが……

• IOボトルネックはどこですか？それはホスト、ネットワーク、またはストレージにありますか？
• あまりにも多くのデータサービス（重複排除、消去コーディング、複製など）がメタデータを増やし、パフォーマンスに影響していませんか？
• ゲストVMとストレージVMは同じリソースを共有しているのに、どうやって問題を特定しますか？
• IOが内部ストレージ、または別のノードのストレージの問題なのかわかりますか？ 内部ストレージの場合は、負荷をバランシングもしくは退避させることが簡単にできますか？
• 負荷を移行するためのワークロードは、反ってパフォーマンス負荷がかかってしまいませんか？
• 問題が別のノードのストレージであれば、それはネットワークのボトルネックですか？複数の外部ノードが関与していますか？

これらのように、プロセスは複雑になりますが、HCIクラスタの規模が大きくなればなるほど複雑さは増します。多くの場合、上記のシナリオに対する解決策は、ノード（リソース）を追加することです。

より高いリスク

仮想化は、ハードウェア保守やパッチ適用など、従来の多くのインフラストラクチャの問題を解決するのに役立ちました。外部ストレージを使用すると、vMotionまたはHyper-Vのライブマイグレーションを使用して、コンピュートおよびメモリの負荷を移動することで、VMを別のホストに簡単に移動できます。しかしながら、HCIアーキテクチャではストレージはコンピュートと密接に結びついていますので、考慮すべき点がたくさんあります：

• メンテナンス前のデータ退避。ほとんどのメーカーやSIerは、データを退避させずに保守を行いますが、それはリスクが発生するためベストプラクティスとは言えません。ただ、データを退避すれば、コンピュートノードとストレージノードの負荷が他のノードに移動するので、その分ボトルネックやノイジーネイバー（うるさい隣人）問題の恐れが発生します。
• 容量が減る。メンテナンスのためにノードをオフラインにすると、部分的に大きくストレージがオフラインになるため、クラスタが制約を受ける可能性があります。
• 利用可能なフラッシュが減る。特にハイブリッド構成では、ノードがオフラインになると、大量のフラッシュがオフラインになることになります。Flashはキャッシュとして非常に重要なので、フラッシュミスが発生し、パフォーマンスが低下します。

すべてのことは、ITチームがメンテナンスウィンドウの作成に細心の注意を払う必要があることを意味します。メンテナンスを行うのはリスクも伴いますが、パッチやその他のメンテナンスを定期的に行わないと、それに伴うリスクも大きくなりますよね。

雪だるま式に増える課題

単一のHCI障害は、より大きな問題を引き起こす可能性があります。何らかの理由でホストに障害が発生すると、次のような影響があります。

• 利用可能なコンピューティングとストレージリソースが減ります。
• ハイブリッド構成では利用可能なフラッシュが使えなくなると、残りのフラッシュが飽和してパフォーマンスが落ちます。障害が発生したノードにあったVMは、別のフラッシュに移動させる必要があります。通常かどうしていたVMも、移動してきたVMもどちらもリソース不足になってパフォーマンスが落ちてしまいます。
• これらのプロセスは、ノードが障害を起こすたびに繰り返されます。

フラッシュドライブなどの単一のコンポーネント障害が発生すると、ノード全体が動かなくなる可能性があります。その結果、ストレージがホストから切り離されている場合よりも、操作に与える影響がはるかに大きくなります。

ベスト・オブ・ブリード・アーキテクチャ（いいとこ取り）はリスクが低い

従来のHCIは、仮想化のステートレスな性質が活かせずにリスクを増大させます。それに対して、疎結合でまとまったアーキテクチャでは、パフォーマンス問題のトラブルシューティングが簡単です。特に、アーキテクチャを基礎から構築してワークロード単位の分析を提供する場合は、たとえば、Tintriでは、コンピューティング、ネットワーク、およびストレージ全体のレイテンシ問題の根本原因を確認し、VMまたはコンテナレベルでのインフラストラクチャ全体を表示することができます。

ストレージとコンピューティングは物理的および論理的に分離されているため、上記のリスクのいずれもティントリでは影響しません。そのため、大規模なエンタープライズインフラストラクチャの基盤として安心して使えるのです。

Author

ティントリジャパン合同会社　マーケティング本部
マーケティング本部長　羽鳥正明

外資系ITベンダにてPC、サーバーのプロダクト・マーケティングを8年間担当。その後Linux/OSSビジネス関連企業にてマーケティング全般をマネジメントしたあと、ストレージ業界に身を投じ、EMCやDellでエンタープライズ向けストレージのプロダクト・マーケティングを歴任し、現在は仮想化向けストレージのティントリにてマーケティングならびにPR活動全般を一手に引き受ける。

また、2015年4月より、一般財団法人ストレージネットワーキング・インダストリー・アソシエーション日本支部(SNIA JAPAN)にて運営理事として参画。

コンタクト：info.japan@tintri.com

※本コラムは、ティントリジャパンに掲載されたブログ記事より転載したものです。

[PR]提供：ティントリジャパン