マルチパスとlvmを使用したプロセス - 新しいストレージアレイへの移行

マルチパスとlvmを使用したプロセス - 新しいストレージアレイへの移行

私は古いRedhat(5)サーバーを持っており、9つのアレイファイルシステムを新しいアレイに移動する必要があります。これを行うための最良の方法とプロセスのしくみについてのヘルプを探しています。

データは配列レベルのコピーに直接コピーされます。既存のサーバーから9つのLUNid(WWN)を取得し、これをmultipath -llの出力で確認しました。また、古いストレージに対応する新しいストレージにもLUNidがあります。新しいストレージに移行する方法がわかりません。 pvscanなどのLVMコマンドの機能を完全に理解していません。プロセスは、アレイファイルシステムを停止してマウント解除した後、/etc/fstabから削除してブート時にマウントを試みないようにすることだと思います。次にサーバーをシャットダウンし、新しいアレイLUNidを接続して起動します。このステップでは、multipath -llの新しいLUNidを確認したいと思います。そうですか?カスタムデバイスの命名を指定しなかったため、各デバイスのデバイス名のmpathX形式も表示されますか?各PVにはUUIDがあり、VGとLVも同様であることがわかります。 LVMが各PV、ボリュームグループ、および論理ボリュームを再構築し、すべて同じデータを含むようにするために必要なこれは重要な情報ですか?つまり、新しいLUNidディスクの1つの/dev/mapper/mpath24のPVはそのディスクのUUIDによって識別されるため、同じデータになります。

これはうまくいくでしょうか?再起動とマルチパスがパスとデバイスを検索して列挙した後(そして/etc/multipath/boundsを更新)、LVMが起動し、自動的にディスクを要求し、デフォルトで機能します。それでは、以前のようにファイルシステムをマウントできますか?

そうでない場合、どのような措置を講じるべきですか? pv/vg/lvスキャンを実行する必要がありますか?マルチパスの起動時に何が起こり、LVMが起動したときに何が起こるのかを理解するのが役立ちます。

最後に、再起動を避けることは可能ですか、それともプロセスの秩序のためにそれを行うのが最も安全ですか?再起動せずにこれを行うことができる場合は、ファイルシステムをアンマウントして新しいLUNidを接続してからどのような手順を実行する必要がありますか?再起動プロセスと同じタスクを実行する一連のマルチパスおよび後続のLVMコマンドはありますか?どちらの場合も追加の措置を講じる必要がありますか?

ありがとうございます。

答え1

はっきりすると、lvmでミラーを作成してから分離する予定ですか?それともアレイ間でデータがコピーされましたか?

データがあるアレイから別のアレイにコピーされているかどうか。プロセスは簡単です。同期されたとき。 IOを停止し、VGをエクスポートします。現在のディスクホストの可視性を削除します。コピーを停止します。コピーを分割します。このオプションを使用すると、プロセスが正しく完了していない場合に戻ることができます。

ホストに新しいディスクを提供します。これは新しいUUIDを持ちます。 LUN/ボリュームのUUIDは、対応するLUN/ボリュームが存在するアレイによって異なります。新しい運転室からVGを入手してください。

これで終わりました。

もちろん、ホスト上の新しいディスクはマルチパスを事前に正しく設定する必要があります。

とにかく、本番データでこれを行う前に。テストテストは、非常に少ないテストデータを使用してソースからターゲットまでの全体的な方法をテストします。

LVMを使用してすべてのタスクを実行するにはどうすればよいですか?

これは広範でおそらくあまり具体的ではない質問です。

結論として。 LVMを事前に知らなければ、これは難しい作業です。

手順は次のとおりです。 1.- 所有者に新しい部屋を表示します。 1.aアレイ製造元(HP、DELL、IBM ...)は、そのアレイモデルの特定の構成を含むmultipath.confを提供しています。検索と申請

1.b これにより、新しいディスクがホストに表示されます。

mpathXはオプションの1つです。おそらく最高ではないでしょう。

1.c multipath.confでディスク名を定義できます。

  1. 新しいディスクをスキャンします。

3.- ディスクフォーマット

3.a製造元が特別な位置合わせを必要とすることを確認します。ディスク全体またはパーティションのPVの場合は通常異なります。

4.- 物理ボリュームの作成

5.- ここにはいくつかのオプションがあります。

5.a VGにディスクを追加し、各アレイの各ボリュームのミラーを作成します。

5.a1 stop service.

5.a2 Separate the mirrors of each array --split-mirrors
5.a3 export old disks

完了すると、各アレイに1つの完全なコピーがあります。

サービスを開始します。

LVMに関する事前の知識なしに本番データを使用してこれを行います。非常に危険かもしれません

テスト 新しい小さなVGと複数のボリュームを作成し、ファイルシステムにデータを追加できます。新しいスタンドに十分なサイズのディスクを追加します。完全な作業を見るには、同じVGとミラーと--split-mirrorに配置してください。

試験結果

答え2

ファイルシステムを新しいアレイに移動するプロセスが完了しました。以下はステップです。

アレイファイルシステムが停止した後にマウント解除されます。
ファイルシステムが/ etc / fstabから削除されたため、起動時にマウントされません。データのアレイレベルのコピーを新しいストレージアレイにコピーします。 LUNは古いアレイから切断され、新しいアレイに接続されます。ホストが再起動されました。 "multipath -ll"コマンドを使用すると、新しいLUNが接続され、scsiデバイス(/ dev / sd *)へのパスも明確であることを確認できます(4つのパスはデュアルポートHBAペアに対応します)。 LVMの使用:「pvs」は、物理デバイスを期待どおりに表示します。ただし、「vgs」にはボリュームグループは表示されません。
「vgscan」を実行すると、すべてのボリュームグループが表示されるため、「vgs」も表示されます。ただし、ファイルシステムのマウントが失敗し、/dev/mapper/vg_name/lv_name パスに「該当するファイルまたはディレクトリはありません」と報告されます。 / devのこのパスにはボリュームグループ名は表示されません。 「vgchange -ay」を実行してボリュームグループを「アクティブ化」すると、パスが/ devに表示されます。その後、ファイルシステムをマウントするだけです。
データが存在し、正しいことを確認してください。ファイルシステムを含むように/ etc / fstabを復元します。すべてがスムーズに行われていることを確認するために、テストの再起動が行われました。十分。

LVMがディスクの先頭にUUIDを含むヘッダーを書き込むことを知っておくと便利です。これは、デフォルトのストレージパスとデバイスが変更されたときにディスクを識別し、それを正しいLVMオブジェクト(pv、vg、lv)に保持するメカニズムです。

最後に、「vgs」の代わりに「vgdisplay」を使用すると、最初に「vgs」でボリュームグループ情報が不足し、/ devにパスが表示されないときに診断が簡単になります。 「vgdisplay」はボリュームグループの状態を表示し、その段階で役立つ手がかりを提供します。

新しいLUN接続からマシンブートまで、プロセス全体は約15分かかり、ボリュームグループの状態がすぐに診断されるとはるかに高速になります。

準備中に、すべての関連ファイルとデータのバックアップコピーが別々に作成され保存されていることを確認してください(/etc/fstab、/etc/lvm/、/etc/multipath.conf /etc/multipathd/bindingsなど)。また、pvdisplay、vgdisplay、lvdisplay、multipath -ll、fdisk -lなどから出力をキャプチャしました(各ファイルシステムでいくつかのサンプルデータの生成されたハッシュもチェックとして使用されましたが、実際には使用されません)。また、変更プロセス全体でコンソールにアクセスでき、セッションがアクティブであることを確認しました。

関連情報