AOS5.11を紹介（その5） AHVでもEFIがサポートされました。

昨今では、パソコンにおいてもサーバーにおいても大容量化が進んでおり、1つの物理的なHDDでも10TBを超えるものも存在しています。
Windowsの場合、旧来のBIOSを利用すると2TBを超えるディスクを起動ディスクとすると、2TB以上の領域を利用できないなど、大容量化に対して旧来の技術では対応ができないという課題がありました。
また、Hyper-Vの第2世代で構成された仮想マシンはUEFIと構成され、AHVへの移行にはかなり手のかかる作業が必要でした。

今回AOS5.11から正式にAHVにおいてもUEFIがサポートされました。
従来からAHVにおいてもUEFIはacliコマンドで設定することでEFIモードにすることはできましたが、非サポート扱いでしたがこのタイミングでUEFIもサポータブルになりました。

2019/4末の段階で、AHVでEFIを設定した仮想マシンの起動ロゴが変わっていることに気が付いておりました。（以前はロゴのない文字しかない画面でした）

知らぬ間にAHVで仮想マシンのUEFI画面がかっこよくなっていた。
ただし、今のところAHVにおけるUEFIモードは正式サポートではない...。（そのうち正式サポートされることを願っている今日この頃）#Nutanix pic.twitter.com/QzM6bvP0el

— Shadowhat (@shadowhat) April 29, 2019

これがおそらく「AHV-20170830.256」のバージョンであると思いますので、4月末ぐらいには水面下にAHVだけが先行的にバイナリが提供されたのかもしれません。

このUEFI対応に伴い、Prismの仮想マシン作成画面でもBIOSかUEFIかを選択できる画面が追加されました。

また、BIOS利用時は、優先Bootメディアを選択できるようになり、デフォルトのCDROMドライブではなく最初から任意のメディアにGUIで変更できるようになりました。

なお、AHVとして正式にUEFIに対応しているゲストOSは以下の通りです。

• Microsoft Windows 10 Home/Pro
• Microsoft Windows server 2012 R2/2016
• CentOS 7.4/7.5
• Red Hat enterprise Linux 7.1
• Ubuntu 12.04.x LTS Desktop/Server
• Ubuntu 16.04.x LTS Desktop/Server
• Ubuntu 18.04.x LTS Desktop/Server
• SUSE Linux Enterprise Server 12 SP3

最新の情報は、AHV Administrator Guideを参照してください。
https://portal.nutanix.com/#/page/docs/details?targetId=AHV-Admin-Guide-v511:vmm-compatibility-matrix-for-uefi-supported-vm-r.html

UEFIが正式に対応したこととNutanix Move 3.0からHyper-VからAHVへの移行がサポートされたことにより、Hyper-V第2世代(UEFI)で作成された仮想マシンも問題なく移行することができるようになったのは、AHVの利用の幅を広げる大きな理由の1つになったと思います。

AOS5.11を紹介（その4） Storage QoS機能の搭載でノイジネイバーの影響を低減する

今期は、AOS5.11に搭載されたStorage QoS機能についてご紹介します。

仮想化において厄介なのは特定の仮想マシンがストレージのI/O負荷を大きくかけて、仮想化基盤にいる他の仮想マシン全体に迷惑をかける、いわゆるノイジーネイバー（うるさい隣人）の存在です。

Nutanixは、CVMが各仮想マシンのI/Oを把握しているため、それぞれのマシンに対してフェアなI/Oを提供するようにできています。
しかし、I/Oに対しての制限（リミット）を設定することができませんでしたが、このAOS5.11からIOPSの制限を入れる機能が追加されました。
これがStorage QoS機能となります。

このStorage QoSの設定にはするには以下の環境である必要があります。

• ハイパーバイザーは「ESXi」または「AHV」である必要があります。
• Nutanixクラスターのライセンスが「Pro」以上である必要があります。
• 設定には、Prism Central（Prism Starterでよい）を利用します。
• IOPSの最小値は100です。100未満は設定できません。
• IOPSを設定した仮想マシンは、IOの遅延が出てくる可能性があります。
• リンククローンで作成した仮想マシンの場合、マスターvDiskはQoSの対象になりません。
• VolumeGroup及びVolumeGroupが設定された仮想マシンには適用されません。

では具体的に設定方法を見てみましょう。
まずは、Prism CentralのVMsから、I/Oを制限したい仮想マシンにチェックを入れ、上のActionメニューから「Set QoS Attributes」をクリックします。

ここで指定したいIOPSまたは、スループットを入力します。
下側の表には入力したIOPSに基づいたスループットが自動的に計算されて表示されます。

ここでポイントは、32Kを超えるブロックサイズの場合、IOPSではなくスループットで自動的にリミテーションがかかる仕組みとなっています。
IOPSですから、1ブロックのサイズが大きくなれば当然ながら少ないIOPSであっても、ある程度の負荷がストレージ側にかかってきます。そのため、このStorage QoSに関しては、32Kを超えるストレージブロックは、スループットに置き換え最終的に受け渡されるデーターのサイズに違いがないようにし、フェアな速度を提供するように作られています。

IOPSの制限を入れることにより、例えば普段負荷がかからない仮想マシンにリミテーションを入れて、Windows Updateやウイルス対策ソフトのフルスキャンなどの業務外の作業で仮想化基盤全体の負荷がかかり、本来利用したいサービスが稼働している仮想マシンの動作影響を抑えることや、マルチテナントにおけるノイジネイバーによる他のテナントへの影響範囲を制限することができます。

StorageのIO制限は、ストレージにおいてよく要求される事項の一つでもあります。
NutanixのStorage QoSは、LUN単位ではなく仮想マシン単位で行えることはNutanixのメリットであると思います。

コンピュート専用ノードの動きを見てみる

前回の記事で、AOS5.11からコンピュート専用ノードの紹介をさせていただきました。
今回は具体的に、コンピュートノードをクラスターに追加する方法と追加後にどのようにPrism,に表示されるかなどをご紹介したいと思います。

まず、前提条件として、コンピュートノードは、既に４ノード以上で稼動しているNutanixクラスターに追加する形でしか構成されません。３ノード構成でうち１ノードをコンピュート専用ノードにするといったことは出来ませんので、ご留意ください。

まずは、既存のコンピュートノードを見てみましょう。
AHVはインストールされていますが、CVMが存在しないことが分かります。

[root@COMPUTE-NODE ~]# uname -a
Linux COMPUTE-NODE 4.4.77-1.el6.nutanix.20170830.301.x86_64 #1 SMP Wed Jun 26 17:05:47 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[root@COMPUTE-NODE ~]# virsh list --all
Id               名前               状態
----------------------------------------------------

[root@COMPUTE-NODE ~]#

これは、FoundationVMで、ComputeOnlyNodeでFoundationすることでこの環境を作成することが出来ます。

では次に、既存クラスターへの追加を行います。
追加は、前回説明したとおりExpandClusterから、行います。

通常のノードの場合、ExpandClusterを行うとIPv6リンクローカルアドレスを使ったDicoveryが行われますが、CVMが存在しないコンピュート専用ノードは自動検出されません。そのため以下のようにマニュアルでAHVホストIPを入力し、検出を行います。

ここで、AHVのIPアドレスを入力します。

検出を行うと、そのノードのモデルやシリアル番号は表示されます。
通常この情報はCVMが保有しているのですが、コンピュート専用モデルでイメージングされた場合にのみ、AHVハイパーバイザー上にモデル情報等が記録されます。
コンピュートノードのためCVMのIPアドレスは入力欄がありません。

Expand Clusterの作業自体は、AOSのバージョンチェックがないことや、追加ノードのディスクメンバーをStoragePoolへの仲間入りさせる作業が発生しない分、かなり早く終わります。

追加されたコンピュート専用ノードは通常と同じハードウェアに上がってきます。
ここで、コンピュート専用ノードは以下の画面の通り、TypeにCompute Onlyノード（日本語では計算のみ）として記載され、通常のHCIノード（コンピュートとストレージの両方を持つ通常ノード）と異なる事が確認でできます。
パフォーマンスグラフを見ても、ストレージに関するグラフが表示されていないことが分かります。

ハードウェア一覧でのストレージIO部分が、コンピュート専用ノードでは表示されないことがわかります。

持ちろん、仮想マシンのライブマイグレーションホストの選択も可能ですし、ライブマイグレーションは問題なく動作します。

では、ノードの取り外し（Remove）についても最後に紹介しておきます。
ノードの取り外しもExpandと同様、ノードのディスクがストレージメンバーに存在しないため、わずか１〜２分でRemove処理が完了します。
（通常のHCIノードの場合、ノード取り外し時に、自分のデーターを他のノードにコピーし、SSD/ディスクをStoragePoolのメンバーから外す作業が発生するためそれなりの時間がかかります）

今回はコンピュートノードについて確認をしてみましたが、最初のFoundationのところがひと手間ありますが、それ以降のノード拡張作業などはいつものNutanixのオペレーションと同じくシンプルな操作で、コンピュートノードであることをあまり意識しないNutanixらしい使いやすさを実現していると感じます。

AOS5.11を紹介（その3） コンピュート専用ノードの誕生

Nutanixは、ストレージとコンピュートノードのセットになったノードが一般的ですが、容量だけ増やすこのことの出来るストレージ専用ノードの２つがラインナップされています。さらにAOS5.11から、コンピュートだけを追加するコンピュート専用ノードがリリースされました。コンピュート専用ノードは、Nutanixのドキュメント上では「CO」(Compute Only）として記載されていることがありますので、COという表現を見たらコンピュート専用ノードのことと思い出してください。

さて、このコンピュート専用ノードは、読んで字のごとくストレージ機能を提供しない演算処理だけのノードとなります。
ディスク容量はそこまで必要ないけれども、CPUやメモリーを多く消費するワークロードにおいては、このコンピュート専用ノード重宝する物だと思います。

このコンピュート専用ノードを既存クラスターに追加するためにはいくつかの制限事項があります。ではその制限事項を確認しておきましょう。

＜構成の注意点＞

• Nutanixクラスターは少なくとも4ノードの通常ノードで構成されたされている必要があります。
• クラスタ内のコンピュート専用ノードとハイパーコンバージドノード（通常のノード）の比率は、
  「1 コンピュート専用ノード：2 ハイパーコンバージド」
  である必要があります。
• クラスタ内のすべてのハイパーコンバージドノードは、オールフラッシュノードである必要があります。
• ハイパーコンバージドノード上のCVMに割り当てられるvCPUの数は、クラスター内のすべてのコンピュート専用ノードで利用可能なコアの総数以上である必要があります。（つまりコンピュートノードが８コアの場合、CVMのvCPUコアも８コア以上にする必要がある）
• すべてのハイパーコンバージドノードに割り当てられたNIC帯域幅の合計は、クラスター内のすべての計算専用ノードに割り当てられた合計NIC帯域幅の2倍である必要があります。（コンピュートノードが10GbpsのNICで通信する場合、ハイパーコンバージドノードのネットワークは20Gbps以上、つまり25Gネットワークが必要となります）
• コンピュート専用ノードのAHVのみ対応します。AHVのバージョンは、クラスター内の他ノードと同じである必要があります。
• コンピュート専用ノードを作成するためには、Foundationであらかじめコンピュート専用ノードでイメージングする必要があります。 

＜機能上の注意点＞

• ホストブートディスク（M.2 or BOSS）の交換（PrismUIからの操作）
• ネットワークセグメンテーション
• AOS5.11からのサポート

＜サポートされているハードウェア＞

• NXシリーズ
• Dell XC Core
• Cisco UCS

構成の制限ざっと見る限り、え？？？みたいな制限がかなりあります...。
（普通のハイパーコンバージドノードを買う方がきっと安くなる気がします）

なお、コンピュートノードは、闇雲に好きなサーバーを追加するわけでは無く、Nutanixのコンパチビリティが通ったモデルだけがサポータブルであることが、サポートされているハードウェアの一覧から分かります。

では、このコンピュートノードの作り方とノードの追加方法をお知らせします。

まずコンピュートノードの追加方法です。
コンピュートノードは、Foundationツール（Foundation VM）を利用して、CVMの存在しないコンピュート専用ノードでイメージングする必要があります。
しかし、Foundation4.4.1では、このコンピュート専用のメニューは表示されません。このモードを表示するためには、FoundationVMで以下の設定を入れる必要があります。

FounadtionVMで以下のファイルを作成します。

vi /home/nutanix/foundation/config/features.json

以下の内容を記載し、保存してviを終了します

{"compute_only": true}

Foundationサービスを再起動します。

/home/nutanix/foundation/bin/foundation_service restart

これで、FoundationのノードDiscovery画面の右上メニューで、「Add Compute-only Node」が表示されるようになります。

イメージングが完了したノードは、既存クラスターのPrism画面から、Expand Clusterの画面を利用してノード拡張を行います。
ただし、CVMが存在しないノードのためNode Discoveryによる自動的なノードの検出は出来ません。 そのため、Manual Host Discoveryから、AHVのIPアドレスを入れてノードを手動で検出させた後、Expand Cluster機能でノードを追加する流れとなります。

HCIは本来、ストレージとコンピュートノードが一体化することでハイパフォーマンスと利便性を提供する物であり、コンピュートノードだけの追加となると、HCIの意味合いが薄まる感じもしますが、ユーザーのニーズに合わせて提供された機能であると思います。

AOS5.11を紹介（その2） 1ノード120TBオーバーモデルの誕生

今日はハイパーバイザーに依存しない話しを1つご紹介します。

NutanixはSoftware Defiedベースの分散アーキテクチャーを利用した完全なる分散型のストレージを実現しています。
ソフトウェアベースである以上、ソフトウェアのパフォーマンスとの勝負の部分も一部ありますが、AOS5.11よりノードあたり120TBの容量を保持できるノードを対応しました。これにより、3ノードであってもかなりの容量を担保できる仮想化環境を構築できます。

この対応により、1ノードに対して搭載できるディスクとして12TBモデルがサポートされるようになります。

なお、2つほど注意点があります。

1）１ノード４０TBを超える場合、スナップショットのRPOは６時間となります。
これは、AOS5.11より前に話が出ていましたが、40TiBを超えるノードで構成されている場合、スナップショットのサイクルは、6時間に1回となります。Nutanixは、通常1時間に1回のスナップショットが設定可能ですが、環境によっては出来ないことがありますので注意が必要です。

2）CVMのメモリーサイズに注意
ノードあたり120TBを構成する場合、CVMのメモリーサイズは36GBに設定する必要があります。

今後Nutanixは、ノードあたり200TiBのサポートもでているようですので、ますます容量単価も下がり、大容量化に対応するNuttanixを利用することで、スト手レージヘビーな要件も対応できる幅が広がると思います。

(参考）
Supported Snapshot RPO for Storage Heavy Nodes
※Accessには、Nutanix Support Portalへのログインが必要です。

AOS5.11を紹介（その1） アップリンクチーミングモード変更GUI機能を紹介

ついに2019/6/8、待ちに待ったAOS5.11がリリースされました。
このブログもAOS5.11を待っており昨年から更新が出来ておらず、奇しくも今年１発目の投稿となります。（これから巻き返せればと思います...）

さて、AOS5.11にはたくさんの機能が盛り込まれているのですが、その中の1つであるbr0のアップリンク構成変更のGUI化について紹介します。

AHVにおける操作性が悪いところの1つが、アップリンクNICのチーミングモードの設定現行でした。AHVで構成されたNutanixクラスターは、初期出荷時にAcrive/Backupモードでチーミングモードが設定されています。Nutanixの推奨チーミングモードはこのActive/Backupモードとなりますが、より多くのトラフィックを処理するために状況によってはLAG(Link Aggregation)を利用する事もあるかと思います。
AHVにおいてアップリンクのチーミングモードを変更するためには、「manage_ovs」コマンドをCVM上で実行する必要があるのですが、パラメーターが複雑であったり、状況によってはAHVホスト側で直接「ovs-vcsctl」を実行する必要があるなど、あまりユーザーフレンドリーではありませんでした。

しかし、AOS5.11からこのアップリンクモードの変更がPrism Elementから出来るようになりました！（個人的には待望の機能1つ）

では早速、使い方をご紹介します。
まず、Prism Element画面から「Network」を選択します。

続いて、現在のアップリンクに属しいているNICを確認します。
各ホストのホスト名称をクリックします。

この状態では、アップリンクNICに1Gと10Gが混在しています。

この状況はAHVで稼動する場合において推奨されない構成となります。
その理由は、10G/1G混在時に1GNICがリンクアップすると、10GNICを利用していても、速度がすべて1Gに統一されてしまうからです。1Gを明示的に利用しない場合はこのような事故は防げるかと思いますが、接続間違いが起きてもトラブルがおきないようアップリンクの構成から1GNICをはずすことが推奨とされています。 なお「0G」というNICもアップリンクに存在（表示）されていますが、こちらはDELL XCで構成されている場合、iDRACとの通信用の内部NICが表示されているためです。このNICは、本来アップリンクに存在してはいけない（Foundationを行った場合、自動的にこのNICは、アップリンクの対象から外されます）のでこちらも除外したいと思います。

では、早速アップリンクモードの変更を行いたいと思います。
先程のネットワーク画面の右上にある「＋アップリンク設定」をクリックします。

ここでアップリンクのモードを変更できます。
今回は、Active/Backupのまま、1GNICをアップリンクの対象から外してみます。

アップリンクモードは「アクティブ-バックアップ」を選択し、NICの設定で、「Select All 10G NICs」を選択した後「保存」をクリックします。

設定はこれだけです。

実際に設定反映をしてみると、Taskにはホストをメンテナンスモードにし、再起動していることが分かります。アップリンクモードの変更は仮想マシンの通信停止に陥る可能性もあるため、ホストを1台ずつメンテナンスモードにし、仮想マシンをライブマイグレーションされた後、チーミングモードが変更されるという仕組みす。この作業がホスト分だけ1つずつローリングで設定される仕組みとなります。（この仕組みから、N+1で構成されていない環境ではこの設定は利用できません）

設定変更はノード数にもよりますが1ノードあたりだいたい5〜7分程度ではないかと思います。設定が完了すると、ちゃんとアップリンクNICが10Gだけになっていることが分かります。

今までのコマンドとの戦いも無く、マウス数クリックだけで変更できるのは、大変便利です。

次回はまた別のAOS5.11の機能をご紹介できればと思います。