AHVのネットワーク設定について（その２）

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はAHVの仮想ネットワーク設定についてご紹介します。

仮想環境を構築するときに、仮想マシンが通信するネットワークを設定すると思います。今回はVMwareでの設定における内容とAHV上でどのように管理させるのかをご説明したいと思います。

まずは、VMwareで仮想ネットワークを設定する場合について、ご説明したいと思います。

1. 仮想スイッチについて（Standard Editionの場合）

ESXのホスト上で仮想スイッチの設定する場合には、すべてのESXホストで同⼀の設定にする必要があります。

⼀つのホスト上に物事が完結するのであれば特に何も気にすることはありませんが、例えば仮想マシンをvMotionで他のホストに移動させる場合、移動先のホストで仮想マシンが接続する仮想スイッチが同じような設定がされていない場合、vMotionは失敗します。ESXのホストが台数が少なければ、まだ設定の修正をするのに時間はかかりませんが、台数が多い

場合には⾻が折れるような作業になります。

これを回避するために、すべてのホストの仮想スイッチ統合する機能として、分散スイッチ（Distribution Switch）を利⽤することがあります。これを利⽤することにより、すべてのホストの仮想マシンにポートを割り与えられ、アップリンクポートからどの物理ホストに割り振るかを設定することで、ホストを跨いだスイッチの管理ができるようになります。

２. 仮想スイッチについて（Enterprise Editionの場合）

設定についてはvCenterで簡単にできるようになっていますが、どのように仮想マシンを管理するのかを図式化しておかないと、管理者が変わる際にすぐに理解できないと思いますので、そのあたりは注意が必要です。

今お話した分散スイッチですが、標準で利⽤できるものではありません。⼩規模のユーザではスイッチの管理も難しくはないので、VMwareのライセンス体系では上位エディションに⾷い込まれています。

３. vSphereのライセンスについて

⼤規模（データセンター系）のお客様に⾮常に効果的なソリューションであると思います。⾮常に便利なこちらの機能ですが、NutanixのハイパーバイザーであるAHVではどうなっているでしょうか。

４. AHVにおける仮想ネットワークについて

AHVでは、vDS（分散スイッチ）と同様の機能が標準で利⽤できるようになっています。しかもそれが⾃動管理で利⽤できるようになっています。

そもそもNutanixについては、VMwareのように歴史が古いわけではありません。1Gのネッ

トワークできめ細かにネットワークのサイジングをやっているVMwareに⽐べて、Nutanixは10GのネットワークでそのネットワークでvLANなどを設定して細分化するような形になっていることから、逆にネットワークが簡素化された状態で設定できるようになっています。

そのため、仮想マシンの作成時にvLANを設定するとそれをすべての仮想スイッチに分散して設定できることから、各社のスイッチなどでvLAN設定の⾃動化追加のソリューションなどにも対応できるようになっています。

AHVであれば、先ほどお話したvMotionなどが失敗するような設定漏れなどもなくなります。

５.ネットワークインフラの可視化

また、NutanixのAHVでの仮想ネットワークには可視化する機能もあります。仮想マシンからどのホストのインタフェースからどのネットワークスイッチに接続しているのがすぐにわかるようになっています。また、ホスト上のBond設定についてもGUIで確認できるようにもなっているため、⾮常に使いやすくなっています。

ひと昔前まではAHVは「タダだけど、機能は限定されているからあまり使い物にならない」という話でしたが、ようやく機能も出揃ってきており、ここまで使えるのか︕というレベルにまで来ております。画⾯イメージでこだわりを持たれる⽅もおられると思いますが、機能⾯で簡素化を望まれる⽅は是⾮検討してみてはいかがでしょうか。

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

AHVのネットワーク設定について（その１）

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はAHVのネットワーク設定についてご紹介します。

１．AHVのネットワーク概要

AHVはOpen vSwitch（OVS）を使用して、CVMとハイパーバイザーおよびゲストVMを相互に、および物理ネットワークに接続します。 OVSサービスは各AHVノードで実行され、OVSサービスは自動的に起動します 

それでは、AHVのネットワークを把握する上でそれぞれのコンポーネントについて説明します。

２．Open vSwitch

Open vSwitch（OVS）はLinuxカーネルに実装され、マルチサーバー仮想化環境で動作するように設計されたオープンソースソフトウェアスイッチです。デフォルトでは、OVSはMACアドレス学習テーブルを管理するレイヤ2学習スイッチのように動作します。ハイパーバイザーホストと仮想マシンはスイッチの仮想ポートに接続します。 NutanixはOpenFlowプロトコルを使用してOpen vSwitchの設定と通信を行います。 

各ハイパーバイザーはOVSインスタンスをホストし、すべてのOVSインスタンスが組み合わさって単一のスイッチを形成します。一例として、次の図は2つのハイパーバイザーホストで実行されているOVSインスタンスを示しています。 

3．ブリッジ

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

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

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

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

４．ポート

ポートは、仮想スイッチへの接続を表すブリッジ内に作成された論理構造です。 

Nutanixは、internal、tap、VXLAN、bondなど、いくつかのポートタイプを使用します。 

• 内部ポート　ー　デフォルトブリッジ（br0）と同じ名前で ー AHVホストへのアクセスを提供します
• タップポートは、仮想マシンに提供される仮想NICのブリッジ接続として機能します
• VXLANポートは、Acropolisが提供するIPアドレス管理機能に使用されます
• ボンドポートは、AHVホストの物理インターフェースにNICチーミングを提供します

５．ボンド

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

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

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

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

６．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が削除されるまで、アドレスはプールに解放されません。 

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

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

Open vSwitch

デフォルトのOVSブリッジbr0に関連付けられているOpenFlowテーブルを変更しないでください。 

1GbEおよび10GbEインタフェース

ゲストVMトラフィックに10GbEインターフェイスを使用する場合は、ゲストVMがコントローラVMとハイパーバイザーの通信に使用するVLANを使用していないことを確認してください。 

ゲストVMの接続に1GbEインターフェイスを使用する場合は、ハイパーバイザー製造元のスイッチポートとネットワーク構成のガイドラインに従ってください。

1GbEインターフェイスを10 GbEインターフェイスと同じボンドに含めないでください。
また、ループを回避するために、1 GbEインターフェイスをブリッジbr0に個別にまたは2番目のbondで追加しないでください。他のブリッジでそれらを使用してください。 

VLAN

コントローラーVMとAHVを同じVLANに追加します。デフォルトではコントローラVMとハイパーバイザはVLAN0に割り当てられており、上位の物理スイッチに設定されているネイティブVLANに配置されます。

コントローラVMとハイパーバイザーホストが割り当てられているVLANに、ゲストVMを含む他のデバイスを追加しないでください。ゲストVMを1つ以上の別々のVLAN上で分離します。 

上位の物理スイッチ

Nutanixは本番のユースケースではFabric Extender（FEX）または同様のテクノロジの使用をお勧めしません。初期段階では、このようなテクノロジでは低負荷の実装がスムーズに実行される可能性があり、実装の規模が大きくなるにつれて、パフォーマンスの低下、VMの参照などの問題が発生する可能性があります。 

Nutanixは本番ワークロード用により大きなバッファを備えた10Gbps、ラインレート、ノンブロッキングスイッチの使用を推奨しています。 低遅延のカットスルー設計を持ち、パケットサイズ、トラフィックパターン、または10GbEインターフェイスで有効になっている機能に関係なく、予測可能で一貫したトラフィック遅延を提供する802.3-2012規格準拠のスイッチを使用します。ポート間レイテンシは2マイクロ秒以上にする必要があります。 

ハイパーバイザーホストに接続されているスイッチポートでは、

高速コンバージェンステクノロジー（Cisco PortFastなど）を使用してください。

仮想ブリッジ

OVSブリッジbr0を削除または名前変更しないでください。 

ネイティブのLinuxブリッジvirbr0を変更しないでください。 

ハイパーバイザーホストのIPMIポート

IPMIインターフェイスに接続するスイッチポートをトランクしないでください。 管理を簡単にするために、スイッチポートをアクセスポートとして設定します。

Controller VM

Contoller VMをOVSブリッジbr0またはネイティブLinuxブリッジvirbr0から削除しないでください。 

ポートがボンド化されたOVS(bond0)

物理ホスト上の10GbEインターフェースをデフォルトのOVSブリッジbr0上のOVSボンディングに集約し、これらのインターフェースを物理スイッチ上でトランキングします。

デフォルトでは、OVSボンディングの10GbEインターフェイスは推奨されているアクティブバックアップモードで動作します。 LACP設定は機能することが知られていますが、サポートが制限されている可能性があります。

物理ネットワークのレイアウト

従来のリーフスパインアーキテクチャでは、冗長なトップオブラックスイッチを使用してください。このシンプルでフラットなネットワーク設計は、高度に分散された

シェアードナッシングコンピューティングおよびストレージアーキテクチャに最適です。 特定のクラスタに属するすべてのノードを同じレイヤ2ネットワークセグメントに追加します。 他のすべてのNutanix推奨事項にサポートしている限り、他のネットワークレイアウトもサポートされます。 

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

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

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

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのVLANによる仮想ネットワークセグメントおよび構成変更不可のコンポーネントについてご紹介します。

• VLANによる仮想ネットワークセグメント
• 構成不可のコンポーネント
  
  

Nutanixのネットワークを構成するときに重要なものはVLANです。VLANを利⽤した仮想ネットワークのセグメント化がわかっていないとネットワーク構成ができません。

今回はAHVホスト・コントローラーVM・仮想NICに対しての割り当てについてお話したいと思います。

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

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

Open vSwitchブリッジのポートを異なるVLANに割り当てることで、Acropolis

ノードにセグメント化された仮想ネットワークを設定できます。 VLANポートの割り当ては、各ノードで実行されているコントローラVMから設定されます。 

• 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上でのみトラフィックの送受信に戻ります。 

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

ここにリストされているコンポーネントは、Nutanixの製造時およびインストールプロセスによって構成されています。

Nutanixサポートの指示がある場合を除き、これらのコンポーネントを変更しないようにして下さい。

ここに記載されている設定を変更すると、クラスタが機能しなくなる可能性があります。特に、いかなる場合でも、ESXiの[システム構成のリセット]オプションを使用したり、NutanixコントローラVMを削除したり、バックアップのためにコントローラVMのスナップショットを作成したりしないでください。 

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の移行、状態の保存、またはチェックポイントの取得
  
  

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

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

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

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのストレージ設定（Erasure Coding/Compression/Deduplication）についてご紹介します。

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

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

イレージャーコーディング（Erasure Coding）︓

クラスタの有効容量または使⽤可能容量を増やします。Erasure Codingを有効にした後に⽣じる容量削減は、圧縮および重複排除の容量削減に追加されます

圧縮（Compression）︓

2種類の圧縮のうちの1つを可能にするオプションのコンテナ設定・ポストプロセスの圧縮︓データは書き込まれた後に圧縮されます・インラインの圧縮︓データが書き込まれる際に圧縮されます

重複排除（Deduplication）︓

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

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

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

Erasure Codingを使用すると、クラスターの有効容量または使用可能容量が増えます。 Nutanixはデータ回復力のためにデータコピーを維持します。Redundancy Factor 2を設定した場合、2つのデータコピーが維持されます。 Redundancy Factor 3を設定した場合、3つのデータコピーが維持されます。

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

例えば、4つのデータブロック（a b c d）を持つ6ノードのクラスタを考えます。 Redundancy Factor 2が設定されているため、データの2つのコピーが維持されます。 次の図では、赤色のテキストがデータコピーを表しています。

Redundancy Factor ２構成において単一ノード障害保護を保管するために、パリティ「Ｐ」およびデータブロックａ、ｂ、c、ｄが別々のノードに配置される。 パリティを使用して冗長性を実現すると、システム上の合計データが2 x（a + b + c + d）ではなくa + b + c + d + pになるため、データの再調整が行われます。 この例では、8つのデータブロックではなく5つのデータブロックがあります。 

データブロックｃを含むノードが故障した場合、データブロックｃは、ここに表示されているように、Erasure Codingされた部分の他のメンバー（ａ ｂ ｄおよびｐ）を使用することによって回復される。 次にブロックｃは、このErasure Codingされた部分の他のメンバを持たないノードに置かれる。 

2. 圧縮(Compression)

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

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

ポストプロセスの圧縮︓
データは書き込まれた後に圧縮されます書き込みと圧縮の間の遅延時間は設定可能です。

ワークロードごとに異なるI/Oプロファイルが あるため、Nutanixに推奨される遅延値はありません。このタイプの圧縮は、ほとんどのワークロードにお勧めです

インラインの圧縮︓

データが書き込まれる際に圧縮されます

このタイプの圧縮は、バッチ処理を実⾏するほとんどのワークロードに推奨

圧縮は記憶容量の使用を最適化します。この容量を最大限に活用するには、どのユースケースとワークロードが圧縮から最もメリットを得て、どの内容がコンピュートへのオーバーヘッドが圧縮に対してメリットをもたらすかを理解することが重要です。 

３. 重複排除(Deduplication)

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

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

• キャッシュ重複排除︓24GB RAM
• 容量重複排除︓32GB RAM

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

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

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

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

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixの分散ストレージファブリック(Distributed Storage Fabric)についてご紹介します。

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. ストレージのコンポーネント

ここで、各コンポーネントについての説明します。

ストレージティア

ストレージティアは利⽤可能な物理ストレージの種類を定義します。 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の作成と管理はクラスターによって⾃動的に処理されます。

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

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

vSphereで利⽤する場合はNFSもしくはiSCSIで提供されますが、通常利⽤するのはNFSの⽅が多いと思います。データをホストにローカライズすることでネットワークでのより取りを削減します。（データローカリティ）

データストアは仮想マシン操作に必要なファイルの論理コンテナです。 NutanixはストレージボリュームをvSphere内のデータストアとしてマウントするときに、iSCSIとNFSの両方のプロトコルをサポートすることによって選択肢を提供します。 NFSにはiSCSIよりもパフォーマンスおよびスケーラビリティの面で多くの利点があり、推奨されるデータストアタイプです。

NFSデータストア：
分散ストレージファブリック（DSF）はゲストVMトラフィックのデータパスをそのホストにローカライズすることで、不要なネットワークのやりとりを削減します。これにより、iSCSIとVMFSのペアリングで一般的な、リモートストレージデバイス間の不要なホップがなくなり、パフォーマンスが向上します。 vMotionおよび関連するvSphere機能（ハイパーバイザーとしてESXを使用している場合）を有効にするには、クラスター内の各ホストが同じデータストア名を使用してNFSボリュームをマウントする必要があります。 Nutanix WebコンソールとnCLIの両方に、Nutanixクラスタ内の複数のホスト上にNFSデータストアを作成する機能があります。

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

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

ローカルESXデータストアをNutanixコンテナに正しくマップするためには・NFS共有をコントローラVMのIPアドレスやクラスタの仮想IPアドレスではなく、192.168.5.2（内部IPアドレス）にマッピングします・データストア名はコンテナ名と同じにしてください

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

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

注：Nutanixストレージコンテナーを汎用のNFSまたはSMB共有として使用することはお勧めできません。 Nutanixソリューションは仮想マシンにセントリックであるため、推奨されるメカニズムはファイル共有サービスを提供する仮想マシンをデプロイすることです。 

SMBライブラリシェア：

Nutanix SMB共有の実装は、機能とパフォーマンスがvSphere構成と同等であるNFSデータストアと同等のHyper-Vです。 SMBライブラリ共有としてのNutanixストレージコンテナの登録は、単一のPowerShellスクリプト、またはVirtual Machine Manager GUIを介して実行できます。 

4. Distributed Storage Fabric

クラスタを作成したら、次のエンティティを作成する必要があります。 

• クラスタ内の全物理ディスクからなる1つのストレージプール
• プール内の空き容量をすべて使用する1つのコンテナ

すべての利用可能なクラスタストレージを含む単一のストレージコンテナは、ほとんどのお客様のニーズに適しています。セットアップ中に顧客が追加のコンテナーを要求した場合は、必要なコンテナーを作成してから、作業しているハイパーバイザーに適したものとしてそれらをマウントすることができます。 ストレージダッシュボードには、クラスター内のストレージ構成に関する動的に更新された情報が表示されます。

ストレージダッシュボードを表示するには、メインメニューの左端のプルダウンリストから[ストレージ]を選択します。 

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

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

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

異なるハイパーバイザー間のDR（Cross Hypervisor）

 みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixが提供する異なるハイパーバイザー間のDR機能のCross Hypervisor DR(以下CH-DRと省略)をご紹介します。

そもそも異なるハイパーバイザーでDRをするのはなんで？かと思う方もいらっしゃるかと思いますが、ハイパーバイザーの移行時はもちろんのこと、インフラ管理の複雑さの軽減、システム全体のコスト削減、そして動作させるワークロードの要件によってリモートオフィスの環境などを変えていく必要があるからです。

まずは、CH-DRの詳細の前にリモート環境における課題についてお話したいと思います。

１．リモートオフィスでの課題について

リモートオフィスを設備を構築する際に、データセンターと同様なシステムを組んでしまうとインフラそのものが複雑することもあります。そもそもリモート拠点に運⽤を熟知したエンジニアを配置することはコスト的に難しいです。ITインフラはそもそも誰でも運⽤できるようなものでなければ意味がありません。それに動作させるワークロードなどの要件もあり、データセンターと同様のスペックで構成することは難しいケースがあります。

しかしながら、Nutanixを利用することで、少しでもその問題点を解決することができます。

２．小規模構成の問題点やWAN回線の問題点をNutanixが解決

リモートオフィスでの環境で問題となることは、まずシステム構成とWANの回線などに関する内容です。リモートの拠点では基本的に⼩規模構成でシステムを組まれることが多くなります。2台くらい⼩規模も組まれることを考えると、先⽇ご紹介したWitness VMなどを構成してシステムを組むことがあります。Nutanixでは1台のWitnessサーバーで複数拠点の管理も可能になります。

また、WANについて要件も完全同期のソリューションでなければ、WAN回線の速度やレイテンシなどの要件も厳しいものはございません。そのため、DRの要件がある場合はNutanixソリューションを考えてみるのは良いかと思います。

3．データ保護におけるリモート・ブランチオフィスでのフルスタックソリューション

Nutanixにおけるデータ保護を考えるにあたり、クラウドを利⽤するケースもありますが、オンプレミスを前提で考えた場合、Nutanixの機能を利⽤したスナップショットを利⽤することが考えらます。このケースの場合に運⽤⾯やコスト⾯そして、ワークロードを踏まえた場合にどのようなソリューションが⼀番良いのかというと、Cross Hypervisor DRが選ばれ

ることがあります。

４．Cross Hypervisor DR(CH-DR)について

異なるハイパーバイザー（CrossHypervisor）間のDRについてですが、Nutanixでなければできない機能ではありません。実際に他社のソフトウェアでもESXi 〜 Hyper-V間の異なるハイパーバイザーでのDR環境を提供できるプラットフォームはすでにあります。

Nutanixはそれを追加コストがかけることがなく実現することができます。（ESXi 〜 AHV もしくは AHV 〜 ESXi）

これを実現することにより、例えばエッジに近いお客様がESXiでしか認定されていないアプリケーションを利⽤してシステムをESXiで導⼊した場合、他の拠点でのハイパーバイザーまで同⼀のものにしなければいけないかというお話です。データの保護だけがしっかりできていれば、別に異なるハイパーバイザーでも問題ないと考えます

その時に異機種間のDRプラットフォームを利⽤することでシステムが効率化することもあります。このように柔軟にプラットフォームを選択することでシステム運⽤を簡素化することができます。

【CH-DRはデータの保護は⾏いますが、異なるハイパーバイザーになるため、動的なワークロードの移⾏（vMotionなど）はサポートしていません】

５．Cross Hypervisor DR(CH-DR)の詳細

Cross Hypervisorディザスタリカバリ(CH-DR)は、VMの保護、スナップショットの作成、スナップショットの複製、およびその後のVMのリカバリーの保護ドメイン・セマンティクスを使⽤することによって、ある ハイパーバイザーから別のハイパーバイザー（ESXiから AHVもしくはAHVからESXi）に仮想マシンを移⾏する機能を提供します。スナップショットから。これらの操作を実⾏するには、すべてのVMにNGTをインストールして設定する必要があります。NGTは、VMの移植性に必要なすべてのドライバを使⽤してVMを構成します。ソースVMを準備 したら、それらを別のハイパーバイザータイプでリカバリできます。

6．CH-DRのUEFIおよびセキュアブートサポート

NutanixはUEFIとセキュアブートを備えたゲストVMのCHDRの移行をサポートします。Nutanixソフトウェアの最小要件やUEFI・セキュアブートの要件もこちらのイメージを見て頂ければと思います。

７．複数のSCSIディスクをオンラインにする

復旧後に複数のSCSIディスクをオンラインにする⽅法について説明します。

WindowsではSANポリシーによって、新しく検出されたディスクをオンラインにするかオフラインにするか、および読み取り/書き込みにするか読み取り専⽤にするかを決定します。ANポリシーが正しく構成されていない場合は、起動ディスクのみがオンラインになります。

ディスクがオフラインになると、パーティションまたはボリュームは使⽤できなくなり、ドライブ⽂字は割り当てられません。したがって、ディスクをオンラインにする必要があります。

複数のSCSIディスクを使⽤してVMを復旧すると⾮ブートディスクはWindowsに接続されずに表⽰されます。リカバリ後にこれらのディスクをオンラインにする必要があります。（⼿順は以下のイメージをご参照下さい）

８．マルチパス用のデバイスのブラックリスト

SCSIデバイスでマルチパスが有効になっていて、fstabにデバイス名が含まれていると/dev/sd*、VMをESXiからAHVに移⾏するときにVMが起動せず、次のようなメッセージが表⽰されます。e2fsckを使⽤中のデバイス/ dev / sd *は続⾏できません 表⽰されています。

VMを起動するには、fstabの名前を持つSCSIデバイスをマルチパスからブラックリストに登録する必要があります。 これを実現するには、コンソールでメンテナンスモードに⼊り、次の⼿順を実⾏します。

1.ルートファイルシステムをルート

（rw）としてマウント

$ mount / -o rw,remount

2.multipath.confファイルに次の⾏を追加して、問題の原因となっているデバイスをブラックリストに登録

blacklist{

devnode "^sd[a-z]"

}

3.VMを再起動します。

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

Nutanixのデータ保護について（その２）

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回は前回の投稿に続いてNutanixのデータ保護に関してご紹介します。

内容は若干長いため、2回に分けてご紹介しております。

(画像の⼀部はNutanix様の資料から拝借させて頂いております)

１．データ保護の⽅式について

データ保護の方式として代表的なものとしてレプリケーションがあります。

レプリケーションは、あらゆる企業のデータ保護ソリューションの基本コンポーネントで

あり、重要なデータとアプリケーションを確実にかつ効率的に別のサイトまたは別の

インフラストラクチャにレプリケートできるようにします。エンタープライズ

ITアーキテクトには多くのテクノロジオプションがありますが、成功したエンタープライズデータ保護イニシアチブに必要なレプリケーション機能があります。 

Nutanixのネイティブレプリケーションインフラストラクチャと管理は、現実の要件を

満たすためにさまざまなエンタープライズトポロジーをサポートします。 

それぞれのデータ保護方式について、以下にご紹介したいと思います。

２．双方向ミラーリング

すべてのサイトがアクティブトラフィックをサポートする必要がある環境では、複数のサイト間で仮想マシンの複製をミラーリングする機能が必要です。2サイトの例を挙げてみます。

サイト2は、サイト1で実行されている選択されたワークロードのターゲットとして使用されます。同時に、サイト1はサイト2で実行されている指定ワークロードのデータ保護ターゲットとして機能します。どちらの場所にもアイドルリソースはありません。

両方の場所でストレージ、コンピューティング、およびネットワーキングリソースを利用することは、将来のデータ災害の発生を見越してサーバーがアイドル状態にあるという従来のデータ保護の考え方よりも大きなメリットです。

３．１対多のレプリケーション

別のシナリオでは、複数のリモートロケーションを持つ1つの中央サイトがあるかもしれません。ティア１のワークロードがサイト1で実行され、サイト2と3がリモートバックアップロケーションとして機能する例を考えてみると、サイト1のワークロードを2箇所と3箇所の両方に複製できます。

データ障害が発生した場合、保護されたワークロードは、仮想マシン全体の可用性を高めるために、必要なレプリケーションサイトのいずれかで開始できます。

1対多トポロジは、サイト間の帯域幅を最適化するように設計することもできます。たとえば、サイト1と3の間で利用できるワイドエリアネットワーク（WAN）の帯域幅が、サイト1と2の間の帯域幅よりも大きいとします（サイト1と2は同じ都市にあり、サイト3は全国にあります）。

この場合、帯域幅を節約してパフォーマンスを向上させるために、サイト1で実行されているサイズの大きい仮想マシンがサイト2に複製されるように複製スケジュールを設定できます。同様に、小規模の仮想マシンはサイト3にバックアップされ、帯域幅の狭いリソースをより有効に活用できます。

４．多対１のレプリケーション

たとえば、ハブスポークアーキテクチャでは、サイト1と2で実⾏されているワークロードを中央 サイト3に複製できます。単⼀サイトへの複製の集中化により、地理的に分散した環境の運⽤効率が向上します。リモートオフィスとブランチオフィス（ROBO）は、多対1トポロジーの従来型の ユースケースです。

５．多対多のレプリケーション

このトポロジーは最も柔軟な設定を可能にします。ここで、IT部⾨はアプリケーションとサービスのレベルの継続性を保証するために最⼤限の制御と柔軟性を持っています。

６．データ保護のダッシュボード

データ保護のダッシュボードには、クラスター内のデータ保護の構成に関する動的に更新された情報が表⽰されます。ダッシュボードでの表⽰画⾯も含めて以下のイメージを紹介いたします。

ビューセレクタ

• 「概要」ボタンをクリックして、サマリービューにデータ保護と回復の情報を表示します
• 「テーブル」ボタンをクリックして、データ保護情報を表形式で表示します。テーブル画面はさらに保護ドメインビューとリモートサイトビューに分けられます。保護ドメイン情報を表示するにはAsync DRまたはMetro Availabilityタブをクリックし、リモートサイト情報を表示するにはRemote Siteタブをクリックします

ページセレクタ

テーブルビューでは、リモートサイトと保護ドメインはページあたり10個表示されます。リストに10項目を超える項目がある場合は、合計ページ数と現在のページのページ数とともに、左右のページング矢印が右側に表示されます。

テーブルの内容をエクスポート

テーブルビューでは、⻭⾞のアイコンをクリックしてCSVまたはJSON形式のいずれかのファイルにテーブル情報をエクスポートすることができます。プルダウンメニューから[Export CSV]または[Export JSON]を選択します。

テーブルの内容を検索

テーブルビューでは、検索フィールドに文字列を入力してテーブル内の特定のコンテンツを検索できます

７．Metro Availability Witness Option

Metro Availability構成にWitnessを追加することもできます。「Witness」とは、Metro Availabilityの設定状態を監視する特別な仮想マシンです。Witnessは別の障害ドメインに常駐し、Metro Availabilityサイト間のネットワーク障害とサイト障害を区別できる外部ビューを提供します。

Witnessの⽬的は、サイトの障害やサイト間のネットワーク障害が発⽣した場合にフェールオーバーを⾃動化することです。Witnessの主な機能は次のとおりです。（現状はESXiのみをサポート）

• サイトまたはサイト間のネットワークに障害が発⽣した場合にフェイルオーバーを決定する
• （たとえば）WAN障害のために両⽅のサイトで同じストレージコンテナーがアクティブに なっているスプリットブレイン状態を回避する
• 単⼀のストレージまたはネットワークドメインで障害が発⽣した場合の処理

Metro Availability 障害プロセス(Witnessなし)

プライマリサイトの障害（Metroストレージコンテナーが現在アクティブなサイト）またはサイト間のリンクがオフラインになった場合、Nutanix管理者はMetro Availabilityを⼿動で無効にしてリモートのターゲットストレージコンテナーを昇格する必要があります（または現在の）サイトをアクティブにします。

セカンダリサイトとの通信に障害が発⽣した場合（サイトの停⽌またはサイト間のネットワークリンクの停⽌による）、Metro Availabilityは設定に応じて次のいずれかを実⾏します（⾃動または⼿動）。

自動：指定した時間内にセカンダリサイトの接続が回復しない場合、システムは一時停止後にプライマリサイトのストレージコンテナのMetro Availabilityを自動的に無効にします

手動：システムは管理者が手動で処置をとるのを待ちます

Metro Availability 障害プロセス(Witnessあり)

Witnessを追加すると、サイトの機能停⽌やネットワーク障害が発⽣した場合にMetro Availabilityを 無効にしてストレージコンテナを昇格させるプロセスが完全に⾃動化されます。Witness機能は障害が発⽣した場合にのみ使⽤されます。つまり、Witness障害⾃体はどちらのサイトで実⾏されている仮想マシンにも影響しません。

Metro Availability 運用モード

Witnessを追加した後、3つのMetro Availability操作モード（Witnessモード（新）、⾃動再開モード、⼿動モード）から選択できます。障害シナリオに対するMetro Availabilityの応答は、選択されている 動作モードによって異なります。次の表に、動作シナリオに基づく障害シナリオと応答動作を詳しく⽰します。

Witnessの要件

Witnessを設定する際には、いくつかの要件があります。

• Witness VMには（少なくとも）以下の要件があります。

            2つのvCPU

            6 GBのメモリ

            25 GBのストレージ

• Witness VMは個別の障害ドメインに存在する必要があります。これは、各Metro Availabilityサイトからの独⽴した電源およびネットワーク接続を意味します。Witness VMは3番⽬の物理サイトに配置することをお勧めします。 このサイトでは、単⼀障害点を回避するために、サイト1と サイト2への専⽤ネットワーク接続が必要です。
• Metro Witnessとの通信はポートTCP 9440を介して⾏われるため、Witnessを使⽤するMetroクラスタ上の コントローラVMに対してこのポートを開く必要があります。
• 各Metro AvailabilityサイトとWitness VM間のネットワーク 遅延は、200ミリ秒未満でなければなりません。
• Witness VMは、サポートされている任意のハイパー バイザーに常駐することができ、NutanixまたはNutanix以外のハードウェアのどちらでも実⾏できます。
• 1つのWitness VMに複数の（異なる）Metroクラスタペアを 登録できますが、クラスタペアあたり50のWitnessed Metro 保護ドメインという制限があります。

以上がNutanixのデータ保護に関する説明になります。

よろしくお願いします。