Workspace ONE Access のアップグレード後の構成

Workspace ONE Access 21.08 にアップグレードした後で、特定の設定を構成することが必要になる場合があります。

Workspace ONE Access Connector インスタンスの構成

新しい仮想アプリケーションサービス、セキュリティの更新、解決済みの問題などの最新機能を入手するには、既存の Workspace ONE Access Connector のインストールをバージョン 21.08 にアップグレードします。Workspace ONE Access Connector は、Workspace ONE Access のコンポーネントです。VMware Workspace ONE Access Connector 21.08 のインストールガイドを参照してください。

Log4j 構成ファイル

Workspace ONE Access インスタンスの log4j 構成ファイルを編集した場合、新しいバージョンのファイルはアップグレード中に自動的にインストールされません。ただし、アップグレード後、それらのファイルによって制御されるログは動作しません。

この問題を解決するには：

仮想アプライアンスにログインします。
.rpmnew サフィックスを持つ log4j ファイルを検索します。
find / -name "*log4j.properties.rpmnew"
見つかったファイルごとに、新しいファイルを .rpmnew サフィックスのない対応する古い log4j ファイルにコピーします。

Workspace ONE UEM 構成を保存します。

Workspace ONE UEM 構成を保存すると、カタログのデバイスサービス URL が入力されます。このタスクを実行すると、新しいエンドユーザーがデバイスを登録および管理できるようになります。

Workspace ONE Access コンソールにログインします。
[ID とアクセス管理] > [セットアップ] > [VMware Workspace ONE UEM] を選択します。
[Workspace ONE UEM 構成] セクションで、[保存] をクリックします。

セカンダリデータセンターのクラスタ ID

クラスタ ID はクラスタ内のノードを識別するために使用されます。

Workspace ONE Access 21.08 の展開にセカンダリデータセンターが含まれている場合は、アップグレード後にセカンダリデータセンターのクラスタ ID の変更が必要になる場合があります。

新しいサービスアプライアンスが起動されると、Workspace ONE Access はクラスタ ID を自動的に検出して割り当てます。複数のデータセンターがある環境では、各クラスタを一意の ID で識別する必要があります。

クラスタに属するすべてのアプライアンスは同じクラスタ ID を持ち、クラスタは通常、3 つのアプライアンスで構成されます。

セカンダリデータセンターをセットアップするときは、クラスタ ID がデータセンターに一意であることを確認します。クラスタ ID がデータセンターに一意でない場合は、各ノードに Elasticsearch discovery-idm プラグインがインストールされていることを確認し、次の手順に従ってクラスタ ID を手動で編集します。これらの操作はセカンダリデータセンターでのみ 1 回だけ実行する必要があります。

各ノードに Elasticsearch discovery-idm プラグインがあることを確認します。
1. 仮想アプライアンスにログインします。
2. 次のコマンドを使用して、プラグインがインストールされているかを確認します。
  /opt/vmware/elasticsearch/bin/plugin list
3. プラグインが存在しない場合は、次のコマンドを使用して追加します。
  /opt/vmware/elasticsearch/bin/plugin install file:///opt/vmware/elasticsearch/jars/discovery-idm-1.0.jar
Workspace ONE Access コンソールにログインします。
[ダッシュボード] > [システム診断ダッシュボード] タブを選択します。
一番上のパネルで、セカンダリデータセンタークラスタのクラスタ情報を見つけます。
セカンダリデータセンターのすべてのノードのクラスタ ID を、最初のデータセンターで使用されているものとは異なる番号に更新します。
たとえば、最初のデータセンターが 2 を使用していない場合は、セカンダリデータセンターのすべてのノードを 2 に設定します。
プライマリデータセンターとセカンダリデータセンターの両方のクラスタが正しく構成されていることを確認します。
プライマリデータセンターとセカンダリデータセンターにある各ノードで以下の手順に従って操作します。
1. 仮想アプライアンスにログインします。
2. 次のコマンドを入力します。
  curl 'http://localhost:9200/_cluster/health?pretty'
  
  クラスタが正しく構成されている場合、コマンドは次の例のような結果を返します。
```
{
  "cluster_name" : "horizon",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 20,
  "active_shards" : 40,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0
}
```

セカンダリデータセンターアプライアンスのキャッシュサービス設定

セカンダリデータセンターを設定すると、セカンダリデータセンターの Workspace ONE Access インスタンスには、/usr/local/horizon/conf/runtime-config.properties ファイルの "read.only.service=true" エントリによって読み取り専用アクセスが構成されます。このようなアプライアンスをアップグレードすると、サービスは起動に失敗します。

この問題を解決するには、次の手順を実行してください。手順には、次の 3 つのノードを含むセカンダリデータセンターのシナリオ例が含まれています。


sva1.example.com
sva2.example.com
sva3.example.com

セカンダリデータセンターの仮想アプライアンスに root ユーザーとしてログインします。
この例では、sva1.example.com にログインします。
次のサブ手順に示されているように、/usr/local/horizon/conf/runtime-config.properties ファイルを編集します。
既存のエントリを編集することも、新しいエントリを追加することもできます。該当する場合は、コメントアウトされているエントリのコメントアウトを外します。
1. cache.service.type エントリの値を ehcache に設定します。
```
cache.service.type=ehcache
```
2. ehcache.replication.rmi.servers エントリの値を、セカンダリデータセンター内の他のノードの完全修飾ドメイン名 (FQDN) に設定します。区切り文字にはコロン : を使用します。
この例では、エントリを次のように設定します。
```
ehcache.replication.rmi.servers=sva2.example.com:sva3.example.com
```
サービスを再起動します。
service horizon-workspace restart
セカンダリデータセンターの残りのノードで前述の手順を繰り返します。
この例では、設定する残りのノードは sva2.example.com と sva3.example.com です。

Workspace ONE Access Connector インスタンスの構成

Log4j 構成ファイル

Workspace ONE UEM 構成を保存します。

セカンダリ データセンターのクラスタ ID

セカンダリ データ センター アプライアンスのキャッシュ サービス設定

セカンダリデータセンターのクラスタ ID

セカンダリデータセンターアプライアンスのキャッシュサービス設定