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等のネットワーク設定もすべてやり直し
１ノード構成は、
本当に少しだけ触りたいようなケースだけ使うようにしましょう。
今回は以上です。
次回は、調達方法について触れます。