Amazon Web Services ブログ
VMware Cloud on AWS Outpostsの基礎についての深掘り
AWS で Sr. Manager, Solutions Architecture を務める Aarthi Raju と Sr. Partner Solutions Architect を務める Schneider Larbi による記事です。
お客様がワークロードのモダナイズとクラウドへの移行を検討する際、ユースケースによっては完全にクラウドに移行し、Amazon Elastic Compute Cloud (Amazon EC2) やコンテナ、サーバーレスアーキテクチャにアプリケーションを実装することを選択する方もいらっしゃいます。
vSphere ワークロードを持つお客様は、VMware Cloud on AWS を利用して、アプリケーションを高速かつシームレスにクラウドに移行しています。
VMware Cloud on AWS では、アプリケーションのコードやロジックをリファクタリングや変更することなく、ワークロードをより迅速に移行することができます。我々のチームは、vSphere のワークロードをクラウドに移行するお客様と仕事をしていく中で、低レイテンシー、ローカルでのデータ処理、あるいはデータのガバナンスやコンプライアンスなどの要件により、特定のワークロードについてはオンプレミスやエッジに残す必要があるとフィードバックを受け取りました。
Amazon Web Services (AWS) は、vSphere をご利用のお客様のこうしたユースケースに対応するため、VMware Cloud on AWS Outposts を発表しました。このサービスは、企業がこれらのワークロードを、オンプレミスのフルマネージドな VMware Cloud on AWS スタック上で実行できるようにするものです。
VMware Cloud on AWS Outposts により、AWS は AWS Availability Zones (AZ) の境界を拡張し、vSphere 基盤による VMware Software-Defined Data Center (SDDC) を AWS リージョンからエッジまで延伸することが可能になります。これは、お客様がクラウドのオペレーションモデルを利用しつつオンプレミスで vSphere ワークロードを実行できるようラックの形で提供されています。
お客様は、レイテンシー、データの所在地、およびローカルデータ処理の要件により、他の方法ではクラウドに移行できなかったレガシーアプリケーションを実行できるようになりました。さらに、AWS リージョンがない場所でも、フルマネージドなソリューションで vSphere ワークロードを実行できるようになりました。
本稿では、VMware Cloud on AWS Outposts の基礎について深く掘り下げ、お客様とパートナーがこのサービスを活用してオンプレミスの vSphere ワークロード展開をスケールさせたり、モダナイズする方法について説明します。
VMware Cloud on AWS Outposts とは何か
AWS Outposts は、AWS のインフラストラクチャ、サービス、オペレーティングモデルをオンプレミスでお客様に提供するものです。これは、AWS が 1 つまたは複数のサーバーラックからキャパシティをプールし、お客様が使用できるようにするための論理的な構成モデルだと考えてください。
VMware Cloud on AWS Outposts では、ESXi、Software Defined Storage の vSAN、Software Defined Network の NSX、中央管理のための vCenter で構成される VMware SDDC を Outposts ラックで稼働させ、親となる AWS Region に接続する形で運用しています。
VMware Cloud on AWS Outposts は、クラウドで使用されているのと同じ SDDC コンポーネントを保持します。以下のアーキテクチャは、その様子の論理的な全体像を示したものです。
図 1: VMware Cloud on AWS Outposts のアーキテクチャ
上の図は、デプロイされた AWS Outpost の論理的な構成を示しています。このアーキテクチャでは、論理的な各 Outposts がコンピュート、ストレージ、ネットワークコンポーネントを含むラックで構成され、サービスリンクを使用して AWS リージョンの AZ との接続性を持っていることを示しています。
これは、VMware Cloud on AWS Outposts がスタンドアロンラックとしてリージョンとの接続無しに独立して動作するようには設計されていないことを意味しています。むしろ、カスタマーサイトへのリンクを通じて論理的な拡張を行うことで、Availability Zone の一部として扱われます。SDDC が稼働するインフラ基盤は AWS が完全に管理し、ラックの SDDC コンポーネントは全て VMware が管理します。
コンピュート
VMware Cloud on AWS Outposts は、Amazon EC2 で提供されている i3en.metal インスタンスを使用しています。このインスタンスはハイパーコンバージドインスタンスであるため、サーバーによってコンピュートと共にストレージおよびネットワークも提供されます。
インスタンスは ESXi が稼働するベアメタルホストで、48 コア CPU @2.5Ghz の Intel Xeon Cascade Lake プロセッサを搭載しています。デフォルトでハイパースレッディングが有効になっているため、ノードあたり合計 96 の論理 CPU コアが提供されています。
これにより、CPU 負荷の高い vSphere ワークロードをエッジで低レイテンシーで実行するための十分な CPU パワーが提供されます。また、各ノードには 768GiB のメモリが搭載されています。
さらに、お客様が注文されたすべての構成には、予備機 (“ダークキャパシティ”) が付属しています。この予備ノードは、Elastic Distributed Resource Scheduling (eDRS) によるスケールアウトや、ライフサイクル管理に使用されます。例えばホスト障害が発生した場合、技術チームが現地入りしてノードを交換するまでの間、予備機を稼働させることができます。
ラック内には、Outposts サービス全体の管理サーバーとなる 4 台の M5 EC2 インスタンス (ラックサーバー) が存在します。これらのインスタンスにより、AWS はラック内のハードウェアコンポーネントをリモートから管理することができます。
さらに、これらラック内の M5 インスタンスにより、AWS リージョンから SDDC ソフトウェアをダウンロードし、ラックにデプロイすることができます。下図は、6 ノードラックの論理的な構成図になります。
図 2: VMware Cloud on AWS Outposts の HW 構成
VMware Cloud on AWS Outposts は、お客様によるクリック操作、もしくは VMware API によって、SDDC ノードをスケールアップまたはスケールダウンすることができるように設計されています。注文されたラック内のノード数に応じて、お客様はこれらの機能を使用しノード数を調整することができます。
例えば、6 台のノードを搭載したラックを購入した場合、VMware Cloud on AWS Outposts での SDDC 展開に必要な最小ノード数である 3 台での導入から始め、ラック内で購入したノードをすべて使い切るまでノードを追加してスケールアップすることが可能です。
ストレージ
VMware Cloud on AWS Outposts を支える主要なストレージは、i3en.metal ベアメタルインスタンス内の低レイテンシー、高ランダム I/O 性能、高シーケンシャルディスクスループットに最適化された内蔵の高密度な Non-Volatile Memory Express (NVMe) SSD インスタンスストレージによって提供されています。
各ノードは、50TiB の Raw ストレージ、もしくは 45.8TB の使用可能な実ストレージ容量を提供します。これらのドライブは、VMware vSAN を通してラック内の仮想マシン (VM) 用ストレージとして提供されます。
各 NVMe SSD ドライブは、ベアメタルインスタンス内で暗号化されています。さらに vSAN は、静止データの暗号化を提供する AWS Key Management Service (AWS KMS) を使用して別レイヤーでの暗号化を追加します。ユーザーは、VMware の SPBM (Storage Policy Based Management) VM ストレージポリシーを個々の vdisk レベルで利用することができます。以下は、1 台の i3en.metal ノードがどのように設計されているかを示しています。
図 3: i3en.metal の vSAN ストレージ設計
この設計から、各 SSD ドライブの一部を vSAN のキャッシュ用に、残りをキャパシティ用に確保します。一部の構成では、キャッシュ用の高速ディスクとワークロード実行用のキャパシティディスクを混在させて使用しているお客様もいらっしゃいます。
VMware Cloud on AWS Outposts の場合、vSAN に使用するディスクはすべて SSD であるためパフォーマンスには影響がありません。仮想化可能なほぼすべてのワークロードを実行できるように設計されています。
ネットワーク
各 VMware Cloud on AWS Outposts は、オンプレミスから AWS リージョン内の親 AZ に接続されています。VMware Cloud on AWS Outposts の基盤となるネットワークは、Amazon Virtual Private Cloud (VPC) です。このネットワーク構成は AWS クラウド上で動作し、Outposts サービスはそれに接続しています。
これは、サービスリンクを用いて VPC をクラウドからオンプレミスに拡張することで、Outposts の基盤となるコンポーネントをオンプレミスの VPC に展開し、お客様がより身近に AWS クラウドを利用できるようにしたものです。
VPC のネットワークは、Outposts のラック内のベアメタルインスタンスのアップリンクネットワークと考えることができます。ベースとなる VPC 上では、SDDC 上の NSX によってワークロードネットワークはインフラ管理ネットワークから抽象化されます。
下図は、ネットワーク設計の観点から Outposts がどのように見えるかを示した論理構成図です。
図 4: VMware Cloud on AWS Outposts の論理構成図
ローカル接続
お客様は Outposts からお客様のネットワーク機器へ物理的な接続を設定することで、オンプレミスのネットワークを VMware Cloud on AWS Outposts にシームレスに統合することができます。以下のアーキテクチャ図は、その様子を論理的に示したものです。
図 5: VMware Cloud on AWS Outposts との物理接続
物理的な接続が完了した段階で、お客様のネットワークから専用の VLAN を割り当て、それをお客様ネットワーク機器と Outpostsネットワーク機器に適用し、リンクアグリゲーションプロトコル (LACP) を使用してリンクアグリゲーションを構成します。これらの VLAN は、リージョン向けのサービスリンクトラフィックと、オンプレミスネットワーク向けのトラフィックであるローカルゲートウェイ (LGW) 向けのトラフィック専用で使用されます。この設定をサポートする VLAN は、お客様からご提供いただきます。
図 6: お客様および Outposts ネットワーク機器間のリンクアグリゲーション
リンクアグリゲーションで物理接続を設定したら、最後のステップとして Border Gateway Protocol (BGP) を使用して、Outposts のネットワーク機器とお客様機器の間で経路情報交換の設定をします。BGP セッションを設定する前に、サービスリンクに少なくとも /26 の IP アドレスレンジを提供する必要があります。このレンジはパブリック IP、もしくはインターネットにアクセスできるものでなければいけません。
サービスリンク用のレンジは 2 つの連続したレンジに分割され、お客様機器と Outposts のネットワーク機器にアドバタイズされます。ローカルゲートウェイの VLAN については、VMware Cloud on AWS Outposts のためにネットワークレンジを割り当てる必要はありません。オンプレミスへの通信が必要な SDDC の論理ネットワークは、ローカルゲートウェイ BGP セッションを使用してオンプレミスへの経路情報を交換します。
図 7: VMware Cloud on AWS Outposts とお客様ネットワーク機器間の BGP セッション
上記のアーキテクチャは、NSX Software-Defined Networking が LGW のルーティング構成とどのように相互作用するのかを示しています。ベースとなる VPC ネットワークは、ラック内の i3en.metal ベアメタルインスタンスにアップリンク接続を提供します。NSX のネットワークスタックは、Outposts 上で稼働する VM の接続を提供します。
この設計により、Outposts 上に作成された NSX 論理ネットワークは、VPC を通じて自動的にローカルゲートウェイにアドバタイズされ、LGW も Outposts のネットワーク機器を通じてお客様ネットワーク機器に転送します。
以上がオンプレミスネットワークが Outposts の SDDC 内に作成されたネットワークと通信するための経路情報交換の設定方法です。Outposts からオンプレミスネットワークへのローカル接続の設定について詳しく知りたい方は、こちらのドキュメントをご参照ください。
リージョンとの接続
VMware Cloud on AWS Outposts は、Wide Area Networking (WAN) 接続を介して親リージョンに接続します。お客様は、Outposts のサービスリンクをオンプレミスに接続する際に、2 つのオプションがあります。
1 つ目は、パブリック仮想インターフェース (VIF) による AWS Direct Connect の利用で、以下のアーキテクチャはサービスリンクの WAN 接続をどう構成するかを示しています。
図 8: AWS Direct Connect のパブリック VIF を利用したサービスリンク接続
上のアーキテクチャは、AWS Direct Connect によるリージョンへのサービスリンク接続を図示しています。物理的な Direct Connect 回線が確立された後、お客様は Outposts が接続されるリージョンで終端するパブリック VIF を確立することができます。
パブリックインターフェースは、AWS がオンプレミスのエッジデバイスと全てのパブリックルートを交換できるようにするための BGP セッションです。サービスリンクのネットワークレンジとしてプライベート IP を使用する場合は、パブリック IP へのネットワークアドレス変換 (NAT) を構成することで、サービスリンクが AWS Direct Connect 上で構成されたパブリック仮想インターフェースを使用してリージョン内の Outposts サービスにアクセスできるようになります。
NAT は、オンプレミスのエッジデバイス、または AWS Direct Connect のリージョンにあるエッジデバイスのいずれかに設定することができます。
一方で、サービスリンクのトラフィックを公衆インターネット上で通信させたくないというお客様もいらっしゃいます。そのような要件がある場合、AWS Direct Connect 上のプライベート VIF を使用してサービスリンクを構成することができます。
図 9: AWS Direct Connect のプライベート VIF を利用したサービス接続
上記のアーキテクチャでは、サービスリンクトラフィックは公衆インターネットを通過せず、オンプレミスの IP レンジを使用してプライベート VIF 上で送信されます。つまり、お客様がインターネットに接続されていないプライベート IP を使用する場合、サービスリンクのネットワークレンジに対してネットワークアドレス変換は必要ありません。
このオプションの場合、お客様は注文前に既存の AWS Direct Connect 回線を用意している必要があります。さらに、AWS アカウントにプライベート仮想インターフェースをプロビジョニングし、VMware Cloud on AWS Outposts を実行している VMware 管理の AWS アカウントに共有する必要があります。
この前提条件を満たした上で、お客様はオンプレミスで使用されておらず、かつネットワーク内の他の IP レンジと競合しないプライベートネットワークレンジを提供する必要があります。次に、仮想プライベートゲートウェイの Autonomous System Number (ASN) と、払い出された Direct Connect プライベート VIF の IDを提供する必要があります。これらの詳細は、VMware Cloud on AWS Outposts 注文時に、プライベート接続を構成するために自動的に入力されます。
図 10: Outposts 接続注文ページのスクリーンショット
最後に、お客様は ISP から公衆インターネット接続を使用して、Outposts から AWS クラウド内のサービスに接続することも可能です。以下のアーキテクチャは、その設定方法を示しています。
図 11: サービスリンクのインターネット接続
High Availability
High Availability は、ホスト障害やネットワークに問題が発生した際に、正常稼働中のホストで仮想マシンを再起動させる VMware の代表的な機能です。VMware Cloud on AWS Outposts SDDC では、クラウドおよびオンプレミスの VMware と同等の機能を持ちます。
VMware Cloud on AWS Outposts は、仮想マシンレベルの保護以外にも、高い可用性を実現できるように設計されています。ラック内の電源やネットワーク機器も回復性が担保されています。
さらに、VMware Cloud on AWS Outposts には、VMware の高可用性を補完するために、購入した各構成の容量が余分に提供されます。ラック外でも、サービスリンク接続の回復性を担保するようお客様にお勧めしています。
AWS Direct Connect を使用する場合は、複数の Direct Connect ロケーションを利用した回復性のあるリージョンへの接続を推奨しています。詳しくは、Direct Connect の回復性に関する推奨事項のドキュメントをご参照ください。
またお客様は、1 つの AZ が利用できなくなった場合にサービスリンクの回復性を確保するために、リージョン内の異なる AZ に接続する複数の論理的な Outposts をオンサイトで使用することができます。サービスリンクにインターネット接続を使用する場合は、少なくとも 2 つの異なる ISP からの接続がサービスリンク構成にあるようにしてください。以下のアーキテクチャは、このセットアップ方法を示しています。
図 12: VMware Cloud on AWS Outposts で推奨される HA 構成
ハイブリッドリンクモード (HLM)
vCenter のハイブリッドリンクモード (HLM) により、VMware で稼働するオンプレミスのリソースと VMware Cloud on AWS Outposts を一元的に表示、管理することができます。これにより、VMware Cloud on AWS Outposts の vCenter をオンプレミスの vCenter にリンクし、エッジとオンプレミスのリソースを統合的に管理するインターフェイスを提供することができます。
また、データセンター内の VMware Cloud on AWS Outposts とリージョンにある別の VMware Cloud on AWS の間でもこれを構成することができます。この機能を利用するには、vSphere 6.5 またはそれ以降のバージョンが必要です。
図 13: VMware Cloud on AWS Outposts とオンプレミス間の HLM
参考情報
本稿では、VMware Cloud on AWS Outposts の基礎について説明しました。以下は、これらをデプロイする際に役立つ参考情報です。
翻訳は ENT-C SA 太田が担当しました。原文はこちらです。