仮想化デスクトップ構築講座

おかげさまで、データコアのトレーニングには沢山の方々にご参加いただき、DCSA、DCIE取得者も増えてまいりました。仮想化分野はこれからも発展する分野として、今後もエンジニアの方々のトレーニングが必要となるかと思います。データコアでは引き続き、ストレージの仮想化を皆様にご理解頂くため、トレーニングを継続してまいりますので、よろしくお願いいたします。

ところで、弊社とお取引いただいているネットワークデザイン株式会社様より、最近はやりのデスクトップ仮想化に関するトレーニングのご紹介をいただきました。短期集中型で価格もお手ごろとのことでした。今後、VDIも普及の兆しを見せており、ご興味のある方は下記をご覧の上、ネットワークデザイン様にお問い合わせください。「デスクトップ仮想化」「ストレージ仮想化」双方のトレーニングを受講いただき、両者を組み合わせたソリューションを是非研究してみてください。

仮想化デスクトップ環境構築 入門コース1日凝縮講座 http://www.networkdesign.jp/education/academy-mypchandson-beginner.html
仮想化デスクトップ環境構築 ベーシックコース1日凝縮講座 http://www.networkdesign.jp/education/academy-mypchandson-basic.html
仮想化デスクトップ環境構築 実践コース1日凝縮講座 http://www.networkdesign.jp/education/academy-mypchandson-advanced.html

iSCSIでミラーチャネル（ミラーパス）を設定するには - その2

FAQ1206にその詳細があります。
サポートサイトへのログオンアカウントがないと見ることができない情報です。

この情報はSANmelody2.xとSANsymphony6.xに関する情報になります。


iSCSIのタイムアウト値を60secから30secに変更することが推奨です。
これはDCIEのトレーニングでも設定するように促しています。
一般的にWindowsではディスクのタイムアウト値は60secですが、ミラーパスはそれよりも早くリンクダウンを検出したいというのが背景にあります。

まずはデータコアのサイトから
　DcsInstallTasks.exe
をダウンロードします

コマンドプロンプトから
DcsInstallTasks sanmelody base iscsitimeout
と実行します

もしSANsymphony環境なら
DcsInstallTasks sansymphony base iscsitimeout
です



余談ですが
ミラーパスはやはりファイバーチャネルが強い推奨です!

SANmelody3.0で1.17GB/sを見ました！

データコアではあまりパフォーマンスの話題をメーカーとして提供しないのですが...
（サーバ構成、バックエンドディスクの構成によって変わるため）

一昨日、訪問したお客様のパッケージシステムでパフォーマンス検証をされていて、あまりにも感動的なパフォーマンスを表示していたのでアップしました。


512バイトという小さなブロックのシーケンシャル書込で　100,000 iops
64kバイトという小さなブロックのランダム書込で　　　　　1.17GB/s
を叩きだしていました。はやい！

128kB シーケンシャルリード　90,000 iops 1.17GB/s
128kB ランダム　　　　リード　90,000 iops 1.17GB/s
シーケンシャル、ランダムでもほぼ変わらない?!

64kB ランダム 書込 1.17GB/s
1MB ランダム 書込 1.17GB/s
ブロックサイズが変わってもほぼ同じスループット?!


因みにざっと環境ですが
バックエンドディスクは
　3GbpsのSAS接続、SAS 12ドライブ
SMYサーバは
16GBメモリ搭載、フロントエンドには8Gbps FCを2本
IOをかけたアプリサーバは
　IBM System x3850
という感じです。


詳しいことを知りたい方にはこのパートナーさんを紹介します。

私が感嘆したのはバックエンドディスク3Gbp SASでもSMYを挟めばこんなにすばらしいパフォーマンスを出すことです。

1PBの仮想ディスクを認識させました

現行のSSY(SANsymphony)、SMY(SANmelody)でも1PBのバーチャルボリュームが年明けにサポートされるという開発計画は聞こえており、パートナーさんにもその旨を伝えてあります。


が、次期製品であるSANsymphony-??（正式名称はまだオフレコです）のα版のバイナリで1PBの仮想ディスクを作成してみました。
GPT変換すればWin2k8上から1ボリュームで1PBを認識しています！！
んんん、感動的です。



α版を評価してフィードバックできるプログラムを実施しております。興味のある方は
データコアに一報ください。
datacore-japan-sales@datacore.com
どしどし募集しております！

プールの容量管理とプール内ミラーのステータス

SP2(SANmelody 3.0.2)になってから
"Pools Performance"というＧＵＩが追加されました。
SANsymphonyでは以前からあったＧＵＩです。

このＧＵＩで確認できるのは
1. プールの空き容量、使用量、しきい値までを視覚的にわかる
2. PSP2から搭載されたプール内でのディスクミラーのステータスがわかる
　- raw ディスクのミラーの進行状況
　- ミラーの関係の情報
　- ミラーの構築/リカバリの状況

-メニューへのアクセス


-Pools PerformanceのGUI

PSP2のリリースでSANsymphonyに近づきました

データコア・ソフトウェア　SANmelodyの機能を大幅強化
―冗長性の強化と仮想ストレージへの容易な移行を実現―
http://japan.datacore.com/pressroom/pr_091105.asp


このリリースはSANmelody3.0のPSP2で5つの大きな機能強化がされました。 どれもこれもこれまではSANsymphonyのみでの機能でした。


1. プール内のディスクをミラー - お引っ越し機能 　
プール内にあるディスクをミラーさせることができます。ソフトウェアRAID1みたいな感じです。 　
用途としてはアプリサーバやバーチャルボリュームに影響を与えることなく、Melody配下で管理されているディスクアレイをオンラインで引っ越しできます 。











2. ミラーパスの冗長化（FCのみ） 　
これまではミラーボリュームごとにパスはひとつしかありませんでした。仮にミラーパスが複数本、SMY間に結線されていても任意のパスのひとつを選ぶだけでした。ミラーしたボリュームが複数あれば、ミラーパスの負荷分散でしかなかったのですが、PSP2からミラーパスも2重化させることができます 。









3. プロキシボリューム - 既存ディスクのお引っ越し 　
例えば既にUFSなどのファイルシステムでフォーマットされているディスクアレイをSMY配下に接続して、一度SMYでカプセル化、ラッピングされてバーチャルボリュームとして、今使っていたUNIXサーバに当該ボリュームをマップしてみせることができます。 　用途は既存ディスクアレイからの引っ越しです。Melody配下で管理されれば、スナップショット、HAによるミラーボリューム、AIMによる非同期IPミラーなど好き放題にデータ移行ができます


4. リカバリプライオリティ　-　リカバリの優先順位 　
HA構成でミラーボリュームが10個あるとします。さて、片ノードのディスクアレイに障害あって、全部リプレースされたとすれば、フルリカバリでもミラーが必要です。さて、どのボリュームから優先的にミラーの状態に回復してヘルシーになって欲しいか。データの重要性は重みがあるので、きっとDBは先に、メールは先に、ファイルサーバは後からなど優先順位がお客様によって違うと思います。



















5. スナップショットグループ
スナップショットはこれまでスナップショットセットを組んだ当該ボリュームに対してのみにアクションしかできませんでした（例えばEnable、CI、IU、SUなど）。スナップショットセットをまとめてひとつのグループとしてグループコマンドして同時にEnable、CI、IU、SUなどが実行できるようになりました。 　
用途は例えばデータベースなどではデータベースを構成するモジュールが複数のディスク（ボリューム）に保存される構成が組まれます。スナップを取りたいときはそれらをまとめてオペレーションしたいなどありますので、このグループ機能がとても役に立ちます。

管理容量の考え方

SANmelodyではサーバごとにその配下に管理される容量でライセンスを購入することになります。
例えば、SANmelodyをHA構成で導入したい。それぞれのMelody配下に2TBの物理リソースを管理したいならば
　ES3(2TBの物理リソース)
を2本必要とします。
SANmelodyサーバ1には　2TBの物理リソース
SANmelodyサーバ2には　2TBの物理リソース


ところでSANsymphonyでHA構成をする場合はリージョンワイドでの管理容量になります。
例えば8TB管理と16TB管理できるラインセンスを購入した場合、都合24TBになるので
　SANsymphonyサーバ1には　12TBの物理リソース　（こちらには8TB管理のライセンスがある）
　SANsymphonyサーバ2にも　12TBの物理リソース　（こちらには16TB管理のライセンスがある）
という構成が組めます。


つまりSANmelodyでHA構成（パートナ）を組んでも管理容量はシェアできないですが、SANsymphonyでは管理容量がシェアされることになります。
(SANsymphonyではリージョン内に一台でも無制限容量ライセンスがある場合、すべてのノードでUnlimitedのライセンスを購入する必要があります）



因みに管理容量としてカウントされるのはSANmelodyやSANsymphonyの管理下に入るタイミング、一番単純なのはプールにディスクをアサインした瞬間からともいえます。（またはパーティションボリュームをProtectした時から）
従って、上記のSANmelodyサーバのES3の例でみると、
　SANmelodyサーバ1に物理的に10TBぐらいディスクの管理から見えていても構わない。
　単にプールにディスクリソースを2TBまでしか参加させられない
ということです