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の良さの一面を感じます。