Entwickeln von StoreFront Aggregation für mehrere Standorte

Eine Kernfunktionalität von StoreFront ist die Möglichkeit, “allgemeine” Anwendungs- und Desktop-Ressourcen von mehreren Citrix Virtual Apps and Desktops (CVAD) -Sites zu aggregieren und zu deduplizieren. Diese Funktionalität wird allgemein als Multi-Site-Aggregation bezeichnet. Duplikate Anwendungen und Desktops werden basierend auf Übereinstimmung von den Eigenschaften Application Display Name und Application Category identifiziert. Diese Funktionalität ist in der Konsole ab Version 3.5 verfügbar und war zuvor eine Konfigurationsdateibearbeitung. Der Zweck der Aggregation mehrerer Standorte besteht darin, Citrix Administratoren die Möglichkeit zu geben, redundante CVAD-Standorte zu erstellen (aus Gründen der Skalierbarkeit oder des Fehlers), Benutzern jedoch ein einzelnes Anwendungs- oder Desktopsymbol anstelle von Duplikaten pro Site zu präsentieren (wie es ohne diese Funktion angezeigt würde). StoreFront steuert dann, wie Anwendungen und Desktopstarts auf die verschiedenen Sites verteilt werden, die diese Ressource unterstützen.

In diesem Artikel wird erläutert, wie diese Einstellungen in einer Unternehmensumgebung implementiert werden können und wie sie mit anderen verwandten Einstellungen wie Anwendungsschlüsselwörtern und Abonnements integriert werden, um weiter zu steuern, wie Benutzersitzungen weitergeleitet und Ressourcen präsentiert werden.

Übersicht

Die Konfiguration der Einstellungen für mehrere Sites erfolgt über den Assistenten “Delivery Controller verwalten” in der StoreFront-Konsole mit verschiedenen Konfigurationen in der Produktdokumentation. Wenn mehr als eine Site für den Store konfiguriert ist, wird die Schaltfläche Konfigurieren unter “Benutzerzuordnung und Multi-Site-Aggregationskonfiguration” aktiviert, wie im Folgenden dargestellt.

Konfigurationsoptionen

Nach der Auswahl wird ein Administrator aufgefordert, Benutzerzuordnungen und Ressourcenaggregation zu konfigurieren, wie im Folgenden dargestellt. Der Link “Benutzer zu Controllern zuordnen” fordert den Administrator auf, eine Benutzergruppe zu konfigurieren, auf die diese Einstellungen angewendet werden sollen. Auf dem Link “Aggregierte Ressourcen” werden die tatsächlichen Aggregationseinstellungen für mehrere Sites angegeben.

Benutzerzuordnung und Ressourcenaggregation

Die Aggregation für mehrere Standorte kann erst konfiguriert werden, wenn mindestens eine Benutzergruppe definiert wurde, auf die die Einstellungen angewendet werden sollen. Die integrierte Gruppe “Jeder” kann verwendet werden, wenn ein einzelner Satz von Aggregationseinstellungen auf alle Benutzer angewendet werden soll, die eine Verbindung zum Store herstellen. Sobald diese Einstellungen konfiguriert sind und ein Benutzer nicht Mitglied einer der hier angegebenen Gruppen ist, werden keine Anwendungen oder Desktops für diesen Benutzer aufgelistet. In den nächsten beiden Abschnitten werden die verfügbaren Konfigurationen im Detail beschrieben, beginnend mit den Optionen “Aggregierte Ressourcen”.

Aggregationsoptionen

Im Abschnitt Aggregierte Ressourcen werden einem Administrator alle Sites angezeigt, die aufgelistet und aufgefordert werden auszuwählen, welche überlappenden Ressourcen haben und aggregiert sind, wie im Folgenden dargestellt.

Einstellungen für Aggregatressourcen

Für die aggregierten Sites gibt es zwei weitere Konfigurationen, die steuern, wie Ressourcen aufgelistet werden und Sitzungen auf diesen Sites gestartet werden. Diese Einstellungen gelten für alle Sites, die für die Aggregation markiert sind:

  • Controller veröffentlichen identische Ressourcen: Diese Einstellung steuert die Aufzählung. Wenn zwei Sites als “identisch” markiert sind, platziert StoreFront die Farmen in denselben “äquivalenten Farmsatz”, was bedeutet, dass Enumerationsanforderungen auf den Sites Lastenausgleich (Round-Robin) haben, da angenommen wird, dass die Ressourcensets gleichwertig sind, was die Aufzählungszeit spart. Wenn die beiden Sites nicht als “identisch” gekennzeichnet sind, sendet StoreFront eine XML-Enumerationsanforderung an alle und dedupliziert die gängige Anwendung und die Desktops von den resultierenden Ressourcensätzen.
  • Lastausgleichsressourcen über Controller hinweg: Diese Einstellung steuert den Sitzungsstart. Startanfragen sind entweder Lastausgleich über die Sites hinweg oder werden in Failover-Reihenfolge verteilt, unabhängig davon, ob die Websites “identisch” sind oder nicht. Die Sitzungsfreigabe hat Vorrang vor einer Lastausgleichsentscheidung. Wenn ein Benutzer bereits über eine Sitzung in Standort B verfügt und eine andere Anwendung oder einen Desktop startet, wird diese Sitzung daher auch in Standort B gestartet (vorausgesetzt, dass die Anwendung oder der Desktop dort verfügbar ist).

Einige Anwendungsfälle, die nicht gut über die GUI behandelt werden, sind Kombinationen aus Lastenausgleich und Failover oder Kombinationen von identischen und nicht identischen Standorten. Wenn es beispielsweise zwei Produktionsstandorte gibt, die einen Lastausgleich haben müssen, und einen DR-Site, der nur verwendet wird, wenn beide Produktionsstandorte ausgefallen sind, kann die GUI nicht verwendet werden, und die web.config-Datei muss stattdessen manuell geändert werden (siehe das richtige Format für diese Datei). Citrix Dokumente

Design Takeaways

So fassen Sie den vorherigen Abschnitt zusammen:

  • Nur eine von einer Reihe von “identischen” Sites wird verwendet, um Anwendungen und Desktops aufzuzählen, wenn die Sites über StoreFront aggregiert werden
  • Sitzungsstarts können entweder Lastausgleich oder Failover über aggregierte Sites hinweg sein

Zuordnung der Benutzerfarm

Die Einstellungen “Benutzer zu Controllern zuordnen” werden im Allgemeinen als “User Farm-Mapping” bezeichnet, da sie verwendet werden, um zu steuern, für welche Websites eine bestimmte Gruppe von Benutzern aufzählen darf, ob diese Sites aggregiert sind oder nicht. Es gibt zwei primäre Anwendungsfälle für diese Funktionalität:

  1. Einschränken der Aufzählung: Selbst ohne Aggregation für mehrere Standorte bedeutet das Zuweisen einer Gruppe von Benutzern in StoreFront zu einer Teilmenge von Sites, dass StoreFront nur XML-Aufzählungsanforderungen an diese Sites sendet, wenn sich ein Benutzer aus dieser Gruppe authentifiziert. In einer globalen Bereitstellung kann sich diese Situation erheblich auf die Aufzählungszeit auswirken, da StoreFront daran gehindert wird, mit Sites zu kommunizieren, auf die ein bestimmter Benutzer ohnehin nicht zugreifen muss. Diese Einstellungen können beispielsweise verwendet werden, um US-Benutzer den in den USA ansässigen CVAD-Sites zuzuordnen, sodass StoreFront bei der Anmeldung dieser Benutzer keine anderen global verteilten Sites erreichen kann.
  2. Zuweisen von Aggregationseinstellungen: Wenn die Aggregation mit mehreren Sites konfiguriert ist, kann es wünschenswert sein, verschiedenen Benutzergruppen verschiedene Konfigurationen zuzuweisen, z. B. verschiedene Failover-Konfigurationen oder verschiedene Kombinationen von Websites.

Die “Benutzer zu Controllern zuordnen” fordert Administratoren zuerst auf, eine Benutzergruppe und dann die Sites anzugeben, denen die Benutzergruppe zugewiesen ist (obwohl im Dialogfeld “Controller” steht, handelt es sich um Sites, wie für den Store definiert). Es gibt eine Spalte, die angibt, ob die ausgewählten Sites zuvor für die Aggregation konfiguriert wurden oder nicht, wie im Folgenden dargestellt. Wenn die aggregierten Sites für Failover konfiguriert wurden (“Load Balance-Ressourcen über Controller” wurde verlassen), kann die Reihenfolge der Sites hier über die Pfeile auf der rechten Seite festgelegt werden.

Benutzerzuordnungseinstellungen

Es ist möglich, dass ein Benutzer Teil von mehreren Benutzergruppenzuordnungen sein kann. Wenn StoreFront die Liste der konfigurierten Benutzergruppen liest, wird die Verarbeitung nicht beendet, nachdem eine Übereinstimmung für einen Benutzer gefunden wurde. Alle konfigurierten Gruppen werden verarbeitet und alle zurückgegebenen Sites werden mit aufgelistet. Dieses Szenario kann bei Citrix Administratoren erwartet werden, die in der Regel Zugriff auf alle Anwendungen und Desktops haben und Mitglieder mehrerer Benutzergruppen sind, um gemeldete Benutzerprobleme testen und reproduzieren zu können. Dies bedeutet nur, dass Administratoren (oder andere Benutzer, die Mitglieder mehrerer Gruppen sind) möglicherweise ein anderes Startverhalten auftreten, das Benutzer in einer der Gruppen, da auf sie mehrere Konfigurationen angewendet wurden. Konfigurationsweise gilt nur, wenn zwei Benutzergruppen Zugriff auf denselben Sites mit unterschiedlichen Aggregationseinstellungen haben. Im Kontext eines einzelnen Benutzers kann eine Site nur zu einer Aggregationsgruppe gehören oder es wird ein Fehler angezeigt. Dies wird behoben, indem die Aggregationsgruppen zwischen den beiden Benutzergruppenzuordnungen gleich benannt werden, was standardmäßig über die GUI erfolgt. Dies kann jedoch eine Überlegung sein, wenn die web.config-Datei für einen fortgeschritteneren Satz von Konfigurationen, wie zuvor referenziert, manuell geändert wird.

Design Takeaways

So fassen Sie den vorherigen Abschnitt zusammen:

  • Das Zuweisen von Benutzergruppen zu Sites, auch ohne konfigurierte Aggregation, kann verwendet werden, um den Aufzählungsdatenverkehr zu begrenzen und somit die Zeit bis zur Fertigstellung dieses Prozesses zu verkürzen
  • Die Failoverreihenfolge für aggregierte Sites wird im Assistenten für die Benutzergruppenzuweisung angegeben.
  • Wenn mehrere Benutzergruppenzuordnungen konfiguriert sind, die einige der gleichen aggregierten Sites enthalten und Benutzer zu mehreren Gruppen gehören, müssen die Aggregationsgruppen denselben Namen haben.

Anwendungsschlüsselwörter

Eine andere Möglichkeit, die Ressourcenanzeige und den Start zu steuern, ist die Verwendung von Schlüsselwörtern im Feld Anwendungsbeschreibung. In den Store-Einstellungen kann die Anzeige basierend auf benutzerdefinierten Schlüsselwörtern gefiltert werden, wie dokumentiert im Artikel CTX223451. Es gibt auch einige spezielle, vordefinierte Schlüsselwörter, die einzigartige Funktionen haben. Zwei davon sind “primär” und “sekundär”, die den Sitzungsstart auf mehreren Sites beeinflussen. Wenn zwei Instanzen derselben Anwendung veröffentlicht werden, wird die mit dem angegebenen Schlüsselwort “primär” immer gegenüber dem mit dem Schlüsselwort “sekundär” bevorzugt. Diese Einstellung überschreibt alle Site-Aggregationseinstellungen, die in den vorherigen Abschnitten behandelt werden, was bedeutet, dass diese Einstellungen häufig zusammen verwendet werden.

Zum Beispiel müssen bei zwei CVAD-Sites, Site A und Site B, fast alle Anwendungen außerhalb von Site A (basierend auf der Back-End-Anwendungsarchitektur) gestartet werden und sind nicht bei Site B übergegangen, aber es gibt einige Anwendungen, die hauptsächlich von Site B aus gehostet werden. alle Benutzer in Failover-Reihenfolge, wobei Site A zuerst aufgeführt ist. Die außergewöhnlichen Anwendungen, die hauptsächlich von Site B aus gehostet werden, würden mit dem Schlüsselwort primär in Site B und sekundär in Site A konfiguriert.

Design Takeaways

So fassen Sie den vorherigen Abschnitt zusammen:

• Die “primären” und “sekundären” Schlüsselwörter können verwendet werden, um den Anwendungsstart über mehrere Sites hinweg weiter zu steuern, und haben Vorrang vor den Einstellungen für die Site-Aggregation

Abonnements

Abonnements in StoreFront zeigen, wie Benutzer “bevorzugte” Anwendungen haben dürfen und in einer lokalen Datenbank auf jedem StoreFront-Server gespeichert werden, die automatisch in einer Servergruppe repliziert wird. Standardmäßig werden Abonnementdatensätze im Format gespeichert<SiteName>.<DisplayName>. Dies liegt daran, dass StoreFront standardmäßig Ressourcen von allen CVAD-Websites aufzählt und diese einzeln anzeigt. Wenn zwei Ressourcen zufällig mit demselben Namen auf verschiedenen Sites veröffentlicht werden, werden Abonnements für sie einzeln nachverfolgt. Daher benötigen wir eine Art Website-Tag, um diese Abonnements zu unterscheiden.

Dies ändert sich mit der Site-Aggregation, bei der identische Ressourcen über Sites hinweg nicht einzeln angezeigt und verfolgt, sondern hinter derselben Abonnementverknüpfung aggregiert werden. Das Website-Tag ist nicht mehr sinnvoll, da ein einzelner Abonnementdatensatz dieselbe Ressource von mehreren Sites abdecken muss. Daher werden bei der Konfiguration der Site-Aggregation die Abonnementdatensätze für aggregierte Ressourcen im Format gespeichert<AggregationGroup>.<DisplayPath>\<DisplayName>.

Dies bedeutet, dass, wenn StoreFront Multi-Site-Aggregation konfiguriert wird, nachdem die Sites zuvor einzeln verfügbar waren (mit aktivierten Abonnements), alle Benutzerabonnements für neu aggregierte Ressourcen aufgrund der Änderung des Abonnementdatensatzes verschwinden. Der bisherige Abonnementdatensatz ist nicht mehr gültig, da die Anwendung nicht mehr an eine Site, sondern an eine Aggregationsgruppe gebunden ist. Eine Problemumgehung besteht darin, die Abonnementdatenbank über PowerShell zu exportieren, alle Datensätze für Ressourcen zu ersetzen, die mit dem richtigen Format aggregiert werden, und die Abonnementdatenbank nach der Konfiguration der Site-Aggregation erneut zu importieren. Andernfalls müssen Benutzer ihre Anwendungen erneut abonnieren.

Design Takeaways

So fassen Sie die vorherigen Abschnitte zusammen:

  • Multi-Site-Aggregation ändert das Format von Benutzerabonnements in der Abonnementdatenbank, was berücksichtigt werden muss, wenn die Aggregation nach Go-Live implementiert wird

Referenzen

Produktdokumentation: StoreFront Einstellungen für mehrere Standorte

Verwendung von StoreFront Schlüsselwörtern

Entwickeln von StoreFront Aggregation für mehrere Standorte