VSSのDiskShadow内でCreateコマンドが成功しない

下記のようなエラーが出た場合、

DISKSHADOW> create

COM 呼び出し "m_pVssBackup->AddToSnapshotSet" に失敗しました。

直前の操作が失敗しました。
- 返された HRESULT: 80042306
- エラー テキスト: VSS_E_PROVIDER_VETO

DISKSHADOW>


確認したいことは、HIK（ホストインテグレーションきっと）をインストールしたWindowsホスト上での設定です。

ヘルプファイルからの抜粋ですが
・Volume Shadow Copyサービスが開始していること
・DiskShadowコマンドを実行するコマンドプロンプトを管理者モードで実行
・ユーザアカウント制御を使用している場合、「管理者承認モードですべての管理者を実行する」を無効にする

を確認してください。

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

ESXホスト接続のDataCoreサーバでリクラメーションするには

リクラメーションに関してはFAQ578のTB16に紹介されています
http://datacore.custhelp.com/app/answers/detail/a_id/578

TB16は下記よりダウンロードできます
ftp://support.datacore.com/psp/TBs/TB16_NMV_Reclaim_Unused_Space.pdf


下記にESX環境での手法を簡単に箇条書きにしました。参考にしてください

方法その1　- ESXのGuest OS(仮想マシン)上で0書込みして、クリーンアップする方法
1. Guest OS上で0を書き込む（Windowsであればsdeleteを用いて）
2. Vmkfstools -w を実行
3. DcsNmvCleanup を実行（SSVの場合 Reclamation の実行）


方法その2　-　vmfs上に目一杯、空のvmdkを作成し、クリーンアップする方法
1. vmkfstools -c -d eagerzeroedthick /vmfs/volumes//.vmdk
ダミーのvmdkを作成することでVMFSを完全に埋め尽くす
2. 当該vvolにDcsNmvCleanupを実行（SSVの場合 Reclamation の実行）
3. そのvmdkファイルを削除

パートナー(HA)を組んだSANmelody間でApplyができない

FAQ1165にチェック項目があります。
http://datacore.custhelp.com/app/answers/detail/a_id/1165/kw/1165

一度ご確認願います。

DataCore MPIO 3.0 PSP2でCore対応しました

SANsymphony-V R8のリリースと合わせてDataCore MPIO 3.0 PSP2がリリースされました。
またDataCore MPIOは無料のソフトウェアとなりました!!
ダウンロードはこちらから

詳細はリリースノートを参照して欲しいのですが以下の点がアップデートです。
- SANsymphony-Vをサポート
- Windows Server2008 R2のコアインストールホスト（アプリサーバ）上へのインストール
です。

注意点はこのコアインストールのWindowsホストにvDisk（またはvVOL）を提供した場合、
その都度情報のアップデートのため、
Get-dcsmpioinfo.ps1
というスクリプトを実行する必要があります。

イベントログは何行保存されるのか、また別に保存できるのか？

SANsymphony-Vに関する情報です。

ヘルプファイルの
Event Log and Alerts
に記載されています。


おおよそ100,000メッセージまたは1GBに達した時点で全て削除されます。

削除される前にSANsymphonyフォルダ配下に下記のようなファイルで吐き出されます。
Dcsx_log_2010_10_12_09_24_40.sdf
Dcsx_log_ の後がタイムスタンプになっています。
上記の例だと 2010年10月12日9時24分40秒です。

レプリケーションで使用するポートは何番?

いよいよSANsymphony-V R8がリリースされました。
初のSSVに関するブログはレプリケーションです。

レプリケーションで使用するポート番号は
3793番です。
FireWallでポート3793は開けてください。

因みにSSVのヘルプの目次で
Windows Security Setting Disclosure
を確認すると記載されています。

3793番ポートを使用するのはDataCore Executive Serviceです。
レプリケーション以外にも
・コンフィグ情報交換の通信用
・管理コンソールとの通信用
・サポートバンドルのアップロード
にも使用します。