Find Communities by: Category | Product

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



今月、VxRailチャンピオンクラブの勉強会にLTで参加した際に、皆さんいろいろとvSANやHCIの負荷試験についてその方法を検討されている様でしたので、私がよく使うVmware社のLabsツール、HCIBenchの使い方を紹介いたします。

あまり日本語で取り上げられていないので、これから試してみようという方、ぜひとも参考にして頂ければと思います。

 

※本投稿はvExperts Advent Calendar 2017 の12月17日の分の参加blogになります。

https://adventar.org/calendars/2248

 

※ 2019年に HCIBench 2.0 がリリースされましたので、その後のネタとして以下のブログにも記事をまとめていますので参照ください。

調べたこと 試したこと: HCIBench 2.0 のリリースと機能強化のご紹介

調べたこと 試したこと: HCIBench を利用したベンチマークテストのポイントと効率化(1)

調べたこと 試したこと: HCIBench を利用したベンチマークテストのポイントと効率化(2)


■ HCIBenchとは?

 

HCIBenchとはVmware Labs Filngsで公開されている負荷試験の自動化を目的とした無償のベンチマークツールです。

ツールの公開サイトはこちら → HCIBench

HCIBench-20171218_030.png

 

HCIBenchはベンチマークツールとしてもメジャーなVDBenchを利用したvSANデータストア・vSANクラスタへの負荷試験を自動化して、ベンチマークレポートの収集が簡単にできるようになります。

 

また、vSphere環境であればvSAN以外のHCI、NFSやiSCSI、FCのデータストアに対してもVDBenchの負荷試験利用が可能です。

VDBenchを利用して複数ホストに負荷試験を実施するのは割とテクニックがいるテストなので、これを自動化できるHCIBenchは非常に便利なツールです。

 

HCIBenchはOVA形式の仮想マシンで提供され、vSANの性能検証に欠かせないコントローラVM(PhotonOS)と、負荷用のテストVMテンプレート(PhotonOS)で構成されます。

テスト用のコントローラVMには以下のツールが組み込まれて配布されていますので、準備が非常に楽です。

  • Ruby vSphere Console (RVC)
  • vSAN Observer
  • Automation bundle
  • Configuration files

 

負荷用のPhotonOS VMテンプレートは、別途ダウンロードしたVDBenchが組み込まれ、クラスタに自動でクローン展開されて負荷を実行します。


■ HCIBench実行環境の注意事項


HCIBenchのコントローラVMをデプロイするvSphereクラスタと、負荷をかける対象のvSphereクラスタは同一L2のネットワークが適用されている環境が推奨です。

ユーザーガイドにはどのvSphere環境への展開でも問題ない、と記載されていますが負荷対象のクラスタとコントローラVMの配置されるクラスタは別環境である方が正しいレポートが取得できるので推奨です。

また、HCIでやりがちな構成として、コントローラVMと負荷をかける対象のテストVM、そしてvCenterが同じクラスタ、同じデータストア上に存在すると過負荷を掛けすぎてログが正常に取得できないなど残念な結果になることもあるので、

できれば負荷試験対象のクラスタとは別の場所にvCenterとコントローラVMを配置することが強く推奨されます。今回のVxRail環境は外部vCenterを利用しております。


一度パラメータ指定を間違えて、VxRailクラスタ全体の容量を食い潰し、管理VMのリソースを枯渇させて死亡したことがあります...

間違っても本番環境では実施しないでください。

 

※テストVMとの通信で従来コントローラVMのDHCPサービスを利用していましたが、HCIBench 1.6.5 以降のバージョンではStaticIPでテストVMに自動的にIPを割り当てて検証が可能になりました。StaticIP オプションを利用する場合は、Public NetworkとPrivate Networkを同一ネットワーク(同一VLAN)で設定します。詳細はユーザーガイドを参照願います。

 

■ HCIBenchの準備

 

事前にDLが必要となるものは HCIBench の公式サイトからダウンロードするOVAファイルと、VDBenchのバイナリです。

VDBenchはOracle社が公開しているオープンソースのベンチマークテストツールですので、以下のOracle社のDLサイトから入手します。

Vdbench Downloads

 

■ HCIBench コントローラVMの展開

 

HCIBench でダウンロードしたOVAをvSphereクラスタ上にデプロイします。

vSphereへOVAのデプロイ手順は通常のvSphereの操作手順に準拠しますが、注意点として必ずシンプロビジョニング形式でデプロイしてください。詳細はユーザーガイド(英文)にも記載があります。

 

HCIBench-20171217_005.png

負荷試験の実行結果を蓄積するとコントローラVMの容量が増加しがちなので、不要なデータは試験後に回収後、SSHでログインして削除してしまうことを推奨します。

 

HCIBench-20171217_011.png

デフォルトの仮想ディスクフォーマットがシックプロビジョニングになっている場合がありますので、特にVMFSにデプロイする場合は必ずシンプロに変更してください(NFS・vSAN上にデプロイする場合は結果的にシンプロビジョニングでデプロイされます)

 

HCIBench-20171217_013.png

HCIBenchのネットワークは、WebUIへのアクセス用のパブリックネットワークと、テストVMとの通信用のプライベートネットワークの二つを指定します。

プライベートネットワークはDHCPがすでに利用できる環境であればDHCPをそのまま利用し、DHCPがない場合はプライベートとパブリックを両方とも同じネットワークに指定しておきます。HCIBench 1.6.5以降は自動でStaticIPをこのネットワーク上に設定して負荷試験が実行できます。

 

HCIBench-20171217_015.png

HCIBenchのWebUIアクセス用のネットワーク情報とrootのパスワードを設定します。

ここで指定したrootパスワードはWebUIへのアクセスと、コントローラVMへのSSHアクセスなどでも利用可能です。

 

HCIBench-20171217_016.png

準備が完了したらデプロイを続行します。

シンプロビジョニングなので初期のストレージ消費量は2GB弱と非常にエコです。

 

HCIBench-20171217_020.png

デプロイ完了後、パワーオンしてIPへの疎通を確認してください。



■HCIBenchの初期設定


HCIBenchのWebUIは http://<HCIBench IP>:8080 でアクセスできます。

rootパスワードを入力してください。

HCIBench-20171217_022.png

 

また、ポート8080をつけない場合は、負荷試験結果などが保存されているディレクトリツリーを確認できます。

HCIBench-20171217_029a.png


WebUIにログインできたら負荷対象のvSphereクラスタ情報の入力と、VDBenchのバイナリをアップロードします。

少し画面が長くなりますが、以下のような設定項目を埋めます。

HCIBench-20171217_023.png


ポイントとなる個所を簡単に説明します。


▼ 負荷対象vSphere環境の指定

HCIBench-20171217_031a.png


vCenter、ログイン情報、データセンター、クラスタの情報欄はvSphere Web Clientなどで表示されているインベントリ名を正確に入力します。


▼プライベートネットワークの指定

HCIBench-20171217_029.png

ネットワーク欄はコントローラVMのデプロイ時に指定したプライベートネットワークと同じL2ネットワークのポートグループ名を入力します。(vSS、vDSのどちらでも可能です)

「Set Static IP ~~」のチェック欄は、ネットワークでDHCPが有効でない場合にチェックを入れてください。

その場合、指定するネットワークはHCIBench コントローラVMのパブリックネットワークを同じL2ネットワークを指定します。


▼負荷対象データストアの指定

HCIBench-20171217_032a.png

データストア欄はvSANの様に1クラスタ1データストアであれば、上の様に1行でデータストアのインベントリ名を入力します。


HCIBench-20171217_033a.png

通常のVMFS(FC・iSCSI)やNFSのデータストアを利用する場合で、複数データストアに均等な負荷をかけたい場合は1行毎に入力します。

ここに入力されたデータストアに対して均等に仮想ディスクが作成され、負荷試験が実施されます。


「Clear Read/Write Cache Before Each Testing」のチェックボックスは、この後の設定メニューの負荷対象ホストを個別にアクセス指定する時のみ有効にできます。

ただ、vDSのポートグループを利用する場合には負荷対象ホストを個別指定はできないので、今回はこのチェックは利用しません。


▼負荷対象ホストの指定

HCIBench-20171217_034a.png

HCIBenchは指定しなければクラスタ内の全ホストに対して負荷試験を実施します。

特定ホストのみに負荷試験を実施したい場合などは上記のメニューで指定します。ただし、先にも述べたようにvDSのポートグループを指定している場合はこのオプションは利用できません。


▼テストVMの構成指定

HCIBench-20171217_035a.png

 

テストVMの台数、テストVM1台毎の仮想ディスクの数、および仮想ディスクのサイズを指定します。

「EASY RUN」を選ぶとvSANデータストアの負荷試験用に自動でクラスタの情報を読み取り、テストVMの台数、仮想ディスクの数などが指定され簡易テストが実行できます。

初回の動作確認を兼ねて、「EASY RUN」は一度実施してください。


複数のテストを続けて実行する際などは「Re-Use The Existing VMs If Possible」にチェックを入れてテストVMの再利用が可能です。


▼VDBenchバイナリのアップロード


Vdbench Downloads からDLしたバイナリをアップロードします。

HCIBench-20171217_036.png

「ファイルを選択」ボタンからDLしたバイナリを指定します。


HCIBench-20171217_038.png

 

▼設定バリデーションの実施

HCIBench-20171217_036a.png


設定入力が完了したら「Save Configuration」をクリックし、「Validate」を実行します。

HCIBench-20171217_037a.png

バリデーションがすべてパスしたことを必ず確認してください。

HCIBench-20171217_038a.png


■ HCIbenchを利用した負荷試験の実行


準備が完了したら「Test」をクリックして負荷試験を実行します。

負荷試験の内容にもよりますが、「EASY RUN」であればテストVMのデプロイから負荷試験実行で1時間半ほどかかります。


HCIBench-20171217_059.png

HCIBench-20171217_051.png

負荷試験の一連の動作はすべて自動化されており、必要台数分のテストVMのデプロイ、仮想ディスクの作成、負荷の実行が行われます。

環境のセットアップさえ完了すれば、負荷試験の間は別の仕事に時間を割り当てられるし、業務の終了際に試験を実行して翌朝確認なども可能です。


HCIBench-20171217_018a.png


■ HCIBench 実行結果の確認

HCIBench-20171217_036a.png

テストの完了後、「Result」をクリックするとWebUIで結果の確認ができます。

「Save result」をクリックするか、以下の画面でZIPファイルをダウンロードすることで負荷試験の結果をローカルに保存できます。

HCIBench-20171217_039a.png

負荷試験のテスト名フォルダをクリックすると、詳細データをWebUI上で確認できます。

HCIBench-20171217_026a.png

※EASY RUN はvSANデータストアへの標準的な負荷を想定して、ブロックサイズ4K / R:W=7:3 / 100%RandomIO / 4スレッド で実行されます。


テキストファイルにはベンチマーク結果のサマリが含まれているので、ここを確認すれば試験結果がすぐにわかります。


HCIBench-20171217_027a.png

サマリレポートですが、IOPSやスループット、IO遅延など必要な情報は一通り確認できます。

また、クラスタでのCPU利用率や、vSANのKernel側でのCPU負荷も確認ができます。



それぞれのテストVM毎のVDBenchの結果を確認したい場合はフォルダの中の個別ファイルでチェックできます。


HCIBench-20171217_040a.png

個別のテストVM毎のレポートも全て閲覧可能です。

また、「iotest-vdbench-XXvm」フォルダの配下には、vSANObserverの情報が格納されており、

「stats.html」を開くとvSANObserverのViewで詳細なvSANコンポーネントのレポートを確認することができます。

HCIBench-20171217_041a.png

HCIBench-20171217_042a.png


■HCIBenchの活用・応用編


ここまで、HCIBenchの「EASY RUN」を利用した標準的なテストをご紹介しましたが、

HCIBenchはVDBenchの負荷パターンのパラメータファイルを作成したり、作成済みのパラメータファイルをインポートすることで多様な負荷試験の実行が可能です。

VDbenchのパラメータファイルを初見で1から作れと言われても非常に面倒なのですが、自動で多数のファイルを簡単に作成できるのも大きなメリットです。

HCIBench-20171217_043a.png


負荷パターンは以下の様な項目で指定します。

HCIBench-20171217_044a.png

ここで注意しなければいけない点としては、仮想ディスクの数(Number of Disks to Test)は、必ずテストVMの指定項目で設定した数と同一にすること、負荷試験実施時間(Test Time)は、Reporting Intervalの倍数にすること、Warmup TimeはTest Time以下に指定することくらいです。

Warmup Timeの指定は負荷試験の開始から指定時間は記録されない(暖機運転)となります(オプション)。

Reporting Intervalの指定は長時間の負荷試験中にログが大量になることを防ぐために記録のインターバルを指定します(オプション)。


私の場合は、Read/Write比とRandom/Sequential比、IO ブロックサイズを少しずつ変更し、データストアに対して一括で負荷を掛けられるようにパターンを作り、前パターンの試験を一気に実行できるようにしています。

HCIBench 1.6.5.1ではブロックサイズは以下のパターンで指定できます。

HCIBench-20171217_007a.png


より細かい、VDBenchのパラメータを作成したい場合は、手動で作成したファイルを読み込ませる事ができるので、VDBenchを熟知した方はそちらのほうがやりやすいかもしれません。

 

作成したパラメータはそれぞれのパターンで名前がついていますので、個別のパターンを指定して負荷試験の実行もできますし、「Use All」を選択することで、登録した全パターンの一括負荷試験も可能です。

HCIBench-20171217_009a.png

※作成したパターンファイルはコントローラVMの [ /opt/automation/vdbench-param-files ] ディレクトリに格納されていますので、SCPなどでバックアップもできますし、SSH接続してviなどで直接パラメータファイルの編集も可能です。

HCIBench-20171217_022a.png

自動生成されたパラメータファイルを編集して、VDBenchの追加パラメータを含めることも可能です。


HCIBench-20171217_046a.png

最後に、負荷試験前の仮想ディスクの初期化(ZERO埋め or Randomデータ埋め)の指定や、

パラメータファイルで指定した試験実施時間の上書き変更、

試験実施後のテストVMの削除の有無を指定できます。


※試験が失敗したときに再度デプロイ、仮想ディスクの初期化が時間がかかるので、あえてチェックする必要はないかと思います。

 

 

■ まとめ

 

HCIBenchは今まで面倒だったストレージ負荷試験を均質なパラメータで、どんなクラスタにも一括で実施できることができます。

ベンチマーク毎に実行環境やパラメータを変えるのではなく、複数の環境を同じパラメータで試験する事で性能比較が容易になることがHCIBenchの大きなメリットとなります。

 

無償で使え、面倒だったVDBenchを自動化してストレージ負荷試験を実行できる強力なツールですので、ぜひ活用してみてください。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.5の追加機能、リリースノートなどを確認すると

VxRail Manager自体のプロキシ設定のサポートや、ノード拡張時に一度に同時6台を追加拡張できるバッチ拡張モードなどが加わっています。

バッチ拡張モードについては後日、そのレポートを投稿しようと思いますが、

地味にESXi側にも新しい機能が加わりましたのでご紹介します。

 

■ 追加されたサービス


VxRail 4.5のvCenterで各ESXiホストのサービスを見ると、以前とは異なるVxRail関連のエージェントにマニアックな人は気づくかもしれません。

VxRail4.5-UI-20171207_001.png

 

VxRailで以前から

  • loudmouth (EVO:RAILの頃からあるVxRail Manager エージェント)
  • vxrail-election (VxRail 4.0で追加された初期導入時の1st Node選定用プロセス)

の二つが存在していましたが、VxRail 4.5において追加の

  • vxrail-platform-service
  • vxrail-platform-service-util

が加わりました。

 

アップグレードの時にバイナリに含まれていたパッケージがこれら4つのサービスを構成しています。

VxRail4.5-Agent.png

 

■ VxRail Platform Service の役割


新しい二つのサービスが何をしているか、ですがサービス名が示す通り、ESXiの基盤の管理を行うものの様です。

  • vxrail-platform-service
  • vxrail-platform-service-util

このうち、-utilの方はバージョンアップなどの際に利用される様で、詳細が確認できていないのでこちらはいずれ確認次第に紹介します。

 

vxrail-platform-service の実態は、実はesxcliコマンドのオプションとして「esxcli vxrail ~~」が加わっています。

下にESXiにSSHで接続した際のコマンドの画面を貼りますが、ESXiの核となる管理CLI、esxcli にvxrail というオプションが追加されているのが確認できます。

VxRail4.5-UI-20171207_003.png

 

今のところ、ハードウェアの構成(マザーボード・ドライブ情報など)やファームウェアの状態確認などの機能が利用できます。

VxRailが単なるvSAN Ready Nodeの亜種ではなく、Vmwareの核となるESXiとも密に連動したアプライアンスであるという方向性がこの辺りのアップデートからも感じることができます。

 

※個々のオプションの紹介は省きますが、VxRailを利用していて興味ある方はesxcliのオプション詳細が記載されたxmlが以下のファイルなので、こちらを確認してください。

/usr/lib/vmware/esxcli/ext/esxcli-vxrail.xml

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.5.0が9月末にリリース、10月に入ってVxRail 4.0.070がリリースされSupport EMCにもアップグレード用バイナリがいくつか上がっているので、検証した際の手順と注意点を簡単にまとめたいと思います。


VxRail アプライアンスの魅力でもある簡単バージョンアップ機能、vSphere 6.0u3 から vSphere 6.5u1へのメージャーアップグレードが8クリックくらい(ワンクリックではない)で完了してしまいます。

 

※ 年末年始のシステムメンテナンス時にアップグレードを計画されている方もいらっしゃると思いますが、4.0.xから4.5.xへのメジャーアップグレードに対応したバージョン次のVxRail 4.5.1xxとなるようです。まずはVxRail 4.0.400に更新して次のリリースを待ちましょう。

 

※ 作業の公式手順はSolveDesktopの手順書、リリースノートを必ず正としてください。

※ VxRail 4.0.070へのメジャーアップグレードは、2017年12月6日現在、VxRail 4.0.310からのアップグレードが正式サポートとなります。


★DECNでVxRailのアップグレードに関しての情報、注意点などがまとまった以下のスレッドが有用ですのでアップグレードの計画時にチェックをお勧めします。

VxRail Upgradeに関する注意点

 

■ アップグレード用バイナリのダウンロード


まずはバイナリを落とします。Support EMCにログインして、VxRailのダウンロードページの【Full Release】欄のXX Composite for XXがアップグレード用パッケージです。

https://support.emc.com/downloads/39970_VxRail-Appliance-Series

for4.0.310_002.png

今回は 4.0.310からのアップグレードなので

VxRail 4.5.070 Composite Upgrade Package for 4.0.310

こちらを選びます。

ダウンロードしたZIPファイルの中身に何が含まれているかは、先日の投稿を参照ください。

VxRailを構成するコンポーネントのバージョンについて

 

■ 作業前の事前注意・準備情報

 

  • DNSサーバにVxRailの関連コンポーネント(VxRail Manager、vCenter、PSC、各ESXiホスト)のFQDNを登録
    VxRail 4.5.xから、従来vCenter Server Applianceにインストールされ機能していた内部DNS(DNSMASQ)が利用できなくなります。
    そのため、必ずDNSサーバにコンポーネントのFQDNを登録しておく必要があります。
  • vCenter 6.0 -> vCenter 6.5への移行用 一時IPアドレスの用意
    vCenter 6.5は従来のSUSE LinuxベースからPhoton OSベースに大きく変わっているため、仮想アプライアンスが再デプロイされ、既存のデータが移行されます。その時に必要となる一時IPアドレス(既存のvCenterなどと同じセグメント)が一つ必要となります。
  • 当然ながら、アップグレード前はvCenter Web Client側でも各ホストが正常であることを確認しておきます。

 

■ VxRail ManagerへダウンロードしたZIPファイルをそのままアップロード

 

VxRail Managerにログインして、構成メニューから「ローカルアップグレード」をクリックしてZIPファイルをアップロードします。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_043.png

 

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_052.png

Quantaモデルの場合は適用されるものが、VxRail Manager、vCenter Server Appliance、vSphere ESXiの三つとシンプルです。

※実際はESXiの中にVxRail Manager用のVIBや、VxRail Platform Service用のVIBも含まれています。

 

参考に、DELLモデルの場合(以下のキャプチャは 4.5.0 -> 4.5.070へのものですが)は、DELL PowerEdge用の各モジュール一式が更新されます。

VxRail4.5-4.5.070_Upgrade-20171030_021.png

 

■ アップグレードの実行

 

「続行」ボタンをおしてアップグレードを開始すると、早速何か「additional information」を入れろを青帯が表示されます。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_056.png

 

ここで必要になるのが、事前準備の項で記載した、vCenterのデータ移行用の一時IPアドレスと、FQDNを登録したDNSサーバのアドレスです。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_058.png

 

アップグレードが進行すると、自動的に新しいPhoton OSベースのvCSA、PSCがデプロイされ、既存の設定・データが移行されます。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_065.png

vCenterのアップグレードが完了して、サービスが起動すると新しいvCenter 6.5のWeb Clientにアクセスできるようになります。

画面を見ると、Photon OSベースのvCSA以外に、以前のvCSAなどに(legacy)と書かれ、シャットダウンされています。

※正常移行が確認できた後、これらは削除可能です。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_099.png

 

ESXiホストなどのアップグレードも終わり、4Node構成のVxrail アプライアンスであれば2時間ほどでアップグレードは完了です。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_100.png

 

■ アップグレード後のVxRail 4.5のチェック

 

VxRail Managerの画面を見てると、殆ど何も変わってません(笑)

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_102.png

パフォーマンスViewも同じですね

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_104.png

 

構成設定のあたりをみると「プロキシの有効化」が追加されています。一応VxRail 4.5の追加項目の一つです。ちょっと地味ですが...

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_106.png

 

VxRail 4.5の注目アップデート内容はやはりvSphere 6.5u1に大幅アップグレードなので、やはりメインはWebClientのHTML5対応、でしょうか。当然VxRail環境でも利用可能です。

※vSphere 6.5u1でのHTML5 vSphere Client自体が一部の機能制限がありますが、通常の仮想マシン運用では不自由する事はないと思います。

 

vCenterをブラウザで開くと従来のFlashとHTML5が選べるようになりました。

VxRail4.5-HTML (2).png

HTML5 vSphere Clientを選択すると新しいUIのvCenter環境が利用可能です。

VxRail4.5-HTML (1).png

 

 

今回のアップグレードに関しての記事は以上となります。

vSpehre vSANクラスタのアップグレードもほぼ自動で、運用負担なく実施できてしまうのがVxRail アプライアンスの大きな魅力かと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。




年末年始の計画メンテナンスでVxRailのバージョンアップを計画されているお客様からの質問がちらほら来ているので、2017年12月6日時点でのそれぞれのアップグレードパスをまとめました。

2017年12月5日にVxRail 4.0.400もリリースされましたので、どのバージョンから直接更新が可能か確認する際に参照ください。

 

※ DELL EMCの公式情報ではなく、あくまでもリリースノート、KBやSolveDesktopでの情報を整理した覚え書きです。作業計画時には必ずSolveDesktopの手順書を生成してそちらを正として確認ください。

各バージョンに含まれるコンポーネント情報は以下KB参照

https://support.emc.com/kb/495337

 

アップグレードパスは2018年2月現在、VxRail 4.5 リリースノートの巻末に記載がありますので最新情報はそちらを確認してください。

https://support.emc.com/docu86659_VxRail_Appliance_Software_4.5.x_Release_Notes.pdf

https://support.emc.com/docu80740_VxRail_Appliance_Software_4.0.x_Release_Notes.pdf

※ 表が見切れている時は右にスクロールしてください。

ターゲットバージョン
3.03.54.0.04.0.1004.0.1324.0.2004.0.1314.0.3004.0.3014.0.3024.0.3104.0.4004.5.04.5.0704.5.1xx
3.0-要SR-------------
3.5--○ ※1-----------
4.0.0---○ ※3○ ※3○ ※3-○ ※3○ ※3------
4.0.100----○ ※3○ ※3-○ ※3○ ※3-----
4.0.131----○ ※3○ ※3-○ ※3○ ※3-----
4.0.132-----○ ※3-○ ※3○ ※3----
4.0.200-------○ ※3○ ※3----
4.0.300--------○ ※3---?
4.0.301------------?
4.0.302-------------?
4.0.310-----------○ ※3○ ※2?
4.0.400--------------?
4.5.0-------------○ ※2?
4.5.070--------------?
4.5.1xx---------------

 

注意事項

  • ※1:VxRail 3.5 から VxRail 4.0.x へのアップグレードは、VxRail Manager 4.0.100 の個別パッケージでVxRail Managerを更新し、その後にVxRail 4.0.302のアップグレードパッケージを適用可能。
  • ※2:2017年12月現在、VxRail 4.0.310 から VxRail 4.5.070へのメジャーアップグレードはDELL EMCへSRでサポート依頼を上げる必要がある。また、VxRail 4.0.30x から 4.5.xへのメジャーアップグレードは次期バージョンのVxRail 4.5.1xxでのサポート予定となりますので注意して下さい。
  • ※3:2017年12月現在、ターゲットコードとしてVxRail 4.0.302、4.0.400、4.5.070がSupport EMCサイト上でバイナリが公開されているため、ターゲットコードへの更新が推奨。
  • アップグレード手順は必ず公式のSolveDesktop資料を確認する事。
  • 3Node構成のアップグレード時には事前のクラスタ正常性チェックプロセスをスキップさせる必要があるので注意。
  • VxRail 4.0.310 は 2017年12月時点の出荷時のみの適用バージョンのため、以前のバージョンからVxRail 4.0.310にはアップグレードパスは無し。
  • VxRail 4.0.400 は VxRail 4.0.132 以降のバージョンから直接アップグレードが可能。
  • VxRail 4.0.x から VxRail 4.5.xへのメジャーアップグレードはVxRail 4.0.300 以降で適用可能。ただし、2017年12月6日時点ではVxRail 4.0.310からのみサポートとなり、
  • VxRail 4.5.070のアップグレードパッケージは、4.0.xからのアップグレードパッケージと、4.5.0からのアップグレードパッケージでバイナリが異なるので注意。
  • VxRail Managerを利用したインターネットアップグレードは、最新の同一メジャーバージョンがターゲットとなるので、直接アップグレードがされない世代差の更新がある場合はローカルアップグレードが必要です。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


最近VxRailのバージョンアップについてよく聞かれるので、自分用に各情報のリンクをまとめました。

 

■ VxRailの公式ドキュメント、KB、ダウンロードパッケージなどのURL

Support EMCのアカウントで要ログイン

https://support.emc.com/products/39970_VxRail-Appliance-Series

 

■ VxRailのバージョンアップ用のパッケージの入手方法

Support EMCのダウンロードページから入手可能

https://support.emc.com/downloads/39970_VxRail-Appliance-Series

 

Full Release の + 印を開き、「VxRail <Version> Composite Upgrade Package」というZIPファイルがバージョンアップ用パッケージです。

VxRail_001.png

例えば、VxRail 4.0.3xⅹ から 4.5.070へのアップグレードパッケージ「VXRAIL_COMPOSITE-4.5.070-6881819_for_4.0.zip」の中には、

以下のようなVxRailを構成するコンポーネント(ESXi、vCenter、VxRail Manager、BIOS、Firmwear、VxRail agent、Device driver、etc)など、必要なものすべてが含まれています。

 

VxRail Manager 4.5.070-6881818

  • VMware vCenter Server Appliance 6.5.0-6671409
  • ESXi 6.5.0-6765664 (Dell)
  • Dell ptAgent 1.4-1.10264 (Dell)
  • VxRail Platform Service 1.0.0-60 (All platforms)
  • BIOS 2.5.5 (Dell)
  • Disk Controller 13.17.03.05 (Dell)
  • DELL iSM 2.5.1.ESXi600-0000 (Dell)
  • HBA driver 14.15.00.00-1OEM.650.0.0.4598673 (Dell)
  • VxRail VIB 4.5.070-6881818 (All platforms)

 

BIOSやファームウェアも一括でアップグレードできるHCI製品は珍しいです。

 

ちなみにZIPファイルは解凍せずに、そのままVxRail Managerにアップロードして利用しますが、中身は以下のようになっています。

VxRail_002.png

 

上記のZIPファイルを手動でアップロードしてアップグレードする方法はローカルアップグレードと呼ばれています。

手順などは過去いくつか投稿しているので参照ください。

 

インターネットアップグレードが可能な時は、VxRail Manager上から適用が可能です。

詳細はこちらの以前の投稿を参照

 

■ VxRailの各コンポーネントに含まれるソフトウェアのバージョン一覧、サポートマトリクス。

各バージョンのリリースノート、または以下のKBに集約されています。

 

※ 2018/5/18 追記 : KBの構成が変更となりました。詳細は以下のサポートマトリクスと、外部vCenter利用時のサポマトを参照ください。

VxRail versions and each component code levels (通常のサポマト)

https://support.emc.com/kb/495337

 

VxRail and external vCenter interoperability matrix(外部vCenter利用時のサポマト)

https://support.emc.com/kb/520355

 

 

vSphereのパッチ公開に合わせて順次VxRailもバージョンアップしているので、なるべく最新で安定したバージョンで運用する事が推奨です。

2017年11月30日時点では以下のようなバージョンの組み合わせとなっています。

※最新は常に上記のKBやリリースノートで確認してください。

 

VxRail ReleaseSystem VersionEsxi (Version - Build #)VxRail managervSANInternal vCSAExternal vCSA
MinRecommendedMax
3.03.0.0.34822486.0 U1b - 33801243.0.0.3482248 (VRMe)6.16.0 U1bN/AN/AN/A
3.53.5.0.39368716.0 U2 - 36207593.5.0.39368716.26.0 U26.0 U26.0 U2 or later6.0 U3b
4.04.0.0-46311856.0 U2 P03 - 41922384.0.0-46311846.26.0 U26.0 U26.0 U2 or later6.0 U3b
4.0.000014.0.00001-46311856.0 U2 P04 - 46009444.0.0-46311846.26.0 U26.0 U26.0 U2a or later6.0 U3b
4.0.1004.0.100-49076976.0 U2 P04 - 46009444.0.100-49076966.26.0 U2a6.0 U26.0 U2a or later6.0 U3b
4.0.1324.0.132.00000-51281786.0 U3 - 50505934.0.132-51281776.26.0 U36.0 U26.0 U3 or later6.0 U3b
4.0.2004.0.200-52341436.0 EP07a - 52249344.0.200-52341426.26.0 U3a6.0 U26.0 U3 or later6.0 U3b
4.0.3004.0.300-56294296.0 P5 - 55726564.0.300-56294286.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3014.0.301-60265196.0 P5 - 55726564.0.301-60265186.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3024.0.302-68297786.0 EP11 - 67650624.0.302-68297776.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3104.0.310-61371156.0 P5 - 55726564.0.310-61371146.26.0 U3b6.0 U36.0 U3b or laterN/A
4.54.5-66077446.5 U1 - 59693034.5-66077436.6.16.5 U16.5 U16.5 U1N/A
4.5.0704.5.070-68818196.5 EP02 - 67656644.5.070-68818186.6.16.5 U1a6.5 U16.5 U1aN/A

 

次の投稿ではVxRail 4.0.x -> 4.5.x へのメジャーバージョンアップグレードについて紹介します。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail 4.5 の検証している中で、いつもDNSサーバの設定は入れて実施しているのですが、

隔離環境用にDNSサーバのアドレスを未指定でセットアップしようとしたところ、

VxRail 4.5 ではこの項目を空欄にすることが出来なくなっていました。


また、VxRail 4.0以前で、外部DNSを利用せずにセットアップした環境(vCSAのDNSMASQサービスを流用していた場合)も、VxRail 4.5へのアップグレード時に外部DNSサーバの準備が必要となります。

※詳細は次のコミュニティのスレッドにコメントしました(こちら

Re: Vxrail構築_DNSサーバを使用しない方法(運用含め)

 

現状、作業PCに簡易的にDNSサーバを立てるなどの準備が必要になりそうです。

VxRail4.5.0_20171113_001.png

 

英語UIだと以下のメッセージ。

VxRail4.5.0_20171113_002.png

 

VxRail 4.5のPoCを隔離環境で実施する場合や、隔離環境での事前セットアップには注意が必要そうです。

ご注意ください。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※2017/10/27 修正版リリース済み


今週週明け、検証環境でChromeでWeb Clientが使えなくなってしまい、普段利用していないFirefoxだと大丈夫だったのでしばらくすれば直るだろうと思ってましたが、WilliamさんのBlogでも取り上げられていました。

http://www.virtuallyghetto.com/2017/10/shockwave-flash-has-crashed-workaround-for-vsphere-web-flash-client.html

 

20171016_017.png

同じ事象でアクセスできない方はFlashが最新になっているとクラッシュするので、しばらくはブラウザのアップデートを控えるか、リスクがありますがKBを参照して古いバージョンのFlashに切り替えるなどワークアラウンドが必要となります。


※2017/10/18 追記 : 公式にKBも出たようです

https://kb.vmware.com/kb/2151945

 

※2017/10/23追記 : Flash Player 27 Betaを入れて回避する方法がKBに追記されました。


※2017/10/27追記 : 面倒を強いられていたWeb Clientのクラッシュ問題。

 

Flashの最新版(27.0.0.183 or later)がリリースされ、解決されました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※ 前編の「VxRail 管理系VMのバックアップ・リストア方法【バックアップ取得編】」の続きです。

 

前編で取得したバックアップデータを利用して、VxRailの各コンポーネントの復旧を試してみます。


※2018/04 Update:

2018/04現在のVxRailバージョンでは、VxRail Managerなどのバックアップ手順が公式にリリースされました。SolveDesktopなどの手順を必ず確認してデータ保護対策を実施してください。

 

■ VxRail Manager のリストア

 

VxRail Manager VMが起動しなくなってしまった、壊れてしまったという場合は直近のイメージバックアップを戻すことで元通りになります。

※構成ファイルだけを戻したい場合などはFLRで抜き出すか、別途SCPなどで取得しておくことが推奨です。

 

まず、障害状態を作るためVxRail Managerを停止します。

FILESV01_Vxrail4.0.301_20170829_139.png

 

次にvDPのリストア画面からインベントリ名を別名で指定して直近のVxRail Managerを復元します。

FILESV01_Vxrail4.0.301_20170829_140.png

 

リストアオプションは以下の様に別名を指定します。

FILESV01_Vxrail4.0.301_20170829_146.png

 

リストア処理が開始されるとWeb ClientのインベントリにVMが追加され、ステータスが確認できます。

また、DataDomainからはリストアのトラフィックが流れているのが確認できます(リストア時は重複排除データが"復元されて"から流れるので実際のサイズのトラフィック負荷がかかります)

FILESV01_Vxrail4.0.301_20170829_158.png

FILESV01_Vxrail4.0.301_20170829_156.png

 

リストアが完了したら起動します。MACアドレスの競合は、元のVxRail Managerが残っているので表示されています。

今回は無視で構いません。

FILESV01_Vxrail4.0.301_20170829_160.png

 

起動後、しばらくしてVxRail Managerのサービスが立ち上がれば、リストアしたVxRail Managerでも問題なくシステム状態が確認できます。(今回1ホスト停止いていますが、その状態も反映されているのが確認できます。)

FILESV01_Vxrail4.0.301_20170829_161.png

 

VxRail Managerのイメージバックアップからのリストアは以上です。

それほど難しくなく戻すことが可能です。

 

 

■ vCSAのリストア

 

vSAN上にvCSA自身が稼働していると、vCSAが起動できなくなるなど重大障害が発生した際のリストアにコツが要ります。

ポイントは以下となります。

 

  • vDPはvCenter自身がダウンしているとWeb ClientのvDPコンソールが利用できないため緊急リストアモードでESXiホストに直接VM(vCSA)を戻す必要がある。
  • しかし、vDPの緊急リストアモードでリストアする際にはESXiをvCenterから明示的に「切断」しなければならない。(C#のvSphere Clientではなく、HTML5のHost Clientでの実施を推奨)
  • さらにvDPの緊急リストアでvCSAをリストアしても、10G 2portでvDSが構成されるVxRailの場合、デフォルトの設定のままでは「vCenterがダウンしているとvDSの新規ポートアサインが出来ない」ので、リストア後のvCSAがネットワークに接続できない...orz
    • そのため、バックアップ編にも書きましたが、VxRailの運用時にはvDSに「短期バインド(Ephemeral Binding)」のvCSAリストア時用ポートグループを作成しておくことを推奨します。
  • 短期バインドのポートグループがない場合、vCSAをネットワークに接続するためにはvDSではなく、新規にvSSを作成し10G 2portのうちの片方をvDSから外しvSSに付け替えなければならない(DELL PowerEdgeモデルはNDCの1Gポートがあるので、上位スイッチ次第ですがそれを利用する事が出来るので復旧が楽です)。
  • vSSにvCSAを接続し、通信が可能になると再びvSANクラスタ、vDSがvCenter管理下になりますので、緊急リストア様にvCenter管理下から外したESXiをvCenterに際せず属し、vMotionで正常な他のホストに戻すことができます。
  • vCSAの移行後、vSSを削除し、vDSにポートを戻すことが出来ます(変に設定をいじったのが気になる場合はFRU用のイメージでホストを初期化してVxRail Managerでノード交換の手順で再追加という荒業も出来ますが、たぶん公式は非サポート)

 

テキストで書く複雑ですが、vCSA on 時分自身のvSAN with vDS の構成だと復旧時にこのような搦め手が必要です。

※PSCのみの障害の時は、緊急リストアこそ必要ですが、vCSAが生きているのでvDSに接続できるため、それほど手間はかかりません。

 

 

キャプチャ付きで以下説明します。

 

まず、障害を模す為にvCSAを停止します。

FILESV01_Vxrail4.0.301_20170829_166.png

 

Web Clientは利用できなくなりますので、仮想マシンのリストアのためにvDPのコンソールにアクセスします。

緊急リストアのタブを確認すると、今vDPがいるホストが確認できます。

FILESV01_Vxrail4.0.301_20170829_176.png

 

対象のESXiホストのHTML5 Host Clientにアクセスします(Host ClientはESXi 6.0u1以降で標準で組み込まれています)

FILESV01_Vxrail4.0.301_20170829_170.png

 

rootアカウントでログイン後、vCenterからの切断を実行します。

FILESV01_Vxrail4.0.301_20170829_177.png

 

※ここでC#のvSphere Clientにある「vCenter Serverからのホストの関連付け解除」は実施しない方が良いので、上記のHost Client側での操作を推奨します。

FILESV01_Vxrail4.0.301_20170901_001.png

↑ 何度も切り分けした訳ではないのですが、この操作は後が面倒になった事があるので避けた方が良いです。

 

Host Clientを利用してvCenterからホストを切断状態にします。

FILESV01_Vxrail4.0.301_20170829_178.png

 

この状態で緊急リストアが可能になります。

最新の正常なvCSAのバックアップを選択します。

FILESV01_Vxrail4.0.301_20170829_180.png

 

ホストのroot情報を入力し、インベントリ名をオリジナルから変更、リストア先のデータストアをvSANデータストアで指定します。

FILESV01_Vxrail4.0.301_20170829_181.png

FILESV01_Vxrail4.0.301_20170829_182.png

 

リストアが開始されます。

FILESV01_Vxrail4.0.301_20170829_186.png

FILESV01_Vxrail4.0.301_20170829_183.png

 

■ vCSA接続用の仮vSSの作成


正常運用時にvDSに「短期バインド(Ephemeral Binding)」のポートグループを作成していればリストア完了後、そのポートグループに接続することができますが、作成していない場合はvCSAがvDSのポートグループに接続できないので別途vSSを作成し、管理ネットワークを割り当てる必要があります。

※vCenterの管理下にないvDSに新規VMの接続は出来ないため、「接続中」のチェックが有効になりません。

FILESV01_Vxrail4.0.301_20170829_197.png

FILESV01_Vxrail4.0.301_20170829_198.png

 

vSSの新規作成とVMネットワーク ポートグループの作成、およびvDSから物理NIC(vmnic0)を剥がしてvSSに追加します。

※ESXi 6.0のHTML5 Host Clientだとこの辺りの操作がいまいちなので、この設定はC# vSphere Clientを利用します。

vCSAをリストアしたESXiホストのネットワーク構成からvDSを選び、物理NICを片方削除します。

FILESV01_Vxrail4.0.301_20170829_208.png

 

新規のvSSに剥がした物理NICを割り当て、管理ネットワークのポートグループを作成します(VxRailのデフォルトはNative VLAN = VLAN 0 です)

FILESV01_Vxrail4.0.301_20170829_210.png

FILESV01_Vxrail4.0.301_20170829_212.png

FILESV01_Vxrail4.0.301_20170829_213.png

FILESV01_Vxrail4.0.301_20170829_216.png

 

作成したvSSのポートグループにリストアしたvCSAを接続します。

FILESV01_Vxrail4.0.301_20170829_219.png

 

vCSAがネットワークに接続されればWeb Clientにアクセスが可能になります。

FILESV01_Vxrail4.0.301_20170830_002.png

 

■ vSANクラスタの正常化


この時点では緊急リストアで切断されたESXiホスト上にリストアしたvCSAや、稼働していたvDPが正しくインベントリに登録されません。

対象のESXiホストを右クリックして「接続」を実行します。

FILESV01_Vxrail4.0.301_20170830_004.png

FILESV01_Vxrail4.0.301_20170830_005.png

 

接続後、リストアしたvCSAと稼働していたvDPが確認できます。

FILESV01_Vxrail4.0.301_20170830_006.png

 

この状態まで復旧出来ればvCSAをクラスタ内の他のESXiホストにvMotionで移動可能です。

vMotionする際に、移行先ではvDSの管理ネットワークに付け替えます。

FILESV01_Vxrail4.0.301_20170830_008.png

 

移行が完了します。

FILESV01_Vxrail4.0.301_20170830_011.png

 

ここまで復旧できれば、一時的に作成したvSSの削除後、物理NICを再度vDSに割り当てが出来ます。

vDSにネットワークが戻った後はVxRail Managerの管理画面でも状態が元に戻った事が確認できます。

FILESV01_Vxrail4.0.301_20170831_041.png

 

以上が、一通り確認したvCSA障害発生から復旧までの一連の手順です。


本投稿の手順はメーカー側が公式で提示している手順ではないので、もしかしたら私が確認しきれなかった何等かのVxRail Manager関連で接続・構成の不都合などがあるかもしれません。

vSphere・vSANクラスタとしての正常化は可能なので、重要なシステムを保護する普段として参考にして頂ければと思います。

 

 

■ 参考

 

場合によっては最初に記したようにESXiホストをFRU用のESXiインストーラを利用して初期化して、ノード交換の手順で交換してきれいにしてしまうという事も出来るはずです。(恐らくメーカー非サポートの手順ですがシステムの正常復旧のための手段としては有りかと考えています。)


VxRail Managerを利用した故障ノードの交換手順は非常に簡単に、短時間でノード交換が可能です。

 

FILESV01_Vxrail4.0.301_20170830_023.png

FILESV01_Vxrail4.0.301_20170830_028.png

FILESV01_Vxrail4.0.301_20170830_033.png

 

以上、VxRailの管理系VMのバックアップとリストアについてでした。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail のデータ保護、特にVxRail Manager や vCenter・PSCなどの管理系VMのバックアップ・リストアについて、現時点でメーカー公式には手順が公開されておらず、一部では "これらが壊れたら初期化してください" という情報が流れています。

 

さすがにそれはあり得ないので、VxRailを導入する上で管理系VMの保護はどのように実装したほうが良いかをご紹介します。

VxRailに限らず、vSAN上にvCenterが稼働している場合には、バックアップとリストアにコツが必要なので、参考にしていただければと思います。


※本項の内容はメーカーが公式にサポートを明言した手法ではなく、弊社で検証、正常動作を確認した内容となります。

 

※2018/04 Update:
2018/04現在のVxRailバージョンでは、VxRail Managerなどのバックアップ手順が公式にリリースされました。SolveDesktopなどの手順を必ず確認してデータ保護対策を実施してください。

 


後半のリストア編はこちら:VxRail 管理系VMのバックアップ・リストア方法【リストア・復旧編】

 

■ 今回の前提


  • VxRail 4.0.x で実施(次期バージョンVxRail 4.5はvSphere 6.5ベースとなり、vCSAのバックアップ関連が機能向上しているので、後日検証レポートを掲載予定です)
  • バックアップソフトウェアはvSphere Data Proteciton(vDP 6.1.4)を利用(2020年3月でEOAですが無償でVADP構成としてはシンプルなので)。基本的にVADPイメージバックアップをサポートするソフトウェアであれば同様の構成が可能です。
  • vDPには既知のバグを回避するワークアラウンドを適用(詳細は後述)
  • vDPは外部ストレージとしてDataDomainを利用(データ保護の基本は保護対象と異なる場所に保護データを格納する事)。
  • 2U4Nモデルを利用(10G 2ポートという縛りの中での復旧方法の説明のため。PowerEdgeモデルは1Gオンボードもあるので復旧はより楽になります)。
  • vCenterは組み込み型を利用(外部vCenterモデルより復旧が面倒が面倒なので)。
    • ただし、vSphere(vSAN)クラスタでVxRailのようにvDSのみの構成の場合、通常のvDSの設定運用のままではvCenter障害時に新たにデプロイしたvCSAがvDSに接続できなく、vSSを作るなどの必要があります。
    • そのため、あらかじめvDSに障害時のリストア用に「短期バインド(Ephemeral Binding)」の管理ネットワーク用ポートグループを作成しておいてください。見落としがちですが私は超推奨します。vDSとポートバインドの詳細はKBを参照してください(VMware Knowledge Base)
  • vCenter(vCSA)のPostgresDBはスクリプトでバックアップも実施。

 

 

まずはバックアップの環境作りから紹介します。

 

■ vDPの準備1(デプロイ)

 

vDPの展開はvDPの管理者ドキュメントに沿って進めてください。

ポイントはFQDNを事前にDNSで解決出来るように登録しておくことくらいです。

vCenterは外部PSCモデルでのセットアップです。

FILESV01_VxRail_BackupRestore_20170726_016.png

 

今回はバックアップデータを外部のDataDomainに配置するので、vDPのローカル重複排除ボリュームは最小容量の0.5TBで作成します。

FILESV01_VxRail_BackupRestore_20170726_018.png

 

CPUとメモリもデフォルトで組みます。4vCPUを割り当てれば6ジョブ並列まではこの構成で処理可能です。

FILESV01_VxRail_BackupRestore_20170726_020.png

 

基本のvDPデプロイが完了したら次はDataDomainの接続です。

FILESV01_VxRail_BackupRestore_20170726_029.png

 

DataDomainを接続する際には必ず以下の「チェックポイントコピーの有効化」にチェックを入れてください。

このチェックを入れておけばvDPアプライアンスが壊れても、DataDomainからバックアップカタログとデータの復旧が可能です。

FILESV01_VxRail_BackupRestore_20170726_032.png

 


■ vDPの準備2(バグ修正のワークアラウンド適用)


vDP 6.1.xにはvSAN上の複数のVMDKを持つVMバックアップにおいて、バックアップが失敗・ジョブステータスが92%で止まる、といった不具合があります。

幾つかVMware、EMCでKBが出ていますが、vDPアプライアンスのVADP動作モードで本来不要なSANモードを無効にする事で解決します。

※幾つかのKBで「NBDモード」にする、「対象VMと同じvSAN上にvDP Proxyをデプロイ」するなどの記載がありますが気にしないでください。vSAN上にvDPデプロイしてHotAddモードのみの設定でバックアップできます。


▼詳細は以下KBを参照

VDP 6.1.3 stops responding while VMs with multiple VMDKs on vSAN are backed up

 

https://kb.vmware.com/kb/2149101

VDP appliance crashes and reboots during backup when performing HotAdd for VMDKs located on vSAN storage

https://support.emc.com/kb/485349


VDP backup fails for vSAN VMs when multiple VMDKs are included in one backup job due to automatically selecting SAN mode

https://support.emc.com/kb/493844

 

▼ワークアラウンドの適用

vDPアプライアンスにSSHで接続して操作します

  1. ログインユーザーはadmin、パスワードはデプロイ時の管理者パスワード
  2. su - で rootに
    admin@cl2-vdp2:~/>: su -
    Password:<password>
  3. /usr/local/avamarclient/var/vddkconfig.ini ファイルの最後に vixDiskLib.transport.san.DisableVmCheck=0 を追記
    root@cl2-vdp2:~/#: printf "vixDiskLib.transport.san.DisableVmCheck=0 \n" >> /usr/local/avamarclient/var/vddkconfig.ini
  4. KBでは vmwareflr と avagent-vmware のサービス再起動とありますが、vDPを再起動すれば済むのでWeb Clientから再起動かけます。


これで多数のVMDKファイルで構成されるvCSA、VxRail Managerのバックアップも問題ありません。

 

 

■ vCSAのPostgresDBのバックアップ・リストア

 

vCSA、PSCともにvDPでVADPイメージバックアップを行いますが、DBはスクリプトを利用して簡単にバックアップが可能です。

イメージバックアップ時にDBの不整合が起きることは稀ですが、念のためDBを公式手順でバックアップしておきます。

※vCSA上でcron設置するなどで定期的に取得可能です

※vCenter 6.5以降はvCSAのVAMI(https://<vCSA>:5480/)コンソールからGUIでバックアップ設定が可能になります。

 

※詳細は以下KB参照

Back up and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database

Back up and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database (2091961) | VMware KB

 

  1. 上記KBからDLしたLinux用のスクリプトをvCSAにSCPなどでアップロードし、解凍・実行権も付与を行います。
    in-vcsa-cl2:~ # unzip 2091961_linux_backup_restore.zip

    Archive: 2091961_linux_backup_restore.zip

      inflating: backup_lin.py

      inflating: restore_lin.py

    in-vcsa-cl2:~ # chmod +x backup_lin.py

    in-vcsa-cl2:~ # chmod +x restore_lin.py


  2. バックアップスクリプトを実行します(-f で保存パス、ファイル名を指定)
    in-vcsa-cl2:~ # python /root/backup_lin.py -f /root/in-vcsa-cl2_vcdb.bk

    Backup completed successfully.

     

  3. 必要に応じて出力したバックアップファイルを別の場所(ファイルサーバなど)にコピーしておきます。

 

今回はvCSA自身にDBのバックアップファイルを格納し、バックアップファイルごとvDPでVADPイメージバックアップで取得します。

こうする事でイメージバックアップからの戻しで正しくサービスが立ち上がらなかった際に、バックアップデータからDBを復旧する事が可能です。

 

DBのバックアップを内部に持つことで、VMDKの容量が枯渇する場合がありますので、取得したDBサイズを見ながら必要に応じてVMDKのサイズを変更してください。

※参考KB

Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.0 (2126276) | VMware KB

https://kb.vmware.com/kb/2126276

 

■ vDPで管理系VMのバックアップの実施

 

Web ClientのvDP管理画面でバックアップジョブを作成します。

バックアップタイプは「ゲストイメージ」>「フルイメージ」を指定します。

FILESV01_Vxrail4.0.301_20170829_025.png

 

バックアップ対象のVMを指定します(今回はVxRail Manager、vCSA、PSCでそれぞれジョブを分けましたが一括でも構いません)

FILESV01_Vxrail4.0.301_20170829_026.png

 

同様の手順で、vCSA、PSC、VxRail Managerのバックアップジョブを設定します。

※vCSAはDBのバックアップをスクリプトで取得済みの前提です。

FILESV01_Vxrail4.0.301_20170829_032.png

 

vDP単体でも重複排除が効きますが、DataDomainと連携すると転送されるトラフィックも重複排除が猛烈に効いているのが確認できます。

以下のキャプチャは初回バックアップ時のDataDomain上のステータス確認時のものですが、一番左が取得している対象データ量、左から2番目が重複排除後のデータ量です。

毎秒100MB~200MBがvDP内で重複排除され、DataDomainには毎秒30MB前後で転送されているのが確認できます。

FILESV01_Vxrail4.0.301_20170829_038.png

 

これが2回目以降のバックアップではVADPのCBT(Change Block Tracking)が効き、データのスキャンも猛烈な速度でチェックされ、さらにDataDomainへ転送されるデータは殆ど発生していないのが確認できます。

重複排除バックアップの威力ですね。

FILESV01_Vxrail4.0.301_20170829_065.png

 

バックアップ取得が完了します。RPO24時間で指定する場合は日次でジョブをスケジュールしてください。

FILESV01_Vxrail4.0.301_20170829_081.png

 

バックアップ設定・取得に関しては以上となります。

vSAN上にAll in Oneで構成可能なVxRailですが、万が一のクラスタ全断障害に備えて、バックアップデータを外部の器(DataDomainなど)に保存してデータ保護の仕組みを確立する事がポイントになります。

 

■ 外部vCenter利用時のバックアップについて

 

外部vCenter時の保護もイメージバックアップとDBのスクリプトバックアップの組み合わせがお勧めです。

特に、外部vCenter自身が、他のvCenter管理下のクラスタにデプロイされている場合は、リストアの運用も容易になります。

 

■ 組み込みvCenterをDBのスクリプトバックアップだけでは構成できないのか?

 

DBのスクリプトバックアップはリストア時にはvCSAを再度デプロイし、DBを復元する必要があります(vCenter6.0の場合)。

この際に同一FQDN、同一設定で再デプロイしつつ、DBを戻せば基本的にvCenterの機能は復旧しますが、VxRail Managerとの証明書連携の再設定や、VxRail特有のDNSMASQサービスの再インストールなど手作業が発生してしまうためイメージバックアップの利用を推奨します。


■ vCSA復旧用にvDSに短期バインド(Ephemeral Binding)のポートグループを作成


前提条件の項にも書きましたが、vCSA on vSAN  + vDSの構成の時、vCenterが障害で利用できなくなるとvDSに新しいVMを接続できなくなるので、vCSA自体の再デプロイに備えて「短期バインド」のポートグループを作成しておきます。

Ephemeral Binding_002.png


 

後編のリストア編に続きます。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


興味本位でVxRail アプライアンスにベンチマークツールで高負荷を掛けている時にバージョンアップを仕掛けるとどうなるか、試してみました。

 

今回はDELLモデル 4ノード、外部vCenterを利用した構成です。

CPU負荷が90%~100%とサチった状態を作って、この状態でアップグレードを試してみます。

VxRail_VerUp_20170726_016.png

 

結果ですが、VxRail Managerのバージョンアップは成功しますが、次の段階でESXiホストのバージョンアップが「CPU usage」の警告でバージョンアップがストップしてしまいました。

 

VxRail_VerUp_20170726_036.png

上で動くVMを他のノードに退避出来ないので当然と言えば当然ですが、この辺りはしっかりとvSphere上のアラートをチェックしてストップをかけるようです。

高負荷を掛けている原因のVMを止めるなど、CPU利用率を落とした後に「再試行」をクリックすればバージョンアップは無事に完了します。

 

負荷の少ない業務後や夜間などにVxRailのバージョンアップを実施する事が多いとは思いますが、

一斉に走るバッチ処理や、月次のWindows Updateの処理と重ならないように注意したほうが良さそうです。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


今年に入ってだいぶ導入実績の増えてきたDELLモデルのVxRail 4.0ですが、アップグレード時に注意しておくべきことがあります。

 

DELLモデルの導入時や、その後のテストの後にノードの初期化(内部SDカードのイメージをRASRを利用して復元)した場合、

そのままの状態のESXiノードのアップグレードがエラーで失敗します。

ユーザーの方が簡単にバージョンアップを実施できるのがVxRailの良いところですが、エラーがいきなり出るとかなり萎えます...

 

エラーのメッセージは以下の様に長いので読むのは一苦労ですが、「/etc/rc.local.d/99.evobackup」の文言が見えたら今回の事象の可能性が高いです。

VxRail_VerUp_20170726_055.png

 

これは、RASRでの初期化に、ESXiのローカルのreserディレクトリと、ESXiの構成バックアップファイルが作成されないために、marvin VIBのアップグレード時の事前チェックに失敗するというものです。

/vmfs/volumes/DE*****-01-01-service-datastore1/reset/configBundle.tgz

 

※DE***** は、ノードのシリアルNo(PSNT)です。

※ configBundle.tgz ファイルはEVO:RAILの頃からあった2U4Nモデルの初期化用バックアップファイルです。


ワークアラウンドは、ダミーの configBundle.tgz をtouchコマンドで作ってあげることです。

SSHでRASRを実施したESXiにログインして、以下のダミーディレクトリとファイルを作成します。

 

mkdir /vmfs/volumes/DE*****-01-01-service-datastore1/reset

touch /vmfs/volumes/DE*****-01-01-service-datastore1/reset/configBundle.tgz

 

これでアップグレードは成功するはずです。

※アップグレード前にRASRを実施したことのあるノードには全てこの作業をしておくことが推奨されます。

 

公式KBは以下を参照してください。

https://support.emc.com/kb/501659

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail 4.0.200で初期化したアプライアンスのセットアップと、ノード交換などの検証を行ってみました。

 

地味に良くなっていた点として、ESXiのホスト名の「連番のオフセット」と「ポストフィックス」が設定がセットアップ時に追加されました。

FILESV01_VxRail 4.0.200_20170530_011.png

今までは

vxesxi-01.rail.local, vxesxi-02.rail.local, vxesxi-03.rail.local, vxesxi-04.rail.local, ...

と1から連番でFQDNが設定されていたのが、

オフセット設定が可能になったので、05 から開始したり、ポストフィックスとして連番の後に文字列の追加が可能になりました。

vxesxi-05a.rail.local, vxesxi-06a.rail.local, vxesxi-07a.rail.local, vxesxi-08a.rail.local, ...

 

クラスタは別だが、ホスト名は連番で振り管理したい場合などは便利な機能改善です。

 

 

また、4.0.100以降でセットアップ済みのアプライアンスの各種設定変更が可能になったので、

ノード交換時に投入するパスワードに関しても但し書きが追加されています(英文のままでしたが)

FILESV01_VxRail 4.0.200_20170531_001a.png

 

6/6にESXi 6.0P05となるパッチもリリースされ、月末にリリース予定のVxRail 4.0.300でもいくつかの機能が乗ってくるようなので、

この秋にリリース予定のVxRal 4.5に向けて、HCIとしての機能が充実してきました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


GW明けにDELL EMC World 2017に参加して、その後の累積した業務に追われてなかなか更新できなかったのですが、

VxRail 4.0.200 まわりのアップデート情報、検証した内容をまとめます。

 

今回の確認点は以下の4点。

 

・vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装

・iSCSI データストア利用時にも問題なくバージョンアップできるようになった。.

(https://support.emc.com/kb/495553、iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題)

・vCenter 6.0u3から推奨となったPSCのメモリ4GBが反映されないVMware側のKnown Issueへの備え

・アップグレード時に失敗すると面倒なイメージプロファイルの欠落事象の事前チェック


後半二つは弊社の検証環境やお客様の環境で確認したアップグレード時のエラーの回避策と事前にチェックについてまとめました。

 

 

【vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装】

 

VxRail 3.5からvSphere Standardが利用可能になりましたが、DRSが使えないため、ローリングアップグレードや、メンテナンスのタイミングで暗黙の了解というか、手動でいろいろやる必要がありました。

今回の更新で、Standard利用時にもGUI上に適切な操作指示が表示されるようになりました。

FILESV01_VxRail4.0.2-StdLic_20170506_001.png

Standardはこのような機能がEnabledですが、DRSはありません。※vDSの機能ははvSANライセンスに紐づく。

今回はテストしたのは管理VMを除いて100VMの稼働する環境です。

 

FILESV01_VxRail4.0.2-StdLic_20170506_009.png

DLしてきた4.0.200のパッケージをアップロードして、更新を「続行」します。

 

FILESV01_VxRail4.0.2-StdLic_20170506_020.png

VxRail ManagerやvCSA、PSCはいつも通り順調にアップグレード。

続いてホストの更新に入ったタイミングで、次のメッセージが出力されます。

FILESV01_VxRail4.0.2-StdLic_20170506_026.png

やはり自動でvMotionはしてくれませんね、当然ですが…

ただ、以前はわからなかった「どのタイミグで、どのホストのVMをvMotionで逃がせばよいか」が明確に指示されるので割と便利になりました。

 

都度vMotionを手動で実行するのは面倒なのでPowerCLIでスクリプト組んでおくか、8ノード以上のクラスタで利用する場合はやはりEnterprise Plus相当のライセンスでDRSを有効にしておくことがお勧めです。

 

 

【iSCSI データストア利用時にも問題なくバージョンアップできるようになった】

 

iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題<https://support.emc.com/kb/495553> が解決しました。

 

 

事前準備として、今回はVxRail 3.5のクラスタでSoftware iSCSIを有効化して、外部のUnityからiSCSiデータストアを接続しました。

※一般的なiSCSIの有効化ですが、ネットワークの構成によってPortBindを利用するか否かが違いますので、詳細は<ESX/ESXi でソフトウェア iSCSI ポート バインディングを使用する際の考慮事項 (2080447) | VMware KB>を参照ください。

FILESV01_Unity-VxRail_20170502_053.png

iSCSI Software Adapterが有効化されます。

FILESV01_Unity-VxRail_20170502_057.png

 

vDSにiSCSI用のポートグループを作成し、2つの10GbE NICにそれぞれ1つずつ割り当てます(チーミングを組まない)

FILESV01_Unity-VxRail_20170502_081.png

FILESV01_Unity-VxRail_20170502_082.png

FILESV01_Unity-VxRail_20170502_072.png

※iSCSIの場合はNICチーミングではなく、マルチパスで冗長化します。

 

今回の構成ではPort Bindを有効にしておきます。

FILESV01_Unity-VxRail_20170502_086.png

 

ここまで来たら、Unity側にVxRailのvCenterを登録し、UnityのUIからiSCSIデータストアを作成し、同時にVxRailにもマウントしてしまいます。

 

UnityのUIでVxRailの各ホストがリストされる事を確認し、

FILESV01_Unity-VxRail_20170502_098.png

Unityの「Vmware」タブからデータストアを追加します。

FILESV01_Unity-VxRail_20170502_099.png

 

FILESV01_Unity-VxRail_20170502_099.png

FILESV01_Unity-VxRail_20170502_099.png

VxRailの4ホストにチェックを入れれば、

FILESV01_Unity-VxRail_20170502_106.png

データストアの作成完了と同時に、

FILESV01_Unity-VxRail_20170502_118.png

VxRailのvCenter Web ClientからもiSCSIデータストアがマルチパスでマウントされている事がすぐに確認できます。

FILESV01_Unity-VxRail_20170502_124.png

 

iSCSIデータストア有のVxRail 3.5からVxRail 4.0.200へのアップグレード

 

上で作成したVxRail 3.5の環境から4.0.200へのアップグレードは、

いったんVxRail Managerだけ4.0.100に更新し、その後vSphere含めて4.0.200のコンポーネントに更新します。

 

FILESV01_VxRail3.5-4.0.2_20170427_005.png

VxRail Manager 4.0.100に更新後、VxRail 4.0.200のパッケージをアップロードします。

FILESV01_VxRail3.5-4.0.2_20170427_016.png

そこからは、今までのVxRail アップグレードと同様にPSC、vCenter、各ホストが更新され、iSCSIデータストアがマウントされていても問題なくアップグレードが完了しましたので、キャプチャは省略します。

 

【vCenter 6.0u3から推奨となったPSCのメモリ4GBが反映されないVMware側のKnown Issueへの備え】

 

VxRail 4.0.132からvCenter 6.0U3となっていますが、6.0U3以降ではPSCのメモリは4GBが推奨となります。

vCenterのリリースノートの既知の不具合にありますが、VxRailの環境でもPSCが推奨の4GBには自動で更新されないので、必要に応じて手動で更新する必要があります。

 

※弊社の作業した環境で、1件、アップグレード中にPSCが正しく再起動せず、再起動後もメモリ不足のアラートが出ていたものがありましたが、これは事後に4GBにメモリを増量することでアラートが消えました。

アップグレード作業で本件が不安な場合は、事前にリリースノートの以下の手順でメモリを増やしておくことを推奨します。

 

----

VMware vCenter Server 6.0 Update 3 リリース ノート

  • vCenter Server Appliance 6.0.x から 6.0 Update 3 へのアップデート中に Platform Services Controller のメモリが変更されない
    vCenter Server Appliance の Platform Services Controller を 6.0.x から 6.0 Update 3 にアップデートするときに、Platform Services Controller のメモリが変更されず、2 GB のままになります。
    • 回避策:この問題を回避するには、次の手順を実行します。
      1. vCenter Server Appliance 仮想マシンの Platform Services Controller をパワーオフします。
      2. 仮想マシンの [設定の編集] から、メモリ サイズを手動で増やします。
      3. vCenter Server Appliance 仮想マシンの Platform Services Controller をパワーオンします。

注:vCenter Server Appliance の Platform Services Controller は、フレッシュ インストールおよび 5.5.x から 6.0 Update 3 へのアップグレード時には、デフォルトで 4 GB のメモリを使用します。

----

※PSCのメモリを増量して起動後、vCenterとの通信がうまくいかない場合はvCSAも再起動してください。

 

一応、Communityで質問したところ、開発側のAlekseyさんからも解答をもらえました。

About PSC memory size on VxRail 4.0.200 (vSphere6.0u3a~)

 

 

【アップグレード時に失敗すると面倒なイメージプロファイルの欠落事象の事前チェック】


極稀にホストのアップグレード中に失敗する事象があります。

原因はよくわからないのですが、赤枠で囲った部分、ホストの「イメージプロファイル」が欠落している場合、アップグレードのVIBが適用できずに失敗してしましますので、

アップグレードの事前に全ホストの「イメージプロファイル」の状態は確認しておいた方が良いです。

※VxRail Managerでの事前チェックではここが確認されない。

FILESV01_VxRail4.0.2-StdLic_20170506_032.png

 

このイメージプロファイル(ESXiホスト内のimgdb.tgz)が壊れる事象のワークアラウンドはKB<https://support.emc.com/kb/494822>も公開されているのですが、

アップグレード中にエラーが出るのは心臓によくないので、事前にチェックしておいた方が吉です。

※手順はほかの健全はホストからimgdb.tgzをコピーして適用します。

 


※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



先週4/26に割と大きなアップデートを含んだVxRail 4.0.200がリリースされたので、よく問い合わせいただく4.0.200で何が変わったかを簡単にまとめたいと思います。

 

【 VxRail 3.5以降のコンポーネントのバージョン】

昨年末にVxRail 4.0.0がリリースされてから、このところのvSphere側の脆弱性対応やマイナーバージョンアップに対応する形でパッチが矢継ぎ早にリリースされていたので各バージョンの内容を整理します。

 

VxRail 4.0.132以降で、vSphere 6.0u3がベースラインとなっているなど、vSAN周りの性能向上や安定性向上が期待できるので、今日現在はVxRail 4.0.200へのアップグレードが強く推奨されています。

 

■VxRail 3.5

  • vSphere 6.0 Update2 (ESXi 6.0u2 + vCSA 6.0u2)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 3.5 (Marvin 3.5)

■VxRail 4.0 (メジャーバージョンアップ)

  • vSphere 6.0 Update2+ (ESXi 6.0p03 + vCSA 6.0u2)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0 (Marvin 4.0)

 

■VxRail 4.0.100 (VxRail 3.5から直接のアップグレード可能)

  • vSphere 6.0 Update2a (ESXi 6.0p04 + vCSA 6.0u2a)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.100 (Marvin 4.0.100)

 

■VxRail 4.0.132 (VxRail 3.5からはVxRail Managerを4.0.100に更新してからアップグレード)

  • vSphere 6.0 Update3 (ESXi 6.0u3 + vCSA 6.0u3)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.131 (Marvin 4.0.131)

■VxRail 4.0.200 (VxRail 3.5からはVxRail Managerを4.0.100に更新してからアップグレード)

  • vSphere 6.0 Update3a (ESXi 6.0u3a + vCSA 6.0u3a)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.200 (Marvin 4.0.200)

 

【VxRail 4.0.200のエンハンスメント】

詳細はリリースノート(要Support EMCログイン)に記載がありますが、数が多いので個人的にこの更新は嬉しいなと思うものを以下まとめます。

特に気になった項目は太字にしています。

 

  1. VxRail Appliances deployed with an internal vCenter can be moved to an external vCenter.
    (詳細は試してみないとわかりませんが、組み込みのvCenterを外部vCenterとしてVxRailクラスタの外に出す事ができる?ってことでしょうか。詳細は別途調べてみます)
  2. vSphere Distributed Switch (VDS) のデフォルトポートグループ名の変更
  3. vSAN、vMotion用 VMkernelのIPアドレスの変更
  4. VDSのvCenterなどの管理ポートグループのVLAN変更.
  5. 組み込みのvCenter、PSCの管理パスワードの調整
    administrator@vsphere.local
    root@localos
    root@vCSA
  6. アップグレード時のコンパチチェックの最適化.
    (以前の投稿でも書きましたが、地味にアップグレード時にリトライで治るエラーが出て心臓によくなかった)
  7. vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装
    (先月の投稿の時にお伝えしたvSphere Std利用時の煩わしさがなくなります)
  8. Fixed Issue : VxRail cluster upgrade fails if cluster hosts are connected to iSCSI data store.
    (https://support.emc.com/kb/495553 にもありましたが、iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題、これが治ったことが個人的に一番大きなポイントです)
  9. Fixed Issue : Physical view not recovered when PTAgent doesn't get host agentinfo one time.
    (これも地味にDELL版 PowerEdgeのアプライアンスでたまにHardware Viewの取得に失敗する事があって困っていたので早期に直って安心しました)

 

VxRail 3.0で昨年リリースされてから1年で4.0.200まで刻んできましたが、リリース当初はサポートされていなかった各種初期構成時のデフォルト値の変更や、柔軟な構成にも対応するように数々の改善が加わってきました。

来月のDELL EMC World 2017でも何か発表があるはずですし、vSphere 6.5がベースとなるVxRail 4.5の登場もそろそろなので、今年度もいろいろ情報を追っていこうと思います。

 

来週GW半ばあたりにiSCSiデータストアをマウントしたVxRail 3.5からVxRail 4.0.200へのアップグレードと、vSphere Standard Edtionのクラスタの「半自動」アップグレードの検証レポートをアップしたいと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※VxRail 4.5など2018年時点でのバージョンでは、vSphere Standard Editionを利用した環境でのアップグレード時にもVxRail Manager上でvMotionを促すメッセージなどフォロー機能が実装されています。


VxRail 3.5以降でvSphere Standard Editionの利用が可能になりましたが、

現時点ではアップグレードやメンテナンスにおいて一部制限があります。

 

具体的にどのような点に注意するべきか、

VxRail で vSphere Standard Editionを利用した場合の設定・運用ポイントを紹介します。


大きく以下の点がvSphere Standard Editionでは制限されます

  • DRS、リソースプールなどのvSphere Enterprise Plus Editionの機能は使えません。
  • DRSが使えないので、VxRailのアップグレード時などのホストのメンテナンスモード投入、再起動を伴う動作時に自動で仮想マシンが退避されない → vMotionを手動で実施する必要がある。
  • その他はvSphereのライセンス差分程度。


Standard Editionでも利用できた事

  • vDSはVxRailに含まれるvSAN Enterpriseのライセンスで提供されます。
  • NIOCも使えました。これは意外。


※2017年3月時点のVxRail 4.0.100、4.0.132ベースでの情報ですので今後のバージョンで変わる可能性があります。

※本投稿用に検証したバージョンがお蔵入りしたVxRail 4.0.131というバージョンだったので投稿しようか迷ったのですが、関連するKBとリリースノートが正式に公開されたので改めて公開します。

以下、よく質問のあるvSphere Standard Edition利用時の運用イメージをまとめました。

 

■vSphere Standard Editionの適用

 

VxRailは初期セットアップ後はvSphereの評価ライセンスが適用されているので、機能はフル機能利用できます。

当然、DRSやResourcePool、NIOCなども利用できてます

※vDSはvSAN Enterpriseでも利用可能です。

FILESV01_VxRail 4.1.131_20170303_005.png

 

自社にはvSphere StandardのNFRライセンスがなかったのですが、vExpertの特典の評価ライセンスにStdが含まれていたので今回はこれを利用しました。

当然、現在の利用中の機能が制限されると警告があります。

FILESV01_VxRail 4.1.131_20170303_006a.png

 

vSphere Standard 適用後、DRSが利用不可になるのでResourcePoolが削除され、インベントリに作成済みの仮想マシンが大量に並んでしまいました。

FILESV01_VxRail 4.1.131_20170303_012.png

■vSphere Standard Edition + vSAN Enterpriseでも利用可能な機能


vSphere StandardでDRSなどは制限されてしまいましたが、vSAN ライセンスが提供する機能にvDSが含まれるため、vDSは残っています。

今回初めて気づいたのですが、NIOCもどうやら継続して利用できるようです。無効化→有効化を試しても問題ありませんでした

ライセンスガイドなどにもNIOCはvSphere Enterprise plusに付いてくる機能とあるのですが、どうやらvSAN EnterpriseでvDSが利用できる環境であればNIOCも使えるのかもしれません。

FILESV01_VxRail 4.1.131_20170303_014.png


NIOCのシェア値もそのまま残っています。

FILESV01_VxRail 4.1.131_20170303_013.png

 

■vSphere Standardが適用されたVxRailのアップグレード


vSphere StandardではDRSが無効になるので、ホストのメンテナンスモード投入 → 他のホストに仮想マシンのvMotionによるオンライン移行が利用できません。

そのため、アップグレード中にホストの再起動が行われる際には、管理者が手動で仮想マシンの退避を行う必要があります。

 

※通常のアップグレード時の作業内容は過去投稿を参照ください。

 

 

VxRail Managerがアップグレード実行前にシステムのチェックを実施しますが、この際にvSphere Standardが適用されている場合は、ワンクリックアップグレード機能が実行できないので以下のような警告が表示されます。

FILESV01_VxRail 4.1.131_20170303_033.png

vSphere Standardの当たっている環境のアップグレード時には、以下のKBに沿ってアップグレード時のプリチェックを無効化する必要があります(パートナーレベルのKBなのでURLのみ記載します)

「VxRail: How to bypass upgrade pre-check」

https://support.emc.com/kb/493135

 

上記KBの内容を実行すると、プリチェックが除外されるのでvSphere Standerd Editionでもアップグレードが続行されるようになります。

 

★ここからがなかなか面倒です。

ホストがNode1からアップグレードが開始されますが、DRSが利用できないStandardでは毎回ホストのメンテナンスモード投入時に仮想マシンを手動で移動しなければなりません。

 

VxRail Manager上では各ホストのメンテナンスモード投入タイミングで「アップグレード時のPythonフック」表示で待ちになります。

FILESV01_VxRail 4.1.131_20170303_043.png


Web ClientでvCenterに接続し、Node1上のパワーオンの仮想マシンをvMotionでほかのホストに移動します。

FILESV01_VxRail 4.1.131_20170303_034.png


ホスト上の仮想マシンが空になると、

FILESV01_VxRail 4.1.131_20170303_036.png


Node1がメンテナンスモードに投入されるとアップグレードが続行されます。

FILESV01_VxRail 4.1.131_20170303_046.png


アップグレードのVIB適用後、ホストも再起動されます。

FILESV01_VxRail 4.1.131_20170303_045.png

Node1のアップグレードが終わると、次はNode2の処理が開始されるので、Node2上の仮想マシンの他のノードに退避させ、同様の操作を全ノード数分実行します。


※どのバージョンからどのバージョンにアップグレードするかによっても変わると思いますが、

1ホストあたりvSphereの差分VIBと、VxRailのエージェント(MARVIN)のVIBのインストール時にそれぞれ再起動が走ります。


最終的に全ノードの更新が完了しますが、やはりDRS機能の有無の差は非常に大きい印象です。

個人的には3ノード、4ノード構成などの最小構成以外はEnterprise plusで設計・導入する事が運用的にも強く推奨されるべきと考えています。

FILESV01_VxRail 4.1.131_20170303_068.png

■VxRail 4.0.131 の問題について

4.0.131は2017年3月上旬にリリースされましたが、すぐに4.0.132に差し替えられました。

4.0.131と132の違いは、vSphere ESXiに含まれるLSI SAS HBAのドライババージョンがvSAN HCL DBの更新を待たずに先行で131のバイナリには含まれていたため、vSAN Health Checkでも警告が出力されてしまいます。

 

詳細は以下KBに掲載されていますが、2017/3/23にVmware社のvSAN HCL DBが更新されvSAN警告は非表示となりました。

VxRail: vSAN Health page warning on LSI driver in 4.0.131 on Quanta appliance

https://support.emc.com/kb/497029


3/22以前のvSAN HCL DBだとドライバの互換警告が出ていましたが、

FILESV01_20170405_002.png

FILESV01_20170405_001.png


3/23移行のDBに更新すると、

FILESV01_20170405_004.png

グリーンに戻ります。

FILESV01_20170405_003.png

 

■まとめ

2017年3月時点ではVxRailをvSphere Standardで利用した際に、以下の点に注意が必要です。

・DRS、Resource Poolなどの機能が使えなくなる

・ホストのバージョンアップ時には、手動で別ホストへ仮想マシンの移動が必要となる。全ノード分なのでしんどいと思います。


NIOCはそのまま利用できるようです。


Filter Blog

By date:
By tag: