« X-Rayの内部 (Nutanix純正ベンチマークツール) | メイン | Nutanix on HPE® ProLiant® is NOW AVAILABLE »

2017/07/31

VMware Cloud on AWS ー 想定通りのキャパシティの展開

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS – Predictable Capacity Provisioningで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

VMworldのセッション LHC2971BU - Managing your Hybrid Cloud with VMware Cloud on AWS(VMware Cloud on AWSでハイブリッドクラウドを管理する)、私はこのセッションをEmad Younis氏と一緒に喋りますが、その旬日をしている際に、以下のような質問をTwitterで投げかけました:

訳: サーバーハードウェアを購入してそれをvSphereクラスタとして運用するまでの平均のリードタイムは今日現在どれ位ですか?

その結果、返信の数は圧倒的なものでした。今回のお話はそれほどでもありません。プロセス内の一つ一つのすべてのステップを自動化しようと我々が奮闘するのは面白いものです。Alan氏、Luc氏そしてWilliam氏のようにESXiホストのインストールや構成するスクリプトをつくるコミュニティを支援する人もいます。一貫性のある、人的ミスのない、迅速なプロセスです。時間のかかるサーバー展開のプロセスから貴重な時間を削り出すことができます。幾つかの会社はvRealizeスイートと連携し、ITサービスのポートフォリオ全体に一貫性のあるユーザーエクスペリエンスを作り上げています。また面白いことに、リードタイムの全体において、最も影響力のあるのが内部的な購入のプロセスです。2つの例を上げましょう :

訳 : 45~60日、最大で90日。10~30日が購入申請、30日が納期、1週間がケーブリングと検証とクラスターへの追加です。

訳 : はは! だったら、わからないよ。購入の承認は完全に予測不能。

訳 : 殆どの待ち時間は見積もり/購入/納期です。実際のセットアップは数分から、数時間。

訳 : 購入が承認されても納期に3週間です。時々クラスタへの追加と稼働まで3週間でいけることもあるけど。

そして、リストはどんどん伸びていきました。殆どの組織においては準備段階が非常に厳格で、よく定義されている手順のようでした。ですが、購入プロセスにおけるリードタイムは想定通りでも、一貫したものでもありませんでした。全てのメッセージがIT組織の俊敏性が縛られているというものでした。

IT組織はビジネスの要求に応じて迅速に反応できなくてはなりません。現状のワークロードのリソース管理ですらむす香椎のです、今後数ヶ月で挑戦しなくてはいけないことを考えてみてください。残念なことに新しいワークロードを追加するということは要求のカーブが線形になるということではありえません。(起こりうる)将来のお客さまのニーズに対応するため、その規模は2倍にもなるかもしれません、それができなければ新しいワークロードの追加はできないことになります。こうなると会社自身の基盤に影響を与えかねませんし、さらにITサービスを適切に運営する能力にも影響を与えかねません。

訳 : いつもの感じだと30~45日程度。管理プロセスに必要となる項目などで「次の」待ち時間を減らすために規模はほぼ倍になっています。

基本的に、サーバーリソースの購入についてのCAPEX(購入コスト)要素は大きくIT組織の実行力に影響もしくは妨げとなります。CAPEX/OPEX(運用コスト)についての戦略は多くの管理者やアーキテクトのフォーカスエリアからは外れています。これ自身は彼ら自身の意味での実行力を低下させるものではありません。多くののツイートがそれを証明してくれたとおり、VMware Cloud on AWSはホストのリソース調達のプロセスをCAPEXからOPEXへシフトさせ、より高速で、一貫性のある、そして想定通りの方法でコンピューティング、ストレージ、ネットワークリソースを提供してくれるのです。AWSの運用モデルを活用し、AWSインフラストラクチャで動作しているSDDCクラスタはボタンをクリックするだけでリサイズすることが可能です。クラスタを右クリックして、リサイズを選択して下さい。

Vmcresizecluster

追加したいホスト数を選択すれば、すぐさま新しい専属の物理ハードウェアがクラスタに追加されます。もう新しいワークロードに必要なリソースが追加されているのです。リサイズは同様にリソースを縮小することができるということも意味しています。もちろん、コストも下がることになります。

AWSとVMCの管理が統合されているため、新しいESXiホストは完全に新しいワークロードを迎え入れられる状態になっています。すべてのVMKernelネットワークと論理ネットワークは自動的に構成され利用できるようになります。vSANデータストアもホストが保持しているNVMeフラシュデバイスをローカルに保持しているホストで自動的に拡張されます。DRSが新しい物理リソースを検出し、自動的にクラスタのリバランスを実施するため、最も最適化されたリソースが利用できるようになります。

Erastic DRSとHAによる自動回復によって、専属のハードウェアリソースの追加と削除は完全に自動化されることになります。ですが、この話については別の記事でご紹介することにしましょう。

リソース管理の観点からは、心構えが完全に異なるものになります。VMCはインフラストラクチャ構成と管理にかける時間を減らし、リソースの消費によりフォーカスを当てられるようになります。今後数ヶ月でクラスタの構成に何が必要でしょうか? バースト時の戦略は?

残念ながら、サービスがまだリリースされていない現在、詳細をお話することはできません。VMworldではVMware Cloud on AWS関連セッションにびっくりするほどのラインアップを取り揃えています。  私自身も2つのVMworld両方でリソース管理についてのmeet the expertを実施します。この素晴らしいテクノロジーについてもっと話をしたいという方はぜひサインアップして下さい。

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381久しぶりにFrank氏がVMCの記事を更新しましたので、翻訳しました。クラスタにリソースを追加するまでに、何ヶ月かかる?そんな問いかけからスタートします。どの会社も購買プロセスが最も時間のかかるプロセスなのですね。

VMC on AWSも、いよいよ準備が整ってきて、VMworld前後には提供開始されるのでしょうか?ホストごとのリソーつ追加ですので、完全にオンプレミスのvSphereの管理の延長上で管理が行えます。

問題は・・・OPEXになるとは言え、リソースの追加の権限をどこまで持てるのか、というところですね。ITは電気屋、水道のようになれるのか・・・? まだまだIT屋がしなくてはならないことはたくさんあるように思います。