記憶域の容量確認における変化
新澤千明氏：次にいきます。これで構築は終わって、いよいよ運用を開始しました。ここに至ってもちょっといろいろありました。
運用編、はじまり。記憶域のサイジングについてです。すでに既存のHyper-Vクラスターの古いやつがあったので、そこから移行対象の仮想マシンを調べて、必要なストレージ容量は算出できていました。
ここで注意すべき点があるのですが、容量について、Azure Stack HCIから警告が発せられることは特にないということです。調子に乗ってじゃんじゃん仮想マシンを作っていたら、いつの間にか容量がカツカツのギュウギュウなんてこともあり得ます。
2023年の春の状況ですが、容量超過についてAzure Stack HCI側から警告される機能はなにもありませんでした。自分で確認して、余裕を持ってディスクの空きを確保する必要があります。
WACの場合はVolumesの中を直接見る必要があるということですね。Toolメニュー、Volumesの中のディスク容量を確認する必要があります。
弊社のWACではVolumesの容量を確認してから仮想マシンを追加するという、地味な方法でやっています。
だったんですが、WACのバージョン2306、2023年の夏のバージョンですが、WACのダッシュボードに容量警告機能が付きました。ダッシュボードのところです。自分でダッシュボードを見る必要はあるんですが、ちょっとだけ便利になりました。クリック数が少しだけ減りました。
仮想マシン転送は夜間メンテナンスで
次のスライドにいきます。運用編の仮想マシンの転送についてです。1行で書いてありますが、メチャクチャいろいろありました。
なんとか構築はできて仮想マシンが動作するようになりました。そうなると、次は既存のHyper-V仮想環境で動かしている仮想マシンを、Azure Stack HCIに移行しなきゃなりません。社内サーバーだけですが、それでも100個ぐらいはありました。
このセッションに参加されている方にとっては、100個なんて別に珍しくないと思います。むしろ少ないほうじゃないでしょうか。ただ、今回は時間制限がありぶっつけ本番だったということもあって、精神的にはかなりヒリヒリしたものとなりました。
ここでMS（マイクロソフト）さんから助け舟がありました。「Azure Migrateを使ってみませんか？」と。Private Preview中のやつですね。招待いただき、試してみることになりました。仮想マシンを旧来のHyper-VクラスターからAzure Stack HCIへ移行させる機能のPrivate Preview中でした。2023年の春です。
Azure Migrateを用いた既存のHyper-V環境から仮想マシン移行は、日本初の事例だったそうです。Azure to Azureの転送では同様のシステムがすでにリリースされていて、リージョン間の仮想マシン転送は数秒で終わるそうです。「これは期待できるな」「これで助かる」と思いました。（しかし）次のスライドにいく前に結論を言っちゃうんですが、残念ながら使っていません。
MSさんの名誉のために言うと、Private Preview中のため、まだ機能に制限があって、残念ながら速度がぜんぜん出なかったんですね。これは今後改善されていくと公式から答えていただいています。なので期待して待ちたいと思います。ちょっと弊社は試すのが早すぎました。タイミングが合わなかった感じです。
というわけで、これからお話しするAzure Migrateについては、2023年4月の情報になっています。現在はどんどん性能が良くなっていると思うので、興味のある方はちょっと調べてみてください。
（仮想マシンを旧来のHyper-VクラスターからAzure Stack HCIへ移行させる機能を）使わなかった理由です。使わなかった理由としては、まずは当時マイグレートに時間がかかった上に、その間に仮想マシンがダウンしてしまうことが1つ目の理由でした。
弊社の環境ではありますが、仮想ディスクはWindows Serverの最低要件の32Gぐらいで作った記憶があります。その容量で、転送に20分から30分ぐらいかかりました。
次にネットワークアダプターの設定に関してですが、仮想マシンのネットワークアダプターが消えて新しいアダプターになっちゃいます。消えちゃいます。ネットワークアダプターにあるWindowsだと、Ethernet1とか2とかあると思いますが、あれが消えて、Ethernet3とかが勝手にできています。
しかも、固定IPアドレスは、転送元に設定されていた仮想基盤にあった時のアダプターごと消えちゃいました。移行後に自動で付け替えられたネットワークアダプターはDHCPになっています。サーバーセグメントにはDHCPを立てていなかったので、どこにもつながらないんですね。それに気づくまで、ずっとサービスダウン状態になっていました。試験中です。
そんなこんなで「なんかまだ制限が多いね」という気持ちになっちゃいまして、使うのをやめちゃったという経緯があります。ただ、今後機能拡充されていくと思うので、MSさんの今後の開発に期待しています。次回機会があったら使ってみたいです。
ちなみに、Azure Migrateのことをもう少し話すと、Private Preview中は、転送を管理してくれるVMを、Azureの日本リージョンに設置できませんでした。その時は設置が許容されているus-centralのリージョンに設置することになったんですが、ここでやや不安になったのは、転送する仮想マシンの大きなデータが、日本のリージョンからUSのリージョンまで行って戻ってくるんじゃないかということです。大陸間を行き来されたら、大変な料金と転送量に跳ね上がってしまいます。
こちらは念のためMSさんに確認したんですが、管理VMとやりとりをするのはメタデータのみであり、仮想マシンのディスクの大きなデータはオンプレtoオンプレ、アメリカまで行って戻ってくることはないということなので、Azure転送コストはかからないということでした。小ネタでした。
次にいきます。でもって「結局、転送はどうしたの？」というところですが、先ほどちょっとだけ話した物理のバックアップアプライアンスを弊社では使っていまして、既存のHyper-V基盤もアプライアンスのバックアップ対象に入っていました。そのため、exportコマンドでなければ転送できない仮想マシン以外は、アプライアンスのGUIを使って転送できてしまいました。
さすがにライブマイグレーションはできませんが、ダウンタイムは1つのマシンにつきだいたい15分ほどで、止められない仮想マシンはすべて冗長構成になったので、これは特に問題はありませんでした。冗長化していない仮想マシンも、15分なら許容範囲だろうということで、夜間メンテナンスでやっちゃいました。
今ちょっとだけ話したexportコマンドでなければ転送できないマシンというのは、仮想マシンの中にはフェールオーバークラスターになっているものがあって、フェールオーバークラスターになっていると、そもそもスナップショットが取れないわけですね。 前述のバックアップアプライアンスはスナップショットを取ってバックアップを取る仕組みになっていたんですが、それができない。そんなわけで、昔ながらのexportコマンドで直接書き出すことになりました。一番安定しました。
旧基盤からAzure Stack HCIのCluster Shared Volumeへ直接書き出せるので、準備する時間さえあれば、始めからすべての仮想マシンをexportコマンドで書き出したほうが早かったかなと今となっては思っています。ダウンタイムも短かかったです。旧基盤からアプライアンスに読み込んで、もう1回Azure Stack HCIに持ってくると手間がなくなるので、単純計算して半分ですね。そのほうが早かったかもなと今となっては思います。
あとはNLBの話ですね。仮想マシンの中にはNLBを組んでいるものがあって、NLBを組んでいると、旧クラスターと移行先のAzure Stack HCIの間にあるネットワーク機器にNLBのVIPのMACアドレスを設定しないといけません。書いてわかったあとは簡単なんですが、これに気づくのにも時間がかかりました。
仮想マシンの運用管理をWACでするか、SCVMMでするか
次にいきます。小ネタのWACの話です。WACですべて管理できると思っていました。
既存のHyper-V基盤は、SCVMM（System Center Virtual Machine Manager）と呼ばれているやつを利用して、仮想マシンの運用管理を行っていました。
噂話レベルですが、今後SCVMMはあまり更新が行われなくなるだろうという話を聞いていたため、「だったらもううちは新しいしWACを使おう。うちのチームではWACに統一しよう」という話になりました。
これも先に結論を言ってしまいますが、そうはなりませんでした。SCVMMでは「ユーザーロールで仮想マシンごとに権限を分けて、そのチームの人はそのマシンの起動・終了、管理権限を付与する。別のチームの人には付与しない」ということができますが、今のWACでは残念ながらそれができません。
今のところの情報ですが、今後の開発計画にも入っていないそうです。今のところ弊社では大きな問題にはなっていないのですが、SCVMMでの運用を復活させるべきか、ちょっと悩んでいるところです。
さらに障害が発生した時、仮想マシンがWACから消えてしまうことがありました。消えちゃいます。これを復旧させるために、Hyper-V Managerやフェールオーバークラスターは、結局引き続き通用することになっています。
次にいきます。仮想マシンをノード間移動させた時に、意図しないノードに移動した件です。これは現在のWACのバージョンではもう改善されています。
2023年4月に構築した時点でWACの管理画面から仮想マシンのノード間移動を行うと、謎の挙動をしていました。UI上は転送先ノードを選べるのですが、実際はシステムによって内部でrecommendedされたノードにしか移動しません。実行されるコードがそうなっていました。いかにも転送先ノードを選べるようにはなっていたんですが、なぜか必ずおすすめノードにしか行きませんでした。
当時は自分で意図したノードに行かせたい時は、仕方なくFailover Cluster Managerかコマンドで移動させることにしていました。WACを2306、2023年の夏のバージョンに更新したら、UIで指定されたノードに移動するようになっていました。MSさん、ありがとうございます。
クラスターのストレージの容量が足りない事件
最後に、クラスターのストレージ容量追加についてです。トラブル発生・容量が足りない事件です。サイジングはしていたんですが、あとから「足りなくない？」という事態が発生して大変困りました。外部にiSCSIとかのオブジェクトストレージがあったので、これをマウントして仮想マシンのイメージ置き場にすればいいかなと簡単に思っていたんですが、Azure Stack HCIは外部ストレージをマウントできないんですね。その時に知りました。もう大ピンチです。
今後どうなるかはMSさん次第ですが、当時はとにかくできませんでした。MSさんに問い合わせて軽く絶望しました。「容量追加したい時はノードを増やせ」と。どんどんどんどん積み重ねていくしかありません。
結局、移行する仮想マシンの中にいらないファイルを大量確保しているものが見つかったので、これを減らして対処はしました。ですが、HCIみたいにほかのオブジェクトストレージを追加することは今のところできないので、注意が必要です。
Azure Stack HCIの構築・運用・つまずきポイントのオンラインセッションで話す内容は、こちらで以上となります。まだ情報が少なく、なかなか一筋縄ではいきませんが、これからの知見が蓄積されることを願っています。みんなで幸せなAzure Stack HCIライフを送りましょう。
みなさま、ご清聴ありがとうございました。
