Amazon WorkSpaces(以下、WorkSpaces)と Azure Virtual Desktop(以下、AVD)シリーズの9本目、本編ではなく番外編の記事です。
1本目は記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces事前準備編~
2本目は記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces構築編~
3本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces MFA実装編~
4本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop事前準備編~
5本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop構築編~
6本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop MFA実装編~
7本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~まとめ編~
8本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktopアクセス時自動起動設定 番外編01~
今回は自動スケールのお話です。
この機能は私が調べた限りではWorkSpacesでは実装されていません。
私が見つけれていないだけかもしれませんので、ご自身の責任で調査してください。
AVDの自動スケール機能の公式サイトは以下です。
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/autoscale-scaling-plan?WT.mc_id=Portal-Microsoft_Azure_WVD
AVDの自動スケールとは?
まずこの[自動スケール]の定義をきちんと理解しておかないと本番環境実装時に痛い目に遭いますので、私の検証した結果を記事にします。
はじめ私はこのAVDの自動スケール機能を、以下の図のような機能だと思っていました。
AVDサービスとして既存の起動中のセッションホスト(実際はただのVM)のCPU負荷やらセッション数やら何某かの負荷を監視し、この監視結果を受けて事前に設けた閾値を超えるとVMをイメージから新規で構築するという仕組みです。
まずこの認識が違いました。
実際に検証した結果、AVDの自動スケール機能は以下のような機能でした。
言葉で表現すると、セッションホストの1台当たりのRDPセッション数を監視し、ホストプール内に予め作成済み、かつ停止(割り当て解除済み)のVMを起動させ、セッションホストの起動台数を自動的にスケールアウト/スケールインする機能ということでした。
はい。
待てど暮らせどVMが新規で構築されることはありませんでした。
私の設定が間違っているという可能性も十分考えられますし、プレビュー機能なのでまだ新規構築の機能まで実装できていない、という可能性も考慮できますが、新規構築と既存VMの起動/停止では内部処理も大きく違いますし、以降の設定手順で付与する権限からも、起動と停止のみのサービスだと推察されます。
自動スケール機能の実装
はい。
またしても前置きが長くなりましたが、実装していきましょう。
AVDにVMを起動できる権限を付与する
Azure Portalに権限操作を行える権限をもつユーザでログインし、右ペインから[サブスクリプション]をクリックします。
右ペインにサブスクリプションがなければ[すべてのサービス]から検索してください。
Start VM on Connect設定対象のホストプールが存在する[サブスクリプション]をクリックします。
右ペインから[アクセス制御(IAM)]をクリックします。
[+追加]をクリックし、展開される[ロールの割り当ての追加]をクリックします。
ロール(役割)の検索ボックスが出てくるので、
[Desktop Virtualization Power On Off Contributor]と入力するとAzure ADのビルトイン権限が出てきますので、[Desktop Virtualization Power On Off Contributor]を選択し、[次へ]をクリックし
[アクセスの割り当て先]を[ユーザ、グループ、またはサービスプリンシパル]を選択し、[メンバー]を[メンバーを選択する]をクリックし、出てきた[選択]ページの検索ボックスに[Azure Virtual Desktop]もしくは[Windows Virtual Desktop]と入力し、
[Azure Virtual Desktop]をクリックし、
[選択]をクリックします。
[レビューと割り当て]をクリックします。
再度[レビューと割り当て]をクリックします。
スケジューリングプランの作成
Azure Portalにログインし、画面右ペインから[スケーリング プラン]を選択するか、[すべてのサービス]から[スケーリング プラン]を検索してください。
[+作成]をクリックします。
[サブスクリプション]は自動スケール機能の対象になるホストプールが存在するサブスクリプションを選択します。
[リソースグループ]は今回はホストプールと同じリソースグループを選択しました。サービスライフサイクルの概念がリソースグループの概念だとするならば、スケーリングプランもホストプールと統合した管理を行う方が良いだろうという判断です。
[名前]はまぁ適当につけてください。
[場所]はリージョンですが、ホストプールと同じリージョンにしました。
プレビュー機能なので実装できるリージョンが決まっています。
恐らくホストプールと同じリージョンでないと、ホストプールとスケーリングプランの関連付けができないのではないかと思いますのでご注意ください。
[タイムゾーン]はホストプールを利用する場所のタイムゾーンを選択しましょう。
[除外タグ]は大事なのですが、ここで指定したVMはスケーリングプランの対象外になります。
[次へ:スケジュール]をクリックします。
[+スケジュールを追加する]をクリックします。
1週間のカレンダー機能でどの曜日にこのスケーリングプランを適用するのかを指定します。
必要な曜日を選択し[次へ]をクリックします。
はい。
ここから自動スケールの肝になる設定値です。
まずは[ランプアップ]です。
電気を付ける、みたいなイメージでしょうか。
自動スケーリング機能が動作を開始する際の振る舞い、という感じですね。
[開始時間]は前の項目で選択した曜日のうち、何時にこのスケール機能を開始するかの設定です。
ここで指定した時間から負荷の計測が始まります。この設定値まではまだスケジュールの機能です。
開始時間を超えてからこれ以降の設定値に基づいて自動スケールの振る舞いが、次項の設定[ピーク時間]まで動作します。
一般的には業務開始30分~1時間くらい前でしょうか。
以下からスケールの判断基準に関する設定値です。
[負荷分散アルゴリズム]はAVD構築時にもあった[幅優先]と[深さ優先]のどちらかを選択します。
[幅優先]は複数台あるセッションホストのうち、同時接続セッション数がなるべく同じになる設定値、[深さ優先]は1台のセッションホストが最大セッション数になるまで1台に接続を集約させ、1台のセッションホストのセッションが最大限になり溢れたセッションが発生してはじめて2台目のセッションホストに接続を行う、という1台当たりのセッションホストの負荷のかかりかたをどのように判断してセッションを分散させるか、という設定値です。
公式サイトでは[幅優先]にしましょうとなっています。
[幅優先]にすることで次回アクセスというか、今あるセッションの次に接続されるセッションの接続までの時間が短縮されます。
幅と深さの違いを考えれば当たり前ですね。
しかもここの設定値で、元々AVD構築時に設定した幅優先か深さ優先かの設定値が上書きされます。
[ホストの最小割合(%)]はセッションホストの最大台数のうち、何%を最低限の起動台数として維持するのか、という設定値です。
簡単な言い方をすると、最低限常時起動しているセッションホストの台数を、デプロイ済みのセッションホストの台数のうち何%として指定するのか、という設定値です。
これから業務開始、という時刻を開始時間として設定するので、いつでもアクセスできるホットスタンバイ状態のVMを何台起動しておくのか、という設定値でうs。
ここで設定したVM台数で業務開始時のセッションの集中を捌きます。
[容量のしきい値(%)]は1台当たりの最大セッション数のうち、何%を超えたら次のセッションホストを起動するのか、という設定値です。
この設定値はユーザの使用感に直結します。
このしきい値が少なければ1台あたりのセッションホスト最大数までに余力のある時点、例えば最大10セッションまで接続設定しているホストプールにおいて、50%としていすれば5セッション張った時点で2台目のセッションホストを起動する、という設定値です。
これを100%にしていると、10セッションまで張ってからでないと2台目のセッションホストが起動されませんので、10セッション張った直後に11セッション目(11番目のユーザ)の接続試行が行われてから実際に接続されるまでのオーバーヘッドとして、VMの起動時間がまるまるかかってしまいます。
これらを設定し、[次へ]をクリックします。
次にピーク時間の自動スケーリングの振る舞いです。
[開始時刻]はランプアップの開始時間からここで指定した時間までは[ランプアップ]の設定値に則り、この時間からはこの[ピーク時間]で設定した自動スケーリングを行うという意味の設定値です。
[負荷分散アルゴリズム]もここで再度設定しますが、ここの設定値はどこかの設定とを上書いたりはしません。
あくまで[開始時間]で指定した時間以降のピーク時のみの振る舞いです。
[容量しきい値(%)]は前項目[ランプアップ]の[容量の閾値(%)]と同じ値になるのでグレーアウトしています。
[次へ]をクリックします。
続いて[ランプダウン]の設定です。
電気を消す、みたいなイメージでしょうか?
だんだん暗くしていくって方がイメージ的にあってますね。
ピークを過ぎてセッション数が減っていった場合のスケールインをどのような判断で行い、残っているセッション(ユーザ)に対してどのような通知を行うか、という設定値です。
[開始時刻]は実際には業務の終了時間になるでしょう。
[負荷分散アルゴリズム]は業務終了時なので[深さ優先]の方が良いでしょう。
スケールイン、つまりVMを停止していくので、起動しているVMのセッション数が公平になるような判断ではなく、なるべくユーザがセッションを張っている、つまり作業しているVMは落とさない方が無難だからです。
[ホストの最小の割合]は全セッションが切断された後、最大台数のうち何%のVMを起動したままにしておくのか、という設定値です。
[容量のしきい値]は1台当たりの最大セッション数のうち、何%までを残すセッションとして許容するのか、という設定値です。
最大10セッションまで接続できるセッションホストに、ここの値が90%だとすると、9セッションまで残っていればこのVMは「起動させたままとする」という判断を行います。
このしきい値を下回ると次の設定項目
[ユーザのログオフを強制する]の設定項目に従い、残っているセッションは強制的に切断されるか否かが決まります。
そして切断されるユーザには[通知メッセージ]の項目で設定したメッセージがポップアップで出力されます。
[ユーザをログ合おうとしてVMをシャットダウンするまでの遅延時間]は、VMにセッションが無くなってからVMを何分待機させて起動させたままにするか、という設定値です。
最後に[次へ]をクリックします。
最後の設定値[ピーク時以外の時間]の設定値です。
これはランプダウンも過ぎ、残業や深夜残業、夜間作業などの時間帯での設定値になります。
[開始時刻]は残業する方たちも減って、VMをゴリゴリ落としまくっていきますよ、という時間帯です。
[負荷分散アルゴリズム]はこの時間帯でも変更することが可能です。
[容量のしきい値(%)]はランプダウンの設定値と同じになるのでグレーアウトしています。
はい。
これで自動スケールの設定が終わりました。
自動スケールをホストプールに関連付ける。
設定したスケーリングプランをクリックします。
[ホストプールの割り当て]をクリックします。
[割り当て]をクリックします。
[ホストプールを1つ選択する]から設定したいホストプールを選択し、[割り当て]をクリックします。
以上で自動スケール設定は完了です。
動作確認
動作確認したところ、2セッションまで許可してるセッションホストに2セッション目を張ったらすぐに2台目のVMが起動し、2台目のVMのセッションを切断し、1台目のセッションも1接続にすると2台目のセッションホストが停止(割り当て解除済み)になりました。
本日はここまで。