2014/03/28

【デモ 7】VMware VAAIとの連携

今回は、VMwareのストレージオフロード、VAAIとの連携の一つをご紹介します。


動画は、ESXiのStorage vMotionを使ったFull Copyの連携です。

同一の仮想マシンをStorage vMotionを使い移動し、その際のESXiからのI/Oを比較しました。
vCenterのパフォーマンス表示でディスク性能を確認しています。

見ていただくとわかりますが、前半はVAAIを無効にしているためStorage vMotionの処理がESXi側で行われているのがわかります。後半はVAAIの連携を行い、Storage vMotionの処理がストレージ側へオフロードされ、ESXi側の処理が大幅に軽減されています。



全く違いますよね。

ちなみにSANsymphony-Vは、MicrosoftのODX (Offloaded Data Transfer ) もサポートしています。
こちらも改めて、ご紹介するつもりです!

2014/03/20

【デモ 6】Remote ReplicationによるDR

今回ご紹介するデモ動画は、リモートレプリケーションです。
DR(災害対策)で主に利用されます。

データコアでも、特に震災以降この機能を利用したDRのご相談は増えています。


通常ストレージベースでDRをやる場合は、双方のサイトにに同じストレージを要求します。
一般的にDRが可能なストレージは、製品、ソフトウェアともに高額な場合が多く、コストが大きなネックになりがちです。また、ストレージをリプレースするたびに、同等の機能に再投資して、再構築して、違った仕組みで運用する事にうんざりしている方も多いかもしれませんね。

SDSであるSANsymphony-VのRemote Replicationは、仮想ディスク間のレプリケーションなのでハードウェアの制約はありません。DRサイト側に極端に安価な全く異なったストレージを利用しても構成できる訳です。これもSDSならではのメリットですよね。


 
 
さて、動画ではリモートレプリケーションのセットを組み、DRサイト側でデータを確認するところまでをご覧いただけます。受信用の仮想ディスクは、そのままでは直接確認できないため、スナップショットを実行してデータを確認しています。
 
手順も非常にシンプルです。
予め、DRサイト側のDataCoreサーバを登録し、受信用の仮想ディスクを作成します。
次に送信用の仮想ディスクから、リモートレプリケーションの設定ウィザードで、双方の仮想ディスクのレプリケーションセットを組みます。
 
セットを組むと自動的に初期イニシャライズが始まります。
初期イニシャライズも、オンライン、オフラインの選択が可能になっているので、回線の帯域や転送データ量など、状況に応じて最適な方法を選択することができます。
 
どんなストレージ間でもレプリケーションが可能なので、いつでもDRをやりたい時に、必要最小限の投資でできるのもメリットですね。
 
従来のストレージベースのDRは、非常にハードウェアの制約が多いソリューションだったので、この機能もSDSならではと言えると思います。
 
安価に、継続的なDRの仕組みを作りたい方におすすめです。
 
 

2014/03/19

データセンターコンファレンスご来場御礼

データセンターコンファレンス 2014 Spring無事に終了いたしました。

お忙しい中ご来場いただいた皆さま、お名刺交換をさせていただいた皆さま、誠にありがとうございました。


自分のセッションと、ブログ、YouTubeの動画を連携させるつもりで、本日のセッションを企画したのですが、私の力不足もあり十分にお伝えできなかったかも知れません。

もう少し時間があれば…言い訳ですね。

このブログやYouTubeの動画などの追加コンテンツが、私のつたないご説明の補完になれば幸いです。

本日のセッションがご参加いただいた皆さまの少しでもお役にたてて、今後SANsymphony-Vが皆さまのストレージ環境を改善できれば、こんなに嬉しいことはありません。

本日はありがとうございました。

【デモ 5】SDS環境におけるストレージの移行

今回は、ストレージの移行に関するデモ動画を2本ご紹介します。

ストレージリソースがハードウェアである以上、避けて通れないのが老朽化とリプレースです。

最もストレージに限らずハードウェアのインフラは、5年前後のサイクルで永遠に入れ替え続けなければいけない訳ですが、その避けられないリプレースの負担をSDSであれば簡単にする事ができます。

今回は、その例をストレージ移行にフォーカスしてご覧いただきたいと思います。


まず、最初のデモ動画ですがプール内ミラーという機能を使い、ストレージプール内で古いリソースと新しいリソースをミラーしてしまいます。ミラーの定義はオンラインで可能となっており、仮想ディスクを使っているホストOSには全く影響がありません。

ミラー終了後、古いリソースをプールから取り外せば、簡単に古いリソースから新しいリソースへのデータ移行が完了します。




次に、SANsymphony-Vの環境では古いリソースをプールから取り除いてしまう事も可能です。
一時的にはプールの縮小になります。そのため取り除くためには、取り除くリソース上のデータを同一プール内で退避できる事が前提となります。

プールにオンラインで新しいリソースを追加することは非常に簡単にできるので、この機能と組み合わせれば、古いリソースを抜く、新しいリソースを加えるという一連の作業で、リプレースが完了することになります。

デモ動画は、古いリソースを抜いてから、新しいリソースを追加する順番で作業をしていますが、新しいリソースを追加してから、古いリソースを抜く事も可能ですし、その方が手順としては良いかも知れませんね。



いずれにしてもSANsymphony-V環境であれば、もうハードウェアの老朽化やそれに伴うリプレースの負担は、非常に軽減されます。これもSDSのメリットの一つです。


【デモ 4】CDPとロールバック

デモ第4弾CDPの動画をご紹介します。

普段お客様先などでデモをやっていても、非常に盛り上がる機能の一つです。

CDPはContinuous Data Protectionの略で、継続してデータを保護する仕組みです。
SANsymphony-Vの場合は、最長14日間の仮想ディスクの更新をブロックレベルで全てログしておき、後から任意の時点のロールバックボリュームを作り出す事ができます。



動画では、作成時刻の名前を付けたテキストファイルと、画像ファイルを使って2分前の状態までロールバックするデモをご覧いただけます。

CDPを使うには、予め仮想ディスクに"Data Protection"の設定を有効にしておく必要があります。
この際に"History Log"領域を決めるのですが、この容量を超えるまで、もしくは14日間というのがログの保存期間になります。また、プールへのI/Oを変更する関係上、ホストOSに提供したまま有効にすることはできないので注意が必要です。仮想ディスク作成時に有効にするか、既存の仮想ディスクに対しては、ホストOSから外して有効にし、再提供する事になります。

ロールバックボリュームの作成ウィザードで要求される主な設定項目は以下のとおりです。
  • 仮想ディスク名(ソースとなる仮想ディスク名に実行時間を加えた形で自動で定義されます。もちろん変更も可能です。)
  • ロールバック時間(秒単位での指定が可能です。)
  • ロールバックボリュームを作成するプールの指定
これだけで、保存期間内のどの時点の状態も作り出せるのです。

仕組みですが、ソースとなる仮想ディスクとHistory Log領域から透過的に指定した時点のイメージを作り出しています。そのため、必要な時にすぐに欲しい時点の状態が作れる訳です。

ロールバックボリュームから取り出せば特定ファイルやフォルダー配下のロールバックも可能ですし、アプリの障害などで数秒前に時点を作り出して調査する、復旧するなどの利用も可能です。

ブロックレベルでやっているので、特にOSやアプリケーションの制約もありません。

デモ動画でも落書きした画像ファイルが、2分前にロールバックして元通りになっているのが確認できますが、本当に便利です!

これぞSDSという機能の一つと思っていますが、いかがでしょうか?

【デモ 3】スナップショット(仮想ディスクの複製)


デモ動画第3弾は、Snapshotです。

一言でいうなら仮想ディスクの複製機能ですが、ソフトウェアのレイヤーで行うことで色々と面白い使い方ができる機能です。



動画では、差分スナップショットを作成し、ホストOSからファイルにアクセスするところまでをご覧いただけます。

スナップショット作成ウィザードの導線は、動画にもあるようにツールバーから、対象となる仮想ディスクの右クリックメニューから、対象となる仮想ディスクの情報ウィンドウ内のSnapshotタブからなど複数あります。このあたりは、全てのウィザードで共通の操作感なので、慣れていただくほど簡単になっていくと思います。

ウィザード上で要求される主な設定項目は以下のとおりです。
  • 仮想ディスク名(ソースとなる仮想ディスク名に実行時間を加えた形で自動で定義されます。もちろん変更も可能です。)
  • 実行するDataCoreサーバの指定(ミラーされてる場合は、2台のDataCoreサーバのうち好きなサーバを指定する事ができます。)
  • スナップショットのタイプ(差分かフル)
  • スナップショット先のプールの指定
  • OS管理情報の複製の有無(データだけではなく、OSの管理情報を複製するかしないかのオプションです。デフォルトは複製しない設定になっています。)
こんな項目を指定いただければ、簡単に複製が作れます。

デモ動画では、Tier PoolからSATA Poolにスナップショットを作成しています。
例えば、Tier Poolを構成しているストレージとは別のストレージでSATA Poolを構成していれば、物理的に全く違うストレージ上に複製を作れるという事です。

一般的なストレージのスナップショットやクローンの機能は、同一の筐体内で実施します。
そのため有用性の範囲や、構成面でどうしても制約が出てしまいます。

SANsymphony-Vのスナップショットは、全く自由です。ハードウェアの制約は一切ありません。
また、ソースとなる仮想ディスクとの関連性を切り離す(スプリット)ことで、独立した仮想ディスクとしてハンドルすることも可能です。

そのため、バックアップやリカバリポイントの保持という本来の目的だけでなく、移行やテンプレートとなる仮想ディスクの複製、検証用に本番と同様の複製を作成するなど、さまざまな用途が考えられます。


タスクによる簡易の自動化や、Windows PowerShellによる高度な実装、VSSによる連携など、運用形態に合わせて活用ができるのも魅力です。

今では、多くのお客様がご利用いただく機能になりました。


2014/03/13

【デモ 2】Create Virtual Disks

前回のデモ動画では、「Quick Serve」をご紹介しました。

今回の動画は「Create Virtual Disks」つまり仮想ディスクの作成です。
「Quick Serve」と違い、任意に細かい指定をしながら仮想ディスクを作成する方法です。とは言っても、ウィザード形式で進行するためあっけないほど簡単に仮想ディスクは作成できます。


動画では、1PBの仮想ディスク(シンプロビジョニングを使った仮想容量です。)をWindows Hostに提供するまでをご覧いただけます。

動画を見ていただくとわかりますが、仮想ディスクの作成ウィザードの起動には色々な導線があります。ツールバー、DataCoreパネルの「Virtual Disks」から右クリック、「Virtual Disks」の情報ウィンドウからリンクをクリックしての起動 などなど。
非常に直感的に操作ができるようになっています。

まず、Step 1は仮想ディスクのプロパティ設定です。

  • 仮想ディスク名
  • 仮想ディスクのタイプ(①シングル、②デュアル、③ミラーの3タイプから選択)
  • 仮想ディスクのサイズ(最大1024TB、つまり1PBまでの容量をサポート)
  • 同時に作成する数(最大100個の仮想ディスクを同時に作成)
  • 容量の予約(優先的なリソース割り当ての予約)
などを指定して、次のStepへ行きます。

次のStep 2はストレージソースのセットです。
SANsymphony-Vの仮想ディスクは、基本プールを使ってシンプロビジョニングで切り出されます。Step 1で決めたプロパティの仮想ディスクをどのプールから作るか、ここで設定します。

Step 1で指定したタイプによって、選択可能なプールが出てきます。デモ動画では、ミラーのタイプを選択しているため、冗長化された2台のDataCoreサーバの双方でプールを指定する事なります。画面には既に作成されているプールが候補としてプールのステータスと共に表示されています。
また、ここで新しいプールを作成するウィザードに入る事もできます。
デモ動画では、1PBの仮想ディスク3個を「Tier Pool」から作成しています。

Step 3はアドバンスドオプションです。
少し高度なオプション設定が可能です。詳細は、別途ご紹介します。

Step 3までを設定し「Finish」を押すと、仮想ディスクが作成されます。
デモ動画でも、左のDataCoreサーバパネル上で3つの仮想ディスクが作成されているのがわかります。「Quick Serve」との違いは、まだホストOSに提供されていない点です。

最後にホストOSへの提供ですが、提供したい仮想ディスクを右クリックし「Serve to Hosts」を選んでも良いのですが、デモ動画ではドラッグ&ドロップでホストOSに提供しています。
なおホストOSに提供前の仮想ディスクが、デモ動画上で「Unknown」→「Redundancy Failed」となっているのは、仮想ディスクの作成中→ミラーの初期同期というステップを踏んでいるからです。

ホストOSのWindowsのディスク管理で情報を更新すると、1PBのディスクが見えてきます。OSがGB表示なので、桁がエラい事になってますね!笑
ホストOSからは好きにフォーマットしていただければ、通常のローカルドライブと全く同じ様に利用できます。


シンプロビジョニングの仮想ディスクは、プールの容量を共有する事ができます。
共通の空き容量を持つ事で、ストレージの使用率を格段に向上させたり、いつでも好きなサイズの仮想ディスクが作成でき、壊せばリソースプールに戻るなど、リソース管理が非常に楽になります。

最近ではストレージにとって必須の機能ですね。
SANsymphony-Vの特徴としては、どんなリソースもプールに追加できる点です。追加できるリソースに制約がないため、拡張の容易性、自由なリソース選定が可能です。
SDSならではのメリットですね。