他のリカバリ・アプライアンスへのバックアップの移行

21 他のリカバリ・アプライアンスへのバックアップの移行

この章では、古いリカバリ・アプライアンスから新しいリカバリ・アプライアンスへのアップグレードなど、メンテナンス目的のリカバリ・アプライアンス間のバックアップの移行について説明します。

RACLIの移行アシスタントは、古いリカバリ・アプライアンス(ソース)から新しいリカバリ・アプライアンス(宛先)にバックアップをシームレスに移行するように設計されています。ユーザーおよび保護ポリシーがソースからクローニングされて、宛先のリカバリ・アプライアンスに追加されたことが確認されます。移行アシスタントは、ソースに存在するのと同じ構成を、宛先のリカバリ・アプライアンスに作成します。これには、(ソースにあった場合は)レプリケーション・サーバー、保護ポリシー、VPCユーザー、copy-to-cloud用のリカバリ・アプライアンスのOKVエンドポイント構成、およびcopy-to-tape用のOracle Secure Backup (OSB)が含まれます。最後に、保護されているすべてのデータベースが、ソースのリカバリ・アプライアンスから宛先のリカバリ・アプライアンスにコピーされます。

移行アシスタントは、いくつかの事前チェック操作を実行します。

ソースと宛先の間でRACLIバージョンが一致することを確認します。
ソースと宛先の間でTLS設定が一致することを確認します。
宛先の記憶域の場所のサイズが、ソースの記憶域のサイズと一致するか、それより大きいことを確認します。
新しいOKV jarファイルがダウンロードされて、宛先のリカバリ・アプライアンスにステージングされていることを確認します。両方のリカバリ・アプライアンスが同じウォレットを共有していることを確認します。これは、単一の共有キーを使用したクライアントとクライアントの間の対称型暗号化が、ソースと宛先のリカバリ・アプライアンスの間で一致することを意味します。移行時には、宛先のリカバリ・アプライアンスでOKVエンドポイントの登録が実行されます。これにより、ソースで実行されていたcopy-to-cloud操作が、宛先でも同じように機能するようになります。
ソースのリカバリ・アプライアンスのcopy-to-tape操作が無効化または一時停止されていることを確認します。
ソースのリカバリ・アプライアンスのデータベース名が、宛先にすでに存在するデータベースと競合しないことを確認します。

事前チェックの後、移行アシスタントはソースのリカバリ・アプライアンスからメタ・データを収集し、移行バンドルを作成して移行サーバーを作成します。宛先のリカバリ・アプライアンスで、移行アシスタントが、ユーザーのメタデータ、保護ポリシーおよび保護されたデータベースをクローニングします。ソースのリカバリ・アプライアンスにレプリケーション・サーバーがあった場合は、このレプリケーション・サーバーが宛先のリカバリ・アプライアンスに作成されます。移行サーバーにポリシーが追加されて、COPYALL_BACKUPSが開始されます。COPYALL_BACKUPSは、データベースの既存のすべてのバックアップを宛先のリカバリ・アプライアンスにレプリケートします。これには、期限切れの可能性があるが、ソースのリカバリ・アプライアンスからまだパージされていないバックアップも含まれます。ソースは、制御された秩序正しい方法でバックアップをレプリケートし、宛先はCOPYALL_BACKUPSを認識して、バックアップを正しい順序で収集および保守します。

ノート:

ソースから宛先のリカバリ・アプライアンスへの移行プロセスは、使用可能なネットワーク帯域幅で、大量のバックアップ・データをコピーする必要があるため、完了までに長時間かかる場合があります。

移行アシスタントは、COPYALL_BACKUPSステータスをチェックして確認します。完了すると、ソースのリカバリ・アプライアンスから移行サーバーが削除されます。

RACLIを使用したリカバリ・アプライアンス間の移行の構成

パートナーシップの概要

移行パートナシップにより、2つの異なるリカバリ・アプライアンス(RA)をリンクして、root以外のユーザーでリモート管理できるようにします。パートナーシップでは:

2つのリカバリ・アプライアンスの間に1対1の関係が確立され、移行の完了後に削除されます。
特定のRACLIコマンドを実行するために、ソースのリカバリ・アプライアンスに、宛先へのSSHアクセス権を持つ内部的な「パートナ」OSユーザーが作成されます。
双方向通信が確立されるため、このコマンドを実行する必要があるのは、1つのリカバリ・アプライアンスのみです。

移行操作は、RACLIコマンドを使用して実行してください。

表21-1 移行用の主要なRACLIコマンド

プログラム・ユニット	説明
`racli add ra_partner --target_host=FQDN [--partner_user=NAME] [--partner_uid=UID] [--admin_user=VALUE] [--admin_key=VALUE]`	ソースと宛先のリカバリ・アプライアンスの間に双方向接続を確立します。権限が制限されたrootではない'partner_user'を作成し、SSHキーベースの双方向認証を設定します。
`racli list ra_partner`	ホスト名を含む、パートナのリカバリ・アプライアンスのすべての情報を表示します。
`racli alter ra_partner { --target_host=FQDN } [--partner_user=VALUE] [--partner_dir=VALUE] [--admin_user=VALUE] [--admin_key=VALUE]`	ソースのリカバリ・アプライアンスにあるパートナのSSHキーおよびその他の詳細を更新して、宛先と共有します。
`racli remove ra_partner --target_host=FQDN [--partner_user=VALUE] [--partner_dir=VALUE] [--admin_user=VALUE] [--admin_key=VALUE]`	ソースと宛先のリカバリ・アプライアンスの間のパートナ関係をサポートするために作成されて移行中に使用されたオブジェクトおよび構成を削除するために、ソースのリカバリ・アプライアンスで実行します。
`racli begin migration`	ソースのリカバリ・アプライアンスから宛先のリカバリ・アプライアンスへの移行を開始します。
`racli status migration`	移行サーバーのステータスおよび`COPYALL_BACKUPS`のバックアップ状態を返します。
`racli end migration`	ソースと宛先のリカバリ・アプライアンスの間の移行サーバーをクリーン・アップします。

移行に関するノート

記憶域: ソースのリカバリ・アプライアンス(RA1)を単一の宛先のリカバリ・アプライアンス(RA2)に移行する場合、事前チェックに合格するには、RA2の記憶域の場所のサイズがソースのRA1よりも大きい必要があります。これにより、ソースのRA1からすべてのデータをコピーするのに十分な領域が確保されます。
ソースのレプリケーション・サーバー: 移行前にソースのリカバリ・アプライアンス(RA1)に関連付けることができるレプリケーション・サーバーは1つのみです。ソースのRA1に元々複数のレプリケーション・サーバーがあった場合は、追加のレプリケーション・サーバーを削除する必要があります。RA2への移行では、1つのレプリケーション・サーバーのみが設定されます。
レプリケーションをクローニングしない単一の移行: ソースのリカバリ・アプライアンスにレプリケーション・サーバーが構成されていた場合、移行プロセスにより、宛先のリカバリ・アプライアンスにこれが設定されます。
Copy-to-Cloud: 移行用のソースのリカバリ・アプライアンス(RA1)に、マスター・キーを含むcopy-to-cloud設定がある場合(racli list okv_utilでチェックされます)、移行前にRA2のWebコンソールを介して宛先のリカバリ・アプライアンス(RA2)にこのOKVを登録しておく必要があります。[OKVクライアント・ソフトウェアのインストールを参照してください。]

マスター・キーは、宛先ホストの各ノードにダウンロードする必要があります。これを行わないと、マスター・キーがローカルのリカバリ・アプライアンスで見つかっても、宛先のリカバリ・アプライアンスにないため、事前チェックが失敗する可能性があります。
保護ポリシーの移行: 移行プロシージャでは、ソースのリカバリ・アプライアンスを廃止できるように、すべての保護ポリシーを宛先のリカバリ・アプライアンスに移行することを目的としています。
パートナーシップの欠落: これにより、事前チェックが失敗します。たとえば、ソースのリカバリ・アプライアンス(RA1)がリカバリ・アプライアンスRA3にレプリケートされていて、ソースのRA1をリカバリ・アプライアンスRA2に移行しようとしている場合は、RA2とRA3の間にパートナシップが必要です。

racli add ra_partner --target_host=RA3_full_name --partner_user=RA2_RA3

ソースのリカバリ・アプライアンス(RA1)にリカバリ・アプライアンス(RA3)への既存のレプリケーション・サーバーがあった場合は、移行アシスタントがレプリケーション・サーバーを作成し、宛先のリカバリ・アプライアンス(RA2)とレプリケーション・リカバリ・アプライアンス(RA3)の間のレプリケーションの保護ポリシーを追加します。

ユースケース1: RA1およびRA2からの移行

単一のリカバリ・アプライアンスから別のリカバリ・アプライアンスにバックアップを移行する場合は、次のステップに従ってください。

図21-1 2つのリカバリ・アプライアンス間の移行

RA1 (ソース)で、RA2 (宛先/ターゲット)とのパートナシップを確立します。
```
racli add ra_partner  --target_host=<RA2> 
```
RA1で、移行プロセスを起動します。
```
racli begin migration  --target_host=<RA2>
```
ノート:
移行プロセスが移行サーバーを作成、追加および使用します。正常に完了すると、移行サーバーが削除されて、移行関連プロセスがクリーン・アップされます。
事前チェックにエラーあれば、レビューして修正してください。次に、racli begin migrationを再実行します。
データベース管理者が、クライアント(データベース)のバックアップがRA2を指すように変更できます。
RA1で、移行プロセスのステータスを確認します。
```
racli status migration 
```
ステータスがCOMPLETE状態の場合、移行を終了して移行サーバーをクリーン・アップします。
```
racli end migration --target_host=<RA2> 
```

ユースケース2: 双方向レプリケーション・ペアのRA1とRA2から、別のレプリケーション・ペアRA3とRA4への移行

図21-2 双方向レプリケーションを使用したラックの移行

双方向レプリケーションのRA1-RA2を示していますか、双方向レプリケーションのRA3-R4にデータを移行しています。

プロシージャ:

RA1 (ソース)で、RAパートナーシップを設定します。

RA1とRA3の間にRAパートナーシップを設定します。
```
racli add ra_partner --target_host=RA3_full_name
```
RA1 (ソース)で、RA1とRA4の間にRAパートナシップを設定します。これにより、RA1がRA3およびRA4とパートナになり、移行プロセス全体のコントロール・センターとして機能します。
```
racli add ra_partner --target_host=RA4_full_name 
```
RA2(ソース、これは元のレプリケーションであるため)で、RA2とRA4の間にRAパートナシップを設定します。
```
racli add ra_partner --target_host=RA4_full_name
```
移行プロセスを開始します。
```
racli begin migration  --target_host=<RA2>
```
ノート:
移行プロセスが移行サーバーを作成、追加および使用します。正常に完了すると、移行サーバーが削除されて、移行関連プロセスがクリーン・アップされます。
この時点でデータベース管理者が、クライアント(データベース)のバックアップが、RA3およびRA4 (双方向レプリケーションと仮定)を指すように変更できます。
RA1 (ソース)で、移行プロセスのステータスを定期的にチェックします。
```
racli status migration 
```
ステータスがCOMPLETEと表示されたら移行を終了できます。これにより、移行サーバーを含むすべての移行プロセス・コンポーネントがクリーン・アップされます。
```
racli end migration --target_host=<RA2> 
```