データベース
Citrix Virtual AppsサイトおよびCitrix Virtual Desktopsサイトでは、次の3つのSQL Serverデータベースを使用します：
- サイト：（別名：サイト構成）実行中のサイト構成に加えて、その時点でのセッションの状態と接続情報を格納します。
- 構成ログ：（別名：ログ）サイト構成の変更や管理タスクに関する情報を格納します。このデータベースは、構成ログ機能が有効化（デフォルトは有効）されているときに使用されます。
- モニター： セッションや接続情報などのデータを格納するために、Directorにより使用されます。
各Delivery Controllerは、サイトデータベースと通信します。Controllerとデータベース間の接続にはWindows認証が必要です。任意のControllerをシャットダウンしても、そのサイトのほかのControllerには影響しません。しかしながら、これはサイトデータベースが単一障害点になりうることを意味します。このデータベースサーバーで障害が発生しても、既存の接続は、ユーザーがログオフまたは切断するまでは機能し続けます。サイトデータベースが利用不可能な場合の接続動作について詳しくは、「ローカルホストキャッシュ」を参照してください。
データベースに関しては、Citrixでは以下をお勧めします：
-
定期的にバックアップを取ります。データベースのバックアップを定期的に作成して、データベースサーバーに障害が発生してもバックアップから復元できるようにします。各データベースを異なる方法でバックアップしなければならない場合があります。詳しくは、CTX135207を参照してください。ただし、ここで説明されているCitrixXenDesktopDBは、サポートされなくなった、または既にお客様が利用できなくなったCitrixXenDesktopDBを指しています。
-
サイト、監視、およびSQL Serverデータベースを定期的にバックアップおよび復元します。SQL Serverデータベースに関する特定の情報については、「SQL Serverデータベースの完全バックアップおよび差分バックアップの作成」を参照してください。
サイトに複数のゾーンが含まれている場合は、プライマリゾーンには必ずサイトデータベースを格納してください。すべてのゾーンのコントローラーは、このデータベースと通信します。
高可用性
自動フェールオーバーを確実にするために、数種類の高可用性ソリューションがあります。
- AlwaysOn可用性グループ機能（基本的な可用性グループを含む）： SQL Server 2012で導入されたエンタープライズレベルの高可用性および障害回復ソリューション。これにより、1つまたは複数のデータベースの可用性を最大化できます。AlwaysOn可用性グループ機能では、Windows Server Failover Clustering（WSFC）ノード上にSQL Serverインスタンスが存在する必要があります。詳しくは、「 SQL ServerでのWindows Serverフェールオーバークラスタリング」を参照してください。
- SQL Serverデータベースのミラーリング： データベースをミラーリングすると、アクティブなデータベースサーバーが停止しても自動フェールオーバー処理が実行され、ユーザーは通常、停止の影響を受けません。各データベースサーバー上に完全なSQL Serverライセンスが必要になるため、ほかのソリューションよりも費用が高くつきます。SQL Server Expressエディションを使用してデータベースをミラーリングすることはできません。
- SQLクラスタリング： MicrosoftのSQLクラスタリングテクノロジを使用して、任意のサーバーに障害が起きた場合に別のサーバーが自動的にタスクや実行内容を引き継ぐようにできます。ただし、このソリューションのセットアップは複雑で、SQLミラーリングなどほかのソリューションよりも自動フェールオーバー処理には一般的に時間がかかります。
- ハイパーバイザーの高可用性機能の使用： この方法では、仮想マシンとしてデータベースを展開し、ハイパーバイザーの高可用性機能を使用します。このソリューションでは既存のハイパーバイザーソフトウェアを使用でき、またSQL Server Expressエディションも使用できるため、ミラーリングよりも費用が安いというメリットがあります。ただし、データベースの新しい仮想マシンの起動に時間がかかるため、自動フェールオーバー処理が遅くなり、ユーザーへのサービスが中断する可能性があります。
ローカルホストキャッシュ機能は、SQL Serverの高可用性のベストプラクティスを補完します。ローカルホストキャッシュによりユーザーは、サイトデータベースに接続できない状態でも、アプリケーションやデスクトップに接続および再接続できます。詳しくは、「ローカルホストキャッシュ」を参照してください。
サイト内のすべてのControllerで障害が起きた場合、VDAが高可用性モードで動作するように構成できます。これにより、ユーザーは障害発生後もデスクトップやアプリケーションにアクセスして使用することができます。高可用性モードでは、Controllerを経由しない、VDAへの直接ICA接続が可能になります。Controllerとのすべての通信に失敗した場合にのみ、この機能を使用してください。この機能を他の高可用性ソリューションの代わりに使用しないでください。詳しくは、CTX 127564を参照してください。
SQLクラスター化またはSQLミラー化インストールにおける、ノード上へのControllerのインストールはサポートされていません。
データベースソフトウェアのインストール
デフォルトでは、初めてDelivery Controllerをインストールしたときに、そのサーバーで他のSQL Serverインスタンスが検知されなかった場合に、SQL Server Expressエディションがインストールされます。通常、概念実証またはパイロット展開では、このデフォルトの動作で十分です。ただし、SQL Server ExpressはMicrosoftの高可用性機能をサポートしていません。
デフォルトのインストールでは、デフォルトのWindowsサービスアカウントおよび権限を使用します。Windowsサービスアカウントをsysadminロールに追加する方法など、デフォルトの設定について詳しくは、Microsoft社のドキュメントを参照してください。Controllerは、この構成でNetwork Serviceアカウントを使用します。SQL Serverに追加のロールまたは権限は必要ありません。
必要に応じて、データベースインスタンスで ［インスタンスの非表示］ を選択できます。Studioでデータベースのアドレスを構成する場合、インスタンス名ではなく、インスタンスの静的ポート番号を入力してください。SQL Serverデータベースエンジンのインスタンスを非表示にする方法について詳しくは、Microsoft社のドキュメントを参照してください。
ほとんどの実稼働環境、およびMicrosoftの高可用性機能を利用しているすべての環境では、Express以外のサポート対象エディションのSQL Serverのみを使用することをお勧めします。最初のControllerがインストールされているサーバー以外のマシンに、SQL Serverをインストールします。サポートされるSQL Serverのバージョンについては、「システム要件」を参照してください。データベースは1つまたは複数のマシンに常駐できます。
サイトを作成する前に、SQL Serverソフトウェアをインストールしておく必要があります。データベースを作成する必要はありませんが、作成する場合は、必ず空にしておいてください。Microsoft高可用性テクノロジの構成も推奨されます。
Windows Updateを使用して、SQL Serverを最新の状態に保ってください。
サイトの作成ウィザードを使ったデータベースのセットアップ
［サイトの作成］ウィザードの ［データベース］ ページで、データベースの名前とアドレス（場所）を指定します。（「データベースのアドレス形式」を参照してください）。DirectorがMonitor Serviceをクエリするときのエラーを防ぐため、監視データベースの名前にはスペースを使用しないでください。
［データベース］ページには、自動とスクリプト使用の2つのデータベース設定オプションがあります。StudioユーザーやCitrix管理者が、必要なデータベースアクセス権を持っている場合は、通常、自動オプションを使用します（「データベースのセットアップに必要な権限」を参照してください）。
構成ログや監視データベースの場所は、サイトの作成後に変更できます。「データベースの場所の変更」を参照してください。
ミラーデータベースを使用するようにサイトを構成するには、以下の手順を完了してから、自動またはスクリプトによるセットアップ手順に進みます。
- SQL ServerソフトウェアをサーバーAおよびBにインストールします。
- サーバーAに、プライマリとして使用するデータベースを作成します。サーバーAのデータベースをバックアップしてから、サーバーBにコピーします。
- サーバーBで、バックアップファイルを復元します。
- サーバーAでミラーリングを開始します。
サイトの作成後にミラーリング設定を検証するには、PowerShellコマンドレットget-configdbconnectionを実行して、ミラーに対する接続文字列でフェールオーバーパートナーが設定されていることを確認します。
ミラー化されたデータベース環境でDelivery Controllerを後から追加、移動、または削除する場合は、「Delivery Controller」を参照してください。
自動セットアップ
必要なデータベース権限を持っている場合は、サイトの作成ウィザードの ［データベース］ ページにある ［Studioでデータベースを作成および設定する］ を選択します。次に、プリンシパルデータベースの名前とアドレスを入力します。
指定したアドレスにデータベースが存在する場合、そのデータベースは空でなければなりません。指定されたアドレスにデータベースが存在しない場合、データベースが見つからないというメッセージが表示され、データベースを作成するかどうかの確認を求められます。作成に同意すると、Studioにより自動的にデータベースが作成され、プリンシパルデータベースとレプリカデータベースに初期化スクリプトが適用されます。
スクリプトを使ったセットアップ
必要なデータベース権限がない場合は、データベース管理者など、必要なデータベース権限を持っている人に支援を依頼してください。手順は以下のとおりです：
-
サイトの作成ウィザードの ［データベース］ ページで、［スクリプトを生成して手動でセットアップ］ を選択します。この操作により、次のプリンシパルデータベースとレプリカデータベースのそれぞれに対して、サイト、監視、およびログのデータベースの3種類のスクリプトが生成されます。
- 名前に「SysAdmin」を含むスクリプト。データベースとDelivery Controllerのログインを作成するスクリプト。これらのタスクには、securityadmin権限が必要です。
-
名前に「DbOwner」を含むスクリプト。データベースでユーザー役割を作成し、ログインを追加してから、データベーススキーマを作成するスクリプト。これらのタスクには
db_ownerの権限が必要です。 - 名前に「Mixed」を含むスクリプト。必要な権限にかかわらず、1つのスクリプトにすべてのタスクを含めます。
スクリプトの格納先を指定します。
注：
エンタープライズ環境では、データベースのセットアップに、役割（権限）が異なる（
securityadminまたはdb_owner）チームが処理する可能性があるスクリプトが含まれます。該当する場合は、最初にsecurityadminロールの管理者が「SysAdmin」スクリプトを実行し、次にdb_owner権限を持つ管理者が「DbOwner」スクリプトを実行します。これらのスクリプトの生成には、PowerShellを使用することもできます。詳しくは、「優先データベース権限スクリプト」を参照してください。 -
これらのスクリプトをデータベース管理者に渡します。この時点で、サイトの作成ウィザードは自動的に停止します。後で戻ってきたときに、サイトの作成を続行するように求められます。
その後、データベース管理者がデータベースを作成します。個々のデータベースには、次の特性が必要です：
- 「
_CI_AS_KS」で終わる照合順序を使用します。_100_CI_AS_KSで終わる照合順序を使用することをお勧めします。 - 最適なパフォーマンスを実現するには、SQL Server Read-Committed Snapshotを有効化します。詳しくは、CTX137161を参照してください。
- 構成済みの高可用性機能（該当する場合）。
- ミラーリングを構成するには、まず、完全復旧モデルを使用するようにデータベースを設定します（デフォルトは簡易モデル）。プリンシパルデータベースをファイルにバックアップして、それをミラーサーバーにコピーします。次に、ミラーサーバーにバックアップファイルを復元します。最後に、プリンシパルサーバーでミラーリングを開始します。
データベース管理者は、SQLCMDコマンドラインユーティリティ、またはSQL Server Management StudioをSQLCMDモードで使用して、以下のことができます：
- 高可用性SQL Serverデータベースインスタンスで、各
xxx_Replica.sqlスクリプトを実行する（高可用性が構成されている場合） - プリンシパルSQL Serverデータベースインスタンスで、各
xxx\_Principal.sqlスクリプトを実行する。
SQLCMDについて詳しくは、Microsoftのドキュメントを参照してください。
すべてのスクリプトが正常に終了したら、データベース管理者は、Citrix管理者に3種類のプリンシパルデータベースアドレスを渡します。
サイト作成の続行を求めるメッセージが表示されます。［データベース］ ページに戻ります。渡されたアドレスを入力します。データベースをホストしているサーバーのいずれかに接続できない場合、エラーメッセージが表示されます。
データベースのセットアップに必要な権限
データベースを作成し、初期化（または、データベースの場所を変更）するには、ローカル管理者およびドメインユーザーでなければなりません。また、特定のSQL Server権限も必要です。以下の権限は、Active Directoryのグループメンバーシップで明示的に構成または取得できます。Studioを使用する管理者にこれらの権限がない場合、SQL Serverユーザーの資格情報を入力する必要があります。
| 操作 | 目的 | サーバーロール | データベースロール |
|---|---|---|---|
| データベースの作成 | 空のデータベースを作成します | dbcreator |
|
| スキーマの作成 | サービス固有のすべてのスキーマを作成して、サイトに最初のControllerを追加します |
securityadmin* |
db_owner |
| Controllerの追加 | サイトにController（2つ目以降）を追加します |
securityadmin* |
db_owner |
| Controller（ミラーサーバー）の追加 | ミラー化されたデータベースのミラーロールのデータベースサーバーにControllerログインを追加します |
securityadmin* |
|
| Controllerの削除 | サイトからControllerを削除します | ** | db_owner |
| スキーマの更新 | スキーマの更新およびHotfixを適用します | db_owner |
* securityadminは、技術的にはより限定的なサーバーの役割ですが、実際にはsysadminのサーバーの役割と同等のものとして扱われます。
** Studioで、またはStudioかSDKで生成されたスクリプトを使用して、Controllerをサイトから削除すると、データベースサーバーへのControllerログオンは削除されません。これは、同じマシン上のほかのCitrix製品のサービスで使用されるログオンが削除されるのを防ぐためです。ログオンが不要になった場合は、手動で削除する必要があります。この操作には、securityadminのサーバーの役割メンバーシップが必要です。
Studioを使用してこれらの操作を実行する場合、Studioユーザーは、適切なサーバーロールのメンバーとして明示的にデータベースサーバーアカウントを持っているか、またはアカウントの資格情報を提供できることが必要です。
優先データベース権限スクリプト
エンタープライズ環境では、データベースのセットアップに、役割（権限）が異なる（securityadminまたはdb_owner）チームが処理する必要があるスクリプトが含まれます。
PowerShellを使用して、優先データベース権限を指定することができます。デフォルト以外の値を指定すると、個別のスクリプトが作成されます。1つのスクリプトには、securityadminの役割が必要なタスクが含まれています。もう1つのスクリプトは、db_ownerの権限のみが必要で、データベース管理者に連絡することなくCitrix管理者が実行できます。
get-*DBSchemaコマンドレットの-DatabaseRightsオプションで有効な値は以下のとおりです：
-
SA: データベースとDelivery Controllerのログインを作成するスクリプトを生成します。これらのタスクにはsecurityadminの権限が必要です。 -
DBO: データベースでユーザー役割を作成し、ログインを追加してから、データベーススキーマを作成するスクリプトを生成します。これらのタスクにはdb_ownerの権限が必要です。 -
Mixed: （デフォルト）必要な権限にかかわらず、1つのスクリプトにすべてのタスクを含めます。
詳しくは、コマンドレットのヘルプを参照してください。
データベースのアドレス形式
データベースのアドレスは、以下の形式のいずれかで指定できます。
ServerNameServerName\InstanceNameServerName,PortNumber
AlwaysOn可用性グループ機能では、場所フィールドにグループのリスナーを指定します。
データベースの場所の変更
構成ログや監視データベースの場所は、サイトの作成後に変更できます。（サイトデータベースの場所を変更することはできません。）データベースの場所を変更する場合は、以下の点に注意してください：
- 変更前のデータベース内のデータは変更後のデータベースにインポートされません。
- 構成ログデータベースの場所を変更する場合、変更前のデータベースの内容は集約されなくなります。
- 変更後のデータベースの最初にデータベースの変更を示すログが記録されますが、変更前のデータベースの場所は記録されません。
データベースが切断されているときの構成変更が禁止された環境（必須ログ機能）では、構成ログの場所を変更することはできません。
データベースの場所を変更する場合は、次の手順に従います。
- データベースを常駐させるサーバーに、サポートされているバージョンのMicrosoft SQL Serverがインストールされていることを確認します。必要に応じて、高可用性機能をセットアップします。
- Studioのナビゲーションペインで［構成］を選択します。
- 場所を変更するデータベースを選択して、［操作］ ペインの ［データベースの変更］ を選択します。
- 変更後の場所とデータベース名を指定します。
- 必要な権限を持っているのでデータベースをStudioで作成するという場合は、［OK］をクリックします。確認のメッセージが表示され、［OK］をクリックするとStudioによりデータベースが自動的に作成されます。Studioユーザーの資格情報を使ってデータベースへのアクセスが試行されます。それが失敗すると、データベースユーザーの資格情報の入力を求められます。アクセスに成功すると、Studioによりデータベーススキーマがデータベースにアップロードされます（資格情報はデータベース作成時のみ保持されます）。
- Studioにデータベースを作成させない場合、または必要な権限がない場合は、［スクリプトを作成］をクリックします。作成されるスクリプトには、データベースおよびミラーデータベース（構成する場合）を手動で作成するためのコマンドが記述されます。スキーマをアップロードする前に、データベースが空であること、および1人以上のユーザーがそのデータベースにアクセスでき、変更できることを確認してください。
追加情報
- データベースのサイズ評価ツール
- 「サイト構成データベースのサイズ変更」および「接続文字列の構成」（SQL Serverの高可用性のためのソリューションを使用する場合）