SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Azure Stack HCI の評価時に参照するドキュメント

leave a comment

Azure Stack HCI の評価を実施する際に参照しておきたいドキュメントをまとめておきたいと思います。

システム要件

Azure Stack HCI のシステム要件については次のドキュメント / ドキュメントツリーから確認することができます。

Nested Hyper-V 環境で検証を行う場合は、構築をしながらシステム要件を満たすように構成を変更することができるので、評価環境であれば、厳密に構成要件を追う必要が無い / 実際の導入時には認定ハードウェアを使用することになるため、ハード的な要件をどこまで追えばよいかは気になるところではありますが、基本的には上記のドキュメントから必要になる情報を参照することができると思います。

HCI はストレージ / ネットワーク構成も重要となりますので要件としては次の情報も参照しておく必要があります。

  • Azure Stack HCI の物理ネットワーク要件
    • Management / StorageSwitch / ComputeSwitch 用に 3 つの NIC があるとよい気がします
    • SET は使用しなくても構築は可能ですが、SET を使用する場合はさらに NIC を追加する必要があります
  • 記憶域スペース ダイレクトのハードウェア要件
    • OS ドライブ以外に 2 ドライブが必要
      • 22H2 の 2 ノード構成を Nested Hyper-V で構築した場合、OS ドライブ / データディスクドライブ の 2 ドライブ構成でも初期構築ができたので、評価のための構成であれば OS ドライブ以外に 1 ドライブでも構築できるかもしれません

 

リリースノート

2023/5/16 時点の最新版は 22H2 となりますが、現在最新のバージョンがどのバージョンとなるのかを確認するためのリリースノートが公開されています。

Azure Stack HCI は毎年機能更新プログラムが提供されており、機能更新プログラムを適用しなくてはいけない期限が決まっています。

現在の最新である 22H2 であれば、2022-10-25 にリリースされたものとなり、更新の適用期限が 2023-04-25 となっています。そのため、21H2 という一つ前のバージョンが使用できるのは 2023-04-25 までとなります。

Azure Stack HCI は定期的に機能更新プログラムの適用が必須となる利用形態となりますのでリリースノートで、適用期限は確認しておいたほうが良いかと思います。

 

FAQ

Azure Stack HCI ならびに HCI の管理に必要となる Windows Admin Center の FAQ / 問題に重要な情報が記載されていることもありますので、情報の場所は抑えておく必要があります。

 

評価ガイド

Azure Stack HCI は日本語の評価ガイドが公開されており、評価する際には最初にこのドキュメントを確認しておくとよいかと思います。Azure を使用した評価環境の構築のステップから記載されていますので、評価環境の構築から情報を入手することができます。

 

 

評価環境の構築方法

評価メディアの入手

Azure Stack HCI は 60 日の無料試用版が提供されていますので、この期間であればソフトウェアコストを発生させることなく検証を行うことができます。

日本語版 / 英語版のインストールメディアを入手することができます。

基本的な機能確認であれば日本語版でも進めることができると思いますが、日本語版ではいくつかの機能の利用が制限されている (or 細かな操作で稀にエラーになるケース) ことがあるため、検証を迅速に進めたい場合は英語版でインストールしておいたほうが良いかもしれません。

 

物理環境を使用した検証環境の構築

1 台の物理環境で構築するのであれば、単一サーバーでの構築を行うことが可能です。

私も検証用に単一サーバーの環境を用意してあるのですが、NIC × 1 / 内蔵ディスク× 3 (OS 用: 1 / S2D 用: 2) の環境があれば、1 台のサーバーで Azure Stack HCI を構築することが可能です。

複数台の物理環境を用意して構築を行う場合には、次のドキュメントを確認しながら構築することになるのではないでしょうか。

 

仮想環境を使用した検証環境の構築

Azre Stack HCI は Nested Hyper-V の環境上に構築をすることも可能ですので、一台の物理環境上に Hyper-V をインストールし、そのうえで複数ノードの Azure Stack HCI を構築するということも可能です。

仮想環境を使用した Azure Stack HCI の検証環境の構築については次のドキュメントから手順を確認することができます。

 

仮想環境で検証する場合の仮想マシンの基本構成

仮想環境で Nested Hyper-V を使用して検証をする場合、次のような構成で検証することができます。

Nested Hyper-V のホスト OS

仮想環境の実行基盤のため、ある程度の CPU / メモリ / ストレージが確保できれば活用できます。
(CPU: 8 コア / メモリ: 24 GB / VM 格納用ディスク: 300GB 程度の環境で検証可能)

実行基盤の NIC については外部アクセス用に 1 枚の NIC が割り当てられれば、基本構成としては対応できると思います。

このホスト OS に Hyper-V の役割をインストールし、仮想スイッチとしては次の 2 種類のスイッチを作成しておきます。

  • 上述の NIC を使用した「外部ネットワーク」用のスイッチ
    • 管理用ならびに Azure Stack HCI 上の仮想マシンで使用するためのスイッチ
    • このスイッチに接続した NIC については、MAC アドレスのスプーフィングが必要
  • 「内部のみ」で使用する内部ネットワーク用のスイッチ
    • Azure Stack HCI の S2D のような内部通信で使用するためのスイッチ

 

Nested Hyper-V のゲスト OS (Azure Stack HCI ホストを起動する環境)

Azure Stack HCI ホストを稼働させる環境については次のようなリソースを割り当てています。

  • 基本リソース
    • CPU: 4 コア
      • 各 Azure Stack HCI ホスト用の仮想マシンに対して「Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true」 を実行しておく
    • メモリ: 10 GB
    • ディスク (OS 用 / S2D 用各 1 本でも検証ができそうだが、S2D の障害検証を考慮し複数ディスク構成とする)
      • OS 用 × 1
      • S2D 用 × 3
  • ネットワーク
    • 以下の用途の NIC を接続 (最小であれば、外部ネットワーク用のスイッチに接続した NIC × 2 で対応できる)
      • ホスト OS の「外部ネットワーク」用のスイッチを使用した NIC × 2
        • 「Management」 という名称の NIC として利用される
        • 「ComputeSwitch」という仮想スイッチに接続される NIC として利用される
          • 管理 OS とは共有されないスイッチとなるため、Azure Stack HCI ホストから NIC の認識が外れる
          • MAC アドレスのスプーフィングが必要
      • ホスト OS の「内部ネットワーク」用のスイッチを使用した NIC × 1
        • 「StorageSwitch」という仮想スイッチに接続される NIC として利用される
          • NIC 名は「vSMB1」に設定される
          • MAC アドレスのスプーフィングが必要

 

Hyper-V の有効化

Nested Hyper-V のホスト OS / ゲスト OS でHyper-V を有効にできない (Nested Hypre-V の要件を満たしているのに WAC 上では満たしていないことになる) 場合は、次の記事を確認して DISM を使用した有効化を行う必要があります。

具体的には、各環境で「DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V」を実行して Hyper-V を有効化します。

 

MAC アドレスのスプーフィングの設定個所

Hyper-V の仮想スイッチを Nested 上に作る場合、その仮想スイッチで使用する NIC については MAC アドレスのスプーフィングを有効化しておかないと通信が上手くできないケースがあるため、PING のレベルで想定した通信ができていない場合は MAC アドレスのスプーフィングを有効化してみるとよいかと思います。

MAC アドレスのスプーフィングを使用する場合は次のような設定になると思います

  • Hyper-V 実行基盤
    • External Network に使用する NIC (Hyper-V の外部スイッチ)
      • MAC アドレススプーフィングを ON
      • これにより、Hyper-V 上で実行する Azure Stack HCI ホスト OS の仮想マシンの Management Network として使用することができる
    • Azure 上で構築する場合、Azure VM でこの設定ができないため NAT スイッチを使用することになる
  • Azure Stack HCI ホスト用仮想マシン
    • Storage 用 Network (Hyper-V の 「StorageSiwtch 仮想スイッチ」に接続する NIC / vSMB1) に使用する NIC
      • MAC アドレススプーフィングを ON
      • S2D のデータ同期に使用する NIC となる
    • Compute 用 Network (Hyper-V の 「ComputeSwitch 仮想スイッチ」に接続する NIC) に使用する NIC
      • MAC アドレススプーフィングを ON
      • HCI 上に構築する仮想マシンで使用する HCI ホスト OS とは共有しない仮想スイッチで使用する NIC

そのほかには SET を使用する場合も MAC アドレスのスプーフィングが必要になるかと。

 

NAT スイッチを使用するか MAC アドレススプーフィングのみにするかの判断

入れ子になった仮想化による仮想マシンでの Hyper-V の実行 に記載されていますが、Nested Hyper-V でネットワークを構築する場合は、ネットワーク オプション に記載されているように、MAC アドレスのスプーフィングが NATネットワークのいずれかを使用する必要があります。

Azure VM を使用して Nested Hyper-V を構築する場合、Azure VM 側で MAC アドレスのスプーフィングを設定することができないため、NAT ネットワークを使用することになります。

NAT ネットワークの構築方法は、次のドキュメントから参照することができます。

 

物理環境に Hyper-V の実行基盤を構築した Nested Hyper-V の場合は、MAC アドレスのスプーフィングと NAT ネットワークの両方を使用することができます。どちらを使えばよいかについては「Nested Hyper-V 上で検証環境に必要なリソースを完結させるか」が一つの判断基準となるのではないでしょうか。

既に Domain Controller / Windows Admin Center を構築済みで、それを利用する場合は、MAC アドレスのスプーフィングを使用することで構成を容易にできます。(Nested Hyper-V 上のネットワークを、既存のネットワークとフラットな構成にできる)

そうではなく、一通りのリソースを Nested Hyper-V 上に構築する場合は、NAT ネットワークを使用することで、完全に分離した環境として Azure Stack HCI の環境を構築することができます。

 

Azure を使用した検証環境の構築

物理環境を用意することはできないが Azure サブスクリプションを用意することができる場合は Azure VM + Nested Hyper-V の環境で構築を行うこともできます。(前述の評価ガイドも Azure 上で構築されています)

Azure 上で Azure Stack HCI を評価するためのドキュメントはいくつか公開されており、関連するドキュメントとしては次のようなものがあります。

最初は、評価ガイドを確認しながら手動で構築をしたほうが良いかと思いますが、容易に展開ができるようにテンプレートも公開されており、上記のドキュメントはテンプレートによる展開を可能にするものとなりますので、複数回展開をする必要がある場合はテンプレートの利用も検討するとよいのではないでしょうか。

 

ストレージ / ネットワークの追加確認情報

ストレージ

Azure Stack HCI のデータ領域は記憶域スペースダイレクト (S2D) が使用されるため、本機能の情報も抑えておく必要があります。

ネットワーク

Windows Admin Center から手動でネットワークを組む方法が提供されているので利用は必須ではないのですが、ネットワークを構成する際には Network ATC を使用して構築することもできます。

実環境のネットワークセットアップでは ATC を利用するかもしれませんので、どういう構築ができるのか把握しておく必要はあるのかもしれません。(私は今のところ ATC ではなく手動で構築してしまっています)

 

バックアップ

Azure Stack HCI のバックアップには、Recovery Service コンテナーの Microsoft Azure Backup Server (MABS) を使用することができます。

サードパーティ製品でも、バックアップソリューションは提供されており、Azure Stack HCI 用のユーティリティ アプリケーション で紹介されています。

MABS を使用する場合は、Azure Stack HCI に保護エージェントを導入する必要があり、エージェントの導入方法は Data Protection Manager 保護エージェントのインストールと更新 /  DPM 保護エージェントの展開 に記載されています。

検証環境でディスク I/O にネックがある環境で、バックアップが失敗する場合は Data Protection Manager または Azure Backup Server で BMR バックアップが失敗する の情報についても確認しておくとよさそうです。

保護対象の追加時にエラーが発生し、保護対象を削除したい場合などには、次の情報の「Remove-ProductionServer.ps1」が活用できそうでした。

Share

Written by Masayuki.Ozawa

5月 16th, 2023 at 11:08 pm

Posted in Azure Stack HCI

Tagged with

«
»

Leave a Reply