IT or War

SNMPの Version による差異  SNMPにいくつかのVersionがあることはよく知られた事実だと思います。主には、SNMP v1, v2c, v3 が利用されています。 普段利用するうえで、あまり SNMP の Version の細かな違いを意識することは少ないと思います。多くの方は、v1とv2cは認証が不要、v3は認証が必須で設定が面倒、というくらいの差異しか感じていないのではないかと思います。 しかしながら（当然ながら）、それ以外の差異も存在しています。それぞれの詳細な仕様は以下のRFCで規定されています。 SNMP v1 https://datatracker.ietf.org/doc/html/rfc1157 SNMP v2 https://datatracker.ietf.org/doc/html/rfc1905 https://datatracker.ietf.org/doc/html/rfc1910 SNMP v3 https://datatracker.ietf.org/doc/html/rfc3414 上記のRFCを読み解くのは難しいので、詳しく知りたい方は SNMP message format についてググればわかりやすい記事を見つけられると思います。 この Version による差異は、実は SNMP Trap にも存在します。具体的には以下の記事で説明されているように、SNMP v1、v2c であっても PDU の Message format が異なっています。  SNMP v1 Trap PDU Message format http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat-3.htm SNMP v2 Trap PDU Message format http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats-5.htm SNMP Trapで利用されるVersionは何か？ ここで疑問に思うのは、SNMP Trap を送信する監視対象デバイスはどの SNMP Version の Trapを送信しているのか、という点です。 SNMP Get などで Pollin...

  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...

この投稿は vExpert Advent Calendarの10日目です。 https://adventar.org/calendars/6689 本記事では以下の状況と、簡易な復旧方法について説明します。 環境 vCSAは自身が管理するvSphere Cluster上に存在する。 vCSAは自身が管理する vDSに接続される vCSAが接続されるdvportgroupはEphemeralではない 該当のvCSA以外にvSphere Clusterを管理できる vCSA は存在しない  障害状況 vCSAは何らかの理由により、もともと存在していたESXiから、別のESXiに再登録されている。 vCSAはvDSから切断されてしまっている。 解説 上記の状況は、ESXiの障害などによって副次的に発生しうる状況です。もともと、vCSA は vDS に接続されていましたが、ESXi の障害などにより、いったん Guest OS から Shutdown され、Host Client を利用して別の ESXi に再登録したうえで起動しています。 この場合、もともとvCSAが接続されていたdvportは別の ESXi 上のポートであるため、起動時にvCSAはvNICを接続することができず、切断状態となります。 vCSAが切断状態になり、かつESXiのHost Clientからは仮想マシンをvDSに接続することができないため（Ephemeral Port を除く）、vCSAの復旧が困難となります。  この状況において有効な解決策としては事前に用意しておいたEphemeral Port を利用するか、もしくは一時的にVSSを作成して復旧する方法が一般的な方法です。 事前にEphemeral Port の準備がない場合には、VSSを作成することになりますが、Uplinkに空きがない場合は、Uplinkを付け替える必要があり、手順は複雑になります。 今回はVSSを利用しない簡易な復旧方法についてご紹介します。 簡易な復旧方法 完結に手順を示すと以下です。 vNICが切断されているVCSAをShutdown  vCSAが存在する ESXi を Maintenance Mode～Reboot  vCSA を再度起動～vNICが接続状態であることを確認...

 vSAN 7U3 での Shutdownに関するエンハンスメント 何が変わったか それまで煩雑だったvSAN Cluster の Shutdown 手順が vSAN 7U3 の新機能によって簡易化されました。 参考： https://core.vmware.com/blog/vsan-7-update-3-whats-new    従来のやり方（Manual Shutdown）では、vSAN Cluster上のすべての仮想マシンを停止したのちに、ESXiをメンテナンスモードに入れる前に、手動でScriptを実行する必要がありました。 また、PowerUp の際も、ESXi をメンテナンスモード解除した後で、同様に手動で Script を実行する必要がありました。vSAN 6.7U3 より未満の Version では、すべての ESXi でこれを実施しなくてはならず、かつ Script も VMware のサイトからダウンロードし全 ESXi に配置し、かつそれを時刻同期した状態で Cron で実行する必要がありました。 vSAN 6.7U3 以降では、Script が更改され、自動化が進み、かつデフォルトで ESXi に内蔵されました。しかも、vSAN Cluster 内の任意の1ホストで実行するだけでよいため、それまでと比べて非常に簡易化されましたが、依然として CLI ベースの対応が必要であり、エンドユーザにとっては難しい場合もありました。 今回の vSAN 7.0 U3 では、従来の CLI ベースの Shutdown 手順から、GUI での Shutdown が可能になりました。自動化も大きく進み、Shutdown と PowerUp の両手順において、わずか数クリックで完了できます。 そもそもなぜ CLI ベースの Shutdown が必要だったか。 vSAN には、以下の KB で説明される不具合があり、過去すべての Version で該当します。この不具合は2018年に報告されていますが、最新版でも直っていません。 A simultaneous reboot of all hosts in the vSAN cluster may result in data unavailability after a sin...

大したナレッジではないですが個人的なメモを兼ねて。  参考： Migrating a virtual machine between two different vDS version (79446) (vmware.com) https://www.virtuallyghetto.com/2018/09/vmotion-across-different-vds-version-between-onprem-and-vmc.html ターゲット側のVCSAで以下を設定する vSphere Client (or vSphere Web Client) にログインし、Navigater Pane にある vCenter の インベントリを選択する 設定ー＞詳細設定を選ぶ config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig を trueにする。（下図参照。vSphere Web Client の場合）

  **** 留意事項 ***** こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。 DECNが近い将来に廃止となるためこちらに移行させていただいております。 内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。   ※本記事は前回の続きです。前回の記事はコチラ↓↓↓ vSphereのアラーム定義で一覧にないEventのアラームを定義する方法       さて、前回の記事ではより自由なアラーム定義の方法をご紹介しましたが、そのためにはEventIDが必要だということがわかりました。 厳密にはEventIDでなくともEventDescriptionを設定すればいいのですが、日本語の場合はスペースや句読点など正しく入力するには多少のハードルがありますので好ましくありません。 前回のEventを例にするとEventDescriptionは以下の二つになりますが、それぞれ微妙に半角スペースが用いられており、正しく入力できない懸念があります。   "RAM ディスクがいっぱいです。" "RAM ディスクのファイル テーブルがいっぱいです。"     したがって、EventIDがわかるのであればEventIDで入力したいところです。 ではどうやってEventIDを調べるのか、というのが本記事の趣旨になります。     実はEvent自体はvCenter内に定義ファイルと思しきものがあるのでそれを見ればいいのです。 VMwareの公式情報があるわけではないですが、検証機で試したところ以下の場所に定義ファイルと思しきものを見つけることができました。   /etc/vmware-vpx/extensions/hostdiag/extension.xml     ちなみに確認で用いたvCenterのVersionは以下です。 BRANCH:vsphere65ep7 BUILDNUMBER:8815520 CLOUDVM_VERSION:6.5.0.21000   このファイルをみるとEventIDやそのDescriptionがまとめられて...

ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...