【VMware認定資格】VCAPへの道【VCAP6.5-DCV Deploy Section 1対策編】
まえがき
本記事は、VMware認定資格 VCAP-Deployの試験対策記事です。(対象vSphere バージョンは6.5)
本記事は、記事投稿者が当該試験を受験前に自己学習のまとめとして掲載しているものですので、記事作成時点では投稿者は試験で実際に問われる設問を一切把握しておりません。
記事の内容は、当該試験の公式出題範囲から出題される可能性が高そうなものを独自に予測したものですので、その点をご留意の上お読みいただけますと幸いです。
なお、本記事の親記事はこちらですので、他のSectionについても同様の情報を参照されたい場合は以下のリンクも是非ご覧ください。
【VMware認定資格】VCAPへの道【VCAP6.5-DCV Deploy 対策編】
vSphere Auto Deployの初期設定
vSphere Auto Deployとは、物理ホストの電源を入れれば、自動的にESXiがインストールされ、その後定義した設定が自動で構成されるという機能です。これにより得られる利点は新規ホスト展開の時間短縮です。また、自動化された構成によりミスがない初期展開というのも魅力です。
本機能の利用には上記の動画にあるようにDHCP、TFTP、Auto Deployサーバーの展開が必要です。
なお、Auto Deployサーバーについては、vCenter Serverアプライアンスの場合はその中に内包されています。試験対策的な点での考察としては、時間的な制約上から展開済みのこれらのサーバーに対していくつかの設定を適用していく可能性あります。例えば、本機能ではPXEブートなどのハードウェア設定などは試験範囲の対象になるかは現実的では無いと言えます。
vSphere Web Client を使用した vSphere Auto Deploy プロセスの概要(VMware Docs)
vSphere Auto Deploy 用にシステムを準備(VMware Docs)
- vCenter Server アプライアンス内にて必要なサービスを起動する
- Auto Deployサービス
- Image Builderサービス
- TFTP用ファイルの展開
- DHCPサーバーの設定
出題されそうな範囲はこれらの範囲かなと考えられます。
サービス起動については、vSphereのUI上から行うことが可能です。HOL上ではユーザーの権限制限により通常の方法ではサービス状態の確認が難しいですが、6.7のVAMIから確認した図を参考までに載せておきます。
サービス起動後、vSphere Web ClientからTFTPサーバー配置用ファイルを入手可能となります。
特にhardwiredで終わるファイルは、起動ファイルです。物理ホストの起動形式(BIOSブートとUEFIブート)でファイルが異なるため、その点は注意です。（下図内ではBIOSブート用ファイルをハイライトしています)
ファイルをTFTPサーバー上に配置後は、DHCPサーバー側でオプション設定を行う必要があります。
上図内のOption 66と67は、DHCPサーバーが配布をする情報です。（Windows ServerでDHCPを組んだ際の画像を参考に掲載しておきます）
これら以外にも他にも設定箇所はありますが、出題対象になりそうな箇所として上記を挙げてみました。
スクリプトを活用したESXiホストの自動インストール
Linuxで有名な”Kick Start”ファイルを利用する事で、OSインストール時の各種入力項目を自動的に入力させることが可能です。（これにより、大量に同じ設定の新規インストールされたESXiを手軽に構成することが可能です）
各種項目に対する応答を定義する方法は、ks.cfgというファイルにその内容を記述します。
ファイルの提供方法は、ローカル及びネットワーク上の2種類があります。
サポートされている、インストールまたはアップグレード スクリプトの保存場所
ファイル形式についてはこちらのURLの内容をご覧ください。
デフォルトの ks.cfg インストール スクリプトについて(VMware Docs, 6.7)
デフォルトの ks.cfg インストール スクリプトについて(VMware Docs, 6.5)
ks.cfgファイルを準備できれば、いよいよスクリプトによる自動インストールの実践です。
なお、もしファイルを用意するのが少々面倒だという方は、インストーラーイメージ内にも実は応答ファイルが用意されています。今回は私はKick Startインストールのイメージを掴むために、このデフォルトで用意されたファイルを利用してのインストールにチャレンジしました。
まず、ESXiのインストールイメージを起動します。画面右下にあるオプション”Shift+O”を押下します。
Shift+O押下後、入力プロンプトが現れますので、こちらに次の文字を入力し、その後Enterを押下します。
ks=file://etc/vmware/weasel/ks.cfg
これは、ESXi インストーラー内の、/etc/vmware/weasel/ks.cfgを参照するように、という命令です。
*Weaselはイタチ、ですね。Red Hatではanaconda-ks.cfgというファイルで、アナコンダ(蛇)なので、イタチvs蛇という事でしょうか。
Enter押下後、数分待つと、次のように構成ファイルを読み取っているような動きが確認出来ます。
このまま、待つこと数分。次のようにインストールが完了した旨が表示されました。
この後は再起動が実行され、通常通りのESXiとして利用が可能です。
なお、組み込まれたks.cfgを利用した場合のESXiのパスワードは次の通りです。
ESXi 6.5以前 mypassword / ESXi 6.7 myp@ssw0rd
*パスワードについてはVMware Docs内で明記があります。
vCenter Serverの展開と構成
vCenter Server アプライアンスを展開後、vCenter Server自体の管理や設定には”VAMI(vCenter Server Appliance Management Interface)”を使う必要があります。アクセス方法はvCenter ServerのFQDNまたはIPアドレスにポート番号5480を指定してブラウザからアクセスすればOKです。
なお、VAMIで実施可能な操作はvSphereの世代毎にデザインも含めて異なりますので、この点は注意ください。
vSphere Update Managerの基本操作
vSphere Update Manager(通称VUM)とは、次のオブジェクトの更新管理を行うソフトウェアです。
- vSphere ESXi(セキュリティパッチ、アップグレード、サードパーティツール)
- 仮想マシン(仮想マシン ハードウェアバージョン、VMware Tools)
- 仮想アプライアンス
本ソフトウェアの導入方法ですが、vCenter Server アプライアンス6.5以降からはデフォルトで組み込まれています。Windows ServerベースのvCenter Serverの場合は展開方法が異なります。今回は試験対策を前提とした記事なのでこの点は割愛します。各展開手法ごとの違いを学びたい方はこちらをご覧ください。
試験時間や構成難易度から考えても、Update Managerの新規展開は対象から外れると予想されます。また、VMwareとしては今後アプライアンス版のvCenter Serverのみの提供ですから、アプライアンス版での環境提供が来ると予想します。
最低でも抑えておきたいのは、VUMで登場する用語と機能の2点だと言えます。また、展開手法としては上図で示すようにパッチレポジトリをvCenter自身にするのか、別サーバーを立てるのかがあります。
詳細はこちらをご覧ください。
<用語>
- ベースライン 管理対象オブジェクトに対する適用パッチなどの集合体
- ベースライングループ 複数のベースラインをまとめたもの
- 添付(Attach) ベースラインを、更新管理対象に関連付けること
- 修正(Remediate) 更新対象が、添付されたベースラインに満たない場合、差分を埋めるオペレーション
- UMDS Upgate Manager Download Service、パッチレポジトリとして動作するサービス（オプション）
<機能>
- vSphere HAやFTなどの冗長性のための機能を、更新作業中のみ一時的にオフにする事が可能
- 仮想マシンに対する変更の前に、自動的にvSphere スナップショットの取得及び保持期間の指定が可能
- vApp構成済みの仮想マシン群には、vAppで定義したシーケンスでの起動を実施
上記各機能は下図内の箇所に設定があります。下図では仮想マシンの更新時にスナップショットを取得し、かつスナップショットを維持する設定となっています。
こちらの図では、ベースライン”Non-Critical Host Patches”が、クラスタ”Cluster Site A”に添付されており、スキャンをした結果、クラスタ内の2つのホストが”準拠”状態で有ることが確認出来ています。
準拠＝定義したパッチが全て適用されている状態です、”修正”は非準拠状態の対象が存在する場合に行います。
仮想マシンの構成変更
基本的には仮想マシンの右クリックから変更が可能です。主に2種類の変更可能な構成があります。
1つ目は仮想マシンハードウェアバージョン(赤)、2つ目は仮想マシンの変更(緑)です。
- 仮想マシンハードウェアバージョンの更新
- 仮想マシンの変更
仮想マシンは、基本的にはOSを停止せずにハードウェアを増設/削除が可能です。
但し、例外的にCPUやメモリについては”Hot Add”という機能をサポートするOSかつこの機能を有効にしている場合のみオンラインでの設定変更が可能です。
仮想マシンのハードウェアバージョンの変更のポイントは、次の通りです。
- 対象仮想マシンの再起動が必要であること
- アップグレードのみ可能、かつスケジューリングも可能
- ダウングレードは限定された方法で可能(関連KB)
- 更新前にバックアップ or スナップショット/VMware Toolsの更新をすること(関連KB)
試しに、仮想マシン ハードウェアバージョン4で新規に作成をした仮想マシンのハードウェアバージョンの更新を試してみました。更新先のバージョンの指定は可能です。
ゲストOSがWindowsかつ最新のVMware Toolsが動作していないと判断された場合は、ハードウェア更新に伴い仮想NIC(vNIC)の設定がリセットされる可能性があると警告が出ました。
これは障害ではなく、仮想マシンの視点ではハードウェアバージョンの更新＝全く新しいハードウェアを認識する、という動きのため起こる症状です。(関連KB)
この動作については、以前は管理者が手動でVMware Toolsの機能を利用して構成を保存、復元をしなくてはいけませんでしたが、現在は動的にこれをVMware Toolsが実施しています。
試験対策的な観点ではハードウェア更新前に、次の流れを実施出来るか、が鍵になりそうです。
- 仮想マシンのスナップショット取得
- VMware Toolsのインストール（権限上可能なら）
- 更新対象仮想マシンの停止
- 仮想マシンハードウェアバージョンの更新
最後に、仮想マシンのセキュリティ強化のための”コピー・アンド・ペースト”機能の無効化についても紹介します。(元々本機能はデフォルトで無効です)
この機能は仮想マシンの詳細設定内の値で制御されています。設定値は以下の”Configuration Parameters”内にあります。
本項内で、以下のように2つの値を追加します。
(Name自体も管理者で入力する必要があります。isolation.tools.~の文字列を覚えておきましょう)
今回はこの値自体が動作するかを試すために、私がこの値を追加しました。機能を確認するためあえてFALSEとしましたが、機能自体を無効にするにはTRUEと入力してください。
結果、本値により仮想マシンと物理マシン間でのコピー・アンド・ペーストが出来ました。
コメント