(57)【要約】様々な開示の実施形態によるシステムおよび方法によって、ミラーリング仮想ターゲットを管理して仮想ターゲットのメンバを同期化することや、仮想ターゲットのメンバが同期化されたか検証することが可能である。一実施形態では、ミラーリング仮想ターゲットはまず、ミラーリング・ターゲットの１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニット（ＩＶＬＵ）と、ミラーリング・ターゲットのソース・ターゲットに対応する第２のＩＶＬＵとを提供する工程によって、同期化される。１つ以上の内部仮想論理ユニットにより、ミラーリング・ターゲットの複数の宛先ターゲット・メンバの各々に、まず書込コマンドが発行される。転送準備完了信号が返送されることによって、各宛先ターゲットがデータを受信するのに使用可能であることが明らかとなったとき、第２の内部仮想論理ユニットによってソース・ターゲットに読出コマンドが供給される。このようにして、ソース・ターゲットからデータを読み出す前に、ソース・ターゲットと宛先ターゲットとの間のデータ・パスが確立される。したがって、データがソース・ターゲットから読み出され、書込データへ変換され、データのバッファリングを伴わずに回線速度で宛先ターゲットへ経路指定される。仮想ターゲットのメンバが同期化されたか検証するために、同様の処理が提供される。一実施形態では、ミラーリング・ターゲットの同期化または同期化の検証中に、ミラーリング・ターゲットの入力コマンドを管理するシステムおよび方法が提供される。入力コマンドは待ち行列に入れられ、保留状態の同期化コマンドまたは検証コマンドが完了したときに、ミラーリング・ターゲットへ供給され受信される。
2007535763.tif 000002
【特許請求の範囲】
【請求項１】
ミラーリング・ターゲットを管理する方法であって、
１つ以上の宛先ターゲットに関するデータ受信の使用可能性を判定する使用可能性判定工程と、
同１つ以上の宛先ターゲットがデータを受信するのに使用可能であると判定されたときにだけ、ソース・ターゲットに読出コマンドを供給する読出コマンド供給工程と、からなる方法。
【請求項２】
使用可能性判定工程は、
前記１つ以上の宛先ターゲットに第１のコマンドを供給する工程と、
前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定する工程と、を含む請求項１に記載の方法。
【請求項３】
第１のコマンドは書込コマンドおよび検証コマンドのうちの１つ以上である請求項２に記載の方法。
【請求項４】
前記１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニットと、前記ソース・ターゲットに対応する第２の内部仮想論理ユニットとを提供する工程を含む請求項１に記載の方法。
【請求項５】
第１の内部仮想論理ユニットを提供する工程は第１の宛先ターゲットに対応する第１の内部仮想論理ユニットを提供する工程を含むことと、
第２の宛先ターゲットに対応する第３の内部仮想論理ユニットを提供する工程と、を含む請求項４に記載の方法。
【請求項６】
第１の内部仮想論理ユニットを提供する工程は第１の内部仮想論理ユニットにおける第１の宛先ターゲットに対応する第１のメンバと、第２の宛先ターゲットに対応する第２のメンバとを提供する工程を含む請求項４に記載の方法。
【請求項７】
使用可能性判定工程は、
第１の内部仮想論理ユニットに関連する処理ユニットに第１のコマンドを供給する工程と、
第１の内部仮想論理ユニットに関して提供された情報から前記１つ以上の宛先ターゲットの位置を判定する工程と、
同処理ユニットから前記１つ以上の宛先ターゲットに第１のコマンドを供給する工程と、
前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定する工程と、を含む請求項４に記載の方法。
【請求項８】
前記処理ユニットは第１の処理ユニットであることと、
第２の処理ユニットは第１の処理ユニットに第１のコマンドを供給し、前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定することと、を含む請求項７に記載の方法。
【請求項９】
読出コマンド供給工程は、
前記１つ以上のターゲットが転送準備完了信号を返送したときに、第２の処理ユニットから第２の内部仮想論理ユニットに読出コマンドを供給する工程と、
第２の内部仮想論理ユニットに関して提供された情報を使用して、第１の処理ユニットから前記ソース・ターゲットに読出コマンドを経路指定する工程と、を含む請求項８に記
載の方法。
【請求項１０】
第１のコマンドは書込コマンドであることと、
前記ソース・ターゲットから読出データを受信する工程と、
読出データを書込データに変換する工程と、
書込データを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項９に記載の方法。
【請求項１１】
読出データを書込データに変換する工程は、
第１の処理ユニットの出口部分において読出データを受信する工程と、
第１の処理ユニットの出口部分において読出データを書込データに変換する工程と、
出口部分から第１の処理ユニットの入口部分に書込データを経路指定する工程と、
入口部分から前記１つ以上の宛先ターゲットに書込データを経路指定する工程と、を含む請求項１０に記載の方法。
【請求項１２】
読出データは１つ以上の読出データ・パケットであることと、
第１の処理ユニットの出口部分において読出データを書込データに変換する工程は、同１つ以上の読出データ・パケットが１つ以上の書込データ・パケットであることが示されるように、同１つ以上の読出データ・パケットのヘッダ情報を更新する工程を含むことと、を含む請求項１１に記載の方法。
【請求項１３】
第１のコマンドは検証コマンドであることと、
ソース・ターゲットから読出データを受信する工程と、
読出データを検証データに変換する工程と、
検証データを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項９に記載の方法。
【請求項１４】
読出データを検証データに変換する工程は、
第１の処理ユニットの出口部分において読出データを受信する工程と、
第１の処理ユニットの出口部分において読出データを検証データに変換する工程と、
出口部分から第１の処理ユニットの入口部分に検証データを経路指定する工程と、
入口部分から前記１つ以上の宛先ターゲットに検証データを経路指定する工程と、を含む請求項１３に記載の方法。
【請求項１５】
読出データは１つ以上の読出データ・パケットであることと、
第１の処理ユニットの出口部分において読出データを検証データに変換する工程は、同１つ以上の読出データ・パケットが１つ以上の検証データ・パケットであることが示されるように、同１つ以上の読出データ・パケットのヘッダ情報を更新する工程を含むことと、を含む請求項１４に記載の方法。
【請求項１６】
処理ユニットは第１の処理ユニットであることと、
前記１つ以上の宛先ターゲットに第１のコマンドを供給する工程は、前記１つ以上の宛先ターゲットと通信状態にある第２の処理ユニットに書込コマンドを供給する工程を含むことと、を含む請求項７に記載の方法。
【請求項１７】
前記ミラーリング・ターゲットに対する同期化コマンドまたは検証コマンドが保留状態にあるときに、前記ミラーリング・ターゲットに関してイニシエータから供給されたコマンドを受信するコマンド受信工程と、
同イニシエータから供給されたコマンドを待ち行列に入れるコマンド投入工程と、
同期化コマンドまたは検証コマンドが完了したときに、同イニシエータから供給された
コマンドを待ち行列から取り出し、前記ミラーリング・ターゲットに供給するコマンド取出工程と、を含む請求項１に記載の方法。
【請求項１８】
コマンド受信工程、コマンド投入工程およびコマンド取出工程は、前記イニシエータが前記ミラーリング・ターゲットのサービス損失を経験することなく実施される、請求項１７に記載の方法。
【請求項１９】
読出データを書込データに変換する工程は回線速度で実施される請求項１０に記載の方法。
【請求項２０】
読出データを書込データに変換する工程は読み出された読出データまたは書込データのバッファリングを伴わずに行われる請求項１０に記載の方法。
【請求項２１】
読出データを検証データに変換する工程は回線速度で実施される請求項１３に記載の方法。
【請求項２２】
読出データを検証データに変換する工程は読み出された読出データまたは書込データのバッファリングを伴わずに行われる請求項１３に記載の方法。
【請求項２３】
１つ以上の宛先ターゲットと、ソース・ターゲットとを含むミラーリング・ターゲットを管理する装置であって、
同１つ以上の宛先ターゲットおよび同ソース・ターゲットと通信状態にある１つ以上のポートと、
同１つ以上のポートと通信状態にあり、同１つ以上の宛先ターゲットがデータを受信するのに使用可能な状態にあるときにだけ、同ソース・ターゲットに読出コマンドを供給する１つ以上の処理ユニットと、からなる装置。
【請求項２４】
前記１つ以上の処理ユニットは、前記１つ以上の宛先ターゲットに第１のコマンドを供給し、前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定することにより、前記１つ以上の宛先ターゲットがデータを受信するのに使用可能な状態にあるか否かを判定する、請求項２３に記載の装置。
【請求項２５】
前記コマンドは書込コマンドおよび検証コマンドのうちの１つ以上である請求項２４に記載の装置。
【請求項２６】
前記１つ以上の処理ユニットと通信状態にあり、前記１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニットと、前記ソース・ターゲットに対応する第２の内部仮想論理ユニットとを含むメモリ、を含む請求項２３に記載の装置。
【請求項２７】
第１の内部仮想論理ユニットは第１の宛先ターゲットに対応することと、
メモリは第２の宛先ターゲットに対応する第３の内部仮想論理ユニットを含むことと、を含む請求項２６に記載の装置。
【請求項２８】
第１の内部仮想論理ユニットは第１の宛先ターゲットに対応する第１のメンバと、第２の宛先ターゲットに対応する第２のメンバとを含む請求項２６に記載の装置。
【請求項２９】
前記１つ以上の処理ユニットは、第１および第２の内部仮想論理ユニットと関連付けられる第１の処理ユニットと、第２の処理ユニットとを含む請求項２６に記載の装置。
【請求項３０】
第２の処理ユニットは第１の内部仮想論理ユニットに対する第１のコマンドを第１の処
理ユニットに供給することと、
第１の処理ユニットは第１の内部仮想論理ユニットに関して供給されたメモリ内の情報から前記１つ以上の宛先ターゲットの位置を判定することと、
第１の処理ユニットは同位置を判定した後に、前記１つ以上の宛先ターゲットに第１のコマンドを供給することと、
第２の処理ユニットは前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定することと、を含む請求項２９に記載の装置。
【請求項３１】
第２の処理ユニットは前記１つ以上の宛先ターゲットが転送準備完了信号を返送したときに、第２の内部仮想論理ユニットに対する読出コマンドを第１の処理ユニットに供給することと、
第１の処理ユニットは第２の内部仮想論理ユニットに関して提供された情報を使用して、読出コマンドをソース・ターゲットへ経路指定することと、を含む請求項３０に記載の装置。
【請求項３２】
前記情報は前記宛先ターゲットが結合されるラインカードおよびポートである請求項３１に記載の装置。
【請求項３３】
第１のコマンドは書込コマンドであることと、
第１の処理ユニットは読出コマンドを供給した後に前記ソース・ターゲットから読出データを受信し、読出データを書込データに変換し、書込データを前記１つ以上の宛先ターゲットに供給することと、を含む請求項３１に記載の装置。
【請求項３４】
第１の処理ユニットは入口部分および出口部分を含み、出口部分において読出データを受信し、読出データを書込データに変換することと、書込データは出口部分から入口部分へ経路指定され、入口部分から前記１つ以上の宛先ターゲットへ経路指定されることと、を含む請求項３３に記載の装置。
【請求項３５】
読出データは１つ以上の読出データ・パケットであることと、
第１の処理ユニットは同１つ以上の読出データ・パケットが１つ以上の書込データ・パケットであることが示されるように、同１つ以上の読出データ・パケットのヘッダ情報を更新することによって、読出データを書込データに変換することと、を含む請求項３４に記載の装置。
【請求項３６】
第１のコマンドは検証コマンドであることと、
第１の処理ユニットは読出コマンドを供給した後に前記ソース・ターゲットから読出データを受信し、読出データを検証データに変換し、検証データを前記１つ以上の宛先ターゲットに供給することと、を含む請求項３１に記載の装置。
【請求項３７】
第１の処理ユニットは入口部分および出口部分を含み、出口部分において読出データを受信し、読出データを検証データに変換することと、検証データは出口部分から入口部分へ経路指定され、入口部分から前記１つ以上の宛先ターゲットへ経路指定されることと、を含む請求項３６に記載の装置。
【請求項３８】
読出データは１つ以上の読出データ・パケットであることと、
第１の処理ユニットは同１つ以上の読出データ・パケットが１つ以上の検証データ・パケットであることが示されるように、同１つ以上の読出データ・パケットのヘッダ情報を更新することによって、読出データを検証データに変換することと、を含む請求項３７に記載の装置。
【請求項３９】
第１の処理ユニットは前記１つ以上の宛先ターゲットと通信状態にある第３の処理ユニットに第１のコマンドを供給することによって、前記１つ以上の宛先ターゲットに第１のコマンドを供給することと、第３の処理ユニットは第１のコマンドを前記１つ以上の宛先ターゲットへ経路指定することと、を含む請求項３０に記載の装置。
【請求項４０】
第１の処理ユニットは読出データを書込データに回線速度で変換することが可能である請求項３３に記載の装置。
【請求項４１】
第１の処理ユニットは読出データまたは書込データのバッファリングを伴うことなく読出データを書込データに変換することが可能である請求項３３に記載の装置。
【請求項４２】
第１の処理ユニットは読出データを検証データに回線速度で変換することが可能である請求項３６に記載の装置。
【請求項４３】
第１の処理ユニットは読出データまたは検証データのバッファリングを伴うことなく読出データを検証データに変換することが可能である請求項３６に記載の装置。
【請求項４４】
第１の処理ユニットは前記１つ以上の宛先ターゲットと通信状態にある請求項２９に記載の装置。
【請求項４５】
第１の処理ユニットは前記ソース・ターゲットと通信状態にある請求項２９に記載の装置。
【請求項４６】
第１の処理ユニットは前記１つ以上の宛先ターゲットとまたは前記ソース・ターゲットと通信状態にあるポート用の処理ユニットではない請求項２９に記載の装置。
【請求項４７】
メモリと、前記１つ以上の処理ユニットは前記ミラーリング・ターゲットに関する同期化コマンドまたは検証コマンドを前記装置が処理している間は、前記ミラーリング・ターゲットに対する入力コマンドを同メモリ内の待ち行列に入れ、同期化コマンドまたは検証コマンドが完了したときは、入力コマンドを待ち行列から取り出し、前記ミラーリング・ターゲットに供給することと、を含む請求項２３に記載の装置。
【請求項４８】
入力コマンドは１つ以上のイニシエータから受信されることと、
前記１つ以上の処理ユニットは入力コマンドを待ち行列に入れ、前記装置から同１つ以上のイニシエータに故障応答が供給されることがないことと、を含む請求項４７に記載の装置。
【請求項４９】
故障応答はビジー応答と、タスク・セット・フル応答とを含む請求項４８に記載の装置。
【請求項５０】
前記１つ以上の処理ユニットは、前記ミラーリング・ターゲットのサービス損失を経験することなく、入力コマンドを待ち行列に入れ、待ち行列から取り出し、供給することを含む請求項４８に記載の装置。
【請求項５１】
前記ミラーリング・ターゲットはミラーリング仮想論理ユニットである請求項２３に記載の装置。
【請求項５２】
ミラーリング・ターゲットを管理する方法であって、
同ミラーリング・ターゲットの１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニット（ＩＶＬＵ）と、同ミラーリング・ターゲットのソース・ターゲットに対応す
る第２のＩＶＬＵとを提供するＩＶＬＵ提供工程と、
同１つ以上の宛先ターゲットに対する第１のコマンドを第１のＩＶＬＵに供給する第１コマンド供給工程と、
第１のコマンドを同１つ以上の宛先ターゲットへ経路指定する第１コマンド経路指定工程と、
同ソース・ターゲットから転送準備完了信号が受信されたときに、同ソース・ターゲットに対する読出コマンドを第２のＩＶＬＵに供給する読出コマンド供給工程と、からなる方法。
【請求項５３】
第１のＩＶＬＵは第１の宛先ターゲットに対応することと、
ＩＶＬＵ提供工程は第２の宛先ターゲットに対応する第３のＩＶＬＵを提供する工程を含むことと、を含む請求項５２に記載の方法。
【請求項５４】
ＩＶＬＵ提供工程は第１の処理ユニットにおいて第１および第２のＩＶＬＵを提供する工程を含む請求項５２に記載の方法。
【請求項５５】
第１コマンド供給工程は内部イニシエータから第１の処理ユニットに第１のコマンドを供給する工程を含むことと、
読出コマンド供給工程は内部イニシエータから第１の処理ユニットに読出コマンドを供給する工程を含むことと、を含む請求項５４に記載の方法。
【請求項５６】
前記内部イニシエータは中央処理装置であることと、
第１の処理ユニットはパケット処理ユニットであることと、を含む請求項５５に記載の方法。
【請求項５７】
前記中央処理装置はコピー・サービス・マネージャおよび検証サービス・マネージャのうちの１つ以上を含む請求項５６に記載の方法。
【請求項５８】
第１のコマンドは書込コマンドであることと、
読出コマンドに応答して前記ソース・ターゲットから読出データを受信する工程と、
第１の処理ユニットにおいて読出データを書込データに変換する工程と、
書込データを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項５６に記載の方法。
【請求項５９】
第１の処理ユニットにおいて読出データを書込データに変換する工程は前記中央処理装置を必要としない請求項５８に記載の方法。
【請求項６０】
第１の処理ユニットにおいて読出データを書込データに変換する工程は読出データまたは書込データのバッファリングを伴うことなく回線速度で実施される請求項５８に記載の方法。
【請求項６１】
第１のコマンドは検証コマンドであることと、
読出コマンドに応答して前記ソース・ターゲットから読出データを受信する工程と、
第１の処理ユニットにおいて読出データを検証データに変換する工程と、
検証データを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項５６に記載の方法。
【請求項６２】
第１の処理ユニットにおいて読出データを検証データに変換する工程は前記中央処理装置を必要としない請求項６１に記載の方法。
【請求項６３】
第１の処理ユニットにおいて読出データを検証データに変換する工程は読出データまたは検証データのバッファリングを伴うことなく回線速度で実施される請求項６２に記載の方法。
【請求項６４】
ミラーリング・ターゲットを管理する装置であって、
第１の処理ユニットと、
第１の処理ユニットと通信状態にあり、ミラーリング・ターゲットを同期化しているときまたはその同期化を検証しているときに、少なくとも、ミラーリング・ターゲットの１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニット（ＩＶＬＵ）と、ミラーリング・ターゲットのソース・ターゲットに対応する第２のＩＶＬＵとを維持するメモリと、
同１つ以上の宛先ターゲットに対する第１のコマンドを第１のＩＶＬＵに供給し、ソース・ターゲットから転送準備完了信号が受信されたときに、ソース・ターゲットに対する読出コマンドを第２のＩＶＬＵに供給する内部イニシエータと、からなる装置。
【請求項６５】
内部イニシエータは第１の処理ユニットに第１のコマンドを供給することによって、前記１つ以上の宛先ターゲットに対する第１のコマンドを第１のＩＶＬＵに供給することと、
第１の処理ユニットはメモリ内に維持されている第１のＩＶＬＵに関する情報を使用して、第１のコマンドを前記１つ以上の宛先ターゲットへ経路指定することと、を含む請求項６４に記載の装置。
【請求項６６】
第１のコマンドは書込コマンドであることと、
第１の処理ユニットは読出コマンドがソース・ターゲットに供給された後に、ソース・ターゲットから読出データを受信し、読出データを書込データに変換し、書込データを前記１つ以上の宛先ターゲットへ経路指定することと、を含む請求項６４に記載の装置。
【請求項６７】
読出データおよび書込データは内部イニシエータによって受信されない請求項６６に記載の装置。
【請求項６８】
第１のコマンドは検証コマンドであることと、
第１の処理ユニットは読出コマンドがソース・ターゲットに供給された後に、ソース・ターゲットから読出データを受信し、読出データを検証データに変換し、検証データを前記１つ以上の宛先ターゲットへ経路指定することと、を含む請求項６４に記載の装置。
【請求項６９】
読出データおよび検証データは内部イニシエータによって受信されない請求項６８に記載の装置。
【請求項７０】
内部イニシエータは中央処理装置である請求項６９に記載の装置。
【請求項７１】
１つ以上の宛先ターゲットに関するデータ受信の使用可能性を判定する工程と、
同１つ以上の宛先ターゲットがデータを受信するのに使用可能であると判定されたときにだけ、ソース・ターゲットに読出コマンドを供給する工程と、からなる方法を実施するように１つ以上のプロセッサをプログラムするプロセッサ読取可能なコードをそれ自体に実装した、１つ以上のプロセッサ読取可能な記憶デバイス。
【請求項７２】
前記方法は、
前記１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニットと、前記ソース・ターゲットに対応する第２の内部仮想論理ユニットとを提供する工程と、
前記ソース・ターゲットから読出データを受信する工程と、
読出データを書込データに変換する工程と、
書込データを前記１つ以上の宛先ターゲットに供給する工程と、
を含む、請求項７１に記載の１つ以上のプロセッサ読取可能な記憶デバイス。
【請求項７３】
読出データを書込データに変換する工程は読出データまたは書込データのバッファリングを伴うことなく回線速度で実施される、請求項７２に記載の１つ以上のプロセッサ読取可能な記憶デバイス。
【請求項７４】
前記方法は、
前記１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニットと、前記ソース・ターゲットに対応する第２の内部仮想論理ユニットとを提供する工程と、
前記ソース・ターゲットから読出データを受信する工程と、
読出データを検証データに変換する工程と、
書込データを前記１つ以上の宛先ターゲットに供給する工程と、
を含む、請求項７１に記載の１つ以上のプロセッサ読取可能な記憶デバイス。
【請求項７５】
読出データを検証データに変換する工程は読出データまたは検証データのバッファリングを伴うことなく回線速度で実施される、請求項７４に記載の１つ以上のプロセッサ読取可能な記憶デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はストレージ・エリア・ネットワークに関する。
【背景技術】
【０００２】
今日のデータ集中型産業および応用分野の環境では、情報管理のタスクが益々重荷となってきている。より詳細には、多くの企業および個人が、効果的かつ効率的に信頼性のある形で維持する必要があるデータの量が益々増えるという問題に直面すると同時に、生データの記憶域管理もより煩雑で困難なものとなってきている。各エンティティは引き続き、より多くの記憶域を追加し、より多くのユーザにサービスを提供し、より多数のユーザがより多くのデータにアクセスできるようにする必要に直面している。
【０００３】
益々高まるこうした需要を満たすべく、近年、ストレージ・エリア・ネットワークすなわちＳＡＮの概念が大衆性を獲得している。様々なＳＡＮの定義が存在するが、ＳＡＮは一般に、コンピュータ・システムと記憶要素との間および記憶要素間のデータ転送を主目的とするネットワークと見なすことができる。ＳＡＮは、（例えば、ＳＣＳＩ接続を用いて）サーバに直接接続される記憶デバイス、および例えば従来のイーサネット（登録商標）・インターフェースを使用してローカル・エリア・ネットワーク（ＬＡＮ）に直接追加される記憶デバイスを含めた、それ自体の直接的な接続先の相手方部品の多くと帯域幅制限が異なる、本質的に独立したネットワークを形成することが可能である。
【０００４】
ＳＡＮの環境では一般に、記憶デバイス（例えば、テープ・ドライブおよびＲＡＩＤアレイ）およびデータの記憶が可能な他のデバイスを含み得るターゲットと、サーバ、パーソナル・コンピューティング・デバイスその他、書込コマンドおよび要求の供給が可能なデバイスを含み得るイニシエータとが、様々なスイッチおよび機器のうちの一方又は両方を介して相互接続される。スイッチおよび機器への接続は通常、ファイバ・チャネル（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ）である。この構造を用いると、一般に、ＳＡＮ上の任意のイニシエータが任意のターゲットと通信すること、また反対にＳＡＮ上の任意のターゲットが任意のイニシエータと通信することが可能になる。この構造は、イニシエータからターゲットへの代替パスも提供する。言い換えれば、特定のイニシエータが低速でありまたは完全に使用不能である場合に、ＳＡＮ上の別のイニシエータがそのターゲットへのアクセスを提供することができる。ＳＡＮは、複数のコピーを使用可能としてデータをミラーリングすることによって、データの可用性に関するより高い信頼性を生み出すことを可能とする。より多くの記憶域が必要とされるときは、追加の記憶デバイスを特定のイニシエータに接続する必要なくＳＡＮに追加することができるだけでなく、新しいデバイスをストレージ・ネットワークに簡単に追加することができ、任意のポイントからそれらのデバイスにアクセスすることもできる。
【０００５】
ＳＡＮの中には、ＳＡＮ向けの記憶域管理を実施する機器を利用するものものある。典型的な一機器は、データを受信しそれ自体の内部に記憶し、次いでそのデータを該当する１つ（または複数）のターゲットに転送するために、例えば内部プロセッサを用いてそのデータを分析し、そのデータに作用する。かかる蓄積交換（ｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ）処理は、１つ（または複数）の記憶デバイスとのデータの読み書きに要する時間を含むデータ・アクセスを、低速化することができる。
【０００６】
機器が切換え処理を実施することもできるが、多数のイニシエータが存在し、多くの機器に含まれるポートの数が少ないことから、イニシエータを機器と接続するために、しば
しばスイッチが使用される。より最近のＳＡＮの実装形態では、機器が不要となりシステムから取り除くことが可能となるように、以前は機器によって実施されていたある種の機能はスイッチに引き継がれている。
【０００７】
ＳＡＮは、物理空間がユーザにとって未知の状態のまま、典型的にはスイッチおよび機器のうちの一方又は両方を介して特定のユーザに１つ以上の物理ターゲットの空間を割り振る仮想化機能を実施する。例えば、企業はＳＡＮを利用して、従業員がデータ記憶および検索のためにアクセスするデータ記憶域を提供することができる。例えば、エンジニアリング部門は、「エンジニアリング記憶空間」として割り振られた記憶域を有することができる。従業員は、外付けハード・ディスク・ドライブなどの物理記憶デバイスを見る場合またはそれらと対話する場合と同様に、仮想空間を見ることができそれらと対話することができる。しかしながら、上記の空間は、実際には複数の物理記憶デバイスに渡って分割される可能性があり、また、単一の記憶デバイス内であっても断片化される可能性がある。スイッチまたは機器は、仮想空間および１つ（または複数）のブロック番号を求める要求を受信し、それに従ってデータを送出するために、要求された仮想空間と物理的に相関する１つ（または複数）のデバイスおよびそれらのデバイスの一部分を判定することができる。
【０００８】
より最近のストレージ・エリア・ネットワーク・スイッチは、当初ＳＡＮで使用されていた機器では必要とされるようなデータのバッファリングを伴うことなく、イニシエータとターゲットとの間でデータを経路指定することが可能である。例えば、ストレージ・スイッチの中には、典型的なネットワーク・スイッチが通常発生させるものよりも長いレイテンシをデータ・パケットに発生させることなく、データ・パケットを経路指定できるものもある。イニシエータとターゲットとの間でバッファリングを伴わないデータ転送は、相互接続を行うスイッチによって信頼性のある形で効率的に処理される必要がある。ストレージ・スイッチの一例は、２００２年１月１８日に出願された「ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ  ＩＮ  Ａ  ＳＴＯＲＡＧＥ  ＳＹＳＴＥＭ」と題する同時係属中の米国特許出願第１０／０５１，３９６号で確認され得る。
【０００９】
例えば、ＳＡＮの１つの重要な特徴は、いわゆるミラーリングを通じてすなわちミラーリングされた仮想ターゲット（ミラーリング仮想ターゲット；ｍｉｒｒｏｒｅｄ  ｖｉｒｔｕａｌ  ｔａｒｇｅｔ）を使用して、複数のターゲット内または１つ以上のターゲットにおける複数の論理ユニットの内部に信頼性のある形で効率的にデータを記憶することができる能力である。ネットワークの中には、データ記憶域の信頼性向上のために、１つ以上の物理位置に複数のデータ・コピーを維持する記憶領域（または仮想ターゲット）を含むことができるものもある。したがって、かかるネットワーク内のスイッチは、例えば記憶領域へのデータの書込の要求に応答して、２つ以上の記憶デバイスにデータを経路指定することができる。
【００１０】
ミラーリング仮想ターゲットを確立するには、各ミラーリング仮想ターゲット・メンバのデータを同期化する必要がある。典型的には、一方のターゲットのデータが、ミラーリング仮想ターゲットを形成する他方のデバイスに書き込まれるソース・データとして指定される。バッファ型の諸実装形態では、データは、ソース・ターゲットから読み出され、バッファされ得、次いで他方のターゲットがそのデータを受信するのに使用可能であるときは、そのそれぞれに書き込まれ得る。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
一方、非バッファ型の一実装形態を実現するには、宛先ターゲットがそれを受信するのに使用可能な状態になるまで待つために、ソース・データがスイッチにおいて維持される
べきではない。したがって、スイッチ内でのバッファリングを伴わない場合にもソース・ターゲットから１つ以上の宛先ターゲットへのデータの転送が容易になるようにミラーリング仮想ターゲットを同期化するシステムおよび方法が、必要とされる。さらに、初期ミラー同期化（ｉｎｉｔｉａｌ  ｍｉｒｒｏｒ  ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）を実施し、ミラーリング仮想ターゲットに対するコマンドをイニシエータ側デバイス（ｉｎｉｔｉａｔｉｎｇ  ｄｅｖｉｃｅ）から受信している間に、ミラーリング仮想ターゲットの整合性および同期性を維持するシステムおよび方法が、必要とされる。
【課題を解決するための手段】
【００１２】
様々な実施形態によれば、ミラーリング仮想ターゲットを管理するシステムおよび方法が、提供される。一実施形態では、ストレージ・スイッチが、ミラーリング仮想ターゲットの初期ミラー同期化を実施して、仮想ターゲットのメンバ間のデータを同期化する。
【００１３】
一実施形態は、同期化対象のミラーリング・ターゲットの各メンバに対応する内部仮想ターゲット（ＩＶＴ）を提供することを含む。同期化されるデータのソース・ターゲットとして指定されるミラーリング・ターゲットのメンバ毎に、第１の内部仮想論理ユニット（ＩＶＬＵ）が確立され得る。ミラーリング・ターゲットの残りの各メンバまたは宛先ターゲット毎に、１つ以上の追加のＩＶＬＵが確立され得る。ＩＶＴが提供された後は、ＩＶＴおよびそれぞれのＩＶＬＵを介して各宛先ターゲット・メンバに書込コマンドが供給され得る。各宛先ターゲットが転送準備完了信号（ｔｒａｎｓｆｅｒ  ｒｅａｄｙ  ｓｉｇｎａｌ）を返送すると、それぞれのＩＶＬＵを介してソース・ターゲットに読出コマンドが供給され得る。各宛先ターゲットからの転送準備完了信号を待ってからソース・ターゲットに対して読出コマンドを発行することにより、一実施形態によるストレージ・スイッチは、同期化対象のデータを受信する前に内部データ・パスを確立することができる。したがって、データは、ソース・ターゲットから読み出され、書込データに変換され、ストレージ・スイッチ内でのバッファリングを伴うことなく各宛先ターゲットに回線速度で供給され得る。
【００１４】
一実施形態では、ＩＶＴは、第１の処理ユニットにおいて提供される。第２の処理ユニットは、ＩＶＴに読出コマンドおよび書込コマンドを供給することができるコピー・サービス・マネージャを含む。書込コマンドは、第１の処理ユニットにおいて受信され、ＩＶＴに関して提供された情報を使用して、該当する宛先ターゲット・メンバへ経路指定され得る。
【００１５】
一実施形態では、ストレージ・スイッチは、ミラー同期化検証を実施して、ミラーリング仮想ターゲットのメンバが同期化されていることを検証する。初期ミラー同期化と同様に、ＩＶＴが提供され、ＩＶＴを介して各宛先ターゲットに読出コマンドが供給され得る。各宛先ターゲットから転送準備完了信号が返送されると、ソース・ターゲットに読出コマンドが供給される。ソース・ターゲットから受信されたデータは、検証データに変換され、バッファリングを伴うことなく、検証のために宛先ターゲットに回線速度で供給され得る。
【００１６】
一実施形態では、ストレージ・スイッチは、ミラーリング仮想ターゲットが同期化または検証されている間に、ミラーリング仮想ターゲットに対する入力コマンドを管理する。ミラーリング・ターゲットに関して受信されたコマンドは、ミラーリング・ターゲットに直ちに供給されるわけではない。上記のコマンドは、スイッチが何らかの保留状態の（ｐｅｎｄｉｎｇ）同期化コマンドまたは検証コマンドを完了させている間、一時的に待ち行列に入れられることもある。同期化コマンドまたは検証コマンドが完了した後は、スイッチは、それらのコマンドを待ち行列から取り出し、イニシエータからミラーリング仮想ターゲットに供給することが可能となる。
【００１７】
一実施形態によれば、１つ以上の宛先ターゲットに関するデータ受信の使用可能性を判定する工程と、同１つ以上の宛先ターゲットがデータを受信するのに使用可能であると判定されたときにだけ、ソース・ターゲットに読出コマンドを供給する工程とを含む、ミラーリング・ターゲットを管理する方法が、提供される。一実施形態では、この方法はさらに、ソース・ターゲットから読出データを受信する工程と、この読出データを書込データまたは検証データに変換する工程と、この書込データまたは検証データを同１つ以上の宛先ターゲットに供給する工程とを含む。
【００１８】
一実施形態によれば、１つ以上の宛先ターゲットおよびソース・ターゲットと通信状態にある１つ以上のポートと、同１つ以上のポートと通信状態にある１つ以上の処理ユニットとを含む、ミラーリング仮想ターゲットを管理する装置が、提供される。同１つ以上の処理ユニットは、同１つ以上の宛先ターゲットがデータを受信するのに使用可能であるときにだけ、ソース・ターゲットに読出コマンドを供給する。
【００１９】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの両方の組合せを使用して達成され得る。本発明に使用されるソフトウェアは、ハード・ディスク・ドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、光ディスク、フロッピー（登録商標）・ディスク、テープ・ドライブ、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、または他の適当な記憶デバイスを含めた１つ以上のプロセッサ読取可能な記憶デバイス上に記憶される。諸代替実施形態では、ソフトウェアの一部または全部が、カスタム集積回路、ゲート・アレイ、ＦＰＧＡ、ＰＬＤ、および特殊目的プロセッサを含めた専用ハードウェアによって置き換えられる可能性もある。一実施形態では、本発明を実装したソフトウェアは、１つ以上のプロセッサをプログラムするのに使用される。１つ以上のプロセッサが、１つ以上の記憶デバイス（ハード・ディスク・ドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、光ディスク、フロッピー・ディスク、テープ・ドライブ、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、または他の適当な記憶デバイス）、周辺機器（プリンタ、モニタ、キーボード、ポインティング・デバイス）および通信インターフェース（例えば、ネットワーク・カード、無線送信機／受信機など）のうちの１つ以上と組み合わされてもよい。
【発明を実施するための最良の形態】
【００２０】
図１には、一実施形態によるストレージ・スイッチを含む例示的なシステム１００を示す。システム１００は、サーバ１０２など複数のイニシエータ側デバイスを含むことができる。より多くのサーバが使用されてもより少ないサーバが使用されてもよく、諸実施形態はサーバ１０２に加えてまたはサーバ１０２の代わりに任意の適当な物理イニシエータを含み得ることが理解されるであろう。図示されてはいないが、上記のサーバはＬＡＮに結合されてもよい。図示のように、各サーバ１０２は、ストレージ・スイッチ１０４に接続されている。しかし、他の実施形態では、各サーバ１０２は、存在するすべてのストレージ・スイッチ１０４よりも少ない数のストレージ・スイッチ１０４に接続されてもよい。サーバとスイッチとの間で形成される接続は、一実施形態ではファイバ・チャネルまたはギガビット・イーサネット（ｉＳＣＳＩプロトコルに従ってパケットを搬送するもの）であるが、どのようなプロトコルを利用してもよい。他の実施形態は、Ｉｎｔｅｌ  Ｉｎｃ．社によって定義されるＩｎｆｉｎｉＢａｎｄ（登録商標）プロトコルを使用しても、他のプロトコルまたは接続を使用してもよい。
【００２１】
いくつかの実施形態では、１つ以上のスイッチ１０４はそれぞれ、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、またはインターネットなどのワイド・エリア・ネットワーク（ＷＡＮ）１０８に結合される。大部分の実施形態において、ストレージ・スイッチ１０４とＷＡＮ  １０８との間で形成される接続は一般に、インターネット・プロトコル（ＩＰ）を使用することになる。ＭＡＮ／ＷＡＮ  １０８に直接接続される形で図示され
ているが、他の実施形態は、スイッチ１０４とＭＡＮ／ＷＡＮ  １０８との間の媒介物としてルータ（図示せず）を利用してもよい。
【００２２】
さらに、各管理局１１０はそれぞれ、各ストレージ・スイッチ１０４と、各サーバ１０２と、各記憶デバイス１０６とに接続されている。管理局は異なるコンピュータとして図示されているが、各タイプのデバイスを管理するソフトウェアを単一のコンピュータ上に集めてもよいことが理解されるはずである。
【００２３】
かかるストレージ・スイッチ１０４は、それ自体の切換え機能に加えて、仮想化および記憶サービス（例えば、ミラーリング）を提供することもできる。かかるサービスとしては、従来のアーキテクチャの機器から通常提供されるサービスを挙げることができる。
【００２４】
さらに、本発明の一実施形態によるストレージ・スイッチの知能は、あらゆるスイッチ・ポートに分配される。このように分配される知能によって、システムの拡張性および可用性をもたらすことが可能になる。分配された知能によって、一実施形態によるスイッチが「ワイヤ速度」でデータを処理することが可能となる。すなわち、ストレージ・スイッチ１０４は、典型的なネットワーク・スイッチが通常発生させるものよりも長いレイテンシをデータ・パケットに発生させることはない。したがって、スイッチの「ワイヤ速度」は、特定のポートに対する接続によって決定される。したがって、ＯＣ−４８接続を有する一実施形態では、ストレージ・スイッチは、ＯＣ−４８の速度（２．５ビット／ｎｓ）を保つことができる。ＯＣ−４８の速度で移動する２キロバイト（バイト毎に１０ビット）のパケットなら、わずか８マイクロ秒程でスイッチに到達する可能性がある。１キロバイトのパケットなら、わずか４マイクロ秒程しか掛からない可能性もある。１００バイトの最小パケットなら、経過時間は４００ｎｓに過ぎない可能性もある。
【００２５】
図１に示されるネットワークを含めた様々なストレージ・エリア・ネットワークに関するさらなる情報は、２００２年１月１８日に出願された「ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ
ＩＮ  Ａ  ＳＴＯＲＡＧＥ  ＳＹＳＴＥＭ」と題する米国特許出願第１０／０５１，３９６号、および２００２年１月１８日に出願された「ＳＴＯＲＡＧＥ  ＳＷＩＴＣＨ  ＦＯＲ  ＳＴＯＲＡＧＥ  ＡＲＥＡ  ＮＥＴＷＯＲＫ」と題する米国特許出願第１０／０５１，３２１号で確認され得る。
【００２６】
「仮想化」とは一般に、ユーザの加入（ｓｕｂｓｃｒｉｂｅ）する仮想ターゲット空間を１つ以上の物理記憶ターゲット・デバイス上の空間にマッピングすることを指す。「仮想」および「仮想ターゲット」（または「仮想論理ユニット）という用語は、加入単位で割り振られる記憶空間がストレージ・スイッチ１０４に接続されている１つ以上の物理記憶ターゲット・デバイス上のどこにあってもよいことに由来するものである。物理空間は、１つ以上の「論理ユニット（ＬＵ）」を含み得る「仮想ターゲット」または「仮想論理ユニット（ＶＬＵ）」として提供することが可能である。各仮想ターゲットは、ｉＳＣＳＩおよびＦＣプロトコルで頻繁に使用される１つ以上のＬＵ番号（ＬＵＮ）で識別される、１つ以上のＬＵからなる。各論理ユニットは一般に、１つ以上のエクステント、すなわち物理デバイス上の隣接する記憶空間スライスから構成される。したがって、仮想ターゲットまたはＶＬＵは、記憶デバイス全体（１つのエクステント）を占有することも、単一の記憶デバイスの一部（１つ以上のエクステント）を占有することも、あるいは複数の記憶デバイスの一部（複数のエクステント）を占有することもできる。物理デバイス、ＬＵ、エクステントの数、およびそれらの正確な位置は、実体的なものではなく、加入者ユーザからは見えない。
【００２７】
記憶空間は、本願明細書の様々な実施形態では「ドメイン」と呼ばれることもある１つ以上の「プール」に各仮想ターゲットが属する、いくつかの異なる物理デバイスに由来す
ることもある。一実施形態では、同じドメインのユーザだけが、各自のドメイン内の仮想ターゲットを共用することを許される。また、いくつかのドメインをメンバとして含むドメイン・セットも形成され得る。ドメイン・セットの使用は、複数のドメインに関するユーザの管理を容易にすることができ、例えば、５つのドメインを有する１つの企業がサービスを停止することを決めた場合にも、ドメイン・セット全体を使用不能にするために取る必要があるアクションは、１つだけで済む。ドメイン・セットのメンバは、他のドメインのメンバであってもよい。
【００２８】
図２には、本発明の一実施形態によるストレージ・スイッチ１０４の機能ブロック図を示す。ストレージ・スイッチ１０４のようなストレージ・スイッチおよびその動作の詳細に関するさらなる情報は、２００２年１月１８日に出願された「ＳＴＯＲＡＧＥ  ＳＷＩＴＣＨ  ＦＯＲ  ＳＴＯＲＡＧＥ  ＡＲＥＡ  ＮＥＴＷＯＲＫ」と題する米国特許出願第１０／０５１，３２１号で確認され得る。一実施形態では、ストレージ・スイッチ１０４は、それぞれ以下で詳細に説明する複数のラインカード３０２，３０４，３０６と、複数のファブリック・カード３０８と、２枚のシステム制御カード３１０とを含んでいる。例示的なストレージ・スイッチが図示されているが、様々な実施形態に従って他の多数の実装形態および構成が使用され得ることが理解されるであろう。
【００２９】
［システム制御カード］２枚のシステム制御カード（ＳＣＣ）３１０のそれぞれは、あらゆるラインカード３０２，３０４，３０６に接続されている。一実施形態では、かかる接続は、当技術分野でよく知られるＩ２Ｃ信号によって、またＳＣＣを用いたイーサネット接続を介して形成される。ＳＣＣはＩ２Ｃ接続を用いて、個々のラインカードやファブリック・カードの電源投入を制御し、これらを監視する。ＳＣＣはまた、イーサネット接続を介したカード間通信を使用して様々な記憶サービスを開始し、例えばスナップショットおよび複製を開始する。
【００３０】
さらに、ＳＣＣは、ストレージ・スイッチや該スイッチに取り付けられているすべての仮想ターゲットおよび物理デバイス、例えばサーバおよび記憶デバイスに関する構成情報を追跡するデータベース３１２を維持する。さらに、データベースは、使用率、エラーおよびアクセス・データに関する情報、ならびに仮想ターゲットおよびユーザの様々なドメインおよびドメイン・セットに関する情報も保持する。データベースのレコードは、本願明細書では「オブジェクト」と呼ばれることもある。各イニシエータ（例えば、サーバ）およびターゲット（例えば、記憶デバイス）は、当技術分野で知られるＷＷＵＩ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）を有する。データベースは、一実施形態ではフラッシュ・メモリから形成されるＳＣＣ内部のメモリ・デバイス内に維持されるが、様々な実施形態では他のメモリ・デバイスが使用され得る。
【００３１】
ストレージ・スイッチ１０４には、イーサネット接続を使用して管理局１１０からＳＣＣ  ３１０を介して到達され得る。したがって、ＳＣＣは、管理局への接続用の追加のイーサネット・ポートも含んでいる。管理局の管理者は、記憶デバイスまたは仮想ターゲットの追加または除去を発見すると共に、ＳＣＣデータベース３１２に記憶されている任意のオブジェクトを仮想的に照会し更新することができる。
【００３２】
［ファブリック・カード］スイッチ１０４の一実施形態では、３枚のファブリック・カード３０８が存在するが、他の実施形態は、より多くのファブリック・カードを有することもより少ないファブリック・カードを有することもある。各ファブリック・カード３０８は、一実施形態ではラインカード３０２，３０４，３０６のそれぞれに結合され、すべてのラインカードを一緒に接続する働きをする。一実施形態では、各ファブリック・カード３０８は、すべてのラインカードが実装されたときに最大のトラフィックを取り扱うことができる。各ラインカードによって取り扱われるかかるトラフィック負荷は、一実施形
態では最大１６０Ｇｂｐｓであるが、他の実施形態は、より高い最大トラフィック・ボリュームを取り扱うことも、より低い最大トラフィック・ボリュームを取り扱う可能性もある。１枚のファブリック・カード３０８が故障した場合も、生存する２枚のカードは依然として、発生し得る最大のスイッチ・トラフィックに対して十分な帯域幅を有し、例えば一実施形態では、各ラインカードは、入口（ｉｎｇｒｅｓｓ）１０Ｇｂｐｓ、出口（ｅｇｒｅｓｓ）１０Ｇｂｐｓの、２０Ｇｂｐｓのトラフィックを生成する。ただし、通常の環境下では、３枚のファブリック・カードはすべて同じ時間にアクティブ状態にある。データ・トラフィックは、各ラインカードから、３枚のファブリック・カードのうちの該データを収容可能ないずれかのファブリック・カードに向けて送られる。
【００３３】
［ラインカード］ラインカードは、サーバとの接続および記憶デバイスとの接続を形成する。一実施形態では、ストレージ・スイッチ１０４は、最大１６枚までのラインカードをサポートするが、他の実施形態は、異なる数のラインカードをサポートする可能性もある。さらに、一実施形態では、異なるタイプの３枚のラインカード、すなわちギガビット・イーサネット（ＧｉｇＥ）カード３０２と、ファイバ・チャネル（ＦＣ）カード３０４と、ＷＡＮカード３０６とが利用される。他の実施形態は、より多くのタイプのラインカードを含んでいても、より少ないタイプのラインカードを含んでいてもよい。ＧｉｇＥカード３０２は、イーサネット接続用であり、一実施形態ではｉＳＣＳＩサーバまたはｉＳＣＳＩ記憶デバイス（あるいは他のイーサネット・ベース・デバイス）に接続される。ＦＣカード３０４は、ファイバ・チャネル接続用であり、ファイバ・チャネル・プロトコル（ＦＣＰ）サーバまたはＦＣＰ記憶デバイスに接続される。ＷＡＮカード３０６は、ＭＡＮ接続またはＷＡＮ接続用である。
【００３４】
図３には、一実施形態によるストレージ・スイッチ１０４内で使用される一般的なラインカード４００の機能ブロック図を示す。ラインカード４００は、例示のために提示されるに過ぎない。諸実施形態によれば、他のラインカードおよび設計を使用することも可能である。図３には、すべてのタイプのラインカード、例えばＧｉｇＥ  ３０２、ＦＣ  ３０４、またはＷＡＮ  ３０６に共通するコンポーネントを示す。他の実施形態では、ＩｎｆｉｎｉＢａｎｄなど他のプロトコルを使用してデバイスに接続する他のタイプのラインカードが利用される可能性もある。
【００３５】
［ポート］各ラインカード４００は、複数のポート４０２を含んでいる。これらのポートは、ラインカードからサーバへの接続または記憶デバイスへの接続を形成する。図示の実施形態では８つのポートが示されているが、他の実施形態ではより多くのポートが使用されることも、より少ないポートが使用されることもある。例えば一実施形態では、各ＧｉｇＥカードは、最大８つの１Ｇｂイーサネット・ポートをサポートでき、各ＦＣカードは、最大８つの１Ｇｂ  ＦＣポートまたは４つの２Ｇｂ  ＦＣポートをサポートでき、各ＷＡＮカードは、最大４つのＯＣ−４８ポートまたは２つのＯＣ−１９２ポートをサポートできる。したがって、一実施形態では、最大可能接続はスイッチ１０４毎に１２８ポートとなる。各ラインカードのポートは、一実施形態では全２重であり、サーバまたは他のクライアントに接続されるか、記憶デバイスまたはサブシステムに接続されるか、あるいはその両方である。
【００３６】
さらに、各ポート４０２は、関連メモリ４０３も有する。１つのポートに１つのメモリ・デバイスだけが接続されるように示されているが、各ポートがそれ自体のメモリ・デバイスを有していても、すべてのポートが単一のメモリ・デバイスに結合されてもよいことが理解されるはずである。ここでは図面を見やすくするために、１つのポートに１つのメモリ・デバイスだけが結合されるように示されている。
【００３７】
［記憶プロセッサ・ユニット］一実施形態では、各ポートは、記憶プロセッサ・ユニッ
ト（ＳＰＵ）４０１と関連付けられる。一実施形態では、ＳＰＵは、データ・トラフィックを迅速に処理し、そのためワイヤ速度動作が可能になる。一実施形態では、各ＳＰＵは、いくつかの要素、すなわちパケット集約分類エンジン（ＰＡＣＥ）４０４と、パケット処理ユニット（ＰＰＵ）４０６と、ＳＲＡＭ  ４０５と、ＣＡＭ  ４０７とを含む。他の実施形態は、より多くの要素を使用しても、より少ない要素を使用してもよく、同じ機能を得るために各要素を組み合わせることもできる。例えば、いくつかの実施形態はＳＰＵ内にＰＡＣＥおよびＰＰＵを含むが、このＳＰＵは他のＳＰＵとメモリ要素を共用する。
【００３８】
［ＰＡＣＥ］各ポートは、パケット集約分類エンジン（ＰＡＣＥ）４０４に結合されている。図示のように、ＰＡＣＥ  ４０４は、２つのポートを２倍の帯域幅の単一のデータ・チャネルに集約する。例えば、ＰＡＣＥ  ４０４は、２つの１Ｇｂポートを単一の２Ｇｂデータ・チャネルに集約する。ＰＡＣＥは、各受信パケットを制御パケットまたはデータ・パケットに分類することができる。制御パケットは、ブリッジ４１６を介して処理のためにＣＰＵ  ４１４に送られる。データ・パケットは、以下で論じる、ローカル・ヘッダが追加されたパケット処理ユニット（ＰＰＵ）４０６に送られる。一実施形態では、ローカル・ヘッダは１６バイトであり、結果として６４バイト（１６バイトのヘッダ、４８バイトのペイロード）のデータ「セル」となる。ローカル・ヘッダは、情報を搬送するのに使用され、スイッチ１０４によって内部的に使用されるものである。ローカル・ヘッダは、パケットがスイッチから出る前に取り除かれる。したがって、「セル」は、スイッチのローカルで使用され、ローカル・ヘッダと元のパケットとを含む移送ユニットとすることが可能である（いくつかの実施形態では、元のＴＣＰ／ＩＰヘッダについても元のパケットから取り去られる）。しかしながら、本発明の必ずしもすべての実施形態がローカル・ヘッダを作成し、外部パケットとは異なる「内部パケット」（セル）を有するわけではない。したがって、本願明細書で使用される「パケット」という用語は、「内部」パケットを指すこともあれば「外部」パケットを指すこともある。
【００３９】
分類機能は、従来のシステムの蓄積交換モデルを使用せずに、スイッチが記憶域の仮想化およびプロトコル翻訳機能をワイヤ速度で実施することを可能にする上で役立つものである。各ＰＡＣＥは、ＰＰＵへの専用パス、例えばＰＰＵ  ４０６１を有する一方、図示の実施形態の４つのすべてのＰＡＣＥは、一実施形態では１０４ＭＨｚ／３２ビット（３．２Ｇｂｐｓ）のデータ・パスであるＣＰＵ  ４１４に対するパスを共用している。
【００４０】
［パケット処理ユニット（ＰＰＵ）］ＰＰＵ  ４０６１などの各ＰＰＵは、仮想化およびプロトコル翻訳を実行時に実施するが、これは、かかる処理中にセルがバッファされないことを意味する。ＰＰＵには、後で説明する他のスイッチ・ベースの記憶サービス機能も実装される。ＰＰＵは、一実施形態では、ＯＣ−４８の速度すなわち２．５Ｇｂｐｓで入口と出口のどちらの方向にもセルを移動することが可能であり、他の実施形態では、ＯＣ−１９２の速度すなわち１０Ｇｂｐｓでセルを移動することができる。一実施形態では、ＰＰＵは、入口ＰＰＵ  ４０６１ｉと、出口ＰＰＵ  ４０６１ｅとを含み、これらはいずれも同時に作動する。入口ＰＰＵ  ４０６１ｉは、ＰＡＣＥ  ４０４１から入力データを受け取り、データをトラフィック・マネージャ４０８ｉに送り、出口ＰＰＵ  ４０６１ｅは、トラフィック・マネージャ４０８ｅからデータを受け取り、データをＰＡＣＥ  ４０４１に送る。図３には、入口ＰＰＵ  ４０６１ｉと出口ＰＰＵ  ４０６１ｅとを有するものとして１つのＰＰＵ  ４０６１だけが示されているが、一実施形態ではすべてのＰＰＵ  ４０６が入口ＰＰＵと出口ＰＰＵの両方を含むこと、また図３では、図面を見やすくするために入口ＰＰＵと出口ＰＰＵの両方を有するＰＰＵが１つだけ示されていることが理解されるはずである。
【００４１】
各ポートでは、（例えば、サーバから仮想ターゲットへの）多数のストレージ接続が同時に確立され得る。しかしながら、各接続は、仮想ターゲットに一意のものであり、ＴＣ
Ｐ制御ブロック・インデックス（ｉＳＣＳＩ接続の場合）およびポート番号によって一意に識別され得る。接続が確立されたときは、ラインカード４００のＣＰＵ  ４１４が、その接続に関する仮想ターゲット記述子（ＶＴＤ）をＰＰＵ  ４０６に送ることによって、ＰＰＵ  ４０６にアクティブ状態の仮想ターゲットを知らせる。ＶＴＤは、ＰＰＵがそのデータに適切に作用する必要がある、例えば仮想化、翻訳、および様々な記憶サービスを実施する必要がある接続および仮想ターゲットに関するすべての関連情報を含んでいる。ＶＴＤは、ＳＣＣデータベース内のオブジェクトから導出され、通常はＳＣＣデータベース内の関連オブジェクト内に格納されている情報のサブセットを含む。
【００４２】
同様に、本発明の一実施形態では、物理ターゲット記述子（ＰＴＤ）が利用される。ＰＴＤは、実際の物理デバイスと、それらの個々のＬＵまたはそれらの個々のエクステント（ＬＵの隣接する一部またはＬＵ全体）を記述し、ＶＴＤに関する情報と同様の情報を含むことになる。また、ＶＴＤと同様にＰＴＤも、ＳＣＣデータベース内のオブジェクトから導出される。
【００４３】
ＶＴＤおよびＰＴＤを記憶し、それらに迅速にアクセスするために、一実施形態では、ＰＰＵ  ４０６１などのＰＰＵは、ＳＲＡＭ  ４０５１およびＣＡＭ  ４０７１に接続される。ＳＲＡＭ  ４０５１は、ＶＴＤおよびＰＴＤのデータベースを記憶することができる。ＶＴＤへの迅速なアクセスのために、ＶＴＤ識別子（ＶＴＤ  ＩＤ）すなわちアドレスや、ＰＴＤ識別子（ＰＴＤ  ＩＤ）のリストも、ＰＰＵのＣＡＭ  ４０７１内に維持される。ＶＴＤ  ＩＤは、ＴＣＰ制御ブロック・インデックスおよびＬＵＮを使用して索引付け（マッピング）される。ＰＴＤ  ＩＤは、ＶＴＤ  ＩＤを使用して索引付けされる。さらに、ＩＰ経路指定サービスのために、ＣＡＭ  ４０７１は、経路が追加または除去されたときにＣＰＵによって更新される経路表も含んでいる。
【００４４】
様々な実施形態では、各ＰＰＵが図示のようなそれ自体のＣＡＭおよびＳＲＡＭデバイスに接続され、あるいは、すべてのＰＰＵが単一のＣＡＭおよびＳＲＡＭ（図示せず）のうちの一方又は両方に接続されることになる。
【００４５】
ＰＰＵに対する未処理の各要求（例えば、読出や書込）に関しては、その要求の状態を追跡するタスク制御ブロックが、ＰＰＵのＳＲＡＭ  ４０７内に確立される。入口ＰＰＵ上でストレージ・スイッチによって受信される要求の状態を追跡する入口タスク制御ブロック（ＩＴＣＢ）と、出口ＰＰＵ上でストレージ・スイッチから送出される要求の状態を追跡する出口タスク制御ブロック（ＥＴＣＢ）とが存在する。各仮想ターゲットの接続に関しては、多数の同時要求が存在することもあり、したがって多くのタスク制御ブロックが存在することもある。タスク制御ブロックは、要求が開始されると同時に割り振られ、要求が完了すると同時に解放される。
【００４６】
［トラフィック・マネージャ］各ラインカード４００上には２つのトラフィック・マネージャ（ＴＭ）４０８、すなわち入口トラフィック用のＴＭ  ４０８ｉと、出口トラフィック用のＴＭ  ４０８ｅとが存在する。入口側ＴＭは、４つのすべてのＳＰＵから一実施形態では６４バイトのデータ・セルの形でセルを受け取る。かかる一実施形態では、各データ・セルは、１６バイトのローカル・ヘッダと、４８バイトのペイロードとを有する。ヘッダは、ＴＭにセルの宛先ポートを伝えるフローＩＤ（ＦｌｏｗＩＤ）を含む。いくつかの実施形態では、ＳＰＵは、セルをＴＭに転送する前に、セルにＴＭヘッダを付けることができる。いくつかの実施形態では、ＴＭまたはＳＰＵはファブリック・カードを介してセルを送信するために、セルをより小さなセルに細分化することも可能である。
【００４７】
一実施形態では、入口側ＴＭは、１２８ビット／１０４ＭＨｚのインターフェース４１０を介してファブリック・カードにデータ・セルを送る。他の実施形態は、１２５ＭＨｚ
または他の速度で動作することができる。出口側ＴＭは、ファブリック・カードからデータ・セルを受け取り、それらを４つのＳＰＵに引き渡す。
【００４８】
入口側ＴＭと出口側ＴＭはどちらも、引渡し用の待ち行列にセルを入れるための大きなバッファ４１２を有する。入口側ＴＭ用と出口側ＴＭ用のどちらのバッファ４１２も６４ＭＢであり、スイッチ内での内部フロー制御のために多数のパケットを待ち行列に入れることが可能である。セルは、キャッシュ型またはバッファ型スイッチの諸実装形態の場合のようにはバッファされない。これらのシステムの場合のようなトランスポート・レベルでの肯定応答は存在しない。セルは、スイッチ内のフロー制御を維持するために一時的にバッファされるだけである。各セルがそれぞれの元の順序を維持し、ＴＭにおけるセルの高度な処理は存在しない。ＳＰＵは通常、ファブリック・カードの出力フローが入力フローと同様の速さであるときは、入口側ＴＭにセルを迅速に送ることができる。したがって、セルは、出口側ＴＭへと迅速に移動する。一方、出力ポートは混雑し、または複数の入口ラインカードによって一杯となるので、出口側ＴＭのバック・アップが行われることもある。そのような場合では、アクションを迅速に取るべき旨を出口側ＳＰＵに知らせるフラグが、出力セルのヘッダ内にセットされる。出口側ＴＭはまた、ストレージ・アクセスのサービス品質を提供する際に使用されるフロー制御機能をアクティブ化するよう求める要求を入口側ＳＰＵに送る。インターネットを介した通信トラフィックとは異なり、ストレージ・トラフィックに関してはパケットまたはセルの欠落が許容可能でないことは留意に値する。したがって、バッファ内のセルの量が指定された閾値を超えた場合、ＳＰＵは、バッファ・オーバフローを回避するために、それ自体のフロー制御機能を直ちにアクティブ化して入力トラフィックを減速させることができる。
【００４９】
［ファブリック接続］ファブリック接続４１０は、ＴＭにおける２５６ビットの並列信号（それぞれ入口１２８ビット、出口１２８ビット）を、１６０Ｇｂｐｓのバックプレーンに対する１６ビットのシリアル・インターフェース（入口８ビット、出口８ビット）に変換する。したがって、このバックプレーンは、１／１６のピンでありながらも１６倍の速度で作動している。この変換により、膨大な数のピンとワイヤを接続することなく、妥当なコストで可用性の高いバックプレーンの構築が可能になる。さらに、一実施形態では、３枚のファブリック・カードが存在するので、一実施形態では、それぞれ８ビットの信号を３枚のファブリック・カードのうちの１枚に接続する３本の高速コネクタが、各ラインカード上に存在する。当然のことながら、他の実施形態では、３つのファブリック接続４１０は必要でないこともある。
【００５０】
［ＣＰＵ］あらゆるラインカード上には、一実施形態ではＰｏｗｅｒＰＣ（登録商標）７５０  Ｃｘｅであるプロセッサ（ＣＰＵ）６１４が存在する。一実施形態では、ＣＰＵ
４１４は、バス・コントローラ４１５およびブリッジ４１６を介して、各ＰＡＣＥを３．２Ｇｂバスに接続する。さらに、ＣＰＵ  ４１４は、各ＰＰＵ、ＣＡＭ、およびＴＭにも接続されているが、いくつかの実施形態では、この接続は４０Ｍｂｐｓとより低速である。３．２Ｇｂのパスと４０Ｍｂのパスのどちらを用いても、ＣＰＵがラインカードの大部分のデバイスと通信すると共に、ラインカード上のあらゆるデバイスの内部レジスタの読出および書込を行い、マイクロコードをダウンロードし、制御パケットを送受信することが可能となる。
【００５１】
各ラインカード上のＣＰＵは、電源投入時にあらゆるチップを初期化し、マイクロコードが必要とされる場合は常に、ＳＰＵおよび各ポートにマイクロコードをダウンロードする責任を負う。ラインカードが作動状態になると、ＣＰＵは、制御トラフィックを処理する。仮想ターゲットの接続を確立するのに必要な情報に関して、ＣＰＵは、ＳＣＣにその情報を要求し、ＳＣＣは、ＳＣＣデータベース内の該当するオブジェクトから情報を取得する。
【００５２】
［ラインカード−ポートの区別］一実施形態では、各ラインカードが１つのタイプのポートをサポートするので、それぞれのタイプのラインカード内の各ポート、例えばＧｉｇＥ、ＦＣ、またはＷＡＮは、互いに異なる。他の実施形態では、他のラインカード・ポートが、ＩｎｆｉｎｉＢａｎｄなど他のプロトコルをサポートするように設計される可能性もある。
【００５３】
［ＧｉｇＥポート］ギガビット・イーサネット・ポートは、ｉＳＣＳＩサーバおよび記憶デバイスに接続される。ＧｉｇＥポートはすべての種類のイーサネット・トラフィックを搬送するが、一般に、本発明の一実施形態によるストレージ・スイッチ１０４によってワイヤ速度で処理される唯一のネットワーク・トラフィックは、ＴＣＰ／ＩＰパケット内のｉＳＣＳＩパケット・データ単位（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ：ＰＤＵ）である。しかしながら、他の実施形態では、（ネットワーク・ファイル・システム（ＮＦＳ）のような）他のプロトコルに従ってイーサネット接続を介して搬送されるパケットが、ＧｉｇＥポートにおいて受信され、ＳＰＵおよびＣＰＵのうちの一方又は両方によって処理されることもある。
【００５４】
ＧｉｇＥポートは、仮想ターゲットまたはｉＳＣＳＩデバイスに関するＴＣＰ／ＩＰセグメントの受信および送信を行う。仮想ターゲット用のＴＣＰ接続を確立するには、ラインカードのＣＰＵ  ４１４とＳＣＣ  ３１０の両方が必要となる。ＴＣＰパケットが受信され、初期ハンドシェークが実施された後は、ＴＣＰ制御ブロックが作成され、ＧｉｇＥポートのメモリ４０３に記憶される。また、接続を認証し、仮想ターゲットの構成を理解するために、ＳＣＣデータベースのオブジェクトからＶＴＤが検索され、ＣＰＵのＳＤＲＡＭ  ４０５に記憶される。ＴＣＰ制御ブロックは、パケットが属する特定のＴＣＰセッションまたはｉＳＣＳＩ接続を識別し、一実施形態ではＴＣＰセグメントの番号、状態、ウィンドウ・サイズを含み、場合によっては接続に関するその他の情報も含む。さらに、ＴＣＰ制御ブロックは、本願明細書では「ＴＣＰ制御ブロック・インデックス」と呼ばれるインデックスで識別される。接続用のＶＴＤが作成され、ＳＰＵのＳＲＡＭ  ４０５に記憶され得る。ＣＰＵは、それ自体のＳＤＲＡＭに記憶され、元々はＳＣＣデータベースから取得されたＶＴＤの情報を検索することによってＶＴＤを作成する。ＶＴＤの迅速な参照用のＶＴＤ  ＩＤが、ＳＰＵのＣＡＭ  ４０７内のＶＴＤ  ＩＤのリスト内に確立される。ＶＴＤ  ＩＤは、ＴＣＰ制御ブロック・インデックスに関係付けられ（ａｆｆｉｌｉａｔｅｄ）、ＴＣＰ制御ブロック・インデックスによって索引付けされる。
【００５５】
ポートは、ｉＳＣＳＩ  ＰＤＵを受信したときは本質的に接続の終着点として働く一方、スイッチは、ターゲットとの新しい接続を開始する。ポートは、入口側でパケットを受信した後に、特定のＴＣＰ接続を識別するＴＣＰ制御ブロック・インデックスを用いてｉＳＣＳＩ  ＰＤＵをＰＡＣＥに引き渡す。非ＴＣＰパケットまたはｉＳＣＳＩ  ＰＤＵを含んでいないＴＣＰパケットに関しては、ポートは、接続の終着点として働くことなく該パケットを受信し送信する。ポート４０２は典型的には、ＴＣＰ制御ブロック・インデックスを使用してｉＳＣＳＩパケットが受信されまたは送信されるＰＡＣＥ  ４０４と通信する。あるパケットのＴＣＰ制御ブロック・インデックスが−１であるときは、非ｉＳＣＳＩパケットが識別される。
【００５６】
［ＦＣポート］ＦＣポートは、サーバと、ＦＣ記憶デバイスとに接続されている。ＦＣポートは、接続先サーバにとってファイバ・チャネル記憶サブシステム（すなわち、ターゲット）として見え、すなわち、当技術分野で理解されるように、イニシエータ（例えば、サーバ）がプロセス・ログイン（ＰＬＯＧＩまたはＰＲＬＩ）を実施して接続を確立するのを可能にする仮想ターゲット・デバイスの大きなプールを提示する。ＦＣポートは、ＧＩＤ拡張リンクサービス（ＥＬＳ）を受け取り、当該イニシエータ（例えば、サーバ）
によるアクセスに使用可能なターゲット・デバイスのリストを返送する。
【００５７】
上記のポートは、ファイバ・チャネル記憶デバイスに接続されたときはファイバ・チャネルＦポートとして見え、すなわち、当技術分野で知られるように、記憶デバイスからファブリック・ログインを受け取り、ＧＩＤ要求を受け取り、処理することによって名前サービス機能を提供するものである。言い換えれば、記憶デバイスにとってはイニシエータとして見えることになる。
【００５８】
さらに、ＦＣポートは、別の既存のＳＡＮネットワークにも接続され得、かかる例では、その別のネットワークにとって多くのＬＵを有するターゲットとして見える。
ポートの初期化時に、ラインカードのＣＰＵは、ファブリック・ログイン、プロセス・ログイン、およびＧＩＤの送信、ならびにそれらの受信をいずれも済ませることができる。ＳＣＣは、ＦＣ  ＥＬＳをｉＳＮＳ要求およびｉＳＮＳ応答に変換するアプリケーションをサポートしている。したがって、ＳＣＣ内の同じデータベースが、ＦＣイニシエータ（例えば、サーバ）およびターゲット（例えば、記憶デバイス）の両方を、それらがｉＳＣＳＩイニシエータおよびターゲットである場合と同様に追跡し続ける。
【００５９】
ＦＣ接続が確立されたときは、ＧｉｇＥポートとは異なり、ＦＣポートは、ＴＣＰ制御ブロックまたはそれらの等価物を作成する必要がなく、必要なすべての情報は、ＦＣヘッダから使用可能である。しかし、（フレームの宛先を識別するＤ＿ＩＤで索引付けされた）ＶＴＤは依然として、ＧｉｇＥポートについて説明したのと同様の様式で確立される必要がある。
【００６０】
ＦＣポートは、１Ｇｂ向けに構成されても、２Ｇｂ向けに構成されてもよい。１Ｇｂポートとしては、図３に示されるように２つのポートが単一のＰＡＣＥに接続されるが、２Ｇｂポートとして構成される一実施形態では、ＳＰＵでの輻輳を回避するために、ポート・トラフィックと、ＳＰＵによって対応可能なトラフィックとを整合させるべきである。一実施形態では、ポートは、ＰＯＳ／ＰＨＹインターフェースを用いてＰＡＣＥに接続される。各ポートは別々に構成することが可能であり、すなわち、あるＰＡＣＥが２つの１Ｇｂポートを有し、別のＰＡＣＥが単一の２Ｇｂポートを有するようにしてもよい。
【００６１】
［ＷＡＮポート］ＷＡＮラインカードを含む諸実施形態では、ＷＡＮラインカードは、一実施形態ではＯＣ−４８接続とＯＣ−１９２接続とをサポートする。したがって、２つのタイプのＷＡＮポート、すなわちＯＣ−４８と、ＯＣ−１９２とが存在する。ＯＣ−４８に関しては、各ＳＰＵ毎に１つのポートが存在する。ＰＡＣＥ内には分類機能は依然として存在するが、集約機能は存在しない。ＷＡＮポートは、ＳＯＮＥＴに接続されており、ＩＣＭＰ、ＲＩＰ、ＢＰＧ、ＩＰ、およびＴＣＰなどのネットワーク・パケットを送受信するときはＧｉｇＥポートと同様の働きをする。一実施形態によるＷＡＮポートは、追加のハードウェア・コンポーネントを必要とするＶＰＮおよびＩＰＳｅｃを用いたネットワーク・セキュリティをサポートする。
【００６２】
ＯＣ−１９２の方が高速なワイヤ速度となることから、諸実施形態では、ＯＣ−１９２をサポートする、より高速なＳＰＵが必要とされる。
［スイッチ・ベースの記憶動作］
当業者ならｉＳＣＳＩおよびＦＣプロトコルの一般的な知識を有するはずである。しかし、ｉＳＣＳＩのさらなる情報については、その全体を本願明細書に援用する、インターネット・エンジニアリング・タスク・フォース（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ：ＩＥＴＦ）によって策定が進められているインターネット・ドラフト（ｗｗｗ．ｉｅｔｆ．ｏｒｇを参照）の「ｄｒａｆｔ−ｉｅｔｆ−ｉｐｓ−ｉＳＣＳＩ−２０．ｔｘｔ」（２００３年１月１９日）を参照されたい。ファイバ・チャネ
ル（ＦＣ）のさらなる情報については、その全体を本願明細書に援用する、「ＳＣＳＩ  Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  Ｐｒｏｔｏｃｏｌ−２（ＦＣＰ−２）」Ｒｅｖ：０８（２００２年１１月２３日）（ｗｗｗ．ｔ１０．ｏｒｇを参照）を参照されたい。また、これらはいずれも、２００２年１月１８日に出願された「ＳＴＯＲＡＧＥ  ＳＷＩＴＣＨ  ＦＯＲ  ＳＴＯＲＡＧＥ  ＡＲＥＡ  ＮＥＴＷＯＲＫ」と題する米国特許出願第１０／０５１，３２１号においてさらに記載されている。
【００６３】
［記憶域プール］
図１に示すように、本発明の一実施形態によるシステムはその物理構成において、１つ以上のサーバ１０２と、１つ以上の物理デバイス１０６、すなわち記憶デバイスまたはサブシステムとに結合されたスイッチ１０４を含んでいる。各物理ターゲットは、１つ以上の論理ユニット（ＬＵ）１０７から構成される。これらのＬＵから最終的に仮想ターゲットまたはＶＬＵが形成される。
【００６４】
仮想ターゲットが作成すなわち「提供」され得る前に、スイッチは、それ自体に取り付けられるか、それ自体からアクセスするのに使用可能であるか、またはその両方である物理記憶デバイス、ならびにそれらの物理記憶デバイスの特性を「認識する（ａｗａｒｅ）」必要がある。したがって、本発明の一実施形態では、記憶デバイスまたはイニシエータ・デバイスがスイッチに接続されまたは登録されるときに、スイッチは、その新しいデバイスの性能特性を学習する必要がある。デバイスが「発見（ｄｉｓｃｏｖｅｒ）」されると、そのデバイスには、性能特性に関する情報を収集するための様々な問合せが送られる。例えば、転送レートを測定しまたはアクセス時間をチェックするために、読出コマンド／書込コマンドが送られることもある。これに代えて、いくつかの実施形態では、管理者に管理局１１０の性能特性を入力させ、次いで該特性がスイッチ１０４に供給され得るようにして性能特性の取得が行われることもある。
【００６５】
デバイスに関して収集された情報はすべて、一般的にはエンド・ユーザには見えないが、本発明の一実施形態では、スイッチは、これらの情報に基づいてポリシーに基づくデバイスの分類を行う。記憶デバイスに関するポリシーが決定されると、そのデバイス用のＬＵが、本願明細書では「ドメイン」と呼ばれることもある記憶域プール８０２に割り当てられる。各記憶デバイスは１つ以上のＬＵから構成されているので、特定の記憶デバイスのすべてのＬＵは、同じプールに割り当てられる。しかし、一実施形態では、各ＬＵは、スイッチから別々の記憶ノードと見なされ、ＳＣＣデータベース内ではＬＵオブジェクト単位で記述される。したがって、各プールは、ＬＵをメンバとしてもつ。一実施形態では、プールへの割当ては、物理記憶デバイスがそれに従って動作するプロトコル、例えばｉＳＣＳＩまたはファイバ・チャネルとは無関係に行われる。当業者には理解されるように、各プールはスイッチ内で、それ自体に割り当てられたＬＵのプールに関するリストによって定義され、このリストは、一実施形態ではＳＣＣデータベースに記憶される。かかるリストは、ＬＵオブジェクトを指すポインタから構成されてもよい。
【００６６】
各プールには一般に、特定の特性を有するユーザだけがアクセス可能となる。例えば、建物１に位置するユーザ用に「建物１の共用ゴールド記憶域プール（Ｂｕｉｌｄｉｎｇ  １  Ｓｈａｒｅｄ  Ｇｏｌｄ  Ｓｔｏｒａｇｅ  Ｐｏｏｌ）」というタイトルの記憶域プールが確立されてもよい。別の例示的なプールには、「エンジニアリング専用シルバー記憶域プール（Ｅｎｇｉｎｅｅｒｉｎｇ  Ｅｘｃｌｕｓｉｖｅ  Ｓｉｌｖｅｒ  Ｓｔｏｒａｇｅ  Ｐｏｏｌ）」というタイトルが付されてもよく、特定の企業のエンジニアリング・チームが排他的にアクセス可能であってもよい。当然のことながら、プールの無限のバリエーションが確立され得、ここに記載され図示されるプールは、単なる例示に過ぎない。
【００６７】
さらに、一実施形態では、２つの特別なプール、すなわち「デフォルト・プール」と、
「ＮＯプール（Ｎｏ  Ｐｏｏｌ）」とが存在する。デフォルト・プールは、ストレージ・ネットワークへのアクセスを有する任意の者へのアクセスを可能にする。一方、「ＮＯプール」は、一般にユーザからはアクセス可能でなく、スイッチ自体またはシステム管理者からしかアクセス可能でない。ＬＵは、あるプールに割り当てられると、スイッチ自体またはシステム管理者によって別のプールに再割当てされ得る。例えば、ＬＵは当初、ＮＯプール内に配置され、検査された後、デフォルト・プールまたは他のプールに移動され得る。
【００６８】
［仮想ターゲットの提供］
物理デバイス用のＬＵがアクセス可能なプール内（すなわち、「ＮＯプール」以外）にあれば、それらのＬＵから仮想ターゲットまたはＶＬＵが作成され得る。それらが図４に示されるように作成されると、サーバ（およびそれぞれのユーザ）は、それぞれ１つ以上のエクステント１５４から構成される１つ以上の仮想ターゲットまたはＶＬＵ  １５２が「見える」ことになるが、必ずしも物理デバイス１０６が「見える」わけではない。エクステントは、物理デバイスに由来するＬＵの隣接する一部またはＬＵ全体である。図４の例に示されるように、例示的な仮想ターゲット１５２内の各エクステントは、いくつかの物理デバイスに由来するＬＵ全体から形成される。ターゲットが「仮想」であることを理解していないサーバなどのイニシエータからは、「エクステント」は依然としてＬＵＮによって参照され得る。ＬＵによって使用されるプロトコルを含めた仮想ターゲットの構成は、サーバとは無関係である。しかし、図４に示されるように、各仮想ターゲットは、物理デバイス１０６のＬＵにマッピングされるエクステントから構成される。
【００６９】
仮想ターゲットを提供するために、一実施形態においてユーザは、
・サイズ（例えば、ギガバイト単位）、
・記憶域プール。一実施形態ではユーザはアクセスの許可された記憶域プールの内からしか選択できない、
・所望の使用可能性。例えば、常時使用可能（データが極めて重要であり破損してはならない）、通常使用可能など、
・仮想ターゲットのＷＷＵＩ、
・バックアップ・プール、
・ユーザ認証データ、
・ミラーリング・メンバの数、
・ミラーリング数の位置（例えば、ローカルまたはリモート）
を含めた仮想ターゲットに関するいくつかの特性を選択する。本発明の他の実施形態では、異なる特性、追加の特性、あるいはより少ない特性が選択される可能性もある。
【００７０】
次いで、スイッチは、選択されたプールからの使用可能な資源を分析して仮想ターゲットが形成され得るか否かを判定し、詳細には、仮想ターゲットのサイズ要件を満たすいくつかのＬＵ（またはＬＵの一部）が使用可能であるか否かを判定する。使用可能である場合は、１つ以上のエクステントを有する仮想ターゲットが作成され、仮想ターゲットと、それ自体のエクステントと、それ自体の特性とを識別する仮想ターゲット・オブジェクトが、ＳＣＣデータベース内に形成される。様々な仮想ターゲットについてユーザ選択される特性の例は、２００２年１月１８日に出願された「ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ  ＩＮ  Ａ  ＳＴＯＲＡＧＥ  ＳＹＳＴＥＭ」と題する米国特許出願第１０／０５１，３９６号で確認され得る。
【００７１】
［イニシエータ接続の提供］
サーバまたは他のイニシエータがスイッチに接続されており、イニシエータがｉＳＮＳまたはＳＬＰをサポートしている場合は、一実施形態では、イニシエータはそれ自体をスイッチに登録し、それにより、イニシエータ・オブジェクトがＳＣＣデータベース内に記
憶されることになる。一方、他の実施形態では、スイッチは、イニシエータ接続を作成し、更新し、削除するアクセス提供機能を含む。アクセス接続すなわちスイッチとイニシエータ（サーバなど）との間の接続を作成する際は、ユーザは、例えばサーバＷＷＵＩ、プロトコル（例えば、ＧｉｇＥまたはファイバ・チャネル）などの接続の詳細、排他使用と共用の別、ソースＩＰアドレスおよび宛先ＩＰアドレス、帯域幅の最小パーセンテージおよび最大パーセンテージ、サーバから必要とされる接続の数、アクセス・セキュリティ、読取専用と読取／書込両用の別、ＶＰＮがイネーブルされているかなど、様々なパラメータを指定することになる。
【００７２】
ユーザ指定情報の一部または全部が、ＳＣＣデータベース内に記憶されているイニシエータ・オブジェクト内に保存される。接続が除去されたときは、イニシエータ・オブジェクトは削除される。
【００７３】
次いで、スイッチ、管理局、または他のネットワーク管理は、特定の接続用の記憶域プールを作成し、それにより、イニシエータが仮想ターゲットを形成するのに使用可能なＬＵが指定される。
【００７４】
［ユーザ・ドメイン］
物理デバイスと同様に仮想ターゲットも、指定された特性を有するものだけがアクセス可能なプールに割り当てられ得る。したがって、物理デバイスと同様に仮想ターゲットも、ユーザに特有のドメイン（本願明細書ではユーザ・ドメインと呼ばれることもある）、デフォルト・ドメイン（誰でもアクセス可能）、あるいはＮＯドメイン（Ｎｏ  Ｄｏｍａｉｎ）に割り当てられ得る。一実施形態では、各ドメインは、そのドメインに割り当てられているすべての仮想ターゲットのリストを含むＳＣＣデータベース内のオブジェクトによって識別される。ＮＯドメインは仮想ターゲットに関して、予備仮想ターゲット、ミラーリング仮想ターゲットのメンバ、または別のスイッチのリモート仮想ターゲットを含むことができる。仮想ターゲットのＮＯドメインは本質的に、あるタイプの仮想ターゲット用のパーキング・プレースである。本願明細書では説明を分かりやすくするために、仮想ターゲットに言及する場合は、プールを「ドメイン」と呼び、物理デバイスに言及する場合は、プールをそのまま「プール」と呼ぶ。しかし、「プール」および「ドメイン」は概念上、本質的に同じものであることが理解されるはずである。
【００７５】
上述のようにイニシエータ接続が提供されると、イニシエータの要件を満たす仮想ターゲットが提供され、イニシエータからアクセス可能なプール内に配置され、あるいは、例えばＮＯドメインやデフォルト・ドメインなど別のドメインからイニシエータのユーザ・ドメインに仮想ターゲットを移動させることによって、それ以前に提供された仮想ターゲットが、イニシエータからアクセス可能な状態にされる（仮想ターゲットとイニシエータ接続のどちらが最初に提供されてもよく、これらは必ずしも特定の順序で提供される必要はないことに留意されたい）。次いで、例えば読出要求または書込要求を送ることによってイニシエータが仮想ターゲットへのアクセスを要求すると、仮想ターゲット・オブジェクトとイニシエータ・オブジェクトの両方が、ＳＣＣデータベースから読み出され、イニシエータ接続および仮想ターゲットに関する情報が、その要求を処理する際に使用される１枚（または複数枚）の関連するラインカードに渡される。
【００７６】
図５ａ〜５ｃには、ストレージ・エリア・ネットワーク内で仮想ターゲットを提供する一例を示す。図５ａ〜５ｃのシステムは、ＬＵ１，ＬＵ２，ＬＵ３，ＬＵ４，ＬＵ５，ＬＵ６の合計６つのＬＵを有する３つの物理デバイス１０６１，１０６２，および１０６３を含んでいる。図５ａでは、各物理デバイスは、スイッチに結合され、２つのイニシエータＸ，Ｙからアクセス可能なプール、すなわち「Ｘ−Ｙユーザ・プール」内に配置される。
【００７７】
イニシエータＸおよびイニシエータＹがそれぞれ１つの仮想ターゲットを必要とする場合は、図２ｂに示されるように、一実施形態では、エクステントＬＵ１〜３を含む仮想ターゲットＶＴ１と、エクステントＬＵ４〜６を含むＶＴ２とを形成するＬＵが提供される。ＶＴ１は、サーバＸのユーザ・ドメイン内に配置され、ＶＴ２は、サーバＹのユーザ・ドメイン内に配置される。イニシエータＸは、ＶＴ１にはアクセスできるがＶＴ２にはアクセスできず、イニシエータＹは、ＶＴ２にはアクセスできるがＶＴ１にはアクセスできない。
【００７８】
その代わりに、例えばイニシエータＹが合計６つのＬＵを有するミラーリング仮想ターゲットＭを必要とする場合では、ＶＴ１，ＶＴ２は、仮想ターゲットＭのメンバとして作成され得る。ＶＴ１，ＶＴ２は、スイッチのＮＯドメイン（ユーザが物理ターゲットに直接アクセス可能でないドメイン）内に配置され得、Ｍは、図２ｃに示されるようにＹからアクセス可能な状態にされる。ＶＴ１，ＶＴ２はＭのメンバとして、独立してアクセス可能なものではない。ＶＴ１は、ＬＵ１〜３（物理デバイス１０６１）から構成され、ＶＴ２は、ＬＵ４〜６（物理デバイス１０６２および１０６３）から構成される。仮想ターゲットＭに対するデータの書込要求が受信されたときは、スイッチ１０４は、その入力データをＶＴ１（物理デバイス１０６１）とＶＴ２（物理デバイス１０６２および１０６３のうちの一方又は両方）との両方に経路指定し、したがって、少なくとも２つの物理位置にデータが記憶されることになる。
【００７９】
［オブジェクト］
上述のように、各仮想ターゲット、各イニシエータ接続、および各物理デバイスは、それぞれのエンティティのオブジェクト内に含まれる情報を用いて、ＳＣＣデータベース内で識別される。各仮想ターゲット・オブジェクトおよび物理ターゲット・オブジェクトは、エクステントのリストまたはそれ自体を含むＬＵのリストを含む。本発明の一実施形態では、仮想ターゲット・オブジェクトの一例は、次の情報を含む：
・エンティティ・タイプ
・エンティティ識別子
・ＩＰアドレスの管理
・タイム・スタンプおよびフラグ
・ポート
・ドメイン情報
・ＳＣＮビット・マップ
・容量および問合せ情報
・エクステントの数
・エクステントのリスト
・エクステント・ロケータ
・仮想モード・ページ
・サービス品質ポリシー（例えば、表４の最初の３つのエントリ）
・使用率、エラー、および性能データの統計
・ＳＬＡ識別子
物理ターゲット（またはＬＵ）オブジェクトも、同様の情報を含むことができる。ＶＴＤ情報に関するさらなる情報は、２００２年１月１８日に出願された「ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ  ＩＮ  Ａ  ＳＴＯＲＡＧＥ  ＳＹＳＴＥＭ」と題する米国特許出願第１０／０５１，３９６号で確認され得る。
【００８０】
［仮想化］
単なる例示のために、様々なパケット・タイプを対象とする例示的な入口処理および出口処理を説明する。様々な実施形態によれば、様々なパケット・タイプ毎に、多数の方法
が使用され得ることが理解されるであろう。一実施形態では、ＰＰＵによって入力パケットがデータまたは制御トラフィックとして分類された後は、ＰＰＵは、データのバッファリングを伴わずにデータ・パケットの仮想化を実施することができる。ＰＰＵは、各受信パケット毎にパケットのタイプ（例えば、コマンド、Ｒ２Ｔ／ＸＦＥＲ＿ＲＤＹ、書込データ、読出データ、応答、タスク管理／打切り）を判定し、次いで入口（パケットがスイッチに入る場所）と出口（パケットがスイッチから出る場所）のいずれかのアルゴリズムを実施して、仮想ターゲットを物理ターゲットに、あるいは反対に物理ターゲットを仮想ターゲットに翻訳する。したがって、仮想化機能は、入口ポートおよび出口ポートに分配される。さらなるワイヤ速度動作を可能にするために、要求位置をアクセス位置にマッピングする仮想記述子が、ＣＡＭと共に使用される。さらに、各パケット毎に特別な考慮事項が存在することもある。例えば、パケットの宛先となる仮想ターゲットは、いくつかの非隣接エクステントに渡って隔置されることもミラーリングされることもあり、あるいはその両方が行われることもある。
【００８１】
［コマンド・パケット−入口］
仮想ターゲットとの間の転送タスクを開始するために、それぞれｉＳＣＳＩ  ＰＤＵまたはＦＣＰ  ＩＵ内のｉＳＣＳＩまたはＦＣイニシエータからＳＣＳＩコマンドが送られる。図６を参照すると、工程５０２で（分類後に）かかるパケットがＰＰＵにおいて受信されたときは、次に工程５０４で有効なＶＴＤ  ＩＤが存在するか否かを判定するために、ｉＳＣＳＩイニシエータの場合にはＴＣＰ制御ブロック・インデックスと論理ユニット番号（ＬＵＮ）とを使用して、また、ＦＣイニシエータの場合にはＳ＿ＩＤ（フレーム・ソースの識別）とＬＵＮとを使用して、ＰＰＵのＣＡＭがチェックされる。各ケースのＬＵＮはそれぞれ、ｉＳＣＳＩ  ＰＤＵまたはＦＣＰ  ＩＵ内で発見される。有効なＶＴＤ
ＩＤが発見されない場合には、工程５０６で、応答パケットがイニシエータに送り返される。有効なＶＴＤが発見された場合には、工程５０８で、無効なパラメータの有無がチェックされる。無効なパラメータが存在する場合には、工程５０６で、応答パケットがｉＳＣＳＩまたはＦＣイニシエータに送り返される。
【００８２】
工程５１０で、タスク・インデックスと共に入口タスク制御ブロック（ＩＴＣＢ）の割振が行われる。タスク・インデックスは、ＩＴＣＢを指しまたは識別するものである。ＩＴＣＢは、（ＶＴＤから取得した）フローＩＤ、ＶＴＤ  ＩＤ、（ｉＳＣＳＩパケット自体の）コマンド・シーケンス番号すなわちＣｍｄＳＮや、イニシエータ（オリジネータ）の識別（例えば、ｉＳＣＳＩ  ＰＤＵの形で送られるｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇ、またはＦＣＰフレーム・ヘッダ内のＯＸ＿ＩＤ）を記憶する。ＯＸ＿ＩＤは、オリジネータ（イニシエータ）の交換に関する識別である。ＩＴＣＢは、ＰＰＵのＳＲＡＭに記憶される。当然のことながら、所与の任意の時間に進行中のコマンドが多数存在する可能性があり、その場合には、ＰＰＵは、任意の特定の時間にいくつかのＩＴＣＢを記憶することができる。各ＩＴＣＢはそれぞれ、それ自体のタスク・インデックスによって参照される。
【００８３】
ＶＴＤは、特定の仮想ターゲットに対する未処理のコマンドの数を追跡し、したがって、工程５１２で新しいＩＴＣＢが確立された場合は、未処理のコマンドの数を増分させる。いくつかの実施形態では、ＶＴＤは、いずれか１つの特定の仮想ターゲットに対する、未処理であってもよいコマンドの最大数を確立する。工程５１４で、フローＩＤ、ＶＴＤ
ＩＤ、およびタスク・インデックスはすべて、ローカル・ヘッダにコピーされる。フローＩＤは、トラフィック・マネージャに宛先ラインカードおよびポートを伝えるものである。その後、タスク・インデックスは、特定のタスクのパケットを識別するために、出口ポートから返送される。最後に、パケットは、工程５１６でトラフィック・マネージャに送られ、次いで経路指定ファブリックへと送られ、それによって最終的に出口ＰＰＵに到達する。
【００８４】
仮想ターゲットが複数のエクステントから構成される場合は、各エクステント毎に１つずつ、複数のフローＩＤがＶＴＤ内で識別される。ＰＰＵは、パケットのブロック・アドレスをチェックし、正しいフローＩＤを選択する。例えば、仮想ターゲットが２つの１Ｇｂエクステントを有し、コマンドのブロック・アドレスが２番目のエクステント内にある場合は、ＰＰＵは、２番目のエクステントのフローＩＤを選択する。言い換えれば、フローＩＤは、宛先／出口ポートを判定するものである。読出コマンドがエクステントの境界を跨ぐ場合、すなわち、そのコマンドが開始ブロック・アドレスを第１のエクステント内に指定し、終了ブロック・アドレスを第２のエクステント内に指定している場合には、ＰＰＵは、第１のエクステントから該当するデータを読み出した後に、そのコマンドを第２のエクステントに対して繰り返して残りのブロックを読み出す。書込コマンドがエクステントの境界を跨ぐ場合には、ＰＰＵは、両方のエクステントにそのコマンドを複製し、書込データの順序を管理する。読出コマンドがエクステントの境界を跨ぐ場合は、２つのエクステントに対する２つの読出コマンドが存在することになる。第２の読出コマンドは、第１の読出コマンドが完了して、データがイニシエータに順次返送されることが保証された後にだけ送られる。
【００８５】
［コマンド・パケット−出口］
図７を参照すると、工程６０２で、コマンドのＰＤＵまたはＩＵが、スイッチ・ファブリックを通過した後に、ＰＰＵに到着し、出口ポートに向けて送られることになる。工程６０４で、ＰＰＵは、パケットの宛先となる１つ（または複数）の物理デバイスを識別しようと試みる。そうするために、ＰＴＤ  ＩＤ（物理ターゲット記述識別子）の有無について、ローカル・ヘッダのＶＴＤ  ＩＤを使用してＰＰＵのＣＡＭが探索される。ＶＴＤ
ＩＤは、特定の出口ＰＰＵに関連する特定のＰＴＤ  ＩＤに関係付けられ、その索引付けを行う。ＰＴＤは、ＶＴＤと同様にＰＰＵのＳＲＡＭに記憶され、また、ＶＴＤ内で発見されるのと同様の情報を含んでいる。探索が不成功に終わった場合には、そのパケットがＣＰＵから直接送られたコマンド・パケットであり、ＰＰＵから追加の処理が必要とされないことが仮定され、それによってＰＰＵがローカル・ヘッダ内のフローＩＤに基づいて、そのパケットを適当な出口ポートに渡すことになる。探索が成功した場合には、ＰＴＤ  ＩＤは、仮想ターゲットがそれにマッピングされ、現時点でパケットを処理している特定の出口ラインカードと通信状態にある物理ターゲット（エクステントを含む）を識別する。
【００８６】
次に工程６０６で、ＰＰＵは、タスク・インデックスと共に出口タスク制御ブロック（ＥＴＣＢ）の割振を行う。一実施形態では、出口用に使用されるタスク・インデックスは、入口用に使用されるものと同じである。タスク・インデックスは、ＥＴＣＢも識別する。さらに、ＥＴＣＢは、ｉＳＣＳＩ  ＰＤＵのＣｍｄＳＮまたはＦＣＰ  ＩＵに関する交換シーケンスを含めて、コマンドに必要な他の任意の制御情報も記憶する。
【００８７】
工程６０８で、ＰＰＵは、ＰＴＤの内容を使用して仮想ターゲットのＳＣＳＩブロック・アドレスを物理デバイスのブロック・アドレスに変換する。この変換は、仮想ターゲットのブロック・アドレスをエクステントの開始ブロック・オフセットに追加することによって行うことができる。例えば、アクセスしようとする仮想ターゲットのブロックが１９９０であり、それに対応する第１のエクステントの開始オフセットが３０００である場合は、アクセスされるエクステントのブロック・アドレスは、４９９０となる。次に工程６１０で、ＰＰＵは、適当なｉＳＣＳＩのＣｍｄＳＮまたはＦＣＰのシーケンスＩＤを生成し、これらをｉＳＣＳＩ  ＰＤＵ内またはＦＣＰフレーム・ヘッダ内に配置する。工程６１２で、ＰＰＵは、必要に応じてＦＣＰフレーム・ヘッダも構築し（いくつかの実施形態では、入口ＰＰＵはこの工程で、ＦＣＰヘッダから必要な情報を読み出した後にＦＣＰフレーム・ヘッダを除去するが、他の実施形態では、ＦＣＰフレーム・ヘッダはそのままの
状態にしておき、単に必要なフィールドを更新または変更するだけである）、また、パケットがｉＳＣＳＩターゲットに送られるようにするために、ＴＣＰ制御ブロック・インデックスがＰＴＤからローカル・ヘッダにコピーされる。さらに、ＰＰＵは、ｉＳＣＳＩまたはＦＣＰヘッダに必要とされるフラグまたは他の変数があればそれらも提供する。次いで工程６１４で、完成したｉＳＣＳＩ  ＰＤＵまたはＦＣＰフレームがＰＡＣＥに送られると、ＰＡＣＥは、工程６１６でローカル・ヘッダを取り去り、工程６１８でそのパケットを適切なポートに渡す。
【００８８】
［Ｒ２ＴまたはＸＦＥＲ＿ＲＤＹ−入口］
図８を参照すると、書込コマンドであるコマンドが上述のようにターゲット記憶デバイスに送られた後は、工程７０２で、記憶デバイスが書込データを受け取る準備が完了したときに、記憶デバイスからＲ２Ｔ  ＰＤＵまたはＸＦＥＲ＿ＲＤＹ＿ＩＵが受信されることになる。工程７０４で、ＰＰＵは、パケット内のｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇまたはＯＸ＿ＩＤを使用して対応するＥＴＣＢを識別する。いくつかの実施形態では、パケットのｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇまたはＯＸ＿ＩＤは、ＥＴＣＢを識別するタスク・インデックスと同じものである。ｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇまたはＯＸ＿ＩＤが無効である故に、ＰＰＵが有効なＥＴＣＢを識別できない場合には、パケットは破棄される。そうではなく、ＥＴＣＢが識別された場合には、工程１０６１で、ＰＰＵは、ＥＴＣＢから（出口タスク・インデックスと異なる場合は）入口タスク・インデックスと、ＶＴＤ  ＩＤとを検索する。ＰＰＵは、やはりＰＴＤ  ＩＤによってＥＴＣＢ内で識別されるフローＩＤもＰＴＤから検索する。フローＩＤは、元のイニシエータ（入口）ポートのラインカードをトラフィック・マネージャに示す。工程１０６２で、フローＩＤ、ＶＴＤ  ＩＤ、およびタスク・インデックスは、パケットのローカル・ヘッダにコピーされる。最後に工程７１０で、パケットは、トラフィック・マネージャおよびスイッチ・ファブリックに送られる。
【００８９】
［Ｒ２ＴまたはＸＦＥＲ＿ＲＤＹ−出口］
図９を参照すると、Ｒ２ＴまたはＸＦＥＲ＿ＲＤＹパケットは、スイッチ・ファブリックから出た後は、工程８０２で、それ自体がイニシエータ（特定のタスクに関する元のコマンドを開始したデバイス）に戻される途中にＰＰＵによって受信される。工程８０４で、タスク・インデックスは、そのＩＴＣＢから元のｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇとＶＴＤ  ＩＤとが取得され得るＩＴＣＢを、ＰＰＵに対して識別する。工程８０６で、Ｒ２Ｔ／ＸＦＥＲ＿ＲＤＹの所望のデータ転送長またはＢＵＲＳＴ＿ＬＥＮフィールドが、ＩＴＣＢ内に記憶される。工程８０８で、ＦＣＰのＤ＿ＩＤまたはＴＣＰ接続用のＴＣＰ制御ブロック・インデックスを用いて、ローカル・ヘッダが更新される。ＩＴＣＢ内に記憶される元のパケットの記憶済みＳ＿ＩＤが、Ｄ＿ＩＤとなることに留意されたい。工程８１０で、必要に応じてＦＣＰフレーム・ヘッダが構築され、またはそのフィールドが更新される。工程８１２で、ローカル・ヘッダ内でフローＩＤの代わりに宛先ポート番号が指定され、ｉｎｉｔｉａｔｏｒ＿ｔａｓｋ＿ｔａｇと共にＳＣＳＩ  ＰＤＵ内に配置され、また、ＦＣ接続の場合では、ＲＸ＿ＩＤおよびＯＸ＿ＩＤがＦＣＰフレーム内に配置される。ＲＸ＿ＩＤフィールドは、レスポンダ（ターゲット）の交換に関する識別である。また、ＰＰＵは、ＰＤＵまたはＦＣＰヘッダ内に配置される必要がある他のフラグまたは変数があればそれらも配置する。工程８１４で、パケットはＰＡＣＥに転送され、ＰＡＣＥはローカル・ヘッダから出力ポートを識別する。次いで工程８１６で、ローカル・ヘッダが取り去られ、工程８１８で送信に適したポートに転送される。
【００９０】
コマンドが２つ以上のエクステントに分割された場合、例えばそのコマンドがあるエクステント内から始まり、別のエクステント内で終わる場合は、第１のエクステントまでのデータ転送が完了し、したがってイニシエータからの順次的なデータ転送が保証されるまで、ＰＰＵは、第２のエクステントのＲ２ＴまたはＸＦＥＲ＿ＲＤＹを保持する必要があ
る。さらに、第２のエクステントのＲ２ＴまたはＸＦＥＲ＿ＲＤＹのデータ・オフセットは、第１のエクステントに転送されるデータ量を加えることによって修正される必要がある。
【００９１】
［書込データ・パケット−入口］
イニシエータは、Ｒ２ＴまたはＸＦＥＲ＿ＲＤＹパケットを受信した後は、書込データ・パケットを返送する。図１０を参照すると、工程９０２で、イニシエータから書込データのｉＳＣＳＩ  ＰＤＵまたはＦＣ  ＩＵが受信されたときは、工程９０４で、そのパケットの属するＩＴＣＢが識別される必要がある。通常、ＩＴＣＢは、いくつかの実施形態ではタスク・インデックスと同じものであるＲＸ＿ＩＤまたはｔａｒｇｅｔ＿ｔａｓｋ＿ｔａｇを使用して識別され得る。さらに、ＳＰＵは、受信パケットが順序通りであることも識別する。しかしながら、いくつかの状況では、イニシエータは、Ｒ２ＴまたはＸＦＥＲ＿ＲＤＹを受信する前に送られる非請求データを転送することになる。かかる場合には、ＰＰＵは、特定の仮想ターゲットに関する未処理のタスクを探索することによって、ＩＴＣＢを発見する必要がある。それでもＩＴＣＢが発見されない場合には、パケットは破棄される。ＩＴＣＢが発見された場合には、工程９０６で、転送される合計のデータ量がＩＴＣＢ内で更新される。工程９０８で、フローＩＤおよびタスク・インデックスが、パケットのローカル・ヘッダに追加される。次いで工程９１０で、パケットは、トラフィック・マネージャに転送され、最終的にスイッチ・ファブリックへと転送される。
【００９２】
［書込データ・パケット−出口］
図１１を参照すると、工程１００２で、（トラフィック・マネージャを介して）スイッチ・ファブリックから書込データ・パケットが受信されたときは、工程１００４で、そのパケットのＥＴＣＢが識別される必要がある。典型的には、ＥＴＣＢは、ローカル・ヘッダ内のタスク・インデックスを使用して識別され得る。ＥＴＣＢが発見されると、工程１００６で、ＰＰＵは、ＥＴＣＢ内の情報を使用して、適当なｉＳＣＳＩのＤａｔａＳＮまたはＦＣＰのシーケンスＩＤと共に、ＰＤＵまたはＦＣＰフレーム・ヘッダ用の他のフラグおよび変数、例えばデータ・オフセットがあればそれらも生成する。工程１００８で、ＰＴＤに関するＴＣＰ制御ブロック・インデックスまたはＦＣＰのＤ＿ＩＤを用いて、ローカル・ヘッダが更新される。ポート番号もローカル・ヘッダに追加される。工程１０１０で、完成したｉＳＣＳＩ  ＰＤＵまたはＦＣＰフレームがＰＡＣＥに送られると、ＰＡＣＥは、工程１０１２でローカル・ヘッダを取り除き、工程１０１４でそのパケットを適切なポートに転送する。
【００９３】
［初期ミラー同期化］
ミラーリング仮想ターゲット（またはミラーリングＶＬＵ）は、データ記憶域の信頼性を向上させるために、２つ以上の物理位置においてデータを維持する。ミラーリング仮想ターゲットを最初に提供するときは、仮想ターゲットの各メンバ内に記憶されているデータを同期化する必要がある。したがって、初期ミラー同期化処理は、ミラーリング仮想ターゲットの各物理ターゲット・メンバ間のデータを同期化するために実施され得る。一実施形態では、１つのターゲット・メンバを１次（ソース）ターゲットとして確立することによってデータが同期化され得る。次いで、１次ターゲットのデータは、ミラーリング仮想ターゲットのその他の各ターゲット・メンバに書き込まれ得る。１次ソース・ターゲットのデータが各宛先ターゲットに書き込まれた後は、仮想ターゲットの初期状態が確立され、各ターゲット・メンバがミラーリング仮想ターゲットと同一のデータ・セットを記憶した状態で、仮想ターゲットがミラーリングされ得ることになる。
【００９４】
本開示ではしばしば、初期ミラー同期化がミラーリング仮想ターゲットの初期提供時に実施されるものとして言及されているが、必ずしもそうである必要はない。初期ミラー同期化は、いつ実施されてもよい。例えば、ミラーリング仮想ターゲットの１つ以上のター
ゲットが何らかの理由で同期化されていないことが判定された後に、初期ミラー同期化が実施されてもよい。別の例では、初期ミラー同期化は、ミラーリング・ターゲットのメンバの同期化を保証する所望の瞬間に実施されてもよい。
【００９５】
一実施形態によるミラーリング仮想ターゲットの初期ミラー同期化を、図１２および図１３を参照して説明する。図１２は、一実施形態による初期ミラー同期化処理の流れ図であり、図１３は、ストレージ・スイッチ１３００と、ミラーリング仮想ターゲットのメンバを同期化するのに使用され得るコマンド・フローとを含む簡略ブロック図である。図１３では論述を分かりやすくするために、上述で既にその動作が説明されたストレージ・スイッチ１３００の多くのコンポーネントを省略している。図１３に示される一実施形態によるストレージ・スイッチは、中央処理装置１３０２を含むことができる。一実施形態では、ＣＰＵ  １３０２は、初期ミラー同期化を管理するコピー・サービス・マネージャ（ＣＳＭ）１３０４を含むことができる。様々な実施形態において、ＣＳＭ  １３０４は、１つ以上のソフトウェア・モジュール、コンポーネント、あるいは実質的に本願明細書に記載される通りの機能を実施し得る命令セットを含むこともできる。ＣＳＭ  １３０４は、専用ハードウェアを含むことができるか、不揮発性メモリ（例えば、フラッシュ・メモリ、ＥＥＰＲＯＭなど）や他のメモリ・デバイスのような１つ以上の記憶デバイス上に記憶されているソフトウェアによってプログラムされるハードウェアを含むことができるか、あるいはその両方である。
【００９６】
図１２の工程１２０２で、例えば前述のようにユーザがミラーリング仮想ターゲットを提供したことに応答して、仮想ターゲットの初期ミラー同期化が開始する。例えば、ユーザは、図１３に示される物理ターゲットＭ０，Ｍ１をメンバとしてもつ仮想論理ユニット１３０６を提供することができる。物理ターゲットＭ０，Ｍ１は、１つ以上の物理デバイスの物理ＬＵであってよい。本願明細書では、仮想ターゲットのメンバとしての２つの物理ターゲットは、例示のために提示されるに過ぎない。諸実施形態による仮想ターゲットは、任意の数の物理ターゲット・メンバを含むことができる。
【００９７】
提供されたＶＬＵ  １３０６に対応する物理ターゲットの初期同期化を開始するために、工程１２０４で、内部仮想ターゲット（ＩＶＴ）が作成される。例えば、ＣＳＭ  １３０４は、メモリ１３１０に記憶され、ＰＰＵ  １３１２からアクセス可能なＩＶＴ  １３０８を作成することができる。ＩＶＴ  １３０８は、処理のソースとして指定されたミラーリング・ターゲット１３０６のメンバに対応する第１の内部仮想論理ユニット（ＩＶＬＵ）を含むように提供され得る。ミラーリング・ターゲット１３０６の残りのメンバに対応する１つ以上の第２のＩＶＬＵが、提供され得る。例えば、図１３に提示される例では、ソース・ターゲットＭ０についてはソースＩＶＬＵ（０）１３２０が提供され、宛先ターゲットＭ１については宛先ＩＶＬＵ（１）が提供される。一実施形態では、ＶＬＵ  １３０６が３つ以上のメンバ・ターゲットを含んでいる場合は、ミラーリング・ターゲットの対応する各ターゲット（宛先）メンバについて別々のＩＶＬＵが提供され得る。別の実施形態では、各宛先ターゲットは、同じＩＶＬＵの別々のメンバとして提供され得る。一実施形態では、内部仮想論理ユニットは、初期ミラー同期化処理用に作成または提供される１次オブジェクトとしてもよい。同期化処理が完了した後は、ＩＶＬＵは、破棄されてもよい。ＣＰＵ  １３０２およびＣＳＭ  １３０４は同期化中、ＩＶＬＵ（０）１３２０およびＩＶＬＵ（１）１３２２に読出コマンドおよび書込コマンドを供給する内部イニシエータとして働くことができる。
【００９８】
物理ターゲットを同期化する前に、ＩＶＴの１つのメンバは、ＶＬＵのその他の各メンバにそれ自体のデータが書き込まれるソース・ターゲットとなる、１次メンバとして指定される。一実施形態では、ユーザから提供されたＶＬＵ  １３０６は、ＶＬＵのどの物理ターゲットを１次メンバにすべきかを指定することができる。他の実施形態では、ストレ
ージ・スイッチが、メンバのうちの１つをデフォルトとして指定することもできる。
【００９９】
様々な実施形態によれば、ＩＶＴは、ストレージ・スイッチの任意のＰＰＵにおいて提供され得る。図１３に提示される例では、ＩＶＴ  １３０８は、ＰＰＵ  １３１２において提供されるが、そうでない場合は、初期ミラー同期化処理とは関連付けられない。ＰＰＵ  １３１２は、物理ターゲットＭ０またはＭ１のどちらに接続されたポートとも関連付けられていない。さらに、ＰＰＵ  Ａ１２は、ＶＬＵ  １３０６が最初に提供されたポートとも関連付けられていない。一実施形態では、ＣＳＭ  １３０４は、ＩＶＴを提供するのに最適なＰＰＵを判定するアルゴリズムを含む。一実施形態では、このアルゴリズムは、ＶＬＵの１次メンバに関連するＰＰＵにおいてＩＶＴを提供することが好ましい。１次メンバのＰＰＵが、所定の数のいくつかのタスクまたは所定の数を超えるタスクを処理している場合は、ＩＶＴは、別のＰＰＵ（例えば、その他の仮想ターゲット・メンバのうちの１つのＰＰＵ、または１次メンバに関連するＰＰＵのラインカード上にある別のＰＰＵ）に割り当てられ得る。別の実施形態では、ＣＳＭ  １３０４は、最も少ない数のタスクを処理しているストレージ・スイッチのＰＰＵを選ぶ。
【０１００】
ＩＶＴ  １３０８が提供された後は、工程１２０６で、ＣＳＭ  １３０４は、ミラーリング仮想論理ユニットの１つ（または複数）の宛先ターゲットに対して書込コマンドを発行する。図１３の例では、ＶＬＵ  １３０６のミラーリング・メンバＭ０が１次メンバである。したがって、書込コマンドはまず、宛先ターゲットＭ１に対して発行される。図１３では、書込コマンドのコマンド・フローは、１で表されている。図示のように、ＣＳＭ
１３０４はまず、ＩＶＬＵ（１）１３２２に対して書込コマンドを発行し、この書込コマンドは、ＳＲＡＭ  １３１０に記憶され、ＰＰＵ  １３１２と関連付けられる。複数の宛先ターゲットが存在する場合は、ＣＳＭ  １３０４は、各宛先ターゲット毎に提供される個々のＩＶＬＵに対して複数の書込コマンドを発行することも、宛先ターゲット毎に提供される１つ以上のＩＶＬＵの個々のメンバに対して１つ以上の書込コマンドを発行することもできる。書込コマンドは、入口ＰＰＵ  １３１２１において受信される。ＰＰＵ  １３１２は、ＩＶＬＵ（１）１３２２用に維持されているＶＴＤオブジェクトから宛先ターゲットＭ１の位置（例えば、ラインカードおよびポートの位置）を判定することができる。Ｍ１の位置が判定された後は、書込コマンドは、スイッチ・ファブリックを経てＰＰＵ  １３１４（宛先ターゲットＭ１に関連するＰＰＵ）に転送される。例えば、ＰＰＵ  １３１２は、書込コマンドのヘッダ情報を更新して、該当する宛先ラインカードおよびポートを指定することができる。ＶＬＵ  １３０６が２より多くのミラーリング・メンバを含んでいる場合は、ＰＰＵ  １３１２は、ミラーリングＶＬＵに関する各宛先ターゲットの位置を判定し、それらの各宛先ターゲットに書込コマンドを転送する。
【０１０１】
書込コマンドはまず、ＰＰＵ  １３１２の入口からスイッチ・ファブリックに送られる。図１３では論述を分かりやすくするために、トラフィック・マネージャやインターフェースなどのコンポーネントは省略されている。書込コマンドは、スイッチ・ファブリックを通過し、そこでＰＰＵ  １３１４へ経路指定される。書込コマンドは、出口ＰＰＵ  １３１４２において受信され、ＰＡＣＥ  １３１６に転送される。ＰＡＣＥ  １３１６は、そのコマンドをターゲットＭ１に転送し、ターゲットＭ１は、転送準備完了信号が書込コマンドに使用可能であるか否かを判定する。ターゲットＭ１が使用可能な転送準備完了信号を有する場合は、工程１２０８で、転送準備完了信号（例えば、ＸＦＥＲ＿ＲＤＹ情報単位またはＲ２Ｔパケット単位）が、ＰＡＣＥ  １３１６に返送される。転送準備完了信号のコマンド・フローは、図１３に示されているコマンド・フロー内に２で表されている。転送準備完了信号は、ＰＡＣＥ  １３１６からＰＰＵ  １３１４１を経てスイッチ・ファブリックに送られ、そこでＰＰＵ  １３１２２に戻るように経路指定される。ＰＰＵ  １３１２２は、転送準備完了信号をＣＳＭ  １３０４に返送することになる。
【０１０２】
ＣＳＭ  １３０４は、１つ（または複数）の各宛先ターゲットからの転送準備完了信号を受信するまで待った後で、ソース・ターゲットに対して読出コマンドを発行する。１つ（または複数）の宛先ターゲットに対してまず書込コマンドを発行することにより、一実施形態によるストレージ・スイッチは、データを受信する前に同期化すべきデータの内部フローを確立することができる。このようにすれば、バッファリングを伴わない場合にも、回線速度でソースから宛先にデータを成功裏に経路指定することが保証され得る。ソース・ターゲットからデータが読み出されたときに、そのデータを各宛先ターゲットが受信するのに使用可能となるように、ストレージ・スイッチは、各宛先ターゲットからの転送準備完了信号を受信するまで待った後で、ソース・ターゲットに対して読出コマンドを発行する。このようにすれば、ストレージ・スイッチは、１つ以上の宛先ターゲットから転送準備完了信号が返送されるのを待つ間に、ソース・ターゲットから読み出されたデータをバッファする必要がなくなる。データは、ソース・ターゲットから読み出されると同時に、各宛先ターゲットにマルチキャストされ得る。
【０１０３】
１つ（または複数）の各宛先ターゲットから転送準備完了信号が受信された後は、工程１２１０で、ＣＳＭ  １３０４は、ソース・ターゲットに対して読出コマンドを発行する。図１３のコマンド・フロー内に３で表される読出コマンドはまず、ＰＰＵ  １３１２１に送られる。ＰＰＵ  １３１２１は、読出コマンドをスイッチ・ファブリックに転送し、そこで読出コマンドが、ソース・ターゲットＭ０に接続されているＰＰＵ  １３１８へと経路指定される。工程１２１２で、ソース・ターゲットＭ０は、ＰＡＣＥ  １３２０から読出コマンドを受信し、読出データを返送する。工程１２１２において、一実施形態では工程１２０８で宛先ターゲットから返送された転送準備完了信号の指定する最小データ・サイズ（例えば、バースト長または所望のデータ長フィールド）に従って、１つ以上の読出データ・パケットが返送される。
【０１０４】
図１３に示されるコマンド・フロー内の４で示される読出データは、ソース・ターゲットＭ０からＰＡＣＥ  １３２０およびＰＰＵ  １３１８１を経て、スイッチ・ファブリックへと転送される。次いで、読出データは、スイッチ・ファブリックからＰＰＵ  １３１２へ経路指定される。読出データは、出口ＰＰＵ  １３１２２において受信される。工程１２１４で、ＰＰＵ  １３１２２は、１つ（または複数）の読出データ・パケットを１つ（または複数）の書込データ・パケットに変換する。一実施形態では、ＰＰＵ  １３１２は、それが書込データ・パケットであることが示されるようにパケットのローカル・ヘッダ情報を更新することができる。一実施形態では、ソース・ターゲットＭ０から読出パケットが受信されたときに、ＰＰＵ  １３１８は、割り振り済みのＥＴＣＢからＶＴＤ  ＩＤと、タスク・インデックスと、フローＩＤとを検索し、それらをローカル・ヘッダにコピーする。ＰＰＵ  １３１２２において読出データが受信されたときは、書込要求用に割り振られたＩＴＣＢが参照され、その割り振られたＩＴＣＢに対応する値を用いて読出データのヘッダ情報が更新される。ＦＣＰ−ＳＣＳＩでは、例えばＯＸ＿ＩＤ、ＲＸ＿ＩＤ、ＳＥＱ＿ＩＤ、ＳＥＱ＿ＣＮＴおよびＰＡＲＡＭを含む読出フレーム・ヘッダ・フィールドは、書込コマンドのＩＴＣＢおよびデータ・ストリームに対応する値に変換される。
【０１０５】
読出データが書込データに変換された後は、工程１２１６で、ＰＰＵ  １３１２２は、書込データを１つ（または複数）の宛先ターゲットに転送する。図１３のコマンド・フロー内の５で表される書込データはまず、ＰＰＵ  １３１２２からＰＡＣＥ  １３２２に送られる。ＰＡＣＥ  １３２２は、出口ＰＰＵ  １３１２２から受信されたデータを入口ＰＰＵ  １３１２１へ経路指定することが可能である。これにより、ＰＰＵ  １３１２が書込データをスイッチ・ファブリックに転送し、そこで書込データが１つ（または複数）の宛先ターゲットに関連する１つ（または複数）のＰＰＵへ経路指定され得るようにすることが可能になる。ＰＰＵ  １３１４は、スイッチ・ファブリックから書込データを受信し、ＰＡＣＥ  １３１６を介して、そのデータを宛先ターゲットＭ１に転送する。
【０１０６】
工程１２０８で、宛先ターゲットに対して発行された書込コマンドの全体のサイズを超えない所望のデータ長またはバースト・フィールド長を指定した転送準備完了信号が、宛先ターゲットから返送された場合は、書込コマンドに関するすべてのデータが１つ（または複数）の宛先ターゲットに供給されるまで、工程１２１０〜１２１６が繰り返され得ることが、当業者には理解されるであろう。ＣＳＭ  １３０４は、宛先ターゲットから受信された転送準備完了信号で指定されるバースト・サイズに従って、書込コマンドが満足されるまでソース・ターゲットに対して複数の読出コマンドを発行することが可能である。さらに、ＶＬＵ全体を同期化するために、宛先ターゲットに対して複数の書込コマンドが発行されてもよい。例えば、１２８Ｋなど制限された転送サイズ用の各書込コマンドが、発行されてもよい。したがって、１つのＶＬＵを同期化するのに、工程１２０６〜１２１６が複数回繰り返される可能性もある。
【０１０７】
前述のように、工程１２０４では、初期ミラー同期化を実施するためにストレージ・スイッチのどのＰＰＵにおいてＩＶＴが提供されてもよい。図１４は、ストレージ・スイッチ１４００を含む簡略ブロック図であり、ＩＶＴが１次ターゲット・メンバ（ソース・ターゲット）に関連するＰＰＵにおいて提供される一実装形態のコマンド・フローを示している。ミラーリング・ターゲット・メンバのデータの同期化を開始するために、ＣＳＭ  １４０４はまず、図１４のコマンド・フロー内の１で表される書込コマンドを宛先ターゲットＭ１に対して発行する。書込コマンドはまず、ソース・ターゲットＭ０に関連する入口ＰＰＵ  １４１２１に供給される。ＰＰＵ  １４１２１は、コマンドをスイッチ・ファブリックに転送し、そこでコマンドが、出口ＰＰＵ  １４１４２およびＰＡＣＥ  １４１６を経て宛先ターゲットＭ１へ経路指定される。宛先ターゲットＭ１は、書込データを受信するのに使用可能であるときは、転送準備完了信号をストレージ・スイッチ１４００に返送する。図１４のコマンド・フロー内の２で表される転送準備完了信号は、ＰＰＵ  １４１４１から出口ＰＰＵ  １４１２２を経て、ＣＳＭ  １４０４に戻るように経路指定される。ＣＳＭ  １４０４は、ミラーリング・ターゲットの１つ（または複数）の各宛先ターゲットから転送準備完了信号が返送されたときに、ソース・メンバに対して読出コマンドを発行する。ＣＳＭ  １４０４は、図１４のコマンド・フロー内の３で表される読出コマンドを入口ＰＰＵ  １４１２１に供給し、入口ＰＰＵ  １４１２１は、そのコマンドをスイッチ・ファブリックに転送する。読出コマンドの宛先（読出コマンドのローカル・ヘッダにコピーされるフローＩＤの形で指定され得る）は、ＰＰＵ  １４１２に関連するラインカードおよびポートにコマンドを経路指定するようトラフィック・マネージャに指令を出す。次いで、読出コマンドは、スイッチ・ファブリックから出口ＰＰＵ  １４１２２を経てソース・ターゲットＭ０へと経路指定される。次いで、ソース・ターゲットＭ０は、図１４のコマンド・フロー内の４で表される１つ以上の読出データ・パケットをＰＡＣＥ  １４２２に返送し、ＰＡＣＥ  １４２２は、そのパケットを入口ＰＰＵ  １４１２１に転送する。読出データは、入口ＰＰＵ  １４１２１からスイッチ・ファブリックを通過して出口ＰＰＵ  １４１２２に到着する。出口ＰＰＵ  １４１２２において、読出データは、図１４のコマンド・フロー内の５で表される書込データに変換され、次いでＰＡＣＥ
１４２２に戻るように転送される。前述のように、ＰＡＣＥ  １４２２は、書込データ・パケットをＰＰＵ  １４１２１に返送することができ、そこで書込データ・パケットが、スイッチ・ファブリックに転送され、出口ＰＰＵ  １４１４２およびＰＡＣＥ  １４１６を経て宛先ターゲット・メンバＭ１に到着する。
【０１０８】
［ミラー同期化検証］
ミラーリング仮想ターゲットのメンバの同期化に加えて、様々な実施形態によるストレージ・スイッチは、ミラーリング仮想ターゲットのメンバが同期化されていることを検証することもできる。ミラーリング仮想ターゲットのメンバが同期化されていることを検証するために、１つのメンバ・ターゲットのデータが読み出され、その他のメンバ・ターゲ
ットのデータと比較される。一実施形態によるストレージ・スイッチは、ソース・ターゲットから読み出され、１つ（または複数）のその他のメンバ・ターゲットのデータと比較されるデータをバッファすることなく、ミラーリング仮想ターゲットのメンバが同期化されていることを回線速度で検証することができる。
【０１０９】
図１５は、一実施形態に従ってミラーリング仮想ターゲットのメンバが同期化されていることを検証する流れ図であり、図１６は、ミラーリング仮想ターゲットが同期化されていることを検証するストレージ・スイッチ１５００と、コマンド・フローとを含む簡略ブロック図である。仮想ターゲット１６０６は、同期化を検証すべきメンバとして物理ターゲットＭ０，Ｍ１を含んでいる。工程１５０２で、例えば仮想ターゲット１６０６のメンバが同期化されていることを検証するユーザ要求が管理局から受信されたことに応答して、検証処理が開始する。一実施形態では、ＣＰＵ  １６０２は、ミラーリング・ターゲットの検証を管理する検証サービス・マネージャ（ＶＳＭ）１６０４を含む。工程１５０４で、ＶＳＭ  １６０４はまず、物理ターゲットＭ０に対応するＩＶＬＵ（０）１６２０と、物理ターゲットＭ１に対応するＩＶＬＵ（１）１６２２とを含むＩＶＴを提供する。ＶＳＭ  １６０４は、（例えば、検証開始時にユーザ指定が受信されたことに応答して）Ｍ０を１次メンバとして指定する。初期ミラー同期化の場合と同様に、ＩＶＴは、ストレージ・スイッチ１６００内のどのＰＰＵにおいて提供されてもよい。図１６の例では、ＩＶＴ  １６０８は、ソース・ターゲットＭ０に関連するＰＰＵにおいて提供される。ミラーリング・ターゲットが３つ以上の宛先ターゲットを含んでいる場合は、各宛先ターゲットをメンバとして含む単一のＩＶＬＵが提供されることも、１つ以上の宛先ターゲットをメンバとしてもつ複数のＩＶＬＵが提供されることもある。複数のターゲットを単一のＩＶＬＵのメンバとして提供することを含む一実施形態では、検証処理は、特定のターゲットの識別は行わず、メンバ・ターゲットの１つが同期化されていない状態を返送することしかできない。かかる一実施形態では、同期化検証の失敗は、各宛先ターゲットにデータが書き込まれるようにする単一のＩＶＬＵに、正しいデータを書き込むことによって訂正され得る。
【０１１０】
ＩＶＴ  １６０８が提供された後は、工程１５０６で、ＶＳＭ  １６０４は、図１６のコマンド・フロー内の１で表される書込コマンドまたは検証コマンドを宛先ターゲットに対して発行する。書込コマンドまたは検証コマンドは、図１４に関して前述したように経路指定され得る。ターゲットＭ０が使用可能な転送準備完了信号を有する場合は、工程１５０８で、図１６のコマンド・フロー内の２で表される転送準備完了信号が、ＶＳＭ  １６０４に返送される。転送準備完了信号は、宛先ターゲットが受信できる最大バーストまたはデータ長を指定することができる。各宛先ターゲットから転送準備完了信号が受信された後は、工程１５１０で、ＶＳＭ  １６０４は、図１６のコマンド・フロー内の３で表される読出コマンドを１次ターゲット・メンバに対して発行する。読出コマンドは、読出データを複数のターゲットと突き合わせて検証すべき場合に、各メンバ・ターゲットから受信される最小バーストまたはデータ長を指定することができる。工程１５１２で、ターゲットＭ０は、読出コマンドに応答して１つ以上のデータ・パケットをＰＰＵ  １６１２に返送する。読出データは、入口ＰＰＵ  １６１２１において受信され、スイッチ・ファブリックへと送られ、そこで出口ＰＰＵ  １６１２２に戻るように経路指定される。工程１５１４で、読出データは、出口ＰＰＵ  １６１２２において検証データに変換される。例えば、各読出データ・パケットのヘッダ情報は、そのデータが検証データであることが示されるように更新することができ（例えば、バイト・チェック要求（ｂｙｔｅ  ｃｈｅｃｋ  ｒｅｑｕｅｓｔ）を用いるＳＣＳＩ検証にヘッダ情報を変更することができ）、１つ（または複数）のメンバ・ターゲットを検証する宛先の識別が示されるように更新することもできる。ＰＰＵ  １６１２２において読出データが受信されたときは、書込要求用に割り振られたＩＴＣＢが参照され、その割り振られたＩＴＣＢに対応する値を用いて読出データのヘッダ情報が更新される。ＦＣＰ−ＳＣＳＩでは、例えばＯＸ＿ＩＤ、ＲＸ＿
ＩＤ、ＳＥＱ＿ＩＤ、ＳＥＱ＿ＣＮＴ、およびＰＡＲＡＭを含む読出フレーム・ヘッダ・フィールドは、書込コマンドまたは検証コマンドのＩＴＣＢおよびデータ・ストリームに対応する値に変換される。一実施形態では、ＰＰＵ  １６１２２は、データのバッファリングを伴うことなく、読出データを検証データに回線速度で変換する。読出データが検証データに変換された後は、検証データは、ＰＡＣＥ  １６２２を経てＰＰＵ  １６１２１に戻るように経路指定される。工程１５１６で、１つ（または複数）の検証データ・パケットが、スイッチ・ファブリックに送られ、宛先ターゲットＭ１に関連するＰＰＵ  １６１４１へ経路指定され得る。次いで、検証データは、１つ（または複数）の宛先ターゲットに供給され、各宛先ターゲットは、検証データをそれ自体の記憶データと比較して、データ同士が整合し、したがって宛先ターゲットがソース・ターゲットと同期化されているか否かを判定する。
【０１１１】
工程１５０８で、発行された検証コマンドの全体のサイズを超えないデータまたはバースト・フィールド長を指定した転送準備完了信号が、宛先ターゲットから返送された場合は、検証コマンドに関するすべてのデータが検証のために１つ（または複数）の宛先ターゲットへ供給されるまで、工程１５１０〜１５１６が繰り返され得ることが、当業者には理解されるであろう。ＶＳＭ  １６０４は、宛先ターゲットから受信された転送準備完了信号で指定されるバースト・サイズに従って、検証コマンドが満足されるまでソース・ターゲットに対して複数の読出コマンドを発行することが可能である。さらに、ＶＬＵ全体の同期化を検証するために、宛先ターゲットに対して複数の検証コマンドが発行されてもよい。例えば、１２８Ｋなど制限された転送サイズ用の各検証コマンドが、発行されてもよい。したがって、１つのＶＬＵを検証するのに、工程１５０６〜１５１６が複数回繰り返される可能性もある。
【０１１２】
一実施形態では、ラインカードのＣＰＵは、初期ミラー同期化を実施し、ソース・ターゲットから読み出されたデータを各宛先ターゲット用の書込データに変換することができる。さらに、ラインカードのＣＰＵは、ミラー同期化検証を実施し、読出データを検証データに変換することもできる。読出コマンドがソース・ターゲットに送られる前に、各ターゲットがデータを受信するのに使用可能であることを保証するために、ミラーリングＶＬＵの１つ（または複数）の宛先ターゲット・メンバに対してなおも書込コマンドが発行される。宛先ターゲットが使用可能な状態になるのを待つ間にスイッチ内でのデータのバッファリングを避けるために、ソース・ターゲットに対して読出コマンドを発行する前にスイッチ内の内部データ経路が確立され得る。
【０１１３】
例えば、図１４のブロック図（コマンド・フローではない）を参照すると、ＣＰＵ  １４１０は、各宛先物理ターゲットに書込コマンドを供給することによって、初期ミラー同期化またはミラー検証を開始することができる。一実施形態では、各書込コマンドは、それぞれのＰＰＵを経て経路指定されるのではなく、ＣＰＵ  １４１０から物理ターゲットに直接送られる。別の実施形態では、書込コマンドは、ＩＶＴが前述したように提供されるＰＰＵ（ミラーリングＶＬＵの１つ（または複数）のメンバに対応する１つ以上のＩＶＬＵを含む）に供給され得る。かかる一実施形態では、書込コマンドは、ＩＶＴの提供されているＰＰＵからそれ自体に関連するＰＰＵを経て、各宛先物理ターゲットへ経路指定されることになる。各物理ターゲットから転送準備完了信号が受信された後は、ＣＰＵ  １４１０は、ソース・ターゲットに対して読出コマンドを発行する。一実施形態では、１つ（または複数）の書込コマンドの場合と同様に、読出コマンドは、ＩＶＴの提供されているＰＰＵを経た後、ソース・ターゲットに関連するＰＰＵを経るように経路指定される。別の実施形態では、読出コマンドは、ＩＶＴの提供されているＰＰＵを通過することなく、それ自体に関連するＰＡＣＥを経てソース・ターゲットに直接送られる。ソース・ターゲットは、それと一緒に供給された転送準備完了信号で指定されるデータ転送長またはバースト長（すべての宛先メンバ・ターゲットによって指定される最小の長さであり得る
）に従って、１つ以上のデータ・パケットに応答することになる。図１３、１４、および１５に関して説明した処理とは対照的に、読出データは、ＩＶＴの提供されているＰＰＵへは経路指定されない。その代わりに、読出データは、ソース・ターゲットに関連するＰＡＣＥからＣＰＵ  ４１４へ直接経路指定される。ＣＰＵ  ４１４は、初期同期化が実施されたときは読出データが書込データに変換され、ミラー検証が実施されたときは読出データが検証データに変換されるように、１つ（または複数）の読出データ・パケットのヘッダ情報を更新することができる。次いで、書込データまたは検証データは、１つ（または複数）の宛先ターゲットに供給され得る。一実施形態では、書込データは直接、１つ（または複数）の宛先ターゲットに関連する１つ（または複数）のＰＡＣＥへ経路指定され、次いで１つ（または複数）の宛先ターゲットへ経路指定される。別の実施形態では、書込データまたは検証データは、ＩＶＴの提供されているＰＰＵに転送され、次いで１つ（または複数）の宛先ターゲットに関連する１つ（または複数）のＰＰＵを介して１つ（または複数）の宛先ターゲットへと転送される。
【０１１４】
書込コマンドは、各宛先ターゲットに対して発行され、ＣＰＵは、各宛先ターゲット・メンバからの転送準備完了信号を待った後で、ソース・ターゲットに対して読出コマンドを発行するので、１つ（または複数）の宛先ターゲットがデータを受信するのに使用可能な状態になるのを待つ間に、ＣＰＵにデータがバッファされることはない。ただし、読出データおよび書込データは、ソース・ターゲットに関連するＰＡＣＥから出ると、ＣＰＵ
１４１０との間の通常のコマンド・パスに入ることに留意すべきである。したがって、読出データ以前にＣＰＵコマンド・フローに入る他のタスクまたは要求をＣＰＵ  １４１０が処理している間に、該ＣＰＵにデータがバッファされる可能性もある。
【０１１５】
一実施形態によるストレージ・スイッチは、仮想ターゲットの初期ミラー同期化またはミラー同期化検証中に、イニシエータ側デバイスから入力コマンドを受け取ることもある。コマンドは、初期化または検証処理中にミラーリング仮想ターゲットの整合性および同期性を維持するために受信され処理され得る。一実施形態によれば、ビジー状態信号およびタスク・セット・フル状態信号を含めた故障応答が、仮想ターゲットに対してコマンドを発行したイニシエータ側デバイスに返送されないように、ミラーリング仮想ターゲットは、ミラー同期化または検証中に「オンライン」状態を維持することができる。このようにすれば、イニシエータがどのようなサービス損失も経験することなく、イニシエータの保留状態のコマンドを、初期ミラー同期化またはミラー検証と同時に発生させることが可能となる。図１７は、一実施形態に従ってミラーリング仮想ターゲットを対象とする初期ミラー同期化またはミラー同期化検証を実施している間に、該仮想ターゲットまたはＶＬＵに対する入力コマンドを処理する流れ図である。
【０１１６】
工程１７００で、前述したようなミラーリングＶＬＵの初期ミラー同期化または検証が開始する。工程１７０２で、１つ（または複数）の宛先ターゲットに対して、同期化または検証処理用の第１の書込コマンドまたは検証コマンドが発行される。工程１７０４では、工程１７０２で発行されたコマンドは依然として保留状態にあるが、同期化または検証される仮想ターゲットに対する書込コマンド、読出コマンド、または他のコマンドが受信されたか否かが判定される。コマンドが受信された場合にも、受信コマンドは、入口ＰＰＵからＶＬＵの各ターゲット・メンバに直ちに経路指定されるわけではない。その代わりに、入力コマンドが、同期化を管理するＣＳＭまたはＶＬＵの検証を管理するＶＳＭに経路指定され得る。工程１７０６で、入力コマンドは、ＣＳＭまたはＶＳＭによって待ち行列に入れられ得る。一実施形態では、入力コマンドは、（例えば、図３のＳＲＡＭ  ４１８などのローカル・メモリに記憶される）先入れ先出しバッファ内の待ち行列に入れられることもあり、したがって、それらが受信された順序で待ち行列から取り出され処理されることになる。工程１７０４で、コマンドが受信されていないことが判定された場合には、処理は直接、工程１７０８に進む。
【０１１７】
工程１７０８では、工程１７０２で発行されたコマンドが処理されたか否かが判定される。コマンドの処理が完了していない場合には、流れ図は、ミラーリングＶＬＵに対する追加のコマンドがイニシエータから受信されたか否かを判定する工程１７０４に進む。
【０１１８】
工程１７０８で、工程１７０２で発行されたコマンドが処理されていると判定されたときは、工程１７０２で発行されたコマンドを処理している間にミラーリングＶＬＵに対するコマンドがあれば、それらのコマンドが工程１７１０で待ち行列から取り出され、工程１７１２で処理される。一実施形態では、ＦＩＦＯの先頭がアクセスされ、その先頭のコマンドが工程１７１０で待ち行列から取り出され、工程１７１２で処理される。工程１７１４で、待ち行列内に追加のコマンドが存在するか否かが判定される。さらにコマンドが残っている場合には、もう１つのコマンドが、工程１７１０で待ち行列から取り出され、工程１７１２で処理される。待ち行列内のすべてのコマンドが処理された後は、処理は工程１７１６に進み、そこでは、同期化または検証を実施するために追加のコマンドを発行し処理する必要があるか否かが判定される。それ以上コマンドを発行する必要も処理する必要もない（例えば、すべてのソース・ターゲットのデータが１つ（または複数）の宛先ターゲットに書き込まれ、またはすべてのソース・ターゲットのデータが１つ（または複数）の宛先ターゲットと突き合わせて検証された）場合には、処理は工程１７１８で完了する。一方、ミラーリング・ターゲットを同期化しまたは検証するために、追加のコマンドを発行し処理する必要がある場合には、処理は引き続き、次のコマンドを発行する工程１７０２に進む。
【０１１９】
同期化または検証されるミラーリング・ターゲットに関して受信された入力コマンドを待ち行列に入れることにより、イニシエータ側デバイスからコマンドを受信している間に、同期化または検証が実施され得る。これにより、ミラーリング・ターゲットが処理中にオンライン状態を維持することができるようになるので、性能の向上をもたらすことが可能となる。イニシエータ側デバイスは、ミラーリング・ターゲットに由来する何らのサービス損失も経験しない。イニシエータ側デバイスにとってミラーリング・ターゲットが連続的に使用可能なものとして「見える」ように、入力コマンドは、同期化または検証用コマンドの合間に処理されることになる。
【０１２０】
本発明に関する上記の詳細な記載は、例示および説明のために提示されてきた。これは排他的なものではなく、開示の厳密な形態に本発明を限定するものでもない。上記の教示に照らせば多くの修正形態および変形形態が可能である。記載の諸実施形態は、本発明の諸原理および実際の応用例を最良の形で説明し、それにより、企図される特定の使用に適合するように様々な実施形態において様々な修正が加えられる本発明を、当業者が最良の形で利用できるようにするために選ばれたものである。本発明の範囲は、本願明細書に添付の特許請求の範囲およびそれらの等価物によって定義されるものとする。
【図面の簡単な説明】
【０１２１】
【図１】一実施形態によるストレージ・エリア・ネットワークの概略機能ブロック図。
【図２】一実施形態によるストレージ・スイッチの概略機能ブロック図。
【図３】一実施形態によるストレージ・スイッチ内で使用されるラインカードの概略機能ブロック図。
【図４】イニシエータ側デバイスから見ることのできる仮想ターゲットを示す概略機能ブロック図。
【図５ａ】仮想ターゲットの提供を例示的に示すストレージ・エリア・ネットワークの概略機能ブロック図。
【図５ｂ】仮想ターゲットの提供を例示的に示すストレージ・エリア・ネットワークの概略機能ブロック図。
【図５ｃ】仮想ターゲットの提供を例示的に示すストレージ・エリア・ネットワークの概略機能ブロック図。
【図６】一実施形態によるコマンド・パケットまたはフレームに関する入口方向の仮想化処理を示す流れ図。
【図７】一実施形態によるコマンド・パケットまたはフレームに関する出口方向の仮想化処理を示す流れ図。
【図８】一実施形態によるＲ２ＴまたはＸＦＥＲ＿ＲＤＹパケットあるいはフレームに関する入口方向の仮想化処理を示す流れ図。
【図９】一実施形態によるＲ２ＴまたはＸＦＥＲ＿ＲＤＹパケットあるいはフレームに関する出口方向の仮想化処理を示す流れ図。
【図１０】一実施形態による書込データ・パケットまたはフレームに関する入口方向の仮想化処理を示す流れ図。
【図１１】一実施形態による書込データ・パケットまたはフレームに関する出口方向の仮想化処理を示す流れ図。
【図１２】一実施形態による初期ミラー同期化処理の流れ図。
【図１３】一実施形態に従ってミラーリング仮想ターゲットのメンバを同期化するのに使用され得る、ストレージ・スイッチおよびコマンド・フローを含む概略ブロック図。
【図１４】一実施形態に従ってミラーリング仮想ターゲットのメンバを同期化するのに使用され得る、ストレージ・スイッチおよびコマンド・フローを含む概略ブロック図。
【図１５】一実施形態に従ってミラーリング仮想ターゲットのメンバが同期化されていることを検証する流れ図。
【図１６】ミラーリング仮想ターゲットが同期化されていることを検証するストレージ・スイッチと、コマンド・フローとを含む簡略ブロック図。
【図１７】一実施形態に従ってミラーリング仮想ターゲットを対象とする初期ミラー同期化またはミラー同期化検証を実施している間に、該仮想ターゲットに対する入力コマンドを処理する流れ図。
【図１】
2007535763.tif 000003
【図２】
2007535763.tif 000004
【図３】
2007535763.tif 000005
【図４】
2007535763.tif 000006
【図５ａ】
2007535763.tif 000007
【図５ｂ】
2007535763.tif 000008
【図５ｃ】
2007535763.tif 000009
【図６】
2007535763.tif 000010
【図７】
2007535763.tif 000011
【図８】
2007535763.tif 000012
【図９】
2007535763.tif 000013
【図１０】
2007535763.tif 000014
【図１１】
2007535763.tif 000015
【図１２】
2007535763.tif 000016
【図１３】
2007535763.tif 000017
【図１４】
2007535763.tif 000018
【図１５】
2007535763.tif 000019
【図１６】
2007535763.tif 000020
【図１７】
2007535763.tif 000021
【手続補正書】
【提出日】平成19年1月17日(2007.1.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ミラーリング・ターゲットを管理する方法であって、
１つ以上の宛先ターゲットに関するデータ受信の使用可能性を判定する使用可能性判定工程と、
同１つ以上の宛先ターゲットがデータを受信するのに使用可能であると判定されたときにだけ、ソース・ターゲットに読出コマンドを供給する読出コマンド供給工程と、からなる方法。
【請求項２】
使用可能性判定工程は、
前記１つ以上の宛先ターゲットに第１のコマンドを供給する工程と、
宛先ターゲットが転送準備完了信号を返送することによって、前記宛先ターゲットがデータを受信するのに使用可能な状態であることを判定する工程と、
を含む請求項１に記載の方法。
【請求項３】
前記ソース・ターゲットから読出データを受信する工程と、
読出データを書込データに変換する工程と、
書込データおよび書込コマンドを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項２に記載の方法。
【請求項４】
第１の内部仮想論理ユニットにおける第１の宛先ターゲットに対応する第１のメンバを提供する工程と、
第１の内部仮想論理ユニットにおける第２の宛先ターゲットに対応する第２のメンバを提供する工程と、を含む請求項３に記載の方法。
【請求項５】
ソース・ターゲットと、１つ以上の宛先ターゲットとを含むミラーリング・ターゲットを管理する装置であって、
同ソース・ターゲットおよび同１つ以上の宛先ターゲットと通信状態にあるポートと、
同ポートと通信状態にあり、同１つ以上の宛先ターゲットがデータを受信するのに使用可能な状態にあるときにだけ、同ソース・ターゲットに読出コマンドを供給する１つ以上の処理ユニットと、からなる装置。
【請求項６】
前記１つ以上の処理ユニットは、前記１つ以上の宛先ターゲットに第１のコマンドを供給し、前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定することにより、前記１つ以上の宛先ターゲットがデータを受信するのに使用可能な状態にあるか否かを判定する、請求項５に記載の装置。
【請求項７】
前記１つ以上の処理ユニットと通信状態にあり、前記１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニットと、前記ソース・ターゲットに対応する第２の内部仮想論理ユニットと、第２の宛先ターゲットに対応する第３の内部仮想論理ユニットとを含むメモリ、を含む請求項６に記載の装置。
【請求項８】
第２の処理ユニットを含むことと、
第２の処理ユニットは第１の内部仮想論理ユニットに対する第１のコマンドを第１の処理ユニットに供給することと、
第１の処理ユニットは前記１つ以上の宛先ターゲットに第１のコマンドを供給することと、
第２の処理ユニットは前記１つ以上の宛先ターゲットが転送準備完了信号を返送したか否かを判定することと、
第２の処理ユニットは前記１つ以上の宛先ターゲットが転送準備完了信号を返送したときに、読出コマンドを第１の処理ユニットに供給することと、を含む請求項７に記載の装置。
【請求項９】
ミラーリング・ターゲットを管理する方法であって、
同ミラーリング・ターゲットの１つ以上の宛先ターゲットに対応する第１の内部仮想論理ユニット（ＩＶＬＵ）を提供する第１ＩＶＬＵ提供工程と、
同ミラーリング・ターゲットのソース・ターゲットに対応する第２のＩＶＬＵとを提供する第２ＩＶＬＵ提供工程と、
第１のＩＶＬＵおよび同１つ以上の宛先ターゲットに第１のコマンドを供給する第１コマンド供給工程と、
同ソース・ターゲットから転送準備完了信号が受信されたときに、同ソース・ターゲットに対する読出コマンドを第２のＩＶＬＵに供給する読出コマンド供給工程と、からなる方法。
【請求項１０】
第１のコマンドは書込コマンドであることと、
読出コマンドに応答して前記ソース・ターゲットから読出データを受信する工程と、
読出データを書込データに変換する工程と、
書込データを前記１つ以上の宛先ターゲットに供給する工程と、を含む請求項９に記載の方法。
【国際調査報告】
2007535763.tif 000022