LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

NutanixのVLANによる仮想ネットワークセグメントおよび構成変更不可のコンポーネントについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は2つの話題は1回の記事でご紹介したいと思います。

 

・VLANによる仮想ネットワークセグメント

構成変更不可のコンポーネント

 

Nutanixのネットワークを構成するときに重要なものはVLANです。VLANを利用した仮想ネットワークのセグメント化がわかっていないとネットワーク構成ができません。今回はAHVホスト・コントローラーVM・仮想NICに対しての割り当てについてお話したいと思います。

また、Nutanixの設定の中では変更不可の項目がいくつかございます。あらかじめ設定変更不可の項目を覚えておくと構築で困ることがないと思います。(現時点の情報です)

 

1.VLANによる仮想ネットワークセグメント

f:id:t_komiya:20190504231304p:plain

・AHVホストをVLANに割り当てる

AHVホストをVLANに割り当てるには、クラスタ内のすべてのAHVホストで次の手順を実行します。

1. SSHでAcropolisホストにログオンします

2. ポートbr0(デフォルトのOVSブリッジの内部ポート、br0)を、ホストにするVLANに割り当てます


root@ahv# ovs-vsctl set port br0 tag=host_vlan_tag

 

host_vlan_tagをホストのVLANタグに置き換えます

3. ポートbr0のVLANタギングを確認 root@ahv# ovs-vsctl list port br0

4. 表示されたタグパラメータの値を確認

5. pingテストを実行して、AHVホストのIPアドレスへの接続を確認します

 

コントローラVMのVLANへの割り当て

デフォルトではコントローラVMのパブリックインターフェイスはVLAN 0に 割り当てられています。

コントローラVMを別のVLANに割り当てるには、そのパブリックインターフェイスのVLAN IDを 変更します。変更後、新しいVLAN上にあるデバイスからパブリックインターフェイスにアクセスします。

 

注:コントローラVMへの接続が失われないようにするには、パブリックインターフェイスを 介してコントローラVMにログオンしているときにVLAN IDを変更しないでください。VLAN IDを変更するには、IPアドレス192.168.5.254を持つ内部インターフェイスにログオンします。

 

アクセスモードまたはトランクモードで動作するための仮想NICの設定

デフォルトではゲストVM上の仮想NICはアクセスモードで動作します。 このモードでは仮想NICは、それが接続されている仮想ネットワークのVLANである自分の VLAN上でのみトラフィックを送受信できます。アクセスモードインターフェイスの使用に 制限されている場合、複数のVLAN上でアプリケーションを実行している仮想マシン (ファイアウォールアプリケーションなど)は、複数の仮想NIC(各VLANに1つ)を使用する 必要があります。

アクセスモードで複数の仮想NICを設定する代わりに、トランクモードで動作するように 仮想マシン上に単一の仮想NICを設定できます。 トランクモードの仮想NICは、独自のVLANに加えて、任意の数のVLANを介してトラフィックを送受信できます。 特定のVLANをトランクすることも、すべてのVLANをトランクすることもできます。

仮想NICをトランクモードからアクセスモードに変換することもできます。

その場合、仮想NICは自身のVLAN上でのみトラフィックの送受信に戻ります。


2
.構成変更不可のコンポーネント

f:id:t_komiya:20190504232202p:plain

Nutanixソフトウェア

  • ローカルデータストア名
  • 名前や仮想ハードウェア構成を含む、任意のController VMの設定と内容(特定の機能を有効にするために必要な場合は、メモリを除く)

・AHV設定

  • インストールのパッケージを含むハイパーバイザーの設定
  • iSCSI設定
  • Open vSwitch設定
  • コントローラーVMのスナップショット取得

・ESXi設定

重要事項:vSphereのリソースプールを作成したら、NutanixのコントローラーVMは一番上の共有に配置しなければならない

  • NFS設定
  • VMスワップファイルのロケーション
  • VMの起動/シャットダウンの順番
  • iSCSIソフトウェアアダプタの設定
  • vSwitchNutanix 標準仮想スイッチ
  • 「管理ネットワーク」ポートグループ内のvmk0インターフェース
  • SSH enabled
  • ホストのファイアウォールポートが空いていること
  • コントローラーVMのスナップショット取得

・Hyper-V設定

  • 英語の言語パック
    現状、他の言語パックでのインストールがサポートがされていない
  • クラスタ名(ウェブコンソールを利用時)
  • ホスト名(ホスト名は、クラスタの拡張作成時にのみ設定できます)
  • 内部スイッチの設定と外部ネットワークアダプタ名

    Nutanixホスト上にExternalSwitchとInternalSwitchの2つの仮想スイッチが作成されます。
    これらの仮想スイッチに対応する2つの仮想アダプタ、vEthernet(ExternalSwitch)とvEthernet (InternalSwitch)がホスト上に作成されます。
    注:これらのスイッチとアダプタを削除したり、これらの仮想スイッチと仮想ネットワークアダプタの名前を変更したりしないでください

  • Windowsのロールと機能 Nutanixホストに新しいWindowsの役割や機能をインストールする必要はありません。これには特にマルチパスIO機能が含まれ、これによりNutanixストレージが使用できなくなる可能性があります。
  • 自動起動アクションのコントローラVM事前設定VM設定
  • コントローラVMの高可用性設定
  • コントローラVMの操作:コントローラVMの移行、状態の保存、またはチェックポイントの取得

参考情報までにチェックして頂ければ幸いです。

 

以上、よろしくお願い致します。

 

AHVのネットワーク設定について[第二弾]

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はAHVのネットワーク設定についてお話したいと思います。

以前にもこちらのトピックについてはお話しておりますが、前回は仮想スイッチのみのお話で終わってしまいましたので、今回は全般的なお話をしたいと思います。

前回の内容は以下のURLから確認ができます。

https://blog.lenovojp.com/entry/2018/09/09/162719

1.AHVのネットワーク概要

f:id:t_komiya:20190504130925p:plain

AHVはOpen vSwitchを利用してネットワークを構成します。OVS(Open vSwitchを略します)のサービスはそれぞれコンポーネントがありますのでそれぞれ説明したいと思います。

.Open vSwitch

f:id:t_komiya:20190504131316p:plain

Open vSwitchはLinuxカーネルで実装されており、マルチサーバーの環境環境で動作するように設計されております。OVSはMACアドレスを学習してテーブル管理しております。ハイパーバイザーと仮想マシンはスイッチの仮想ポートに接続します。各ハイパーバイザーはOVSインスタンスをホストして、すべてのOVSインスタンスが組み合わさって単一のスイッチを形成しています。(以前のブログで紹介した内容がこちらになります)

 

.ブリッジ

ブリッジは、物理インターフェイスと仮想インターフェイス間のネットワークトラフィックを管理するための仮想スイッチとして機能します。

デフォルトのAHV構成には、br0というOVSブリッジとvirbr0というネイティブLinuxブリッジが含まれています。

virbr0 Linuxブリッジは、CVMとAHVホスト間の管理通信専用に使用されます。他のすべてのストレージ、ホスト、およびVMネットワークトラフィックは、br0 OVSブリッジを通過します。

AHVホスト、仮想マシン、および物理インターフェイスは、ブリッジへの接続に「ポート」を使用します。

 

.ボンド

ボンドポートはAHVホストの物理インターフェースにNICチーミングを提供します。

デフォルトでは、bond0という名前のbondがブリッジbr0に作成されます。ノードイメージングプロセスの後、すべてのインターフェースは単一のBond内に配置されます。これはFoundationイメージングプロセスの要件です。

デフォルトの設定は、初期の展開時にbond0から1ギガビットポートを削除するように変更する必要があります。10ギガビットポートだけが残ります。 Open vSwitchボンディングでは、アクティブバックアップ、balance-slb、balance-tcpなど、いくつかの負荷分散モードが可能。

リンクアグリゲーション制御プロトコル(LACP)もボンドに対してアクティブにできます。 "bond_mode"設定はインストール中に指定されないため、デフォルトでactive-backupになります。

f:id:t_komiya:20190504131936p:plain

5.IPアドレス管理(IPAM)

ネットワークの作成とVLAN管理に加えて、AcropolisはDHCPを使用して仮想マシンへの IPアドレスもサポートします。

各仮想ネットワークと関連VLANは、特定のIPサブセット、関連ドメイン設定、および割り当てに使用可能なIPアドレスプールのグループを使用して設定できます。 Acropolisは、設定されたIPアドレスプールと設定が使用されるように、OVSのVXLANとOpenFlowルールを使用してユーザーVMからのDHCP要求を傍受します。

管理者はAcropolisとIPAMを使用して統合されたPrismインターフェースからネットワーク管理を含む完全な仮想化導入を実現できます。これにより、仮想マシンのプロビジョニングと ネットワークアドレスの割り当てに関連する従来の複雑なネットワーク管理が大幅に 簡素化されます。 IPAM機能を有効にしてアドレスの重複を回避する前に、必ずネットワーク チームと協力して仮想マシンのアドレス範囲を逆にしてください。

管理対象VMのNICが作成されると、IPアドレスがアドレスプールから割り当てられます。 VM NICまたはVMが削除されるまで、アドレスはプールに解放されません。

.ネットワーク設定におけるベストプラクティス

f:id:t_komiya:20190504132307p:plain

ベストプラクティス内容については、AHVのネットワークの内容における注意点ではありますが、必ずしもこれを満たさなければ接続できないわけではなく、ベストケースであることをあらかじめご了承ください。

OVSブリッジのOpenFlowテーブルは変更しないでください。

1GbEおよび10GbEについてはそれぞれのインタフェースの注意事項がイメージに記載しております。VLANについてもデフォルトで設定されているものもありますので、注意しながら変更して下さい。 

f:id:t_komiya:20190504132354p:plain

上位のネットワークスイッチについては、基本はノンブロッキングがおススメです。諸条件はイメージ内に記載しておりますので、ご覧ください。 

IPMIインタフェースはトランクしないでください。

f:id:t_komiya:20190504132433p:plain

CVMについては設定は削除していけないものがありますのでご注意下さい。OVSのボンディングについては10GbEで設定をお願いします。

 

AHVのネットワークを設定する前に是非注意事項として覚えて頂ければ幸いです。

 

よろしくお願い致します。

 

Nutanixのストレージ設定について~Erasure Coding / Compression / Deduplication~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのストレージに関して説明したいと思います。

 

Nutanix Enterprise Cloud Platformには、あらゆるワークロードで利用可能な容量を効率的に利用するために連携して機能する、幅広いストレージ最適化テクノロジが組み込まれています。 これらのテクノロジはインテリジェントでワークロードの特性に対応しているため、手動による設定や微調整が不要です。

以下のストレージ最適化手法を活用できます。

  • イレージャーコーディング(Erasure Coding):
    クラスタの有効容量または使用可能容量を増やします。Erasure Codingを有効にした後に生じる容量削減は、圧縮および重複排除の容量削減に追加されます
  • 圧縮(Compression):
    2種類の圧縮のうちの1つを可能にするオプションのコンテナ設定・ポストプロセスの圧縮:データは書き込まれた後に圧縮されます・インラインの圧縮:データが書き込まれる際に圧縮されます

  • 重複排除(Deduplication):
    パフォーマンスを向上させるためのプレミアム層(RAMとフラッシュ)、またはストレージスペースの節約のための容量層(HDD)での同一のゲスト仮想マシンデータの共有。コンテナーまたはvDiskのプロパティによって有効になります

それでは、各設定についてイメージで説明したいと思います。

 

1.イレージャーコーディング

f:id:t_komiya:20190505114726p:plain

 今回の構成は6ノードで4つのデータブロックをRF2の構成時のイレージャーコーディングの説明になります。一言で言いますと、ノードをディスクに見立ててRAIDを構成するイメージになります。通常はミラー構成なので容量は半分になりますが、イレージャーコーディングは約70%程度効率が上がります。ノード数が増えるほど、容量効率が上がるような仕組みになります。

まず、RF2なのでクラスタ内に2つのデータコピーが維持されます。

f:id:t_komiya:20190505114746p:plain

4つのデータが6つのノードに格納されますが、赤字がそのイメージだと思って頂ければと思います。

f:id:t_komiya:20190505114801p:plain

ノードを保護するためにパリティを配置して、一つのノードがダウンしてもデータを再調整行われるようになっています。詳細はイメージをご参照ください。

f:id:t_komiya:20190505114820p:plain



こちらの図はノードが一台障害があった場合の動作になります。CのデータがPを利用してもう一つ別のノードで再調整されてデータが配置されます。

ノード数が多い場合には、この方式が大変有効になります。

 

.圧縮(Compression)

コンテナは圧縮を有効にできます。 Snappy圧縮ライブラリを使用した書き込み操作中または 書き込み操作後にデータの圧縮が行われます。 Nutanixによるテストでは、ディスクスペース 使用量の約30%の削減が示されていますが、実際のディスクスペース使用量の削減は環境ごとに異なります。

 

次の種類の圧縮が利用可能です

  • ポストプロセスの圧縮:データは書き込まれた後に圧縮されます
    書き込みと圧縮の間の遅延時間は設定可能です。
    ワークロードごとに異なるI/Oプロファイルが あるため、Nutanixに推奨される遅延値はありません。
    このタイプの圧縮は、ほとんどのワークロードにお勧めです
  • インラインの圧縮:データが書き込まれる際に圧縮されます
    このタイプの圧縮は、バッチ処理を実行するほとんどのワークロードに推奨

f:id:t_komiya:20190503185920p:plain

圧縮については、ワークロードにより適しているものがあるため、ケースによって使い分けることが良いでしょう。

 

.重複排除(Deduplication)
f:id:t_komiya:20190503190206p:plain

重複排除については、リードキャッシュ用の重複排除と容量削減用の重複排除の二つがあります。どちらの機能を利用するかは、購入するエディションにも依存するので注意してください。

さらに、重複排除が有効になっているクラスター内のコントローラーVMは、追加のRAMで構成する必要があります。

・キャッシュ重複排除:24GB RAM

・容量重複排除:32GB RAM

f:id:t_komiya:20190503190448p:plain

重複排除についてもベストプラクティスがあります。データの特性やワークロードにより、使用しても意味がない場合がありますので、十分に注意して利用してください。

 

ストレージ機能としては当たり前のようにサポートしている機能ですが、どのようなもので利用するのかを含めて、最適なストレージの設定を行うようにして頂ければと思います。

 

よろしくお願い致します。

 

 

 

Nutanixの分散ストレージファブリック(Distributed Storage Fabric)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixの分散ストレージファブリック(Distributed Storage Fabric)についてご説明します。前回のブログでDSFについては一部説明はしているものの、詳細の説明については今回のブログでお話したいと思います。

 

1.分散ストレージファブリック(Distributed Storage Fabric)について

Nutanix Acropolis DSF(Distributed Storage Fabric)は、同じホスト上のローカルVMに ストレージリソースを提供することで、ゲストVMのパフォーマンスを向上させます。この方法により、ローカルストレージコントローラ(Nutanixノードごとに1つ)は、同じ物理ノード上で実行されている仮想マシンによって行われたI/O要求の処理にリソースを割り当てることが できます。クラスタ内で実行されている他のコントローラは、自分のローカルゲストVMに よって行われたI/O要求を自由に処理できます。このアーキテクチャは、リモートストレージ コントローラとネットワーク(SANまたはNAS)全体に配置されたリソースを持つ従来の ストレージアレイとは対照的です。

Nutanixアーキテクチャには、いくつかの重要なパフォーマンス上の利点があります。まず、 ストレージリソースはローカルであるため、各要求はネットワークを通過しません。これにより、I/Oパスから物理ネットワークが排除されるため、待ち時間が大幅に短縮されます。さらに、 各ホスト(またはNutanixノード)には独自の仮想ストレージコントローラ(CVM)があるため、共有ストレージアーキテクチャで一般的なストレージのボトルネックが解消されます。新しいNutanixノードをクラスタに追加すると、CVMも同じ割合で追加され、予測可能でスケーラブル、そしてリニアなパフォーマンスを提供します。スケールアウトアーキテクチャにより、予測可能な高いストレージパフォーマンスが可能になります。

 

2.ストレージのコンポーネント

f:id:t_komiya:20190502234719p:plain

ここで、各コンポーネントについての説明をしたいと思います。(一部前回内容と重複しますが)

・ストレージティア

ストレージティアは利用可能な物理ストレージの種類を定義します。 Webコンソールから、ストレージプール内のディスクの階層の内訳を判断できます。

・ストレージプール

ストレージプールは1つ以上の層からの物理ディスクのグループです。 ストレージデバイスは一度に1つのストレージプールにしか割り当てることができないため、ストレージプールは仮想マシン間の物理的な分離を提供します。 Nutanixはクラスタ内のすべてのディスクを保持するために単一のストレージプールを作成することをお勧めします。 ほとんどのユースケースをサポートするこの構成により、クラスターは容量やIOPSなどのリソースの分配を動的に最適化できます。 ディスクを別々のストレージプールに分離すると、仮想マシン間の物理的な分離が可能になりますが、ディスクがアクティブに使用されていない場合は、これらのリソースが均衡にならない可能性もあります。 新しいノードを追加してクラスタを拡張すると、新しいディスクも既存のストレージプールに追加できます。このスケールアウトアーキテクチャにより、ニーズに合わせて成長するクラスタを構築できます。

・ストレージコンテナ

ストレージコンテナはストレージプール内の使用可能なストレージのサブセットです。 ストレージコンテナは仮想マシンによって使用される仮想ディスク(vDisk)を保持します。 新しいストレージコンテナのストレージプールを選択すると、vDiskが格納されている物理ディスクが定義されます。 Nutanixクラスター内のノードはNFSデータストア(vSphere)、SMB共有(Hyper-V)、またはiSCSIターゲット(vSphereまたはAHV)としてストレージコンテナをマウントして、仮想マシンファイル用の共有ストレージを提供できます。

このストレージはシンプロビジョニングされます。つまり、ストレージコンテナの作成時に合計最大容量を割り当てるのではなく、データが書き込まれるときに必要に応じてストレージがストレージコンテナに割り当てられます。 ストレージコンテナレベルでのオプションの1つは、(書き込まれているとおりに)インラインで、または書き込まれた後に圧縮を有効にすることです。

・ボリュームグループ

ボリュームグループは論理的に関連する仮想ディスク(またはボリューム)の集まりです。ボリュームグループはボリュームグループ内のディスクを共有する1つ以上の実行コンテキスト(仮想マシンまたは他のiSCSIイニシエータ)にアタッチされています。ボリュームグループをファーストクラスのエンティティとして管理できます。 1つ以上の実行コンテキスト、それらを障害回復ポリシーに含め、他の管理タスクを実行します。ボリュームグループを現在の実行コンテキストからデタッチして、同じアプリケーションのインスタンスを実行している別の実行コンテキストにアタッチすることもできます。これは、おそらくボリュームの複製先のリモートの場所にあります。

ボリュームグループは1つの単位として管理できます。 iSCSIターゲットとしてボリュームグループ全体をアタッチし、ボリュームグループ全体をデタッチします。
ただし、ボリュームグループ内のディスクのサイズを変更することはできます。

各ボリュームグループは、UUID、名前、およびiSCSIターゲット名によって識別されます。ボリュームグループ内の各ディスクには、UUIDと、ボリュームグループ内の順序を指定するLUN番号もあります。ボリュームグループは、排他アクセスまたは共有アクセスのどちらにも構成できます。

バックアップ、保護、復元(インプレース復元とアウトオブプレース復元)、およびボリュームグループの移行ができます。非同期データ複製(Async DR)用に構成された保護ドメインに、排他的にまたは仮想マシンと一緒にボリュームグループを含めることができます。ただし、メトロアベイラビリティに構成された保護ドメイン、保護されたvStore、またはアプリケーション整合性スナップショット作成が有効になっている整合性グループにボリュームグループを含めることはできません。

・vDisks

vDiskは仮想マシンにストレージを提供するストレージコンテナ内の使用可能なストレージのサブセットです。

ストレージコンテナーがNFSボリュームとしてマウントされている場合、そのストレージコンテナー内のvDiskの作成と管理はクラスターによって自動的に処理されます。

 

データストアについては、以下でイメージと併せてご説明します。

 

3.データストア/SMB共有

f:id:t_komiya:20190503000128p:plain vSphereで利用する場合はNFSもしくはiSCSIで提供されますが、通常利用するのはNFSの方が多いと思います。データをホストにローカライズすることでネットワークでのより取りを削減します。(データローカリティ)

ESXでNutanixコンテナを正しくマップするときは水色の内容に注意してください。

f:id:t_komiya:20190503000647p:plain

Hyper-V環境ではSMB共有でマウントします。基本的にはハイパーバイザーに最適なプロトコルをNutanixとして推奨しております。

f:id:t_komiya:20190503000848p:plain

前回のブログでも載せておりましたが、画面イメージをもう一度載せておきます。

ストレージのダッシュボードより、DSFに関する情報を確認することができます。

 

次回はストレージの設定についてご説明する予定です。

 

よろしくお願い致します。

 

Nutanixの用語を覚えてみよう!~Nutanixの構成要素について~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixの基本的な用語について説明します。新入社員が入ってきてこれからNutanixを覚えようという人もいらっしゃいますので、Nutanix Bibleもいいけれどこちらのサイトも是非参考資料としてみて頂ければと思います。

 

1.Nutanixの用語について

f:id:t_komiya:20190429231944p:plain

Nutanixを構成する用語ですが、これらの用語です。それぞれの用語について一つずつ説明していきたいと思います。

・ノード

ノードはNutanixクラスタの基本単位になります。各ノードは標準ハイパーバイザーを実行し、SSDとHDDストレージの両方で構成されたプロセッサー、メモリー、およびローカルストレージを含みます。

・ブロック

ブロックは、最大4つのノードを含むNutanixのラックマウント型ユニットです。(2U4Nodesの高密度サーバーが対象になります)

・クラスタ

クラスタはAcropolis Distributed Storage Fabric(DSF)を形成するNutanixブロックとノードのセットです。

・データストア

データストアは仮想マシン操作に必要なファイルの論理コンテナです。

・vDisk

vDiskは仮想マシンにストレージを提供するコンテナ内の使用可能なストレージのサブセットです。コンテナがNFSボリュームとしてマウントされている場合、そのコンテナー内のvDiskの作成および管理はクラスターによって自動的に処理されます。

・コンテナ

コンテナはストレージプールの論理的なセグメンテーションで、仮想マシンまたはファイルのグループ(vDisk)を含みます。コンテナは通常、NFSデータストアまたはSMB共有の形式で共有ストレージとしてホストにマッピングされます

・ストレージプール

ストレージプールとは、クラスタ用のSSDやHDDなどの物理ストレージデバイスのグループです。ストレージプールは複数のNutanixノードにまたがることができ、クラスターの規模が拡大するにつれて拡張されます。

・ストレージティア

ストレージティアでは、MapReduce階層化テクノロジを利用して、データを最適なストレージ階層(フラッシュまたはHDD)にインテリジェントに配置し、最速のパフォーマンスを実現します。

 

ここには記載はありませんが、AOS5.9からブロックの集合体でRackという概念があります。詳しい内容について過去のブログの方を参照して頂ければと思います。

https://blog.lenovojp.com/entry/2018/10/07/022932

2.ノードについて

f:id:t_komiya:20190429232609p:plain

仮想マシンのホストのことを指しますが、Nutanixは通常のラックサーバと高密度のサーバーで構成されるため、それぞれのハードウェアでわかりやすく示してみました。高密度サーバーでは、筐体の中に収納されている一台のサーバーになります。

3.ブロック・クラスタについて

f:id:t_komiya:20190429232937p:plain

ブロックについては先に説明した通り、高密度サーバーのみに適応される概念です。4ノードを一つのブロックとして扱います。もちろん、筐体障害の場合はシステム停止になったりします。そこで、複数の筐体にまたがってデータを格納する方式(Block Awareness)を採用することが多いです。

4.Prism上での画面イメージ

f:id:t_komiya:20190429233656p:plain

Prism上からの画面で説明します。ハードウェアのメニューからDiagramを選択するとNutanixのクラスタを形成しているハードウェアが表示されます。(今回は2U4Nodeの筐体に3台分しか表示されておりませんが)

今回の構成では、クラスタとブロックが同じ枠で囲われておりますが、ノード数が多ければクラスタは組んでいる構成で表示されます。

青色で表示されているところはDiskになりますが、コンポーネントに障害が起きていれば、該当のパーツが赤く表示されます。

5.Distributed Storage Fabric

f:id:t_komiya:20190429235655p:plain

Nutanixのノードがグループとなって、分散ストレージファブリックを形成されます。この分散ストレージがハイパーバイザーを動作させる基盤になり、またi/Oはローカルで処理された後に、データの冗長化を保つためにデータを分散配置します。

6.データの構造

f:id:t_komiya:20190430000004p:plain

DSFのデータ構造はこのようなイメージで構成されます。物理ディスクグループのストレージプールを作成され全体の容量が定義されます。そこからコンテナを定義して使用可能な領域を定義して、コンテナ内にvDisk(仮想マシン用の領域)を割り当てます。こちらについては、ハイパーバイザーによって、サポートするプロトコルも異なりますので、ご注意下さい。AHVについてはiSCSIになります。

f:id:t_komiya:20190430000642p:plain

ストレージについて画面イメージをこちらに載せておきます。ストレージメニューからTableを選択します。ストレージプールを選択すると、テーブル情報とサマリ情報が表示されます。こちらで、ストレージプールやコンテナの情報が確認できます。また、データをExportすることもできます。

 

以上、Nutanixの構成要素の説明を終わります。

 

よろしくお願い致します。

【太鼓判】ユニリタ・Actifio・レノボで実現するITモダナイゼーション

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はユニリタ社・Actifio社・レノボ社で実現するITモダナイゼーションについてソリューションをご紹介したいと思います。

 

ソリューションのご紹介の前に、ユニリタ社およびActifio社がどのような会社なのかをご存じでない方もいらっしゃいますので、両社のご紹介したいと思います。

 

ユニリタ [https://www.unirita.co.jp/]

データ活用領域、ITシステム運用管理領域のパッケージソフトウェア開発・販売・サポートおよびソリューション、コンサルティングサービスの提供しております。

「Information」「Service」「Cloud」3つのコアテクノロジーを通じてお客様のビジネスにおける価値を創造するDX(デジタルトランスフォーメーション)を加速させる真のパートナーを目指します。

 

Actifio[https://www.actifio.com/jp/]

データセンターバックアップソリューションの総合評価でNo.1(Gartner社)の実績、データの仮想化、コピーデータマネージメントで容量消費なく仮想コピー生成、任意の場所で即時アクセスを実現可能にし、増大するデータを削減するソリューションを提供しています。30ヶ国以上の国々で千社を超えるグローバル企業やサービスプロバイダーのお客様にソリューションを提供しています。

 

今回ご紹介するITモダナイゼーションについてですが、3社のソリューションをレガシーシステムのデータ移行を簡素化して、データの効率的な利用でDevOps 環境を最適化する「IT モダナイゼーション」ソリューションを提供します。

それぞれの会社製品も合わせて今回の内容をご紹介します。

 

1.現在のアプリケーションのITインフラの課題について

近年、企業が保有するデータ量は増え続けています。これらのデータを効率良く活用することが、DX(デジタルトランスフォーメーション)時代を生き抜くカギになります。そのため、データの集計、加工だけでなく、データの分析および開発テスト環境などさまざまな用途でデータをレガシーシステムから取り出し、活用することが必須になっています。しかし、DXを実現するには、ITモダナイゼーション(近代化)が必要です。

 

レガシーシステムは非常に高価であり、また運用も複雑化しています。データもレガシーシステム向けに入力することが必要であり、非常に手間がかかっています。また、アプリケーションも複雑なコードで構成されており、アップデートや変更に時間を要し、テスト工程も含めると莫大な時間と費用がかかります。今後はクラウドを活用した、SaaS(Software as a Service)などの活用や、Windowsアプリケーションからのデータ連携やテストデータなどの効率的な活用が必要です。

f:id:t_komiya:20190429123314p:plain

 「Waha! Transformer」「Actifio」「ThinkAgile HXシリーズ」の3つのソ
リューションを利用することで、ITモダナイゼーションの実現が可能とな
り、ビジネスに俊敏性が生まれ、戦略的なサービスが創造できるように
なります。

 

.3社のソリューションのご紹介

  • Waha! Transformer (ユニリタ社)
    「Waha! Transformer」でメインフレーム/UNIXといったレガシーシステ
    ムからのデータの変換/加工を行い、ユーザ環境に適したフォーマット
    に変換します。

    https://www.unirita.co.jp/products/waha.html

    f:id:t_komiya:20190429131644p:plain

  • Actifio (Actifio社)
    「Actifio」を利用することで、反復して利用するテストデータによるスト
    レージ容量を削減し、テストデータを短時間で提供することができます。
    コピーデータを一元管理した上でデータのマスキングも「Waha!
    Transformer」で連携して行います。
    https://www.actifio.com/jp/technology/solutions-architecture/

    f:id:t_komiya:20190429132446p:plain

  • ThinkAgile HXシリーズ (レノボ・エンタープライズ・ソリューションズ)
    レガシーシステムで抽出したデータを分析する基盤およびDevOps環境
    などで利用するテストデータの活用場所として、LenovoのNutanixアプ
    ライアンスである「ThinkAgile HXシリーズ」を利用することで、インフラ
    ストラクチャーの運用を簡素化します。さらにハイブリッドクラウドとの
    連携により、仮想環境およびアプリケーションが最適に動作可能な環
    境を提供します。

    https://www.lenovo.com/jp/ja/data-center/software-defined-infrastructure/ThinkAgile-HX-Series/p/WMD00000326

    f:id:t_komiya:20190429132929p:plain
    Lenovoの「ThinkAgile HXシリーズ」はハイブリッドクラウドの連携や運用の簡素化だけでなく、Lenovoが持っているハードウェアの特性やサポート体制が品質向上につながります。
    ハードウェアの信頼性については、サーバーベンダーのなかで4年連続No.1を獲得しております。運用管理についてもハードウェア管理するソフトウェアとNutanixとの連携でシステム全体を監視できるようになっています。また、ネットワークインフラとの親和性もあり、仮想マシン作成時にネットワーク機器に同時に設定を施すことができるようになっております。これはクラウドで利用される技術を採用することにより実現しています。また、お客様に提供する前にハイパーコンバージドインフラを事前導入することで、納品後すぐに利用できるサービスを提供しています。
    サポート体制に関しても、障害時のハードウェア・ソフトウェア含めた一括の窓口を提供しており、お客様は一つの電話番号でシステム障害の問い合わせが可能になっています。
    ハイパーコンバージドインフラの特徴に、無停止によるシステム拡張があります。事前に社内にシステム停止の連絡することなく、システムの拡張が可能で、IT管理者のTCO削減に大きく貢献します。SAPなどのミッションクリティカルな環境でも「ThinkAgile HXシリーズ」はサポートします。Lenovoは、SAPのグローバルマーケットリーダーであり、ベンチマークにおいてもパフォーマンスNo.1のベンダーです。レガシーの環境に比べてTCOを大きく削減することが可能です。

.ITモダナイゼーション実現の向けて

f:id:t_komiya:20190429133351p:plain


3社のソリューションを組み合わせたITモダナイゼーションをイメージ化したものがこちらになります。

是非、ITモダナイゼーションとDX時代を生き抜くために、「Waha! Transformer」
「Actifio」「ThinkAgile HXシリーズ」の組み合わせを、ぜひご検討ください。

 こちらは、レノボ・エンタープライズ・ソリューションの太鼓判にも掲載予定です。

 

よろしくお願い致します。

 

Nutanixが提供するコンテナプラットフォーム~Karbonのご紹介~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixが提供しているコンテナサービスのKarbonをご紹介します。

Karbonのことをご説明する前に、まずはコンテナとコンテナが必要な背景をお話したいと思います。

1.コンテナが必要な背景

f:id:t_komiya:20190413222737p:plain

Nutanixでは様々な機能を提供しています。ハイパーコンバージドインフラとして複雑さをなくし運用をシンプル化して高い俊敏性を兼ね備えてデータセンターのモダナイゼーションを実現しています。

Enterprise Cloudによりビジネスアプリケーションをできる完全一体型の単一ソフトウェアを提供していますし、オンプレミスとクラウド(Xi Cloud)を統合できる環境もすでに持っています。

今回のコンテナが関係するところについては、アプリケーションの開発者向けのプラットフォームの部分です。クラウド環境でアプリケーションを利用する場合、クラウド環境に適した環境でなければなりません。その場合に、従来型のようなスクラッチでの開発を行っていては、時間もお金もかかってしまうだけでなく、クラウド適した(俊敏性を要求される)環境には全く適しません。そこで、最新のアプリケーションとサービスを一つの環境で実行できるものとしてコンテナが必要となるわけです。

f:id:t_komiya:20190413223941p:plain

アプリケーションも進化しています。従来のアプリケーションは一つのモジュールで提供されていることからコードが複雑な構造になってしまい、アップデートや変更を行おうとするとすべての部分に影響が出てしまい、作り直しに手間がかかります。それによりテストの工数も増えてしまいインフラが俊敏性を兼ね備えてもアプリケーションが俊敏性を下げてしまう結果になります。

最近のアプリケーションはマイクロサービスと呼ばれるものに移行されています。マイクロサービスは、アプリケーションを複数のサービスに分割するため、アプリケーションの更新や変更が簡単になります。したがって、ビジネスの競争力を維持しながら更新が迅速に導入されます。

マイクロサービスにとって重要な要因となるインフラストラクチャのシフトがあります。それがコンテナです。

2.コンテナとはどういうもの?

f:id:t_komiya:20190413224450p:plain

コンテナと比較されるものとして、仮想マシンがあります。コンテナは仮想マシンに比べて、軽量であり、コンテナでホストOSをシェアできますし、OSを仮想化します。起動も早くメモリ消費も少ないのが特徴で持ち運びが非常に優れています。詳細はイメージをご参照ください。

3.コンテナのオーケストレーション

f:id:t_komiya:20190413224909p:plain

コンテナにはオーケストレーションが必要です。コンテナーオーケストレーションは、特に大規模で動的な環境において、コンテナーのライフサイクルを管理することがすべてです。ソフトウェアチームは、コンテナオーケストレーションを使用して多くのタスクを制御および自動化します。

・コンテナのプロビジョニングと配置

・コンテナの冗長性と可用性

・ホストインフラストラクチャ全体にアプリケーションの負荷を均等に分散するためのコンテナのスケールアップまたは削除

・ホスト内のリソースが不足している場合、またはホストが死んだ場合の、あるホストから別のホストへのコンテナの移動

・コンテナ間のリソース割り当て 外の世界を持つコンテナ内で実行されているサービスの外部への公開

・コンテナ間のサービスディスカバリのロードバランシング

・コンテナとホストのヘルスモニタリング

・アプリケーションを実行しているコンテナーに関連したアプリケーションの構成

4.Nutanix Karbon

f:id:t_komiya:20190413232958p:plainNutanix Karbonはお客様の環境を全体的にKubernetesクラスタを展開および管理するためのターンキーソリューションですKarbonはNutanixで上流およびネイティブのKubernetes機能を提供し、繰り返し作業を自動化し、複雑な作業を簡素化します。また、組織が自社のコード、コンテナ、およびアプリケーション開発にフォーカス できるようになりますf:id:t_komiya:20190413234116p:plain

 Karbonのメリットは使いやすく、管理しやすいプラットフォームにあります。インフラストラクチャと同時にライフサイクルを管理できるところ、サードパーティどのAPI連携できるのも特徴にあります。今後出てくる機能はAPI連携するものがリリースされる予定です。

.Kubernetes クラスタマネージャ

f:id:t_komiya:20190413234713p:plain

KarbonはPrism Centralで管理されるプラットフォームであり、Prismでのアラートやクラスタのヘルス管理も連携します。また、Karbon内部の解析も行うことができるようになるので、よりNutanixがインフラ(オンプレミスおよびクラウド含めて)アプリケーションの統合環境が実現されていくことになります。 

f:id:t_komiya:20190413235129p:plain

従来型のアプリケーションとクラウドネイティブのアプリケーションをNutanixで統合管理することができます。これにより、アプリケーションにとって望ましい環境でコンピュート環境を提供されることになります。

.Karbonでできること

f:id:t_komiya:20190413235610p:plain

Karbonを利用することで、Calmで作成するBlueprintは仮想マシンとコンテナの両方をサポートします。K8sのAPIはサードパーティとも連携し、統合したライフサイクル管理を実現します。 

f:id:t_komiya:20190413235814p:plain

Karbonを利用することで、LCM(LifeCycle Management)でファームウェアのみならず、マイクロサービスもまとめてアップグレードします。これにより、Era、Calm、Filesなどのアプリケーションも合わせてアップグレードされます。(今後これらがマイクロサービスで提供されるようになります)

 

今後はコンテナプラットフォームへの対応がNutanixで移行が進んでいくようになります。これによりインフラストラクチャとアプリケーションがもっと連携するような基盤がNutanixで出来上がっていくと思われます。

 

以上、よろしくお願い致します。

Nutanixのサイジングとベストプラクティスについて(その2)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixにおけるサイジングとベストプラクティスについての第二弾の内容をお伝えしたいと思います。

前回はNutanix Sizerの紹介とサイジングに関するそれぞれのリソースにおける注意事項をご紹介しましたが、今回はベストプラクティスを中心にお話したいと思います。

1.Nutanixのサイジングについて

f:id:t_komiya:20190407231503p:plain

 Nutanix Sizerでサイジングできる主なソリューションとして上記の内容になります。

VDIなどに関しては、VMware ViewやCitrix XenDesktopベースにしたサイジングやユーザ種別(タスクワーカー・オフィスワーカーなど)でサイジングできます。

サーバ仮想化については、仮想サーバの大きさを大・中・小と言った3種類で試算できます。

ほかにはデータベースやファイルサーバなどもソリューションもありますが、リソース全体でどのくらい必要なのか(例えば全体でCPUが200、メモリが500GB、容量が10TB程度など)を指定して算出するケースはRAW Inputなどを利用して算出できます。

 

サイジングするデータが事前にわかっていればよいが、実際の環境からそれを算出する方法はないのかと思う方もいらっしゃるかと思います。

2.仮想環境におけるデータの収集方法

f:id:t_komiya:20190407232936p:plain

既存のVMwareの環境がどれくらいの仮想でどのくらいのリソースを利用しているのかを簡単にわかるツールとして、RVToolsがあります。

お客様から既存環境の仮想マシンの一覧を頂くケースもありますが、実際に管理をしっかりやっていれば問題ないと思いますが、常にデータを管理できていれば良いですが、抜けがある場合も考えられます。

f:id:t_komiya:20190407233736p:plain

RVToolsは実際に仮想環境を管理するvCenterサーバもしくはESXホストから直接Credential情報をベースのログインして仮想マシンの情報を収集します。

収集した情報をレポートにまとめてもらえるので、仮想マシンのリソースが簡単に把握することができます。

f:id:t_komiya:20190407233844p:plain

f:id:t_komiya:20190407234015p:plain

RVToolsのレポートは上のイメージにもありますが、Excelライクな表示になります。こちらでリソースが把握できるわけですが、実際にどのように見ていくのかも合わせてもまとめておきました。
こちらをまとめて、RAW InputでサイジングをかけるとNutanixに必要な構成もすぐに出すこともできますので、是非ご利用下さい。

3.正しいサイジングについて

f:id:t_komiya:20190407234520p:plain

f:id:t_komiya:20190407234558p:plain

前回の内容からCPUとメモリのサイジング内容については記載していますが、改めて記載しておきます。メモリについては仮想マシンあたりのメモリオーバーヘッドの例を記載していますので、参考程度に見て頂ければと思います。

f:id:t_komiya:20190407234830p:plain

サイジングにおける注意事項を今回は記載したいと思います。

仮想環境でサイジングを行う場合、単に仮想マシンのリソースだけでサイジングするのではなく、CVMのオーバーヘッドも考慮する必要がありますので、数値を差し引くことを忘れずにお願いします。

また、CVMについてはCPUやメモリもありますので数値は前回のブログをご参照下さい。

圧縮。重複排除については、機能として利用できるが、CVMのオーバーヘッドにつながることから、利用しないほうがベターです。(利用しても良いがオーバーヘッドの考慮は忘れずに)

IOパフォーマンスを考慮する場合は、SSDの作業領域を多めにしておくことを忘れずに

既存環境もアセスメントしてからサイジングすることをお薦めします。

4.やってはいけないこと

f:id:t_komiya:20190407235344p:plain

Nutanixを提案する際によくあることを含めてコメントしたいと思います。

Nutanixはよく高いと言われて、価格を下げるためにRF2で提案している構成で、N+1台構成(例えば4台)からN台構成(例えば3台)に変更しようと言われます。

Nutanixや他のHCIも3台でも問題なく動作しますが、N台(特に3台)のケースでは、一台障害で落ちた場合に正常な状態での動作にはならないことから、障害対応も迅速に行う必要があります。そのため、N+1の構成はお客様に対する運用負荷を軽減させることもあるので、簡単に提案を変えることをしないようにお願いします。

変更する場合も、お客様にリスクを説明した上での対応を考えたほうがよいです。

気をつけよう!HCIに潜む落とし穴~知っておくとちょっと得をします~ - LTN Blog 〜 Lenovo Technology Network 〜

設計上の考慮事項についてですが、高密度型サーバー(2U4ノードのサーバー)を提案する場合に、筐体障害を考慮してBlock Awarenessを提案することをお忘れなく、一つの筐体でシステムが収まるという価値提案はできるものの、エンクロージャ障害には耐えられないため、Block Awarenessが必要になります。

Rack Awarenessは大規模の構成時に設計する概念になるため、小規模では意識する必要がありません。

Microsoftサポート、セキュリティ機能強化~AOS5.9の機能紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

VDIやGPUのプロファイルについては、アプリケーション要件があるために、CPUの周波数を意識する必要があります。

f:id:t_komiya:20190408000325p:plain

レプリケーション要件については、仕様やライセンス要件をご確認下さい。

LTN Blogにも過去にNear SyncやMetroAvailabilityの記事は紹介しております。

Nutanixのデータ保護について覚えてみよう~Metro Availability と Near Syncの違いについて~ - LTN Blog 〜 Lenovo Technology Network 〜

また、異なるノードを追加する際についてですが、皆さん普通に1ノード追加すればよいと考える方もいらっしゃいますが、異なる容量の受け皿はもう一台追加する必要があるので、ご注意下さい。

一台しか増設しない場合リソース計算を間違えないようにお願いします。

ライセンスについてはレプリケーション要件などで関連してきます。Ultimateライセンスにしておけば問題ないケースは多いですが、Filesや暗号化のソフトウェアライセンスはProライセンスでも利用できることから、エディションの選択は間違えないようにお願いします。

 

最後の方は、特に提案時に気をつける内容として、まとめさせていただきました。

 

よろしくお願い致します。

 

Nutanixのサイジングとベストプラクティスについて(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixにおけるサイジングとベストプラクティスについて2回の記事に分けてご紹介したいと思います。

Nutanixを構成する場合、提案するお客様の要件をヒアリングしてサイジングしたり、既存の環境などを調査してサイジングすることがあると思います。特に要件をヒアリングしてヒアリングする場合には、一般的にCPUやメモリやストレージをサイジングする場合に何か指標がないと困ると思います。(以下イメージはNutanix様の資料から拝借させて頂いております)

f:id:t_komiya:20190407160632p:plain

サイジングするにはまずワークロードのサイズを正しく知る必要があります。仮想マシンの数や種類、設定パラメータ、お客様が要求するSLAなどです。

上記の内容から簡単にサイジングすることは容易ではなく、ものによっては数日かかることもありました。

そんなサイジングを簡単にしてくれるのがNutanix Sizerです。

1.Nutanix Sizerとは?

f:id:t_komiya:20190407161000p:plain

Nutanix SizerはNutanix向けのサイジングツールで、実際に必要なワークロードを入力すれば、条件を満たすNutanixの構成をBOM(Bill of Material)の形で出力してくれます。

こちらのNutanix Sizerですが、my.nutanix.comから登録して利用することができます。

こにツールはSEさんまたは技術ユーザーが自分のニーズを満たす最適なソリューションを作成するためのツールです。利用する方は基本的にNutanixのアーキテクチャを理解されていることが前提としています。

2.サイジングするコンポーネントについて

f:id:t_komiya:20190407161543p:plain

サイジングするコンポーネントについてですが、イメージにもある通りCPU・メモリ・SSD・HDDなどが対象になります。(NICなどはサイジングに直接必要になるわけではありません)

必要な要件をNutanix Sizerに入力すれば、それぞれのメーカー毎に最適なマシンと必要な台数が出力されるわけですが、それぞれの項目について考慮する内容がありますので、そちらについて述べていきたいと思います。

.プロセッサの考慮について

f:id:t_komiya:20190407162341p:plain

プロセッサの考慮について、物理CPUと仮想CPUの考え方があります。仮想CPUは物理コアを割り当てることを考えていますが、ここで考慮する内容はワークロードによって物理コアを仮想CPUに対する割合が異なります。

一般的な仮想化では1:4の比率で割り当てることが多いですが、負荷の高いワークロードであれば、1:2になることもありますし、1:1のケースもあります。

VDIに関しては、一般的な環境では約1:8~1:10が一般的になりますが、こちらの数値は実際に各社のエンジニアでナレッジがありますので、もし各社の見積もりに開きがある場合はその観点かもしれません。

4.メモリの考慮について

f:id:t_komiya:20190407162258p:plain

 メモリに関する事項については、主に2点です。

一つはオーバーコミットについてです。VMwareをご存じの方はオーバーコミットなどを意識することがあるかと思いますが、NutanixのAHVについては現状メモリのオーバーコミットはないと考えてサイジングをお願いします。

また、CVMについてのメモリ容量も考慮しましょう。実際にNutanixのサポートポータルに載っている情報を記載しておりますが、こちらでVDIとサーバー仮想化で20GBがデフォルトで利用されると記載がありますが、実際の運用では20GBでもメモリが足りなくなるケースもあります。念のため、VDIやサーバー仮想化のワークロードでもCVMのメモリは28GBで定義しておくと良いでしょう。

5.機能毎のCVMの追加メモリ構成

f:id:t_komiya:20190407164650p:plain

Nutanixではストレージを有効活用するにあたり重複排除・圧縮機能やイレージャーコーディングなどがあります。この機能はCVMのリソースを消費しますので、その分をサイジングで考慮する必要があります。実際にストレージを容量効率を優先することも必要ですが、大容量でもない構成の場合には重複排除や圧縮などは利用しないほうがよいと思います。

6.SSDの考慮について

f:id:t_komiya:20190407165856p:plain

f:id:t_komiya:20190407165920p:plain

SSDについては、仮想マシンのデータの書き込みデータ用のキャッシュとして利用され、その後リモートのSSDにコピーされます。

また、SSDの階層は容量が75%を超えると、データをコールドティアのHDDにマイグレーションしてSSDの容量を75%以下にキープしようとします。

また、SSDに関しては、次のスライドで紹介しますが、以下のような構成になっています。

・Nutanix Home(CVMコア)

・Cassandra(メタデータストレージ)

・OpLog(持続書き込みバッファ)

・統合キャッシュ(SSDキャッシュ部分)

・エクステントストア(永続ストレージ)

f:id:t_komiya:20190407170559p:plain

ストレージとして最高のパフォーマンスを得るためにはSSDのサイジングは不可欠です。ここでは作業領域として必要領域をSSDの領域として確保することを記載しております。

 

注意:OpLogのサイズ変更は、AOSのリリース4.0.1の時点から動的に行われるようになりました。これにより、エクステントストア部分が動的に拡大することが可能になります。使用される値は完全に利用されたOpLogを仮定しています。例えば、OpLogの計算に使用される残りのGiBは、フォ​​ーマットされたSSD容量からNutanix HomeとCassandraが差し引かれた後になります。OpLogはすべてのSSDデバイスに配布されています。

可用性を確保するために、Nutanix Homeは最初の2つのSSD間でミラーリングされています。 5.0以降ではCassandraはノード内のSSD間でシャードされ(現在は最大4つ)、SSDあたり15GiBの初期に予約があります(メタデータの使用量が増えると一部のStargate SSDを利用できます)。デュアルSSDシステムでは、メタデータはSSD間でミラーリングされます。 SSDあたりのメタデータ予約は15GiBです(デュアルSSDの場合は30GiB、4本のSSDの場合は60GiB)

7.HDDの考慮について 

f:id:t_komiya:20190407170922p:plain

HDDについては、ストレージとしてのトータル容量になります。ここではReplication Factorにより容量が大きく変わるので要注意です。

また、お客様の要件によっては圧縮・重複排除を利用するか否かを判断する必要があります。

SSDおよびHDDの考慮点を全体的に言えることとしては、容量全体の閾値は約75%~80%でもっておくとよいでしょう。それ以上の容量で利用するとパフォーマンスが劣化することがありますので、その時はノード増設を行えるようにPrism側でアラート上げる設定を行っておく必要があります。

8.Storage Capacity Calculator

f:id:t_komiya:20190407171554p:plain

f:id:t_komiya:20190407171614p:plain

最後のNutanix Sizerで出力したデータを少し紹介します。

先ほどの章でお話したSSDの項目について、CVMのオーバーヘッドの内容でコメントをつけておきました。

 

是非ワークロードを意識してNutanixをサイジングしていくように心がけていきましょう。

 

よろしくお願い致します。

マルチクラウドのDaaSプラットフォーム ~Nutanix Xi Frameについて~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。
本日はマルチクラウド環境でDaaSプラットフォームを実現するNutanix Xi Frameについてご説明したいと思います。
こちらは、HCIのプラットフォームとは違い、クラウドサービスの内容になります。そのため、提供形態は月額もしくは時間単位の課金になります。
まず、Xi Frameとはどのようなものか説明したいと思います。

Xi Frameは以下のようなものです。
ブラウザを使用して任意のデバイス上のユーザーに Windowsアプリケーションとデスクトップを配信する安全なクラウドプラットフォーム
今までのDaaSは提供するまでに、システムの構築・ワークロードの構築に時間がかかり、接続するPCの構成や利用者のマニュアルなどを作成したり構築までに非常に時間がかかります。また構築が終わったあとも起動時間が遅い、使い勝手が悪い、USBが使えない、アプリがインストールできないなど従来のPCで利用していたものに比べてユーザーエクスペリエンスが良いものではないケースもあります。
Xi Frameはブラウザを利用してクラウド上のデスクトップ環境を利用させることにより、セキュアで使い勝手の良いDaaS環境を実現しています。

1.なぜFrameが必要なのか?

f:id:t_komiya:20190404211232p:plain

従来型のHCI環境のVDI環境はNutanixの1クリックでデプロイできる環境(Calmなどを利用)が構築できますが、マルチクラウドの環境でそれができれば好きな時に好きな環境でデスクトップ環境が構築できるようになります。その最適なプラットフォームがXi Frameになります。(イメージを参照)
Xi Frameを利用してダッシュボードから1クリックでデスクトップ環境をできるようになります。
2.Nutanix Xi Frameの機能

f:id:t_komiya:20190330234642p:plain

Xi Frameの機能についてご説明します。HTML5やH.264などの言語やコーデックに対応しており、ブラウザも多種に対応しています。仮想デスクトップおよびアプリケーション仮想化にも対応しています。またクラウド上で対応しているかの話になりますが、GPUにも対応しており、AWSおよびAzureなどのクラウドにも対応しています。

f:id:t_komiya:20190330235350p:plain

f:id:t_komiya:20190331001424p:plain

ワークスペースの配信が1クリックで行うことができ管理がシンプルになっています。ブラウザアクセスで利用できることからクライアント側のプラットフォームに柔軟に対応できます。また、クラウドストレージサービスとの親和性も高く、Xiクラウドを含めパブリッククラウド上にデスクトップが展開できることが特徴です。
3.エンタープライズ対応のデスクトップとしてのサービス

f:id:t_komiya:20190330235659p:plain

マルチクラウドにデスクトップが展開できると言っても、セキュリティが担保されていなければ何も意味がありません。Xi Frameは簡素化した管理だけでなく、セキュリティ対応としてユーザー認証はもちろんのことSOC-2、FedRAMP、FIPSなどのセキュリティにも対応しています。こちらはあくまで米国基準のセキュリティであるため、日本での対応については、別途確認が必要になります。
4.オンデマンドでの容量のモニタリング・自動スケーリング

f:id:t_komiya:20190331000412p:plain

マルチクラウドでデスクトップを利用することは良いが、リソースの監視およびリソースのスケーリングはどうするのかと思うことがあります。Xi Frameは週次の利用率をモニタリングすることができます。また、オンプレミスのVDIなどではピーク時のトラフィックを見積もった上でシステムを構築する必要がありますが、Xi Frameの場合はその必要がありません。そのため、インフラを瞬時に拡張し時には縮小することが容易にできる柔軟性を備えております。
5.Frameの特徴

f:id:t_komiya:20190331001424p:plain

Xi FrameはマルチクラウドでDaaSを利用できるとお話しましたが、普通にRDPを利用してデスクトップを使用するとプロトコルのオーバーヘッドが大きくなり最適化したものではありません。Frameは元々ブラウザへのビデオストリーミングの開発を行っており、H.264ベースのコーデックに対応したQoSを提供して、WANおよび低帯域のネットワークにも対応できるようになっています。また、通常のPCで要求されるような要件(イメージを参照)にも数多く対応しています。
6.Frameが提供するデスクトップ管理の簡素化

f:id:t_komiya:20190331002319p:plain

Xi Frameを利用する際、どのようにシステム実現するか検討する必要があります。
1.インフラの選定(オンプレミス・クラウド)
2.利用するアプリケーション
3.ユーザーの認証方法
4.利用するファイルサーバー
5.利用する端末
これらの要件を決めていく必要がありますが、難しいシステム設定は必要ありません。クライアントの目線からデスクトップを利用することを考えればよいのです。
今までVDI導入でクラウドを利用することをためらっていた管理者もいらっしゃるかと思いますが、このXi Frameを利用することにより、ユーザーエクスペリエンスの高いDaaS環境を提供することができます。管理者はむしろクライアントの管理の方に目を向けてシステムの管理部分については、クラウドやXi Frameの機能で統合してみてはいかがでしょうか。

また、こちらのFrameはロケーションに関係なくストレスに利用できます。
実際に日本のNutanixのSEさんがFrameを新幹線の中で利用した動画がYoutubeにアップロードされておりますので、是非参考に見て頂ければと思います。

youtu.be


よろしくお願い致します。