さっしーの試してみるか3: Windows Server HCI

ラベル Windows Server HCI の投稿を表示しています。すべての投稿を表示

2024年4月21日日曜日

Storage Spaces Directのストレージ層を改めて見返してみる

Azure Stack HCI 22H2をSingle Server/Single Nodeから、2ノードクラスターへ変更する

の続き。

あたらめて

ストレージ層の概要テーブル

について再考しました。

Azure Stack HCI Single Node/Siingle Serverからノード追加すると、双方向ミラーが利用できるAzure Stack HCI 2ノードクラスターとなります。

この両者には、MirrorOnHDD, MirrorOnSSD, MirrorOnSCM（以降、MirrorOn*と呼称します）というストレージ層が共通項としてあります。が下記の差異もあります。

Azure Stack HCI Single Node/Siingle Server
ParityOnHDD, ParityOnSSD, ParityOnSCM（以降、ParityOn*と呼称します）
Azure Stack HCI 2ノードクラスター

NestedMirrorOnHDD, NestedMirrorOnSSD, NestedMirrorOnSCM（以降、NestedMirror*と呼称します）
NestedParityOnHDD, NestedParityOnSSD, NestedParityOnSCM（以降、NestedParityOn*と呼称します）

一つの考えとして、Azure Stack HCI Single Node/Siingle Serverからノード追加すると、双方向ミラーが利用よきるAzure Stack HCI 2ノードクラスターにした際、ParityOn*は無くても良いストレージ層ともいえます。

ここで、さらにAzure Stack HCI 3ノードクラスターに拡張すると、MirrorOn*のみがストレージ層になります。

さらにAzure Stack HCI 3ノードクラスターに拡張すると、パリティが使えるようになるため、ParityOn*が再び登場します。

Inline fault domain changesには、不要なストレージ層を削除するよう記載があります。ここまでの考えをもとに、Azure Stack HCI Single Node/Siingle ServerからAzure Stack HCI 2ノードクラスター化する際に、不要なストレージ層を削除しても良さそうですし、削除しない選択肢もあるのかなと感じました。

2023年7月28日金曜日

AksHci PowerShell モジュールの最新化

AksHci PowerShell モジュールの最新化でより良い方法はないかと。

いろいろ読み直してみたところ、

AksHci PowerShell モジュールのインストール

に下記記述（リンク）がありました。

ヘルパースクリプトを使用して古い AKS-HCI PowerShell モジュールを削除し、AKS デプロイで PowerShell のバージョン関連の問題を回避できます。

baziwane氏が投稿したスクリプトがそうです！

実行結果例は、下記のとおりです。

配列内のモジュール名を変えれば、他にも応用できますね。

2023年4月16日日曜日

diskspdのダウンロードで、ひっかかる

クイックスタート: DISKSPD をインストールして実行する

に沿って、インストールを進めていた時のことです。

ダウンロードが終わったと思い、zipファイルを展開するとエラー発生。

ファイルがダウンロードされていませんね。。。

ファイルのダウンロード先指定、相対パス、省略のいずれもエラーとなります。

となると、絶対パス指定しかない。

うまくダウンロードできました。

ということで、System.Net.WebClientでオブジェクト作成して、オブジェクト.DownloadFileメソッドを使う場合、<ENTER_PATH>は絶対パスを入れると理解しました。
以下、クイックスタート: DISKSPD をインストールして実行するより該当部分を転記しておきますね。

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.0.21a/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.0.21a.zip")

2023年1月14日土曜日

Windowsにおける環境変数NO_PROXYの書き方

Azure CLIのプロキシ設定

で、Azure CLIとPowerSehllでプロキシ設定用の環境変数について、記載してました。

後日、プロキシの例外設定をしておかないといけないケースがあり、下記にまとめました。

netsh winhttp set proxyのバイパス指定を気をつけないと、クラスター対応更新にも影響がある

で、Azure Arc Resource BridgeやAKS on Azure Stack HCIをプロキシ配下で構成している中で、やはりプロキシの例外設定が必要と理解しました。

UNIX/Linux/Macもか？だと、下記が参考になりますね。

Proxyでつらい人のためのメモ書き

では、Windowsの環境変数でNO_PROXYのお作法は、どうなるのかということで教えていただいたものに対して、ネットを探したところ類似の記法がありました。

Proxy設定

の"noProxy"行にある".example2.com,127.0.0.0/8"的な感じで良い模様。

PowerShell的に書くと、以下のようになりますかね。プライベートIPアドレスと全部入れてみました。

$env:NO_PROXY="localhost,127.0.0.0/8,.お使いのドメイン名,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

2022年12月28日水曜日

netsh winhttp set proxyのバイパス指定を気をつけないと、クラスター対応更新にも影響がある

クラスター対応更新ができなくなっていることに気づいた。

プロキシ設定が不要の時には発生しなかった。

真っ先に

netsh winhttp set proxy Proxy:portnumber "<local>;localhost;*.お使いのドメイン名"

になっていないのではと、確認してみたらやっぱりそうだった。。。

というわけで、3ノードクラスター全台に再設定しました。

結果、無事に問題解消しました！

2022年12月13日火曜日

AKS on Azure Stack HCI構成時、netsh winhttp set proxyのバイパス指定を気をつけないと、WinRMの通信がうまくいかない

以前、AKS on Azure Stack HCIを構成した時は、Proxy無しでした。

Proxy有りのケースで構成していたら、

Initialize-AksHciNode

でエラーになりました。。。

Test-WSManを実行してみると、ホスト名のみの場合でエラーになると判明しました。

この後、netsh winhttp set proxyのコマンドラインサンプルをいくつかみていたら、<local>があることを思い出した。

もしやと思って、まずnetsh winhttp set proxyを再実行しました。

Initialize-AksHciNodeを再実行しました。

うまくいきました。また一つ勉強になりました。つまり、

netsh winhttp set proxy Proxy:portnumber "<local>;localhost;*.お使いのドメイン名"

をベースにしないとダメですね。

2022年11月5日土曜日

Windows Admin Centerの更新プログラムが開始する前に、チェックしている内容

Azure Stack HCIクラスターで更新プログラムを実行した例をもとに書いています。

テストの概要

更新プログラムを実行させる前に確認しています。

これにはまってしまって、何回かリトライしました。"All failover cluster nodes must be able to access Windows PowerShell scripts"が気になったので、調べてみました。

Failover Cluster Rule ID 17 Internal Error configuring Cluster Aware Updating

から、

Tests for cluster updating readiness

にたどり着きました。

"Resolution steps"に"Ensure that all possible owner nodes of the CAU clustered role use the same PowerShell pre-update and post-update scripts."とあるのです。がそのあたりは、変えていないし、うまくいっていたケースもあるんですよね。。。

結局、2ノードを順次再起動させてみたところなんか解消したような。。。当方の環境起因でこのメッセージが出るのかもしれませんね。

インストールの前提条件の確認

更新プログラムをインストールする前に前提条件を確認しています。

クラスターの検証、CSVの状態、ブートドライブの空き容量、クラスターノードとしてVMを稼働させうるに足りるメモリ量、CPUリソース量、各クラスターノードのOSリリースチャンネルが同じであるかを見ていますね。

※とはいえ、Azure Stack HCI OSふくめクラスターノードのOSバージョンアップでは、各クラスターノードのOSリリースチャンネルが一時的に不一致になりますけどね。

2022年10月15日土曜日

Hyper-V VMの仮想TPM用証明書は、いつできるの？！

Hyper-V VMの仮想TPM用証明書をフェールオーバークラスターの全ノードに配置する

の続き。

別の3ノードS2Dクラスターへ、Hyper-V VMの仮想TPM用証明書（以降、仮想TPM用証明書と略す）を配置していました。

その際、1ノードだけHyper-V VMの仮想TPM用証明書がなかったのですね。。。

仮想TPM付きの仮想マシンを作って確認してみました。

仮想マシンを作成したタイミングでは、Hyper-V VMの仮想TPM用証明書は作成されず。

仮想マシンへのゲストOSインストールでも、Hyper-V VMの仮想TPM用証明書は作成されず。

ゲストOSのインストールが終わり、ゲストOS自体が起動したタイミングでHyper-V VMの仮想TPM用証明書は作成されてました。
※画面キャプチャは、他2ノードの仮想TPM用証明書が配置済みの状態です。

あと興味深い点があります。仮想TPM証明書名に含まれるホスト名は、証明書の作成時点のものなんだなと。

※下図赤枠のホスト名は、現在変更しています。

2022年10月10日月曜日

Hyper-V VMの仮想TPM用証明書をフェールオーバークラスターの全ノードに配置する

またひとつ、勉強になった件。

とある理由により、仮想マシンにWindows 11 Enterpriseを入れたわけです。Windows 11は、TPMが必要なので、仮想マシンハードウェアで仮想TPMを有効化しました。

で、これらの仮想マシンは、Azure Stack HCI OSによるAzure Stack HCIクラスターで動作しています。

この仮想マシン群が、うまくライブマイグレーションしないことに気づきました。
フェールオーバークラスターマネージャーでイベント出てます。

当該Hyper-Vノードのイベントログにもちらりほらりとイベントが出ています。

で、色々見ていく中で、下記のイベントを見つけました。

イベントID 24008, Microsoft-Windows-Hyper-V-VMMS

The version of the device 'Microsoft Virtual TPM Device' of the virtual machine 'g2w11e02' is not compatible with device on physical computer 'CONTOSOAX64001'. (Virtual machine ID 8A7E2A27-631D-4038-9993-40BCED805E48)