VMware Cloud Director アプライアンスのサイジング ガイドライン

必要に応じて、VMware Cloud Director アプライアンス ベースのサーバ グループに個別の構成を使用したり、VMware Cloud Director 仮想アプライアンス インスタンスに異なるサイズを使用したりできます。

概要

プライマリ セルで障害が発生した場合にクラスタが自動フェイルオーバーをサポートできるように、VMware Cloud Director の最小デプロイは 1 つのプライマリ セルと 2 つのスタンバイ セルで構成される必要があります。この環境は、何らかの理由でいずれかのセルがオフラインになる障害シナリオでも引き続き利用できます。スタンバイ障害が発生した場合、障害が発生したセルを再デプロイするまで、クラスタはパフォーマンスをいくらか低下させながら完全に機能した状態で動作します。アプライアンス環境とデータベースの高可用性構成を参照してください。

VMware Cloud Director アプライアンスには、デプロイ時に選択できる 4 つのサイズ（小、中、大、特大 (VVD)）があります。小規模アプライアンス サイズはラボの評価に適しています。このドキュメントでは、小規模アプライアンス構成に関するガイダンスは提供していません。サイジング オプションの表に、その他のオプションの仕様と、本番環境に最適な使用事例を示します。特大構成は、VMware Validated Designs (VVD) for Cloud Providersのスケール プロファイルと一致しています。

より大きなカスタム サイズを作成するために、システム管理者はデプロイされたセルのサイズを調整できます。

本番環境で推奨される最小の構成は、中規模仮想アプライアンスの 3 ノードによるデプロイです。

重要： VMware は、データベース HA のない VMware Cloud Director アプライアンスのデプロイ環境にはサポートを提供しません。

VMware Cloud Director アプライアンスのサイジング オプション

次の決定ガイドを使用して、環境のアプライアンス サイズを見積もることができます。

	中	大	特大 (VVD)
推奨される使用事例	ラボ環境または小規模な本番環境	本番環境	API 統合および監視を使用する本番環境
vRealize Operations Management Pack 環境での VMware Cloud Director のデプロイ	いいえ	いいえ	はい
VMware Cloud Director での Cassandra 仮想マシン メトリックの有効化	いいえ	いいえ	はい
30 分のピーク期間に API にアクセスする同時実行ユーザーまたはクライアントの概数。	< 50	< 100	< 100
管理対象仮想マシン	5,000	5,000	15,000

構成の定義

	中	大	特大 (VVD)
HA クラスタ構成	1 つのプライマリ セル + 2 つのスタンバイ セル	1 つのプライマリ セル + 2 つのスタンバイ セル + 1 つのアプリケーション セル	1 つのプライマリ セル + 2 つのスタンバイ セル + 2 つのアプリケーション セル
プライマリまたはスタンバイ セルの vCPU	8	16	24
アプリケーション セルの vCPU	該当なし	8	8
プライマリまたはスタンバイ セルの RAM	16 GB	24 GB	32 GB
アプリケーション セルの RAM	該当なし	8	8
vCPU と物理コアの比率	1:1	1:1	1:1
クラスタ内の各アプライアンスの最小ディスク容量	112 GB	112 GB	112 GB

システムがサイズ不足かどうかを検出する方法

VMware Cloud Director セルでは、CPU またはメモリの使用量が増加すると、高レベル、つまりキャパシティ近くのレベルで推移します。また、VMware Cloud Director セルでデータベースへの接続が切断される場合があります。

システムのセル数が不十分かどうかを検出する方法

いずれかの VMware Cloud Director セルの vcloud-container-debug.log および cell-runtime.log ファイルに以下のようなエントリが記録されます： org.apache.tomcat.jdbc.pool.PoolExhaustedException: [pool-jetty-XXXXX] Timeout: Pool empty.Unable to fetch a connection in 20 seconds, none available。また、 VMware Cloud Director セルでデータベースへの接続が切断される場合があります。

注：

デフォルトのデータベース接続構成に基づいて、すべての構成は、プライマリ、スタンバイ、アプリケーション タイプで最大 6 セルに制限されます。

アプライアンスのサイジングをカスタマイズする方法

vpostgres-reconfigure サービス アプライアンス デプロイの実行後に、VMware Cloud Director アプライアンスのサイジングをカスタマイズしてカスタム構成を実現するには、2 つの方法があります。

• vpostgres-reconfigure サービスを使用して、アプライアンスのサイジングをカスタマイズします。
• postgresql.auto.conf ファイルを手動で更新して、アプライアンスのサイジングをカスタマイズします。

vpostgres-reconfigure サービスを使用して VMware Cloud Director アプライアンスのサイジングをカスタマイズするには、vSphere Client で仮想マシンのハードウェア設定を編集します。アプライアンスが起動するたびに vpostgres-reconfigure サービスが実行され、仮想マシンのサイズに合わせて PostgreSQL 設定が変更されます。

注： vpostgres-reconfigure サービスによって、以前に手動で行った postgresql.auto.conf のカスタマイズが変更されることはありません。

手動でカスタマイズする場合は、postgresql.auto.conf ファイルを編集します。手動によるカスタマイズは、vpostgres-reconfigure サービスのカスタマイズよりも優先されます。アプライアンスのサイジングを手動でカスタマイズするには、すべてのセルで次の手順を実行します。

1. プライマリ アプライアンスの OS に root として直接ログインするか、SSH クライアントを使用して接続します。
2. vCPU 情報を表示してメモするには、次のコマンドを実行します。

   grep -c processor /proc/cpuinfo

3. RAM 情報を表示してメモするには、次のコマンドを実行します。

   以下で報告されている RAM は KB 単位であるため、1048576 (1024*1024) で割って GB に変換する必要があります。

   cat /proc/meminfo | grep MemTotal | cut -dk -f1 | awk '{print int($2/1048576)}'

4. shared_buffers の値を計算するには、RAM の合計から 4 GB を引き、1/4 倍して、floor 処理を行います。

   shared_buffers = floor [ 0.25 * (total RAM - 4 GB) ]

   ここで、floor は角括弧内の値以下となる最大の整数を返します。

5. effective_cache_size の値は、RAM の合計から 4 GB を引き、3/4 倍して計算します。

   effective_cache_size = 0.75 * (total RAM - 4 GB)

6. max_worker_processes の値は vCPU の数として計算します。

   デフォルトの値（最小値）は 8 です。

7. ユーザーを postgres に変更します。

   sudo -i -u postgres

8. 次のコマンドを実行し、計算した値に置き換えて Postgresql.auto.conf 構成ファイルを更新します。

   psql -c "ALTER SYSTEM set shared_buffers = 'shared_buffers value';"
   psql -c "ALTER SYSTEM set effective_cache_size =  'effective_cache_size value';"
   psql -c "ALTER SYSTEM set work_mem = '8MB';"
   psql -c "ALTER SYSTEM set maintenance_work_mem = '1GB';"
   psql -c "ALTER SYSTEM set max_worker_processes= 'max_worker_processes value';"
   

9. exit コマンドを実行して root ユーザーに戻ります。
10. vpostgres プロセスを再起動します。

    systemctl restart vpostgres

11. ユーザーを postgres に再度変更します。

    sudo -i -u postgres

12. 各スタンバイ ノードで、postgresql.auto.conf ファイルをノードにコピーし、vpostgres プロセスを再開します。
    1. postgresql.auto.conf をプライマリ ノードからスタンバイ ノードにコピーします。

       scp /var/vmware/vpostgres/current/pgdata/postgresql.auto.conf postgres@standby-node-address:/var/vmware/vpostgres/current/pgdata/

    2. vpostgres プロセスを再起動します。

       systemctl restart vpostgres

手動によるカスタマイズを削除して、 vpostgres-reconfigure サービスを引き続き使用するには、ユーザーを postgres に変更し、次のコマンドを実行します。

psql -c "ALTER SYSTEM reset shared_buffers;"
    psql -c "ALTER SYSTEM reset effective_cache_size;"
    psql -c "ALTER SYSTEM reset max_worker_processes;"