[Nutanix] 純正移行ツール Xtract for VMの紹介(2)

前回はXtract for VMsの説明とインストールについて簡単に紹介しました。

今回は実際に仮想マシンの移行について簡単に紹介しようと思います。

 

 

① Xtract for VMsにログインし、ソース環境を追加します。ソース環境はvCenterになります。

 

② ソース環境を追加しましたら、今度はターゲットのAHVクラスタを追加します。

 

③ ソース、ターゲットを追加しましたら、移行プランを作成します。画面中央の”Create a Migration Plan”をクリックします。

 

④ 移行プランを作成したら、ターゲットクラスタとコンテナを選択します。

 

⑤ 移行対象仮想マシンを選択し、移行プランに追加します。

 

⑥ 移行時仮想マシンのネットワークアダプタのドライバーなどがAHV用に上書きされます。そのためXtract for VMsが仮想マシンにログインする必要があります。仮想マシンにログインするユーザ名とパスワード、移行先で使用するネットワークを指定します。

 

⑦ これで移行準備は終わりです。”Save and Start”をクリックし、移行を開始しましょう。

 

⑧ 移行が開始されると、まず設定した情報の有効性をチェックします。

 

⑨ 設定情報が有効だった場合は、初期レプリケーションが自動的に開始されます。

 

⑩ 初期レプリケーションが開始されるとXtract for VMsにトラフィックが流れるのが確認できます。

⑪ この状態でソースのvCenterを見てみると、移行対象仮想マシンに対してスナップショットが作成されたことが確認できます。

 

⑫ 移行が終盤にかかると “Status”に’小さい●’が表示されます。クリックしてみると”Ready For Cutover” 状態が確認できます。前回にも説明した通りCutoverを実行しない限り、移行は完了されません。

 

⑬ 仮想マシンを選択し “Cutover”を実行します。Cutoverを実行するとソース環境上の仮想マシンはシャットダウンされ、仮想マシンの’メモ’欄には次のようなメッセージが記録されます。

VM migrated to 192.168.205.55 by New Migration Plan on Tue Oct 10 11:40:26 UTC 2017 by xtract-vm 1.0.15

 

⑭ ソース環境上の仮想マシンが停止したらスナップショットが作成され、最終同期が行われます。

 

⑮ 移行が完了しました。移行が完了したらPrism上で移行された仮想マシンが確認できます。

 

⑯ ソース環境のvCenterを確認してみると仮想マシンの停止後、スナップショットが作成されてから削除されたことも確認できます。

 

どうでしょうか?本当に簡単じゃないすか?操作ステップも少なく、非常にスムーズに移行ができました。

個人的にはAHV専用ツールではない、汎用の移行ツールとして仕上げてもらいぐらいです。:)

 

今回の検証は1ノードのコミュニティーエディション(しかもネスト)で行いましたので、コミュニティーエディションをお持ちの方は是非試してみてください。

 

 

広告

[Nutanix] 純正移行ツール Xtract for VMの紹介(1)

10月5日、Nutanix社純正移行ツールであるXtract for VMがGAされました。(Xtract for DBsもありますが、それは今度にします)

 

このXtract for VMは今年ワーシントンで開催された.NEXT Conf 2017 USで発表された移行ツールです。このツールを使うとvSphere環境からAHV環境へ仮想マシンをを簡単に移行できます。(過去にVDDK(Virtual Disk Development Kit)を使用した移行ツールを使ったことがありますが、このXtract for VMも同じフローです)

上図のように移行を開始するとまず、初期レプリケーション(initail seeding)が行われます。初期レプリケーション完了後は差分のみ同期が行われます。ここまででは移行は終わりません。仮想マシンの移行を完了するためにはCutoverを実行し仮想マシンを切り替える必要があります。切り替えという表現を使ったのはCutoverを実行することでソースvSphere環境上の仮想マシンがシャットダウンされ、ターゲットAHV環境にレプリケーションされている仮想マシンが登録されるためです。よって移行が完了してもvSphere上の仮想マシンは残ります。

 

 

Xtract for VMの重要機能は以下のとおりです。

  • 稼働中または停止中の仮想マシンの移行可能
  • 移行プロセスの一時停止、レジューム可能
  • スケジューリング可能
  • 複数クラスタからの移行をサポート
  • 移行対象仮想マシンのグループ化可能
  • 切り替えタイミングを見計らっての移行可能(Cutover)
  • 仮想マシン単位で移行状況のモニタリング可能
  • AHVがサポートしているすべてのOS対応

 

逆にまだサポートされない部分は次のとおりです。

  • AHVがサポートしてないOSの仮想マシン
  • 仮想マシン名が英語以外の場合
  • vCenterを経由しないESXiホストダイレクト接続
  • RDMや独立ディスクを使用している仮想マシン
  • マルチライトモートディスクを使用している仮想マシン
  • 2GBのスパースディスクを使用している仮想マシン

 

早速検証環境で動作を確認してみました。さすが、NutanixらしいシンプルなUIと直感的な操作でまったく迷うことなく移行ができました。

 

簡単にインストールと移行方法について紹介したいと思います。

まずインストール前に利用条件を確認しましょう。Xtract for VMを利用する場合、以下の条件を満たす必要があります。

  • vSphereからAHVへの一方向への移行のみサポート
  • ソースのvSphere(vCenter)は、バージョン5.5以上
  • ターゲットのAHV(AOS)は、バージョン5.5以上
  • 操作するブラウザはGoogle Chromeのみサポート
  • 移行対象仮想マシンにはvmware toolsインストール済み
  • 移行対象仮想マシンの仮想ハードウェアバージョンは7.0以上
  • CBTサポート要

 

それでは簡単にインストールについて紹介します。

簡単の方法はアプライアンスの導入です。

① まずNutanixのポータルからXtract for VM用ファイルをダウンロードし、解凍します。

 

② 解凍したフォルダの中から、’xtract-vm-1.0.15.qcow2’ファイルをPrismの”Image Configuration”に登録します。

 

③ Xtract for VM用仮想マシンを作成します。仮想マシン作成時は、次の項目を設定します。

    • CPU : 2 vCPU
    • メモリ : 4GB
    • ディスク : 手順 ②で登録したイメージファイル ※ デフォルトで追加されているCD-ROMは削除します。削除しないとエラーが作成できません。
    • ネットワークアダプタ : vCenterとAHVクラスタにアクセス可能なネットワーク
    • カスタムスクリプト : 解凍したフォルダ内の’xtract-vm-cloudinit-script’ファイルの中身を”Type or paste script”欄にコピーアンドペーストします。

 

④  仮想マシンを作成し、起動後はWebブラウザからXtract for VM UIにアクセスします。EULAに同意後、初期パスワードを設定すると準備完了です。

 

⑤ ログインしてみると非常にシンプルなUIであることが分かります。(個人的にはこれもNutanixの強みの一つだと思います)

 

これでXtract for VMのインストールは終わりです。次回は移行の方法について簡単に紹介したいと思います。

 

[VMware] !!! vSAN All Flashモードの緊急修正パッチ公開 !!!

10月5日、vSNA All Flashモードの重要なパッチが公開されました。

 

内容は、チェックサムエラーにより、特定な操作やIOパターンが発生した場合、仮想マシンへのアクセス不可、ホスト失敗、再同期失敗などの致命的な状態に陥る可能性があるとのことです。

 

条件はESXi 6.0 Patch 4 (build number 4558694)以上のvSAN、すなわちvSANバージョン6.2, 6.5, 6.6, 6.6.1のAll Flashモードで重複排除が有効化されている場合で、この条件を満たしている場合は、直ちに下記修正パッチを適用することを推奨しています。

 

[Nutanix] Self Service Restoreについて

少し古い内容かもしれません。

 

NutanixにおいてvSphereやAHVを利用する場合は、仮想マシンにNutanix Guest Tools(NGT)がインストールできます。このNGTは仮想マシンの情報をNutanixクラスタに提供したりESXiからAHVへ仮想マシンを移行する際に必要なVM Mobilityドライバーを提供したり、Linux OSの仮想マシンに対してアプリケーションの整合性を保てるスナップショットの作成などをサポートしています。またこれから紹介するセルフサービスリストアもこのNGTを使います。

 

Self Service Restore(SSR) aka File Level Restore

AOS 4.6よりWindows OSの仮想マシンに限って利用できるセルフサービスリストア機能です。(5.1の現在もLinux OSの仮想マシンではこのSSRを利用できません) 4.6ではコマンドでの実行でしたが5.0からはGUIでの利用が可能になりました。

このSSRはProtection Domainによって作成されたローカルスナップショットを仮想マシンにマウントし、必要なデータをコピーできるようになるため、利用者はVolume Shadow Copyのように自分でファイルレベルでデータを復元できます。

SSRを利用するためには次の条件が必要です。

  • 仮想マシンのOSがWindows Server 2008 またはWindows 7移行のバージョンであること。
  • 仮想マシンがポート2074を使い、NutanixクラスタIPアドレスに疎通できること。
  • Protection Domainで保護されている仮想マシンであること。
  • 仮想マシンにCD-ROMドライブが追加されていること。

上記の条件を満たしていればSSRを有効にでき、利用者自身がデータをリストアできます。それは簡単にSSRの有効について紹介します。

① まずSSRを利用する仮想マシンにNGTをインストールします。Prismより仮想マシンの”Manage Guest Tool”をクリックすると自動的にNGTイメージがマウントされます。この時、オプションとして”Enable Nutani Guest Tools”と”Self Service Restore(SSR)”を選択します。(NGTインストール後でもオプション設定は可能です)

 

② マウントイメージより、NGTをインストールします。

③ NGTのインストールが完了するとデスクトップに”Nutanix SSR”のアイコンが登録されます。

 

④ アイコンを実行するとSSR UIが表示されます。ちなみにPrismのコンソールより実行するブラウザが’応答なし’状態になってしまうのでRDPからの操作が良いかもしれません。(ブラウザが’応答なし’になった場合は、新しくブラウザを起動すれば引き続き利用可能です)

 

⑤ それでは簡単に使い方を確認しましょう。SSRを有効にした仮想マシンのフォルダを削除後、リストアしてみます。(ここではMicrosoft.NETフォルダを削除しました)

 

⑥ SSR UIを起動します。ログインユーザ名とPWDは、仮想マシンのローカル管理者です。※ドメインユーザでログインする場合あ、”ドメイン\ユーザ名”形式での入力が必要です。

 

⑦ ログインするとProtection Domainによって作成されたスナップショットが確認できます。Protection Domainの運用によっては年単位でのデータのリストアも可能です。:)

 

⑧ テストなので、最新のスナップショットを選択しました。表示されるディスクを選択し、”Mount”を実行します。

 

⑨ ディスクが正常にマウントされたことが確認できます。ちなみにマウントドライブが2つなので、Cドライブのためです。

 

 

⑩ エクスプローラを開き、ドライブを確認すると’E’と ‘F’ドライブにマウントされていることが確認できます。もちろん「ディスクの管理」でも確認できます。

 

⑪ ‘Fドライブ’から必要なファイルをコピーし、復元します。一つ注意点があります。マウントしたドライブは、何故か書き込みや削除などができてしまいます。間違ってスナップショットのデータは修正しないよう気をつけてください。

 

 

⑫ データを復元したらマウントしたディスクを取り出して終了です。:)

 

どうでしょうか?簡単ではありませんか?まあ〜実環境で運用するためには権限やスナップショットの管理など少々考慮すべきことはありますが、このSSRを使うと確実にインフラ管理者の運用負荷は減ります。

この機能を追加費用なしで利用できることは非常に魅力的にです。このSSRはもちろんローカルデータ保護やリモートサイトへのレプリケーションによるDR構成までも追加費用なしで簡単に実現できることがインフラ管理者がNutanixを欲しがる理由の一つではないかと思います。:)

 

 

[Nutanix] NTC 2018応募受付開始

今年もNutanix社のNTC(Nutanix Technology Champions)プログラムの2018年度の応募受付が開始されました。

 

徐々に認知度が広がっているNTCはNutanix社のソリューション、テクノロジーなどをコミュニティーやブログ活動などで広めたエキスパートを称えるグローバルプログラムです。

もちろん所謂、“資格”ではなく単なる”名誉”ですが、ITインフラ業界でのNutanixの知名度や影響力、技術力を考えるとエンジニアとしての自分の価値を知らせられる良い機会ではないかと思います。

 

NTCに選ばれると以下のようなメリットがあります。

  • Nutanix製品および新しいアナウンスのアーリーブリーフィング
  • 開発中のプロダクトへのプライベートベータテスト参加可能
  • エンジニアリングチームとのミーティング参加可能
  • 専用NTC Slack参加
  • NPP、NPX取得のためのサポート
  • ゲストブロギングやプレゼンチャンス

 

応募期間は11月7日まででNTC 2018の発表は12月になるとのことです。

Nutanixのソリューション/テクノロジーの情報を発信している方やコミュニティー活動をされている方は是非応募してみてはいかがでしょうか?

NTC Application Form

 

ちなみにNutanix社の資格制度について気になる方は過去の記事をご確認くださいなー。

NPP、知ってますか?

 

[VMware] vSAN環境のESXiホストの起動/再起動に時間がかかる

既に運用している方はご存知かと思います。

vSAN環境においえESXiホストを起動または再起動する場合、non-vSAN環境より時間がかかります。理由は下図のような状態がしばらく続くからです。

VSAN: Initializing SSD: xxxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxxx Please wait….

 

この状態がしばらく続くため、起動中フリーズしたかのように見えます。この状態で10分以上なんの変化がないとイライラしてくるかもしれません。:) この場合は軽く「Alt+F12」を押します。すると下図のように実は処理は進んでいることが分かります。

 

それでは”なんでこんなに時間がかかるのか?”ということですが、vSANの場合、ESXiホスト起動時SSD上のログを参照しメタデータテープルを作成するためのようです。このメタデータテープル作成はディスクグループごとに行われるようです。なのでディスクグループ内にデータ量が多いとその分、メタデータテープル作成に時間がかかり、結果的にはESXi起動/再起動全体に時間がかかってしまいます。この現象は所謂、”バイ・デザイン”的な動きのため、イライラせずに処理が終わるまで待ちましょう。なお、“SSD Initialized ~”の状態では強制的に処理中断させたり、再起動を実行するとデータが壊れる可能性があるとのことですので、ご注意を!

 

本現象については先日KB2149115が公開されました。

Initializing vSAN during boot takes a longer time

 

 

[Nutanix] IPMI情報の変更

それほど利用するシーンは多くないとは思いますが、備忘録として…

 

先日、vSphereをハイパーバイザーとして使用するNutanix、正確にはDell EMCのXCシリーズを導入したお客様から連絡がありました。XCのiDRACのIPアドレスを変更したら、次のようなアラートメールを受信したとのことでした。

IPMI IP address on Controller VM xxx.xxx.xxx.xxx was updated from xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx without following the Nutanix IP Reconfiguration procedure.

 

Impact          : The host is unreachable through the IPMI interface.

Cause           : The IP address configured in the cluster does not match the actual setting of the IPMI interface.

Resolution      : Follow the IP address change procedure in the Nutanix documentation.

 

Node Id         : NA

Block Id        : 11111112

Cluster Id      : 122345678884

Cluster Name    : cluster.clustername

Cluster Version : nutanix-core-el6-release-danube-4.5.2-stable-aa23456788823456788859ce1234567888ea2237e8f3

Cluster Ips     : aaa.aaa.aaa.aaa bbb.bbb.bbb ccc.ccc.ccc

Timestamp       : Mon Sep 10 02:51:56 2017

 

確認をしたところ、IPアドレスの変更はiDRACのUIより直接行ったとのこと。

 

iDRACからIPアドレスを変更した場合、その変更内容はCVM側で認識しません。そのため、iDRACのIPアドレスを変更する場合は、ホスト側で実施する必要があります。

変更はLinux共通コマンドでもあるipmitoolを使います。

 

 

まず、以下のコマンドで現在の設定情報を確認しましょう。

[root@esx-3:~]  /ipmitool lan print 1

Set in Progress         : Set Complete

Auth Type Support       : MD5

Auth Type Enable        : Callback : MD5

                        : User     : MD5

                        : Operator : MD5

                        : Admin    : MD5

                        : OEM      :

IP Address Source       : Static Address

IP Address              : 10.3.12.213

Subnet Mask             : 255.255.255.0

MAC Address             : 74:e6:e2:fc:9d:3a

SNMP Community String   : public

IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10

BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled

Gratituous ARP Intrvl   : 2.0 seconds

Default Gateway IP      : 10.3.12.254

Default Gateway MAC     : 00:00:00:00:00:00

Backup Gateway IP       : 0.0.0.0

Backup Gateway MAC      : 00:00:00:00:00:00

802.1q VLAN ID          : Disabled

802.1q VLAN Priority    : 0

RMCP+ Cipher Suites     : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

Cipher Suite Priv Max   : Xaaaaaaaaaaaaaa

                        :     X=Cipher Suite Unused

                        :     c=CALLBACK

                        :     u=USER

                        :     o=OPERATOR

                        :     a=ADMIN

                        :     O=OEM

 

上記のコマンドを実行することで、現在のiDRACのネットワーク情報が確認できます。

 

次は、下記のコマンドで設定ができる状態に切り替えます。

 

[root@esx-3:~] /ipmitool lan set 1 ipsrc static

 

次は、新しいネットワーク情報を設定します。

[root@esx-3:~] /ipmitool lan set 1 ipaddress 10.3.12.3

Setting LAN IP Address to 10.3.12.3

[root@esx-3:~] /ipmitool lan set 1 netmask 255.255.255.0

Setting LAN Subnet Mask to 255.255.255.0

[root@esx-3:~] /ipmitool lan set 1 defgw ipaddr 10.3.12.254

Setting LAN Default Gateway IP to 10.3.12.254

 

終わりましたら、再度設定した内容を確認しましょう。

[root@esx-3:~]  /ipmitool lan print 1

Set in Progress         : Set Complete

Auth Type Support       : MD5

Auth Type Enable        : Callback : MD5

                        : User     : MD5

                        : Operator : MD5

                        : Admin    : MD5

                        : OEM      :

IP Address Source       : Static Address

IP Address              : 10.3.12.3

Subnet Mask             : 255.255.255.0

MAC Address             : 74:e6:e2:fc:9d:3a

SNMP Community String   : public

IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10

BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled

Gratituous ARP Intrvl   : 2.0 seconds

Default Gateway IP      : 10.3.12.254

Default Gateway MAC     : 00:00:00:00:00:00

Backup Gateway IP       : 0.0.0.0

Backup Gateway MAC      : 00:00:00:00:00:00

802.1q VLAN ID          : Disabled

802.1q VLAN Priority    : 0

RMCP+ Cipher Suites     : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

Cipher Suite Priv Max   : Xaaaaaaaaaaaaaa

                        :     X=Cipher Suite Unused

                        :     c=CALLBACK

                        :     u=USER

                        :     o=OPERATOR

                        :     a=ADMIN

                        :     O=OEM

[root@esx-3:~]

 

これで終わりです。上記の手順を各ホスト毎に実行するだけです。変更した内容は自動的にiDRACに反映されるのでiDRAC側で何か設定を変更することはありません。

 

 

 

 

[VMware] VMworld 2017 Europe #5

 

最終日です。

今日でVMworld 2017 Europeは終わりです。ソリューションエクスチェンジを含め、各イベントコーナは14時になると片付け始めるしセッションも16時で終了です。一昨年来た時には14時で登録したセッションも終わり、モンジュイック城も言ったり有名らしいイカスミパエリアも食べて半日ほど観光もできましたが、今年はなぜか最後までセッションを入れてしまいました。

今日はGeneral Sessionもありませんので9時からきっちりとセッションを聞きました。

 

vSAN 6.6 : A Day in the Life of an I/O

タイトルだけだとvSANのIOに関するなんだかディープな話が聞けそうな感じがしましたが、実際はvSAN 6.6の機能説明でした。前半はvSANってなんぞやで後半はvSAN 6.6の新しい機能説明でしたね・もちろん所々IOについても説明はありました。

まず、重複排除と圧縮のIOパスについて紹介します。まあ、すでに沢山の情報が出回っていますが自分は下記のスライドが分かりやすくまとめたと思いますね。

 

もちろん重複排除と圧縮にはトレードオフがあることも忘れませんでした。 🙂

 

またvSANトラフィックの概念も分かりやすくまとめてましたので紹介します。

 

Reference Design for SDDC with NSX and vSphere : Part 2

今度はNSXのセッションです。が… ご覧の通りタイトルにPart2ってついてます。ということは前に2日間のどっかでPart  1があったというこですが、自分は聞いていません。で参加者の殆どはPart 1を聞いていてプレゼンターも同じ人のようでした。ふむ。セッション開始後簡単にPart 1のまとめを言ってましたがついていけませんでした。プレゼンターがあまりにも速口でですね… 汗

 

とりあえず聞けた内容は…

  • 小規模(1-2ラック)でのNSX構成であれば無理にVXLANを構成しなくても良いぜ。DFWだけでも十分使えるよー。
  • DLRは要らない。ESGで十分でしょう。
  • Edgeクラスタは作らなくても良いよー   みたいな…

 

次に中規模です。

  • 中規模なのでManagementクラスタとEdgeクラスタは同居でも良いぜー。
  • ただESGはECMPの二重化してねー   みたいな…

 

大規模については…

  • 規模が大きいからEdegクラスタ分けられるでしょ?分けてね。
  • 分ける時は最低4ノードで構成するんだよー。
  • DLR Control VMとESGは違うノードで動かしてねー

 

スライドをご覧のとおり、もちろんもっと話してましたよ。規模の話以外にNICは40GbEが良いぜーとエンタープライズトポロジーの話もありましたがメモるのを諦めました。マジでは速口です。参加者から喋りが速すぎる~ってクレームがあったぐらいですから。

 

vSAN Networking Design and Configuration Consideration

このセッションの内容は殆ど既に公開されている vSAN Networking Design Guideにある内容かもしれませんでした。必ず聞く必要はありませんでしたけどvSANでは有名なCormacさんがプレゼンターとして登壇するので聞きました。いや~オーラが違いましたね。w

 

まずはvSAN Networkingを構成する重要な2つのコンポーネントの紹介がありました。

  • CMMDS:vSANの内部通信とメタデータ交換用として利用され、6.6からユニキャストに変更されたのがこのCMMDSのようです。またこのCMMDSはESXiホスト間のハートビート交換用途としても利用されるとのことでした。
  • RDT:仮想ディスク(vmdk)をクラスタのESXiホストに分配したり再同期トラフィックも利用するとのことでした。

そしていくつか説明のあったネットワーク構成の考慮事項は…

  • vSAN構成時はESXiホストのF/Wは気にしなくてもよい。
  • IPv4とIPv6の混在はアップグレード時のみサポート。その他は絶対に混在はするな。
  • 仮想スイッチはvDSを推奨。
  • チーミングはvSS/vDS共にRoute Based on IP Hashを推奨。
  • vSANはロードバランシングメカニズムは持っていないため、LAGとLACP構成を推奨
  • 拡張クラスタの場合、witnessはL3レイヤーで構成する。

 

あと面白いチャートを見せてくれました。

拡張クラスタの場合、サイトーサイト間のネットワークレーテンシーが10 msを超えるとIOPSが半分になりました。

 

またパッケとロスが2%発生するとIOPSが半分に、10%だと1/10に落ちてしまうとのことですう。ちゃんとしたネットワークアダプターとスイッチを使いましょう。

 

vSAN Day2 Guidance and Recommendations for Running and Maintaining a vSAN Cluster

vSANクラスタを運用時、推奨する内容を紹介するセッションでした。当たり前なことは何いまさら?と思うかもしれませんが運用し始めると意外と疎かになることがあります。”当たり前なことを当たり前に”ってそれほど重要なことです。

このセッションでは17個の推奨がありました。

  • vSANクラスタの空き容量は常に25%-30%確保すること。
  • スケールアウト、スケールアップが自由なので状況に合わせて構成を変更すること。
  • メンテナンスモードにはNo Data Migrationは避けること。
  • 構成ホスト数はFTTに+1ホストが推奨。
  • 重複排除と圧縮は便利で簡単だが、ドライブ単体では削除できないので注意を。
  • クラスタにエラーがある場合はオブジェクトのとステータスとヘルス状態を確認すること。
  • ネットワークパーティションを確認すること。(正常:1  おかしい:2)
  • ドライバのアップデートはVUMを使うこと。 Baseline作成時は Host Extensionオプション選択する。
  • web Clinetのパフォーマンスモニターをチェックすること。
  • vROpsとvRLも使うと良いぞ~。
  • DCUIにリモートアクセスし再起動状態を確認すること。

  • Health UIでディスクバランス状態を確認すること。
  • VUMでソフトウェアの最善のバージョンかを確認、アップグレードプロセスを確認すること。
  • アップグレードはvCenter→ESXiホスト順にすること。
  • ホストを削除する場合は、メンテナンスモードでデータを全部退避してからディスクグループを削除すること。(ディスクグループのUUIDが残ってしまう可能性があるのでディスクグループを先に削除しないように)
  • vSANクラスタを停止する時は正しい順序で行うこと。

  • すべてのホスト、vCenterは同じDNS、NTPを参照するように設定すること。

 

本当に当たり前のことですが、今一度確認しても良いかもしれません。

 

これで登録したすべてのセッションを聞きました。今年は例年と違い、分かりやすいプロダクトのアップデートが少なかったんですが、PKSやHCXが発表されましたし、VMware on AWSのサービスが開始されるなと新しいVMwareの戦略を確認できた良い機会だったと思います。

 

あ!それから今年のHands-on-LabsはNSXとvSANが人気でしたね。

 

[VMware] VMworld 2017 Europe #4

 

3日目です。

朝9時からGeneral Sessionを含め5つのセッションを聞きました。

 

General Session

昨日と同じくパットCEOが登壇しました。今日はユーザからの質問に答えるとサンジェイ COOとレイ CTOも壇上に。質問と回答を一行でまとめると…

  • AWSとの関係は?今後も強力なパートナーシップを続けていく。(まあ~ VMware on AWSの開始しましたしそうでしょうね。w)
  • 分かりづらいライセンス/パッケージングって何とかならないのか?ライセンスとパッケージングについては簡略化して行く予定。(確かにこれは同意。分かりづらい。そして高い!是非とも簡略化と)
  • HTML5 Clientの完全なバージョンはいつリリース?現在はWeb Clientの機能の90%までカバー。次は100%になる。
  • オープンソースの転換すると意向は?今まで通り今後もオープンソースコミュニティを支援することで貢献したい。

まあ、こんな感じかと。(おそらく… 汗)

 

後半はPKSやVMware Cloud Services、NSX CloudなどをElastic Sky Pizzaという架空の会社を例として紹介しました。

できれば既に公開されている映像を見てほしいです。Elastic Sky Pizzaの例は今後VMware社が進めていくビジョンをよく表現していると思います。長いので26分ごろから見てもよいかと。

 

そう。Elastic Sky Pizzaの話の前に最年少NSX Ninja(!)を紹介する場面がありました。何歳だと思います?

エジプト出身の15歳の少年でした。既にVCIX-NVも取得済みらしいです。w

 

 

vSAN Troubleshooting Deep Dive

vSANがVMwareストレージソリューションとして主役になっているのでこれからもvSANを導入するケースが増えていくと思います。となると当然、トラブルも多くなりそのためのトラブルシューティングも必要不可欠になります。ということで満席でした。w

 

簡単にメモを共有すると、まず大前提として”ハードウェアのコンパチビリティは必ず合わせる”でした。あとは”ストレージポリシーを正しく”というのもありましたね。

次にトラブルシューティングに役に立つツールの紹介です。並べてみると色々ありますね。w

そしてAbsentとDegradedはESXi SCSI Sense Codeを受信したかどうかで判断するとのこと。ですよねー。なのでディスクを引っこ抜いただけだとDegradedになりませんよねー。

ツールを使ったトラブルシューティングについては今度共有しようと思います。

 

VMware Validated Design for Software-Defined Data Center Architecture Deep Dive

自分にはあまり馴染みのない内容でした。VMware Validated Design for SDDCとは言葉の通りVMware社がハードウェアからソフトウェアまで検証し動作を確認した所謂スタンダード仕様です。VMware社は検証をベースにどのバージョンのプロダクトが有効なのかレファレンスガイドまで公開しています。

内容そのものは面白かったですが、スケールが大き過ぎるのかあまり実感は湧きませんでした。果たしてこの規模の構成を導入する顧客がどれほどいるんでしょうね。w

VMware Validated Design for SDDCの最新バージョンは4.1でサポートしているプロダクトは以下のとおりでした。

クラスタのとネットワークの構成についても説明してくれましたがね… ふむ。

正直よく分かりません。

 

vCenter Server Design and Availability

このセッションはvCenterの設計や6.5からサポートするようになりましたVCHAについてでした。

まずEmbedded構成か外部PSC+vCenter構成かはEnhanced Linked Modeを構成する環境なのか確認してから決めるように言われました。要はEmbeddedも本番環境で十分使えるし、余計に外部PSC+vCenter構成にした場合結局PSCとvCenterの可用性を確保するため費用がかかるからとか。

外部PSC+vCenter構成の構成をする場合は、PSCはロードバランサを使う必要があるとのこと。vCenterの場合はVCSAであればVCHAを利用し可用性を確保できますと。合わせるこんな感じになります。

合わせてVCHAが簡単かつ低コストでvCenterの可用性を高められる方法だと強調してました。

VCHAの詳細はこんな感じです。

 

Extreme Performance: vCenter Performance Deep Dive

今日の最後のセッションです。またもや満席でした。まあ、それほどvCenterが重要で問題が起きると色々面倒だからでしょうね。w

まずVCSAがWindowsバージョンvCenterより性能面で上回るベンチマーキング結果を紹介しました。

既にご存知の方も多いと思いますが、vCenterのパフォーマンスが低下は次のような方法で軽減できるとのことです。

クローン作成時はクローンマスターと同じホストではなく別のホスト上にすること、vMotionとプロビジョニングのネットワークアダプタを分けること、CPUやメモリが常に70%を超える場合はリソースを増やすことなどなどでした。

また書き込みが頻繁に起きるDBの場合はSSDドライブを使うことを推奨するし、定期的にリソースや空き容量を確認することもパフォーマンスが落ちる前に対処ができるとのことでした。そしてできればイベント/タスクログ保存世代を減らしてDB用容量が枯渇することを防ごうとも。まあ、当たり前のことを当たり前のよう言ってました。w

以外に問題を引き起こしているプロセスを見つける方法も紹介しましたが、これも少し整理してから今度共有したいと思います。

 

今日はすべてのセッションが終了後”カスタマ感謝パーティー”がありました。このパーティーにはKaiser Chiefsというバンド(有名ですかね?もっと激しい方を聴いているのでよく分かりませんでした)のライブもありました。

案外面白かったんですが、本当にグタグタで3曲ほど聴いてからホテルに戻りました。w

 

あと1日ですね。

 

 

[VMware] VMworld 2017 Europe #3

2日目です。会場の最寄り駅から出てみたら雨でしたね。駅からは数百メートル歩かなきゃ行けなかったので会場について時にはびしょびしょ。朝からテンションだだ下がりでした。(雨に濡れるのが何より嫌いです)

 

とにかく会場についてからはぶつぶつと独り言で文句を言いながらGeneral Session開始を待ちました。今日はリモートミーティングの予定があったので直接会場に入らず、自由にいられるvmvillageの大スクリーンでGeneral Sessionを聞きました。

 

General Session

始まる前から壇上ではチェロやバイオリン奏者の演奏に合わせてVRヘッドセットとコントローラを装着したアーティスト(?)が絵を描くパフォーマンスで会場を盛り上げてました。

※ちょっとした動画も撮りましたがwordpressでどうやって動画が追加できるのか分かりませんー

 

EMEAのVPが挨拶後、パットCEOが登場しました。過去のITに比べ巨大かつ急速に発展している現在のIT、そして未来のITをどう向かうべきか、そしてVMwareはその流れに乗るべき戦略をプレゼンしたと思います。そしてIBMとの提携のHCXソリューション(オンプレミスとクラウドをシームレスにつなぐと)を紹介したり、Sanjay COOとEMEA顧客のお偉いさんがちょっとしたパネルディスカッションもやってました。

リモートミーティング中だったため、あまりメモったりできず詳細な内容は覚えてません。というかあれですね。英語がそこまで到達してませんというべきですね。汗

ただGeneral Sessionの中で印象的なのはパットCEOの”過去のScience FictionはScience Factになりつつある”という言葉でした。SFでしか出てこなさそうなものがどんどん現実になっている… 確かにそうでした。

 

もうひとつはVRを利用したデモでした。これはUSでも話題になったかと思います。パットCEOがVRヘッドセットとコントローラを装着するとスクリーンには仮想データセンタが登場。コントローラを使って仮想データセンタのESXiホスト上の仮想マシンをゴミ箱に捨てると仮想マシンが削除され、雲の中のAWSへ仮想マシンを投げるとそのままAWSにマイグレーションされました。またVMware on AWSのElastic DRSを利用し簡単にクラスタのリソースを追加するなと、まあ~まだScience Factになるには無理がありそうですがかなり印象的なパフォーマンスでした。

 

General Sessionが終わり、登録したセッションが始まるまで時間があったのでvSAN Specialist試験も受けました。VMworld期間中は50%の価格だったので…結果はと言いますと

運良くパスしました。w

 

vSphere Clients Roadmap: HTML5 Client, Host Client, and Web Client

ロードマップという文句にまた騙されました。w ただのWeb Clientがどういう進化をし改善されたかという内容が半分でしたかね。セッション後半はHTML5 Client(セッションではもうはやvSphere Clientと言ってました)についての内容でした。特に新しい内容はなく、”Flingsから短い間隔で頻繁に改善されたバージョンが公開されているし皆さんのフィードバックが大事っす!”みたいな要望を繰り返し言ってましたね。下図はHTML5 Clientの機能対応情報を表したスライドです。

 

Migrate to the vCenter Server Appliance You Should

以前に紹介したとおりWindows版vCenterは次期メジャーバージョンより”非推奨”になり、その次のバージョンからはサポートしなくなります。

よって必然的にVCSAへの移行になりますが、このセッションはVCSAへの移行時の考慮点について紹介でした。

移行のステップとしてはまずMigration Assistantを使って事前チェックを行い、Migration Toolによる移行を推奨してました。合わせて次のような移行の制限事項の話もありました。

  • 同一バージョンのWindows版vCenterからのVCSAへの移行はダメ
  • 複数のvCenterを一つのVCSAに移行することもダメ
  • トポロジーを変更することもダメ (例 PSC+vCenter をEmbedded VCSAにとか)

それ以外にvCenter、ESXiホスト、vCenterプラグインやソリューション、仮想マシンについての考慮事項の紹介もありましたが、この紹介は今度にしようと思います。

 

VMware Cloud on AWS Hybrid Cloud Architectual Deep Dive:Networking and Storage Best Practices

VMware Cloud on AWS 関連では初めてのセッションです。そもそもAWSを触ったことがないのでセッション内容の半分は???でした。汗 ただvSphere特にvSAN関連の情報が得られて良かったです。

上図のようにVMware Cloud on AWSはvSANを提供しますがESXiのブートデバイスはAWSのEBS(Elastic Block Store)を使い、ストレージ領域としてはNVMeのInstance Storeを利用し提供するとのことでした。合わせて VMware Cloud on AWSはvSAN以外にS3も利用ができ、主にファイルサービスやデータプロテクション、そしてビックデータ解析での利用がオススメのようです。

あとは… ネットワークの話もありましたが、ネットワークに弱いもんで流し聞きでしたね。汗

 

It’s the Apps: Fully Loaded Application Monitoring with vRealize Operations

今日の最後のセッションでした。仕事上vROpsを導入する場合がしばしば(vSOMのお陰)ありますが、実際に導入後まともに活用されてないのが実情でした。利用していてもインフラのモニタリングぐらいですかね。vROpsもSCOMやその他のモニタリングツールと同様カスタマイズすると強力な管理ツールになるんですけどね。プレゼンターも同じ考えのようで”もっとvROpsを使おうぜ!”、”vROpsでアプリケーションもモニタリングしようぜ!”がこのセッションのテーマです。w

vROpsによるアプリケーションモニタリングのメリットはもちろんパフォーマンス低下などの問題が発生した場合の迅速な原因追求とトラブルシューティング、何よりインフラ管理者の潔白を証明できるとのこと。そうですね。インフラ管理者あるあるですかね。アプリケーションのパフォーマンスが落ちると十中八九、仮想マシンやらストレージやらに原因があるんじゃん?って疑われますからね。w

とにかく”vROpsでアプリケーションのモニタリングを!”と言いながらVMware社環境のvROpsをデモとして見せてくれました。

綺麗じゃありません?こんなにダッシュボードを作れたら…  で肝心などういう風にアプリケーションをモニタリングするのかは教えてくれませんでした。┐(´ー`)┌

 

今日のセッションが全て終わってソリューションエクスチェンジを覗いてみたら飲んで騒いでましたね。

 

私は疲れてそのままホテルに戻りました。1日中セッションを聞いてたらソリューションエクスチェンジを回るのも面倒でしたから…