vSphere 6.7 Update 2 のリリースが発表
VMware のハイパーバイザーであるvSphereのマイナーアップデートであるUpdate2のリリースがVMware vSphere Blogで発表されました。
各所でアップデートについて纏められていますが、個人的に気になった点を記載してみます。
（Veeamの9.5.4aが3月26日にリリースされましたが、そのリリースノートに仮想ハードウェアバージョン15とvSphere6.7u2の対応について記載があったので、そろそろ来るとは思っていましたが・・・）
現物が手元にないので箇条書きで。
外部PSCの廃止
vSphere6.7（vSphere6.5u2）のリリース時は、vCenter Serverの組込みリンクモードがで導入されたことで、その利便性から外部PSCを利用したリンクモードはネガティブな方向性が見えていましたが次回Updateでは廃止されることになりました。vSphere6.7u1でも「vCenter Server Converge Tool」を利用して外部PSCを組込みPSCに移行することが出来ましたが、Update2ではこの「vCenter Server Converge Tool」の機能が強化されているそうです。
※ 以前は同じSSOドメイン内に複数のvCenter Serverを持つためには、拡張リンクモード（ELM）を利用する必要があり外部PSCが必要でした。令和の時代はうってかわって外部PSCは駆逐される運命のようです。
L1TFに対する保護強化
インテル®Skylake™プロセッサーまたはそれ以前のプロセッサの脆弱性対策が強化されパフォーマンスも改善されるとのことです（具体的な数値などは不明）。
vSphere Update Manager（VUM）
VUMのUIが機能強化されるそうです。vSANヘルスチェックをスキップ可能になるそうなので試してみたいですね。
新バージョンになるもの
仮想ハードウェアバージョン15がサポートされるようです。1VMあたりの最大積載数が向上されるようです（256vCPU ／ 6TB vRAM）。
VMware Toolsのバージョンが10.3.5にUpdateされるようです。Windows Server 2019がWindows Update 経由でvmxnet3ドライバをインストール出来るようになるそうです。
バックアップソリューションの対応状況との兼ね合いがあるので、本格的に導入が進むのはもう少し先のことでしょうか？
Veeam Backup & Replication 9.5u4 の インストール & アップデート手順
Veeam Backup & Replication 9.5をvSANの環境に実装したので、導入について記録しておこうと思います。
前提として ESXi6.7u1 + vSAN の環境での話しです。
VBRは9.5u3と9.5u4を扱います。
なお先に記載しておきますが、VBR9.5u3aは、ESXi6.7u1+vSAN環境ではうまく動作しません。最新のVBR9.5u4を使用する必要があります。
＃VBR9.5u3aのインストールは出来ますが、バックアップ等を実行しようとするとクレデンシャルでエラーが出ます。
軽い言い訳ですがリリースノートの記述が以下の通りだったので、ESXi6.7u1もサポートされるのだと勘違いしました。VBR9.5u4がリリースされてリリースノートを確認するとUpdate1は具体的に記載されています。
＃ちなみにVBR9.5u4にはESX(i)4.1が含まれていませんが、試していないので動作の方はわかりません。
以下に記載するのは『VBR9.5u3のインストール』『VBR9.5u4へのアップデート』の手順です。
よってESXi6.7u1を利用している方は、直接VBR9.5u4をインストールしたほうが短い手順で使用出来ます。
インストール前の準備ですが以下が必要です。
・インストーラ(isoファイル)
・インストールするマシン(今回はVM／WindowsServer2016)
Local Administratorの権限が必要
isoファイルをマウントできる環境が必要です
・ライセンスファイル
評価版、有償版ともにインストール時にライセンスを食わせる必要があります
インストーラ(isoファイル)をマウントして、setup.exeを実行します。実行するとインストーラーが起動します。
下図の左側のInstallをクリックします。各コンポーネントを個別にインストールする場合は、右側から任意のコンポーネントのInstallをクリックします。
まず EULA が出力されるので Accept します。
あらかじめ用意しておいたライセンスファイルを選択します。評価ライセンスでインストール後に正規ライセンスを適用することもできます。画面下に記述のあるフリーモードについては試していないので分かりません。
各コンポーネントのインストール場所を指定したい場合はココで変更します。
VBRで使用するSQLのモジュールに不足がある場合は、下図のように指摘されます。個別で準備しない場合はInstallをクリックしインストールします。
インストールが終了するとステータスが全てパスになります。
先ほどの各コンポーネントのインストール場所の指定に戻ります。冗長なので図は割愛。
各パラメータのデフォルト値から変更したい場合は、下図で任意の値に変更します。
インストールが完了すると下図が出力されます。
インストール後はOSの再起動が必要なのでサーバを他の用途に使用している場合は注意が必要です。
VBRを操作する場合は、ショートカット等を用いてコンソールを使用します。
VBRと一緒にコンソールもインストールしている場合は、ローカルログオンとなります。管理者権限でログインしているため下図の通りパスワード等の入力は不要です。
＃リモートログオンの場合は当然ID/Passwordの入力が必要です。
初回起動の際は、ローカルのマウントなどの処理がありますが、結果を Apply し Finish を選択します。
通常であればこの後、ハイパーバイザーの登録などを実行するのですが、ここではアップデートの手順を記載します。
インストール時と同じくインストーラ(isoファイル)をマウントして、setup.exeを実行します。実行するとインストーラーが起動します。
下図の左側の Upgrade をクリックします。
インストール時と同じくEULA が出力されるので Accept します。
この後『アップデートの対象コンポーネントの確認』と『ライセンスの適用』とありますが ”Next" で次に進みます。
管理者権限のあるアカウントを指定します。
”Next" を選択するとメッセージが出力されますが、”はい” を選択します。
”Install” を選択するとVBRのアップデートが開始されます。ただしメッセージにある通りアップデートはVBRにしか適用されません。チェックボックスにチェックを入れるとアップデート終了後に自動的にリモートコンポーネントのアップデートが開始されます。
アップデートが完了すると下図が出力されます。
アップデート後はOSの再起動が必要なのでサーバを他の用途に使用している場合は注意が必要です。
VBR9.5u4 にアップデート後は vSAN6.7u1 でも問題なくバックアップジョブを処理できるようになります。なお、テーマの色が少し深緑になっています。
VBRのインストールとアップデートの大まかな手順は以上です。
vSphere & vSAN オンラインセミナー メモ
2019/3/13 VMware社が開催したvSphereとvSANのウェビナーに参加したので感想と気になった点を記載します。
VMware社開催のウェビナーの参加は初めてでしたが、先に結論を述べると非常に良かったです。参加のきっかけはTwitterでの宣伝を見かけたことですが、また開催されれば参加したいですね。
なお、ウェビナーは日本語での開催でスライドの表記もすべて日本語です（vSphereClientのSSも日本語化されている）。スライドも翌日にデータで提供して頂きありがたかったです。
あと、最後にQ&Aコーナーもあり至れり尽くせりで良かったです。
備忘録 (別の機会でまた開催されるでしょうから細かいことは記載しません / 気になった方は是非参加してみてください)
・Persistant Memoryディスクタイプの違い
vPMemDiskとVNVDIMMで制約事項にかなり違いあり
・vPMemDisk仮想マシンの作成方法
・vNVDIMM仮想マシンの利用方法
vSphereClientでの作成方法をスライドで確認、環境さえあれば簡単に利用できますね
・PoC環境構築のTips
実際に構築した際の注意点などを共有して頂けた。やっぱりBIOSやドライバー関係のチェックは必須ですね。
・VMFS (Copy on Write) ベースのスナップショットの動作
これは従来からよく知られた方式。注意点もよく知られた性能劣化等の制約などなど
・vSAN Sparse (Redirect on Write) ベースのスナップショットの動作
vSANがROWなのを知りませんでした。個人的には今回のウェビナーで最も大きな収穫です。提示された資料を拝見したところIOPSの性能低下もほとんどないですね。
【vSAN6.7u1】オフライン環境での『vSNA HCL DB』『vSANリソースカタログ』の更新について
オフライン環境でvSANを運用していると健全性サービスの『vSNA HCL DBの更新状態』や『vSANリソースカタログの更新状態』に関するアラートが出る事があります。
なお本記事は、vSphereClient(HTML5)で少しUIaが変わったvCSA6.7u1＋vSAN6.7u1の環境が前提です。
この話題についてはＫＢや過去のリヴィジョンの情報があるかと思いますが、念のため分かりやすい記述のあるＫＢを一点掲示します。
vSAN 健全性サービス - vSAN HCL の健全性 - vSAN HCL DB の最新の状態 (2109870)
https://kb.vmware.com/s/article/2109870?lang=ja
対応方法ですが、ＫＢに記載がある通り『最新のHCL DB（jsonファイル）を入手し手動でvCenterServerにアップロード』する方法です。
オフラインでのアップロードですが大きく以下のような手順となります。
１．最新のHCL DB（jsonファイル）を入手
２．vCenterServerにアップロード
１．最新のHCL DB（jsonファイル）を入手
当該サイトからjsonファイルを入手します。
IEの場合はリンクをクリックすると以下のようなポップが出力されるので保存します。
２．vCenterServerにアップロード
ちなみに”サイレンスアラート”とはアラートが新規に出力されなくなるそうです。クリックすると[はい／いいえ]を選択することになります。ただし現在のアラートが自動的に削除されるわけではありません。またサイレンスアラートから元に戻す場合は、即時反映なので注意が必要です。
「ファイルから更新」をクリックし、入手したjsonファイルを選択します。
ファイルを開くと更新中になります。しばらく待ちます。
更新が終わると自動的に最終更新日が更新されます。
２’．vCenterServerにアップロード（vSANリソースカタログの更新状態）
『vSANリソースカタログの更新状態』の更新ですが、『vSNA HCL DBの更新状態』と大差ありません。
最新のvSANリソースカタログを入手します。
「ファイルから更新」をクリックし、入手したjsonファイルを選択します。
『vSNA HCL DBの更新状態』と同じくファイルを開くと更新中になります。しばらく待ちます。
更新が終わると自動的に最終更新日が更新されます。
全般的に簡単な作業ですが、ステータスが緑色になると気分が良いですね。
Japan VMUG UserCon2018 気になったこと
Japan VMUG の UserCon 2018 が2月27日に無事終了したので、当ブログも再開です。
UserCon 2018 に参加したので印象に残った事に触れたいと思います。
ヴイエムウェア株式会社の高橋さんが『VMware最新製品アップデート』と題してvSphere関連の新機能や今後のリリース予定の機能について講演されていました。
その中で、最も印象に残った機能は、2 Host vSAN で利用する vSAN Witness Appliance （以下Witness）について複数の2 Host vSANクラスタを1台のWitnessで管理できる機能です。
現場サイドの意見を述べさせていただくと、実に使い勝手の良い機能だと思います。
vSANクラスタの利用目的ですが、個人的にはシンクライアントの基盤として利用するのが非常にフィットすると考えています。そしてシンクライアント基盤として利用していると単一の拠点での利用だけでなく、他拠点での利用要件が追加されることはままあります。
実際、私も開発や検証用の環境としてvSANクラスタをセットアップしていますが、アプリケーションの開発規模が拡張した場合、リモートオフィス的な拠点が複数にわたって展開することを検討する機会があります。
例えば新たに2拠点展開する場合、リモートオフィス側の規模が中小規模であれば2 Host vSANは規模感がフィットします。私見ですが、ストレッチクラスタも良いですが、コストや手間を鑑みると2 Host vSANに軍配が上がります。
とはいえ、リモートオフィスが複数に展開する場合、従来であればセンター側のクラスタにWitnessを複数構える必要がありましたが、リモート拠点を一元管理するWitnessというのはシンプルな構成と運用を好むわたしには非常に魅力的です。
わたしの本業のネットワークのデザインにしても楽ですよね。
VMwareさんは、目玉機能としてもう少し推しても良いのでは？
そういえば、2 Host vSANについては、DellEMCさんのサポートサイトで公開されている以下の説明サイトが秀逸です。一通り目を通せば2 Host vSANについての理解が深まるのでお勧めです。
vCSAにHOSTSを登録する季節
特殊な条件下では、vCSAの名前解決をDNSに頼りたくない場合があったりしますが、そんなときに代替えとなるのはHOSTSへのエントリーの登録です。
＃本番環境など可用性の要件が厳格な環境では名前解決はDNSでやるべきだと思います！
＃そういった意味では正式な代替え手段とは考えない方が良いかもしれません。
私は、本番以外の開発・検証・ラボなどサイロを幾つか抱えていますが、そういった要件の緩い環境では以下のような条件が揃おう事があります。
・物理マシンのDNSを用意できない
・仮想サーバの設置場所がデータセンター等ではない
（法定点検などで停電があるなど全仮想サーバの電源を落とす機会がある）
もちろんHOSTSを利用しなくとも対応はできます。vCSAとDNSを同じホスト上で実行し、最後はHostClientで両方の電源を落とせばよいかと思いますが、DNSの扱いを気にせず作業を出来る事はわたしのような面倒臭がり屋には利点と考えています。
試しにDNSを落としてみましたが、直後からvSphereClient上の全てのホストおよびゲストと接続できなくなります（ただし両者間でPingは応答があります）。
この状態でvCSAのHOSTSにホストのエントリーを登録すると復旧します。もちろんHostClientでDNSを起動しても同じく復旧します。
vCSA～ホストの接続は、IP reachabilityでは無くあくまで名前解決なんですね。
さてvCSAのHOSTSの登録手順ですが、通常のLinuxServerと同じです。
rootアカウントでSSH等で接続し、vimでHOSTSファイルを直接編集し、保存して完了です。サーバ本体やプロセスの再起動は必要ありません。
接続したら”shell”と入力しHOSTSを編集できるモードに移行します。HOSTSは下図の通り/etc配下に格納されています。当たり前ですが初期には何もエントリーがありません。
"vi /etc/hosts"でHOSTSファイルを編集します。
① " i " や " o "でインサートモードに移行
② エントリーを追加
③ 追加が終わったら " ESC " でコマンドモードに戻り " ZZ " で内容を保存してvimを終了
念のために編集後は反映されているか確認しておきましょう。
これでエントリーの追加は終わりです。逆にエントリーを削除する場合は、同じように直接編集するかHOSTSファイルをあらかじめコピーしておき（hosts.orzなど）リストアしても良いです。
なお保存すると即時反映なのでその点は気を付けましょう。
