あらゆるビジネスにとってデータ/情報が長年にわたって不可欠であった現代の世界では、エンタープライズストレージシステム間でデータを自由に移動する能力がこれまで以上に重要になっています。 シンプルで柔軟なデータ移動の必要性は、次のようなさまざまなタスクによって決定できます。
- より生産的なディスクアレイの容量使用率の最適化。 そのため、SSDドライブの高価な容量を他のタスクのために解放するために、非常に高い処理速度が不要になったデータをオールフラッシュアレイからハードディスクのあるアレイに移動する必要があります。
- アレイのディスクおよびコンピューティングリソースの使用効率を高める：1つのアレイに十分なリソース（容量またはパフォーマンス）がなく、別のアレイ（近くまたは隣接する建物にある）にそのようなリソースが過剰である場合、1つのアレイからデータの一部を移動するアレイを別のアレイにすると、この問題が解決します。アレイのアップグレードにお金をかける必要はありません。 つまり、ここでは実際には複数のアレイ間で負荷を分散することについてです。
- 古いアレイを廃止し、このアレイから新しいアレイにデータを移動します。
そしてもちろん、ここで重要なことは、このプロセスの単純さ、データを任意の方向に移動する能力、ビジネスプロセスを停止せずにデータを移動する能力（つまり、サーバーとアプリケーションに対して透過的）ほどデータを移動する能力ではありません。 特別なハードウェアやソフトウェアに追加コストをかけずに、これらすべてを実現できることも重要です。
HPE 3PAR Storage Federationでは、上記のすべてを実装することができます。 HPE 3PAR Storage Federationを使用すると、複数のHPE 3PAR StoreServアレイを単一の論理システムに結合して、システム全体のディスク使用率を高め、さまざまなシステムコンポーネント間の負荷分散を行うことができます。 データ転送は、マウスを1回クリックするだけで実行されます。 さらに、他のアレイ（つまり、HPE 3PAR StoreServファミリーに属していないアレイ）も一般システムに含めることができますが、1つの例外があります：この場合のデータ転送は、一方向からのみ可能です-アレイからStoreServアレイへ非StoreServ。
次に、ディスクアレイフェデレーションの仕組みと、その構成に必要なものについて簡単に説明します。
トポロジー
現在、最大4つのHPE 3PAR StoreServアレイをフェデレーションに結合できます。これらは、7400、8450、20800など、現代および前世代のさまざまなモデルになります。マイクロコードは少なくとも3.2.2 MU1でなければなりません。 フェデレーションに含まれるアレイ（以下、このようなアレイを「フェデレーテッド」と呼びます）に、一方向の移行を行う必要がある他のアレイを接続することもできます（このようなアレイは「移行ソース」と呼ばれます）。 一方向の移行は、HPE 3PAR StoreServアレイと他のHPEアレイの両方からサポートされます：EVA / P6000およびP9500 / XP10000 / XP12000 / XP20000 / XP24000、およびサードパーティのアレイから：EMC CX4 / VNX / vMAX、HDS USP / USP -V / USP-VM / VSP、IBM XiV。 そのような移行ソースは最大6つ存在できますが、アレイ、フェデレーション、および移行ソースの合計数は8を超えることはできません。可能な構成の2つのオプションを以下に示します。 これらの図の矢印は、データ移行の可能な方向を示しています。
図1 2つのフェデレーテッドアレイと6つの移行ソース
図2。 4つのフェデレーテッドアレイと4つの移行ソース
このブログの後半では、フェデレーションアレイについてのみ説明します。 以降の出版物では、他のアレイからHPE 3PAR StoreServアレイへのデータ移行について説明します。
ポートとゾーン
フェデレーテッドアレイでは、データをこのアレイに移行するために使用する2つのFCポートを割り当てる必要があります。このようなポートはpeerと呼ばれます。 別の/他のアレイへの移行に使用されるポートは、 ホストポートと呼ばれます。 ホストポートは、専用または非専用のいずれかです。 フェデレーテッドアレイのピアポートとホストポートをゾーンに結合する必要があります。この場合、すべてのポートで2つのゾーンしか使用できない簡易ゾーニングスキームを使用できます（下の図3を参照）。各アレイのホストポート。
図 3.統合ディスクアレイのゾーニングスキーム。
移行オプション
3つの移行オプションがサポートされています。
- サーバーOSおよびマルチパスソフトウェアがボリュームアクセスパスのオンライン追加をサポートしている場合、 オンライン移行が可能です。 オンライン移行中、サーバーはそのボリュームへのアクセスを失うことはなく、サーバーからの入出力要求の配列による処理は中断されません。
オンライン移行には2つのオプションがあります。
-サーバーレベルでの移行-この場合、特定のサーバー（またはサーバーのグループ）にエクスポートされたすべてのボリュームが同時に移行されます。
-ボリュームレベル（ボリュームグループ）での移行-この場合、特定のサーバー（またはサーバーグループ）にエクスポートされたボリュームの一部のみが同時に移行されます。 この場合、残りのサーバーボリュームは引き続きアレイによって提供されます。 複数のアレイ間で入力/出力の負荷を再分配できるのはこの移行オプションで、サーバーはすべてのボリュームに同時にアクセスできます：すでに別のアレイに移行されているボリューム、移行中のボリューム、およびそうでないボリューム移行しました。
- 中断の少ない移行 オンライン移行のオプションが不可能な場合、最小限のダウンタイムで移行を実行できます。 ダウンタイムは、サーバーの再構成に必要な時間によって決まります。そのため、ソースアレイではなくターゲットアレイが認識されます。 移行中、すべてのデータがサーバーで利用可能になります。 この移行オプションは、サーバーレベルでのみ可能です（上記を参照）。
- オフライン移行 。 この移行オプションは、提示されていないボリュームを移行する場合に使用されます。
移行移住者の能力は、データを移動する必要があるサーバーのオペレーティングシステムによって異なります。 たとえば、Windows Server 2008/2012、RedHat Enterprise 5/6/7、SuSE Enterprise 10/11/12、VmWARE 5.x / 6.0などのOSではオンライン移行が可能です。
移行プロセス
Storage Federationの初期セットアップは、SSMC（StoreServ管理コンソール）グラフィカル管理コンソールから実行されるいくつかの簡単なステップに要約されます。
- フェデレーションで結合する配列を選択します。
- これらのアレイにピアポートとホストポートを割り当て、それらをゾーンに含めます（スイッチ上のゾーンは事前に作成する必要があります）
ボリュームレベル（ボリュームグループ）での移行とホストレベルでの移行（ホストに提供されるすべてのボリュームが移行される場合）は、わずかに異なる方法で実装されます。 実際、ボリュームレベルでの移行中、ソースアレイは、移行していないホストの他のすべてのボリュームのサービスを継続する必要があります。 ボリュームレベルの移行では、ホストがSCSI ALUAマルチパスプロトコルをサポートする必要があります。
ボリュームレベルでの移行プロセスは次のとおりです。
- 移行するボリュームのグループを選択します。 さらに、各ソースボリュームはターゲットアレイに自動的にエクスポート（提示）され、ターゲットアレイはこれらのボリュームをホストに自動的にエクスポートします。 （ターゲットアレイ上の）コピーボリュームは、対応するソースボリュームとまったく同じWWNを持ちます。
- その結果、ホストは各ボリュームの新しいアクセスパスを確認し、アレイからのこれらの新しいパスのステータス（レポートターゲットポートグループ（RTPG）SCSIコマンド経由）を要求します。 その結果、ホストは、2つのグループのパス（ターゲットポートグループ）で各ボリュームを見ることになります。最初のグループ-ソースアレイのポートを経由し、2番目のグループ-ターゲットアレイのポートを経由します。 この場合、最初のグループはアクティブな最適化モードになり、2番目のグループはスタンバイモードになります。
- その後、移行プロセスが開始され、最初にTPGモードが変更されます。最初のグループのパスはスタンバイモードになり、2番目のグループはアクティブな最適化モードになります（図4を参照）。 その後、すべてのI / O要求はターゲット配列に送られます。 ソースボリュームからコピーボリュームへのデータのコピーが開始されます。もちろん、コピーはホストの関与なしに2つのアレイ間で直接実行されます。
- 移行プロセス中に、新しいデータがコピーボリュームに書き込まれますが、新しいデータはターゲットアレイによって元のボリュームにコピーされます（データが失われないように突然何かがうまくいかない場合）。 この場合、要求されたブロックが既に移行されている場合、読み取りはローカルで（つまり、コピーボリュームから）実行されます。 要求されたブロックがまだ移行されていない場合、「順番がずれて」移行されます。 移行プロセス中に生産性がいくらか低下することは当然のことです。
- ボリューム（ボリュームグループ）の移行が完了すると、ターゲットアレイに永続的に配置されます。 選択した移行設定に応じて、移行が成功した後、またはソースアレイにソースボリュームを残したまま、ソースボリュームを自動的に削除できます。 ソースボリュームが自動的に削除されないように設定されている場合、移行の完了後にボリュームはミラーリングされません。 移行プロセス中および移行の完了後、移行に関係しなかったソースアレイ上のボリュームは、制限/変更なしでホストにアクセスできます。
図 4.データ移行中の移行済みボリューム（Vol-B）へのアクセスパスのステータス。
結論として、災害に強いソリューションと高可用性ソリューションが使用されている場合、フェデレーションも使用できることを付け加えます。 つまり、サーバークラスターが動作しているボリュームを移行できます。 HPE StoreServアレイ間のレプリケーションに参加するボリュームは移行できます（この場合、レプリケーションペアの1つのアレイのボリュームは3番目のアレイに移行します-これらのボリュームのレプリケーションを維持しながら、ソースボリュームまたはターゲットボリュームのいずれかを移行できます）。 はい。また、移行中に一貫性グループがサポートされていることも追加する必要があります。アプリケーションが複数のボリュームで動作する場合、そのようなボリュームは一貫したボリュームグループとして移行する必要があります。 整合性のあるグループとは、整合性のあるグループのすべてのボリュームがターゲットアレイに移行されるまで、ターゲットアレイとソースアレイ間のボリュームのミラーリングが続行されることを意味します。
ライセンス
ストレージフェデレーションのライセンスは、ストレージフェデレーションとはまったく呼ばれませんが、Peer Motionです。 フェデレーションに含まれるすべてのアレイのライセンスを取得する必要があります-双方向移行の可能性が必要な場合。 一方向の移行のみが必要な場合は、ターゲットアレイのみにライセンスを付与できます。
したがって、複数のHPE StoreServアレイの管理者であれば、すぐにストレージフェデレーションをすぐに活用できます。 言う-すぐに活用する-トライアル（トライアル）ライセンスを使用して、ストレージフェデレーションの機能を評価できることを意味します。
配列をフェデレーションに結合します、それは価値があります！