18 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レプリケーションで使用するためのsshの構成

• WindowsでのsshおよびCygwinのインストール

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

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

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

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

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

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

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

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

プライマリ・クラスタからのroot用の公開鍵の取得

プライマリ・クラスタの各ノードに定義されているroot用の公開鍵を、スタンバイ・クラスタの各ノードの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/.ssh/authorized_keys2ファイルを作成し、その最後に鍵を追加します。

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

# ssh-keygen -t rsa

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

root用の同じ公開/秘密鍵ペアをプライマリ・クラスタ内のすべてのノードで共有することも、プライマリ・ノードごとに異なる鍵ペアを設定することもできます。プライマリ・クラスタ内のすべてのノードで同じ公開鍵がrootに対して有効な場合、スタンバイ・クラスタの各ノードで、~repluser/.ssh/authorized_keys2ファイルにその鍵のみを追加する必要があります。各プライマリ・ノードに独自のroot用の公開鍵がある場合は、すべての公開鍵をそのファイルに追加する必要があります。いずれの場合も、スタンバイの特定のノードで更新した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 standby-addr1 [standby-addr2 …] standby-mountpoint

このコマンドは、ユーザーrepluserがsshを使用して、初期化時にレプリケーションと同じように指定された各standby-addrに接続できることを確認します。

前述のコマンドで指定したstandby1およびstandby2クラスタの鍵設定を検証するには、次のコマンドを使用できます。

# acfsutil repl info -c -u repluser standby1 standby2 standby-mountpoint

クラスタへの接続にVIP standby12_vipを使用する予定だった場合は、同じコマンドを使用します。

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

WindowsでのsshおよびCygwinのインストール

この項では、Microsoft WindowsのホストでCygwinをインストールしてsshデーモンを開始する方法について説明します。この情報は、WindowsホストでOracle ACFSスナップショットベースのレプリケーションを使用する場合にのみ当てはまります。

Oracle ACFSレプリケーションのCygwinの要件

Oracle ACFSスナップショットベースのレプリケーションでは、sshを使用してプライマリ・クラスタからスタンバイ・クラスタにレプリケーション関連のデータを転送します。Microsoft Windowsで稼働しているホストでレプリケーションを使用する場合は、この項の説明に従って、ホストでCygwinをインストールしてsshデーモンを開始する必要があります。

Cygwinは、基本的にMicrosoft WindowsホストにLinuxに類似の環境を提供するユーティリティです。Linux APIレイヤーとして機能し、多くのLinux API機能を提供するDLL(cygwin1.dll)です。Cygwinをインストールすると、ホストでsshデーモンを構成できます。Oracle ACFSレプリケーションは、Cygwin 2.0で動作保証およびサポートされています。

sshデーモンにより、Oracle ACFSレプリケーションでは、レプリケーションを実行しているプライマリ・クラスタからレプリケーションを実行しているスタンバイ・クラスタへのssh接続を確立できます。

注意:

ここでのsshデーモンのインスール手順では、特定のユーザーrepluserとしてログインし、コマンドを実行することにのみ使用可能なデーモンとなります。このデーモンは、他のユーザーとしてログインしてコマンドを実行したときに正しく機能するものではありません。この制限は、次の2つの要因によるものです。

• Oracle ACFSに定義されたユーザーはドメインベースのユーザーである必要があります。

• ドメインベースのユーザーに対して汎用のsshデーモンを有効にするには、Trusted Computing Baseの一部としてユーザーが動作できるSeTcbPrivilegeなど、なんらかの非常に強力な権限をそのユーザーに付与するデーモン・ポリシーを作成する必要があります。このようなポリシーを作成することは、ほとんどの企業の環境で許可される可能性は低いため、このようなポリシーの使用はここでの手順に含まれていません。

Cygwinをインストールする前の手順

sshの設定から始める前に、次の手順でチェックを実行してOpenSSHおよびMKSNTを使用していないことを確認します。

この項で説明するナビゲーションの手順は、Microsoft Windowsオペレーティング・システムによって異なります。

1. OpenSSH\binおよびmksnt実行可能ファイルが格納されているディレクトリがPATH環境変数にないことを確認します。ある場合は、次の手順を実行してPATH文字列から削除します。

   1. 「マイ コンピュータ」を右クリックし、「プロパティ」を選択します。

   2. 「システムのプロパティ」ウィンドウで、「詳細設定」をクリックします。

   3. このタブで、「環境変数」をクリックします

   4. PATHシステム変数を検索して選択し、OpenSSH\binまたはmksnt関連の値がPATH文字列に含まれている場合は、「編集」をクリックします。

   5. 「システム変数の編集」ダイアログ・ボックスで、これらの値をPATH文字列から削除し、「OK」をクリックします。

2. OpenSSH、MKSまたはその他のソースから実行されている場合は、ssh daemonを停止して無効にします。sshデーモンが実行中の場合、次の手順を実行して停止し、無効にします。

   1. 「マイ コンピュータ」を右クリックし、「管理」を選択します。

   2. 「コンピュータの管理」ウィンドウの左側のペインで、「サービスとアプリケーション」を展開し、「サービス」を選択します。

      • 右側のペインで、ssh daemon/MKS Secure Shellサービスを右クリックし、表示されたメニューで「停止」エントリをクリックします。

      • 同じペインで、ssh daemon/MKS Secure Shellサービスを右クリックし、表示されたメニューで「プロパティ」エントリをクリックします。開いたダイアログ・ボックスで、「スタートアップの種類」として「無効」を選択し、「OK」をクリックします。

Cygwinのインストール

Microsoft WindowsホストにCygwinをインストールするには、次の手順を実行します。

1. 次のURLにアクセスして、「Install Cygwin」をクリックします。

   http://www.cygwin.com/ 

2. 実行しているMicrosoft Windowsのバージョンに応じて、32ビット・バージョンまたは64ビット・バージョンのCygwinセットアップ実行可能ファイルをダウンロードします。

3. 実行ファイルを実行し、「Next」をクリックして続行します。

4. 「Choose Installation Type」画面で、「Install from Internet」を選択して「Next」をクリックします。

5. 「Choose Installation Directory」画面で、「Root Directory」にC:\cygwinと入力し、「Next」をクリックします。

6. 「Select Local Package Directory」画面で、ダウンロードしたインストール・ファイルを格納するローカル・マシン上のディレクトリを選択し、「Next」をクリックします。

7. 「Select Connection Type」画面で、インターネットに接続するための適切な設定を選択し、「Next」をクリックします。

8. 「Choose Download Site(s)」画面で、利用可能リストから任意のサイトを選択し、「Next」をクリックします。

9. パッケージの選択画面で、次のパッケージを選択し、「Next」をクリックします。「アーカイブ」カテゴリから、unzipとzipを選択します。「Net」カテゴリから、opensshおよびopensslを選択します。パッケージを選択して「Next」をクリックすると、「Resolving Dependencies」画面が表示されます。「次へ」をクリックして次に進みます。

10. 「Installation Status and Create Icons」画面では、変更しません。「Finish」をクリックして、インストール・プロセスを終了します。

sshの構成

この項では、ホストにCygwinをインストールした後に、Oracle ACFSレプリケーション用にsshを構成する方法について説明します。

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

Oracle ACFSレプリケーションでは、sshをプライマリ・クラスタとスタンバイ・クラスタ間のトランスポートとして使用するため、レプリケーションを実行するユーザー・アイデンティティは明示的に指定する必要があります。レプリケーション・プロセスでは、プライマリ・ノードの特権ユーザーはsshを使用してレプリケーションにかかわるスタンバイ・ノードにログインします。sshで特権ユーザーとしてスタンバイ・ノードにログインすることは望ましくありません。かわりに、最小限の権限を持つユーザー・アイデンティティを使用してください。選択するユーザーは、ドメインベースのユーザーであり、ORA_ASMADMINグループのメンバーである必要があります。

ここでの説明では、repladminおよびrepluserを使用してレプリケーション・ユーザーを指していますが、選択した実際のユーザー名でrepladminおよびrepladminを置き換えます。repladminユーザーは、プライマリとスタンバイの両方でacfsutil repl initコマンドを実行するユーザーを指します。このユーザーは、Administratorsグループのメンバーである必要があります。repluserユーザーは、スタンバイにログインするためにsshで使用するユーザーを指します。このユーザーは、ドメインベースのユーザーであり、ORA_ASMADMINグループのメンバーである必要がありますが、Administratorsグループのメンバーではありません。Oracle RACの使用に適したユーザーがすでに存在する場合は、そのユーザーをrepluserとして使用する必要があります。

Oracle ASMのユーザー権限の詳細は、「Oracle ASMの権限について」を参照してください。Oracle ACFS acfsutilコマンドの実行の詳細は、「Oracle ACFSコマンドライン・ツールの使用について」を参照してください。

構成手順

sshを構成する場合、状況によってはcygwin.batスクリプトを実行する必要があります。Microsoft Windows Server 2008およびMicrosoft Windows Vistaでcygwin.batを実行する場合は、必ず管理者モードでバッチ・ファイルを起動します。これを行うには、cygwin.batファイルを右クリックし、「管理者として実行」を選択します

sshを構成してCygwinの設定をテストするには、次の手順を実行します。

1. Cygwinのインストール後、C:\cygwinディレクトリに移動し、任意のエディタを使用して編集モードでCygwin.batファイルを開き、bashシェルを起動する前に次の行を追加します。

   set CYGWIN=binmode ntsec

   前述の行を追加した後のCygwin.batファイルの内容は、次のようになります。

   @echo off  
   C: 
   chdir C:\cygwin\bin 
   set CYGWIN=binmode ntsec bash --login –i

2. Cygwin (cygrunsrv)が正しくインストールされているかどうかを確認するには、C:\cygwin\Cygwin.batを実行し、次のコマンドを実行します。

   cygrunsrv –h

   Cygwinが正しくインストールされている場合、すべてのCygwinヘルプ・オプションが画面に表示されます。このコマンドでエラー・メッセージが戻された場合は、状況に応じてCygwinを再インストールする必要があります。

3. repladminおよびrepluserの各アイデンティティをWindowsレベルで定義します。

   これらのロールに対して、かわりに既存のユーザーを使用することもできます。これらのロールに新しいアイデンティティを定義する場合は、次の点に注意してください。

   • repladminユーザーは、Administratorsグループのメンバーである必要があります。repladminは、ドメインベースのユーザーでもあるようにしてください。repladminがローカル・ユーザーの場合、すべてのプライマリ・ノードで同じグループ・メンバーシップを使用して定義する必要があります。

   • repluserユーザーは、ドメインベースのユーザーであり、ORA_ASMADMINグループのメンバーである必要があります。

4. sshdサービスを構成します。C:\cygwin\Cygwin.bat,を実行し、次のコマンドを実行します。

   ssh-host-config

   コマンドを実行すると、次のプロンプトが表示されます。該当するレスポンスは太字で示されています。その他の出力も表示されることがありますが、ここでは省略します。

   *** Query: Should StrictModes be used? (yes/no) yes
   *** Query: Should privilege separation be used? <yes/no>: yes
   *** Query: New local account ’sshd’? <yes/no>: yes
   *** Query: Do you want to install sshd as a service?
   *** Query: <Say "no" if it is already installed as a service> <yes/no>: yes
   *** Query: Enter the value of CYGWIN for the daemon: [] binmode ntsec

   ここで、ssh-host-configから、パスワードなしログインを使用するのに必要なユーザー・アカウントに関する注意情報がいくつか出力されます。この機能は、Oracle ACFSレプリケーションで必要となります。repluserアカウントは、このアカウントとして指定する必要があります。

   *** Info: The following privileged accounts were found: 'cyg_server' .
   *** Info: This script plans to use 'cyg_server'.
   *** Info: 'cyg_server' will only be used by registered services.
   *** Query: Do you want to use a different name? (yes/no) yes

   プロンプトにyesと応答し、sshdを実行する名前でrepluserを指定します。すると、次のプロンプトが表示されます。

   *** Query: Enter the new user name: repluser
   *** Query: Reenter: repluser
   
   ***Warning: The specified account 'repluser' does not have the
   ***Warning: required permissions or group memberships.  This may
   ***Warning: cause problems if not corrected; continuing...
   *** Query: Please enter the password for user 'repluser':
   *** Query: Reenter:

   前述では、ユーザーrepluserがすでに存在することを前提としています。権限またはグループ・メンバーシップがないことに関する警告の出力は無視してもかまいません。構成が成功した場合は、次のメッセージが表示されます。

   Host configuration finished. Have fun!

5. /var/emptyディレクトリが存在し、repluserが所有していることを確認します。

6. repluserユーザーとrepladminユーザーがCygwinで認識されていることを確認します。

   c:\cygwin\etc\passwdファイルをバックアップし、編集モードでファイルを開きます。repladminユーザーまたはrepluserユーザーを参照している行をすべてこのファイルから削除します。ユーザーごとに、次のコマンドを実行します。どちらのユーザーもドメインベースのユーザーであることを前提としています。

   /bin/mkpasswd -d -u repladmin >> /etc/passwd

   ユーザーごとに名前が付いたホーム・ディレクトリが/etc/passwdに存在することを確認します。必要に応じて作成します。たとえば、/home/repladminがユーザーrepladminに表示されるディレクトリの場合、次を実行して必要なディレクトリを作成します。

   mkdir -p /home/repladmin
   chown repladmin /home/repladmin

7. sshデーモンが開始していることを確認し、自動的に開始するように構成します。

   1. 「マイ コンピュータ」を右クリックし、「管理」を選択します。

   2. 「コンピュータの管理」ウィンドウの左側のペインで、「サービスとアプリケーション」を展開し、「サービス」を選択します。

   3. 右側のペインで、CYGWIN sshdサービスを右クリックし、表示されたメニューで「プロパティ」エントリをクリックします。開いたダイアログ・ボックスで、「スタートアップの種類」として「自動」を選択し、「OK」をクリックします。

sshデーモンが開始していない場合、起動プロセスの障害に関する情報がないかc:\cygwin\var\log\sshd.logファイルを調べます。

プライマリからのrepladmin用の公開鍵の取得

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

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

repluser@standby $ ls -ld ~/.ssh
drwx------+ 1 repluser Domain Users 4096 2016-02-23 11:27 .ssh

repladmin用の公開鍵が特定のプライマリ・ノードに定義されている場合、~repladmin/.ssh/id_rsa.pubなどの.pubファイル内にあります。公開鍵ファイルが存在する場合は、レプリケーションが実行されるスタンバイの各ノードにrepluserとしてログインすることを認可された一連の鍵に、その内容を追加します。各スタンバイ・ノードで、必要に応じて~repluser/.ssh/authorized_keys2ファイルを作成し、その最後に鍵を追加します。

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

# ssh-keygen -t rsa

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

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

スタンバイのホスト鍵の取得

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

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

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

[repladmin@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の設定が完了します。ホスト・スタンバイ用のホスト鍵が、ホスト・プライマリのrepladminユーザー用のknown_hostsファイル(~repladmin/.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」を参照してください。

SYSTEMユーザー用の鍵の追加

Oracle ACFSレプリケーションでは、プライマリ・クラスタのノードで稼働しているデーモンを使用してレプリケーションの進行状況を制御します。このデーモンは、アイデンティティNT_AUTHORITY\SYSTEMを使用して自動的に開始されます。このデーモンにより、sshを使用しているレプリケーションでは、プライマリ・データをスタンバイ・サイトに転送して適用できます。

デーモンによって開始されるプロセスは、デーモンのアイデンティティを保持します。ユーザーがNT_AUTHORITY\SYSTEM (sshを介してスタンバイと実際にやり取りするユーザー)である場合、sshはSYSTEMユーザーのホーム・ディレクトリでスタンバイに渡す公開鍵を探し、そこでスタンバイが渡したホスト鍵を確認します。

デーモンでsshを正常に使用できるようにするには、プライマリのrepladmin用に設定した.sshディレクトリの内容をSYSTEMのホーム・ディレクトリ内の.sshディレクトリにコピーする必要があります。このディレクトリには、他のホーム・ディレクトリに使用されている場所と対応する場所を使用します。

たとえば、ユーザーrepladminのホーム・ディレクトリが/home/repladminの場合は、/home/SYSTEMをSYSTEMのホーム・ディレクトリとして使用します。このような.sshディレクトリは、repladminとしてログインして作成します。

まず、SYSTEMのホーム・ディレクトリが存在しない場合は、それを作成します。

$ mkdir /home/SYSTEM

次に、repladmin用の.sshディレクトリをSYSTEM用のディレクトリにコピーします。

 $ cd  $HOME
 $ cp -p -R .ssh /home/SYSTEM

Cygwinの設定のテスト

ここで、Cygwinの設定をテストします。使用可能なsshクライアントがある別のコンピュータを使用して、次のコマンドをユーザーrepladminとして実行します。

ssh -l repluser host-address date

host-addressは、sshを構成したばかりのホストを指します。次に例を示します。

ssh -l repluser standby1.us.example.com date

インストールおよび構成手順が正常に完了した場合、このコマンドはパスワードの入力要求なしに実行されます。

sshの構成後に、プロセス分岐化の失敗、メモリー・リーク・エラーまたはファイル・アクセス・エラーが発生した場合、次のリンクをアクセスして解決策を確認してください。

http://cygwin.com/faq.html

問題の解決策が見つからない場合は、次のリンクを使用してCygwinコミュニティにその問題をレポートしてください。

http://cygwin.com/problems.html

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の出力では)レプリケーションが初期化されていないように見えることがあります。

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