Release Notes

予期された動作
このセクションでは、metro node の予期された動作について説明します。
● メタデータ ボリュームやログ ボリュームなどのシステム ボリュームは、シン デバイスでサポートされています。一方、metro
node はこれらのボリュームを使用して、システム操作を行っています。スペース不足の状態を避けるには、すべてのエクステ
ントを事前に割り当てる必要があります。
● 各クラスターが互いに通信できる状態では、metro node は同じストレージ ボリュームが各クラスターから要求されないように
します。ただし、クラスターが区分化されている場合は、metro node は同じストレージ ボリュームが両方のクラスターから要
求されるのを防ぐことができません。この場合、metro node によってこの状況が検出されると、オートコールが送信されます。
それが検出されると、この問題は解決されます。
● コンシステンシー グループに属する分散デバイスの 1 つのボリュームが正常でなくなり、再構築とマークされた場合、正常で
ないボリュームを削除することができなくなります。分散コンシステンシー グループでは、2 つのボリュームの分散デバイス
メンバーが必要になります。この問題を避けるには、次の手順に従います。
1. attach mirror コマンドを使用して、新しいミラーを正常なボリュームに接続します。
2. 正常でない古いミラーを接続解除します。
● クラスターでメタデータの使用率が 90%を超えた場合、metro node によってオートコール イベントがトリガーされます。最初
のクラスターから 8 時間以内に、別のクラスターのメタデータも 90%を超えた場合、metro node によってオートコール イベン
トはトリガーされません。これは設計によるものであり、metro node Metro 構成で発生します。
● Unisphere では、Provision by pools ウィザードと Provision by Storage volumes ウィザードにより、storage-at-clusters プロパティ
に値が設定されたコンシステンシー グループのみを選択できます。
● データ移行時、または再構築時にホストの I/O パフォーマンスが影響を受ける場合は、デバイスの再構築の転送サイズ設定を
小さくするか、同時に実行する移行または再構築の数を減らします。詳細については、www.dell.com/support にある『metro ノ
ード機能の管理者ガイド』を参照してください。
● metro node システムにプロビジョニングされたパスの数を処理する十分なホスト リソースがあることを確認します。
● Metro 構成で WAN-COM リンクの QoS が低いと、極端な場合、動作が不安定になり、データ欠損になる可能性があります。
WAN-COM リンクを構成および監視するためのベスト プラクティスに従ってください。
● Metro 構成の metro node では、IP WAN COM リンクでネイティブな暗号化が提供されません。お客様は、クラスター間の IP
WAN リンクでデータの暗号化を実現するために、外部アプライアンスを展開する必要があります。
● 要求されたストレージ ボリュームが hardware dead になると、metro node によって 20 秒以内に、そのストレージ ボリューム
が自動的に調査されます。調査が成功すると、metro node によってボリュームから"dead"ステータスが削除され、正常稼働状
態に戻ります。
注意: デバイスが hardware dead の間は、metro node RAID 1 配下のストレージ ボリュームで、データを変更する操作を実
行しないでください（保守またはアレイ内のディスク交換など）。そのような操作が必要な場合は、最初にストレージ ボリ
ュームを metro node RAID 1 からデタッチし、データ変更操作を実行した後、metro node RAID 1 にストレージ ボリューム
を再追加します。また、必要に応じて、再構築をトリガーします。このステップに従わないと、metro node 配下のデータ
が、その認識なしに変更されます。データの再構築を行わないと、RAID 1 ボリュームで不整合が発生し、リザレクション
時にデータが破損する場合があります。
● システム ボリュームとして使用されるストレージ ボリューム（metro node メタボリュームの RAID 1 ミラー ボリューム、ログ
ボリューム、メタボリュームのバックアップ）は、metro node でシステム ボリュームとして使用される前に、フォーマットま
たはゼロ化される必要があります。
● バックエンド アレイのインタラクションについては、2 つのタイプの障害処理があります。
○ 明確な障害応答：バックエンド ファブリックから切断されているストレージ ボリュームまたはポートによるリクエストの
拒否など。
○ ストレージ アレイが障害モードになる条件：1 個以上のターゲット ポートがファブリックに残り、一方、それに対してイニ
シエーター（metro node）が送信したすべての SCSI コマンドがタイム アウトになる、など。
Metro node は、ファブリックに残っているものの応答しない状態のパスを分離します。この場合、ホスト イニシエーターによ
り、metro node 仮想ボリュームに対して送信された I/O リクエストは、応答しないパスからバックエンド アレイの応答するパ
スにリダイレクトされます。分離が実行されると、metro node はオートコール イベントを発令します。
● no-link ステータスのフロントエンド ポートに対して、 export port summary を実行すると、エクスポート ステータス
が suspended になります。
制限事項
このセクションには、metro ノードのリリース 7.0、パッチ、サービス パックの制限事項がリスト表示されています。
12 リリース ノート