VMware / Microsoft 製品はこう使う。

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

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 たのしくなってきましたね。

 

かたやん

vSphere 7 - 新しいDRS ってどこが新しいの?

さて、GWで毎日なにか達成感がほしくて記事書いてみたりいろいろもがいているかたやまです。今回はvSphere 7 でDRSに機能追加されたとのことなので見てみました。

 

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

 

DRS とは言わずもがな Distributed Resource Scheduler のことですが、DRS自体は2006年 のときに実装されたもので、なかなかの歴史があります。

なかなかの歴史がある機能でありながら、これまで大きな機能の追加というか変化などはあまり行われずここまできています。

vSphere 7 ではメニューが増えたり、考え方が変わったりしたので、メモです。

 

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

実はざっくりですが、vSphere7 がリリースされた4/3(日本時間)でDELLEMC の石塚さん、わたし(片山)、VMwareの南さんで書いた記事の中にこんなことを書いています。

https://japancatalog.dell.com/c/isg_blog_vsphere7_01/

Dell)DRS は最近日本のユーザ様でも普通に使ってもらえるようになった印象ですが、何が変わったのでしょうか?

 

VMware)これまでの DRS はクラスタ全体の負荷を管理し、ホスト間の負荷のバランスをとるように動作していました。それに対して新しい DRS ではアプリケーション中心の思想で再設計が行われ、アプリケーションが動作するワークロードそのものを最適化するような配置が行われるようになりました。旧バージョンの DRS との最大の違いは、ホスト間の負荷のバランスをとらなくなったことです。新しい DRS ではホスト上の VM に対してスコアを計算し、このスコアに基づいて VM を移動させます。またこのスコアは1分ごとに計算されており、よりきめ細かな最適化が行われるようになりました。

 

つまり、VMごとにDRSスコアというものを出して、スコアが(改善する)と思われるESXiホストにVMを移動させる、ということが言いたいようです。 VMwareの公式Blogでもそのように書かれていますね。
 
DRSスコアの見方については、、猛烈にわかりにくい…!のですが、文面からのわたしの解釈は、
ベースの考え方として、スコアは高ければ高いほど、リソースの競合がなく、良い状態ということ。つまり100% が一番いい状態。ただし、80%とか100%のDRSスコアのVMが50%とかスコアが低いVMよりもパフォーマンスがいいかどうかは別。理由は、DRSスコアは5つの指標から算出されるため、一概にスコアが悪いからといってパフォーマンスが悪いとは限らない(状況による)。
例えば、CPU Ready timeが高くなってしまっているときでも、CPUの影響をあまり受けないアプリケーションがVM上で動作している場合などは、見かけ上パフォーマンス影響を受けていないように見えることもあるとおもいます。そもそもパフォーマンスが悪いと言葉は、すごく広域な意味合いであるため、あまり掘り下げても "状況による" というのが正直なところなのかもしれない。

Obtaining a VM DRS score of 80-100% indicates that there is mild to no resource contention. It does not necessarily mean that a virtual machine in the 80-100% bucket is doing way better than a virtual machine in the lower buckets. That is because there are many metrics that influence the VM DRS score. Not only performance metrics are used, but capacity metrics are also incorporated in the algorithm.

 

DRSのスコアはVMwareさんの資料や記事からはこんな感じで書かれています。

・CPU %ready time

・メモリスワップ

・CPU キャッシュ動作

・現在のESXiホストが持つ予備リソース容量

・マイグレーションのコスト
 
実際のDRSスコアをVMごとに見る画面ではこれらの列が用意されていました。

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

・DRSスコア
・アクティブなCPU
・使用済みCPU
・CPU Readiness
・付与されたメモリ
・スワップ済みメモリ
・バルーンメモリ
 
 
DRSを動かそう
やはりわたくしエンジニアですので、動いているものをみたいわけで。
新DRSのテストになっていないかもしれないですが、DRSスコアとかの変化を見るためだけに実機を触りました。新しい画面に何か表示されてほしいですから。 
DRSの設定は 完全自動化 にして、その他はデフォルト値のままです。 
 
まずテンプレートとなるWindows Server 2019 (vCPU2, Mem8GB)を作成し、以下のPowerCLI で仮想マシンを250個クローンする。そのとき、データストアはvsanDatastoreを使い、あとからのテスト用に1つのESXiホストに仮想マシンが寄るようにした。
 

$esxName = "172.31.7.125"
$template = "WS2019-2"
$datastore = "vsanDatastore"
foreach($n in 1..250) {
New-VM -Name test-vm$n -VMHost (Get-VMHost -Name $esxName) -Template $template -Datastore $datastore -RunAsync
}

作成後の状態がこちら。

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

 

 

DRSは仮想マシンが起動したときから発動するようになるので、この250個の仮想マシンを一気にパワーオンします。172.31.7.125というESXi上で仮想マシンが250個リソースを使い始めたので、vCPUならびにメモリがいっきに使用状態になるので、即座にDRSが開始されはじめます。

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

 

DRSが順次動き始めているときに [監視] - [vSphere DRS] - [CPU使用率] を見ました。

やはり、172.31.7.125 に寄せて仮想マシンのクローンをしていたので、案の定の見え方です。

 一応画面説明をみると、あくまでここでは仮想マシンのCPU使用率を表示しているらしく、CPU Ready timeというわけではないらしいです。

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

 

[監視] - [vSphere DRS] - [メモリ使用率] を見ました。同じく想定通り172.31.7.125 のメモリをめっちゃ使っています。これがどうなっていくか楽しみです。

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

 

その間にもDRSでどんどん仮想マシンが別ホストへ移行されていきます。

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


DRSスコアはどうなっているかというと0%のものもあれば、80%くらいのものもあり、バラバラという印象。

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

 

 

6分ほど経過して確認すると、CPU使用率がすこしマシになってきました。平準化されてきましたね。

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

 同じくメモリもましになってきました。

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

 

9分くらい経つとほぼほぼふらっとになりつありますね。

仮想マシンのパワーオンからトータル約10分でリバランス完了しました。

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

 

 

[監視] - [vSphere DRS] - [推奨]

DRSの設定を "完全自動化" から"手動" に変更したら使えます。

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

 

DRSで動かしたほうがいい仮想マシンを表示してくれ、しかも原因が何かを表示してくれています。すごく親切ですね。さっそく [今すぐ DRS を実行]をクリックします。

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

 

 "推奨の更新" というタスクが動きました。ボタンの意味合いからだとすぐにvMotion が実行されるのかとおもいきや、10分経っても実行されず。

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



 

まだ見れていないメニュー

まだみれていないものは以下3つです。

[監視] - [vSphere DRS] - [障害]  →謎

[監視] - [vSphere DRS] - [ネットワーク使用率] →みてもおもしろくなさそう

 

 少し長くなってしまいました。

 

こうやって文字にすることで自分の頭にも入るのでいいですね。

 

おわり

vSphere 7 - File Service for vSAN 7 をESXiでNFSマウントしてみる(2)

前回の投稿で、File Service を有効化の流れをご紹介しました。

vSphere7 - File Server for vSAN7 を有効化するよ - VMware製品はこう使う。

 

VMware公式ドキュメントはこちらあたりです。(VMware Docs)

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-82565B82-C911-42F7-85B1-E9EF973EE90C.html

 

ファイル共有を作っていく🙆

今回は、vSANのFile Serviceで ファイル共有を作成していき、その後、スタンドアロンのESXiにマウントさせようとおもいます。

 

左のインベントリ一覧から vSANクラスタをクリックして、[設定]タブ - [vSAN] - [ファイル サービスの共有] をクリックして追加ボタンを押して共有を作成していきます。

 

一般的なNFS共有を作るときの設定項目が並んでいますね。

・[プロトコル]:NFS3 , NFS4.1 が使えます。設定画面で選ぶ必要はありません。ただ経験則的にNFS4.1使われてるのを見たことがないですが…

・[名前] :共有名です。

・ストレージポリシー:vSAN特有のワードが出てきました。この共有に保存されるデータをどのような冗長性を担保するかというポリシーですね。作る共有によってストレージポリシーを変更できるのはFile Serviceの良さと思いました。

・ストレージ容量の割り当て:クォータ(閾値)の設定です。

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

 

こんな感じで設定しました。

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

 

ファイル共有へのアクセス権の設定です。

私は  [任意のIPアドレスからのアクセスを許可] で設定しましたが、各項目の解説です。

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

[アクセスなし]:アクセス件の設定をしない場合に選択

[任意のIPアドレスからのアクセスを許可]:一見、指定したIP アドレスからだけのアクセスを許可するような文言ですが、指定することはできません。

[ネット アクセスのカスタマイズ]:アクセスするネットワークを範囲指定する設定です。

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

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

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

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

 

最後に確認画面が表示され、 [終了]ボタンをクリックすると共有が作成されます。

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

 

共有ができあがった画面がこちら。

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

 

[URLのコピー] のリンクをクリックすると、NFSv3、NFSv4.1 を選ぶことができるので、クリックするとリンクをコピーできます。わざわざ入力する手間もかからないのですごくいい!!

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

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

 

スタンドアロンのESXiからFile Serviceをマウントする
※vSphere 7.0リリースされた現時点ではESXiでマウントはNot Supportだそうですが。

 

vSANクラスタに所属しない単独のESXiを右クリック して、[ストレージ] - [新しいデータストア...] をクリックします。

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

 

新しいデータストア [NFS] を選択して [NEXT] ボタンをクリック。

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

 

NFSの情報を入力します。

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


[FINISH]をクリック!

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


無事マウント完了。

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


ファイル共有の容量の監視は データストアをクリックし、[監視] - [vSAN] - [容量] から確認します。ファイル共有の容量は、[ユーザーオブジェクト]にふくまれるのですが、

スクリーンショットを撮り忘れました。。

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

 

使い始めるまでは以上になります。

個人的には、このNFSに仮想マシン置いたらどれくらいのIOPS出るのだろうという好奇心が湧いてきました。

 

次回はせっかく有効化したFile Serviceですが、無効化してみようとおもいます。

 

 

 

vSphere 7 - File Service for vSAN 7 を有効化してみようではないか。

File Service for vSAN7 を有効化するよ

 

手元の環境を使ってvSphere 7 のFile Service を有効化したのでスクリーンショットをペタペタ貼っていこうの会です。(まだ普通に有効化しただけですが)

私が使っている環境はvSphere7 正式GA後のものを使っているのでスクリーンショットもGA版です。

 

環境(Build 15843803)

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

 

File Service for vSAN 7 ってなに?

ようはファイル共有機能です。といってもきちんとした機能なので、ご紹介。


File Service はvSphere 7 の注目機能の1つで、vSAN 7に完全に統合されているのが特徴です。vSANデータストア上にNFSが位置するような構造になっていて、NFS v3, NFS v4.1 を介してアクセスすることになります。

vSAN自体を構築するのが簡単になっていることはご存知のとおりですが、このFile Service も有効化(構築)するのは簡単で、非常にシンプルな構造になっています。

 

注目すべきはこのFile Serviceはファイル共有がVM、PC、そしてコンテナで利用することを想定されているという点です。アピールするかのように「Pod1」「Pod2」が画面のど真ん中に表示されていますね 笑

 

 

ここ1年以上、VMware社はアプリケーションとインフラの融合をメッセージしてきていますが、技術的にはこういったところがネタになってくる部分ですね。

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

 

ただし、File Serviceを利用するにあたり、各ESXiノードごとにファイルサービスエージェントをデプロイすることになりますので、有効化ボタンを "ポチッとな" だけでは利用することはできませんので、ご注意ください。

 

ファイルサービスエージェントがNFS を提供することになるわけですが、間にDistributed File System というのがいるので、全てのファイルサービスエージェント間で構成を共有しています。(ファイル共有名など)

Windows Server のDFS(Distributed File System) をご存知の方は似たようなものだと思ってもらえればいいかなと。

 

事前準備

・各ESXiホストに配置されるファイルサービスエージェント(仮想マシン)で使うIP Addressを用意する(ESXi×4台なら4つ用意)

・準備するIP Address を全て逆引きできるできるようにしておく

・パラメータ:名前空間の名称、DNSサーバーIP Address、DNSサフィックス名

・用意が整っていればだいたい30分くらいの作業

 

有効化していく

では、File Serviceの有効化メニューを見てみましょう。

左のインベントリからvSANクラスタをクリックしたあと、[設定]タブ - [vSAN] - [サービス] の中にある [ファイルサービス] から ”有効化” ボタンをクリックするところから始まります。

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

 

概要が表示されます。この図は本当にわかりやすいですね。

Pod のアピールがすごいですが、両サイドを見るとVMもPCも接続されているので、汎用性が高いことが見て取れます。

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

 

 

vCenterからインターネット接続できるようにしているにも関わらず、直接ファイルサービスエージェントのOVFやVMDKをダウンロードできなかったです。

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

 

そのため、手動でダウンロードしました。

ダウンロードはこちらから(探すのめんどくさかった)
-VMware Virtual SAN File Services Appliance 7.0 (release date 2020-04-02)
https://my.vmware.com/jp/group/vmware/details?downloadGroup=VSAN-FILESERVICE-700&productId=973#product_downloads

File Name:
-VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.ovf
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.mf
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.cert
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-system.vmdk
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-log.vmdk
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-cloud-components.vmdk

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

 

名前空間、DNSサーバー、DNSサフィックスを入力して次へ!

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

 

ファイルサービスでどのネットワークを使うのか、を選びます。

vDSにつながっている使っている vmkernelポートはちゃんと表示してくれているという親切な表示です。

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

 

ファイルサービスエージェントが使用するIP Address のプールを指定します。

1行目のIP Address を入力したあとに"自動入力"ボタンを押すと、連番が自動入力されます。また、 "ルックアップDNS"ボタンを押すと名前解決して自動でFQDNが入ります。

事前にDNSレコードを作成しておかないと、この画面を突破できません。

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

 

設定項目がざっと一覧で表示されます。"終了"ボタンをポチっと押します。

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

 

ファイルサービスエージェントがデプロイされ自動的に「vSAN File Service Node」という名前になります。この仮想マシンの実態はPhoton OS で、VMware曰くこの上でファイルサービスとしてコンテナが動いているそうです。

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

 

ESXi1台に対して、1台のファイルサービスエージェントなので、あえてDRSは無効化してFile Serviceを有効化しましたが、特に問題なく構成ができた結果となります。

 DRSがオンだったら、稼働するホストを指定するアフィニティルールが作られたのか・・・?(未確認)

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

 

 

File Serviceの有効化がおわると、以下のようにパラメータが表示されるようになります。

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


使い方とかについては後日紹介できればとおもっています。

オワリ