【レポート】 VMware Cloud on AWSのアーキテクチャーパターンとベストプラクティス #reinvent #ARC402-R
はじめに
中山(順)です
本記事は、以下のセッションのレポートとなります。ご査収ください。
速報性を重視したため一部内容が不正確な部分があるかもしれません。気が付き次第訂正します。
また、レポート記事ではありますが、公式ドキュメントへのリンクを張るなどして一部補足しています。
概要
VMware on AWSの概要から始まり、ネットワークやAWSサービスとの組み合わせをわかりやすく説明してくれるセッションでした。
- title: ARC402-R - [REPEAT] Architectural Patterns and Best Practices with VMware Cloud on AWS
- Speaker: ANDY REEDY (Manager, Partner Solutions Architecture , Amazon Web Services)
The recent launch of VMware Cloud on AWS gives customers new options for addressing several use cases, including cloud migration, hybrid deployments, and disaster recovery. We introduce and describe design patterns for incorporating VMware Cloud on AWS into existing architecture and detail how the service’s capabilities can influence future architectural plans. We explore design considerations and nuances for integrating VMware Cloud on AWS Software Defined Data Centers (SDDCs) with native AWS services, enabling you to use each platform’s benefits. Architects, system operators, and anyone looking to understand VMware Cloud on AWS will walk away with examples and options for solving challenging use cases with this new, exciting service.
セッション内容
VMware on AWSとは?
- WMware on AWSとは
- オンデマンドで利用できるクラウドサービス
- SDDC(Software Defined DataCenter)
- VMware社が管理
- 最新のVMware製品を活用してリソースの柔軟性を確保
- ESXi
- NSX
- VSAN
各コンポーネントの仕様
各コンポーネントの詳細は画面を見ていただくとして、特徴的だったのはストレージです。
ローカルのフラッシュストレージをVSANでアグリゲートする仕様で、EBSやEFSは使用していないとのこと。
ネットワークも特徴的でしたが、それは後述します。
AWSおよびオンプレミスとの連携
VMware on AWSの環境は、AWSのサービスともオンプレミスのサービスとも接続可能です。
アカウント、支払い
VMware on AWSを利用する際、アカウント自体が分かれるとのこと。
- VMware on AWSのリソースは専用アカウントで作成
- AWSへの支払いはVMwareが行う
- エンドユーザーはVMwareに支払い
- 日本でのリリース時も同様になると推測はしますが、気になる方は個別に確認しましょう
- アカウントはシングルテナント
ユースケース
以下のようなユースケースを想定しているとのこと。
- 既存のデータセンターの拡張
- データセンターの移行
- 併用
- 例えば、ライフサイクルが長くてかかる負荷が安定しているのはオンプレミス、ライフサイクルが短くかかる負荷が変動するならAWS、など?
- あとは、オンプレミス環境の拡張が間に合わない場合の代替手段など?
利用開始
利用開始は、専用のサイトからサインアップする必要があるとのこと。
環境の構築時には以下の事項を決定する必要がある。
- SDDCの名前
- ホスト数
- 最小4、最大32
- 管理ネットワークのCIDR
- 接続するVPC, Subnet
- リージョン
- 現在はバージニアとオレゴンのみ
ユーザーが利用するAWSアカウントとの連携
ユーザーが利用する既存のAWSアカウントでIAMロールを作成し、VMwareのアカウントを信頼する必要があるようです。
(後述するENIの作成やRoute Tableの設定などに必要なのだと推測)
管理の方法
管理は2つの手段で実施する必要はあります。
- vmc.vmware.com
- サービス全般(アカウント管理)
- ネットワーク全般(拠点やAWSとの接続、インターネットへのアクセスなど)
- vCenter
- リンクモードの管理(オンプレミスのvCenterとの連携)
- 論理ネットワークの管理
- 仮想マシンの管理
- ストレージの管理
NSX
ネットワークはNSXを使って構成されています。
図のようにカプセル化されているので、VPCのネットワークアドレスをサービス利用時に意識する必要は(たぶん)ないんだと思います。
(構築時だけ意識するのかも)
VXLANやNVGREを知ってる方なら問題なくご理解いただけるかと思います。
環境の構築にあたっては。1つのVPCと3種類のSubnetを作成するとのこと。
- 管理用
- VXLAN
- STORAGE(VSAN)
(スクリーンを撮り損ねました。。。)
このVPC上にNSXで論理ネットワークを構築するようです。
作成される論理ネットワークは、管理用とユーザー用の2種類。
管理ネットワークには、vCenterの仮想アプライアンスとNSXのマネジャーが配置されるようです。
(冗長化とかしてないのかな?と気になりました。そもそも、冗長化について考える必要があるのかも含めて。)
CGW(Customer Gateway)
ここでCGWの詳細について解説。
主な機能は以下の通り。
- North/South Firewall
- NAT
- DNS Forwarding
- DHCP
- IPsec VPN Termination
- AWSアカウントとの接続
AWSアカウントとの接続は、ESXiホストごとにENIができるようでルーティングさせるためにはRoute Tableの設定が必要なようです。
(実環境さわって手順を確認したい)
オンプレミスとの接続は、インターネットVPNとDirect Connectの2種類の方法で可能。
インターネットVPNは、CGW(NSX)およびMGW(NSX)とオンプレミスのVPNルーターとIPsecで接続するようです。
DirectConnectは、通常通りVIFを作成したうえでVMKernel経由で接続されるようです。(ここは仕組みがよくわからず。。。あとで調べる)
Best Practiceと考慮事項(ネットワーク)
まずは、アドレス設計が重要です。
当然、重複があるとルーティングできないので、注意しましょう。
AWSとの接続については、接続先のAWSアカウントのENIができる都合上、ユーザーのAWSアカウントにおけるSubnetの設計に注意しましょう。
オンプレイスとの接続については、通常のVPCとの接続同様に接続の方法(VPN or DX)や可用性についても考慮しましょう。
L2VPNも使えるようです。
サイト間の接続まとめ
各サイト間の接続方法は以下の通りです。
要件に応じて、選択しましょう。
- AWSアカウントとの接続
- VPCのENIとCGWを接続
- オンプレミスとの接続
- L2VPN
- IPsec VPN×2 (CGW, MGW)
- DirectConnect
具体的な構成例
マルチリージョン構成
同じリージョン間での接続であれば、ENIとCGE(NSX)による接続でいいのですが、他のリージョンの場合にはCGW(NSX)と接続先のVGWとVPN接続をすることになるとのこと。
ALB
ユーザーのAWSアカウントでALBを構成し、VMwareアカウント上の仮想マシンをターゲットにすることが可能なようです。
ALBが利用できるということは、WAFなどのALBと連携するサービスも使えるということになります。
Storage
S3を利用する場合、VMwareのアカウントにあるIGWから直接S3へアクセスすることが可能です。
このほか、ユーザーのAWSアカウントのVPC EndpointからS3にアクセスするような構成も可能とのことです。
DNS
ユーザーのAWSアカウントのDNS環境へフォワーディングすることも可能のようです。
ベストプラクティスと考慮事項(アーキテクチャ)
- セキュリティ
- Security Group以外にCGW(NSX)にもFirewall機能があるので、設計時に考慮
- VPC FlowLogsの有効化
- CloudTrailの有効化
- クラウドサービスとして扱うこと
- リソースの利用率などを踏まえて、ホストを増減させましょう(コロケーションではないので、柔軟性をちゃんと生かしましょう!)
- APIを利用した自動化
- マルチキャスト通信をサポート
- ホストは占有しているので、それを前提にライセンスを調達
- vSphereがサポートしているOSをサポートしている(EC2でサポートしていないOSも利用できる)
- 無駄なホストはリリースしましょう
まとめ
個人的にはVMwareのことに触れるのは3-4年ぶりで、懐かしいという思いを抱きつつ聴講しておりましたw
日本国内でVMwareを導入されている企業は非常に多いかと思いますので気になっておる方も多いと思います。
仕組みはシンプルでわかりやすく、設計や構築はそんなに難しくないように感じました。
DirectConnectにも対応していることから、比較的シビアな要件下でも検討の余地があるのではないでしょうか。
(ビジネス的に)興味があるので、今後もVMware on AWSをウォッチしたいと思います!