2023年4月22日土曜日

Azure Arc対応サーバーでエージェントのアップグレードをお勧めされる

結論としては、Windows Updateでちゃんと更新されていたのです。が、Advisorの検出には、少々タイムラグがあるなということですね。

Azure Arc対応サーバーの概要を見ていたら、Advisorからエージェントのアップグレードをお勧めされました。

クリックしていき、さらに詳細を確認していきました。
エージェントのバージョンが古いよというアドバイスでした。

推奨アクションをクリックするとLearnのドキュメントにたどり着きました。

エージェントをアップグレードする

で、確認したところ、すでにエージェントはアップグレード済みでした。

ということで、冒頭のとおり、Advisorの通知にはちょっとだけタイムラグがあるよということですー

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")

 

Azure Stack HCIのノード拡張とCSVの回復性変更で、仮想マシンのDisk I/Oはどれくらいダウンするのか

注)Nested Hyper-Vかつ、CSVあたりの仮想マシンは一つだけということで、本番環境と比較しうるにはまったくもって不十分です。これをもって、なにかを可否を判断するのは早計と考えております。そこのところを踏まて、あくまでも参考としてとらえていただけると大変助かります。

以前、下記の記事を書きました。

Azure Stack HCI Single Serverから2ノードクラスターにしましたが、更に3ノードクラスターにしてみます。

本稿は、パフォーマンス面を把握してみることにしました。しかしながら、冒頭にも書いた通りで、極めて限定的な確認です。

前提

  • Nested Hyper-VのAzure Stack HCI 22H2 クラスター
    • 400GBのCluster Shared Volume(以降、CSV)を二つ作成
    • 上記CSVにWindows Server 2022仮想マシンを一つずつ作成
      クラスター内の仮想マシン数としては、合計2個
  • 上記クラスターを2ノードから3ノードへ拡張
    • ノードの拡張は、Windows Admin Centerより実行
    • 下記ドキュメントに基づき、2個のCSVに対して、2 way Mirrorから3 way MirrorへResiliencyを変換(回復性を変更)
      2 ノードから 3 ノード以上のクラスター
      ※クラスターパフォーマンス履歴も2 way Mirrorから3 way Mirrorへ変換
  • 各パターンにてパフォーマンス計測を最低3回実施
    • 2 way Mirrorから3 way Mirrorへ変換時に、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測
    • 3 way Mirrorへ変換時後、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測
  • 上記のパフォーマンス計測は、下記ドキュメントに記載されているサンプルから変更
    DISKSPD を使用してワークロード ストレージのパフォーマンスをテストする
    • 仮想マシンのvCPU 4へ負荷をかけるため-tオプションを4(すなわち-t4)を指定
    • 読み取り要求50%と書き込み要求50%にするため、-w50を指定

2 way Mirrorから3 way Mirrorへ変換時に、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測

2 way Mirrorから3 way Mirrorへ変換は、CSVのオーナー変更を行うと開始されます。下記画像のとおり、変換にともなうRepairのストレージジョブが実行中さなか、仮想マシンでパフォーマンス計測がおこわなれるという具合です。
※Hyper-Vノード側でCSVへRepairジョブを実行、仮想マシンではパフォーマンス計測されています。
ですので、パフォーマンス計測もそのタイミングから実施しました。
各々のIOPSは下記の通り。
  • 仮想マシン1台目のIOPS平均は、258.25(小数点第3位以下は切り捨て)
    • 238.93
    • 250.265
    • 285.56
  • 仮想マシン2台目のIOPS平均は、351.67(小数点第3位以下は切り捨て)
    • 336.331
    • 292.30
    • 426.38

3 way Mirrorへ変換時後、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測

各々のIOPSは下記の通り。
  • 仮想マシン1台目のIOPS平均は、1263.66(小数点第3位以下は切り捨て)
    • 1062.59
    • 1221.91
    • 1506.50
  • 仮想マシン2台目のIOPS平均は、1136.81(小数点第3位以下は切り捨て)
    • 981.89
    • 1155.72
    • 1272.82

まとめ

仮想マシン内でのパフォーマンスは、平常時より低下することが確認できました。
  • 仮想マシン1台目のIOPSは、平常時の20%ほど
  • 仮想マシン2台目のIOPSは、平常時の30%ほど
※Hyper-Vノードの再起動後に、CSVのRepairが実行されます。そういった場合にも、上記のようなパフォーマンス低下が起こりえますね。。。

2023年4月3日月曜日

Azure Backup 用の Azure Monitor ベースのアラートに切り替える

メールが届きまして、「Azure Backup 用のクラッシクアラートが2026/03/31にリタイヤする」ということでした。

Azure Backup 用の Azure Monitor ベースのアラートに切り替える

に従って、Azure Monitor ベースのアラートに切り替えることとしました。

以降で、切り替え手順をまとめます。
※画面は、日本語版でお届けします。

今回対象となるバックアップコンテナーは、下記になります。

「バックアップセンター」の「概要」下側にある「アクティブなアラート」へスクロールします。「アクションを起こすには、ここをクリック」をクリックして、切り替えを開始します。
今回のケースでは、クラッシクアラートを使用しているバックアップコンテナー(バックアップボルト)が一つあります。

「ルールの作成」をクリックして、アラート処理ルールを新規作成します。

アラート処理ルールとアクション グループを作成するサブスクリプション、リソース グループ、リージョンを入力します。これは、冒頭で確認したものを使用します。あと未設定ですが、通知の送信先にするメールアドレスも指定しておきます。 

検証したところ、メールアドレスは配列として定義しないと駄目な模様。。。マスキングしていますが、下記イメージの感じで指定しました。
検証が成功しましたので、「作成」をクリックします。

デプロイ完了しました。

これをサブスクリプションごとに繰り返すとのこと。

アラートルールを作成したら、クラッシクアラートをオプトアウトします。
バックアップセンターに戻り、「アクションを起こすには、ここをクリック」をクリックして、クラッシクアラートのオプトアウトを開始します。

「アラートの設定」で、「更新」をクリックします。
設定画面が右側に表示されるので、「Azure Monitorアラートのみを使用」をチェックし、「更新」をクリックします。
しばらく待ってみると、表示は消えました。

切り替えとしては、以上です。

オプションとして、下記の設定もあるようなので、必要に応じ設定ですね。

計画メンテナンス期間中の通知を抑制する

2023/04/05 追記

メールアドレスを登録したことで、アクショングループに追加できた旨のメールが届きました。


2023年4月1日土曜日

Windows Admin Center in Azureの拡張は、リソースグループからも確認できます

通常、Windows Admin Center in Azureの拡張は、リソースグループから見えていません。

「非表示の方の表示」をチェックすると、Windows Admin Center in Azureの拡張は、リソースグループからも確認できますね。

Azure Stack HCIの登録先として、東日本が増えました

登録方法自体は変わりませんが、登録の流れを見てみます。
※再登録するなかで確認しました。

登録を進めます。

登録先リージョンとして、東日本が増えています。
ちなみに、

https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-hci-clusters#azure-region-availability

では、カナダ中央、東日本がまだ追記されていません。(本稿は、2023/04/01に書きました)
おってドキュメントも更新されると思われるので、待ちましょう。

追加先のリースグループ(新規作成を選びました)を指定して、登録を開始します。

しばらく待つと完了しました。

Azure Portalからも登録を確認できました。

Azure Stack HCI Single Serverのクラスター対応更新

Windows Server & Cloud User Group Japan 第34回 勉強会資料「Windows Admin Center 2211とWindows Admin Center in Azure:2023年3月」

の36ページにて少しふれていた、クラスター対応更新の有効化方法についてまとめます。

Windows Server 2019や2022のクラスターでは、PowerShellで設定しておりました。なので、Azure Stack HCIクラスターでも同様にPowerShellで設定してみました。

画面キャプチャを上記に貼りましたが、警告表示が出ます。(この時は動作に支障ないと思っていました)

GUIのクラスター対応更新から、アップデートをかけてみたのですが、失敗します。。。

クラスター対応更新の無効化、再有効化を何回かリトライしましたが、状況変わらず。
※別途、調べるつもりで今日まで放置中。

Windows Admin Centerから、クラスター対応更新の有効化を試みます。

何事もなかったかのように完了しました。。。

クラスター対応更新が可能か、確認します。

Netsted Hypre-V仮想マシンなので、ハードウェアに対するファームウェアやデバイスドライバーの更新プログラムは、ありません。この手順は、スキップするので「インストール」クリックします。
「インストール」クリックします。
クラスター対応更新も正常完了しました。

※PowerShellによる、クラスター対応更新の有効化方法で何が足りないかは、細く長く確認してみます。続報出てきたらまとめてみます。