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

2016年4月

2016/04/27

ネットワールド、Veeam 始めるってよ

 弊社では色々なメーカーのバックアップソフトを扱っておりますが、この度、新たなメーカーのバックアップソフトが加わることになりました。そのメーカーとは Veeam Software です!下記のプレスリリースで発表されています。

https://www.veeam.com/news/veeam-expands-into-japan-to-deliver-availability-for-the-always-on-enterprise.html

そこで、今回はVeeam Softwareとバックアップソフトをご紹介しましょう。

 

①  Veeam Softwareとは

Veeam社の本社はスイスのバールにあり、仮想環境向けデータ保護と監視ツールを提供するソフトウェアベンダーです。2006年の設立から約10年が経ちますが、売り上げと顧客数を急速に伸ばしています。

Veeam01

②  主力製品について

主力製品はデータ保護製品のVeeam Backup & Replicationと監視ツールのVeeam ONEです。また、この2つがセットになったVeeam Availability Suite もあります。

Veeam03

Veeam Backup & Replicationはバージョンアップを重ね、ユーザーが望む多くの機能を実装してきました。そして、今年1月には新バージョンとなる v9 をリリースしています。

Veeam04_3

 

③  特徴的な機能

この製品が他のバックアップソフトと何が違うのかが気になると思います。細かな違いは多々ありますが、特徴的な機能をいくつかご紹介します。

 (1)ストレージ・スナップショットとの統合
vSphereの仮想マシンのバックアップでは、vStorage API for Dada Protection(以下、VADP)を使用しますが、VADPによるスナップショットではバックアップ中の変更量に応じてログファイルのサイズが大きくなっていくため、バックアップ時間が長くなった場合や変更量が多い場合はスナッショット領域が肥大化してしまいます。

また、スナップショットを削除する際にはマージ(結合)処理が伴いますが、ログファイルが大きくなると、マージ処理に時間がかかったり、不安定になることもあります。

Veeam Backup & Replicationでは、この問題を解決するためにストレージ(NetApp,HP StoreVirtual/StoreServ,EMC VNX/VNXe)とのスナップショット連携機能を提供しています。vSphere上でスナップショットを作成した後、ストレージのスナップショットを作成し、すぐにvSphere上のスナップショットを削除することでスナップショットを保持する時間を短くすることができます。

Veeam05

更に、NetAppのストレージの場合、SnapMirror/SnapVaultと連携することが可能で、SnapMirrorのレプリケーション先・SnapVaultのバックアップ先からバックアップすることでプライマリストレージに影響を与えることなくバックアップできます。vSphere のデータストアとしてNetAppを利用している方には最適です。

Veeam06

ちなみに、次期バージョン(9.5)では、Nimble Storageとのストレージ連携ができるようになる予定ですので、ご期待ください。
https://www.veeam.com/blog/integration-nimble-storage-veeam-availability-suite.html

 (2)アプリケーション対応
VADPでのバックアップはエージェントレスでのバックアップになりますが、VeeamBackup & Replicationはアプリケーション(Active Directory,MSSQL,SharePoint,Exchange,Oracle)を意識したバックアップが可能です。他社のバックアップ製品でも同様の機能を提供しているものはありますが、VMware ToolsのVSSに依存していたり、仮想マシンへエージェントのインストールが必要になります。

それに対して、VeeamBackup & Replication VMware ToolsのVSSインテグレーションコンポーネントは使用せず、Veeamが独自実装したMicrosoftのVSSインテグレーションを使用し、エージェントレスでのアプリケーションを意識したバックアップが可能です。 

Veeam07 

また、VADPのバックアップからのアプリケーションのオブジェクト単位のリストアに対応しているバックアップソフトはいくつかありますが、MS SQL Serverについては、テーブル単位のリストアのリストアも可能で、更に他社ではまだ実現できていない?Oracleのリストアにも対応しています。

 (3)重複排除ストレージとの連携
Veeam Backup & Replicationのバックアップデータ先(リポジトリ)としては、Windows・Linux・NAS(CIFS)・テープなど多くの種類に対応していますが、その中でもバックアップのパフォーマンスが良いのが、EMC DataDomainやHP StoreOnceの重複排除ストレージと組み合わせた場合です。

EMC DataDomainやHP StoreOnceをCIFSとして利用しても良いのですが、Data DomainのDD BoostやStoreOnceのCatalystといったソースサイド重複排除機能を利用すれば、プロキシサーバ上で重複排除を行い、重複排除された(最適化された)データのみをバックアップストレージに送信することで、低速リンク経由でもバックアップデバイスへ高速にデータを送信できます。

Veeam09

通常、DD BoostやStoreOnce Catalystを使う場合は専用のPluginを各メーカーのサイトからダウンロードしてインスト-ルする必要がありますが、Veeam Backup & ReplicationはPluginが予めインストールされていますので、すぐに利用することができます。

尚、Data DomainはDDOS 5.4~5.7まで、StoreOnceはOS 3.13.1以降が対応しております。
https://helpcenter.veeam.com/backup/vsphere/system_requirements.html#target

 (4)セルフサービス機能

日々のバックアップは管理者がスケジュールでバックアップしていても、仮想マシンやその中のファイルをリストアすることになった場合、ユーザーが管理者に連絡してリストアしてもらうのは、管理者・ユーザーのどちらにとっても手間のかかる作業です。

Veeam Backup & ReplicationはEnterprise Managerでのセルフサービスによるリストア機能を提供しています。セルフサービスによりユーザーは専用のリストアポータルサイトにアクセスすることで、仮想マシン単位・ファイル単位・アプリケーション単位のリストアが可能になり、管理者・ユーザー両者の負荷を軽減させることができます。

Veeam10

 

④  価格体系

ライセンスはCPUソケット単位の課金でStandard/Enterprise/Enterprise Plusの3つのエディションと小規模環境向け(6ソケットまで)のEssentialsがあります。エディションによって使える機能が異なり、例えば、前述のストレージ連携をする場合は、Enterprise Plusが必要になります。

※エディション比較表

https://www.veeam.com/jp/backup-version-standard-enterprise-editions-comparison.html


以上、今回は簡単にご紹介させていただきましたが、他にも色々な魅力的な機能がありますので、仮想環境のバックアップにお悩みの方やVeeam製品が気になって夜も眠れない方は、下記までお気軽にお問合せください。

Email :veeam-info@networld.co.jpPropartner_logo_distr_img

担当:臼井

2016/04/25

実況中継!? VSAN 6.2 中の人によるふかーい話 (パフォーマンス編・中編)

みなさん、こんにちわ。本記事は「実況中継!? VSAN 6.2 中の人によるふかーい話」の続編にあたります。

以前の記事はこちらです。

本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。

実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる~い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。

トランザクショナルワークロードでのIOPS

Fig393

DVD StoreはTPC-Cのようなワークロードで、DVDのオンラインショッピングで顧客がDVDを購入するというトランザクションを発生させるツールです。そしてBrokerageはTPC-Eのようなワークロードで証券マンが顧客の要望を元にトレーディングを行うようなトランザクションを模したものとなります。分析を行ったり、株式マーケットのシステムとも統合されているものです。

DVD Storeの処理はCPUで多くのことが行われさほどIOはかかりません。結果はすべての機能を有効にしたとしても殆ど変わらないということが出来ます。

Brokerageの場合は小さなサイズのIOが高いIOPSで処理されます。ベースラインは40,000IOPSですが、圧縮処理とイレイジャーコーディングで25,000IOPSほどまで性能が劣化しています。エンドユーザーとしては選択肢が用意されます。つまりパフォーマンスを取るか、キャパシティを優先して効率化機能を利用するかどうかです。パフォーマンスは崖から落ちるような具合には劣化はしません。

会場より : 重複排除で大体25%ぐらいの劣化ということですね。

その通りです。このワークロードでは非常に重複排除のコストが高かったです。基本的にこうしたワークロードでは重複排除での削減効果あまりないはずです。(補足:実際には重複排除と圧縮の機能を切り離して有効にすることはできません。また、後のスライドで容量削減効果のスライドが出てきますが、そこではベンチマークであるがゆえにそこそこの効果を得られていますが、実際の環境では重複排除効果はここで言うように小さなものになるはずです。)

トランザクショナルワークロードでのレイテンシ

Fig394

DVD Storeの場合のレイテンシは2ミリ秒~3ミリ秒の間で様々な機能の有効/無効はほとんど影響がありませんでした。

一方でBrokerageを利用した場合、1ミリ秒ほどだったレイテンシがすべてを有効にすると6ミリ秒近くまで上昇しています。先ほどのスライドであらかた予想できたことですが、その通りになっています。

会場より : そうすると、クラスタ単位で重複排除するのではなく、アプリケーションごとに選べるようにしたほうが良かったのでは?

そうすると、今度は別のパラメーターを考えなくてはいけなくなり、複雑になってしまいます・・・。

トランザクショナルワークロードでのCPU利用率

Fig395

DVD StoreはCPUを多く利用しますが、IOのためにそれが使われているということはなく、機能を有効にしてもほとんど代わりはありません。3%~4.2%程度で一貫しています。

Brokerageの方では20%近くのCPU負荷がかかっています。そしてCPUの負荷は70%程度に下がってしまっています。どうしてでしょうか?これはレイテンシが高いためにIOをそれ以上押しこむことができなくなっているからです。ですからCPUの負荷が下がっているのです。

会場より : とすると、単独のIOあたりの負荷は変わっていなくて、IOが少なくなった分負荷が下がっているだけなのか・・・。(訳注: VSANのIO処理が増えているのではなく、CPU全体の利用率が下がっているため、割合としてVSANのCPU利用率が増えているということです。)

そのとおりです!

トランザクショナルワークロードでの容量削減効果

Fig396

これについてはさほど詳しくお話するつもりはありません。(訳注: ベンチマークテストゆえの結果であり、実際の環境の値ではこれと大きく異る可能性があります。)

DVD Storeの場合75%ほどの容量削減効果が得られています。実際のデータセットを考えれば予想ができる数字です。

Brokerageの方も同様です。実際のデータセットのサイズを反映した値になっています。

さて、次でいよいよ最後です。次回は障害発生時のパフォーマンスについての内容です。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/04/18

実況中継!? VSAN 6.2 中の人によるふかーい話 (パフォーマンス編・前編)

みなさん、こんにちわ。本記事は前回の「実況中継!? VSAN 6.2 中の人によるふかーい話 (容量効率化編)」の続編にあたります。

本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。

実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる~い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。

検証環境

今回の検証結果は全てこの4台のクラスタにおける結果を利用しています。

Fig388

パフォーマンスの劣化はありません。

6.1から6.2になりましたが、チェックサムの機能を有効にしてもパフォーマンスの劣化はありません。6.2で一部のデータパスを最適化したため、むしろレイテンシが良くなっている場合もあります。

Fig389

新しいデータサービスによるパフォーマンスへの影響は?

容量効率化の機能はどのようにパフォーマンスへ影響するかです。レイテンシやIOPSはもちろん、CPUの利用率も見ていきます。統合率への影響がもっとも重要ですからね。

サマリとしては以下のことがいえます :

重複排除によってTCOを劇的に削減しながら・・・

  • 高いIOPSと低レイテンシーを維持している
  • CPUのオーバヘッドを最小限に保っている(オンデマンドでのみ利用する)
  • 重複排除は非常に効率的である

ではVDIのケースを見ていきましょう

6.1はベースラインです。6.2はチェックサム機能が追加されています。6.2+R5はイレイジャーコーディングを利用し、6.2+Dは重複排除と圧縮を有効にしています。そしてすべての機能をOnにした場合の値も表示しています。

Fig390

グラフは短いほうがパフォーマンスが良いということです。これはレイテンシを表示しており、実際のユーザーが体感した時間を表しています。View Plannerを利用していますのでファイルを保存したり、なにか書き込んだりということをやっています。グループA(青い棒グラフ)はさほどI/Oを利用しない作業を行っている想定です。こちらではほとんど差がでません。もっとI/Oを利用するグループBにおいては4.3秒だったレイテンシが5.1秒までしか上昇していません。すべての機能がOnになってですよ!!

さて、これはCPUにどのような影響を及ぼしているでしょうか?

VDIの場合、サーバには詰め込める限りの数の仮想マシンを詰め込みます。今回の場合、1ホストあたり145台の仮想マシンが動作しています。青の棒グラフはホスト全体のCPUの利用率を表しています。見ての通りほぼ全てを使いきっています。

Fig391

そしてVSAN 6.1ではわずか0.5%のCPUを利用しているに過ぎません。チェックサムやそれ以外の6.2の機能を全て利用してもこの値は1.4%程度になるだけです。

会場から: ほとんど3倍になっているじゃないか!!(笑)

重要なのはVDIを利用する際に(他のソリューションのように)サーバの能力のうち4分の1を割り当てるなどする必要はないということです。仮想マシンの統合率に全く影響がないというのは重要な事です。

これには私もびっくりでした!

こんなにも効果があると思っていなかったのでテストを3回もやらせたぐらいです。これはリンククローンでの結果です。145台の4倍の数の仮想マシンが動作しています。この青い棒グラフは物理的な容量を表しています。

Fig392

重複排除は非常に有効です。そしてRAID-5でもう少し効率化がなされます。面白いことにベースディスクが1つで後はデルタ(差分)なのですが、デルタ内に多くの重複があるということです。

会場より : パッチの火曜日の後は、すごいだろうね。

もちろんです、それから今回はView Plannerを利用していますので各々の仮想マシン内では同じようなデータの更新が行われているという点もあると思います。

こういうデータを出してしまうと過剰に反応してしまう人もいますし、業界はこうした結果であふれています。実際にはコミュニティの紡ぎだした数字を使うのが良いでしょう。

中編に続きます。次回はトランザクショナルなワークロードについてのパフォーマンスについての内容です。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/04/12

ついに日本国内リリースされたVxRAIL【セットアップ編】

 こんにちは、石塚です。VxRail国内リリースから1か月が経ちましたが、リリース直後から多くのお客様からお問い合わせを頂いています。 やはりハイパーコンバージドは注目株なのは間違いありませんね。

 

 今回も前回に引き続きVxRailについてご紹介したいと思います。今回取り上げるテーマは「簡単導入は本当なのか!?」です。 前回のなかでもご紹介しましたが、簡単且つスマートで確実なインストールが可能と謳われています。 しかし、実際にVxRailをまだ見たことの無い方にとっては「本当か?」とか「何をもって簡単と言っているんだ?」などの疑問があるかと思います。 今回は長文にはなってしまうのですが、スクリーンショットを多く使い、「この記事さえ読めば誰でもVxRailを構築できる」と言うレベルを目指してご紹介したいと思います。

 

作業の前に準備するもの

 イキナリ箱を開けても何となーく導入できるぐらい簡単なのですが、クッキング番組のようにまずは予め準備頂きたいものをご説明します。

 まずはハードウェアとして準備頂くもののリストです。

  1. VxRail(1箱にアプライアンス本体、電源ケーブル、ベゼルがまとめられています)
  2. 10Gbスイッチ(アプライアンス毎に8つのポートが必要です)
  3. 10Gbスイッチに適合したケーブル×8つ
  4. 200V電源ポート×2つ
  5. Windows PC(ブラウザとしてFirefoxもしくはChromeをインストール済み)

 

 ここでポイントになるのは10Gbスイッチです。 VMware Virtual SANの場合、強い推奨となっている10Gbスイッチですが、VxRailの場合は各ノードごとに搭載されている10Gbポート×2つで全てのデータ通信を行うので「10Gbスイッチは必須」になっています。 例外的にVxRail60だけは1Gb×4つで構成されています。 また、この10Gbスイッチの構成には必ず以下の構成をお願いしています。

  • Default VLANを構成して下さい(恒久的に利用します)
  • 全てのノード間の管理セグメントにはマルチキャスト通信が必要です
  • 全てのノード間のVSANセグメントにはマルチキャスト通信が必要です

 上記3点はアプライアンスの増設時に追加されるアプライアンスを検出するためと、VSANの要件になっています。 EMC社が提供しているVDX6740B(Brocade OEMの10Gbスイッチ)については、細かい導入ガイドがあり、サンプル構成ファイルもあるのでこちらを参照すると分かりやすいかと思います。 この資料はEVO:RAILシリーズのころのものですが、VxRailでも同様なのでご安心下さい。 VDXであれば10Gbスイッチも含めて一元保守になりますね。 また、導入手順書を作成するツール(SolveDesktop)にはCisco Nexusについての構成も同様に構成方法が掲載されています。

01_2

 SFP+モデルの場合のケーブルの種類ですが、これは接続する10Gbスイッチ側の要件を確認して準備下さい。 VxRailはアクティブケーブルでもパッシブケーブルでもサポートされています。 ※VDXをお使いになられる場合はアクティブケーブルになります。

 続いてご質問の多い電源仕様です。 大容量メモリを搭載した4つのサーバが動いていますので、現時点では200Vが必要になっています。 これもVxRail60だけは例外的に100Vでもサポートされています。

 環境的な最後の準備はセットアップするWindows PCについてです。 ブラウザとしてFirefoxもしくはChromeを準備して下さい。Internet Exploreでは正常に実行できないことがあります。 VxRailの工場出荷時のIPアドレスは192.168.10.200になっています。同セグメントが存在している場合はIPが重複しないか確認をして下さい。また、デフォルトのIPに接続し、そして実運用のIPへそのまま接続することになるので、セットアップするWindows PCには実運用のIPアドレスに疎通可能なIPアドレスと、VxRail工場出荷デフォルトIPに接続可能なIPアドレス(例えば192.168.10.210など)の両方のIPアドレスを設定して下さい。

02

 上記の例では実運用セグメントのIPとして10.10.50.101/16が設定されていて、セットアップ用セグメントのIPとして192.168.10.210/24を割り当てています。

 続いて、準備するパラメータについては以下の通りです。

<システムパラメータ>

  1. NTPサーバ
  2. DNSサーバ
  3. オプション)Active Directory情報(ドメイン名, ユーザ名, パスワード)
  4. オプション)HTTPプロキシ情報(プロキシサーバIPアドレス, ポート番号, ユーザ名, パスワード)

<管理パラメータ>

  1. ESXiのホスト情報(ホスト名(1から始まる通し番号になります))
  2. vCenterホスト名
  3. VxRail Managerのホスト名(VxRailの管理GUIを提供するゲストOSのホスト名)
  4. ESXiの管理IPアドレス(4つ以上の通し番号)
  5. vCenterのIPアドレス(ESXiの管理IPアドレスと同セグメント)
  6. VxRail ManagerのIPアドレス(ESXiの管理IPアドレスと同セグメント)
  7. 上記の管理IPセグメントのネットマスク
  8. 同管理IPセグメントのゲートウェイ
  9. ESXiのパスワード
    ※複雑性を求められ、特定の記号(&’”;=`\$)は利用できません。
     また、キーフレーズ及びそれに類するものも利用できません。
     例えば Welc0me1! のような複雑性が必要になります。

 

<vMotionパラメータ>

  1. ESXiのvMotion用IPアドレス(4つ以上の通し番号)
  2. 同vMotionセグメントのネットマスク
  3. 同vMotionセグメントのVLAN ID

 

<Virtual SANパラメータ>

  1. ESXiのVirtual SAN用IPアドレス(4つ以上の通し番号)
  2. 同Virtual SANセグメントのネットマスク
  3. 同Virtual SANセグメントのVLAN ID

 

<仮想マシンネットワークパラメータ>

  1. 仮想マシンネットワーク名(仮想スイッチポートグループ名)
  2. 仮想マシンネットワークのVLAN ID

 

<ソリューションパラメータ>

  1. ログサーバ(vRealize Log Insight(バンドル済み)もしくはSyslog)の選択
  2. ログサーバのホスト名
  3. ログサーバのIPアドレス
  4. VxRail Manager ExtensionのIPアドレス(ハードウェア監視するためのゲストOSのIPアドレス)

 以上が必要になるパラメータの全てです。

 これらを以降で紹介する初期セットアップウィザードで入力するだけで、vSphere、vCenter、仮想スイッチ、vMotion、Virtual SAN、Log Insightなど全ての初期セットアップが完了します。ボタンを押せばあとは15分待つだけです!

それではセットアップ開始!

 必要なハードウェア、10Gbスイッチの構成、パラメータの準備ができたら、あとは箱を開けてセットアップするだけです。このステップでのポイントは電源をノード#4 ⇒ ノード#3 ⇒ ノード#2 ⇒ ノード#1の順番で起動する、と言う流れです。そしてそれぞれのノードは15秒程度の間隔をあけて起動して下さい。あとは5分程度待てばセットアップが開始できるようになります。

 

 まず、初期セットアップ用のIPアドレスである192.168.10.200/24」にブラウザで接続します。

03

 上記のようなウェルカムページが表示されます。注目すべきはこの時点で日本語であることです。 セットアップからしてグラフィカルで、且つ日本語が使えると言うのは管理者様にとって本当に優しいと思います。「開始する」ボタンをクリックして次へ進みます。

04

 毎度おなじみ使用許諾についての条件書が提示されます。 一読して右下の「同意する」をクリックして下さい。

05

 前述の各種準備についての確認ページです。 10Gbスイッチの構成、VLANの構成(管理用のDefault VLAN、vMotion、Virtual SAN各VLAN)が完了していることを確認したらそれぞれのチェックボックスをクリックしてマーキング(例のようにチェックボックスが青く変化します)して、右下の「次へ」ボタンをクリックして下さい。

 

0502

 続いてセットアップの方法を選択します。 通常はウィザードに則ってセットアップすると思いますので、「ステップバイステップ」をクリックします。

06_2

 まずはシステムパラメータを入力します。 前述の準備で決定しているパラメータを適宜入力して下さい。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<システムパラメータ>

  1. NTPサーバ
  2. DNSサーバ
  3. オプション)Active Directory情報(ドメイン名, ユーザ名, パスワード)
  4. オプション)HTTPプロキシ情報(プロキシサーバIPアドレス, ポート番号, ユーザ名, パスワード)

07_2

 続いて管理パラメータです。 前述の準備で決定しているパラメータを適宜入力して下さい。 現バージョン(3.0.0)の場合はホスト名はショートネーム(ホスト部)での入力になります。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<管理パラメータ>

  1. ESXiのホスト情報(ホスト名(1から始まる通し番号になります))
  2. vCenterホスト名
  3. VxRail Managerのホスト名(VxRailの管理GUIを提供するゲストOSのホスト名)
  4. ESXiの管理IPアドレス(4つ以上の通し番号)
  5. vCenterのIPアドレス(ESXiの管理IPアドレスと同セグメント)
  6. VxRail ManagerのIPアドレス(ESXiの管理IPアドレスと同セグメント)
  7. 上記の管理IPセグメントのネットマスク
  8. 同管理IPセグメントのゲートウェイ
  9. ESXiのパスワード
    ※複雑性を求められます。
     特定の記号( & ’ ” ; = ` \ $ )は利用できません。
     キーフレーズ及びそれに類するものも利用できません。
     上記を踏まえると、例えば Welc0me1! のような複雑性が必要になります。

08

 続いてvMotionパラメータです。 前述の準備で決定しているパラメータを適宜入力して下さい。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<vMotionパラメータ>

  1. ESXiのvMotion用IPアドレス(4つ以上の通し番号)
  2. 同vMotionセグメントのネットマスク
  3. 同vMotionセグメントのVLAN ID

 

09

 同様にVirtual SANパラメータです。 前述の準備で決定しているパラメータを適宜入力して下さい。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<Virtual SANパラメータ>

  1. ESXiのVirtual SAN用IPアドレス(4つ以上の通し番号)
  2. 同Virtual SANセグメントのネットマスク
  3. 同Virtual SANセグメントのVLAN ID

 

10

 あともう一息です。 今度は仮想マシンネットワークパラメータです。 前述の準備で決定しているパラメータを適宜入力して下さい。 3つ以上のセグメントを構成しておきたい場合はページ下部にある「もう1つ追加」をクリックして必要セグメントを追加登録して下さい。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<仮想マシンネットワークパラメータ>

  1. 仮想マシンネットワーク名(仮想スイッチポートグループ名)
  2. 仮想マシンネットワークのVLAN ID

 

11

 入力作業の最後はソリューションパラメータです。 前述の準備で決定しているパラメータを適宜入力して下さい。 入力が終わったら右下の「次へ」ボタンをクリックして下さい。

<ソリューションパラメータ>

  1. ログサーバ(vRealize Log Insight(バンドル済み)もしくはSyslog)の選択
  2. ログサーバのホスト名
  3. ログサーバのIPアドレス
  4. VxRail Manager ExtensionのIPアドレス(ハードウェア監視するためのゲストOSのIPアドレス)

 

12

 全てのページに必要なパラメータを入力したら「検証」ボタンをクリックして正当性を確認します。

 

13

 このようなエラーが表示された場合、該当パラメータを確認したり、環境状態を確認するなどの対処を行って、再度「検証」を行って下さい。 トラブルシューティングの材料としては、左下にある「ログを表示」をクリックするとバックグラウンドで行っている内容(どこに何を行っているか)が分かります。

 

14

 無事、検証がクリアされると「VxRAILの構築」ボタンをクリックしてセットアップを開始します。

 

15

 このページで「構成の開始」ボタンをクリックすることでセットアップが開始されます。 表示されている通り、実運用IPアドレスにリダイレクトされますので、アクセスできる状態が必要になります。(作業前に2つのIPアドレスを設定しているのはこのためです。)

 

16

 現在セットアップしている状況は上記のように把握できます。 セットアップの内容としては以下の通りです。 これら31ステップの作業を全自動で、しかもたったの15分で行っているのですから、これはどう考えても楽チンですよね!

<VxRailの初期セットアップの内容>

  1. Setup password on VxRail Manager VM
  2. Configure VxRail Manager VM Hostname
  3. Install private DNS(dnsmasq) on VxRail Manager VM
  4. Configure private DNS(dnsmasq) on VxRaill Manager VM
  5. Perform vCenter Server first boot configuration
  6. Install private DNS(dnsmasq) on vCenter
  7. Configure private DNS(dnsmasq) on vCenter
  8. Setup management network ESXi hosts
  9. Configure NTP on ESXi Hosts
  10. Configure Syslog in ESXi hosts
  11. Configure Syslog in vCenter
  12. Configure Syslog in VxRail Manager VM
  13. Restart Loudmouth in VxRail Manager VM
  14. Create Service Account on vCenter
  15. Register ESXi hosts with vCenter
  16. Setup ESXi hostname
  17. Create Distributed Switch
  18. Register ESXi hosts with Distributed Switch
  19. Create Distributed Portgroup
  20. Configure ESX Networking
    Management, vMotion, VM networks on vmnic0, and VSAN Networking on vmnic1 in an Active/Standby configuration on a single Standard Switch)
  21. Rename “VM Network” to be “vCenter Server Network”
  22. Remove standard Switch
  23. Setup DNS on ESXi host to use DNS(dnsmasq) on vCenter
  24. Restart Loudmouth on ESXi hosts
  25. Create Storage Policy for VSAN with vCenter
  26. Rename VSAN Datastore from vsanDatastore to MARVIN-Virtual-SAN-Datastore
  27. Set vCenter to auto-start
  28. Enabled Enhanced vMotion Compatibility
  29. Configure ESXi root password
  30. Initialize vCenter licensing ready for Product Activation Code(PAC)
  31. Enable HA

 3分クッキングよろしく、15分経って以下のように完了メッセージが出たら右下の「VXRAILの管理」ボタンをクリックして下さい。

17 15分待てば出来上がり!

 

 VxRail Managerと呼ばれている統合管理GUIのログイン画面が表示されます。 ここでは管理者アカウント(administrator@vsphere.local)と先に入力したvCenterへのパスワードを入力して「認証」ボタンをクリックして下さい。

18 まずは administrator@vsphere.local でログインします

 

 色々触って確認したいところですが、最後にVxRail ManagerとVxRail Manager Extensionを連携させる儀式が残っています。 右側にあるメニュー一覧から「EXT」をクリックし、続いて右下にある「VXRAIL MANAGER EXTENSION」ボタンをクリックして下さい。

 

19 もう1ステップだけセットアップが残ってます。

 まず、毎度おなじみ使用許諾が表示されるので、一読して「同意する」ボタンをクリックして下さい。

 

20 毎度おなじみ使用許諾画面

 

 

 続いて中央に見えている「これで完了です!」ボタンをクリックして下さい。

 

21 ここでも日本語表示が当たり前。

 物理的な管理及び、メーカサポートとの連携のためのVxRail Manager Extensionを構成するためのパラメータを入力します。

 

22

<VxRail Manager Extensionパラメータ>

  1. vCenter IPアドレス
  2. DNSサーバ情報(オプション)
    ※オプションとなっていますが、インターネット連係が必要なので
     管理ネットワーク上のDNSサーバを指定して下さい
  3. vCenterのrootパスワード
  4. ESXiのrootパスワード

 入力が終わったら左下にある「送信」ボタンをクリックして数分待ちます。 以下のようにVxRail Manager Extensionのログイン画面が表示されたら本当の完了です。 念のためVxRail Managerと同じように administrator@vsphere.local でログインを確認して下さい。

 

23 念のため administrator@vsphere.local でログインできるか確認しましょう

 

 これにてセットアップは終了です。 事前準備さえ終わっていれば、箱を開けてから実質1時間程度で仮想インフラが完成します。 ゲストOSを作成することも可能ですし、vMotionやHA、DRSも構成済みの状態です。

 

 今回はスクリーンショットを多用したため長編大作気味になってしまいましたが、やっていることは本当にシンプルで、作業内容自体は簡単なものになっています。 仮想インフラの構築はここまでシンプル且つスピーディに行えるようになった、と感じて頂けたら嬉しいです。

 

 次回は日常運用のお話として、ゲストOSの作成手順やステータスの確認やログの採取手順をご紹介しようと思います。

 

 

2016/04/11

PernixData Architectでブロックサイズの影響を見る

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

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

本記事の原文はViewing the impact of block sizes with PernixData Architectで閲覧可能です。

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

仮想化環境のブロックサイズについて理解する という記事で、ブロックサイズがどういったものであるか、そして、それがストレージI/Oにどのように影響するのかということ、そして、どうしてそれが仮想環境において、最も見落とされがちな計測値の一つになりがちなのかということを述べました。その重要性を理解するための最初のステップはデータセンタ全体にわたってそれを可視化出来るようにした上で、それぞれのワークロードに対して十分なきめ細やかさも兼ね備えておくことです。しかし、ブロックサイズのような計測値を可視化する際にはそれだけでは十分とはいえません。データ自身を正しく理解できなければ、データ全く意味が無いものになってしまいます。データは以下の要件を満たす必要があります:

  • 簡単にアクセスできる
  • 簡単に意味が理解できる
  • 正確である
  • 他の関連する計測値とどのように相関するかを理解しやすい

今後の記事で特定のシナリオにおいて、こうした情報をどのように利用し、環境をアプリケーションのパフォーマンスのためにチューニングしていくのが良いのかという点においては追求していきます。さぁ、まずはPernixData Architectが基本的な、つまり、一般的なRead/Writeアクティビティに於いて、どのようにブロックサイズについて可視化するのかを見ていきましょう。

サマリビューにおけるブロックサイズの頻度

特定の仮想マシンの"Overview(概要)"ビューをArchitectで表示すると、I/Oサイズの頻度(IO Frequency)を小さなブロックから大きなブロックに渡るまで、任意の時間の間隔での分布を表示することが可能です。このI/Oの頻度はメインのサマリページでクラスタ全体を表示した時にも表示されます。以下のイメージは単独の仮想マシンにフォーカスした際のものです。

Fig377

上の図で最も興味深い点はReadとWriteでブロックサイズの頻度が異なっているということです。これは一般的なことではあるものの、このようにデータを簡単に見ることができないため、殆どの場合、気づかれることなく放置されている特性です。

"Workload"を利用したブロックサイズ表示

Architectの"Workload"ビューはワークロード単独、ワークロードのグループ、もしくはvSphereクラスタ全体で発生するブロックサイズの分布をパーセンテージによって表示します。表示するタイムフレームはお望みのとおりに変えられます。この表示では特定の仮想マシンの複雑で、ユニーク、かつ動的なブロックサイズの分布を他のビューより明らかに、そして高速に表示してくれます。以下の例は単独のワークロードの15分間の例です。Read/Writeの割合や、CPU利用率などの他のメトリックと同様、こうした変動が起こる度にそれを理解しておくことは非常に重要です。単に積み重なっていくだけのものや、長い間で同じものでは無いからです。

Fig378

実際の環境において"Workload"ビューを見てみると、人工的なI/O生成器の限界に瞬時に気付かされることになります。こうした人工的なワークロードは環境における複雑なブロックサイズの分布をエミュレーションすることはできず、その目的は非常に限られてしまうということです。"Workload"ビューはワークロードが非常に劇的で、常に変わり続けているということも表示してくれます。結果として1度きりのストレージアセスメントでは不十分だという事にもなります。CPUやメモリのリソースについてはこうした疑問を誰も持ちませんが、どうしてストレージについてはこうした制限を自分自身でかけてしまうのでしょうか?

"Workload"ビューはあくまで分布をパーセンテージで表示するということは気に留めておいてください。パーセンテージベースの表示であるということは全体からの相対的な割合を表示してくれるということです。こうしたパーセンテージの背後にある絶対的な値を表示しているわけではありません。その分布が50IOPSの時もあれば、5,000IOPSであることも有ります。しかしながら、こうした表示はワークロードや環境全体が短い時間で、または長い間隔のトレンドとして刻々と移り変わっているということを示すためには非常に有効です。

IOPSとThroughputビューにおけるブロックサイズ

この仮想マシンをまず、IOPSの標準の"Read/Write"ブレイクダウンで見てみましょう。以下のイメージは一定のReadが行われたあと、殆どWriteに移り変わっているということを示しています。上の"Workload"ビューを見返してみると、これらのI/Oがどのようなブロックサイズ分布になっているかを推定することが可能です。

Fig379このIOPSビューのまま、事前に定義されている"Block Size"のブレイクダウンを選ぶことで、ブロックサイズごとにどれだけのIOが発生しているかの絶対数を見ることが可能です。以下のイメージは"Workload"ビューとはことなり、実際のI/Oをブロックサイズごとに表示しています。

Fig380しかし、これは全体のうち一部しか言い表していません。単一のブロックサイズは単独のI/Oの属性に過ぎません。ですから、IOPSビューでは4Kブロックの10 IOPSは256Kの10 IOPSと全く同じに見えます。実際には64倍ものデータが流れているのです。「転送されたデータ総量(Payload Amount Transmitted)」という観点でこれを見ていくためには以下のように"Throughput"ビューを"Block Size"ブレイクダウンで見ていく必要があります。

Fig381上のようにブロックサイズをその転送量(Payload)のサイズ(Throughput)で見ていけば、その時点において大きなブロックサイズが支配的であるということをより良く表示することが可能ですし、比較的小さな転送量(Payload)は小さなブロックサイズによってなされていることがわかります。

もう一つ、Architectによってデータを可視化する方法をお伝えしましょう。"Performance Grid"ビューをクリックして、特定のブロックサイズのIOPSとThroughputを見ることが出来るように変更しましょう。以下のイメージが表示しているとおり、上の行は4K~8KのIOPSとThroughputを表示しており、同時に下の行では256K以上のIOPSとThroughputを表示しています。

Fig382

上の図が示しているのは4K~8KのブロックサイズのIOPS数のピークも256K以上のブロックサイズのIOPSのピーク値もほとんど同じであるにもかかわらず、転送量は大きく異なっているということです。

なぜこれが問題なのか?

PernixData Architectがなぜこれらを取り上げているのかお伝えしていきましょう。同じ時間の間隔の中で、仮想マシンの実効レイテンシーを見ていきます。以下のイメージから、仮想マシンの実効レイテンシーがWriteが支配的に変わったタイミングから明らかに大きくなっています。(Read/Writeのチェックはあえて見やすさのために外しています)

Fig383

以下のイメージをさらに見てください。こちらでは"Block Size"のブレイクダウンを利用して、ブロックサイズごとのレイテンシを表示しています。

Fig384

見ていただいたとおり、大きなサイズのブロックほどレイテンシが大きくなっています。こうした柔軟なビューのおかげで、レイテンシを贔屓目なく見ることができ、そのレイテンシがどこに足を引っ張られているのかを見ることができます。さぁ、もっと歩みを進めましょう。Architectでは"Block Size"のブレイクダウンが事前定義されており、ReadとWriteのブロックサイズごとの特性ーレイテンシー、IOPS、スループットーを表示することが出来るようになっています。さらに、カスタムブレイクダウンを利用して、ブロックサイズだけではなく、以下のイメージのようにReadとWriteに特化して見ることも可能です。

Fig385

上で表示されているレイテンシーの"Custom"ブレイクダウンではそれぞれのブロックサイズのすべてのReadとWriteの値を表示することができますが、単純化して見やすくするために幾つかのものはチェックを外しています。このビューから64Kか、それよりも大きなWriteによって殆どのレイテンシが生じているということを確認できます。こうすると仮想マシンで生じているレイテンシが、大きなサイズのブロックのWriteによって引き起こされているということを明確に見て取ることが可能です。ただし、その影響についてはただブロックサイズが大きいIOだけがレイテンシが高いというだけではありません。こうしたラージブロックのレイテンシは小さなブロックのI/Oにも影響を及ぼします。これについてはそれにフォーカスした情報をいつか投稿したいと思います。

以下のイメージにある通り、Architectは特定のポイントにマウスを当ててクリックすることでドリルダウンしてさらなる知見を表示することが可能です。これは仮想マシンごとにも、クラスタ全体においても行うことが可能です。マウスをそれぞれのブロックサイズを表している棒グラフの上に置くことでどれだけのIOが発行され、それぞれがどのようなレイテンシになっていたかを見ることが可能です。

Fig386フラッシュで解決?

ブロックサイズがアプリケーションのレイテンシに影響をおよぼすことは明らかです。フラッシュで解決?そうでしょうか? 実際にはそうとは限りません。上で上げてきた全ての例では仮想マシンはフラッシュ上で動作させています。フラッシュと、ストレージソリューションがどのように実装されているかによって、これは非常に興味深く、そして仮想マシンに対して非常に大きなパフォーマンスへの影響を及ぼすことになります。ストレージのメディアはストレージインフラストラクチャにおいては単なる一つのコンポーネントに過ぎません。これらのコンポーネントとそれらが引き起こすパフォーマンスへの影響は従来型の三層構造のアーキテクチャであれ、ハイパーコンバージド環境のような分散ストレージ環境であれ、変わることなく存在します。

パフォーマンスマトリックス内でのブロックサイズ

Architectに固有の表示としてパフォーマンスマトリックス(Performance Matrix)があります。それが表示するもののユニークさとどのように使うかをお伝えしていきます。利用しているストレージソリューションは製造社によってある一定の想定のもとに最適化されていますが、その想定はご自身のワークロードには合わないかもしれません。大抵の場合、それを知るすべはありません。しかし、いかに示すとおり、Architectを利用してどのようなワークロード特性をストレージ装置が苦手としているのかを知ることが可能です。

Fig387

パフォーマンスマトリックスは(上で上げたとおり)仮想マシンごと、もしくはグループやクラスタの集計として表示することが可能です。どのサイズのブロックサイズ以上で、ストレージインフラストラクチャが悲鳴を上げ始めるかの閾値をみるためには非常に良い表示です。これはストレージ装置側が提供する統計情報とは大きく異なったものです。というのもArchitectは完全にエンドツーエンドでこうしたメトリックを理解する方法を提供し、さらにそれを非常にきめ細やかに行うからです。ストレージ装置はこうしたデータについて正確に理解し、計測するという点では正しい場所ではないのです。

まとめ

ブロックサイズは仮想マシンのパフォーマンスに対して非常に大きな影響をもたらしますし、コンピューティングや他のストレージの計測値と合わせて最重要な項目として取り扱われるべきものです。これを全く無視してしまうのは非常に大きな問題であり、ベンダーが「我々のソリューションは高速です、信じてください」という言葉もまたしかりです。Architectはブロックサイズについて、これまでには実現できなかった可視性を実現し、これに答えてくれます。これを活用して、あなたの環境にとってこれがどういう意味を持つのかということをしっかり見定めてください。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/04/06

NetApp 7toC 移行サービス始めました!アセスメント編

皆様こんにちわ

NetApp大好きな皆様に朗報でございます。

なんと・・・ネットワールドで7toC移行サービスを始めます!!(NAS利用限定)

じゃじゃじゃーん!

-------------------------------------

※7toCとは?

7-Mode To clustered Data ONTAPの略で、同じNetAppと言えどOSが違い、基本的には互換性がなく移行ができません。

そんなモヤモヤを解決できる機能の名称になります。

7toCを使うことにより、7-ModeとcDOT間でSnapMirrorを使用したデータ移行が可能になります。

-------------------------------------

既存は7-Modeです。でも新規は最新のcDOTを買いたい。

そうなると必然的に出てくる課題。そう!

【データ移行】!!!

皆様も頭を抱えている点だと思います。

ある人は言います。

「robocopyでやればいいじゃん?」

ある人は言います。

「お客様にやってもらえばよくない?」

いやいや・・・そうもいきませんよ・・・

そんな皆様にピッタリのソリューション、【7toC】について段階を追って記事にしていこうかと思います。

今回は移行サービス開始記念の第一弾として比較的容易に移行できる64bit環境のご説明をしていきます。

7toCでデータ移行するうえでポイントになるのが、既存が32bitか64bitか?になります。

なぜ大事なのか?

そうなんです。cDOT8.3からは32bitアグリゲート及びボリュームをサポートしておりません。

なのでこの既存が32bit or 64bitは大事なポイントになります。

これを確認するコマンドは既存7-Modeで「aggr status」と打ってみてください。

<32bitの場合>

           Aggr State           Status            Options
          aggr0 online          raid_dp, aggr
                                  32-bit

<64bitの場合>

           Aggr State           Status            Options
          aggr0 online          raid_dp, aggr
                                  64-bit

こんな形で表示されます。

どちらも表示されない場合は、32bitの可能性があります。

例えば既存がFAS2020等、7-Modeのバージョンが7.xの場合は表示されません。

「32bitはNGですか・・・?」

大丈夫です。32bitからでも移行はできます!!

が、32bitからの移行は工数が多く、手順が長くなりますので、今回はまず64bitからの移行の方法を記載していきたいと思います。

既存が64bitの方は第一関門突破になります。

次に確認する項目がONTAPのバージョンになります。

以下が7toCを行う上でサポートされているバージョンの一覧です。

• Data ONTAP 8.0
• Data ONTAP 8.0.1
• Data ONTAP 8.0.2
• Data ONTAP 8.0.3
• Data ONTAP 8.0.4
• Data ONTAP 8.0.5
• Data ONTAP 8.1
• Data ONTAP 8.1.2
• Data ONTAP 8.1.3
• Data ONTAP 8.1.4
• Data ONTAP 8.2
• Data ONTAP 8.2.1

※細かいPパッチバージョンは気にしなくて大丈夫です。

モデルで言うとFAS2040以降やFAS31xx以降、FAS60xx以降であればサポートされるONTAPバージョンになりますね!

今現在お使いの機種がどのONTAPまでインストールできるかにつきましては、NetApp社のHardwareUniverseというツールがありますので、そちらで確認してみてください。

http://hwu.netapp.com/Home/Index

※閲覧にはNetAppパートナー契約が必要になります。パートナー契約をご検討のパートナー様は弊社営業担当もしくは下記URLより是非ご相談ください。

【NetApp製品問い合わせ先】

さて次に確認する点は、既存でお使いの7-Modeの機能がcDOTに移行できるか?になります。

例えば代表的な機能としてCIFSでの「WORKGROUP」になりますね。

残念ながら今現在の最新のcDOTでもWORKGROUP機能は実装されておらず、ActiveDirectroyが必須になるなど細かい点に注意が必要です。

こういった細かいポイントの確認って大変ですよね?

安心してください。ありますよ?

皆様一回は噂に聞いたことがあるかと思いますが、NetApp社より7MTTというツールがリリースされております。

こちらのツールの本来の用途としてはGUI画面で7toCを行うものなのですが、最新のバージョンではなんと移行におけるアセスメント機能が実装されております。

今回はこのツールを使用してのアセスメント方法をご紹介していきたいと思います。

まずはNetApp社のサポートサイトより、最新の7-Mode Transition Tool 2.3をダウンロードしてください。

※2016年4月現在の最新は2.3になります。

http://mysupport.netapp.com/NOW/download/software/ntap_7mtt/2.3/

※インストール要件もこちらからご確認ください。

「ダウンロードできないよ?」

「権限がないって怒られるよ?」

という方もいらっしゃるかと思いますので、そういった場合はお近くの販社様等にご連絡してみてください。

無事ダウンロードできた方は、実際にインストールしてみましょう!

2

5

11

特にハマるポイントもなく、サクッとインストールできるはずです!

※私の環境はjavaで色々怒られましたが(笑)

さて!では実際にツールを使ってみましょう!

デスクトップにショートカットアイコンがありますので、クリック。

 

23desk

ブラウザが起動します。

 

23login

ここでアカウントを入力しますが、こちらに入力する項目はインストールしたWindowsのアカウントを入力する点にご注意ください。

※私ですか?10分くらいNetAppのrootのアカウントを入れて唸っていたのは内緒です(笑)

 

15


トップ画面が表示されますので、【Collect & Assess】のGet Startedで早速行ってみましょう!

16_2

Collect & Assessのトップ画面が表示されますので、【Add Systems】を押して、既存7-Modeの情報を入力してみましょう!


Add

ここでは7MTTをインストールしたWindowsと通信可能な既存7-ModeのIPとそのアカウントを入力します。

「登録できませーん!」

「エラーになりまーす!」

おや・・・?

もしかしてこれですか??

Error_2

私もこれで1日ハマりました(笑)

もし同じ現象になってしまった方は既存の7-Modeで以下をお試しください。

>options tls.enable on ※通信時にTLSを有効にする必要があります。

>secureadmin setup ssl ※SSL Key Lengthをデフォルト512→1024に変更します。

一応私の検証環境ではこれで登録できました!

20_2

登録が無事完了すると【Ready】と表示されます。
右上の【Create Transition Assessment Report】をクリックしてみましょう!

21_2

移行先のONTAPバージョンを入力し、【Generate Report】をクリックします。

22_2

画面下の部分で何やらレポート作成中ぽいメーターが表示されております。

23_2

レポーティングが終わると2つのファイルが出来上がります。

AssessmentExecutiveSummary.xml → Word

こちらは既存7-Modeのボリューム数や使用プロトコル、推奨移行方法等が確認できます。

Word

AssessmentWorkbook.xml → Excel

こちらは移行の注意点や未サポートの機能、修正方法等が確認できます。

Excel

さて今回は移行サービス開始記念第一弾として、7toCアセスメント編ということでしたが皆様いかがでしたでしょうか?

次回は実際の7-Modeからの移行方法を記事にしていきたいと思います。

「簡単そうに見えるけど実は難しいんでしょう?」

「さすがに移行までは難しいので有償でお願いしたいのですが・・・」

そういったご要望に答える為に、ネットワールドではアセスメントや移行サービスまでを行うサービスをご提供しております!!

ご要望ある方は是非、弊社営業担当もしくは下記URLよりご連絡頂けますと幸いです。

【NetApp製品問い合わせ先】

担当:長岡

2016/04/04

実況中継!? VSAN 6.2 中の人によるふかーい話 (容量効率化編)

みなさん、こんにちわ。VSAN 6.2がリリースされていろいろなご質問をいただくことが多くなってきました。特に通り一遍の機能紹介だけでは満足されず、その実装方式に至るまでものすごくふかーいご質問をいただくケースも有ります。こんなご質問にお答えするために今回はこんな記事を用意しました。

本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。

実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる~い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。機能のリクエストについてや将来的な構想についての言及も有りますが、あくまでそこは保証の限りではありませんので、ご注意ください。

今回はまずは容量効率化編です。

VSANの重複排除と圧縮はクラスタの機能です。

ストレージポリシーとして実装されているというような議論も有るようですが、単一のVMに重複排除を適応したとしてもその効果はたかが知れています。ですから、クラスタ全体で実装されているのです。

重複排除と圧縮は両方を提供します。

複雑なので、どちらか一方だけ、などの選択肢をユーザーに提供はしません。ユーザーは重複排除と圧縮のどっちが有効なのかを知りません。なので選ぶこともしません。様々なデータを長時間にわたって調査しましたが、重複排除をした後に圧縮(LZ4を使っています)を行ってもさほどパフォーマンスに影響がないという結論に達しました。重複排除が聞かないようなデータベースなども、圧縮によってデータ削減がなされます。別々にする必要は無いのです。

実際に重複排除も圧縮もオーバーヘッドは非常に小さく保っています。重複排除を行った後に圧縮を行いますが、実際に利用する際にはオーバーヘッドは(圧縮単体や重複排除単体のオーバーヘッドと)さほど変わりません。ですから、両方を実施するのです。

重複排除のドメインはディスクグループです。

重複排除をクラスタ全体で実施するのか、それとも一部で実施するのか?我々の答えは重複排除はディスクグループのドメイン内で実施するというものです。これを選択するに至った経緯はいくつか有ります。VSANはロードバランシングの観点から様々なデータ分散を行っています。また、別の観点で言うと耐障害性の観点からもデータの分散を行っています。

グローバルで重複排除を行うと、せっかく障害を考慮して分散したデータが消えてしまいます。(もちろんグローバルの重複排除には劣りますが)ディスクグループ内での重複排除でもかなりのスペースの効率化が期待できます。

質問への回答の中から : ディスクグループ単位で実装することによって並列処理をおこなうためにも有利な実装になっています。

重複排除はキャッシュからキャパシティにデータが移動する際に実施されます。

もう一つの要件は可能な限りパフォーマンスに影響を及ぼしたくないということです。ですからデータはログ構造でパフォーマンス層(Writeバッファ)に書き込みます。この時点では何もしません、パフォーマンスには影響はありません。このデータをキャパシティ層に書き込む際に重複排除を実施します。この書き込みは重複排除されますからCPUなどの負荷を抑えることもできます。また、重複排除されるデータはキャッシュからキャパシティに落ちていくコールドデータのみです。書き込んだあと、すぐに更新がかかってしまうデータに対して重複排除を行う意味は無いからです。

重複排除のメタデータ自身もキャパシティ層に分散して保持されます。

重複排除のチャンクの細やかさのサイズは4Kです。ですから非常に優れた重複排除率を実現することができます。ですが、細かなブロックであるということはより多くのメタデータを必要とするという事にもなります。安価なキャパシティ層のSSDに分散して保持することにしました。ですからこのメタデータのサイズは2%~最大でも4%程度ですが、更にインメモリキャッシュなどのトリックも使って保持しています。

重複排除と圧縮はオールフラッシュのノードのみでサポートされます。

先程も述べたとおり、重複排除と圧縮は単一の機能です。ハイブリッドアーキテクチャの場合、ローカリティ(訳注:仮想マシンが動作しているノードにデータがある確率が高いこと)を考えなくてはなりません。ですが、このデータは重複排除されてしまいますので、ローカリティを考えるということがそもそも難しくなるのです。結果としてハイブリッドアーキテクチャの場合、非常に大きなキャッシュを載せなくてはなりません。だったらオールフラッシュの方がイイねという悲劇が生まれるのです。殆どの場合コスト的にオールフラッシュの方が理にかなっているという調査結果に基づいています。

会場からの補足: (サムスンの)SSDと4TBのHDDを考えて、3倍以上に圧縮が聞くようであればオールフラッシュの方がいいことになりますね。いろんな仮想マシンにおいて、大体4倍ぐらいは効いている印象です。もちろんこれは効くVMと効かないVMがあるという前提ですけど。イレイジャーコーディング(による効率化)もあるのでいいと思います。

圧縮はLZ4を利用し、ブロックが圧縮で4Kから2K未満になる場合だけ圧縮します

いろんなアルゴリズムを採用できますが、LZ4が最も効率が良いとわかりました。また、重複排除は4Kの単位ですが、この4Kを圧縮して2K未満になった場合のみ、圧縮を行い、そうでない場合は4Kのままキャパシティ層に書き込みます。

イレイジャーコーディング:RAID-5は1障害耐性、RAID-6は2障害耐性

RAID-5は3+1で最低4ホスト、RAID-6は4+2で最低6ホスト必要です。これはインライン処理(クライアント=仮想マシンで実施されます 訳注:キャッシュとキャパシティ間ではなく、仮想マシンとキャッシュ間で実施)です。ストレージポリシーで選択可能です。

イレイジャーコーディングはオールフラッシュのみでサポートされます。

イレイジャーコーディングを行うと、パフォーマンスと容量効率化にトレードオフが生じます。分散書き込みおよびパリティ計算などによって、RAID-5では1つのWriteが2つのWriteと2つのReadに増えてしまいます(合計4倍)。RAID-6では3つのReadと3つのWrite(合計6倍)になります。磁気ディスクではIOPS数が小さく、パフォーマンスに影響が出ますのでこの機能はオールフラッシュのみでサポートすることにしました。そうでないと、パフォーマンスを確保するために多くのSSDキャッシュが必要となり、結局オールフラッシュの方が安くなってしまうという、以前もお話した悲劇が起きるからです。

質問より: ROBO構成のようにノード数が小さいときに筐体内でイレイジャーコーディングを行いたいというニーズもあるのでは?

ノード単位ではなくてもっと小さな単位・・・ディスクグループ、おっと!言いすぎかな。保証はできませんが、将来的にそうしたニーズに対応するための機能は考えています。

チェックサム・・・これはエンドツーエンドです(笑)

ガンマ線やアルファ線でデータが変わってしまうことがありますんで・・・(笑)これは去年頂いたご指摘でしたね。CRC32でチェックサムを計算します。そしてデータとともにキャパシティ層に届けられます。データをReadする際にだけでなく、あらゆるステップでこのチェックサムをチェックします。これは単に保存時のデータが変わってしまうことだけではなく、いうように宇宙線など(笑)でデータが変わってしまうことに対してもデータを保護したいからです。もちろん、それだけではなく、ネットワークだったり、様々なポイントでデータが変更されてしまう可能性を排除したいからです。

チェックサムはデータが保管されているのとは別のディスクに保存されます

チェックサムはわずかばかりはパフォーマンスには影響しますが、ほとんど考えなくても良いレベルです。チェックサムは他のデータとは別に個別に管理されています。そしてこの機能はハイブリッドアーキテクチャでもオールフラッシュでもサポートされます。これは非常に重要な事です。標準でこの機能は有効になっています。要らないのであればOFFにすることもできます。

QoS機能は仮想マシンか、VMDKごとにIOPSの上限値を指定できます

サービスプロバイダなどのSLAに利用できます。いつも有効にするのではなく、システムの負荷が高い時にだけ例えば、レイテンシの閾値を設けたいなどのリクエストをもらっています。これについては将来的に対応を考えたいと思います。

CBRC(コンテンツベースのReadキャッシュ)をVSANに統合しました

VDI環境向けにCBRCを提供していますが、非常に高い効果をあげています。それをVSANに統合しました。キャッシュが分散するアーキテクチャのなので、ローカルの揮発性のつまり、インメモリのキャッシュを設けたということです。Write-Thoughのキャッシュですが、多くのワークロードに非常に有効です。仮想マシンが動作しているホスト上に構成されます。

質問より: 他のストレージ(VSAN以外の)に対しても使えるようにして欲しいなぁ。

それについては後でお話しましょう。(訳注: PernixDataが有りますよ!笑)

仮想マシンのスワップファイルをシンプロビジョニング出来るようにしました

これまで仮想マシンのスワップファイル(メモリ不足の際にメモリ内容を格納するファイル)はシックプロビジョニングされていました。今回、お客様からの要望に応える形でシンプロビジョニング出来るようになっています。

まとめ

今回は容量効率化編で、スライドを使うのではなく殆どがQ&A方式でしたので文字ばかりですが単なる機能として理解するのではなく、アーキテクチャとして理解するために重要な情報が得られますね。それぞれの箇所で述べていますが、将来的な機能については保証の限りではありませんので、ご注意ください。次回、パフォーマンス編ではスライドもご紹介したいと思います。乞うご期待!

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/04/01

CommVault Simpana:番外 クライアントPCのバックアップ バイナリ作成編

エンタープライズ向けであるバックアップ製品のSimpanaは、サーバ系OSのバックアップを得意としていますが、表題にあるようなクライアントPC、例えばWindows10や7、8、MacintoshといったPC向けのバックアップも管理できます。


今回は、クライアントPCのバックアップについて、取り上げてみます。

サーバ系と大きく違うのは、クライアントPCの動作しているのは人が使っている時間、日昼にしか電源が入っていないことが異なる点です、その点に考慮する必要が出てきます。

サーバ系は、夜間に処理が少ない時間帯を見計らってバックアップを取るのが常ですが、クライアントPCは夜間に電源が入っていないことが常となり、サーバ系と同じようなバックアップを仕掛けることが出来ません。 つまり、人が使っている時間帯を使って取ることになります。

これがなかなか厄介な話しになります。


CommVault社のサイトでも同じことを言っています。
第6回 サーバーのバックアップは完璧! なのに、なぜエンドポイント データのバックアップは難しい?
※クライアントPCへの対応をエンドポイントとか、エッジ(Edge)と言いますが、同じものです。


クライアントPCバックアップを利用するにはインストールからですが、サーバ系のように数GBもあるバイナリををコピーしてというのは無駄が多いので、Simpanaの便利な機能を使ってカスタムパッケージを作り、共有のバックアップ環境として統一感のあるインストール操作を提供します。


まずは、インストールバイナリをダウンロードするところから始めます。


①サーバ系のバイナリをダウンロードする際に使用したbootstrapを使います。

SP7以降から2段階の方式になっていて、まずOS毎に容量の少ないインストールバイナリ:bootstrapを入手し、その後必要なインストールバイナリを入手する方式です。

Simpanapackage01


※バイナリのダウンロードに関しては、下記を参考にしてください。
【連載】第1回 始めてみよう!CommVault Simpana インストール編


②SetupAllをクリックして、表示されるGUIに合わせて、[次へ >(N)]ボタンを押していきます。

Simpanapackage02_5


③パッケージのダウンロードを選択し、ダウンロード場所を指定して、[次へ >(N)]ボタンを押していきます。

Simpanapackage03_3


④Windows(32ビットのWin32/64ビットのWinX64)とUnix/Liunxが選択できます。 今回は、Unix/Liunxを選択し、Mac OSXを選択して、[次へ >(N)]ボタンを押していきます。

Simpanapackage05


⑤パッケージを選択を選び、”ダウンロード・・・”にチェックを入れ、パッケージリストから必要なパッケージを選択して、[次へ >(N)]ボタンを押していきます。 クライアントPCのファイルバックアップだけであれば、File System Coreのみの選択で対応可能です。

Simpanapackage06


⑥選択したパッケージの確認後、ダウンロードが始まります。

Simpanapackage07


⑦以下の表示で終了です。

Simpanapackage08_2


指定したフォルダに、CVDownloads.tarが存在することを確認します。


今回は、バイナリを集めたところで終了です。

次回は、そのバイナリからインストールするパッケージのカスタマイズを行います。

お楽しみに!!


Edit by :バックアップ製品担当 松村・安田

CommVault Simpana:番外

クライアントPCのバックアップ バイナリ作成編
パッケージカスタマイズ(Mac OS)編
インストール(Mac OS)編



【過去の記事】

メーカのサイト:
Simpana早わかり講座

導入編:
【連載】第1回 始めてみよう!CommVault Simpana インストール編
【連載】第2回 始めてみよう!CommVault Simpana インストール後の作業とバックアップ編
【連載】第3回 始めてみよう!CommVault Simpana VMwareバックアップ編
【連載】第4回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(1)
【連載】第5回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(2)とリストア
【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

製品紹介編:
第一回、最新!データ統合管理ソリューション CommVault Simpana のご紹介!
第二回、データ統合管理ソリューションCommVault Simpana 基本構成
第三回、データ統合管理ソリューションCommVault Simpana Backup
第四回、データ統合管理ソリューションCommVault Simpana Deduplication
第五回、データ統合管理ソリューションCommVault Simpana SnapShot Management
第六回、データ統合管理ソリューションCommVault Simpana Virtualization