2021年7月27日火曜日

Nutanixクラスタの正常性の確認について~Health Monitoring~

みなさん、こんにちは

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

今回はNutanixのヘルスモニタリングについてご紹介します。

まず、はじめにNutanixの正常性を確認するというが何を⾒ることができるのか︖ということをお話します。

1.ヘルスモニタリング
Nutanixはクラスターの正常性をモニターするための一連の状況チェックを行います。
  • 仮想マシン、ホスト、およびディスクの状態をホームダッシュボードに表示
  • 仮想マシン、ホスト、およびディスクの深刻度、ヘルス状態の情報をダッシュボードに表示
  • スケジュールされたヘルスチェックの頻度と実行頻度をカスタマイズ
  • Prismから直接NCCヘルスチェックを実行
  • すべてのノードとコンポーネントのログを収集

ヘルスダッシュボード
ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する更新された情報が表示します。
ヘルスダッシュボードを表示するには、メインメニューのプルダウンリストから[Health]を選択。

ヘルスチェックの設定
一連のヘルスチェックが定期的に実行され、一連のクラスタヘルスインジケータが提供され、実行する検査を指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することが可能。

NCC(Nutanix Cluster Check)の間隔の設定
NCCがPrismから指定された時間後に自動的に実行されるように設定するには、次の手順を実行。

Webコンソールを使用したチェックの実行
Prism WebコンソールのヘルスダッシュボードからNCCチェックを実行できるようになりました。すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

Webコンソールを使用したログの収集
Prism Webコンソールのダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了するとタスクダッシュボードからログバンドルをダウンロードできます。

2.ヘルスダッシュボード
ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する動的に更新された正常性 情報が表⽰されます。ヘルスダッシュボードを表⽰するには、メインメニューの左側にあるプルダウンリストから[Health]を選択します。

  • メニューオプション
    ヘルスダッシュボードには、メインメニュー以外のメニューオプションはありません
  • 画面の詳細
    ヘルスダッシュボードは3つの列に分かれています。
    • 左側の列には、各エンティティタイプ(VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタ サービス、および[構成されている場合]保護ドメインとリモートサイト)のタブが表⽰されます。各タブには、クラスタのエンティティの合計(ディスクの総数など)と各正常性状態の数が表⽰されます。タブをクリックすると、表⽰された 情報が展開されます(次のセクションを参照)。
    • 中央の列には、左側の列で選択されているものに関する詳細情報が表⽰されます。
    • 右側の列には、すべてのヘルスチェックの要約が表⽰されます。また、チェックボタン(成功、警告、失敗、無効)から個々のチェックを表⽰するオプションもあります。
    • [Summary]タブには、チェックステータスとチェックタイプに従って、すべてのヘルスチェックのSummaryが表⽰
    • [Checks]タブには、個々のチェックに関する情報が表⽰されます。カーソルを項⽬の上に移動すると、そのヘルスチェックに関する詳細情報が表⽰されます(次の図を参照)。適切なフィールドタイプをクリックして[Apply]をクリックすると、チェックをフィルタリングできます。チェック内容は以下のように分類されます。
  • ステータスでフィルタリング
    合格(Passed), 失敗(Failed), 警告(Warning), エラー(Error), オフ(Off), またはすべて(all)
  • タイプでフィルタリング
    スケジュールされていない、スケジュールされていない、イベントトリガーされている、またはすべて
  • エンティティタイプ別にフィルタリングする
    VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタサービス、またはすべて
たとえば、Failureをチェックのみを表⽰する場合は、[ Failure ]オプションを選択してチェックをフィルタします。 特定のチェックをクリックすると、中央の列に、チェックが失敗した⽇時とチェック失敗の割合の詳細な履歴が 表⽰されます。バーをクリックすると、合格と失敗の履歴の詳細グラフが表⽰されます(上図参照)。
マウスをグラフの線に沿って動かすと、その時点に関する情報が表⽰されます。

また検索ボックスに⽂字列を⼊⼒することで、特定のチェックを検索することもできます。「Action」タブにはチェックを管理し、チェックを実⾏し、ログを収集するオプションがあります。


  • フォーカスとフィルタリングのオプション
    ヘルスダッシュボードでは、さまざまなビューを通じてエンティティのヘルス情報を表示できます。左の列タブをクリックすると、そのタブが展開され、そのエンティティタイプ(VM、ホスト、またはディスク)のグループ化カテゴリが表示されます。また、中央のセクションは追加の詳細で拡張されます。チェックし右の列のタブには、そのエンティティタイプに関連するヘルスチェックを表示します。

    グループ化カテゴリをクリックすると、そのグループ化に関する詳細情報が表示されます。左側の列が 展開され、グループ化とフィルタオプションのセットが表示されます。選択したグループが強調表示 されます。そのグループをクリックすると、別のグループを選択できます。各グループエントリには、 そのグループに含まれるカテゴリの数が表示され、中央のセクションにはそれらのカテゴリに関する情報が表示されます。次の例では、ディスクストレージ階層が選択されており、そのグループには2つのカテゴリ(SSDとHDD)があります。デフォルトでは、すべてのエンティティ(この例ではすべてのディスク)が カテゴリ情報に含まれています。1つまたは複数のフィルタをクリックすると、含まれているリストを 絞り込むことができます。

    中央の列には、選択したグループ内の各カテゴリのフィールドが表示されます。各フィールドには、その カテゴリの詳細が表示されます。特定のエントリにカーソルを置くと、追加情報が表示されます。フィルタリング用のドロップダウン選択リスト(グループ化フィルタと同じ)と、情報を並べ替えるためのリストによるドロップダウンソートがあります。

    右側の列には、そのエンティティタイプに関連するヘルスチェックが引き続き表示されます。
中央の列には、ダイアグラムビューとテーブルビュー(次ページ参照)の2つの表示オプションがあります。
テーブルビューは詳細な情報を表形式で提供します。列ヘッダーをクリックしてエントリを並べ替えることができます。

中央の列には、最上部にウォッチリスト情報(「現在見ているHDD」または「現在 IOPS total DISK IOPS」)も含まれています。
ヘルスダッシュボードは、現在のウォッチリスト内のエンティティに関する情報を反映するように動的に調整されます。
この画面では、ステータス情報(中央の列)と関連するヘルスチェック(右の列)が18個のディスクを反映するように、ウォッチリスト(現在は18/18個のディスクを合計しているディスク)ですべてのディスクが選択されています。
監視リストを現在のエンティティタイプ(単一ディスクなど)または別のエンティティタイプ(ホストなど)のサブセットに変更すると、ステータス情報と関連するヘルスチェックが新しいウォッチリストに応じてカスタマイズされます。

⼀連のヘルスチェックが定期的に実⾏され、⼀連のクラスタヘルスインジケータが提供されます。実⾏する検査を 指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することができます。
クラスターヘルスチェックは、AOS、ハイパーバイザー、およびハードウェアコンポーネントを含むさまざまな エンティティをカバーします。チェックのセットはデフォルトで有効になっていますが、いつでもチェックの実⾏、無効化、または再設定ができます。1つまたは複数のヘルスチェックを再設定するには、次の⼿順を実⾏します。

1.ヘルスのダッシュボードでは、Action > Manage Check でクリックします
ヘルスダッシュボードには、ヘルスチェックに関する情報が再表⽰されます。特定のヘルスチェックをクリックすると、その チェックが強調表⽰されます。ヘルスチェックを選択するか(最初に選択するか)、以前に選択したヘルスチェックが強調表⽰されます。次の情報が表⽰されます。

  • 左側の列には、ハイライトされた状態が正常性チェックの⼀覧として表⽰されます。いずれかのエントリをクリックして、そのヘルスチェックを選択して強調表⽰します。
  • 中央の列には、このヘルスチェックの機能が記載されており、影響を受けるエンティティ(ホスト、ディスク、またはVM)全体で実⾏スケジュールと履歴が提供されます。
  • 右の列には、このヘルスチェックが失敗した原因(原因、解決、影響)が記載されています。
2.特定のチェックを実⾏するには、[Run Check]をクリックします。

3.ヘルスチェックをオフにする(またはオンにする)には、中央の列の上部にあるチェックオフ(またはチェックオン)リンクをクリックし、ダイアログボックスで[Yes]ボタンをクリックします。

4.パラメータの設定を変更するには(設定可能なパラメータがあるヘルスチェックの場合)、中央の列の上部にあるパラメータリンクをクリックし、ドロップダウンウィンドウでパラメータ値の1つ以上を変更して、[Update]ボタンをクリックします。このリンクは、ヘルスチェックに設定可能なパラメータが含まれている場合にのみ表⽰されます。設定可能
なパラメータは、そのヘルスチェックに固有です。たとえば、CPU Utilizationヘルスチェックには、ホスト平均CPU使⽤率のしきい値とホストピークCPU使⽤率のしきい値の割合を指定するパラメータが含まれています。

5. ヘルスチェックを実行するスケジュールを変更するには、中央の列の上部にあるスケジュール可能なチェックのスケジュールリンクをクリックし、ドロップダウンリストから間隔を選択します。1分から48時間までの間隔を選択できます。各Checkにはデフォルトの間隔があり、ヘルスチェックに応じて1分に1回から1日に1回まで変更可能。
ほとんどの場合、デフォルトの間隔が最適であり間隔を変更することは推奨されません(Nutanixのカスタマーサポートによって要求されない限り)。

3.NCC(Nutanix Cluster Checkの間隔)
Prismから指定された時間が経過した後にNCCを自動的に実行する設定を行うには、次の手順を実行ヘルスダッシュボードの[Action]ドロップダウンメニューから[Set NCC Frequency]を選択構成スケジュールを選択します。

→4時間ごと:4時間間隔でNCCチェックを実行するには、このオプションを選択
→毎日:NCCチェックを毎日実行するには、このオプションを選択します。開始時刻フィールドからチェックを実行する時刻を選択
→毎週:毎週 NCCチェックを実行するには、このオプションを選択します。あなたからのチェックを実行する曜日と時刻を選択しオンと開始時刻のフィールドを。たとえば、[オン]フィールドで日曜日と月曜日を選択し、[開始時刻]フィールドから午後3時を選択すると、毎週日曜日と午後3時にNCCチェックが自動的に実行します

電子メールのアラート設定を使用して設定した電子メールアドレスも表示されます。レポートはすべての受信者に電子メールとして送信します[Save]をクリックします。

4.Webコンソールを使用したCheckの実行
Prism WebコンソールのHealthダッシュボードからNCCチェックを実行可能
すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

  1. ヘルスダッシュボードの[Action]ドロップダウンメニューからCheckを実行します。
  2. クラスタに対して実行するチェックを選択します。
    a. すべてのチェック:すべてのチェックを一度に実行するには、このオプションを選択
    b. 失敗および警告チェックのみ(Only Failed and Warning Checks):ヘルスチェックの実行中に、失敗または警告を出したCheckのみを実行するには、このオプションを選択
    c. 特定のチェック:このオプションを選択し、実行するテキストボックスにCheckまたはCheckの名前を入力します。
    このフィールドは、Checkの名前の入力を開始すると自動入力。
    この実行のために選択したすべてのチェックは、[Added Checks]ボックスに表示されます。
  3. 選択した電子メールのクラスタチェックレポートを送信クラスタチェック後にレポートを受信するためのオプションを選択し、電子メール構成を受信するには、アラートの電子メール構成を構成していることを確認します。
実行のステータス(成功または中止)は、タスクダッシュボードで使用できます。デフォルトでは、すべてのイベントトリガーチェックが渡されます。また、ヘルスダッシュボードの[Summary]ページは、ヘルスチェックの実行状況に応じて更新

5.Webコンソールを使用したログの収集
Prism Webコンソールのホームダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了すると、タスクダッシュボードからログバンドルをダウンロード可能です。

  1. 正常性ダッシュボードの[アクション]ドロップダウンメニューから[ログコレクタ]を選択します。
  2. ログを収集します。
    a. Collect Logs starting nowを収集する:時間数または日数に基づいてログを収集するには、このオプションを選択します
    b. Custom Date Range:このオプションを選択すると、開始日と終了日のフィールドに日付範囲を指定します。時間フィールドは、現在の時間で自動的に更新されます。ただし、収集操作を開始する時刻を選択するオプションもあります。
  3. [Run Now]をクリックして操作を開始します。
操作が終了すると、最後の2回分のログバンドルをタスクダッシュボードからダウンロードして、後で分析することができます。

参考にして頂ければ幸いです。よろしくお願い致します。








2021年7月26日月曜日

AHVの High Availability(⾼可⽤性)について

みなさん、こんにちは

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

今回はAHVの高可用性【High Availability】(以下HAで省略)についてご紹介します。

HAの⽅式については2種類存在します。
  • ベストエフォート
  • リザベーション

1.ベストエフォート方式について
HAの設定についてはFoundationでセットアップ後に組まれていますが、Prismのメニューで「Manage VM High Availablity」というメニューで「Enable HA Reservation」のチェックのON/OFFで設定が決まります。
設定をOFFのままであれば、ベストエフォートになり、ONにすればリザベーション(予約)になります。

  • Acropolisは、ホストがダウンした場合に管理する仮想マシンの⾼可⽤性を提供
  • 正常でないホストが修復されている間に、別の正常なホスト上で仮想マシンが再起動されます
  • ホストが修復されている間、仮想マシンが⻑期間停⽌する⼼配はありません
  • ストレージの⾼可⽤性の最⼤はRF-3であるため、最⼤2つのホスト障害をサポートします
ベストエフォートの場合、障害発⽣後は⾃動で再起動しますが、デフォルト設定なので、ノードで使⽤可能なリソースに基づいて、他のクラスタノード上の仮想マシンの復旧と電源投⼊を⾏います。エンタープライズクラスの機能を最初から有効にすることは⾮常に効果的ですが、ベストエフォート型のオプションでは、リソースの制限のために仮想マシンの電源がオンにならない状況が発⽣する可能性があります。


より定義された復旧モデルの場合、AHVは仮想マシンの⾼可⽤性を保証するために、クラスタ内に必要なリソースを予約することができます。デフォルトのベストエフォート機能と同様に、リザベーション(予約)モードも⽤意されており、ワンクリックで選択できます。

2.リザベーション(予約)方式について
チェックを⼊れることにより、AHVはNutanixクラスタを分析し、復旧に最適な⾼可⽤性ポリシーを選択します。現時点では、システムは、確⽴された⾼可⽤性ポリシーに基づいて新しいVMを確実に回復できるようにポリシーを設定します。
AHVは、ポリシーをクラスタ内の使⽤可能なメモリに基づいており、次の可⽤性ポリシーを提供します。

  • ホストのCPUとメモリの使⽤状況を追跡します
  • ホスト機能の対象となり、仮想マシンのポリシーに準拠した仮想マシンを配置
  • 仮想マシンの⾼可⽤性を保証するリソースを予約
リザーブド・セグメント︓AHVは、単⼀ノードを専⽤ノードに割り当てるのではなく、クラスタ内のノード全体に⾼可⽤性リカバリ・ポイントを分散します。ハイアベイラビリティイベントが発⽣すると、障害の発⽣したホスト上で実⾏されている仮想マシンは、クラスタ内の他のノードで再起動します。

サポートするポリシーについて
  • データローカリティを維持しますQoSを保証します
  • 特定のリソースタイプとの相関関係を決定づける
  • ハードウェア/ソフトウェアポリシーの制約に従う
  • ワークロード間の⼲渉を避ける
  • 集合的なリソース要件を優先する
予約された構成では、仮想マシンの⾼可⽤性設定は、確⽴されたNutanixクラスタのフォールトトレランスレベルに応じて、クラスタ全体でリソースを予約します。仮想マシンの⾼可⽤性の構成では、次のことから保護するために必要なリソースが予約されています。

  1. NutanixコンテナがReplicationFactorが2で構成されている場合、1台のAHVホスト障害まで許容
  2. NutanixコンテナがReplication Factorが3で構成されている場合、2台のAHVホスト障害まで許容
Nutanixは、クラスタから⼊⼿可能な詳細に基づいてリカバリオプションを⾃動的に選択することにより、⾼可⽤性のリカバリ⽅法の選択を簡素化します。ベストエフォート型のデフォルトを超えて仮想マシンの⾼可⽤性を有効にすると、新しい仮想マシンの⾼可⽤性に対応するのに⼗分なリソースがポリシーで確保できる限り、新しく作成された仮想マシンの電源を⼊れることができます。

仮想マシンの⾼可⽤性はハイパーバイザベースの⾼可⽤性のイベントでのみ、実⾏中の仮想マシンのリカバリ性を考慮した構成にする必要があります。ハイパーバイザベースのイベントは、Nutanixソリューション内のストレージまたはCVMイベントを含む⾼可⽤性とは異なります。
ストレージまたはCVMイベントには、(定義されたレプリケーションファクタに基づいて)データレプリケーションによるリカバリと、クラスタ内のリモートCVMへのリダイレクトが含まれます。

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



2021年7月21日水曜日

NutanixのREST APIについて

みなさん、こんにちは

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

今回はNutanixのREST APIについてご紹介します。

REST APIについてご存じない⽅もいらっしゃると思いますので少しご説明したいと思います。

---------------------------------
REST (Representational State Transfer) APIは、Webシステムを外部から利⽤するためのプログラムの呼び出し規約(API)の種類の⼀つです。RESTそのものは適⽤範囲の広い抽象的なモデルであるが、⼀般的にはRESTの考え⽅をWeb APIに適⽤したものをRESTful APIと呼んでいる。

RESTful APIでは、URL/URIですべてのリソースを⼀意に識別し、セッション管理や状態管理などを⾏わない(ステートレス)。同じURLに対する呼び出しには常に同じ結果が返されることが期待される。

また、リソースの操作はHTTPメソッドによって指定(取得ならGETメソッド、書き込みならPOSTメソッド)され、結果はXMLやHTML、JSONなどで返される。また、処理結果はHTTPステータスコードで通知するという原則が含まれることもある。

---------------------------------
NutanixにおいてはREST APIがどのように使われて、どのように利⽤するのかを今回お話したいと思います。

1. Nutanix REST API
Nutanix REST APIを使⽤すると、Nutanixクラスタに対してシステム管理コマンドを実⾏するスクリプトを作成できます。APIを使⽤すると、HTTP要求を使⽤してクラスターに関する情報を取得したり、構成変更可能になります。コマンドからの出⼒はJSON形式で返されます。
動作イメージについても合わせてご覧いただければと思いますが、送信側(クライアント)から受信側(Nutanixクラスタ)に対して、必要としているクラスタ情報を取得ししたり、作成・更新・削除する際にHTTPをベースに操作を⾏います。

HTTPで送信した命令を元に出⼒結果をHTTPのコードとJSONファイルで出⼒します。
このようにして、HTTPのリクエストからNutanix上の操作を⾏うことができるようになっているのが、Nutanix REST APIになっています。

2. Nutanix REST APIを利用するには
Nutanix REST APIを利⽤するには、Nutanix REST APIが何ができるのかを知る必要があります。Prismの管理画⾯の右上にあるアカウントのメニューからREST API Explorerがメニューにあるので、こちらをクリックします。
REST API Explorerが起動されるとNutanix APIが表⽰されますが、REST APIにはバージョンもございます。バージョンの指定は右側のプルダウンメニューから選択することができます。現状はVersion3まであります。

REST API ExplorerでAPIで管理できるクラスターオブジェクトとのリストを表⽰します。オブジェクトについては、ベースがURI形式の相対パスになって表⽰されます。該当のPrism(Nutanix クラスタ)のIPアドレスおよびREST APIのバージョンを指定することで利⽤できます。

今回はNutanixで利⽤できるREST APIでClusterのコマンドについて説明したいと思います。ここでClusterに関して操作を展開してみます。

3. オペレーションに関して
Clusterに関するオペレーションが表⽰されます。例えばGet clusterなどはNutanixのクラスタ情報をクライアント側から取得するAPIになっています。それ以外にも様々な変数をNutanixクラスタの情報を作成、更新するAPIもあります。
ここで、Get clusterをクリックするとクラスタの情報がウィンドウで展開されて表⽰されます。ここでウィンドウで表⽰されているのがクライアント側から送信するGet clusterのREST APIの中⾝になります。

4. APIをテストする
APIをテストには、「Try it out!」をクリックすることで、クラスタ内で使⽤するAPIを呼び出してテストできます。
クリックするとクラスタに設定されているIPアドレス情報やマシンのシリアル情報などが取得できるようになります。こちらはブラウザベースでテストしていますが、実際はクライアント側からコマンドを実⾏することになります。

CentOSがインストールされている仮想マシンからコマンドで、curl コマンドを利⽤することで、リモートのサーバーに対してコマンドを投⼊することができます。

$ curl -X GET --header 'Accept
application/json' 'http://NutanixクラスタのIPアドレス:9440/api/nutanix/v2.0/cluster'

このようなAPIを利⽤することにより、オペレーションがコードされて⾃動化するためのツールとして利⽤できます。以前こちらのブログで紹介したCalmなどはこのREST APIなどが連携されて構成されているソリューションだと思って頂ければと思います。

では、REST APIを利⽤するとどのようなことができるのかをまとめてみました。

5. APIを使用した完全なライフサイクルの自動化
利⽤できるようなシーンとして、イメージのようなものを想定しています。
例えばプロビジョニングについて説明します。

新⼊社員で研修などで開発環境をたくさん作成しなければいけない場合、管理者が⼀つずつ⼿動で構築するのは⾮常に効率が悪くなります。そこで、オペレーションをすべてコードしておくことで必要に作業がシンプル化し、作業時間もかからずに導⼊が終わります。

どのように対応するかについては、仮想マシンのプロビジョニングに必要なイメージを⽤意して、それを必要な台数分をPOSTで作成することで対応できます。
その結果、プロビジョニングの時間が数分程度で終了して、管理者が準備に費やす時間を削減することができます。

システムの最適化にこのAPIを使うためにはどうするのかをお話したいと思います。
例えば制約を受けるようなVMを常にシステムを更新することによって発⾒して、リソースに影響を与えるような仮想マシンを保護するようなものを探したい場合にもこちらのREST APIを利⽤することで対応可能になります。

発⾒⽅法については、Powershellなどの連携で対応できます。システム全体の情報はREST APIで取得し、仮想マシンへの指⽰はPowerShellなどでそれぞれでできる部分をうまく連携することでパフォーマンスおよびセキュリティなどからシステム守るようなことができるようになります。

NutanixはGUIですべてできるようななっているように⾒えますが、細かい操作が必要な場合は是⾮REST APIなども利⽤してみると良いと思います。

最後にNutanixのREST APIにおける簡単なアーキテクチャを紹介したいと思います。参考程度に⾒て頂ければと思います。

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








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のネットワークを設定する前に是⾮注意事項として覚えて頂ければ幸いです。

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