Microsoft/VMware 製品はこう使う。

好きなことを好きに描く.

[Azure/AzureVM] Azure VM 環境で RHEL を利用するときの考え方

こんばんは。

ここ数年、AWSに所属していたり、Microsoftの中の人になっていたりと変化が多いこの頃です。いろいろAzure のTips が溜まってきていることや、いろんな方に Microsoft Azure の理解を深めて頂きたいので、短い記事を連発していく予定です。

 

中の人になって、Microsoft はLinux に積極的に投資や活動をおこなっているな、と改めて感じました。

サティア・ナデラCEOになったときに Microsoft ♥ Linux と発信しはじめてから、以下のようなBlog が公開され、今でも閲覧可能になっています。


Microsoft Loves Linux - Microsoft Windows Server Blog

 

では、Azure VM 上でRHEL をご利用頂く際に、考えていくことを順番に書いていきます。大きくはこれらがわかれば使っていけると思います。

1.支払い方法

2.一般的にどのVMイメージを使うのか

3.Azure VM(オンデマンド) のRHELの更新プログラムはどうやって入手、適用するのか

 

1.支払い方法

支払い方法として、大きく2つあります。

1.オンデマンドの利用(Azure VM(RHEL)の従量課金の料金にライセンス費用を盛り込んで使う方法)

多くのユーザーがライセンスの管理が煩雑になるため、1のオンデマンドの利用をご選択いただいています。システム管理の観点で、ライセンスがXX年XX月に切れる、サブスクリプションがXX年XX月に切れる、保守がXX年XX月に切れる、のような管理を数百台、数千台のOS分管理するのはしんどいものです。

Excelで管理しているけど、最新かわからない、なんてよくある話。。

 

2.RHELのライセンスを持ち込んでAzure VM でお使い頂く方法

Azure上のVM利用時にもともと持っているRHELのライセンスを持ち込んで、Azure VMとして利用する方法があります。
Azure の月額の利用料は減るものの、サポート窓口がOS部分がRHEL社になるなど、運用観点でワンストップサポートにならないことが多いのが難点です。

 

2.一般的にどのVMイメージを使うのか

Azure Virtual Machine のイメージ選択時に ↓ を選びます。

実は、RHEL のイメージは複数種類あって、選ぶときにややこしい!と思うことが多々あります。今回もパット見だけでわかりずらいものがありました。例えば「Red Hat Inc」で検索をかけた結果がこちら。わかりずらい。

 

きちんとバージョンごとにOSイメージが用意されているのが本物なので、きちんと目的のイメージを選択するようにしてほしい。

 

3.Azure VM(オンデマンド) のRHELの更新プログラムはどうやって入手、適用するのか

オンプレミスやハウジング環境等でこれまでRHELを使っていた方は、オンライン上にあるRed Hatパッケージリポジトリを使用するために、Subscription Managerを使って登録したあと、Red Hat のレポジトリにアクセス可能か確認し、yumで更新するのが一般的でした。
もしくは、隔離された環境であれば、RHELのサイトへログインし必要なパッチを確認し手動アップデートを行っている人もいるかもしれません。

Azure VM としてRHELを稼働させる場合、RHELの更新プログラム適用については、すごく簡単になっています。

まず、Subscription Manager でRHELのサブスクリプションを登録などといった作業は不要です。

なら、どこからどうやって更新プログラムを入手するんや!ということになるわけですが、最新の更新プログラムを取得するには、sudo yum update の実行で更新可能です。

yum は大まかにいうとパッケージのインストールやアップデート、削除などを簡単に実行してくれるものですが、sudo yum update の実行で参照される先(レポジトリ)は、Azure RHUI になります。

(参考資料)

Red Hat Update Infrastructure - Azure Virtual Machines | Microsoft Learn

Azure RHUI については、上記の公開ドキュメントが参考となりますが、ポイントとしてはこの2つになります。

 ・Red Hat 社でホストされているリポジトリのコンテンツをミラーリングする

 ・Azure 固有のコンテンツを使用してカスタム リポジトリを作成する

つまり、Red Hat 社のレポジトリをミラーした場所のレポジトリが使用可能ということです。


一般的な、オンデマンドでの利用(Azure VM(RHEL)のご利用料金にライセンス費用が内包されている)の場合は、Azure RHUI にアクセスするための構成が事前に設定されているため、sudo yum update の実行で更新可能となっています。

 

yum 自体は一般的なRHEL系Linuxのコマンドのため、Azure 特有のことは特にありません。

 

更新プログラムリストを見る場合は、Updateinfo から確認できますし、セキュリティ重要度を知りたい場合は、 list security all オプションを書けばよいです。

# sudo yum updateinfo list security all

 

kernel に関するアップデートの情報を除外したい場合は、--exclude=kernel*  リストを追加すればよいです。

「--exclude」 指定することで除外されます。

# sudo yum updateinfo list security all --exclude=kernel*

(実行サンプル)

[root@RHEL8 ]# sudo yum updateinfo list security all --exclude=kernel*

Last metadata expiration check: 2:47:56 ago on Wed 21 Aug 2024 05:22:03 AM UTC.

RHSA-2024:2621 Important/Sec. bpftool-4.18.0-477.55.1.el8_8.x86_64

RHSA-2024:3810 Moderate/Sec.  bpftool-4.18.0-477.58.1.el8_8.x86_64

RHSA-2024:4740 Moderate/Sec.  bpftool-4.18.0-477.64.1.el8_8.x86_64

RHSA-2024:5255 Important/Sec. bpftool-4.18.0-477.67.1.el8_8.x86_64

 

実際にパッケージを適用の際は、yum updateinfo を yum update に変更し、オプションはそのままで実施することで除外したものを適用することが可能です。

 

Microsoft は  な会社なので、Microsoft Azure でRHEL使ってくれる人が増えるといいなと思っています。

ゲストOSとして稼働する Windows Server にも サブスクで。(Azure Stack HCI)

私は Azure Stack HCI の投稿が多いわけですが、面白いものがリリースされました。

 

Azure Stack HCI OS の上で稼働する仮想マシンのWindows Server ライセンスを

サブスクでゲットして運用しようというものです。

 

きちんと Microsoft のサイトに記載があります。 

 

azure.microsoft.com


このアドオンワークロード のところですね。

意外に安い?気がする…。

$23.25/物理コア/月

f:id:japan-vmware:20220414191911p:plain

 

どのようなとき Windows Server サブスクリプションが使えるか、というと、

Azure Stack HCI(専用OS)の上で稼働させるゲスト用のライセンスをサブスクで入手できるということです。

docs.microsoft.com

 

 

このように書いてある。

 

  • Windows Server サブスクリプション: Windows Server のゲスト ライセンスを Azure 経由でサブスクライブします。 Azure Stack HCI に対してのみ利用できます。

 

ということは、これまでゲストOSのWindows Server のライセンスを購入して、

届くまで時間がかかってイライラしていたものが、必要なときにすぐ入手できるということになりますね。

 

オンプレにもスピード感を。ということなのかもしれない。

 

ハイブリッドクラウドのMicrosoft の方針はやはり本気なのだなとおもった次第です。

 

 

 

手順)Azure Stack HCI OS + AX ノードでの構築の流れを紹介

こんにちは。

 

いま、マイクロソフトがすごくハイブリッドクラウドに前のめりになり、

Azure Hybrid 戦略 という名前まで付けて推進している、Azure Stack HCI の

大まかな構築の流れを公開します。

 

2021年12月に 基本誰でも参加可能な Microsoft 超進化研究所ウェビナー でMicrosoft の高添さんと対談した資料です。

 

試した環境は ハードウェア AX-6515 , Azure Stack HCI OS 21H2 で試しています。

ハイブリッドクラウド専用OSなので、ぜひ興味をもってくださいねw

 
 
 

Windows Server 2022 で WSL(Windows Subsystem for Linux) を使えるようにする

WSL(Windows Subsystem for Linux) を Windows Server 2022 で有効化する手順をご紹介します。

 

WSL ではLinux をエミュレーションしたサブシステムで、Linuxカーネルそのものが動作します。

インストールできるLinuxの種類(ディストリビューション)は、wsl -l -o で確認することができます。

f:id:japan-vmware:20211127212102p:plain

PS C:\Users\administrator.DELLTECH> wsl -l -o
インストールできる有効なディストリビューションの一覧を次に示します。
既定の分布は ' * ' で表されます。
 'wsl --install -d <Distro>'を使用してインストールします。

  NAME            FRIENDLY NAME
* Ubuntu          Ubuntu
  Debian          Debian GNU/Linux
  kali-linux      Kali Linux Rolling
  openSUSE-42     openSUSE Leap 42
  SLES-12         SUSE Linux Enterprise Server v12
  Ubuntu-16.04    Ubuntu 16.04 LTS
  Ubuntu-18.04    Ubuntu 18.04 LTS
  Ubuntu-20.04    Ubuntu 20.04 LTS

-------------------------------------------------------------------------------

 

◆WSLをインストールする

インストールコマンド

  wsl --install -d Ubuntu

このコマンドだけでインストールできます。Ubuntuじゃないディストリビューションの方がいい場合は、ubuntu の部分をDebian とかに変えるだけでインストールできます。

 

大体、私の環境だと30秒くらいでインストール完了しました。その後再起動させます。

f:id:japan-vmware:20211127213119p:plain

 

再起動後、ログインすると、自動的にプロンプトが起動してセットアップが続行されます。

f:id:japan-vmware:20211127214117p:plain

 

しばらく待ちます。

f:id:japan-vmware:20211127214139p:plain

 

別のプロンプトがまた自動的に起動されます。

Linuxで使うユーザーネームを問われるので、任意のものを入力します。

f:id:japan-vmware:20211127214249p:plain

 

すると、Ubuntu が起動し、普通にLinuxが使えるようになります。

f:id:japan-vmware:20211127214332p:plain

 

試しに apt update を実行して、アップデートをかけてみました。

f:id:japan-vmware:20211127214705p:plain

すんなり、アップデート完了。

f:id:japan-vmware:20211127214842p:plain

 

Windows のスタートボタンをクリックすると、Ubuntu というアイコンが表示され、

次回からこれをクリックすることでLinuxが使えるようになります。

仮想マシンを稼働させるほどのオーバーヘッドがなく、便利ですね。

 

f:id:japan-vmware:20211127215149p:plain

 

搭載しているディスクを綺麗サッパリ初期化してくれるスクリプト(Azure Stack HCI OS, Windows 版 Azure Stack HCI 共通)

こんにちは。

 

前回の記事でAzure Stack HCI OS 21H2 をNested で構築する方法をご紹介しました。

今回は、構築する中で、めちゃくちゃ便利なスクリプトをご紹介します。

 

構築中に あ!間違えた!とか入力ミスして構築をしてしまったことがある人は結構いるとおもいます。構築したあとに フェールオーバークラスタ名が違っていた、とか、
構築に失敗して、ファイルシステムのゴミがいっぱい生まれて、次構築しようとしたらうまく構築ができず四苦八苦、、、などエンジニアのみなさまなら想像がつくかとおもいます。

 

そんなときに使えるスクリプトを 海外のMicrosoft MVP の方が作ってくれていて、これがめちゃくちゃ重宝します。

私のチームではこのスクリプトを "魔法のスクリプト" と呼んでいます 笑

https://github.com/dkawula/Operations/blob/master/S2D/FactoryReset-Clear-SDSConfig.ps1

 

【私が試して動作問題なかったOS】

Windows Server 2019 のS2D
Azure Stack HCI OS 21H2
Azure Stack HCI OS 20H2

 

【ハードウェア環境】
ESXi 上で作成したNested 環境で実行 → 普通に使えた
AX6515(Dell のS2D ReadyNode) → 普通に使えた 
 BOSS Boot Device  240GB x 2 (Raid1)
    SSD 960GB x 4 本(All Flash 構成)

 

想定トラブル時1

実際に私が困って使った状況をご紹介します。
現在、AX6515 というDell Technologiesの S2D Ready Node を使って検証をしているのですが、いざ構成しようとしたら、以前に誰かが使っていてファイルシステムが残っていてこのような状態になっていました。

 

f:id:japan-vmware:20211111121037p:plain

 

これは Get-physicaldisk コマンドレットを実行した結果なのですが、このマシンは SSD 4本とBoot Devce(BOSS)を積んでいるのみのマシンにもかかわらず、過去に誰かが検証した際のゴミが残っています。
OS をインストールするときのセットアップウィザードで消したらいいのでは?という方もいらっしゃるかもしれませんが、残念ながらその画面では消せませんでした。
(状況によりますが)

みて頂くとわかりますが、CanPool 列 が False  になっていますよね。
False になっていると S2D を構成できないのでここを True  にする必要があるわけです。

 

そのため、魔法のスクリプトを実行します。
その前にスクリーンショットの環境は Azure Stack HCI OS 21H2 で実行しているので、Server Core (CLI) のみのOSですので、ネットワーク上に共有ファイルを作って、そこにスクリプトを置いて、ASH OS 側にコピーして実行しました。

172.31.90.5 のCドライブの共有設定して、そこに魔法スクリプトを置いています。
置いた魔法スクリプトを Azue Stack HCI OS の Cドライブ配下にコピーしています。

f:id:japan-vmware:20211111115659p:plain

 

コピーしてきた、スクリプトを実際に実行します。
※元のスクリプト名が長いので 短いスクリプト名に名前変更だけしています。

f:id:japan-vmware:20211111114640p:plain

 

実行開始します。

f:id:japan-vmware:20211111115926p:plain

 

途中で エラーなども多く表示されますが、無視して大丈夫です。
理由は最後に記載します。

f:id:japan-vmware:20211111120011p:plain

 

ディスクがクリーニングされているのがわかります。

f:id:japan-vmware:20211111120144p:plain

 

4本のディスクとBootDevice が削除されていることが表示されています。

f:id:japan-vmware:20211111120251p:plain

 

では実際に、Get−Physicaldisk を実行してみましょう。
ゴミが消えて、SSD 4本とBoot Devce(BOSS) のみ表示されるようになりました。
また、CanPool の値が True になっているので、Azure Stack HCI の構成ができるDisk になっているのがわかります!

f:id:japan-vmware:20211111121359p:plain

 

想定トラブル時2

構築が終わったあとに、再構築する必要がでた場合にも魔法スクリプトは素晴らしい活躍をします 笑

一度2ノードでも、3ノードでもいいのですが、構築し終わったあとの Azure Stack HCI は、フェールオーバークラスタが構成され、S2D(Storage Space Direct)も構成されている状況です。もちろんクラスターが構成されているわけですから、クラスターディスクも作成されているので、再構築になると猛烈にダルい作業が発生します。
エンジニアの人だと「OS再インストールからなのか…?」「ファイルシステムにゴミが残る…」「IP Address 振り直し…?」いろいろ思い浮かぶと思います。

それらの一気に解消するのも魔法スクリプトです。😋

 

先程、ここでエラーがでていましたよね。
ここで何をしているか、というとクラスターの削除やクラスターディスクの削除をしています。

f:id:japan-vmware:20211111120011p:plain

 

つまり、この魔法スクリプトは、クラスターを削除し、S2D 機能をオフにしたのち、
ディスクを綺麗サッパリしてくれるということです。

 

注意点

もし仮想スイッチが作成されている場合は、仮想スイッチだけコマンドで削除する必要があります。そのときは Remove-VMSwitch コマンドレットで削除をお願いします!
コマンドだるいな。。。というときはWindows Admin Centerからホストに接続して仮想スイッチの削除もできます。

最後に

個人的にすばらしいとおもったのは、IP Address の設定は初期化されないですし、ドメインに参加している場合はドメインから離脱することもありません。
つまり、魔法スクリプトを各ノードで実行するだけで再度Azure Stack HCI の構築を開始することができます。
ESXi の Nested とかでここまでの便利なものはみたことが個人的になかったので感動的でした…検証時や実際の構築時に困ったらつかってみてはいかがでしょうか。

一応念の為申し上げておくと、使用については自己責任でお願いしますね😋
Microsoft MVP の方が善意で公開してくれてるものですので。

 

よい Azure Stack HCI 生活を!!!

 

一応スクリプト内容をそのまま張っておきます。

 

-------------------------------------

# #
# *** USE AT YOUR OWN RISK *** #
# PERMANANT DATA LOSS WILL OCCUR #
# #
# This script completely clears any existing Storage Spaces configuration #
# and all data on EVERY non-system drive PERMANENTLY! #
# #
# Notes: #
# #
# If certain drives cannot be cleared and the reason given is #
# 'Redundant Path' then MPIO may need to be installed and/or configured. #
# #
# Power cycling the JBOD enclosures can also remove additional #
# errors encountered during the run. #
# #
# Run cmdlet with Administrator rights. #
# #
################################## WARNING ################################
################################# Change Log ################################
# #
# 02/13/2014: Changed logic to remove SAS-connected boot/system disks #
# 02/13/2014: Changed output for clearing disks and tracking runtime #
# 04/07/2014: Corrected logic to deal boot and system drives #
# 04/07/2014: Added logic to deal with non-core cluster objects #
# 07/23/2015: Changes to better support Storage Spaces Direct #
# #
#############################################################################
#Script has been tested and verified to work to Factory Reset Storage Spaces Direct by Dave Kawula#
[CmdletBinding(SupportsShouldProcess=$true, ConfirmImpact="High")]
param()
if ($PSCmdlet.ShouldProcess("localhost","Clear Storage Spaces configuration and wipe disks"))
{
Write-Host ""
Write-Host Clearing existing Storage Spaces configuration and wiping disks...
Write-Host ""
$runStart = [DateTime]::Now
# Install necessary tools if needed
$toolsInstalled = $false
if (!(Get-WindowsFeature -Name "RSAT-Clustering-PowerShell").Installed)
{
Write-Host Installing required tools... -ForegroundColor Cyan -NoNewline
Install-WindowsFeature -Name "RSAT-Clustering-PowerShell"
$toolsInstalled = $true
Write-Host Done.
Write-Host ""
}
# Remove any cluster objects if present
Write-Host "Removing any cluster objects" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
foreach ($clusterGroup in (Get-ClusterGroup -ErrorAction SilentlyContinue -WarningAction SilentlyContinue))
{
if (!$clusterGroup.IsCoreGroup)
{
Remove-ClusterGroup -Name $clusterGroup.Name -Force:$true -RemoveResources:$true -ErrorAction SilentlyContinue
}
}
Remove-Cluster -Force -CleanupAD -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
Write-Host "Done."
$disks = Get-PhysicalDisk | Where-Object {($_.BusType -EQ "SAS") -or ($_.BusType -EQ "SATA")} # -or ($_.BusType -EQ "RAID")}
Write-Host ""
Write-Host "Removing any stale PRs" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
foreach ($disk in $disks)
{
Clear-ClusterDiskReservation -Disk $disk.DeviceId -Force -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
}
Write-Host "Done."
Write-Host ""
Write-Host "Updating the storage provider cache (x2)" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
Update-StorageProviderCache -DiscoveryLevel Full
Start-Sleep 1
Update-StorageProviderCache -DiscoveryLevel Full
Write-Host "Done."
# Remove virtual disks and storage pools
Write-Host ""
Write-Host "Removing Virtual Disks and Pools" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
$storagePools = Get-StoragePool | ? FriendlyName -NE "primordial"
$storagePools | Set-StoragePool -IsReadOnly:$false
Get-VirtualDisk | Set-VirtualDisk -IsManualAttach:$false
Get-VirtualDisk | Remove-VirtualDisk -Confirm:$false
$storagePools | Remove-StoragePool -Confirm:$false
Write-Host "Done."
Write-Host ""
Write-Host "Updating the storage provider cache (x2)" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
Update-StorageProviderCache -DiscoveryLevel Full
Start-Sleep 1
Update-StorageProviderCache -DiscoveryLevel Full
Write-Host "Done."
Write-Host ""
# Collect IDs of any system/boot disks
$disks = Get-Disk
$diskIdsToRemove = @()
foreach ($disk in $disks)
{
if ($disk.IsBoot -or $disk.IsSystem)
{
$diskIdsToRemove += $disk.UniqueId
}
}
# Get collection of physical disks
$allPhysicalDisks = Get-PhysicalDisk | Where-Object {($_.BusType -EQ "SAS") -or ($_.BusType -EQ "SATA")} # -or ($_.BusType -EQ "RAID")}
# Create a new collection of physical disks without any system/boot disks
$physicalDisks = @()
foreach ($physicalDisk in $allPhysicalDisks)
{
$addDisk = $true
foreach ($diskIdToRemove in $diskIdsToRemove)
{
if ($physicalDisk.UniqueId -eq $diskIdToRemove)
{
$addDisk = $false
}
}
if ($addDisk)
{
$physicalDisks += $physicalDisk
}
}
# Iterate through all remaining physcial disks and wipe
Write-Host "Cleaning disks" -ForegroundColor Cyan -NoNewline
Write-Host "..."
$totalDisks = $physicalDisks.Count
$counter = 1
foreach ($physicalDisk in $physicalDisks)
{
$disk = $physicalDisk | Get-Disk
# Make sure disk is Online and not ReadOnly otherwise, display reason
# and continue
$disk | Set-Disk –IsOffline:$false -ErrorAction SilentlyContinue
$disk | Set-Disk –IsReadOnly:$false -ErrorAction SilentlyContinue
# Re-instantiate disks to update changes
$disk = $physicalDisk | Get-Disk
if ($disk.IsOffline -or $disk.IsReadOnly)
{
Write-Host "Warning: " -NoNewline -ForegroundColor Yellow
Write-Host "Unable to process disk " -NoNewline
Write-Host $disk.Number -NoNewline
Write-Host ": Offline Reason: " -NoNewline
Write-Host ($disk.OfflineReason) -NoNewline -ForegroundColor Yellow
Write-Host ", HealthStatus: " -NoNewline
Write-Host $disk.HealthStatus -ForegroundColor Yellow
}
else
{
Write-Host "Cleaning disk " -NoNewline
Write-Host $disk.Number -NoNewline -ForegroundColor Cyan
Write-Host " (" -NoNewline
Write-Host $counter -NoNewline -ForegroundColor Cyan
Write-Host " of " -NoNewline
Write-Host $totalDisks -NoNewline -ForegroundColor Cyan
Write-Host ")..." -NoNewline
# Wipe disk and initialize
$disk | ? PartitionStyle -NE "RAW" | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false
$disk | Initialize-Disk -PartitionStyle GPT
Write-Host Done.
}
$counter++
}
# Remove any installed roles/tools
if ($toolsInstalled)
{
Write-Host Uninstalling Failover Cluster tool... -NoNewline -ForegroundColor Cyan
Remove-WindowsFeature -Name "Failover-Clustering","RSAT-Clustering-PowerShell"
Write-Host Done.
}
Write-Host ""
Write-Host "Updating the storage provider cache (x2)" -NoNewline -ForegroundColor Cyan
Write-Host "..." -NoNewline
Update-StorageProviderCache -DiscoveryLevel Full
Start-Sleep 1
Update-StorageProviderCache -DiscoveryLevel Full
Write-Host "Done."
# Output physical disk counts
Write-Host ""
Write-Host Physical Disks:
Get-PhysicalDisk | Group-Object Manufacturer,Model,MediaType,Size | ft Count,Name -AutoSize
Write-Host Configuration and data cleared!
Write-Host ""
Write-Host "Run duration: " -NoNewline
Write-Host ([Math]::Round((([DateTime]::Now).Subtract($runStart)).TotalMinutes,2)) -ForegroundColor Yellow -NoNewline
Write-Host " minutes"
}

Azure Stack HCI OS 21H2 を Nested かつ WAC(Windows Admin Center)で構築する

みなさま 2021/11/2 -11/3 の Microsoft Ignite は見ましたか?😋

 

明確に Azure Arc や Azure Stack HCI のお話がありましたね。
私としては、いまの Microsoft の方針は世の中のITインフラが動く場所やデータの発生源からのデータの流れを考えると、すごくマッチしているように思え、すごく納得感があります。

 

2021年は、ハイブリッドクラウドの観点から Azure Arc や Azure Stack HCI の啓蒙活動をしているので、Azure Stack HCI OS 21H2 もGA されたことですし、限りあるリソースの中で、Azure Stack HCI OS 21H2 を使った構築の流れを記載します。


タイトルのとおり、限りあるリソースの中でNested 環境で作成します。
"Nested" というのは、ハイパーバイザーの上でさらにハイパーバイザーを稼働させることを意味します。つまり、今回は ESXi の上で仮想マシンとして Hyper-V を稼働させるということになります。

 

環境情報

【物理的なマシン】
ハードウェア:R640 x 1台
CPU:Intel Xeon Silver 4114 2.2GHz
OS:ESXi 6.7 (Build: 15160138)

【仮想マシン】
Azure Stack HCI OS 21H2  × 3 台
Windows Server 2022 × 1 台(Windows Admin Center 稼働用)
Windows Server 2019 × 1 台(Active Directory / DNS)

 

【既に構築済のモノ】

・Active Directory / DNS は既にあるものを使っています

・Windows Admin Center は ADDS との共存は不可なので、別で立てています 
 Version:1.3.2105.24004

【事前に見ておいたほうがいいモノ】
私のチームで共同で以下のサイトを作っているので、事前に読むと進めやすいです。

Azure Stack HCI攻略Wiki | Dell eカタログサイト

事前準備1

Azure Stack HCI を構築するには事前準備がすごく重要になってきます。
特にNested だとしなければいけないこともあるので、事前準備だけでかなり長い記事になりそうです。

Azure Stack HCI OS をダウンロードします。

事前準備2(仮想ハードウェア)

Azure Stack HCI OS 21H2  × 3 台 を作っていきます。
ESXi の Host Client から以下のようにディスクを構成しています。
30GBのディスクに Azure Stack HCI OS をインストールし、その他は実際に使う領域(キャパシティ)として追加しています。
キャパシティに関しては、最低で4本のSSD が必要ですが、わたしは仮想マシンを少し作りたい想定なので、多めの5本にしています。

すべてシンプロビジョニングです。

f:id:japan-vmware:20211104151040p:plain

Azure Stack HCI OS は 現時点で All Flash が必須になっています。
しかし、、、見てわかる通り、このままではただの全てハードディスク構成ですので、Azure Stack HCI OS から見て、「自分には SSDが搭載されている!」と錯覚させる必要があります。その方法は私のこの記事をみてほしい。

大まかに説明すると、仮想マシンの構成ファイル(.vmx)にこれを追記します。
scsi0:1.virtualSSD = 1

Nested ESXiにSSDがあるように思わせる設定 - VMware / Microsoft 製品はこう使う。

今回は5つのハードディスクをSSDに思わせたいので、私はこんなカタチで追記しています。その後、パワーオンすることでSSDとしてAzure Stack HCI OS から認識されます。

scsi0:1.virtualSSD = 1
scsi0:2.virtualSSD = 1
scsi0:3.virtualSSD = 1
scsi0:4.virtualSSD = 1
scsi0:5.virtualSSD = 1

f:id:japan-vmware:20211104170013p:plain

 

CPUの設定では [ハードウェアアシストによる仮想化をゲストOSに公開] にチェックをいれます。
これにチェックを入れないと、Azure Stack HCI OS にHyper-Vの役割がインストールされるときにエラーになってしまいます。

f:id:japan-vmware:20211104152612p:plain

 

ネットワークに関しては、3本のNIC をつけています。
[VM Network] が管理用のネットワークで、[Katayama_Storage1] が、ストレージ同期などに使うネットワークです。

f:id:japan-vmware:20211104162139p:plain

 

Azure Stack HCI OS 21H2 のインストール

OSのインストールに関しては、普通のWindows Server をインストールするときと何も差がありません。3台に同じようにインストールを実施します。
注意が必要なのは、Azure Stack HCI OS は Server Core OS(GUIナシ)のOSであるため、最初の設定などは自動起動する SConfig の画面 ↓ から設定します。

この画面で最低限実施することは、以下になります。

・IP Address の設定(管理IP, Storage IP)
・ホスト名の設定

やっておいたらいいことは以下です。
あとからWindows Admin Center経由でドメイン参加させることも可能ですが、私は直接コンソールからやっています。

・ドメインへの参加

f:id:japan-vmware:20211104173412p:plain

Azure Stack HCI OS 21H2 のIP Address の設定で私が少しハマった(困った)のは、
SConfig(上記の画面)から IP Address を設定しようとしたときに設定が反映されない自称に遭遇しました。何度設定しようとしても Error となりました。
そのため、SConfig の画面で 「15」を入力してPowerShell を起動後に netsh コマンドで設定を実施しました。netshコマンドだったらなぜか設定ができました。
同じ事象に遭遇した際は、原始的ですが netsh コマンドをご利用ください。

書式
netsh interface ip set address "<インタフェース名>" static <IPアドレス> <ネットマスク> <ゲートウェイ>
コマンド例
C:\>netsh interface ip set address "Ethernet0" static 172.16.1.101 255.255.255.0 172.16.1.1 

 

また、この環境特有の話ではないですが、"Ethernet0" "Ethernet1" "Ethernet2" がどのネットワークに所属しているNICなのかわからなくなってしまいがちなので、そのあたりもご注意ください。

 

Windows Admin Center (WAC) のみで Azure Stack HCI を構築していく

これまでコマンドで構築していくのが主流の Azure Stack HCI でしたが、Windows Admin Center のみで構築をしていきます。GUI のみで構築!

 

Windows Admin Center にログインし、[追加]ボタンをクリックすると、
右側に "サーバークラスター " が表示されるので、[新規作成] ボタンをクリックします。

 

f:id:japan-vmware:20211104211525p:plain

 

[Azure Stack HCI] を選択し、[すべてのサーバーを1つのサイトに] をクリックします。
ストレッチクラスタなどを組むときは、もう1つの選択肢になると思います。

f:id:japan-vmware:20211104212100p:plain

 

事前にどのような前提条件があるのかを表示してくれています。
すごく良心的です。ここで何かチェックが入るわけではありません。
[次へ] をクリックして進みます。

f:id:japan-vmware:20211104212326p:plain

 

ここからが、構成していくフェーズに入ります。
クラスターを構成するノードを検索して、[追加]ボタンでリストアップしていきます。
今回は3ノードクラスタなので、3台を追加しています。
Nested 環境なので、ハードウェアモデルのところが VMware,Inc になっています。

以下のスクリーンショット上部の少し見えていない部分では、サーバー(ASH OS)に接続しにいくときに使用するユーザーを指定しています。
※ドメイン名¥Administrator を指定

f:id:japan-vmware:20211104175146p:plain

 

事前準備の段階でドメイン参加をしたので、ここでは既にドメインに参加済みであることが表示されています。そのまま [次へ] をクリックします。

f:id:japan-vmware:20211104213059p:plain

 

[機能をインストールします] をクリックします。
ここでインストールされるのは、Hyper-V の役割など必須のものがインストールされます。事前準備の段階で、仮想CPUの設定で、[ハードウェアアシストによる仮想化をゲストOSに公開] にチェックをいれておかないとココでエラーになってしまいます。
クリック後は、2〜3分で終わるはずなので、[次へ] をクリックします。

 

f:id:japan-vmware:20211104213354p:plain

f:id:japan-vmware:20211104213723p:plain

 

更新プログラムのインストールも流れ作業で適用可能です。

f:id:japan-vmware:20211105001321p:plain

f:id:japan-vmware:20211105001429p:plain


ここで、Dell の認定済みノード(AX Node)などであれば、Firmwareとか適用できるはず。その際、Windows Admin Center のプラグインに OMI MS WAC(Dell EMC OpenManage Integration with Microsoft Windows Admin Center) もインストール済みじゃないといけないはず。
今回はNested のため、試せるわけもなく、[次へ] をクリックする。

f:id:japan-vmware:20211105001507p:plain

 

再起動を実施します。Nested のため、再起動に関しては激早いです。

f:id:japan-vmware:20211105001847p:plain

 

再起動が終わったら、[次のステージ:ネットワーク] ボタンがクリックできるようになります。

f:id:japan-vmware:20211105002007p:plain

 

続いて、ネットワークの設定セクションに入っていきます。
各ノードに搭載しているNIC が表示されます。USB NIC など構成に不要なものは除外する必要があります。もし、残ったまま進めようとすると構成時にエラーになります。

f:id:japan-vmware:20211105002122p:plain

すべて3つのNIC を搭載させています。
実際の動作検証済みノードだともっとNICポート数が多いので混乱しないように注意が必要そうです。

f:id:japan-vmware:20211105002428p:plain

 

管理ネットワークで使う NIC を選びます。
今回の環境では NIC Teaming しないので、左側の [管理用に1つの物理ネットワークアダプター] を選択します。

f:id:japan-vmware:20211105002542p:plain

 

事前に "Ethernet0" にのみきちんと管理ネットワークのIP Address を設定していたため、 "管理者におすすめ" と親切に記載してくれています。

f:id:japan-vmware:20211105002908p:plain

 

[適用してテスト] ボタンをクリックすると疎通確認が行われ、[次へ]ボタンがクリックできるようになります。ここで管理ネットワークでどのNICを使うのかが決まります。

f:id:japan-vmware:20211105003043p:plain

 

仮想スイッチを作成します。選択肢としては、3つあります。
 ・仮想スイッチ1つに複数の単独NICが接続される構成(左)
 ・ユーザーが使用する用の仮想スイッチ1つのみが作成される(中央)
 ・ユーザー用、ストレージ用、2つの仮想スイッチが作成される(右)
Dell の Azure Stack HCI の構成ガイドは "中央" の構成を推奨としているようですが、
Nested なので、左の構成を選択します。

f:id:japan-vmware:20211105003327p:plain

 

仮想スイッチ名などもデフォルト名 "ConvergedSwitch" というのが入力されています。
デフォルト値から変更することなく [次へ] ボタンをクリックします。

f:id:japan-vmware:20211105003924p:plain

 

RDMA(Remote Direct Memory Access)の設定を有効化すことができる。
ここで重要なのは、Azure Stack HCI OS 側に NIC の Driver がインストールされていないと、RDMA を有効化する事ができないと思われる。
Nested なので、RDMA は使えないので、このまま [次へ] をクリックする。 

f:id:japan-vmware:20211105004045p:plain

 

クラスター内のストレージ同期のネットワークにつかうIP Address の指定です。
私はあらかじめ、Azure Stack HCI OS のコンソールからIP Address を設定していたので、既に192.168.1.x が表示されています。この設定値は模範的ではなく、きちんとVLANごとに分けるのが正攻法ですので、ご注意ください。

f:id:japan-vmware:20211105004405p:plain

 

WACから ASH OS ノードに接続するときのアカウントを聞かれます。

f:id:japan-vmware:20211106152633p:plain

 

さらに、CredSSP を有効にするかどうかを聞かれます。
有効にしないと先に進めないので [はい] をクリックします。

f:id:japan-vmware:20211106153109p:plain

 

無事接続テストが完了します。
[次のステージ:クラスタリング] に進みます。

f:id:japan-vmware:20211106153225p:plain

f:id:japan-vmware:20211106153313p:plain

 

ボタンなどをクリックすることなく、自動的にクラスタが構成可能かチェックが実行されます。

f:id:japan-vmware:20211106153459p:plain

 

だいたい3分くらいで検証が行われました。

f:id:japan-vmware:20211106153609p:plain

 

警告が出ていますね。

f:id:japan-vmware:20211106153706p:plain

 

想定していた警告だったのでスルーします。

f:id:japan-vmware:20211106153817p:plain


クラスタ作成を行います。
ここでは Windows Failover Cluster の名前と  クラスターIP を入力します。
その他の設定はデフォルトにしています。

f:id:japan-vmware:20211106153853p:plain

 

クラスター構成が開始されます。

f:id:japan-vmware:20211106154112p:plain

 

数分でクラスターが構成されました。(10分もかからなかったとおもいます)

f:id:japan-vmware:20211106154155p:plain

 

ついに 記憶域 の設定に入ってきましたね!
まずはじめに、余計なデータが入っている場合は削除することができるようです。
今回は空っぽのディスクなので、使いませんでした。

f:id:japan-vmware:20211106154244p:plain

 

各ホストに SSD が5本接続されているのがわかります。

f:id:japan-vmware:20211106154640p:plain

 

一応全部のSSD が見えている状態です。

f:id:japan-vmware:20211106154735p:plain

 

接続されているSSD がきちんと使えるかをチェックします。
一発合格しました。一応、どんなチェックをしているのか、スクロールしたスクリーンショットもつけています。

f:id:japan-vmware:20211106154842p:plainf:id:japan-vmware:20211106154947p:plain

 

つ、ついに S2D(Storage Space Direct) の有効化です。
[有効にする] ボタンをクリックすると、構成が開始します。

f:id:japan-vmware:20211106155041p:plain

f:id:japan-vmware:20211106155230p:plain

 

約2分くらいで Storage Space Direct は有効化されました!(はやい)
ここまでで構成自体は完了ですが、まだ他に少しやらないといけないことがあります。

f:id:japan-vmware:20211106155339p:plain

 

残りの作業

・SDN(Software Defined Network)の設定 →オプションなので今回はスキップ

・Azure Stack HCI OS を Microsoft Azure に登録 ※これしないと仮想マシン作成できない

「Azure 接続」の部分から [このクラスターを登録] をクリックして進める必要があります。

f:id:japan-vmware:20211106155855p:plain

 

今回は、構築の流れを知るために、私自信の備忘録にもなるかとおもって、流れを記載しました。

◆一覧

f:id:japan-vmware:20211106160042p:plain

◆Azure Stack HCI OS 21H2 ノードの概要

f:id:japan-vmware:20211106160416p:plain



総評

これまでコマンド(PowerShell)で構築するのがやっとだったAzure Stack HCI ですが、
Windows Admin Center のみで構築できるのはユーザーにとって導入の敷居がグッと下がっ多様に思います。
また、Windows Admin Center は Azure Backup なども簡単に使えますし、Azure Hybrid の 中核である Azure Arc の操作なども助けてくれるため、これぞ真のハイブリッドクラウドの出発時点ですね。

 

Azure Arc とは なにか?

ワタクシが ハイブリッドクラウド研究会でお話しているYoutube があるので、是非みてくださいね😋

www.youtube.com

 

 番外編)Windows Admin Center の更新を試してみる

Windows Admin Center の新しいバージョンがたまたまリリースされたので、ついでに付録として記載します。

現在:1.3.2105.24004

次    :1.3.2111.01001

[更新プログラムのインストール] をクリックするとすぐに始まりました。

f:id:japan-vmware:20211106161404p:plain

 

f:id:japan-vmware:20211106161529p:plain

 

無事、3分くらいでインストールされました!

どんどん使い勝手がよくなってきている。

f:id:japan-vmware:20211106162107p:plain

 

f:id:japan-vmware:20211106162233p:plain

 

Azure Hybrid たのしくなってきましたね。

 

かたやん