Suhrが2022年9月15日に投稿した記事の翻訳版です。Nutanixはお客様に選択の自由を提供することでその評価を獲得してきました。これについては多くの例がありますが、今回の記事では、Nutanixクラウドプラットフォームのアーキテクチャがコンピュートハイパーバイザーとは独立して稼働する分散型AOSストレージスタックによってどのようにお客様にハイパーバイザーの選択肢というオプションを提供するのか、掘り下げたいと思います。ご存知のとおり、ワークロードの稼働にどのハイパーバイザーを使うのか、選ぶのは朝起きで、どのシャツを着るのか選ぶのとはまるで違います。どんなときにも着ていけるシャツ(そしてハイパーバイザーも)はありません。ワークロードとアプリケーションはそれぞれに固有の要件を抱えており、それらのワークロードを混在させることもあるため、要件に競合や重複も出てきます。HCIで柔軟に稼働させる事ができることは、こうした環境において大変重要です。分散ストレージスタックと仮想化コンピュートレイヤーが異なるイノベーションによって推進されているということもまた事実です。6.7を利用しているお客様にとって、コンピュート仮想化レイヤーは十分に成熟したもので、新しい、よりコストの高いバージョンへのアップグレードは強い動機を感じるものではありません。したお客様においては、ハイパーバイザーのアップグレードを行わずにアップグレードができるNutanixのストレージスタックのアップグレードの機能は選択肢と統制のもう一つの事例になります。今回の記事では、単独のハイパーバイザーを動作させることと、複数のハイパーバイザーを動作させることについて掘り下げ、ハイパーバイザーの選択肢と共に、どのような以降の選択肢があるのかと、それらの価値を示す例をいくつか取り上げたいと思います。マルチハイパーバイザーのサポートNutanixのコントロールプレーンは利用しているハイパーバイザーに関わらず、一貫性を保っています。これはつまり、クラスタ、レプリケーション、運用、更にその他のNutanix製品を利用する際の管理エクスペリエンスが同じであるということです。複数のハイパーバイザーが展開されている環境であったとしても、単一インスタンスからの管理が可能で、容易に可視化とレポート作成が可能です。ストレージレベルでは、データ構造とレプリケーション機能をどんなハイパーバイザーを使っていたとしても利用可能です。動作しているハイパーバイザーを切り替えられる機能は、お客様が環境内のリスクとハイパーバイザーレイヤーに紐づくコストを管理することに役立ちます。これは異なるハイパーバイザーを異なる環境で動かす、もしくは完全に移行することで実現されます。ほとんどのデータセンター内でたった一つのハイパーバイザーだけが利用されているという環境が一般的ではあるものの、2つ目のハイパーバイザーを利用するということが非常に意味を成す事例もいくつかあります。した事例には特定のアプリケーションが特定のハイパーバイザーを要件としている場合や、パブリッククラウド上で稼働するクラスタを必要とする場合、そして、ディザスタリカバリのための環境を構築しようとする場合です。AHVをサポートするアプリケーションがどんどん増えつつありますが、皆様のビジネスにとって重要なアプリケーションが特定のハイパーバイザーしかサポートしていないということもあります。した状況において1つのハイパーバイザーを利用し、その他のワークロードについては他のハイパーバイザーへと切り替える事もできます。ディザスタリカバリ用の場所で異なるハイパーバイザーを動かすという事例についてもう少し掘り下げていきましょう。ESXiをハイパーバイザーとして利用されているお客様も多くおられます。コストを削減し、運用をシンプル化するため、多くのこうしたお客様がAHVをDR環境で利用しています。このアプローチを取ることで、ESXiハイパーバイザーのライセンスと管理コストをDRクラスタ側に支払うことを回避しているのです。これはNutanixにビルトインされたレプリケーション機能がESXiとAHVクラスタ間でも動作するからこそ実現されます。これはプライマリのESXiベースの環境からAHVベースの環境へとフェイルオーバーし、状況が整えばフェイルバックも実現します。シンプルで洗練された移行Nutanixが初めてか、もしくはすでにESXiをハイパーバイザーとしてクラスタを展開したことがあるかに関わらず、AHVへ移行ができるという選択肢はそれ自体が柔軟性を備えたシンプルなソリューションです。AHVベースのクラスタへの移行をシンプルにするツールです。Nutanixへと移行する際にもvMotionが適切な選択肢ではない場合に有用なツールです。Move製品では単一の仮想マシンや仮想マシンのグループを選択して定義したグループを目的地となるAHVクラスタへと移行させます。Moveはターゲットへレプリカコピーをほぼデータが同期した形で維持します。実際の移行を選択した際には仮想マシンをシャットダウンし、最後の変更をレプリケーションして、目的地側で仮想マシンをスタートさせます。このアプローチは計画的な、そしてカットオーバー時のダウンタイムを最小にすることができる簡単な移行手法となります。一つの方法はインプレースクラスタコンバージョン(変換)を利用する方法です。HCIクラスタを仮想マシンを越のクラスタへと移行させることなく、AHVへと変換を行います。この操作はNutanixコントロールプレーンで管理され、ホストとその上で動作している仮想マシンをシャットダウンします。CVM内で動作するプロセスが自動的にホストをAHVへとコンバートし、仮想マシンをAHVフォーマットへと変換し、ホストと仮想マシンをオンラインへと戻します。これはホストごとにクラスタ全体が変換されるまでローリングで行われます。シンプルなAHVのアップグレードNutanixではアップグレードは簡単です。我々はコンシューマー製品の簡単さのエクスペリエンスをエンタープライズのインフラストラクチャーへともたらしました。シームレスで、ダウンタイムのない、1-クリックのアップグレードをコアとなるAOSストレージと管理プレーンに対して提供するところからはじめました。Nutanixがストレージを超えて例えば仮想化の領域にまで拡大した際に、あらゆる対象をアップグレードするツールのニーズが生まれました。これがあらゆる製品のアップグレードをシンプルにする能力を持つサービスであるライフサイクルマネージャー(LCM)の作成に繋がりました。LCMは今では複数のNutanix製品のアップグレードすることができ、リスクとレガシーなインフラストラクチャーのアップグレードのエクスペリエンスのようなそれにまつわる膨大な時間を取り除きながら、それらをほんの数クリックに変えてしまいます。LCMはアップデートされた製品のインベントリと展開されているヴァージョン、そしてアップグレード時の互換性についても維持します。Centralなどのアップグレードが表示され、LCMが依存関係とアップグレードのパスを適切に取り扱います。これらはこれまでは管理者やそのアウトソース先のパートナーなどが行っていた仕事です。LCMはアップグレードの前に何百ページにも及ぶ製品ドキュメントやナレッジベース記事、ブログを読む時間を節約させることができるのです。NutanixとLCMでそれを利用する組織は確信を持ってためらいなく仮想化レイヤーをアップグレードでき、更に製品のライフサイクルの終息までアップグレードを待つということもしなくて済みます。8へアップグレードで苦しめられているのがVMwareのお客様です。8へとアップグレードしなければならず、管理チームは2倍の調査、ストレス、そしてリスクを背負うことになります。過去の経験から言えば、ほとんどの組織はこうした2重のアップグレードを最後の最後まで避ける傾向にあり、サポートを受け続けるためにそれしか最後の手段が残されていないという場合にしか実施しません。したアップグレードは従業員の稼働時間とリスクを減らすためにパートナーへの依頼を行う対価という形でコストとしてのしかかってきます。HCIへ乗り換えていただくことで、こうしたためらいだらけの日々を避けることができます。ESXiをハイパーバイザーとして維持しながら、LCMでシンプル化された計画をもとにハイパーバイザーをアップグレードする必要のないストレージのアップグレード機能を活用することができます。AHVを選択した場合、ハイパーバイザーのアップグレードまでもが心配無用の過去のものとなります。これが重要なのか?一箇所、もしくは複数箇所、またはハイブリッドクラウドアーキテクチャーなどどのようにNutanixを展開されていたとしても、Nutanixはニーズに合わせた形で適切なハイパーバイザーを適切な場所で稼働させる柔軟性を提供します。どこから始めたとしても、Nutanixは皆様の望む状態を実現するツールと柔軟性、そして利用しやすい移行方法でワークロードをストレスから開放します。お望みのお客様にとっても重要なことですが、何よりもコンピュートのハイパーバイザーのヴァージョンのアップグレードを強要されないということが素晴らしいのです。これこそがNutanixのお客様に提供する柔軟性、そしてリスク、時間、コストの削減のもう一つの具体例です。自由な選択肢がNutanixの成功のキーとなっています。ベンダー、バージョン、場所の選択肢です。これは不確かな時代に大きな付加価値を生むことでしょう。download.OK。