IT or War

  リンク障害と Active/Standby の挙動について Active/Standby 、つまり NIC Teaming のロードバランシングで「明示的な Failover 順序の使用」を選択し、ネットワーク障害検出で「リンク状態のみ」を選んだ場合の挙動について確認する   この場合は非常にシンプルな挙動となる。 つまり、平時は常に Active に設定された Uplink を利用し、 Link Down が発生すると Standby の Uplink に切り替わる。 そして、 Link 復旧後は元の Uplink に戻ってくる（※ Failback が有効）     リンク障害と Active/Active ”発信元の仮想ポートに基づいたルート”について 次に、「発信元の仮想ポートに基づいたルート」を利用した場合の以下の挙動について確認する   該当のロードバランシング設定については以下のドキュメントに説明がある 発信元の仮想ポートに基づいたルート (vmware.com)   上記の設定においては、各仮想ポートに対し、 Uplink 利用の優先順位が基本的に固定的に割り当てられるため、 Link ダウン時にもう片方の Uplink に Failover した場合、 Link 復旧後には元の Uplink に戻ってくる挙動となることを実機で確認した。       リンク障害と Active/Active ”物理 NIC の負荷に基づいたルート”について 次に「物理 NIC の負荷に基づいたルート」の挙動について確認した。     物理 NIC 負荷に基づいたルート (vmware.com)     この設定の場合、ドキュメントの説明にもある通り、物理 NIC の負荷に応じて利用する Uplink を動的に決めるため、 「仮想ポートに基づくルート」のように各仮想ポート毎に個別優先順位が設定されているわけではない、 そのため、リンク障害時に Failover したのち、リンクが復旧したとしても、その際に物理 NIC の使...

背景 vCenter からのメール配信は STARTTLS に対応しているらしいのでその動作確認のために、 STARTTLS に対応したメールサーバを構築してみました。 https://kb.vmware.com/s/article/2063147   パブリッククラウドの利用や、昨今関心が高いセキュリティポリシー観点で平文の SMTP ではなく STARTTLS などで暗号化通信を行う環境が増えてくると思われます。その準備として、 vCenter サーバからのメール配信として STARTTLS を必須とするメールサーバーを構築しました。   Postfix のインストールと設定 証明書の生成 mkdir -p /etc/mail/certs/ cd /etc/mail/certs/ hostname openssl req -new -x509 -nodes -out server.pem -keyout server.pem -days 7000     Postfix のインストール yum -y install postfix     Starttls の設定 vi /etc/postfix/main.cf   以下の設定を投入 参考： https://www.postfix.org/postconf.5.html #smtpd_tls_security_level = may smtpd_tls_security_level = encrypt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.pem ※必須にする場合は encyrpt 。任意にする場合は may にする   再起動して設定を反映 service postfix restart   設定の確認 /usr/sbin/postconf | grep -e smtpd_tls_security_level -e ...

vSAN は NIC チーミングのロードバランシング設定を無視する？   vSAN 関連のドキュメントに以下の記載に関連していろいろと調べてみた。     「 vSAN では、ロード バランシングに NIC チーミングは使用されません。」   上記の記載は以下のドキュメントで確認できる。   Basic NIC Teaming (vmware.com) vSAN ネットワークの設計 (vmware.com)   日本語の説明だけ読むと、以下の誤解が生まれそうな記載である。   誤解①： vSAN は NIC Teaming でロードバランシングポリシーが設定されていても常に Active/Standby で動作をする   誤解②： vSAN のロードバランシングは NIC Teaming 以外の機能を利用する   きちんと原文（英語）で前後の文脈を考慮するとそういうことではないと判断できる。 そもそも vSAN の仕組みをよく知らない人のために NIC Teaming のロードバランシング設定がどのような形で反映されるのかを確認しておく。     ①各仮想マシンが自分で vSAN データストアに直接 IO リクエストをするわけではなく、仮想マシンは稼働している ESXi に対し SCSI のリクエストを送信する ② ESXi は仮想マシンからの SCSI リクエストを vSAN データストアへの IO として処理する ③ ESXi は vSAN の IO を処理するために vSAN vmkernel port を利用する ④ vSAN vmkernel port は vDS につながっていて、 dvport ID に紐づいている ⑤ vDS のロードバランシングは dvport id 単位で実施されるため、該当の dvport id がどの Uplink を利用するかはロードバランシングポリシーによって決まる   つまり、 ESXi 上で稼働する VM から vSAN データストアへの IO リクエストは単一の vsan vmk...

※本投稿は2020年に別のブログサービス（現在アクセス不可）に投稿した記事の再掲です 情報的に古い内容となっております。   VxRailなど、PowerEdge上にESXiをInstallしている場合、トラブルシューティングや初期構築などでiDRACの仮想コンソールに接続することはしばしばあると思います。 先日、ESXiのInstall用途で、iDRACの仮想コンソールにJavaで接続しようとしたら、エラーになって接続できないことがありました。   結論からいうと、iDRACのFWをUpdateするか、Javaのセキュリティファイルの設定を書き換えることで解決できました。 その時のトラブルシューティングを記します。     事象 キャプチャをとればよかったのですが、残念ながら取り損ねてしまいました。 英語でのキャプチャが欲しかったので後で事象を再現させて取ればよい、と楽観していたところ再現しなくなってしまったので取れずじまいです。   事象としては、idracの仮想コンソールにJavaで接続しようとした際に、Javaのアプレット（？）が起動した直後に「ビューワが切断された～」みたいなメッセージがでて接続できないという事象でした。   トラブルシューティング Javaのコンソールやトレースを有効化する Javaのエラーを見れば何かわかる、と思ったのでJavaのコンソールやロギングを有効化しました。 有効化は、コンパネからJavaのコントロールパネルを開き、AdvancedタブからConsoleやLoggingやTracingのチェックを入れればいいだけです。   事象を再現してログをみる コンソールとロギング・トレーシングの設定をしたら、もう一度事象を再現させて、ログを見ればよいです。 実際に記録されていたログは以下です。 2020年2月19日 4:07     Java Web Start 11.241.2.07 Using JRE version 1.8.0_241-b07 Java HotSpot(TM) Client VM JRE expiration date: 20/05/17 0:00 console.user.home = C:\Users\Administrat...