Omnissa Access インストールのための仮想マシンの準備

この準備フェーズは、Omnissa Access の Control Plane ベースの展開を開始する前に、すべての仮想マシン、ネットワーク、証明書、およびインフラストラクチャの前提条件に沿った準備が確実に行われるようにします。

この展開モデルでは、プラットフォームおよびアプリケーション サービスが専用の仮想マシン全体に展開され、Control Plane フレームワークを介して調整されます。展開ワークフローを開始する前に、必要なすべての仮想マシンとサポート インフラストラクチャをプロビジョニングして検証する必要があります。

展開トポロジの要件

展開モデルでは、ブートストラップ、インフラストラクチャ/プラットフォーム サービス、Omnissa Access サービスに専用の仮想マシンを使用します。

標準の本番環境の展開は、次のノードで構成されます。

必要なノードの合計数：小規模または中規模を使用している場合は 6、大規模を使用している場合は 7。

重要：

• インストール ワークフローを開始する前に、すべての仮想マシンが展開され、アクセスできる必要があります。
• すべてのノードに固定 IP アドレス、DNS レコード、およびホスト名を構成する必要があります。
• configuser のパスワードは、すべてのノードで一貫して構成する必要があります。
• configuser のデフォルトのパスワード有効期限は、OVA 展開の日付から 60 日です。すべてのクラスタ ノードで同じパスワードをリセットする必要があります。
• Control Plane ブートストラップとクラスタの初期化が完了した後、ノード ロールまたは展開トポロジの変更はサポートされません。
• すべてのノードは、必要なネットワーク ポートを介して相互に通信できる必要があります。
• 展開の前に、Omnissa Access ノードの前にロード バランサを構成する必要があります。

高可用性のためのインフラストラクチャ セットアップ ガイドライン

問題が発生してもシステムが動作し続けられるようにするには、次のルールに従って、インフラストラクチャとプラットフォーム用の仮想マシン (VM) を作成します。

各ノードは異なる物理マシン（ESX ホスト）で実行します。 たとえば、3 つのインフラストラクチャ/プラットフォーム ノードと 2 つの Omnissa Access ノードが必要な場合は、次のように配置します。

• インフラストラクチャ/プラットフォーム ノード 1 → 物理ホスト 1
• インフラストラクチャ/プラットフォーム ノード 2 → 物理ホスト 2
• インフラストラクチャ/プラットフォーム ノード 3 → 物理ホスト 3
• Omnissa Access ノード 1 → 物理ホスト 1
• Omnissa Access ノード 2 → 物理ホスト 2

この方法では、1 台の物理ホストが停止しても、サービスは他の 2 台を使用して実行でき、システムの可用性と安定性を維持できます。

ハードウェアのサイズ要件

次のサイジングは、Omnissa Access の Control Plane ベースの展開にのみ適用されます。

環境内のユーザー、グループ、およびアプリケーションの数に基づいて展開サイズを選択します。

次の表に、各展開サイズに必要な最小ハードウェア構成を示します。

展開サイズ別の最小ハードウェア構成：

¹ インフラストラクチャ/プラットフォーム ノードは、データベース、メッセージング、キャッシュ、検索を含む内部プラットフォーム サービスをホストします（PostgreSQL、Redis、Kafka、OpenSearch）。

*ブートストラップ ノードには、展開サイズに関係なく、8 個の vCPU が必要です。

重要：

• リソースのサイズは、認証の負荷、有効なサービス、および統合の要件によって異なる場合があります。
• ログ、監査の保持、および運用上の要件に基づいて、追加のストレージ割り当てが必要になる場合があります。

すべてのノードの要件

Omnissa Customer Connect ページから Omnissa Access OVA をダウンロードし、Omnissa Access を選択します。ファイルをダウンロードしたら、すべての仮想マシンを展開します。

展開の前に、すべてのノードに対して次の要件が満たされていることを確認します。

• 固定 IP アドレスが割り当てられています。
• ホスト名が正しく構成されています。
• cp-cluster.ini ファイルでホスト名を使用している場合は、DNS 解決が構成され、検証されています。
• SSH アクセスが有効です。
• ネットワーク経由ですべてのノードが相互にアクセス可能です。
• ロード バランサが構成され、アクセス可能です。
• configuser パスワードが構成されているか、すべてのノードで同じパスワードにリセットされています。

目的は、オペレーティング システムとベース インフラストラクチャが完全に準備され、展開中に Control Plane サービスに干渉しないようにすることです。

証明書の要件

展開の前に必要な TLS 証明書を準備します。

Omnissa Access の FQDN 証明書

Omnissa Access 展開の FQDN には TLS 証明書が必要です。

証明書の要件：

• PEM 形式 (.pem)。
• CN はプライマリ テナントの FQDN と一致する必要があります。
• 証明書には、次のサブジェクト代替名 (SAN) が含まれている必要があります。
  • tenant.example.com
  • tenant-cert.example.com
  • tenant-amsso.example.com

ワイルドカード証明書は、必要な SAN エントリを満たす場合にサポートされます。

例：

展開ドメインが example.com の場合、証明書の SAN エントリは次のようになります。

• tenant.example.com
• tenant-cert.example.com
• tenant-amsso.example.com

証明書とプライベート キー ファイルは、展開の構成時に必要です。

ネットワーク構成の要件

Unified Access Gateway 2.8 以降では、リバース プロキシ機能がサポートされているため、ユーザーに Omnissa Access 統合カタログへの安全なリモート アクセスを提供できます。Unified Access Gateway は、Omnissa Access アプライアンスのフロントエンドとして動作するロード バランサの背後の DMZ に展開できます。

ポートの要件

次のポート要件は、内部および外部通信用です。

重要：

• 展開の前に、必要なファイアウォール ルールが構成されていることを確認します。
• インフラストラクチャと Omnissa Access ノード間で内部プラットフォーム ポートにアクセスできる必要があります。
• パブリック向けポートは、ロード バランサまたはリバース プロキシを介してのみ公開する必要があります。
• ポートの公開は、展開アーキテクチャとセキュリティ要件によって異なる場合があります。