VMware Cloud on AWS ～ここがオンプレとは違うんだよ 編 その１～
何だこのタイトル？(´･ω･`)
と思われるかもしれませんが、今回はVMware Cloud on AWS(以降VMC)とオンプレミスのvSphere仮想化基盤の違いについて、何点かご紹介しようと思います。
ログインユーザーについて
VMCへのログインは、原則として「cloudadmin@vmc.local」のみで行います。
バージョン5.1以降のvSphere仮想化基盤を利用された方であれば、『administrator@vsphere.local』というユーザーになじみがあるのではないでしょうか？
VMCでは、ユーザーは「administrator」が使えません。
この「cloudadmin」というユーザーが、我々利用者が使える唯一のユーザーになります。
さて、このcloudadminですが、「じゃあ、VMCのvSphere基盤ならなんでも触れる権限持ってるんだよね？」というと、そうではありません。
実際に、ユーザーを追加するための画面です。
赤点線枠にあるように、『vmc.local』というSSOドメインに対して、ユーザーの追加ができません。
さらに、グループはというと…
表示権限すらありません。
VMCでは、SSOのドメインユーザーを作成し、権限を割り当て、運用を行うということができません。
クラスタグループの設定変更
vSphere HA
vSphere DRS
という機能が、vSphereにはあります。
これは、vSphere仮想化基盤を使用された方や設計された方であれば、とても馴染みの深い単語だと思います。
どちらも、vSphereの主力機能であり、仮想化基盤の冗長性を容易に高めてくれる素晴らしい機能です。
VMCでは、この機能が既定で「ON」になっています。
ふむふむ。
たしか、vSphere HAには「アドミッションコントロール」や「ハートビートデータストア」や、「APD」「PDL」の設定とかが色々あったなぁ…そこらへんは変更できるのかなぁ
と思ったあなた。(私のことです。)
その必要はありません！
まず、vSphere HAもvSphere DRSも、どちらの設定も変更することはできないようになっています。
これについて、VMwareは以下のように記載しています。
vSphere DRS
VMware は、発生する移行の数を最小限に抑えながら最適なリソース配布を行う設定を選択しています。これらの設定は変更する必要がないため、変更できません。事前構成済みの値は、参考値として使用できます。
vSphere HA
vSphere HA の設定を確認します。設定は、クラウド環境に最適化されています
当然と言えば当然で、vSphere HAは、「ハードウェア障害」に対応するための機能といっても過言ではありません。
ですが、ハードウェアは「AWS(VMware)」が管理をしています。
よって、その設定はVMwareにより最適なものが設定されている。
ということですね。
ユーザーのみならず、SEさんも、「クラスタ」という大きな設計要素が不要になるのは大きいですね。
管理系のコンポーネント
VMCでは、vCenter ServerやNSXといったいわゆる「管理系のコンポーネント」の仮想マシンに対して、電源操作などは一切受け付けないようになっています。
これらのマシンは、VMC上で仮想マシンとして稼働し、Mgmt-ResourcePoolの下に格納されています。
試しに、vCenterをシャットダウンしようとしても…
ご覧の通り、電源操作系が全て非アクティブ状態になっています。
ちなみに、ESXiホストもメンテナンスモードや
電源のシャットダウンなどもできないようになっています。
データストアは2種類ある
VMCは、外部共有ストレージを持たず、VMwareのSDS技術である「vSAN」を使用しています。
VMCでは、
・vsanDatastore
・WorkloadDatastore
の2種類があります
前者は、vCenterやNSXが稼働するデータストア
後者は、ユーザー作成した仮想マシンが稼働するデータストア
となっており、もう予想もついているかと思われますが、
『vsanDatastore』を触る権限が、ユーザーにありません。
このようにどんなファイルがあるのかも見ることができません。
仮想マシンを作ると、それらは全て「WorkloadDatastore」に作成されます。
また、このデータストア、ちょっと変わったつくりになっています。
下図、容量に注目してみてください。
まず、vsanDatastore
次に、WorkloadDatastore
お気づきでしょうか？
使用容量が全く一緒です。
これは、両データストアが同一領域を参照しているためです。
つまり、ユーザーがWorkloadDatastoreを使用すれば、vsanDatastoreの容量も同じだけ減っていく、とうことになります。
同じ領域を見ているデータストアが2つある、というのは何とも面白い構造ですね。
こうした制限はなぜあるのか？
理由はとっても単純で、VMCがVMwareとAWSによって「サービスとして提供されているものだから」でしょう。
提供するサービスの根幹を成すような設定を、ユーザーによって勝手に変更されたり、停止されたりしたらサービスとして成立しません。
ユーザーは、あくまでvSphere仮想化基盤を「使用する立場」であり、使用するのに必要な権限が「cloudadmin@vmc.local」というユーザーに与えられています。
従来のオンプレ基盤と異なり、戸惑うところもあるかもしれませんが、
「使用する」ということに専念させてくれるのは、ユーザーにとって一番ストレスのない形態だと思います。
今回は、オンプレミスとの違いを『使用者』および『設計者』の観点からご紹介しました。
あと1つ2つほどご紹介したいものがあるのですが、その2で書きます。
