Citrix Virtual Apps and Desktops 7 2402 LTSR

データベース

注:

Citrix Virtual Apps and Desktops™の展開は、WebベースのWeb StudioとWindowsベースのCitrix Studioという2つの管理コンソールで管理できます。この記事ではWeb Studioのみを扱います。Citrix Studioに関する詳細は、Citrix Virtual Apps and Desktops 7 2212以前のバージョンに該当する記事を参照してください。

シトリックス バーチャル アプリ または シトリックス バーチャル デスクトップ™ サイトは、3つのSQL Serverデータベースを使用します。

  • サイト: (サイト構成とも呼ばれます)実行中のサイト構成、現在のセッション状態、および接続情報を保存します。
  • ログ: (構成ログとも呼ばれます)サイト構成の変更と管理アクティビティに関する情報を保存します。このデータベースは、構成ログ機能が有効になっている場合(デフォルト = 有効)に使用されます。
  • 監視: Directorが使用するデータ(セッション情報や接続情報など)を保存します。

各Delivery Controllerはサイトデータベースと通信します。Controllerとデータベース間ではWindows認証が必要です。Controllerは、サイト内の他のControllerに影響を与えることなく、プラグを抜いたり電源を切ったりできます。ただし、これはサイトデータベースが単一障害点となることを意味します。データベースサーバーが故障した場合、既存の接続はユーザーがログオフまたは切断するまで機能し続けます。サイトデータベースが利用できなくなった場合の接続動作については、「ローカルホストキャッシュ」を参照してください。

Citrixはデータベースに関して以下を推奨します。

  • 定期的にバックアップしてください。 データベースサーバーが故障した場合にバックアップから復元できるように、データベースを定期的にバックアップしてください。各データベースのバックアップ戦略は異なる場合があります。詳細については、CTX135207を参照してください。ただし、これはCitrixXenDesktopDBを参照していますが、これは現在サポートされておらず、お客様は利用できません。

  • サイト、監視、およびログのSQL Serverデータベースを定期的にバックアップおよび復元してください。 SQL Serverデータベースに関する具体的な情報については、「SQL Serverデータベースの完全バックアップと差分バックアップの作成」を参照してください。

サイトに複数のゾーンが含まれている場合は、プライマリゾーンに常にサイトデータベースが含まれていることを確認してください。すべてのゾーンのControllerがそのデータベースと通信します。

高い可用性

自動フェールオーバーを確実にするために考慮すべき高可用性ソリューションがいくつかあります。

  • AlwaysOn可用性グループ(基本可用性グループを含む): SQL Server 2012で導入されたこのエンタープライズレベルの高可用性および災害復旧ソリューションにより、1つ以上のデータベースの可用性を最大化できます。AlwaysOn可用性グループでは、SQL ServerインスタンスがWindows Server Failover Clustering (WSFC) ノード上に存在する必要があります。詳細については、「SQL ServerでのWindows Serverフェールオーバークラスタリング」を参照してください。
  • SQL Server データベースミラーリング: データベースのミラーリングにより、アクティブなデータベースサーバーが失われた場合でも、自動フェールオーバープロセスが数秒で発生し、ユーザーは通常影響を受けません。この方法は、各データベースサーバーで完全なSQL Serverライセンスが必要となるため、他のソリューションよりも高価です。ミラーリング環境ではSQL Server Expressエディションを使用できません。
  • SQL クラスタリング: Microsoft SQL クラスタリングテクノロジーを使用すると、障害が発生した別のサーバーのタスクと責任を、あるサーバーが自動的に引き継ぐことができます。ただし、このソリューションのセットアップはより複雑であり、自動フェールオーバープロセスは通常、SQL ミラーリングなどの代替手段よりも遅くなります。
  • ハイパーバイザーの高可用性機能を使用する: この方法では、データベースを仮想マシンとして展開し、ハイパーバイザーの高可用性機能を使用します。このソリューションは、既存のハイパーバイザーソフトウェアを使用し、SQL Server Expressエディションも使用できるため、ミラーリングよりも安価です。ただし、データベース用に新しいマシンが起動するのに時間がかかる場合があり、ユーザーへのサービスが中断される可能性があるため、自動フェールオーバープロセスは遅くなります。

ローカルホストキャッシュ機能は、SQL Server の高可用性に関するベストプラクティスを補完します。ローカルホストキャッシュにより、サイトデータベースが利用できない場合でも、ユーザーはアプリケーションやデスクトップに接続および再接続できます。詳細については、「ローカルホストキャッシュ」を参照してください。

サイト内のすべてのコントローラーが失敗した場合、VDAを高可用性モードで動作するように構成できます。これにより、ユーザーはデスクトップとアプリケーションへのアクセスを継続できます。高可用性モードでは、VDAはコントローラーによって仲介される接続ではなく、ユーザーからの直接ICA接続を受け入れます。この機能は、すべてのコントローラーとの通信が失敗するまれな場合にのみ使用してください。この機能は、他の高可用性ソリューションの代替ではありません。詳細については、「CTX 127564」を参照してください。

SQL クラスタリングまたはSQL ミラーリングのインストールにおけるノードへのコントローラーのインストールはサポートされていません。

データベースソフトウェアのインストール

デフォルトでは、最初のDelivery Controller™をインストールする際に、そのサーバーで別のSQL Server インスタンスが検出されない場合、SQL Server Express エディションがインストールされます。このデフォルトの動作は、概念実証またはパイロット展開には通常十分です。ただし、SQL Server ExpressはMicrosoft の高可用性機能をサポートしていません。

デフォルトのインストールでは、デフォルトのWindows サービスアカウントと権限が使用されます。これらのデフォルトの詳細については、Windows サービスアカウントをsysadmin ロールに追加する方法を含め、Microsoft のドキュメントを参照してください。この構成では、コントローラーはNetwork Service アカウントを使用します。コントローラーには、追加のSQL Server ロールや権限は必要ありません。

必要に応じて、データベースインスタンスに対してインスタンスを非表示を選択できます。Web Studioでデータベースのアドレスを構成する際は、インスタンス名ではなく、インスタンスの静的ポート番号を入力してください。SQL Server データベースエンジンのインスタンスを非表示にする方法の詳細については、Microsoft のドキュメントを参照してください。

ほとんどの運用環境の展開、およびMicrosoft の高可用性機能を使用するすべての展開では、サポートされているExpress 以外のSQL Server エディションのみを使用することをお勧めします。SQL Serverは、最初のコントローラーがインストールされているサーバー以外のマシンにインストールしてください。システム要件に、サポートされているSQL Server のバージョンが記載されています。データベースは1台以上のマシンに配置できます。

サイトを作成する前に、SQL Server ソフトウェアがインストールされていることを確認してください。データベースを作成する必要はありませんが、作成する場合は空である必要があります。Microsoft の高可用性テクノロジーの構成も推奨されます。

Windows Updateを使用してSQL Serverを最新の状態に保ちます。

サイト作成ウィザードからデータベースをセットアップする

サイト作成ウィザードのデータベースページで、データベース名とアドレス(場所)を指定します。(「データベースアドレス形式」を参照してください。)DirectorがMonitor Serviceをクエリする際の潜在的なエラーを回避するため、監視データベースの名前に空白を使用しないでください。

データベース」ページでは、データベースを設定するための2つのオプション(自動とスクリプトの使用)が提供されます。一般的に、必要なデータベース権限(Web StudioユーザーおよびCitrix管理者)がある場合は、自動オプションを使用できます。(データベース設定に必要な権限を参照してください。)

サイト作成後、構成ログおよび監視データベースの場所を後で変更できます。データベースの場所の変更を参照してください。

ミラーデータベースを使用するようにサイトを構成するには、以下を完了してから、自動またはスクリプトによるセットアップ手順に進みます。

  1. 2台のサーバー(AとB)にSQL Serverソフトウェアをインストールします。
  2. サーバーAで、プライマリとして使用するデータベースを作成します。サーバーAのデータベースをバックアップし、サーバーBにコピーします。
  3. サーバーBで、バックアップファイルを復元します。
  4. サーバーAでミラーリングを開始します。

サイト作成後にミラーリングを確認するには、PowerShellコマンドレットget-configdbconnectionを実行して、接続文字列にミラーへのフェールオーバーパートナーが設定されていることを確認します。

ミラーデータベース環境で後でDelivery Controllerを追加、移動、または削除する場合は、Delivery Controllerを参照してください。

自動セットアップ

必要なデータベース権限がある場合は、サイト作成ウィザードのデータベースページで、Studioからデータベースを作成および設定を選択します。次に、プライマリデータベースの名前とアドレスを指定します。

指定したアドレスにデータベースが存在する場合、それは空である必要があります。指定したアドレスにデータベースが存在しない場合、データベースが見つからないことが通知され、データベースを作成するかどうかを尋ねられます。その操作を確定すると、Web Studioは自動的にデータベースを作成し、プライマリデータベースとレプリカデータベースの初期化スクリプトを適用します。

スクリプトによるセットアップ

必要なデータベース権限がない場合は、データベース管理者など、権限を持つ人に支援を依頼してください。手順は次のとおりです。

  1. サイト作成ウィザードのデータベースページで、手動でセットアップするためのスクリプトを生成を選択します。この操作により、以下のプライマリデータベースとレプリカデータベース(サイト、監視、ログデータベース)のそれぞれについて、次の3種類のスクリプトが生成されます。

    • 「SysAdmin」という名前を含むスクリプト。データベースとDelivery Controllerのログインを作成するスクリプトです。これらのタスクにはsecurityadmin権限が必要です。
    • 「DbOwner」という名前を含むスクリプト。データベースにユーザーロールを作成し、ログインを追加し、データベーススキーマを作成するスクリプトです。これらのタスクにはdb_owner権限が必要です。
    • 「Mixed」という名前を含むスクリプト。必要な権限に関係なく、すべてのタスクを1つのスクリプトにまとめたものです。

    スクリプトの保存場所を指定できます。

    注:

    エンタープライズ環境では、データベースのセットアップには、異なる役割(権限)を持つ異なるチームによって処理される可能性のあるスクリプトが含まれます: securityadminまたはdb_owner。該当する場合、まずsecurityadminロールを持つ管理者によって「SysAdmin」スクリプトが実行され、次にdb_owner権限を持つ管理者によって「DbOwner」スクリプトが実行されます。これらのスクリプトを生成するには、PowerShellを使用することもできます。詳細については、「推奨されるデータベース権限スクリプト」を参照してください。

  2. これらのスクリプトをデータベース管理者に渡します。サイト作成ウィザードは、この時点で自動的に停止します。後でサイト作成を続行するために戻ると、プロンプトが表示されます。

データベース管理者は、その後データベースを作成します。各データベースは、以下の特性を持つ必要があります。

  • _CI_AS_KSで終わる照合順序を使用します。_100_CI_AS_KSで終わる照合順序を使用することをお勧めします。
  • 最適なパフォーマンスを得るには、SQL ServerのRead-Committed Snapshotを有効にします。詳細については、「CTX 137161」を参照してください。
  • 該当する場合、高可用性機能が構成されていること。
  • ミラーリングを構成するには、まずデータベースを完全復旧モデルを使用するように設定します(シンプルモデルがデフォルトです)。プライマリデータベースをファイルにバックアップし、ミラーサーバーにコピーします。次に、ミラーサーバーでバックアップファイルを復元します。最後に、プライマリサーバーでミラーリングを開始します。

データベース管理者は、SQLCMDコマンドラインユーティリティまたはSQLCMDモードのSQL Server Management Studioを使用して、次の操作を行います。

  • 高可用性SQL Serverデータベースインスタンス(高可用性が構成されている場合)で、xxx_Replica.sqlの各スクリプトを実行します。
  • プライマリSQL Serverデータベースインスタンスで、xxx\_Principal.sqlの各スクリプトを実行します。

SQLCMDの詳細については、Microsoftのドキュメントを参照してください。

すべてのスクリプトが正常に完了すると、データベース管理者はCitrix管理者に3つの主要なデータベースアドレスを提供します。

Web Studioはサイト作成を続行するように求めます。データベースページに戻ります。アドレスを入力します。データベースをホストしているサーバーのいずれかに接続できない場合、エラーメッセージが表示されます。

データベースのセットアップに必要な権限

データベースを作成および初期化する(またはデータベースの場所を変更する)には、ローカル管理者およびドメインユーザーである必要があります。また、特定のSQL Server権限も必要です。以下の権限は、明示的に構成するか、Active Directoryグループメンバーシップによって取得できます。Web Studioのユーザー資格情報にこれらの権限が含まれていない場合、SQL Serverのユーザー資格情報の入力を求められます。

実行操作 目的 サーバーの役割 データベースの役割
データベースの作成 適切な空のデータベースを作成する dbcreator  
スキーマの作成 すべてのサービス固有のスキーマを作成し、最初のControllerをサイトに追加する securityadmin* db_owner
コントローラーを追加 (最初のコントローラー以外の) コントローラーをサイトに追加 securityadmin* db_owner
コントローラー (ミラーサーバー) を追加 ミラーデータベースのミラーロールにあるデータベースサーバーにコントローラーログインを追加 securityadmin*  
コントローラーを削除 サイトからコントローラーを削除 ** db_owner
スキーマを更新 スキーマの更新またはホットフィックスを適用   db_owner

技術的にはより制限的ですが、実際には、securityadmin サーバーロールを sysadmin サーバーロールと同等として扱うことができます。

サイトからコントローラーが削除されても、データベースサーバーへのコントローラーのログオンは削除されません。これは、同じマシン上でこのCitrix製品以外のサービスによって使用されているログオンが誤って削除されるのを防ぐためです。ログオンが不要になった場合は、手動で削除する必要があります。この操作には、securityadmin サーバーロールのメンバーシップが必要です。

Web Studioを使用してこれらの操作を実行する場合、Web Studioユーザーは、適切なサーバーロールのメンバーであるデータベースサーバーアカウントを持っているか、またはそうであるアカウントの資格情報を提供できる必要があります。

推奨されるデータベース権限スクリプト

エンタープライズ環境では、データベースのセットアップには、異なる役割(権限)を持つ異なるチームによって処理される必要があるスクリプトが含まれます: securityadmin または db_owner

PowerShellを使用すると、推奨されるデータベース権限を指定できます。デフォルト以外の値を指定すると、個別のスクリプトが作成されます。1つのスクリプトには securityadmin ロールを必要とするタスクが含まれます。もう1つのスクリプトは db_owner 権限のみを必要とし、データベース管理者に連絡することなく、Citrix管理者が実行できます。

get-*DBSchema コマンドレットでは、-DatabaseRights オプションには次の有効な値があります。

  • SA: データベースとDelivery Controllerのログインを作成するスクリプトを生成します。これらのタスクには securityadmin 権限が必要です。
  • DBO: データベースにユーザーロールを作成し、ログインを追加し、その後データベーススキーマを作成するスクリプトを生成します。これらのタスクには db_owner 権限が必要です。
  • Mixed: (デフォルト) 必要な権限に関係なく、すべてのタスクを1つのスクリプトにまとめます。

詳細については、コマンドレットのヘルプを参照してください。

データベースアドレスの形式

データベースアドレスは、次のいずれかの形式で指定できます。

  • ServerName
  • ServerName\InstanceName
  • ServerName,PortNumber

AlwaysOn 可用性グループの場合、場所フィールドにグループのリスナーを指定します。

データベースの場所を変更する

サイトを作成した後、構成ログデータベースと監視データベースの場所を変更できます。(サイトデータベースの場所は変更できません。)データベースの場所を変更すると、次のようになります。

  • 以前のデータベースのデータは、新しいデータベースにインポートされません。
  • ログを取得する際、両方のデータベースからログを集約することはできません。
  • 新しいデータベースの最初のログエントリは、データベースの変更が発生したことを示しますが、以前のデータベースを特定するものではありません。

強制ログが有効になっている場合、構成ログデータベースの場所を変更することはできません。

データベースの場所を変更するには:

  1. データベースを配置するサーバーに、サポートされているバージョンのMicrosoft SQL Serverがインストールされていることを確認します。必要に応じて、高可用性機能をセットアップします。
  2. Web Studioにサインインし、左ペインで [設定] を選択します。
  3. [データベース] タイルを見つけて [編集] を選択します。
  4. [データベースの管理] ページで、新しい場所を指定するデータベースを選択し、アクションバーで [データベースの変更] を選択します。
  5. 新しい場所とデータベース名を指定します。
  6. Web Studioにデータベースを作成させたい場合で、適切な権限がある場合は、[完了] をクリックします。プロンプトが表示されたら [完了] をクリックすると、Web Studioがデータベースを自動的に作成します。Web Studioは、資格情報を使用してデータベースへのアクセスを試行します。失敗した場合は、データベースユーザーの資格情報の入力を求められます。その後、Web Studioはデータベーススキーマをデータベースにアップロードします。資格情報は、データベース作成期間中のみ保持されます。
  7. Web Studio にデータベースを作成させたくない場合、または十分な権限がない場合は、データベーススクリプトの生成をクリックします。生成されたスクリプトには、必要に応じてデータベースとミラーデータベースを手動で作成するための手順が含まれています。スキーマをアップロードする前に、データベースが空であり、少なくとも1人のユーザーがデータベースにアクセスして変更する権限を持っていることを確認してください。

詳細情報

データベース