リファレンスアーキテクチャ:Citrix DaaS-Azure

はじめに

このガイドは、Microsoft AzureでのCitrix DaaS Sのアーキテクチャと展開モデルを支援します。

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

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

  • 運用:運用には 、イメージ管理、サービスの監視、ビジネス継続性、サポートなど、さまざまなトピックが含まれます。Azure PowerShell、Azure CLI、ARM テンプレート、Azure API などの操作の自動化を支援するさまざまなツールを利用できます。

  • アイデンティティ -Azure の全体像の基礎の1つは、人のアイデンティティとそのロールベースのアクセス(RBAC)です。Azure ID は、Azure Active Directory (Azure AD) と Azure AD ドメインサービスを介して管理されます。お客様は、ID統合のどちらの方法を使用するかを決定する必要があります。

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

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

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

計画

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

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

このドキュメントでは、Citrix Cloudの展開モデルを中心に説明します。お客様は、組織のニーズに基づいて、次のサービスを計画および採用できます。

Citrix DaaS

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

Citrix Virtual Desktops Essentials サービス

CitrixとMicrosoftのお客様は、組織内にWindows 10 Enterpriseを展開するためのオプションが増えています。Citrix Virtual Desktops Essentials サービスは、Microsoft Azureクラウドソリューションを好むお客様のために、Windows 10エンタープライズへの移行を加速します。これにより、ユーザーごとに Windows 10 Enterprise (現在の支店) のライセンスを取得しているお客様は、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 DaaS を配信する際のスケーラビリティと経済性に関する設計ガイドを参照してください

操作

オペレーションの対象領域では、基本サービスのワークスペース環境の要件と階層のプランニングについて詳しく説明します。最上位レイヤーには、サブスクリプション、リソースグループ、および地域の設計に関する考慮事項があります。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(米国西部)、欧州(米国東部)、SCU(米国中南部) リソースがデプロイされる Azure リージョンを識別します。

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

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

Service スコープ 推奨パターン
サブスクリプション グローバル [System][Environment]##[Location]-sub WSCD01scu-sub
リソース グループ グローバル [System]-[Role]-[Environment]##-[Location]-rg CTX-Apps-P01-CUS-rg
仮想ネットワーク リソース グループ [System][Environment]##[Location]-vnet CTXP01cus-vnet
Subnet 親 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
Key Vault サブスクリプション [System][Environment]-vault CTXP-vault

サブスクリプション

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

単一サブスクリプションワークスペースモデル

単一のサブスクリプションモデルでは、すべてのコアインフラストラクチャとCitrixインフラストラクチャが同じサブスクリプションに配置されます。これは、最大1,200のCitrix VDA(セッション、プールされたVDI、または永続VDI)を必要とする展開に推奨される構成です。制限は変更される可能性があります。 最新のVDA制限については、以下を確認してください。単一のサブスクリプション内の最新の開始/シャットダウンスケール番号については、 次のブログを参照してください

図-2: Azure シングルサブスクリプションワークスペースモデル Azure-RA-Image-2

マルチサブスクリプションワークスペースモデル

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

Azure-RA-Image-3

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

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

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

Azure 地域

Azure リージョンは、レイテンシーで定義された境界内にデプロイされ、専用のリージョンの低レイテンシーネットワークを介して接続される一連のデータセンターです。Azure では、必要な場所にアプリケーションをデプロイできる柔軟性が得られます。Azure は世界中の 42 リージョンで一般提供され、2018 年 11 月時点でさらに 12 リージョン向けのプランが発表されています。

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

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

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

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

可用性セット

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

Citrix展開の各コンポーネントは、Citrixの全体的な可用性を最大化するために、独自の可用性セットに配置する必要があります。たとえば、Cloud Connectorには別の可用性セットを使用し、Citrixアプリケーションデリバリーコントローラー(ADC)、StoreFrontなどには別の可用性セットを使用する必要があります。

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

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

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

Azure 計画メンテナンス

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

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

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

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

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

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

障害回復(DR)

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

アーキテクチャの拡張

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

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

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

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

Azure に Citrix Infrastructure が存在するということは、ユーザーがコアワークスペースにアクセスする前に、手動プロセスを起動する必要がなく、システムを復元する必要もありません。

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

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

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

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

リソース グループ

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

リソースグループの設計を成功させるには、リソースグループに含まれるリソースのライフサイクルを理解することが重要です。

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

イメージの管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AzureのCitrix環境のコストを削減するために使用できる2つのテクノロジー、リザーブドインスタンス、およびCitrix AAutoscale が利用可能です。

リザーブドインスタンス

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

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

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

Citrix Autoscale

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

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

Azure-RA-Image-4

図-4:Citrix のAutoscaleフロー

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

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

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

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

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

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

Azure VM インスタンスタイプ

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

ほとんどのCitrix展開では、DシリーズおよびFシリーズのインスタンスタイプが使用されます。Dシリーズは、通常、Citrixインフラストラクチャコンポーネントで使用され、場合によってはFシリーズのインスタンスタイプよりも多くのメモリを必要とするユーザーのワークロードに使用されます。F シリーズのインスタンスタイプは、応答性の認識をもたらす高速プロセッサのため、ユーザーのワークロードの分野で最も一般的です。

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

お客様のインフラストラクチャ内のコンポーネントのサイズと数は、常にお客様の要件、規模、ワークロードによって異なります。しかし、Azure では、動的にオンデマンドでスケーリングする能力があります!コスト意識の高いお客様にとっては、小規模から始めて、スケールアップするのが最善のアプローチです。Azure VM では、サイズを変更するときに再起動が必要になるため、スケジュールされたメンテナンスウィンドウ内および設定された変更制御ポリシーの下でのみこれらのイベントを計画します。

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

お客様のユースケースとエンドユーザーに必要なリソースをよりよく理解するために、次の高レベルの質問を確認する必要があります。これはまた、事前に自分のワークロードを計画するのに役立ちます。

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

コンポーネント 推奨されるインスタンスタイプ
デリバリーコントローラー、クラウドコネクタ プレミアム SSD ストレージを備えた標準 DS2_V2 または DS2_v3
サーバーOSのユーザーワークロードのスケールアップ 仮想アプリケーションを搭載した Standard_F16S_v2 VM は、他のインスタンスと比較して 1 ユーザーあたりの 1 時間あたりのコストが最も低いことが確認されました。Standard_DS5_v2 仮想マシンは、他のインスタンスと比べてコスト競争力も高かった
サーバーOSのユーザーワークロードのスケールアウト Standard_F4_V2 インスタンスおよび Standard_F8_v2 インスタンスは、ユーザー数を減らしますが、ユーザーコンテナのサイズが小さくなるため、電源管理操作の柔軟性が向上します。これにより、マシンの割り当てをより効果的に解除し、従量課金インスタンスのコストを削減できます。また、スケールアウト時に障害ドメインは小さくなります。
デスクトップOSのユーザーワークロード Standard_F2_v2 は、デュアルコアのコストが最も低く、Windows 10 で優れたパフォーマンスを発揮します。

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

グラフィックを多用するワークロードの場合は、 NVv4シリーズの仮想マシンを検討してください 。彼らはAMD EPYC 7002プロセッサと仮想化Radeon MI25 GPUを搭載しています。これらの仮想マシンは、VDI およびリモート可視化のために最適化および設計されています。パーティション化されたGPUにより、NVv4は、より小さなGPUリソースを必要とするワークロードに最適なサイズを、最適な価格で提供します。代わりに NVv3 シリーズは、OpenGL や DirectX などのフレームワークを使用して、リモート視覚化、ストリーミング、ゲーム、エンコーディング、および VDI シナリオ向けに最適化および設計されています。これらの仮想マシンは NVIDIA テスラ M60 GPU によってバックアップされます。その他のGPUオプションについては、 Azureの他の製品を確認してください

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

ストレージ

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

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

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

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

ユーザー情報

この項では、ID コントロール、ワークスペースユーザーの計画、およびエンドユーザーエクスペリエンスについて説明します。設計上の主な考慮事項は、Azure テナントと Citrix Cloud テナントの両方で ID を管理することです。

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

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

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

アイデンティティ設計に関する一般的な考慮事項

通常、お客様のActive Directory サイトをAzure に拡張すると、Active Directoryレプリケーションを使用して、Citrix WorkspaceでIDと認証が提供されます。一般的な手順は、AD 接続を使用して 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 認証は、Citrix Workspace、Citrix DaaS、およびCitrix ADC/StoreFront認証でサポートされています。Azure AD を使用した完全な SSON の場合は、Citrix フェデレーション認証サービス (FAS) または Azure AD DS (コアドメインサービスの場合) を使用する必要があります。

Citrix FASは、Citrix Workspace のDaaSへのシングルサインオン(SSO)をサポートしています。Citrix FASは、通常、次のIDプロバイダーのいずれかを使用している場合に採用されます。

  • Azure Active Directory
  • Okta
  • SAML 2.0
  • Citrix Gateway

アクティブディレクトリと Azure Active Directory の成果

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

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

Azure-RA-Image-5

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

Citrix Cloud 管理+ Azure AD

デフォルトでは、Citrix CloudはCitrix IDプロバイダーを使用して、Citrix CloudにアクセスするすべてのユーザーのID情報を管理します。お客様は、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 CloudにアクセスするためにCitrix IDまたはAzure ADを使用するかどうかを判断します。URLは次の形式です。 https://citrix.cloud.com/go/{Customer Determined}
  • Citrix CloudへのAzureのAD認証の認証URLを特定する

ガバナンス

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

Citrix Cloud管理者ログイン

Citrix Cloud管理者がCitrix Cloudにアクセスするために、シトリックスアイデンティティ、Active Directory アイデンティティ、またはAzure AD を使用するかどうかを決定します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環境で使用される該当するサブスクリプションに対する共同作成者権限があります。範囲が狭いサービスプリンシパルには、ネットワーク、マスターイメージ、および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 は、グローバルなセキュリティインテリジェンス、高度な顧客向けコントロール、セキュリティで強化されたインフラストラクチャから得られる独自のセキュリティ利点を提供します。この強力な組み合わせにより、アプリケーションとデータの保護、コンプライアンスへの対応、コスト・パフォーマンスの高いセキュリティをあらゆる規模の組織に提供できます。

CVADサービスによるストレージ・アカウントのプロビジョニングのセキュリティ保護

前述したように、MCSは顧客のサブスクリプションで機械をスピンアップするサービス (CVAD 内) です。MCS は、Azure リソースグループへのアクセスに AAD ID — アプリケーションサービスプリンシパルを使用して、さまざまなアクションを実行します。 ストレージアカウントタイプのリソースの場合、MCSは異なるアクション(書き込み/読み取り/削除) に必要なときにキーを取得するlistkeys権限が必要です。 現在の実装では、次の要件に関するMCS要件があります。

  • ストレージアカウントネットワークは、パブリックインターネットからのアクセスです。
  • ストレージアカウント RBACはlistkeysアクセス許可

一部の組織では、ストレージアカウントのエンドポイントをパブリックにしておくことが懸念されます。 以下は、管理ディスクを使用して仮想マシンを展開するときに作成および格納されるアセットの分析です(デフォルトの動作)。

  • テーブルストレージ: カタログのプライマリストレージアカウント (またはプライマリが Premium ディスクに使用されている場合はセカンダリ) のテーブルストレージに、マシン構成と状態データを保持します。 テーブル内に機密情報はありません。
  • ロック: 特定の操作 (ストレージアカウントへのマシンの割り当て、ディスクの複製) では、ロックオブジェクトを使用して複数のプラグインインスタンスからの操作を同期します。 これらのファイルは空のブロブであり、機密データは含まれません。

2020 年 10 月 15 日より前に作成されたマシンカタログの場合、MCSはアイデンティティディスク用の追加のストレージアカウントを作成します。

  • ディスクのインポート: ディスクをインポートする場合 (ID、命令)、ディスクをページ BLOB としてアップロードします。 次に、ページ BLOB から管理ディスクを作成し、ページ BLOB を削除します。一時データには、コンピュータオブジェクト名とパスワードの機密データが含まれます。これは、2020年10月15日以降に作成されたすべてのマシンカタログには適用されません。

サービスで必要なアクセス許可のみにアクセス許可を制限するには、特定のリソースグループに適用される狭いスコープサービスプリンシパルを使用することをお勧めします。これは、「最小特権」というセキュリティ概念に準拠しています。詳細については、 [CTX219243およびCTX224110を参照してください](https://support.citrix.com/article/CTX224110)

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

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

  • 仮想マシンアクセスを制御し、特権アクセスを保護します。
  • マルウェア対策のプロビジョニングにより、悪意のあるソフトウェアの識別と削除に役立ちます。
  • マルウェア対策ソリューションをセキュリティセンターと統合して、保護の状態を監視します。
  • 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 個以上の仮想ネットワークサブネットに関連付けることができます。各サブネットには、0 または 1 つのルートテーブルが関連付けられます。

NSG および UDR は、仮想ネットワーク内のサブネットレベルで適用されます。Azure で Citrix Virtual Network を設計する場合は、同様のコンポーネント用のサブネットを作成し、必要に応じて 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 ゲートウェイ間の通信は、暗号化されたトンネルを介してインターネット経由で送信されます。
  • Azure ExpressRoute: ExpressRoute パートナーを通じて、お客様のネットワークと Azure の間に確立されます。この接続は非公開です。トラフィックはインターネットを経由しません。

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

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

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

ADCおよび従来のStoreFront では、Azure へのエクスプレスルートやVPNではなく、オフィスのISPを使用してADCへのユーザーの接続を指示するために、最適なゲートウェイルーティングを使用することもできます。

ユーザ定義ルート (UDR)

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

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

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

Azure のサポート:

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

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

Azure-RA-Image-8

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

SD-WAN

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

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

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

Citrix ADC

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

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

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

Citrix ADC-導入モデル

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

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

ソース

このリファレンスアーキテクチャの目的は、お客様独自の実装計画を支援することです。この作業を簡単にするために、独自の詳細な設計と実装ガイドに適応できるソース図を提供します。 ソース図です

参照ドキュメント

操作

ユーザー情報

ガバナンス

セキュリティ

Azure モニター

接続

リファレンスアーキテクチャ:Citrix DaaS-Azure

この記事の概要