Release Notes
Table Of Contents
予期された動作
このセクションでは、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 プロパティ
に値が設定されたコンシステンシー グループのみを選択できます。
● CLARiiON™ Navisphere Management Suite を使用すると、LUN のアクティブなストレージ プロセッサー(SP)を変更する場合
に、metro node のユーザー インターフェイスで、不正な SP がアクティブとして報告されることがあります。たとえば、実際に
は SPB がアクティブである場合に、SPA がアクティブと報告される場合があります。この不正確な報告を修正するには、I/O
を起動します。I/O が開始した後で、システムはアクティブな SP を認識し、それを正しく報告します。
● データ移行時、または再構築時にホストの I/O パフォーマンスが影響を受ける場合は、デバイスの再構築の転送サイズ設定を小
さくするか、同時に実行する移行または再構築の数を減らします。
● 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 ボリュームで不整合が発生し、リザレクション
時にデータが破損する場合があります。
● デフォルトでは、管理サーバーで作成されたすべてのユーザーで、直近の 91 日間でパスワードが変更されていないユーザーは、
アカウントがロックされます。admin ユーザー アカウントはロックされませんが、admin ユーザーは次回のログイン時に、パス
ワードを変更するように強制されます。アカウントのロックを解消するには、SolVe Desktop トラブルシューティング セクショ
ンの「パスワード ポリシー」セクションを参照してください。サービスユーザーには、ポリシーは強制されません。
● システム ボリュームとして使用されるストレージ ボリューム(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 になります。
リリース ノート 9