HCIを導入した後に注意！
従来の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またはコンテナレベルでのインフラストラクチャ全体を表示することができます。
ストレージとコンピューティングは物理的および論理的に分離されているため、上記のリスクのいずれもTintriでは影響しません。そのため、大規模なエンタープライズインフラストラクチャの基盤として安心して使えるのです。
