**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

vMotionできない、、、そんな時。      （その①）

vMotionできない、、、そんな時。      （その②）

本記事では前回記事で説明した対処法の一つである、

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動（ダウンタイム数分～数十分

について説明します。

実施方法

※下記手順では仮想マシンの停止～起動を繰り返していますが、必ず1 VM ずつ実施してください。

本手順では仮想マシンを順々に移動していきますが、VMの種別として、以下の順番で実施します。

１．GuestOSから安全にShutdownできるVM

２．VCSA/PSC

３．GuestOSから安全にShutdownできないVM

• 安全にShutdownできないVMとはGuestOS側からShutdownする手順が存在しないVMのことです。
• VxRail環境ではVMware Log InsightがデフォルトではGuestOS側からShutdownする方法がなく、安全にShutdownできないVMに相当します。

対象ESXi上の安全にShutdownできるVMの移動方法

1. 仮想マシンのダウンタイムの調整が完了したら、対象ESXi上の仮想マシンの一つGuestOS側からShutdownしてください。
   • 具体的なShutdown手順や対象の仮想マシンを管理している担当者もしくは構築ベンダやOSベンダにご相談ください。
2. Shutdownできたことを確認する
   • Ping疎通などで確実にOSが落ちたことを確認してください。
   • 対象ESXiにてコマンドが発行できる場合はlocalcli vm process listコマンドから対象VMがいないことを確認してください。
   • なお、OSレベルでのShutdownが完了したのちであっても、下図のようにGUI上ではDisconnect（または切断状態）のままであり、対象VMについて操作はできません。（※下図はVxRail Manager VMをShutdownした後です。）
3. Shutdownした仮想マシンを起動するESXiのHost Clientを起動する（WebClientではない）
4. HostClientから仮想マシンの登録ウィザードを起動する
5. 既存の仮想マシンの登録を選ぶ
6. データストアから対象のVMを探す
7. データストアから対象のVMを探す
8. 対象の仮想マシンが選択されていることを確認して次の手順に進み、登録を完了させる
9. 登録が完了するとWebClientで切断状態（またはdisconnected）ではなくなる
10. 手動で別のESXiに移動した場合、ネットワークアダプタに接続できなくなるため、WebClientからネットワークアダプタをいったん別のポートグループに変更した後、再度元のポートグループに戻す。
11. ネットワークアダプタのポートグループ設定を変更→戻しを実施したのちにVMを起動する。
12. 起動時に質問への回答を選択する
13. 移動しました、を選択してOKをおすとVMが起動する
14. 仮想マシンの移動と起動が完了したので、GuestOSレベルでの動作を確認する。
15. 同様の作業を対象ESXi上の安全にShutdownできるすべてのVMで実施する。※ただしVCSA/PSCでは実施しない。
16. 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート（VxRailの場合はDell EMC）の指示通りにESXiを再起動し、作業後にヘルスチェックを実施してください

対象ESXi上のVCSA/PSCがある場合の移動方法

1. 安全にShutdownできるVMがすべて移動済みであることを確認する。
2. WebClientにて分散スイッチの新規ポート作成ウィザードを起動する
1. 適当に名前をつける

対象ESXi上の安全にShutdownできないVMの移動方法

1. 本手順の実施をする前に対象ESXi上には、安全にShutdownできないVMしかいないことを確認してください
   • 安全にShutdownできないVMとはGuestOS側からShutdownする手順が存在しないVMのことです。
   • VxRail環境ではVMware Log InsightがデフォルトではGuestOS側からShutdownする方法がなく、安全にShutdownできないVMに相当します。
2. 正常にShutdownできない場合はESXiごと落とすか個別にKillするしかありません。本手順で想定している状況ではESXiへSSHでログインすらできない場合もあり、その場合は個別のKillは実施できず、ESXiごと落とす手順になります。
3. 強制的にVMを落とす手順は、PCの電源を引っこ抜く行為に等しくファイルシステムが破損するリスクがあります。仮想マシン上で稼働するOSベンダやアプリケーションベンダに相談し、少しでも安全に落とせるような状況で実施してください。
4. 実際の移行手順としてはvSphere HAによる移行が一番簡単ですので、BMCやiDRACのハードウェア管理インターフェースからESXiをShutdownするような手順になりますが、実施する前にかならずvSphere Web ClientからvSANヘルスチェックを実施して、冗長性の低下したデータがないことを確認してください。
   • 確認方法は下記の前回記事の補足項目を参照してください。
   • vMotionできない、、、そんな時。      （その②）
5. データ冗長性に問題ないことが確認できたら対象ESXiを強制的にShutdownし、PonwerOnしてください。
6. vSphere HAが有効な場合は自動的にほかのESXi上で再起動されます。
7. 設定や条件などによってほかのESXi上で再起動されなかったVMはESXiの起動後に手動で起動するか、ほかのESXiの仮想マシンを再登録して起動してください。
8. 起動後、正常性を確認してください。
9. ESXiの再起動が完了したらvCenterから正しく認識されている（応答なし状態ではない）ことをvSphere Web Clientから確認し、Shutdownした仮想マシンを起動してください。
10. 最後にvSANヘルスチェックとVxRail ManagerのDiagnostic（VxRailの場合）を実施して健全性を確認してください。

• こちらのヘルスチェック手順をご参考にしてください
• エラーや警告があった場合はサポートにご連絡ください。

この方法のメリット・デメリット

メリット

• ダウンタイムを短くできる。
• VMの移動を複数回に分けて実行できる
• 万が一ESXiが起動してこなくても安全

デメリット

• 手順が複雑

この方法の使いどころ

以下の場合にお勧めです。

• ダウンタイムを少しでも短くしたい
• 長時間のメンテナンスウインドウを確保できない
• VMによってメンテナンスウィンドウの時間が異なる

今回は非常にボリュームの大きい内容となっていましましたが、手間をかけてのダウンタイムを短くしたい場合などに有効な方法を紹介しました。

次回は、

仮想マシンを強制的にPowerOff（Kill）し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分

について説明します。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

前回よりだいぶ時間が空いてしまいましたが、本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

vMotionできない、、、そんな時。      （その①）

vMotionできない、、、そんな時。      （その②）

vMotionできない、、、そんな時。      （その③）

本記事では前回記事で説明した対処法である以下について説明します。

③ 仮想マシンを強制的にPowerOff（Kill）し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）

④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）

予告では③のみでしたが、似たような話なのでまとめることにしました。

今回の手順は基本的には前回記事の最後の手順（対象ESXi上の安全にShutdownできないVMの移動方法）と同様です。

本手順は稼働中のVMを強制的に落とす手順のためデータの破損が発生する可能性があります。したがって以下の注意事項があります。

基本的な注意事項は以下です。

・安全にシャットダウンできないVMに対して実施する。シャットダウンできる場合は前回記事に沿った対応をする

・実施する前に必ずデータの冗長性低下が起こっていないことを確認する。

・大事なデータは必ずバックアップをする

実施方法

事前の確認

1. vSphere Web ClientからvSANヘルスチェックを実施して、冗長性の低下したデータがないことを確認する
   • 確認方法は下記の前回記事の補足項目を参照してください。
   • vMotionできない、、、そんな時。      （その②）
2. 対象VMのデータのバックアップおよびDiskにコミット済みであることを確認する
   • 可能であればアプリケーションレベル・仮想マシンレベルのバックアップを取得する
   • 簡易的にスナップショットの取得でも可
   • 可能であれば仮想マシン負荷の低い時間帯を狙って実施する
   • 未コミットのデータを可能な限りDiskにコミットする（Linuxのsyncコマンドなど）
3. 対象VMにVCSA/PSCが含まれる場合は事前にEphemeral Portを作成する
   • 手順については前回記事の 「対象ESXi上のVCSA/PSCがある場合の移動方法」を参照ください

ESXiごとShutdownする手順

事前の準備・確認が完了したらいよいよ仮想マシンを強制的に落とします。

一番簡単な方法はホストであるESXiごと落としてしまうことです。

手順については前回記事の「対象ESXi上の安全にShutdownできないVMの移動方法」を参考にしてください。

全仮想マシンがすべて停止し、vSphere HAが有効な場合は別のESXiホストでVMが再起動します。

vSphere HAが無効な場合は対象ESXiホストの再起動が完了したのちに、手動で起動してください。

vSphere HAが有効なのに仮想マシンが再起動されなかった場合は以下の理由が考えられます。

• アフィニティルールによる稼働可能なESXiホストの制限
• アドミッションコントロールによる制限
• 古いESXiがLockを保持したままになっている場合
  • 参考：ネットワールド　らぼ: VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

各仮想マシンを個別に停止する方法

状況によっては各VMを一つずつ停止したい場合もあると思います。その場合は対象ESXiホストにSSHかESXi Shellでログインし、Killを実施する必要があります。

仮想マシンの個別のKillについては以下が参考になります。

• VMware KB https://kb.vmware.com/s/article/1014165?lang=ja
• ネットワールド　らぼ: VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

killした後の挙動については状況に依存します。状況によっては障害によってすでにバックグラウンドでHAジョブが開始されており、仮想マシンファイルのロック取得待ちとなっている場合があります。この場合は仮想マシンが停止するとHAジョブにより別のホストで再起動されます。

状況によってはHAジョブが開始されていない場合もありますので、その場合は手動にて他のHostに再登録および起動とネットワークアダプタの再設定を実施する必要があります。

手順については前回記事の「対象ESXi上の安全にShutdownできるVMの移動方法」のステップ2以降をご参照ください。

いかがでしたでしょうか。一応今回でこのシリーズは終了となります。

仮想化技術の発展によってサーバの可用性と可搬性が向上し、多くのメリットを享受できるようになりましたが、一方で今回の一連の記事で想定している障害のように、ハイパーバイザーに起因する不具合によって、物理サーバにはなかったダウンタイムが発生してしまう場合もあります。

しかしながら物理サーバ時代の不便さと比べれば、仮想化のメリットは非常に大きく、管理負荷低減やサービスレベルの向上が実現されていることも事実とおもいます。

hostdの不具合によるvMotion不可という事象は、仮想化基盤の管理者であれば一度は経験し、かつお客様にとっては対処に困る障害対応と思います。

本不具合だけで仮想化技術を嫌いにならず、長く付き合っていただければと思います。

もしhostd不具合などでvMotion不可となる事象が発生した際は、本記事によってお客様のストレス軽減や業務影響の低減に寄与できれば幸いです。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

アラーム定義情報を一括で取得したい！

VxRailのログを見ていると、ときどき突如としてalarm-xx が現れることがあります。

alam-xxはvCenterで定義されている個々のアラームに対応するMoref IDなので、当然ながらそれに対応するアラーム定義があるのですが、残念ながらMoref IDは環境によって異なりますし、（あるかもしれませんが）ID採番のRuleなどもなさそうなのでMorefIDだけからアラームの詳細を予測することができません。

そのため、何かが起きていることはわかるのですが、「何が起きているの！！？？」とちょっとドキドキしてしまいます。

そういう時、「全部のAlarmのMorefIDと対応する情報が一括で取得できたらいいのに・・・」と常々思っていました。

また、運用管理者の観点からも現在のシステムに定義されているアラームの一覧やダンプを取得したい！ということはあるかと思います。

しかしながら、WebClientや標準のコマンドとしてアラーム定義の細かい情報を一括でExportしたりする方法は見当たりませんでした。

アラーム名と定義場所は出せるかも知れませんが細かいトリガーやアクションの情報となるとWebClientから一つ一つコピー＆ペーストするような作業になってしまうのでとてもやる気になりません。

ということで、今回はvSphere SDK for pythonを利用して、VCSA CLI上で一括でアラーム定義情報をDumpスクリプトを作成しましたので、使用方法と合わせて共有させていただきます。

開発・検証環境

今回のスクリプトは以下の環境で動作検証をしました。

多少Versionが違っても動くとは思います。

もし動かなかったらコメント等で教えていただければ、時間があるときに修正します。

もちろんご自由にスクリプトを書き換えていただいてもかまいません。

VxRail™ Appliance 4.5.229

VMware vCenter Server Virtual Appliance (vCSA) 6.5 U2c GA build 9451637

VMware ESXi 6.5 Express Patch 11 GA build 10719125

使用方法

いざ、スクリプトファイルと添付して使用方法を書くぞ！、、、と思った段階で初めて気づきましたが、このブログはファイルの添付ができないんですね。。。仕方ないのでソースを直に書きます。

HTMLによる不必要な改行の挿入などによるコード破壊を防ぐため、あえてフォーマットを無効にしています。

少し見栄えが悪いですがご容赦ください。

pythonは文法上、改行やインデントにシビアなのでコピペする際にご留意ください。不必要な空行や、スペースが一つ挿入されただけでも動かなくなります。

#####   ここから ######   # coding:utf-8 #!/usr/bin/env python  from __future__ import print_function from __future__ import unicode_literals import os import codecs import subprocess import re import string import json import ssl import sys import traceback import atexit import platform import time import datetime import socket import getpass import argparse  sys.path.append("/usr/lib/vmware/site-packages/")  from pyVmomi import vim, vmodl from pyVim import connect from pyVim.connect import SmartConnect, Disconnect from pyVim.task import WaitForTask   def parse_argument():     parser = argparse.ArgumentParser(description='Print All Alarm Definition')     parser.add_argument('-s', '--server', dest="server", required=True, help='vCenter IP Address')     parser.add_argument('-u', '--username', dest="username", required=True, help='vCenter SSO admin username')     parser.add_argument('-p', '--password', dest="password", required=True, help='vCenter SSO admin password')     args = parser.parse_args()     return args    def main():     args = parse_argument()     vcipaddr = args.server     vcusername = args.username     vcpassword = args.password     context = None     context = ssl.create_default_context()     context.check_hostname = False     context.verify_mode = ssl.CERT_NONE     si = connect.Connect(host = vcipaddr,user = vcusername,pwd = vcpassword)     atexit.register(Disconnect, si)          alarms = si.content.rootFolder.declaredAlarmState     for alarm in alarms:         print(alarm.alarm.info)  if __name__ == '__main__':     main()    #####  ここまで  #######  

↑上記の内容をVCSAの適当な場所にdump_AlarmDefinition.pyとして保存してください。

保存したら以下のSyntaxで実行してみてください。

root@vc [ ~ ]# python dump_AlarmDefinition.py -s <vcenter ip> -u <vcenter sso user> -p '<vcenter sso user password>'

パスワードに特殊文字が含まれる場合は、シングルクォーテーションで括ってください。

例は以下です。

※例にあるパスワードはVMware HOLで用いられるものを仮で使用しており、その他の意味はありません。

実行例：

root@vc [ ~ ]# python dump_AlarmDefinition.py -s localhost -u administrator@vsphere.local -p 'VMware1!'

サンプル出力：

root@vc [ ~ ]# python dump_AlarmDefinition.py -s localhost -u administrator@vsphere.local -p 'VMware1!'

(vim.alarm.AlarmInfo) {

   dynamicType = <unset>,

   dynamicProperty = (vmodl.DynamicProperty) [],

   name = 'Host Requires Encryption Mode Enabled Alarm',

   systemName = 'alarm.HostRequiresEncryptionModeEnabledAlarm',

   description = 'Alarm to indicate that the host requires encryption mode enabled.',

   enabled = true,

   expression = (vim.alarm.OrAlarmExpression) {

      dynamicType = <unset>,

      dynamicProperty = (vmodl.DynamicProperty) [],

      expression = (vim.alarm.AlarmExpression) [

         (vim.alarm.EventAlarmExpression) {

            dynamicType = <unset>,

            dynamicProperty = (vmodl.DynamicProperty) [],

            comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

            eventType = vim.event.EventEx,

            eventTypeId = 'com.vmware.vc.host.Crypto.ReqEnable.KeyMissingOnKMS',

            objectType = vim.HostSystem,

            status = 'red'

         },

         (vim.alarm.EventAlarmExpression) {

            dynamicType = <unset>,

            dynamicProperty = (vmodl.DynamicProperty) [],

            comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

            eventType = vim.event.EventEx,

            eventTypeId = 'com.vmware.vc.host.Crypto.ReqEnable.KMSClusterError',

            objectType = vim.HostSystem,

            status = 'red'

         },

         (vim.alarm.EventAlarmExpression) {

            dynamicType = <unset>,

            dynamicProperty = (vmodl.DynamicProperty) [],

            comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

            eventType = vim.event.EventEx,

            eventTypeId = 'com.vmware.vc.crypto.HostKeyUpdatedEvent',

            objectType = vim.HostSystem,

            status = 'green'

         },

         (vim.alarm.EventAlarmExpression) {

            dynamicType = <unset>,

            dynamicProperty = (vmodl.DynamicProperty) [],

            comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

            eventType = vim.event.EventEx,

            eventTypeId = 'com.vmware.vc.host.Crypto.Enabled',

            objectType = vim.HostSystem,

            status = 'green'

         }

      ]

   },

   action = <unset>,

   actionFrequency = 0,

   setting = (vim.alarm.AlarmSetting) {

      dynamicType = <unset>,

      dynamicProperty = (vmodl.DynamicProperty) [],

      toleranceRange = 0,

      reportingFrequency = 300

   },

   alarmMetadata = <unset>,

   key = 'alarm-1',

   alarm = 'vim.alarm.Alarm:alarm-1',

   entity = 'vim.Folder:group-d1',

   lastModifiedTime = 2018-12-01T17:27:21.718Z,

   lastModifiedUser = '',

   creationEventId = 0

}

 

........... 以降、全アラーム情報がDumpされる

問題なく情報をダンプすることができました。

出力がかなり長くなりますのでリダイレクトなどしてファイルにいったんファイルに出力するのがお勧めです。

アラーム定義のオブジェクト情報がそのまま表示されているので見にくいですが、アラーム定義の情報をすべて網羅しているのでテキスト処理などで必要な部分のみを抽出したりできますし、またソースを変更して、名前とトリガーとアクション情報のみを抽出することも可能です。

例えばスクリプト中の

print(alarm.alarm.info)

の部分を

print(alarm.alarm.info.name)

print(alarm.alarm.info.expression)

print(alarm.alarm.info.action)

とすれば、アラーム定義の名前とトリガー＆アクション部分のみを抽出できます。

※pythonなのでインデントや改行には注意してください。↑はHTMLのフォーマットを無効にしていません

いかがでしたでしょうか？実際に業務で使える情報抽出まではあと一段階の処理が必要となるとおもいますが、

テキスト処理やpythonであればいくらでも有識者はいますので、このDump情報があれば環境に合わせて自由に必要な情報を抽出・成形できると思います。

この記事の内容がお役に立てれば幸いです。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

本記事では、vCenterにデフォルトで定義されている、Host CPU/Memoryの使用率のアラーム定義のオススメについて御紹介いたします。

vSphere 環境のデフォルトアラーム定義と自動通報

vSphere環境を構築すると、デフォルトで多くのアラームが定義されていて、条件を満たすとWebClientGUI上に警告やエラーが表示されます。

Dell EMCの提供するVxRailの場合でもデフォルトで定義されているアラームは同様です。（Versionによっては追加でVxRail固有のアラームも定義されています。）

別途SMTPやSNMPを設定していると、発生したアラームを通知することもできますが、VxRailの場合はESRSを連携することで、発生したアラームの種別やタイミングによって、Dell EMC側に自動通報し、障害を迅速に解決することが可能です。

自動通報は障害を正しく通知できれば非常に便利なのですが、対応不要なケースも多くみられます。

その筆頭となるのが冒頭に書いたHost（ESXi）のCPU/Memory使用率のアラームです。

Host CPU/Memoryのアラームはデフォルトで、以下の設定になっています。

ー CPU 使用率 90％以上が5分継続で発報

ー Memory 使用率95％以上が5分継続で発報

※CPU 使用率アラームの設定

※メモリ使用率アラームの設定

※上記の条件を満たしたときに、必ず自動通報されSRが自動作成されることは保証されていないのでご留意ください。自動通報はあくまでもベストエフォート型のサービスです。

デフォルト設定による誤検知！？

サポートの仕事をしていると月に何件も（場合によっては何十件も！）Host CPU/Memory使用率の対応をすることがありますが、実際にCPU/Memoryの使用率のアラームを受信したあとに、対象筐体をESRS経由で確認するとすでに対応不要となっているケースが非常に多いです。

というのも、DRSが有効な環境では自動vMotionによって、負荷がほかのHostに分散されるためです。

何事もなく対応不要で終われればメデタシメデタシなのですが、お客様にはご連絡をしなくてはいけません。

多くの場合は、Windows Updateのタイミングであったり、週次・日次バックアップといった予想された負荷が原因なのですが、お客様も連絡を受けたら確認せざるをえず、問題ないのにもかかわらず確認の手間が発生してしまいます。

カスタマイズ設定によるお客様管理負荷削減

障害でなく問題のない通知で毎日のように連絡を受けるのは（手間だから）避けたい、と考えるお客様は多くいらっしゃると思います。

対象のアラームを無効にしてしまえば、このアラームによる不要な対応からは解放されますが、さすがに無効化は気が引けるという方も多いと思います。

そういった場合には設定値の変更（閾値の緩和）がお勧めです。

前半で述べたように、デフォルトでは高使用率状態が5分以上継続すると発報されますが、私の所感として、5分でアラートが上がってしまうのは少し短すぎると思います。

というもの、DRSが有効な環境であれば負荷の偏りに応じて自動でvMotionをしてくれるのですが、

DRSが稼働するインターバルはデフォルトで5分に設定されているため、DRSによる分散がなされる前にアラームが発報される可能性があるからです。

そこで、以下のように閾値の時間を延ばすことで不要な通知を抑制可能です。(vSphere 6.0/VxRail 4.0.xの場合)

※クリックすると拡大できます。

Host and cluster ViewでvCenerのインベントリを選んでいることに注意してください。（画面左上の赤線）

ClusterやHostを選択している状態では対象のアラームを変更することはできません。

残りの部分については赤線で強調した部分を追っていただければ設定できるかと思います。

vSphere 6.5(VxRail 4.5.x)の場合は若干配置が異なります。

Alarm Definitionsを選択したのちの操作は同じです。

変更後の設定時間についてはお客様次第ではありますが、vMotionの時間も考えると15分くらいがよいのではないかと思います。

もし、経験則等でお勧めの設定をお持ちの方は教えていただけると幸いです。

いかがでしたでしょうか？

今回はアラーム定義の変更による管理負荷軽減策として、Host CPU/Memory使用率アラームの変更をご紹介しました。

その他環境によっては問題ないにもかかわらず、ちょくちょくアラームが発報されてしまうようなケースもあるかと思います。

その場合も同様に、閾値設定を見直すことで、誤検知率が減り、余剰の時間を別の作業に当てることができるようになれば幸いです。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

RVC（vSphere Ruby Console）とはVCSAに標準で搭載されているCLIベースの管理ツールのことです。

「RVCってvSANを管理するときに使うものでしょう？」

と思われている方も多いとは思いますが、それだけではありません。

RVCを活用するとvSphere Web Clientにログインすることなく、VCSAのCLIからアラートや構成情報を取得することができます。

RVCの使い方

RVCはVCSAだけでなくWindows版のvCenterでも利用可能ですが、本記事ではVCSAのみにフォーカスします。

RVCのログイン方法

1. SSHでVCSAにログイン
2. 以下のコマンドを実行
   • # rvc administrator@vsphere.local@localhost
3. パスワードを求められるので入力する
4. RVCが起動してコマンドが発行できる状態になる。

vSphere Clusterの情報とアラームを確認

RVCでできることは多いですが、ここではvSphere Clusterの確認手順を示します。

1. RVCにログインする
2. 以下のようにコマンドを順番に実行して対象のClusterのパスに移動する
   1. > cd /localhost
   2. > ls
      • DataCenterが表示されるのでDataCenterへ移動する。
   3. > cd <datacenter name>/
      • パスについてはタブ補完が可能です。
   4. > cd computers/
   5. > ls
      • 以下のようにClusterのパスを確認することができます。
      • 異常が発生している場合は表示に色がつく仕様になっています。
      • 正常な場合
      • 異常な場合（赤く色が付き、CPUとメモリの表示もおかしい）
3. 対象のClusterのパスまで移動したら以下のコマンドでクラスタの情報を入手する
   • > show <Cluster name>
4. また以下のコマンドで発生しているアラームや設定問題を確認できる
   • > alarms <Cluster name>
   • > issues <Cluster name>

同様にして、ESXi hostやVMについても情報を入手したり、発生しているアラームや設定問題を確認することが可能です。

今回はRVCの使用方法の例として、アラームなどの情報確認方法を紹介しました。

次回は、上記活用のタイミングやサポート向けの情報取得スクリプトを紹介します。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

vSphereのサポートをしていると、お客様によってはお問い合わせ時の情報が不十分で初動が遅れてしまうことが多々あります。

例えばよくある例として、

お客様：「エラーを検知しました」

サポート：「（エラーメッセージが知りたい。。。）」

お客様：「エラーの画面キャプチャ（WebClient）を取得しました」

サポート：「（肝心な部分が切れていて写ってない。。。）」

お客様：「エラーメッセージはこれです。」

サポート：「（できれば英語でほしかった。。。）」

といった感じで、事象を特定するまでに何度かやり取りが発生し、時間がかかってしまうことがあります。

※英語が好まれるのはEscalationや検索の都合によるもの。

vSphere WebClientでは、エラーメッセージのテキストをクリップボードにコピーすることが出来ないため、想像以上に多くのお客様が画面キャプチャを取る、という方法を選びます。

実際には、下図のようにエラーメッセージをコピーすることは可能なのですが、対象のインベントリのMonitor -> All Issueへ移動しなくてはならず、しかもエラーの発生するインベントリは毎回同じではないため、vSphere操作に不慣れなお客様には少々難度が高いです。

そこで前回記事で紹介したRVCを利用したアラーム情報取得スクリプトを考えてみました。

↓↓↓

#!/usr/bin/bash

 

function retrieveObjInfo() {

  echo ""

  echo "==================================="

  echo $1

  echo "==================================="

  x=\'$1\'

  echo "--------- Alarms of $x ---------------"

  echo $PASS | rvc -c "alarms localhost/$i$2$x" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

  echo "--------- Config Issue of $x -----------"

  echo $PASS | rvc -c "issues localhost/$i$2$x" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

}

 

 

IFS=$'\n'

echo "vCenter SSO user is administrator@vsphere.local"

read -sp "vCenter SSO Password: " PASS

echo ""

for i in $(echo $PASS | rvc -c "ls localhost" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep datacenter | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

do

  CLUSTER=""

  echo "Detected Cluster list of DataCenter $i"

  echo "---------------------"

  echo $PASS | rvc -c "ls localhost/$i/computers" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep cluster | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"

  echo "ALL"

  echo "NONE"

  echo "---------------------"

  echo ""

  read -p "Selected Cluster Name (Default:ALL) > " CLUSTER

  if [ "$CLUSTER" = "" ]

  then

    CLUSTER="ALL"

  fi

  for j in $(echo $PASS | rvc -c "ls localhost/$i/computers" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep cluster | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

  do

    if [ "$CLUSTER" != "ALL" -a "$CLUSTER" != "$j" ]

    then

      break

    fi

    retrieveObjInfo $j "/computers/"

    for k in $(echo $PASS | rvc -c "ls localhost/$i/computers/$j/hosts" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | grep host | grep -v localhost | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

    do

      retrieveObjInfo $k "/computers/$j/hosts/"

      for n in $(echo $PASS | rvc -c "ls localhost/$i/computers/$j/hosts/$k/vms" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2- | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | cut -d ":" -f 1 );

      do

        retrieveObjInfo $n "/computers/$j/hosts/$k/vms/"

      done

    done

  done

  for l in $(echo $PASS | rvc -c "ls localhost/$i/datastores" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | cut -d ":" -f 1);

  do

    retrieveObjInfo $l "/datastores/"

  done

  for m in $(echo $PASS | rvc -c "ls localhost/$i/networks" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2- | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | sed -r "s/\ \(vds\)//g" | cut -d ":" -f 1 );

  do

    echo ""

    echo $m

    m=\'$m\'

    echo "--------- Alarms of $x ---------------"

    echo $PASS | rvc -c "alarms localhost/$i/networks/$m" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

    echo "--------- Config Issue of $x -----------"

    echo $PASS | rvc -c "issues localhost/$i/networks/$m" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

  done

done

unset IFS

 

コチラのスクリプトはVCSA上で実行することを想定しています。

実行すると、与えられたSSO認証情報を用いてRVC経由でvCenter配下のCluster、ESXi、VM、DataStore、分散仮想スイッチのインベントリで出ているアラート情報をすべて取得してきます。

使い方は簡単です。

１．VCSAにSSHでログイン

２．適当な名前でファイルを作成（例：alarmRetrieve.sh）

３．vi で編集して上記スクリプトを書き込んでSave（※コミュニティからコピーするとHTMLの都合上で余計な改行が入りますが、シェルスクリプトは問題なく動作します。）

４．chmod 777 で実行権限を追加（例: chmod 777 alarmRetrieve.sh）

５．スクリプトを実行（例：./alarmRetrieve.sh）

すべてのインベントリのアラーム情報を取得するため、VM数やNode数が多いと時間がかかりますが、漏れなくすべてのアラームを、英語の原文で取得できます。

アラームの発報時刻がわからないのが非常に残念ですが、vSphereに不慣れなオペレータでも、スクリプトを実行するだけでアラーム情報を入手してサポートに問い合わせることが出来ます。

このスクリプトで入手できるアラート情報があれば、だいたいの場合においてサポートエンジニアにてある程度の業務影響が想定でき、またログ取得対象を絞り込めるため、調査開始の初動がスムーズになります。

アラーム情報だけでなくそれぞれのインベントリの基本情報も合わせて取得する必要がある場合を想定して、上記を少しだけ改良した以下のスクリプトも作成しました。

#!/usr/bin/bash

 

function retrieveObjInfo() {

  echo ""

  echo "==================================="

  echo $1

  echo "==================================="

  x=\'$1\'

  echo "--------- Summary of $x --------------"

  echo $PASS | rvc -c "show localhost/$i$2$x" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

  echo "--------- Alarms of $x ---------------"

  echo $PASS | rvc -c "alarms localhost/$i$2$x" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

  echo "--------- Config Issue of $x -----------"

  echo $PASS | rvc -c "issues localhost/$i$2$x" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

}

 

 

IFS=$'\n'

echo "vCenter SSO user is administrator@vsphere.local"

read -sp "vCenter SSO Password: " PASS

echo ""

for i in $(echo $PASS | rvc -c "ls localhost" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep datacenter | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

do

  CLUSTER=""

  echo "Detected Cluster list of DataCenter $i"

  echo "---------------------"

  echo $PASS | rvc -c "ls localhost/$i/computers" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep cluster | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"

  echo "ALL"

  echo "NONE"

  echo "---------------------"

  echo ""

  read -p "Selected Cluster Name (Default:ALL) > " CLUSTER

  if [ "$CLUSTER" = "" ]

  then

    CLUSTER="ALL"

  fi

  for j in $(echo $PASS | rvc -c "ls localhost/$i/computers" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | grep cluster | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

  do

    if [ "$CLUSTER" != "ALL" -a "$CLUSTER" != "$j" ]

    then

      break

    fi

    retrieveObjInfo $j "/computers/"

    for k in $(echo $PASS | rvc -c "ls localhost/$i/computers/$j/hosts" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | grep host | grep -v localhost | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g");

    do

      retrieveObjInfo $k "/computers/$j/hosts/"

      for n in $(echo $PASS | rvc -c "ls localhost/$i/computers/$j/hosts/$k/vms" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2- | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | cut -d ":" -f 1 );

      do

        retrieveObjInfo $n "/computers/$j/hosts/$k/vms/"

      done

    done

  done

  for l in $(echo $PASS | rvc -c "ls localhost/$i/datastores" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | cut -d ":" -f 1);

  do

    retrieveObjInfo $l "/datastores/"

  done

  for m in $(echo $PASS | rvc -c "ls localhost/$i/networks" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4 | cut -d " " -f 2- | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | sed -r "s/\ \(vds\)//g" | cut -d ":" -f 1 );

  do

    echo ""

    echo $m

    m=\'$m\'

    echo "--------- Summary of $x --------------"

    echo $PASS | rvc -c "vds.show_running_config localhost/$i/networks/$m" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

    echo "--------- Alarms of $x ---------------"

    echo $PASS | rvc -c "alarms localhost/$i/networks/$m" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

    echo "--------- Config Issue of $x -----------"

    echo $PASS | rvc -c "issues localhost/$i/networks/$m" -c "quit" 'administrator@vsphere.local@localhost' 2> /dev/null | tail -n +4

  done

done

unset IFS

 

いかがでしたでしょうか？

障害時にサポートエンジニアによるRemote接続が出来ず、ログ調査がメインとなる環境では、事象の特定に時間がかかり業務影響の判断や調査開始までに時間を擁してしまうことが多々あります。

この記事がそういった時間の短縮にお役に立てれば幸いです。

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

※本記事は以下のDell EMCのインサイドコミュニティ投稿をもとに作成しています。（外部アクセス不可）

https://inside.dell.com/docs/DOC-362113

https://inside.dell.com/docs/DOC-362080

対象のNodeのコンソールを起動する

1. KVMもしくはiDRAC経由で仮想コンソールを起動する
   • KVMを使う場合。
     • 通常のサーバと同じくKVMを接続する
     • G560についてはMini Display portケーブルが必要なので注意
   • iDRAC（ネットワーク接続）の場合
     • 事前にiDRACのIPを確認・もしくは設定しておく（デフォルトは192.168.0.120 もしくはDHCP）
   • LANケーブルを準備する
   • 以下のコミュニティ文書を参考にiDRACの仮想コンソールを起動する
     • VxRail:BMCの仮想コンソール機能を利用してDCUIを操作する
   • iDRAC (Direct USB接続)の場合
     • Micro USBケーブルが必要（スマホ充電用のもので可能）
     • Dell EMC KB#522682 の手順に従い接続する
2. 仮想コンソールが起動出来たらESXiが起動完了していることを確認する。
   • Dell Modelの場合はRASRが正常に完了していることを確認する

VxRail Manager から Ping が通るかを確認（IPv6）

1. 対象Nodeで以下のコマンドを実行し、vmk0のIPv6アドレスを取得する
   • esxcfg-vmknic -l
2. VxRail Managerから以下のコマンドを発行し、VxRail Managerから対象NodeへのIPv6疎通を確認する
   • ping6 -I eth0 <対象Nodeのipv6 IP>
   • 例： ping6 -I eth0 fe80::xxxx:dddd:ffff:xxxx
3. Ping疎通できない場合はネットワーク設定（VLAN等）を確認する。疎通できた場合は次に進む

VxRail ManagerからSSHできるかを確認（IPv6）

1. VxRail Manager から以下のコマンドを発行して対象NodeにデフォルトパスワードでSSHログインできるかを確認
   • sshpass -p 'Passw0rd!' ssh -6 -o 'UserKnownHostsFile=/dev/null' -o 'StrictHostKeyChecking=no' -l root <ipv6>%eth0
   • 例： sshpass -p 'Passw0rd!' ssh -6 -o 'UserKnownHostsFile=/dev/null' -o 'StrictHostKeyChecking=no' -l root fe80::xxxx:dddd:ffff:xxxx%eth0
2. ログインできた場合は次に進む。できなかった場合はNodeをReimage（RASR）する。

Loudmouthサービスが問題なく稼働していることを確認する

1. 対象Nodeにて以下のコマンドでloudmouth サービスをリスタートする
   • /etc/init.d/loudmouth restart
2. VxRail Managerにて以下のコマンドでLoudmouthサービスをリスタートする
   • systemctl restart vmware-loudmouth
3. VxRail Managerで以下のコマンドを発行し、対象のNodeがDiscoverされていることを確認する
   • /usr/lib/vmware-loudmouth/bin/loudmouthc query | tail -n 1 | cut -c 10- | python -mjson.tool
4. Discoverされていない場合はMulticast疎通確認に進む。Discoverされていた場合は時刻確認に進む

Multicast疎通確認

1. VxRail Manager にて以下のコマンドでeth0のIPv6アドレスのLink Localアドレスを確認する (fe80から始まるアドレス)
   • ip address
2. 対象NodeにSSHでログインする（IPv6）
3. 対象Nodeで以下のコマンドでMulticast Address宛にPingする
   • ping -6 -I vmk0 ff02::fb
4. Ping応答の中にVxRail ManagerのIPv6が含まれていることを確認する
5. 確認できない場合はスイッチののマルチキャスト設定を確認する

Node時刻の確認

1. VxRail Managerの時刻を確認する（dateコマンド）
2. 対象Nodeの時刻を確認する（date コマンド）
3. 時刻にずれがあった場合はKB#521094のスクリプトを実行し、時刻ずれが修正されることを確認する
4. スクリプトが動作しない、もしくは効果がない場合は次に進む

VxRail Manager DBの確認

1. VxRail Managerにて以下のコマンドを発行する
   • psql -U postgres marvin -c "select applianceid,nodeposition,ip,model,morefid,number,primarynode,configurationstate from vxrailhost;"
2. 対象Nodeの行があることを確認する。無い場合は対象NodeとVxRail ManagerをRebootする
3. 対象Nodeの行のconfigurationstate の列が0であることを確認する。0 でない場合はWebExの準備をしてEscalationする

ハードウェア構成の確認（初期構築時のみ）

1. VxRail Manager DBに記載があるにもかかわらず初期構築のウィザードでNodeがDiscoverされない場合は、下記のKBに従いハードウェア構成をチェックする
   • https://support.emc.com/kb/501464
   • CPUのミスマッチがある場合はiDRACから全NodeのモデルとCPU情報を確認する。（Core数。ベンダ。周波数など）
   • メモリのミスマッチがある場合は、iDRACよりメモリ障害や認識不良が発生していないかチェックする
   • メモリのサイズが3バイトのみ違う場合は下記KBに基づきTPMの設定を確認する
     • https://support.emc.com/kb/525489
   • Diskのミスマッチの場合はiDRACからDisk数、Slot位置、サイズ、SSD or HDDを確認する
   • NICのミスマッチの場合は、すべてのNodeが同じNIC数、同じ速度で認識していることを確認する
     • esxcfg-nics -l

VxRail Managerの再起動

1. 最後にVxRail Managerを再起動する
2. 再起動後にNodeがDiscoverされていることを確認する
   • Node 追加・交換時はAdd Nodeができる状態になっていることを確認する
3. 状況が解決しない場合はEscalationをする

その他・ログ・Tips

• Node交換のタイミング
  • Quantaの場合
    • Disk/PSU/Fan以外のパーツ（CPU/メモリ/BMCなど）が壊れた場合はすべてNode交換となる
  • Dell モデルの場合
    • 細かい粒度で交換可能なためNode全体交換は存在しない（営業手配の特別ケースを除く）
    • ただし、NodeのReimageが発生した場合はNode交換と同じ影響・手順になる
      • OS破損、NDC交換（4.5.150以前）、Bootデバイス交換（SATADOM/BOSS/M2.SSD）の場合はReimageが発生する
  • VxRail 4.7.100以降はNode交換用の手順・スクリプトは存在せず、Node RemoveとNode Addの複合手順となる
• 初期構築およびNode追加・交換時のVxRail Managerのログの場所
  • /var/log/vmware/marvin /tomcat/logs/marvin.log
• 各NodeのPSNTは適切でなくてはならない。
• Quanta Nodeの場合BMCの設定はデフォルトでなくてはならない（IP設定とパスワードを除く）
• Dell Modelの場合、iDRAC設定とBIOS設定は工場出荷のデフォルトでなくてはならない（IP設定とパスワード）
  • Dell EMC KB#498837  & Dell EMC KB#492642
• 初期構築時のNodeはすべて全く同じ構成（メモリ・CPU・Disk・Network・Model）でなくてはならい
  • TPMの設定も共通でなくてはならない
  • Add Node時はAF/HYとNIC数・速度以外には制限はない
• どうしてもうまくいかない場合はVxRail Managerが起動するPrimary Nodeを変更して改善があるかどうかを確認する
  • https://support.emc.com/kb/493136
• G560の場合はPSNTが文字化けする不具合が発生することがある。
  • https://support.emc.com/kb/528180
• 初期構築およびNode追加・交換完了後はサポートマトリクス通りのVersionとなっていることを確認する
  • サポートマトリクス
    • Dell model
      • https://support.emc.com/docu82227_VxRail_Support_Matrix.pdf
    • Quanta model
      • https://support.emc.com/docu91492_VxRail_G410_Series_Support_Matrix.pdf
  • ESXiのVersionだけでなく、サポートマトリクスに記載のあるVIB/Firmware/DriverのVersionを確認する
    

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

※本記事はDell EMCのインサイドコミュニティの以下の記事をもとに作成しています。（外部アクセス不可）

https://inside.dell.com/docs/DOC-362081

https://inside.dell.com/docs/DOC-362114

初期構築時

Node追加・交換時

***** 注意 *******

こちらの記事で紹介するvSANで発生するスプリットブレイン（仮想マシンの二重起動）は

HCI アプライアンスやReady Nodeを問わず、vSAN環境で確認される事象ですが、vSANのバグではありません。

あくまでもvSAN環境の設定に依存する問題です。

こちらの記事ではvSAN環境で稀に起こりうる、仮想マシンの二重起動（スプリットブレイン）について紹介します。

なお、本記事では特に言及がない限りスプリットブレイン ＝ 仮想マシンの二重起動を示す用語として扱います。

vSAN環境におけるスプリットブレインの可能性については、以下のVMware Japanのブログでも紹介されているものになります。

VMware Virtual SAN 利用時の vSphere HA 設定に関するベストプラクティス - Japan Cloud Infrastructure Blog - VMware Blogs

本記事では、実際にどういう状況でスプリットブレインが起こるのかを、事象の再現を通じて紹介し、発生の仕組みについて説明します。

スプリットブレインの発生の仕組み

上記のVmware Japanのブログでも示唆されている通り、ハートビートデータストアがない状況でネットワークパーティションに相当する障害が発生した場合、スプリットブレインになる可能性があります。

ネットワークパーティションとは

VMware徹底入門 第4版 では、ネットワークパーティションの発生条件は以下のフローチャートでわかりやすく示されています

つまり、vSphere HAのハートビートが途絶え、かつハートビートデータストアのハートビートファイルがロックされており、かつ隔離アドレスへのPing疎通がある場合にネットワークパーティションとなります。

ネットワークパーティションの場合、障害ホストは自分自身が仮想マシンを稼働させるに足る状況である（データストアへアクセス可能、ネットワークへのアクセスも可能）と判断するため、仮想マシンを停止しません。

一方でパーティションされたホスト以外のホストは、ハートビートファイル経由で、パーティションされたホストの存在が確認できるため、パーティションされたホストで稼働する仮想マシンを起動しようとはしません。

Heartbeat Datastoreがない場合のネットワークパーティション

では、ハートビートデータストアがない状況（アクセスできないのではなく、設定されていない）の場合、上記のフローチャートはどのようになるのでしょうか。

ハートビートデータストアがない状況ではハートビートファイルの確認ができませんので、隔離アドレスへのPingによって、ネットワークパーティションか、隔離状態かが決まります。

この場合、実際にデータストアへのアクセスがない場合でも、隔離アドレスへのPingが通るとネットワークパーティションと判定されるため、仮想マシンを停止ししません。

データストアにアクセス不可であるにもかかわらず仮想マシンが停止しないため、パーティションされたホスト上で仮想マシンが稼働し続けることになります。

一方で、パーティションされたホスト以外のホストからは、ハートビートデータストアがないためパーティションされたホストの状態が確認できません。そのため、仮想マシンを起動しようとします。

健全なホストは当然ながらデータストアへのアクセスがありますので問題なく仮想マシンを起動できます。

その結果、パーティションされた側と健全なホストの両方で同じ仮想マシンが起動することになります。（＝ スプリットブレイン）

パーティションされた側の仮想マシンはDiskへのアクセスがない状態ですので、まともにOSが動作できませんがメモリ上に展開されているプログラムは生きており、仮想マシンとしてもMAC アドレスを持っているため、MACアドレスやIPアドレスの重複が発生する可能性があります。

vSAN環境でスプリットブレインが起こりうる条件

vSAN環境の場合、デフォルト設定のまま使用してしまうと、スプリットブレインが起こりうる条件を満たしている場合があります。

すなわち、

• ハートビートデータストアがない
• データストアにアクセスできない状態でも、隔離アドレスにPingが通る

という状況です。

vSANデータストアはハートビートデータストアとして利用できない制限があるため、外部データストアがなければハートビートデータストアの設定ができませんが

vSAN環境の場合、HCIとして導入されるとvSANデータストア以外に共有の外部ストレージがなく、ハートビートデータストアがない状況もあり得ます。

また、vSAN Clusterの場合、vSphere HAのハートビートはvSAN ネットワークを流れることになりますが、隔離アドレスのデフォルトは管理ネットワークのデフォルトゲートウェイになるため、vSANネットワークのみが切断（＝vSphere HAのハートビート停止、およびvSANデータストアへのアクセス不可）された場合でも隔離アドレスへはPingが通ります。

したがって、vSAN ClusterでvSANデータストア以外の共有ストレージがなく、かつ隔離アドレスをデフォルトから変更していない環境ではスプリットブレインが起こりうる、ということになります。

スプリットブレインをラボで再現する

※絶対に本番環境で実施しないでください。実施による損害についての責任は負いません

再現方法概要

再現方法は簡単です。まずは必須の設定以外はすべてデフォルトでvSAN Clusterを構成します。

その状態でスイッチ側で、vSAN vmkernel portが使用するポートのうち一つを選んでvSAN用VLANの設定を消します。

こうすることで、ESXi側で対象のUplinkポートがLinkup状態のためUplinkポートのFailoverをしません。

かつ、vSAN疎通が失われることでvSphere HAのハートビート疎通と、vSANデータストアへのアクセスが両方失われます。

この状況でも管理ネットワークは影響がありませんので隔離アドレス（デフォルトゲートウェイ）へのPingは通ります。

再現事前準備

1. 必須設定以外すべてデフォルトでvSAN Clusterを構成する
2. vSAN Cluster内のホストのうち、パーティションされるホストを任意に選ぶ
3. DRSを無効にする
4. １で選んだホスト上に、検証用のVMのみを配置する（VCSA/PSCなど重要なVMは使用せず、安全な場所に配置しておく）
5. 検証用VMを起動する
6. 検証用VMがほかのホストでも稼働できることを確認する（vMotionのCompatibilityの検証を利用）
7. ハートビートデータストアがないことを確認する
8. １で選んだホストのvSAN vmkernel portが使用するポートをスイッチ側で特定する

スプリットブレインを再現

事前準備が完了したら、後はスイッチ側で対象ポートのvSAN VLANを無効にするだけです。

無効にしてほどなくすると検証用VMが１で選んだホスト上で稼働しつつ、ほかのホスト上でも起動されていることが確認できると思います。

Host Clientでログインすると二つのホストで同時に同じVMが起動していることが確認できるはずです。

vCenterはどちらかのインベントリからVMを削除しようとしますが、両方とも稼働状態のためエラーになります。

この状態はVLAN設定を復旧させた後も継続します。

スプリットブレインを終了させるためには手動で仮想マシンを停止するしかありません。

スプリットブレインを防ぐためには

スプリットブレインを防ぐ方法はいくつもあります。

ハートビートデータストアを構築する

ハートビートデータストアがあれば、上記のスプリットブレインは発生しません。

この方法では、パーティションされたホストの存在をほかのホストが認識することができるため、仮想マシンが2重で起動されることはなくオリジナルのホストでのみ稼働し続けます。

ただし、パーティションされたホストはvSANデータストアへのアクセスがありませんので対象の仮想マシンのOSはまともに動作できません。

ハートビートではストアはFC-SAN接続でなくとも、iSCSIでもNFSでも構いませんがせっかくのHCIなのに外部ストレージ必須になってしまうのはちょっと、、、という意見もあるかもしれません。

隔離アドレスを変更する

隔離アドレスをデフォルトである、管理ネットワークのデフォルトゲートウェイから、vSANネットワーク上のInterfaceに設定することでvSANレベルの障害とvSphere HAレベルの障害の粒度がより一致する形になるため、スプリットブレインを防ぐことができます。

この方法では、vSANネットワークの切断がホスト隔離状態になりますので、仮想マシンが停止しHAによりほかのホストで起動することになります。

しかし、この方法ではvSAN VLAN内にPing疎通可能なネットワークデバイスが必要になります。

TORスイッチの持つ仮想インターフェース機能などを利用できれば問題ないです。

vSphere HA Component Protectionを利用する

この方法は使用できません。特にラボで検証などもしていませんが予期せぬ挙動となる可能性がありますので避けてください。

スプリットブレインを防ぐ手段にはなりませんが注意のために記載しました。

このことはVmware docに記載されております。

     Other vSphere HA Interoperability Issues

VMCP does not detect or respond to accessibility issues for files located on Virtual Volume datastores. If a virtual machine's configuration and VMDK files are located only on Virtual Volume datastores, they are not protected by VMCP.

!!!!!!  留意事項 !!!!!!

本記事はEMC Community Networkの記事のコピーです

同Communityが将来的にDell Communityに統廃合される可能性があるため、退避用に作成しています。

オリジナルのEMC Community文書については以下をご参照ください。

EMC Community Network - DECN: WebEx: Support Sessionへの参加方法

本資料はRemote調査の際にSupport Sessionに参加する手順をまとめたものです。

Meeting Sessionとは別の機能とUIですので、Support Sessionの場合のみご参照ください。

#### WebEx: Support Sessionへの参加方法 ####

WebExの概要とご留意事項

• WebEXはお客様サイトの端末（PC,サーバ）を、Dell EMCエンジニアがインターネット経由で操作するためのツールです。
• 作業中はDell EMCのエンジニアがWebEX端末であるPCの占有いたします。
• お客様はダブルクリックによっていつでも操作権を取り戻すことができますが、同じ端末で並行して作業を実施いただくことはできませんのでご留意ください。
• WebEX端末が物理マシンの場合、カバーを閉じたり、ロックしたりしないでください。接続がストップいたします。
• WebEX端末が仮想マシンの場合はRemoteDesktopの画面を最小化したり、閉じたりしないでください。接続がストップいたします。
  • 仮想マシンの場合はCPU2コア以上、メモリ４GB以上、ストレージ空き容量１０GB以上、リソースシェアの優先度は標準以上、を目安でお願いいたします。
• ネットワーク状況により不意に接続が切れることがございます。弊社側からの再接続はできないため、切断時には再接続のご協力をお願いいたします。
• 接続要件については基本的にインターネット上のサイト（GoogleやYahoo）に接続できる環境であれば、基本的に問題なく接続可能です。接続に問題が発生した場合は以下を参考にネットワーク要件とお客様ネットワーク設定をご確認いただく場合がございます。
• その他ネットワーク要件を含む端末要件については下記をご参照ください。
  • The specified item was not found.

Support Sessionへの参加方法

Dell EMCのサポートエンジニアより以下のようなメールを送信させていただきます。

メール内のURLをクリックいただきWebEx Sessionにご参加いただきます。

Dell EMCのエンジニアより提供される上記のURLをクリックすると以下の画面が開かれます。

以下の4項目を入力いただき右下のSubmitを押下してください

• First Name
• Last Name
• Email Address
• Company

※Support Session Numberのところには9桁の数字が表示されておりますので、”Select Agent"の部分はそのままでお願いします

Submitボタンを押すと以下の画面が表示されますので、ブラウザに応じたAdd-onやPluginを案内に従いダウンロード＆インストールをお願いいたします。

Add-on（Plugin）のInstallが完了し以下のウインドウが表示されましたら接続完了です。

WebEXのチャット機能を利用してDell EMCのエンジニアと直接やり取りが可能です。

※この時点ではまだDell EMCエンジニアによるお客様端末の閲覧や操作は不可です。

Remote サポートエンジニアが端末のControlをリクエストすると、以下のPop Upがでますので、OKを押下してRemote Controlをご承認ください。

チェックボックスにチェックを入れるとその後の承認が自動化されます。

!!!!!!  留意事項 !!!!!!

本記事はEMC Community Networkの記事のコピーです

同Communityが将来的にDell Communityに統廃合される可能性があるため、退避用に作成しています。

オリジナルのEMC Community文書については以下をご参照ください。

EMC Community Network - DECN: WebEx ネットワークと端末の要件およびセキュリティ情報

Dell EMCエンジニアとのWebExセッションに参加するためのネットワーク要件です。

基本的に、Internetにアクセスできる（GoogleやYahooなどのページにアクセス・表示できる）環境であれば問題なく接続できますので

トラブル時の参考資料としてお使いください

#### WebEx ネットワーク要件 ####

使用されるIP Addressの範囲

以下のGlobal IPアドレスの範囲が使用されます

• 114.29.192.0/19 (CIDR) or 114.29.192.0 - 114.29.223.255 (net range)
• 210.4.192.0/20 (CIDR) or 210.4.192.0 - 210.4.207.255 (net range)
• 69.26.176.0/20 (CIDR) or 69.26.176.0 - 69.26.191.255 (net range)

使用されるポート

TCP Port 443 および80が使用されます

使用されるドメイン

接続対象のドメインは弊社の emcsupport2.webex.comだけではなく、*.webex.comが必要になります。

また上記ドメインの名前解決（Internet上）も必要になります。

参考URL

https://cisco-support.webex.com/guest/articles/en_US/Usability_FAQs/WBX264/myr=false

https://collaborationhelp.cisco.com/article/ja-jp/WBX264

※WebExはCisco社より提供されているリモートサポートツールです

その他補足および注意事項

Proxyサーバなどのネットワークデバイスでフィルター実装されている場合はWhilteList登録なども必要になる場合があります。

例）

• *.webex.comとの通信におけるSSL Inspection（SSL Checking、SSL Decode他）の無効化。
• *webex.comとの通信をException Listへ登録。

#### 端末要件 ####

OSおよびブラウザの要件について

以下のCisco社のページをご参照ください。

https://collaborationhelp.cisco.com/article/ja-jp/q17qoe

端末の要件について

求められる端末の性能や容量の要件はWebEx調査の内容は使用するアプリケーションに依存いたしますが、Best Practiceとして以下をお願いしております。

※端末の性能が調査に不足と判断された場合は代わりの端末をご依頼させていただく場合がございます。

• CPU： 2GHz以上が2コア以上
• メモリ：4GB以上
• Disk：空き容量が10GB以上
• リソース優先度：標準以上 （仮想マシンの場合）

WebEX作業内容によっては事前にアプリケーション等をInstallしていただく必要がございます。一般的に調査に必要となるアプリケーションは以下でございます。

※細かくは作業対象の製品や作業内容に依存いたしますので都度依頼者にご確認をお願いいたします。

※準備が不足している場合は、追加でInstallをご依頼させていただく場合や、作業を断念する場合がございます。

• 標準的なブラウザ（IE、Chrome、Firefox）
• SSHクライアント（TeratermやPuttyなど）
• SCP、SFTPクライアント（WinSCPなど）
• 最新のJava （JRE）
• 最新のAdobe Flash

#### セキュリティ情報 ####

セキュリティについて

WebEXを利用したリモート接続中やファイル転送中は暗号化されたセキュアな通信を実現します。

ドキュメントおよびプレゼンテーションは、標準的な暗号化方式である256-bit Advanced Encryption Standard(AES)を使用し、エンドツーエンドで暗号化され転送されます。

すべてのミーティングは128-bit SSLv3を使用して転送されます。

SSLではポート443(HTTPSトラフィック)を使用します。

このためログファイルなどを取得している際にも内容がテキストで送信されることはなく、セキュアな環境で通信することができます。

※合わせてネットワーク要件のセクションもご参照ください。

!!!!!!  留意事項 !!!!!!

本記事はEMC Community Networkの記事のコピーです

同Communityが将来的にDell Communityに統廃合される可能性があるため、退避用に作成しています。

オリジナルのEMC Community文書については以下をご参照ください。

EMC Community Network - DECN: VxRail: WebEx調査時に端末にご用意いただくもの

この文書は、Dell EMCのサポートエンジニア（VxRail）がWebEXによる調査や作業を実施する際に必要となるスペックやアプリケーションを記述したものです。

※WebEX端末 ＝ お客様がWebEx用にご用意いただいた物理PCもしくは仮想マシンのこと

#### VxRail: WebEx調査時に端末にご用意いただくもの ####

WebEx端末の推奨スペック

• CPU： 2GHz以上が2コア以上
• メモリ：4GB以上
• Disk：空き容量が10GB以上
• リソース優先度：標準以上

必須でご用意いただきたいアプリケーション

• SSHクライアント（TeratermやPuttyなど）
• SCP、SFTPクライアント（WinSCPなど）
• vSphere Web Clientへのアクセスに必要なFlashおよびHTML5対応のブラウザ

※事前のご準備がされていない場合はInstallや実行ファイルのダウンロードをお願いさせていただきます

状況により必要となるアプリケーション

• Java(JRE Version 8）  ※BMCの仮想コンソールへのアクセスに必要となります。NodeのNot Responding発生の際は必須です。
• vSphere 統合プラグインが使用可能なブラウザ
• vSphere Client

ご準備いただきたいIP情報

• VxRail Manager IP
• vCenter server IP
• iDRAC/BMC IP

ご準備いただきたい認証情報

※お客様のセキュリティポリシーなどにより開示できない場合は都度ご入力いただく必要がございます。

• VxRail Manager root ユーザパスワード
• vSphere web client 管理ユーザ名およびパスワード
• vCenter root ユーザパスワード
• PSC root ユーザパスワード
• ESXi root ユーザパスワード
• iDRAC/BMC  パスワード

この記事では、vSphere Web Client/Host Client/ Dell EMC FTPサイトなどのGUIを英語にする方法を紹介します。

＃＃＃ブラウザのの英語表示設定 ＃＃＃

Google Chromeの場合

１．Google Chromeの右上のアイコンから設定を選びます。

２．開かれた画面で一番下まで行き、詳細設定をクリックして展開します。

３．”言語”の設定項目を探して、”言語を追加”から英語を追加します。

４．英語が追加できたら右側のアイコンから序列を変更し、英語が一番上に来るようにします。

５．英語が一番上にきたら再起動ををクリックします。（Chromeが再起動します。）

６．（vSphere WebClientの場合のみ）再度Google Chromeが起動されたら、以下のようにLocaleを指定する形でWebClientにアクセスします。

https://＜Web Client Server＞:9443/vsphere-client/?locale=en_US

※上記後もWebClientの表示が英語にならない場合は、一度WebClientをログアウトしてログインしてみてください。

その他ブラウザの再起動やキャッシュのクリアなどを試してください。

Internet Explorer（IE）の場合

１．IEからインターネットオプションを開き、全般＞言語をクリックしてください。

２．言語の優先順位の設定をクリックしてください。

３．コントロールパネルの言語設定が開きますので、”言語の追加”からEnglishを追加してくださいｌ

４．Englishが追加できたら、序列を変更し、Englishが一番上に来るように変更してください。

５．設定が完了したら右上のXからコントロールパネルを閉じ、IEを再起動してください。

６．（vSphere WebClientの場合のみ）再度IEが起動されたら、以下のようにLocaleを指定する形でWebClientにアクセスします。

https://＜Web Client Server＞:9443/vsphere-client/?locale=en_US

※上記後もWebClientの表示が英語にならない場合は、一度WebClientをログアウトしてログインしてみてください。

その他ブラウザの再起動やキャッシュのクリアなどを試してください。

この記事では、vCenterで発生するアラートをSNMPを使用して通知する設定方法を紹介します。

1. vCenterへSNMPサーバ(Receiver)やCommunity stringなどの設定

a. vCenter Server SettingsのMenuへ移動

     ・vCenter 6.0の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Manage > Settings > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

   ・vCenter 6.5の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

   ・vCenter 6.7の場合

vCenter Client(HTML5) にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

b. Edit vCenter Server SettingsにてSNMP receiversの欄に設定する情報(Port / Community)を入力

※複数のReceiverを設定する場合は、Enabledにチェックを入れることを忘れないでください

vCenter 6.7の場合は"Enable receiver"をクリックし緑にすることで有効化できます

c. 設定した値がGUIに反映されていることを確認

2. vCenterに定義されているアラート設定に、SNMP通知を送信する設定を追加

※下記例はESXiがvCenterへの応答がなくなった場合等に発生するアラートの"Host connection and power state"を例にしています

※アラートを見つける際には、虫眼鏡マークの"Filter"に文字列を入力すると見つけやすいです(vCenter 6.0, 6.5)

※アラートを見つける際には、Alarm Name横にあるマークを押して文字列を入力すると見つけやすいです(vCenter 6.7)

a. vCenterに定義されているアラート(Alarm Definitions)一覧へ移動し設定を追加するアラートを選択

     ・vCenter 6.0の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Manage > Alarm Definitions を選びアラート一覧を表示、"Host connection and power state"の項目を選択

右側にあるEditを押す

     ・vCenter 6.5の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Monitor > Issues > Alarm Definitionsを選びアラート一覧を表示、"Host connection and power state"の項目を選択

右側にあるEditを押す

     ・vCenter 6.7の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > Alarm Definitions を選びアラート一覧を表示、"Host connection and power state"の項目を選択

上部のEDITを押す

b. アラートが発生した際にSNMP trapを送信する設定を実施

・vCenter 6.0、6.5の場合

左側の"3 Actions"タブを選択

緑の"＋"を押して、Action列にて"Send a notification trap" を選択

アラームのステータス移行に関して"Once"か"Repeat"を選択しSNMP trapの送信するタイミングと頻度を選びます

・vCenter 6.7の場合

     "Alarm Rule 1"までNextで進む

     "Send SNMP traps"をチェックして緑に変更（必要に応じて"Repeat"にチェック）

     そのままNEXTで進み、SAVE

アラーム毎のステータス移行はアラートのTriggers欄を参照すると良いです

c. 設定したActionがGUIに反映されていることを確認

・vCenter 6.0、6.5の場合

"Host connection and power state"の詳細欄のActionsを押して展開

Send a notification trapと反映されていることを確認

・vCenter 6.7の場合

     "Host connection and power state"の左側にある↓をクリックし展開

     Alarm Rulesにsend SNMP trapsと反映されていることを確認

■補足：MIBファイルに関して

MIBファイルを使用したい場合は下記のVMware KB(1013445)にあるものをご使用ください

（画面、右側の"Attachments" にファイルがございます）

SNMP MIB module file download (1013445)

https://kb.vmware.com/s/article/1013445

### 参考文献

・SNMP MIB module file download (1013445)

https://kb.vmware.com/s/article/1013445

・アラーム アクションの指定

・アラームとしての SNMP トラップの送信

・vCenter Server の SNMP 設定の構成

Now it's time to investigate more deeply about troubleshooting of VMware Horizon View. In this post, I want to continue speaking about the LDAP structure and data of the VDI server. If you look at the first post of this series, I talked about how to connect to View LDAP with windows MMC: ADSI Edit. Now I will show you which VDI objects belong to which one of OUs in Directory Service hierarchy of VMware View:

1. OU=Server Groups specified a list of desktop pools in the Horizon environment.

2. OU=Servers contain all the VMs (Desktops that have been deployed by every desktop pool.

3. OU=Data Disk listed all of the generated virtual disks belong to each of the desktop.

4. OU=Groups contains all of predefined Admin groups and manually added roles in horizon administration console with their allowed permissions mentioned into the pae-AdminRolePermissions attribute of defined object.

5. OU=Applications is about all added virtual APPs to Horizon environment, for example by an Application Pool of an RDS Farm. Each of the created Apps are listed here.

Now let's review sub_OUs of OU=Properties:

1. If you configured the View event database, you can see the related object in sub_OU of OU=Database as a pae-EventDatabase class. Database server type and instance name, configured TCP Port, Database name and also events longevity are the main attributes of this class of object.

2. OU=Server is about Horizon View servers class as the pae-VDMProperties class. OU=Server, OU=LVM contains VDI servers (as same as the last mentioned object class) that are related to Linked-Mode Desktop Pools.

3. OU=VirtualCenter listed configured vCenter servers (VC) and composer servers (SVI) with object class type of pae-VirtualCenter. You can also check specified connection credential and URL addresses of each server: https://VC:443/sdk and https://SVI:18443

4. OU=Global contains some important objects such as:

4-1 CN= Common with some important attributes about VDI management, like Pod Name (or Cluster Name that has been generated from computer name of first / primary installed connection server), timeout of console session and connected desktop desktop, Maximum session time duration, Syslog related configuration, Pre-forced logoff message for Horizon endpoint users, IPSec mode and etc.

4-2 CN=License with hashed-form of imported license key for VMware Horizon View.

4-3 CN=Keys contains RADIUS configs, some session timeouts like RDP, VDM Gateway and Security servers, Security Server Pairing settings and etc.

I tried to mention some useful and critical OUs of VMware Horizon View LDAP structure on this post, if you think I forgot to review another important object of View LDAP, I will be appreciated to tell me about it.

Link to my personal blog's post: Undercity of Virtualization: VMware VDI (Horizon View) Troubleshooting - Part II

NSX-T 2.4 から、NSX-T の Web UI が大きく変更されました。

特に大きな変更点として、従来の NSX-T の操作／設定は「ネットワークとセキュリティの詳細設定」画面に移動され、

あらたに「ネットワーク」「セキュリティ」といったシンプルな画面が追加されています。

（Simplified UI と呼ばれたりするようです。）

そこで、あらたな UI に慣れるべく NSX-T 2.5 のラボ環境を「ネットワーク」画面から作成してみます。

NSX-T 2.5 の Web UI の様子。

NSX-T の Simplified UI での「ネットワーク」「セキュリティ」の部分です。

新しい「ネットワーク」画面です。

以前とはオブジェクトの名前が変更（例えば「Tier-0 ルータ」が「Tier-0 ゲートウェイ」に）されています。

これらは名前が変更されただけではなく、以前の方法で作成されたオブジェクトとは

別種類のものとして扱われます。

新しい「セキュリティ」画面です。

従来どおりの操作も「ネットワークとセキュリティの詳細設定」画面から可能です。

たとえば「ネットワーク」画面で作成されたオブジェクトは、こちらの画面にも表示されますが、

基本的には設定変更などは不可で、作成された「ネットワーク」画面側で操作することになります。

Simplified UI は、NSX-T の Policy API をベースとしたもので、

今後の NSX-T では、従来からの API ではなく Policy API がおもに使用される想定のようです。

NSX-T Data Center 2.5 の API Guide は、下記の Web サイトで確認することができます。

NSX-T Data Center REST API - VMware API Explorer - VMware {code}

リファレンス見出しの抜粋をもとに説明すると、

おおまかに下記のようなイメージとして捉えるとよさそうです。

• 2 API Methods
  • 2.1 AAA
  • 2.2 Cloud Service Manager
  • 2.3 Management Plane API ★従来の NSX-T UI のベースとなる API（今の「～詳細設定」）
  • 2.4 Nsx-Intelligence
  • 2.5 Policy ★新たな Simplified UI のベースとなる API
  • 2.6 Upgrade

今回のラボ環境構築の流れ。

今回作成する NSX-T の環境は、以前に紹介した  NSX-T 2.4 環境と同様のものです。

環境のイメージについては、下記の投稿にあります。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

Simplified UI の「ネットワーク」画面から操作するのは、

Tier-0 ルータ / Tier-1 ルータ / 論理スイッチといったコンポーネントです。

その前提となる トランスポート ノード や Edge クラスタのセットアップについては、ここでは省略します。

以前に投稿した内容ですと、下記（Host / Edge トランスポート ノードのセットアップ）までは実施ずみとしています。

自宅ラボで NSX-T 2.4 環境を構築する。Part.7

以前の「VLAN 論理スイッチ」にあたる「VLAN セグメント」と、

「Tier-0 論理ルータ」にあたる「Tier-0 ゲートウェイ」の作成から始めます。

以前の投稿では下記にあたります。

自宅ラボで NSX-T 2.4 環境を構築する。Part.8

それでは、

つづく・・・

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

まず、従来の「VLAN 論理スイッチ」にあたる「VLAN セグメント」を作成します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

VLAN セグメントの作成。

さっそくですが、VLAN のセグメントを作成します。

NSX-T の Manager にログインして、「ネットワーク」画面を開きます。

画面左にある「セグメント」→「セグメント」タブにある、「セグメントの追加」をクリックします。

セグメントの設定入力画面が表示されるので、下記を入力して「保存」します。

• セグメント名： seg-vlan-0200。
• トランスポート ゾーン： tz-vlan-01。これは Edge ノードを接続ずみの VLAN トランスポート ゾーンです。
• VLAN： 200。今回は NSX-Tと外部との境界になるネットワークに VLAN ID 200 を使用しています。

セグメントを作成すると、設定を続行するか確認があります。

「はい」を選択すると、作成したオブジェクトでそのまま（ひとつ前の画面で）設定作業を続けられます。

今回は「いいえ」で閉じます。

セグメントが作成されました。

「状態」が稼働中（緑色）になっていない場合は、少し待ってから隣の更新ボタンをクリックすると、

稼働中の状態になるはずです。

VLAN セグメント／VLAN 論理スイッチ は異なるのか？

セグメントを作成した後に、

「ネットワークとセキュリティの詳細設定」→「スイッチング」を開いて、

論理スイッチ（従来のセグメントにあたるもの）を確認してみます。

※この確認は、セグメント／論理スイッチの比較のためなので、通常のセグメント作成では不要です。

今回は、この画面で「ls-vlan-0200」という従来どおりの論理スイッチを作成してあります。

「セグメント」には、従来の論理スイッチとはことなり先頭に丸いマークが表示されています。

この「ネットワークとセキュリティの詳細設定」で論理スイッチとセグメントそれぞれの

設定変更の画面を開くと、おたがいに違うオブジェクトとして扱われていることがわかりやすいと思います。

まず、「ネットワークとセキュリティの詳細設定」で

VLAN 論理スイッチの設定画面を開いてみます。

当然ながら、VLAN ID などの設定変更ができるようになっています。

一方、「ネットワークとセキュリティの詳細設定」で

VLAN セグメントの設定画面を開いてみると、ほぼ設定変更ができなくなっています。

Simplified UI ／ Policy API による NSX-T 環境には、これまでの NSX-T とは明確に差異があるので、

Policy API ならではの定義方法を意識する必要がありそうです。

つづく。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-0 ルータ」にあたる「Tier-0 ゲートウェイ」を作成します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

Tier-0 ゲートウェイの作成。

Tier-0 ゲートウェイを作成します。

この先の手順で指定するアップリンクの VLAN セグメント「set-vlan-0200」は、前回の投稿で作成したものです。

NSX-T の Manager の「ネットワーク」→ 「Tier-0 ゲートウェイ」画面を開き、

「Tier-0 ゲートウェイの追加」をクリックします。

下記のパラメータを設定して「保存」します。

• Tier-0 ゲートウェイの名前
• HA モード： アクティブ／スタンバイ
• Edge クラスタ： 作成ずみの Edge クラスタを選択します。

Tier-0 には作成後に設定変更するパラメータがあるため、

「Tier-0 ゲートウェイの設定を続行しますか？」では「はい」を選択します。

Tier-0 ルータ作成時に表示されていた入力画面が表示されます。

アップリンクとなるポートを作成するため、

「インターフェース」→「設定」をクリックします。

「インターフェイスの設定」画面が表示されるので、「インターフェイスの追加」をクリックします。

次のパラメータを入力してから「保存」をクリックします。

• 名前： インターフェースの名前を入力します。
• タイプ： 「外部」を選択したままにします。
• IP アドレス/マスク： NSX 外部の VLAN と、NSX-T の VLAN セグメントにあわせた IP アドレスを指定します。
• 接続先（セグメント）： 作成ずみの VLAN セグメント「seg-vlan-0200」を選択しています。
• Edge ノード： 作成ずみの Edge ノードを選択します。

インターフェースが作成されたことを確認して「閉じる」をクリックします。

「状態」が「不明」になっている場合は、更新ボタンをクリックすると「稼働中」になるはずです。

「インターフェイス」に「1」（インターフェースの数）が表示されるようになります。

そのまま画面を下にスクロールして「編集を終了」をクリックします。

「ネットワークとセキュリティの詳細設定」での Tier-0 ゲートウェイ。

作成した Tier-0 ゲートウェイは、「ネットワークとセキュリティの詳細設定」画面では

「Tier-0 ルータ」と同様に表示されます。

「ネットワークとセキュリティの詳細設定」配下の対応する画面には、

「ネットワーク」画面で表示されるオブジェクトの「詳細設定」からでも表示できます。

前回作成した「セグメント」と同様に、Simplified UI で作成した Tier-0 / Tier-1 ゲートウェイの場合も、

先頭に丸いマークが表示されています。

つづく ...

VxRailの環境では、未構成NodeのDiscoveryのためにIPv6のマルチキャストが必要です。

マルチキャスト通信は定期的に行われており、ある程度の帯域を消費するわけですが、実際にどれくらいの通信量なのかと質問を受けたので実際にラボ環境で測定してみました。

ラボ環境では、VxRailが3クラスタあり合計12Nodeです。

そのうち一つのVxRail Manager VM上でTCPDUMPを実行し、結果をWireSharkで解析しました。

Loudmouthで利用するマルチキャスト IPv6 アドレスである ff02::fb 宛のパケットでフィルターをかけて収集したところ、

24917秒の観測時間中に、9740個のLoudmouthマルチキャストパケットが観測されました。

内訳は以下です。

12個以上のソースがあるのはVxRail ManagerやSmart Fabricなどがあるためです。

また、パケットの平均サイズは約220バイトでした。

これが多いのか、少ないのか、影響があるのかないのかの環境次第だと思いますが、とりあえず参考情報として公開してみました。

ちょっと前の話なので今更感がありますが、Version 76以降のGoogle ChromeからFlashの実行がデフォルトでBlockされるようになりました。

以前であれば、Flashの実行が必要な際にポップアップが出てAllow or Blockを選択できましたが、Version 76にUpdateしたとたんに出なくなりました。

Flashが実行できないとWebClientが使えないことになってしまいますが、ブラウザの設定を変えれば以前のようにポップアップを出すことができます。

詳細は以下のURLをご確認ください。

https://gigazine.net/news/20190731-google-chrome-76/