Azure Citrix Virtual Apps and Desktops

寄稿者

著者: Loay Shbeilat

謝辞: Nitin Mehta

はじめに

このガイドは、Microsoft Azure上のCitrix Virtual Apps and Desktops サービスのアーキテクチャと展開モデルを支援します。

Citrix CloudとMicrosoft Azureの組み合わせにより、新しいCitrix仮想リソースを俊敏性と伸縮自在性でスピンアップし、要件の変化に応じて使用量を調整することができます。Azure上の仮想マシンは、Citrix Virtual Apps and Desktopsサービスの展開に必要なすべての制御コンポーネントとワークロードコンポーネントをサポートします。Citrix CloudとMicrosoft Azureには、グローバルな運用のためのアイデンティティ、ガバナンス、セキュリティを確立する共通のコントロールプレーン統合があります。

このドキュメントでは、お客様の環境の前提条件、アーキテクチャ設計上の考慮事項、および導入ガイダンスについても説明します。 このドキュメントでは、次の 5 つの主要なアーキテクチャ原則について、設計上の決定と導入の考慮事項について説明します。

  • オペレー ション-オペレーションには、イメージ管理、サービス監視、ビジネス継続性、サポートなど、さまざまなトピックが含まれます。Azure PowerShell、Azure CLI、ARM テンプレート、Azure API など、オペレーションの自動化を支援するさまざまなツールが用意されています。

  • アイデンティティ -Azure 全体像の基礎の 1 つは、人の ID とその役割ベースアクセス (RBAC) です。Azure ID は、Azure Active Directory (Azure AD) および Azure AD ドメインサービスを通じて管理されます。お客様は、ID 統合の方法を決定する必要があります。

  • ガバナンス -ガバナンスの鍵は、Azure リソースの計画、アーキテクチャ、取得、デプロイ、運用管理に関連するポリシー、プロセス、手順を確立することです。

  • セキュリティ -Azure には、さまざまな構成可能なセキュリティオプションと、それらを制御する機能があります。これにより、お客様は組織の展開固有の要件を満たすようにセキュリティをカスタマイズできます。このセクションは、Azure のセキュリティ機能がこれらの要件を満たすためにどのように役立つかを理解するのに役立ちます。

  • 接続 -Azure仮想ネットワークと顧客のローカル/クラウドネットワークを接続することは、ハイブリッドネットワーキングと呼ばれます。このセクションでは、ネットワーク接続とネットワークサービスルーティングのオプションについて説明します。

計画

Azure経由でCitrix アプリとデスクトップを配信するための最も一般的な3つのシナリオは次のとおりです。

  • Azureでリソースの場所を提供するCitrix Cloudを使用したグリーンフィールドの展開。このシナリオは、Citrix Virtual Apps and Desktops サービスを通じて提供され、お客様がサブスクリプションモデルを利用し、コントロールプレーンインフラストラクチャをCitrix にアウトソーシングすることを希望する場合に使用します。
  • オンプレミス展開を Azure に拡張する。このシナリオでは、お客様は現在のオンプレミスの制御レイヤーを持っており、新しい展開または移行のために Citrix リソースの場所として Azure を追加したいと考えています。
  • リフトとシフト。このシナリオでは、お客様はCitrix 管理インフラストラクチャをAzureにデプロイし、Azureをサイトとして扱い、Citrix NetScaler とStoreFront を使用して複数のサイトのリソースを集約します。

このドキュメントでは、Citrix Cloudの展開モデルに重点を置いています。お客様は、組織のニーズに基づいて、次のサービスを計画および導入できます。

Citrix Virtual Apps and Desktops サービス

Citrix Cloud Virtual Apps およびDesktopsサービスにより、Citrix テクノロジーの提供と管理が簡素化され、既存のオンプレミスソフトウェア展開を拡張したり、100% クラウドに移行したりできます。Windows、Linux、Webアプリケーション、およびWindowsおよびLinux仮想デスクトップへの安全なアクセスを提供します。優れたエンドユーザーエクスペリエンスを維持しながら、複数のリソースの場所でアプリケーションやデスクトップを一元的に管理できます。

Citrix Virtual Desktops Essentials サービス

Citrix とMicrosoftのお客様には、組織内にWindows 10 Enterpriseを展開するオプションが増えています。Citrix Virtual Desktops Essentials サービスでは、Microsoft Azureクラウドソリューションを好むお客様のために、Windows 10 Enterpriseへの移行を迅速化します。これにより、ユーザーごとに Windows 10 Enterprise (Current Branch for Business) のライセンスを取得しているお客様は、Azure から高性能な Windows 10 Enterprise 仮想デスクトップエクスペリエンスを提供することができます。

Citrix Virtual Apps Essentials サービス

新しいアプリケーション仮想化サービスであるCitrix Virtual Apps Essentialsは、Citrix Cloudプラットフォームのパワーと柔軟性と、シンプルで規範的で使いやすいMicrosoft AzureのRemoteAppのビジョンを組み合わせたものです。Citrix Virtual Apps Essentials、バックエンドインフラストラクチャをクラウドに移行することで、管理やエンドユーザーエクスペリエンスを犠牲にすることなく、アプリケーションの配信を簡素化することで、優れたパフォーマンスと柔軟性を実現します。

コンセプトリファレンスアーキテクチャ

この概念的なアーキテクチャでは、AzureでCitrix Cloudリソースの場所を展開するための一般的なガイドラインを提供します。これについては、以下のセクションで説明します。

Azure-RA-Image-1

図-1:Citrix Cloudの概念的なリファレンスアーキテクチャ

Microsoft AzureでのCitrix Virtual Apps and Desktopsサービスの配信のスケーラビリティと経済性については、ホワイトペーパーを参照してください。

操作

このガイドでは、Workspace 領域環境の要件と基礎サービスの階層のプランニングについて詳しく説明します。最上層には、サブスクリプション、リソースグループ、および地域設計に関する考慮事項があります。VMストレージ、ユーザープロファイルストレージ、マスターイメージ管理/プロビジョニングに関する一般的な質問が続きます。また、Autoscaleによるリザーブドインスタンスの最適化、およびビジネス継続性/ディザスタリカバリの計画に関するガイダンスも提供されます。

命名規則

Microsoft Azure のリソースの名前付けは、次の理由で重要です。

  • ほとんどのリソースは、作成後に名前を変更できません。
  • 特定のリソースタイプには異なる命名要件がある
  • 一貫した命名規則により、リソースの検索が容易になり、リソースの役割を示すことができます。

命名規則を成功させる鍵は、アプリケーションと組織全体で命名規則を確立し、それに従うことです。

Azure サブスクリプションに名前を付ける場合、冗長な名前によって、各サブスクリプションのコンテキストと目的が明確になります。命名規則に従うと、多くのサブスクリプションがある環境で作業するときの明瞭さが向上します。

サブスクリプションの命名に推奨されるパターンは次のとおりです。

変数 説明
[システム] CTX (Citrix)、CORE (Azure) リソースがサポートする製品、アプリケーション、またはサービスの 3 文字の識別子。
[役割] XAW(XenAppワーカー)、VDA(Virtual Delivery Agent)、CC(Cloud Connector)、CVA(Citrix Virtual Apps) サービスのサブシステムを表す 3 文字の識別子。
[環境] D、T、P(開発、テスト、またはprod) リソースの環境を識別します。
## 01, 02 複数の名前付きインスタンス(ウェブサーバーなど)を持つリソースの場合。
[場所] WU(米国西部)、EU(米国東部)、SCU(米国中南部) リソースのデプロイ先の Azure リージョンを識別します。

Azure でリソースに名前を付けるときは、共通のプレフィックスまたはサフィックスを使用して、リソースの種類とコンテキストを識別します。タイプ、メタデータ、コンテキストに関するすべての情報はプログラムで利用可能ですが、共通の接尾辞を適用することで視覚的な識別が簡単になります。接尾辞を命名規則に組み込む場合は、接辞を名前の先頭 (接頭辞) にするか、最後尾 (接尾辞) にするかを明確に指定することが重要です。

明確に定義された名前付けスキームは、システム、ロール、環境、インスタンス数、および Azure リソースの場所を識別します。名前付けは、Azure ポリシーを使用して適用できます。

サービス スコープ 推奨されるパターン
サブスクリプション グローバル [System][Environment]##[Location]-sub WSCD01scu-sub
リソース グループ グローバル [System]-[Role]-[Environment]##-[Location]-rg CTX-Apps-P01-CUS-rg
仮想ネットワーク リソース グループ [System][Environment]##[Location]-vnet CTXP01cus-vnet
サブネット 親VNET [Descriptive Context] DMZ - 10.0.1.0/24 Infrastructure - 10.0.2.0/24
ストレージ アカウント リソース グループ [System][Role][Environment]##[Location] 注:小文字の英数字を使用する必要があります。 ctxinfd01scu
コンテナ ストレージ アカウント [Descriptive Context] vhds
仮想マシン リソース グループ [System][Role][Environment]##[Location] 注:15 文字以下である必要があります。 CTXSTFD01scu
ネットワーク インターフェイス リソース グループ [vmname]-nic# CTXSTFD01scu-nic1
パブリックIPアドレス リソース グループ [vmname]-pip CTXSTFD01scu-pip
仮想ネットワーク ゲートウェイ 仮想ネットワーク [System][Environment]##[Location]-vng WSCD01scu-vng
ローカルネットワークゲートウェイ リソース グループ [System][Environment]##[Location]-lng WSCD01scu-lng
可用性セット リソース グループ [System][Role]-as CTXSTF-as
ロードバランサー リソース グループ [System][Role]-lb CTXNSG-lb
ストア サブスクリプション [System][Environment]-analytics CTXP-analytics
タグ リソース [Descriptive Context] Finance
キー・ヴォールト サブスクリプション [System][Environment]-vault CTXP-vault

サブスクリプション

サブスクリプションモデルの選択は、Citrix 展開内外におけるお客様のAzureフットプリントの拡大を理解する複雑な決定です。Citrix の展開が小さい場合でも、Azure APIに対して大量の読み取り/書き込みを行う他のリソースが依然として多いため、Citrix環境に悪影響を及ぼす可能性があります。その逆も同様です。多くのCitrix リソースが利用可能なAPI呼び出しを大量に消費し、サブスクリプション内の他のリソースの可用性を低下させる可能性があります。

シングルサブスクリプション Workspace モデル

単一のサブスクリプションモデルでは、すべてのコアインフラストラクチャとCitrix インフラストラクチャが同じサブスクリプションに配置されます。これは、最大1,000個のCitrix VDAを必要とするデプロイメントに推奨される構成です。

Azure-RA-Image-2

図 2: Azure シングルサブスクリプション Workspace モデル

マルチサブスクリプション Workspace モデル

このモデルでは、コアインフラストラクチャとCitrix インフラストラクチャは、大規模な展開環境でのスケーラビリティを管理するために別々のサブスクリプションになっています。多くの場合、マルチリージョンインフラストラクチャ設計のエンタープライズデプロイは、Azure サブスクリプションの制限に達しないように、複数のサブスクリプションに分割されます。

Azure-RA-Image-3

図 3: Azure マルチサブスクリプション Workspace モデル

以下の質問は、お客様が Azure サブスクリプションオプションを理解し、リソースを計画するのに役立つガイダンスを提供します。

コンポーネント 条件
AzureサブスクリプションにはCitrix リソースのみが含まれていますか? Azureサブスクリプションを専用のCitrix リソースに使用するか、Citrixリソースを他のシステムと共有するかを決定します。
単一または複数サブスクリプションの展開 通常、複数のサブスクリプション展開は、単一のサブスクリプションの制限が問題であり、より詳細なセキュリティ制御が必要な大規模な展開用です。
どのような Azure の制限に達する可能性がありますか? リソースグループにはいくつのリソースがありますか。 リソースグループには制限があり、Machine Creation Service(MCS)にはVMリソースあたり2台または3台のディスクが必要です。ソリューションの計画中にAzure サブスクリプションの制限を確認します。
Azure サブスクリプションの CVAD サービスの原則にはどのようなアクセス許可が必要ですか。 Citrix Virtual Apps and Desktops では、サブスクリプション内にリソースグループとリソースを作成する必要があります。たとえば、サービスプリンシパルにサブスクリプションへのフルアクセスを許可できない場合は、事前に作成されたリソースグループへの共同作成者アクセス権を付与する必要があります。
開発環境とテスト環境は、本番環境とは別のサブスクリプションで作成されますか? 開発サブスクリプションとテストサブスクリプションを運用環境から分離することで、孤立した環境とサイロリソース使用率におけるグローバル Azure サービスのアプリケーションおよび変更が可能になります。このプラクティスには、セキュリティ、コンプライアンス、サブスクリプションのパフォーマンスに関する利点があります。これらの環境用にサブスクリプションを個別に作成すると、イメージ管理が複雑になります。これらのトレードオフは、お客様のニーズに基づいて考慮する必要があります。

Azure Regions

Azure リージョンは、レイテンシーによって定義された境界内にデプロイされ、専用のリージョンの低レイテンシーネットワークを介して接続される一連のデータセンターです。Azure は、必要な場所にアプリケーションをデプロイする柔軟性をお客様に提供します。Azure は世界中の 42 のリージョンで一般公開されており、2018 年 11 月より 12 のリージョンについて計画が発表されています。

地理とは、通常、2 つ以上の Azure リージョンを含む離散的な市場で、データの常駐とコンプライアンスの境界を維持します。地域によって、特定のデータ常駐とコンプライアンスのニーズを持つお客様は、データとアプリケーションを緊密に保つことができます。

アベイラビリティーゾーンは、Azure リージョン内の物理的に独立した場所です。各アベイラビリティーゾーンは、独立した電源、冷却、ネットワーキングを備えた 1 つ以上のデータセンターで構成されます。アベイラビリティーゾーンを使用すると、ミッションクリティカルなアプリケーションを、高可用性と低レイテンシーのレプリケーションで実行できます。復元性を確保するために、有効なすべてのリージョンに少なくとも 3 つの個別のゾーンがあります。

地域を選択する際には、これらの要因を考慮してください。

コンポーネント 条件
コンプライアンスとデータ常駐サービス お客様は特定のコンプライアンス要件またはデータ常駐要件を持っていますか。Microsoft は、データの冗長性やその他の運用上の目的で、特定の Geo 内のリージョン間で顧客データをコピーすることがあります。たとえば、Azure グローバル冗長ストレージ (GRS) は、データセンターの大きな災害が発生した場合に、同じ Geo 内の 2 つのリージョン間で BLOB データとテーブルデータをレプリケートし、データの耐久性を強化します。特定の Azure サービスでは、サービスのデプロイ先のリージョンを指定できません。これらのサービスは、指定がない限り、Microsoft のデータセンターに顧客データを格納する場合があります。最新のアップデートについては、Azure Regions mapWeb サイトを確認してください。
サービスの可用性 暫定地域内でのサービスの可用性を確認します。リージョン別のサービスの可用性は、お客様がリージョン内で利用可能なサービスを判断するのに役立ちます。Azure Service は特定のリージョンでサポートされる可能性がありますが、Azure 政府、ドイツ、中国などのソブリンクラウドでは、すべてのサービス機能が利用できるわけではありません。
Citrix 展開の対象となるAzureリージョンを決定します。 ユーザーと顧客のデータセンターに対する Azure リージョンの近接性を確認します。
複数の Azure リージョンが必要ですか? 複数の Azure リージョンは、通常、次のような高レベルの理由で考慮されます。-アプリケーションデータまたはエンドユーザーへの近接-ビジネス継続性と災害復旧のための地理的冗長性-Azure の機能またはサービスの可用性

可用性セット

可用性セットは、Azure で使用できる論理的なグループ化機能です。Azure では、可用性セット内に配置された VM リソースが Azure データセンター内にデプロイされるときに、相互に分離されます。Azure では、可用性セット内に配置された VM が複数の物理サーバー、コンピューティングラック、ストレージユニット、およびネットワークスイッチにわたって実行されることが保証されます。ハードウェアまたは Azure ソフトウェアの障害が発生した場合、VM のサブセットのみが影響を受け、アプリケーション全体が稼働したままであり、お客様が使用できる状態を維持します。可用性セットは、お客様が信頼性の高いクラウドソリューションを構築したい場合に不可欠な機能です。

Citrix環境の各コンポーネントは、Citrix 環境全体の可用性を最大化するために、独自の可用性セットに配置する必要があります。たとえば、Cloud Connectorには別の可用性セットを使用し、Citrix Application Delivery Controller(ADC)、StoreFront などには別の可用性セットを使用する必要があります。

可用性セットが最適化されると、次のステップは、可用性セット内の仮想マシンのダウンタイムに関する復元性を構築することです。これにより、MicrosoftがVMを再起動または再デプロイする際のサービスのダウンタイムを最小化/排除できます。これは、計画的なメンテナンスイベントにも拡張できます。サービス全体の信頼性を高めることができる機能が 2 つあります。

これら 2 つの機能は、予期しないメンテナンスやクラッシュから保護しません。

  • Azure の計画されたメンテナンス
  • Azure のスケジュールされたイベント

Azure の計画されたメンテナンス

Azure は定期的に更新を実行して、Azure のホストインフラストラクチャの信頼性、パフォーマンス、およびセキュリティを向上させます。メンテナンスで再起動が必要な場合は、Microsoft から通知が送信されます。Azure Planned Maintenance を使用すると、これらの通知をキャプチャし、Microsoft のスケジュールではなく、顧客のスケジュールに従って事前にアクションを実行することができます。

各層のサービス所有者に電子メール通知を送信することで、計画されたメンテナンス機能を利用し (手動介入のため)、サービス保護を自動化する Runbook を構築します。

Azure のスケジュールされたイベント

Azure のスケジュールされたイベントは、すぐにメンテナンスを通知するプログラムによってアプリケーションに通知を与える Azure メタデータサービスです。アプリケーション管理者が中断に備えて制限できるように、今後のメンテナンスイベント (再起動など) に関する情報を提供します。計画的なメンテナンスのように聞こえるかもしれませんが、そうではありません。主な違いは、これらのイベントは、計画されたメンテナンスと場合によっては計画外のメンテナンスで発生することです。たとえば、Azure がホストの修復活動を行っており、短期間で仮想マシンを移動する必要がある場合などです。

これらのイベントはプログラムによって消費され、次の事前の通知を与えます。

  • フリーズ — 15 分
  • 再起動 — 15 分
  • 再デプロイ — 10分

障害回復(DR)

Azure は、今日のクラウド導入から即時の価値を引き出そうとしている Citrix のお客様に、非常にコスト効率の高い DR ソリューションを提供できます。展開モデルのトポロジによって、DR ソリューションの実装が決まります。

アーキテクチャの拡張

このトポロジでは、管理インフラストラクチャはオンプレミスのままですが、ワークロードは Azure にデプロイされます。オンプレミスのデータセンターに到達できない場合、既存の接続ユーザーは接続されたままですが、管理インフラストラクチャが使用できないため、新しい接続はできません。

管理インフラストラクチャを保護するには、Azure Site Recovery を事前に構成して、管理インフラストラクチャを Azure に回復します。これは手動プロセスであり、リカバリ後もお客様の環境を運用可能にできます。このオプションはシームレスではなく、NetScaler VPXなどのコンポーネントをリカバリすることはできませんが、より柔軟な目標復旧時間(RTO)を持つ組織では運用コストを削減できます。

ホスティングアーキテクチャ

このトポロジを展開すると、Citrix 管理インフラストラクチャはAzureにデプロイされ、別のサイトとして扱われます。これにより、サイト障害発生時にオンプレミス展開から機能を分離できます。Citrix NetScaler とStoreFront を使用してリソースを集約し、本番リソースと災害復旧リソース間でほぼ瞬時にフェイルオーバーできるようにします。

AzureにCitrix Infrastructureが存在すると、ユーザーがコアWorkspace にアクセスする前に手動プロセスを呼び出す必要はなく、システムを復元する必要もなくなります。

クラウドサービスアーキテクチャ

Citrix Cloudを使用すると、Azureは別のリソースの場所になります。このトポロジーでは、管理コンポーネントが Citrix as a Service によってホストされるため、最もシンプルな展開を実現できます。また、障害復旧ワークロードは、重複するインフラストラクチャを展開せずに実現できます。災害発生時のフェイルオーバー時のユーザー・エクスペリエンスは、事実上シームレスに実現できます。

次の表の項目は、お客様の DR 計画に役立ちます。

コンポーネント 条件
Citrix 環境のRTOおよびRPO要件はどのようなものですか。 RTO:目標とする期間とサービス・レベル。災害発生後にビジネス・プロセスをリストアする必要があります。RPO:中断中に失われたデータ量がビジネス継続性プランの最大許容しきい値(許容値)を超過するまでの時間間隔。 「
Azure 仮想マシンアプリケーションがデプロイされているリージョン全体でサービスの中断が発生した場合、どのような結果が得られますか。 これらのオプションは、お客様のDRに対するRTOおよびRPOに合わせて確認する必要があります。AzureのCitrix 環境の災害復旧は、次の方法で対処できます。*Azureサイトの復旧*パッシブセカンダリサイト*アクティブサイトのAzureサイト。リカバリは、サーバーOS(Citrix インフラストラクチャおよびサーバーVDA)のみをサポートします。クライアントOSはサポートされません(ARMテンプレートを使用して作成された永続デスクトップなど)。また、MCS(サーバーまたはクライアントVDA)で作成されたマシンカタログは、リカバリタスクを使用して再作成する必要があります。

リソース グループ

Azure のリソースグループ (RG) は、簡単または自動的なProvisioning、監視、およびアクセスコントロールを実現し、コストをより効果的に管理するための論理グループの資産を集めたものです。Azure で RG を使用する利点は、アプリケーションに属する関連リソースをグループ化することです。これらのリソースは、作成から使用まで、そして最後にプロビジョニング解除まで統一されたライフサイクルを共有するためです。

リソースグループを適切に設計するための鍵は、リソースグループに含まれるリソースのライフサイクルを理解することです。

最初の作成時に、マシンカタログに1つ以上のリソースグループを適用できます。これらのリソースグループはマシンカタログ間で共有できません。リソースグループは240に制限されています。リソースグループ内のリソースの種類ごとに 800 リソース数の制限があるため、Citrix MCS VM。

リソースグループは作成時にマシンカタログに関連付けられ、後で追加または変更することはできません。マシンカタログにリソースグループを追加するには、マシンカタログを削除して再作成する必要があります。

イメージの管理

イメージ管理は、開発、テスト、本番環境にわたって一貫して適用されるイメージの作成、アップグレード、割り当てを行うプロセスです。イメージ管理プロセスを開発する際には、次の点を考慮する必要があります。

オンデマンドプロビジョニング

お客様は、MCS を使用して Azure 非永続的なコンピューターを管理するか、独自の Azure Resource Manager (ARM) テンプレートを作成するかを決定する必要があります。MCS を使用してマシンカタログを作成する場合、Azure のオンデマンド Provisioning 機能を使用すると、ストレージコストが削減され、カタログの作成が高速になり、仮想マシン (VM) のパワー操作が高速になります。Azureのオンデマンドプロビジョニングでは、VMは、プロビジョニング完了後、Citrix Virtual Apps and Desktopsで電源投入操作が開始されたときにのみ作成されます。仮想マシンはAzureポータルで実行されている場合にのみ表示され、Citrix Studioでは電源ステータスに関係なく、すべての仮想マシンが表示されます。ARMテンプレートまたはMCSで作成されたマシンは、Citrix StudioのAzureホスト接続を使用してCitrixによって電源管理できます。

ストレージアカウントコンテナ

お客様は、Citrix Machine Creation Services(MCS)を使用して仮想マシンの作成元となるソース(またはゴールデン)イメージの保存の組織構造を決定する必要があります。Citrix MCSイメージは、スナップショット、管理対象または非管理対象ディスクから作成でき、標準ストレージまたはプレミアムストレージに配置できます。非管理ディスクは、汎用ストレージアカウントを介してアクセスされ、Azure Blob ストレージコンテナー内に VHD として格納されます。コンテナは、実稼働、テスト、開発イメージを分離するために使用できるフォルダです。

イメージ・レプリケーション

お客様は、リージョン間でイメージを複製するための適切なプロセスと、全体的なイメージ管理戦略でCitrix App Layering テクノロジーを使用する方法を決定する必要があります。PowerShell スクリプトを Azure オートメーションと共に使用して、イメージレプリケーションをスケジュールすることができます。Citrix App Layering の詳細については、こちらを参照してください。Elastic Layeringには、Azureファイルには存在しないSMBファイル共有が必要であることに注意してください。Elastic Layering をサポートするサポートされている SMB 共有テクノロジについては、「ファイルサーバー」セクションを参照してください。

ファイル・サーバ・テクノロジー

Azureは、Citrixユーザーデータの保存、移動プロファイル情報の保存、またはCitrixレイヤー共有のターゲットとして機能するために使用できるいくつかのファイルサーバー技術を提供しています。これらのオプションには、次のものがあります。

  • スタンドアロン・ファイル・サーバ
  • ストレージ・レプリカを使用するファイル・サーバ
  • ストレージスペースを直接使用したスケールアウトファイルサーバー (SOFS) (S2D)
  • 分散ファイル・システム:レプリケーション(DFS-R)
  • Azure マーケットプレースのサードパーティ製ストレージアプライアンス (NetApp など)

お客様は、ビジネス要件に最適なファイル・サーバ・テクノロジーを選択する必要があります。次の表は、各ファイル・サービング・テクノロジーの利点と考慮事項の概要を示しています。

オプション 長所 注意事項
スタンドアロン・ファイル・サーバ よく知られ、テストされています。既存のバックアップ/リストア製品との互換性 単一点障害。データの冗長性はありません。毎月のパッチ適用の停止。通常は分単位で測定されます。
ストレージ・レプリカを使用するファイル・サーバ ブロックレベルの複製。SMB 3.0. ストレージに依存しない(SAN、クラウド、ローカルなど)。同期レプリケーションと非同期レプリケーションを提供します。複数リージョンアクセスが必要な場合に推奨 手動フェイルオーバーが必要です。2 倍のディスク容量を使用します。手動フェイルオーバーでは、ダウンタイムは発生しますが、通常は分単位で測定されます。DNS の依存関係。
ストレージスペースの直接の SOFS 高可用性。マルチノードおよびマルチディスクHA。スケールアップまたはスケールアウト。SMB3.0および3.1です。計画的および予期しない保守作業中の透過的なフェイルオーバー。Azure 内のユーザープロファイルストレージに推奨 2 ~ 3 倍のディスク容量を使用します。サードパーティ製のバックアップソフトウェアサポートは、ベンダーによって制限される可能性があります。複数リージョンの展開をサポートしない
分散ファイル・システム:レプリケーション ファイル・ベースのレプリケーションのための実証済みのテクノロジー。PowerShell をサポート ドメインベース。アクティブ-アクティブ構成では展開できません。
サード・パーティ製ストレージ・アプリケーション 重複除外テクノロジー。ストレージスペースのより良い使用。 追加費用。独自の管理ツール。

推奨されるファイル・サーバの仮想マシン・タイプは、通常、DS1、DS2、DS3、DS4、またはDS5で、お客様の使用要件に応じて適切な選択を行います。最高のパフォーマンスを得るには、Premium ディスクのサポートが選択されていることを確認します。その他のガイダンスについては、Microsoft Azureドキュメントを参照してください。

インフラストラクチャ・コスト管理

Azure の Citrix 環境のコストを削減するために使用できる 2 つのテクノロジを利用できます。リザーブドインスタンスと Citrix Autoscale。

リザーブドインスタンス

Azure リザーブド VM インスタンス (RI) は、Windows および Linux 仮想マシン (VM) で 1 年または 3 年の期間を使用することにより、従量課金制の料金に比べて最大 72% のコストを大幅に削減します。Azure RI で得られるコスト削減と Azure ハイブリッド特典の付加価値を組み合わせることで、最大 80% の節約を実現できます。80% は、通常の従量課金レートと比較して、Windows Server の 3 年間の Azure リザーブドインスタンスのコミットメントに基づいて計算されます。

Azure リザーブドインスタンスは、 コンピューティング 能力を事前にコミットする必要がありますが、リザーブドインスタンスをいつでも交換またはキャンセルできる柔軟性も備えています。予約には、仮想マシンのコンピューティングコストのみが含まれます。ソフトウェア、ネットワーク、ストレージの追加料金は削減されません。これは、Citrix インフラストラクチャとユースケースに必要な最小容量に適しています (オンとオフ時間).

Citrix Autoscale 機能は、リザーブドインスタンスと連携してコストをさらに削減できます。クラウド内のバーストにAutoscaleを使用できるようになりました。デリバリーグループでは、自動スケーリングが必要なマシンにタグを付け、リザーブドインスタンス(またはオンプレミスのワークロード)を除外できます。詳細については、こちらをご覧ください:デリバリーグループの特定マシンに対するAutoscaleの制限

Citrix Autoscale

Autoscaleは、Citrix Virtual Apps and Desktopsサービス専用の機能であり、プロアクティブにマシンの電源を管理するための一貫した、高性能なソリューションを提供します。その目的は、コストとユーザーエクスペリエンスのバランスを取ることです。Citrix Autoscaleにより、Smart Scaleテクノロジ(廃止)をStudioの電源管理ソリューションに組み込むことができます。

マシンの種類 スケジュールベース 負荷ベース ロードおよびスケジュールベース
公開アプリケーションまたはホストされた共有デスクトップをホストするサーバーOS マシン(サーバーVDI) サポートされる サポートされる サポートされる
静的(専用)VDIデスクトップをホストするデスクトップOS マシン サポートされます。マシンの電源がオフになっている間(勤務時間後など)、ユーザーはCitrix Receiverを介してマシンの電源を投入できます。Autoscaleの [電源オフの遅延] を設定して、ユーザーがセッションを確立する前にAutoscaleでマシンの電源が自動的にオフにならないようにすることができます。 未割り当てのマシンでのみサポートされます。 未割り当てのマシンでのみサポートされます。
デスクトップOS -ホストするマシン-ランダムで非永続的なVDIデスクトップ(プールされたVDIデスクトップ) サポートされる サポートされます。[セッション数] スケーリングメトリックを使用して、セッションの最大数を 1 に設定します。 サポートされます。セッション数スケーリングメトリックを使用して、マシンの最小数を 1 に設定します。

Autoscaleでは、Virtual Apps and Desktops、Virtual Apps and Desktopsサービス、Virtual Apps Essentials、およびVirtual Desktops Essentials のサイトの電源管理がサポートされています。

これらのサービスのいずれかを使用した単一サイトの電源管理は、次のようにサポートされます。

  • サイトあたり最大2,000台のVDAまたはVDAを電源管理できます。
  • 最大120のデリバリーグループを電源管理できます。
  • デリバリーグループあたり最大1,000個のVDAまたはVDAを電源管理できます。

Azure-RA-Image-4

図-4:Citrix のAutoscaleフロー

Citrix Autoscaleについて詳しくは、こちらをご覧ください:こちら

エンドユーザーエクスペリエンスの最適化

エンドユーザーエクスペリエンスの最適化には、エンドユーザーの応答性に対する認識と、予算内に収まるというビジネスニーズのバランスをとる作業が含まれます。このセクションでは、ビジネスおよびエンドユーザーに適した規模の環境を提供することに関する設計概念と決定について説明します。

ユーザー・ワークスペースの定義

ユーザー評価の計画を立てる際には、Citrix VDIハンドブックとベストプラクティスドキュメントに貴重なガイダンスが記載されています。既存のユースケースとエンドユーザーに必要なリソースをよく理解するために、次の高レベルの質問を確認してください。

トピック 質問
ユーザーの数 環境内に何人のユーザーが期待されていますか。評価フェーズで適切な VDI モデルが決定されましたか。(Virtual Apps またはVirtual Desktops)
使用例 エンドユーザーが消費するアプリケーションの種類を教えてください。アプリケーションのVDA要件はどのようなものですか?アプリケーションはどのように最適に配信されますか?(Virtual Apps Virtual Desktops)
ユーザーグループの勤務時間 ユーザーが環境にアクセスするのはいつですか。ピーク時間は何時ですか?1日を通して予想される消費量はどれくらいですか?(特定の時間帯のユーザーの消費は、スケールの自動化と Azure リザーブドインスタンスの購入に関するWorkspace 要件を特定するのに役立ちます)。
場所 エンドユーザーの所在地ワークスペースを複数のリージョンにデプロイするか、1 つのリージョンにのみデプロイするか。
ユーザーおよびアプリケーションデータ ユーザーとアプリケーションのデータはどこに保存されますか。データは Azure のみに含まれるか、オンプレミスのみ、またはその両方が混在するのか。ユーザーデータにアクセスするための最大許容レイテンシーはどれくらいですか?

Azure VM インスタンスタイプ

各Citrix コンポーネントは、Azureの関連する仮想マシンの種類を利用します。使用可能な各 VM シリーズは、VM に割り当てられたリソース (CPU、メモリ、IOPS、ネットワークなど) を制御するさまざまなサイズのワークロードの特定のカテゴリ (汎用、コンピューティング最適化など) にマッピングされます。

ほとんどの Citrix デプロイメントでは、D シリーズと F シリーズのインスタンスタイプが使用されます。Dシリーズは、Citrix インフラストラクチャコンポーネントに一般的に使用され、Fシリーズインスタンスタイプに含まれない追加のメモリを必要とするユーザーのワークロードにも使用されます。F シリーズのインスタンスタイプは、応答性の認識をもたらすプロセッサが高速であるため、フィールドで最も一般的です。

**DシリーズまたはFシリーズを選ぶ理由 **Citrix の観点から見ると、ほとんどのインフラストラクチャコンポーネント(Cloud Connector、StoreFront、NetScaler など)はCPUを使用してコアプロセスを実行します。これらのVMタイプは、バランスのとれたCPUとメモリ比を持ち、均一なハードウェア(Aシリーズとは異なり)でホストされ、一貫したパフォーマンスを実現し、プレミアムストレージをサポートします。確かに、顧客は、ニーズと予算に合わせてインスタンスタイプを調整できます。

お客様のインフラストラクチャ内のコンポーネントのサイズと数は、お客様の要件、規模、ワークロードに常に依存します。しかし、Azure では、動的にオンデマンドで拡張できます。コスト重視のお客様には、小規模な開始とスケールアップが最適なアプローチです。Azure VM では、サイズを変更するときに再起動が必要となるため、スケジュールされたメンテナンスウィンドウ内および確立された変更管理ポリシーの下でのみこれらのイベントを計画します。

スケールアップやスケールアウトはどうですか?

お客様のユースケースとエンドユーザーに必要なリソースをよりよく理解するために、次の大まかな質問を検討する必要があります。これは、事前にワークロードを計画するのにも役立ちます。

スケールアップは、1 時間あたりのユーザーあたりのコストを最小にする必要があり、インスタンスで障害が発生した場合に大きな影響を許容できる場合に最適です。スケールアウトは、単一インスタンスの障害の影響を最小限に抑える必要がある場合に適しています。次の表に、さまざまなCitrix コンポーネントのインスタンスタイプの例を示します。

コンポーネント 推奨されるインスタンスタイプ
Delivery Controller、Cloud Connector プレミアム SSD ストレージを搭載した標準 DS2_v2 または DS2_v3
サーバーOSユーザーワークロードのスケールアップ Virtual Appを使用した Standard_F16s_v2 仮想マシンは、他のインスタンスと比較して、ユーザー/時間あたりのコストが最も低いことが確認されました。また、Standard_DS5_v2 VMは他のインスタンスと比較してコスト競争に優れていました
サーバOSユーザーワークロードのスケールアウト Standard_F4_v2 インスタンスおよび Standard_F8_v2 インスタンスは、ユーザー数を減らすことができますが、ユーザーコンテナのサイズが小さいため、電源管理操作の柔軟性が向上します。これにより、マシンの割り当てをより効果的に解除して、従量課金制インスタンスのコストを節約できます。また、障害ドメインはスケールアウト時に小さくなります。
デスクトップOSユーザーのワークロード Standard_F2_v2は、デュアルコアのコストが最小で、Windows 10でうまく動作します。

最新のインスタンスタイプの調査は、この領域で優れた洞察を提供するために行われました。読み取りを強くお勧めします。いずれの場合も、お客様はワークロードとともにインスタンスタイプを評価する必要があります。

グラフィックを多用するワークロードの場合は、NVIDIA Tesla M60 GPU を搭載し、インテル Broadwell CPU を搭載した NVIDIA GRID テクノロジを搭載したNV_v3-series仮想マシンを検討してください。これらの仮想マシンは、GPUアクセラレーション・グラフィックス・アプリケーションおよび仮想デスクトップを対象としており、お客様はデータの視覚化、結果のシミュレーション、表示、CADでの作業、またはコンテンツのレンダリングとストリーミングを希望します。また、これらの仮想マシンは、エンコードやレンダリングなどの単精度ワークロードを実行することもできます。NV_v2 仮想マシンはプレミアムストレージをサポートし、その前身の NV シリーズと比較して 2 倍のシステムメモリ (RAM) が付属しています。

通常、スケールアップはコストを削減するための好ましいモデルですが、Autoscale は小規模なインスタンス(ホストあたり 15 ~ 20 セッション)の恩恵を受けることができます。小さいインスタンスは、大きいインスタンスよりも少ないユーザーセッションをホストします。そのため、最後のユーザーセッションがログオフされるまでの時間が小さいインスタンスほど短縮されるため、Autoscaleはマシンをいち早くドレイン状態にします。つまり、Autoscaleは小さいインスタンスの電源をすぐにオフにするので、コストを削減できます。Autoscaleに関するインスタンスサイズに関する考慮事項の詳細については、「公式ドキュメント」を参照してください。

ストレージ

他のコンピューターと同様に、Azure の仮想マシンは、オペレーティングシステム、アプリケーション、およびデータを格納する場所としてディスクを使用します。すべての Azure 仮想マシンには、Windows オペレーティングシステムディスクと一時ディスクの 2 つ以上のディスクがあります。オペレーティングシステムディスクはイメージから作成され、オペレーティングシステムディスクとイメージの両方が Azure 内に仮想ハードディスク (VHD) として格納されます。仮想マシンには、追加のディスクがデータディスクとしてアタッチされ、VHD としても格納されている場合もあります。

Azure Disks は、エンタープライズレベルの耐久性を提供するように設計されています。ストレージには、プレミアム SSD ディスク、標準 SSD、標準 HDD ストレージの 3 つのパフォーマンス階層があります。これらの階層は、管理対象または非管理対象です。管理ディスクはデフォルトであり、非管理ディスクなどのストレージアカウント制限の対象にはなりません。

Microsoft では、管理対象ディスクよりも管理対象ディスクを使用することをお勧めします。非管理ディスクは、例外としてのみ考慮する必要があります。標準ストレージ (HDD および SSD) には、トランザクションコスト (ストレージ I/O) が含まれますが、ディスクあたりのコストは低くなります。Premium Storage にはトランザクションコストはありませんが、ディスクあたりのコストが高くなり、ユーザーエクスペリエンスが向上します。

可用性セットを使用しない限り、ディスクは SLA を提供しません。可用性セットはCitrix MCSではサポートされていませんが、Citrix Cloud Connector、NetScaler およびStoreFront に含める必要があります。

Microsoft運用管理スイート (OMS)

OMS Workspaceは、顧客、ワークロード・タイプ、ビジネス・グループまたは部門によって最もよく定義されます。たとえば、サーバーVDA、クライアントVDA、StoreFront サーバーにはそれぞれ独自のOMS Workspaceがあります。管理を簡素化するには、できるだけ少ないワークスペースを作成します。Microsoft運用管理スイートでは、2 つの主要な管理テクノロジを利用できます。

管理ソリューション

管理ソリューションは通常、Log Analytics に情報を収集し、収集されたデータを分析するためのログ検索とビューを提供します。また、Azure Automation などの他のサービスを使用して、アプリケーションまたはサービスに関連するアクションを実行することもできます。

ソリューションとは、特定のワークロードについてキャプチャおよび監視できるサービス、構成、イベントID、容量などのセットです。OMS Workspaceには、複数のソリューションを適用できます。OMS Workspaceの範囲内でワークロードに対してお客様にとって重要なデータ・ポイントを特定します。ソリューションは、OMS で使用可能な、あらかじめ構築されたモジュールまたはカスタムモジュールであり、特定の Workspace に割り当てられます。

Workspaceログ分析

Log Analytics Workspace は、独自のデータリポジトリ、データソース、およびソリューションを備えた独自の Log Analytics 環境です。その目的は、Azure から取得したログデータを管理してアクセスし、ログデータの異常を探すことです。

ID

このセクションでは、Identity コントロール、Workspace のユーザー計画、およびエンドユーザーエクスペリエンスに重点を置いています。設計上の主な考慮事項は、Azure テナントと Citrix Cloud テナントの両方でアイデンティティを管理することです。

Microsoft Azure Active Directory (Azure AD) は、ディレクトリサービス、ID ガバナンス、およびアプリケーションアクセス管理を提供する ID およびアクセス管理クラウドソリューションです。1 つの Azure AD ディレクトリは、作成時に Azure サブスクリプションに自動的に関連付けられます。

すべての Azure サブスクリプションには、ユーザー、サービス、およびデバイスを認証するための Azure AD ディレクトリとの信頼関係があります。複数のサブスクリプションが同じ Azure AD ディレクトリを信頼できますが、サブスクリプションは 1 つの Azure AD ディレクトリのみを信頼します。

Microsoft の ID ソリューションは、オンプレミスとクラウドベースの機能にまたがり、場所を問わず、すべてのリソースに対する認証と承認のための単一のユーザー ID を作成します。この概念は、ハイブリッドアイデンティティとして知られています。Microsoft ソリューションを使用したハイブリッド ID には、さまざまな設計オプションと構成オプションがあり、組織のニーズに最も適した組み合わせを特定することが困難な場合があります。

アイデンティティ設計の一般的な考慮事項

通常、お客様のActive Directory サイトをAzureに拡張すると、Citrix Workspace でIDと認証を提供するためにアクティブディレクトリレプリケーションが使用されます。一般的な手順は、AD Connect を使用して Azure Active Directory にユーザーをレプリケートすることです。これにより、Windows 10 に必要なサブスクリプションベースのライセンス認証が提供されます。

完全な機能と拡張性のために、ローカルの Active Directory ドメインサービスを Azure 仮想ネットワークサブネットに拡張することをお勧めします。 Azure ロールベースのアクセス制御 (RBAC) は、Azure リソースのきめ細かなアクセス管理を提供します。アクセス許可が多すぎると、攻撃者に公開され、アカウントされる可能性があります。権限が少なすぎると、従業員は効率的に仕事を遂行できません。RBAC を使用すると、管理者は従業員に必要な権限を正確に付与できます。

認証

Citrix のコア機能を使用するには、ドメインサービス (AD DS または Azure AD DS) が必要です。RBAC は、Azure Resource Manager 上に構築された認証システムで、Azure のリソースのきめ細かなアクセス管理を提供します。RBAC を使用すると、ユーザーのアクセスレベルをきめ細かく制御できます。たとえば、あるユーザーが仮想ネットワークのみを管理し、別のユーザーがリソースグループ内のすべてのリソースを管理するように制限できます。Azure には、使用できる組み込みのロールがいくつか含まれています。

Azure AD認証は、WorkspaceエクスペリエンスサービスおよびCitrix ADC/StoreFront認証でサポートされています。Azure AD で完全な SSON を使用するには、Citrix フェデレーション認証サービス (FAS) または Azure AD DS (コアドメインサービス用) を使用する必要があります。

Citrix FASはWorkspaceエクスペリエンスサービスではまだサポートされていないため、展開アーキテクチャの一部としてStoreFront が必要です。 Azure MFA サーバー (クラウドサービス、Azure MFA サーバー、Azure MFA NPS 拡張) は、SAML ポリシーおよびフル SSON の Citrix FAS を使用しなくても、Azure MFA の使用を有効にできます。ただし、これはIaaS VMであり、お客様が管理する必要があります。

Active Directory と Azure のActive Directory 結果

  • Azure Active Directory プロビジョニングテナント
  • 組み込みまたはカスタム Azure ロールへのマッピングを使用した Azure RBAC の目的の組織ロールのリスト
  • 必要な管理者アクセスレベルのリスト(アカウント、サブスクリプション、リソースグループなど)
  • Azure の新しいユーザーにアクセス/ロールを付与する手順
  • 特定のタスクのユーザーに JIT(ジャストインタイム)昇格を割り当てる手順

以下は、名前空間のレイアウトと認証フローのアーキテクチャの例です。

Azure-RA-Image-5

図5:名前空間のレイアウトと認証フローのアーキテクチャ

Citrix Cloud Administration + Azure AD

デフォルトでは、Citrix CloudはCitrix IDプロバイダーを使用して、Citrix Cloudにアクセスするすべてのユーザーのアイデンティティ情報を管理します。この変更は、代わりに Azure Active Directory (AD) を使用するように変更できます。 Citrix CloudでAzure ADを使用すると、次のことができるようになります:

  • 独自のActive Directory を使用して、監査やパスワードポリシーを制御し、必要に応じてアカウントを容易に無効にすることができます。
  • サインイン資格情報が盗まれた可能性に対して、より高いレベルのセキュリティを実現するために、多要素認証を構成します。
  • ブランドのログインページを使用するため、ユーザーは正しい場所にログインしていることを確認できます。
  • ADFS、Okta、Pingなどの任意のIDプロバイダーにフェデレーションを使用できます。

Citrix CloudにはAzure ADが含まれているため、アクティブなAzure ADセッションにログインする必要なくAzure ADに接続できます。Citrix Cloud管理者ログインにより、お客様のCitrix CloudテナントでAzureのADアイデンティティを使用できるようになります。

  • Citrix Cloud管理者がCitrixアイデンティティまたはAzure ADを使用してCitrix CloudのURLにアクセスするのかを”https://citrix.cloud.com/go/{Customer Determined}”の形式で指定します。
  • Citrix CloudへのAzureのAD認証の認証URLを特定する

ガバナンス

Azure Governance は、さまざまな Azure リソースを大規模に管理できるように設計された概念とサービスのコレクションです。これらのサービスでは、サブスクリプションを論理的な方法で整理および構造化し、Azure ネイティブリソースのパッケージを作成、デプロイ、および再利用可能な機能が提供されます。このテーマは、Azure リソースの計画、アーキテクチャ、取得、デプロイ、運用、および管理に関連するポリシー、プロセス、および手順の確立に重点を置いています。

Citrix Cloud管理者ログイン

Citrix Cloud管理者が、Citrixアイデンティティ、Active Directory アイデンティティ、またはAzureのADのいずれを使用してCitrix Cloudにアクセスするのかを決定します。Azure ADの統合により、管理者向けのCitrix Cloudへの多要素認証が可能になります。Citrix CloudへのAzureのAD認証の認証URLを特定します。URLは、https://citrix.cloud.com/go/{Customer Determined}形式に従います。

RBAC のアクセス許可と委任

Azure AD を使用すると、Azure リソースのロールベースのアクセス制御 (RBAC) を使用してガバナンスポリシーを実装できます。これらの権限を適用するための主なツールの 1 つは、リソースグループの概念です。リソースグループは、ライフサイクルと管理所有権を共有する Azure リソースのバンドルと考えてください。

Citrix 環境のコンテキストでは、チーム間の適切な委任を可能にし、最小の特権の概念を促進するような方法で構成する必要があります。例として、Citrix Cloudの展開環境で、外部アクセス用にAzureマーケットプレイスからプロビジョニングされたCitrix ADC VPXを使用する場合が挙げられます。Citrix インフラストラクチャのコア部分ですが、Citrix ADCには個別の更新サイクルや管理者のセットなどが設定されている場合があります。これにより、Citrix ADCを他のCitrixコンポーネントから別々のリソースグループに分離し、Azure RBACのアクセス許可をテナント、サブスクリプション、およびリソースの管理ゾーンを通じて適用できるようになります。

MCS サービスプリンシパル

Azure AD テナントによってセキュリティ保護されているリソースにアクセスするには、アクセスを必要とするエンティティをセキュリティプリンシパルで表す必要があります。これは、ユーザー(ユーザープリンシパル)とアプリケーション(サービスプリンシパル)の両方に当てはまります。セキュリティプリンシパルは、Azure AD テナント内のユーザー/アプリケーションのアクセスポリシーとアクセス許可を定義します。これにより、サインイン時のユーザー/アプリケーションの認証、リソースアクセス時の承認などのコア機能が有効になります。

Citrix MCSサービスによって使用されるサービスプリンシパルに割り当てられた権限を決定します。

サブスクリプションスコープのサービスプリンシパルには、Citrix 環境で使用される該当するサブスクリプションに対する共同作成者権限があります。Narrow Scopeサービスプリンシパルでは、ネットワーク、マスターイメージ、およびVDAを含むリソースグループに、詳細なRBACが適用されます。限定スコープサービスプリンシパルは、サービスに必要なアクセス許可のみにアクセス許可を制限することをお勧めします。これは、「最小権限」というセキュリティ概念に準拠しています。

タグ付け

お客様は、Azure リソースにタグを適用して、メタデータを分類に論理的に整理します。各タグは、名前と値のペアで構成されます。たとえば、本番環境のすべてのリソースに「環境」と「生産」という名前を適用できます。

顧客は、そのタグ名と値を使用して、サブスクリプション内のすべてのリソースを取得できます。タグを使用すると、異なるリソースグループから関連リソースを取得できます。この方法は、管理者が課金や管理のためにリソースを整理する必要がある場合に役立ちます。

リソースあたりのタグ数は 15 に制限されています。Citrix MCSでは、仮想マシンごとに2つのタグが作成されるため、MCSマシンのタグ数は13に制限されます。MCS 非永続的なマシンは、再起動時に削除されます。これにより、タグ、起動診断などの Azure VM 固有の特性が削除されます。タグが必要な場合は、Azure Append ポリシーを作成し、適用可能な MCS リソースグループに適用することをお勧めします。

Azure ポリシー

Azure ポリシーは、タグ付け、許可された SKU、暗号化、Azure リージョン、命名規則などの側面を制御できます。使用可能なデフォルトポリシーと、カスタムポリシーを適用する機能があります。Azure ポリシーは、サブスクリプションまたはリソースグループレベルで適用できます。複数のポリシーを定義できます。リソースグループレベルで適用されるポリシーは、サブスクリプションレベルポリシーよりも優先されます。

Citrix 環境全体で制御および標準化する必要があるAzureの側面を特定します。ハードクォータはポリシーを強制し、例外を許可しません。ソフトクォータは、ポリシーの適用を監査し、ポリシーが満たされていない場合に通知します。ポリシーの定義の詳細については、Azure のドキュメントを参照してください。

Azure-RA-Image-6

図 6: Azure ガバナンスアクセスポリシーと RBAC

セキュリティ

セキュリティは Azure のあらゆる面に統合されています。Azure は、グローバルなセキュリティインテリジェンス、高度な顧客向けコントロール、セキュリティで強化されたインフラストラクチャから得られる独自のセキュリティ上の利点を提供します。この強力な組み合わせにより、アプリケーションとデータを保護し、コンプライアンスへの取り組みをサポートし、あらゆる規模の組織にコスト・パフォーマンスに優れたセキュリティを提供します。

IaaS-Azure セキュリティセンターの監視

Azure セキュリティセンターは、Azure リソースのセキュリティ状態を分析します。セキュリティセンターは、潜在的なセキュリティの脆弱性を特定すると、必要なコントロールを構成するプロセスをお客様に案内する推奨事項を作成します。Azure のリソースタイプ (仮想マシン (VM) とコンピューター、アプリケーション、ネットワーク、SQL、ID とアクセス) には、推奨事項が適用されます。あなたが従わなければならないいくつかのベストプラクティスがあります:

  • VMアクセスとセキュアな特権アクセスを制御します。
  • マルウェア対策をプロビジョニングして、悪意のあるソフトウェアの識別と削除を支援します。
  • マルウェア対策ソリューションをセキュリティセンターと統合して、保護の状態を監視します。
  • VM を最新の状態に保ち、構築したイメージに最新の Windows およびセキュリティ更新プログラムが含まれていることを確認します。
  • VM を定期的に再デプロイして、OS の新しいバージョンを強制します。
  • 仮想マシンへのトラフィックを制御するためのネットワークセキュリティグループとルールの設定。
  • Web アプリケーションのファイアウォールをプロビジョニングして、Web アプリケーションをターゲットとする攻撃を防御します。
  • 推奨ベースラインと一致しない OS 構成に対処する。

ネットワーク設計

ネットワークセキュリティは、ネットワークトラフィックに制御を適用することにより、不正なアクセスや攻撃からリソースを保護するプロセスとして定義できます。目標は、正当なトラフィックだけが許可されるようにすることです。Azure には、アプリケーションとサービスの接続要件をサポートする堅牢なネットワークインフラストラクチャが含まれています。ネットワーク接続は、Azure にあるリソース間、オンプレミスと Azure でホストされるリソース間、およびインターネットと Azure との間でのネットワーク接続が可能です。

仮想ネットワーク(VNet)セグメンテーション

Azure 仮想ネットワークは、オンプレミスネットワークの LAN に似ています。Azure 仮想ネットワークの背後にある考え方は、お客様がすべての Azure 仮想マシンを配置できる単一のプライベート IP アドレススペースベースのネットワークを作成することです。ベストプラクティスは、より大きなアドレス空間をサブネットに分割し、サブネット間にネットワークアクセス制御を作成することです。サブネット間のルーティングは自動的に行われるため、ルーティングテーブルを手動で設定する必要はありません。

ネットワークセキュリティグループ (NSG)を使用します。NSG は、5 タプル(送信元 IP、送信元ポート、宛先 IP、宛先ポート、およびレイヤ 4 プロトコル)アプローチを使用して、ネットワークトラフィックの許可/拒否ルールを作成する、シンプルでステートフルパケットインスペクションデバイスです。ルールは、単一の IP アドレス、複数の IP アドレス、またはサブネット全体との間で送受信されるトラフィックを許可または拒否します。

お客様は、Azure でユーザー定義ルート (UDR) と呼ばれるカスタムルートまたはユーザー定義ルートを作成して、Azure の既定のシステムルートを上書きしたり、サブネットのルートテーブルに追加ルートを追加することができます。Azure では、管理者はルートテーブルを作成し、そのルートテーブルを 0 個以上の仮想ネットワークサブネットに関連付けることができます。各サブネットには、ゼロまたは 1 つのルートテーブルを関連付けることができます。

NSG および UDR は、仮想ネットワーク内のサブネットレベルで適用されます。AzureでCitrix 仮想ネットワークを設計するときは、これを念頭に置いて仮想ネットワークを設計することをお勧めします。同様のコンポーネント用のサブネットを作成し、必要に応じてNSGとUDRを細かく適用できます。たとえば、Citrix インフラストラクチャを独自のサブネットに分割し、各ユースケースに対応するサブネットを作成します。

Citrix に必要なポートとプロトコルと、サポートするテクノロジーを特定します。これらのポートが、環境で使用されるネットワークセキュリティグループ内で許可されていることを確認します。ネットワークセキュリティグループでは、着信および発信通信を、IP、仮想ネットワーク、サービスタグ、またはアプリケーションセキュリティグループの定義済みセットに制限できます。

Azure-RA-Image-7

図 7: NSG と ASG を使用した Azure セキュリティセンターとネットワークセキュリティ

接続

Azure仮想ネットワークを顧客のローカル/クラウドネットワークに接続することは、ハイブリッドネットワーキングと呼ばれます。このセクションでは、ネットワーク接続とネットワークサービスルーティングのオプションについて説明します。 お客様は、次のオプションの任意の組み合わせを使用して、オンプレミスのコンピューターとネットワークを仮想ネットワークに接続できます。

  • ポイント対サイト仮想プライベートネットワーク (VPN): 仮想ネットワークとお客様のネットワーク内の 1 台のコンピュータの間に確立されます。仮想ネットワークとの接続を確立する各コンピュータは、その接続を構成する必要があります。この接続タイプは、お客様の既存のネットワークをほとんどまたはまったく変更する必要がないため、Azure の使用を開始したばかり、または開発者にとって最適です。コンピュータと仮想ネットワーク間の通信は、インターネットを介して暗号化されたトンネルを介して送信されます。
  • サイト間 VPN: オンプレミスの VPN デバイスと、仮想ネットワークにデプロイされた Azure VPN Gatewayの間で確立されます。この接続の種類により、顧客が仮想ネットワークへのアクセスを許可するすべてのオンプレミスリソースが有効になります。オンプレミスの VPN デバイスと Azure VPN Gateway 間の通信は、インターネット経由で暗号化されたトンネルを介して送信されます。
  • Azure ExpressRoute: ExpressRoute パートナーを通じて、お客様のネットワークと Azure の間で確立されます。この接続はプライベートです。トラフィックはインターネットを通過しません。

Azure から顧客への接続に関する主な考慮事項は、帯域幅、待ち時間、セキュリティ、およびコストです。サイト間 VPN の帯域幅制限は Express Route よりも低く、お客様が使用するエッジルータのパフォーマンスに依存します。SLA は VPN Gateway SKU で利用できます。サイト間 VPN は、インターネット経由で IPSEC を使用します。

エクスプレスルートは、インターネット経由ではなく、専用のプライベート接続です。これにより、高速ルートを使用するときの待ち時間が短縮されます。さらに、エクスプレスルートは最大 10 Gbps まで拡張できます。エクスプレスルートは、認定パートナーを使用して設定されます。これらのプロバイダによる構成時間は、プロジェクトの計画中に考慮する必要があります。エクスプレスルートコストには、Microsoft コンポーネントとエクスプレスルートプロバイダーコンポーネントがあります。

通常、これらの接続は複数のサービス(データベースレプリケーション、ドメイントラフィック、アプリケーショントラフィックなど)で共有されます。 ハイブリッドクラウドの展開では、内部ユーザーがAzureのCitrix アプリケーションにアクセスするためにICAトラフィックがこの接続を通過する必要がある場合があります。そのため、帯域幅を監視することが重要になります。

NetScaler と従来のStoreFront では、Azureへの高速ルートやVPNではなく、オフィスのISPを使用してユーザーのNetScaler への接続を指示するために、最適なGateway ルーティングを使用することもできます。

ユーザー定義ルート (UDR)

通常、お客様は UDR を使用して Azure トラフィックを Azure 内のファイアウォールアプライアンスまたは特定の仮想ネットワークにルーティングします。たとえば、VDAからインターネットへの北/南のトラフィックなどです。大量のトラフィックが Azure 内のサードパーティファイアウォールアプライアンスにルーティングされる場合、これらのアプライアンスのサイズや構成が適切でないと、リソースのボトルネックや可用性のリスクが生じる可能性があります。NSG はサードパーティ製のファイアウォールを補うために使用でき、必要に応じて可能な限り活用する必要があります。トラフィックのイントロスペクションが必要な場合は、Azure ネットワークウォッチャーを検討してください。

仮想ネットワークピアリング

仮想ネットワークピアリングは、2 つの Azure 仮想ネットワークをシームレスに接続します。ピアリングされると、仮想ネットワークは接続のために 1 つとして表示されます。ピアリングされた仮想ネットワーク内の仮想マシン間のトラフィックは、Microsoft バックボーンインフラストラクチャを介してルーティングされます。トラフィックは、同じ仮想ネットワーク内の仮想マシン間でプライベート IP アドレスのみを介してルーティングされます。

Azure では、次のものがサポートされています。

  • VNet ピアリング-同じ Azure リージョン内の VNet の接続
  • グローバル VNet ピアリング-Azure リージョン間の VNet の接続

複数の VNet にワークロードを展開するお客様は、VNet ピアリングを使用して、VNet 間の VM 間の通信を有効にすることを検討する必要があります。

Azure-RA-Image-8

図 8: データセンターの接続性とルート

SD-WAN

ソフトウェア定義WAN(SD-WAN)テクノロジーにより、困難な接続でも優れたユーザーエクスペリエンスを提供できます。仮想アプリケーションやデスクトップ配信に自然に適合します。

  • 使用可能なすべての帯域幅をアクティブ/アクティブ接続に集約し、より多くの帯域幅を提供します。
  • 独自のHDX Quality of Experience テクノロジーを使用して、パフォーマンスを最適化し、ネットワークポリシーを調整します。
  • リッチメディアや高品位ビデオでも、最高品質のエクスペリエンスを実現し、仮想アプリやデスクトップユーザーの常時接続を確実にします。

VPN を使用しているお客様は、SD-WAN を利用して Azure およびカスタマーデータセンターの接続に冗長性を加えたり、アプリケーション固有のルーティングを提供したりする場合があります。Citrix SD-WAN は、使用可能なすべての接続でトラフィックを自動的にリダイレクトします。実際、経験は非常にシームレスで、ユーザーは変更が発生したことに気付くことさえできません。プライマリアクセス IP アドレスは変更されないため、ユーザーは同じ方法とデバイスを使用してアプリやデータにアクセスできます。

Citrix ADC

Citrix ADC on Microsoft Azureは、組織がクラウドにデプロイされた安全で最適化されたアプリケーションや資産にアクセスできるようにし、変化する環境のニーズに合わせて調整するネットワーク基盤を確立するための柔軟性を提供します。データセンターに障害が発生した場合、Citrix ADCはユーザーのトラフィックをセカンダリサイトに自動的にリダイレクトします。ユーザーの中断はありません。複数のデータセンターにまたがるロード・バランシングとグローバル・サーバのロード・バランシングにより、サーバの稼働状態、容量、使用率の最適化が実現します。

お客様と話し合い、リソースの場所ごとに次のユースケースを定義します。

アクセス方法 注意事項
内部のみ 内部アクセスのみが必要な場合は、Citrix ADCは必要ありません。
Citrix ADC Gatewayサービス経由の外部アクセス。 Citrix Cloud ADC Gatewayサービスは、ICAプロキシを提供します(安全なリモート接続のみ)。
Azureリソースの場所にデプロイされたCitrix ADC VPX経由の外部アクセス お客様は、以下が必要な場合、AzureでCitrix ADC VPXアプライアンスを検討する必要があります。 1. 完全SSON 2による多要素認証。エンドポイントスキャン 3. 高度な認証または事前認証ポリシー 4. Citrix のSmartAccess ポリシー。注:これらの要件により、Workspaceエクスペリエンスサービスではなく、Citrix ADCで認証が行われるように求められます。認証がCitrix ADC Gateway仮想サーバーによって管理されている場合は、StoreFront が必要です。

Citrix ADC-導入モデル

アクティブ-アクティブ展開では、Azure ロードバランサーを使用してスケールアウトできるスタンドアロンの Citrix ADC ノードを活用します。アクティブ/パッシブペアは、ノード障害発生時のICAトラフィックのステートフルフェイルオーバーを容易にします。ただし、1つのVPXの容量に制限されます。アクティブ-パッシブノードには、Azure ロードバランサーも必要です。

Citrix ADC は、AzureのNICごとに500メガビット/秒に制限されています。SNIP、NSIP、VIPトラフィックを分離し、Citrix ADC Gatewayやその他のサービスで利用可能なスループットを最大化するには、複数のNICを使用することをお勧めします。

参照ドキュメント

操作

ID

ガバナンス

セキュリティ

Azure Monitor

接続

Azure Citrix Virtual Apps and Desktops