AHV移行時の課題

 既存のHypervisorからAHVへ移行する場合、前回お話したように「ダウンタイムをいかに最小限にするか？」「何かあったときに容易に切り戻り（ロールバック）できるか？」という点が重要になってきます。この2点をどのようにXtract for VMsで解決しているのが、データの転送の観点からみていきたいと思います。

Xtract for VMsの移行の流れ

　 Xtract for VMsの移行はシンプルな移行ジョブとして作成されますが、当然裏側では様々なタスクが実行されています。スムーズな移行を実現するためにタスクを分類すると、「ダウンタイムを最小限にするためのデータ転送のタスク」と「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」にわけることができます。

　今回はこのうち「ダウンタイムを最小限にするためのデータ転送のタスク」について掘り下げていきたいと思います。来週執筆予定の「Xtract for VMs Deep Dive第2回」では「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」について掘り下げる予定です。

ソースとなるvSphere環境から仮想マシン1台（Xt-02-w2k12r2）をAHV環境へ移行する流れは以下になります。今回はデータ転送が行われるフェーズの①～③について出力されるログをベースにどんな処理が実行されているのか見ていきましょう。

Migration Planの作成

↓

Migration Planの実行

↓①

CutOverの待機

↓②

CutOverの実行

↓③

Migration Planの完了

Xtract for VMsのデータ転送の仕組み(Migration Planの実行編)

　Xtract for VMsでは「Migration Plan」の実行時に「Data Seeding」と呼ばれる移行元仮想マシンの全データの転送が行われます。このとき、仮想マシンはもちろんゲストOSの中で動作するアプリケーションは動作していて問題ありません。

この「Data Seeding」時は、以下のようなデータ転送処理が行われます。他にもゲストOS内で様々な処理が実行されますが、データ転送に関わる部分だけを取り上げています。仮想マシンがもつすべてのスナップショットが削除される点だけ注意が必要です。

• 仮想マシンがもつすべてのスナップショットの削除
• 仮想マシンのスナップショットの取得（ロールバック時にはこのスナップショットに戻る）
• 全データの転送

これらのスナップショットの取得は、ソースとなる仮想マシンのvmware.logファイルにログが出力されます。「XTRACT-VMSnap-0」というスナップショットを取得していることがわかります。

では次に気になるデータ転送の経路についてみていきましょう。

 Xtract for VMsでは通常移行先のAHVクラスタ上にXtract for VMsの仮想アプライアンスを展開します。この仮想アプライアンスを中心にどういったデータ転送が発生するのでしょうか。

　まずソースVMのデータのやりとりは、通常のvSphere環境でバックアップするときに用いられるVADP(vStorage API for Data Protection)と呼ばれるAPIを利用しています。ソースの仮想マシンに対してスナップショットを実行して、仮想ハードディスクに対して読み取り専用でアクセスすることができます。

　そしてターゲットVMのデータのやりとりは、AHVクラスタ上の「Storage Container（データストア）」をXtract for VMsのゲストOSがNFSマウントすることで、直接AHVクラスタへデータを書き込みます。一度Xtract for VMsにデータを保存して、それをもう一度AHVクラスタへ書き込むようなことはしていません。そのため、データ転送自体最短で完了することができますし、移行元のデータサイズによってXtract for VMsにローカルディスクを追加する必要もありません。

図としてあらわすと以下のようになります。

　これらの一連のタスクのログは、Xtract for VMsのサポートログの中に、xtract-vm-diskreader.log,xtract-vm-diskwriter.logのログとして保存されています。

Data Seedingフェーズではこのような動作で、Xtract for VMsを介して移行元仮想マシンのデータを移行先のAHVクラスタへデータを転送しているようです。

Xtract for VMsのデータ転送の仕組み(Cutoverの待機編)

　先ほどのData Seedingフェーズで全データを転送しましたが、アプリケーションは起動状態だったため最後にデータ整合性を担保したデータで上書きする必要があります。

　しかし、仮想マシンの移行時にData Seeding後にすぐに移行（Cutover）をするとは限りません。動作確認等を入念に行ったり、短時間とはいえシステム停止が必要なためメンテナンス時間の調整で、一ヵ月先になったりすることも当然考えられます。

　例えばData Seedingを行ってから一ヵ月後に移行する場合、一ヵ月の差分データを移行直前にすべて転送完了する必要があります。アプリケーションやデータ構造によっては大部分のデータを再転送することも考えられます。その場合、データサイズによってはシステム停止の時間が長時間になってしまいます。

システム停止時間を最小に抑えるためにXtract for VMsではData Seeding完了後からCutoverが実行されるまでの間は10分間隔で移行元仮想マシンのデータを移行先AHVクラスタへ差分転送が実行されるアーキテクチャになっています。

　こうすることで、アプリケーションやデータ構造によるデータ変更量の多少、Data SeedingからCutoverの期間に長さに関わらず、Cutover時には最長でも10分前のデータが担保された状態を維持することができるのです。

　10分間隔と非常に短い間隔で実行されていますが、差分データの取得にはData Seeding時と同じVADPのCBT(Change Block Tracking)の機能を利用しているため、すべてのデータの差分チェックを行う必要はありません。既に変更があったブロックを認識しているため、変更ブロックだけを速やかに差分転送することが可能なアーキテクチャを採用しています。

　Data Seeding時と同様に移行元仮想マシンのvmware.logファイルにCBTを利用した差分データの取得のログが出力されます。

Xtract for VMsのデータ転送の仕組み(Cutoverの実行編)

さて最後になりました。実際にvSphere上で動いている仮想マシンを停止して、AHVクラスタ上で仮想マシンを起動する「Cutover」フェーズの動作をみていきましょう。

まずソースとなるvSphere上の仮想マシンでは以下のようなタスクが実行されます。

• Guest OSの停止
• スナップショットの取得
• （データ整合性が担保される、差分データ転送）
• スナップショットの削除
• 仮想マシンのNICの接続を解除
• Migrate Plan実行時に取得したスナップショットの削除

　先ほどCutoverの待機編で説明したように、直近10分前のデータ同期が完了しているためこの3の最後の差分データ転送が短時間で完了するため、まるでOSのパッチ適用をするぐらいのメンテナンス時間で容易に移行できるのがXtract for VMsの最大の特徴ということができます。

そして移行先となるAHVクラスタ上ではPrismを確認すると以下のようなタスクが実行されます。今回の移行元仮想マシンが仮想HDDを2つ持っているためImageが2つ作成されています。

• Xtract for VMが書き込んだHDDをもとにテンプレート（Image）を作成
• 1で作成されたテンプレートを元に仮想マシンを作成
• 仮想マシンの電源をオン
• テンプレートを削除

今回はXtract for VMsを使ったvSphereからAHVへの仮想マシンの移行の際のデータの転送の仕組みについて掘り下げて紹介してみました。次回はどうやってハイパーバイザーの違いを吸収しているのか、ゲストOSで実行されているXtract for VMの移行タスクについて掘り下げて紹介してみたいと思います。

ではまた来週。

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 5 – Resiliencyをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

信頼性についての話をする場合、データの信頼性のみを見てしまい、ビジネスアプリケーションを稼働させるために必要なストレージコントローラーや管理コンポーネントの信頼性については見落とされてしまうという過ちが多くあります。

RAIDやホットスペアのドライブといった従来からのテクノロジーは場合によってはデータの信頼性を提供しますが、スケールアウトも自己修復もできないデュアルコントローラータイプのストレージに接続されていた場合、単一のコンポーネントの障害であったとしても、データが利用できなかったり、パフォーマンスや機能がいくばくか低下するというようなことに見舞われます。信頼性の回復について、ハードウェア交換に依存したインフラストラクチャは私がハードウェアサポート契約と24x7 4時間オンサイトはもはや必要のないものになった(和訳予定なし)という記事で以前議論したとおり、根本的に崩壊しているのです。

加えて、もしも管理アプリケーションのレイヤに信頼性がなくなった場合、データレイヤの高可用性や信頼性が阻害されることになり、ビジネスアプリケーションは(例えば普通のスピードでは)うまく動作しなくなったり、まったくもって動かなくなることもあるでしょう。

Acropolisプラットフォームはデータと管理レイヤの双方に高い信頼性を提供しており、N+1またはN+2(Resiliency Factor 2 または 3)に設定することができます。これによって最大2つのノード障害が同時に発生しても管理そしてデータを失わずに対応することができます。更に、｢ブロックアウェアネス｣があればブロック全体(最大4ノード)の障害においてもクラスタは完全な機能を維持し続けます。こう考えるとXCPのデータと管理コンポーネントの信頼性は最大でN+4であるということもできます。

更に、より大きなXCPクラスタではノード/コントローラー/コンポーネントの障害の影響はより小さくなっていきます。4ノードの環境でN-1は25%のインパクトですが、8ノードのクラスタでは12.5%です。クラスタが大きければ大きいほどコントローラー/ノードの障害のインパクトは低減されるのです。対象的にデュアルコントローラーのSANにおいては単一コントローラーの障害は50%もの品質低下影響があり、その後に障害が起きれば完全な停止に追い込まれます。Nutanix XCP環境は自己治癒機能を持っているため、障害イベントでもN-1になるだけです。その後に機能する自己治癒がその後に発生する障害からも保護を行ってくれるため、大きな影響や停止を起こすことはないのです。

Acropolisのマスターインスタンスが障害を起こした場合でも、30秒以内で完了する新たなマスター選出によって完全な機能が環境に復元されます。これは管理の可用性が｢シックスナイン｣(99.999%)以上であることと等価です。重要なのはAHVはこの管理の信頼性が組み込まれているということです。さらに設定をする必要もありません!

更に詳しい情報についてはこちら: Acropolis: の拡張性(和訳予定なし)

データの高可用性についてはハイパーバイザーに関係なくNutanix分散ストレージファブリック(DSF ー Distributed Storage Fabric)は2つまたは3つのデータ/パリティを保持しており、SSD/HDDもしくはノードの紹介時に設定されたRFをクラスタ内のすべてのノードで復元します。

データの信頼性

データの信頼性だけが重要な要素ではないとはお話しましたが、やはりこれはキーとなります。結局のところ、データを失う可能性のある共有ストレージソリューションではあらゆるデータセンタの目的に見合ったソリューションにはなりえないのです。

データの信頼性についてはNutanixの分散ストレージファブリックの根幹ですから、データ信頼性のステータスはPrismのホームスクリーンに表示されます。以下のスクリーンショットで我々は信頼性が定常状態にいるのか、または障害(キャパシティのリビルド)時のイベントの両方を確認する事ができます。

この例ではクラスタ内のすべてのデータは設定されたResiliency Factor(RF2 または 3)コンプライアンスに従っている状態です。そして、クラスタは最低限のN+1のノード障害時のリビルドのためのキャパシティも確保しています。

信頼性のステータスのさらに詳細に分け入るためにはシンプルに上のボックスをクリックするだけです。そうすれば更に細かな障害からの保護についての詳細が表示されます。

以下のスクリーンショットはメタデータなどを示していまっす。OpLog(永続的Writeキャッシュ)とZookeeperなどのバックエンドの機能が監視されており、必要なときにはアラートが発行されます。

これらのどれか一つでも通常もしくは｢グリーン｣状態でない場合、Prismは管理者へアラートを発報します。アラートの原因がノード障害の場合、Prismは自動的に(Pulse経由で)Nutanixのサポートへと通知を行い、必要なパーツを出荷を初めます。大抵の場合、ハードウェアのメンテナンスのSLAが4時間オンサイトなどであったとしても、Nutanix XCPクラスタはハードウェアの到着よりも随分前に自己治癒を終えています。

これはNutanixがハードウェア(の交換)に依存しない信頼性をもっていることのまたとない例です。

データの完全性

ゲストOSとしてへのWrite I/Oの完了通知はデータが永続メディアに書き込まれた後のみであるべきです。これはこの時まではストレージがバッテリーバックアップのキャッシュや無低電源装置(UPS)で保護されていたとしても、データを失う可能性が伴います。

唯一のWriteの事前完了通知を行うメリットはパフォーマンスですが、良いパフォーマンスのためにデータの完全性やがデータそのものが失われてしまうリスクを犯しますか?

もう一つの一般的に見逃されがちなエンタープライズグレードのストレージソリューションについての要件はサイレントなデータの欠落を検出し、復元する能力です。Acropolisはソフトウェアで全てのWriteとRead両方にチェックサムをつけています。重要なことはNutanixはその下のハードウェアやサードパーティのソフトウェアにデータの完全性を維持するための機構で依存していないということです。全てのチェックサム発行と(必要な場合の)復元はネイティブで行われます。

プロのコメント : もしストレージソリューションがチェックサムをWriteとReadの両方で行っていない場合にはそのソリューションは本稼働環境では使わないで下さい。

サイレントなデータの欠落(あらゆるベンダーのあらゆるストレージデバイスがこの影響を受けます)が起きた場合、チェックサムが合わず、I/Oは別のノード(もちろん、物理的に別のSSD/HDD)上にある別のレプリカから取得されます。もしイレイジャーコーディング環境でチェックサムが合わなかった場合、EC-XがデータをHDD/SSD障害時と同様の方法で再計算し、I/Oを提供します。

バックグラウンドでNutanix Distributed Storage Fabricはデータの欠落を無効化し、設定されているResiliency Factorを壊れていないレプリカか、EC-Xが利用されている場合にはストライプから復元するのです。

このプロセスは完全に仮想マシンやエンドユーザーからは透過的に行われますが、XCPの信頼性に置ける重要なコンポーネントです。下にある分散ストレージファブリック(DSF)は自動的にAcropolis管理コンポーネントも保護します。これは全てのコンポーネントが一緒に作られていて、後からボルトドメされているわけではないAcropolisアーキテクチャの多くの先進性の1つの例です。

RF3(Replication Factor 3)に設定されているストレージコンテナのAcropolis環境ではN+2の管理の可用性が提供されます。結果として、ほとんど起きそうにもない、同時に3ノードの障害が起きない限りは管理が停止していまうということもありません。幸いなことにXCPはこの起こりそうにもないシナリオに対しても回答を持っています。ブロックアウェアネスを利用すれば3もしくはそれ以上のブロックでもクラスタを保護し、ブロック全体(最大4ノード)の障害においてもデータと管理をオフラインにせずに済みます。

Acropolisの信頼性周りの話の一部として、複雑性がないという話に戻りましょう。Acropolisは1クリックのローリングアップグレードをすべての機能において実現しています。単一障害点は一切ありません。最悪のシナリオとしてAcropolisマスターを載せているノードが障害を起こしたとしても、30秒以内に別の生き残ったノード上で次のマスターロールが再起動され、仮想マシンの電源を開始します。繰り返しになりますが、これは組み込まれた機能で、設計/インストール/維持が必要な追加もしくはサードパーティのソリューションを必要とはしません。

上で述べてきた点はAHV自身というよりは大部分がXCPの機能です、ですからAHVのロードバランシング機能と障害対応機能を取り上げたいと思います。

従来型の3階層のインフラストラクチャ(例 SAN/NAS)とは異なり、Nutanixのソリューションはマルチパスを必要としません。これは全てのI/Oがローカルのコントローラーから提供されるからです。結果としてマルチパスのポリシーの選択などの別のレイヤーの複雑性や潜在的な障害点になりうるものを排除できているのです。

しかしながら、ローカルのCVMが何らかの理由で利用できなくなった時には最も効率的な方法でI/Oをノード上のすべての仮想マシンに提供しなくてはなりません。AHVはこれを以下に示すようにvDiskレベルでランダムにリモートのStargateへI/Oをリダイレクトすることで実現しています。

AHVがこれをできる理由は全てのvDiskがiSCSI経由で提示されており、自身のターゲット/LUNを所有しているからです。つまりvDisk自体がTCP接続を保持しています。これは例えばMS SQL/ExchangeもしくはOracleのような複数のvDiskが必要となるようなビジネスクリティカルなアプリケーションを同時に複数のコントローラーで利用できるということを意味します。

結果として全ての仮想マシンのI/OはAcropolisクラスタ全体に負荷分散され、これによって単一のCVMがボトルネックにならないということを保証します。仮想マシンは障害時やメンテナンス時も素晴らしいパフォーマンスを得ることができるのです。

更に詳しくはこちら: Acropolis Hypervisor (AHV) I/O Failover & Load Balancing(和訳予定なし)

まとめ:

1. 以下に対応する最初から有効になっている自己治癒の機能:
   1. SSD/HDD/ノード障害
   2. Acropolis と PRISM (管理レイヤー)
2. 組み込みのデータの完全性とソフトウェアベースのチェックサム
3. 最大で4台同時のノード障害を無害化
4. 管理の高可用性は99.9999%以上 (シックス“ナイン”)
5. データと管理の信頼性についてはハードウェアに依存していない

更に詳しくはこちら: Ensuring Data Integrity with Nutanix – Part 2 – Forced Unit Access (FUA) & Write Through(和訳予定なし)

インデックスへ戻る

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

今回はもっとも重要な･･･そして長い記事です。データの信頼性はもちろん、管理コンポーネントの信頼性についても記載されていますが、AHVの優れている(そしてユニークな)ポイントはvDisk一つ一つを仮想マシンがiSCSIでTCP接続しているという点でしょう。iSCSIの接続が切れる(CVMの障害などで)場合でも瞬時に別のCVM経由で再接続され、I/Oの停止は発生しません。これはNFSやCIFSで接続されている他のハイパーバイザーでは実現できない･･･つまりNutanixなりの思い切った実装が元になっています。

こうした複雑なことをしていても、Prismがそれをキレイに覆い隠してくれる･･･それがNutanixのいいところですね。さて、次は第6弾ですが、明日はちょっと別の内容をはさみます。

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はHow Nutanix Marketplace Brings Developers and IT Togetherをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

ニースにおいて、我々は新しいエンタープライズのための先進的なパブリッククラウドのような消費モデルの開発者中心のサービスを発表しました。この記事では開発者とITをより緊密にするという我々の見通しを共有させていただきます。そこではよりよいコラボレーションが育まれ、アプリケーションの俊敏性が増すことになります。これによって組織に劇的な効果が上がることになるでしょう。

開発者とITに共通して必要とされる一般的な目的には市場への迅速な投入の加速、対応時間の短縮、インフラストラクチャの問題の解決に費やす時間の最小化などがあります。しかしながら、開発者は最新の技術の取り込みとオンデマンドなリソースの提供に目を向けがちで、IT側はアプリケーション開発者を手助けする適切なツールの必要性についてはしばし目を伏せがちです。Nutanixは既に管理、アップグレード、ITリソースの拡張のシンプル化などの優れたプラットフォームを提供することで市場への投入時間を短くするという部分については提供をしてきています。しかし開発者は本当にサービスの提供についてNutanixプラットフォームを利用していることの価値を感じているのでしょうか?例えば、コンテナの世界に置ける最先端のイノベーションを活用できているでしょうか?開発の業務に集中できるようにするために自動的にコンテナプラットフォームが展開される様になっているでしょうか?ここにNutanix Marketplaceが登場してきた意味があります。

セルフサービスのちからを与える ー ワンクリック、エニークラウド

Nutanix Marketplaceは我々の2017年Q4でのリリースを予定しています。開発者に一箇所からただのワンクリックで必要なアプリケーションリソースを瞬時に利用開始できるようにします。チームにとっては自身のための特別オーダーメイドとなる様々な展開オプションをユーザーの役割とグループに応じて手に入れることができるようになります。Nutanix Marketplaceからアプリケーションの1つを起動するということは、MarketplaceやまたはカスタムのITが事前に作成した、事前に定義された全体が自動化された手順のフローをインスタンス化するということです。これには仮想マシン、バイナリ、必要なアプリケーション構成が含まれています。これを利用することで開発者は自分自身の必要とするスピードで完全にセルフサービスの状態でサービスを利用することができます。

ITの観点からは、単により良く、迅速なサービスを提供できるということだけに留まりません。アプリケーションはマーケットプレイスからいつも実行可能ですし、再現性があり、数日もしくは数ヶ月のアプリケーションの展開や管理の提携作業を取り除くことになります。すべてのユーザーのアクティビティはエンドツーエンドで追跡可能で、トラブルシューティングや互換性のニーズを解決することにも役立ちます。

マーケットプレイスは我々のオープンなアプローチということを前提に設計されています。開発者はアプリケーションをオンプレミスに、もしくはパブリッククラウドにもしくはその両方にまたがっても展開するということを選択することができます。結果としてITはマルチクラウド戦略を実現しながら、その利用状況やクラウドをまたいだリソースのコストについても可視性を手に入れることができるのです。

事前統合のBlueprint

開発者は常に新たな開発、検証、コード投入の新しい考え方やツールを取り込むことで開発のプロセスを改善しようと考えています。これを最終目標として、Nutanixは事前に統合され、検証の済んだblueprintを提供し、ITチームが新しいテクノロジーを自身の環境に迅速に導入できるようにします。これらの事前統合されたblueprintを用いることでIT部門は開発者とともに新しいツールを迅速に試験導入し、共同でそれを利用するかどうかの決断をすることができます。この能力は新しいツールの実権を育むということだけではなく、チーム間のコラボレーションを生み出すことにもなります。

上のスクリーンショットではJenkins、Puppet、Hadoop、そしてMySQLなどの事前統合されたblueprintを確認することができます。NutanixはGoogleとのパートナーシップの中でコンテナのオーケストレーションプラットフォームであるKubenetesのblueprintも提供します。このblueprintではNutanixのオンプレミスとパブリック裏ウドの療法へKubernetesクラスタを展開することができます。以下のスクリーンショットでは35ページにも及ぶガイドが必要なほど複雑で、多くのコンポーネントと様々なスクリプトが必要になる点っかい手順がシンプルなblueprintへと翻訳され、マーケットプレイスからワンクリックで利用可能になるということを確認できます。

まとめると、Nutanix MarketplaceはIT部門に対し、開発者のための優れたセルフサービス環境を実現するための素晴らしい方法をご提供しながら、より良い統制とマルチクラウド戦略への簡単な道筋を提供します。Nutanixでの自動化についてもっとよく知りたいですか? Nutanix CalmのページまたはCalmの技術メモをダウンロードして下さい。

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology, our plans to introduce product features in future releases, product performance, competitive position and potential market opportunities. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, Acropolis Compute Cloud, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

今回もニースで発表になった内容の記事となります。Nutanix Calmはマルチクラウド環境に置けるオーケストレーションを実現するのみならず、スケールアウト、アップグレードなどのアプリケーションライフサイクル全体をコントロールする意欲的なプラットフォームです。

このCalmを最も簡単に利用できるようにするのがこのNutanix Marketplaceです。ワンクリックとある通り、Nutanixの上にこのマーケットプレイスのアプリケーションを展開するのは本当に簡単で、新しい技術を少し試してみようというところから、その先に本格的に導入しようという場合、そしてその環境をパブリッククラウドへと移行させようという場合、様々なライフサイクルの局面で利用することができます。

自動化って･･･開発者のものだよねもしくはDev/Opsだよね、というちょっと大変そうな道ではなく、ワンクリックで簡単な道を用意してくれています。閉ざされた自動化が少しでも開ければと思い、私も期待しています。登場が待ちきれません。(翻訳時には登場が待ちきれませんでしたが、なんとリリースされています!)

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 6 – Performanceをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

性能についてお話をする際に、4KのI/Oベンチマークを使うなど、非現実的なスピードを比較対象として並べていくのは非常に容易いことです。ですが、すべての本当のデータセンタの技術のエキスパートが知っているとおり、IOPSはパズルの本の小さなピースでしかないのです。私の意見では、IOPSはこれほどまでに注目をあびるべきではないほどの注目を浴びています。これについてはこちらの記事でお話をしています。ピークパフォーマンス vs 実際の世界のパフォーマンス。

性能についてお話をする際に、私は管理コンポーネント、アプリケーション/仮想マシン、分析、データの信頼性などのすべてとその間のものも含めてお話をしていきます。

さて、AHV(旧称: Acropolis Hypervisor)を動作させているNutanix XCPが全てのコンポーネントにおいて一貫した高いパフォーマンスを保証している幾つかの例を見ていきましょう:

管理の性能:

Acropolisの管理レイヤにはAcropolis Operating System(以前のNOS)、Prism (HTML5のGUI)、そしてAHVの管理スタックが含まれており、｢マスタ｣と｢スレーブ｣のインスタンスからなっています。

このアーキテクチャは全てのCVMが動作し、各々平等にプラットフォームの全てのエリアで継続的にスムースに動作することができるように、保証しています。つまり、中心となるアプリケーションやデータベースやコンポーネントは存在せず、それがボトルネックになることもないのです。完全に分散させることこそがウェブスケールプラットフォームを提供する鍵です。

おのののコントローラー仮想マシン(CVM)はローカルノードの管理に必要なコンポーネントと分散ストレージファブリックと管理タスクに貢献するためのコンポーネントを動作させています。

例 : 1つのAcropolis｢マスタ｣が居ますが、これは単一障害点でもパフォーマンスのボトルネックでもありません。

Acropolis マスタ は以下のタスクを担当します:

1. HAのスケジューラー
2. ネットワークコントローラー
3. タスクの実行者
4. ハイパーバイザーからのローカルの統計を収集/提出
5. 仮想マシンのコンソール接続のVNCプロキシ
6. IPアドレスの管理

各々のAcropolis スレーブ は以下のタスクを担当します:

1. ハイパーバイザーからのローカルの統計を収集/提出
2. 仮想マシンのコンソール接続のVNCプロキシ

マスタであるか、スレーブであるかにかかわらず、各々のCVMは2つの最も重たいタスクを実行しています。ハイパーバイザーからのローカルの統計を収集/提出と利用している場合は仮想マシンのコンソールの接続です。

初めから分散して設計されているため、XCPのプラットフォームは一貫した高いパフォーマンスを達成できています。中央の、例えば中心となる管理仮想マシンとそれに紐付いたデータベースサーバへ統計情報を送信することはボトルネックになりえますが、何らかの形でのアプリケーションレベルのHA(例 : SQL Aways on Availability Group)が導入されていない場合、これは単一障害点にもなりうるため、殆どのお客様でこれは受け入れがたい状態です。

Acropolisマスタが行っている役割はHAのスケジューラーやネットワークコントローラー、IPアドレス管理、タスク実行者など、全て軽量なタスクです。

HAスケジューラータスクはノード障害時にしかアクティブにならないタスクで、マスタにとってのオーバーヘッドは非常に小さいものです。ネットワークコントローラーのタスクは新たなVLANを構成する際などにしか利用されません。タスクの実行は全てのCVMで実行されている分散されたすべてのタスクを継続的に監視するシンプルなものです。IPアドレスの管理は基本的にはDHCPのサービスで、これも非常に小さなオーバーヘッドです。

パート8で、Acropolis Analyticsについて更に詳しくお話します。

データローカリティ

データローカリティはXCPの他にはない機能で、新しいI/Oは仮想マシンが動作しているローカルノードとクラスタ内の他のノードにレプリケーションされて書き込まれるというものです。データローカリティは次回以降のReadのI/Oがネットワークを経由して転送され、リモートのコントローラーを利用するという必要性を排除します。

仮想マシンがクラスタ内を移動する場合には、WriteのI/Oは常にローカルに書き込まれるため、リモートからのリードはリモートデータのReadが必要な場合にのみ発生します。もしもデータがリモートに有り、その先アクセスされないのであればリモートのI/Oは発生しません。結果として大抵の場合、90%以上のI/Oがローカルから提供されることになります。

現在、うまく設計された10Gbのネットワークでは帯域とレイテンシの問題はさほど問題にならないかもしれませんが、フラッシュのパフォーマンスが幾何級数的に向上していくにつれ、ネットワークは非常に高価な40Gb(もしくはそれ以上の)のネットワークへの移行なくしては簡単に大きなボトルネックとなります。データローカリティは大部分のRead I/Oをローカルから提供し、Writeのコピーのうちの一つをローカルでさばくことによってWrite I/Oからのネットワークのオーバーヘッドを減らすことでネットワークへの依存関係を最小化することに役立ちます。ですから、ローカリティはお客様がパフォーマンスに妥協すること無くより低コストなネットワークを利用することを可能にするのです。

データローカリティはサポートされている全てのハイパーバイザーで動作しますが、AHVは他にはないデータアウェアな仮想マシンの配置をサポートしています : 仮想マシンは障害時やメンテナンス時に仮想マシンのデータのローカルデータの割合が最も高いノードで、つまりリモートのI/Oの可能性が最も低くなるノードで電源が入りそれぞれの仮想マシンのI/Oのオーバーヘッドが低くなります。

さらに、データローカリティはハイパーバイザーや仮想マシンの統計データなどの分析のためのデータの収集についても適用されます。結果として統計データはローカルに書き込まれ2つ目(もしくはRF3が設定されている場合には3番目も)はリモートに書き込まれます。これはつまり、統計データ、非常に膨大にもなりうるデータが分散ファイルシステムとクラスタに有りうる限りの最小限の影響しか与えないということも意味しています。

まとめ:

1. クラスタとともに管理コンポーネントも拡張され、一貫したパフォーマンスを保証する
2. データローカリティがデータがコンピューティング(仮想マシン)とデータを可能な限り近くにあることを保証する
3. データの場所をベースとしたインテリジェントな仮想マシンの配置
4. 全てのNutanixコントローラー仮想マシンはチーム(ペアではない)で動作し、クラスタ内のすべてのコンポーネントとワークロード(仮想マシン)に適切なパフォーマンスを保障

インデックスへ戻る

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

さて、皆様の大好きなパフォーマンスに関連する記事になりました。XCPという名前が多用されているとおり、記事が古いので現在のAHVはこれはさらに先を行っています。

仮想マシンの配置はよりインテリジェントなものとなり、vSphereでいうDRSに相当する動的なものになっていますし、AHV Turboモードによって、ハイパーバイザーを通過する際に発生するオーバーヘッドもNutanixにとっては過去のものになりつつ有ります。

常に進化を続け、購入したノードの性能もソフトウェアで向上していく･･･そうしたNutanixの魅力の一つで外せないのが、この性能で、その中心にあるのがAHVなのです。

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 7 – Agility (Time to value)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

他のハイパーバイザーと管理蘇シューションを展開する時には、一貫したパフォーマンスを保証したり、ダウンタイムのリスクを最小限に留めるためにある一定のデザインのための労力とそれの作業への専門性が必要です。一方で出来る限りの俊敏性も実現しなくてはならないのです。Acropolisの管理には全くと言っていいほど殆ど設計は必要ありません。組み込みの管理ソリューションは最初から最適化されており、高可用性を備えているからです。これによって他のハイパーバイザーとそれに紐づく管理コンポーネントの展開よりもAHVはより早い展開を実現することが可能です。

AHVをベースとした環境の最初のサイズを気にすること無く、すべての管理、分析、データ保護、そしてBC/DRコンポーネントは自動的に展開され、適切にサイジングされます。AHVのクラスタに限った話ではありませんが、管理の設計の労力は必要ありません。これによって非常に早く(大抵の場合、1時間以内で単一ブロックの展開)その価値を発揮し始めます。

AHVは数え切れないほどの機能も提供し、お客様が迅速にソリューションを展開できるようにしています :

• 組み込みの管理&分析

クラスタの管理に必要なすべてのツールが自動的にクラスタ内に展開されているという事実は、価値提供開始までの時間はこうしたツールの設計/展開/検証のいずれにも依存していないということを意味しています。AHVを管理するためのクライアントをインストールするという必要性もありません。単にウェブブラウザでアクセスすれば良くなっています。

• 組み込みのセキュリティ/コンプライアンス監査による、出荷時からの要塞化構成

最初から要塞化されていることで、実装フェーズでセキュリティが崩壊してしまうというリスクを排除することができます。それと同時に、自動化された監査によって、普段の運用の中でセキュリティの設定を変更してしまうというようなことがあったとしてもそうして変更されてしまった設定はセキュリティプロファイルで決められているものに戻されます。

• インテリジェントなクローン作成

分散ストレージファブリックとの統合により、AHVはほとんど一瞬で仮想マシンのクローンを行うことができます。この機能は仮想マシンの電源の状態には関係ありません。ですから、他のハイパーバイザーのように仮想マシンの電源がオフでないといけないというような制限はないのです。

この機能のデモについてはこちら: Nutanix Acropolis hypervisor acli cloning operations

注意: クローンについてはPrismもしくはacli(Acropolis CLI)で行えます

まとめ:

1. 最小限の設計/実装の労力でAHVは管理することができます
2. マルチクラスタの一元管理が必要な場合、単一の仮想マシン(Prism Central)のみが必要となり、これは仮想アプライアンスとして展開できます
3. 分析、データ保護、レプリケーション、管理の高可用性化のための追加アプライアンス/コンポーネントは必要ありません
4. 適切なAcropolisプラットフォームの展開に何かに特化した専門家が必要になることはありません

インデックスへ戻る

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

さて、パート7は少し短めです。ですが、ビジネスにおいて最も効果を発揮する部分もここでしょう。数週間から数ヶ月掛けてインフラを展開するということも以前は非常に多かったのですが、Nutanixに関して言えば当社のSEがご支援に入って、一週間以上に渡って作業するということは(ハードウェアの設置やNutanix以外の部分を除くと)まずありません。

つまり購入して、すぐにその価値を発揮し始めるNutanixを採用することは投資回収期間を大幅に縮めることにつながります。(もちろん、更にソフトウェアアップグレードでその価値が継続的に上がっていくということも!)

長かったシリーズもあと2つになりましたが、後2日おつきあいお願い致します。

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 8 – Analytics (Performance / Capacity Management)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

AcropolisはAcropolisプラットフォーム、コンピューティング(AHV/仮想マシン)、そしてストレージ(分散ストレージファブリック)をカバーする強力かつシンプルに使える分析ソリューションを提供しています。

他の分析ソリューションとは異なり、Acropolisは追加で設計/展開もしくは構成が必要となるソフトウェアライセンスや管理インフラストラクチャ、もしくは仮想マシンやアプライアンスを必要としません。Nutanixのコントローラー仮想マシンは組み込みで分析機能を提供し、一切外部へ依存関係を持っていません。別の製品や仮想アプライアンスにデータを展開/取込が必要にならないということは、オーバーヘッドが小さいということにもなります。つまり、保存するデータが小さくなるということで、ストレージへの影響も小さくなります。

この機能は組み込みで初日から使えるというだけでなく、環境が時を経て成長するに連れて、Acropolisは自動的に分析機能を拡張していきます。どこかでしきい値を超えて追加のインスタンスを展開する必要性や、分析のための仮想アプライアンスのコンピューティング/ストレージのリソースの割当を増やすまたは、バックエンドにデータベースを追加するというようなことには永遠にならないのです。

分析UIのデモについては以下のYoutubeのビデオを4:50から御覧ください : 

YouTube: Nutanix Prism UI - 28 nodes

まとめ:

1. 組み込みの分析ソリューション
2. 追加でのライセンスを必要としない
3. 設計/実装もしくは仮想マシン/アプライアンスの展開の必要はありません
4. XCPのクラスタが成長するのとともに自動的に分析機能もスケールします

Acropolisに組み込まれているためオーバーヘッドは小さく、分散ストレージファブリックを活用できます。

インデックスへ戻る

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

今回はデモビデオを見て頂く･･･という記事なのですが、分析ソリューションが組み込まれていて、小さなオーバーヘッドで利用できるということは非常に重要です。

また、Prismの使いやすさは見ていただいて理解頂くのが一番です!ぜひビデオをじっくり御覧ください!

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 10 – Costをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

コストがリストの一番下にあって、驚かれている方もいらっしゃるかもしれません。ですが、これまでの記事を読んできていただいた方はおそらく、業界の他の製品と比べてAHVが様々な面で優れた仮想化プラットフォームであるということにお気づきでしょう。私の意見では、Starterエディションに含まれているから、AHVを｢低価格なオプション｣もしくは｢機能に制限のある廉価なハイパーバイザー｣と考えるのは誤りです。(これは全てのNutanixのお客様に無償で提供することにしているという意味でしかありません)

ハイパーバイザーやその管理コンポーネントのライセンス/ELAが明らかに削減されるという点を考慮しないとしても、AHVを利用して頂く実際のコスト上のメリットは劇的な設計、実装、運用の様々なフェーズともちろん、日々の管理の労力の劇的な削減です。

この原因は多くの要素からなります:

設計フェーズのシンプル化

すべてのAHVの管理コンポーネントは組込されており、高可用性構成で、自動的にスケールします。目的に特化した専門家(SME ー Subject Matter Expert)を管理ソリューションの設計に巻き込む必要もありません。何年にも渡って数え切れないほどの高可用性仮想化ソリューションを設計してきた人間の一人として、AHVは最初から私が過去にお客様のために他の製品を利用しながら夢に描いて来たもの、そのものです。

実装フェーズのシンプル化

すべての管理コンポーネント(Prism Centralという例外はありますが)は自動的に展開され、エンジニアがこれらのコンポーネントをインストール/パッチ/要塞化するという要件は存在しません。

Acropolisとすべての管理コンポーネントはすべてCVM内に組み込まれています。これは間違いの起こる可変の部品が少ないということを意味し、それらの検証を行う必要もありません。

経験的に、運用の検証は大抵の場合見落とされがちで、インフラストラクチャはその設計要件とその導入効果が実証される前に本稼働環境へと投入されてしまいます。AHVでは管理コンポーネントは自動的に展開され、コンポーネントが提供されないというリスクはまったくもってありません。更に運用上の検証を行うにしても、従来型の製品とは異なり、可変できる部分が非常に少ないため、検証は非常に早く終えることができます。

日々の運用のシンプル化

AcroplisはAcroplisベースソフトウェア(以前はNOSと呼んでいました)、AHV、ファームウェア、そしてNutanixクラスタチェック(NCC)に対して完全に自動化されたローリングアップグレードの機能を提供しています。それだけではありません、アップグレードのダウンロードの前に互換性のないヴァージョンインストールしてしまうリスクを排除してやハードウェア互換性リスト(HCL)や互換性マトリックスをチェックしてからダウンロードされます。

AHVはキャパシティ管理を劇的にシンプルにします。これは必要とされるキャパシティ管理がストレージプールレイヤだけであるということに由来します。管理者がLUN/NFSマウントするもしくはコンテナにおいてキャパシティを管理するという必要はありません。この能力はよく知られているハイバーバイザーが持っている、例えばvSphere ストレージ DRSの必要性も排除します。

サードパーティのライセンスコストの削減

AHVにはすべての管理コンポーネントが含まれています。もしくはPrism Centralを利用する場合においても事前にパッケージされたアプライアンスを使うだけです。すべてのOSのライセンスは発生しません。すべてのNutanixノード上で動作している高い信頼性を持つ管理コンポーネントはMicrosoft SQLやOracleというようなサードパーティのデータベース製品、もしくはベストなケースで仮想アプライアンスを展開すればよいという場合であったとしてもこれらは高可用性を欠くもので、バックアップや維持が必要になります。AHVではこれらの必要性を排除しています。

管理用インフラストラクチャのコストの削減

仮想化ソリューションに10もしくはそれ以上の管理コンポーネント(それぞれが専用の仮想マシンになっている場合がほとんど)が必要になるということはよくある話です。小さな環境においても一元管理、パッチ、パフォーマンスやキャパシティの管理の機能を利用しようとすればこれらが必要になってしまいます。環境が成長するについれて、もしくは高い可用性の要件が必要になるに連れて、管理仮想マシンの数とそのためのコンピューティングの要件は増えていく傾向にあります。

すべての管理コンポーネントはNutanixコントローラー仮想マシン(CVM)の中で動作しており、CVMはそれぞれのNutanixのノードで起動しています。専用の管理クラスタは必要ありません。コンピューティング/ストレージのリソースの総量も減らすことができます。

管理用インフラストラクチャの削減からの間接的なコスト削減は以下を含みます:

1. ラックスペースの削減 (RU)
2. 電源/空調の削減
3. ネットワークポートの削減
4. コンピューティングノードの削減
5. ストレージキャパシティとパフォーマンス要件の低減

大事なことを言い忘れていました、メンテナンスウィンドウやシステム停止時にかかるコストはどうでしょうか?

Acropolisは完全に非破壊的なワンクリックのアップグレードを提供しており、多くの障害ポイントを削減しています(例 : サードパーティのデータベース)、その一方で、非常に信頼性の高いプラットフォームを提供しています。AHVはお客様のメンテナンス時やシステム停止時のコストも削減してくれます。

まとめ:

1. Acropolisの管理コンポーネントの設計は必要ありません
2. 管理コンポーネントの日々の維持運用も必要ありません
3. 複雑性を削減し、ダウンタイムやヒューマンエラーによるダウンタイムの可能性を削減します

インデックスへ戻る

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

全10回(実質9回)の本シリーズはこちらでおしまいです。残念ながら原文のパート9の内容はパスワードで保護されているため、日本語にしたとしてもこちらで公開することはできません。

ですが、パート9がなかったとしてもAHVが如何に優れたハイパーバイザーであるかということはお伝えできたのではないかと思っています。しかも、本記事を翻訳している間にAOS 5.5がリリースされ、AHV Turboを含む様々な最新の機能が現在進行形で取り込まれています。次世代である上に更に歩みを止めずに進化し続けている唯一のハイパーバイザーと呼んでよいのではないでしょうか。

最後に今回、9にもなるシリーズ、つまり9日間分のブログの翻訳を決意させてくださった、NutanixのAdvent Calender周辺の管理者の皆様、誠にありがとうございます。まさかの2枚目のカレンダー、今年何をやり忘れているか･･･。AHVでした。来年はAOS 5.5と一緒に登場した新機能で更に武装を強化し、Year of AHVにしましょう!

また、毎日のように更新されるブログを呼んでくださった皆様、ありがとうございます。

　ここまではXtract for VMsを使ったvSphere環境からAHV環境へ移行する仕組みをデータ転送の仕組みから紹介してきました。今回はvSphere環境のESXiからAHV環境へハイパーバイザーを変更した場合に、「ゲストOSにどういった変更が起こるのか？」「変更をどうやってXtract for VMsが吸収しているのか？」といったところを掘り下げて紹介してみたいと思います。

ハイパーバイザー変更の影響とは？

　昔々、「仮想サーバ」が当たり前になる前の時代は、サーバに直接OSをインストールして利用する「物理サーバ」が一般的に利用されてきました。vSphereを始めとするサーバ仮想化ソリューションを導入する際には、Physical Server(物理サーバ)からVirtual Server（仮想サーバ）に移行するためにP2Vと呼ばれる移行作業が必要でした。例えばvSphereの場合vCenter Converterと呼ばれるツールが提供されていて、物理サーバから仮想サーバに容易に行えるようなツールが提供されていました。

物理サーバから仮想サーバに移行する際に注意が必要な事項には以下のようなものがありました。

・ハードウェアが変更される

・NICのMACアドレスが変更される

・元々導入されていたハードウェアのユーティリティが悪さをする

・元々導入されていたセキュリティソフトが悪さをする

　物理サーバの場合、HPE社のProLiantの場合、DELL社のPowerEdgeの場合などサーバベンダーごとにインストールされるユーティリティが異なったり、利用していた共有ストレージがあったりすると、ストレージベンダーが提供されるユーティリティも入っていたりと、サーバごとにハマりどころがあったりしました。

 Xtract for VMsは移行元環境はESXiだけを想定すればいいため、こういったハマりどころはありませんが、ハードウェアの変更やMACアドレスの変更といったものはP2Vと同様で発生します。

　Xtract for VMsは移行元仮想マシンにエージェントソフトなどを導入することなく移行可能というのがウリの1つだったりしますが、移行時には自動的にこういったハイパーバイザーの変更を吸収するためにスクリプトだったりドライバのインストールだったりが行われます。

　だったりで済ますと話が終わってしまいますので、皆さんが興味をお持ちの裏側でどういった処理が実行されているのか前回同様ログファイルから追ってみたいと思います。

ハイパーバイザー変更に備えるXtract for VMsの裏側～移行前処理～

　Xtract for VMsではハイパーバイザーの変更に備えて、様々なタスクを実行します。例えばvSphereで利用していたディスクコントローラはAHVではVirtIOに切り替わります。例えばWindows OSではInboxではVirtIOのドライバはもっていません。そのため何も対策をしないで移行しても、AHV環境で移行元の仮想マシンを起動してもシステムディスクが検出できずに起動すらできません。

　Xtract for VMsではこういったことを防ぐために移行元仮想マシンが移行元ハイパーバイザーで稼働している状態でもいくつかのタスクを実行しています。これらのタスクを実行する前にはスナップショットを取得しているため、万が一何かあったとしても容易に元の状態に復帰することが可能です。

xtract-srcagent.logファイルをざっと眺めてみると、以下のようなタスクが実行されていることがわかります。

1. Checking admin permissions
2. Checking windows installer version
3. Adding Nutanix sha1 certificate
4. Adding Nutanix sha2 certificate
5. Loading user profile
6. App Mobility drivers are NOT installed
7. Setting SAN Policy=OnlineAll
8. Retaining IP information

　これらのタスクが実際にどんなことをやっているのか、なぜ必要なのか見ていくことにしましょう。ログファイルをみると実際にこれらのタスクを実行時に呼び出されているスクリプトファイルも確認することができます。これらのタスクで必要なファイルはXtract for VMsの仮想アプライアンスの中の「/opt/xtract-vm/resources/」に保存されているファイルが適宜移行対象の仮想マシンにアップロードされて実行されているようです。

Checking admin permissions

　これはわかりやすいですね、そのままの通りでXtract for VMsではMigration Planを作成する際にゲストOSの認証情報を入力する必要があります。この入力したユーザアカウントがこの後のタスクで必要になるローカルAdministratorの権限を持っているかどうかの確認を実施しています。

Checking windows installer version

 これはこの後のタスクとしてAHV環境で必要なドライバ群をインストールする際に要求されるWindowsインストーラのバージョンを確認しています。msiexec.exeファイルのバージョンを確認して一定以上のバージョンでない場合、エラーを返すようになっているようです。

Adding Nutanix sha1 certificate / Adding Nutanix sha2 certificate

 なんで証明書なんて追加しているの？と思われるかもしれませんが、昨今のWindowsではドライバ署名の証明書が不正だとそもそもインストールできないといったことがあります。そのため事前に証明書ファイルをコピーしてインストールするといった流れを自動的に行っています。

Loading user profile

　これは…。何者なんでしょうかね？きっと以降のタスクでユーザプロファイルに含まれる環境変数とかが必要だから読み込んでいるんじゃないかと推測しています。

App Mobility drivers are NOT installed

　AHVで必要になるドライバ群（App Mobility drivers）をインストールします。これによってAHV上での初回起動時にシステムディスクが見つからないといったことがなく起動が可能になります。事前にインストールしておくだけなので、移行元仮想マシンの再起動が必要といったこともありません。

Setting SAN Policy=OnlineAll

　SANなんて構成してないけど…って思われる方もいらっしゃるかもしれませんが、Windowsのディスク管理のポリシーの名前がSAN Policyです。最近のWindowsに対してホットアドでディスクを追加（拡張ではない）すると、追加したLUNがオフライン状態で認識していることにお気づきでしょうか？

　　これはWindows OSのSAN Policyの設定が既定ではオフライン共有になっており、新規のLUNを検出したときの動作はオフライン状態となります。それではDドライブ等がオフライン状態で起動されてしまい、アプリケーションが正常に動作しなくなることになります。そこで常にオンライン状態となるようにポリシーを変更するためにdiskpartコマンドを実行してから移行を実施しています。

Retaining IP information

　これもその名前のとおり、移行元仮想マシンのIPを保持するためのタスクになります。先ほどハイパーバイザーを変更する際にハードウェアが変更になると説明しましたが、Windowsではハードウェアが変更されると「ローカルエリア接続＃2」というようなインターフェースが新規作成され既存の「ローカルエリア接続」の設定を引き継ぐことはできません。

　そこでXtract for VMsでは事前に既存のネットワーク設定のバックアップを取得して、移行後の初回起動時にネットワーク設定のリストアを実施することで力業ではありますがネットワーク設定を引き継ぐことを可能にしています。但し現在のバージョンのXtract for VMsはこういった若干力業でネットワーク設定を移行していることもあり、NICの順序などを意識しなくてはいけない2個以上のNICを持った仮想マシンの移行時にはネットワーク設定を引き継ぐことができないような仕様になっています。この場合、この後紹介する移行後処理として手動でIP設定を引き継ぐ必要があります。

ハイパーバイザー変更に備えるXtract for VMsの裏側～移行後処理～

　Xtract for VMsでは移行後のクリーンアップは自動では行われません。管理者が移行完了後に行う必要があります。不要になったVMware Toolsのアンインストールや、非接続状態のデバイスの削除はAHVに移行が行った後で、必ずスナップショットを取得してから実行しましょう。

まとめ

　ここまで3回にわたってXtract for VMsを使ったvSphere環境からAHV環境への移行について紹介してきました。Xtract for VMsのような移行ツールは裏側の動きがブラックボックスになっているとなかなか怖くてとっつきにくいですが、こうして中身がわかってくると安心して利用いただけるのではないでしょうか？

　Xtract for VMsを利用することで、お使いのvSphereの環境からシステム停止の時間を最小限にして移行を行うことができます。今まで既存システムの移行がハードルでＡＨＶの採用を見送ってきた方は、是非一度Xtract for VMsを使った移行を検討していただければと思います。

HPE教育サービスの中川明美です。

3回目はvSANと連携するｖRealize Operations ManagerとvRealize Log Insightについてご紹介します。

#1: VMware vSAN 6.6 What’s New

#2: トラブルトラブルシューティング時に役立つツール　1

#3: トラブルトラブルシューティング時に役立つツール　2

ｖRealize Operations Managerはソリューション(アダプタ)を、vRealize Log Insightはコンテンツパックの追加なく、デフォルトでvSANに関するデータを表示することができるようになりました。こちらのBlogでは、ｖRealize Operations Manager 6.6.0、vRealize Log Insight 4.5.1を使用しています。

ｖRealize Operations Manager (vROps)

「管理」画面の「ソリューション」で、「VMware vSAN」を選択し、「構成」でvCenter Serverの名前と認証情報を入力します。その後データの収集が開始されます。

「ダッシュボード」の「はじめに」では、標準ダッシュボードが提供されます。これらは5つのカテゴリ (赤枠線内) に分けられます。

ｖSANに関わる標準ダッシュボードは次の4つです。右ペインのダッシュボードを一度選択すると、左ペイン(赤枠点線内)にダッシュボードの名前が表示されます。

個人的には、「vSANのトラブルシューティング」ダッシュボードがお勧めです。このダッシュボードを使用すれば、ｖSANの構成や状態、キャパシティやパフォーマンスまで確認できます。

どのような情報が得られるかを確認します。17項目が大きく3つに分けられています。

< ①ｖSANクラスタから始めましょう >

ｖSANクラスタの構成情報やアラート、クラスタ全体のパフォーマンス状況を表示します。

< ②参加しているホストとディスクグループを見てみましょう >

ディスクグループおよびvSANクラスタ内のESXiホストの情報やワークロードを表示します。

< ③キャッシュおよびキャパシティディスクの健全性を確認します>

ヒートマップで、キャッシュディスクとキャパシティディスクの健全性を表示します。

2つのアラートが気になりますが、後ほど確認します。

vRealize Log Insight

管理画面の「統合」で、「vSphere」を選択し、vCenter Serverの名前と認証情報を入力します。その後Logが収集されます。

vSANは10のダッシュボードが提供されています。下図は、「Object Events」を選択した画面です。コンポーネントの5つの状態を表示します。

「Absent」イベントが発生しているのが気になります。グラフをクリックすると、メニューが表示されます。「インタラクティブ分析」を選択し、詳細な情報を表示します。

下図は、「Absent」のインタラクティブ分析画面です。

ここでは、ホストの停止を想定し、vSANクラスタを構成する1台のESXiホストをメンテナンスモードにしました。メンテナスモードへ切り替えた時と、終了した時に生じたイベントを確認します。

<Absentのインタラクティブ分析>メンテナンスモードに切り替えた時のイベント

接続可能な「active」状態から、接続不能な「absent」状態へ変更しています。

<Resyncingのインタラクティブ分析>メンテナンスモードを終了した時のイベント

オブジェクトは、古さを表す「Stale」状態から、再同期の「resyncing」へ遷移しています。オブジェクトとは、VMホームのネームスペース/vmdk/スワップファイル等を指します。

「'oldCompState'： 'active', 'newCompState'： 'absent'」イベントは、クラスタやオブジェクト/コンポーネントの問題と考えられます。たとえば、クラスタ内のESXiホストの切断、コントローラのリセット、ディスク/ディスクグループの障害が発生しているのではないかと推測できます。

また、このイベント/ステータスが一時的であるかどうかは、同じUUIDに対して反対のログ「'oldCompState'： 'absent', 'newCompState'： 'active'」が表示された場合に判断できます。

「Decommissioning」ダッシュボードを確認すると、Absentイベントが発生している時間帯で、メンテナンスモードに切り替えられたことがわかります。

Log Insightは、膨大なLogをカテゴライズし、視覚的にわかりやすい情報で表示されること、インタラクティブ分析で関連する詳細なLogを表示できることがメリットですね。

最後に、vROpsに表示されていた警告表示のアラートを確認します。

アラートをクリックすると、下図の画面が表示されます。KBが表示され、キャッシュサイズの検討を促しています。その下には「詳細情報が必要ですか？」とリンク表示があります。

「追加メトリックの表示」と「ログの表示」をクリックしてみます。

◆追加メトリックの表示◆

読み取りキャッシュに黄色のひし形で警告表示されています。メトリックではキャッシュヒット率の変遷を確認できます。

◆ログの表示◆

vROpsでLog Insightの情報を追加すれば、連携することも可能です。この画面では、キャッシュヒット率が0%になった時間帯で検索し、イベントを表示しています。

vROpsの2つのアラートは、メンテナンスモードに切り替えたことが要因で通知されました。実際の環境でESXiホストが切断され、キャッシュヒット率が低下していたなら、パフォーマンス劣化を招いていたかもしれません。状況を把握しておけば、慌てず対処できますね。

ｖSAN 6.6になって、監視/管理系のツールが強化されています。情報があり過ぎても管理者としてはどう活用するべきかを悩みますね。こちらのBlogでは、ここを押さえておけばある程度のトラブルシューティングができるのではないかとポイントを絞ってご紹介いたしました。

お役に立てましたら、幸いです。

HPE教育サービスでは、vSANのVMware認定コースを提供開始します。トラブルに対応するにはアーキテクチャを知ることは重要です。ぜひこの機会に学んでみませんか。

次の開催日程は、1/29(月)-31(水)です。申し込みはお早めに！

VMware vSAN: Deploy and Manage [V6.6]　3日間コース

日本ヒューレット・パッカード株式会社　教育サービス　中川明美

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

第3段は来週ですと書いておきながら、他の記事のペース具合がすごかったので(誰のせいなんでしょう?)落ち着いた本日公開致します。今回はアケミ姉さんのお得意のvRealizeシリーズです。前回はコマンドがメインのトラブルシュートでしたが、今回は運用ツールのvRealizeを利用しています。

管理ツール、運用ツール、監視ツール･･･なかなか軽視しがちと言うか、いつも使ってるのでなんとかしたい･･･という発想もあるかもしれませんが、VMwareはSDDC、つまりデータセンタ全体ですので、こうした専用ツールへの投資も非常に効果大です。

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方は1 Million IOPS in 1 VM – World First for HCI with Nutanixをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

この数ヶ月、私はNutanixの才能のあるエンジニアたちと新しい機能についての取り組みを行ってきました。この機能はNutanix AOSとAHV製品の将来のリリースで一般公開となります。ある土曜日の昼下がり、私はUSにおり、ふと思いついたことがありました。この機能を使ったとして、単一の仮想マシンで我々はどれだけのパフォーマンスを出すことができるんだろう? このときに私はNutanix社のAHVチームのシニアスタッフエンジニアFelipe Franciosi氏を巻き込むことにしました。単一の仮想マシンで100万IOPSに到達することが可能なのだろうか? フランスはニースのNutanix .Next Conferenceで世界初を発表することへ向けて、チューニングが始まりました。この記事にはより刺激的になるようにライブマイグレーションに関するものや、混合IOについても取り上げたい思います。

大きな成果を上げるためには大きなチームを巻き込む必要があります。今回も例外ではありません。Felipe氏はNutanix NX9030のクラスタ上に1つのUbuntuの仮想マシンを用意してくれ、最大で4KB 100% ランダムReadで最大で100万IOPSを叩き出す手助けをしてくれました。幾つもの検証を繰り返し、継続的なパフォーマンスであることや4KBの代わりに8KBでも実現ができないかなども試してみています。Felipe氏との作業の後、最後のチューニングではMalcom Crossly(AHVチームのスタッフエンジニア)にも手伝ってもらっています。我々は8KBの100%ランダムReadで100万IOPSを達成し、更にそれを24時間継続することができました。更に我々の心に打ったのはレイテンシはほんの110マイクロ秒または0.11ミリ秒だったということです。

100万IOPSを単一仮想マシンで叩き出すということはこれまでではなし得られなかったことです。VMwareとMicrosoftはこれまで何度もデモを行ってきました。ですが、いずれのケースもハイパーコンバージドインフラストラクチャ上もなく、さらにちょっと複雑なことを行っていました。VMwareの場合、数百にも及ぶLUN、ゾーニング、マスキング、オールフラッシュストレージ装置を単一仮想マシンに2つもつなぐ、などです。今回の検証の場合、我々は小さな、NX9030がほんの10台のクラスタ(もっとスケールアウトさせることができます)を利用しています。仮想マシンはローカルディスクボリュームを合計で33個(OS用に1つ、残りがIO負荷用)接続しています。

以下はNutanixクラスタ上の単一仮想マシンに最初に継続的なIOテストを行った際にキャプチャしたイメージです。

さて、疑問が生まれてきます。本当に単一の仮想マシンで100万IOPSが必要なのでしょうか? しかもランダムReadで? 幾つかのケースではその答えはイエスです。もちろん100万IOPSも必要としないということもありますが。非常に小さなレイテンシのRead操作からメリットを受けられるアプリケーションは多くあります、例えば金融機関の支払いのゲートウェイなどです。

どうして単一の仮想マシンでなくてはならないのか? 近年では殆どの状況において多くの仮想マシンを使うスケーラブルプラットフォームの利用に興味はないのか?という疑問を持つ方もおられると思います。そのとおりです。ですが、Nutanixのような分散スケールアウトシステムの課題は常にパフォーマンスのスケールアップです。多くの仮想マシンを利用してのパフォーマンスのスケールアウトはあたり前のことなのです。しかし、単一の非常に大きな仮想マシンで非常に高いパフォーマンスを得るということはとてもトリッキーな課題です。こうしたことは特に大きなデータウェアハウス環境で重要です。

大きなスケールアップデータウェアハウスにおける能力を確認するために70%Read,30% Write、100%ランダムの64KBというワークロードも検証しています。これはSQL Serverデータベースが生成するのと類似のワークロードです。以下はこの検証の結果のイメージです。

見て分かる通り、この構成の単一仮想マシンで我々は継続的に13GB/sのスループットをRead 70%、Write 30%で達成しました。ワーキングセットのサイズは3TB以上です。これによってこの構成はIOスループットの観点から非常に巨大なデータウェアハウスにも利用できるということを示しています。WriteについてはRoCE(RDMA over Converged Ethernet)を利用するRDMAとMallanoxの40GbE CX3 Proアダプターを利用しています。全てのアップリンクはMellanox社のSN2700スイッチに収容され、RDMA用の低遅延のロスのないファブリックで一貫したパフォーマンスを提供しています。

これがクラスターが持つパフォーマンスの全てでしょうか? いいえ、違います。この10ノードを利用して、仮想マシンの数をスケールアウトさせるとより高いパフォーマンスを達成することができます。以下のイメージのデモが示すとおりです。WindowsとIOMeterを利用して10ノードのクラスタと64KBの100%ランダムReadで28GB/sのスループットを達成することができました。

IOパターンを70%のランダムReadと30%のランダムWriteに代えた場合、10ノードのクラスタのスループットは21GB/sまで落ちました。

仮想マシンの数のスケールアウトが効果があるということを明らかに示しています。単一の仮想マシンでも優れたIOパフォーマンスを叩き出すことができるのです、当然のことです。お楽しみのために、32KBの100%ランダムReadの結果もお見せします。これはとあるオールフラッシュストレージベンダーでよく利用されています。

10ノードのNutanix NX9030からなるクラスタで、10の仮想マシンから100%ランダムReadのワークロードを流したところ22GB/sが出ています。このクラスタは非常に小さいもので、32、48もしくはもっと大きなサイズへと拡張可能で、それに合わせてパフォーマンスもリニアに拡張されます。これはNutanix Acropolis分散ストレージファブリックを利用するメリットです。クラスタにノードを追加することで、増えていくワークロードのためにリニアに拡張でき、想定通りの一貫した構成を取れるのです。

これはもちろん想定通りの質問です。もしもライブマイグレーションや環境のアップグレードを行っていないときであればそうかもしれません。ですが、ライブマイグレーションが行われたとしたらどうなるでしょうか?喜んでお答えしましょう。8KBのランダムReadで100万IOPSを実行している途中に、その仮想マシンをライブマイグレーションさせてみました。以下の短いビデオを見ることで、仮想マシンを一つのホストから別のホストへ移行させた際に、平常時に戻る前にIOPSが少し減少するのを確認できます。ビデオではライブマイグレーションの発生時のみではないということも確認できます。

YouTube: 1M IOPS Live Migration

Nutanix AHVハイパーバイザーはCPU、メモリ、そしてストレージIOリソースのバランスをスマートに行い、プラットフォーム上のすべての仮想マシンが取りうる限りの最高のサービスを実現します。ビデオではマイグレーションの後でもパフォーマンスの欠落が無いということも示していますが、これも期待通りです。こちらのJosh Odgersの記事をご参照下さい。将来的にどこにボトルネックが移るのかということも含まれています。

こうした変更はもしもWriteがミックスされてくるとどうなるでしょうか? 8KBのIOサイズ、70%のReadと30%のWriteで、期待値としては同じような振る舞いです。以下のビデオは単一の仮想マシンでライブマイグレーションを行っているものですが、その最中に 600K IOPSと4Gものスループットを示しています。

YouTube: 8K 7030 IOPS Live Migration

ここでお見せしている機能はAHV Turbo(IOパスをAHVカーネルから取り除く)で、次のAOS 5.5のリリースへワンクリックアップグレードすることで利用可能になります。AHV上にあるのであれば何の変更も加えずにAHV Turboからのメリットを受けることができます。ですが、もしもパフォーマンスを最大化したいと考えるのであればLinux上でマルチキューブロックIOを有効にするか、Windowsでは最新のvirtio-scsiドライバーを利用して下さい。単一仮想マシンでの検証はまた別の機能を利用していますが、この機能については5.5.1でリリースされる予定です。この機能では単一の仮想マシンは必要であればさらなるストレージIOリソースを利用してパフォーマンスを得ることができます。この機能はAcropolis分散スケジューラーとシームレスに統合されています。最後に仮想マシンは仮想化NUMAを利用しており、AOS 5.5と一緒に登場するAHVで利用できるようになります。我々はAHV TurboをワシントンDCで行われたNutanix .NEXTカンファレンスUSで最初にでもしましたが、Josh Odgersはその他にも8K 70/30についてのハイライトをこちらの記事で記載しています。

最後に

Nutanixのソフトウェア、Acropolis、Prism、そしてAHVは近年のサーバーハードウェアの能力を解き放ち、最も要件の高いアプリケーションであっても優れたパフォーマンスを実現することができます。新しいハードウェアの革新が業界標準のプラットフォームとしてもたらされればすぐにNutanixソフトウェアはその先進性を利用できるようにします。これによって持続的なパフォーマンスとスケーラビリティの改善のサイクルが実現され、フォークリフトによるハードウェアの入れ替えはもう考える必要がなくなるのです。Intel x86であれIBM Powerのアーキテクチャを選ぶのであれ、AHVは他のハイパーバイザーが羨むようなパフォーマンスを実現することが可能です。我々はAHVの本来の力の触りの部分を初めただけです。今後多くのものが登場するでしょう。チャンネルはそのまま! 2018年の5月のニューオリンズの.NEXT conferenceで更に詳しく!

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

さて、今年を締めくくる記事としてはこちらを選びました。将来のAHVではなんと単一VMで100万IOPSを実現できるということです。爆速大好きさん、こちらに集まれー(笑)

･･･ っていうか、32もvDisk繋いだり、色々とAHV Turbo以外にもおまじないが入っているようで･･･。ここまでしなきゃいけないんだったら、Nutanixのシンプルさはなくなってしまいます。今回は参加することに意義がある的な感じですかね。

今回の記事はベンチマークの数字がすごいでしょう? というよりも様々なワークロードに対応ができるだけの改善点をハイパーバイザーに取り込んでいるということに意味があると思っています。HCI専用ハイパーバイザーとしてどれだけ独自の進化をとげるのか･･･?

まさに海の覇者として独自の進化を遂げたサメのようなハイパーバイザーになってきました。(※サメは軟骨魚類という一般的な魚よりも旧世代のアーキテクチャ(笑)を採用している魚ですが、食物連鎖の頂点に位置しています、例えば、泳ぎ続けないと息ができないとか･･･)

おそらく前回の記事の機械学習だとか、色んな意味でそういうことを考えなくても良くしてくれるというNutanixのもう一つの車輪(Prism)側の対応も楽しみです。

乞うご期待です!

本記事のIBM社のPower Systems Cloud Offering ManagerのAlise Spence氏によってIBM IT Infrastructure Blogに投稿されたものからの引用です。

原文を参照したい方はPower your containerized cloud with IBMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

先月、IBMは新たなオンプレミス用のIBM Cloud Privateを発表しています。

このIBM Cloud Privateについては以下のように表現されています。

An innovative and revolutionary platform-as-a-service (PaaS) offering, IBM Cloud Private incorporates the best of open source tools, including Kubernetes container orchestration, with the unique IBM values that enterprises need to be confident in a secure, compliant and performant private cloud platform.

革新的かつ革命的なプラットフォーム-アズ-ア-サービス(PaaS)製品で、IBM Cloud PrivateはKubernetesのコンテナオーケストレーションを含む最高のオープンソースツールをIBMの付加価値である企業に求められるセキュアでコンプライアンスを満たし、パフォーマンスについても確信を持って利用できるプライベートクラウドプラットフォーム上で動作させることができるようになっています。

IBM Power Systemsをネイティブにサポートしており、競合との差別化は以下のような点があげられます:

• Developers can create blazing-fast apps by deploying cognitive services on hardware optimized for the work at hand, for higher container density and better throughput.
• Apps that integrate new cloud-native apps and services with core business data on enterprise systems can be co-located with near-zero latency.
• Data center administrators can deploy Cloud Private on their choice of Power servers including the IBM Hyperconverged Systems powered by Nutanix, LC servers and enterprise servers with PowerVM.

• 開発者は高いコンテナの統合率と優れたスループットのためのハードウェアに最適化されたコグニティブサービスを展開することで、非常に高速なアプリケーションを作成することができる
• 新しいクラウドネイティブなアプリやサービスを統合するアプリケーションとエンタープライズシステムのコアビジネスデータをほとんど遅延のない場所に共存させることができる
• データセンタ管理者はCloud PrivateをIBM Hyperconverged Systems powered by Nutanix、LCサーバ、そしてPowerVMを搭載したエンタープライズサーバを含むPowerサーバの中から選んで展開することができる

それぞれを詳しく見ていきましょう。。

Want to accelerate the speed of your apps? Our optimized hardware puts you in the driver’s seat with higher container density and better throughput.(アプリのスピードを高速化したい? 最適化されたハードウェアがより高い統合率のコンテナ、より良いスループットへと皆様をお連れいたします。)

A properly configured cloud environment delivers efficiency–a huge benefit to any business, especially when delivered by platform performance. Optimized for cognitive services, Power Systems can deliver insights faster. How? Because of fewer systems and improved horizontal and vertical scalability. The IBM POWER9-based AC922 delivers 3.8 times the reduction in AI model training times[1]. Other Power System servers deliver similar performance gains, all leading to faster and more accurate results for next generation deep learning workloads.

And with multi-architecture support for Docker containers, developers can easily control and automate which platform to deploy specific containers to for best results.

適切に構成されたクラウド環境が効率性を提供します ー あらゆるビジネスにとって巨大なメリットです、特にプラットフォームにパフォーマンスがもたらされた場合には。コグニティブサービスに最適化されたPowerシステムは知見をより高速に提示します。どうやって? 選りすぐったシステムと改善された水平、垂直の拡張性によって、です。IBMのPOWER9ベースのAC922はAIモデルの教育時間を3.8倍も削減することに成功しました(*)。他のPowerシステムサーバも同様のパフォーマンス向上を示しており、全ての次世代のディープラーニングのワークロードをより早く、正確な結果へと導いています。

Dockerコンテナをマルチアーキテクチャでサポートすることで、開発者は最良の結果のためにどのプラットフォームへどのタイプのコンテナを展開するかということを制御、自動化することができます。

Integrate modernized cloud-native apps and services with core business data(コアビジネスデータを最新のクラウドネイティブアプリと統合)

Top enterprises use Power Systems for their most critical business data. Frequently, industry or government regulations are forcing them to find ways to make data more accessible while maintaining their required data security and availability. IBM Cloud Private on IBM Power Systems enables enterprises to create or modernize applications while providing tight integration with the critical data that applications require. By co-locating apps and data, clients will see near-zero latency when integrating with data stores managed in Linux, AIX, or IBM i environments.

トップ企業がそのもっとも重要なビジネスデータのためにPowerシステムを利用しています。よくあることとして業界や当局が標準仕様としてデータに必要なセキュリティと可用性を維持しながら、一方でデータへのアクセス性をより高めるような方法を探すべし、としていることがあります。IBM Powerシステム上のIBM Cloud Privateは企業がアプリケーションが求める重要なビジネスデータの緊密な統合を実現しながら、企業がアプリケーションを作成、もしくは近代化することができるようにします。アプリケーションとデータを同一の場所に格納することで、クライアントからはLinux、AIXもしくはIBM iの環境に管理保管されているデータと連携する際もほぼ遅延のないアクセスを実現することができるのです。

Deploy new cloud native apps on choice of infrastructure, including IBM Hyperconverged Systems powered by Nutanix(IBM Hyperconverged Systems powered by Nutanixを含むインフラストラクチャから新たなクラウドネイティブアプリを展開先を選択できる)

IBM Cloud Private runs across the entire IBM Power Systems portfolio, POWER8 or above, requiring a little endian partition running any flavor of Linux. Clients wishing to leverage existing systems or skills can deploy Cloud Private into PowerVM LPARs. Clients looking to maximize performance for AI or data scientist workloads can opt for bare metal support on OpenPOWER systems. And clients looking to build out new infrastructure in support of new services can get the fastest time-to-value with minimal effort using IBM Hyperconverged Systems powered by Nutanix.

IBM Cloud Private for Power Systems Starter Kits makes it quick and easy to get started. These kits offer implementation guidance that helps organizations to get up and running quickly on their choice of Power Systems infrastructure: OpenPOWER scale-out, enterprise servers, or hyperconverged. When ready, clients can leverage a choice of service-optimized Power Packs, which are Reference Architectures to expand compute capacity and deploy production-ready HA clusters.

Click here to learn more about IBM Cloud Private and try the software, or click here to learn more about cloud solutions like IBM Cloud Private on IBM Power Systems and download a solution brief.

IBM Cloud PrivateはIBM Power システムのPOWER8以降のリトルエンディアンのパーティショニングを稼働させているあらゆるLinuxのすべてのポートフォリオで動作します。既存のシステムを活用する事もできますし、もしくはスキルさえあればCloud PrivateをPowerVM LPARS内に展開することもできます。AIやデータサイエンティストのワークロードの性能を最大化したい場合にはOpenPOWERシステムのサポートの元ベアメタルを利用することもできます。そしてもっとも価値創出までの時間の短い、新しいインフラを最小の労力で作成したいという場合にはIBM Hyperconverged Systems powered by Nutanixをつかうとよいでしょう。

IBM Cloud Private for Power Systems Starter Kitsを利用すれば、素早く、簡単に始めることができます。こうしたキットは実装のガイダンスが記載されており、ご自身の選択したPower システムインフラストラクチャ(OpenPOWERのスケールアウト、エンタープライズサーバ、またはハイパーコンバージド)の稼働開始、稼働の手助けとなります。準備ができたら、サービスに最適化されたPower Packを選び活用することもできます。これにはコンピューティングキャパシティの拡張や本稼働系を展開する際の高可用性クラスタのためのリファレンスアーキテクチャが含まれています。

IBM Cloud Privateについてより詳しく学ぶ、もしくはソフトウェアの試用については こちら をクリック。または こちら をクリックして、IBM Cloud Private on IBM Power Systemsなどのソリューションについて詳しく調べたり、ソリューションブリーフをダウンロードして下さい。

もしもアプリケーションの近代化でどれほどスピードが上がるのかを知りたいのであれば、以下のライブウェブキャストにもご参加下さい :

Bring the Changes Your Customers Want: application modernization and agility with IBM Cloud Private on Power Systems(お客様の要求に変化をもたらす : IBM Cloud Private on Power Systemsでアプリケーションの近代化と俊敏性を)

Time and Date:  11:00 AM EST, January 11, 2018 (日本時間 :2018年11月12日1:00 AM)

Register here. https://event.on24.com/wcc/r/1560084/CF1B4670D48B2BAD72B54C8CD25C8A83

(*) •Results are based IBM Internal Measurements running 1000 iterations of Enlarged GoogleNet model (mini-batch size=5) on Enlarged Imagenet Dataset (2240×2240) .

• Power AC922; 40 cores (2 x 20c chips), POWER9 with NVLink 2.0; 2.25 GHz, 1024 GB memory, 4xTesla V100 GPU ; Red Hat Enterprise Linux 7.4 for Power Little Endian (POWER9) with CUDA 9.1/ CUDNN 7;. Competitive stack: 2x Xeon E5-2640 v4; 20 cores (2 x 10c chips) /  40 threads; Intel Xeon E5-2640 v4;  2.4 GHz; 1024 GB memory, 4xTesla V100 GPU, Ubuntu 16.04. with CUDA .9.0/ CUDNN 7 .

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

本当は年明けに･･･と思っていたのですが、1月12日の深夜1時からのIBMさんのウェブセミナーの告知も含まれていたので、こんな日にも記事を出しております、ゴメンナサイ。

Nutanix担当の目線でいくと、Nutanix on Powerの上で、IBM Cloud Privateを動作させれば、｢Googleのようなウェブスケールなインフラ上でIBMのクラウドが動く｣という事になります。重要なデータをAIやコグニティブサービスを使ってビジネスに活用していく、こうした世の中だからこそのプラットフォームだと思います。

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はFlexibility and Expanded Application Support with Compute Cloudをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

ここ数年に渡って、Nutanix エンタープライズクラウドOSは驚くべき進化を遂げてきており、7000社を超えるお客様がそれを採用するに至っています。2つのことが明らかとなりました :

• お客様はハイパーバイザーの埋め込まれた、パブリッククラウドと同様の利用体験をもたらすインフラストラクチャのスタックに価値を感じておられます。我々は2017年度の第4四半期の会計レポートで、4四半期の移動平均を取った場合に24%ものノードがAHVで展開されているとしました。これは従来型の仮想化ソリューションの代替として強い関心があるということを示しています。
• Map-Reduceアルゴリズムを活用して常に実施される圧縮、インテリジェントな重複排除、EC-Xによるイレイジャーコーディングで最適化されるお客様のストレージキャパシティといったストレージレベルでの継続的なイノベーションによって、ストレージ層が逼迫するということは殆どありません。こうした診断結果は組み込みのPulse HD診断ツールとクラスタ利用率計測のコールホーム機能によってもたらされたものです。

図: Nutanix Prism がお客様の高いストレージキャパシティ最適化率を示しているところ

我々はマイクロサービスベースのアーキテクチャを採用して優れた俊敏性と拡張性を実現しているアプリケーションの萌芽を感じています。クラウドと等しい効率性を真に開放し、こうしたアプリケーションの利用に必要とされるものは、適切な量のキャパシティが必要な一方で、アプリケーションチームが追加してほしいと言うものを必要なだけ追加しなくてはなりません。

必要とされる追加リソースの提供

我々の仮想化ツールであるAHVはPrismに含まれるX-fitマシンインテリジェンスと一緒に使うことで、キャパシティの見通しやワークロードベースのWhat-if分析によって、適切なリソース利用率を実現し、キャパシティ不足による抑圧を避けることができ、また、拡張に際しての推奨構成も提示することができます。Nutanixは全てが選択と自由からなっています! 我々は多くののCPU、メモリ、そしてストレージタイプ(ハイブリッドとオールフラッシュ)の組み合わせから様々なバリエーションでのコンピューティングとストレージのキャパシティを実現することができます。もちろん、アプリケーションの成長(例えば、Citrix XenDesktopまたはXenApp、Cloudera等)のシナリオや、アプリケーションが追加のリソースを必要とするということもありましたが、基本的には1次元での話でした。

ストレージについては、問題は我々の｢ストレージヘビー｣構成によって解決することができました。この構成ではストレージリソースを柔軟に拡張することができ ー コンピューティングを追加すること無く ー 最大で60TBを追加することができます。我々は｢コンピューティングヘビー｣の構成でIntelのCPUの最も大きなコア数を利用することもできます、ですが、こうしたノードは常にいくらかはストレージも搭載していなくてはなりませんでした。

Nutanix Acropolis Compute Cloud (AC2)の登場

もしも、Nutanixクラスタにコンピューティングのリソースのみを追加することができたとしたら? そして、運用の手間については一切変える必要がないとしたら? これが我々がNutanix Acropolis Compute Cloud (AC2)でアナウンスしたもので、Nutanixクラスタをコンピューティングのみで拡張できるようにするものです。

AC2はNutanixのお客様にストレージとは独立してコンピューティングキャパシティを拡張することを通して、インフラストラクチャの利用率をさらに高めることができます。要件の高いビッグデータや機械学習のアプリケーションを含むアプリケーションワークロードをサポートするために、柔軟なコンピューティング｢サービス｣を提供できるのです。

図: 既存のNutanix環境内のコンピューティングを拡張する

“ワンクリック” での利用

AC2はコンピューティングキャパシティをPrismの｢ワンクリック｣操作を利用して簡単に拡張できるようにし、瞬時にNutanix エンタープライズクラウドOSの提供するインフラストラクチャとストレージサービス(ADFS ー Acropolis 分散ファイルシステム、 Acropolisブロックサービス、Acropolis ファイルサービスなど)に完全なアクセスを実現させます。AHVをベースとする仮想化のメリットの全てが一切の設定抜きで利用できるようになります :

• 常に利用できる高可用性
• 自動的なCPUの互換性
• ライブマイグレーション、Acropolisダイナミックスケジューリング(ADS)によるリソース競合の解決(コンピューティングとストレージの両方)

AC2コンピューティングサービスは利用できるユースケースの幅を拡張させてくれます。これはNutanixが継続的にその旅路でマルチクラウド管理のOSをシンプルなワンクリックの操作で実現し、IT担当者があらゆるクラウドであらゆるアプリケーションを提供していく手助けをしていくからです。

製品の提供時期

AC2は現在開発中です。価格の詳細は適切なリリース日が近くなってからアナウンスされます。

新しいAC2機能についてもっと詳しく知りたいですか? プレスリリースもご参照下さい。

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology, our plans to introduce product features in future releases, product performance, competitive position and potential market opportunities. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, Acropolis Compute Cloud, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

年が明けてからもまだニースネタがいっぱいですよ。ニースネタはビジョンのほうが豊作でしたが、One more thingで2つの新機能が発表されています。この2つの機能を連投していきます。OSSのほうが発表的には先でしたが、個人的にはこちらのAC2のほうが(深読みできて)面白いと感じていますので、こちらから先に翻訳しました。

マイクロサービスベースのアーキテクチャを採用したアプリケーション･･･という記載も読み取れるように、このAC2は単純に他社のHCIが提供しているコンピューティングキャパシティOnlyをターゲットとしている製品ではないように思います。注意してみていただきたいこととして、AHVのみのサポートであり、ここで動かすワークロードは一般的なワークロードでは無いように思います。

AHVであれば基本はKVMですから、マイクロサービスで利用されているようなOSSをベースとしたテクノロジーとも相性が良いため、何らかもう一つ裏に仕掛けが隠れているような気がしてなりません。(もちろん、もう一つの新機能であるOSSもその一つかもしれません)

ハイパーバイザーとしても一つ大きな一歩を踏み出すぞ、というそんなメッセージにも取れましたので、2018年最初の記事で取り上げさせていただきました。

こんにちは。

CommVault v11 の最新サービスパック(SP10) がリリースされました。

CommServe の内部データベース Microsoft SQL Server バージョンのアップデート (バージョン 2014) などが更新されておりますので、ご興味のある方は、CommVault 技術ドキュメントのサイト(こちらをクリック)をご覧ください！

さて、今回は、CommVault のバックアップ保存先としてクラウドの活用をご紹介します。

CommVault では、バックアップ先として、さまざまなクラウドサービスをサポートしていますが、サポートするクラウドベンダーの詳細は、CommVault のサイトで公開されていますので、下記の URL を参照ください。

◆Cloud Storage - Support◆
http://documentation.commvault.com/commvault/v11/article?p=features/cloud_storage/cloud_storage_support.htm

バックアップ先のクラウドストレージライブラリに対して、直接バックアップする場合、重複排除機能を利用すること*ができます。重複排除は、バックアップから冗長なデータセグメントを排除し、バックアップデータのサイズが削減されますので、クラウドへ効率的にデータを転送することができます。
* 一部のクラウドサービスでは、重複排除機能がサポートされないため、ご注意ください。

【Direct Deduplication to Cloud Storage】

また、2次バックアップ先としてクラウドを使用する場合、CommVault の Storage Policy に Copy Policy を追加設定することで対応できます。以前、Media Agent 間で重複排除済みバックアップデータをコピーする機能「DASH Copy」をご紹介しましたが、クラウドストレージに対しても同機能を使用することができます。

【Deduplication in Secondary Copies】

クラウドストレージを使用する前に、接続性のチェックなどを実施するツール「CloudTestTool」が提供されています。CloudTestTool は、CommVault のインストールパスに格納されていますが、Amazon S3、Microsoft Azure、Google Cloud Storage など、クラウドベンダーを指定して確認することができます。

CloudTestTool の起動画面

◆Cloud Storage - Tools◆
http://documentation.commvault.com/commvault/v11/article?p=features/cloud_storage/cloud_storage_tools.htm#Cloud_Test_Tool

今回、Amazon S3 をバックアップ先として設定する手順を簡単にご説明します。CommVault 管理コンソールを起動し、「ストレージリソース」-「ライブラリ」-「追加」-「Cloud Storage ライブラリ」の順にクリックします。「Cloud Storage の追加」画面が表示されますので、Amazon S3 へのアクセス情報など必要な情報を入力して設定します。

Cloud Storage の追加

「Cloud Storage の追加」が完了した後、CommVault のライブラリに Amazon S3 のクラウドストレージがバックアップ先として追加されます。

CommVault ライブラリ

いかがでしたか。

バックアップ先としてクラウドストレージを使用する設定は、簡単に実施することができます。災害対策や長期保管の目的などクラウドを活用するケースが増えていますので、ご検討ください。

CommVault 社で Amazon S3 にバックアップする手順でビデオで公開されていますので、こちらも併せてご参考ください。

◆参考情報◆

http://www.commvault.co.jp/products/documentation/video/backup_to_aws/

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

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はReimagine Object-based Storage in a Multi-cloud Eraをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

*参照元: https://www.mckinsey.com/industries/consumer-packaged-goods/our-insights/inside-p-and-ampgs-digital-revolution

立ち止まって、雑貨屋やスーパーマーケットの棚にどれだけ多くの労力が製品の配置のために割かれているか、考えてみたことはありますか?購入してもらうために皆様の目を引くためだけにこれが行われているのです。そしてどこに製品を置くのか、ということはパズルのほんの一部に過ぎません。製品を拡充するということもまたもう一つです。新しい製品が継続的に製造されていく中で、棚の上では何千通りものコンビネーションが可能なのです。

デジタル世代において、異なる製品のコンビネーションを作って、｢モック｣の棚をフォーカスグループがみるというコストの高い手動のプロセスは本当に破壊されつつあります。プロクター&ギャンブルの例では、仮想化ショッピング棚野テクノロジーを用いて、異なるアプローチでこの手動のプロセスを取り除いています。アプリケーション開発者は膨大なデータとそれを迅速に分析する能力によってこの仮想化された棚をプログラムし、数分で新しいコンビネーションを打ち込んで表示することができます。これによって実際に一つ一つの製品を手動で並び替えること無く、数千に及ぶコンビネーションを検証、開発して知見を得ることができます。根本からプロクター&ギャンブル社は手動の手順を取り除いて自動化されたものに変え、時間の節約とコストの削減を実現しようとしているのです。

進行し続けるデータの成長に対処する

考えられないスピードでデータが成長しているということを我々は皆知っています。｢仮想化ショッピング棚｣のようなデジタルアプリケーションにおいては特にその傾向が強いです。ですが、それはいつ貴方がそうしたものを採用するのか、ということを告げているのです。IDCの予測によると2020年までにデータの成長は40ZBに到達し、そのうちの63%が非構造化データになるであろうとしています(*)。これは本当に大きな非構造化データであり、企業では現在複雑な、管理の難しい、拡張に制限のあるサイロにそのデータを保管しています。さらに、幾つかの企業では非常に巨大な量のデータを保管するためのファイル構造を検討し始めており、これはアプリケーション開発者にとっては必ずしもベストなソリューションとは言い難いものです。こうした人々はディレクトリ構造やパスを気にすること無く膨大な量のデータを保存、取り出しするためだけのシンプルな構造を探し続けています。パブリッククラウドはその伸縮性と使いやすさによってこうした課題の一部の解決に役立っていますが、セキュリティ、統制、そして大規模スケール環境での一貫した動作においてのコスト効率については埋めることができていません。これによって、非効率さが産まれ、ビジネスの俊敏性が損なわれています。エンタープライズにはデータ成長(テラバイトクラス)を消費、管理できる新しいパラダイムが必要とされており、更に幾つかのケースでは標準的なコンプライアンスを維持しながらそれを実現しなくてはならないのです。

Acropolis オブジェクトストレージサービス(AOSS - Acropolis Object Storage Service)

お客様がNutanixを採用し続けるにつれ、そのお客様は予測のできないデータ成長の課題を抱えることになります。望むと望まざるとそうなってしまうのです。Nutanixはこの問題を念頭に置き、Acropolis オブジェクトストレージサービス(AOSS- Acropolis Object Storage Service)という新しいオブジェクトベースのストレージサービスをリリースしました。この機能はエンタープライズクラウドOSの一部としてワンクリックの手順で展開することができるようになります。

図: それぞれのニーズを満たす複数のストレージサービス

将来的に、仮想マシン、ファイル、ブロック、そしてオブジェクトサービスを単一のOSで動作させることができるようになります。この新しいサービスはマルチクラウド時代のために作られており、無限の規模でグローバルに統合されたオブジェクトベースのストレージです。アプリケーション開発者はS3互換APIストレージとして利用でき、必要とされる優れたパフォーマンスを提供することができます。

オブジェクトベースストレージの基本

過去これまでにオブジェクトストレージを使ったことがないということであれば、これはちょっと変に思えるかもしれません。ですが、実際には本当にシンプルです。少し詳しく見てみましょう :

• オブジェクトストレージは通常のブロックまたはファイルシステムのストレージとは少し異なっています。オブジェクトストレージは従来型のディレクトリ構造のファイルシステムとは異なり、平坦なオブジェクトのリストを利用しており、ファイルは｢buckets｣に保存されています。オブジェクトはファイル名ではなくユニークなIDを利用して保存されています。これによってデータの保管とメタデータに必要とされるオーバーヘッドの総量を劇的に減らすことができます。
• さらに、オブジェクトはメタデータと一緒に保管されており、高い拡張性を実現できます。オブジェクトはテラバイトやもっと小さなキロバイトのサイズで、単一のコンテナ内に何億というオブジェクトを保持することができます。アプリケーション開発社はオブジェクトにシンプルなS3互換APIコールを通して｢GET｣や｢PUT｣と言ったアクションを行うことができ、複雑なディレクトリ構造を気にする必要はありません。

Nutanix エンタープライズクラウド OSを利用することからのメリットとして、数千にも及ぶお客様が信頼するすべてのコアデータパスの効率性ー 圧縮、重複排除、イレイジャーコーディング ー、そしてそれ以外にも多くのものを継承することができます。複雑なサイロ構造のインフラストラクチャの購入、構築、管理そして、展開の時間を劇的に削減することができるのです。

マルチクラウドの世界のためのAOSS

アプリケーションがパブリック、プライベート、分散クラウドをまたがるこの時代において、我々Nutanixはオブジェクトストレージソリューションを他にはないこの3つの全てのクラウドをまたがるものとして設計しました。

図: パブリッククラウド、データセンタ、拠点そして戦略エッジにまたがるインフラストラクチャ

こうしたソリューションの主だった特性は :

• グローバルなネームスペース (全てのクラウドで単一のネームスペース)
• 無限の拡張性 (過去のアーキテクチャ上の制限を取り除いた)
• ワンクリックのシンプルさ(意図を理解するデザインと誤解の生まれないデザイン)

グローバルネームスペース: マルチクラウドを念頭に置いたほんとうの意味でのグローバルなネームスペースというのが焦点です。これが故にNutanixソリューションはAOSSでS3 APIを採用しました。Nutanixクラスタとパブリッククラウドをまたぐストレージファブリックにおいて単一のネームスペースを提供します。それだけではなく、オブジェクトデータをNutanixクラスタに書き込むアプリケーションはクラウドをまたいでレプリケーション、階層化を行うことができます。これによって開発者はアプリケーションがクラウドの境界をまたいで動くという場合にもアプリケーションを書き直す必要はありません。

無限の拡張性: このソリューションは簡単に拡張できるため、使わないリソースのための導入の初期のコストを最小限に抑えることができます。もしもNutanixソリューションがコンピューティングやストレージのリソースが不足しそうだと予見されれば単にコンピューティング/キャパシティを非破壊的にクラスタで拡張し、仮想マシンリソースの再分配を行えばよいのです。これは劇的にパブリッククラウドとプライベートクラウドの間の障壁を低くします。

ワンクリックのシンプルさ: 複数のクラウドにまたがるため、管理はシームレスで簡単なものでなくてはなりません。膨大な量の非構造化データを保持しながら、拡張を行う唯一の方法はAOSSを単一クリック操作で展開し、アプリケーション開発者に迅速に利用させることです。NutanixエンタープライズクラウドOSはマシンインテリジェンスと自動化で多くのクリックを減らし、Prismからのワンクリックで運用をシンプルにするだけではありません。膨大な量のシステムデータから学習を行い、よくあるタスクを自動化して、すぐにアクション可能な知見を生成することで仮想化の最適化やマルチクラウドの管理、そして日々のタスクを後押しするのです。

どこでオブジェクトストレージを使うのが良いのか?

オブジェクトベースのストレージソリューションを様々なワークロードとともに効率良く使うためには様々な方法があります。例えばビッグデータ分析やデータウェアハウスアプリケーション、大規模なIoTセンサーデータなどです。私の好きな1つにフォーカスしてみましょう。法規制強制を行う当局が犯罪の解決のために監視のビデオにアクセスしたいとします。まず最初に必要となるのが監視データを常に録画しているカメラと定期的にそれをリアルタイムに引っ張り、分析を行ってその中に個人を発見するということを行います。数日や数ヶ月戻ってビデオを見るという必要性もあるでしょう。こうしたシステムは非破壊的に拡張できるバックエンドを必要とします。カメラの数やそこでキャプチャされるイメージの品質によってはこうしたカメラは数日で数テラバイトのデータを生成します。例えばロンドンを例に取ると422,000台のCCTVのカメラが有り(*)、いい解像度で毎秒20フレーム平均で録画を行えば、1ヶ月も立たないうちに0.5ペタバイトものデータが保存されることになります。

*参照元: https://www.cctv.co.uk/how-many-cctv-cameras-are-there-in-london/

典型的な監視環境ではセキュリティビデオデータは入力デバイス(例:セキュリティカメラ)を利用し、リアルタイムアクセスのために保存され、その後事後プロセスで顔認識を実施します。これはとても複雑に聞こえますが、アーキテクチャレベルで掘り下げて、もっと柔軟に拡張可能な柔軟なシステムを利用しようとすれば、さほど複雑ではありません。

1. カメラは情報をLinuxクライアントで動作しているアプリケーションに送信
2. データを暗号化されたオブジェクトストレージのbucket(s)に保存、1週間ほどはデータがここに置かれる
3. 事前処理のアプリケーション(ビッグデータ分析)が単一ネームスペース内をクロールし、このデータを使って顔認識機能を走らせる。最終的にデータの一部のみがもっと長期間保管するためのデータとして別のbucketへと移動される
4. ストリーミングのアプリケーションがリアルタイム情報または事後処理を施されたデータにアクセスし、迅速に法強制当局を手助けする

これはNutanixのオブジェクトベースのストレージソリューションを拡張とコストの効率に利用するだけでなく、データのポータビリティを実現するためにも利用している優れたシナリオだといえるでしょう。開発者にパブリックとプライベートのデータセンタをまたがるグローバルなネームスペースがあれば、環境が小さく、見通しが難しい場合にはNutanix Calmを利用して、パブリッククラウドから初めるということもできます。拡張が行われ、環境がよくわかってくれば、アプリケーションを内部へと異動させ、同じ場所でS3互換のAPIを利用して同じデータを利用できるのです。アプリケーションを書き直す必要はありません。

これはほんの一つの例ですが、さまざまな業界オブジェクトベースのストレージは多くの異なるシナリオで効果的に利用されています。病院を例に取るとベンダーニュートラルなアーカイブ(レントゲン、医療技術、電子プライバシーアプリケーション(PACS))を実装したいと考えているようですし、メディア外車はより大きなイメージファイルの置き場所を必要としています。

次に皆様がスーパーマーケットへ行くことがあって、ショッピングの棚を見た際に、通路のコーナーに監視カメラがあるのに気がつくかもしれません、そのデータに何が起こっているのか?インテリジェントな知見を得るためにどれだけのデータが保存されているのか、考えてみて下さい。

製品提供時期

AOSSは現在開発中です。価格の詳細は適切なリリース日が近くなってからアナウンスされます。

新しいAOSS製品についてもっと興味がある?我々のプレスリリースにも目を通して下さい、また、objectstorage@nutanix宛にフィードバック下さい。皆様の護憲を心待ちにしております。

*参照元: IDC File- and Object-based Storage Forecast, 2016-2020

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology, our plans to introduce product features in future releases, product performance, competitive position and potential market opportunities. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, Acropolis Compute Cloud, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

随分長く引っ張りましたが、ニースで発表された内容は今回の内容でほぼ網羅できたと思います。最後にAOSSを持ってきました。ニースではNutanixは複雑性を排除するベンダーである、というメッセージが出されていました。もうデータセンタのインフラの複雑性は結構排除できたな･･･次なる一手はAI、コグニティブを利用して、複雑なデータ(非構造化データ)をビジネスに役立ててデジタル革命を起こそう!ということがメインの主張であったと思います。

今回のAOSSはその非構造化データを大量に溜め込み、AIやコグニティブで処理する前の中間として位置づけられるストレージであると考えています。中間ストレージ･･･であればやはりそれ専用のものを用意するのではなく、他のリソースとシェアし合いながら利用するなど一つ考えておくべきかもしれません。

なにより、AOSSは今後のNutanixの目指す先に必須の機能になると思います。

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSoftware EngineerのFelipe Franciosi氏によるものです。原文を参照したい方はThe Wait is Over: AHV Turbo is Here!をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Nutanix OSの次なるリリース、5.5の最もホットな機能の一つは我々の.NEXTイベントで多くの方が耳にされたはずのAHV Turboテクノロジーです。このソリューションを実現しているキーとなっているのが我々の社内ではFrodoと呼ばれているコンポーネントです。この記事ではこのFrodoがどのようにストレージデータパスに入っており、今日市場で利用できる他のストレージ仮想化エンジンとどのように異なっているのかをご紹介していきます。

従来、AHVは仮想マシンを単一キューのVirtio-SCSI PCIコントローラーとして取り扱っていました。これはディスク数や仮想CPU数とは関係なくゲストOSは最大で同時に128のリクエストしか発行ができないということを意味します。加えて、この単一データ構造はハイパーバイザー側からは単一スレッドでしか管理ができませんでした。このモデルは他のハイパーバイザーと対して差はありません。

このアーキテクチャはほとんどの状況においては本当にうまく動くのですが、高いスループットやIOPSレートの場合、限界が見えてきます。近年のNVMeのようなハードウェアやRDMAの採用が増えるにつれ、これが心配になってくるのです。他のハイパーバイザーはこの問題をそれぞれのゲストOSにより多くの仮想化コントローラーを割り当てることで回避しています。しかし、このソリューションは単一仮想ディスクのパフォーマンスを改善するものではなく、単に仮想マシンの構成に複雑さをもたらすものです。加えて、実際のハードウェアを考慮した上で、本来行わなければならないものでもありません。

NVMeコントローラーから初めましょう、単一ドライブで数十万ものIOPSが提供されます。こうしたレベルのパフォーマンスを実現するためにはこうしたドライブのそれぞれを複数のハードウェアキューがあるものとして取り扱わなければなりません。つまり、オペレーティングシステムがマルチキューのブロックレイヤの提供をサポートしなくてはならないのです。これによってスタック全域に渡るより良い拡張性が実現できます : アプリケーションはマルチキューに対して並列でIOを投入できますし、それと同時に、ハードウェアはそのキューをこれまた同時に処理することができるのです。

実際のハードウェア上でもしそれがうまく動いているのに、どうしてハイパーバイザーはそれに追従しないのか? AHVは追従しました。

Frodoは仮想マシンへのVirtio-SCSI PCIコントローラーの提供を行う、新しいAHVのコンポーネントです。これまでのゲストの問題で唯一変わっていることは、コントローラーがマルチキューになったということです。ですが、ハイパーバイザー側ではFrodoはより効率的に、そしてマルチスレッドを使って異なるキューを並列で処理できるように設計されています。

これを実現するために、FrodoはNutanix上で動くために特別な設計になっています。マルチスレッドでリクエストキューを並列で処理するために、それぞれのスレッドも非常に効率化されています。まず最初に、FrodoはリクエストがSCSIコマンドであるということを理解しています。ですから、Frodoは一切の処理を行うこと無く、コマンドを直接CVMへと渡します。これはCVMもまたこのプロトコルをサポートしているからです。続いて、仮想キューがスレッドへとマッピングされ、これによってインテリジェントなリクエストのバッチ処理が行えるようになり、更に通信もまた効率的なものとなります。最後に、AHVに完全なデータパスのコントロールを委ねることができるようになります。これは将来の多くの可能性のための基盤のレイヤ化ということになるでしょう。

上のグラフはNX-3060-G5のオールフラッシュ構成での4KのランダムReadリクエストのIOPSを取ってきて比較したものです。8 vCPU、16GBのメモリ、6つの仮想化ディスクで構成された単一の仮想マシンでの驚くほどの数字のパフォーマンスの向上を示しています。Frodoによってパワーアップした仮想マシンは180K IOPSに届くほどのパフォーマンスを示しているのに対してQemuを使っている仮想マシンは80K以上になることはありません。

Frodoの開発はAHVに対して何故Nutanixが投資を行っているかということの素晴らしい例です。Nutanixがスタック全体をコントロールするとなれば、その可能性は無限大なのです。

結論として、Nutanix AHVは今日においても素晴らしいハイパーバイザーです。AHV TurboはNutanix Enterprise Cloud OSが次世代の技術、例えばRDMA、NVMe、3D XPointなどから多くのメリットを享受できるようにするために作られています。

もし何か気になる点や疑問点があれば、 フォーラムでこの続きをお話しましょう。投稿にはAHVTurboというタグを付けることを忘れないでください。

Forward Looking Statements
This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology and our plans to introduce product features in future releases. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, the Nutanix logo and other Nutanix products mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand and product names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

昨年AHVは次世代ハイパーバイザーです!という記事を沢山投稿してきましたが、最新のAHVにはAHV Turboが搭載されています。ゲストOSの中、ハイパーバイザー、CVMと様々な部分でのチューニングを行っているのですが、メインとなるコンポーネントのFrodoはハイパーバイザー内部で動作しています。

グラフを見ても分かる通り、今後の高速なフラッシュやネットワークを考えるとハイパーバイザー内のオーバーヘッドが大きいものなのか、わかっていただけるかと思います。AHVはそこに真っ先に対応した最先端を走るハイパーバイザーなのです。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix AOS 5.5 delivers 1M IOPS from a single VM, but what happens when you vMotion?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Nutanixは単一仮想マシンで100万IOPSを達成 - HCIでは世界初!もご参照下さい。

長年に渡ってNutanixは複数のハイパーバイザーに対して優れたパフォーマンスを提供してきましたし、同様にネイティブのNXシリーズ、OEM(Dell XCとLenovo HX)、そして直近ではソフトウェアオンリーの選択肢としてCiscoとHPEというハードウェアプラットフォームでも同様です。

直近のTweet(下)で、単独の仮想マシンで8KのランダムReadで100万IOPSと、8GBps以上のスループットが次世代ハイパーバイザーであるAHVで実現できることを示しました。

#Nutanix delivering 1 million IOPS in a single VM at 8k block size and only 0.11ms latency puts to bed the In-kernel vs Controller VM debate.#VSAN#VMware#HCIpic.twitter.com/afkq1cC0e3

— Josh Odgers (@josh_odgers) November 9, 2017

殆どの反応はポジティブなものでしたが、いつものように幾つかの競合のベンダーがパフォーマンスに関しての恐怖や不確実さや嘘(FUD Fear, Uncertainty, Doubt)を広めようとやってきました。その中にはライブマイグレーション(vMotion)の最中やその後はパフォーマンスが継続しないというもので、これはIOパスのパフォーマンスを示していないというものです。

インカーネルとコントローラー仮想マシンの対立(翻訳予定なし)に関するIOパスの議論についてちょっと復習しましょう。

IOパスを検証するために、Nutanixの場合はコントローラー仮想マシンを経由します。そのため、ここでの様々な変動要素やボトルネックを可能な限り排除したいと考えるはずです。これはread/writeの検証はwriteがネットワークのような要素に依存してしまうため、適切には行えないということを意味します。ここではNVMeを搭載しているノードを利用しているため、ボトルネックはとっくにネットワーク部分になってしまい、ユーザー仮想マシンとコントローラー仮想マシンの間のパスではなくなっているのです。

以前のツイート(下)でSATA SSD、NVMe、そして3DxPointのスループット性能を例に上げて、次世代フラッシュにおいてはネットワークが明らかにボトルネックになるということを示しました。

Does anyone see a problem with this?
Hint: Its the network!
(Unless you have #Nutanix data locality!)#HCI#NEXTConfpic.twitter.com/NXcgFyL5gP

— Josh Odgers (@josh_odgers) June 19, 2016

サードパーティによるNutanixのデータローカリティについてのFUDに対して、Nutanixのオリジナルで他にはないデータローカリティの実装(翻訳予定なし)という記事を書いています。ここにはNutanixが優れたパフォーマンスを提供するためにネットワークへの依存度を可能な限り小さくしているということが書かれています。

ですから、我々がやるべきことはRead IOの検証を行い、ユーザー仮想マシンとソフトウェアディファインドストレージの間のIOパスに可能な限りの負荷をかけることです。インカーネルの部分もありますし、NutanixのCVMが動作しているユーザースペースの部分もあります。

Tweetは8KのランダムReadが100万IOPS、8GBpsのスループットがNutanixのIOパスにあるということを示しており、110マイクロ(ミリではありません)秒のレイテンシを実現できるほど効率的であるということも示しています。

次なる疑問は、Nutanixや一般的なHCIにおいてvMotionの後に何が起こるか、という誤解を解いていくということでしょう。

この疑問は適切なものですということこから初めましょう。ですが、vMotionの最中や後にパフォーマンスが落ちたとして、それは大きな問題なのでしょうか?

ビジネスアプリケーションにとって、ベンダーに共通する事項としてDRSのShould(あるべき)/Must(必ず)のルールでvMotionをメンテナンス時や障害時以外にはvMotionを発生させないようにするということが、従来型/古くからのNAS/SAN、もしくはHCIであっても、インフラストラクチャに関係なく推奨されています。

NAS/SANにあっては最良のシナリオでも100%リモートのIOですが、Nutanixにおいてはこれは最悪のシナリオです。Nutanixは通常時、100万IOPSであり、ライブマイグレーションとその後の数分間パフォーマンスが20%落ちると考えてみましょう。

それでもまだ80万IOPSです。これでも殆どのNAS/SANのソリューションが提供する性能よりも高いのです。

しかし、実際のところは以下のリアルタムに録画されたビデオが示すとおり、ライブマイグレーションの最中やNutanixは優れたパフォーマンスを継続的に提供しています。ヒント: puttyのセッション(左側のコンソール内)の数字へご注目下さい。最終的な結果につながるゲストレベルでのパフォーマンスを示しています。

YouTube: 1M IOPS Live Migration

私の友人で同僚のMichael “Webscale” Webster (VCDX#66 & NPX#007)氏のビデオであるということをお伝えしておきます。

IOはライブマイグレーション中に3秒ほど100万IOPSを下回り、最低では95万6千 IOPSであるということが記録されています。つまり10%程度の低下が3秒ほどであればこれは非常に価値のあるものと言えるでしょう。というのも、パフォーマンスの低下は移行に伴う仮想マシンのスタン(静止)が原因であり、その下のストレージによるものではないからです。

我々の｢オトモダチ｣である古くからのストレージベンダーもそれぞれの巨大で最悪なストレージ装置で同じテストを繰り返し行なっています。

あまり面白くありませんか? では 70/30の read/writeワークロードがどう動くか見ていきましょう!

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

AHVのパフォーマンスに関する記事ですが、未だに続く、ローカリティとライブマイグレーションの相性の悪さの問題に答えるものとなっています。昨年の記事にもある通り、そもそもライブマイグレーション自身がリソースを多く消費するため、ライブマイグレーションは頻繁に行うべきものではありませんし、ライブマイグレーション後もリモートからのReadは"オンデマンド"にローカルへのコピーが行われるため、急速にリモートに対するReadの割合は低下します。また今回Joshさん(とそのお友達のMichaelさん)が示したとおり、(ワークロードが非常に大きなものであったとしても!)大きな影響は発生しないのです。(ネットワークもRDMAを使っているということもあるでしょう!)

AHVは常に進化を続けますが、その進化はHCIインフラの中だけに最適化されたものです。万能を切り捨てたゆえの思い切ったアーキテクチャに今後も注目です。来週もJoshさんの記事をお送りします。

こんにちは。普段、Commvault のブログのパートを担当しておりますが、今回は、Data Domain とクラウドを活用するデータ保護ソリューションをご紹介します。

クラウドを活用したデータ保護については、以前よりも技術面や経済面で敷居が低くなり、他社のバックアップベンダーでも積極的にクラウドの活用を行っていますが、データの転送量や転送にかかる時間、ネットワークの帯域幅など考慮すべき点が多いのも事実です。

そんな中、Dell EMC が今年の5月にラスベガスで開催した「Dell EMC World 2017」でクラウド災害対策ソリューション Data Domain Cloud DR が発表されました。

Dell EMC データ保護製品の「Avamar/Data Domain」を組み合わせることにより、有事の際にオンプレミス上の VMware 仮想マシンを、AWS の EC2 インスタンスへ自動変換しディザスタリカバリを実現します。

製品リリース前のベータプログラムの評価を行いましたので、クラウドを有効活用したDRソリューションをご紹介したいと思います。

データ保護ソリューションにおいて「クラウド」と聞いて、皆さんは何を思い浮かべますか？

今日現在、クラウド環境内では、セキュリティの対策に加えて、冗長化の構成が進んでおり、より安全性・信頼性の高い環境が提供されていますので、オンプレミスの２次バックアップ先、さらにオンプレミスのディザスタリカバリ先として検討されるケースが増えてきています。

 【クラウドの活用例】

• 災害対策でデータを保存する場所
• ストレージのコストを削減するための場所
• オンプレミスのディザスタリカバリ先(←今回ここに注目)

Data Domain とクラウドを活用する例として、Data Domain のストレージをクラウドへ階層化し、長期保管を目的した「Data Domain Cloud Tier」が既に提供されています。

これは、データ移動ポリシーに従い、Data Domain からクラウドへアクティブ階層に存在していないセグメントのみを直接送信し、データのリコールのためにクラウドから取り出すのは一意のセグメントのみですので、データ転送時のネットワーク使用量を削減することができます。

また、今年 AWS EC2 や Microsoft Azure 上での Data Domain Virtual Editionの構成もサポートされて、物理 Data Domainから 仮想 Data Domain へのレプリケーションなど、Data Domain とクラウドを組み合わせたデータ保護がさらに注目されてきそうですね。

それでは、本題の Data Domain Cloud DR の製品について、ご説明していきます。

【Data Domain Cloud DR 構成概要図】

【Data Domain Cloud DR 製品概要】

• Data Domain Cloud DR 関連コンポーネントのシンプルなデプロイとセットアップ
• 既存 Avamar と Data Domain を使用可能
• オンプレミスの Data Domain から Amazon S3 へ直接保護 (重複排除・データ圧縮転送)
• Avamar 管理コンソールからバックアップポリシーの設定操作が可能
• EC2 への DR (Failover) および vSphere への Failback を提供 (AWS⇔vSphere間を自動変換)

Data Domain Cloud DR は、オンプレミスの Avamar と Data Domain 環境と組み合わせて、オンプレミス上で取得した VMware 仮想マシンのバックアップ、クラウドバックアップおよびディザスタリカバリの統合管理を提供します。

これから Data Domain Cloud DR の構成環境と動作概要を順に解説していきますが、Data Domain Cloud DR は、2つのメインのコンポーネントと関連コンポーネントで構成されます。オンプレミス側には、Cloud DR Add-on (CDRA) と呼ばれる仮想アプライアンスを配置し、AWS 側には、Cloud DR Server (CDRS) と呼ばれる EC2 インスタンスを配置します。

【Data Domain Cloud DR 動作概要】

Data Domain と Data Domain Cloud DR Add-on との間で DD Boost 機能が使用され、Cloud DR Add-on が Data Domain のバックアップを読み取って、S3 に自動コピーします。Cloud DR Server は、S3 にコピーされたバックアップからリストアする際に、Amazon マシンイメージへの変換など、リカバリ処理の全体管理を行っています。

オンプレミス側の VMware 仮想環境のバックアップは、従来通り、Avamar 管理コンソールを使用して、バックアップポリシーの設定を実施することができます。Data Domain Cloud DR のために新たな操作を覚える必要がなく、AWS 上にバックアップを取得するかどうか、バックアップポリシーの中で選択できます。

【Avamar Cloud DR 設定】

オンプレミスからAWSへのバックアップデータの流れですが、以下、フルバックアップと増分バックアップ(永久増分)の動作を参照ください。２回目以降は、永久増分として変更のみをバックアップする動作になります。

【フルバックアップの流れ】

1. Avamar から仮想マシンのフルバックアップを実施し、Data Domain に保管
2. フルバックアップ完了後、Data Domain Cloud DR から Data Domain のバックアップデータを読み込んで、データ暗号化・圧縮処理を実施
3. Amazon S3 のバケットへセグメント単位でデータ転送

【増分バックアップの流れ】

1. Avamar から仮想マシンの増分バックアップを実施し、Data Domain に保管
2. 増分バックアップ完了後、Data Domain Cloud DR から Data Domain のバックアップデータを読み込んで、データ暗号化・圧縮処理を実施
3. フルバックアップ以降の変更のみを Amazon S3 のバケットへ送信 

次に、Amazon S3 上のバックアップから Amazon EC2 へリカバリを行う「Failover」ですが、以下の順で実行されます。Amazon Machine Image (AMI) の変換の際に VMware Tools のアンインストールが実施されます。

1. Avamar または Cloud DR Server の管理コンソールから Failover を開始
   

2. Restore Service インスタンスを起動
   

3. S3 のバックアップから VMX ファイルと VMDK ファイルを元の状態に戻す
   

4. VMDK ファイルを EC2 上の Amazon マシンイメージに変換

5. 最後に、EC2 インスタンスとして起動し、リカバリが完了

ベータ版のテストでは、以下の環境で Failover リカバリの所要時間を確認することができましたが、ご利用の環境によって、この数値は変わりますので、参考値(目安)としてください。

バックアップデータからクラウド環境へリカバリ機能を搭載するバックアップ製品は増えてきていますが、クラウド環境からオンプレミス環境へ切り戻しが可能な製品はまだ少ない状況です。Data Domain Cloud DR (バージョン 17.3 以降)では、オンプレミスと AWS とのサイト間での差分データを切り戻す「Failback」機能が追加されていますので、オンプレミス側の VMware 仮想環境で”再”稼働させることもできます。

【Cloud DR Failback 操作画面】

今回のブログでは、オンプレミスとクラウドを１つのシステムとして活用できる新たなディザスタリカバリ・ ソリューションとして、Data Domain Cloud DR をご紹介いたしました。

今後、Data Domain Cloud DRの新機能など追加がありましたら、再度ご紹介させていただきますが、ディザスタリカバリ先のインフラ構築にかけるコストをできるだけ抑えるためには、クラウドを活用する構成は、コストメリットの高い有効な手法になりますので、ご参考になれば幸いです。

最後に DELL EMC 製品情報と DPS x VxRail キャンペーン情報(2017年9月15日～2018年1月31日)をご案内いたします。詳細は、以下のURLをご参照ください。

EMC製品ページ：
http://www.networld.co.jp/product/emc/

DPS×VxRailキャンペーン：
http://www.networld.co.jp/campaign/emc_avamarve_vxrail/

それでは次回もよろしくお願いします。

担当：斉藤・吉田・(松村)

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 4 – Securityをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

セキュリティはXCPの設計において、一つ肝となる部分です。革新的な自動化を利用した結果、おそらく業界で最も堅牢でシンプルで包括的な仮想化インフラストラクチャが出来上がりました。

AHVはハードウェアベンダーのHCLを包括的にサポートするようには設計されていません、更にはボルトオンスタイルで数え切れないほどの手間のかかる製品群を積み上げたものでもありません。AHVはそうしない代わりに、Nutanixの分散ストレージファブリックとうまく動くように最適化されており、認証の下りたNutanixもしくはOEMパートナーのアプライアンス上で全てのサービスと機能を完全にウェブスケール式に提供できるようにしてあります。

これによって、他のハイパーバイザーと比べ、より緻密で目的にフォーカスした品質管理と被攻撃面を劇的に削減することができているのです。

セキュリティ開発ライフサイクル(SecDL)が全てのAcropolis プラットフォームで活用されており、全てのコードの一行一行までが本稼働環境での動作を保証されています。この設計はdefense-in-depthモデルに従っており、すべての必要のないlibvirt/QEMU(SPICE、利用しないドライバー)のサービスは削除されています。さらにlibvirtの非-rootグループでソケットは最小限の権限しか付与されないようになっており、SELinuxがゲストのvmescapeからの保護を保証し、その上侵入検知システムが組み込まれています。

AHVは文書化されたセキュリティベースライン(XCCDF STIG)をサポートしており、自己修復機能を搭載しています。お客様の定義した間隔でハイバーバイザーはセキュリティベースラインに対するあらゆる変更をスキャンし、あらゆる不都合が検出さればた場合にユーザーを介さずにバックグラウンドでその変更をリセットします。

Acropolisプラットフォームも更に包括的なセキュリティの認証/検証のリストを保持しています:

まとめ

Acropolisは以下のような多くのセキュリティの先進性を提供している:

1. 組み込みの自己監査を行うセキュリティ技術実装ガイド(STIGs - Security Technical Implementation Guides)
2. 管理者が要塞化の推奨事項を適応する必要のない、そもそもから既に要塞化されたハイパーバイザー
3. 他のサポートされているハイパーバイザーに比べて削減された被攻撃面

Nutanixのセキュリティに関しては以下もご参照下さい:

• Enabling security and compliance for Nutanix(和訳予定なし)
• Simply Secure(和訳予定なし)

インデックスへ戻る

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

第4弾はセキュリティです。ハイパーバイザーはOSの一種ですが、そのうえでさらに多くのOSを起動することを考えると最もセキュリティが必要とされるOSであるということになるのではないでしょうか。AHVは変更検知と自動修復の機能を持ったハイパーバイザーです。また、不要なドライバーなどは入っていないため、巨大なHCLを抱えるOSに比べて被攻撃面も小さくなります。

私自身はセキュリティについて詳しいわけではありませんが、セキュリティ面で見てもシンプルであるが故に、非常に堅牢なハイパーバイザーということは理解できます。

ようやく折り返しですが、次回の第5段にもご期待ください。

本記事は全三回の連載になっています。本記事は全三回の連載になっています。興味のある方は他の回のコンテンツもご覧ください。

第1回: Nutanix Xtract for VMsは使えるのか？　

http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--61ff.html

第2回: Nutanix Xtract for VMs Deep Dive ～データ転送の裏側～

http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--342e.html

第3回: Nutanix Xtract for VMs Deep Dive ～ハイパーバイザー変更を吸収する仕組みとは～

http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--ae65.html

AHV移行時の課題

 既存のHypervisorからAHVへ移行する場合、前回お話したように「ダウンタイムをいかに最小限にするか？」「何かあったときに容易に切り戻り（ロールバック）できるか？」という点が重要になってきます。この2点をどのようにXtract for VMsで解決しているのが、データの転送の観点からみていきたいと思います。

Xtract for VMsの移行の流れ

　 Xtract for VMsの移行はシンプルな移行ジョブとして作成されますが、当然裏側では様々なタスクが実行されています。スムーズな移行を実現するためにタスクを分類すると、「ダウンタイムを最小限にするためのデータ転送のタスク」と「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」にわけることができます。

　今回はこのうち「ダウンタイムを最小限にするためのデータ転送のタスク」について掘り下げていきたいと思います。来週執筆予定の「Xtract for VMs Deep Dive第2回」では「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」について掘り下げる予定です。

ソースとなるvSphere環境から仮想マシン1台（Xt-02-w2k12r2）をAHV環境へ移行する流れは以下になります。今回はデータ転送が行われるフェーズの①～③について出力されるログをベースにどんな処理が実行されているのか見ていきましょう。

Migration Planの作成

↓

Migration Planの実行

↓①

CutOverの待機

↓②

CutOverの実行

↓③

Migration Planの完了

Xtract for VMsのデータ転送の仕組み(Migration Planの実行編)

　Xtract for VMsでは「Migration Plan」の実行時に「Data Seeding」と呼ばれる移行元仮想マシンの全データの転送が行われます。このとき、仮想マシンはもちろんゲストOSの中で動作するアプリケーションは動作していて問題ありません。

この「Data Seeding」時は、以下のようなデータ転送処理が行われます。他にもゲストOS内で様々な処理が実行されますが、データ転送に関わる部分だけを取り上げています。仮想マシンがもつすべてのスナップショットが削除される点だけ注意が必要です。

• 仮想マシンがもつすべてのスナップショットの削除
• 仮想マシンのスナップショットの取得（ロールバック時にはこのスナップショットに戻る）
• 全データの転送

これらのスナップショットの取得は、ソースとなる仮想マシンのvmware.logファイルにログが出力されます。「XTRACT-VMSnap-0」というスナップショットを取得していることがわかります。

では次に気になるデータ転送の経路についてみていきましょう。

 Xtract for VMsでは通常移行先のAHVクラスタ上にXtract for VMsの仮想アプライアンスを展開します。この仮想アプライアンスを中心にどういったデータ転送が発生するのでしょうか。

　まずソースVMのデータのやりとりは、通常のvSphere環境でバックアップするときに用いられるVADP(vStorage API for Data Protection)と呼ばれるAPIを利用しています。ソースの仮想マシンに対してスナップショットを実行して、仮想ハードディスクに対して読み取り専用でアクセスすることができます。

　そしてターゲットVMのデータのやりとりは、AHVクラスタ上の「Storage Container（データストア）」をXtract for VMsのゲストOSがNFSマウントすることで、直接AHVクラスタへデータを書き込みます。一度Xtract for VMsにデータを保存して、それをもう一度AHVクラスタへ書き込むようなことはしていません。そのため、データ転送自体最短で完了することができますし、移行元のデータサイズによってXtract for VMsにローカルディスクを追加する必要もありません。

図としてあらわすと以下のようになります。

　これらの一連のタスクのログは、Xtract for VMsのサポートログの中に、xtract-vm-diskreader.log,xtract-vm-diskwriter.logのログとして保存されています。

Data Seedingフェーズではこのような動作で、Xtract for VMsを介して移行元仮想マシンのデータを移行先のAHVクラスタへデータを転送しているようです。

Xtract for VMsのデータ転送の仕組み(Cutoverの待機編)

　先ほどのData Seedingフェーズで全データを転送しましたが、アプリケーションは起動状態だったため最後にデータ整合性を担保したデータで上書きする必要があります。

　しかし、仮想マシンの移行時にData Seeding後にすぐに移行（Cutover）をするとは限りません。動作確認等を入念に行ったり、短時間とはいえシステム停止が必要なためメンテナンス時間の調整で、一ヵ月先になったりすることも当然考えられます。

　例えばData Seedingを行ってから一ヵ月後に移行する場合、一ヵ月の差分データを移行直前にすべて転送完了する必要があります。アプリケーションやデータ構造によっては大部分のデータを再転送することも考えられます。その場合、データサイズによってはシステム停止の時間が長時間になってしまいます。

システム停止時間を最小に抑えるためにXtract for VMsではData Seeding完了後からCutoverが実行されるまでの間は10分間隔で移行元仮想マシンのデータを移行先AHVクラスタへ差分転送が実行されるアーキテクチャになっています。

　こうすることで、アプリケーションやデータ構造によるデータ変更量の多少、Data SeedingからCutoverの期間に長さに関わらず、Cutover時には最長でも10分前のデータが担保された状態を維持することができるのです。

　10分間隔と非常に短い間隔で実行されていますが、差分データの取得にはData Seeding時と同じVADPのCBT(Change Block Tracking)の機能を利用しているため、すべてのデータの差分チェックを行う必要はありません。既に変更があったブロックを認識しているため、変更ブロックだけを速やかに差分転送することが可能なアーキテクチャを採用しています。

　Data Seeding時と同様に移行元仮想マシンのvmware.logファイルにCBTを利用した差分データの取得のログが出力されます。

Xtract for VMsのデータ転送の仕組み(Cutoverの実行編)

さて最後になりました。実際にvSphere上で動いている仮想マシンを停止して、AHVクラスタ上で仮想マシンを起動する「Cutover」フェーズの動作をみていきましょう。

まずソースとなるvSphere上の仮想マシンでは以下のようなタスクが実行されます。

• Guest OSの停止
• スナップショットの取得
• （データ整合性が担保される、差分データ転送）
• スナップショットの削除
• 仮想マシンのNICの接続を解除
• Migrate Plan実行時に取得したスナップショットの削除

　先ほどCutoverの待機編で説明したように、直近10分前のデータ同期が完了しているためこの3の最後の差分データ転送が短時間で完了するため、まるでOSのパッチ適用をするぐらいのメンテナンス時間で容易に移行できるのがXtract for VMsの最大の特徴ということができます。

そして移行先となるAHVクラスタ上ではPrismを確認すると以下のようなタスクが実行されます。今回の移行元仮想マシンが仮想HDDを2つ持っているためImageが2つ作成されています。

• Xtract for VMが書き込んだHDDをもとにテンプレート（Image）を作成
• 1で作成されたテンプレートを元に仮想マシンを作成
• 仮想マシンの電源をオン
• テンプレートを削除

今回はXtract for VMsを使ったvSphereからAHVへの仮想マシンの移行の際のデータの転送の仕組みについて掘り下げて紹介してみました。次回はどうやってハイパーバイザーの違いを吸収しているのか、ゲストOSで実行されているXtract for VMの移行タスクについて掘り下げて紹介してみたいと思います。

ではまた来週。