| ETERNUS SF AdvancedCopy Manager 運用手引書 13.0 -AIX- |
|
目次
索引
|
本章では、AdvancedCopy Managerの運用における注意事項について説明します。
バックアップ運用／レプリケーション運用の注意事項について説明します。
バックアップ運用／レプリケーション運用における全般的な注意事項について説明します。
すべてのStorageサーバには、AdvancedCopy Managerが使用する内部コード系（Storage管理サーバへAdvancedCopy Managerをインストールする際に指定するコード系）のロケールがインストールされている必要があります。
Storage管理サーバとStorageサーバの間で、言語環境(LANG)が異なる場合に対処が必要となります。以下にその組み合わせと対処方法を示します。
|
Storage管理サーバ |
Storageサーバ |
対処方法 |
|---|---|---|
|
Windows (SJIS) |
Windows (SJIS) |
必要なし |
|
Windows (SJIS) |
Solaris (EUC) |
StorageサーバにSJISパッケージをインストールする必要がある |
|
Windows (SJIS) |
HP-UX (EUC) |
StorageサーバにSJISパッケージをインストールする必要がある |
|
Windows (SJIS) |
Linux (EUC) |
必要なし |
|
Windows (SJIS) |
Linux (UTF8) |
必要なし |
|
Windows (SJIS) |
AIX (SJIS) |
必要なし |
|
Windows (SJIS) |
AIX (EUC) |
StorageサーバにSJISの言語環境を追加する必要がある |
|
Solaris ロケールの設定による(標準 EUC) |
Windows (SJIS) |
必要なし(Storage管理サーバがEUCの場合、Storageサーバが問題なく処理する) |
|
Solaris ロケールの設定による(標準 EUC) |
Solaris (EUC) |
必要なし(同じコードの場合) 管理サーバがSJISの場合、StorageサーバにSJISパッケージをインストールする必要がある |
|
Solaris ロケールの設定による(標準 EUC) |
HP-UX (EUC) |
必要なし(同じLANGの場合) 管理サーバがSJISの場合、StorageサーバにSJISパッケージをインストールする必要がある |
|
Solaris ロケールの設定による(標準 EUC) |
Linux (EUC) |
必要なし |
|
Solaris ロケールの設定による(標準 EUC) |
Linux (UTF8) |
必要なし |
|
Solaris ロケールの設定による(標準 EUC) |
AIX (SJIS) |
必要なし(同じLANGの場合) 管理サーバがEUCの場合、EUCの言語環境を追加する必要がある |
|
Solaris ロケールの設定による(標準 EUC) |
AIX (EUC) |
必要なし(同じLANGの場合) 管理サーバがSJISの場合、SJISの言語環境を追加する必要がある |
|
Linux (EUC) |
Windows (SJIS) |
必要なし(Storage管理サーバがEUCの場合、Storageサーバが問題なく処理する) |
|
Linux (EUC) |
Solaris (EUC) |
必要なし |
|
Linux (EUC) |
HP-UX (EUC) |
必要なし |
|
Linux (EUC) |
Linux (EUC) |
必要なし |
|
Linux (EUC) |
Linux (UTF8) |
必要なし |
|
Linux (EUC) |
AIX (SJIS) |
StorageサーバにEUCの言語環境を追加する必要がある |
|
Linux (EUC) |
AIX (EUC) |
必要なし |
|
Linux (UTF8) |
Windows (SJIS) |
必要なし |
|
Linux (UTF8) |
Solaris (EUC) |
StorageサーバにUTF8の言語環境を追加する必要がある |
|
Linux (UTF8) |
HP-UX (EUC) |
StorageサーバにUTF8の言語環境を追加する必要がある |
|
Linux (UTF8) |
Linux (EUC) |
必要なし |
|
Linux (UTF8) |
Linux (UTF8) |
必要なし |
|
Linux (UTF8) |
AIX (SJIS) |
StorageサーバにUTF8の言語環境を追加する必要がある |
|
Linux (UTF8) |
AIX (EUC) |
StorageサーバにUTF8の言語環境を追加する必要がある |
また、サーバ間レプリケーションを行う場合は、複製元サーバで使用してるコード系のロケールが、複製先サーバにインストールされている必要があります。
以下のデバイスは、バックアップ対象、レプリケーション対象としないでください。
システムが格納されているデバイス
AdvancedCopy Managerがインストールされているデバイス
AdvancedCopy Managerの管理簿が存在するデバイス
|
業務ボリューム上のデータ |
データの整合性確保 |
運用方法 |
|---|---|---|
|
ファイルシステム |
AdvancedCopy Managerのコマンドがファイルシステムをアンマウントして整合性を確保します。 |
本マニュアルの『バックアップ・リストアの前後処理』および『レプリケーションの前後処理』を参照してください。 |
|
上記以外 |
運用でデータの整合性を確保する必要があります。 |
バックアップ、レプリケーションの実行時に業務を停止するなどの対処を行ってください。 |
バックアップ運用／レプリケーション運用を開始する前に、AdvancedCopy ManagerのWeb画面にて、全Storageサーバが管理するデバイス情報の取り込みを行います。この操作は、選択したStorageサーバに定義されているデバイスの総数に比例した時間がかかります。デバイス数が多い場合はCPU負荷やI/O負荷の低い状態で実施してください。
目安として、負荷のない状態で、1デバイス(ディスク)あたり約0.5秒かかりますので、参考としてください。
デバイスをマルチパス構成にしている場合、片パスが閉塞されても自動的にパス交替しません。
片パスが閉塞された場合は、以下の対処実施後、バックアップ／レプリケーションを再実行してください。
以下のコマンドを実施し、パスを切り換える。正常なデバイスに対して以下のコマンドを実行してください。
/usr/sbin/lspv hdisk*
バックアップ／レプリケーションのコマンドを再度実行する。
複数のサーバからマウントできる状態のボリュームに対してバックアップ／リストア、レプリケーションを行う場合は、他サーバからのマウントを事前に解除してください。
また、他サーバからのマウントが必要ないディスクには、ETERNUS ディスクアレイやファイバーチャネルスイッチ等のハードウェアの設定により、複数のサーバから同じ論理ディスクを検出したり、アクセスしたりできないように設定してください。
ファイルシステムを対象とする場合、データへのアクセス抑止とデータの整合性を保証するためにボリュームのアンマウントを行います。
そのため、ボリュームが使用中の場合はアンマウントができないため、バックアップ／リストアおよびレプリケーション処理の実行はエラーとなります。
以下の点などに注意して、アンマウントができる状態で処理を実行するようにしてください。
他のアプリケーションがボリュームを使用していないこと。使用している場合は、一時的にアプリケーションを停止してください。
ユーザーがボリュームを使用していないこと。利用している場合は、一時的に利用をやめてください。
ボリュームの中に別のボリュームをマウントしていないこと。別のボリュームをマウントしている場合は、一時的にマウントを解除してください。
NFS共有でshareされていないこと（Solaris/HP-UX/AIX/Linuxの場合）。Shareされている場合は、一時的にunshareしてください。
アンマウントが必要な時間はコマンドの実行中のみです。コマンドの終了後は運用を再開することができます。
スナップショット型高速バックアップの注意事項について説明します。
スナップショット型高速バックアップでは、指定世代本数のバックアップボリュームが必要となります。この為、以下の場合は、バックアップする事ができません。
指定世代本数全てがバックアップされている。かつ
バックアップボリュームとして利用できる新規ボリュームが1本もない。
同一の業務ボリュームを指定して、連続してスナップショット型高速バックアップを実施すると、平行してバックアップ処理が行われます。
また、保存世代数以上のスナップショット型高速バックアップを連続して実施すると、一番古いバックアップ処理から順にキャンセルされます。すなわち、指定世代本数以上のバックアップ処理は同時に実施できません。
同期型高速バックアップの注意事項について説明します。
業務ボリュームとバックアップボリュームが等価状態になる前にバックアップ実行コマンドを実行する事は出来ません。
同期型高速バックアップ運用のバックアップポリシー設定時に、必要な数のバックアップボリュームが登録されていなくても、スナップショット型高速バックアップ運用に必要な数のバックアップボリュームが登録されていれば、バックアップポリシーは、設定出来ます。この場合、同期型バックアップは実行出来ない事があります。
リストアの注意事項について説明します。
最新のバックアップボリューム採取時点からリストア操作を行うまでに、業務ボリュームの内容を書き換えたとしても、書き換えられたデータについては保証されません。
AIXではすべてのデバイスをLVMで管理しています。このためバックアップを実行すると、バックアップボリュームのLVM管理情報が、業務ボリュームのLVM管理情報で書き換えられてしまう為、そのままではバックアップボリュームを活性化することや、バックアップボリューム上の論理ボリュームをマウントできなくなります。
バックアップボリュームをマウントするためには、バックアップボリュームのLVM管理情報を書き換える必要があります。バックアップボリュームのLVM管理情報を書き換えると、通常手順で業務ボリュームに対するリストアを実施できなくなりますのでお勧めしません。しかし運用上どうしてもバックアップボリュームをマウントしなければならない場合は、以下の手順を実施することでマウント可能となります。手順を誤ると業務データを破壊する危険性があるので、細心の注意を払って実施してください。各コマンドの詳細はAIXのマニュアルを参照してください。また次項『バックアップボリュームのLVM管理情報を書き換えた場合のリストア手順』についても合わせて参照してください。
lspvコマンド等を使用して、バックアップボリュームの物理ボリューム名を控えてください。
# /usr/sbin/lspv hdisk0 0004f10aa92e686c rootvg hdisk1 0004f10a1c7879c5 vg01 |
バックアップボリュームのボリュームグループ名がvg01の場合、上記の例では物理ボリューム名がhdisk1になります。
chdevコマンドを使用して、一時的にバックアップボリュームをLVMから削除します。
# /usr/sbin/chdev -l hdisk1 -a pv=clear |
exportvgコマンドを使用して、バックアップボリュームをエクスポートします。
# /usr/sbin/exportvg vg01 |
recreatevgコマンドを使用して、バックアップボリュームのLVM管理情報を書き換えます。
# /usr/sbin/recreatevg -y vg01 hdisk1 |
recreatevgコマンドを実行することで、ボリュームグループ内の論理ボリューム名が変更されるため、lsvgコマンドを使用して変更後の論理ボリューム名を確認します。
# /usr/sbin/lsvg -l vg01 vg01: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT fslv01 jfs 2 2 1 closed/syncd N/A |
手順5で確認した論理ボリューム名を指定してファイルシステムをマウントします。マウントした論理ボリュームは、次回バックアップを行うまでにアンマウントしてください。バックアップボリューム内の論理ボリュームがマウントされていると、バックアップに失敗します。
バックアップボリュームのLVM管理情報を書き換えると、業務ボリュームとバックアップボリュームでLVM管理情報が一致しなくなるため、通常の手順でリストアできなくなります。その場合、以下の手順でリストアしてください。手順を誤ると業務データを破壊する危険性があるので、細心の注意を払って実施してください。各コマンドの詳細はAIXのマニュアルを参照してください。
本マニュアルの『バックアップ・リストアの前後処理』を参照して、リストアの後処理スクリプトを編集してください。
リストア処理を実行します。手順1により、この時点では業務ボリュームは非活性の状態となります。
lspvコマンド等を実行し、業務ボリュームの物理ボリューム名を控えてください。
# /usr/sbin/lspv hdisk0 0004f10aa92e686c rootvg hdisk1 0004f10a1c7879c5 vg01 |
業務ボリュームのボリュームグループ名がvg01の場合、上記の例では物理ボリューム名がhdisk1になります。
chdevコマンドを使用して、一時的に業務ボリュームをLVMから削除します。
# /usr/sbin/chdev -l hdisk1 -a pv=clear |
exportvgコマンドを使用して、業務ボリュームをエクスポートします。
# /usr/sbin/exportvg vg01 |
recreatevgコマンドを使用して、業務ボリュームのLVM管理情報を書き換えます。
# /usr/sbin/recreatevg -y vg01 hdisk1 |
recreatevgコマンドを実行することで、ボリュームグループ内の論理ボリューム名が変更されるため、lsvgコマンドを使用して変更後の論理ボリューム名を確認します。
# /usr/sbin/lsvg -l vg01 vg01: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT fslv01 jfs 2 2 1 closed/syncd N/A |
手順7で確認した論理ボリューム名を指定してファイルシステムをマウントします。
業務ボリューム以外のボリュームに対してリストアを行う場合は、リストアの前後処理スクリプトが実行されません。またリストア先ボリュームとバックアップボリュームでLVM管理情報が一致しないため、LVM管理情報の書き換えが必要となります。このため業務ボリューム以外のボリュームへリストアする場合は、以下の手順を実施してください。手順を誤ると業務データを破壊する危険性があるので、細心の注意を払って実施してください。各コマンドの詳細はAIXのマニュアルを参照してください。
リストア先ボリュームのボリュームグループに含まれる、全ての論理ボリュームをアンマウントしてください。
varyoffvgコマンドを使用して、リストア先ボリュームのボリュームグループを非活性化します。以下の実行例では、リストア先ボリュームのボリュームグループ名をvg01としています。
# /usr/sbin/varyoffvg vg01 |
リストア先ボリュームに対してリストアを実行します。手順は本マニュアル『リストアの実行』を参照してください。
lspvコマンド等を実行し、リストア先ボリュームの物理ボリューム名を控えてください。
# /usr/sbin/lspv hdisk0 0004f10aa92e686c rootvg hdisk1 0004f10a1c7879c5 vg01 |
リストア先ボリュームのボリュームグループ名がvg01の場合、上記の例では物理ボリューム名がhdisk1になります。
chdevコマンドを使用して、一時的にリストア先ボリュームをLVMから削除します。
# /usr/sbin/chdev -l hdisk1 -a pv=clear |
exportvgコマンドを使用して、リストア先ボリュームをエクスポートします。
# /usr/sbin/exportvg vg01 |
recreatevgコマンドを使用して、リストア先ボリュームのLVM管理情報を書き換えます。
# /usr/sbin/recreatevg -y vg01 hdisk1 |
recreatevgコマンドを使用することで、ボリュームグループ内の論理ボリューム名が変更されるため、lsvgコマンドを使用して変更後の論理ボリューム名を確認します。
# /usr/sbin/lsvg -l vg01 vg01: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT fslv01 jfs 2 2 1 closed/syncd N/A |
手順8で確認した論理ボリューム名を指定してファイルシステムをマウントします。
クラスタ運用での一般的な注意事項として以下の項目があります。
システム全体に環境変数が設定されるようなSWSTGNODEの登録は実施しないでください。
AdvancedCopy Managerでは、業務を構成するデーモンの監視を実施していません。業務のデーモンが何らかの原因で停止した場合、自動で再起動を実施しないため、手動にて再起動する必要があります。また、AdvancedCopy Managerの業務用のデーモンが停止したことにより、パッケージがフェールオーバすることもありません。
AdvancedCopy Managerの業務を構成するデーモンとその起動方法については、本マニュアルの『デーモンの起動と停止』を参照してください。
クラスタシステムにおけるバックアップ運用については、通常運用と異なる以下の注意事項があります。
バックアップコマンド実行中にフェールオーバが発生した場合、資源整合コマンドを使用して整合性がとれるようにリカバリ対処が必要です。
同期型高速バックアップを使用する場合は，バックアップをクラスタ業務に登録しないでください。
クラスタ運用を行う場合、AdvancedCopy Managerはサービスグループに組み込まれており、サービスグループの一部として動作するため、バックアップ運用はサービスグループの運用系で実施する必要があります。
待機状態となっているノードや、別のサービスグループからバックアップを行うことはできません。
AdvancedCopy Managerでのバックアップ／リストアでは，基本的に処理の前後で業務ボリュームのアンマウント／マウント処理が必要となります。
業務ボリュームのマウントポイントがクラスタ業務に登録されている場合はマウント／アンマウントの代替としてクラスタ業務からマウントポイントリソースのオフライン／オンラインを実施してください。またはバックアップ／リストア前後処理スクリプトで行うアンマウント／マウント処理をオフライン／オンライン処理に変更してください。
また、マウントポイントリソースのオフライン／オンラインを行ってから、実際にボリュームがアンマウント／マウントされるまでに時間差があります。そのため実際にアンマウント／マウントされるまで待ち合わせる処理(sleepやdfコマンドの結果を監視するなど)をオフライン／オンラインの成否を判定する箇所の後に追加してください。
前後処理スクリプトについての詳細とカスタマイズ例は、本マニュアルの『バックアップ/リストアの前後処理』を参照してください。リソースのオフライン／オンラインに使用するコマンドの詳細については クラスタシステムのマニュアルを参照してください。
AdvancedCopy Managerが属するサービスグループが稼動している場合、稼動ノードでのみバックアップ運用が可能です。待機ノードではバックアップ運用を行うための環境が整っていない（必要なリソースが使用できない）ため、バックアップ運用を行うことはできません。同様に、サービスグループが停止している場合も、環境が整っていないためにバックアップ運用を行うことはできません。
ただしサービスグループが停止している場合に限り、一時的に必要最低限の環境を整えることで、バックアップ運用を行うことができます。
以下の共有ディスクを有効（オンラインやファイルシステムの場合はマウント）にできない場合、バックアップ運用を行うことはできません。
AdvancedCopy Manager共有データ用共有ディスク
バックアップ運用ディスク(運用したい業務ボリューム/バックアップボリューム)
バックアップ運用での以下の操作はできません。
GUI操作によるバックアップ/リストア
Storage管理サーバからのバックアップ運用の操作 (-h オプション指定によるホストの指示)
業務ボリューム/バックアップボリュームの追加削除やポリシーの変更
Storage管理サーバ業務兼Storageサーバ業務にてバックアップ管理の表示系コマンドを実行する場合、コマンドにオプションを指定する必要があります。バックアップ管理の表示系コマンドについては、『Solaris OE版 ETERNUS SF AdvancedCopy Manager 運用手引書 10.1 バックアップ管理のコマンド』を参照してください。
以下の手順にて、サービスグループ停止中のバックアップ運用を行います。
両ノードでサービスグループが停止していることを確認します。
サービスグループを停止する方法については、VERITAS Cluster Serverのマニュアルを参照してください。
バックアップしたいノードにtelnet等でログインします。
論理IPアドレスは使用できません。物理IPアドレスを使用して運用するノードを直接ご利用ください。
共有ディスクを有効にします。
共有ディスクを起動（オンライン）します。
AdvancedCopy Manager共有データ用共有ディスクをマウントします。
業務ボリュームがファイルシステムの場合、マウントします。
共有ディスクの有効化は必ずどちらか一方のノードで行ってください。両ノードで同じ共有ディスクを有効にしないでください。
バックアップ運用を実施します。
クラスタ運用の通常時と同様、バックアップ運用を行うことができます。
リストア実行コマンドを使用してリストアすることもできます。
手順3で有効にした共有ディスクを全て解除します。
マウントしたファイルシステムは、アンマウントします。
共有ディスクを停止（オフライン）します。
サービスグループを起動（オンライン）します。
必要に応じて、サービスグループを起動します。
サービスグループの起動方法については、VERITAS Cluster Serverのマニュアルを参照してください。
クラスタシステムにおけるレプリケーション運用については、通常運用と異なる以下の注意事項があります。
レプリケーションコマンド実行中にフェールオーバが発生した場合、資源整合コマンドを使用して整合性がとれるようにリカバリ対処が必要です。
同期型レプリケーションを使用する場合は，複写先ボリュームをクラスタ業務に登録しないでください。
クラスタ運用を行う場合、AdvancedCopy Managerはサービスグループに組み込まれており、サービスグループの一部として動作するため、レプリケーション運用はサービスグループの運用系で実施する必要があります。
待機状態となっているノードや、別のサービスグループからレプリケーションを行うことはできません。
レプリケーションでは，コマンドによって処理の前後で複写先，複写元ボリュームに対してアンマウント／マウント処理が必要となります。
複写先，複写元ボリュームがクラスタ業務に登録されている場合はアンマウント／マウントの代替としてクラスタ業務から複写先，複写元ボリュームリソースのオフライン／オンラインを実施してください。またはレプリケーション前後処理スクリプトのアンマウント／マウント処理をオフライン／オンライン処理に変更してください。
また、マウントポイントリソースのオフライン／オンラインを行ってから、実際にボリュームがアンマウント／マウントされるまでに時間差があります。そのため実際にアンマウント／マウントされるまで待ち合わせる処理(sleepやdfコマンドの結果を監視するなど)をオフライン／オンラインの成否を判定する箇所の後に追加してください。
前後処理スクリプトについての詳細とカスタマイズ例は、本マニュアルの『レプリケーションの前後処理』を参照してください。リソースのオフライン／オンラインに使用するコマンドの詳細については クラスタシステムのマニュアルを参照してください。
AdvancedCopy Managerが属するサービスグループが稼動している場合、稼動ノードでのみレプリケーション運用が可能です。待機ノードではレプリケーション運用を行うための環境が整っていない（必要なリソースが使用できない）ため、レプリケーション運用を行うことはできません。同様に、サービスグループが停止している場合も、環境が整っていないためにレプリケーション運用を行うことはできません。
ただしサービスグループが停止している場合に限り、一時的に必要最低限の環境を整えることで、レプリケーション運用を行うことができます。
以下の共有ディスクを有効（オンラインやファイルシステムの場合はマウント）にできない場合、レプリケーション運用を行うことはできません。
AdvancedCopy Manager共有データ用共有ディスク
レプリケーション運用ディスク(運用したい複写元ボリューム／複写先ボリューム)
レプリケーション運用での以下の操作はできません。
Storage管理サーバからのレプリケーション運用の操作 (-h オプション指定によるホストの指示)
複製元/複製先ボリュームの追加削除
-mオプションを指定しないサーバ間レプリケーション
Storage管理サーバ業務兼Storageサーバ業務にてレプリケーション管理の表示系コマンドを実行する場合、コマンドにオプションを指定する必要があります。レプリケーション管理の表示系コマンドについては、本マニュアルの『レプリケーション管理のコマンド』を参照してください。
以下の手順にて、サービスグループ停止中のレプリケーション運用を行います。
両ノードでサービスグループが停止していることを確認します。
サービスグループを停止する方法については、VERITAS Cluster Serverのマニュアルを参照してください。
レプリケーション運用したいノードにtelnet等でログインします。
論理IPアドレスは使用できません。物理IPアドレスを使用して運用するノードを直接ご利用ください。
共有ディスクを有効にします。
共有ディスクを起動（オンライン）します。
AdvancedCopy Manager共有データ用共有ディスクをマウントします。
複製元／複製先ボリュームをファイルシステムとしてマウントして運用していた場合はマウントします。
共有ディスクの有効化は必ずどちらか一方のノードで行ってください。両ノードで同じ共有ディスクを有効にしないでください。
レプリケーション運用を実施します。
クラスタ運用の通常時と同様、レプリケーション運用を行うことができます。
複製先ボリュームから複製元ボリュームにリストアすることもできます。
手順3で有効にした共有ディスクを全て解除します。
マウントしたファイルシステムは、アンマウントします。
共有ディスクを停止（オフライン）します。
サービスグループを起動（オンライン）します。
必要に応じて、サービスグループを起動します。
サービスグループの起動方法については、VERITAS Cluster Serverのマニュアルを参照してください。
Web画面環境についての注意事項は、ETERNUS SF AdvancedCopy Manager使用手引書『クライアントの設定』を参照してください。
|
目次
索引
|