2021年7月20日火曜日

NutanixのLCM(Life Cycle Management)について

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのLCM(Life Cycle Management)についてご紹介します。

まずは、LCMとは何か︖ということをお話します
LCMの役割はNutanixのクラスタ内のすべてのエンティティ(構成要素)のソフトウェアとファームウェアのバージョンを管理するものです。
単にファームウェアを管理するだけなら普通にできるのではと思いますが、これが重要
なのはNutanixで特徴である1クリックアップグレードの要素の⼀つになっています。つまり1クリックアップグレードはこのLCMの機能で成り⽴っているといっても過⾔ではありません。

それではLCMの仕組みについて、説明していきたいと思います。

1. 従来型の1クリックアップグレード
従来型の1クリックアップグレードの場合、AOSをアップグレードする際にアップグレードするタイプを選択し、メタデータとイメージをアップロードします。その後アップデートをクリックするとアップグレードは始まります。

今まではNutanixは単独のプラットフォームであったことから特に問題はありませんでしたが、今後は他のハードウェアベンダーや様々なデバイスが出てくることもあり、それらのプラットフォームにも1クリックアップグレードが対応する必要があり、そのためにLCMのインターフェースを変更するがあります。

2. なぜインタフェースを変更する必要があるのか?
こちらのイメージはNutanixをご存じな⽅は⾒たことがあると思いますが、今後Nutanixは様々な規模での展開、プラットフォーム、アップグレードする要素が多様化することを⽰しています。
これらを今までアップグレードするときにはそれぞれ個別のオペレーションが必要であり、依存性も管理されておらず、中にはパフォーマンスに悪影響を及ぼすものもあります。

3. 従来のオペレーティングシステムの更新
例えば、Linuxなどを例に挙げてみると、パッケージをアップデートする際にはyumコマンドで⼀発でできるようになっています。これがNutanixの場合はどうなっているのか︖GUIで1クリックでアップデートできるようになっているのがNutanixユーザの理想だと思います。

4. Cloud OSのアップデート
こちらはPRISM上のLife CycleManagementの画⾯をキャプチャしたものです。GUIでアップデート可能で、これが1クリックアップグレードできるようになれば良いことです。

5. LCMのアーキテクチャ


LCMのアーキテクチャを図式化してみました。こちらはNXをベースにしておりま
す。AOS、ハイパーバイザーおよびその他の機能がLCMとクラスタ内のCVMが連携して(ローリング)アップデートを⾏います。もちろん、こちらはPRISM Centralからもアップデートが可能になっています。


LCMのRepositoryの構造になります。アップデートを⾏う際にアップデート対象
のリストが必要になります。そのリストをもとにどのモジュールをアップデート
するのかということでリストに書かれたモジュールをアップデートする際にダウ
ンロードを⾏います。AOS、AHVなどの関連モジュール以外にそれぞれのハード
ウェアメーカー毎のモジュールもダウンロードします。

6
. 現状のLCMの機能について
現状のLCMの機能について、最後にコメントします。
このLCMでアップデートする際に、他のホストに仮想マシンをvMotionしたり、ローリングアップグレードで各ホストを再起動してくれます。
また、複数のコンポーネントが選択されている場合はその依存関係もチェックした上で正しい更新順序でアップグレードを⾏います。
ダークサイト(インターネットがつながらない環境)下でもアップグレードできるようにインタフェースを持っています。(オフラインでのアップグレード)

是⾮試してみてはいかがでしょうか。検証環境をお持ちの⽅は気軽にやってみましょう。

よろしくお願いします。





2021年7月19日月曜日

AHVのネットワーク設定について(その2)

みなさん、こんにちは


本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

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

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

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

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

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

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

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

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

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

4. AHVにおける仮想ネットワークについて
AHVでは、vDS(分散スイッチ)と同様の機能が標準で利⽤できるようになっています。しかもそれが⾃動管理で利⽤できるようになっています。
そもそもNutanixについては、VMwareのように歴史が古いわけではありません。1Gのネッ
トワークできめ細かにネットワークのサイジングをやっているVMwareに⽐べて、Nutanixは10GのネットワークでそのネットワークでvLANなどを設定して細分化するような形になっていることから、逆にネットワークが簡素化された状態で設定できるようになっています。
そのため、仮想マシンの作成時にvLANを設定するとそれをすべての仮想スイッチに分散して設定できることから、各社のスイッチなどでvLAN設定の⾃動化追加のソリューションなどにも対応できるようになっています。

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

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

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

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

2021年7月18日日曜日

AHVのネットワーク設定について(その1)

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

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

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

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

2.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ホスト、仮想マシン、および物理インターフェイスは、ブリッジへの接続に「ポート」を使用します。

4.ポート
ポートは、仮想スイッチへの接続を表すブリッジ内に作成された論理構造です。 
Nutanixは、internal、tap、VXLAN、bondなど、いくつかのポートタイプを使用します。 

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

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

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

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


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

7.ネットワーク設定におけるベストプラクティス
ベストプラクティス内容については、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のネットワークを設定する前に是⾮注意事項として覚えて頂ければ幸いです。

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






2021年7月17日土曜日

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

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

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

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

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

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

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

2.構成変更不可のコンポーネント
ここにリストされているコンポーネントは、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の移行、状態の保存、またはチェックポイントの取得

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

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

2021年7月16日金曜日

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

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

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

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

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

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

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

インラインの圧縮︓
データが書き込まれる際に圧縮されます
このタイプの圧縮は、バッチ処理を実⾏するほとんどのワークロードに推奨

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

3. 重複排除(Deduplication)
重複排除については、リードキャッシュ⽤の重複排除と容量削減⽤の重複排除の⼆つがあります。どちらの機能を利⽤するかは、購⼊するエディションにも依存するので注意してください。
さらに、重複排除が有効になっているクラスター内のコントローラーVMは、追加のRAMで構成する必要があります。
  • キャッシュ重複排除︓24GB RAM
  • 容量重複排除︓32GB RAM
重複排除についてもベストプラクティスがあります。データの特性やワークロードにより、使⽤しても意味がない場合がありますので、⼗分に注意して利⽤してください。

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

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

2021年7月15日木曜日

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の作成と管理はクラスターによって⾃動的に処理されます。

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

3. データストア/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も同じ割合で追加され、予測可能でスケーラブル、そしてリニアなパフォーマンスを提供します。スケールアウトアーキテクチャにより、予測可能な高いストレージパフォーマンスが可能になります。

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










2021年7月14日水曜日

異なるハイパーバイザー間のDR(Cross Hypervisor)

 みなさん、こんにちは


本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

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

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

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

2.小規模構成の問題点やWAN回線の問題点をNutanixが解決
リモートオフィスでの環境で問題となることは、まずシステム構成とWANの回線などに関する内容です。リモートの拠点では基本的に⼩規模構成でシステムを組まれることが多くなります。2台くらい⼩規模も組まれることを考えると、先⽇ご紹介したWitness VMなどを構成してシステムを組むことがあります。Nutanixでは1台のWitnessサーバーで複数拠点の管理も可能になります。
また、WANについて要件も完全同期のソリューションでなければ、WAN回線の速度やレイテンシなどの要件も厳しいものはございません。そのため、DRの要件がある場合はNutanixソリューションを考えてみるのは良いかと思います。

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

4.Cross Hypervisor DR(CH-DR)について
異なるハイパーバイザー(CrossHypervisor)間のDRについてですが、Nutanixでなければできない機能ではありません。実際に他社のソフトウェアでもESXi 〜 Hyper-V間の異なるハイパーバイザーでのDR環境を提供できるプラットフォームはすでにあります。
Nutanixはそれを追加コストがかけることがなく実現することができます。(ESXi 〜 AHV もしくは AHV 〜 ESXi)
これを実現することにより、例えばエッジに近いお客様がESXiでしか認定されていないアプリケーションを利⽤してシステムをESXiで導⼊した場合、他の拠点でのハイパーバイザーまで同⼀のものにしなければいけないかというお話です。データの保護だけがしっかりできていれば、別に異なるハイパーバイザーでも問題ないと考えます
その時に異機種間のDRプラットフォームを利⽤することでシステムが効率化することもあります。このように柔軟にプラットフォームを選択することでシステム運⽤を簡素化することができます。
【CH-DRはデータの保護は⾏いますが、異なるハイパーバイザーになるため、動的なワークロードの移⾏(vMotionなど)はサポートしていません】

5.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・セキュアブートの要件もこちらのイメージを見て頂ければと思います。

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


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

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

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

8.マルチパス用のデバイスのブラックリスト
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を再起動します。


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