XenApp and XenDesktop

Verbindungsleasing

Wichtig:

Der Local Host Cache (LHC) ist die bevorzugte Hochverfügbarkeitslösung für XenApp und XenDesktop anstelle des Verbindungsleasings. Weitere Informationen finden Sie unter Local Host Cache.

  • In dieser Version ist das Verbindungsleasing bei einer Neuinstallation von XenApp und XenDesktop® standardmäßig deaktiviert.
  • Das Verbindungsleasing wird ab dem Current Release, das auf dieses XenApp und XenDesktop 7.15 Long Term Service Release folgt, nicht mehr bereitgestellt.

Um sicherzustellen, dass die Sitedatenbank immer verfügbar ist, empfiehlt Citrix®, mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen, indem die Best Practices für Hochverfügbarkeit von Microsoft befolgt werden. Netzwerkprobleme und -unterbrechungen können jedoch verhindern, dass Delivery Controller auf die Datenbank zugreifen, was dazu führt, dass Benutzer keine Verbindung zu ihren Anwendungen oder Desktops herstellen können.

Die Verbindungsleasing-Funktion ergänzt die Best Practices für die Hochverfügbarkeit von SQL Server, indem sie Benutzern ermöglicht, sich mit ihren zuletzt verwendeten Anwendungen und Desktops zu verbinden und wieder zu verbinden, selbst wenn die Sitedatenbank nicht verfügbar ist.

Obwohl Benutzern eine große Anzahl veröffentlichter Ressourcen zur Verfügung stehen kann, nutzen sie oft nur wenige davon regelmäßig. Wenn Sie das Verbindungsleasing aktivieren, speichert jeder Controller Benutzerverbindungen zu diesen kürzlich verwendeten Anwendungen und Desktops während des normalen Betriebs (wenn die Datenbank verfügbar ist) im Cache.

Die auf jedem Controller generierten Leases werden zur regelmäßigen Synchronisierung mit anderen Controllern auf der Site in die Sitedatenbank hochgeladen. Zusätzlich zu den Leases enthält der Cache jedes Controllers Anwendungs-, Desktop-, Symbol- und Workerinformationen. Das Lease und die zugehörigen Informationen werden auf der lokalen Festplatte jedes Controllers gespeichert. Wenn die Datenbank nicht verfügbar ist, wechselt der Controller in den geleasten Verbindungsmodus und „spielt“ die zwischengespeicherten Vorgänge ab, wenn ein Benutzer versucht, sich von StoreFront mit einer kürzlich verwendeten Anwendung oder einem Desktop zu verbinden oder wieder zu verbinden.

Verbindungen werden für einen Leasingzeitraum von zwei Wochen zwischengespeichert. Wenn die Datenbank also nicht verfügbar ist, bleiben die Desktops und Anwendungen, die der Benutzer in den letzten zwei Wochen gestartet hat, diesem Benutzer über StoreFront zugänglich. Desktops und Anwendungen, die während des vorherigen zweiwöchigen Leasingzeitraums nicht gestartet wurden, sind jedoch nicht zugänglich, wenn die Datenbank nicht verfügbar ist. Wenn ein Benutzer beispielsweise eine Anwendung zuletzt vor drei Wochen gestartet hat, ist sein Lease abgelaufen, und dieser Benutzer kann diese Anwendung nicht starten, wenn die Datenbank jetzt nicht verfügbar ist. Leases für lang laufende aktive oder getrennte Anwendungs- oder Desktopsitzungen werden verlängert, damit sie nicht als abgelaufen gelten.

Standardmäßig betrifft das Verbindungsleasing die gesamte Site; Sie können jedoch alle Leases für bestimmte Benutzer widerrufen, wodurch diese daran gehindert werden, auf Anwendungen oder Desktops zuzugreifen, wenn der Controller sich im geleasten Verbindungsmodus befindet. Mehrere andere Registrierungseinstellungen gelten Controller-basiert.

Überlegungen und Einschränkungen

Obwohl das Verbindungsleasing die Verbindungsresilienz und Benutzerproduktivität verbessern kann, gibt es Überlegungen bezüglich der Verfügbarkeit, des Betriebs und der Leistung anderer Funktionen.

Das Verbindungsleasing wird für servergehostete Anwendungen und Desktops sowie für statische (zugewiesene) Desktops unterstützt; es wird nicht für gepoolte VDI-Desktops oder für Benutzer unterstützt, denen kein Desktop zugewiesen wurde, wenn die Datenbank nicht verfügbar ist.

Wenn sich der Controller im geleasten Verbindungsmodus befindet:

  • Administratoren können Studio, Director oder die PowerShell-Konsole nicht verwenden.

  • Workspace Control ist nicht verfügbar. Wenn sich ein Benutzer bei Citrix Receiver™ anmeldet, werden Sitzungen nicht automatisch wiederhergestellt; der Benutzer muss die Anwendung neu starten.

  • Wird ein neuer Lease unmittelbar vor dem Ausfall der Datenbank erstellt, die Lease-Informationen aber noch nicht über alle Controller synchronisiert, kann der Benutzer die Ressource nach dem Ausfall der Datenbank möglicherweise nicht starten.

  • Benutzer von servergehosteten Anwendungen und Desktops können mehr Sitzungen verwenden, als ihre konfigurierten Sitzungslimits zulassen. Zum Beispiel:

    • Eine Sitzung wird möglicherweise nicht übertragen, wenn ein Benutzer sie von einem Gerät aus startet (externe Verbindung über NetScaler® Gateway), während der Controller sich nicht im Leased-Connection-Modus befindet, und sich dann von einem anderen Gerät im LAN verbindet, während der Controller sich im Leased-Connection-Modus befindet.
    • Die Sitzungswiederherstellung kann fehlschlagen, wenn eine Anwendung gestartet wird, kurz bevor die Datenbank nicht mehr verfügbar ist; in solchen Fällen werden eine neue Sitzung und Anwendungsinstanz gestartet.
  • Statische (zugewiesene) Desktops werden nicht energieverwaltet. VDAs, die ausgeschaltet sind, wenn der Controller in den Leased-Connection-Modus wechselt, bleiben nicht verfügbar, bis die Datenbankverbindung wiederhergestellt ist, es sei denn, der Administrator schaltet sie manuell ein.

  • Wenn Sitzungsvorabstart und Sitzungsverweildauer aktiviert sind, werden keine neuen Vorabstartsitzungen gestartet. Vorabgestartete und verweilende Sitzungen werden nicht gemäß den konfigurierten Schwellenwerten beendet, während die Datenbank nicht verfügbar ist.

  • Die Lastverwaltung innerhalb der Site kann beeinträchtigt werden. Serverbasierte Verbindungen werden an den zuletzt verwendeten VDA weitergeleitet. Lastausgleicher (und insbesondere Sitzungsanzahlregeln) können überschritten werden.

  • Der Controller wechselt nicht in den Leased-Connection-Modus, wenn Sie SQL Server Management Studio verwenden, um die Datenbank offline zu schalten. Verwenden Sie stattdessen eine der folgenden Transact-SQL-Anweisungen:

    • ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK IMMEDIATE
    • ÄNDERN DATENBANK <database-name> SETZEN OFFLINE MIT ROLLBACK NACH <seconds>

    Jede Anweisung bricht ausstehende Transaktionen ab und führt dazu, dass der Controller seine Verbindung zur Datenbank verliert. Der Controller wechselt dann in den Leased-Connection-Modus.

Wenn Connection Leasing aktiviert ist, gibt es zwei kurze Intervalle, in denen Benutzer keine Verbindung herstellen oder wiederherstellen können: (1) von dem Zeitpunkt, an dem die Datenbank nicht mehr verfügbar ist, bis der Controller in den Leased-Connection-Modus wechselt, und (2) von dem Zeitpunkt, an dem der Controller vom Leased-Connection-Modus wechselt, bis der Datenbankzugriff vollständig wiederhergestellt und die VDAs neu registriert wurden.

Wenn Sie einen nicht standardmäßigen Wert für das Sitzungsroaming konfigurieren, wird die Sitzungswiederherstellung auf ihren Standardwert zurückgesetzt, wenn ein Controller in den Leased-Connection-Modus wechselt. Weitere Informationen finden Sie unter Connection Leasing und Sitzungsroaming.

Siehe den Artikel Zonen für Informationen darüber, wo die Daten des Verbindungslasings gespeichert werden.

Konfigurieren und Bereitstellen

Beim Konfigurieren Ihrer Bereitstellung für das Verbindungslasing:

  • VDAs müssen mindestens Version 7.6 haben, und die Maschinenkataloge und Bereitstellungsgruppen, die diese Maschinen verwenden, müssen auf dieser Mindestversion (oder einer späteren unterstützten Version) sein.
  • Die Größenanforderungen für die Sitedatenbank werden steigen.
  • Jeder Controller benötigt zusätzlichen Speicherplatz für die zwischengespeicherten Leasingdateien.

Sie können das Verbindungslasing über das PowerShell SDK oder die Windows-Registrierung deaktivieren oder aktivieren. Über das PowerShell SDK können Sie auch aktuelle Leases entfernen. Die folgenden PowerShell-Cmdlets beeinflussen das Verbindungslasing; Details finden Sie in der Cmdlet-Hilfe.

  • Set-BrokerSite -ConnectionLeasingEnabled $true|$false – Aktiviert oder deaktiviert das Verbindungslasing. Standard = $true
  • Get-BrokerServiceAddedCapability – Gibt „ConnectionLeasing“ für den lokalen Controller aus.
  • Get-BrokerLease – Ruft entweder alle oder eine gefilterte Menge aktueller Leases ab.
  • Remove-BrokerLease – Markiert entweder eine oder eine gefilterte Menge von Leases zur Löschung.
  • Update-BrokerLocalLeaseCache – Aktualisiert den Verbindungslasing-Cache auf dem lokalen Controller. Die Daten werden bei der nächsten Synchronisierung erneut synchronisiert.
Verbindungsleasing