Designentscheidung: StoreFront- und Multi-Site-Aggregation entwerfen

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 war ab Version 3.5 in der Konsole verfügbar und war zuvor eine Bearbeitung der Konfigurationsdatei. Der Zweck der Multi-Site-Aggregation besteht darin, Citrix Administratoren zu ermöglichen, redundante CVAD-Sites zu erstellen (aus Gründen der Skalierbarkeit oder des Fehlers der Domäne), Benutzern jedoch anstelle von Duplikaten pro Standort ein einzelnes Anwendungs- oder Desktopsymbol anzuzeigen (wie dies ohne diese Funktion angezeigt würde). StoreFront steuert dann, wie Anwendungs- 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 in andere verwandte Einstellungen wie Anwendungsschlüsselwörter und Abonnements integriert werden können, um die Weiterleitung von Benutzersitzungen und die Darstellung von Ressourcen weiter zu steuern.

Übersicht

Die Konfiguration von Multi-Site-Einstellungen erfolgt über den Assistenten “Delivery Controller verwalten” in der StoreFront-Konsole. Verschiedene Konfigurationen werden in der Produktdokumentationdetailliert beschrieben. 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 mehrerer 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. Wenn ein Benutzer nach der Konfiguration dieser Einstellungen kein Mitglied einer der hier angegebenen Gruppen ist, werden für diesen Benutzer keine Anwendungen oder Desktops 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 Ressourcen aggregieren

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 Websites, 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.
  • Lastenausgleich von Ressourcen über Controller hinweg: Diese Einstellung steuert den Sitzungsstart. Startanforderungen werden entweder mit Lastenausgleich (Roundrobin) über die Sites hinweg oder in der Failover-Reihenfolge verteilt, unabhängig davon, ob die Sites “identisch” sind oder nicht. Die gemeinsame Nutzung von Sitzungen hat Vorrang vor einer Lastausgleichsentscheidung. Beachten Sie, dass der Lastausgleich den Lastindex nicht berücksichtigt. Wenn ein Benutzer bereits eine Sitzung auf Site B hat und eine andere Anwendung oder einen anderen Desktop startet, wird diese Sitzung daher auch auf Site B gestartet (vorausgesetzt, die Anwendung oder der Desktop ist dort verfügbar).

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 benötigen, und einen DR-Standort, der nur verwendet wird, wenn beide Produktionsstandorte ausgefallen sind, kann die GUI nicht verwendet werden, und die Datei web.config muss stattdessen manuell geändert werden (das richtige Format für diese Datei finden Sie in den Citrix Docs).

Design Takeaways

Um den vorherigen Abschnitt zusammenzufassen:

  • 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 mit Lastenausgleich oder Failover über aggregierte Sites hinweg erfolgen

Zuordnung von Benutzerfarmen

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 hauptsächliche Anwendungsfälle für diese Funktion:

  1. Einschränken der Aufzählung: Selbst ohne Aggregation mehrerer Standorte bedeutet das Zuweisen einer Benutzergruppe in StoreFront zu einer Teilmenge von Sites, dass StoreFront nur dann 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.

Einstellungen zur Benutzerzuordnung

Es ist möglich, dass ein Benutzer Teil von Zuordnungen mehrerer Benutzergruppen ist. 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 für 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 lediglich, dass Administratoren (oder andere Benutzer, die Mitglieder mehrerer Gruppen sind) möglicherweise ein anderes Startverhalten erfahren als Benutzer in einer der Gruppen, da auf sie mehrere Konfigurationen angewendet wurden. In Bezug auf die Konfiguration wird nur berücksichtigt, ob zwei Benutzergruppen Zugriff auf dieselbe Gruppe von Sites mit unterschiedlichen Aggregationseinstellungen haben. Im Kontext eines einzelnen Benutzers kann eine Site nur zu einer Aggregationsgruppe gehören, andernfalls 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

Um den vorherigen Abschnitt zusammenzufassen:

  • 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 Failover-Reihenfolge für aggregierte Sites wird im Assistenten zur Zuweisung von Benutzergruppen angegeben
  • Wenn mehrere Benutzergruppenzuordnungen konfiguriert sind, die einige der gleichen aggregierten Sites enthalten, und Benutzer mehreren Gruppen angehören, müssen die Aggregationsgruppen denselben Namen haben

Schlüsselwörter für Anwendungen

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 im Artikel CTX223451dokumentiert. 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 in den vorherigen Abschnitten behandelten Site-Aggregationseinstellungen, 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

Um den vorherigen Abschnitt zusammenzufassen:

• 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 in diesem Format gespeichert <SiteName>.<DisplayName>. Dies liegt daran, dass StoreFront standardmäßig Ressourcen von allen CVAD-Sites auflistet und sie 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 Site-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 Site-Tag ist nicht mehr aussagekräftig, da ein einziger Abonnementdatensatz dieselbe Ressource von mehreren Sites abdecken muss. Daher werden bei der Konfiguration der Standortaggregation die Abonnementdatensätze für aggregierte Ressourcen im Format gespeichert <AggregationGroup>.<DisplayPath>\<DisplayName>.

Dies bedeutet, dass, wenn die StoreFront-Aggregation für mehrere Standorte konfiguriert wird, nachdem die Sites zuvor einzeln verfügbar waren (mit aktivierten Abonnements), alle Benutzerabonnements für neu aggregierte Ressourcen aufgrund der Änderung des Abonnementdatensatzformats 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, die aggregiert werden, durch das richtige Format zu ersetzen und die Abonnementdatenbank nach der Konfiguration der Siteggregation erneut zu importieren. Andernfalls müssen Benutzer ihre Anwendungen erneut abonnieren.

Imbissbuden entwerfen

Um die vorherigen Abschnitte zusammenzufassen:

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

Referenzen

Produktdokumentation: StoreFront Multi-Site-Einstellungen

Verwendung von StoreFront Schlüsselwörtern

Designentscheidung: StoreFront- und Multi-Site-Aggregation entwerfen