VMware のリソースの推奨事項を vRealize Automation 展開計画の開始点として使用します。

初期のテストと本番環境への展開後も、引き続きパフォーマンスを監視し、必要に応じてvRealize Automation のスケーラビリティの説明に従って追加のリソースを割り当てます。

認証

vRealize Automation を構成するときに、ユーザー認証にデフォルトのディレクトリ管理コネクタを使用するか、既存の SAML ベースの ID プロバイダを指定してシングル サインオン環境をサポートできます。

2 要素認証が必要な場合、vRealize Automation は RSASecurID との統合をサポートします。この統合ポイントが構成されると、ユーザーにはユーザー ID およびパスコードを要求されます。

ロード バランサの考慮事項

最小応答時間またはラウンドロビン方式を使用して、vRealize Automation アプライアンスとインフラストラクチャの Web サーバにトラフィックを分散します。セッション アフィニティ(スティッキー セッション)機能を有効にして、後続の要求を各一意のセッションからロード バランサ プール内の同じ Web サーバに送信できます。

ロード バランサを使用して Manager Service のフェイルオーバーを管理できますが、Manager Service は一度に 1 つのみアクティブになるため、ロード バランシング アルゴリズムは使用しないでください。また、ロード バランサでフェイルオーバーを管理するときは、セッション アフィニティを使用しないでください。

vRealize Automation Appliance をロード バランシングする場合は、ポート 443 と 8444 を使用します。Infrastructure Web サイトと Infrastructure Manager Service の場合は、ポート 443 のみロード バランシングする必要があります。

他のロード バランサも使用できますが、NSX、F5 BIG-IP ハードウェア、および F5 BIG-IP Virtual Edition はテスト済みで使用が推奨されます。

ロード バランサの構成の詳細については、vRealize Automation のドキュメントを参照してください。

データベースの展開

vRealize Automation は、7.0 以降のリリースでは、アプライアンス データベースを自動的にクラスタ化します。7.0 以降のすべての新しい展開では、内部アプライアンス データベースを使用する必要があります。7.1 以降にアップグレードする vRealize Automation インスタンスの外部データベースはアプライアンス データベースにマージする必要があります。アップグレード プロセスの詳細については、vRealize Automation の製品ドキュメントを参照してください。

インフラストラクチャ コンポーネントを本番環境に展開する場合は、専用のデータベース サーバを使用して Microsoft SQL Server (MSSQL) データベースをホストします。vRealize Automation には、Microsoft 分散トランザクション コーディネータ サービス (MSDTC) を使用するように構成されているデータベース サーバと通信するマシンが必要です。デフォルトで、MSDTC にはポート 135 とポート 1024 ~ 65535 が必要です。

デフォルトの MSDTC ポートの変更の詳細については、Microsoft のナレッジベース記事「Configuring Microsoft Distributed Transaction Coordinator (DTC) to work through a firewall」を参照してください。この記事は、https://support.microsoft.com/ja-jp/kb/250367 で参照できます。

IaaS Manager Service ホストでは、IaaS SQL Server データベース ホストの NETBIOS 名を解決できる必要があります。NETBIOS 名を解決できない場合は、Manager Service マシンの /etc/hosts ファイルに、SQL Server の NETBIOS 名を追加し、Manager Service を再起動します。

vRealize Automation は、Microsoft SQL Server 2016 でのみ SQL AlwaysON グループをサポートしています。SQL Server 2016 をインストールする場合は、データベースを 100 モードで作成する必要があります。Microsoft SQL Server の古いバージョンを使用する場合は、共有ディスクを使用してフェイルオーバー クラスタ インスタンスを使用します。MSDTC を使用した SQL AlwaysOn グループの構成については、https://msdn.microsoft.com/ja-jp/library/ms366279.aspx を参照してください。

データ収集の設定

デフォルトのデータ収集設定では、ほとんどの実装環境に対応する収集開始ポイントが指定されています。本番環境への展開後も、引き続きデータ収集のパフォーマンスを監視して、調製を行う必要があるかどうか確認します。

プロキシ エージェント

パフォーマンスを最大にするには、関連付けられているエンドポイントと同じデータセンターにエージェントを展開します。追加のエージェントをインストールして、システムのスループットと並行性を向上させることができます。分散展開には世界各地に分散された複数のエージェント サーバを含めることができます。

エージェントを関連付けられているエンドポイントと同じデータセンターにインストールした場合、データ収集のパフォーマンスは平均で 200% 向上する可能性があります。測定される収集時間には、プロキシ エージェントと Manager Service 間でのデータの転送時間のみが含まれます。Manager Service でデータを処理する時間は含まれません。

たとえば、製品をパロアルトのデータセンターに展開し、vSphere エンドポイントがパロアルト、ボストン、およびロンドンにあるとします。 この構成では、vSphere プロキシ エージェントはパロアルト、ボストン、およびロンドンの各エンドポイントに展開されます。エージェントがパロアルトのみに展開された場合は、ボストンとロンドンのデータ収集時間が 200% 増える可能性があります。

Distributed Execution Manager の構成

一般的に、Distributed Execution Manager (DEM) は、Model Manager ホストにできるだけ近い場所に置きます。DEM Orchestrator には常に Model Manager への強力なネットワーク接続が必要です。インストーラは、デフォルトで、Manager Service とともに DEM Orchestrator を配置します。プライマリ データセンターに、フェイルオーバー用と 2 つの DEM ワーカー インスタンス用に 2 つの DEM Orchestrator インスタンスを作成します。

DEM ワーカー インスタンスが場所に固有のワーフクローを実行する場合は、その場所にインスタンスをインストールします。

スキルを関連のワークフローと DEM に割り当てて、それらのワークフローが常に適切な場所にある DEM で実行されるようにします。vRealize Automation デザイナ コンソールを使用したワークフローと DEM へのスキルの割り当てについては、vRealize Automation 拡張機能のドキュメントを参照してください。

最適なパフォーマンスにするには、DEM とエージェントを個別のマシンにインストールします。vRealize Automation エージェントのインストールの詳細については、エージェントのインストールを参照してください。

vRealize Orchestrator

すべての新しい導入環境で、内部 vRealize Orchestrator インスタンスを使用します。必要な場合には、従来の導入環境では引き続き外部 vRealize Orchestrator を使用できます。内部 vRealize Orchestrator インスタンスに割り当てられたメモリを増やす手順については、 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147109 を参照してください。

最適な製品パフォーマンスを得るためには、vRealize Orchestrator のコンテンツを本番環境にインポートする前に、『vRealize Orchestrator Coding Design Guide』の構成ガイドラインを確認して実装します。