バックアップ運用/レプリケーション運用における全般的な注意事項について説明します。
Storageサーバのロケールについて
すべてのStorageサーバには、AdvancedCopy Managerが使用する内部コード系(Storage管理サーバへAdvancedCopy Managerをインストールする際に指定するコード系)のロケールがインストールされている必要があります。
Storage管理サーバとStorageサーバの間で、言語環境(LANG)が異なる場合に対処が必要となります。以下にその組み合わせと対処方法を示します。
Storage管理サーバ | Storageサーバ | 対処方法 |
---|---|---|
Windows (SJIS) | Windows (SJIS) | 必要なし |
Solaris (EUC) | StorageサーバにSJISパッケージをインストールする必要がある | |
HP-UX (EUC) | StorageサーバにSJISパッケージをインストールする必要がある | |
Linux (EUC) | 必要なし | |
Linux (UTF8) | 必要なし | |
AIX (SJIS) | 必要なし | |
AIX (EUC) | StorageサーバにSJISの言語環境を追加する必要がある | |
Solaris ロケールの設定による(標準 EUC) | Windows (SJIS) | 必要なし(Storage管理サーバがEUCの場合、Storageサーバが問題なく処理する) |
Solaris (EUC) | 必要なし(同じコードの場合) 管理サーバがSJISの場合、StorageサーバにSJISパッケージをインストールする必要がある | |
HP-UX (EUC) | 必要なし(同じLANGの場合) 管理サーバがSJISの場合、StorageサーバにSJISパッケージをインストールする必要がある | |
Linux (EUC) | 必要なし | |
Linux (UTF8) | 必要なし | |
AIX (SJIS) | 必要なし(同じLANGの場合) 管理サーバがEUCの場合、StorageサーバにEUCの言語環境を追加する必要がある | |
AIX (EUC) | 必要なし(同じLANGの場合) 管理サーバがSJISの場合、StorageサーバにSJISの言語環境を追加する必要がある | |
Linux (EUC) | Windows (SJIS) | 必要なし(Storage管理サーバがEUCの場合、Storageサーバが問題なく処理する) |
Solaris (EUC) | 必要なし | |
HP-UX (EUC) | 必要なし | |
Linux (EUC) | 必要なし | |
Linux (UTF8) | 必要なし | |
AIX (SJIS) | StorageサーバにEUCの言語環境を追加する必要がある | |
AIX (EUC) | 必要なし | |
Linux (UTF8) | Windows (SJIS) | 必要なし |
Solaris (EUC) | StorageサーバにUTF8の言語環境を追加する必要がある | |
HP-UX (EUC) | StorageサーバにUTF8の言語環境を追加する必要がある | |
Linux (EUC) | 必要なし | |
Linux (UTF8) | 必要なし | |
AIX (SJIS) | StorageサーバにUTF8の言語環境を追加する必要がある | |
AIX (EUC) | StorageサーバにUTF8の言語環境を追加する必要がある |
該当パッケージをインストール後、再度GUIクライアントから「Storageサーバ上の全デバイス情報の更新」操作を実施してください。
バックアップ、レプリケーション対象について
以下のデバイスは、バックアップ対象、レプリケーション対象としないでください。
AdvancedCopy Managerがインストールされているデバイス
AdvancedCopy Managerの管理簿が存在するデバイス
LVM(Logical Volume Manager)の論理ボリュームまたはボリュームグループ
ボリューム上のデータとデータの整合性について
業務ボリューム上のデータ | データの整合性確保 | 運用方法 |
---|---|---|
運用中のOracleのデータベーススペース | Oracleと連携する必要があります。 | Oracle連携用のサンプルスクリプトを使用します。 詳細については、「付録B Oracleと連携したバックアップ運用(サンプルシェルスクリプト)」を参照してください。 |
運用中のSymfowareのデータベーススペース | AdvancedCopy ManagerのコマンドがSymfowareと連携して整合性を確保します。 | 「第5章 バックアップ運用(Symfoware)」を参照してください。 |
ファイルシステム | AdvancedCopy Managerのコマンドがファイルシステムをアンマウントして整合性を確保します。 | 「付録A バックアップ/リストアの前後処理」および「付録C レプリケーションの前後処理」を参照してください。 |
上記以外 | 運用でデータの整合性を確保する必要があります。 | バックアップ、レプリケーションの実行時に業務を停止するなどの対処を行ってください。 |
デバイス情報の取り込みについて
バックアップ運用/レプリケーション運用を開始する前に、AdvancedCopy ManagerのGUIクライアントを使用して、全Storageサーバが管理するデバイス情報の取り込みを行います。デバイス情報の取り込みについては、「4.4.5 Storageサーバ配下のデバイス情報の取り込み」を参照してください。この操作は、選択したStorageサーバに定義されているデバイスの総数に比例した時間がかかります。デバイス数が多い場合はCPU負荷やI/O負荷の低い状態で実施してください。
目安として、負荷のない状態で、1デバイス(パーティション)あたり約0.5秒かかりますので、参考としてください。
同時実行数の上限について
1つのLU(Logical Unit)内で、同時に実行できるアドバンスト・コピーのセッション数には、上限(最大値)があります。そのため、1つのLU内のボリューム数は、LUあたりの最大コピーセッション数以下にしてください。
運用上、1LUあたりの最大コピーセッション数以上のボリュームを、同一LUに作成する必要がある場合、同一LU内のボリュームに対して、最大コピーセッション数以上のアドバンスト・コピーを同時に実施しない運用設計が必要です。
なお、1LUあたりの最大コピーセッション数については、ETERNUS ディスクアレイの『SA/SEハンドブック』を参照してください。
パーティションのサイズについて
業務ボリュームとバックアップボリュームは同一サイズである必要があります。しかし、以下のパーティションについては、OS制御領域が自動的に確保されるため、fdiskコマンドで指定したサイズが、全て利用可能なサイズとはなりません。
ディスク内の先頭(fdiskコマンド上一番左)に存在する基本パーティション
拡張パーティションの先頭の論理パーティション
図11.1 パーティションで確保されるサイズについて
このため、業務ボリュームとバックアップボリュームを構成するパーティションは、サイズを同じにして作成した、以下の組み合わせにしたがい構成してください。
図11.2 業務ボリュームとバックアップボリュームの組み合わせ
図11.3 サイズの異なるパーティションが混在しているディスクでの組み合わせ例
また、レプリケーション運用において、複製元ボリューム/複製先ボリュームを同一サイズにする場合も、上記の同色の組み合わせにしてください。
ポイント
運用ミスを防止するために、AdvancedCopy Managerで管理するETERNUS ディスクアレイ上の全パーティションは、拡張パーティションとする事をお勧めします。
全てを拡張パーティションとして定義できない場合には、業務ボリュームとして定義したデバイスが含まれるパーティション構成と、バックアップボリュームとして定義したデバイスが含まれるパーティション構成は同一にする事をお勧めします。
注意
PRIMECLUSTER GDSのボリュームをバックアップ運用する場合
GDSボリュームをバックアップする場合は、バックアップボリュームのサイズをセクタサイズで指定して、GDSボリュームと一致させてください。
バックアップボリュームの作成方法は以下になります。
バックアップするGDSボリュームの正確なサイズと本数を調べてください。
正確なサイズは、以下のコマンドで出力されるBLOCKSに、512バイトをかけた値です。
sdxinfo -o ボリューム名 |
下記の例では、BLOCKSに425984と出力されているため、サイズは218103808バイト(425984ブロック*512バイト)になります。
# sdxinfo -o v1 OBJ NAME CLASS GROUP SKIP JRM 1STBLK LASTBLK BLOCKS STATUS ------ ------- ------- ------- ---- --- -------- -------- -------- -------- volume v1 c1 g1 off on 65536 491519 425984 ACTIVE |
partedコマンドを使用して、バックアップボリュームのディスク形式が、msdos形式であることを確認してください。msdos形式でない場合は、「/sbin/parted <デバイス名> mklabel msdos」を実行してmsdos形式にしてください。
バックアップボリュームを作成するディスクの1セクタあたりのバイト数を調べます。
下記の例では、”sectors of 512 bytes”とあり、1セクタが512バイトであることがわかります。
# /sbin/sfdisk -uS -l /dev/sdp Disk /dev/sdp: 1017 cylinders, 133 heads, 62 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdp1 0 - 0 0 Empty /dev/sdp2 0 - 0 0 Empty /dev/sdp3 0 - 0 0 Empty /dev/sdp4 0 - 0 0 Empty |
ディスクにmsdosディスクラベルが存在しない場合、次のようなエラーとなります。
「sfdisk: ERROR: sector 0 does not have an msdos signature」
あらかじめ、対象のディスクに、fdiskコマンドまたはpartedコマンドで、msdosディスクラベルを作成してください。
例) # partedコマンドでmsdosディスクラベルを作成する場合
# /sbin/parted /dev/sdp mklabel msdos |
作成するバックアップボリュームのセクタ数を計算します。
218103808バイト / 512バイト = 425984セクタ |
ただし、論理ボリュームの先頭1セクタは、パーティションディスクリプタが配置されるため、使用できないセクタになります。そのため、求めたセクタ数に1を加算します。
425984セクタ + 1=425985セクタ |
よって、作成するセクタは425985セクタになります。
sfdiskコマンドで入力するファイルを作成します。
バックアップボリュームは、拡張パーティション内の論理パーティションとして作成する必要があるため、以下のようなファイルを作成します。
# cat ./sdp-partition.dat ,,E ; ; ; ,128,L ,425985,L ,425985,L ,425985,L |
1つ目の論理パーティション(/dev/sdp5)は、パーティションディスクリプタの関係により、ほかの論理パーティションと同じサイズにすることができません。
そのため、1つ目の論理パーティションは、適当なサイズ(この場合128セクタ)で作成し、バックアップボリュームとしては使用しません。
sfdiskコマンドを利用して、パーティションを作成します。
# /sbin/sfdisk -uS --force /dev/sdp < ./sdp-partition.dat Checking that no-one is using this disk right now ... OK Disk /dev/sdp: 1017 cylinders, 133 heads, 62 sectors/track Old situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdp1 0 - 0 0 Empty /dev/sdp2 0 - 0 0 Empty /dev/sdp3 0 - 0 0 Empty /dev/sdp4 0 - 0 0 Empty New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdp1 1 8386181 8386181 5 Extended /dev/sdp2 0 - 0 0 Empty /dev/sdp3 0 - 0 0 Empty /dev/sdp4 0 - 0 0 Empty /dev/sdp5 2 129 128 83 Linux /dev/sdp6 131 426114 425984 83 Linux /dev/sdp7 426116 852099 425984 83 Linux /dev/sdp8 852101 1278084 425984 83 Linux Warning: partition 5 does not end at a cylinder boundary Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) |
作成された/dev/sdp6、/dev/sdp7、/dev/sdp8を、バックアップボリュームとして使用してください。
GDSでのミラーについて
筐体間ミラーを行っている場合、筐体障害の場合もOPCによりリストアする必要がある場合は、ミラーの両系をバックアップする必要があります。この場合バックアップボリュームは、論理ボリュームの容量ではなく、物理ボリュームの容量分が必要です。
ディスクへの他サーバからのマウントについて
複数のサーバからマウントできる状態のボリュームに対してバックアップ/リストア、レプリケーションを行う場合は、他サーバからのマウントを事前に解除してください。
また、他サーバからのマウントが必要ないディスクには、ETERNUS ディスクアレイやファイバーチャネルスイッチ等のハードウェアの設定により、複数のサーバから同じパーティションを検出したり、アクセスしたりできないように設定してください。
ファイルシステムを対象としたコピー処理を実行する場合の注意事項
ファイルシステムを対象とする場合、データへのアクセス抑止とデータの整合性を保証するためにボリュームのアンマウントを行います。
そのため、ボリュームが使用中の場合はアンマウントができないため、バックアップ/リストアおよびレプリケーション処理の実行はエラーとなります。
以下の点などに注意して、アンマウントができる状態で処理を実行するようにしてください。
他のアプリケーションがボリュームを使用していないこと。使用している場合は、一時的にアプリケーションを停止してください。
ユーザーがボリュームを使用していないこと。利用している場合は、一時的に利用をやめてください。
ボリュームの中に別のボリュームをマウントしていないこと。別のボリュームをマウントしている場合は、一時的にマウントを解除してください。
NFS共有でshareされていないこと(Solaris/HP-UX/Linuxの場合)。Shareされている場合は、一時的にunshareしてください。
アンマウントが必要な時間はコマンドの実行中のみです。コマンドの終了後は運用を再開することができます。
Logical Unit(ディスク)単位コピーを実施する場合の注意事項
Logical Unit(ディスク)単位コピーは、レプリケーション運用で利用できます。
Logical Unit(ディスク)単位コピーを実施する場合、以下の点に注意してください。
テープバックアップについて
テープバックアップ機能については、『ETERNUS SF AdvancedCopy Manager 運用手引書 テープバックアップ連携編』の「システムボリュームのバックアップ/リストア」を参照してください。
サーバ間でコピーを行う場合
両サーバのバージョンを13.1以降にしてください。
サイズの異なるLogical Unit(ディスク)間でのコピーを行う場合
サイズの異なるLogical Unit(ディスク)間でコピーを行う場合、小さいサイズのLogical Unit(ディスク)に合わせて物理コピーを行います。小さいサイズのLogical Unit(ディスク)から大きいサイズのLogical Unit(ディスク)へコピーする場合は、一部領域には物理コピーが行われず、コピーを行う前のデータが残ります。この残存した領域にLogical Unit(ディスク)の管理情報が存在している場合、パーティショニングツールがディスク形式を誤って認識することがありますので、事前にコピー先のLogical Unit(ディスク)をフォーマットしてから実施してください。
GPTディスクについて
GPTディスクをLogical Unit(ディスク)単位でコピーする場合は、複製元ボリュームと複製先ボリュームのサイズをバイト数まで同じにしてください。
サイズの異なるボリューム間でコピーすると、複製先ボリュームのGPTラベルが書き換えられる場合があります。GPTラベルが書き換えられた複製先ボリュームを複製元ボリュームにリストアしても、複製元ボリュームは利用できません。
コピー実施時の注意
レプリケーション管理の複製元ボリューム/複製先ボリュームの領域と、バックアップ管理の業務ボリューム/バックアップボリュームの領域が重複している場合、領域が重複したボリュームに対して同時にレプリケーション管理とバックアップ管理の操作を行わないでください。
Logical Unit(ディスク)に含まれるパーティションをアンマウントした状態でコピーを実施してください。マウントした状態でコピーを実施した場合、コピー先のディスクに含まれるパーティションは、ファイルシステムとして整合がとれない場合があります。
SDXオブジェクトについて
SDXオブジェクトのLogical Unit(ディスク)単位コピーは利用できません。
異なるOS間でコピーを実施する場合の注意事項
異なるOS間でのコピーは、レプリケーション運用で利用できます。
異なるOS間でのコピーを実施する場合は、次の組み合わせで実施してください。
| 複製先 | ||
---|---|---|---|
パーティション | Logical Unit(ディスク) | ||
複製元 | パーティション | ○ | × |
Logical Unit(ディスク) | ○ | × |
○:可能、×:不可
注意
SnapOPC+を利用して、異なるOS間でコピーを実施する場合は、SnapOPC+が利用可能なOS間でコピーを実施してください。
サポートするディスク形式
以下のディスク形式をサポートしています。
サポートOS | ディスク形式 | |
---|---|---|
GPT | MBR | |
Red Hat Enterprise Linux AS (v.4 for x86) | ○ | ◎ |
Red Hat Enterprise Linux AS (v.4 for EM64T) | ○ | ◎ |
Red Hat Enterprise Linux AS (v.4 for Itanium) | ◎ | ○ |
◎:サポート(推奨)、○:サポート、×:非サポート
udev機構により生成されるデバイス名(by-id、by-path)での運用について
udev機構により生成されるデバイス名を使用してAdvancedCopy Managerを運用する場合、以下の点に注意してください。
ファイルシステムをマウントする場合のデバイス名は、AdvancedCopy Managerで使用するデバイス名と同じにする必要があります。
AdvancedCopy Managerをby-idで運用する場合、by-idでマウントします。
AdvancedCopy Managerをby-pathで運用する場合、by-pathでマウントします。
udev名でサーバ間レプリケーションを行う場合、相手サーバのAdvancedCopy Managerのバージョンを同一にする必要があります。
相手サーバが以下のOSの場合、udev名でのサーバ間レプリケーションは行えません。
HP-UX
AIX
-mオプション使用時の注意事項
サーバ間レプリケーションの場合、以下のコマンドにおいて、-mオプションを指定することにより、非操作サーバとの通信処理を行わないようにすることができます。
-mオプションを指定する場合は、非操作サーバでのボリューム前後処理が行われなくても問題がないように、以下のいずれかの条件が満たされる必要があります。
非操作サーバがシャットダウンされている。
非操作サーバのボリュームに対する前後処理を手動で実施する。
対象ボリュームがファイルシステムではなく、前後処理が不要なRAWデバイスである(Oracle等)。
アドバンスト・コピーのコピー処理性能について
アドバンスト・コピーのコピー処理はETERNUS ディスクアレイによって行われるため、コピー処理性能に関するお問い合わせは、ETERNUS ディスクアレイのサポート部門までお願いいたします。
ラベル指定によるマウントについて
コピー元ボリュームにラベルが付与されている、かつ、以下のaまたはbに該当する場合、アドバンスト・コピーによりシステム内に同じラベルをもつボリュームが複数存在する状態が発生します。
バックアップ/リストアやサーバ内レプリケーションを行った場合
サーバ間レプリケーションにおいて、コピー先サーバにコピー元ボリュームと同じラベルをもつボリュームが存在した場合
同じラベルをもつボリュームが複数存在すると、マウント処理等が正常に動作しません。
このような現象を避けるために、/etc/grub.confおよび/etc/fstabには、ラベルではなく、デバイス(/dev/sda1など)を指定するようにしてください。