vSphere Foundation の資格取得のための備忘
- 自分用に整理するためだけのための備忘です。
- 試験項目は VMware vSphere 6.7 Foundations Exam の Exam Guide に準拠してます。
- Udemy の試験で誤った場所を中心に記述してます。
- 試験合格するまでは追記予定です。
- URL は、https://docs.vmware.com/en/VMware-vSphere/6.7/～ の
enをjpに変えれば日本語のサイトに変わります。(日本語対応していれば)
Section 1 - install and Configure vCenter Server 6.x and ESXi 6.x Hosts
Objective 1.1 - Identify vSphere Architecture and Solutions for a Given Use Case
vSphere レプリケーションを構成し、構成レプリケーションウィザードのリカバリー設定下で、Multi point in time を有効化する。Multi point in time を有効化した vSphere レプリケーションで正しいのはどれ？
- vSphere レプリケーションは、スナップショット付きの仮想マシンをサポートする
- vSphere レプリケーションは、スナップショット付きの仮想マシンをサポートしない
- vSphere レプリケーションは、指定した保持ポリシーをもとにターゲットサイトの Point in Time を定義するため、仮想マシンのスナップショットインスタンスを使う (訳糞)
- vSphere レプリケーションは、指定した保持ポリシーをもとにターゲットサイト上に、仮想マシンのスナップショットインスタンスの数を保持する
そもそも vSphere レプリケーション？
VMware vSphere Replication は、ハイパーバイザー ベースでの仮想マシンのレプリケーションと復旧を可能にする、VMware vCenter Server の拡張機能です。
VMware vSphere Replication の概要
参考
仮想マシンのレプリケーションを構成するときに、レプリケーションの構成ウィザードのリカバリ設定で複数の特定の時点 (MPIT) インスタンス を有効にできます。vSphere Replication は、指定されたリテンション ポリシーに基づいて、ターゲット サイトの仮想マシンのスナップショット インスタンスを一定数保持します。vSphere Replication は、最大 24 個のスナップショット インスタンスをサポートします。仮想マシンをリカバリ後、特定のスナップショットに復元できます。
注：
vSphere Replication が仮想マシンのスナップショットをレプリケートしません。
仮想マシンのレプリケートと複数の特定の時点のインスタンスの有効化
仮想マシンに vSphere レプリケーションを構成するとき、選択可能な 最小の RPO(Recovery Point Objective) は？
- 1分
- 10分
- 15分
- 5分
参考
ターゲットとソースのサイトで VMFS 6.0、VMFS 5.x、NFS 4.1、NFS 3、vVol、または vSAN 6.2 Update 3 ストレージ以降を使用している場合、5 分の目標復旧ポイント (RPO) を使用できます。
コメント
知識問題。記憶あるのみ。
開発者が自宅にマルチティアで開発スタックを作る必要がある。どの vSphere プロダクトが適切か(コスト面でも)
- VMware Player
- vSphere Hypervisor
- vSphere Essentials
- VMware Workstation
コメント
vSphere Hypervisor って製品名を初めて聞いた。
vSphere セキュリティ強化ガイド
vROps 使って準拠していないものを列挙する。
Objective 1.2 - install and Configure vCenter Server 6.x
vCenter Server のライセンス適用について正しいのは
- vCenter Server のライセンスは、インストレーション時に適用されていなければならない
- シングル vCenter Server のインストールのライセンス適用は管理されている仮想マシンの数によって決まる
- vCenter Server のライセンスの期限が切れた場合、仮想マシンはパワーオンのままである
- vCenter Server に割り当てられているライセンスの変更は、vCenter Server サービスの再起動が必要である。
コメント
覚える。
vCenter Server 6.x のデータベース可用性を利用するためのオプションは？
- Microsoft Windows Server Failover Clustering
- vCenter Server ハートビート
- vCenter Server Watchdog
- Microsoft SQL Server 2012/2014 AlwaysOn Availability Groups
- NSX load balancer
vCenter Server Watchdog って？
vSphere 6.0 では、vCenter Server ウォッチドッグ機能が導入されました。vCenter Server ウォッチドッグは、vCenter Server プロセス (PID Watchdog) または vCenter Server API (API Watchdog) を定期的にチェックすることでより優れた可用性を提供し、vCenter Server の VPXD を監視および保護します。
サポート対象の vCenter Server 高可用性オプション (1024051)
リンクモードで2つのvCenterを構成するために必要な管理者が設定すべきシングル・サインオンモードは
- マルチサイト・シングル・サインオン
参考
一緒にインストール可能なほかのコンポーネントについて
vSphere Auto Deploy
ESXi の物理ホストを数百一度にプロビジョニングすることが可能。
VMware vSphere Update Manager Extension
パッチの自動化。ESXi、仮想マシン、仮想アプライアンスをサポート。6.7 だけ。
Objective 1.3 - Install and Configure ESXi 6.x Hosts
スクリプトを使用してインストールするときに、スクリプトを配置できる場所は？
- HTTPS
- NFS
- PXE Server
- FTP
- VVOLs Datastore
参考
インストールまたはアップグレード スクリプトは、次のいずれかの場所に配置できます。
・FTP サーバ
・HTTP/HTTPS サーバ
・NFS サーバ
・USB フラッシュ ドライブ
・CD-ROM ドライブ
スクリプトを使用した、ホストのインストールまたはアップグレード
ESXi のパスワードとアカウントロック
パスワードポリシーについて
ESXi では、ダイレクト コンソール ユーザー インターフェイス、ESXi Shell、SSH、または VMware Host Client を使用してアクセスするためのパスワード要件があります。
- パスワードを作成する際、デフォルトでは、小文字、大文字、数字、および特殊文字（アンダースコアやダッシュなど）の 4 種類の文字を混在させる必要があります。
- デフォルトでは、パスワードの長さは 8 文字以上 40 文字未満です。
- パスワードには、辞書ファイル内の単語または単語の一部を含めることはできません。
ESXi シェルにアクセスするためのショートカットキーは
- Alt + F1
| コマンド | 機能 |
|---|---|
| Alt + F1 | コンソールにスイッチ |
| Alt + F2 | DCUI にスイッチ |
| Alt + F11 | バナースクリーンに戻る |
| Alt + F12 | コンソール上に VMKernel のログを表示する |
覚える必要がなさそう。
ESXi インストール後にホスト内の構成ファイルを直接編集せずにホスト名を変更する方法は？
- DCUI から変える
- vSphere Web Client から デフォルトの TCP/IP 構成を変更する
参考
ESX をインストールする前に必要な 3 項目
- 利用可能なインストールメディア
- ハードウェアクロックを UTC にセット
- リモートストレージを切断
DCUI でテスト用の管理ネットワークから ping 可能な IP アドレスは
- デフォルトゲートウェイ
- プライマリ DNS サーバ
- セカンダリ DNS サーバ
Remote Syslog サーバの設定方法
- vSphere Web Client 使う
- Host Profiles 使う
参考
vSAN が有効になったクラスターからの ESX の外し方
- メンテナンスモードにする
- 1.が完了したらディスクグループを削除する
- ホストをクラスタから外す
ESXi 6.x のライセンスについて
- PowerCLI を使ってバルクでライセンス認証が可能
- ESXi ホストクライアントを使って割り当てることも可能
- vSphere Web Client でももちろん可能
Section 2 - Configure and Manage vSphere 6.x Networking
Objective 2.1 - Configure vSphere Standard Switches (vSS)
vSS ではどのようにポートをスケールさせる？
- vSS のポートは動的にスケールアップのみできる
- vSS のポートは動的にスケールアップ及びスケールダウンできる
- vSS のポートは静的にスケールアップまたはスケールダウンできる
- vSS のポートは動的にスケールダウンのみできる
参考
ESXi ホストのリソースを効率良く使用するため、標準スイッチのポートの数は動的に増減されます。この場合、ホストの標準スイッチは、ホストでサポートされているポートの最大数まで拡張できます。
vSS でジャンボフレームを構成したい場合の必要な手順は
- 物理スイッチが適切に構成されているか確認する
- 分散スイッチに移行する
- ポートグループの MTU を構成する
- スイッチの MTU を構成する
- 分散スイッチの MTU を構成する
コメント
3つめは物理？仮想？たぶん仮想 (標準仮想スイッチ)
Objective 2.2 - Configure vSphere Distributed Switches (vDS)
vDS を使いたい。クラスターには ESXi 5.x と 6.x の混合である、どのバージョンで作成すべきか？
- 分散スイッチ: 5.5.0
- 分散スイッチ: 5.1.0
- 分散スイッチ: 6.0.0
- 分散スイッチ: 5.0.0
コメント
一番古いものに合わせる
vDS の LACP について正しいのは？
- LACP はMACハッシュロードバランシングにて動作する
- LACP はホストプロファイルでは動作しない
- LACP はポートミラーリングでは動作しない
- LACP はソフトウェア iSCSI マルチパスで動作する
コメント
LACP のネットワーク トラフィックのロード バランシングは、MACハッシュではなく、LACP ハッシュ アルゴリズムを使用。他は、vSphere Distributed Switch の LACP サポートの制限 を参考。
vSphere Distributed Switch における LACP のサポート
適切な物理スイッチの構成に必要などのロードバランシングオプションは？
- Route based on IP hash
参考
ロードバランシングポリシー | マニュアル
---------|----------|---------
発信元の仮想ポートに基づいたルート | スイッチの仮想ポート ID に基づいてアップリンクを選択します。仮想スイッチは、仮想マシンまたは VMkernel アダプタのアップリンクを選択すると、必ずこの仮想マシンまたは VMkernel アダプタと同じアップリンクを介してトラフィックを転送します。
IP ハッシュに基づいたルート | 各パケットの送信元と宛先の IP アドレスのハッシュに基づいて、アップリンクを選択します。IP 以外のパケットの場合、スイッチはそれらのフィールドのデータを使用してハッシュを計算します。
IP ベースのチーミングでは、EtherChannel で物理スイッチを構成する必要があります。
発信元 MAC ハッシュに基づいたルート | 送信元のイーサネットのハッシュに基づいて、アップリンクを選択します。
物理 NIC ロードに基づいたルート | 分散ポート グループまたは分散ポートで使用できます。ポート グループまたはポートに接続されている物理ネットワーク アダプタの現在の負荷に基づき、アップリンクを選択します。アップリンクが 30 秒間にわたって 75% 以上ビジー状態の場合、ホストのプロキシ スイッチにより、仮想マシン トラフィックの一部は、空き容量がある物理アダプタに移されます。
明示的なフェイルオーバー順序を使用 | アクティブ アダプタのリストから、フェイルオーバーの検出基準を満たした最上位のアップリンクを常に使用します。このオプションで実行される実際のロード バランシングはありません。
Objective 2.3 - Configure vSS and vDS Features Based on Given Requirements
ネットワーク ロールバックを無効化する方法
-
C:\\ProgramData\\VMware\\CIC\\cfg\\vmware-vpx\\firstboot\\vpxd-service-spec.propファイルを修正し、<rollback>xml タグを調整する -
vpxd 高度な構成オプションを修正し、
config.vpxd.network.rollbackキーを加える -
C:\\ProgramData\\VMware\\CIC\\cfg\\vmware-vpx.cfgファイルを修正し、<rollback>xml タグを調整する -
C:\\ProgramData\\VMware\\CIC\\cfg\\vmware-vpx.cfgファイルを修正し、<networkrollback>xml タグを調整する
そもそも ネットワーク ロールバック ？
構成の変更をロールバックすることで、vSphere は管理ネットワークの構成ミスによってホストの vCenter Server への接続が失われないようにします。
参考
config.vpxd.network.rollbackキーを選択し、値を false に変更します。
キーが存在しない場合、追加して値を false に設定できます。
- Windows Server オペレーティング システムの場合、ディレクトリの場所は C:\ProgramData\VMware\CIS\cfg\vmware-vpx です
- vpxd.cfg ファイルを開いて編集します。
<network>要素で、<rollback>要素をfalseに設定します。
vCenter Server構成ファイルを使用したネットワーク ロールバックの無効化
ネットワークパフォーマンスが遅い
考えられる原因
- 仮想マシンのネットワークリソースシェアが小さすぎる
- パケットサイズが大きすぎて、高いネットワークレイテンシが生じている。
- パケットサイズが小さすぎる。
参考
state tracking をサポートしていない環境での upstream failure detection について
要求を満たすために、Beacon probing を有効にする
ビーコンの検知は、ネットワーク フェイルオーバー検出メカニズムで、チーム内のすべての物理 NIC でビーコンの検知パケットを送信およびリッスンします。チーミングされたアップリンクでは、パケットが各物理 NIC を介して送信されます。
Section 3 - Configure and Manage vSphere 6.x Storage
Objective 3.1 - Connect Shared Storage Devices to ESXi Hosts
vSphere 6.x でサポートされているファイバーチャネルゾーニングオプションは？
- Multiple-Initiators-Single-Target
- Single-Initiator
- Single-Initiator-Single-Target
- Multiple-Initiators-Multiple-Targets
そもそもファイバーチャネルゾーニング？
ゾーニングは、アクセス権の管理に広く使用されている LUN マスキングに似ています。LUN マスキングは、LUN をあるホストからは使用できるようにして、別のホストからは使用できないようにする処理です。
参考
ESXi ホストでは、1 イニシエータ ゾーニングまたは 1 ターゲット 1 イニシエータ ゾーニングを使用します。後者のゾーニングを推奨します。制約が多いゾーニングを使用すると、SAN で発生する可能性がある問題や構成エラーを防止できます。
コメント
ストレージに関しては知識が乏しい・・・
iSCSI ストレージでジャンボフレームを有効化するために必要なステップは？
- LAG グループで MTU を構成する
- VMkernel ポートで MTU を構成する
- 物理スイッチで MTU を構成する
- 仮想スイッチで MTU を構成する
- VTEP で MTU を構成する
そもそもジャンボフレーム？
ジャンボ フレームを使用すると、ESXi ホストでより大きいフレームを物理ネットワークに送信できます。
コメント
iSCSI との関連性がよくわからないが、VTEP(Virtual Tunneling End Point) や LAG (Ling Aggrigation Group) でジャンボフレーム有効化するみたいなオプションは無さそう。
iSCSI アダプターとしてサポートしている 3 つは？
- 独立型ハードウェア iSCSI アダプタ
- 依存型ハードウェア iSCSI アダプタ
- ソフトウェア iSCSI アダプタ
参考
独立型ハードウェア iSCSI アダプタとは、TCP/IP で iSCSI ストレージにアクセスできる、サードパーティ製の専用アダプタのことです。
依存型ハードウェア iSCSI アダプタは、VMware が提供する iSCSI 構成インターフェイスおよび管理インターフェイスと、VMware ネットワークに依存するサードパーティ製アダプタです。
ソフトウェア ベースの iSCSI を実装すると、標準の NIC を使用して、ホストを IP ネットワーク上のリモート iSCSI ターゲットに接続できます。
共有ストレージとしてサポートしているバスアダプタータイプ
- Software iSCSI
- Software FCoE
- Hardware HBA
Software SATA はだめ
Objective 3.2 - Configure and Manage Software Defined Storage
ストレージ I/O コントロールをデータストアグループ上で有効化できない 3つの状態は？
- ソリューションが計画されているデータストアは異なる vSphere クラスターによって利用されている
- ソリューションが計画されているデータストアは Raw Device Mapping file として構成されている
- ソリューションが計画されているデータストアは、3つのエクステントを持っている
- 組織は、エンタープライズライセンスを持っている
- ソリューションが計画されているデータストアは NFS として構成されている
参考
ストレージ I/O コントロールには、要件と制限事項がいくつかあります。
・ストレージ I/O コントロールが有効になっているデータストアは、単一の vCenter Server システムで管理される必要があります。
・ストレージ I/O コントロールは、ファイバ チャネルに接続されたストレージ、iSCSI に接続されたストレージ、および NFS に接続されたストレージでサポートされます。Raw デバイス マッピング （RDM） はサポートされていません。
・ストレージ I/O コントロールは、複数のエクステントを持つデータストアはサポートしません。
・ストレージの自動階層化機能を持つアレイにバッキングされているデータストアでストレージ I/O コントロールを使用する前に、『VMware ストレージ/SAN 互換性ガイド』 を参照して、自動的に階層化されたストレージ アレイがストレージ I/O コントロールと互換性があると確認されているかどうかを調べてください。
注: Storage I/O Control (SIOC) には、Enterprise Plus ライセンスが必要です。このライセンスがない場合、SIOC を有効にするオプションは灰色で表示されます。詳細については、「Compare vSphere Editions」を参照してください。
Storage I/O Control のトラブルシューティング (1022091)
コメント
1 つめはあくまでも「複数クラスターまたぎ≠複数vCenter管理」ってことかな。
vSAN を利用できるストレージコントローラの構成は？
- パススルーモードの SAS コントローラ
- RAID1 モードの SAS コントローラ
- RAID10 モードの SAS コントローラ
- RAID0 モードの SAS コントローラ
参考
Virtual SAN Storage Controller Support
Virtual SAN supports storage controllers in two modes, either pass-through or RAID0 mode.
Virtual SAN Hardware Guidance Part II – Storage Controllers
コメント
ブログ記事からの出題はやめてほしい。
vSAN Cluster を構成する上で、VMware の推奨は？
- キャッシュ層はデータ層の 10% ほど用意する
- ディスクグループは一つ以上のキャッシュディスクと少なくとも 1 つのデータディスクを含めなければならない
- ディスクグループは一つのキャッシュディスクと少なくとも1つのデータサイエンスを含めなければならない
- キャッシュ層はフラッシュ構成である必要は無い
コメント
ディスクグループに関しては、マニュアルに記載のある通り。キャッシュ層のデータ層に対する割合は、blog 記事がリファレンスされていた。マニュアルに載っているものから出してほしい。
参考
各ディスク グループには、1 つのフラッシュ キャッシュ デバイスと 1 つ以上のキャパシティ デバイスが含まれている必要があります。 キャッシュで使用されるデバイスは、ディスク グループ間での共有や、その他の目的で使用することができません。 1 つのキャッシュ デバイスは、1 つのディスク グループ専用にする必要があります。 ハイブリッドのクラスタでは、キャッシュ レイヤーにフラッシュ デバイスが使用され、ストレージ キャパシティ レイヤーに磁気ディスクが使用されます。オールフラッシュ クラスタでは、キャッシュとキャパシティの両方でフラッシュ デバイスが使用されます。
- vSAN All Flash cache and capacity ratio:
There is some confusion today that the 10% vSAN cache to capacity ratio needs to remain the same for an All Flash vSAN. This 10% guideline was meant for hybrid vSAN only. This 10% is a general recommendation could be too much or it may not be enough and should be based on use case, capacity and performance requirements. vSAN all flash caching does not have a % to capacity ratio requirement.
Extending All Flash vSAN Cache Tier Sizing Requirement for Different Endurance Level Flash Device
ストレージDRS で提供される機能は？
- データストアクラスタ内のデータストアに対する I/O ロードバランシング
- 空き容量、I/O ワークロードをもとにした仮想ディスクの初期配置推奨
- データストアクラスタ内のデータストアに対する 空き容量のロードバランシング
- データストアクラスタ内のデータストアに対するスナップショット統合の推奨
- データストアクラスタ内のデータストアに対する仮想マシンのディスクサイズ推奨
スナップショット統合？
冗長差分ディスクの存在が仮想マシンのパフォーマンスに悪影響を及ぼす場合があります。データの依存関係に違反せずにこれらのディスクを結合できます。統合後は冗長ディスクが削除されます。これにより、仮想マシンのパフォーマンスが向上し、ストレージ容量を節約できます。
スナップショットの統合は、スナップショットの[削除] または [すべて削除] の操作を実行したあと、スナップショット ディスクを圧縮できない場合に利用できます。この問題は、たとえば、スナップショットを削除しても、関連するディスクがベース ディスクに戻らない場合ことが原因で起こります。
起動した VM についている VMDK の拡張を様だける 2 つのシナリオは？
- VMDK が非サポートのゲストOSで動作している
- VMDK がスナップショットを持っている
IDE controller を使って接続されていても、LSI logic SAS controller を使って接続されていても問題なし。
参考
また、お使いの仮想マシンがスナップショット上で動作している場合は、VMDK の拡張が妨げられるため、その状態でないことを確認する必要もあります。
ディスク パーティションのサイズを増やす (1004071)
vSAN ホストのディスクグループの最小構成は
- 1 つのキャッシュ用 SSD と 1 つ以上のデータ用 SSD
- 1 つのキャッシュ用 SSD と 1 つ以上のデータ用 HDD
参考
Objective 3.3 - Create and Configure VMFS and NFS Datastores
メンテナンスモードで VMFS5 データスストアを配置可能なタイミングは？
- マルチ エクステントのデータストアのメンバーであるとき
- ストレージ DRS クラスターのメンバーであるとき
- vSAN クラスターのメンバーであるとき
- 仮想ボリュームのメンバーであるとき
Section 4 - Deploy and Administer Virtual Machines and vApps
Objective 4.1 - Create and Deploy Virtual Machines
仮想マシン上で仮想フラッシュリソースを構成しているとき、2 つの利用可能なオプションは？
- 予約
- SCSI コントローラ
- 制限
- ブロックサイズ
参考
仮想マシンには Flash Read Cache を設定できます。Flash Read Cache を有効にするとブロック サイズとキャッシュ サイズを指定して予約ができます。
・[ブロック サイズ] とは、キャッシュに格納される連続したバイトの最小数です。ブロック サイズは公称のディスクのブロック サイズ 512 バイトよりも大きく、4 KB と 1024 KB の間に設定できます。ゲスト OS が単一の 512 バイトのディスク ブロックに書き込む場合、周囲のキャッシュ ブロック サイズのバイトがキャッシュされます。キャッシュ ブロック サイズとディスク ブロック サイズを混同しないでください。
・[予約] とは、キャッシュ ブロックの予約サイズです。256 キャッシュ ブロックの最小数があります。キャッシュ ブロック サイズが 1 MB の場合、最小キャッシュ サイズは 256 MB になります。キャッシュ ブロック サイズが 4 KB の場合、最小キャッシュ サイズは 1 MB になります。
そもそも Flash Read Cache ？
Flash Read Cache™ は、ホスト常駐型のフラッシュ デバイスをキャッシュとして使用して仮想マシン パフォーマンスを高速化できます。
VMware vSphere Flash Read Cache について
パワーオフのVMを移行し、ディスクを再配置するときに利用可能なオプション
- Row Device Mapping 仮想互換性
- Row Device Mapping 物理互換性
- ソースと同じフォーマット
- シックプロビジョニング (Eager Zeroed)
コメント
解説については特に Row Device Mapping は触れていない。マニュアルを見ると、上記 2 つの選択肢のみ含まれている。
Row Device Mapping について
Raw デバイス マッピング （RDM） を使用すると、仮想マシンのデータを、仮想ディスク ファイルに格納するのではなく、直接 SAN LUN 上に格納できます。
互換モード
物理互換の RDM と仮想互換の RDM の違い (2009226)
シックプロビジョニング Lazy Zeroed と Eager Zeroed の違いについて
シック プロビジョニング (Lazy Zeroed)
仮想ディスクをデフォルトのシック フォーマットで作成します。仮想ディスクに必要な容量は、作成時に割り当てられます。物理デバイスに残っているすべてのデータは作成時には消去されません。代わりに、仮想マシンからの最初の書き込み時に、オンデマンドでゼロアウトされます。シック プロビジョニング (Eager Zeroed)
Fault Tolerance などのクラスタリング機能をサポートする、シック ディスクを作成します。仮想ディスクに必要な容量は、作成時に割り当てられます。シック プロビジョニング (Lazy Zeroed) フォーマットの場合とは異なり、物理デバイスに残っているデータは作成時に消去されます。ほかのタイプのディスクに比べて、このフォーマットでのディスクの作成には時間がかかることがあります。
vSphere Web Clientでの新しいコンピューティング リソースおよびストレージへの仮想マシンの移行
マニュアルより、物理デバイスに残っているデータを作成時に消去するかどうかの差っぽい。ま、シンプロビジョニングを選びますよね。
スナップショットについて
ESXi / ESX における仮想マシン スナップショットについて (1015180)
シングルスレッド Windows アプリケーションの仮想マシンを構築する際に、最適な構成は？
- ユニプロセッサーの VM 上にデプロイする
参考
最高のパフォーマンスとリソース使用率を得るためには、単一スレッド アプリケーションを （複数の CPU が搭載された SMP 仮想マシンではなく） ユニプロセッサ仮想マシンに導入してください。
単一スレッド アプリケーションは、単一 CPU のみを活用できます。そのようなアプリケーションをデュアルプロセッサ仮想マシンに導入しても、アプリケーションの速度は向上しません。それどころか、ほかの仮想マシンが使用可能な物理リソースを 2 番目の仮想 CPU が使用してしまいます。
ESXi CPU Considerations
Configuring a virtual machine with more virtual CPUs(vCPUs) than its workload can use might cause slightly increased resource usage, potentially impacting performance on very heavily loaded systems. Common examples of this include a single-threaded workload running in a multiple-vCPU virtual machine or a multi-threaded workload in a virtual machine with more vCPUs than the workload can effectively use.
Performance Best Practices for VMware vSphere 6.7
複数の vCPU の仮想マシンで、シングルスレッドアプリケーションを動かすことは効率が悪い。
Objective 4.2 - Create and Deploy vApps
物理アプリケーションサーバを仮想化し、既存の vApp に加える。アプリケーションライセンスが物理 NIC の MAC アドレスに紐付いており、仮想マシン上で適切にライセンスを確保したい。やるべきことは？
- vSphere Web Client を使って、vNIC の MAC アドレスを構成する
- vDS の物理 NIC の MAC アドレスをアサインする
- ESXi ホストに物理サーバの NIC をインストールする？(訳難・・)
- ゲストOS の vNIC に MAC アドレスをセットする
コメント
解説みてもよくわからなかった。機械的に上記を選ぶことにする。
vApp で制限をかけられるリソースの種類は
- ストレージ
- ネットワーク
- メモリ
- CPU
コメント
ですよね。
OVFテンプレートをデプロイする有効な方法は？
- HA が有効化されたクラスタにデプロイ
- vSphere ハイパーバイザー上へのデプロイ
- DRS が有効化されたクラスターへのデプロイ
- vCenter Serverに接続されたスタンドアロンのホストへのデプロイ
vApp とは (※ vApp を指している想定)
vApp では、リソース管理と他の特定の管理アクティビティ（複数の仮想マシンの同時電源操作など）を実行できます。vApp を仮想マシンのコンテナと見なし、そのコンテナに対して操作を実行することができます。
前提条件
データセンターで次のオブジェクトのいずれかが使用できることを確認します。
- ESX 4.0 以降を実行するスタンドアローン ホスト
- DRS クラスタ
コメント
「HA が有効になっているクラスターにデプロイできない」に納得できない。
Objective 4.3 - Manage Virtual Machine Clones and Templates
Section 5 - Establish and Maintain Availability and Resource Management Features
Objective 5.1 - Create and Configure VMware Clusters
リソースフラグメンテーションの回避の助けになるHA クラスターのアドミッションコントロールポリシーオプションは？
- 専用フェイルオーバホストの利用
- 静的ホスト数によるフェイルオーバ許容量の定義
- クラスターリソースのパーセンテージの予約によるフェイルオーバ許容量の定義
- 仮想マシン監視の利用
参考
スロット ポリシー オプションの場合、vSphere HA アドミッション コントロールにより、指定された数のホストで障害が発生しても、それらのホストからすべての仮想マシンにフェイルオーバーするのに十分なリソースがクラスタ内に残ります。
- クラスタの現在のフェイルオーバー キャパシティを決定します。
これは障害が発生し、パワーオン状態のすべての仮想マシンの要件を満たす十分なスロットが残っている可能性があるホストの数です。
専用フェイルオーバー ホストのアドミッション コントロールでは、ホストで障害が発生したときに、vSphere HA が、指定されたフェイルオーバー ホストのいずれかで障害ホストの仮想マシンを再起動しようとします。
クラスター作成時に構成可能な機能は
- vSAN
- DRS
- EVC
- Proactive HA
コメント
以下の前提条件に、vSAN は作る前って書いてあるので、作成時に構成可能 と言えるのか。
前提条件
vSAN を使用する場合は、vSphere HA を構成する前に有効にする必要があります。
デフォルトで有効な vSphere HA のネットワークトラフィックタイプは？
- vMotion ネットワークトラフィック
- VM ネットワークトラフィック
- ISCSI ポートバインディング ネットワークトラフィック
- 管理 ネットワークトラフィック
そもそも vSphere HA のネットワークトラフィック？
vSphere HA の動作に影響を与えるネットワーク操作を識別するには、ハートビートなどの vSphere HA の通信にどの管理ネットワークが使用されているかを知る必要があります。
ハートビートに使われるので、考慮しろということ。
クラスタの ESXi ホストでは、vSphere HA の通信はデフォルトで VMkernel ネットワークを通過します。
Proactive HA で修復可能なオプションは？
- すべての障害を対象とした検疫モード
- 軽度の障害を対象とした検疫モードおよび重大な障害を対象としたメンテナンス モード (混合)
- すべての障害を対象としたメンテナンス モード
参考
[すべての障害を対象とした検疫モード]。仮想マシンのパフォーマンスに影響がないかぎり、部分的に性能が低下したホストを使用せずに、パフォーマンスと可用性のバランスを調整します。
[軽度の障害を対象とした検疫モードおよび重大な障害を対象としたメンテナンス モード (混合)]。仮想マシンのパフォーマンスに影響がないかぎり、性能がいくらか低下したホストを使用せずに、パフォーマンスと可用性のバランスを調整します。重大な障害が発生したホストで仮想マシンが実行されないようにします。
[すべての障害を対象としたメンテナンス モード]。部分的に障害が発生したホストで仮想マシンが実行されないようにします。
勝手にメンテナンスモードにされると困るような気がするので、あまり有効にしたくない。
Objective 5.2 - Plan and Implement VMware Fault Tolerance
フォールトトレランス について正しいのは？
-
ワークロードの分析と、問題を正すことによってアプリケーションのクラッシュを防止する
→そんな機能ではない -
16vCPU のアプリケーションをサポートする
→サポート対象外 (8vCPU まで) -
クラスタ機能を持たないアプリが守られる
→お、おう -
カスタムのクラスタソリューションが完全に構成及び維持される
→お、おう -
アプリは利用者に持続的な可用性を提供する必要がある
→お、おう
コメント
Fault Tolerance は、vSphere HA よりも高いレベルのビジネス継続性を実現します。対応するプライマリ仮想マシンを置き換えるためにセカンダリ仮想マシンが呼び出されると、セカンダリ仮想マシンは、仮想マシン全体の状態が保持されまま、すぐにプライマリ仮想マシンのロールを引き継ぎます。アプリケーションはすでに稼動し、メモリに格納されているデータを再入力または再ロードする必要はありません。vSphere HA によって提供されるフェイルオーバーは、障害により影響を受ける仮想マシンを再起動します。
HA より構成組むのが難しそう・・・
Fault Tolerance を有効化するための仮想マシンの条件
- 4 vCPU
- e100e virtual network adapter
ライセンスによって、vCPU数が制限を受け、ネットワークアダプタは高速ネットワークが必要(10G/低遅延)と考える
参考
必要条件
- VM をホストしている ESX の CPU は、互換性が必要
- 10-Gbit logging network と低いレイテンシが必要
制限事項
- das.maxftvmsperhost
→クラスタの 1 台のホストで許容されるフォールト トレランス対応仮想マシンの最大数。プライマリ仮想マシンとセカンダリ仮想マシンの両方がこの制限に含まれる。デフォルト値は 4。 - das.maxftvcpusperhost
→ホスト上のすべてのフォールト トレランス対応仮想マシンから集計される vCPU の最大数。プライマリ仮想マシンとセカンダリ仮想マシンの両方の vCPU がこの制限に含まれる。デフォルト値は 8
ライセンス
1 台のフォールト トレランス対応仮想マシンによってサポートされる vCPU の数は、購入した vSphere のライセンスのレベルによって制限される。
- vSphere Standard と vSphere Enterprise
→最大 2 つの vCPU を許可 - vSphere Enterprise Plus
→最大 8 つの vCPU を許可
vSphere Standard、vSphere Enterprise、vSphere Enterprise Plus の各エディションでサポートされる。
Objective 5.3 - Create and Administer Resource Pools
既存の VM にカスタマイズを適用するときに利用可能なオプション
- 仕様の作成
- 既存の仕様から仕様を作成
- 既存の仕様を選択
仕様をインポートしたり、仕様を修正する は不可
リソースプールに追加したあと、仮想マシンの共有値について
-
他に仮想マシンがいなければ共有値は無視される
-
すでに共有値が定義されているなら共有プールの共有値に自動的に合わされる
Objective 5.4 - Migrate Virtual Machines
長距離vMotion失敗の原因について
- 移動対象の2つの ESX のライセンスが、vSphere Enterprise Edition だった。
→vSphere Enterprise Edition Plus 以上である必要あり - vMotion のトラフィックがデフォルトの TCP/IP Stack だった。
→転送(vMotion)専用経路で送ってあげたほうが良い - ホスト間の round-trip が、150 ms 秒以上だった
→150 ms 以内である必要あり
参考
Objective 5.5 - Backup and Restore Virtual Machines
VDP 6.x アプライアンスのために有効なディスク構成(サイズ)は？
- [X] 4TB
- 500GB
- 1TB
- 1.5TB
- 2TB
参考
必要な VDP アプライアンスサイズと数を決めるときに管理者が見るべきポイントは
- リテンション間隔
- VM のゲスト OS ファミリーとバージョン
- VM の数とタイプ (データベース、ファイルシステム)
- 典型的な変化率 ※ Data change rate 更新頻度？
コメント
VDP って使われなくなっているようなので、試験では重要だけどさらっと。
vSphere Data Protection
・vSphere Data Protectionは、VMwareが提供するバックアップアプリケーションです
・バックアップ方式は、イメージバックアップです。
・"VM Centric" がコンセプト、つまり仮想マシンをバックアップ単位として取得をします。
・製品導入には、アプライアンスのデプロイと”vSphereEssentials Plus”以上のライセンスが必要です。
・アーキテクチャは、EMCのAvamar(重複排除バックアップソリューション)をベースにしています。
お題：vSphere Data Protectionは今後どうなるのか？ より
VDP が構成可能な最大ストレージ容量は？
- 8TB
VDP の恩恵は？
- 重複データ削除を使った仮想マシンデータによって、消費されるディスクスペースを減らす
Objective 5.6 - Update ESXi and Virtual Machines
vSphere アップデートマネージャー 6.x がスキャンと修復ウィザートを実行する結果としてできるアクションは？
- ホスト上に サードパーティ製ソフトウェアのインストール及びアップデート
- ESXi ホストにアップグレードとパッチ
- ESXi ホストデバイス上のファームウェアのアップグレード
- 仮想マシンハードウェアのアップグレード
- 仮想マシン内のソフトウェアのインストールとアップグレード
参考
Update Managerを使用して、次のタスクを実行できます。
・ESXiホストのアップグレードとパッチ適用。
・ホストへのサードパーティ製ソフトウェアのインストールと更新。
・仮想マシン ハードウェアおよび VMware Toolsのアップグレード。
Section 6 - Perform Basic Trouble shooting of a vSphere 6.x implementation
Objective 6.1 - Perform Basic Troubleshooting of ESXi and vCenter Installation Issues
ESXi 6.x をインストールしたが、構成中にネットワークの問題が散見された。構成中に問題が発生しているかどうか確認するために、システムをリセットしたい。最小の時間でできる方法は？
-
ホストに接続されているとき、vSphere Client から
Reset System Configuration optionを選択する -
DCUI から、
Reset System Configuration optionを選択する - ESXi インストーラを実行し、ホストを再インストールする
- デフォルトに構成をリセットするためにホストプロファイルを利用する
コメント
リファレンスとして、Understanding the VMware ESXi Direct Console User Interface (DCUI) が案内されていたが、結局 DCUI からしかリセットできないってことなのか。
新しい ESXi hosts が 60秒間接続中のステータスだった。
※ Hardware の状況は健全で、ESXi のハイパーバイザーも適切に構成されている
- ファイアウォールルールが vCenter からのハートビートを防いでいないか確認する
参考
- インベントリへの追加または接続後に ESXi ホストが vCenter Server から切断される (2040630)
- VMware vCenter Server、ESXi、ESX ホストおよび他のネットワークコンポーネントへのアクセスに必要な TCP および UDP ポート (1012382)
Objective 6.2 - Perform Basic Troubleshooting of ESXi and vCenter Operational Issues
HA が有効化されたクラスターでNot Enough Failover Resourcesのエラーが発生していた。エラーメッセージのシナリオは？
- デフォルトで構成されたデータストアに十分なハートビートが無かった
- ホストが障害のハードドライブの置き換えのため、メンテナンスモードだった
- 大きな CPU 予約を持つ仮想マシンが存在した
- クラスターのデフォルトスロットサイズが高すぎた
- デフォルトの VM モニター感覚が高すぎた
HAを有効化しているホストで HA が失敗しているアラートが発生。仮想マシンゲストに再起動の記録はなかった。
ESXi ホストはまだ稼働中だが、ネットワークから切断していた。
参考
-
"vSphere HA virtual machine failed to failover" error in vCenter Server (2034571)
→ホストが切断されただけでは HA オプションは Power On のまま仮想マシンを残し、フェイルオーバーさせない。
vSphere ログの見方
- vSphere Web Client からログバンドル取る
- vSphere Web Client Log Browser から見る
- vRealize Log Insight の UI から見る (解析する)
参考
- Using the Log Browser to view, search, and export Logs for troubleshooting (2032888)
- Export System Log Files using vSphere Web Client
- Collecting diagnostic information for ESX/ESXi hosts and vCenter Server using the vSphere Web Client (2032892)
Objective 6.3 - Perform Basic Troubleshooting of Virtual Machine Operational Issues
仮想マシンをパワーオンしたが、95%でハングした。何が起こったか？
- 仮想マシン、あるいは他のコンポーネントの別タスクがすでに進行中だった
- ホストがリソース競合下にあり、仮想マシンをパワーオンできなかった
- 仮想マシンファイルを含むストレージにアクセスできなかった
- HAクラスターがフェイルオーバーを保証するための十分のリソースが無かった
- 仮想マシンの問題が管理者によってポーズされた ※ 訳無理
コメント
仮想マシンのパワーオン操作が 95% 完了した時点で、質問に対する回答を待って停止する (1027096) の KB がリファレンスされていたが、こんなピンポイントな KB に関する問題を出すなんて、すげーいやらしい。しかも、上記の回答につながるような情報なし。
仮想マシンをリセットすべきと判断するためのオプションは？
- CPU
- I/O
- VMware Tools のハートビート
- ネットワーク
参考
障害間隔内にハートビートが受信されなかった場合は、I/O 統計間隔 （クラスタ レベルの属性） がチェックされます。I/O 統計間隔では、過去 2 分間 （120 秒間） に、仮想マシンでディスクまたはネットワーク アクティビティが発生しているかどうかが確認されます。発生していない場合、その仮想マシンはリセットされます。
500 仮想デスクトップが、互いにコミュニケーションできない。何が必要？
- Private VLAN
- VMware NSX Distributed Firewall
vSphere Host FirewallとPort Filteringは違う
参考
- vNetwork Distributed Switch 上のプライベート VLAN (PVLAN) - コンセプトの概要 (1010691)
- Distributed Firewall
- NSX Distributed Firewall - Can you firewall vNICs that are connected to distributed port groups
なぜ NSX の分散ファイアウォールが必要かよくわからない。
Objective 6.4 - Identify and Troubleshoot Basic Misconfigurations
8のESXi 6.x ホストで DRS クラスターを組んだ。10 仮想マシンがホストにバランシング配置されている。メンテナンスモードに変わろうとしているが失敗している。メンテナンスモードにできなかった理由は？
- メンテナンスモードになろうとしているホスト上の仮想マシンの一つが、一部自動化に個別に設定されている
- DRSクラスタの自動化レベルが、一部自動化だ
- メンテナンスモードになろうとしているホスト上の仮想マシンの一つが、グループ内で実行すべきというホストアフィニティルールで構成されている
- メンテナンスモードになろうとしているホスト上の仮想マシンの一つが、グループ内で実行されなければならないというホストアフィニティルールで構成されている
参考
Section 7 - Perform Basic Monitoring of vSphere Implementation
Objective 7.1 - Monitor ESXi, vCenter Server, and Virtual Machines
vCenter Server アプライアンスのパフォーマンスモニターに役立つツールは？
- Perfmon
- vim-cmd
- esxtop
- vimtop
vimtop とは
vimtop は esxtop に似たツールで、vCenter Server Appliance の環境で実行されます。アプライアンス シェルで vimtop のテキストベースのインターフェイスを使用することにより、vCenter Server Appliance に関する全体的な情報、および vSphere サービスの一覧とそのリソースの使用状況を表示することができます。
サービスのリソース使用量を監視する vimtop プラグインの使用
コメント
perfmon は Microsoft の Windows のユーティリティ。vim-cmd は全然情報が無いが、サポートされていない可能性あり。esxtop は ESXi Shell 上で利用できる ESXi 上で利用可能なツール。
注： vim-cmd コマンドはサポートされていません。
コマンドライン ユーティリティを使用した一般的な仮想マシン関連タスクの実行 (2012964)
Objective 7.2 - Create and Administer vCenter Server Alarms
アラーム定義のトリガーアクションを指定するとき、何の2つのアラームの状態の変化でトリガー指定できるか
- critical から warning
- normal から warning
- normal から critical
- critical から normal
コメント
特に記載されているマニュアルが見当たらなかったが、二弾飛びはだめってこと？
vSphere で作成可能なアラームのアクション
- e-mail 送信
- VM移動
- コマンド実行
Guest の再起動や、シャットダウンは不可。
Objective 7.3 - Install and Configure vRealize Log Insight
Windows や Linux の vRealize Log Insight エージェントの利用は？
- syslog/eventmgr サービスのステータスをコントロールする
- syslog/eventmgr サービスのステータスを監視する
- ファイルシステムのディレクトリを監視する
- フラットテストファイルからイベントを収集する
参考
vRealize Log Insight エージェントはログ ファイルからイベントを収集し、vRealize Log Insight サーバまたは任意のサードパーティの Syslog 宛先に転送します。
コメント
フラットテストファイル(flat test files) がよくわからないが、とりあえずログを集めるのが主な仕事らしい。
vRealize Log Insight デプロイのためのロードバランシングアプライアンスについて VMware の推奨は？
- Citrix NetScaler
- F5 Big-IP
- VMware NSX Load Balancer
- integrated Load Balancer
参考
外部のロード バランサは、 vRealize Log Insight クラスタを含め、 vRealize Log Insight と一緒に使用することはできません。
単一ノード環境の場合、vRealize Log Insight 統合ロード バランサ (ILB) を使用し、ILB にクエリと取り込みトラフィックを送信することがベスト プラクティスです。これにより、オーバーヘッドは発生しませんし、ノードを追加して後で環境にクラスタを作成する場合に設定を簡素化できます。
Integrated Load Balance たるものが存在し、それ以外は使えないっぽい。
ベスト プラクティスとして、本番環境では単一ノードを使用しないでください。
商用では単一ノード使っちゃだめ。
ILB について
仮想IPアドレスを構成する必要あり。
vRealize Log Insight で検索クエリが管理されている再に、できるアクションは？
- クエリのロード
- クエリのスナップショット取得
- 現在のクエリの共有
クエリの複製や、現在のクエリの停止は不可
参考記事
Professional VMware vSphere 6.7 (2V0-21.19, VCP-DCV 2020) を合格するには