8 Oracle ACFSスナップショットベースのレプリケーションの構成

Oracle ACFSスナップショットベースのレプリケーションの要件については、この項で説明しています。

この章では、リリース12.2以上で使用可能なOracle ACFSスナップショットベースのレプリケーションを構成する方法について説明します。リリース12.2より前のOracle ACFSレプリケーションのインストールと同様に、スナップショットベースのレプリケーションの全体的な機能上の目標は、プライマリ・クラスタの更新がスタンバイ・クラスタにレプリケートされるようにすることです。ただし、スナップショットベースのレプリケーション・テクノロジは、プライマリ・ストレージ・ロケーションのスナップショットを使用し、連続するスナップショットの差分を、標準のsshコマンドを使用してスタンバイ・ストレージ・ロケーションに転送します。リリース12.2より前のOracle ACFSレプリケーション機能では、プライマリ・クラスタとスタンバイ・クラスタ間の接続性を確保するために、Network Foundation Technologies (NFT)を中心としてOracleネットワーキング・テクノロジを基に、絶えず変更をレプリケートしました。

Oracle ACFSレプリケーションの設計および実装におけるこの変更により、レプリケーションの構成および使用方法に若干の相違が発生しています。たとえば、sshを使用するには、レプリケーションを実行するプライマリ・ノードとスタンバイ・ノードでホスト・キーおよびユーザー・キーを適切に設定する必要があります。

Oracle ACFSレプリケーションには、ロール・リバーサル機能が用意されています。この機能は、プライマリ・クラスタとスタンバイ・クラスタの両方が必要に応じてもう一方のクラスタと通信できるようにすることで構成できます。ロール・リバーサルでは、スタンバイがプライマリのロールを引き受け、プライマリがスタンバイになります。

この章のトピックは、次のとおりです:

• Oracle ACFSレプリケーションで使用するためのsshの構成

• Oracle ACFSスナップショットベースのレプリケーションへのアップグレード

関連項目:

• Oracle ACFSレプリケーションの概要は、Oracle ACFSレプリケーションを参照してください

• Oracle ACFSレプリケーション・コマンドの詳細は、レプリケーション用のOracle ACFSコマンドライン・ツールを参照してください

• Oracle ASM権限の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください

Oracle ACFSレプリケーションで使用するためのsshの構成

このトピックでは、リリース12.2以上で使用可能なOracle ACFSスナップショットベースのレプリケーションを使用するためにsshを構成する方法について説明します。

Oracle ACFSスナップショットベースのレプリケーションでは、sshをプライマリ・クラスタとスタンバイ・クラスタ間のトランスポートとして使用します。レプリケーションの全機能をサポートするには、クラスタ間のどちらの方向(プライマリ・クラスタからスタンバイ・クラスタ、およびスタンバイからプライマリ)でもsshが使用可能である必要があります。

このトピックの手順では、プライマリからスタンバイの単一方向でのレプリケーション用のsshの構成方法について説明します。sshを完全に構成するには、2回目にプライマリとスタンバイのロールを逆転して手順を実行する必要があります。1回目にステップを実行するときは、プライマリ・クラスタとスタンバイ・クラスタ用に記述されているステップを実行します。2回目には、プライマリ・ロールとスタンバイ・ロールを入れ替えます。プライマリ・クラスタで必要と示されているステップをスタンバイ・クラスタで実行し、スタンバイ・クラスタで必要と示されているステップをプライマリ・クラスタで実行します。2回実行する必要がある手順は、以下で説明しています。

• Oracle ACFSレプリケーション・ユーザーの選択

• Oracle ACFSレプリケーション用のキーの配布

• プライマリ・クラスタからのroot用および補充ユーザー用の公開キーの取得

• スタンバイ・クラスタ用のホスト・キーの取得

• ssh関連ファイルに対する権限に関する注意事項

• sshdの構成に関する注意事項

• ssh関連のキー構成の検証

必要なすべての手順を完了したら、「ssh関連のキー構成の検証」の手順を使用して、両方向でsshが正しく構成されていることを確認できます。

Oracle ACFSレプリケーション・ユーザーの選択

Oracle ACFSスナップショットベースのレプリケーションでは、sshをプライマリ・クラスタとスタンバイ・クラスタ間のトランスポートとして使用するため、スタンバイでレプリケーションを実行するユーザー・アイデンティティは慎重に管理する必要があります。レプリケーション・プロセスでは、レプリケーションが実行されているプライマリ・ノード上のrootユーザーは、sshを使用して、レプリケーションにかかわるスタンバイ・ノードにログインします。

sshでrootとしてスタンバイ・ノードにログインすることは望ましくないため、最小限の権限を付与したユーザー・アイデンティティを使用する必要があります。選択したユーザーには、Oracle ASM管理権限が必要です。通常、Oracleソフトウェアの初回インストール時にOracleインストーラに指定したユーザーは必要なグループに属するため、レプリケーション・ユーザーとして選択するのに好都合です。ここでの説明では、レプリケーション・ユーザーをrepluserとして識別しますが、選択した実際のユーザー名でrepluserを置き換えます。Oracle ACFS acfsutilコマンドの実行の詳細は、「Oracle ACFSコマンドライン・ツールの使用について」を参照してください。

注意:

プライマリ・クラスタとスタンバイ・クラスタの両方で、repluserに同じユーザーとグループのアイデンティティを指定する必要があります。また、ユーザー名と数値のuids、およびグループ名と数値のgidsとの間のマッピングは、プライマリ・クラスタとスタンバイ・クラスタの両方で同一である必要があります。 レプリケーションでの数値の転送はプライマリからスタンバイに対してのみ行われるため、両方のクラスタで数値が同じように使用されるようにするためにはこれが必須です。

Oracle ACFSレプリケーション用のキーの配布

Oracle ACFSレプリケーション用のキーの配布プロセスには、プライマリ・クラスタからの公開キーの取得、スタンバイ・クラスタ用のホスト・キーの取得、ssh関連ファイル用に権限が正しく構成されていることの確認、必要に応じてsshdの構成、そして最後にssh構成の検証が含まれます。

注意:

ホスト・キーを作成するときは、必ず完全修飾ドメインホスト名とローカル・ホスト名の両方のキーを作成してください。

プライマリ・クラスタからのroot用およびrepluser用の公開キーの取得

プライマリ・クラスタの各ノードに定義されているroot用の公開キーおよびrepluser用の公開キーを、スタンバイ・クラスタの各ノードのrepluserが認識している必要があります。

これらのキーを認識させるには、各スタンバイ・ノードに~repluser/.sshディレクトリが存在する必要があります。このディレクトリが存在しない場合は、repluser専用のアクセス権で作成します。.sshディレクトリに対するlsコマンドの出力が次のようになっていることを確認します。

repluser@standby $ ls -ld ~/.ssh
drwx------ 2 repluser dba 4096 Jan 27 17:01 .ssh

root用の公開キーが特定のプライマリ・ノードに定義されている場合、/root/.ssh/id_rsa.pubなどの.pubファイル内にあります。repluser用の公開キーが特定のノードに存在する場合、それはrepluser用に定義されたホーム・ディレクトリの.pubファイル内に存在します。

ユーザーごとに公開キー・ファイルが存在する場合は、レプリケーションが実行されるスタンバイの各ノードにrepluserとしてログインすることを認可された一連のキーに、その内容を追加します。各スタンバイ・ノードで、必要に応じて~repluser/.ssh/authorized_keys2ファイルを作成し、その最後にキーを追加します。

公開キー・ファイルが存在しない場合は、rootとして次のコマンドを実行してプライマリで公開キーと秘密キーのペアを生成します。root用のキー・ペアを生成するには、コマンドをrootとして実行します。repluser用のキー・ペアを生成するには、コマンドをrepluserとして実行します。

# ssh-keygen -t rsa

コマンドから発行される各プロンプトに応えて、[Enter]キーを押します。結果として生成された.pubファイルを各スタンバイ・ノードにコピーします。

root用またはrepluser用の同じ公開/秘密キーのペアをプライマリ・クラスタ内のすべてのノードで共有することも、プライマリ・ノードごとに異なるキーのペアを設定することもできます。プライマリ・クラスタ内のすべてのノードで同じ公開キーがrootまたはrepluserに対して有効な場合、スタンバイ・クラスタの各ノードで、~repluser/.ssh/authorized_keys2ファイルにそのキーのみを追加する必要があります。各プライマリ・ノードに独自のrootまたはrepluser用の公開キーがある場合は、すべての公開キーをそのファイルに追加する必要があります。いずれの場合も、スタンバイの特定のノードで更新したauthorized_keys2ファイルをクラスタの他のノードにコピーすることで、作業を最小化できます。

スタンバイ・クラスタ用のホスト・キーの取得

レプリケーションが実行される各スタンバイ・ノード用のホスト・キーを、レプリケーションが実行される各プライマリ・ノードで認識させる必要があります。適切なキーを生成する方法の1つとして、各プライマリ・ノードから各スタンバイ・ノードに対してrootとして手動でsshを実行します。適切なホスト・キーがまだ認識されていない場合は警告が表示され、sshを有効にしてキーを追加できます。

ssh接続には2人のユーザーがかかわります。プライマリ・ノードではsshはスタンバイ・ノードにrootとして接続する一方、スタンバイ・ノードではsshはrepluserとしてログインします。スタンバイでsshによって実行されるコマンドは、root権限ではなく、repluserの権限で実行されます。

プライマリ・ノードはスタンバイ・ノードにrootユーザーとして接続するため、スタンバイ・ノード用のホスト・キーをrepluser用のファイルではなく、rootユーザーのknown_hostsファイルに追加する必要があります。次に、ホスト・キーを取得する例を示します。

[root@primary usm]# ssh repluser@standby date
The authenticity of host 'standby (10.137.13.85)' can't be established.
RSA key fingerprint is 1b:a9:c6:68:47:b4:ec:7c:df:3a:f0:2a:6f:cf:a7:0a.
Are you sure you want to continue connecting (yes/no)?

yesと応答すると、sshの設定が完了します。ホスト・スタンバイ用のホスト・キーが、ホスト・プライマリのrootユーザー用のknown_hostsファイル(~root/.ssh/known_hosts)に格納されます。

スタンバイ・ノードに対するホスト・キーの設定が特定のプライマリ・ノードで完了したら、仮想IPアドレス(VIP)を使用してスタンバイ・クラスタと通信する場合は、追加のステップを実行する必要があります。VIP名またはアドレスを、スタンバイ・クラスタ内のホストを参照するknown_hostsファイルの各行の先頭に追加する必要があります。たとえば、名前がstandby12_vipのVIPを使用し、スタンバイを参照する次の2行がknown_hostsファイルに含まれる場合、

standby1,10.242.20.22 ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC3pM2YTd4UUiEWEoCKDGgaTgsmPkQToDrdtU+JtVIq/96muivU
BaJUK83aqzeNIQkh+hUULsUdgKoKT5bxrWYqhY6AlTEqNgBHjBrJt9C73BbQd9y48jsc2G+WQWyuI/
+s1Q+hIJdBNMxvMBQAfisPWWUcaIx9Y/JzlPgF6lRP2cbfqAzixDot9fqRrAKL3G6A75A/6TbwmEW07d1zqOv
l7ZGyeDYf5zQ72F/V0P9UgMEt/5DmcYTn3kTVGjOTbnRBe4A4lY4rVw5c+nZBDFre66XtORfQgwQB5ztW/Pi
08GYbcIszKoZx2HST9AZxYIAgcrnNYG2Ae0K6QLxxxScP
standby2,10.242.20.23 ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDIszcjzNtKN03SY8Kl846skFTVP1HF/ykswbmkctEjL6KTWTW+NR
U4MGbvkBqqdXxuPCR7aoGO2U3PEOg1UVf3DWUoux8IRvqKU+dJcdTibMFkDAIhTnzb14gZ/lRTjn+GYsuP5
Qz2vgL/U0ki887mZCRjWVL1b5FNH8sXBUV2QcD7bjF98VXF6n4gd5UiIC3jv6l2nVTKDwtNHpUTS1dQAi+1D
tr0AieZTsuxXMaDdUZHgKDotjciMB3mCkKm/u3IFoioDqdZE4+vITX9G7DBN4CVPXawp+b5Kg8X9P+08Eehu
tMlBJ5lafy1bxoVlXUDLVIIFBJNKrsqBvxxxpS7

VIPを使用できるようにするには、次のようにこの2行を変更します。

standby12_vip,standby1,10.242.20.22 ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC3pM2YTd4UUiEWEoCKDGgaTgsmPkQToDrdtU+JtVIq/96muivU
BaJUK83aqzeNIQkh+hUULsUdgKoKT5bxrWYqhY6AlTEqNgBHjBrJt9C73BbQd9y48jsc2G+WQWyuI/
+s1Q+hIJdBNMxvMBQAfisPWWUcaIx9Y/JzlPgF6lRP2cbfqAzixDot9fqRrAKL3G6A75A/6TbwmEW07d1zqOv
l7ZGyeDYf5zQ72F/V0P9UgMEt/5DmcYTn3kTVGjOTbnRBe4A4lY4rVw5c+nZBDFre66XtORfQgwQB5ztW/Pi
08GYbcIszKoZx2HST9AZxYIAgcrnNYG2Ae0K6QLxxxScP
standby12_vip,standby2,10.242.20.23 ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDIszcjzNtKN03SY8Kl846skFTVP1HF/ykswbmkctEjL6KTWTW+NR
U4MGbvkBqqdXxuPCR7aoGO2U3PEOg1UVf3DWUoux8IRvqKU+dJcdTibMFkDAIhTnzb14gZ/lRTjn+GYsuP5
Qz2vgL/U0ki887mZCRjWVL1b5FNH8sXBUV2QcD7bjF98VXF6n4gd5UiIC3jv6l2nVTKDwtNHpUTS1dQAi+1D
tr0AieZTsuxXMaDdUZHgKDotjciMB3mCkKm/u3IFoioDqdZE4+vITX9G7DBN4CVPXawp+b5Kg8X9P+08Eehu
tMlBJ5lafy1bxoVlXUDLVIIFBJNKrsqBvxxxpS7

最終的に、プライマリ・クラスタのこの1つ目のノードで実行されたホスト・キーの構成は、プライマリ・クラスタ内のすべてのノードで実行する必要があります。前述の手順の結果またはそれに相当するものが各プライマリ・ノードに存在する必要があります。この構成を実現するのに必要な手作業を最小化する方法の1つとして、プライマリ・クラスタのノードの1つでknown_hostsファイルを更新した後、更新後のファイルをクラスタの他のノードにコピーします。

注意:

デフォルトでは、レプリケーションにより、sshによる厳密なホスト・キー・チェックが有効になり、sshの実行時にプライマリ・ノードが目的のスタンバイ・ノードまたはクラスタに必ず接続されます。しかし、プライマリ・クラスタとスタンバイ・クラスタがプライベート・ネットワークで通信する場合など、このチェックが確実に不要である場合は、sshによる厳密なホスト・キー・チェックの使用を無効にできます。厳密なホスト・キー・チェックの無効化の詳細は、acfsutil repl init primaryコマンドの-o sshStrictKey=noオプションを参照してください。厳密なホスト・キー・チェックが無効になっている場合、ホスト・キーの設定は不要です。acfsutil repl initコマンドの詳細は、「acfsutil repl init」を参照してください。

ssh関連ファイルに対する権限に関する注意事項

設定したキーでsshが機能するには、関連のある.sshディレクトリおよびそのディレクトリ内にある一部のファイルについて、各ノードで権限が適切に設定されていることを確認する必要があります。各プライマリ・ノードでは、これはroot用の.sshディレクトリを指します。各スタンバイ・ノードでは、確認する.sshディレクトリはrepluser用のディレクトリです。

各.sshディレクトリとそのディレクトリ内のキー・ファイルに付与する必要がある権限の詳細は、ssh(1)マニュアル・ページのFILESに関する項など、ssh実装のドキュメントを参照してください。

sshdの構成に関する注意事項

レプリケーションの使用を開始すると、sshがレプリケーション操作を実行するために頻繁に起動されます。一部のプラットフォームでは、ssh接続が確立されるたびにsyslogまたは同様の機能を使用してメッセージを記録するように、ssh daemon sshdを構成することもできます。これを回避するには、サーバー構成ファイル/etc/ssh/sshd_configを変更してロギングの頻度を低く指定することができます。ロギングを制御するパラメータは、LogLevelです。接続メッセージは、INFOレベルで発行されます。ERRORなど、頻度がより低いLogLevel設定にすると、それらのメッセージは抑制されます。たとえば、次の行をファイルに追加することで、ログ・メッセージを抑制できます。

LogLevel ERROR

ssh関連のキー構成の検証

プライマリ・クラスタとスタンバイ・クラスタの両方でssh用のホスト・キーおよびユーザー・キーを設定したら、acfsutil repl info -c -uコマンドを使用してキーを検証できます。このコマンドは、それぞれのクラスタの各ノードでrootとして実行します。ローカル・クラスタが今後のレプリケーションの実行に使用する可能性があるリモート・クラスタのすべてのホスト名またはアドレスを引数として取ります。

VIPを使用せずにリモート・クラスタに接続している場合は、特定のレプリケーション関係について、リモート・ホスト名またはリモート・アドレスを1つのみacfsutil repl init primaryに指定します。ただし、関係に他のリモート・ホスト・アドレスが今後かかわる可能性がある場合は、acfsutil repl info -c -uコマンドの実行時に、全リモート・アドレスを指定します。

VIPを使用してリモート・クラスタに接続している場合は、VIPがアクティブな全リモート・ホストの名前またはホスト固有のアドレスを指定する必要があります。VIP名、またはVIPに関連付けられているアドレスを指定しないでください。レプリケーションでsshを使用してVIPに接続する場合、戻されるホスト・キーは、VIPが現在アクティブなホストに関連付けられているキーです。この場合のsshでは、個々のリモート・ノードのホスト名またはアドレスのみが使用されます。

プライマリ・クラスタの各ノードで実行する検証コマンドの形式は次のとおりです。

# acfsutil repl info -c -u repluser standby1 [standby2 …] [snap_shot@]primary-mountpoint

このコマンドで、standbynにはスタンバイ・クラスタのホスト名またはアドレスを指定します。検証コマンドは、ユーザーrepluserがsshを使用して、レプリケーションの初期化と同じ方法で、指定された各スタンバイのホスト名またはアドレスに接続できることを確認します。standby12_vipなどのVIPを使用してクラスタに接続している場合は、同じコマンド形式を使用します。VIPの名前を指定しないでください。

厳密なホスト・キー・チェックを無効にする予定の場合は、-o sshStrictKey=noオプションをコマンドラインに追加して、このチェックをスキップできます。

プライマリ・クラスタの各ノードがスタンバイ・クラスタのすべてのノードに接続できることを確認したら、検証コマンドを再実行してください。今度は、スタンバイ・クラスタの各ノードでコマンドを実行します。次の形式を使用して、プライマリ・クラスタのすべてのノードのホスト名またはIPアドレスを指定します。

# acfsutil repl info -c -u repluser primary1 [primary2 ...] [snap_shot@]standby-mountpoint

このコマンドで、primarynにはプライマリ・クラスタのホスト名またはアドレスを指定します。

Oracle ACFSスナップショットベースのレプリケーションへのアップグレード

この項では、Oracle ACFSスナップショットベースのレプリケーションへのアップグレードについて説明します。Oracle Grid Infrastructure 12cリリース2 (12.2)では、Oracle ACFSスナップショットベースのレプリケーションは、サポート対象のOracle ACFSレプリケーション実装となります。12.2より前のリリースのレプリケーション環境がある場合、Oracle Grid Infrastructure 12cリリース2 (12.2)にアップグレードする際に、既存のレプリケーション・インストールをスナップショットベースのレプリケーションにアップグレードする必要があります。

注意:

• レプリケーション・アップグレード・プロセスは、開始したら完了する必要があります。このプロセスは、ロールバックできません。

• スナップショットベースのレプリケーションにアップグレードする前に、Oracle Flex ASMは有効になっており、必要であれば、パスワード・ファイルの変換を実行しておく必要があります。

インスタンスをOracle Grid Infrastructure 12cリリース2 (12.2)にアップグレードする際、Oracle Flex ASMは既存のインスタンスに対して有効になっている必要があります。レプリケーションをサポートするインスタンスにパスワード・ファイルが存在する場合は、そのファイルを新しいOracle Flex ASMインスタンスで使用できるようにする必要があります。たとえば、インスタンスで前のORACLE_SIDをASMに設定し、現在のORACLE_SIDをAPX1に設定した場合、次のステップを実行する必要があります。

1. 既存のorapw+ASMファイルを+APX1バージョンにコピーします。

   $ cp /oraroot/app/12.2.0/has0626/dbs/orapw+ASM /oraroot/app/12.2.0/has0626/dbs/orapw+APX1 

2. init+APX1.oraという名前の新しいテキスト・ファイルをdbsディレクトリに作成し、次の行のみを新しいファイルに追加します。

   remote_login_passwordfile = exclusive 

3. Oracle ASMプロキシ(APX)インスタンスを再起動します。

   $ asmcmd shutdown --target APX --immediate
   

   環境変数ORACLE_SIDがOracle ASMプロキシ(APX)インスタンスに設定されていることを確認します。その後、インスタンスを再起動してください。

   $ asmcmd startup --pfile init+APX1.ora

スナップショットベースのレプリケーションでは、sshをプライマリ・クラスタとスタンバイ・クラスタ間のトランスポートとして使用します。アップグレード・プロセスの開始前に、「Oracle ACFSレプリケーションで使用するためのsshの構成」の説明に従ってsshを構成する必要があります。

スナップショットベースのレプリケーションにアップグレードする前に、スタンバイ・クラスタ・システムをOracle Grid Infrastructure 12cリリース2 (12.2)にアップグレードする必要があります。このクラスタ・アップグレードは、24時間以内に完了してください。スタンバイ・クラスタは、このアップグレード・プロセスの間、既存のレプリケーションを実行し続けます。次に、プライマリ・クラスタでOracle Grid Infrastructure 12cリリース2 (12.2)にアップグレードします。このアップグレードも24時間以内に完了してください。このアップグレードの間、プライマリ・クラスタは、12.2より前にインストールされた既存のレプリケーションを実行し続けます。スタンバイ・クラスタとプライマリ・クラスタのOracle Grid Infrastructure 12cリリース2 (12.2)へのアップグレードが完了すると、12.2より前にインストールされた既存のレプリケーション実装はサポートされません。

2つのクラスタのアップグレードに続いてすぐに、レプリケーションにかかわるファイルシステムに関連付けられているCOMPATIBLE.ADVMディスク・グループ属性を12.2.0.0.0に設定する必要があります。これで、スナップショットベースのレプリケーションに移行する準備ができました。この移行は、次のいずれかのオプションを使用して実行できます。

• 既存のレプリケーションを終了し、スナップショットベースのレプリケーションを使用するように初期化します。このオプションは、レプリケート対象のデータ量が少ない(数百GB未満)場合にお薦めします。また、このオプションは、1つのノードにのみマウントされるようにプライマリ・ファイルシステムを簡単に制限できない場合や、プライマリでアクティビティを簡単に停止できない場合には、好ましいオプションです。

• acfsutil repl upgradeコマンドを実行して、レプリケーションを終了および初期化せずに、既存のレプリケーション環境をアップグレードします。このオプションは、スナップショットベースのレプリケーションが既存のレプリケーションが停止したポイントから続行できることで、プライマリ・ファイルシステムのコンテンツ全体をスタンバイに転送する必要がありません。このオプションは、大量のデータをレプリケートする場合に便利です。アップグレード・プロセスではデータがほとんど転送されないため、プロセスはすぐに完了すると考えられます。

次に、acfsutil repl upgradeコマンド・オプションを実行してスナップショットベースのレプリケーションにアップグレードする方法の詳細を示します。

• レプリケーション・アップグレード・プロセスを開始する前に、プライマリ・ファイルシステムがプライマリ・クラスタの1つのノードにのみマウントされていることを確認する必要があります。さらに、プライマリ・ファイルシステムに対するアプリケーションの更新をすべて停止してから、acfsutil repl sync applyをもう一度実行して、プライマリでの変更がすべてレプリケートされるようにすることをお薦めします。

• アップグレード・プロセスの最初のステップは、プライマリ・クラスタでacfsutil repl upgrade prepareコマンドを実行します。このコマンドは、スナップショットベースのレプリケーションに使用されるユーザー名およびホスト名またはインタフェース名の他、プライマリ・マウント・ポイントも指定します。ユーザー名およびホスト名は、スナップショットベースのレプリケーションに使用されるacfsutil repl init primaryコマンドのオプションと同様に、—sオプションを使用して指定します。

• プロセスの次のステップは、acfsutil repl upgrade standbyコマンドを実行して、スタンバイ・クラスタでレプリケーションをアップグレードします。このコマンドは、スナップショットベースのレプリケーションに使用されるユーザーの他、スタンバイ・マウント・ポイントも指定します。ユーザー名は、スナップショットベースのレプリケーションに使用されるacfsutil repl init standbyコマンドのオプションと同様に、-uオプションを使用して指定します。

• プロセスの最後のステップは、プライマリ・クラスタでacfsutil repl upgrade primaryコマンドを実行します。これは、前のレプリケーション・デプロイメントを自動的に終了し、スナップショットベースのレプリケーションを開始するコマンドです。このコマンドは、acfsutil repl init primaryコマンドで受け入れられたスナップショットベースのレプリケーション用のコマンドライン・オプションを受け入れます(ただし、現在終了している前のレプリケーション環境から情報が取得されるため、-mオプションおよび-sオプションを除きます)。

• acfsutil repl upgrade primaryコマンドが完了すると、12.2リリースのスナップショットベースのレプリケーションでacfsutil repl initコマンドを実行していたかのように、影響を受けたプライマリ・クラスタとスタンバイ・クラスタ間でスナップショットベースのレプリケーションがアクティブになっています。acfsutil repl info -cコマンドをプライマリ・クラスタとスタンバイ・クラスタの両方で使用し、各クラスタのレプリケーションの状態を確認できます。

注意:

acfsutil repl upgrade standbyまたはacfsutil repl upgrade primaryの実行中にエラーが発生した場合は、次の点を検討します。

• エラーによっては、アップグレード・コマンドが正常に完了するまで、(acfsutil repl infoの出力では)レプリケーションが初期化されていないように見えることがあります。

• アップグレードを続行するには、失敗したアップグレード・コマンドが示したエラーをすべて修正してから、失敗したコマンドを再度発行します。コマンドを何度も再発行することもあり得ます。