2020年7月24日金曜日

AOS 5.17で改善された機能・NICのVLAN切り替え

AOS 5.17がSTSとしてリリースされました。
以前の記事で紹介したとおり、どちらかというとレプリケーション周りの機能追加が多いのですが、普段の利用においても利便性が向上する機能追加が行われています。

その1つが、AHV環境における、仮想マシン稼働中の仮想NICのVLAN変更です。

AOS5.16までは、パワーオン状態の仮想マシンにおいて、NICのVLAN変更を行うことが出来ませんでした。パワーオフの場合はVLAN変更が可能ですが、acliコマンドでの実行でしかできませんでした。

しかし、AOS5.17においては、待望のPrism UIから、しかも仮想マシンがパワーオン状態であってもVLANの切り替えが可能となりました。



何気ないというか、vSphereであれば何年も前から出来ていたことですが、やっとAHV環境でも出来るようになったことは、嬉しいことです。

実際、稼働中の仮想マシンにおいてVLANの変更というのはまずあり得ないと思いますが、検証環境やネットワークの動作確認を行う際には、VLANの変更機能は必要不可欠だと思います。

Nutanixは、ユーザーの意見を常に反映する機能アップデートを行っていますので、このような小さい機能であってもリクエストを上げることで、聞いてもらえるという、Nutanixがお客様視点で製品が作られているという一面を見ることが出来るところでもあると思います。






2020年6月6日土曜日

AOS 5.17がリリースされました

2020年5月に、AOS 5.17がSTSとしてリリーされました。
AOS5.17は、たくさん新機能が搭載されていますが、特にストレージにおけるレプリケーションや冗長化の部分にフォーカスが置かれて、機能追加がなされております。
本日は、AOS5.17における主な追加機能の紹介をしたいと思います。

新しく追加された機能
  • AHVにおけるメトロクラスターサポート
  • NearSyncにて30秒の対応(今までは1分)
  • オンプレ版Leapにおける、NearSyncのサポート
  • 単一PrismCentralでオンプレLeapの構築がサポート
  • メトロ(ESXi)にて、NeaySyncのサポート
    メトロクラスターを構成した環境で、AsyncとNearSyncを追加で設定可能
  • A Sync DR/NearSyncにおけるレプリケーションネットワークの分離
    (個人的には待望の機能!LeapおよびCloudConnectは未対応)
  • Leapにおける仮想マシンに対して、固定IPをサポート
    (今までは、IAPMによる動的IPかDHCPのみがサポートでした)
  • Leapにてリカバリプラン内に、スクリプトの実行が可能に
  • Hyper-Vでのラックアウェアネスサポート
  • Prismにおける冗長性のステータス表示機能の変更
  • AES環境にて入れージャーコーディングをサポート
  • リモート拠点にある新品のNutanixをそのままイメージングできる、Foundation Centralがリリース(Prism Centralで操作)
  • スナップショットメタデーターのマージによるReadアクセスの改善
  • PrismCentralの改善
    単一PCで25000仮想マシン、300クラスターをサポート
  • CAC認証の対応
  • Volume Groupにて、Windows ゲストOSにSCSIアタッチの形式の共有ディスクをサポート
  • Nutanix Flowにて、IdentityBase(AD)によるマイクロセグメンテーションの実装

ざっくりとトピックを記載をさせて頂きました。

MetroやNearSyncは、ミッションクリティカルな現場では便利な機能ですが、普段常用する機能では無いかと思います。
一方、レプリケーショントラフィックを別のネットワークに分離できる機能は、セキュリティの側面からしても大変便利な機能だと思います。

次回以降は、気になる新機能についてすこしだけ掘り下げて見ていきたいと思います。



2020年5月10日日曜日

インターネットにつながらない環境でLCMを利用する場合 AHV編

2019年12月に、LCMをダークサイト、いわゆるインターネットにNutanixクラスターが接続されていない環境下で利用する方法をお伝えいたしました。
AOS5.16がリリースされさらにLCMが2.3になったことにより、AHVもLCMでのアップデートが推奨のアップデート方法となりました。

しかし、このAHVのアップデートですが、今までのOne Click Upgradeでは、ダークサイトであってもNutanix Support PortalからAHVのバイナリとメタデーターのJSONファイルを予めインターネットが接続できる環境でダウンロードした後、Prismからこのファイルをアップデートすれば良かったのですが、LCM2.3以降は、ダークサイトでのアップデートの手順が異なっております。

まず、以前紹介した「インターネットにつながっていない環境でLCMのアップデート方法」を元にLCMのバイナリを配置したWebサーバーを用意します。その後、My Nutanix Supportの「KB8838」を参考に現在利用中のAOSにあわせたAHVのバイナリをダウンロードします。
※本KBは、My NutanixからSupport Portalにログインできるユーザーのみ参照可能です。

2020/5/10現在、以下のAOSバージョンに合せたLCMダークサイト用のAHVバイナリが提供されています。

AOSバージョンバイナリ
AOS 5.10.10lcm_darksite_ahv-builds_el6.nutanix.20170830.396.tar.gz
AOS 5.15lcm_darksite_ahv-builds_el6.nutanix.20170830.395.tar.gz
AOS 5.16 / 5.16.1ahv_darksite_bundle_96 + 110.tar.gz
AOS 5.16.1.1host-bundle-el7.nutanix.20190916.142.tar.gz
AOS 5.16.1.2lcm_darksite_ahv-builds_el7.nutanix.20190916.158.tar.gz

AOSのバージョンに合わせてダウンロードするバイナリが異なるため、事前によく確認をしておく必要があります。

ダウンロードした、tar.gzファイルを展開し、「ahv-build」フォルダとその配下を、LCMのバイナリを配置しているWebサーバーのドキュメントルートに配置します。

この準備が出来たらPrism側のLCMで、Perform Inventoryを実行すると事で、新しいAHVのバイナリがアップデート対象として上がってきます。

今まで、バイナリをアップデートすればすぐ終わる話だったのが、LCMになることですこし手間になっているようにも感じますが、昨今は、管理系もインターネットにつないで、サポートから常に新しい情報を元に監視し疑わしい障害を早く発見するといった新しいアプローチがアメリカでは標準になりつつ有り、Nutanixもその考え方に基づいて設計されています。Nutanixクラスターがインターネットに接続できる環境の場合、LCM用のWebサーバーも必要なく、環境に合わせて必要な情報を自動で取得してきますので、ダークサイトでのLCM運用に比べかなりの手間を省くことが出来ます。
セキュリティを意識しながらもインターネットに管理系をつなぐことも今後は検討することもひとつかと感じます。





2020年5月9日土曜日

Move利用時に既存環境とNutanixクラスターが同じネットワークにいない場合の対処法(MoveでマルチNIC構成を行う)

Nutanix Moveは、既存の仮想化環境からNutanixクラスターへ仮想マシンを移行することが可能です。
このNutanix Moveはネットワークを利用して、既存の仮想環境から仮想マシンイメージを取得しNutanix側に転送する仕組みになっています。

では、既存仮想環境と新しく設置するNutanixがネットワーク的につながっていない場合、どのように移行を行えば良いかという疑問が出てきます。Nutanix Moveは、セカンドNIC構成(NIC2枚挿し)構成が可能です。
※この手法は、移行元仮想環境がHyper-Vの場合はサポートされていません。Hyper-VでNIC2枚構成を希望される場合は、「Nutanix MoveでHyper-V環境におけるNIC2枚挿し構成について」を参考にしてください。




セカンドNICを搭載した際、Moveアプライアンスの初期ウィザードでは設定内容としてあがってきませんので、手動で設定を行う必要があります。
今日は、セカンドNICの設定方法をお伝えします。
今回の環境は、Move 3.5を利用します。Move3.0.2以前の場合は一部の手順が異なりますのでご注意ください。
(なお、この手法は移行元ハイパーバイザーがHyper-Vの場合はサポートされていませんのでご注意ください)

まずは、「AHVへの引っ越しは、Nutanix Moveで(その3)」を元に、Moveアプライアンスを展開します。
Move 3.5現在、Moveアプライアンスの展開先は、AHVでもESXiの2つが選択可能です。

展開し、初期のNIC設定が終わった後、一度Move仮想アプライアンスをシャットダウンします。
その後、Move仮想アプライアンスにNICを追加し、再度Move仮想アプライアンスを起動します。
 
起動後、adminユーザーでMoveアプライアンスにログインを行います。

ログイン後、rootユーザーにスイッチします。
rs

※パスワードは、デフォルト「nutanix/4u」です。

ここで、初期に付与したNICと新たに追加されたNICの状態を確認します。
ip addr | more
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000    #新しく追加したNIC
    link/ether 50:6b:8d:2c:e2:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.XXX.YYY/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::526b:8dff:fe2c:e210/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 50:6b:8d:a2:d1:a3 brd ff:ff:ff:ff:ff:ff
4: docker0:  mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:0d:fe:93:43 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: br-4dd6ea78bbf6:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:e1:d3:47:34 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-4dd6ea78bbf6
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e1ff:fed3:4734/64 scope link
       valid_lft forever preferred_lft forever
7: veth80212f5@if6:  mtu 1500 qdisc noqueue master br-4d
d6ea78bbf6 state UP
  

eth2が新たに追加されたNICであることがわかりますので、それを控えておきます。

続いて、/etc/network/interfaceを開きます。
vi /etc/network/interface
# Configured by /opt/xtract-vm/bin/configure-static-ip at Sat Oct  5 04:12:31 UTC 2019
# loopback configuration
auto lo
iface lo inet loopback

# eth0 Static IP configuration
auto eth0
iface eth0 inet static
        address 192.168.XXX.YYY
        netmask 255.255.255.0
        gateway 192.168.XXX.ZZZ

既存で初期に設定した、IPアドレスが設定されていますので、した側に以下のように設定を行います。

DHCPでIPを付与する場合
auto eth1
iface eth1 inet dhcp

固定IPアドレスを付与する場合
auto eth1
iface eth0 inet static
        address 172.16.XXX.YYY
        netmask 255.255.255.0
        gateway 172.16.XXX.ZZZ

ここで注意点ですが、デフォルトゲートウェイは1つのインターフェースにしか付与できません。
そのため、gateway項目は、eth0かeth1のどちらかにしか記載してはいけません。
それぞれに経路設定が必要な場合は、static routeを設定する必要があります。

入力後は、ネットワーク設定を再起動し新しい設定を読み込みます。
service networking restart
root@move on ~ $ service networking restart
 * WARNING: you are stopping a boot service
 * WARNING: you are stopping a boot service
 * Stopping busybox ntpd ...                    [ ok ]
 * Stopping networking ...
 *   eth0 ...                                   [ ok ]
 *   lo ...                                     [ ok ]
 * Starting networking ...
 *   lo ...                                     [ ok ]
 *   eth0 ...                                   [ ok ]
 *   eth1 ...
 * Starting busybox ntpd ...                    [ ok ]
root@move on ~ $

このような感じで、ネットワークサービスが再起動できていれば問題ありません。

再度、ipaddrコマンドでIPがNICに付与されているかを確認します
ip addr | more
root@move on ~ $ ifconfig | more
br-4dd6ea78bbf6 Link encap:Ethernet  HWaddr 02:42:E1:D3:47:34
          inet addr:172.18.0.1  Bcast:172.18.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:e1ff:fed3:4734/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7181 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6586 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8082154 (7.7 MiB)  TX bytes:7393655 (7.0 MiB)

docker0   Link encap:Ethernet  HWaddr 02:42:0D:FE:93:43
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 50:6B:8D:2C:E2:10
          inet addr:192.168.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fe2c:e210/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7973 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8926408 (8.5 MiB)  TX bytes:5183056 (4.9 MiB)

eth1      Link encap:Ethernet  HWaddr 50:6B:8D:A2:D1:A3
          inet addr:172.16.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fea2:d1a3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10513 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:793805 (775.2 KiB)  TX bytes:3130560 (2.9 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

ただしく、eth1にIPが付与されていることが分ります。

続いて、iptablesの停止とDocker Serviceの再起動を行います。
service iptables stop
svcstop
service docker restart
svcstart

eth1から、MoveのUI画面を開くことも出来ますが、eth0を利用してNutanixクラスターのターゲットストレージコンテナをマウントするため、Nutanixクラスターのインターフェイスは、eth0に向けておくことが必須となります。

これで、Nutanixと既存の移行元環境が別のネットワークであってもMove仮想アプライアンスを介して、移行を行うことが可能です。








2020年5月8日金曜日

Nutanix Move 3.5の紹介とテスト機能について

Nutanix Move 3.5が2020年4月末に公開されました。
今回のバージョンでは、バグフィックスの他に新たな機能が追加されました。
今回は新しい機能について紹介したいと思います。

<新機能>
  • AWS環境からNutanix ESXi環境への仮想マシン移行がサポートされました。
  • 仮想マシンの完全な移行の前に、ターゲット環境で移行テスト機能が追加されました。
  • VMware vSphere 6.7 Update3 の対応
  • ESXiからAHVへの移行対象ゲストの追加
    (RHEL 6.10 /CentOS 7.5~7.7/Windows Server 2019)

AWS環境からESXiへの移行は、読んで字のごとくです。
大きな点は、本番移行前にテスト機能が搭載されたことだと思います!
今回は、このテスト機能について、もう少し深く見ていきたいと思います。

Nutanix Moveで移行をする際によく言われるのは、もし失敗したら?という不安と、それを払拭するためのテストです。
失敗しないのか?という点については、どこについて失敗する可能性があるかを考える必要があります。
Nutanix Moveは、vSphereのバックアップ時に利用するAPI(VDDK)を利用して、仮想マシンイメージのスナップショット差分を取得することで、移行元の仮想マシンはパワーオンのまま仮想マシンを移行する仕組みを持っています。この場合、失敗する可能性があるとすれば、MoveアプライアンスとESXiとの疎通(ネットワーク)の問題であったり、スナップショットが既に大量にあり、VDDKのイメージの取得に失敗するなどいろいろな要因が考えられるため、簡単に失敗するしないという話の前に、Moveの仕組みを知った上で考慮点を洗い出すことが大事だと思います。

話がそれましたが、では実際に正しく動くかテストをしたいという希望に対して、Nutanix Moveは、移行に失敗しても元の仮想マシンは残っていますので、再度元の仮想マシンを起動することでサービスを継続することは可能です。しかし事前のテストのタイミングで、本番の仮想マシンが一時的であってもシャットダウンされてしまうのは、作業を行う時間も限られてしまいますし、あまりスマートではありません。
今まで、Moveを利用したいと言われる方でテストをしたいという要望を言われた場合、元の仮想マシンをクローンしてもらい、それをMoveで移行できるか試してくださいという形で案内をしておりました。元の仮想マシンには何の変更も入れることが無くテストを自由な時間で行うにはおそらくこの方法をとるのが良いかと思います。

一方で、Nutanix Moveに新たについたテスト機能は、実際に稼動している仮想マシンのデーターを移行しつつ、今移行しているデーターを元にその仮想マシンが、Nutanix上で正しく稼働するかをテストすることができます。この段階でテストで正常動作しないことが分れば、一度その移行ジョブを取り消し原因を調査する必要がありますが、本番の仮想マシンを停止すること無く判断をすることが出来ます。
このテスト機能は、AHVからAWSの移行を除く組み合わせの全てをサポートしています。つまり、ESXiからAHV、Hyper-VからAHV、AWSからAHV、ESXiからNutanix+ESXiの環境であれば、このテスト機能が利用可能と言うことになります。

実際のMoveの画面を見ながら変更点を確認しましょう。
まず、Migrationジョブ作成画面で、移行後のNutanix側に登録されたVLAN選択画面の下に、テスト用のVLANを選択する画面が追加されています。こちらは、Target Networkで選択したVLAN以外しか選択できないようになっています。(移行先の本番VLANでテストは出来ない仕様になっているようです)

移行自体の動作は今までのバージョンと特に変わることはありません。
後変更となったところは、実際の移行画面となります。

あらたに、Test Actionというメニューが追加されています。このメニューには、「Create Test VM」、「Recereate Test VM」、「Remove Test VMの3つのメニューが用意されています。
初回テストは、「Create Test VM」を選択肢、まずテストで稼動を行います。

するとこのような形でメッセージが表示されます。移行元のVMに何も影響が無いことと、本来のMoveは、移行元の仮想マシンをシャットダウンして最終のスナップショットを取得しますが、これはテスト機能で稼動するため、クラッシュレベルでのスナップショットからの起動となる旨の注意点が記載されています。
テストが実行されると、View Test VMと言う形で、Prsimのリンクが表示されます。

Prism上を見ると仮想マシン名の末尾に「-MoveTest」という文字列が付与された仮想マシンが存在していることが分ります。
自動的にパワーオンされ、既に起動しております。

仮想マシン自体も、正しく起動していることが分ります。
なお、移行元の仮想マシンがパワーオフの場合、テスト後も仮想マシンはパワーオフのままとなります。
(移行元仮想マシンのパワーステータスに応じて、移行後の仮想マシンもパワーオン、パワーオフが判断されます)


テストが終わったら、仮想マシンはそのままで、Moveの画面から、「Remove Test VM」で、仮想マシンを削除します。


ちなみに、Test Actionで、Create Test VM実行中に、Cutoverボタンを押した場合、自動的にTest VMは削除され、カットオーバー処理が行われるようになっています。

なお、Cutover後のテストは当然ながら出来ません。

テスト機能は今までもなんとか回避は出来ていましたが、手間無く手軽に本番環境に影響なくテストが出来るというのは、移行に対するハードルが下がることに違いは無いと思います。

Nutanix Moveは、移行における大変便利な機能ですが、テスト機能などちょっとかゆいところに手が届く機能が増えて生きているのは、ユーザ視点であるNutanixの良さの一面を感じます。











2020年3月20日金曜日

AHVのUEFIの対応と注意点

AOS5.16からUEFIのSecure Bootにも対応しました。
以前に、AOS5.11でUEFIには対応していましたが、UEFIへの対応強化となります。

では実際にUEFIで仮想マシンを作るところから見ていきたいと思います。

こちらはAOS5.16.1の環境の画面ですがAOS5.11以降、Prism画面からUEFIかBIOSかのどちらかを選択するモードが出てくるようになっています。

UEFIに関してはここから、UEFIを選択するだけです。

acliで確認すると、Prismで作成するとUEFIの領域が、ストレージコンテナが、ManagementShareに作成されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      uefi_boot: True
    }
    cpu_passthrough: False
    disable_branding: False


では、A Sync DRで他のNutanixクラスターにレプリケーションをする際にManagementShareのストレージコンテナも一緒にレプリケーション対象にする必要があるかというと、実際に動きを見たところ、ManagementShareのストレージコンテナをレプリケーション対象に入れなくても、問題なくレプリケーション及びリストア可能です。

現行UEFIでの起動に対応しているOSは、以下の通りです。
  • Windows Server 2012R2/2016/2019 (x64)
  • Windows 10 Pro/Home (x64)
  • CentOS 7.4/7.5/8.0 (x64)
  • RedHat Enterprise Linux 7.1/8.0 (x64)
  • Ubuntu 12.04.x LTS Desktop/Server (x64)
  • Ubuntu 16.04.x LTS Desktop/Server (x64)
  • Ubuntu 18.04.x LTS Desktop/Server (x64)
  • SUSE Linux Enterprise Server 12 SP3 (x64)

なお、Prism上でUEFIで仮想マシンを作成しても、セキュアブートモードにはなりません。
セキュアブートを有効にするには、acliで以下のコマンドを実行する必要があります。

vm.update 仮想マシン名 secure_boot=true machine_type=q35

secure_boot=trueと共に「machine_type=q35」の設定が必要となります。
セキュアブートが有効になると、以下のようにacliで確認するとsecure_boot:Trueと表示が追加されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      secure_boot: True
      uefi_boot: True
    }
=中略=
    hwclock_timezone: "Asia/Tokyo"
    machine_type: "q35"
    memory_mb: 6144
    name: "UEFITEST1"

なお、セキュアブートに対応したOSは、AOS5.16時点で以下の通りです。

  • Windows Server 2016
  • Windows Server 1809
  • CentOS 7.3
  • Red Hat Enterprise Linix 7.7

  • なお、私が試した限りAOS5.16.1では、セキュアブートを有効にした状態で、Windows Server 2019はインストーラー画面の表示がされない(おそらく固まっている)事象を確認しています。
    このあたりはドキュメントに従って、アップデートを待つ必要があるようです。

    ▼UEFI起動時の仮想マシンのブート画面


    一方、セキュアブートでの起動時は、XマークではなくTianoCoreのロゴが表示されます。

    ▼セキュアブート時の仮想マシンブート画面


    また、セキュアブートを有効にした環境では、IDEバスを利用したCDROMドライブや仮想ディスクのマウントとはサポートされていません。セキュアブートの対応によりNGT(Nutanix Guest Tools)は、SATAデバイスのCDROMドライブでも対応することがAOS5.16.1で確認できております。

    UEFI利用時に1点だけ注意点があります。
    UEFI利用時にWindows OSを利用する場合、画面の解像度が800×600に固定され変更することが出来ません。これは、AHV上でVGAドライバーを提供していないことに理由があります。サーバーオペレーションの場合ほとんどがRDPやSSHなどリモートからの操作のため大きな影響はありませんが初期設定が800×600ですと、少々操作し辛い感があります。しかし、UEFIの設定画面で変更することが出来ます。

    ▼画面解像度が固定されている

    仮想マシン起動時にF2キーを押してUEFIの設定画面に入ります。
    [Device Manager]→[OVMF Platform Configuration]から[Change Preferred]で
    画面解像度を変更します。

    設定完了後、「F10」キーを押し、「Y」を押し設定を保存し、その後「ESC」→「ESC」でメインメニューに戻り、[Continue]を選択肢「Enter]キーを押します。
    そのままOSが起動しますが、まだUEFIの設定が反映されていませんので、一度OSを再起動すると新しいUEFIの設定が反映されます。


    なお、AOS5.10であってもUEFIでの設定は可能ですが、UEFIへの対応は正式にはAOS5.11から、セキュアブートはAOS5.16からのサポートとなります。
    AOS5.10でのUEFIで仮想マシンを稼動した場合、先程ご紹介した解像度の設定変更が正しく反映されない制限事項があります。

    AHVにおけるUEFIの対応は、AOS5.11以降急速に進んでいます。
    まだセキュアブートにおいてサポートされるOSが一部少ないなどの課題事項もありますが、これらは近いうちに修正されると思われます。

    Hyper-V 第2世代の仮想マシンからの移行などの場合は、UEFIでの利用が伴いますが、そういった場合も万全に対応可能です。

    2019年12月25日水曜日

    2019年の私とNutanixの振り返り

    2019年も残すところ後僅かとなりました。
    今までこのブログではNutanixの技術情報を中心に書いてきましたが、Advent Calendar 2019の最後である25日は、せっかくの機会ですので自分の振り返りと反省の意を込め、私自身が2019年どのようにNutanixに関わったか(振り回されたを含む)を書いてみたいと思います。



    2019年1月


    2019年2月


    2019年3月
    • Nutanix トレーニング受講
    • .NEXT Anaheimへの準備
    • Nutanix Certified Advanced Professional (NCAP) 5.5 取得


    2019年4月
    • 書籍執筆活動佳境を迎える
    • 社内Nutanixイベント対応で検証作業に追われる


    2019年5月


    2019年6月


    2019年7月
    • 社内Nutanixイベントの対応で環境作成等々に時間を要する


    2019年8月


    2019年9月


    2019年10月


    2019年11月


    2019年12月


    今年のNutanixとの関わりの代表的なものをピックアップしてみました。
    もちろんそれ以外にも、通常の業務でNutanixとの関わり合いは多くありますが、今年もいろいろな意味でNutanixと関わることが多かった1年だったと感じております。
    個人的には、アメリカでの骨折というのが、いろいろな意味での人生初な経験(二度と経験したくない)なところでしたが、そういったネタになる話しは毎度、Nutanix Meetupに登壇した際に話しております(資料の性質上、クローズドでないとお見せできない資料が多いので、いつも会場投影のみで対応させてもらっております)ので、まだNutanix Meetupに来られたことがない方は、是非参加してみて下さい。
    (私は今年7回登壇していたようです...)

    Nutanix Meetup 技術好きエンジニアのためのNutanix勉強会
    https://nutanix.connpass.com/



    来年もNutanixとのよいふれあいができる1年になればと思っております。




    HCIの苦手を克服するストレージ専用ノードの紹介

    HCIは、CPU、RAMを搭載するコンピュートとHDD、SSDなどの記憶領域であるストレージが一体となった製品です。
    一方で、HCIは、CPUやRAMよりもストレージ領域だけを多く利用した環境の場合、ストレージ容量を満たすまで、CPUやRAMも買い足さなければならないため、コスト的に割高になると言われることがあります。

    この言葉は、HCIの概念だけで言うと当てはまることかも知れませんが、Nutanixにおいては、この考え方は必ずしも当てはまりません。

    その答えとして、Nutanixは、ストレージ容量だけを増やすストレージノードが存在します。他社のHCIの場合、ストレージヘビーノードとして大きなストレージ容量を提供できるノードが販売されていますが、Nutanixの場合は、ストレージ専用ノードとして動作し、仮想マシンが稼働しないホストを提供します。

    しかし、ストレージ専用ノードと行っても、HCIである以上ハイパーバイザーも必要ですし、Nutanixの場合、CVMも必須コンポーネントになります。では、ストレージ専用のノードがどのようなメリットがあるのでしょうか。

    下の図を見て頂くと分かるのですが、Nutanixのクラスターは、ストレージ専用ノードと仮想マシンが稼働する部分のハイパーバイザーを混在して構成することが出来ます。

    ▼1つのクラスターでハイパーバイザーの混在が可能


    では、ハイパーバイザーが混在した環境の場合、ESXiで稼動している仮想マシンがAHVにvMotion出来るかというとこれはできません。この環境の場合、ストレージ専用ノードは、AHVがインストールされたノードになります。AHVが稼動するノードはCVMだけが仮想マシンが稼動し、Nutanixクラスター内でストレージ機能のみを提供します。このAHV上で仮想マシンが動作することはできません。

    Nutanixは異機種・異世代混在が可能ですから、ESXiで稼動する部分には、高速なCPUや多くのメモリーを搭載し、ストレージ専用ノードは最小限のCPUとメモリーを搭載することで、ストレージにおけるエンクロージャーの追加のように低コストでストレージ容量だけを増やすことが出来ます。
     また、ハイパーバイザーもAHVを利用するため、追加のハイパーバイザー費用は、かかりません。

    HCIの悪いところを克服した、Nutanixのストレージノードは、従来「NX-6035C-G5」というストレージ専用ノードとして販売されていました。
    現在では、ストレージ専用ノードは、Nutanixで販売されているどのノードでもストレージ線のようー度に設定することが出来ます。

    Nutanixが提供するFoundationツールで、イメージングの際にストレージ専用ノードのチェックを入れてイメージングをすることで、任意のノードをストレージ専用ノードとして稼動させることが出来ます。

    ▼Foundation時に特定のノードをストレージ専用ノードに設定
     ストレージ専用ノード時に設定するAHVのバージョンも指定可能(Foundation 4.5.1)

    このストレージ専用ノードのチェックは、Foundation 4.0から搭載されました。
    また、Foundation 4.5からは、ストレージ専用ノードに対してイメージングするAHVのバージョンを指定できるようになりました。(4.4までは、インストールするAOSに搭載されたAHVバージョンが自動的に展開されていました)


    Nutanixは、ユーザーが便利に、もっと言えば、ITインフラを気にしなくて良い環境を提供することが理念です。そのためHCIによってデメリットが出てくる部分において、そのデメリットを解消する技をちゃんと用意しているところが、Nutanixの魅力的なところの1つだと思います。




    2019年12月24日火曜日

    Flashモードのご紹介

    Nutanixは、AllFlashモデルやNVMeモデルもありますが、売れ筋はSSDとHDDのハイブリッドモデルです。
    Nutanixは、SSDもHDDもキャパシティ領域として利用するいわゆるティアリングでよく使われるデーターをHOTデーターとしてSSDに配置し、使うことが少ないデーターをCOLDデーターとしてHDDにおく動きを自動的に行ってくれます。

    この場合HOT、COLDの各データーはアクセスされている頻度によりますから、あまりアクセスされないデーターはCOLD扱いとなりHDD層に保存されることは理解できるかと思いますが、定期的にしかアクセスされないが、アクセスするときは高速に動作してほしいという仮想マシンも時々あるように思います。

    例えば、月初に前月の請求書を一括でPDF出力する帳票サーバーやバッチサーバーなどがそれにあたると思います。

    このような、普段は使わないけど、いざ使うときは負荷がかかるのでSSDに配置してほしいという希望を叶える機能として「Flash Mode」という機能がNutanixには存在しています。

    このFlashModeは、「ピニングモード」と記載されているドキュメントもありますが、ピニングモードは従来の名称で現在は「Flash Mode」が機能の名称となります。

    このFlashModeは、Extend Storeの25%までの領域をFlashModeで利用できる領域として利用できます。つまり、FlashModeを有効にすればかならずすべてのデーターがSSDに配置されるというわけではないことを理解しておきましょう。

    Flash Modeは、仮想マシン単位の設定の場合、Prismの仮想マシン設定画面の一番下でFlash Modeの有効か設定が可能です。

    また、Volume Groupにおいても同様にFlashModeの設定が可能です。

    このFlash Modeは仮想マシン単位であればPrism上で設定可能です。
    一方でREST APIを利用すれば、仮想ディスク単位で設定することも可能です。

    この場合、まず仮想マシンで、「Enable Flash Mode」で仮想マシン全体を、Flash Modeの設定にした後、Flash Modeの対象から外したい仮想ディスクに対してFlash Modeを無効化するという作業になります。

    なお、この作業はREST APIを利用して行います。
    APIの発行は以下の通りです。(メソッドはPUTを利用します。)
    https://CLUSTER-VIP:9440/api/nutanix/v2.0/virtual_disks/

    投入するJSONは以下の通りです
    {
      "uuid": "仮想ディスクUUID",
      "flash_mode_enabled": false
    }

    RestAPI Exploreからでも実行することが可能です。

    この命令が成功するとステータス200が帰ってきます。

    仮想ディスクごとのFlash Modeの設定状況は、Prism画面で仮想マシンを選択後、下側に表示される「Virtual Disks」で、確認することが出来ます。

    様々なディスクの接続形態で試してみましたが、デフォルトであるSCSI以外にもSATAでもIDEも関係なく、Flash Modeの設定は可能なようです。

    では、最後にFlash Modeについて注意事項を含めてお知らせします。

    • Flash Modeは、仮想マシンのライブマイグレーションには影響しません
    • HOTデーター及びCOLDデーターの分析情報をストレージコンテナ事に持っているため、Storage vMotionを行うと、Flash Modeの効果が出るようになるまで時間がかかります。頻繁にStorage vMotionを行うと、Flash Modeの恩恵は受けにくくなります。
    • ストレージの圧縮及びキャッシュレベルの重複排除には影響しません。
      ただし、キャパシティの朝服排除設定時はFlash Modeは利用しないで下さい
    • クローンされた仮想マシンは、Flash Modeの設定は保持されません。(Flash Mode無効か状態でコピーされます)
    • スナップショットからリストアされた仮想マシンは、Flash Modeの設定が保持されないため、手動で有効の設定が必要です
    • 複数モデル混在のNutanixクラスターの場合、モデルによりSSD搭載容量が異なるため、Flash Modeの動作が必ずしもどのホスト上で稼動しても一定にならない可能性があります。
    • Flash Modeを利用するためには、Nutanix Clusterに対してUltimateライセンスが必要になります。


    Flash Modeを活用しなくても、Nutanixは、SSDをキャパシティ領域として利用しているため、SSDの容量が一定以上になるまではSSD上にデーターを保存し、ハイブリッド環境であっても、オールフラッシュモデルに近いパフォーマンスを発揮します。
    そのため今回ご紹介した、Flash Modeがすべての環境下において有効な機能では無いと思いますが、仮想マシンが多く稼働する環境下で、データーベースやバッチ処理を行うサーバーなど、利用状況に寄らずハイパフォーマンスを必要とする仮想マシンに対して、一定のパフォーマンスを提供するためには、有効的な機能の1つとなるかと思います。












    2019年12月23日月曜日

    Nutanix Moveのよくある質問とポイントをご紹介

    Nutanix Moveは、すごく簡単に仮想マシンをNutanixクラスターに移行してくれるというのは、ご理解いただけたと思います。今回はNutanix Moveでよく聞かれる質問をご紹介したいと思います。

    Q.Nutanix Moveは、どういう課金方法で提供されますか?

    Nutanix Moveは、Nutanix Cluster(有償製品)を保有している場合、無償で利用することができます。Nutanix CEをご利用でNutanix Moveをご利用になりたい方もいるかと思いますが、現状Community版のNutanix Moveは提供されておりません。


    Q.Nutanix Moveで移行がサポートされないゲストOSはどうすればいいのでしょうか?

    Nutanix Moveは原則、AHVが対応しているゲストOSの大半をサポートしていますが、一部サポートされていないゲストOSやそもそもAHVが本来サポートしていないレガシーなOSをAHVで稼動させたい場合があるかも知れません。
    Nutanix Moveは、既存ゲストマシンに対して、VMware Tools/WinRM等を利用してVirt IO Driverなどの必要なものをあらかじめインストールするなど、ほぼ全自動で移行が終えられるように作られています。サポートされていないOSの場合これらの事前準備時点でエラーが出てしまい、そのままでは移行することが出来ません。
    この場合、事前にVirtI/O Driverなどの必要ドライバーを手動でインストール後、Nutanix Moveの移行時に、Preparation Modeを「Manual」に設定し、仮想ディスクのデーターだけをAHVのNutanixクラスターにデーター移行を行うことも可能です。
    出来た仮想ディスクを元に仮想マシンを作成し、あとは必要な設定を入れれば移行を完了させることが出来ます。データー転送だけ異をNutanix Moveにお任せする機能を使うだけでもファイル移動に比べて大幅に減らす事が出来ます。



    Q.Nutanix Moveの仮想アプライアンスは、AHV側に立てた方がいいのでしょうか?それとも旧環境の3Tier環境に入れれば良いのでしょうか?

    Nutanix Moveは、ネットワークを通じて既存クラスターのデーターをvSphereの場合はVADPを使って取得し、NutanixクラスターのストレージコンテナをNFSでマウントしデーターをマウントしたストレージコンテナに配置をします。
    いわゆる仮想環境におけるバックアップとおなじ考え方でデーターを取得します。
    この場合、既存3Tier環境とNutanixクラスターの間のネットワーク帯域を比較して配置するのがよいと思います。
    3Tier環境とNutanixクラスターの間が10Gのネットワークで接続されている場合、3TierでもNutanixクラスターでもどちらにMove仮想アプライアンスを立てても速度に変わりは無いと思います。一方、3Tier環境とNutanixクラスターの間が1Gで接続されている場合は、Nutanix環境に配置すれば、バックアップデーターをNutanixに配置する際は、CVMとダイレクトに通信が出来る環境になるため、高速にバックアップデーターを配置できるようになります。


    Q.Nutanix Moveを利用するにあたって注意することは何かありますか?

    ゲストOSを移行するにあたっては以下のことを確認することが大事です。
    • 対応しているハイパーバイザーのバージョンを確認
      (ESXi5.1/Hyper-V2012~)
    • 対応しているゲストOSの確認
      (既にOSメーカーがサポートを終了したOSは原則非対応)
    • VMware Toolsがインストールされていること
    • OSのAdministrator / root権限のアカウント情報がわかること
    • Windowsの場合、UACがオフになっていること
    とくに、UACが向こうになっているかのチェックは、忘れがちですがこれは無効かしておかないと、VMware Toolsなどのツール経由で必要なファイルをゲストVMに送った後、インストールスクリプトが実行されますが、そこでUACの確認画面が裏で表示され、制御ができないため、途中で処理が中断してしまいます。

    ▼ゲストVMを移行前にUACは"通知しないに"しておきましょう



    Q.vCenter Serverが存在しない単独のESXiホストの仮想マシンは移行できますか?

    Nutanix Move 3.2以降で、ESXi単独環境でvCenter Serverが存在しない環境でもNutanix Moveを利用することができます。ただし、VDDKのAPIを利用する関係からESXiのライセンスがvSphere Hypervisor(無償ライセンス)では、Moveを使った移行は対応していません。


    Q.3TierのvSphere ESXiの環境からNutanix+ESXiの環境移行で利用できないですか?(Nutanix Moveの移行先はAHVのみでしょうか?)

    Nutanix Move 3.3から、移行元vSphere(ESXi)環境から、Nutanix+ESXiの環境においても、仮想マシンの移行が出来るようになりました。従来は移行元のvSphere環境からNutanixのストレージコンテナをNFSでマウントしてストレージvMotionなどを使って、ストレージを移行することで、仮想マシンの引っ越しを実現していました。
    しかし、既存vSphere環境を触りたくない(設定変更が許されない)場合もあるかと思います。そういった場合に、Nutanix Moveを利用することで、既存のvSphereからNutanix+ESXi環境への仮想マシンの引っ越しを、短いダウンタイムで行うことが出来ます。なお、ESXiからESXiへの引っ越しとなるため、Driver等のツールの流し込みはなく仮想ディスクファイルの引っ越しのみの動作となります。


    以上、Nutanix Moveについての注意点やよくある質問をまとめました。
    Nutanix Moveは無償で提供されていますが、大変よく出来たツールだと思います。
    従来のV2Vにおけるダウンタイムに比べ圧倒的にダウンタイムを短くすることが出来ますので、仮想マシン移行の際は是非活用をおすすめします。









    2019年12月22日日曜日

    AHVへの引っ越しは、Nutanix Moveで HyperV編(その2)

    前回までに、Moveを使って仮想マシンの移行準備を行いました。
    今回は、実際に仮想マシンをAHVにマイグレーションします。

    移行前に、Hyper-V上でデスクトップにファイルを作成しておきましょう。

    では、Moveの画面にいき、仮想マシンにチェックを入れCutoverボタンをクリックします。

    カットオーバーを行うと、仮想マシンがシャットダウンされ仮想NICの接続が切断される旨が記載されています。このまま「Continue」をクリックします。

    イベントログを見ているとチェックポイント処理が行われ最終のスナップショットが送られていることが分かります。


    既に移行処理が完了していると出ていますので、Prismで確認をします。

    移行前に作成したファイルもきちんとデスクトップ上に存在しています。
    また、デバイスドライバーもきちんとVirtI/O Driverになっていることが確認できます。

    Hyper-Vであっても、vSphere同様に簡単にAHVに移行が出来ました。

    今回のポイントは、Hyper-V第2世代仮想マシンの移行ということです。
    Hyper-V第2世代の仮想マシンは、 UEFIで作成されており従来のImage Serviceを使ったVHDXの変換だけではAHV上で仮想マシンを動かすことが出来ない状況でしたが、Nutanix Moveを利用すると、UEFIのまま仮想マシンを移行させることが出来ます。
    AOS5.11から、UEFIに正式に対応しましたので、Hyper-V第2世代の仮想マシンを移行する場合は、AOS5.11移行の環境を原則用意頂くことになります。
    (AOS5.10であっても仮想マシンに対してUEFIモードで起動させることは出来ますが、原則サポータブルではありません)

    ▼第2世代の仮想マシンを移行すると、AHVの仮想マシンも自動的にUEFIに設定される。

    以上、Hyper-V環境でのNutanix Moveを使った移行方法のご紹介でした。

















    2019年12月21日土曜日

    AHVへの引っ越しは、Nutanix Moveで HyperV編(その1)

    前回までに、ESXiからAHVへの移行が簡単にかつ、ダウンタイムをかなり短く行うことが出来ることが分かりました。
    では、今回はHyper-VからAHVへの仮想マシン移行についてご紹介します。

    今回は、Nutanix Move 3.4を利用して作業を行います。
    移行元環境は、Windows Server 2012R2で、第2世代の仮想マシン対応で構成された環境にWindows Server 2012 R2をインストールした仮想マシンを移行します。

    まずは、Nutanix MoveのSourceにHyper-Vを登録します。

    すると、add the environment と表示されしばらく待ちが発生します。
    このタイミングでHyper-Vホスト側にWinRM機能を利用して、MoveのAgentがインストールされます。インストール場所は、上記のSourceを登録する際のユーザープロファイルの配下にできあがります。この環境は、Administratorで登録をしていますので、「C:\Users\Administrator\Nutanix\Move\3.4」になります。
    併せて、「move-service.exe」 が、「Nutanix Move Agent」という名前でサービスに登録されます。

    なお、Move3.2までは、このAgentが日本語版のWindowsですとうまくインストールが出来ませんでした。これは、インストール時に利用しているPowerShellのコードが日本語に対応していないことに由来していましたが、Move3.3.1以降では、問題なく日本語環境でもインストールが可能です。

    もし、Agentのインストールに失敗し、Sourceの登録に失敗した場合、Agentを手動でHyper-Vホストにインストール後、再度Source登録することで成功する可能性が高いです。
    Agentバイナリは、Moveアプライアンスにhttp経由でアクセスします。
    http://<nutanix-move-ip>/downloads/agents/move-agent-installer.exe
    ダウンロードしたバイナリを、Hyper-Vホストにインストールします。

    なお、インストール時には以下のパラメーターを入力します。
    move-agent-installer.exe -o install <nutanix-move-ip> -u Administrator
    最後のAdministratorは、サービスを起動するユーザーに紐付きますので、Administratorと書きましたが、実際には管理者権限を保有したユーザーとなります。

    なお、AgentをインストールするとWindows Firewallにて、8087番のポートが開放されるルールが追加されます。このポート番号は、MoveとAgentがやりとりするために利用され、ポート番号を変更することはできません。

    では、続いて、マイグレーションプランを作成します。

    続いてソース環境とターゲット環境のNutanixを登録します。

    続いて、移行したい仮想マシンの「+」マークをクリックし、移動対象のVMに登録します。ここで!マークが表示されます。
    この内容は、セキュアブートに関する注意事項です。
    第2世代の仮想マシンでは、カットオーバープロセス中及びカットオーバーが完了するまでは、仮想マシンのセキュアブート機能は無効になります。カットオーバープロセスが終了すると、セキュアブート機能が再び有効化されます。

    ▼Hyper-Vで第2世代仮想マシンを作成するとデフォルトでセキュアブートが有効になる

    セキュアブートは自動的に無効にされ、移行終了後にHyper-V側のソース仮想マシンは元の設定に戻りますが、セキュアブートが必要でない場合はあらかじめチェックを外しておいてもよいかと思います。なお、セキュアブートの無効化は該当の仮想マシンがパワーオフ状態の時のみ設定変更が可能です。

    続いてネットワークのマッピングを行います。
    ここで出てくるにSource Networkは、Hyper-Vホストのアダプタになります。
    割り当てるネットワークは、仮想マシンが通信したいネットワークになります。

    この画面では、vSphere同様、ゲストOSへVirt IO Driverをインストールするためのcredential情報の入力を行います。vSphereの場合同様複数の仮想マシンを一括して移行する場合、仮想マシン個別のcredential情報を入力することも可能です。

    また、Move 3.4からタイムゾーンの設定項目も追加されました。
    ここでは、「Asia/Tokyo」を選択します。

    Hyper-Vの仮想NICに付与されたMac Addressをを引き継ぐ場合は、「Retain MAC Addresses form the Source VMs.」にチェックを入れます。

    最後にサマリーを確認し、「Save and Start」をクリックします。

    これで、Hyper-Vの仮想マシンにVirtI/O Driverなど必要なモジュールが、「C:\Nutanix」に配置されます。


    Hyper-Vマネージャーで確認すると、vSphereと同様にチェックポイント(スナップショット)が順次取得されているのが分かります。


     では次回に実際に、カットオーバーを行いAHVへの移行を行ってみましょう。









    2019年12月18日水曜日

    AHVへの引っ越しは、Nutanix Moveで(その5)

    前回までに仮想マシンの移行準備は完了しました。
    では、実際に仮想マシンをマイグレートしたいと思います。

    まずは、vSphereのスナップショットを見てみましょう。
    一段階目のスナップショットは既に転送済みで、2回目以降のスナップショットが送信されています。
    ▼2回目のスナップショット

    ▼3回目のスナップショット

    このスクリーン書ととを見ると分かるようにスナップショットは10分に一度送られていますが、スナップショットが多段になってI/Oスピードの低下や仮想ディスクファイル破損を防ぐため、スナップショットは2段階までとなっており、順次古いスナップショットが新しいスナップショットを作成される際に削除されます。

    では、データーの差分がちゃんと送られているかを確認すするため、移行する前に、移行元のWindows Server 2012 R2の仮想マシンにファイルを作成してみます。

    この検証は12/1に行っておりますのでその日付と時刻をテキストファイルに書いてデスクトップに保存します。

    続いてMoveの画面で、In Progressをクリックし、Windows Server 2008 R2をCutover処理を行います。

    確認処理が走ります。

    vSphere Clientを確認すると、移行元の仮想マシンは、シャットダウンスされ最終のスナップショットが送られていることが分かります。

    移行作業が完了すると、自動的にPrism上に仮想マシンが登録され、移行された仮想マシンが自動起動します。

    Prismを見ると仮想マシンが登録され起動していることが分かります。

    仮想マシンにログインすると、先程vSphere上で作成した仮想マシンにも移行前最終で作成したテキストファイルがきちんと移行されていることが分かります。


    今回はNutanix Moveの動きと共に移行方法を紹介しましたが、ユーザー側で操作することはMoveの画面で移行元と移行先を選択するぐらいで面倒な作業無く、任意のタイミングで切り替えが出来るというのは大変便利であることがわかります。