VMware Cloud on AWSの基礎を
おさらいするための記事を書いてます。
過去２回は以下の内容をお届けしました。
第１回 物理構成の理解
https://qiita.com/hiroito1118/items/48d8d66fab24acd16c1d
第２回 管理方法と初期デプロイの概要
https://qiita.com/hiroito1118/items/8ed96c156b8577ca4749
今回は順序的にきれいかどうかはさておき、
ユースケースについて解説します。
１．VMware Cloud on AWSのユースケース
VMware Cloud on AWSに関しての利用シーンを
確認していると、次のユースケースを
目にすることになると思います。
１）データセンターの拡張
２）クラウドへの移行
３）ディザスタリカバリ
それぞれのユースケースについて、
詳しくみていきましょう。
１）データセンターの拡張
このシナリオでは、現在オンプレミスの環境をそのままとして、
追加でVMware Cloud on AWSの環境を構築して、
接続するというケースを想定しています。
つなぎかたは色々とありますが、
追加リソース的に使うにはおそらくL2延伸を実装する
イメージになろうかと思います。
※L2延伸については色々と注意点などありますので、
後日の記事で解説します。
このケースでのメリットは、短期間であったり、
急遽リソース増強を行いたい場合に、
短時間でホスト単位でのリソース増強が可能なことです。
オンプレミスでの増強に何か月もかけていたかつ、
比較的頻度が多かったような場合には効果的と言えます。
また、双方の環境をvCenterで管理できる点は、
クラウドを使いながらも運用スキルセットを
一定範囲に抑えられる点で、現実的です。
しかし、越えるべきハードルとしては、
VMware Cloud on AWSの環境がそれほど小さくなく、
オンプレミスの環境を持ちながらも、
この規模のリソースを維持するだけの
ITリソースの要求があるかどうか、です。
※最小リソースサイズについては第１回目の記事参照
https://qiita.com/hiroito1118/items/48d8d66fab24acd16c1d
重要なこととして、VMware Cloud on AWSでは、
ネットワーク等のユーザ個別の情報をすべてSDDCの中に持つため、
ホストを落とす＝SDDCを削除する＝設定がすべて失われる
という仕掛けになっています。
そのため、使いたい時だけ上げることはできません。
最低３ノードは常時上げてもらい、
４ノード以上についてのみ、増減が可能です。
このため、データセンターの拡張シナリオでは、
オンプレミスとVMware Cloud on AWSの双方の
維持コストが発生します。
IT環境の規模に応じて、ご検討ください。
２）クラウドへの移行
このケースは、オンプレミスのVMware環境を、
VMware Cloud on AWSに完全にお引越しするというイメージです。
ネイティブなクラウド環境へのマイグレーションは、
サーバにエージェントを入れなければいけなかったり、
ソフトウェアでコンバートしたりとリスクを伴います。
VMware to VMwareであれば、コンバートする必要がなく、
リスクが抑えられかつスムーズに移行可能です、
というシナリオです。
個人的には、特に日本では
現実的なシナリオではないかと考えています。
理由としては、やはりリソース規模的に、
日本の顧客では多くがVMware Cloud on AWSの
最小規模に収まってしまう可能性があるためです。
（もちろん、それより大きいケースはあります）
Webのシステムなど変動性のあるものは現実的に
EC2なりAWSネイティブサービスの方を使うでしょうし、
SoR的なシステムだけをかき集めた時に、
最小サイズで収まってしまうのではないかなと。
そう考えると、現実的には、
このマイグレーションプランで、
SoR系→VMware Cloud on AWS
SoE系→AWSネイティブサービス
という構成にしてしまうと、
かなりわかりやすいのかなと思っています。
３）ディザスタリカバリ
最後はこのシナリオです。これが一番注意です。
初めに明確に伝えますが、
VMware Cloud on AWSはホストの停止が実質できないので、
DRサイトで使う場合もコストが定常的にかかります。
EC2インスタンスの様に落とせば課金なし、
というシナリオで検討しないでください。
大事なことなのでもう一度書きます。
DRサイトで使う場合もコストが定常的にかかります。
VMware Cloud on AWSへの期待として、
VMテクノロジだから切り替えスムーズだし、
落としておけば金がかからないと勘違いして、
DRシナリオが提案されているケースが散見されます。
そんなことはありません。
先にも掲載しましたが、落とす＝SDDC削除です。
DRシナリオを実施するためには、
データを定期的に飛ばす必要がありますが。
それを受けるvSANはホストを上げていないと稼働しません。
なので、常時3ノードのホストを上げ続ける必要があります。
ネットワークの設定情報はNSX Managerが保持していますが、
これもvSAN上で稼働します。
落とせば消えます。再構築です。
なので、このディザスタリカバリシナリオで使う場合は、
常時稼働させておく環境として、データセンターの拡張と
ほぼ同じような考え方で利用する必要があります。
現実的には常時稼働させておくコストがもったいないので、
検証環境なり緊急時には落とせるようなもので
リソースを有効活用するのが現実的です。
おまけ）１ノードでの利用に関する注意
VMware Cloud on AWSの利用オプションとして、
１ノードに関する記述があります。
確かに１ノードでの構成は可能は可能なのですが、
PoC用途に限定して利用してください。
理由は、
・そもそも30日間だけ利用可能な限定プランである
・期間中にメンテナンスによるホストが停止を伴う場合、
作成していたSDDCが削除される
ためです。
著者も作業期間中にメンテナンスに遭遇し、
見事SDDCごと削除されました。
＃VPN等のネットワーク設定もすべてやり直し
１ノード構成は、
本当に少しだけ触りたいようなケースだけ使うようにしましょう。
今回は以上です。
次回は、調達方法について触れます。