Omnissa Access のインストール

Control Plane に Omnissa® Access™ を展開するには、このガイドに記載されている手順に従います。

『Omnissa Access のインストールと構成』ガイドのこの「Omnissa Access のインストール」セクションでは、環境に Omnissa Access を展開するためのエンドツーエンドのプロセスについて説明します。これには、展開の概要、Omnissa Access クラスタを構成するプラットフォーム コンポーネントの説明、サポートされている展開アーキテクチャ、および仮想マシンの初期準備からテナント作成までの段階的なインストール手順が含まれます。

このガイドでは、インストール完了後の展開の準備と運用に役立つ、構成と管理に関するトピックについても説明します。

構成が完了したら、Omnissa Access コンソールを使用して、ユーザーとグループの管理、認証およびアクセス ポリシーの設定と管理、カタログへのリソースの追加、およびそれらのリソースの資格管理を行えます。Workspace ONE UEM 統合を構成し、Hub Services を起動することもできます。

デプロイの概要

Omnissa Access は、Control Plane プラットフォームに複数のフェーズで展開されます。各フェーズは、前のフェーズの正常な完了に依存します。

展開段階

1. 仮想マシンを準備します。
2. ブートストラップ ノードとアセットを設定します。
3. Control Plane クラスタを初期化します。
4. Control Plane プラットフォームを展開します。
5. インフラストラクチャおよび Access サービスを展開します。
6. テナントを作成します。

プラットフォーム コンポーネントの概要

次の表に、Omnissa Access に必要なプラットフォーム コンポーネントを示します。

展開アーキテクチャ

Omnissa Access での必要性に応じて、次のアーキテクチャ関連の詳細が満たされていることを確認します。

• 必要な仮想マシン

  ノード タイプ	数	目的
  インフラストラクチャ/プラットフォーム ノード	3	インフラストラクチャ サービス
  Omnissa Access ノード	2 個以上	Access アプリケーション サービス
  ブートストラップ ノード	1	展開コントローラ
  ロード バランサ	-	Access サービスの高可用性 (HA) のため
  合計	6 台以上の仮想マシン

  **注：**プラットフォーム サービスは、すべての管理ノードと Omnissa Access ノードで実行されます。

• サービス配置

  ノード	サービス
  インフラストラクチャ/プラットフォーム ノード	Nomad、Consul、Vault、Postgres、Redis、Kafka、OpenSearch
  Omnissa Access ノード	Nomad、Consul、Vault、Access サービス
  ブートストラップ ノード	展開/管理操作

  すべてのノードが次の要件を満たしていることを確認します。

  • AlmaLinux 9.6 の実行
  • 固定 IP アドレスがある
  • 一意のホスト名がある
  • ブートストラップ ノードからの SSH アクセス権がある

• ロード バランサー構成

  ロード バランサを構成し、Access サービス ノードをアップストリームに追加して、ロード バランサがいずれかのノードにリダイレクトできるようにします。構成要件については、「ロード バランサまたはリバース プロキシを使用して、Omnissa Access への外部アクセスを有効にする」を参照してください。

• DNS 解決

  • **DNS エントリ：**DNS エントリが FQDN IP アドレス（ロード バランサの IP アドレス）に解決されることを確認します。

    tenant.example.com

• 証明書の要件

  • **共通名 (CN)：**ロード バランサのホスト名 (tenant.example.com)。

  • サブジェクトの代替名 (SAN)：

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

    すべての SAN エントリのドメイン部分が、ロード バランサおよびクラスタ ノードで使用されるドメインと一致していることを確認します。

    注：

    • ワイルドカード証明書（*.tenant.example.com など）を使用して、すべての SAN をカバーするように選択できます。
    • 証明書ベースの認証を使用していない場合は、tenant.example.com のみが必要な SAN です。tenant-cert.example.com と tenant-amsso.example.com は省略できます。

  CSR リファレンス

  証明書のタイプに応じて、次のいずれかの構成を使用します。

  ワイルドカード証明書

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = *.tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = *.tenant.example.com
  

  非ワイルドカード証明書（すべての SAN が必要）

  ワイルドカード証明書を使用していない場合は、サブジェクト代替名をそれぞれ明示的に指定します。

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = tenant.example.com
  DNS.2 = tenant-cert.example.com
  DNS.3 = tenant-amsso.example.com