Citrix Virtual Apps and Desktops 7 2203 LTSR

Datenbanken

Eine Citrix Virtual Apps- oder Citrix Virtual Desktops™-Site verwendet drei SQL Server-Datenbanken:

  • Site: (auch als Sitekonfiguration bezeichnet) speichert die laufende Sitekonfiguration sowie den aktuellen Sitzungsstatus und Verbindungsinformationen.
  • Konfigurationsprotokollierung: (auch als Protokollierung bezeichnet) speichert Informationen zu Änderungen der Sitekonfiguration und administrativen Aktivitäten. Diese Datenbank wird verwendet, wenn die Funktion zur Konfigurationsprotokollierung aktiviert ist (Standard = aktiviert).
  • Überwachung: speichert von Director verwendete Daten, wie z. B. Sitzungs- und Verbindungsinformationen.

Jeder Delivery Controller kommuniziert mit der Sitedatenbank. Zwischen dem Controller und den Datenbanken ist eine Windows-Authentifizierung erforderlich. Ein Controller kann abgezogen oder ausgeschaltet werden, ohne andere Controller in der Site zu beeinträchtigen. Dies bedeutet jedoch, dass die Sitedatenbank einen Single Point of Failure darstellt. Wenn der Datenbankserver ausfällt, funktionieren bestehende Verbindungen weiterhin, bis ein Benutzer sich abmeldet oder die Verbindung trennt. Informationen zum Verbindungsverhalten, wenn die Sitedatenbank nicht verfügbar ist, finden Sie unter Local Host Cache.

Citrix empfiehlt, die Datenbanken regelmäßig zu sichern, damit Sie bei einem Ausfall des Datenbankservers aus der Sicherung wiederherstellen können. Die Sicherungsstrategie für jede Datenbank kann unterschiedlich sein. Anweisungen finden Sie unter CTX135207.

Wenn Ihre Site mehr als eine Zone enthält, stellen Sie sicher, dass die primäre Zone immer die Sitedatenbank enthält. Controller in jeder Zone kommunizieren mit dieser Datenbank.

Hochverfügbarkeit

Es gibt mehrere Hochverfügbarkeitslösungen, die für die Gewährleistung eines automatischen Failovers in Betracht gezogen werden sollten:

  • AlwaysOn-Verfügbarkeitsgruppen (einschließlich Basic Availability Groups): Diese in SQL Server 2012 eingeführte Hochverfügbarkeits- und Notfallwiederherstellungslösung auf Unternehmensebene ermöglicht es Ihnen, die Verfügbarkeit für eine oder mehrere Datenbanken zu maximieren. AlwaysOn-Verfügbarkeitsgruppen erfordern, dass die SQL Server-Instanzen auf Windows Server Failover Clustering (WSFC)-Knoten residieren. Weitere Informationen finden Sie unter Windows Server Failover Clustering with SQL Server.
  • SQL Server-Datenbankspiegelung: Die Spiegelung der Datenbank stellt sicher, dass bei Verlust des aktiven Datenbankservers ein automatischer Failover-Prozess innerhalb von Sekunden erfolgt, sodass Benutzer im Allgemeinen nicht betroffen sind. Diese Methode ist teurer als andere Lösungen, da auf jedem Datenbankserver vollständige SQL Server-Lizenzen erforderlich sind. Sie können die SQL Server Express Edition nicht in einer gespiegelten Umgebung verwenden.
  • SQL-Clustering: Die Microsoft SQL-Clustering-Technologie kann verwendet werden, um automatisch zu ermöglichen, dass ein Server die Aufgaben und Verantwortlichkeiten eines anderen ausgefallenen Servers übernimmt. Die Einrichtung dieser Lösung ist jedoch komplizierter, und der automatische Failover-Prozess ist typischerweise langsamer als Alternativen wie die SQL-Spiegelung.
  • Verwendung der Hochverfügbarkeitsfunktionen des Hypervisors: Bei dieser Methode stellen Sie die Datenbank als virtuelle Maschine bereit und nutzen die Hochverfügbarkeitsfunktionen Ihres Hypervisors. Diese Lösung ist kostengünstiger als die Spiegelung, da sie Ihre vorhandene Hypervisor-Software verwendet und Sie auch die SQL Server Express Edition nutzen können. Der automatische Failover-Prozess ist jedoch langsamer, da es einige Zeit dauern kann, bis eine neue Maschine für die Datenbank gestartet wird, was den Dienst für die Benutzer unterbrechen könnte.

Die Local Host Cache-Funktion ergänzt die Best Practices für die SQL Server-Hochverfügbarkeit. Local Host Cache ermöglicht Benutzern die Verbindung und Wiederverbindung mit Anwendungen und Desktops, selbst wenn die Sitedatenbank nicht verfügbar ist. Weitere Informationen finden Sie unter Local Host Cache.

Wenn alle Controller in einer Site ausfallen, können Sie die VDAs so konfigurieren, dass sie im Hochverfügbarkeitsmodus arbeiten. Dadurch können Benutzer weiterhin auf ihre Desktops und Anwendungen zugreifen. Im Hochverfügbarkeitsmodus akzeptiert der VDA direkte ICA-Verbindungen von Benutzern, anstatt Verbindungen, die vom Controller vermittelt werden. Verwenden Sie diese Funktion nur in dem seltenen Fall, dass die Kommunikation mit allen Controllern fehlschlägt. Die Funktion ist keine Alternative zu anderen Hochverfügbarkeitslösungen. Weitere Informationen finden Sie unter CTX 127564.

Die Installation eines Controllers auf einem Knoten in einer SQL-Clustering- oder SQL-Mirroring-Installation wird nicht unterstützt.

Datenbanksoftware installieren

Standardmäßig wird die SQL Server Express Edition installiert, wenn Sie den ersten Delivery Controller™ installieren und keine andere SQL Server-Instanz auf diesem Server erkannt wird. Diese Standardaktion ist in der Regel für Machbarkeitsstudien oder Pilotbereitstellungen ausreichend. SQL Server Express unterstützt jedoch keine Microsoft-Hochverfügbarkeitsfunktionen.

Die Standardinstallation verwendet die standardmäßigen Windows-Dienstkonten und -Berechtigungen. Details zu diesen Standardeinstellungen, einschließlich der Hinzufügung von Windows-Dienstkonten zur Sysadmin-Rolle, finden Sie in der Microsoft-Dokumentation. Der Controller verwendet in dieser Konfiguration das Netzwerkdienstkonto. Der Controller benötigt keine zusätzlichen SQL Server-Rollen oder -Berechtigungen.

Bei Bedarf können Sie für die Datenbankinstanz die Option Instanz ausblenden auswählen. Geben Sie beim Konfigurieren der Datenbankadresse in Studio die statische Portnummer der Instanz anstelle ihres Namens ein. Details zum Ausblenden einer Instanz der SQL Server-Datenbank-Engine finden Sie in der Microsoft-Dokumentation.

Für die meisten Produktionsbereitstellungen und alle Bereitstellungen, die Microsoft-Hochverfügbarkeitsfunktionen verwenden, empfehlen wir die Verwendung ausschließlich unterstützter Nicht-Express-Editionen von SQL Server. Installieren Sie SQL Server auf anderen Maschinen als dem Server, auf dem der erste Controller installiert ist. Systemanforderungen listet die unterstützten SQL Server-Versionen auf. Die Datenbanken können sich auf einer oder mehreren Maschinen befinden.

Stellen Sie sicher, dass die SQL Server-Software installiert ist, bevor Sie eine Site erstellen. Sie müssen die Datenbank nicht erstellen, aber wenn Sie dies tun, muss sie leer sein. Die Konfiguration von Microsoft-Hochverfügbarkeitstechnologien wird ebenfalls empfohlen.

Verwenden Sie Windows Update, um SQL Server auf dem neuesten Stand zu halten.

Datenbanken über den Siteerstellungs-Assistenten einrichten

Geben Sie die Datenbanknamen und -adressen (Speicherort) auf der Seite Datenbanken im Siteerstellungs-Assistenten an. (Siehe Datenbankadressformate.) Um potenzielle Fehler zu vermeiden, wenn Director den Monitor Service abfragt, verwenden Sie keine Leerzeichen im Namen der Überwachungsdatenbank.

Die Seite Datenbanken bietet zwei Optionen zum Einrichten der Datenbanken: automatisch und mithilfe von Skripts. Im Allgemeinen können Sie die automatische Option verwenden, wenn Sie (der Studio-Benutzer und Citrix®-Administrator) über die erforderlichen Datenbankberechtigungen verfügen. (Siehe Erforderliche Berechtigungen zum Einrichten von Datenbanken.)

Sie können den Speicherort der Konfigurationsprotokollierungs- und Überwachungsdatenbank später ändern, nachdem Sie die Site erstellt haben. Siehe Datenbankstandorte ändern.

Um eine Site für die Verwendung einer Spiegeldatenbank zu konfigurieren, führen Sie die folgenden Schritte aus und fahren Sie dann mit den automatischen oder skriptgesteuerten Einrichtungsprozeduren fort.

  1. Installieren Sie die SQL Server-Software auf zwei Servern, A und B.
  2. Erstellen Sie auf Server A die Datenbank, die als Prinzipal verwendet werden soll. Sichern Sie die Datenbank auf Server A und kopieren Sie sie dann auf Server B.
  3. Stellen Sie auf Server B die Sicherungsdatei wieder her.
  4. Starten Sie die Spiegelung auf Server A.

Um die Spiegelung nach dem Erstellen der Site zu überprüfen, führen Sie das PowerShell-Cmdlet get-configdbconnection aus, um sicherzustellen, dass der Failover-Partner in der Verbindungszeichenfolge auf den Spiegel gesetzt wurde.

Wenn Sie später einen Delivery Controller in einer gespiegelten Datenbankumgebung hinzufügen, verschieben oder entfernen, lesen Sie Delivery Controller.

Automatische Einrichtung

Wenn Sie über die erforderlichen Datenbankberechtigungen verfügen, wählen Sie auf der Seite Datenbanken des Siteerstellungs-Assistenten die Option Datenbanken über Studio erstellen und einrichten. Geben Sie dann die Namen und Adressen der Prinzipal-Datenbanken an.

Wenn eine Datenbank unter einer von Ihnen angegebenen Adresse vorhanden ist, muss sie leer sein. Wenn unter einer angegebenen Adresse keine Datenbanken vorhanden sind, werden Sie darüber informiert, dass keine Datenbank gefunden werden konnte, und dann gefragt, ob die Datenbank für Sie erstellt werden soll. Wenn Sie diese Aktion bestätigen, erstellt Studio die Datenbanken automatisch und wendet dann die Initialisierungsskripte für die Prinzipal- und Replikatdatenbanken an.

Skriptgesteuerte Einrichtung

Wenn Sie nicht über die erforderlichen Datenbankrechte verfügen, bitten Sie jemanden um Hilfe, der diese Rechte besitzt, z. B. einen Datenbankadministrator. Die Reihenfolge ist wie folgt:

  1. Wählen Sie auf der Seite Datenbanken im Siteerstellungs-Assistenten die Option Skripte zur manuellen Einrichtung generieren. Diese Aktion generiert die folgenden drei Skripttypen für jede der folgenden Prinzipal- und Replikatdatenbanken: Site-, Überwachungs- und Protokollierungsdatenbanken.

    • Skript mit „SysAdmin“ im Namen. Ein Skript, das die Datenbanken und das Delivery Controller-Login erstellt. Diese Aufgaben erfordern securityadmin-Rechte.
    • Skript mit „DbOwner“ im Namen. Ein Skript, das die Benutzerrollen in der Datenbank erstellt, die Logins hinzufügt und dann die Datenbankschemata erstellt. Diese Aufgaben erfordern db_owner-Rechte.
    • Skript mit „Mixed“ im Namen. Alle Aufgaben in einem Skript, unabhängig von den erforderlichen Rechten.

    Sie können angeben, wo die Skripte gespeichert werden sollen.

    Hinweis:

    In Unternehmensumgebungen umfasst die Datenbankeinrichtung Skripte, die möglicherweise von verschiedenen Teams mit unterschiedlichen Rollen (Rechten) gehandhabt werden: securityadmin oder db_owner. Falls zutreffend, lassen Sie zuerst „SysAdmin“-Skripte von Administratoren mit der Rolle securityadmin ausführen und anschließend „DbOwner“-Skripte von Administratoren mit db_owner-Rechten. Um diese Skripte zu generieren, können Sie auch PowerShell verwenden. Weitere Informationen finden Sie unter Bevorzugte Datenbankrechtsskripte.

  2. Geben Sie diese Skripte Ihrem Datenbankadministrator. Der Assistent zur Siteerstellung wird an dieser Stelle automatisch angehalten. Sie werden aufgefordert, die Siteerstellung fortzusetzen, wenn Sie später zurückkehren.

Der Datenbankadministrator erstellt dann die Datenbanken. Jede Datenbank muss die folgenden Merkmale aufweisen:

  • Verwenden Sie eine Sortierung, die mit _CI_AS_KS endet. Wir empfehlen die Verwendung einer Sortierung, die mit _100_CI_AS_KS endet.
  • Für optimale Leistung aktivieren Sie den SQL Server Read-Committed Snapshot. Weitere Informationen finden Sie unter CTX 137161.
  • Konfigurierte Hochverfügbarkeitsfunktionen, falls zutreffend.
  • Um die Spiegelung zu konfigurieren, stellen Sie die Datenbank zuerst auf das vollständige Wiederherstellungsmodell ein (das einfache Modell ist die Standardeinstellung). Sichern Sie die primäre Datenbank in einer Datei und kopieren Sie sie auf den Spiegelserver. Stellen Sie dann die Sicherungsdatei auf dem Spiegelserver wieder her. Starten Sie schließlich die Spiegelung auf dem primären Server.

Der Datenbankadministrator verwendet das Befehlszeilendienstprogramm SQLCMD oder SQL Server Management Studio im SQLCMD-Modus, um:

  • Jedes der xxx_Replica.sql-Skripte auf den Hochverfügbarkeits-SQL Server-Datenbankinstanzen auszuführen (falls Hochverfügbarkeit konfiguriert ist)
  • Jedes der xxx\_Principal.sql-Skripte auf den primären SQL Server-Datenbankinstanzen auszuführen.

Details zu SQLCMD finden Sie in der Microsoft-Dokumentation.

Wenn alle Skripte erfolgreich abgeschlossen wurden, übergibt der Datenbankadministrator dem Citrix-Administrator die drei primären Datenbankadressen.

Studio fordert Sie auf, die Siteerstellung fortzusetzen. Sie kehren zur Seite Databases zurück. Geben Sie die Adressen ein. Wenn einer der Server, auf dem eine Datenbank gehostet wird, nicht kontaktiert werden kann, wird eine Fehlermeldung angezeigt.

Erforderliche Berechtigungen zum Einrichten von Datenbanken

Sie müssen ein lokaler Administrator und ein Domänenbenutzer sein, um die Datenbanken zu erstellen und zu initialisieren (oder den Datenbankspeicherort zu ändern). Sie müssen auch bestimmte SQL Server-Berechtigungen besitzen. Die folgenden Berechtigungen können explizit konfiguriert oder durch die Mitgliedschaft in einer Active Directory-Gruppe erworben werden. Wenn Ihre Studio-Benutzeranmeldeinformationen diese Berechtigungen nicht enthalten, werden Sie zur Eingabe von SQL Server-Benutzeranmeldeinformationen aufgefordert.

Vorgang Zweck Serverrolle Datenbankrolle
Datenbank erstellen Eine geeignete leere Datenbank erstellen dbcreator  
Schema erstellen Alle dienstspezifischen Schemas erstellen und den ersten Controller zur Site hinzufügen securityadmin* db_owner
Controller hinzufügen Einen Controller (außer dem ersten) zur Site hinzufügen securityadmin* db_owner
Controller hinzufügen (Spiegelserver) Controller-Anmeldung zum Datenbankserver hinzufügen, der sich derzeit in der Spiegelrolle einer gespiegelten Datenbank befindet securityadmin*  
Controller entfernen Controller von der Site entfernen ** db_owner
Schema aktualisieren Schema-Updates oder Hotfixes anwenden   db_owner

* Obwohl technisch restriktiver, können Sie in der Praxis die securityadmin Serverrolle als gleichwertig zur sysadmin Serverrolle betrachten.

** Wenn ein Controller von einer Site entfernt wird, entweder über Studio oder mithilfe von Skripten, die von Studio oder dem SDK generiert wurden, wird die Controller-Anmeldung am Datenbankserver nicht entfernt. Dies soll verhindern, dass eine Anmeldung entfernt wird, die von anderen Diensten als diesem Citrix-Produkt auf derselben Maschine verwendet wird. Die Anmeldung muss manuell entfernt werden, wenn sie nicht mehr benötigt wird. Diese Aktion erfordert die Mitgliedschaft in der securityadmin Serverrolle.

Wenn Sie Studio verwenden, um diese Vorgänge auszuführen, muss der Studio-Benutzer entweder über ein Datenbankserverkonto verfügen, das explizit Mitglied der entsprechenden Serverrollen ist, oder die Anmeldeinformationen eines solchen Kontos bereitstellen können.

Bevorzugte Datenbankberechtigungsskripte

In Unternehmensumgebungen umfasst die Datenbankeinrichtung Skripte, die von verschiedenen Teams mit unterschiedlichen Rollen (Rechten) gehandhabt werden müssen: securityadmin oder db_owner.

Mit PowerShell können Sie die bevorzugten Datenbankrechte angeben. Die Angabe eines nicht standardmäßigen Werts führt zur Erstellung separater Skripte. Ein Skript enthält Aufgaben, die die Rolle securityadmin erfordern. Das andere Skript erfordert nur db_owner Rechte und kann von einem Citrix-Administrator ausgeführt werden, ohne einen Datenbankadministrator kontaktieren zu müssen.

In den get-*DBSchema-Cmdlets hat die Option -DatabaseRights die folgenden gültigen Werte:

  • SA: Generiert ein Skript, das die Datenbanken und das Delivery Controller-Login erstellt. Diese Aufgaben erfordern securityadmin Rechte.
  • DBO: Generiert ein Skript, das die Benutzerrollen in der Datenbank erstellt, die Logins hinzufügt und dann die Datenbankschemata erstellt. Diese Aufgaben erfordern db_owner Rechte.
  • Mixed: (Standard) Alle Aufgaben in einem Skript, unabhängig von den erforderlichen Rechten.

Weitere Informationen finden Sie in der Cmdlet-Hilfe.

Datenbankadressformate

Sie können eine Datenbankadresse in einem der folgenden Formate angeben:

  • ServerName
  • ServerName\InstanceName
  • ServerName,PortNumber

Geben Sie für eine AlwaysOn-Verfügbarkeitsgruppe den Listener der Gruppe im Feld für den Speicherort an.

Datenbankstandorte ändern

Nachdem Sie eine Site erstellt haben, können Sie den Speicherort der Konfigurationsprotokollierungs- und Überwachungsdatenbanken ändern. (Sie können den Speicherort der Sitedatenbank nicht ändern.) Wenn Sie den Speicherort einer Datenbank ändern:

  • Die Daten in der vorherigen Datenbank werden nicht in die neue Datenbank importiert.
  • Protokolle können beim Abrufen von Protokollen nicht aus beiden Datenbanken aggregiert werden.
  • Der erste Protokolleintrag in der neuen Datenbank zeigt an, dass eine Datenbankänderung stattgefunden hat, identifiziert jedoch nicht die vorherige Datenbank.

Sie können den Speicherort der Konfigurationsprotokollierungsdatenbank nicht ändern, wenn die obligatorische Protokollierung aktiviert ist.

So ändern Sie den Speicherort einer Datenbank:

  1. Stellen Sie sicher, dass eine unterstützte Version von Microsoft SQL Server auf dem Server installiert ist, auf dem die Datenbank gespeichert werden soll. Richten Sie bei Bedarf Hochverfügbarkeitsfunktionen ein.
  2. Wählen Sie im Navigationsbereich von Studio die Option Konfiguration.
  3. Wählen Sie die Datenbank aus, für die Sie einen neuen Speicherort angeben möchten, und wählen Sie dann im Bereich Aktionen die Option Datenbank ändern.
  4. Geben Sie den neuen Speicherort und den Datenbanknamen an.
  5. Wenn Studio die Datenbank erstellen soll und Sie über die entsprechenden Berechtigungen verfügen, klicken Sie auf OK. Klicken Sie auf OK, wenn Sie dazu aufgefordert werden, und Studio erstellt die Datenbank dann automatisch. Studio versucht, mit Ihren Anmeldeinformationen auf die Datenbank zuzugreifen. Wenn dies fehlschlägt, werden Sie zur Eingabe der Anmeldeinformationen des Datenbankbenutzers aufgefordert. Studio lädt dann das Datenbankschema in die Datenbank hoch. Die Anmeldeinformationen werden nur für den Zeitraum der Datenbankerstellung gespeichert.
  6. Wenn Studio die Datenbank nicht erstellen soll oder Sie nicht über ausreichende Berechtigungen verfügen, klicken Sie auf Skript generieren. Die generierten Skripte enthalten Anweisungen zum manuellen Erstellen der Datenbank und gegebenenfalls einer Spiegeldatenbank. Stellen Sie vor dem Hochladen des Schemas sicher, dass die Datenbank leer ist und dass mindestens ein Benutzer die Berechtigung zum Zugriff auf und zum Ändern der Datenbank hat.

Weitere Informationen

Datenbanken