構築方法というより泥臭い、キラキラしていない物語
新澤千明氏：みなさん、こんにちは。グリー株式会社・開発本部情報システム部の新澤千明と申します。本日は会場にお集まりいただき、また配信をご視聴いただき、ありがとうございます。
当セッションでは、MS（マイクロソフト）の仮想基盤、Azure Stack HCIの導入で得られた知見というか、つまずきポイントを紹介します。
いろいろなことに当てはまると思いますが、なにごとも理想的な青写真のとおりにトラブルなく進み、完成して運用できることはなかなかありません。実際、今回の構築と運用では大小さまざまなトラブルに見舞われました。
詳しい方にとっては予測のつく事象ばかりかもしれませんが、私のように急に投入された方にとっては心の準備になるかもしれません。話す内容も、構築方法というよりは実体験から得られた、とてもとても泥臭い、キラキラしていない物語になっています。
そんなわけでセッションを始めます。では続きのスライドにいきます。（スライドを示して）本日はこんな内容を話します。この目次はちょくちょく出てきます。
Azure Stack HCI導入の利用目的と構成
でははじめに、導入編の利用目的と構成について話します。はじめに簡単な構成図を説明します。Azure Stack HCIに限らず、仮想基盤は弊社の契約しているデータセンターに設置されています。弊社の六本木オフィスをはじめ、各拠点と接続し、仮想基盤に格納された各サーバーや、物理サーバーにユーザーが接続できるようになっています。
Hyper-Vクラスターはリプレイスを行って、今回話すAzure Stack HCIになりました。Windows Server、仮想マシンは今ここに格納されています。
（スライドを示して）下にあるサーバーには他の物理サーバーとか、vSphereクラスターが存在します。ファイルサーバーは物理のものもあります。バックアップアプライアンス、物理のものがデータセンターに設置されています。
右側の吹き出しに、Azure Stack HCIにどんな仮想マシンが入っているかをざっくり記載しました。ADの認証系とかDNS、DHCP、基幹システムとファイルストレージ、諸々100VM弱というところです。
というわけで、社内ではわりと重要な位置を占めたシステムになっています。
なぜAzure Stack HCIを選んだのか
次は「どうしてAzure Stack HCIにしたの？」というところです。きっかけは、弊社で運用していた既存のHyper-VクラスターがEOL（End Of Life）を迎え、リプレイスが必要になったことです。Hyper-Vクラスター、Hyper-Vの仮想基盤を検討しているうちに、Azure Stack HCIの名前が挙がったわけです。
最終的に選定された理由には、将来Azureとオンプレの仮想基盤の移動も構想に入っているということがありました。また、Azure portalからオンプレ、仮想基盤を管理する機能は、すでにもう実装されています。
オンプレとAzureの仮想マシン統合。これは大変夢がありますよね。とはいえ、Azureからオンプレの仮想マシン管理は、残念ながら今のところ弊社では運用していません。
とりあえずオンプレのHyper-Vクラスターとして構築しました。でも、将来的にはAzureと連携したいと思っています。
また、将来的にはディザスタリカバリーとしてAzure Site Recoveryを使って、クラウドのAzureとAzure Stack HCIのオンプレの間の仮想マシンの相互移行ができるようになると聞いています。現在のところまだ実装されていないそうなので、今後に期待したいです。大変期待しています。
オンプレに置ききれない仮想マシンをAzureに持っていったり、とりあえずAzureで立てちゃった仮想マシンをずっと動かしているんだったら、コストの安いオンプレに持っていくことが柔軟にできるかなと思っています。この機能を期待してAzure Stack HCIを導入したというところが、理由としてはとても大きいです。MSさん、実装を大変期待しています。
「そもそもなんで仮想マシンを動かす基盤をオンプレにしたのか？ クラウドじゃないの？」というところですが、弊社では社内システムで運用するサーバーは、あまりスケールアウト・スケールアップすることがないんですね。リソースも導入前に決めやすいということがあります。スケールアウトの必要が低いなら、オンプレのほうがコストは低くなります。これが理由の大きな部分を占めています。
また、障害が発生した際に、調査対象はすべて自分の手元にあるため、切り分けが容易な場合が多いです。クラウド上の仮想基盤の場合は、情報の開示があるまでどこに問題があるかわからず、手を出せないことが多々あります。というところが、弊社でオンプレを利用している理由になります。
構築と移行の流れ
次にいきます。構築を始めたところのお話をします。まず、構築と移行の流れです。基本的にはWAC（Windows Admin Center）で構築を行っています。今回の資料のほかに、クラスターノードを束ねるスイッチもありますが、本セッションでの説明は割愛します。
文字で書くと簡単そうに見えますね。文字で書くとこれだけなんです。（スライドを示して）結果としてこのような流れにはなっていますが、実際は何度も何度もトライ＆エラーを繰り返したので、スライドの流れとは異なりました。「最短でいけばこんな感じですよ」という理想です。
構築に関しては、それぞれ公式ドキュメントを確認してください。そもそも、構築方法も詳細はどんどん変わっていくと思います。
構成と構築方針
次です。構築編の構成と構築方針についてです。まずオンプレHyper-V基盤として動かそう。
弊社の構成ですが、Dell製のAX-7525の3ノード構成で組んでいます。CPUがAMDのやつですね。AXノードの上には同じくDell製のS5248F-ONが2台、冗長構成で接続されています。この下にクラスターがくっついています。
（スライドを示して）一応小ネタとして、スイッチについてですが、本当は24ポート構成のもので十分だろうと思っていたんですが、2022年当時、半導体不足で納期が遅れていたため、たまたま納期が早かった48ポート構成のものに土壇場で入れ替わりました。
ポート数的には現在やや持て余し気味ですが、同時期に導入したvSphere基盤のPowerEdgeの線もこちらのスイッチに収容したり、今後ほかのサーバーも収容予定のため、余裕がないよりは、多くて良かったかもしれません。
構築時に発生したトラブルから、OSの入れ直しに
次のページにいきます。次はいきなりOSを入れ直す話、実際の構築を始めた時のお話です。
先ほど言いましたが、構築の方針として、弊社ではWAC（Windows Admin Center）を利用することになりました。これはMSさんがLearnで公開している資料を参考にしています。ほかにもPowerShellで構築するドキュメントとかもありますが、好きなものを使えば良いと思います。
参考にしつつ構築したのですが、1ノードだけ挙動がおかしい状態で、いきなり泥臭い話になりました。調べたところ、WMI（Windows Management Instrumentation）が、サーバーを構築している時点で動作していないんですね。これはDellさんの納品が悪かったわけではないです。
WMIを立ち上げ直すだけだったら普通にサービスを動かすだけなのでできたんです。これまでに実装された構築と試験 があったみたいなんですが、何の設定が変わったのかなと思いつつ、今まで何があったのかよくわからず、（WACが）動作していないのか、WMIだけなのか、よくわかりませんでした。
詳細は割愛しますが、機器が納品されたあとこの構築作業が始まる前までに時間が経過していて、MSさん公式で配布しているAzure Stack HCI OSが、納品時の21H2から22H2に変わっちゃっていたこともありました。
このまま突き進んで運用開始後にいきなりバージョンアップして大変な目に遭うよりは、22H2に上げちゃいましょうということで、クリーンインストールすることにしました。
ただ、思えばこの時点でちょっと暗雲が漂っていました。
OS自体を入れ直す話の続きです。ちなみに、VMwareさんのESXiなどでは、ハードウェアごとに合わせたカスタマイズイメージが配布されたりしています。しかし、Dellさんに聞きましたが、「Azure Stack HCI OSの場合はカスタマイズイメージは特になくて、MSさんが公開しているものをそのまま使ってちょ」ということだったので、MSさんのサイトから落としたものをそのまま使っています。
そこで何が起こったかというと、マネジメント用ネットワークインターフェイスのドライバーがないんですね。Dellさんから納品された時点ではOSとドライバーをすでにインストールしてもらった状態になっていたんですが、OSを入れ直したからには、自分で入れ直しになるわけです。当たり前のことですが。
そんなわけで導入したDell AX-7525のAzure Stack HCI OSに適合するドライバーが必要なんですが、Dellさんのドライバーサイトにはありません。今回必要になったマネジメントNICはBroadcom製だったんですが、見つからないんですね。「ないぞ、ないぞ」と。
で、OS入れ直しに付随したドライバー入れ直しのお話です。まずはネットワークアダプターのほうです。
先に種明かしをしちゃうと、DellさんのAzure Stack HCI用のハードウェアのAX-7525は、同じハードウェアを使っているからPowerEdge R7525のドライバーを使えるわけです。すでに触っている方は知っていると思います。弊社もDellさんから聞きました。ただ、それを聞くまでは「ない。どこにもないぞ」と、わりと混乱していました。
あとで述べますが、Network ATCを構成するためには、WACを構築する前にBroadcomのNIC用ドライバーを入れておく必要があります。これが入っていないと、Network ATCの設定中にエラーが出ちゃいます。
このあたりは当時何が悪いのかわからず、構築作業中、何度も何度も画面を行ったり戻ったりしました。前述したとおり、最終的に探し当てたのはPowerEdge R7525用のWindows Server 2022用のものでした。
弊社の場合はこれが適合しました。やっとNetwork ATCに必要なドライバーが揃い、WACでの構築が進みます。
で、ドライバー入れ直しのお話のディスクのファーム編です。
ほかのドライバー、WACからDell OpenManage Integration with Microsoft Windows Admin Center、WACのアドインでインストールができるんですが、ディスクのファームウェアはOSが動いていると適用できないので、いったんシャットダウンしてiDRACからインストールを走らせる必要があります。
こうやって書いてあると「当たり前じゃない？」と自分でも思うんですが、当時はほかにも謎が多すぎて、問題の特定にはけっこう時間を要しました。メチャクチャ混乱していました。
次にいきます。ドライバー導入が終わり、ネットワーク構成をNetwork ATCで設定した際の話をします。先ほど話に出た、ネットワーク（の話のところ）で出た、Network ATCの話ですが、WACの構築中、設定中に誤ってNetwork ATCを使ってNetwork IntentのS2Dを通らせるところのMTUを、1514にしちゃったわけなんですね。
本当は大きい通信をするから9014にしたかったんですが、それまでの謎解きの数々でちょっと疲れていて思考力が落ちてイージーミスをしました。
このMTUを修正したいんですが、Network ATCで設定している以上、アダプターの設定をコマンドで直接書き換えても戻っちゃうわけです。テンプレートで設定したので、勝手に戻ります。
これを変更するコマンドを探していたんですが、公式ドキュメントに見つからなかったんですよね。結局、これは実機のコマンドの引数を調べて叩いて叩いて見つけました。（スライドを示して）スクショの黒いところですね。これが実際に叩いたものになります。
まず、実際にアダプターに設定されているMTUを確認して、Network IntentのMTUも確認しています。これで、私がうっかり間違えて設定したデフォの1514が表示されます。
でもって7行目、8行目で、MTUを9014にしたテンプレートを作って、10行目でネットワークアダプターにセット済みのNetwork Intentに反映させています。Set-NetIntentですね。Nameはそれぞれのアダプターの名前に変えてください。これで反映します。
公式ドキュメントを確認していないんですが、その後、もしかしたらコマンドリファレンスは更新されているかもしれません。もし私のようにうっかりNetwork ATC、MTUを間違えちゃったら、この情報を参考に設定してみてください。
構築はAzure Stack HCIの各ノードに入って進めるべき
構築編の最後は小ネタです。基本的なところですが、コマンドを実行する際、私は自分のローカルPCからPowerShellウィンドウにEnter-PSSessionで入って、ドキュメントにあるコマンドを実行していました。
どれだったか失念してしまいましたが、ちゃんとAzure Stack HCIのノードに直接ログオンしてからでないと、意図した挙動にならない、エラーになるものがありました。
なので、基本的にはすべてAzure Stack HCIの各ノードに入って構築を進めるべきです。基本的なところですが、初心を忘れていたので私はハマりました。
（次回に続く）
＜続きは近日公開＞
Published at
からの記事と詳細 ( OSとドライバーを入れ直し、MTUの再設定も実施 Azure Stack HCI構築のつまずきポイントを乗り越えた“泥臭い”物語 - ログミーTech )
https://ift.tt/cs5wSLC
No comments:
Post a Comment