Azure Step by Step シリーズ(3) XenApp Essentialsの設計手法

今回はXenApp Essentialsの設計手法についての記事です。XenApp Essentialsという名前の露出は結構ありますが、どのように設計すれば良いのかはなかなか情報が出てない様子ですね。
設計に苦労している皆様のお力になればと思い、まとめてみました。
ただ、Cloudなので設計思想がどんどん変わっていくことが予想されますから一旦設計して固定ではなく、定期的な設計の見直しが必要になります。
設計書はどんな頻度で書きなおすことになるのだろうか？
・・・半年に一度ドキュメント更新でお客様とレビュー・・・うっっっ、頭がガガガガッッッ。
※この記事は2018年1月4日の情報をもとに記載しています。

---

---

XenApp Essentials概要

XenApp Essentialsは、アプリケーション配信機能のみにフォーカスした製品です。Azureのマーケットプレイスから購入することができます。
最小契約数は25Userです。

従来のXenAppと何が違うのかと言うと・・・

Citrix Studioは簡易版が提供されている

Citrixを使い慣れている方は戸惑うくらいStudioが簡易化されています。ウィザードに従って設定を行えば構築できるので、初めての方には扱いやすいかと思われます。

XenAppの一部機能が制限されている

XenAppには様々な機能が実装されていますが、XenApp Essentialsでは一部機能を使用することができません。
たとえば、サーバデスクトップの配信を行うことができません。サーバデスクトップの配信を行いたい場合はフルサービス版（Citrix Cloud XenApp Service & XenDesktop Service）の導入をご検討ください。

展開方式はMachine Creation Serviceのみ

XenApp EssentialsではXenAppサーバの展開方式はMCSのみとなります。フルクローン方式、PVS方式は指定できません。
展開イメージを作成し、これを元にXenApp Serverが複数作成されていきます。

コンポーネント概要

登場人物は従来のXenAppとあまり変わりませんが、Citrix Cloud独自のCloud Connectorサーバが必要になります。
また、現時点では、Azure ADを利用することができないためActive Directoryサーバを準備する必要があります。
構成コンポーネント概要図は次のとおりです。

構成コンポーネント一覧は次のとおりです。

名称	役割	場所	作成方法
Delivery Controller	誰に何を配信するのか決める	Citrix Cloud	自動作成
Database	誰に何を配信するのか覚えておく	Citrix Cloud	自動作成
Citrix License	どれだけライセンスを持ってるか把握する	Citrix Cloud	自動作成
StoreFront	アクセスweb画面を表示する	Citrix Cloud	自動作成
NetScaler	アクセスをSSL化する	Citrix Cloud	自動作成
Cloud Connector	Azure上のサーバ群とCitrix Cloudの連携をする	Azure	自動作成
XenApp Server	配信アプリケーションを起動してユーザに提供する	Azure	自動作成
XenApp MCS Master Image	MCS展開元のイメージを作成する	Azure	手動作成
Active Directory	ユーザ権限の管理をする	Azure	手動作成
DNS	IP <>名前の変換をする	Azure	手動作成

Active Directoryはオンプレミスのものを使用しても良いですが、反応を良くするためにAzure上に複製を置いておくのが良いでしょう。

手動展開はActive Directory/DNS/MCSイメージだけ？

・・・だけです。その他のコンポーネントはXenApp Essentialsの構成ウィザードを進めることで設定内容が決まり、自動的にAzureの構成を展開してくれます。
Citrixの構築エンジニア、減員されてしまいそうです。怖いわー。

Azureの構成模式図は次のとおりです。
XenApp Essentialsのカタログ作成ごとに、新しいリソースグループが作成され、割り当てられます。
構成模式図は

• マスター2種類
• カタログ1 XenApp Server3台
• カタログ2 XenApp Server3台

という構成を例に記載してあります。

設計ポイント

では、設計にあたって考慮すべきポイントを記載します。

Active Directoryの配置場所

AD/DNSサーバが必須ですので、どこに置くか決めましょう。

• オンプレミス/Azureのどちらに配置をするのか？
• オンプレミスの場合、Azure上にADサーバの複製を配置するのか？

オンプレミス <>Azureの通信が必要な場合、Express Routeを契約してVPN化するとより安全に運用ができると思います。

ユーザあたりの消費リソース量

1ユーザあたり、どの程度のコンピューティングリソースを利用するかを決めましょう。
既存でXenAppを使用しているのならば、アセスメントで実機の消費傾向を調査すると確実です。
新規に構築する場合は、仮説をたてて当てはめてみましょう。
クラウドサービスなので柔軟に契約リソースを調整できますので、とりあえず始めてみるというのが近道かと思います。上席への説明がとても難しいとは思いますが。
次のリソース値を決めましょう。

• CPU / クロック周波数 (GHz)は？
• メモリ / 消費メモリ容量 (GB)は？
• ディスク / 消費ディスク容量 (GB)は？

XenApp Serverあたりの集約ユーザ数

1仮想マシンに対し、何ユーザを割り当てるのか決めましょう。

• XenApp Server1台あたりの集約ユーザ数は？

日商エレでは多くても50ユーザ前後に収めるようにしています。障害発生時の影響度や過度の集約によるリソースの奪い合い防止、コストメリットとのバランスを考慮すると大体50ユーザ/1サーバくらいが適切になる場合が多いです。1ユーザあたりの消費リソースが大量である場合はまた別の考慮が必要です。詳しくはまた今度。

XenApp Serverあたりのスペック

XenApp Server用仮想マシンの必要スペックは

• (2.で決めた1ユーザあたりのリソース)×(3.で決めた1サーバあたりの集約ユーザ数)=サーバのスペック

となります。
※XenApp Essentials特有のサイジングになります。従来のXenAppとは考え方がことなりますのでご注意ください。

CPU/RAM/HDDの各必要リソースを一覧化し、Azureの仮想マシンサービスモデルから適切なものを選択しましょう。
Azureではリージョンごとに提供される仮想マシンモデルが異なるため、東日本なら東日本の、西日本なら西日本の仮想マシンモデルを調べてから選択するようにしましょう。
適切な仮想マシンモデルが見つからない場合は、

• 2.で決めた1ユーザあたりのリソースを見直す
• 3.で決めた1サーバあたりの集約ユーザ数を見直す

ことでAzureの仮想マシンモデルに当てはめられるよう調整してみてください。 オンプレミスならサーバ構成でメモリだけ増設したりできるんですが、Azureなので、そこはサービス提供されているモデルに迎合せざるを得ないですね。

最小台数と最大台数

XenApp ServerはMCSで自動展開されます。このため、次の条件を決めておく必要があります。

• XenApp Serverを展開する最小台数
  最小台数の算出方法
  このシステムを常に使うユーザ数（想定するしかないでしょうね）をホストできるサーバ数を常に起動するという考え方で算出することができますね。
• XenApp Serverを展開する最大台数
  最大台数の算出方法
  1台あたりの集約ユーザ数は設計済みなので、このシステム全体を何ユーザで利用するのかがわかっていれば最大台数は算出することができますね。

最小稼動台数とピーク時間帯

XenApp Essentialsではシステムの負荷によりXenApp Serverを起動させておく台数を管理しています。不必要なXenApp Serverが停止（Azureの課金対象外）されるため、Azureの課金額を常に最適化することができます。
と、言っても「突発的なリソース消費アップに秒殺で対応するぜ！」まではできません。（MCSマシン起動そのものが秒殺ではないので・・・）
そこで、次の条件を決めておく必要があります。

• 最低でも何台起動させておくか
• 全機を稼動させるピーク時間帯は何時～何時か

これで、ピーク時間には全XenApp Serverが自動的に起動している状態になるように管理することができます。

まとめ

XenApp Essentialsの設計は次のStepを踏むことでスムーズに実施できます。

• Citrixコンポーネント構成を理解する
• Azureコンポーネント構成を理解する
• 設計ポイントを理解する
• 設計ポイントに対する値を決める

この情報がXenApp Essentialsを検討しているみなさんのお役に立ちますように。

今日はここまで。また次の記事でお会いしましょう。

---

この記事を読んだ方へのオススメコンテンツはこちら

---