こんにちは、マイクロソフトの石井です。
Azure サポート部において、Windows による Remote Desktop サービス (RDS) を構築したいというお問い合わせをいただきます。本ポストでは、RDS on Azure 環境についての入門資料となるような情報をまとめてお伝えします。
RDS とは、1 台の Windows Server の RD セッション ホスト (RDSH) というサーバーに対して、複数のユーザーがリモート デスクトップ接続をし、業務アプリケーションや、Office 系の IT 製品を使って業務を行えるという仕組みになります。
Windows クライアント マシンなどとほぼ変わらない業務アプリケーションが実行できますが、クラウドに RDS を構築することで、ユーザーは自宅や世界中から同じデスクトップにアクセスが出来ます。
以下のように、テクノロジーによる働き方改革を実現していく方法のひとつにもなるものです。
・どこでも同じ業務が行えるということで出張先、会社、自宅問わず同じ作業をすることが出来る
・データはあくまでもクラウドに保持されるため、ノート PC のようにデータを持ち歩く心配が無いため、データ セキュリティを担保することが出来る
「どこでも業務を」ということは昨今、サービスのクラウド化、BYOD と端末管理などによって実現するということが一案になっていますが、企業によってはやはりモバイル端末側にデータを持たせたくないというポリシーがあるケースも多く、その場合、RDS on Azure は強力な選択肢になります。
このようなメリットがあることから、日本でも、複数の SIer 様において、Azure 上での構築をしていただいている実績があります。一部では数千人規模のエンド ユーザーに展開するという大規模なものも含まれます。Azure でこのような RDS 構成を取っていただくということは全く問題ありません。本 Tips が、Azure 上での RDS における勘所となれば幸いです。
環境のイメージを公式資料の Remote Desktop Services architecture より抜粋します。最初の画像がシンプルな構成、続くものが冗長化をとった構成になります。(さらに同資料では、AD を VM ではなく Azure AD DS (PaaS) で使うという、よりモダンな方法での構築も紹介されています。)
以降では、このような RDS 構築にあたってよくいただくご質問、あるいは手始めに役立つテンプレートなどをご紹介します。
- 何故このようなポストを投稿したか
はじめに、少し話しづらい点から先にさせていただきますと、私達 Azure サポート部門から提供するサポートでは、IaaS の利用形態として、インフラ側の問題についてのみが焦点になります。もちろん、構築されて問題無く動いていたものが、突然エラーとなりだしたといった「障害対応」の範囲に限れば、Windows OS の中の問題についても対応が行えます。しかしながら、「RDS 環境を構築したいので、手順を教えてほしい」といった、ゲスト OS 自体の構成方法について、手順の支援にあたっては、Premier サポートという上位のサポート契約でのみご支援が行えるものになります。
Azure IaaS における有償 Azure テクニカル サポートの対応範囲
https://blogs.technet.microsoft.com/jpaztech/2017/12/21/azure_technical_support_explained/
サポートの規約上はそうなのですが、せっかくお客様が Azure 上でのサービスを検討されている中、導線も引かずにふいにしてしまう事はとても申し訳ありませんので、このようにポストをさせていただく次第です。
- TIPS
1. RDS ライセンス (RDS CAL) が必要です
Windows の RDS 環境では、RDS CAL という特殊なライセンスが必要です。RDSH の構築後、120 日の猶予期間が与えられますが、それ以降はライセンス サーバーを構築し、RDS CAL をインストールしていない限り、ユーザーから接続ができません。
RDS CAL は、Azureの契約内で購入ができない、ということに注意してください。つまり、Azure マーケットプレースなどから、従量課金といった形態で購入ができるものではなく、ライセンスを販売するパートナーから購入していただく、Azure 以外の費用が生じるということです。
RDS CAL にはデバイス CAL とユーザー CAL といった 2 種類がありますので、運用形態に合わせて購入をご検討ください。
それぞれの違いや動作概要は以下をご参考ください。
RDS (TS) CAL について
https://blogs.technet.microsoft.com/askcorejp/2014/11/03/rds-ts-cal/
RDS CAL の購入について、ご相談についてはお客様が相談しているパートナー企業か、もしくは以下にお問い合わせ下さい。
マイクロソフト ボリューム ライセンス コールセンター (VLCC)
https://www.microsoft.com/ja-jp/licensing/contact-us.aspx
2. 一般的な Windows Server 上の RDS 環境の構築手順について
以下の手順書が有用です。Windows Server 2012 からの手順になりますが、Windows Server 2016 でもほぼ同様です。
Windows Server 2012 標準的なリモート デスクトップ サービス環境構築手順について
https://blogs.technet.microsoft.com/askcorejp/2014/07/08/windows-server-2012-2/
3. サンプルの環境やデザインパターンはあるか？
Azure でのデザインパターンの資料は、本ポスト前半の画像にもありましたとおり、Windows Server 製品部門から公式に公開されています。
Remote Desktop Services architecture
https://docs.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture
また、Azure Marketplace には、PoC(概念実証,デモ) や検証用途にて、"Remote Desktop Services (RDS) - Basic - Dev/Test" という製品が用意されています。こちらでは、簡単に以下の構成が自動的にデプロイ出来ます。
- Active Directory ドメイン コントローラー 1 台
- RD 接続ブローカー 1 台、RD Gateway 1 台
- RD セッション ホスト 1 台～任意の台数
(※ Windows Server 2012 R2 ベースです)
AD の構築、各種 RDS 機能のほか、Azure IaaS としてもロードバランサーを用いたネットワーク構成、IP アドレスの付与など、ヒントになる部分が多くあります。テスト環境として構築し、参照をしてご自身の構築に役立てていただければと存じます。
4. 1 台の RDSH に何人のユーザーが繋げるか (サイジング)
一概には答えられませんが、サイジングには以下のような考え方が適用できます。
・D(S)v2、もしくは D(S)v3/E(S)v3 といったシリーズを選択する
サイジングは Dv2、Dv3 といった、Azure Virtual Machines における汎用的で最も需要が高いシリーズをベースにしていただくとよいでしょう。
少々古くなってしまいましたが、VM のシリーズが困る、という方は以下も参考にしてください。今は Dv3 / Ev3 が最新のメジャー シリーズです。
https://blogs.technet.microsoft.com/mpn_japan/2017/06/17/azure-vm-sizing-details-1/
Azure の Windows 仮想マシンのサイズ
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/sizes
・1 台のサイズを大きくし、多くのユーザーを詰め込むという選択肢もあるが、2 台、3 台と RDSH を増やすという選択肢もある
RDSH は複数展開でき、ユーザーを分散させるようなことも可能です。1 台に詰め込む必要は無いので、横にスケーリングできることが可能ということを視野に入れて下さい。
・ユーザー プロファイル ディスク (User Profile Disk, UPD) の保存先は Premium Storage を使う
ユーザー プロファイル ディスク (UPD) へのストレージ アクセスは、特に多人数が同時作業するときにネックになります。Premium Storage はほぼ必須と考えてよいでしょう。ユーザー プロファイルを UPD としてファイル サーバーに集約しておくことで、ユーザーはどの RDSH にログインしても、自分のファイルを同じようにアクセスして作業が続行出来ます。他方、UPD は同じファイル サーバーに集約されてしまうので、負荷や、単一障害点になり得るといった点がネックになります。このため、さらに必要に応じて、後述の記憶域スペース ダイレクトや、記憶域プールによるストライピングも組み合わせて、冗長化や IOPS の増大を図ります。冗長化については後ほど補足します。
パフォーマンス ログを取りながら様子をみて、サイズ アップ、あるいは RDSH の台数増加、といった形で対処が行えるのが Azure での魅力となります。
最初のサイジングは、VM を 1 台作成し、アプリケーションを使ってパフォーマンス ログを分析する、といったことでもよいかもしれません。オンプレミスに既存環境があるようでしたら、オンプレミスのハードウェア スペックと類似するサイズを調べるということも手始めにお勧めです。
- RDS 環境の耐障害性と冗長化
RDS 環境の注意点についてですが、Azure では「VM はダウンしうる」という前提のもと、構成が必要であるという事です。
障害が発生しうるということを認識し、その対策を取ることの重要性については Azure エンジニアが解説する落ちないサービス入門 にも書きましたので、ご参照ください。
RDS の各種機能において、徹底して冗長化していくのであれば、相応にはいコストな高可用性構成を目指すこととなります。また、弱点を理解し、どういった時に障害になるのかのリスクや、心がけについてエンド様としっかりと合意を得ておくということも大事なことです。
1. RDSH について
RDSH は、ユーザーが直接ログインし、アプリケーションを立ち上げるようなサーバーです。突然のハードウェア障害、インフラ側の基盤障害などの理由で VM がダウンしてしまうと、未保存のデータは失われてしまいますので、ログインしていたユーザー数だけの影響が出てしまいます。この観点では、このサーバーは冗長化のしようがない、と言えます。
しかしながら、多くの場合、RDSH がダウンして切断されても、ユーザー側としては再度接続することで、ほかの RDSH に接続することができます。未保存のデータは失われていますが、同じようにアプリを開き、今までのデスクトップや、ドキュメント フォルダーのファイルを開き直して作業が続行できます。こう考えると、(RDS を使わないケースで) メイン業務で使っているノート PC が故障したケースと比べると、作業ができない時間ははるかに短いとも考えられます。
ただし、これは、ノート PC を配布して作業をさせるということを考えて、各ユーザーに配布した PC が突然落ちたり壊れるという事と、大きくリスクとしては変わらないのではないかとも言えます。
ユーザーの意識としては、これと変わらず、「頻繁にデータを保存すること」「極力クラウドにデータを保存すること」といった心がけに尽きます。
Office アプリケーションの一部、例えば Outlook では、書きかけのメールを 1 分ごとに自動保存するといった設定もありますので、そういった設定でもカバーが行える場合があります。
また、ローカルではなく、Onedrive for Business などのクラウド ストレージを活用するということも一案です。こうすれば、Azure 上のファイル サーバー ダウンのシナリオや、個別のユーザー プロファイル上でのファイル破損の対策にもなります。
RDSH 上で使うアプリについても、今後の展望としてはアプリケーションでのクラウド利用を想定した、「セッション切断がいつ何時でも生じること」を意識したモデルを取り入れたモダンなアプリケーションになっていくことも想定されます (スマートフォン用アプリのようなイメージです)。なるべくアプリケーション サーバー側にデータを持たせること、といったことが一例です。そうなると、RDSH が突然ダウンしてしまった場合に、アプリケーションにおいてデータが失われてしまう危険性は少なくなってくるかもしれません。
2. User Profile Disk サーバーについて
RDSH にログインするユーザーのプロファイルについては、User Profile Disk (UPD) というディスク形式で、ファイルサーバーに格納できます。
UPD を格納するファイル サーバーは、Windows Server 2016 の Storage Spaces Direct (S2D) 機能のファイル サーバーとすることで、冗長化が行えます。
このサーバーは、Premium SSD のディスクを使い、また記憶域プールでストライピングをすることで、IOPS を高めておくことが重要です。
Deploy a two-node Storage Spaces Direct scale-out file server for UPD storage in Azure
https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-storage-spaces-direct-deployment
なお、S2D によるスケール アウト ファイル サーバー (SoFS) の構成をすることになりますが、各 VM に 4 本のデータ ディスクが必要となります。Premium Storage x 4 本ずつでのストライピングで、2 VM 構成ですと合計 8 つの Premium ディスクが必要となります。
記憶域スペース ダイレクトのハードウェア要件
https://docs.microsoft.com/ja-jp/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements
必要な最小数 － 4 つの SSD
3. Active Directory ドメイン コントローラー、RD接続ブローカー、RD ゲートウェイなど
AD のドメイン コントローラー、RD 接続ブローカーや、RD ゲートウェイ、また、データベースとして利用する SQL Server などについては、各種冗長化が行えます。
個別の構成については長くなるため割愛しますが、以下のような Windows Server の技術資料にもヒントが多くあります。
Plan and design your Remote Desktop Services environment
https://docs.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-plan-and-design
Remote Desktop Services - High availability
https://docs.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-plan-high-availability
Supported configurations for Remote Desktop Services in Windows Server 2016
https://docs.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-supported-config