LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

Nutanixだけではない!SAP HANA対応のHCIプラットフォーム(vSAN)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はSAP HANA対応のHCIプラットフォームについてお話したいと思います。

以前こちらのブログでもご紹介していますが、SAP HANA対応については記事についてはすべてNutanixに関する記事になっておりました。(詳細は以下のURLをご参照下さい)

 

 SAP環境にNutanixは最適なんです!~Nutanix Solution for SAP on Lenovo HX Series~ 

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132607954181


ついに出たミッションクリティカル向けのNutanixモデル(ThinkAgile HX for SAP HANA)~ThinkAgile HX7820/HX7821のご紹介~

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132638025276

 

Lenovo ThinkAgile HX for SAP HANA アップデート情報

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132680893218

 

今回紹介するのはVMwareのvSAN対応SAP HANAに関する記事を記載したいと思います。まず、VMwareのvSANにSAP HANAがいつ対応したのか?というお話になりますが、こちらについては2018年11月7日に発表されております。(詳細は以下のURLをご参照下さい)

https://blogs.vmware.com/virtualblocks/2018/10/18/vsan-sap-hana-production/

それでは、VMwareのvSANのSAP HANA対応についてお話します。

 

1.SAPアプリケーションとデータベースをシンプルに仮想化

f:id:t_komiya:20190318002137p:plain

SAP HANA対応についてVMwareとしては5年近く前からすでに対応はしていましたが、HCI環境についてはまだ対応しておりませんでした。vSANと緊密に連携したアーキテクチャが必要とされ、検証に長い年月が費やされてきました。また、業務の自動化およびクラウド対応など目まぐるしく変化する環境に対応するべく、SAPアプリケーションも対応が必要になってきました。今回は運用ビジネスの観点でvRealizeの必要性とSAPのランドスケープの対応にvSANのアーキテクチャが対応できたことが大きな要因となっており、これが実現されることにより、より優れたサービスレベルの維持、導入までの時間短縮、TCOの削減が実現可能となります。

2.vSAN環境でSAP HANAを実現すること

f:id:t_komiya:20190318002737p:plain

f:id:t_komiya:20190318003114p:plain

SAP HANAをvSAN環境で動作させるメリットとして、x86サーバー上でSAPのプラットフォームがすべて動作させることができることです。また、スケールアウトで拡張可能で仮想マシンごとにポリシー管理も可能です。(上記ではHDDと記載ありますが、構成上はオールフラッシュが前提の構成になります)

また、OEMベンダーごとに特有のHCI認定構成が提供可能なことも大きな特徴になります。

3.インメモリデータベースの性能をさらに強化させるデバイス

f:id:t_komiya:20190318003502p:plain

f:id:t_komiya:20190318003515p:plain

SAP HANAはインメモリデータベースになりますが、性能を向上させることについてはデバイス強化があります。vSphere 6.7では高速デバイスがサポートされており、今回はその中の一つでPersistent Memoryの対応があります。こちらは現状対応ベンダーが限られますが、このデバイスを利用することで(ワークロードにより)数百万IOPSのパフォーマンスを引き出すことも可能です。詳細はスライドをご覧ください。

4.LenovoのSAP HANA対応 for HCIプラットフォームについて

f:id:t_komiya:20190318003931p:plain

f:id:t_komiya:20190318004238p:plain

以前紹介したThinkAgileHX7820/HX7821についてはNutanixのプラットフォームでしたが、今回はThinkAgileVXのプラットフォームでのリリースとなります。Nutanixの時は4Uサーバーかつアプライアンス・認定ノードの両方のプラットフォームに対応しておりましたが、今回のvSAN対応については、ThinkAgile VX認定ノードのみの対応となり、CPUも2ソケットまでの対応になります。(2019年3月17日現在)

.LenovoのvSANプラットフォームで利用するメリットについて

f:id:t_komiya:20190318004405p:plain

f:id:t_komiya:20190318004451p:plain

メリットについては、vSANプラットフォームを選択する内容がほとんどになってしまいますが、SAPについてはLenovoはワールドワイドでの実績は豊富にあります。また、vSANと含めてサポートも切り分けて対応致します。

.SAP HANA for HCI(vSAN)を支えるテクノロジーとアーキテクチャ

f:id:t_komiya:20190318004821p:plain

f:id:t_komiya:20190318004839p:plain

こちらにテクノロジーとアーキテクチャを記載致します。

NutanixのSAP HANA対応については、AHV TurboなどのNutanix側のプラットフォームではI/O高速化技術が必要でしたが、VMwareについてはvSphere 6.5からNVMeの対応しておりましたし、今回のvSphere6.7についてはPersistent Memoryの高速アクセス可能なデバイスが対応済みとなっております。また、RDMAについても対応できており、vNUMAについても対応済みです。

アーキテクチャについては簡単ではありますが、スライドに記載しております。

 

引き続き情報がございましたら、アップデートさせて頂きます。

以上、よろしくお願い致します。

SMB向けモデルThinkAgile HX2320/HX2321と小規模向けのバックアップ付き構成について


皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はSMB(中小企業)向けにリリースされたThinkAgile HX2320/HX2321および小規模構成についての説明をしたいと思います。

今回製品説明だけではブログとしては内容は少ないため、小規模向けのバックアップ付きの構成について追加で説明したいと思います。

まず、ThinkAgile HX2320/HX2321に関してですがUS時間の2/20にリリースされています。(製品ガイドはもう少し前からあります)

https://lenovopress.com/lp1027-lenovo-thinkagile-hx2320-appliance 

日本では後日正式に製品発表予定となっております。

1.ThinkAgile HX2320 / HX2321に関してf:id:t_komiya:20190225142007p:plain

以前からレノボのNutanixのラインナップをご存じの方は”あれ?”と思うかもしれません。レノボでSMBモデルとしては今まではThinkAgile HX2320-E / HX2720-EのXpressのライセンスが搭載していた2機種が存在しておりました。今回Xpressライセンスがなくなり、新モデルとしてHX2320/HX2321のモデルがリリースされています。

2U4Nのフォームファクターがなくなり1Uモデルのみとなりましたが、今まで認定ノードにラインナップされていなかったモデルにようやく認定ノードモデルが追加されました。

それでは、今回リリースされたThinkAgileHX2320/HX2321についてもう少し内容を見ていきたいと思います。

f:id:t_komiya:20190225143010p:plain

ThinkAgileHX2320/HX2321についてはCPUも低スペックのCPU(Xeon Goldクラスまで)が選択可能になっています。また、HDDドライブについては3.5インチクラスのディスクが選択可能になっているため、パフォーマンスが低く容量が大きめのワークロードにちょうど良いため、バックオフィス系の用途に向いてます。

f:id:t_komiya:20190225143649p:plain

1か月ほど前にアプライアンスと認定ノードの紹介のスライドにおいて、認定ノードでSMBモデルが「該当モデル」という記載になっておりましたが、ようやく製品が発表されて全ラインナップが埋まりました。

是非こちらのモデルもご検討下さい。

 

2.小規模バックアップ構成に関して

小規模構成でデータのバックアップを行う構成を組む場合どのように組むのか悩むところだと思います。バックアップサーバを別で購入してバックアップサーバとして使用するのは良いがNutanix以外のクラスタを組まなければならないし、Nutanixのクラスタの中で管理しようとするともう一つ別のクラスタを用意する必要があります。

今まであまりお話をしておりませんでしたが、ThinkAgile HX1520-R/ThinkAgile HX1521-Rというレプリケーションターゲット用というモデルがございます。こちらを利用したバックアップ構成についてお話したいと思います。

f:id:t_komiya:20190225145631p:plain

 こちらのイメージを見て頂きたいのですが、SMBモデルのHX2320x3ノードでクラスタを構成します。そのバックアップ先としてHX1520-Rをシングルノードで構築します。この構成でバックアップをどのように取得するかということになりますが、NutanixのAsync DR(非同期DR)でそのまま設定してバックアップを取得することもできます。これであれば、Nutanixのライセンスの範囲内でバックアップが取得できますし、もちろんファイルレベルでもリストアは可能です。

ただし、この方法の場合はアプリケーションを特に意識したバックアップにはなっていないため、その点を考慮するとVeeamなどのサードパーティ製のバックアップソフトウェアなどを利用するのも良いと思います。Veeamを利用することで、バックアップソフトウェアの購入で費用はかかってしまうものの、例えばActive Directoryなどでユーザ単位でリストアしたり、データベースをテーブル単位でリストアすることも可能です。

 

3.2ノード構成に関して

f:id:t_komiya:20190225194857p:plain

以前の記事で2ノード構成のお話をしたかと思いますが、その2ノード構成についてはWitnessサーバーの存在が欠かせないことをお伝えしました。(詳細は以下のURLにて)

http://blog.lenovojp.com/entry/2018/05/06/020320

このWitnessサーバーを構築するノードを別に設ける必要があったのですが、これをバックアップターゲットで実現するのはどうでしょうか?実際にバックアップターゲットのノードにおいてたくさんの仮想マシンを動作させることは基本は想定されておりません。しかしながら、ThinkAgile HX1520-Rについては12コアまでCPUを選択可能になっていることから、CVM以外の仮想マシンをインストールすることは可能です。そのため、Witnessサーバーをインストールして、2ノードのクラスタを監視するように設定して、小規模構成も実現できます。

Nutanixで管理されていないノードを用意することなく、Nutanixの管理下ですべてが完結する構成も良いかと思います。

 

一度ご検討してみてはいかがでしょうか。

 

よろしくお願い致します。

 

 

マルチクラウドにおけるアプリケーションの監視ソリューション~Xi Epochのご紹介~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はマルチクラウドにおけるアプリケーション監視ソリューションのXi Epochについてご紹介したいと思います。

こちらのソリューションですが、名称にXiとついていることからXi Cloudで提供されるSaaSソリューションになります。実際にどのようなソリューションなのか以下に説明致します。

1.Xi Epochは何をするもの?

f:id:t_komiya:20190216234645p:plain

Nutanixのソリューションでクラウド連携するソリューションは以前にもCalmやBeamをご紹介してきましたが、CalmやBeamやアプリケーション導入の自動化やマルチクラウドのコストの最適化・ガバナンスの統制を行うものとして利用するものでした。今回のEpochやクラウド上のアプリケーションにおける監視になりますが、すべてのアプリケーションが対象にしているわけではありません。

Nutanix社に買収される前はNetsil社としてサービスをしておりましたが、その当時からクラウドネイティブのアプリケーションをベースに監視ソリューションを提供しています。そもそも、どのような背景でこのソリューションが利用されているのかをスライド交えて説明したいと思います。

2.クラウドネイティブアプリケーションの出現

f:id:t_komiya:20190216235726p:plain

クラウドネイティブアプリケーションと言われる前は、アプリケーションはモノリシック(一枚岩)で、全体が一つのモジュールでできていました。クラウドネイティブの環境においてはアプリケーションが複数の言語に実行されていることから標準化もできないこと、コードレベルでサービス追加を行うことが非常に複雑でインスタンス毎にサービスの提供期間も異なり、それぞれの問題を切り分けるにも非常に困難な状況を生んでしまいます。それで、分散アーキテクチャの環境で実行されるアプリケーションを定期的に観察し、パフォーマンスを監視するソリューションが必要になります。似たような製品としてはDataDog、Sysdig、New Relic、AppDynamics(Cisco社が買収)やDynaTraceなどがあります。

3.Xi Epochができること?

f:id:t_komiya:20190217001929p:plain

Xi Epochはマルチクラウド上でアプリケーションを観察。監視を行うことができます。アプリケーションの監視については基本はエージェントレス(Credential情報を利用)で行います。監視内容はアプリケーションの健全性・レイテンシ・スループット・エラー率などを細かくシグナル表示します。

  • タグとトラフィック属性でホストとコンテナをフィルタリングしてグループ化することで、マップを作成および共有
  • サービスとその依存関係の検索と発見
  • すべての内部サービスと外部サービスの間のリアルタイムのトラフィックフローを監視
  • 展開前後の過去の行動を比較するためのタイムトラベル
  • Kubernetes(ポッドと名前空間)などのようなポピュラーなプラットフォーム用の箱から出してすぐに使えるマップ

f:id:t_komiya:20190217003522p:plain

Epochは使用言語やクラウド環境などの依存性を関係なくアプリケーションを可視化します。また、アプリケーションを定期的に観察することで、ボトルネックになっている情報を把握して原因究明を早めることができます。

  • 待ち時間、スループットなどの主要パフォーマンス指標は、API呼び出し、DBクエリー、DNSクエリーなどのためにサービスおよびそれらのリンクで利用可能
  • サービスとインフラストラクチャの完全なヘルスメトリックへのワンクリックドリルダウン
  • スロービュー、ハイデマンドAPIコールなどをソートおよび識別するためのテーブルビュー

4. Xi Epochのアーキテクチャ

f:id:t_komiya:20190217003643p:plain

Epochのアーキテクチャについてですが、実際にはアプリケーションが動作しているサーバーリソース監視、パフォーマンス監視、ネットワーク監視を同時に行っています。以前DPI(Deep Packet Inspection)は行っていないのではないかというコメントしたことがありますが、こちらを見る限りアプリケーション間の通信のパケットを解析することでボトルネックを究明できるアーキテクチャになっているようです。また、テレメトリなどの原因究明だけでなく将来予測などの機能も備えているようです。

DPIとテレメトリについては、過去の記事で紹介しておりますので、参考程度にご紹介します。

・DPIについて

blog.lenovojp.com

・テレメトリについ

blog.lenovojp.com

 5.Xi Epochのアプリケーションモニタリング

f:id:t_komiya:20190217004808p:plain

Xi Epochのアプリケーションモニタリングはアプリケーションを観察することで、障害の発生率の改善、迅速な根本原因分析を行います。一部のアプリケーションについては、メトリクスですべてのコンポーネントを監視できるようになっており、そのためナレッジも含めて包括的な監視ソリューションを提供できています。現在はJMX、NGINX、MySQLなどとの70以上のアプリケーション統合が実現できています。

そのほかにも、以下のようなことが可能です。

  • サービスインタラクションのパフォーマンスを監視するためのパケットキャプチャと分析
  • 暗号化されたトラフィックを観察するためにSSLSplitを利用する
  • ヒープサイズ、スレッド数、接続などのメトリクスについては、JMX、NGINX、MySQLなどとの70以上のアプリケーション統合
  • コードレベルの洞察のための、statsdを使用したカスタムメトリック
  • AWS RDSの待ち時間、DynamoDBクエリ、Route53検索でのDNSエラーなどの外部サービスとのやり取りパフォーマンス分析

6.Xi Epochのインフラモニタリング

f:id:t_komiya:20190217005736p:plain

Xi Epochはアプリケーションだけでなくインフラの監視を行います。仮想マシン・コンテナなども対象にしており、監視対象はCPU、メモリ、ディスクI/Oなども含まれます。

DBのモニタリングも行うことができます。よくある話として、SQL分などで必要以上のデータを引き出してしまって、分析の際のデータ量を多くして処理しているケースなどがある場合、適切なSQL分などに修正するなどのアドバイスなども必要になります。

迅速な回答を得るための強力なクエリ中心のインタフェースと低遅延クエリエンジンが備わっています。

  • メトリックスを調査および視覚化し、アラートまたはダッシュボードとして結果を保存するためのAnalytics Sandbox
  • ポッド名、ホスト名、またはHTTP URI、MySQLクエリタイプなどのプロトコル属性など、複数のディメンションからのデータを分析するための広範なフィルタとグループ化オプション
  • HTTP、MySQL、DNSなどの一般的なシステムすべて、およびKubernetesなどのフレームワーク用のすぐに使えるダッシュボード
  • 多次元からのデータをセグメント化して分析するためのチャートからの動的ドリルイン

7.Xi Epochの効果について

f:id:t_komiya:20190217010557p:plain

ノード・エッジ・KPIについてそれぞれ監視を行うことができるようになっており、マップ表示されることで、障害の原因究明を迅速化することができます。また、それぞれの項目についてナレッジを利用することで監視設定を簡素化していることもEpochを導入することも効果にもなります。

8.実際の表示画面について

f:id:t_komiya:20190217011421p:plain

事象発生前の画面と発生後の画面を合わせて載せていますが、マップ表示で赤くなっているところ、その周辺のエンティティに実際の遅延の数値が表示されます。実際にこれをクリックすることで原因も究明できるような仕組みなっています。

以上、よろしくお願い致します

 

 

AHVとESXiは機能比較するものではない!?

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は以前にもご紹介したAHVとESXiの比較に関するお話をしたいと思います。

一年前に同様の記事を書いていますが、以下の記事が閲覧数の上位に来るほどのトピックであるものの、この2つのハイパーバイザーに関しては全く異なる背景から開発されてきたものであることから、機能が多い・少ないということではなく何をしたいのか?ということからこの2つのハイパーバイザーを選択するべきであると考えております。昨年一年間で様々な機能を紹介したものの断片的に紹介したこともありますので、本日は再度内容のご紹介をしながら、昨年記載した比較表の更新も含めて記事を掲載いたします。

blog.lenovojp.com

1.そもそもAHVってどういうもの?

f:id:t_komiya:20190209232638p:plain

AHVはもともとKVMベースのハイパーバイザーです。KVMそのものはハイパーバイザーとしてはほとんど機能がありません。もちろん企業用途で使うためにはいろいろな機能を各ベンダーが開発していく必要があります。NutanixはそのKVMにエンタープライズ向けの機能を必要最低限開発し、Prismで管理させることにより使いやすい仮想化環境を開発したというところにあります。1クリックでの管理、HA・DRSなど企業ユースで必要な機能のサポート、エコシステム対応などを行うことによりお客様が満足するようなシステムにしています。

f:id:t_komiya:20190209233144p:plain

またAHVはEnterprise Cloud向けの仮想化環境を提供していますが、普通の仮想化環境だけでなく、管理、監視、分析機能なども一つのスタックで提供しています。これを実現することで時間やコストの削減にもつながり、インフラの複雑も軽減しています。

まさにこの部分がAHVというよりNutanixの神髄と言えるところになります。

2.ESXiとの比較について

f:id:t_komiya:20190209233719p:plain

こちらがESXiとAHVを機能毎に比較したものになりますが、AHVの方がそれぞれの層でうまく分かれていてシンプルのように見えます。もちろんこれは図の中ではメリットがあると思いますが、ESXiにおいてvCenterを操作するオペレータがこれを意識することはありますでしょうか?操作性は関係なく必要なライセンスを購入するということであれば、どちらもあまり変わりはないと思います。(NutanixもFiles / Calm / Flowは有償です)

f:id:t_komiya:20190209234217p:plain

こちらはコンポーネント毎の比較をしています。それぞれが分割されているESXiに対してAHVは一つのスタックでPrismとネットワーク、ハイパーバイザーがまとまっています。AHVで利用時は一つの画面でできることは当然の話ですが、ESXiやHyper-Vを利用する際は、vCenterなどの別の管理画面が必要になります。開発されているハイパーバイザーが異なれば当然そのような話になりますので、Nutanixを利用する際はAHVを利用したほうが管理性が上がることはここにあります。(ほかにインストールに関してもAHVであればFoundationから設定が自動化されるところが多く早く導入が終了することがあります)

逆にNutanixについてはAHVを利用することの一元管理だけでなく、マルチハイパーバイザー管理というメリットを持ってAHV中心で仮想化環境を構築し、一部ESXiでないと構築できないものがあればESXiで構築するという選択があると考えると良いと思います。

.仮想ネットワークに関して

blog.lenovojp.com

ネットワークに関してはこちらの記事の内容となります。ESXiの時にはStandard Switchを利用して構築する場合は、各ホスト上のスイッチ設定を揃えなければなりません。その煩雑さを軽減するためにvDS(分散スイッチ)が必要となるわけですが、こちらはコスト的な問題で大規模構成時に非常に役立ちます。逆にそこがVMwareの時の差別化になるところですが、AHVの場合はvDSに相当する機能がAHV導入時に利用可能(その設定のみ)になっています。そのため、ネットワーク構成が必要にシンプルになり、VLAN割り当ても含めて操作することができます。

4.HA(High Availability)に関して

f:id:t_komiya:20190210000740p:plain

HAについてですが、ESXiでのHA設定についてお話します。HAの機能としては、VMwareのドキュメントではこれだけの内容が設定できます。もちろんこれは企業ユースであれば要件的には問題ないものではありますが、果たしてこれらの機能を全部使うのか?ということです。基本的にはHAと言っても使う機能は1つもしくは2つまでのユーザーが多いと思います。 

f:id:t_komiya:20190210001124p:plain

AHVのHA設定はたったの2つだけです。Prismの画面で「Manage VM High Availability」の設定からチェックあり・なしで設定が終わりです。

チェックなしでベストエフォート、チェックありでリザベーション(予約)という非常に単純なものになっています。詳細は過去のブログで紹介しておりますので、ご参照ください。

blog.lenovojp.com

.DRSに関して

f:id:t_komiya:20190210001629p:plain

(VMwareの)DRSについても同様で、こちらのイメージのような機能を設定可能です。DRSについてはESXiの場合リソースの設定を細かく設定できますが、重要度の高いアプリケーションはそのような使い方はできますが、ある決まったルールの下で動作させることで、逆に運用の統制化を図ることも可能になります。それをAHVのDRS(ADS)で実現しています。

blog.lenovojp.com

詳細はこちらのブログの記事に記載していますが、システムの稼働状況に合わせて仮想マシンの最適な配置と決まった閾値での他のホストへのリソースの移行を行います。このような形で運用を簡素化することもCloud環境では必要になります。

.vSphereとAHVの機能比較に関して

f:id:t_komiya:20190210002906p:plain

f:id:t_komiya:20190210002921p:plain

f:id:t_komiya:20190210002932p:plain

f:id:t_komiya:20190210002945p:plain

 こちらは昨年掲載した内容のアップデート情報になります。

vGPUの記載については機能として利用可能であることを明記しましたが、HAやvMotionなどの機能は制約があったりする内容を追記しました。また、vSANとの比較においてIOPSの制限については機能がある明記をしましたが、今後の機能拡張になりますので、記載の修正をさせて頂きます。

 

よろしくお願い致します。

 

HCI製品のアプライアンスと認定ノードの違いって?【VMware編】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は先週に引き続きHCI(ハイパーコンバージドインフラ)における製品の違いについてお話したいと思います。 先週のNutanixについては、アプライアンスと認定ノードの2種類だけでしたが、今回のvSANについては以前の記事でも紹介しましたが、3種類あります。(今回の記事では4種類になっています)

違いについては過去のブログ(以下の記事を参照)で紹介しておりますが、実際どのように売っていけばよいのか?どのような提案していけばよいのかがわからないことがありますので、本記事で少し触れていきたいと思います。

blog.lenovojp.com

 

1.レノボのvSANの製品ラインナップに関して

f:id:t_komiya:20190203220732p:plain

以前の記事ではBring Your Own vSANは紹介しておりませんでしたが、今回は掲載しています。ThinkAgile VXおよびThinkAgile VX認定ノードについてはLenovoの認定ハードウェアおよびファームウェアで動作します。vSAN Ready Nodesについては、VMware社が検証したハードウェアスペックになっており、その構成におけるファームウェアおよび構成でパフォーマンスを保証するタイプのものです。Bring Your Own vSANについては、vSAN の構成としては動作はするものの、vSAN Ready Nodesとはハードウェアスペックを変更して構成したサーバーになっていることから、パフォーマンスを保証するものではありません。実際にvSANを構成するはvSAN Ready Nodesで購入するケースは少なく、ほぼ9割以上はBring Your Own vSANの構成になります。

 f:id:t_komiya:20190203221644p:plain

詳細な違いについてはこちらのイメージになります。構成に関しては、vSAN Ready Nodesは今日現在で107通りの構成になります。(107通りの中にThinkAgile VXの構成も含まれます)

vSAN Ready NodesからカスタマイズされているのがBring Your Own vSANになります。数に関しては、ほぼThinkAgile VXの構成とほぼ同じもしくはそれ以上の数になります。また、ライセンスについては、アプライアンス版はOEMライセンスが必須になるものの、それ以外のラインナップについては、OEM版・リテール版 のライセンスが利用可能になります。

それ以外にはシステム導入するベンダーや管理ソフトウェアなどの違いもありますが、イメージをご参照下さい。サポートについてはこの後のスライド説明致します。

f:id:t_komiya:20190203222249p:plain

こちらのイメージはvSAN のラインナップのそれぞれの違いを分かりやすくまとめたものです。こちらで記載のあるVX Installerについては、ライフサイクル管理をするソフトウェアになります。こちらを利用してソフトウェア・ファームウェアのローリングアップグレードをサポートするものになっておりますので、他社のvSANアプライアンスと同等の機能が利用可能になります。

2.ThinkAgile VXのアプライアンスと認定ノードの違いについて

f:id:t_komiya:20190203223251p:plain

こちらがThinkAgile VX/認定ノードのラインナップですが、以前にも紹介しておりますが、ThinkAgile HXと違い認定ノードはForm Factorベースで分かれています。Nutanixの時はシリーズ毎にラインナップを分けられましたが、vSANについては構成次第でSMBモデルにもメインストリームのモデルにもなりえるため、認定ノードはモデル化しておりません。その分自由度も高くなっていることの証だと思われます

3.ThinkAgile VXとvSANの選択方式について

f:id:t_komiya:20190203223659p:plain

ThinkAgile製品およびvSAN製品のそれぞれ選択方式について説明します。ソフトウェアについては先ほどOEMライセンスとリテールライセンスの利用についてお話しましたが、そのライセンスの納品のされ方に違いがあります。それについては導入サービスの違いによって異なりますので、イメージをご参照下さい。サポートについてもLenovoのThinkAgile製品についてはサポートが一元化されてものがついているものの、vSAN Ready Nodesについては、それがありません。この理由については、vSAN Ready NodesはLenovoのThinkSystemシリーズを購入して関係上、ThinkAgile製品にはないサポートになってしまうからです。サポートを手厚いものでご提案する場合は是非ThinkAgile製品でのご提案をお願い致します。

(ThinkAgileのサポートについては先週の記事をご参照下さい。Nutanix部分がVMwareに変わるだけです)

blog.lenovojp.com

.アプライアンスモデルと認定ノードのイメージについて f:id:t_komiya:20190203224932p:plain

 アプライアンスおよび認定ノードについては、先週のNutanix編と内容は同じになります。vSANモデルについては途中でもお話しましたが、サポートが異なります。また導入についてもLenovoは介在せずパートナー様の導入になります。パートナー向けモデルですが、認定ノードのように一次切り分けのサポートがないのがvSANモデルの内容になります。

.パートナー様の提案方法について

f:id:t_komiya:20190203225303p:plain

提案方法についてはNutanix編に比べてパターンが増えます。まずはVMware導入可能なパートナー様に関してです。ThinkAgile VX認定ノードを提案する際での作業面について先週と内容は同じです。ただし、vSAN Ready Nodesでしかサポートされない構成があります。それは2ノードvSAN構成です。こちらについては以前の記事にも記載しましたが、ThinkAgile VXはROBO環境(リモートオフィス環境)のみ2ノードでの構成が可能です。つまり既存で3ノード以上のvSANを導入した上で2ノードの構成を追加で構成する場合にのみ対応可能であることから、単独で2ノードvSANを構成する場合はvSAN Ready Nodesで構成する必要があります。

その他は、お客様がVMwareのスキルがあり切り分けがお客様で可能なケースであればvSAN Ready Nodes構成の提案もアリだと思います。

blog.lenovojp.com

VMware導入不可のパートナー様のケースを以下に記載します。

f:id:t_komiya:20190203225932p:plain

こちらのケースのパートナー様についてはアプライアンスモデルの提案がベストですが、VMware以外のソフトウェアと併せて購入するケースや他のパートナー様が導入するケースがある場合は認定ノードが良いと思います。

ただし、こちらについても2ノードvSAN構成が含まれている場合についてはvSAN Ready Nodesを提案された方が良いケースもありますので、十分に注意したほうがよいと思います。その場合はサポートがハードウェアとソフトウェアが分かれてしまうことをご説明お願い致します。

 

以上、よろしくお願い致します。

HCI製品のアプライアンスと認定ノードの違いって?【Nutanix編】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はHCI(ハイパーコンバージドインフラ)における製品の違いについてお話したいと思います。

HCIにおいては、LenovoやDELLで出ておりますが、この2社についてはNutanixおよびVMware(vSAN)の2つのソリューションでLenovoはアプライアンスと認定ノード(DELLはXC Core)がリリースされていますが、違いについては過去のブログ(以下の記事を参照)で紹介しておりますが、実際どのように売っていけばよいのか?どのような提案していけばよいのかがわからないことがあります。筆者も最近Nutanixに関してはこのような質問も受けており、今回の内容をブログで記載することに致しました。

今回はNutanix編としてお届けしたいと思います。

blog.lenovojp.com

 

1.レノボのNutanixの製品ラインナップに関してf:id:t_komiya:20190126232838p:plain

こちらが現時点(2019年1月26日現在)のラインナップになります。これを見ると認定ノードに関してSMBモデルが存在しておりません。昨年の夏のラインナップからはHX7800シリーズは追加になっているもののSMBモデルが提案できないのは厳しいと思われます。しかしながら、近日中に新しいSMBモデルのリリースが予定されておりますので、 情報公開可能な時期になりましたらお知らせいたします。

それ以外は特にアップデートはございません。 

2.ThinkAgile HXのアプライアンスと認定ノードの違いについて

f:id:t_komiya:20190126233920p:plain

昨年7月に記載した情報からアップデートしております。文字のみの記載から少し図でわかりやすくしてみました。認定ノードについては、以前はノード単位のライセンスのみ提供されておりましたが、今後は容量ベースでのライセンス体系になります。使用するリソースに応じてライセンスが変わります。

導入されるハイパーバイザーに関しては、レノボの導入必須のアプライアンスはお客様指定のハイパーバイザーで納品されますが、認定ノードはレノボの工場でAHVをプリロード(パラメータ設定なし)して出荷します。サポートに関しては次のスライドで紹介します。導入サービスについては、アプライアンスはレノボ導入サービスが必須でありますが、認定ノードはパートナー様での導入を前提としております。レノボの導入もオプションで選択可能です。

3.レノボのサポート窓口(ThinkAgile Advantage)についてf:id:t_komiya:20190126234917p:plain

こちらがNutanixで提供しているサポートサービス(ThinkAgile アドバンテージ・サービス)になります。こちらのサポートはHCI製品に関してハードウェア、ソフトウェアの切り分けを行う窓口になります。通常はアプライアンス製品のみ統一の窓口を提供するように思えますが、こちらのサポートは認定ノードでも利用することが可能になります。実際に認定ノードの場合について、ThinkAgile アドバンテージ・サービスを利用する場合どうなるのかをお話したいと思います。

4.認定ノードにおけるThinkAgile アドバンテージ・サービス

f:id:t_komiya:20190127171525p:plain

認定ノードの場合、通常のアプライアンス製品と違いサポートがハードウェアとソフトウェア分かれてしまいますが、その煩わしさを軽減するのがThinkAgile アドバンテージ・サービスになります。お客様の運用スキルが高ければ問題ありませんが、すべてのお客様が切り分けられるわけではありません。ThinkAgile アドバンテージ・サービスはお客様に代わりハードウェア・ソフトウェアの問題を切り分けを行います。ハードウェアかソフトウェアかわかれば、それぞれのベンダー(レノボ、Nutanix)のサポートが対応できます。

 

ここまでは、ThinkAgile HXの製品とサポートとお話でした。ここからはもう少しわかりやすく2つのモデルを紹介と、どのように提案していけばよいのかを一例をあげてご説明致します。

5.アプライアンスモデルと認定ノードのイメージについてf:id:t_komiya:20190127000421p:plain

両モデルについて説明したものの、どのようなイメージなのかをつかみ切れていない方もいらっしゃると思いますので、まとめてみました。

アプライアンスモデルは一言で言うと、レノボにすべてお任せのモデルになります。お客様・パートナー様はHCIのアプライアンス製品を購入したら、導入まですべてレノボが請け負います。またサポートや保守も全部レノボが受けるので、お客様は運用して困ったらレノボに相談すればよいものです。レノボ製品・サービスが気に入っているお客様には最適なモデルになります。

しかしながら、パートナー様でNutanixライセンス・導入サービスを提供している場合やパートナー様がお客様のシステム運用まで請け負っている場合で導入サービスも提供したい場合は、パートナー様に価値を提供できる認定ノードが非常に効果的なこともあります。その導入ケースの場合、導入にどのような状況になるのかを上図でわかりやすくイラストにしてみました。どちらのケースが良いのかはパートナー様で大きく異なると思います。

 

.パートナー様の提案方法について

f:id:t_komiya:20190127002009p:plain

パートナー様にて導入作業まで行う会社とそうでない会社の場合に分かれると思われます。どちらのケースにおいても認定ノードを提案することはできますが、場合分けでできることもあります。特に導入可能なパートナー様の場合、導入作業を前提に提案を進めていたものの、年度末で導入する作業員が手配できない場合もございます。そのケースの場合、何とかならないと思った時にレノボに導入依頼することも可能なため、認定ノードをうまく提案することも良いと思われます。

 

以上、よろしくお願い致します。

 

Nutanixが提供するDRaaSサービス(Xi Leap)の紹介

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixが先日Londonの.NEXTで発表したDRaaSのXi Leapについてご紹介したいと思います。こちらのサービスですがNutanixのクラウドサービスであるXi Cloudのサービスの一つになります。ここでXi Cloudという言葉を初めてお聞きになった方にXi Cloudのサービスをお話したいと思います。

 

Xi Cloudサービスについて

Xi Cloudサービスは以下の5つのサービスが提供されています。

f:id:t_komiya:20190119235056p:plain

  • Xi IoT (マルチクラウドのIoT基盤)
  • Xi Leap (マルチクラウドでのDRaaS)
  • Xi Epoch (マルチクラウドのアプリケーション監視)
  • Xi Beam (マルチクラウドのコスト可視化、ガバナンス)
  • Xi Frame (マルチクラウドでのDaaSのコントローラ)

Xi Leap以外のサービスについては今後ご紹介したいと思います。

ここで気になるのはDRaaSで提供されているということはどこに地域(Region)で提供されているのか?ということです。現状は4つの地域で提供されていますが、残念ながら日本での提供はまだです。提供地域は以下の通りです。(2018年末の情報)

  • US West Region
  • US East Region
  • UK London
  • EU Italy

実際にXi Leapについての内容について説明したいと思います。

1. 現状のハイブリッドクラウド環境について

f:id:t_komiya:20190119234822p:plain

各企業でハイブリッドクラウドを検討されていると思いますが、非常に複雑なものです。組織はクリティカルで予測可能なワークロード用のインフラストラクチャを所有することを検討していますが、必要に応じてパブリッククラウドサービスを利用することも検討しています。オンプレミスの環境はVMwareのESXiの環境であったり、NutanixのAHVでもあり、クラウドについてはAWS、Azure、GCPなど様々なものが存在します。これらのオンプレミスの環境とパブリッククラウドの環境を完全な形で統合することは難しいと思います。特にパブリッククラウドサービスには個別の構成要素があり、個別の管理ツールが必要なので、最終的には別のITサイロになってしまいます。つまり、明確な運用要件、複雑な管理、および全体的なコストの増加になる可能性があります。

f:id:t_komiya:20190119235926p:plain

そこでNutanixは自社のプラットフォームで構築され、このプラットフォームがセキュアな環境で接続されているパブリッククラウドがあれば、簡単にDRサイトの構築もできるし、1クリックですべてのことが完結するものが構築できると考えるわけです。今回はDRaaSであるXi Leapについて詳細説明したいと思います。

2. ディザスタリカバリ(DR)向け Xiクラウドサービス: Leap™ について

f:id:t_komiya:20190120000738p:plain

お客様の環境ではアプリケーションとサービスを常に利用できるようにすることを強く求められています。 これらの期待に応えるためには、単にデータを保護するだけでなく、完全に自動化されたフェイルオーバーと定期的にリカバリプランをテストする機能も提供するResilience(回復力)が必要となります。

ただし、多くの組織ではDRを目的としたセカンダリデータセンターの運用に関連するコストと複雑さに困惑しています。 クラウドへのDRソリューションは魅力的なコストを提供しますが、データセンターとパブリッククラウド間でワークロードを移行する際の複雑さによって採用が妨げられることがよくあります。

Xi Leap Serviceは、独立したインフラストラクチャスタックを購入して維持することなく、Nutanix環境の中でアプリケーションとデータを迅速かつインテリジェントに保護する、完全に統合されたクラウドへのDRソリューションを提供します。 オンプレミスと復旧サイトで同じプラットフォームを利用することで、Xi Leapは環境間での構成要素、ポリシー、およびデータモデルの複雑な変換の必要性を完全に排除します。

3. Xi Leapの特徴について

f:id:t_komiya:20190120001634p:plain

ビルトインされたディザスタリカバリ

Xi LeapはNutanixプラットフォームにネイティブに組み込まれています。

DRプラン、設定、および監視はPrismで管理されるため、非常にシンプルです。

即座にクラウド環境で利用可能

Nutanix Enterprise Cloud Platformのネイティブ拡張として、Xi Leapが仮想マシン、ネットワーキング、セキュリティ設定などのワークロードプロファイルをリカバリサイトに移植し、セットアップ時間を短縮し、フェイルオーバープロセスを簡素化しているため、簡単に利用できます。

ワンクリックのフェイルオーバーとフェイルバック

Xi Leapは重要なワークロードのビジネス継続性のためにDRを簡素化します。

Xi Leapはフェイルオーバーおよびフェイルバックプロセスをワンクリックで確実に実行するためのDRのオーケストレーションを提供します。

さらに、Xi Leapを使用するとサーバーのメンテナンスやラックの故障時にアプリケーションの部分的なフェイルオーバーが可能になります。

ネットワーク接続性と環境間の共通管理が維持されているため、ソースサイトとターゲットサイトを単一の環境として管理でき、完全な可視性、制御、およびより優れたDR準備を実現できます。

非破壊検査とクリーンアップ

Xi Leapは中断を伴わないテストを提供しているため、DRの環境を定期的に調べてコンプライアンス満たすことができます。

ネットワーク隔離されたテスト環境は、プライマリ環境に影響を与えずにリカバリプロセス全体をテストするために、ユーザの指示により動的に起動されます。

テスト環境はテスト完了時に自動的にクリーンアップされるため、マニュアル作業は不要です。

エンドツーエンドのセキュリティ

Xi Leapは外部からの攻撃からお客様のワークロードを完全に分離して保護する包括的なセキュリティを備えています。

 

ちなみに、現状クラウドへのDRについては、Cloud Connectを利用したソリューションがNutanixとして提供しておりますが、クラウド側にCVMアプライアンスのデプロイが必要となります。Xi Leapを利用することによりDRの簡素化するのは間違いありません。

是非日本リージョンでローンチした時には利用してみてはいかがでしょうか。

 

以上、よろしくお願い致します。 

AWSにも対応したXtract VMs~Xtract for vmsの紹介~【第二弾】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は以前にもご紹介したXtract for VMsのアップデート情報として、AWS対応についてお話したいと思います。前回ご紹介した内容も若干理解していたほうが今回の話題も理解しやすいと思いますので、以下に前回の記事も載せておきます。

blog.lenovojp.com

前回の内容はESXiからAHVへの移行についての内容になっていましたが、今回もそちらの内容にも触れますが、AWSからの移行をご紹介したいと思います。(現状はTechPreview版でのリリース)

1. Xtractによる仮想環境の移行について

f:id:t_komiya:20190114005936p:plain

 みなさまも仮想化環境をNutanixで検討するときに、現状の仮想化環境(VMware)からAHVの環境に移行する場合にシンプルでかつ効率的で柔軟性があるツールを期待していると思います。前回紹介したXtractでESXに関する部分での柔軟性は十分にお伝えしたかと思いますが、今回のXtract 2.0においてはAWSやHyper-Vからの環境をオンプレのAHV環境にマイグレーションができるようになっています。もちろんすべての環境が移行できるわけではなく、AHVでサポートしているものに限定されるわけでありますが、それでもNutanixの環境に統合できることは恩恵は大きいと思います。

2. アプリケーションモビリティの実現

f:id:t_komiya:20190114010311p:plain

AHVへの移行のためにXtractがあるわけではありません。 以前にもご紹介したかと思いますが、マルチクラウド環境においてワークロードを最適なロケーションで動作させるためにCalmでデプロイさせることやBeamなどで複数のクラウド環境(オンプレのNutanixも含む)で最適なコストを見極めて、最適な場所へワークロード移行を行う際にXtractを利用するという、NutanixのEnterprise Cloudのビジョンも進化することで、様々なシーンでXtractを利用される場面が出てきております。

3. Xtractのお客様導入例

f:id:t_komiya:20190114172609p:plain

Xtractを利用して仮想マシンを移行した例を紹介したいと思います。すでに100以上のお客様で合計30,000台以上の仮想マシン(1社あたりでは最大数千という会社もあり)で利用されており、ほとんどがWindowsやCentOSなどの環境をAHVの移行で利用しております。通常この作業を行うと数か月要しますが、このXtractを利用すると期間を短縮することができます。その理由はXtractの対応しているCBT機能が一つのの要因かもしれません。

4. 環境やワークロードに適したデータ移行についてf:id:t_komiya:20190114173404p:plain

Xtractを利用する場合に利用している環境や利用しているワークロードが適しているものかどうかを考える必要があります。ESXであればオンプレ同士で移行が可能ですが、AWSからの移行であれば、対応しているOSや(セキュリティを考慮した)ネットワーク環境も考える必要があります。また、ワークロードについても普通の仮想マシンだけではファイルサーバみたいな容量が大きいものをどうするかなども考える必要があります。(ファイルサーバの場合はデータだけで考えればXtractが必須なツールではありませんが)

マルチクラウド環境でのデータ移行を効率するためにXtractが利用されます。Exchangeやドメインコントローラのようなものの移行についてもベストプラクティス(英語)を後程URLなど記載しておきます。

5. AWSおよびHyper-Vからのアプリケーションモビリティ

f:id:t_komiya:20190114174127p:plain

今回のAWS対応でパブリッククラウドからの仮想マシンの移行がサポートにより、パブリッククラウドへの依存性を軽減することができます。例えばパフォーマンスを必要とするアプリケーションやレイテンシ(遅延)を気にするようなワークロードについてはオンプレに移行したほうがよい場合にXtractを利用することで、1クリック(事前に設定は必要になりますが)で移行が可能となります。オンプレに関してはHyper-Vもサポートが追加されることになります。

6. Xtractのアーキテクチャ(AWS)

f:id:t_komiya:20190114175053p:plain

Xtractのアーキテクチャを簡単にご紹介します。AWSからの仮想マシン移行において、AWSでのCrendential情報を利用して仮想マシンにアクセスできる環境が必要になります。Xtractで移行を実行する際に、仮想マシンは稼働している状態の場合は動作中の差分データの転送も行うためにCBT(Change Block Tracking)機能が必要となります。また、AWS側の環境にはXtract-Liteの仮想マシンをデプロイしてAWS側の仮想マシンにアクセスできるようなアプライアンスを用意する必要があります。もう少し詳細に記載したものを以下のイメージとして載せておきます。

f:id:t_komiya:20190114180415p:plain

 

f:id:t_komiya:20190114180739p:plain

7. Xtract のオペレーション

Xtractでは以下のオペレーション可能となります。

  • パワーオンまたはパワーオフ状態のVMを移行します
    : AWSでは、移行は電源が入った状態で行われます。ESXiの場合、電源状態は保持されます
  • 移行を一時停止して再開
  • 移行のスケジューリング
  • 仮想マシンのデータシーディングを事前にスケジュールし、新しいAHVクラスターに切り替え
  • 単一の管理インターフェース複数のクラスタ間の仮想マシン移行を管理
  • 簡単に移行できるように仮想マシンソートおよびグループ化
  • 個々の仮想マシンレベルでも移行計画の実行の詳細を監視
  • 個々の仮想マシン進行中の移行をキャンセル
  • すべてAHV認定OS移行可能

8. Xtractのコンポーネント

f:id:t_komiya:20190114181231p:plain

こちらがコンポーネントの一覧になります。CLIについてはそれぞれのOSの環境で提供されています。Xtract-vmはターゲットとなるAHV側に導入するモジュールになります。Xtract-vm-LiteはAWSから移行を行う際のAWS側にデプロイするモジュールになります。ESXiやHyper-V環境についてはエージェントを導入します。

また、Xtract for VMで必要なリソースは以下の通りです。

  • コアあたりのvCPU:2
  • コア数:2
  • メモリ:4 GB

9. サポートされているESXiおよびゲストOS情報

f:id:t_komiya:20190114181645p:plain

NutanixのSupport Portalに掲載している情報ですが、こちらにも掲載しておきます。(2019年1月13日現在の情報のため、移行を行う前に情報を確認お願い致します)
10. ESXiマイグレーションの要件

Xtract for VMs使用してESXi上で実行されている仮想マシン移行しようとする前に、以下に記載の要件を必ず満たしてください。

ESXiマイグレーションのための一般要件

  • 対応ブラウザ:Google Chrome
  • VMware ToolsはマイグレーションのためにゲストVMインストールされ、最新にする必要があ
  • 仮想マシン実行されている仮想ハードウェアのバージョンは7.0以上である必要がある
  • ソース仮想マシンChanged Block TrackingCBT)をサポートしている必要がある
  • CBT機能をサポートするには、VMのハードウェアバージョンが7以上である必要がある
  • ディスクスパース(空き容量をゼロブロックで埋める)またはフラットフォーマットでなければならず、最小バージョンは2でなければなりません
  • ESXiのバージョンは5.1以上
  • ホストはメンテナンスモードにしてはいけない
  • ポートTCP 443vCenterからXtractアプライアンスに通信可能な状態にする
  • ESXiホストは、ポートTCP 443およびTCP 902Xtractアプライアンスに通信可能な状態にする
  • すべての仮想マシンにはUUIDが必要です
  • ESXiホストには、仮想マシンの完全な構成詳細が必要
  • 仮想マシンXtractによって作成された複数のスナップショットと互換性がなければなりません
  • Xtract for VMネットワークとAHV CVMネットワークとの間のポート(TCPおよびUDP2049および111許可
  • ゲスト内操作を実行するために使用されるアカウントには、Windowsのローカルセキュリティポリシーまたはグループポリシー内の[Batch Jobしてログイン]権限が必要管理者ユーザーには十分な権限がありません
  • ソースVMにアクセスするためにsudo特権を持つroot以外のアカウントを使用している場合は、SSH サービスがソースVM上で実行されていることを確認してください。具体的には以下を確認が必要
  • localhostへのSSHは、パスワード認証のみを使用して許可されます。つまり、sshd_configPasswordAuthenticationyesに設定
  • sudoを使用してください。ユーザーはパスワードを入力せずにroot特権を引き受けること可能
  • ユーザーは/tmpに対する読み取りおよび書き込み権限が必要
  • Xtractユーザーが[ファイルとディレクトリリストア]セキュリティポリシーでグループに属している 必要があることを確認してください

サービスアカウント

Xtractは管理者権限を持つ以下のサービスアカウントを必要

  • vCenter Server
  • AHVクラスター用のPrism Element Webコンソール

11. AWSマイグレーションの要件

Xtract for VMs使用してAWSで実行されている仮想マシン移行しようとする前に、以下に記載の要件を必ず満たしてください。

AWSマイグレーションのための一般要件

  • 対応ブラウザ:Google Chrome
  • インターネットゲートウェイを持つVPCを少なくとも1つ持つXtractはそのVPCがXtract-Lite 展開しXtract-Lite通信する必要があります
  • ソースVMのすべての発信ポートを有効にする
  • WindowsソースVMの場合、UACがWindows管理者ユーザーに対して無効になっていることを確認が必要
  • LinuxソースVMの場合、必要なパッケージをダウンロードするための初期準備中にVMがインターネット 接続できることを確認。次のパッケージとその依存関係は、SaltStack、python34、python34-pip、wget、curl、epel-release、redhat-lsb-core、jqと共にインストールされます
  • ソースVMは、インターネットゲートウェイとパブリックIPが構成されたVirtual Private Cloud(VPC)の一部である必要が
  • ソースVM準備スクリプトを実行するのは、administratorWindowsソースVMまたはrootLinuxソースVMのいずれかであることを確認する必要がある
  • Windowsリモート管理(WinRM)機能が機能するためには、TCPプロトコルを使用する次インバウンドおよびアウトバウンドポートが有効になっていることを確認が必要
  • WinRM-HTTPS:5986
  • WinRM-HTTP:5985
  • RDP:3389(インバウンドのみ
  • SSH22
  • AWSソースの追加中に提供されたAWSアカウントには、EC2インスタンスのエンドツーエンド マイグレーションを実行するための次の一連の権限が必要
  • "ec2:DetachVolume",
  • "ec2:AttachVolume",
  • "ec2:DeleteSnapshot",
  • "ec2:TerminateInstances",
  • "ec2:DeleteTags",
  • "ec2:CreateTags",
  • "ec2:Describe",
  • "ec2:RunInstances",
  • "ec2:StopInstances",
  • "ec2:CreateVolume",
  • "ec2:DeleteVolume",
  • "iam:SimulatePrincipalPolicy",
  • "ec2:StartInstances",
  • "ssm:DescribeInstanceInformation",
  • "ec2:CreateSnapshot",
  • "iam:GetUser",
  • "ec2:KeyPair",
  • "route53:CreateHostedZone",
  • "route53:UpdateHostedZoneComment",
  • "route53:GetHostedZone",
  • "route53:ListHostedZones",
  • "route53:DeleteHostedZone",
  • "route53:AssociateVPCWithHostedZone",
  • "route53:ChangeResourceRecordSets",
  • "route53:DisassociateVPCFromHostedZone",
  • "route53:ListResourceRecordSets",
  • "route53:GetHostedZoneCount",
  • "route53:ListHostedZonesByName"

サービスアカウント

Xtractは管理者権限を持つ以下のサービスアカウントを必要

  • AHVクラスター用のPrism Element Webコンソール
  • ソースVM準備スクリプトを実行するadministratorためのWindowsソースVMまたはrootLinuxソースVM

12. ESXiからのマイグレーションに関する推奨事項

ESXiからVMを最適に移行するために、Nutanixは以下の内容を推奨

推奨事項

  • アラートが存在する場合は、vCenter内のすべてのVMアラートを消去
  • インベントリ更新
  • テンプレートVM変換
  • vCenterからVMアクセスを有効
  • すべてVMvCenterを介して接続されていることを確認
  • すべてVMvCenterで有効であることを確認
  • 親なし(orphanedVMがある場合は、VMを完全に回復して下さい
  • ディスクCBTの互換性を確認
  • FTペアにある場合は、VMFault ToleranceFT)を無効
  • 移行するVMに最新バージョンのVMware Toolsインストール
  • CBT対応VMのインベントリ内のスナップショット数が30未満であることを確認

13. マイグレーションでサポートされていない機能

f:id:t_komiya:20190114184012p:plain

上記が現状マイグレーションでサポートされていない機能の一覧になります。説明は長くなりますので、割愛させて頂きます。 

14. マイグレーションの機能制限

Xtract for VMsアプライアンス機能制限事項とDNS構成について記載します

AWSからマイグレーション関する認定メトリクス

以下のメトリクスは、AWSからの移行に適してい

  • 大規模なVMアクティブなワークロードを持つVMおよび複数のディスクを持つWindows VMLinux VM組み合わせ
  • 単一Xtract-Mainを使用して13の異なる領域から並行してVMマイグレーション可能
  • それぞれ13のディスクを並列に持つ5つのインスタンスを持つマイグレーションプラン
  • 500 GBのディスクを持つ2つのインスタンスを持つシングルマイグレーション
  • 2 TBのデータを含む5 TBのディスクのシングルマイグレーション
  • マイグレーション計画で10を超えるVMマイグレーション

AWSマイグレーション制限

サポートは以下によって制限される

  • EC2インスタンスタイプC4C5M4M5R4T2を使用したVMマイグレーションがサポート
  • 1.Xバージョンを実行しているXtract for VMsインスタンスから2.0.xへのアップグレードはサポートされていません。VM用のXtractの新しい展開が必要
  • 移行にかかる時間は、VMのサイズ、移行中のVM内のデータチャーン率、およびAWSとオンプレミスデータセンター間のインターネット接続によって異なります

ESXiの移行の制限

次の移行は推奨されませんが、いくつかの制限付きで実行できます。

  • Exchangeは、既存の運用環境と並行して新しいバージョンのExchange Serverをインストールして 移行し、次にユーザーのメールボックスを古いシステムから新しいシステムに移動する必要がある
  • ドメインコントローラは、新しいドメインコントローラを準備し、次にFSMO(Flexible Single Master Operations)の役割を移行することによって移行する必要がある
  • SQL Serverは、新しいSQL Serverをインストールしてから移行操作を実行して移行する必要がある
  • 移行にかかる時間は、VMのサイズ、移行中のVM内のデータチャーン率、およびソースとオンプレミスのデータセンター間のネットワーク帯域幅/接続性によって異なる

各種アプリケーションのマイグレーションのベストプラクティスは以下をご参照ください。

Exchange環境マイグレーションベストプラクティス

https://blogs.technet.microsoft.com/meamcs/2013/07/25/part-3-step-by-step-exchange-2007-to-2013-migration/

ドメインコントローラのマイグレーションベストプラクティス

https://blogs.technet.microsoft.com/canitpro/2014/05/27/step-by-step-active-directory-migration-from-windows-server-2008-r2-to-windows-server-2012-r2/

SQL Server 2012のマイグレーションベストプラクティス

https://www.microsoft.com/en-us/download/details.aspx?id=29302

15. Xtractのダッシュボード画面

f:id:t_komiya:20190114184702p:plain

ダッシュボードオプション

Xtractダッシュボードには、以下のオプションが含まれます。

Source Environment(ソース環境)利用可能なソース環境を表示します。サポートバンドルからVMを移行するための場所を追加するには、[ + Add Source Environment]をクリックします

Target Environment(ターゲット環境):利用可能なターゲット環境を表示しTargetます。+ Add Target Environment]クリックして、VMをAHVに移行する場所を追加します。

マイグレーションプランの作成:AHVにマイグレーションするVMのマイグレーションプランを立てます。マイグレーションプランにはスケジュールオプションが含まれますが、カットオーバープロセスは開始されません。

マイグレーションプランの管理: [Start]、[Pause]、[Resume]、[Abort]、[Edit]、または[Delete]操作を実行して、Xtractダッシュボードの[Migration Plan]ページで既存の移行プランを管理します。

f:id:t_komiya:20190114185126p:plain

Xtract VMにログオンしたら以下のアクションを行います。

  1. ソース環境タイプとして[VMware ESXi]を選択
  2. 表示されたフィールドに入力して「追加」をクリック

  a.ソース名:ソース環境の名前を入力

  b.vCenter ServervCenter ServerIPアドレス またFQDN入力

  c.ユーザー名:vCenter Serverにログオンするため ユーザー名入力

  d.パスワード:vCenter Serverにログオンするため パスワード入力

ソース環境がXtract VMに追加され、ソース環境リストに表示

f:id:t_komiya:20190114185204p:plain

Xtract VMにログオンしたら以下のアクションを行います。

  1. ソース環境タイプとして[Amazon Web Services]を選択
  2. 表示されたフィールドに入力して「追加」をクリック

  a. ソース名:ソース環境の名前を入力

  b.AWSアクセスキーIDAWSアカウントのアクセスキーID入力

  c.AWSシークレットアクセスキー:AWSアカウントにログオンするためのキーを入力

ソース環境がXtractに追加され、ソース環境リストに表示。[Source Name]をクリックしてソースインベントリの詳細を確認し、リージョンおよびVMの移行ステータスに基づいて結果をフィルタリングできます。

f:id:t_komiya:20190114185248p:plain

Xtract VMにログオンしたら以下のアクションを行います。

表示されたフィールドに入力して「追加」をクリック

  a. ターゲット名:Nutanix AHVターゲットの名前を入力

  b.Nutanix環境:ターゲットのPrism CentralまたはPrism ElementIPアドレスまたはFQDNを入力

  c.ユーザ名:ターゲットNutanix環境にログインするための ユーザ名を入力

  d.パスワード:ターゲットNutanix環境にログインするためパスワード入力

ターゲット環境がXtract VMに追加され、ターゲット 環境リストに表示

 

これらの情報を入力したら仮想マシンのマイグレーションが可能になります。

16. 仮想マシンのマイグレーション

f:id:t_komiya:20190114190957p:plain

先ほど設定した情報を元にXtractアプライアンス上でマイグレーションプランを作成します。

マイグレーションプラン作成については次の事項で説明します。マイグレーションプラン作成後はマイグレーションカットオーバーを実行することでマイグレーションが始まります。

マイグレーション前に移行対象の仮想マシンの情報を把握しておく必要があります。

17. ESXiのマイグレーションプランの作成

f:id:t_komiya:20190114191704p:plain

初回ログイン時にデフォルトの認証情報を使用してXtractアプライアンスにログオン可能となります。以下のアクション行うことでマイグレーションプランを作成することができます。

1.Xtract VMログオン

2.Xtractダッシュボードで、[マイグレーションプランの 作成]をクリック

3.新しいマイグレーションプラン名を入力して、[OK] クリック

4.以下のフィールドに入力して、「次へ」をクリック

   a.ソースの選択マイグレーションvCenterソースを選択

   b.ターゲットの選択マイグレーションするVMのターゲットを選択

   c.ターゲットコンテナVMマイグレーションとなるコンテナを選択

5.上記で選択したVMは、リストから1台のまたは複数VMを選択。すべてのVMを追加するには、[+ Add All]をクリックし、[Next]をクリックしますフィルタバーでVMを名前でフィルタできます。適切な列を選択してVMの種類をソートすること可能

6.VM準備のフィールドに入力して、次へ ]クリック

   a.ゲスト仮想マシンのユーザー名とパスワードを入力して、Xtractが必要なドライバーを
   
インストールします

   b.個々のVM設定を上書きする:個々のVMに対して同じ設定を上書きします。個々のVM
   ユーザー名とパスワード
更新したり、不要なVMを削除したり
することもできます。

   c.個々のVMの設定を管理する:ソースVMからのMACアドレスを保持するには、

   [Retain MAC Addresses]チェックボックスをオンにします。ゲストOSの変更を回避するには、

   [Bypass Guest Operations]チェックボックスをオンにします。

   この操作はVMデータマイグレーションには影響しませんが、カットオーバーの前に必要な

   AHVドライバーを使用してゲストOSを手動で準備する必要があります

   さらに、ゲスト操作を迂回する場合は、静的IPアドレスの保存を個別に管理する必要があります

7.ネットワーク設定のフィールドに入力して、次へをクリック

   a.ドロップダウンからターゲットネットワークを選択

   b.データシーディングスケジュール:チェックボックスをオンにして

   マイグレーション日時を選択

8.VMのマイグレーションのサマリを確認

   a.情報を編集するには[戻る]クリック

   b.マイグレーションプランを保存するには、[保存] クリック

   c.マイグレーションプランを保存してすぐに移行を開始するには[保存して開始 ]をクリック。

   マイグレーションの ためのデータ配置処理が開始します。

   マイグレーション プランの[ステータス]を選択してこの情報を監視可能

18. AWSのマイグレーションプランの作成

f:id:t_komiya:20190114192507p:plain

初回ログイン時にデフォルトの認証情報を使用してXtractアプライアンスにログオン可能となります。以下のアクション行うことでマイグレーションプランを作成することができます。

1.Xtract VMログオン

2.Xtractダッシュボードで、[マイグレーションプランの 作成]をクリック

3.新しいマイグレーションプラン名を入力して、[OK] クリック

4.以下のフィールドに入力して、「次へ」をクリック

   a.ソースの選択マイグレーション用のAWSのソースを選択

   b.リージョン:VMのマイグレーション元の リージョンを選択

   c.ターゲットの選択マイグレーションするVMのターゲットを選択

   d.ターゲットコンテナVMマイグレーションとなるコンテナを選択

5.上記で選択したVMは、リストから1台のまたは複数VMを選択。すべてのVMを追加するには、[+ Add All]をクリックし、[Next]をクリックしますフィルタバーでVMを名前でフィルタできます。適切な列を選択してVMの種類をソートすること可能

6.Xtractは自動的にXtract Lite VMを選択したリージョンに展開します。これにより、Xtractと選択したUVMとの間に安全な接続を確立できます。デプロイされたXtract Lite VMの構成です

   a.名前:NTNX-XTRACTLITE-INSTANCE

   b.インスタンスの種類:t2.micro

   c.RAM1GB

   d.ストレージ:20GB EBSボリューム

   e.VPC:指定リージョンのデフォルトVPC

   f.タグ:名前、バージョン、認証データ

   g.セキュリティキー:VMからXtract Liteへの通信をセキュリティで保護するために添付された
   動的に作成されたキー

VMの準備のウィンドウが表示

7.VMを自動的に準備させるには[自動]を選択

8.手動でマイグレーション準備のソフトウェアをダウンロードして実行するために、[手動]を選択してからそれぞれのソースのEC2インスタンスでVMの準備を提供しているスクリプトを実行。このスクリプトは、次のインストールを実行してインスタンスを準備します

   a. Nutanix VirtIOドライバーのインストール

   b. CBTドライバのインストール

   c. Python 3.4のインストール

   d. Xtract-Liteとの接続を確立するためのSalt Minion インストール

9.ネットワーク設定のフィールドに入力して、次へをクリック

   a.ターゲットネットワークを選択

   b.データシーディングのスケジュール:チェックボックスを オンにして、移行する日時を選択

10.VMのマイグレーションのサマリを確認

   a.情報を編集するには、[戻る]をクリック

   b.マイグレーションプランを保存するには、[保存]をクリック

   c.マイグレーションプランを保存してすぐに移行を開始するには[保存して開始 ]をクリック。
   マイグレーションのための
データ配置処理が開始します。マイグレーションプランの [ステータス]
   選択してこの情報を監視
可能

19. Automatic VM Preparation(自動VM準備)

EC2上のWindows VMを自動的に準備する機能を提供し,事前にWinRMを有効にしてポート利用できるようにします。

1.VM PreparationにおいてAutomaticを選択

2.ソースVMの認証情報のフィールドに入力し、[次へ]をクリックします。

   a.ゲスト仮想マシンのユーザー名とパスワードを入力して、Xtractが必要な
   ドライバーをインストールできるようにします。

   b.認証にプライベート(PEM)ファイルを使用する:Xtractが必要なドライバを
   インストールできるように、Linux VMにユーザー名とパスワードの代わりに
   キーを使用するには、認証にプライベート(PEM)ファイルを使用チェック
   ボックスをオンにします。

   c.個々のVM設定を上書きする:個々のVMに対して同じ設定を上書きします。
   個々のVMのユーザー名とパスワードを更新したり、不要なVMを削除したりする
   こともできます。

VMの認証情報が検証されます。検証が成功すると、ゲストツール マイグレーションプランのすべてのVMにダウンロードされ、インストール されます。その後、VM Preparation整っているかどうかが検証されます

20. WinRMの有効化

WinRMを有効にしてWindows EC2インスタンスにゲストツールをインストール

1.Windows VMでPowerShellを開きます。

2.スクリプトを実行して、EC2 Windowsインスタンスに対してWinRMを有効にします

>winrm quickconfig -q

winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'

winrm set winrm/config '@{MaxTimeoutms="1800000"}'

winrm set winrm/config/service '@{AllowUnencrypted="true"}'

winrm set winrm/config/service/auth '@{Basic="true"}'

netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow

netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow

net stop winrm

cmd /c 'sc config winrm start= auto'

net start winrm

3. スクリプトを実行してSecure Sockets Layer(SSL)を有効にします。

>$c = New-SelfSignedCertificate -DnsName "$(hostname)" -CertStoreLocation

cert:\LocalMachine\My winrm create winrm/config/Listener?Address=*+Transport=HTTPS"@{Hostname=`"$(hostname)`";CertificateThumbprint=`"$($c.ThumbPrint)`"}"

21. マイグレーションプランの管理

基本的なアクション

  • Start すでに作成されている移行計画を開始します。ステータスがに変わります。検証計画そしてそれから 移行中。移行が完了すると、ステータスはに変わります。移行が完了しました
  • Pause 進行中の移行を一時停止します。ステータスがに変わります。移行が一時停止しました。このオプションは、移行計画を開始した後にのみ使用できます。移行が一時停止されると、移行を再開、中止、または削除可能
  • Resume 一時停止した移行を再開します。このオプションは、移行計画を一時停止した後にのみ使用可能
  • Abort マイグレーションをキャンセルします。ステータスがマイグレーション中止に変わり、その後マイグレーションのキャンセルに変更になります。マイグレーションがキャンセルされると、マイグレーションプランを削除することしかできず、そのマイグレーションプランに対して他のアクションを実行することはできません
  • Edit 既存のマイグレーションプランを更新します
  • Delete 既存のマイグレーションプランを削除します

22. マイグレーションカットオーバーの実行

f:id:t_komiya:20190114193948p:plain

23. 大規模データのマイグレーション

f:id:t_komiya:20190114194209p:plain

こちらはNutanixのSupport Portalに掲載されている情報になります。参考情報までに

 

最後にHyper-VにおけるXtractのアーキテクチャの情報を載せておきます。こちらも次のリリースで出てくる機能となります。

f:id:t_komiya:20190114194520p:plain

こちらのアーキテクチャはXtract-Liteではなく、Xtract Agentをソース側に導入してターゲット側からデータを取得する内容となります。

 

AHVへの仮想マシン移行時に是非試してみてはいかがでしょうか。

 

よろしくお願い致します。

 

 

1年ぶりのLTS対応AOS5.10 とその追加機能のご紹介~AOS5.10の機能紹介~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は昨年12月にリリースされたAOS 5.10の機能紹介をしたいと思います。AOS5.9がリリースされて3か月も経過していないのに、もう新しいAOS5.10がリリースされるの?と思われる方もいらっしゃるかと思います。NutanixのソフトウェアはLTS(Long Time Support)とSTS(Short Time Support)の二つ分かれて、LTSは1年おきのリリースでアナウンスされることになっており、12月はちょうど1年前にAOS5.5がリリースされた時期ということもあり、今回のリリースになっているわけです。

AOSのリリース時期については、以下のイメージでつかんで頂ければと思います。

f:id:t_komiya:20190107211115p:plain

昨年11月にLTSとSTSの記事は投稿しておりますが、改めてアップデートしたいと思います。

blog.lenovojp.com

 

今回のAOSの5.10がリリースされたことにより、LTSのサポートされる期間が2020年3月まで延びることになりました。AOS5.5のメンテナンスサポートが2019年4月で終了することから、リリースを待ち望んでいた人も多いと思います。メーカー各社のサポートを見て是非アップデートをお願いします。詳細は以下に掲載いたします。

f:id:t_komiya:20190107212231p:plain

f:id:t_komiya:20190107212326p:plain

f:id:t_komiya:20190107212425p:plain

一点だけ注意事項として、AOSのアップグレードパスについてです。

すべてのバージョンから最新版であるAOS5.10にアップグレードできるわけではありません。是非アップグレード前にNutanixのサポートポータル上のアップグレードパスをご参照ください。バージョンによっては2段階のアップグレードが必要になります。

f:id:t_komiya:20190107212644p:plain

 

AOS5.10で追加された機能について

XI Leap対応

f:id:t_komiya:20190107212934p:plain

AOS5.10からXi Leap(Nutanixのクラウドサービス)の接続が可能になりました。

今回はこちらのスライドでDRaaSとしての紹介を軽くしておきますが、今後Xi Leapについてはブログの中でもう少し具体的に紹介させて頂きたいと思います。

Autonomous Extend Store - AES

f:id:t_komiya:20190107213516p:plain

自律的なエクステントストアということですが、要するにランダムライトのパフォーマンスを向上するために、データパスの改善を行っています。今後の大容量化に向けてのメタデータ管理方法を変えてことが今回の狙いになります。(他のノードのCassandraのやりとりが軽減されている)

f:id:t_komiya:20190107214145p:plain

f:id:t_komiya:20190107214233p:plain

詳細は以上のイメージをご参照下さい。これを導入するとどのくらいの効果があるのか?というと・・・Nutanixの.NEXTでの資料を見たところでは20%程度向上しているようです。ポイントを以下に記載しておきます。

主な改善点

持続的なランダム書き込みを改善

  • IOPS Cliff解消
  • 低耐久性SSDの使用を可能にする

高容量のストレージノードのサポート

  • ノードあたり300TB以上

ローカライズされたバックグラウンドデータ管理

  • ローカルノードのILM、重複排除、変換

そんなAESについてですが、良いことばかりではありません。現状の制限事項もございますので、併せて掲載させて頂きます。

f:id:t_komiya:20190107214915p:plain

ここでのポイントですが、ALL Flashのみで利用可能であることとSSDやNVMeの搭載本数に制限があることです。今後のソフトウェアのアップグレードでこちらは解消されますが、すべてが反映されるのはしばらく先の話になります。

また、NXシリーズ以外は各社の認定ファームウェアの確認が必要となります。

Never Schedule Node

f:id:t_komiya:20190107215224p:plain

スケジュール不可ノードと記載がありますが、実際にはストレージ専用ノードと同様のことを記載しております。今まで各社のNutanixのハードウェアでストレージ専用ノードが存在していたかと思いますが、それが任意のシリーズでストレージ専用ノードとして利用することができるようになります。アプリケーションのライセンスを意識する場合には特に有効的になると思います。

また、Nutanixクラスタのデータストレージを増やすためにノードを追加したいが、そのノード上でAHVのVMを実行したくない場合は、スケジュール不可能ノードを追加できます。 AOSは新しいVMの展開時、あるホストから別のホストへのVMの移行中(ホスト障害の場合)、またはその他のVM操作中にかかわらず、スケジュール不可能ノード上のVMをスケジュールすることはありません。 したがって、スケジュール不可能なノード構成では、NutanixクラスタからCPUなどの追加のコンピュートリソースが消費されることはありません。

Disaster Recovery Orchestration

f:id:t_komiya:20190107220948p:plain

PrismでDRのオーケストレーションができるようになっています。DRサイト構築(今回はXi Leap上も含めて)時に仮想マシンの復旧できるシナリオを想定しておかなければならない場合に、そのテストも含めてできるようにするのがこの機能です。以前NearSyncをご紹介したときに出てきたRunBookと同様です。

その他のサポート機能について

f:id:t_komiya:20190107221412p:plain

AOS 5.10についてはほとんどがバグフィックスになりますが、そのほかにサポートされたのがこちらになります。vGPUについては、HAが今まで(AHVで)サポートしていなかったのですが、今回ベストエフォートのモードでのみサポートがされることになります。ベストエフォートモードを忘れてしまった方のために、リンクをつけておきます。blog.lenovojp.com

 

 

2019年1月7日時点でAOS 5.10も2回アップデートがかかっているため、是非プラットフォームがサポートされた段階で機能を試してみてはいかがでしょうか。

(今までAOS 5.6 - 5.9の機能も今回試すことができます)

 

よろしくお願い致します。

IoTエッジやマイクロデータセンターの展開や運用を容易にする「Project Dimension」について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は今年のVMworldやvForumでも話題となりました「Project Dimension」について少しお話したいと思います。(今回の情報はインターネット上の公開情報+α程度のもので、詳細な説明は追ってさせて頂きたいと思います。

こちらのProject Dimensionですが、vSphereのHCIベースのコンピュートシステムとIoTエッジ/マイクロデータセンターの設置や運用を代行するサービスになります。これだけ聞くと大規模のシステムが必要になると思われますが、通常の3台のvSANのシステムから展開できるような、シンプルな構成で実現できます。

Project Domensionの説明を行う前に、まずはVMwareが提供するハイブリッドクラウドについて軽く説明したいと思います。

f:id:t_komiya:20181223160008p:plain

VMwareのクラウドのビジョンは従来型のプライベートクラウドと今回東京リージョンも開設したAWSとのハイブリットクラウドまででしたが、2018年になり大きく異なってきたのがエッジコンピューティングにフォーカスが当たってきたことです。2020年を見据えたオリンピックなどで高解像度のビデオ画像のリアルタイムのAI連携をはじめととしたエッジとクラウド・データセンターでは対応できないものが多くなってきている。そのために高速なネットワーク接続なども必要となるわけですが、エッジまでの伝送スピードも携帯の5Gなどの出現により広帯域のネットワークが出来上がるもの実現する一つのきっかけになります。

また、これらの構成を一つずつ手作りして提供するのではなく、サービスとして提供することにより、少しでも迅速なサービス展開(エッジ側にもコンピュートノードを設置)できるものを考えており、それらを一括で稼働状況も含めて管理できるようなものを考慮されております。現状提供予定しているベンダーとしてLenovoとDELL EMCの2社を予定しています。基本構成としては、VCF(VMware Cloud Foundation)が採用されることになります。

 

f:id:t_komiya:20181223164038p:plain

 ここで、エッジコンピューティングに必要な環境についてお話したいと思います。今までハイブリッドクラウドということで、オンプレミスのデータセンター・サービスプロバイダーやパブリッククラウドなどが挙げられますが、今回初めて登場するエッジについてもう細かく見ると、エッジコンピューティングはそれぞれの業種で異なる用途利用されます。製造業などで生産された商品データや小売業などでは、商品の売り上げデータなど様々なデータが日々生み出されます。俊敏なビジネスの変化ついていくために膨大なデータの活用をハイブリッドクラウド環境で利用する場合に、今まで通りにエッジ側の設備投資などでお金と時間をかける必要があるのでしょうか。

f:id:t_komiya:20181223165742p:plain

それらの生み出されたデータは膨大なデータとなり、分析することでリアルタイムの意思決定に必要なデータとして利用され、今後のビジネスの継続性にもつながりますf:id:t_komiya:20181223170411p:plain

このような構成が5Gのネットワークのインフラが整った場合にどのようになると思いますか?エッジ側で生成されるデータをオンプレのデータセンターやパブリッククラウドなどに転送しても遅延なども含めて問題ないような インフラが出来上がります。そのときに、ハイブリッドクラウドは場所では一つのビジネスケースとして取れることができ、ビジネスの変化にも柔軟に対応できるようになります。

f:id:t_komiya:20181223205407p:plain

ここでProject Dimensionの概要をお話したいと思います。ハイブリッドクラウド側を管理するVMwareとして、VCFのプラットフォームを利用します。ハイブリッドクラウドのコントロールプレーンとして、ゼロタッチプロビジョニングやローリングアップグレードなどの柔軟な管理とポリシー決め・セキュリティなども含まれております。VMware Cloudから各IoTのエッジのサイトに接続しデータの収集・連携を行います。

f:id:t_komiya:20181223212340p:plain

今回レノボがProject DimensionでVMwareと提供する部分についてですが、データセンター部分で提供されるハイパーコンバージドアプライアンスが対象になります。これだけならほかのメーカーでもできるのではと思いますが、実はエッジサイトからのデータの連携する部分においてもレノボが開発する部分があります。こちらの詳細は公開可能になった段階でお話させて頂きたいと思います。

f:id:t_komiya:20181223212903p:plain

イメージとしてこんな感じになると思います。データセンターの設備でエッジ側のそれぞれにサイトにおける規模を選択し、SLAを設定しそれぞれの拠点にポリシーを配信します。

f:id:t_komiya:20181223213114p:plain

設定された情報を元に各拠点からVMware Cloud上の管理サーバにデータの収集を行います。これを実現するプラットフォームがすなわちProject Dimensionになります。

f:id:t_komiya:20181223213450p:plain

提供するコンポーネントはこのようなイメージになると思います。ここでポイントになるのは、エッジ側のネットワークのプロビジョニングで利用されるのは、SD-WANソリューションになるVelocloudになります。Velocloudを利用することで1クリックでエッジ側のネットワーク情報を生成および配信までを実現し、VMware Cloudのネットワークを簡素化するソリューションとして利用されます。(物理スイッチは冗長化である必要は無いようです)

 

参考までに見て頂けれると幸いです。

 

よろしくお願い致します。