Pass-Through Diskをミラーセットした場合、相手側SSVサーバのDisk Poolの消費量は?

既存のディスクアレイなりストレージシステムが物理的な箱としてはひとつなので、物理的に2重化をして、ホストからパスを2重化することで、データのアクセスを止めないようにしたいというニーズが高まっています。

しかも既存のディスクアレイを活用して、今のホスト-ストレージ環境におおきな変更を加えずに実装できないかという要望があります。

そのような場合に、SANsymphony-VストレージハイパーバイザーのPass Through Diskという機能が有用です。

※SSV=SANsymphony-V

その実装の過程で質問があったのですが、

Q. 既存のストレージのLUNをSSV1号機でPass-Through Diskでvdisk化します。
　このvdiskをミラーセットした場合、相手側SSV2号機でのDisk Poolのアロケーション容量はどうなるか?

A. 例えば既存ディスアレイのLUNが10TB、”ブロック”使用量が5TBとします。
　ミラーセットするとSSV2号機のDisk Poolからは5TBのアロケーション容量になります。

注意点）
ここで”ブロック”と強調したのは、例えばファイルシステムとしては5TBを使用している認識でも、過去に7TBまで使用して、2TB削除した場合、ブロックレベルでは7TB使用していることになります。従ってこの状況でパススルーをしてミラーするとDiskPoolからは7TBのアロケーションが必要になります。
余分な2TBのアロケーションを防ぐためには
パススルーの事前に、ファイルシステムに対して”0書込”（WindowsであればSdeleteコマンドなどを使用）をすることが有効です。

VSSのDiskshadowでcreateコマンド発行後にフェイルする

ここ最近、同じような質問を受けました。

Windowsホスト上においてVSSを用いて、静止点を作成して、SSVのスナップショット連携したい。
手順に従って進め、最後に

createコマンドを発行したが、
どうやらフェイルしていると。


SSVのManagement Console（MC）でHost登録をした際の名前を確認してください。
WindowsホストのHostnameとMCで登録したホスト名が同じであることが必須です。

キャッシュサイズの変更後は再起動が不要

SSVではキャッシュサイズを変更できます。
しかし、その変更を反映させるためにはDataCoreサーバのサービスのStopおよびStartが必要になります。

注意が必要なオペレーションです。

ヘルプファイルで cacheで検索すると詳細が記載されています。

DataCoreのALUAサポートについて

DataCoreサーバはストレージコントローラのように振る舞います。

ALUAサポートという機能があり、ALUAとは何かという質問をよく受けます。


ALUAとは非対称論理ユニットアクセス（ALUA：Asymmetric Logical Unit Access）の略で、
SPC-3 に定義されたSCSI用語です。

DataCoreサーバをHAで構成した場合、アクティブ-アクティブのストレージコントローラのように動作すると理解ください。

IDCからストレージハイパーバイザー的なレポート

英語のレポートですが興味がある方は是非、どうぞ！

こちらからダウンロードできます。

リンクをクリックして、必要情報を入力するとダウンロードできます。

DataCoreを挟むと遅くなる？速くなる？

Q: SANsymphony-Vのソリューションは場合、ホストサーバとストレージとの間にDataCoreサーバによる仮想化レイヤが存在します、ストレージへの直接アクセスと比較してホストサーバからみたI/O処理能力低下しないでしょうか?

A: DataCoreサーバのオーバーヘッドつまり、I/O遅延といった質問はよくあります。
単純なSCSIのI/O処理の話しであれば、間に挟まるため確実に処理数は増えます。ただ、それを補って余りある、パフォーマンス効果があるため、全体としてはパフォーマンスが上がる仕組みになっています。

一番、大きいのはキャッシュの機能です。キャッシュは、I/Oの調整役として複数のWrite I/Oを取りまとめてバックエンドのストレージに書き込んだり、先読み（Pre-Fetch）の機能でRead I/Oの先読みを行う事で、応答性能を上げ
ています。

その他、IAサーバの高速CPUでI/O処理を行う点（一般的なストレージコントローラより、はるかに高速です）、I/O（コントローラ、LUN、チャネル）の分散処理（ストライピング）により、ハードウェアの性能を超えたパフォーマンスデザインができる等々、様々な効果で全体的な応答性能が上がる仕組
みです。

DataCoreの経験上、ざっくりReadは数百％、Writeは百数十％くらいは上がっているのが一般的です。Writeの効果が少し低いのは、ストレージのI/O性能は最終的には、バックエンドのリソース（HDD）に依存するからです。

Brodade社製FC HBAをホストに使用する場合

DataCoreサーバのTargetポートにEmulexのFC HBAで、
ホスト側のInitiatorポートにBrocadeのFC HBAという構成を組む場合、
今日時点（2011年7月1日）では既知の問題があります。

BroadeのFCポートで以下のコマンドを実行して、フレーム最大サイズを2048に変更してください

bcu port --dfsize 1/1 2048
bcu port --dsiable 1/1
bcu port --enable 1/1