「最先端」から「最適解」へ！！ AzureStackHCIからHyper-Vへの 仮想基盤移行 グリーホールディングス株式会社 エンジニア　耕崎 稔生 マネージャー　磯田 典宏 

耕崎 稔生（こうざき としお） 新卒で入社した通信工事会社でSIer業務に 従事し、2024年にグリー株式会社（現：グ リーホールディングス株式会社）へ入社。 情報システム部のIT基盤チームとして社内 ITインフラを担当。 グリーホールディングス株式会社 情報システム部 エンジニア 2 

磯田 典宏（いそだ のりひろ） Linux系SIer、 事業会社の情報システム部 を経て、2014年にグリー株式会社（現：グ リーホールディングス株式会社）へ入社。 以来、情報システム部にて社内のITインフ ラを担当し、マネージャー・リードエンジ ニアとして従事 グリーホールディングス株式会社 情報システム部 リードエンジニア/マネージャー 3 

目次・アジェンダ ● AzureStackHCIとは ● 実際に運用してみて ● 移行への決断 ● まとめ 4 

AzureStackHCIとは 5 

AzureStackHCI(現AzureLocal)とは ● オンプレミス環境でAzureのサービスを実行するクラウドハイブリッドな基盤 ● Hyper-VとStorage Spaces Direct (S2D) がベースとして利用されている ● Azure Arc経由でAzureクラウドと連携し、オンプレミスリソースを一元管理 期待したこと: ● EOLを迎える既存Hyper-Vからの脱却と、新たな技術への知見の蓄積 ● オンプレミスとクラウドの柔軟性のある統合管理 ● 将来的なAzureサービス連携の推進 6 

AzureStackHCI仮想基盤の構成 ● グリーグループの社内システム用の仮想マシン格納基盤として利用 ● 各仮想マシンは以下のような役割を担っている（一例） ○ ActiveDirectory ○ DNS ○ 認証システム（複合機、MFAなど） ○ 基幹系システム（SAP） 7 

2023年のテックカンファレンスで導入についての話 AzureStackHCI導入時の(苦労)話 https://www.youtube.com/watch?v=PTBk7sRKwr0 8 

実際に運用してみて 9 

実際に運用してみて・・・ ● トラブルが多発し、順調な運用とはいかなかった ● ドキュメントを読み解くのが大変 ● サポートとの連携がうまくいかない部分もあった ● 具体的な(主にトラブル、障害)事例をいくつかご紹介します 10 

アセスメントの結果は良好 ● 日々の運用でトラブルが頻発していたため、設定や環境に問題がないかを確認する ためアセスメントを実施したが結果は「良好」 ● 残念ながら状況の改善につながるような情報はなかった 11 

トラブル事例のご紹介 12 

仮想マシンのパフォーマンス問題 ● 仮想マシンが遅い、接続できないといった事象が頻発 ● ホストの不安定さとCPU占有による処理待ちが原因 ● リソース追加、一部の仮想マシンを停止、物理PCへ移行するなどの対処 により多少の改善は見られたが、不安定な状態が続く 13 

管理ネットワークが突然通信不可になる ● ホストへのPing、RDPが突然不可になり管理できない状態に ● 対象ホストの仮想マシンがライブマイグレーション不可に ● ログ取得スクリプトで事象解消することを発見 ● iDRACに接続し管理NICの再起動で解消 14 

Mellanoxドライバー不具合① ● Mellanoxのドライバー起因で複数の不具合が発生 ● 前述の問題とは別にクラスター全体でライブマイグレーションが不可に ● 何かのタイミングで「MigrationNetworkOrder」の値が空欄となってしまう 15 

Mellanoxドライバー不具合② ● 本来1つだけのvEthernet仮想NICが複数生成される ● 削除してもNetworkATC修復コマンドを実行すると再生成されてしまう 16 

アップデートで事象解消？ ● 2023年の導入時から今年の5月に23H2へのバージョンアップを完了させ るまで不安定な状態が続いた ● OSバージョンアップ時にMellanoxのドライバーもアップデート ● 結果的には早々にアップデートして仕舞えばよかったのだが、トラブル対 応に追われていたこともあり期限ギリギリの今年5月末に対応 ● アップデートにより現在は安定しているように見えるが・・・ 17 

ファームウェアアップデート起因でクラスター崩壊① ● 昨年のテックカンファレンスの前日である10/24の夜に発生 ● ホスト追加対応の事前準備として、既存ホストのドライバー、ファーム ウェアアップデートを実施することを計画していた ● 仮想マシンを退避して1台ずつアップデートを実施する計画だったが、作 業中のホストとは別のホストが自動的にドレイン、再起動してしまう ● ドレインから復旧させようとするもうまくいかず、約2時間程度クラス ターが停止した状態となってしまった 18 

ファームウェアアップデート起因でクラスター崩壊② ● クラスター復旧後も仮想マシンの動作が不安定 ● iDRACからホストを強制再起動し安定するように ● 仮想マシンの復旧、確認まで完了した頃には翌朝の5:00に ● 「あー 昨日3時間しか寝てねーからつれーわー」状態でテックカンファレ ンスへ参加 ● 当日も少し障害発生していたため、ブース内で密かに対応 ● 後に原因確認するとアップデート作業時の高負荷状態が原因とのこと 19 

NetworkATCIntentエラーの調査中に障害発生① ● Failedエラーが発生していたためサポートに問い合わせ ● エラーステータスは「AdapterBindingConflict」であることを確認 ● サポートから「AdapterBindingConflict」解消用の手順を提示される 20 

NetworkATCIntentエラーの調査中に障害発生② ● 提示されたコマンドが下記 Set-NetAdapterBinding -Name 'Mellanox Port1' -ComponentID vms_pp -Enabled $false Set-NetAdapterBinding -Name 'Mellanox Port2' -ComponentID vms_pp -Enabled $false Set-NetIntentRetrystate -Name 'compute_storage' -NodeName $env:ComputerName -Wait ● 実行するとバインドは無効化されるがリトライコマンドには失敗し、対象 ホスト内の仮想マシンと疎通不可の状態となってしまった ● プリンタ認証、MFA通知など一部社内システムにサービス影響発生 21 

NetworkATCIntentエラーの調査中に障害発生③ ● 対象ホストの仮想マシンをクイックマイグレーションで退避しサービスを暫定復旧 ● 対象ホストを再起動するも改善されず ● 確認したところ本来存在しないはずのvSwitchが生成されており、これを削除する ことでリトライコマンドでの修復が可能となった 22 

NetworkATCIntentエラーの調査中に障害発生④ ● 「AdapterBindingConflict」の解決方 法について2パターンのシナリオが記載 されており、サポートからはシナリオ2 の解決法が提示されたが、今回はシナ リオ1の手順で解決 引用元： https://learn.microsoft.com/ja-jp/windows- server/networking/network-atc/network-atc 23 

反省 ● サポートから提示された手順については影響まで確認する ● ドキュメントをよく読み理解する ● 状況認識に齟齬がないようにする ● サポートに緊急事態であることをしっかり伝える 24 

移行への決断 25 

23H2アップデート時にも障害発生 ● 期限ギリギリで23H2のバージョンアップとMellanoxドライバー含む ファームウェア関連のアップデートを実施 ● ベンダー推奨はWACからの自動ローリングアップデート ● こちらがコントロールできない状態をなるべく避けるため、各ホスト個別 でのアップデート手順を選択 ● 23H2アップデートは正常に完了したが、クラスター機能レベルの更新を 実施したところで障害発生し、仮想マシンが停止してしまった 26 

23H2アップデート工程概要 1. 対象ホストから仮想マシン退避し、クラスターからドレイン 2. ファームウェアアップデート、OSアップデートの実施 3. アップデートしたホストをクラスターへ復帰させる 4. 上記1−3の手順を残りのホストにも繰り返し実施 5. クラスター機能レベルの更新 6. 記憶域ストレージプールの更新 7. 動作確認 27 ここで障害発生 

アップデート前提条件の読み違いが発覚 https://learn.microsoft.com/ja-jp/azure/azure-local/upgrade/upgrade-22h2-to-23h2-other-methods?vi ew=azloc-2504#complete-prerequisites ドキュメントに記載されているアップデート前提条件 ● Azure ローカルで実行されているバージョン 22H2 にアクセスできます。 ● システムは Azure に登録されています。 ● Azure Local バージョン 22H2 インスタンス内のすべてのマシンは正常であり、 オンラインとして表示さ れます。 ● 仮想マシン (VM) をシャットダウンします。 データベースの予期しない停止や損害を防ぐために、OS アップグレードを実行する前に VM をシャットダウンすることをお勧めします。 ● Azure Local 用の Azure Stack HCI バージョン 23H2 OS ソフトウェア更新プログラムにアクセスできま す。 この更新プログラムは、Windows Update またはダウンロード可能なメディアとして利用できます。 メディアは、 Azure portal からダウンロードできる ISO ファイルです。 ● Azure ローカル インスタンスに接続できるクライアントにアクセスできます。 このクライアントは PowerShell 5.0 以降を実行している必要があります。 28 

サポートからの回答 ● サポート回答「全ての工程において全ホスト、全仮想マシンを停止した上 でバージョンアップを実施していただくのが推奨の手順となります」 ※S2Dのため整合性が取れなくなる恐れがあり停止推奨とのこと ● 今後重要メンテナンスのたびにAcitiveDirectoryや基幹システムなど社内 システムを約半日近く止めなければいけないことに。。。 29 

AzureStackHCIの厳しい拡張制限 ● 外部ストレージの利用は不可 ● 拡張可能なHWは完全に同一構成の同一筐体に限られる ● ハード終売、EOLになったら？ 　→実際に導入していたAX-7525が終売に 　→今後、AzureStackHCIの仮想基盤は拡張不可・・・ 30 

もう1つの仮想基盤の問題 ● アプライアンスやLinux系メインのVMware仮想基盤 ● 永続ライセンスが廃止されサブスクリプション化、更に値上げ ● 機能的にはvSphere Enterprise Plus （VEP）ライセンスで十分 だったが、廃止され購入不可となってしまう 31 

新仮想基盤としてHyper-Vを選択 ● AzureStackHCIから「逆」移行の形となるがあえてHyper-V ● 現状の仮想マシンの状況では、メンテナンスのたびに全停止が推奨されるS2D 基盤での運用は現在の弊社環境とは合っていないことがわかった ● 将来的にVMware環境を廃止し、仮想基盤、コスト管理を一本化しシンプルに ● これまでのAzureStackHCI、Hyper-V管理経験を活かすことができる ● ハードウェアの選択肢が広く、柔軟な拡張も可能 32 

仮想マシン移行に課題あり ● AzureStackHCIからHyper-Vへの仮想マシン移行はサポート外（不可） ● エクスポート、インポートでご対応くださいという回答・・・ ● バックアップ、リストアを利用し以下手順で移行可能なことを確認 ○ 仮想マシン停止 ○ 既存のクラスターから仮想マシンの役割を削除 ○ 仮想マシンのバックアップ ○ 新Hyper-V上にバックアップした仮想マシンをリストア ○ 新クラスターに所属させて起動 ● 今後計画的に実施していく予定 33 

まとめ 34 

まとめ - 「最先端」から「最適解」へ！！ 最先端が、必ずしも最適解ではない ● 新しい技術への挑戦は重要だが、それ自体が目的ではない ● 自社の環境、コスト、ニーズに合った「地に足の着いた IT基盤」が最重要 ● トラブルのない安定稼働によりIT部門がビジネスに貢献することができる 成果と展望：攻めの IT部門へ ● 今回の「逆」移行は、一時的なトラブル回避ではなく、「最適化」 ○ Hyper-V→AzureStackHCI→Hyper-V ● グループ全体の成長を促進する「攻めのIT」を推進したい 35 

宣伝：情シスブース（Booth4） ● イルカちゃんとお話しできます マルチAIエージェントによる問い合わせ窓口「バーチャルサービスデスク イルカちゃん🐬」のデモを公開中です。Tech Conferenceのセッションや 展示内容について回答してくれますので、ぜひ話しかけてみて下さい。 ● 情シスのお仕事紹介冊子、ノベルティを配布してます 昨年に続き、社内システムのカオスマップや各チームの取り組み、トラブ ル事例などを紹介した冊子と、各種ノベルティも配布していますので是非 お立ち寄りください。 36 

ご清聴ありがとうございました 37 

No content