Omnissa Access のインストール

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

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

環境にディザスタ リカバリ (DR) サイトを構成する場合、NFS ストレージは必須です。前提条件については、「Omnissa Access のディザスタ リカバリの構成」を参照してください。

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

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

アーキテクチャの概要

Omnissa Access は、Control Plane によって管理されるコンテナ化されたマイクロサービスのセットとして実行されます。Omnissa Access を構成するサービスは、AlmaLinux 9.6 を実行している専用仮想マシンのクラスタ全体に分散され、独立したワークロードとして展開および運用されます。各サービスは独自に実行されるため、個別に更新、再起動、拡張、リカバリできます。

Control Plane

Control Plane は、Omnissa Access 環境を構成するサービスをインストール、実行、拡張、監視するプラットフォームです。次の 3 つのプラットフォーム サービスを使用して、クラスタ内のすべてのサービスを調整します。

• Nomad は、サービス ワークロードをスケジューリングして調整します。
• Consul は、サービス検出とサービス間の安全な内部通信を提供します。
• Vault は、シークレット、証明書、トークンの保存と管理を行います。

サービス カテゴリ

Omnissa Access 環境は、次の 3 つのカテゴリのサービスで構成されています。

ノード タイプ

Omnissa Access クラスタは、3 種類の仮想マシンとロード バランサから構築されます。

• ブートストラップ ノード - 展開コントローラ。このノードから WSO CLI を実行して、クラスタを展開して操作します。
• インフラストラクチャ/プラットフォーム ノード - プラットフォーム サービスとインフラストラクチャ サービスをホストします。
• Omnissa Access ノード - Omnissa Access サービスをホストします。プラットフォーム サービスもこれらのノードで実行されます。
• ロード バランサ - Omnissa Access ノード全体にトラフィックを分散し、Access サービスの高可用性を提供します。

プラットフォーム サービスは、インフラストラクチャ/プラットフォーム ノードと Omnissa Access ノードの両方で実行されるため、オーケストレーション、サービス検出、シークレット管理は、単一ノードに応じてではなく、クラスタ全体で引き続き機能します。

WSO CLI

WSO CLI（Workspace ONE コマンドライン インターフェイス）は、Omnissa Access を展開および運用するためのプライマリ インターフェイスです。WSO CLI コマンドは、ブートストラップ ノードから実行します。

展開の概要

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

展開段階

1. 仮想マシンを準備します。
2. 仮想マシンを展開します。
3. Omnissa Access の展開：次のいずれかを選択します。
   • オプション 1：Access Wizard を使用。
   • オプション 2：手動で段階的に実行。

展開アーキテクチャ

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

• 必要な仮想マシン

  ノード タイプ	数	目的
  インフラストラクチャ/プラットフォーム ノード	3	インフラストラクチャ サービス
  Omnissa Access ノード	小規模および中規模の場合は 2 大規模の場合は 3	Access アプリケーション サービス
  ブートストラップ ノード	1	展開コントローラ
  ロード バランサ	-	Access サービスの高可用性 (HA) のため

  **注：**プラットフォーム サービスは、インフラストラクチャ/プラットフォーム ノードと 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