ad1

ラベル vCSA の投稿を表示しています。 すべての投稿を表示
ラベル vCSA の投稿を表示しています。 すべての投稿を表示

2020年12月6日日曜日

vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版

 ここ数年、様々なお客様環境のアセスメントを実施して、現状の課題と改善案を説明してきた中で vSphere 仮想化基盤のサイジングに関する考慮点や、性能を最大限かつ安定的に発揮する構成、設計についてディスカッションする機会が多くありました。

vSphere のベストプラクティスを挙げていくとキリがありませんが、それらの中で特にサーバーやストレージの物理のデザインにも関連した内容で頻繁に紹介してきたもの集めてみました。(本投稿の内容は基本的に公式のガイドに沿ったデザインの内容ですが、一部個人の経験に基づく内容もありますのでご了承ください)。

※ 本投稿は vExperts Advent Calendar 2020 の 12/6 分を担当しております。
非常に長文ですが、オンプレミス環境の vSphere クラスタデザインの参考にしていただければ幸いです。

2019年12月22日日曜日

ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得するべき情報

今年、いくつか HCIBench 等を利用したストレージ性能検証の方法を紹介したところ、いろいろと性能設計や検証に関連しての質問、相談がありましたので整理してご紹介しようと思います。

本投稿は vExpert Advent Calendar 2019 の 12/22 分を担当させていただきました。
https://adventar.org/calendars/4289

色々書きたい事を集めていたら膨大な量になって情報探し難くなってしまったので、何個かに記事を分ける事にしました
また、以下の HCIBench に関連した投稿も参考にしていただければ幸いです。

 vSAN 性能検証時に取得する情報

現職 (vSAN 製品担当) になってから「性能が出ない」「挙動がおかしい」など、 vSAN 試験に関しての相談を受ける事が非常に多くなり、そんな時に構成や試験内容、パフォーマンスログについてヒアリングするのですが試験事後で情報が取れないなど問題の切り分けに苦労する事が多数ありました。

本投稿では vSAN 性能試験を行う際に必ず取得していただきたいパフォーマンス情報、構成情報などの取得方法、
どの様な時にどの情報を見て問題(性能限界やボトルネックなど)を切り分ける事が出来るか、以下6つツールを利用するポイントをご紹介します。
  1. vCenter でのパフォーマンス情報取得の有効化と vSphere Client での監視
  2. vSAN Observer ログの取得
  3. vSAN 構成情報 ( vSAN Support Information) の取得
  4. vSAN Performance Monitor でのモニタリング
  5. HCIBench でのモニタリングとログ取得
  6. PowerCLI での vSAN Stats ログの取得
※ 性能検証時のログ取得、障害などの切り分け等する際には①~③は必ず設定、取得してください。これがあるだけで問題解決への道のりが大幅に短縮されます。

2019年4月3日水曜日

vSphere 6.7 Update2 のリリースと 外部 PSC の「非推奨」化

本日 4/3、Vmware公式ブログにて vSphere 6.7 Update2 が発表されました。
(4/3時点だとまだリリースノートやバイナリは入手不可)

Announcing vSphere 6.7 Update 2, vSphere Platinum updates, and vSphere ROBO Enterprise

セキュリティ機能の強化やROBO向け機能の強化、vCenter 機能、vUM の強化など各種の改善が入いますが、
vCenter PSC の構成で 外部 PSC (Extarnal  PSC)が正式に「非推奨」と Update のアナウンスで案内される事となりました。
With vSphere 6.7 Update 2, VMware is announcing the deprecation of external PSCs.  
昨年秋の vSphere 6.7 Update1 リリース後に、同じく公式ブログや KB で外部 PSC は非推奨になる、とアナウンスされていましたが vSphere 6.7 Update2 からは正式に「外部 PSC は非推奨」となったのでこれから導入される、バージョンアップされる方は注意が必要です。

External Platform Services Controller, A Thing of the Past
Deprecation of the external Platform Services Controller deployment model (60229)

次期バージョン vSphere 7.0(?) では外部 PSC が廃止になる様なので、それに向けてConversion Tool を利用してバージョンアップ時に組み込み PSC(Emmbedded PSC)に変更する事が推奨されます。
ちなみに、このバージョンから Conversion Tool が GUI 対応になりましたので、vCenter 6.7u2 へのバージョンアップ時に 組み込みPSC にコンバージョンするのが良さそうです。

1年前、vSphere 6.7 / 6.5u2 のリリース時に公式ドキュメントの記載で外部 PSC の利用を推奨しないような記載になった事をブログ記事にしましたが、
今回明確に「非推奨」とされたことで VxRail などのアプライアンス製品のデザインも若干変わってくると思われます。
vCenter 6.7 での組み込みPSC(Enbedded PSC)が(強く?)推奨されるようです
https://kwmtlog.blogspot.com/2018/06/vcenter67-enbedded-psc.html

2018年11月7日水曜日

vCenter 6.xの各バージョンの証明書インポート

vCenter Web Clientを利用する際、検証環境での利用がメインだったので
Web Clientを利用する際はいつも証明書の警告を無視して利用していましたがイベントのデモ用でお客様の目に触れる環境を久々に作った際に、6.5以降で証明書がだいぶ親切になっていたので覚え書き。

※証明書インポートしておかないと、データストアブラウザでのファイルアップロードに失敗したりもするので適用しておくことが推奨です。

手順の基本は以下KB参照(KBでは6.0.xの記載ですが6.5以降も基本同じで、一部親切仕様になっています)。
vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

まずはvCenter 6.0.xの画面から。
▲保護されていない通信」が目立ちます。
証明書のダウンロードは右下の「信頼されたルート CA 証明書をダウンロード」をクリック。

vCenter 6.5では「vSphere Client (HTML5) - 一部の機能」のリンクが追加されていますが基本的に同じです。


vCenter 6.7u1ではHTML5 vSphere Clientにフル機能が実装されたのでメインがHTML5、Flash版はFLEXという名称でサブになっています。
証明書のダウンロード手順は同じです。

ダウンロードしたZIPファイルを解凍すると、vCenter 6.0.xの時はKBの記載通り、
certフォルダに、 xxxxxxx.0 と xxxxxxx.r1 というファイルがあります。
 ここでは
xxxxxxx.0  -> xxxxxxx.0.crt
xxxxxxx.r1  -> xxxxxxx.r1.crl
と拡張子をそれぞれ追加します。


変更後は以下のようになります。

この拡張子の変更作業、vCenter 6.5以降ではZIPファイルを解凍するとWindows用にはフォルダ分けされていてすでに拡張子が適用された状態となり、即利用可能です。
だいぶ親切になりました。


 証明書のインポート手順は各バージョン同じで、crtファイル -> crlファイルの順でインポートします。
Windowsの場合はファイルを右クリックから「証明書のインストール」を選択。

保存先は作業端末なので他のユーザーも利用できるようにローカルコンピュータとしました。

「証明書をすべて次のストアに配置する」にチェックを入れ、「参照」から証明書ストアを選択します。

ここでは「信頼されたルート証明書機関」を選択します。

 「次へ」をクリックし、

「完了」をクリックすれば終わりです。


この操作を、crtファイル、crlファイルにそれぞれ行い、
複数のvCenterなどインポート対象がいくつかある場合は、同様の作業を繰り返します。

証明書のインポート後はWebブラウザを再起動すれば以下のようにすっきりとした画面が開きます。
※接続時にはIPアドレスではなく、FQDNでアクセスしてください。




vCenterもバージョンが進むにつれ、ちょっとしたところが改善されていますね。
お客様に見せる環境などでは見栄えも大事なので証明書は作業端末にインポートしておきましょう。

2018年10月24日水曜日

vCenter6.5のrootアカウントパスワードの失効とvCenter Server Applianceのアップグレード失敗

ここ数年のvCenter Server Appliance(vCSA) 5.5 や 6.0をデプロイすると、初期状態ではrootアカウントのパスワード期限が90日に設定されていました。
90日間越えてしまうとrootアカウントがロックされてしまいVAMI UIやSSHでのログインが不可となります。

この際は以下KBを参照し、LinuxOS側にシングルモードでコンソールログインしてrootアカウントのパスワードを初期化する必要がありました。
vCenter Server Appliance の root アカウントにログインできない (2069041)

vCSA 6.5からは初期状態のrootアカウントのパスワード期限が365日に延長されました。
私も油断していたのですが、検証環境のvCSA6.5が初期状態のままで365日経過してしまいましたが、その時に気づいた今までとの違いをご紹介します。
vCenter 6.5 root ユーザーのパスワードおよびパスワード有効期限の設定の変更

まず、vCSA 6.5の場合、パスワードの期限が切れてもアカウントロックされる事はなく、VAMI UI(https://<vCSA_IP-FQDN>:5480/)や、SSHでのrootログインが可能でした。
この辺りは以前のバージョンに比べるとだいぶ緩くなっています。

ただ、ログイン可能なのですが、VAMIのアカウント管理画面では以下のように、パスワードが過去の時間に切れたことが表示されます。

そして、パスワードの期限が切れている場合はVAMIでのパスワード再設定や、有効期限の無効化の設定は弾かれてしまいます。


先日はこの画面を確認せず、rootアカウントのパスワードが有効なものと思いこんで、vCenterのバージョンアップを実行したところ、以下のようなエラーで失敗しました。


最初はDB容量や空き容量のひっ迫などを疑ったのですが、色々調査するとrootアカウントがおかしいのでは?となり、確認したら有効期限が切れていました。
SSHにもVAMIにもrootでログインできたので気付くのに遅れてしまいました。

vCSA 6.5で有効期限の切れた状態のrootアカウントのパスワード変更は、VAMI UIからは実行できず、SSHかローカルコンソールでvCSAのLinux側にログインしてCLIで passwd
コマンドを投入して再設定します。



再設定後は問題なくvCSAのバージョンアップも成功し、VAMI UIでパスワードの再設定、有効期限の設定変更も可能になりました。


vCSAのバージョンアップ前にはrootアカウントの有効性を確認する事をお勧めします。

2018年7月19日木曜日

vCSA 6.5GA から 6.5U1までのデプロイが2018/7/1以降は不可なのでご注意を

最近いくつかvCSAがデプロイ出来ないのだが、という質問を受けているので改めて以下の不具合(?)のご紹介。

vCSA 6.5.0 ~ 6.5u1 のテンプレートに組み込まれた初期のrootアカウントのパスワードが365日でexpireする事が原因で、新規のvCSA 6.5のデプロイ、アップグレードなど失敗します。
デプロイはGUIでもCLIの場合でも失敗します。

この不具合はvCSA 6.5u1cで改修されていますので、今後も順次6.5u1a、6.5u1bもリリースから一年経過後に新規展開は出来なくなります。
vCenter 6.5u1c リリースノート


ここで注意が必要なのが、「リストア」の時です。
現在のvCSAはVAMI画面からのファイルベースバックアップがサポートされていますが、
取得したバックアップデータをリストアする際、本来はバックアップを取得したバージョンで戻すべきですが、同一バージョンに戻せなくなってしまう場合があります。
例)vCSA 6.5.0でバックアップを取得したが、vCSA 6.5u1cに戻す必要がある、など。

ドキュメントを読む限りはESXiのコンフィグリストアと異なり、厳密にBuild番号まで揃えなくても良さそうですが、vCSAが壊れてしまった非常時に安心してリストアするためにもvCenterはなるべく不具合修正された最新版で運用する事が推奨されます。

2018年6月21日木曜日

vCenter 6.5u2で修正されたvCenter 6.0 から 6.5u1 にかけてのクリティカルな不具合とPostgreSQLのDB破損のリスク

5月にリリースされたvCenter 6.5u2のリリースノートに、
いくつか組み込みDBのPostgreSQLが壊れる問題の修正について記載がありましたが、
それとは別に、ちょっと普通のKBとは異なる事象について書かれたKBがいくつかリリースされています。
不具合が確認されている対象が6.0~6.5u1と幅広いので、可能な限りvCenter 6.5u2へ更新したほうが良さそうです。

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html

vCenter 6.5u2で修正されたDB破損の不具合その1
The embedded vCenter Server Appliance database might be corrupted during a full backup
The VMware PostgreSQL database in the vCenter Server Appliance might be corrupted during a file-based full backup if the backup runs in parallel with a quiesced snapshot. The backup generates a backup_label file in /storage/db/vpostgres that corrupts the database if you revert to this specific snapshot. This fix prevents full backups to run during a quiesced snapshot.
This issue is resolved in this release.
vCenter 6.5u2で修正されたDB破損の不具合その2
The embedded vCenter Server Appliance database might be corrupted due to inconsistent snapshots of virtual machines
The PostgreSQL database in the vCenter Server Appliance might be corrupted due to inconsistent snapshots of virtual machines if the database runs on multiple partitions. This fix adds pre-freeze and post-thaw scripts to freeze filesystem partitions while taking a snapshot.
This issue is resolved in this release.
どちらもバックアップとスナップショットの取得で、バックアップしたDBやスナップショットが破損する場合があるとのことです。

上記の修正済みの不具合とは別で、リリースノートに記載はないが6.5u2で修正されたことになっている少し重そうなKBが出ていたので共有します。

一つ目はvCenter 6.5u2のリリースと同じ5/4に出された
vpxd crashes intermittently with an error "Signal 11 received, si_code 1, si_errno 0"
https://kb.vmware.com/kb/52472
2018/05/04

二つ目は6/19に出された
VPXD stops responding and reports error: "Double register of key: 'vm-XXX' and name:" (56353)
https://kb.vmware.com/kb/56353
2018/06/19

どちらもVPXDがクラッシュしてvCenterが運用不可になるというもので、KBの中に復旧方法などの記載は無く、事象が起きた時のログのサンプルと、
Resolution
This issue is resolved in VMware vCenter Server 6.5 Update 2
という記載があるだけです。
恐らく、起きてしまったら復旧は不可の問題かと思われます。

起きてからでは大変なので、定期的なvCenterのバックアップは取りつつ、早めにvCenter 6.5u2への更新が推奨されるようです。

ご参考まで。

2018年6月6日水曜日

vCenter 6.7 での組み込みPSC(Enbedded PSC)が(強く?)推奨されるようです


vSphere 6.7がGAされ2か月ほど過ぎましたが、改めて今後のvCenterのデプロイをどうしようか考える機会があり調べてたところ、Vmwareの公式ドキュメントの中でvCenter 6.7でのEmbedded PSCがやたらと強く推されていたのでご紹介します。


HTML5 vSphere Clientのエンハンスメントの話が多くて陰に隠れてしまいがちですが、
vCenter 6.7では上の図のように、vCenter組み込みの(Embedded)PSCでのリンクモードがサポートされるようになったのと、拡張などの制限が無くなりました。
PSC関連の変更点は以下の様なものとなります。

  • 組み込みPSCのvCenterでも最大10台のvCSAとリンク可能
  • vCenterHigh Availability (vCenterHA)も併用可能
  • 従来のESXi 8台以上は外部PSCの推奨は無しに
  • 6.0・6.5からのアップグレードの際に組み込みPSCへの変更が可能
  • 5月にリリースされたvSphere 6.5u2にも6.7の組み込みPSCのポリシーは適用


このEmbedded PSCでのリンクモード、従来のvSphere 6.0、6.5では以下のKBに記載があるように非推奨となっていて、VCAP6-DCVのDesign試験などにも普通に出てくる"仕様"でした。
※ 6.0がリリースされた当時はこんな制限なかったのですが、いつからか非推奨になってしまいました。




vCenter 6.7(vCenter 6.5u2も)からはこの制限が無くなり、Embedded PSCが自由に使えるようになる程度に考えていたのですが、
ドキュメントを読んでいくとVMwareがかなりEmbedded PSC構成を推している事が分かりました。
むしろ180度方針転換してExternal PSCを非推奨にしているようにも見えます。

公式ドキュメントに以下の記載があります。
vCenter Server および Platform Services Controller のデプロイ タイプ

■Embedded PSCについて

Embedded PSCの項目には「Platform Services Controller が組み込まれている vCenter Server をインストールすることには、次のようなメリットがあります」と、メリット推しの説明。

  • vCenterとPSC間のWebClient利用時の接続性と名前解決の問題が無い
  • 管理する仮想マシンが少なくて済む
  • バックアップもvCenterのみで良い

等のメリットがあります。

■External PSCについて

一方、External PSCの説明の項は、メリットの説明は無くデメリットの説明のみ…
外部 Platform Services Controller を使用する vCenter Server をインストールすることには、次のようなデメリットがあります

今までExtenal PSCをあれだけ推奨していたのに、180度方針が変わったようです。
vSphere 6.7の新規導入の他、バージョンアップ、移行を検討されている場合は、そのタイミングでEmbedded PSCタイプに変更も可能ですので今後は管理をシンプルにするためにEmbedded PSCでの運用を検討されては如何でしょうか?


過去30日でアクセスの多い投稿