2023年6月3日土曜日

Windows Admin Centerを登録すると、Azureの「アプリの登録」に出てこない

補足)Windows Admin Center 2306 Previewで、Azureへの登録ができるように治りました。 において、Windows Admin Center 2306 Previewを使うと本事象が解消することを確認しています。

Windows Admin Center含めた手元の環境だけかもしれませんが、表記の事象が出ています。

4月末から本日の6月3日まで試行錯誤した結果として、Windows Admin CenterをAzureに登録すると、「すべてのアプリケーション」に表示されました。

Windows Admin Centerでは、一見、登録が成功したように見えるのですが、Azure ADのアプリケーションとしては存在しない(リンク切れ)といった感じになります。


エンタープライズアプリケーションに表示されているアプリIDのGUIDは、エンタープライズアプリケーションのアプリIdと異なりました。

あとアプリの登録には、存在しませんでした。



2023年5月20日土曜日

グループポリシーでAzure Arcエージェントを展開する

教えていただいてから、確認するまで時間がかかってしまいましたが、標記の件、確認します。参考にするドキュメントは、日本語化されていますので、そちらのリンクを貼っておきます。

グループ ポリシーを使用して大規模にマシンを接続する

大きく6つのステップから構成されています。
※原文では、5つとグループポリシーの展開ですが、これらをあわせて6つと解釈しております。あしからずご了承ください。

  1. Windows 用の Azure Connected Machine エージェント パッケージと構成ファイルを配置するためファイル共有を作成します。
    ファイル共有のアクセス権としては、Domain Admins、Domain Computers、Domain Controllersに対して変更を付与します。下記の画像は、Domain Adminに変更を付与したもの。
    Domain Computers、Domain Controllersに対しても、同様のアクセス権を付与します。
  2. ハイブリッド マシンを大規模に Azure に接続するConnected Machine エージェントの前提条件 を確認します。リソースグループに対して、Azure リソース プロバイダーの登録がすべてできているかも大事です。
    大規模なオンボーディング用のサービス プリンシパルを作成する に沿ってサービスプリンシパルを作成します。ちなみに有効期限は、1か月にしてあります。
    続いてサービスプリンシパルのシークレットをダウンロードしておきます。
    サービスプリンシパルが作成されたことを確認しました。
  3. https://github.com/Azure/ArcEnabledServersGroupPolicy/releases/latest/ より最新版をダウンロードします。今回は、1.0.4をダウンロード&解凍しました。
    必要なファイルをドメインコントローラーへコピーするため、いったんの解凍先は、前述のファイル共有配下としています。
  4. 最新バージョンの Azure Connected Machine エージェント Windows インストーラー パッケージをダウンロードし、前述のファイル共有配下へ配置します。
  5. ドメインコントローラーに項番3で展開したファイル群をコピーします。デプロイ スクリプト DeployGPO.ps1を実行して、グループポリシーをデプロイします。
    なおReportServerFQDNパラメーターは、DeployGPO.ps1のコメントに下記の記述があったのでファイル共有をホストするサーバーのFQDNを指定します。
    .PARAMETER ReportServerFQDN
       FQDN of the Server that will act as report Server (and source files)

    ※ ServicePrincipalClientIdとServicePrincipalSecretをテレコにしていました。リトライした画像を下記に貼っておきます。

    ドメインコントローラーで実行したせいなのかデプロイ完了後に、「グループポリシーの管理」が表示されました。「グループポリシーオブジェクト」をドリルダウンすると、GPOが作成されていることが確認できました。
  6. 今回は、スタンドアロンのWindows ServerをAzure Arcにオンボードします。Windows Server OUに作成したGPOをリンクします。

    GPO適用前の状態は、下記の通りでした。
    ※すでに登録済みのサーバーは、リソースグループを別途変更してきました

でレプリケーションし終わるまで待つのも何なので。。。
ドメインコントローラー間で手動レプリケーションを行い、とあるメンバーサーバーでgpupdate /forceを実行しました。で、グループ ポリシー オブジェクトを適用する の「重要」を読むと下記の記述がありました。。。

サーバーが Arc に正常にオンボードされたことを確認したら、グループ ポリシー オブジェクトを無効にします。 これにより、システムの再起動時やグループ ポリシーの更新時に、スケジュールされたタスク内の同じ Powershell コマンドが実行されなくなります。

再起動させたほうが良さそうなのかな。。。仮想マシン2台を再起動させてみました。

Azure Connected Machine Agentがインストールされていました。ということで、順次再起動が必要ですね!

施行した2台においてGPO適用し再起動後の状態は、下記の通りです。


2023年5月19日金曜日

Azure Monitor経由で、Azure Backupの通知が来ました

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

の続き。

SCDPMから仮想マシンの保護を解除し、Azure Backupの保護も解除しました。結果、下記画像のような通知が届きました。(二つのメールアドレスを登録しておりましたので、各々に1通ずつ届きました)


Azure OpenAIのネットワーク制御というか、Azure Cognitive Servicesのネットワーク制御

Azure OpenAIにネットワーク制御があるとわかり、すべてのネットワークから受け付けないようAzure仮想ネットワークのみに絞り込んでみました。

これは、Azure OpenAIということではなく、Azure Cognitive Services 仮想ネットワークを構成する が使えると理解しました。ちなみにこのやり方を使うには、Azure Cognitive ServicesのサービスエンドポイントをAzure仮想ネットワークに作っておく必要がありますね。

では、インターネット経由でのアクセスは、拒否されるでしょうか。Azure Open AI Studioにアクセスできますが、ChatGPT プレイグラウンドでチャットをやり取りすると、下記のとおり拒否されました。

つづいて、Azure仮想ネットワークに接続している仮想マシンへBastion経由でサインインし、Azure Open AI Studio→ChatGPT プレイグラウンドでチャットを開始しました。結果として、Azure仮想ネットワークからは、チャットのやり取りができますね。


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が実行されます。そういった場合にも、上記のようなパフォーマンス低下が起こりえますね。。。