« 2015年3月 | メイン | 2015年5月 »

2015年4月

2015/04/29

【連載】第3回 始めてみよう!CommVault Simpana VMwareバックアップ編

第2回では、管理コンソールの起動、バックアップデバイスの登録、そしてファイルシステムのバックアップ方法をご説明しました。今回の第3回では、VMware vSphere 環境の仮想マシンのバックアップ方法について、ご紹介したいと思います。

 

VMware vSphere 環境の仮想マシンのバックアップについては、基本的には、2通りのバックアップ手法があります。1つ目の手法は、従来の物理サーバのバックアップと同様に、バックアップ対象の仮想マシンにエージェントをインストールしてバックアップする方法です。2つ目の手法は、仮想マシンのシステム障害などに備えて、仮想マシンとして全体のバックアップを取得する方法です。

 

バックアップ対象の仮想マシンにエージェントを導入するバックアップでは、ファイルのバックアップを取得するためのエージェント (FileSystem iDataAgent)や、アプリケーションをバックアップするための専用エージェント(Microsoft SQL Server iDataAgent 等)など、バックアップ対象に適した個々のデータのバックアップを取得することができます。

 

仮想マシン単位のバックアップでは、VMware が提供する vStorage APIs for Data Protection (VADP) 機能 (VMware の Change Block Tracking 機能を使用することで増分バックアップの組み合わせを実現可) と連携させて、仮想マシン全体のイメージバックアップを取得することができますので、仮想マシンのシステム障害が発生した場合には、仮想マシン全体のイメージバックアップからシステム復旧を行うことができます。

Vm

【仮想マシンのバックアップ手法】

 

また、仮想マシン単位のバックアップでは、Simpana のバックアップジョブの Granular Recovery オプション(詳細化オプション) を使用することによって、仮想マシンのイメージバックアップからファイル単位のリストアを行うこともできます。

 

VADP と連携するバックアップは、バックアップソフトウェアの一部としてツール(vSphere Virtual Disk Development Kit) 組み込まれており、仮想マシンを保護する専用のエージェントとして、Simpana を含む、他のバックアップソフトウェアでも同様に提供されています。Simpana の場合、Virtual Server Agent for VMware というエージェントを使用することで VMware vSphere 環境上の仮想マシンのバックアップを取得できます。

 

VADP と連携するツール vSphere Virtual Disk Development Kit (VDDK) は、バックアップソフトウェアの一部として組み込まれていますので、例えば、最新バージョンの vSphere 6.0 環境上の仮想マシンをバックアップするために、バックアップソフトウェア側のアップデートを待つ必要があります。Simpana の場合、手動で VDDK をアップデートすることがサポートされていますので、vSphere 6.0 をサポートする VDDK を個別にアップデートすれば、バックアップソフトウェア側のアップデートを待たず、バックアップを行えるようになります。
※Simpana パッチの適用で対応する場合もありますので、別途お問い合わせください。

 

それでは、Simpana の MediaAgent (バックアップサーバ) に Virtual Server Agent for VMware をインストールして、VMware vSphere 環境上の仮想マシンのバックアップを取得してみましょう!

続きを読む »

2015/04/28

PernixData FVPのパフォーマンス計測値を読み解く

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第4弾です。

本記事の原文はInterpreting Performance Metrics in PernixData FVPで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

御存知の通り、パフォーマンスチャートとグラフは単なる可愛らしい色のライン以上のものです。これらによって様々な知見を得ることができ、よりよい意思決定ができるようになるのです。しかし、正しくこれを理解できなかった場合、意味がなくなってしまいますし、悪い場合には完全にその徴候を見逃してしまいます。どのようにデータが表示されているかによっては、パフォーマンスグラフは素晴らしい物になりますし、逆に混乱をもたらす事にもなります。この2つの違いは非常に大きいです。

vSphereの環境ではあらゆるタイプのパフォーマンスグラフを取り回すための膨大な機会が与えられます。しかし、実際のデータをどう読み解くかというテクニックは殆どの場合語られません。ほとんど一目瞭然でしょう?という反論もあるかもしれません。しかし、実際にはうまく読み解くことができず、利用率が低下しているということがほとんどです。このパフォーマンスグラフの難しさに対しては、多くのソリューションがシンプルなダッシュボードのような治験を提供する心を見を行っています。これはスタートとしては悪くありません。しかし、これによってデータが少なくなってしまい、実際のパフォーマンスの状態を理解するのに必要な詳細情報が得られないこともあります。パフォーマンスに影響のある要素は複雑になることもあり、緑・黄・赤の識別子で得られる知見よりも、もっと長いサンプリング期間が必要なこともあります。

殆どの場合、vSphereの管理者は環境内の「長打者」をVMをCPUでソートすることで簡単に見つけ出すことができます。強力な攻撃を繰り出す仮想マシンを見つけ出し、そこからドリルダウンできるのです。vCenterは標準ではストレージI/Oに関するよいビジュアルプレゼンテーションを提供しません。ストレージのパフォーマンスは仮想環境における非常に多くのパフォーマンスの真犯人であるにも関わらず、面白いことです。PernixData FVPはストレージI/Oの高速化を行いますが、それだけではなく、ストレージI/Oの理解を助けるというこの空白も埋めてくれます。

FVPの計測はVMkernel統計を活用します、私はそれをより見やすくしてくれると思っています。ハイパーバイザーからレポートされるこの統計は仮想マシンそして、アプリケーションからみた情報を測定していますので非常に重要です。インフラストラクチャ内の他のコンポーネント(ストレージやネットワークファブリック、等々)は非常によいパフォーマンスの値を表示しますが、アプリケーションからどう見えているかということは教えてくれないということを覚えておいてください。

パフォーマンスの計測値を読み解くことは大きな問題です。この記事の目的はPernixData FVPのパフォーマンス計測値をより正確に読み解くためのいくつかのポイントをご紹介することです。

続きを読む »

2015/04/27

パート4 - ストレージコントローラーのアーキテクチャ

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPart 4 - Storage controller architectureで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

従来型ストレージによる仮想化データセンタの拡張性の問題シリーズのパート4へようこそ。本シリーズの前の記事ではネットワークトポロジーに着目し、帯域をクラスタリソースとして活用できないということと、次にリソースの管理と配置を分散して行えないことについて述べてきました。今回は従来型のストレージアーキテクチャにおけるストレージコントローラーの役割に着目します。

パート 1: イントロダクション

パート 2: ストレージエリアネットワークのトポロジー

パート 3: データパスはクラスタリソースとして管理されていない

一般的なサーバアーキテクチャとストレージコントローラーのアーキテクチャの根本は共通しています。このサーバは非常に多くのI/Oポートが接続されています。そのポートはバックエンドのディスクとの接続を確立するために利用されており、接続されたホストとの接続のフロントエンドインターフェイスとしての役割を行います。ストレージコントローラーではデータサービスとストレージ固有の機能を提供するプロプライエタリのソフトウェアが動作しています。

利用されているストレージのうちほとんどはストレージコントローラーが2つの4から8コアのCPUを保持する構成になっています。もちろん例外はありますが、今回は一般的な構成についてお話させてください。これは典型的な企業で使われているストレージは2つのストレージコントローラーに16から32コアを搭載しているということを意味します。これらのストレージコントローラーのCPUは何に使われるのでしょうか?今日のストレージコントローラーの役割は以下のとおりです。

  • データパスのセットアップと維持
  • Write-backキャッシュの冗長性とデータ可用性のための、ストレージコントローラー間でWriteのミラー
  • データの移動とデータの一元性
  • RAIDレベルの維持とパリティデータの計算と書き込み
  • スナップショットやレプリケーションなどのデータサービス
  • 重複排除や圧縮のような内部データ節約サービス
  • 多層化アルゴリズムの実行、適切な階層レベルへのデータの昇格や降格
  • ストレージの管理や監視を提供する管理ソフトウェアの統合

続きを読む »

2015/04/20

パート3 - データパスはクラスタリソースとして管理されていない

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPart 3 - Data path is not managed as a clustered resourceで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

従来型ストレージによる仮想化データセンタの拡張性の問題シリーズのパート3へようこそ。先日渡しはFASTプレゼンテーションについての記事 「FAST '15 での FVPの耐障害性Write-Backについてのプレゼンテーション」を公開しました。Ian Forbes氏がホスト間ネットワークと従来型SANがいずれも似たようなネットワークスピードで接続されている場合についてのスループットとレイテンシについての疑問を投げかけています。

パート 1: イントロダクション

パート 2: ストレージエリアネットワークのトポロジー

ESXiホスト間でのIOPSの分散

このシリーズの以前の記事で、アレイから提供されるIOPSはESXiホスト間で平等に分割されるとお伝えしました。実際には通常のアプリケーションの場合、そのアプリケーションの要求に応じてI/Oは様々になります。そしてそのせいでI/Oの要求はクラスタ内のすべてのホストで均一にバランスされることはありません。

仮想化データセンターはそれぞれのコンポーネントの異なるリソースのレイヤーから構成されており、それぞれでロードバランスアルゴリズムが利用されています。2009年にChad氏が典型的なストレージ環境におけるすべてのキューやバッファを表した素晴らしいダイヤグラムを公開しています。この素晴らしい記事をご参照ください。「VMware I/O queues, micro bursting and multipathing(VMwareのI/O キューと局所的なバースト、マルチパス-リンク先は英語)」

どのように仮想マシンの要求や重要度に応じて利用できるアレイに対するパスがロードバランスされていると保証できるのでしょうか?残念なことに今日の仮想化データセンターはこれらの異なるレイヤーに対するロードバランスの機能を持ちあわせておらず、ホットスポットを減らすことや、適切なワークロードの分散を行うことができません。それでは現在既存の仮想化データセンタ環境で利用可能なアルゴリズムの全てを詳しく見て行きましょう。

Fig220

続きを読む »

2015/04/13

従来型共有ストレージでの仮想化データセンターの拡張性についての問題 パート2

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVirtual Datacenter scaling problems with traditional shared storage - part 2で閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

多重化率

ほとんどの仮想化データセンタのアーキテクチャではESXiホストはグループを形成し、ネットワーク経由で中心のストレージアレイに接続されています。ストレージエリアネットワークの設計は大抵コアーエッジトポロジーを成しています。このネットワークトポロジーでは、少数の大きな収容量をもつコアスイッチがその中心に置かれます。ESXiホストはコアスイッチに直接接続されることもありますが、大抵の場合はエッジのスイッチに接続されます。スイッチ同士の接続がコアスイッチとエッジスイッチを結ぶのです。ストレージアレイについても同様の設計が行われています。直接コアスイッチに接続するか、エッジスイッチに接続されるかのいずれかです。

Fig217このネットワークトポロジーはネットワークの観点からは容易な拡張性を実現します。エッジスイッチ(ディストリビューションスイッチと呼ばれることもあります)はポート数の拡張に利用されます。コアスイッチは非常に強力ですが、それでもポート数に制限があります。されに、ネットワークトポロジーのそれぞれのレイヤーは設計上の役割を継承しています。エッジーコアトポロジーによって引き起こされる問題の一つとして、多重化率が挙げられます。これはいくつのエッジスイッチのポートが1つのコアの接続に利用されているかという数字です。システムの配置の設計によってこの問題は始まり、マルチホップになることでレイテンシを大きくしていきます。

レイテンシを下げるためにはホップの数を小さくする必要がありますが、これはポートの数に影響します(そして、接続するホストの数にも)。スイッチのポート数には限りがあるため、これによって利用可能な帯域に影響が出てきます。スイッチを追加してポート数を増やすことは、デバイスの配置の問題に跳ね返ってきます。レイテンシはアプリケーションのパフォーマンスに非常に大きく影響するため、ほとんどのストレージエリアネットワークは可能な限りフラットであるべきであると設計されています。ストレージレイヤーとホストのレイヤーが1つのスイッチレイヤーで接続されているようなケースも有ります。それではコンピューティングリソースのスケールアウトについてと、これによるネットワークトポロジーがどのようにストレージパフォーマンスに影響するのかを詳しく見て行きましょう:

続きを読む »

2015/04/06

従来型共有ストレージでの仮想化データセンターの拡張性についての問題 パート1

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVirtual Datacenter scaling problems with traditional shared storageで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

先日私はFASTのプレゼンテーションについての記事を公開しました。「FAST '15 での FVPの耐障害性Write-Backについてのプレゼンテーション」 Ian Forbesがこれについて以下の様な疑問を投げかけています:

質疑の時間に、だれかがとてもよい質問を投げかけています。PernixData社はWrite-Backとミラー接続構成はスループットとレイテンシにおいて、SANにWrite-Throughするのに比べてメリットがあると言っています。しかし、そういうWrite-Backの接続はIPネットワークを経由する必要があります。例えば、Write-Back接続ネットワークと同じIPネットワークを使うSANがオールフラッシュアレイでホストとNFSやiCSCIで接続されているとしましょう。この場合、Write-Throughも同じネットワークを経由します。この例において、Write-Throughに対するピア接続のあるWrite-Backの優位性はどこにあるのでしょうか?ボトルネック(IPネットワーク)はどちらの場合にも存在しているように見えます。

これは同じネットワーク設計のパラダイムを利用している場合にはまっとうな質問です。FVPのネットワーク設計パラダイムは共有ストレージとESXiホストを接続するエッジ-コアトポロジーではなく、ホスト-ホスト間接続にフォーカスしています。ホスト-ホスト間接続はアーキテクチャの迅速で簡単な拡張に向いています。ブロックのないポイント間接続は高速化された大容量のデータの処理を可能とします。ストレージコントローラーのポート密度が、従来型ストレージアーキテクチャの拡張性の制限になることはよくあることです。加えて、ストレージコントローラーの有限のCPUリソースがパフォーマンスに影響することもあります。仮想化データセンタの全体のロードバランシング機能を利用できないことで、利用できるリソースの効率性をも下げてしまうのです。

続きを読む »

2015/04/01

その名はVSPEX BLUE

こんにちわ、EMC担当の石塚です。エイプリルフールにブログを投下するとネタのように思われそうで迷ったのですが、気にせず始めたいと思います(笑)

弊社のVMware担当の三好も参加していた2月VMware PEXで発表されたEMC版EVO:RAIL「VSPEX BLUE」を皆さんはご存知でしょうか?

そもそもEVO:RAILはハイパーコンバージドインフラと呼ばれる垂直統合型システムインフラのジャンルに属するパッケージ製品のブランド名です。VMware社が策定した検証済みスペックを元にhp社やDELL社など各社がリリースしています。基本的なスペックは以下の通りです。

Blue_spec_2

既に米国のEMC Storeにも登場しています。

EMC VSPEX BLUE Hyper-Converged Appliance
https://store.emc.com/us/Product-Family/EMC-VSPEX-Products/EMC-VSPEX-BLUE-Hyper-Converged-Appliance/p/EMC-VSPEX-BLUE

どのベンダーからリリースされているEVO:RAILもこのスペックでリリースされています。ここで「だったらどこのベンダーのEVO:RAILを買っても同じものと言うこと?」と言う疑問が生まれます。しかも、EMC社にはVCEと言うコンバージドインフラは以前からありました。初めてEMC社がEVO:RAILをリリースすると聞いたとき、この疑問を担当者に質問したところ、当たり前だとは思いますが、ハードウェアスペックは全ベンダーで同じですが差別化要素はきちんとありました。

 

差別化ポイントその1:ゲストOS単位の保護機能

VSPEX BLUEにはいくつかのオプションがバンドルされていますが、その中でも特筆すべき機能があるのですが、そのなかでも 「RecoverPoint for Virtual Machines」のライセンス(15ゲストOS)がバンドルしている点に注目せざるを得ません。

RecoverPoint for Virtual MachinesはESXiサーバーのvmkernelにインストールする「スプリッタ」と呼ばれるモジュールと、vRPAと呼ばれる仮想アプライアンスで構成されます。スプリッタはゲストOSで生じた「書き込みIO」を検出し、データストアに書き込むのとともにvRPAにも書き込みIOを送信します。そして書き込みIOを受信したvRPAは過去に受信した事があるデータであるか判断し、新しいIOであれば保存し、以前にも受信したことがあるデータであれば重複排除処理を行って記録だけを保存します。この動作をほぼリアルタイムで行うことができます。つまり、書き込みの度に記録を取っている=書き込みの度にスナップショットを取得している状態です。

Rp4vm_2

管理出来るスナップショットはvRPAに割り当てている保存領域の容量次第なので1,000を超えることも容易に可能です。しかも、保護単位はゲストOS単位ですから、リストアもゲストOS単位です。リストアについても「リハーサル機能」があるので、完全なリストアを行う前に希望しているタイミングのものなのか確認することができます。これらの操作をvSphere Web Clientから行うことができます。

 

差別化ポイントその2:パブリッククラウドとも連携してハイブリッドクラウドが構築できる

EVO:RAILは内蔵ストレージでVSANを構成して運用することが基本になっています。ベンダー各社がそれぞれにストレージオプションを提供するようですが、VSPEX BLUEにはクラウド連携が可能なCloudArrayの10TBライセンスがバンドルされていいます。

CloudArrayは運用ボリューム上のデータをポリシーに従って、プライベートクラウドやパブリッククラウドへデータを転送できるソリューションです。例えばバックアップや災害対策であったり、容量の疑似的な拡張を実現できます。ユーザから見れば特に意識せず、プライベートクラウドとパブリッククラウドが連携した「ハイブリッドクラウド」が構成できます。オールインワンとしてリリースされているEVO:RAILなので、Software Defined Data Centerとしてはこのハイブリッドクラウドは魅力的かと思います。

 

差別化ポイントその3:VDPAで直接DataDomainへバックアップ

ここまではバンドルされている仮想アプライアンスでオールインワンパッケージになっている点についての差別化ポイントを紹介させて頂きましたが、外部連携オプションとして弊社のバックアップチームが支援させて頂いているDataDomainとの連携もサポートされています。 EVO:RAILはVMware Data Protection Advanced(VDPA)が利用可能です。 VDPAはEMC Avamarの仮想アプライアンスによって実装されているディスクへの重複排除バックアップソリューションであることはご存知かと思います。このVDPAとDataDomainを組み合わせると、VDPAアプライアンスを介さず、直接重複排除されたバックアップデータをDataDomainに保存することができます。また、バックアップデータを保存したDataDomainから別のDataDomainへのレプリケーションも可能です。当然、レプリケーションで転送されるデータも重複排除された状態ですから、転送量を最小限に抑えることが出来ます。バックアップデータをメインストレージとは別のシステムに保存するポリシーのユーザ様にとってはメリットの多いソリューションになります。

 

上記の3点以外にも、故障時にメーカーサポートへ自動的に通知し、オンサイト対応せずに迅速に故障個所を切り分け、調査を行うプロアクティブなサポートが可能なEMC Secure Remote Supportにも対応しています。 また、ロードマップ上ではEMCが得意とするハードウェアストレージのオプションも控えているようです。例えば超パフォーマンスを必要とするシステムなのであればXtremIOの選択の技術者視点からすると、とにかく早く触ってみたい!!と思います。インプレ、各種オプションの検証などをこの場でご提供したいと思っていますので、期待してお待ち下さい。