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までしか参加させられない
ということです

次期製品はSANsymphony-??

データコアではネイティブ64bitでコーディングされたストレージ仮想化ソフトウェアを開発中です。
リリース時期は未だ明らかにはなってはいないのですが...



開発コード名はVirtuoso（イタリア語が語源のようで、その意味は(芸術の)名人，大家，巨匠，(特に音楽の技巧上の)名手と辞書にありました）。

製品名はSANsymphony-(ここにアルファベットが一文字)になりそう。



ここから本題なのですが、データコアでは新製品の使用性、使用感を評価して頂ける人柱を募集します。
日本人の鷲の目で事前に評価頂いて製品にフィードバックを反映するプログラムです。
コミュニティ・テクノロジー・プレビューというプログラム名でで期間は今日から年末まで。


もし、興味があれば是非、データコアに一報ください。
datacore-japan-sales@datacore.com
どしどし募集しております！