AzureでのCitrix虚拟应用程序和桌面サービス
はじめに
このガイドでは,微软AzureでのCitrix虚拟应用程序和桌面サービスのアーキテクチャと展開モデルについて説明します。
Citrix云と微软Azureの組み合わせにより,新しいCitrix仮想リソースを俊敏性と弾力性を高め,要件の変化に応じて使用量を調整することができます。Azureの仮想マシンは,Citrix虚拟应用程序和桌面サービスの展開に必要なすべての制御コンポーネントとワークロードコンポーネントをサポートします。Citrix云と微软Azureには,共通のコントロールプレーン統合があり,グローバルオペレーションのアイデンティティ,ガバナンス,セキュリティを確立します。
このドキュメントでは,お客様の環境の前提条件,アーキテクチャ設計に関する考慮事項,および展開ガイダンスについても説明します。このドキュメントでは,次の5つの主要なアーキテクチャ原則について,設計上の決定と導入の考慮事項について説明します。
運用:運用には,イメージ管理,サービスの監視,ビジネス継続性,サポートなど,さまざまなトピックが含まれます。Azure PowerShell, Azure CLI、手臂テンプレート,Azure APIなどの操作の自動化を支援するさまざまなツールを利用できます。
アイデンティティazureの全体像の基礎の1つは,人のアイデンティティとそのロールベースのアクセス(RBAC)です。Azure IDはAzure Active Directory (Azure广告)とAzure广告ドメインサービスを介して管理されます。お客様は,ID統合のどちらの方法を使用するかを決定する必要があります。
ガバナンス——ガバナンスの鍵は,Azureリソースの計画,アーキテクチャ,取得,展開,運用管理に関連するポリシー,プロセス,および手順を確立することです。
セキュリティazureは,構成可能な幅広いセキュリティオプションとそれらを制御する機能を備えているため,お客様は組織の展開固有の要件を満たすようにセキュリティをカスタマイズできます。このセクションでは,Azureのセキュリティ機能がこれらの要件を満たすのにどのように役立つかを理解するのに役立ちます。
接続azure仮想ネットワークをお客様のローカル/クラウドネットワークに接続することを,ハイブリッドネットワークと呼びます。このセクションでは,ネットワーク接続とネットワークサービスルーティングのオプションについて説明します。
計画
Azure経由でCitrixアプリとデスクトップを配信するための最も一般的なシナリオは,次の3つです。
- Azureでリソースの場所を提供するCitrix云を使用したグリーンフィールドの展開。このシナリオはCitrix虚拟应用程序和桌面サービスを介して配信され,お客様がサブスクリプションモデルにアクセスし,コントロールプレーンインフラストラクチャをCitrixにアウトソーシングしたい場合に使用されます。
- オンプレミスのデプロイをAzureに拡張します。このシナリオでは,顧客は現在のオンプレミスの制御層を持っており,新しいデプロイまたは移行のためのCitrixリソースの場所としてAzureを追加したいと考えています。
- リフトアンドシフト。このシナリオでは,お客様はCitrix ADCと店面を使用して複数のサイトのリソースを集約するために,Citrix管理インフラストラクチャをAzureにデプロイし,Azureをサイトとして扱います。
このドキュメントでは,Citrix云の展開モデルを中心に説明します。お客様は,組織のニーズに基づいて,次のサービスを計画および採用できます。
Citrix虚拟应用程序和桌面サービス
Citrix云虚拟应用程序和桌面サービスにより,Citrixテクノロジの提供と管理が簡素化され,お客様は既存のオンプレミスソフトウェア展開を拡張したり,クラウドに100%移行したりできます。Windows、Linux、Webアプリケーション,WindowsおよびLinux仮想デスクトップへの安全なアクセスを提供します。優れたエンドユーザーエクスペリエンスを維持しながら,複数のリソースの場所でアプリケーションとデスクトップを一元管理できます。
Citrix虚拟桌面必需品サービス
Citrixと微软のお客様には、組織内にWindows 10企业版を展開するオプションが増えています。Citrix虚拟桌面软件包サービスでは、微软Azureクラウドソリューションを好むお客様のために、Windows 10企业版への移行を迅速化します。これにより、ユーザーごとに Windows 10企业版(当前业务分支机构)のライセンスを取得しているお客様は、蔚蓝色的から高性能な Windows 10企业版仮想デスクトップエクスペリエンスを提供することができます。
Citrix虚拟应用要点サービス
新しいアプリケーション仮想化サービスであるCitrix虚拟应用必需品はCitrix云プラットフォームのパワーと柔軟性と,シンプルで規範的で使いやすい微软AzureのRemoteAppのビジョンを組み合わせたものです。Citrix虚拟应用必需品はバックエンドインフラストラクチャをクラウドに移行することで,優れたパフォーマンスと柔軟性を実現し,管理やエンドユーザーエクスペリエンスを犠牲にすることなくアプリの配信を簡素化します。
概念リファレンスアーキテクチャ
この概念的なアーキテクチャでは,以下のセクションで説明するAzureでのCitrix云リソースの場所の展開に関する一般的なガイドラインを示します。
図1:Citrix云の概念的なリファレンスアーキテクチャ
微软AzureでのCitrix虚拟应用程序和桌面サービスの提供のスケーラビリティと経済性については,デザインガイドを参照してください
操作
オペレーションの対象領域では,基本サービスのワークスペース環境の要件と階層のプランニングについて詳しく説明します。最上位レイヤーには,サブスクリプション,リソースグループ,および地域の設計に関する考慮事項があります。VMストレージ,ユーザープロファイルストレージ,マスターイメージの管理/プロビジョニングに関するよくある質問が続きます。また,自动定量によるリザーブドインスタンスの最適化,およびビジネス継続性/ディザスタリカバリの計画に関するガイダンスも提供されます。
命名規則
微软Azureのリソースの名前付けは,次の理由で重要です。
- ほとんどのリソースは作成後に名前を変更できない
- 特定のリソースタイプには異なる命名要件があります
- 一貫した命名規則により,リソースを見つけやすくなり,リソースの役割を示すことができます
命名規則を成功させる鍵は,アプリケーションや組織全体で規則を確立し,それに従うことです。
Azureサブスクリプションに名前を付ける場合,冗長な名前によって,各サブスクリプションのコンテキストと目的が明確になります。命名規則に従うと,多数のサブスクリプションがある環境で作業するときにわかりやすくなります。
サブスクリプションの名前付けに推奨されるパターンは次のとおりです。
変数 | 例 | 説明 |
---|---|---|
[システム] | CTX (Citrix)、CORE (Azure) | リソースがサポートする製品,アプリケーション,またはサービスの3文字の識別子。 |
[役割] | XAW (XenAppワーカー)的共识(虚拟投递代理)、CC(云连接器)、脑血管意外(Citrix虚拟应用程序) | サービスのサブシステムの3文字の識別子。 |
[環境] | D, T, P(開発,テスト,または刺激) | リソースの環境を識別します |
## | 01、02 | 複数の名前付きインスタンス(ウェブサーバーなど)を持つリソースの場合。 |
[場所] | 吴(米国西部)、欧州(米国東部)、SCU(米国中南部) | リソースがデプロイされるAzureリージョンを識別します。 |
Azureでリソースに名前を付けるときは,共通のプレフィックスまたはサフィックスを使用して,リソースの種類とコンテキストを識別します。タイプ,メタデータ,コンテキストに関するすべての情報はプログラムで利用できますが,共通の接辞を適用すると,視覚的な識別が簡単になります。接辞を命名規則に組み込む場合,接辞が名前の先頭(接頭辞)または末尾(接尾辞)のどちらにあるかを明確に指定することが重要です。
明確に定義された命名規則は,Azureリソースのシステム,ロール,環境,インスタンス数,および場所を識別します。名前付けは,Azureポリシーを使用して強制できます。
サービス | スコープ | 推奨パターン | 例 |
---|---|---|---|
サブスクリプション | グローバル | (系统)(环境)# #【位置】子 |
WSCD01scu-sub |
リソースグループ | グローバル | 【系统】- [Role](环境)# # - - rg#(位置) |
CTX-Apps-P01-CUS-rg |
仮想ネットワーク | リソースグループ | (系统)(环境)# #(位置)联接 |
CTXP01cus-vnet |
サブネット | 親联接 | [描述上下文] |
DMZ - 10.0.1.0/24 Infrastructure - 10.0.2.0/24 |
ストレージアカウント | リソースグループ | 【系统】[Role](环境)# #(位置) 注:小文字の英数字を使用する必要があります。 |
ctxinfd01scu |
コンテナ | ストレージアカウント | [描述上下文] |
vhd |
仮想マシン | リソースグループ | 【系统】[Role](环境)# #(位置) 注:15文字以下である必要があります。 |
CTXSTFD01scu |
ネットワークインターフェイス | リソースグループ | vmname nic # |
CTXSTFD01scu-nic1 |
パブリックIP | リソースグループ | [vmname]-pip |
CTXSTFD01scu-pip |
仮想ネットワークゲートウェイ | 仮想ネットワーク | (系统)(环境)# #【位置】-vng |
WSCD01scu-vng |
ローカルネットワークゲートウェイ | リソースグループ | (系统)(环境)# #(位置)液化天然气 |
WSCD01scu-lng |
可用性セット | リソースグループ | (系统)[Role]—— |
CTXSTF-as |
ロードバランサー | リソースグループ | 【系统】[Role]磅 |
CTXNSG-lb |
ストア | サブスクリプション | (系统)(环境)分析 |
CTXP-analytics |
タグ | リソース | [描述上下文] |
金融 |
关键库 | サブスクリプション | (系统)(环境)库 |
CTXP-vault |
サブスクリプション
サブスクリプションモデルの選択は,Citrix展開の内外におけるお客様のAzureフットプリントの増加を理解することを含む複雑な決定です。Citrixの展開が小さい場合でも,Azure APIに対して大量の読み取り/書き込みを行う他のリソースが,Citrix環境に悪影響を与える可能性があります。逆も同様です。この場合,多くのCitrixリソースが使用可能なAPI呼び出しの数が異常に消費されるため,サブスクリプション内の他のリソースの可用性が低下します。
単一サブスクリプションワークスペースモデル
単一のサブスクリプションモデルでは,すべてのコアインフラストラクチャとCitrixインフラストラクチャが同じサブスクリプションに配置されます。これは,最大1200のCitrix的共识(セッション,プールされたVDI,または永続VDI)を必要とする展開に推奨される構成です。制限は変更される場合がありますので,以下の最新のVDAの制限事項を確認してください。1つのサブスクリプション内の最新の起動シャットダウンスケール番号については,以下のブログを参照してください。
図2:Azureシングルサブスクリプションワークスペースモデル
マルチサブスクリプションワークスペースモデル
このモデルでは、コアインフラストラクチャと思杰公司インフラストラクチャが別々のサブスクリプションになり、大規模な展開におけるスケーラビリティを管理します。多くの場合、複数リージョンのインフラストラクチャ設計を使用したエンタープライズ展開は、蔚蓝色的サブスクリプションの制限に達するのを防ぐために、複数のサブスクリプションに分割されます。
図3:Azureマルチサブスクリプションワークスペースモデル
以下の質問は,お客様がAzureサブスクリプションオプションを理解し,リソースの計画に役立つガイダンスを提供します。
コンポーネント | 条件 |
---|---|
AzureサブスクリプションにはCitrixリソースのみが含まれていますか吗? | Azureサブスクリプションを専用のCitrixリソースに使用するか,Citrixリソースを他のシステムと共有するかを決定します。 |
単一または複数サブスクリプションの展開? | 通常,複数のサブスクリプション展開は,単一のサブスクリプションの制限が問題であり,より詳細なセキュリティ制御が必要な大規模な展開用です。 |
どのAzureの制限に達する可能性がありますか吗?リソースグループにはリソースの数はいくつありますか | リソースグループには制限があり,机器创建服务(MCS)にはVMリソースあたり2台または3台のディスクが必要です。ソリューションの計画中にAzureサブスクリプションの制限を確認します。 |
AzureサブスクリプションのCVADサービスの原則に必要なアクセス許可は何ですか吗? | Citrix虚拟应用程序和台式机では、サブスクリプション内にリソースグループとリソースを作成する必要があります。たとえば、サービス原則にサブスクリプションへのフルアクセスを許可できない場合は、事前に作成されたリソースグループへの共同作成者アクセス権を付与する必要があります。 |
開発環境とテスト環境は,本番環境とは別のサブスクリプションで作成されますか吗? | 開発サブスクリプションとテストサブスクリプションを運用環境から分離すると,分離された環境におけるグローバルAzureサービスのアプリケーションと変更が可能になり,リソース使用率をサイロ化することができます。このプラクティスには,セキュリティ,コンプライアンス,サブスクリプションのパフォーマンスにメリットがあります。これらの環境でサブスクリプションを個別に作成すると,イメージ管理が複雑になります。これらのトレードオフは,お客様のニーズに基づいて考慮する必要があります。 |
Azure地区
Azureリージョンは,レイテンシーで定義された境界内にデプロイされ,専用のリージョンの低レイテンシーネットワークを介して接続される一連のデータセンターです。Azureでは,必要な場所にアプリケーションをデプロイできる柔軟性が得られます。Azureは世界中の42リージョンで一般提供され,2018年11月時点でさらに12リージョン向けのプランが発表されています。
地理とは,通常2つ以上のAzureリージョンを含む個別の市場で,データの常駐とコンプライアンスの境界を維持します。地域により,特定のデータの保存場所とコンプライアンスのニーズを持つお客様は,データとアプリケーションを緊密に保つことができます。
アベイラビリティーゾーンは,Azureリージョン内の物理的に独立した場所です。各アベイラビリティーゾーンは,独立した電源,冷却,ネットワーキングを備えた1つ以上のデータセンターで構成されています。アベイラビリティーゾーンを使用すると,高可用性と低レイテンシーのレプリケーションを使用して,ミッションクリティカルなアプリケーションを実行できます。復元性を確保するために,すべての有効なリージョンに少なくとも3つの別々のゾーンがあります。
お住まいの地域を選択する際には,これらの要因を考慮してください。
コンポーネント | 条件 |
---|---|
コンプライアンスとデータのレジデンシー | お客様には,特定のコンプライアンス要件またはデータ・レジデンシーに関する要件がありますか。微软はデータの冗長性またはその他の運用目的で,特定のGeo内のリージョン間で顧客データをコピーできます。たとえば,Azureグローバル冗長ストレージ(GRS)はデータセンターの大災害が発生した場合に,同じGeo内の2つのリージョン間でBLOBとテーブルデータをレプリケートし,データの耐久性を向上させます。特定のAzureサービスでは,顧客がサービスをデプロイするリージョンを指定することはできません。これらのサービスは,指定がない限り,微软のデータセンターのいずれかに顧客データを格納できます。Azure地区地图ウェブサイトで最新のアップデートを確認してください。 |
サービスの可用性 | 仮リージョン内のサービスの可用性を確認します。リージョン別のサービスの可用性は,お客様がリージョン内で利用可能なサービスを判断するのに役立ちます。Azureサービスは特定のリージョンでサポートできますが,Azure政府ドイツ,中国などのソブリンクラウドでは,すべてのサービス機能を使用できるわけではありません。 |
Citrix展開のターゲットAzureリージョンを決定します。 | Azureリージョンのユーザーと顧客データセンターまでの距離を確認します。 |
複数のAzureリージョンが必要ですか | 通常,複数のAzureリージョンは,次の高レベルの理由で考慮されます。——アプリケーションデータまたはエンドユーザーの近さ——ビジネス継続性とディザスタリカバリのための地理的な冗長性azureの機能またはサービスの可用性 |
可用性セット
可用性セットは,Azureで論理的なグループ化機能です。Azureでは,可用性セット内に配置されたVMリソースがAzureデータセンター内にデプロイされるときに互いに分離されます。Azureでは,可用性セット内に配置されたVMが,複数の物理サーバー,コンピューティングラック,ストレージユニット,ネットワークスイッチ間で実行されます。ハードウェアまたはAzureソフトウェアの障害が発生した場合,VMのサブセットのみが影響を受けます。また,アプリケーション全体は引き続き稼働し,お客様が使用できます。可用性セットは、お客様が信頼性の高いクラウドソリューションを構築したい場合に不可欠な機能です。
Citrix展開の各コンポーネントは,Citrixの全体的な可用性を最大化するために,独自の可用性セットに配置する必要があります。たとえば,云连接器には別の可用性セットを使用し,Citrix应用程序交付控制器(ADC),店面などには別の可用性セットを使用する必要があります。
可用性セットが最適化されたら,次のステップは,可用性セット内の仮想マシンのダウンタイムに関する復元力を構築することです。これにより,微软によるVMの再起動または再展開時のサービスのダウンタイムを最小化/排除できます。これは,計画されたメンテナンスイベントにも拡張できます。サービス全体の信頼性を高めることができる 2 つの機能を使用できます。
これらの 2.つの機能は、予期しないメンテナンス/クラッシュから保護されません。
- 蔚蓝色的計画メンテナンス
- Azureのスケジュールされたイベント
蔚蓝色的計画メンテナンス
Azureは,Azureのホストインフラストラクチャの信頼性,パフォーマンス,およびセキュリティを向上させるために,定期的に更新を実行します。メンテナンスのために再起動が必要な場合は,微软から通知が送信されます。蔚蓝色的計画メンテナンスを使用すると、Microsoft のスケジュールではなく、お客様のスケジュールに基づいて、これらの通知をキャプチャし、プロアクティブに行動することができます。
各階層のサービス所有者に電子メール通知を送信し(手動介入の場合),計画されたメンテナンス機能を利用し,サービス保護を自動化するためのRunbookを構築します。
Azureのスケジュールされたイベント
Azureスケジュールされたイベントは,すぐにメンテナンスを警告するために,アプリケーションにプログラムによって通知を与えるAzureメタデータサービスです。アプリケーション管理者は,中断に備えて制限できるように,今後のメンテナンスイベント(再起動など)に関する情報を提供します。計画メンテナンスのように聞こえるかもしれませんが,そうではありません。主な違いは,これらのイベントは,計画されたメンテナンスと場合によっては非計画メンテナンスのために起動されることです。たとえば,Azureがホストの修復アクティビティを実行していて,短期間で仮想マシンを移動する必要がある場合などです。
これらのイベントはプログラムによって消費され,次の事前通知を行います。
- フリーズ- 15分
- 再起動- 15分
- 再デプロイ- 10分
障害回復(博士)
Azureは,今日のクラウド導入からすぐに価値を引き出したいというCitrixのお客様に,コスト効率の高博士いソリューションを提供します。導入モデルのトポロジによって,博士ソリューションの実装が決まります。
アーキテクチャの拡張
このトポロジでは,管理インフラストラクチャはオンプレミスのままですが,ワークロードはAzureにデプロイされます。オンプレミスのデータセンターにアクセスできない場合,既存の接続ユーザーは接続したままになりますが,管理インフラストラクチャが使用できないため,新しい接続はできません。
管理インフラストラクチャを保護するには,Azure站点恢复を事前に構成して,管理インフラストラクチャをAzureに回復します。これは手動のプロセスであり,リカバリ後,環境を運用可能にすることができます。このオプションはシームレスではなく,ADC VPXなどのコンポーネントをリカバリすることはできませんが,より柔軟なRTO(目標復旧時間)を持つ組織では,運用コストを削減できます。
ホスティングアーキテクチャ
このトポロジを展開すると,Citrix管理インフラストラクチャはAzureにデプロイされ,別のサイトとして扱われます。これにより,サイトに障害が発生した場合に,オンプレミスの展開から機能を分離できます。Citrix ADCおよびStoreFront を使用してリソースを集約し、本番リソースと災害復旧リソース間のほぼ瞬時のフェイルオーバーをユーザーに提供します。
AzureにCitrix基础设施が存在するということは,ユーザーがコアワークスペースにアクセスする前に,手動プロセスを起動する必要がなく,システムを復元する必要もありません。
クラウドサービスアーキテクチャ
Citrix云を使用すると,Azureは別のリソースの場所になります。このトポロジでは,管理コンポーネントはサービスとしてCitrixによってホストされているため,最もシンプルな展開を実現できます。また,障害復旧ワークロードは,重複したインフラストラクチャを導入せずに実現できます。災害発生時のフェイルオーバー時のユーザーエクスペリエンスは,シームレスに実行できます。
次の表に示す項目は,お客様の計博士画に役立ちます。
コンポーネント | 条件 |
---|---|
Citrix環境のRTO(目標復旧時間)とRPO(目標復旧時点)要件を教えてください。 | RTO:災害発生後にビジネス・プロセスをリストアする必要がある目標期間およびサービス・レベルRPO:中断中に、その期間中に失われたデータ量がビジネス継続性プランの最大許容しきい値(「許容範囲」)を超過する可能性がある時間。 |
Azure仮想マシンアプリケーションがデプロイされているリージョン全体でサービスの中断が発生した場合の望ましい結果は何ですか。 | これらのオプションは,博士に関するお客様のRTO(目標復旧時点)およびRPO(目標復旧時点)に合わせて確認する必要があります。AzureのCitrix環境の災害復旧は,Azureサイトの回復,パッシブセカンダリサイト,およびアクティブなサイトのAzureサイトを使用して対処することができます。リカバリは,サーバーOS (CitrixインフラストラクチャおよびサーバーVDA)のみをサポートします。クライアントOSはサポートされていません(ARMテンプレートを使用して作成された永続デスクトップなど)。またMCS(サーバーまたはクライアントVDA)で作成されたマシンカタログは,回復タスクを使用して再作成する必要があります。 |
リソースグループ
Azureのリソースグループ(RG)は論理グループ内の資産のコレクションです。プロビジョニング,監視,アクセス制御を簡単または自動で行い,コストをより効率的に管理できます。AzureでRGを使用する利点は,アプリケーションに属する関連リソースをグループ化することです。これは,作成から使用,そして最後にプロビジョニング解除までのライフサイクルが統一されたライフサイクルを共有しているからです。
リソースグループの設計を成功させるには,リソースグループに含まれるリソースのライフサイクルを理解することが重要です。
リソースグループは作成時にマシンカタログに関連付けられ,後で追加または変更することはできません。マシンカタログにリソースグループを追加するには、マシンカタログを削除して再作成する必要があります。
イメージの管理
イメージ管理とは,開発,テスト,本番環境にわたって一貫して適用されるイメージの作成,アップグレード,割り当てのプロセスです。イメージ管理プロセスを開発する際には,次のことを考慮する必要があります。
オンデマンドプロビジョニング
お客様は,Azureの非永続的なコンピューターを管理するためにMCSを使用するか,独自のAzure资源管理器(ARM)テンプレートを作成するのかを判断する必要があります。お客様がMCSを使用してマシンカタログを作成する場合,Azureオンデマンドプロビジョニング機能によってストレージコストが削減され,カタログ作成が高速化され,仮想マシン(VM)の電源操作が高速化されます。Azureのオンデマンドプロビジョニングでは,VMは,プロビジョニング完了後,Citrix虚拟应用程序和桌面で電源投入操作が開始されたときにのみ作成されます。仮想マシンは,Azure门户の実行時にのみ表示されます。Citrix工作室では,電源の状態に関係なく,すべての仮想マシンが表示されます。手臂テンプレートまたはMCSを使用して作成されたマシンは,Citrix工作室でAzureホスト接続を使用してCitrixが電源を管理できます。
ストレージアカウントコンテナ
お客様は、Citrix机创建服务(MCS)を使用して仮想マシンの作成元となる保存ソース(ゴールデン)イメージの組織構造を決定する必要があります。Citrix MCSイメージは,スナップショット,管理対象ディスクまたは非管理ディスクから取得でき,標準ストレージまたはプレミアムストレージ上に配置できます。非管理ディスクは,汎用ストレージアカウントを介してアクセスされ,Azure Blobストレージコンテナー内にVHDとして格納されます。コンテナーは,プロダクション,テスト,および開発イメージを分離するために使用できるフォルダーです。
イメージレプリケーション
お客様は,リージョン間でイメージをレプリケートするための適切なプロセスと,イメージ管理戦略全体におけるCitrix应用程序分层テクノロジの使用方法を決定する必要があります。PowerShellスクリプトカメラは,Azureオートメーションで使用して,イメージのレプリケーションをスケジュールします。Citrix应用程序分层の詳細については,ここを参照してください。弹性分层には、蔚蓝色的ファイルには存在しない中小企业ファイル共有が必要であることに注意してください。弹性分层をサポートするサポートされている 中小企业共有テクノロジについては、「ファイルサーバー“セクションを参照してください。
ファイルサーバテクノロジ
Azureには,Citrixユーザーデータ,移動プロファイル情報の保存,またはCitrix分层共有のターゲットとして機能するために使用できるファイルサーバーテクノロジがいくつか用意されています。これらのオプションには,次のものがあります。
- スタンドアロン・ファイル・サーバ
- ストレージレプリカを使用するファイルサーバ
- ストレージスペースダイレクト(S2D)を使用したスケールアウトファイルサーバ(sof)
- 分散ファイルシステム:レプリケーション(DFS-R)
- Azure市场のサードパーティ製ストレージアプライアンス(NetAppなど)
お客様は,自社のビジネス要件に最も適したファイル・サーバ・テクノロジーを選択する必要があります。次の表に,各ファイル・サービング・テクノロジーに関するいくつかの利点と考慮事項を示します。
オプション | 長所 | 注意事項 |
---|---|---|
スタンドアロン・ファイル・サーバ | よく知られており、テストされています。既存のバックアップ/リストア製品との互換性 | 単一障害点。データの冗長性はありません。毎月のパッチ適用停止時間(分単位)。 |
ストレージレプリカを使用するファイルサーバ | ブロックレベルのレプリケーション。SMB3.0。ストレージに依存しません(三)クラウド、ローカルなど)。同期レプリケーションと非同期レプリケーションを提供します。マルチリージョンアクセスが必要な場合に推奨 | 手動フェイルオーバーが必要です。2倍のディスク容量を使用します。手動フェイルオーバーでは,ダウンタイムは分単位で測定されます。DNS依存関係。 |
ストレージスペースに直接sof | 高可用性。マルチノードおよびマルチディスクHAスケールアップまたはスケールアウト。SMB 3.0および3.1。計画的および予期しない保守作業中の透過的なフェイルオーバーAzure 内のユーザープロファイルストレージに推奨 | 2 ~ 3倍のディスク容量を使用します。サードパーティ製のバックアップソフトウェアのサポートは,ベンダーによって制限されます。複数リージョン展開をサポートしない |
分散ファイル・システム:レプリケーション | ファイル・ベースのレプリケーションのための実証済みのテクノロジー动力壳をサポート | ドメインベース。アクティブ——アクティブ構成では展開できません。 |
サードパーティ製ストレージアプリケーション | 重複除外テクノロジー。ストレージスペースのより良い使用。 | 追加費用。独自の管理ツール。 |
推奨されるファイルサーバー仮想マシンの種類は,通常DS1、DS2、DS3, DS4,またはDS5で,お客様の使用要件に応じて適切な選択が可能です。最高のパフォーマンスを得るには,溢价ディスクサポートが選択されていることを確認します。追加のガイダンスは,微软のAzureで見つけることができます。ドキュメント。
インフラストラクチャコスト管理
AzureのCitrix環境のコストを削減するために使用できる2つのテクノロジを利用できます。リザーブドインスタンスとCitrix自动定量。
リザーブドインスタンス
AzureリザーブドVMインスタンス(RI)はWindowsおよびLinux仮想マシン(VM)で1年または3年の期間で,従量課金制と比較して最大72%のコストを大幅に削減します。Azure RIから得られるコスト削減とAzureハイブリッド特典の付加価値を組み合わせることで,最大80%の節約が可能になります。は80%,通常の従量課金料金と比較して,Windows Serverの3年間のAzureリザーブドインスタンスのコミットメントに基づいて計算されます。
Azureリザーブドインスタンスは,コンピューティングキャパシティに前もってコミットする必要がありますが,リザーブドインスタンスをいつでも交換またはキャンセルできる柔軟性も備えています。予約は,仮想マシンのコンピューティングコストのみを対象とします。ソフトウェア,ネットワーク,ストレージの追加料金は削減されません。これは,Citrixインフラストラクチャと,ユースケース(オンおよびオフ時間)に必要な最小容量に適しています。
Citrix自動スケール機能は、リザーブドインスタンスをサポートし、さらにコストを削減します。クラウドでのバーストに 自动售电を使用できるようになりました。デリバリーグループでは、自動スケーリングが必要なマシンにタグを付け、リザーブドインスタンス(またはオンプレミスのワークロード)を除外できます。詳細については、こちらをご覧ください:デリバリーグループの特定マシンに対する自动定量の制限。
Citrix自动定量
自動スケールはCitrix虚拟应用程序和桌面サービス専用の機能で,一貫性のあるハイパフォーマンスソリューションを提供し,マシンをプロアクティブに電源管理します。その目的は,コストとユーザーエクスペリエンスのバランスを取ることです。Citrix自动定量により、Smart Scaleテクノロジ(廃止)をStudioの電源管理ソリューションに組み込むことができます。
マシンの種類 | スケジュールベース | 負荷ベース | ロードとスケジュールベース |
---|---|---|---|
公開アプリケーションまたはホストされた共有デスクトップをホストするサーバー操作系统マシン(サーバーVDI) | サポート済み | サポート済み | サポート済み |
静的(専用)VDIデスクトップをホストするデスクトップ操作系统マシン | サポートされます。マシンの電源がオフになっている期間(勤務時間後など)は,Citrix接收机を介してマシンの電源投入をトリガーできます。ユーザーがセッションを確立する前にAutocaleがマシンの電源を自動的にオフしないように,自動スケールの電源オフ遅延を設定できます。 | 割り当てられていないマシンでのみサポートされます。 | 割り当てられていないマシンでのみサポートされます。 |
デスクトップ操作系统-ホストするマシン-ランダム非永続的な VDIデスクトップ(プールされた VDIデスクトップ) | サポート済み | サポートされます。セッション数のスケーリングメトリックスを使用して,セッションの最大数を1に設定します。 | サポートされます。セッション数のスケーリングメトリックを使用して,マシンの最小数を1に設定します。 |
図4:Citrixの自动定量フロー
Citrix自动定量について詳しくは,こちらをご覧ください:ここ。
エンドユーザーエクスペリエンスの最適化
エンドユーザーエクスペリエンスを最適化するには、エンドユーザーの応答性に対する認識と、予算内に収まるビジネスニーズのバランスをとります。このセクションでは、ビジネスとエンドユーザーに最適な規模の環境の提供に関する設計概念と決定事項について説明します。
ユーザー・ワークスペースの定義
ユーザー評価を計画する場合,Citrix VDIハンドブックとベストプラクティスドキュメントには非常に有益なガイダンスが提供されます。既存のユースケースとエンドユーザーに必要なリソースをよりよく理解するために,次の高レベルの質問を確認してください。
トピック | 質問 |
---|---|
ユーザーの数 | 環境内で想定されるユーザーは何人ですか。評価フェーズで適切な VDIモデルを決定しましたか。(仮想アプリまたは仮想デスクトップ) |
使用例 | エンドユーザーが消費するアプリケーションの種類は何ですかアプリケーションのVDA要件はどのようなものですか吗?アプリケーションはどのように最適に配信されますか吗?(仮想アプリと仮想デスクトップ) |
ユーザーグループの労働時間 | ユーザーが環境にアクセスするのはいつですか。ピーク時間は何時ですか吗?1日を通して予想される消費量はどれくらいですか吗?(特定の時間内のユーザーの消費量は,スケールの自動化とAzureリザーブドインスタンスの購入に関するワークスペース要件を特定するのに役立ちます)。 |
位置情報 | エンドユーザーはどこにいるのですか吗?ワークスペースは,複数のリージョンにまたがってデプロイするか,または1つのリージョンにのみ配置する必要がありますか。 |
ユーザーデータとアプリケーションデータ | ユーザーデータとアプリケーションデータはどこに保存されますか?データは 蔚蓝色的にのみ含まれるのですか、オンプレミスのみ、またはその両方を混在させますか?ユーザーデータにアクセスするための最大許容レイテンシーはどれくらいですか? |
Azure VMインスタンスタイプ
各Citrixコンポーネントは,Azureの関連する仮想マシンの種類を使用します。使用可能な各VMシリーズは,特定のカテゴリ(汎用,コンピューティング最適化など)にマップされ,VMに割り当てられたリソース(CPU、メモリ,IOPS,ネットワークなど)を制御するさまざまなサイズを使用します。
ほとんどの思杰公司展開では、DシリーズおよびFシリーズのインスタンスタイプが使用されます。Dシリーズは、通常、思杰公司インフラストラクチャコンポーネントで使用され、場合によってはFシリーズのインスタンスタイプよりも多くのメモリを必要とするユーザーのワークロードに使用されます。Fシリーズのインスタンスタイプは、応答性の認識をもたらす高速プロセッサのため、ユーザーのワークロードの分野で最も一般的です。
なぜDシリーズかFシリーズですか吗?Citrixの観点からは,ほとんどのインフラストラクチャコンポーネント(クラウドコネクタ,店面、ADCなど)はCPUを使用してコアプロセスを実行します。これらの仮想マシンタイプは,バランスのとれたCPU対メモリ比を持ち,(シリーズとは異なり)均一なハードウェア上でホストされ,より一貫したパフォーマンスを実現し,プレミアムストレージをサポートします。確かに,お客様は,ニーズと予算に合わせてインスタンスタイプを調整できます。
お客様のインフラストラクチャ内のコンポーネントのサイズと数は,常にお客様の要件,規模,ワークロードによって異なります。しかし,Azureでは,動的にオンデマンドでスケーリングする能力があります!コスト意識の高いお客様にとっては,小規模から始めて,スケールアップするのが最善のアプローチです。Azure VMでは,サイズを変更するときに再起動が必要になるため,スケジュールされたメンテナンスウィンドウ内および設定された変更制御ポリシーの下でのみこれらのイベントを計画します。
スケールアップやスケールアウトはどうですか吗?
お客様のユースケースとエンドユーザーに必要なリソースをよりよく理解するために,次の高レベルの質問を確認する必要があります。これはまた,事前に自分のワークロードを計画するのに役立ちます。
スケールアップは1時間あたりのユーザーあたりのコストを最小にする必要があり,インスタンスに障害が発生した場合に大きな影響を許容できる場合に最適です。単一インスタンスの障害の影響を最小限に抑える必要がある場合は,スケールアウトが優先されます。次の表は,さまざまなCitrixコンポーネントのインスタンスタイプの例を示しています。
コンポーネント | 推奨されるインスタンスタイプ |
---|---|
交付控制器,云连接器 | プレミアムSSDストレージを備えた標準DS2_V2またはDS2_v3 |
サーバーOSのユーザーワークロードのスケールアップ | 虚拟应用を使用したStandard_F16s_v2仮想マシンは,他のインスタンスと比較して,ユーザー/時間あたりのコストが最も低いことが確認されました。Standard_DS5_v2仮想マシンは,他のインスタンスと比べてコスト競争力も高かった |
サーバーOSのユーザーワークロードのスケールアウト | Standard_F4_V2インスタンスおよびStandard_F8_v2インスタンスは,ユーザー数を減らしますが,ユーザーコンテナのサイズが小さくなるため,電源管理操作の柔軟性が向上します。これにより,マシンの割り当てをより効果的に解除し,従量課金インスタンスのコストを削減できます。また,スケールアウト時に障害ドメインは小さくなります。 |
デスクトップOSのユーザーワークロード | 标准F2 v2は、デュアルコアのコストが最も低く、视窗10で優れたパフォーマンスを発揮します。 |
最新のインスタンスタイプの調査は,この領域で優れた洞察を提供するために行われました。読み取りを強くお勧めします。いずれの場合も,お客様はワークロードとともにインスタンスタイプを評価する必要があります。
グラフィックスを多用するワークロードの場合は,NVv4-series仮想マシンを考慮してください。7002年彼らはAMD EPYCプロセッサと仮想化Radeon MI25 GPUを搭載しています。これらの仮想マシンは,VDIおよびリモート可視化のために最適化および設計されています。パーティション化されたGPUにより,NVv4は,より小さなGPUリソースを必要とするワークロードに最適なサイズを,最適な価格で提供します。代わりにNVv3シリーズは,OpenGLや举などのフレームワークを使用して,リモート視覚化,ストリーミング,ゲーム,エンコーディング,およびVDIシナリオ向けに最適化および設計されています。これらの仮想マシンはNVIDIAテスラM60 GPUによってバックアップされます。さらにGPUオプションについては,Azureの他の提供コースを確認してください。
通常,スケールアップはコストを削減するために推奨されるモデルですが,Autocaleは小規模なインスタンス(ホストあたり15 ~ 20セッション)の恩恵を受けることができます。小さいインスタンスは,大きいインスタンスよりも少ないユーザーセッションをホストします。そのため,最後のユーザーセッションがログオフされるまでの時間が小さいインスタンスほど短縮されるため,自动定量はマシンをいち早くドレイン状態にします。つまり,自动定量は小さいインスタンスの電源をすぐにオフにするので,コストを削減できます。自动定量に関するインスタンスサイズに関する考慮事項の詳細については,”公式ドキュメント“を参照してください。
ストレージ
他のコンピューターと同様に,Azureの仮想マシンは,オペレーティングシステム,アプリケーション,およびデータを格納する場所としてディスクを使用します。すべてのAzure仮想マシンには,少なくとも2つのディスク(Windowsオペレーティングシステムディスクと一時ディスク)があります。オペレーティングシステムディスクはイメージから作成され,オペレーティングシステムディスクとイメージの両方が仮想ハードディスク(VHD)としてAzure内に格納されます。仮想マシンには,データディスクとしてアタッチされた余分なディスクがあり,VHDとしても格納されています。
Azure磁盘はエンタープライズレベルの耐久性を提供するように設計されています。ディスクの作成時に選択できるストレージのパフォーマンス階層は,溢价SSDディスク,标准的SSD,标准硬盘ストレージの3つがあり,ディスクは管理または非管理のいずれかです。管理ディスクはデフォルトで,非管理ディスクのようなストレージアカウントの制限の対象にはなりません。
管理ディスクは,管理されていないディスクよりも微软によって推奨されます。非管理ディスクは,例外によってのみ考慮する必要があります。標準ストレージ(HDDおよびSSD)には,トランザクションコスト(ストレージI / O)が含まれます。このコストは考慮する必要がありますが,ディスクあたりのコストは低くなります。高端存储にはトランザクションコストはありませんが,ディスクあたりのコストは高くなり,ユーザーエクスペリエンスが向上します。
可用性セットを使用しない限り,ディスクはSLAを提供しません。可用性セットはCitrix MCSではサポートされませんが、Citrix Cloud Connector、ADC、StoreFront に含める必要があります。
ID
この項では,IDコントロール,ワークスペースユーザーの計画,およびエンドユーザーエクスペリエンスについて説明します。設計上の主な考慮事項は,AzureテナントとCitrix云テナントの両方でIDを管理することです。
微软Azure Active Directory (Azure广告)はディレクトリサービス,IDガバナンス,およびアプリケーションアクセス管理を提供するIDおよびアクセス管理のクラウドソリューションです。単一のAzure广告ディレクトリは,作成時にAzureサブスクリプションに自動的に関連付けられます。
すべてのAzureサブスクリプションは,ユーザー,サービス,デバイスを認証するためのAzure广告ディレクトリとの信頼関係を持っています。複数のサブスクリプションが同じAzure广告ディレクトリを信頼できますが,サブスクリプションは1つのAzure广告ディレクトリのみを信頼します。
微软のIDソリューションは,オンプレミスとクラウドベースの機能にまたがり,場所に関係なく,すべてのリソースに対する認証と承認のための単一のユーザーIDを作成します。この概念は,ハイブリッドアイデンティティとして知られています。微软ソリューションを使用するハイブリッドIDには,さまざまな設計と構成オプションがあります。場合によっては,組織のニーズに最も適した組み合わせを決定することが困難な場合があります。
アイデンティティ設計に関する一般的な考慮事項
通常,お客様のActive DirectoryサイトをAzureに拡張すると,Active Directoryレプリケーションを使用して,Citrix工作区でIDと認証が提供されます。一般的な手順は,广告接続を使用してAzure Active Directoryにユーザーをレプリケートすることです。これにより,Windows 10に必要なサブスクリプションベースのライセンス認証が提供されます。
すべての機能と拡張性のために,ローカルのActive DirectoryドメインサービスをAzure仮想ネットワークサブネットに拡張することをお勧めします。Azureロールベースのアクセス制御(RBAC)は,Azureリソースのきめ細かなアクセス管理を提供します。権限が多すぎると,攻撃者に公開してアカウントを与えられる可能性があります。権限が少なすぎると,従業員が効率的に作業を完了できないことを意味します。RBACを使用すると,管理者は従業員に必要な正確なアクセス許可を与えることができます。
認証
Citrixのコア機能には,ドメインサービス(AD DSまたはAzure AD DSのいずれか)が必要です。RBACは,Azure资源管理器上に構築された認証システムで,Azure内のリソースのきめ細かなアクセス管理を提供します。RBACを使用すると,ユーザーが持つアクセスのレベルをきめ細かく制御できます。たとえば,仮想ネットワークのみを管理するようにユーザーを制限し,別のユーザーがリソースグループ内のすべてのリソースを管理するように制限できます。Azureには,使用できるいくつかの組み込みロールが含まれています。
Azure广告認証は,工作区エクスペリエンスサービスおよびCitrix ADC /店面認証でサポートされています。Azure广告を使用した完全なSSONの場合は,Citrixフェデレーション認証サービス(FAS)またはAzure AD DS(コアドメインサービスの場合)を使用する必要があります。
Citrix FASは工作空间エクスペリエンスサービスではまだサポートされていないため、展開アーキテクチャの一部として店面が必要です。 Azure MFAサーバー (クラウドサービス、Azure MFA服务器、Azure MFA NPS扩展)では、萨米尔ポリシーや、完全な松にCitrix FAを使用することなく、Azure MFAの使用を有効にすることができます。ただし、これは IaaS虚拟机であり、お客様が管理する必要があります。
アクティブディレクトリとAzure Active Directoryの成果
- Azure Active Directoryプロビジョニングされたテナント
- Azure RBACの必要な組織ロールのリスト(組み込みまたはカスタムAzureロールへのマッピング)
- 必要な管理者アクセスレベルのリスト(アカウント,サブスクリプション,リソースグループなど)
- Azureの新しいユーザーにアクセス/ロールを付与する手順
- 特定のタスクに対してJIT(ジャストインタイム)昇格をユーザに割り当てる手順
以下は,名前空間のレイアウトと認証フローのアーキテクチャの例です。
図5:名前空間のレイアウトと認証フローのアーキテクチャ
Citrix云管理+ Azure AD
デフォルトではCitrix云はCitrix IDプロバイダーを使用して,Citrix云にアクセスするすべてのユーザーのID情報を管理します。お客様は,Azure Active Directory(广告)を代わりに使用するようにこれを変更できます。Citrix云でAzure广告を使用すると,次のことができるようになります:
- 独自のActive Directoryを使用して,監査やパスワードポリシーを制御し,必要に応じてアカウントを簡単に無効にすることができます。
- サインイン資格情報が盗まれた可能性に対して,より高度なセキュリティを実現するために,多要素認証を構成します。
- ブランドのサインインページを使用して,ユーザーが適切な場所でサインインしていることがわかります。
- ADFS、Okta、Pingなどの任意の身份证件プロバイダーにフェデレーションを使用できます。
Citrix云にはAzure广告が含まれているため、アクティブなAzure广告セッションにログインする必要なくAzure广告に接続できます。Citrix云管理者ログインにより、お客様のCitrix云テナントで蔚蓝色的の公元アイデンティティを使用できるようになります。
- Citrix云管理者がCitrix云にアクセスするためにCitrix IDまたはAzure广告を使用するかどうかを判断します。URLは次の形式です。
https://citrix.cloud.com/go/{客户决定}
- Citrix云へのAzureの广告認証の認証URLを特定する
ガバナンス
Azureガバナンスは,さまざまなAzureリソースを大規模に管理できるように設計された概念とサービスのコレクションです。これらのサービスでは,論理的な方法でサブスクリプションを整理および構造化し,リソースのAzureネイティブパッケージを作成,デプロイ,および再利用可能な機能を提供します。このテーマは,Azureリソースの計画,アーキテクチャ,取得,展開,運用,および管理に関連するポリシー,プロセス,手順の確立に重点を置いています。
Citrix云管理者ログイン
Citrix云管理者が,Citrixアイデンティティ,Active Directoryアイデンティティ,またはAzureの广告のいずれを使用してCitrix云にアクセスするのかを決定します。Azure广告の統合により,管理者向けのCitrix云への多要素認証が可能になります。Citrix云へのAzureの广告認証の認証URLを特定します。URLは,https://citrix.cloud.com/go/{客户决定}
形式に従います。
RBACのアクセス許可と委任
Azure广告を使用すると,Azureリソースのロールベースアクセス制御(RBAC)を使用してガバナンスポリシーを実装できます。これらのアクセス許可を適用するための主要なツールの1つは,リソースグループの概念です。リソースグループは、ライフサイクルと管理所有権を共有する Azure リソースのバンドルと考えてください。
Citrix環境のコンテキストでは,これらの構成は,チーム間の適切な委任を可能にし,最小権限の概念を促進するように構成する必要があります。たとえばCitrix云展開で,AzureマーケットプレイスからプロビジョニングされたCitrix ADC VPXを外部アクセスに使用する場合が挙げられます。Citrixインフラストラクチャの中核部分ですが,Citrix ADCには個別の更新サイクルや管理者のセットなどが存在する場合もあります。これにより,Citrix ADCを他のCitrixコンポーネントから個別のリソースグループに分離して,Azure RBACのアクセス許可を管理ゾーンを通じて適用できるようにする必要がありますテナント,サブスクリプション,リソースの
MCSサービスプリンシパル
Azure广告テナントによってセキュリティで保護されているリソースにアクセスするには,アクセスを必要とするエンティティをセキュリティプリンシパルで表す必要があります。これは,ユーザー(ユーザープリンシパル)とアプリケーション(サービスプリンシパル)の両方に当てはまります。セキュリティプリンシパルは、Azure AD テナント内のユーザー/アプリケーションのアクセスポリシーとアクセス許可を定義します。これにより、サインイン時のユーザー/アプリケーションの認証、リソースアクセス時の承認などのコア機能が有効になります。
Citrix MCSサービスによって使用されるサービスプリンシパルに割り当てられたアクセス許可を決定します。
サブスクリプションスコープのサービスプリンシパルには,Citrix環境で使用される該当するサブスクリプションに対する共同作成者権限があります。範囲が狭いサービスプリンシパルには,ネットワーク,マスターイメージ,およびVDAを含むリソースグループに,きめ細かRBACいが適用されます。スコープが狭いサービスプリンシパルは,サービスに必要なアクセス許可にのみアクセス許可を制限することをお勧めします。これは”最小特権“というセキュリティ概念に準拠しています。
タグ付け
お客様は,タグをAzureリソースに適用し,メタデータを論理的に分類に整理します。各タグは,名前と値のペアで構成されます。たとえば”環境”という名前と値”生産”を本番環境のすべてのリソースに適用できます。
お客様は、そのタグ名と値を使用して、サブスクリプション内のすべてのリソースを取得できます。タグを使用すると、異なるリソースグループから関連するリソースを取得できます。この方法は、管理者が課金や管理のためにリソースを整理する必要がある場合に役立ちます。
リソースごとに15個のタグに制限があります。Citrix MCSは仮想マシンごとに2つのタグを作成するため,MCSマシンのタグは13個に制限されます。MCS非永続マシンは,再起動時に削除されます。これにより,タグ,ブート診断などのAzure VM固有の特性が削除されます。タグが必要な場合は、Azure Append ポリシーを作成し、適用可能な MCS リソースグループに適用することをお勧めします。
蔚蓝色的ポリシー
Azureポリシーは,タグ付け,許可されたSKU,暗号化,Azureリージョン,命名規則などの側面を制御できます。使用可能なデフォルトのポリシーと,カスタムポリシーを適用する機能があります。蔚蓝色的ポリシーは、サブスクリプションまたはリソースグループレベルで適用できます。複数のポリシーを定義できます。リソースグループレベルで適用されるポリシーは、サブスクリプションレベルのポリシーよりも優先されます。
Citrix環境全体で制御および標準化する必要があるAzureの側面を特定します。ハードクォータはポリシーを強制し,例外を許可しません。ソフトクォータは,ポリシーの適用について監査し,ポリシーが満たされていない場合に通知します。ポリシーの定義の詳細については,Azureのドキュメントを参照してください。
図6:AzureガバナンスアクセスポリシーとRBAC
セキュリティ
セキュリティはAzureのあらゆる側面に統合されています。Azureはグローバルなセキュリティインテリジェンス,高度な顧客向けコントロール,セキュリティで強化されたインフラストラクチャから得られる独自のセキュリティ利点を提供します。この強力な組み合わせにより,アプリケーションとデータの保護,コンプライアンスへの対応,コスト・パフォーマンスの高いセキュリティをあらゆる規模の組織に提供できます。
CVADサービスによるストレージ・アカウントのプロビジョニングのセキュリティ保護
前述したように,MCSは顧客のサブスクリプションで機械をスピンアップするサービス(CVAD内)です。MCSは,AzureリソースグループへのアクセスにAAD ID -アプリケーションサービスプリンシパルを使用して,さまざまなアクションを実行します。ストレージアカウントタイプのリソースの場合,MCSは異なるアクション(書き込み/読み取り/削除)に必要なときにキーを取得するlistkeys
権限が必要です。現在の実装では,次の要件に関するMCS要件があります。
- ストレージアカウントネットワークは,パブリックインターネットからのアクセスです。
- ストレージアカウントRBACは
listkeys
アクセス許可
一部の組織では、ストレージアカウントのエンドポイントをパブリックにしておくことが懸念されます。以下は、管理ディスクを使用して仮想マシンを展開するときに作成および格納されるアセットの分析です(デフォルトの動作)。
- テーブルストレージ:カタログのプライマリストレージアカウント(またはプライマリが溢价ディスクに使用されている場合はセカンダリ)のテーブルストレージに,マシン構成と状態データを保持します。テーブル内に機密情報はありません。
- ロック: 特定の操作 (ストレージアカウントへのマシンの割り当て、ディスクの複製) では、ロックオブジェクトを使用して複数のプラグインインスタンスからの操作を同期します。これらのファイルは空のブロブであり、機密データは含まれません。
2020年10月15日より前に作成されたマシンカタログの場合,MCSはアイデンティティディスク用の追加のストレージアカウントを作成します。
- ディスクのインポート:ディスクをインポートする場合(ID,命令),ディスクをページBLOBとしてアップロードします。次に,ページBLOBから管理ディスクを作成し,ページBLOBを削除します。一時データには,コンピュータオブジェクト名とパスワードの機密データが含まれます。これは,2020年10月15日以降に作成されたすべてのマシンカタログには適用されません。
サービスで必要なアクセス許可のみにアクセス許可を制限するには,特定のリソースグループに適用される狭いスコープサービスプリンシパルを使用することをお勧めします。これは”最小特権“というセキュリティ概念に準拠しています。詳細については,CTX219243およびCTX224110を参照してください。
IaaS-Azureセキュリティセンターの監視
Azureセキュリティセンターは,Azureリソースのセキュリティ状態を分析します。セキュリティセンターは、潜在的なセキュリティの脆弱性を特定すると、必要な制御を構成するプロセスをお客様に提供する推奨事項を作成します。推奨事項は、Azure リソースタイプ (仮想マシン) とコンピューター、アプリケーション、ネットワーク、SQL、および ID とアクセスに適用されます。従わなければならないベストプラクティスはいくつかあります。
- 仮想マシンアクセスを制御し、特権アクセスを保護します。
- マルウェア対策のプロビジョニングにより、悪意のあるソフトウェアの識別と削除に役立ちます。
- マルウェア対策ソリューションをセキュリティセンターと統合して,保護の状態を監視します。
- 虚拟机を最新の状態に保ち、展開時に、構築したイメージに最新の 窗户とセキュリティ更新プログラムが含まれていることを確認します。
- VMを定期的に再デプロイして,OSの新しいバージョンを強制します。
- 仮想マシンへのトラフィックを制御するためのネットワークセキュリティグループとルールを構成します。
- 网状物アプリケーションファイアウォールをプロビジョニングして、网状物アプリケーションを標的とする攻撃からの防御に役立ちます。
- 推奨ベースラインと一致しないOS構成のアドレス指定
ネットワーク設計
ネットワークセキュリティは,ネットワークトラフィックに制御を適用することにより,不正なアクセスや攻撃からリソースを保護するプロセスとして定義できます。目標は,正当なトラフィックのみが許可されるようにすることです。Azureには,アプリケーションとサービスの接続要件をサポートする堅牢なネットワークインフラストラクチャが含まれています。Azure内のリソース間,オンプレミスとAzureでホストされるリソース間,およびインターネットとAzureとの間でネットワーク接続が可能です。
仮想ネットワーク(联接)セグメンテーション
Azure仮想ネットワークは,オンプレミスネットワーク上の局域网に似ています。Azure仮想ネットワークの背後にある考え方は,お客様がすべてのAzure仮想マシンを配置できる単一のプライベートIPアドレス空間をベースにしたネットワークを作成することです。ベストプラクティスは,より大きなアドレス空間をサブネットに分割し,サブネット間にネットワークアクセス制御を作成することです。サブネット間のルーティングは自動的に行われるため,ルーティングテーブルを手動で設定する必要はありません。
ネットワークセキュリティグループ(NSG)を使用します。NSGは、5.タプル(送信元 知识产权送信元ポート、宛先 知识产权宛先ポート、およびレイヤ 4.プロトコル)アプローチを使用して、ネットワークトラフィックの許可/拒否ルールを作成するシンプルなステートフルパケットインスペクションデバイスです。ルールは、単一の 知识产权アドレス、複数の 知识产权アドレス、またはサブネット全体との間で送受信されるトラフィックを許可または拒否します。
お客様は、蔚蓝色的でユーザー定義ルート (UDR)と呼ばれるカスタムまたはユーザー定義のルートを作成して、蔚蓝色的のデフォルトシステムルートを上書きしたり、サブネットのルートテーブルにルートを追加したりできます。蔚蓝色的では、管理者はルートテーブルを作成し、ルートテーブルを 0個以上の仮想ネットワークサブネットに関連付けることができます。各サブネットには、0または 1.つのルートテーブルが関連付けられます。
NSGおよびUDRは,仮想ネットワーク内のサブネットレベルで適用されます。AzureでCitrix虚拟网络を設計する場合は,同様のコンポーネント用のサブネットを作成し,必要に応じてNSGとUDRをきめ細かく適用できるように,このことを念頭に置いて仮想ネットワークを設計することをお勧めします。たとえば,Citrixインフラストラクチャを独自のサブネットに分割し,各ユースケースに対応するサブネットを作成します。
Citrixおよびサポートするテクノロジーに必要なポートとプロトコルを特定します。環境内で使用されているネットワークセキュリティグループ内で,これらのポートが許可されていることを確認します。ネットワークセキュリティグループは、IP、仮想ネットワーク、サービスタグ、またはアプリケーションセキュリティグループの定義済みのセットにインバウンドおよびアウトバウンド通信を制限できます。
図7:NSGおよび ASGを使用した 蔚蓝色的セキュリティセンターとネットワークセキュリティ
接続
Azure仮想ネットワークをお客様のローカル/クラウドネットワークに接続することは,ハイブリッドネットワークと呼ばれます。このセクションでは,ネットワーク接続とネットワークサービスルーティングのオプションについて説明します。お客様は,次のオプションの任意の組み合わせを使用して,オンプレミスのコンピューターとネットワークを仮想ネットワークに接続できます。
- ポイントツーサイト仮想プライベートネットワーク(VPN):仮想ネットワークと顧客ネットワーク内の1台のコンピュータの間で確立されます。仮想ネットワークとの接続を確立する各コンピュータは,その接続を構成する必要があります。この接続の種類は,お客様の既存のネットワークへの変更がほとんどまたはまったく必要ないため,Azureの使用を開始する場合や,開発者にとって最適です。コンピュータと仮想ネットワーク間の通信は,暗号化されたトンネルを介してインターネット経由で送信されます。
- サイト間VPN:オンプレミスのVPNデバイスと,仮想ネットワークにデプロイされたAzure VPN网关の間で確立されます。この接続の種類により,顧客が仮想ネットワークへのアクセスを許可するすべてのオンプレミスリソースが有効になります。オンプレミスのVPNデバイスとAzure VPNゲートウェイ間の通信は,暗号化されたトンネルを介してインターネット経由で送信されます。
- Azure ExpressRoute: ExpressRouteパートナーを通じて,お客様のネットワークとAzureの間に確立されます。この接続は非公開です。トラフィックはインターネットを経由しません。
Azureから顧客への接続に関する主な考慮事項は,帯域幅,待ち時間,セキュリティ,およびコストです。サイト間のVPNは表达路线よりも帯域幅制限が低く,カスタマーが使用するエッジルータのパフォーマンスによって異なります。SLAはVPN网关SKUで利用できます。サイト間VPNは,インターネット経由でIPSECを使用します。
エクスプレスルートは、インターネット経由ではなく、専用の専用接続です。これにより、高速ルートを使用するときのレイテンシーが短くなります。また、エクスプレスルートは10Gbpsまで拡張できます。エクスプレスルートは、認定パートナーを使用して構成されます。これらのプロバイダによる構成時間は、プロジェクト計画時に考慮する必要があります。高速ルートコストには、微软コンポーネントと 快线プロバイダーコンポーネントがあります。
通常,これらの接続は複数のサービス(データベースレプリケーション,ドメイントラフィック,アプリケーショントラフィックなど)で共有されます。ハイブリッドクラウド展開では,内部ユーザーがAzureでCitrixアプリにアクセスするために,この接続を通過するためにICAトラフィックを必要とするシナリオがある場合があります。帯域幅の監視は重要です。
ADCおよび従来の店面では,AzureへのエクスプレスルートやVPNではなく,オフィスのISPを使用してADCへのユーザーの接続を指示するために,最適なゲートウェイルーティングを使用することもできます。
ユーザ定義ルート(UDR)
通常、お客様は UDRを使用して 蔚蓝色的トラフィックを 蔚蓝色的内のファイアウォールアプライアンスまたは特定の仮想ネットワークにルーティングします。たとえば、VDAからインターネットへの北/南のトラフィックなどです。大量のトラフィックが 蔚蓝色的内のサードパーティのファイアウォールアプライアンスにルーティングされる場合、これらのアプライアンスが適切にサイズ設定または構成されていない場合、リソースのボトルネックや可用性リスクが生じます。NSGはサードパーティのファイアウォールを補完するために使用でき、必要に応じて可能な限り活用する必要があります。トラフィックイントロスペクションが必要な場合は、蔚蓝色的ネットワークウォッチャーを検討してください。
仮想ネットワークピアリング
仮想ネットワークピアリングは,2つのAzure仮想ネットワークをシームレスに接続します。ピア接続されると,接続のために,仮想ネットワークは1つとして表示されます。ピアリングされた仮想ネットワーク内の仮想マシン間のトラフィックは,微软バックボーンインフラストラクチャを介してルーティングされます。これは,トラフィックが同じ仮想ネットワーク内の仮想マシン間でルーティングされる場合と同様に,プライベートIPアドレスのみを通じて行われます。
蔚蓝色的のサポート:
- VNetピアリング——同じAzureリージョン内のVNetの接続
- グローバルVNetピアリングazureリージョン間でのVNetの接続
複数のVNetにワークロードを展開しているお客様は,VNetピアリングを使用して,VNet間の仮想マシン間の通信を有効にすることを検討する必要があります。
図8: データセンターの接続性とルート
SD-WAN
ソフトウェア定義WAN (SD-WAN)テクノロジーにより,困難な接続であっても,優れたユーザーエクスペリエンスを提供できます。これは,仮想アプリやデスクトップの配信に自然なフィット感です。
- 使用可能なすべての帯域幅をアクティブ/アクティブ接続に集約し,より多くの帯域幅を提供します。
- 独自のHDXエクスペリエンス品質テクノロジーを使用して,パフォーマンスを最適化し,ネットワークポリシーを調整します。
- リッチメディアやハイデフィニションビデオでも、最高品質のエクスペリエンスで、仮想アプリとデスクトップユーザーの常時接続を確実にします。
VPNを使用しているお客様は,SD-WANを使用してAzureおよびお客様のデータセンター接続に冗長性を追加したり,アプリケーション固有のルーティングを提供したりできます。Citrix SD-WANは,利用可能な接続間でトラフィックを自動的にリダイレクトします。実際,エクスペリエンスはとてもシームレスで,ユーザーは変化が起こったことを認識することさえありません。プライマリアクセスIPアドレスは変更されないため,ユーザーは同じ方法とデバイスを使用してアプリやデータにアクセスできます。
Citrix ADC
微软AzureのCitrix ADCは組織がクラウドにデプロイされた安全で最適化されたアプリケーションと資産へのアクセスを確保し,環境のニーズの変化に応じて調整するネットワーク基盤を確立する柔軟性を提供します。データセンターに障害が発生した場合,Citrix ADCはユーザーのトラフィックを自動的にセカンダリサイトにリダイレクトします。ユーザーは中断されません。複数のデータセンターにまたがる負荷分散とグローバルサーバ負荷分散により,サーバの稼働状態,容量,使用率を最適化できます。
お客様と話し合い,リソースの場所ごとに次のユースケースを定義します。
アクセス方法 | 注意事項 |
---|---|
内部のみ | 内部アクセスのみが必要な場合は、Citrix ADCは必要ありません。 |
Citrix ADC网关服务経由の外部アクセス。 | Citrix云ADC网关服务は、伊卡プロキシを提供します(安全なリモート接続のみ)。 |
AzureリソースロケーションにデプロイされたCitrix ADC VPXを介した外部アクセス | お客様は,以下の要件が必要な場合は,AzureのCitrix ADC VPXアプライアンスを検討する必要があります。1.完全なSSON 2による多要素認証。エンドポイントスキャン3。高度な認証または事前認証ポリシー4。Citrix SmartAccessポリシー。注:これらの要件では,ワークスペースエクスペリエンスサービスではなく,Citrix ADCで認証を行う必要性が求められます。認証がCitrix ADC网关仮想サーバーによって管理されている場合は,店面が必要です。 |
Citrix ADC -導入モデル
アクティブ——アクティブ展開では,スタンドアロンのCitrix ADCノードを使用します。このノードは,Azureロードバランサーを使用してスケールアウトできます。アクティブ/パッシブペアは,ノード障害時のICAトラフィックのステートフルフェイルオーバーを容易にします。ただし,単一のVPXの容量に制限されます。アクティブ/パッシブノードには,Azureロードバランサーも必要です。
Citrix ADCは,Azure NICあたり500 mbpsに制限されています。剪断,NSIPおよびVIPトラフィックを分離して,Citrix ADC网关やその他のサービスで使用可能なスループットを最大化するために,複数のNICを使用することをお勧めします。
ソース
このリファレンスアーキテクチャの目的は,お客様独自の実装計画を支援することです。この作業を容易にするために,独自の詳細な設計および実装ガイドに適応できるソース図を提供します:ソースダイアグラム。
参照ドキュメント
操作
- 一般的なガバナンス
サブスクリプションガバナンス
- タグ付け
- コスト管理
- ポリシー
- 命名規則
- リソースロック
ID
リファレンスアーキテクチャ
AAD特権アイデンティティ (PIM)
ガバナンス
レベル100
レベル200
400级
リファレンス・アーキテクチャ:
セキュリティ
レベル100
レベル200
300级
リファレンス・アーキテクチャ:
Azure监控
レベル100
レベル200
リファレンスアーキテクチャ
ドキュメント
接続
この記事の概要
- はじめに
- 計画
- 概念リファレンスアーキテクチャ
- 操作
- 命名規則
- サブスクリプション
- Azure地区
- 可用性セット
- 蔚蓝色的計画メンテナンス
- Azureのスケジュールされたイベント
- 障害回復(博士)
- アーキテクチャの拡張
- ホスティングアーキテクチャ
- クラウドサービスアーキテクチャ
- リソースグループ
- イメージの管理
- オンデマンドプロビジョニング
- ストレージアカウントコンテナ
- イメージレプリケーション
- ファイルサーバテクノロジ
- インフラストラクチャコスト管理
- リザーブドインスタンス
- Citrix自动定量
- エンドユーザーエクスペリエンスの最適化
- ユーザー・ワークスペースの定義
- Azure VMインスタンスタイプ
- スケールアップやスケールアウトはどうですか吗?
- ストレージ
- ID
- ガバナンス
- セキュリティ
- ネットワーク設計
- 接続
- ソース
- 参照ドキュメント