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のデータ保護に関する説明になります。

よろしくお願いします。

Nutanixのデータ保護について(その 1)

みなさん、こんにちは

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

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

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

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

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

１．Site Failover Operations

サイトがフェイルオーバーした時のオペレーションのことを考えてみましょう。

まず、スナップショットとレプリケーションのスケジュールを設定した後で、あるサイトから別のサイトにフェイルオーバーする必要があるかもしれません。 3つのフェイルオーバーシナリオが可能です。

計画的フェイルオーバー︓

両⽅のサイトが稼働していて、その構成が正しく機能することをテストしたい場合、または1次サイトの計画的保守またはサイト拡張の前にフェイルオーバーします

災害時フェイルオーバー︓

プライマリサイトが停⽌したときのフェイルオーバー

フェイルバック︓

システム停⽌を解決してプライマリサイトに戻したい場合に、復旧サイトから計画的フェイルオーバーを開始します

2．計画的なフェイルオーバーもしくはフェイルバック

この操作は以下のことを行います。 

• 保護ドメインのスナップショットを作成して複製します。 
• ローカルサイトのVMをシャットダウンします。 
• 保護ドメインの別のスナップショットを作成して複製します。 
• すべてのVMの登録を解除し、それらに関連付けられているファイルを削除します。 
• ローカルサイト保護ドメインを非アクティブとしてマークします。 
• 最後のスナップショットからすべてのVMファイルを復元し、それらをリモートサイトに登録します。 
• リモートサイト保護ドメインをアクティブとしてマークします。 

３．災害時フェイルオーバー/保護ドメイン

災害時フェイルオーバー操作は以下のことを行います。 

• 最後の完全複製スナップショットからすべてのVMファイルを復元します。
• 復旧サイトにVMを登録します。
• フェールオーバーサイト保護ドメインをアクティブとしてマークします。

保護ドメイン変更操作は以下のことを行います。 

既存の保護ドメインを変更するには、ドメインモードの変更（アクティブ/非アクティブ）、ドメインの複製、ドメインの移行、ドメイン設定の更新、またはドメインの削除を行います。 

４．保護ドメインのガイドライン

メトロアベイラビリティポリシーを適用するための一般的なガイドライン

保護ドメインは、ローカルクラスタ上のプライマリストレージコンテナと、リモートクラスタ上の同じ名前のスタンバイストレージコンテナを指定することによって作成されます。以下は、メトロアベイラビリティを適用するための設定とガイドラインです。 

• ストレージコンテナをメトロアベイラビリティで使用する場合、データストア名はストレージコンテナ名と同じである必要があります。 
• 2つのサイトにわたるデータストアの可用性を確保するには、両方のサイトにリアルタイムでデータが存在する必要があります。したがって、クラスタ間のラウンドトリップレイテンシは5ms未満である必要があります。
• ピーク書き込みに対応するために十分な帯域幅を維持します。サイト間に冗長な物理ネットワークを用意することをお勧めします。 
• 特定のVMに関連付けられているすべての仮想ディスクが、メトロアベイラビリティが有効になっているコンテナに存在することを確認します。 
• 保護されたVMは、アクティブストレージコンテナに関連付けられているNutanixクラスタまたはスタンバイストレージコンテナに関連付けられているクラスタのどちらでも実行できます。ただし、スタンバイストレージコンテナに関連付けられているクラスタ上でVMが実行されていると、アクティブストレージコンテナへのネットワークを介して読み取りと書き込みが行われます。したがって、ネットワークトラフィックとそれに関連するネットワークの待ち時間を減らすために、VMのデータが存在するアクティブコンテナに対してVMのデータがローカルに実行されるアクティブコンテナに対してVMをローカルに実行することをお勧めします。 
• メトロアベイラビリティポリシーはストレージコンテナ（クラスタではなく）ごとに適用されるため、クラスタはあるデータストアに対してアクティブで、別のデータストアに対してスタンバイになることができます。たとえば、ストレージコンテナ1にOracleデータストア（データストアA）、ストレージコンテナ2にExchangeデータストア（データストアB）を持つクラスタ構成を考えます。クラスタAはデータストアAに対してアクティブで、クラスタBはスタンバイです。データストアBに対してアクティブで、クラスタAをスタンバイにします。さらに、メトロアベイラビリティのストレージコンテナは、同じクラスタ内の通常のストレージコンテナと共存できます。 

５．VMセントリックのデータ保護

AOSは、ネイティブのオンサイトバックアップと、オフサイトバックアップおよびディザスタリカバリ用のリモートレプリケーションの両方に統合データ保護ソリューションを提供します。

これらの機能は、スナップショットがソースVMと同じクラスターに格納されるタイムストリームと、スナップショットがクラスター間で非同期に複製されるサイト間レプリケーションの2つのユースケースで使用できます。 

VMのスナップショットはクラッシュコンシステントです。つまり、VMDKのオンディスクイメージは一時点で一貫性を保っています。つまり、スナップショットはVMがクラッシュしたかのようにディスク上のデータを表します。状況によっては、スナップショットもアプリケーションと整合性があります。

つまり、スナップショットの時点でアプリケーションデータが静止します。アプリケーション整合性のあるスナップショットは、ESXiハイパーバイザーによってホストされているVMにインストールできる一連のユーティリティであるVMware Toolsを介して適用されます。この機能はVSSを起動してVM用のアプリケーション整合性のあるスナップショットを作成します。これは単一のVMを持つ整合性グループに限定されます。

スナップショットは、定義されたスケジュールまたは必要に応じて作成できます。作成されたすべてのスナップショットは有効期限に関連付けられており、有効期限が過ぎるとNutanixクラスタは自動的にスナップショットを削除します。重要ではないVMファイル（スワップファイルやログファイルなど）はスナップショットに含まれません。 

６．データ保護の概念

データ保護に関してはこちらのような概念があります。それぞれに関しての説明を行いたいと思います。

• 保護ドメイン

保護ドメインについては⾮同期DRとMetroAvailabilityの2種類でドメインが存在することを覚えて頂ければと思います。

保護ドメイン（非同期DR）：標準保護ドメインは、クラスター上でローカルにバックアップされ、オプションで1つ以上のリモートサイトに複製された定義済みのVMのグループです。このタイプの保護ドメインは、スナップショットを作成するために非同期データ複製Async D）を使用します。

保護ドメイン名はサイト間で一意である必要があります。 VMは最大1つの保護ドメインに属することができます。クラスタ上の保護ドメインは、次の2つのモードのいずれかにあります。 

アクティブ：稼働中のVMを管理します。スナップショットを作成、複製、およびExpireします。 

非アクティブ：リモートクラスタからスナップショットを受け取ります。 

保護ドメイン（メトロ可用性）：メトロ可用性保護ドメインは、メトロ可用性が有効になっているときに同期データ複製が行われるリモートサイトの同じ名前の（スタンバイ）コンテナにリンクされたローカルクラスタの指定（アクティブ）コンテナで構成されます。 

• 整合性グループ

整合性グループは、保護ドメイン内のVMのサブセットです。 （保護ドメインを作成するときに整合性グループが構成されます）。その保護ドメインのコンシステンシグループ内のすべてのVMは、クラッシュコンシステントな方法でスナップショットを取られます。コンシステンシグループ内のすべてのVMに対して、スナップショットはグループ内のすべてのVMに対して1つのスナップショットを作成します。 

データ保護を⾏う上で重要なのは、スナップショットを取ったデータが整合性を保っていることが重要です。リストア後に整合性が保った状態に戻すのはアプリケーション次第ではあるが、クラッシュコンシステントのバックアップで停電後でも仮想マシンの電源⼊れている状態に戻せるようにしておきましょう。仮想マシンには必ずNGT（Nutanix Guest Tools）を⼊れておきましょう。

• スナップショット

スナップショットについては、特に説明する内容はほとんどないので、画⾯イメージを載せておきます。

• タイムストリーム

タイムストリームについても、スナップショットと同様のお話ですので、画⾯イメージを掲載のみです。

• タイムストリーム

リモートサイトは、バックアップデータを複製するためのターゲットの場所として使用される独立したクラスタです。リモートサイトは、別の物理クラスタまたはパブリッククラウドにあるクラスタのどちらでもかまいません。 1つのクラスタに1つ以上のリモートサイトを設定できます。 

• レプリケーション

レプリケーションとは、スナップショットを1つのクラスタから1つ以上のリモートサイトに非同期的にコピーするプロセスです。いくつかのレプリケーションシナリオがサポート

レプリケーションについては、１つもしくは複数サイトにレプリカを作成することができます。注意事項としては、マルチサイトで複製取る場合には、ライセンスのエディションにご注意下さい。（UltimateもしくはPro Edition選択時はオプションのライセンスが必要になります）

• スケジュール

スケジュールは、スナップショットをとる間隔とスナップショットを保持する期間を指定する保護ドメインの特性です。 （保護ドメインを設定するときにスケジュールが設定されます）。スケジュールは、どのリモートサイトに複製するかをオプションで指定します。 

スケジューリングについては、⾮同期DRについては間隔が短い場合はNear Syncになりますので、その場合は仕様も含めて確認してから設定してください。

本⽇のデータ保護の説明は以上とさせて頂きます。

次回は、複製の⽅式についてご説明したいと思います。

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

Nutanixにおけるハイパーバイザーの変換プロセスについて

みなさん、こんにちは

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

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

今回はNutanixのハイパーバイザーの変換プロセスについてご紹介します。

NutanixではハイパーバイザーをESXiからAHVへの変換することができます。

ハイパーバイザーを変換する際のプロセスがいくつかあるので覚えて頂ければと思います。

1. ESXiからAHVへの変換について

変換プロセスを開始すると、クラスタ内のすべてのノードが1つずつAHVに変換されます

ESXiホストの現在の状態は、ESXiに戻すために保存されます。Foundation内部でESXiホストをAHVに変換します

最初に、すべてのコントローラーVMがAHVに移行されます。コントローラVMがAHV側で起動した後、ESXiで実行されているVMはAHVに移行されます

仮想マシンの移行が完了したら、AHVで仮想マシンを手動で起動する必要

すべてのホストと仮想マシンがAHVに移行されたら、AHVクラスターの使用を開始します。

2. 仮想マシンの変換

ハイパーバイザーの変換ということはつまり仮想マシンも変換することになります。

そのため、仮想マシンにNGT（Nutanix Guest Tools）をインストールして変換を開始すると、仮想マシンの変換も同時に行われます。変換プロセスは以下のようになります。

①検証

クラスタ内の仮想マシンが変換可能かどうか検証します。

②起動

変換を⾏います。変換のプロセスは記録されます。

③仮想マシン変換ためのノードを準備

ノード内の仮想マシンの情報はノードのUUIDに応じて収集され、仮想マシンが保護されているときには変換はできません。仮想マシンはマスター変換レコードに格納されていて、仮想マシンファイルは変更されません。

④仮想マシンの変換を実⾏

ノードの変換レコードを参照して、ハイパーバイザータイプを⽐較して、変換先のハイパーバイザーに変換します。仮想マシン変換後は仮想ネットワークなどもハイパーバイザーの情報に合わせて変換を⾏います。変換が完了すると変換元の仮想マシンファイルは削除されます。

3. ポートグループとVLANの変換およびAHVからESXiへの変換について

ポート仮想マシン変換ためのノードを準備

特定のグループに属するすべてのESXiポートグループ、すべてのVLAN ID、および仮想マシンがキャプチャされ、クラスタ上のすべての一意のESXiポートグループに対応するAcropolis仮想ネットワークが作成され、対応するVLAN IDが割り当てられてからVM正しい仮想ネットワークに転送されます。 

ESXiホストの管理ポートグループにVLANが設定されている場合は、変換後にAcropolis管理インターフェースとController VMパブリックインターフェースが同じVLANに配置されます。 

AHVからESXiへの変換プロセス

逆方向の変換（AHVからESXiへの変換）の間、変換のプロセスは類似しています。

また、クラスタにESXi ISOが保存されていない場合は、変換プロセス中にESXi ISOイメージを提供する必要があります。

注：提供するイメージは、ESXiからAHVへの変換中に使用したものと同じ主要なESXiバージョンのものである必要があります。

４. クラスタ変換作業の中止について

クラスタ変換作業も必ず成功するわけではありません。失敗してしまった時に戻せなくなるのではないかと⼼配する⽅もいらっしゃるかと思いますが、Nutanixの変換作業で失敗したときは失敗した内容のポップアップが表⽰されます。こちらで元の環境に戻すかどうか聞かれるので、「Yes」をクリックすると元の環境に戻すことが可能です。

ハイパーバイザーの変換は通常の変換作業以外にも、DR先にレプリケーションする時もクロスハイパーバイザーでDRするときも同様のことが⾏われます。

以上、参考情報として読んで頂ければと思います。

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