Posted at

基礎からのVMware Cloud on AWSーその3

VMware Cloud on AWSの基礎を

おさらいするための記事を書いてます。

過去2回は以下の内容をお届けしました。

第1回 物理構成の理解

https://qiita.com/hiroito1118/items/48d8d66fab24acd16c1d

第2回 管理方法と初期デプロイの概要

https://qiita.com/hiroito1118/items/8ed96c156b8577ca4749

今回は順序的にきれいかどうかはさておき、

ユースケースについて解説します。


1.VMware Cloud on AWSのユースケース

VMware Cloud on AWSに関しての利用シーンを

確認していると、次のユースケースを

目にすることになると思います。

1)データセンターの拡張

2)クラウドへの移行

3)ディザスタリカバリ

それぞれのユースケースについて、

詳しくみていきましょう。


 1)データセンターの拡張

このシナリオでは、現在オンプレミスの環境をそのままとして、

追加でVMware Cloud on AWSの環境を構築して、

接続するというケースを想定しています。

つなぎかたは色々とありますが、

追加リソース的に使うにはおそらくL2延伸を実装する

イメージになろうかと思います。

※L2延伸については色々と注意点などありますので、

 後日の記事で解説します。

このケースでのメリットは、短期間であったり、

急遽リソース増強を行いたい場合に、

短時間でホスト単位でのリソース増強が可能なことです。

オンプレミスでの増強に何か月もかけていたかつ、

比較的頻度が多かったような場合には効果的と言えます。

また、双方の環境をvCenterで管理できる点は、

クラウドを使いながらも運用スキルセットを

一定範囲に抑えられる点で、現実的です。

しかし、越えるべきハードルとしては、

VMware Cloud on AWSの環境がそれほど小さくなく、

オンプレミスの環境を持ちながらも、

この規模のリソースを維持するだけの

ITリソースの要求があるかどうか、です。

※最小リソースサイズについては第1回目の記事参照

https://qiita.com/hiroito1118/items/48d8d66fab24acd16c1d

重要なこととして、VMware Cloud on AWSでは、

ネットワーク等のユーザ個別の情報をすべてSDDCの中に持つため、

ホストを落とす=SDDCを削除する=設定がすべて失われる

という仕掛けになっています。

そのため、使いたい時だけ上げることはできません。

最低3ノードは常時上げてもらい、

4ノード以上についてのみ、増減が可能です。

このため、データセンターの拡張シナリオでは、

オンプレミスとVMware Cloud on AWSの双方の

維持コストが発生します。

IT環境の規模に応じて、ご検討ください。


 2)クラウドへの移行

このケースは、オンプレミスのVMware環境を、

VMware Cloud on AWSに完全にお引越しするというイメージです。

ネイティブなクラウド環境へのマイグレーションは、

サーバにエージェントを入れなければいけなかったり、

ソフトウェアでコンバートしたりとリスクを伴います。

VMware to VMwareであれば、コンバートする必要がなく、

リスクが抑えられかつスムーズに移行可能です、

というシナリオです。

個人的には、特に日本では

現実的なシナリオではないかと考えています。

理由としては、やはりリソース規模的に、

日本の顧客では多くがVMware Cloud on AWSの

最小規模に収まってしまう可能性があるためです。

(もちろん、それより大きいケースはあります)

Webのシステムなど変動性のあるものは現実的に

EC2なりAWSネイティブサービスの方を使うでしょうし、

SoR的なシステムだけをかき集めた時に、

最小サイズで収まってしまうのではないかなと。

そう考えると、現実的には、

このマイグレーションプランで、

 SoR系→VMware Cloud on AWS

 SoE系→AWSネイティブサービス

という構成にしてしまうと、

かなりわかりやすいのかなと思っています。


 3)ディザスタリカバリ

最後はこのシナリオです。これが一番注意です。

初めに明確に伝えますが、

VMware Cloud on AWSはホストの停止が実質できないので、

DRサイトで使う場合もコストが定常的にかかります。

EC2インスタンスの様に落とせば課金なし、

というシナリオで検討しないでください。

大事なことなのでもう一度書きます。


DRサイトで使う場合もコストが定常的にかかります。

VMware Cloud on AWSへの期待として、

VMテクノロジだから切り替えスムーズだし、


落としておけば金がかからないと勘違いして、


DRシナリオが提案されているケースが散見されます。

そんなことはありません。

先にも掲載しましたが、落とす=SDDC削除です。

DRシナリオを実施するためには、

データを定期的に飛ばす必要がありますが。

それを受けるvSANはホストを上げていないと稼働しません。

なので、常時3ノードのホストを上げ続ける必要があります。

ネットワークの設定情報はNSX Managerが保持していますが、

これもvSAN上で稼働します。

落とせば消えます。再構築です。

なので、このディザスタリカバリシナリオで使う場合は、

常時稼働させておく環境として、データセンターの拡張と

ほぼ同じような考え方で利用する必要があります。

現実的には常時稼働させておくコストがもったいないので、

検証環境なり緊急時には落とせるようなもので

リソースを有効活用するのが現実的です。


 おまけ)1ノードでの利用に関する注意

VMware Cloud on AWSの利用オプションとして、

1ノードに関する記述があります。

確かに1ノードでの構成は可能は可能なのですが、

PoC用途に限定して利用してください。

理由は、

 ・そもそも30日間だけ利用可能な限定プランである

 ・期間中にメンテナンスによるホストが停止を伴う場合、

  作成していたSDDCが削除される

ためです。

著者も作業期間中にメンテナンスに遭遇し、

見事SDDCごと削除されました。

#VPN等のネットワーク設定もすべてやり直し

1ノード構成は、

本当に少しだけ触りたいようなケースだけ使うようにしましょう。

今回は以上です。

次回は、調達方法について触れます。