Windows Server ＆ Cloud User Group Japan 第28回 勉強会 セッションビデオ「AKS on Azure Stack HCI/Windows Serverの準備と監視」を公開します

 

WSL 2で Linux ファイルシステムにアクセスできると思ったら、Windows 11 Insider Build 22000 以上ということだったのですが

Windows Subsystem for Linux 2 (以降、WSL 2) で Linux ファイルシステムをマウントできるみたいだと思って、よく読んでみると前提条件として「Windows 11 Build 22000 以上」が必要だった。

• Volumio を2.9から、3.1にアップグレードしたところ、SDカードに置いていた音楽ファイルがすべて消えた。改めてコピーしなおすとしても、NW 越しだと遅いのでダイレクトに読み書きできないか調べたところ、上記に行き着いたわけです。
• Windows 10では、Ext2Fsd 使うしかない感じ

手元にある Windows 11 のBuild を見てみると22000だった。

WSL 2を入れれば、 Linux ファイルシステムにアクセスできそうですね。

ということで、WSL 2を有効化してみました。

Volumio は、SDXC カードがパーティションに分割されています。

よって Mounting a partitioned disk に沿って進めてみました。がマウントできず。

ビルド番号は、22000なんですけどねぇ。

Windows Insider にしないとだめかもしれない？！

とりあえず次の半期リリースまで待ってみます。

Dell EMC OpenManage Integration Version 2.2.1 with Microsoft Windows Admin Center

Dell EMC OpenManage Integration Version 2.2.1 with Microsoft Windows Admin Center　がリリースされました。変更点を引用します。

• Supports Azure Stack HCI version 21H2
• Supports Windows Server 2022 HCI clusters
• Enhancements
  As part of the secured-core feature, the Trusted Platform Module (TPM) 2.0　attribute message has been enhanced to provide Dell EMC recommendation　of enabling these TPM 2.0 attributes for overall security and system resiliency, even though all these attributes may not be required for secured-core. Enabling TPM related attributes is available from the release OMIMSWAC 2.2.

コンプライアンスサマリーまで確認しました。ノードレベルの詳細情報は、隠されている感じになってますね。

Windows Server ＆ Cloud User Group Japan 第28回 勉強会 資料「AKS on Azure Stack HCI/Windows Serverの準備と監視」を公開します

AKS on Azure Stack HCI/Windows Serverの準備と監視 _ Preparing and monitoring AKS on Azure Stack HCI/Windows Server from Norio Sashizaki

特に明示的に指定しなかったけど、Switch Embedded Teaming の負荷分散モードは Hyper-V Port になっているで、良いのかな

Switch Embedded Teaming (SET)の負荷分散モード（負荷分散アルゴリズム）は Hyper-V Port になっているかを確認（振り返る）します。

Windows Server 2019の場合

下記のような感じで、SET を作ってました。

$NICs = @("イーサネット 7","イーサネット 8")

$VSwName = "SET25"

$MngName01 = "SET2501"

New-VMSwitch -Name $VSwName -NetAdapterName $NICs -AllowManagementOS 0 -EnableIov $true -EnableEmbeddedTeaming $true -Verbose

# -AllowNetLbfoTeams $false

（以下略）

こんな感じで、SET になってます。

※AllowNetLbfoTeamsは、Windows Server 2019でサポートされていないオプションです、念のため。

チーミングモード、負荷分散モードを見てみましょう。

チーミングモードは"スイッチに依存しない"、負荷分散モードは "Hyper-V" というのが、既定値ということでよいみたい。

Windows Server 2022の場合

下記のような感じで、SET を作ってました。

NICs = @("SLOT 4 ポート 1","SLOT 4 ポート 2")

$VSwName = "SET25"

$MngName01 = "SET2501"

New-VMSwitch -Name $VSwName -NetAdapterName $NICs -AllowManagementOS 0 -AllowNetLbfoTeams $false -EnableIov $true -EnableEmbeddedTeaming $true -Verbose

（以下略）

こんな感じで、SET になってます。

※AllowNetLbfoTeamsは、Windows Server 2022でサポートされているオプションで、LBFO を無効化して SET を作成しています。（既定値では、LBFO 有効なのです）

チーミングモード、負荷分散モードを見てみましょう。

チーミングモードは"スイッチに依存しない"、負荷分散モードは "Hyper-V" というのが、既定値ということでよいみたい。

以上

2022/02/14 参考資料を追記

• Teaming in Azure Stack HCI
• NIC Teaming settings
• Set-VMSwitchTeam

ウィルス対策における、AKS on Azure Stack HCI/Windows Server の除外パス

Resolve general issues when using Azure Kubernetes Service on Azure Stack HCI

の

When running AksHci PowerShell cmdlets, an Unable to Load DLL error appears

に除外パスの記載があります。以下、引用しておきますね。

プロセルのファイル名：

• kubectl.exe
• kvactl.exe
• mocctl.exe
• nodectl.exe
• wssdagent.exe
• wssdcloudagent.exe
• kubectl-adsso.exe
• AksHciHealth.exe

フォルダーのパス：

• C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\
• C:\Program Files\WindowsPowerShell\Modules\TraceProvider\
• C:\Program Files\WindowsPowerShell\Modules\AksHci\
• C:\Program Files\WindowsPowerShell\Modules\Az.Accounts\
• C:\Program Files\WindowsPowerShell\Modules\Az.Resources\
• C:\Program Files\WindowsPowerShell\Modules\AzureAD\
• C:\Program Files\WindowsPowerShell\Modules\DownloadSdk\
• C:\Program Files\WindowsPowerShell\Modules\Kva\
• C:\Program Files\WindowsPowerShell\Modules\Microsoft.SME.CredSspPolicy\
• C:\Program Files\WindowsPowerShell\Modules\Moc\
• C:\Program Files\WindowsPowerShell\Modules\PackageManagement\
• C:\Program Files\AksHci\
• C:\AksHci\
  でも、C:\AksHci\ のみ見たこと無い気がするけど。

Get-AksHciCredential と kubectl.exe

Get-AksHciCredential は、AKS on Azure Stack HCI/Windows Server で kubectl.exe を使う際、標記のコマンドレットで 対象の kube-config をダウンロードしてくれます。

上記の通り、kubectl.exe を実行し、Kubernetes クラスターを管理できます。

さて、kubectl.exe は、AKS on Azure Stack HCI/Windows Server をデプロイされた各ノードの C:\Program Files\AksHci 配下にあります。

また、CSV 配下にも、kubectl.exe がありますよ。

AKS on Azure Stack HCI/Windows Server バージョン 1.0.7.10118 が出てますよ

AKS on Azure Stack HCI/Windows Server バージョン 1.0.7.10118 と AksHci PowerShell モジュール 1.1.25も出ています。

Windows Admin Center でアップグレードできますが、PowerShell を使ったアップグレードもできます。

PowerShell を使用して AKS on Azure Stack HCI ホストをアップグレードする

1. Azure PowerShell モジュールの更新
2. 現在のバージョンのAKS on Azure Stack HCI を取得する
3. 利用可能な AKS on Azure Stack HCI 更新プログラムを取得する
4. AKS on Azure Stack HCI 更新プログラムを開始する
5. AKS on Azure Stack HCI ホストが更新されていることを確認する

という流れになります。ちなみに、上記項番1で、"-AcceptLicense"オプションを追加したほうが良いケースもあるようです。ご注意ください。

Windows Admin Center のサーバーIPアドレスを変更しても、問題なく動くよね

 Windows Admin Center のサーバー名を変えると、証明書、Azure AD のアプリ名に影響があるので、めったなことではできない。Azure AD のアプリ名は、下図赤枠の通り、FQDNが入ります。

じゃあ、IP アドレスは、大丈夫？と聞かれたので試してみました。

IP アドレス変更後、DDNS なら ipconfig /registerdns の実施、DNS の静的登録なら A レコードの更新が、各々実施されることが大前提です。

• 別の IP アドレスへの変更、元の IP アドレスへの戻し
• Windows Admin Center の WebUI には、別のマシンからアクセス
  別のマシンで名前解決に失敗する場合は、ipconfig /flushdns を実行してしばらく待つ

で、いくつかの動作をみてみました。

結果、特に問題なし。想定通りです。