XenApp und XenDesktop 7.7: Zones Deep Dive
Dieser Artikel beschreibt die Funktionsweise der Zonenfunktion in XenApp und XenDesktop 7.7 sowie die Auswirkungen der Platzierung von Elementen wie Delivery Controllern, Hypervisorverbindungen und Maschinenkatalogen in verschiedene Zonen. Es kann nützlich sein, zuerst über Zonen in der Citrix Produktdokumentation zu lesen: https://docs.citrix.com/de-de/legacy-archive/xenapp-and-xendesktop.html.
Primär- und Satellitenzonen
Jede XenApp- und XenDesktop 7.7-Site verfügt über eine primäre Zone, die die zentrale Standortdatenbank und mindestens zwei Delivery Controller enthalten sollte.
Sekundäre oder Satellitenzonen sollten mindestens eine VDAs, Controller, StoreFront-Server und NetScaler Gateway-Server enthalten. Bei normalem Betrieb kommunizieren Controller in einer Satellitenzone direkt mit der zentralen Standortdatenbank in der primären Zone.
Controller in der primären Zone werden davon ausgegangen, dass sie über eine gute Verbindung zur Standortdatenbank verfügen und über eine gewisse Konnektivität zu allen Satellitenzonen verfügen. Es wird jedoch nicht davon ausgegangen, dass Elemente in jeder Satellitenzone Konnektivität zu Elementen in anderen Satellitenzonen haben.
Elemente, die Zonen zugeordnet werden können
Eine Reihe verschiedener Elemente in einer XenApp- oder XenDesktop-Bereitstellung können einer Satellitenzone zugeordnet werden, was sich dann auf die Interaktion der Site mit diesen Objekten und anderen damit verbundenen Objekten auswirkt. Die Elemente, die in Satellitenzonen platziert werden können, sind:
- Controller-Maschinen
- Hypervisor-Verbindungen
- Maschinenkataloge
- NetScaler Gateways
Wenn Controller-Maschinen in einer Satellitenzone platziert werden, wird dann davon ausgegangen, dass diese Computer über eine gute (lokale) Konnektivität zu Hypervisoren und VDA-Maschinen in derselben Satellitenzone verfügen. Daher ordnet das System Dinge an, die es vorziehen, diese Controller für die Handhabung dieser Hypervisoren und VDA-Maschinen zu verwenden.
Die Hypervisorverbindung, die in einer Satellitenzone platziert wird, impliziert, dass sich alle über diese Hypervisorverbindung verwalteten Hypervisoren ebenfalls in dieser Satellitenzone befinden, und Controller in dieser Zone werden bevorzugt bei der Kommunikation mit dieser Hypervisorverbindung verwendet.
Ein Maschinenkatalog, der in eine Satellitenzone platziert wird, bedeutet ähnlich, dass sich alle VDA-Maschinen in diesem Katalog in der Satellitenzone befinden, und dies steuert auch, welche Controller beim Versuch verwendet werden, sich bei der Site zu registrieren, nachdem der automatische Aktualisierungsmechanismus der Controller-Liste aktiviert wurde nach der ersten Registrierung jedes VDA.
VDAs werden es vorziehen, sich bei Controllern in derselben lokalen Zone wie sie selbst zu registrieren, aber ein Failover für die Registrierung bei Controllern in der primären Zone. VDAs werden nicht bei Controllern in anderen Satellitenzonen registriert.
NetScaler Gateway-Instanzen können auch Zonen zugeordnet werden, dies geschieht jedoch im Rahmen der StoreFront Optimal HDX-Routingkonfiguration und nicht wie bei den anderen hier beschriebenen Elementen im Rahmen der XenApp- oder XenDesktop-Site-Konfiguration. Wenn ein NetScaler Gateway einer Zone zugeordnet ist, bedeutet dies, dass es bevorzugt verwendet wird, wenn HDX-Verbindungen zu VDA-Maschinen in dieser Zone verwendet werden.
Grenzwerte für die Verbindungsqualität
Die Controller in der Satellitenzone führen SQL-Interaktionen direkt mit der Site-Datenbank aus. Obwohl einige Änderungen vorgenommen wurden, um diese SQL-Interaktion zu minimieren, setzt dies einige Einschränkungen für die Qualität der Verbindung zwischen der Satellitenzone und der primären Zone, die die Datenbank enthält. Die spezifischen Grenzwerte beziehen sich wiederum auf die Anzahl der VDAs und Benutzersitzungen auf den VDAs, die in der Satellitenzone bereitgestellt werden. So können Satellitenzonen mit nur einer geringen Anzahl von VDAs und Sitzungen mit einer minderwertigen Verbindung zur Datenbank funktionieren als Satellitenzonen mit einer großen Anzahl von VDAs und Sitzungen. Einige Richtlinien sind:
Anzahl der zu unterstützenden Sitzungen | Angenommene maximale Anzahl gleichzeitiger Endbenutzersitzungen | Minimale akzeptable Bandbreite | Maximale akzeptable Round-Trip-Latenz |
---|---|---|---|
Weniger als 50 | 20 | 1 Mbit/s | 250 ms |
50 bis 500 | 25 | 1,5 Mbit/s | 100 ms |
500 bis 1.000 | 30 | 2 Mbit/s | 50 ms |
1.000 bis 3.000 | 60 | 8 Mbit/s | 10 ms |
Über 3.000 | 60 | 8 Mbit/s | 5 ms |
Hohe Verfügbarkeit mit Verbindungsleasing
In XenApp und XenDesktop 7.7 kann die Verbindungsleasing-Funktion dazu beitragen, die hohe Verfügbarkeit der Vermittlung neuer Verbindungen an Endbenutzer bei einem Systemausfall aufrechtzuerhalten. Wenn Sie Zonen verwenden, kann der Ausfall durch einen Kommunikationsverlust zwischen einer Satellitenzone und der primären Zone verursacht werden (insbesondere weil sich die Datenbank in der primären Zone befindet). In diesem Fall schalten die Controller der Satellitenzone in den Leasing-Modus um und ermöglichen es Endbenutzern weiterhin, neue Verbindungen zu Anwendungen und Desktops zu verlinken. Die VDAs, auf denen diese Sitzungen ausgeführt werden, müssen jedoch von den Controllern in der Satellitenzone aus zugegriffen werden. Um die Dateisystemlast für Controller-Maschinen in Satellitenzonen zu begrenzen, müssen nur Verbindungs-Lease-Daten für VDA-Maschinen in derselben Zone verwendet werden.
StoreFront-Bereitstellung
Wenn Sie die hohe Verfügbarkeit von Brokering mit Connection Leasing nutzen möchten, müssen Sie eine StoreFront-Instanz in jeder Satellitenzone bereitstellen, wenn eine Satellitenzone von der primären Zone isoliert ist. Dies liegt daran, dass eine zentral bereitgestellte StoreFront-Instanz allein in der primären Zone nicht notwendigerweise in der Lage wäre, die Controller in den Satellitenzonen zu kontaktieren, wenn die Verbindung zwischen der primären und der Satellitenzone bei einem Ausfall unterbrochen wird.
Anzahl der Zonen
Die Anzahl der in der Site konfigurierten Controller kann sich auf die Leistung einiger Vorgänge auswirken, z. B. das Hinzufügen neuer Controller zur Site selbst. Um dies zu vermeiden, wird empfohlen, die Anzahl der Zonen in Ihrer XenApp- oder XenDesktop 7.7-Site auf maximal 10 zu beschränken. In XenApp oder XenDesktop 7.11 und höheren Versionen beträgt der Grenzwert 50.
Low-Level-Konfigurationseinstellungen und -optimierungen
Einige neue Konfigurationselemente wurden zu Support-Zonen hinzugefügt, darunter das Hinzufügen der Definition von Zonen auf der PowerShell-SDK-Ebene, die Teil des Konfigurationsdienst-SDK ist, anstatt beispielsweise Teil des Brokerdienst-SDK zu sein. Andere Teile der Zonenkonfiguration können in anderen PowerShell-SDKs des FMA-Dienstes durchgeführt werden, insbesondere wenn Elemente mit Zonen verknüpft sind. Dies geschieht durch den Dienst, der den größten Eigentümer dieser Objekte hat. Folglich wird die Zonenmitgliedschaft von Maschinenkatalogen mit dem Brokerdienst SDK definiert, und die Zonenmitgliedschaft von Hypervisorverbindungen wird mit dem Host Service SDK konfiguriert.
Darüber hinaus wurde eine neue Registrierungseinstellung hinzugefügt, um die Steuerung einer Drosselung gleichzeitiger Endbenutzerstarts zu ermöglichen. Der Hauptteil davon ist unter HKLM\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions. In einigen Testsituationen haben wir festgestellt, dass hohe Latenzen zwischen Satellitenzonen und der Datenbank in der primären Zone, verbunden mit einer relativ hohen Rate von App- und Desktop-Verbindungen durch Endbenutzer, die einen Controller in der Satellitenzone verwenden, zu verzögerten Starts führen könnten, da frühere Starts zurückgeblieben sind.
Weitere Tipps
Es gab einige Berichte, dass der Zonenknoten in Studio nach dem Upgrade einer Site verschwunden ist. Dies kann darauf zurückzuführen sein, dass die Datei “Rollenkonfiguration” während des Upgrades nicht importiert werden konnte. Sie können dies manuell beheben, indem Sie die Datei über das PowerShell-SDK importieren:
cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig'
Import-AdminRoleConfiguration — Pfad. RoleConfigSigned.xml
Dieser Artikel wurde aus einem Blogbeitrag von William Charnell adaptiert. Um den ursprünglichen Blog zu lesen und die Kommentare zu sehen, gehen Sie zu https://www.citrix.com/blogs/2016/01/12/deep-dive-xenapp-and-xendesktop-7-7-zones/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CitrixBlogs+%28Citrix+Blogs%29.