Designmethodik Steuerungslayer

Der Steuerungslayer ist die vierte Ebene der Designmethodik.

Active Directory

Entscheidung: Design der Gesamtstruktur

Bei Bereitstellungen mit mehreren Gesamtstrukturen bestehen standardmäßig keine domänenübergreifenden Vertrauensstellungen zwischen den Gesamtstrukturen. Ein AD-Administrator kann Vertrauensstellungen zwischen Gesamtstrukturen einrichten, damit Benutzer und Computer aus einer Gesamtstruktur sich in einer anderen Gesamtstruktur authentifizieren und auf Ressourcen zugreifen können.

Für Gesamtstrukturen mit domänenübergreifenden Vertrauensstellungen wird empfohlen, die entsprechenden Einstellungen so zu konfigurieren, dass die Delivery Controller mit beiden Domänen kommunizieren können. Werden keine Vertrauensstellungen konfiguriert, müssen mehrere XenDesktop-Sites für jede Gesamtstruktur konfiguriert werden. Der vorliegende Abschnitt enthält eine Beschreibung der Speicheranforderungen pro Produkt und Größenberechnungen. Weitere Informationen finden Sie im Citrix Artikel CTX134971 – Successfully Deploying XenDesktop in a Complex Active Directory Environment.

Entscheidung: Struktur von Organisationseinheiten

Infrastrukturkomponenten für eine XenApp und XenDesktop-Bereitstellung sollten sich in eigenen Organisationseinheiten befinden, um Worker und Controller für Verwaltungszwecke zu trennen. Die Aufteilung in eigene OU bietet für die enthaltenen Objekte eine größere Verwaltungsflexibilität und Citrix Administratoren kann delegierte Kontrolle gewährt werden.

Die folgende Abbildung zeigt das Beispiel einer Citrix OU-Struktur.

Citrix OU-Struktur

Entscheidung: Benutzergruppen

Berechtigungen und Autorisierungen sollten möglichst Benutzergruppen und nicht einzelnen Benutzern zugewiesen werden, damit beim Erstellen, Ändern oder Löschen von Benutzerkonten nicht zu viele Ressourcenberechtigungen und Benutzerrechte bearbeitet werden müssen. Beispiel für Anwendungen:

  • Eine Anwendung, die für eine Gruppe von 1000 Benutzern veröffentlicht wird, erfordert nur die Validierung eines Objekts für alle 1000 Benutzer.
  • Wird dieselbe Anwendung für 1000 einzelne Benutzerkonten veröffentlicht, so müssen alle 1000 Objekte validiert werden.

Datenbank

Die meisten im vorliegenden Dokument beschriebenen Citrix Produkte erfordern eine Datenbank. In der folgenden Tabelle ist die Verwendung nach Produkten aufgeschlüsselt:

Tabellenlegende:

  • J bedeutet verfügbar.
  • O bedeutet optional.
Produkt Konfigurationsdaten Laufzeitdaten Audit-/Änderungsprotokolldaten Überwachungsdaten
XenDesktop J J J J
Provisioning Services J   O  
Desktop Player J J J J

Entscheidung: Edition

Es gibt mehrere Editionen von Microsoft SQL Server 2012: Express, Web, Standard, Business Intelligence und Enterprise. Basierend auf den Funktionen der verschiedenen SQL Server Editionen wird die Standard Edition häufig zum Hosten der XenApp und XenDesktop-Datenbanken in Produktionsumgebungen verwendet.

Die Standard Edition bietet für die meisten Umgebungen ausreichende Funktionen. Weitere Informationen zu den von Citrix Produkten unterstützten Datenbanken finden Sie in der Matrix der Citrix Datenbankunterstützung. Verschiedene Versionen von Citrix Produkten unterstützen verschiedene SQL Server-Versionen. Daher muss anhand der Unterstützungsmatrix geprüft werden, ob die verwendete SQL Server-Version mit dem bereitzustellenden Citrix Produkt kompatibel ist.

Entscheidung: Dimensionierung des Datenbankservers

SQL Server muss korrekt dimensioniert werden, um Leistung und Stabilität für die Umgebung zu gewährleisten. Da jedes Citrix Produkt SQL Server auf eine andere Weise verwendet, sind keine allgemeingültigen Größenempfehlungen möglich. Nachfolgend finden Sie Empfehlungen zur SQL Server-Dimensionierung für die einzelnen Produkte.

XenApp und XenDesktop

XenApp und XenDesktop-Broker verwenden die Datenbank als Meldungsbus für die Brokerkommunikation, zur Speicherung von Konfigurationsdaten und zur Speicherung von Überwachungs- und Konfigurationsprotokolldaten. Die Datenbanken sind ständig in Verwendung und die Auswirkung auf die Leistung des SQL-Servers kann als hoch angesehen werden.

Gemäß dem Ergebnis interner Citrix Skalierbarkeitstests wird für einen SQL-Server, der alle XenDesktop-Datenbanken hostet, die folgende Spezifikation empfohlen:

  • 2 Kerne/4 GB RAM (Umgebungen mit bis zu 5.000 Benutzern)
  • 4 Kerne/8 GB RAM (Umgebungen mit bis zu 15.000 Benutzern)
  • 8 Kerne/16 GB RAM (Umgebungen mit mehr als 15.000 Benutzern)

Die Datenbankdateien und Transaktionsprotokolle sollten auf separaten Festplattensubystemen gehostet werden, um die hohe Transaktionszahl zu bewältigen. Beispielsweise verursacht die Registrierung von 20.000 virtuellen Desktops in einem Boot Storm von 15 Minuten ca. 500 Transaktionen pro Sekunde in der XenDesktop-Sitedatenbank und die Anmeldung von 20.000 Benutzern während einer 30-minütigen Spitzenzeit etwa 800 Transaktionen pro Sekunde.

Provisioning Services

Neben statischen Konfigurationsdaten speichern Provisioning-Server Laufzeit- und Überwachungsinformationen in der Datenbank. Je nach Boot- und Verwaltungsmuster können die Auswirkungen auf die Datenbankleistung als niedrig bis mittel betrachtet werden.

Basierend auf dieser Kategorisierung wird eine SQL-Server-Spezifikation von 4 Kernen und 4 GB RAM als guter Ausgangspunkt empfohlen. Der SQL-Server sollte während der Test- und Pilotphase sorgfältig überwacht werden, um die optimale Konfiguration zu ermitteln.

Entscheidung: Instanzdimensionierung

Bei der Dimensionierung einer SQL-Datenbank sind zwei Aspekte wichtig:

  • Datenbankdatei: Sie enthält die Daten und Objekte wie Tabellen, Indizes, gespeicherte Prozeduren und Ansichten, die in der Datenbank gespeichert sind.
  • Transaktionsprotokolldatei: Sie enthält eine Aufzeichnung aller Transaktionen und Datenbankänderungen, die von den Transaktionen vorgenommen werden. Das Transaktionsprotokoll ist eine wichtige Komponente der Datenbank, die bei einem Systemfehler zur Rücksetzung der Datenbank in einen konsistenten Zustand erforderlich sein kann. Die Nutzung des Transaktionsprotokolls hängt von dem verwendeten Datenbankwiederherstellungsmodell ab:
    • Einfach: Es sind keine Protokollbackups erforderlich. Protokollspeicherplatz wird automatisch rückgewonnen, um den Platzbedarf gering zu halten, sodass die Verwaltung des Speicherplatzes für das Transaktionsprotokoll überflüssig ist. Datenbankänderungen seit der letzten Sicherung sind ungeschützt. Bei Eintritt eines Notfalls müssen diese Änderungen erneut durchgeführt werden.
    • Vollständig: Es sind Protokollbackups erforderlich. Keine Arbeit geht aufgrund einer verlorenen oder beschädigten Datenbankdatendatei verloren. Daten eines beliebigen Zeitpunkts (z. B. von vor einem Anwendungs- oder Benutzerfehler) können wiederhergestellt werden. Die vollständige Wiederherstellung ist für die Datenbankspiegelung erforderlich.
    • Massenprotokolliert: Es sind Protokollbackups erforderlich. Massenprotokolliert ist ein Zusatz zur vollständigen Wiederherstellung, der schnelle Massenkopiervorgänge ermöglicht. Er wird normalerweise nicht für Citrix Datenbanken verwendet.

Weitere Informationen finden Sie im Microsoft Developer Network unter Wiederherstellungsmodelle (SQL Server).

Zur Einschätzung der Speicheranforderungen muss der Speicherplatzverbrauch gängiger Datenbankeinträge bekannt sein. Der vorliegende Abschnitt enthält eine Beschreibung der Speicheranforderungen pro Produkt und Größenberechnungen. Weitere Informationen finden Sie in dem Citrix-Artikel CTX139508 – XenDesktop 7.x Database Sizing.

XenDesktop – Allgemeines

XenApp 7.x und XenDesktop 7.x verwenden drei Datenbanken:

  • Sitekonfigurationsdatenbank: Enthält statische Konfigurations- und dynamische Laufzeitdaten.
  • Überwachungsdatenbank: Enthält Überwachungsdaten, auf die über Director zugegriffen werden kann.
  • Konfigurationsprotokollierungsdatenbank: Enthält einen Datensatz für jede administrative Änderung, die innerhalb der Site durchgeführt wird (zugänglich über Studio).

Sitedatenbank

Da die Datenbank einer XenApp und XenDesktop-Site statische Konfigurationsdaten und dynamische Laufzeitdaten enthält, hängt die Größe der Datenbankdatei nicht nur von der physischen Größe der Umgebung ab, sondern auch von Nutzungsmustern. Folgende Faktoren wirken sich auf die Größe der Datenbankdatei aus:

  • Anzahl der verbundenen Sitzungen
  • Anzahl der konfigurierten und registrierten VDAs
  • Anzahl der Transaktionen während der Anmeldung
  • VDA-Takttransaktionen

Die Größe der Sitedatenbank hängt von der Anzahl VDAs und aktiver Sitzungen ab. Die folgende Tabelle enthält durchschnittliche maximale Datenbankgrößen, die von Citrix durchgeführte XenApp und XenDesktop-Tests mit spezifischen Benutzer- und Anwendungszahlen sowie Desktop-Bereitstellungsmethoden ergaben.

Benutzer Anwendungen Desktoparten Erwartete maximale Größe (MB)
1000 50 Gehostet freigegeben 30
10.000 100 Gehostet freigegeben 60
100.000 200 Gehostet freigegeben 330
1000 Nicht zutreffend Gehostet gepoolt 30
10.000 Nicht zutreffend Gehostet gepoolt 115
40.000 Nicht zutreffend Gehostet gepoolt 390

Hinweis

Diese Größenangaben dienen nur als Richtschnur. Die tatsächlichen Größe kann je nach Art der Datenbankpflege leicht abweichen.

Die Schätzung der Größe des Transaktionsprotokolls der Sitedatenbank ist aufgrund folgender Einflussfaktoren schwierig:

  • Wiederherstellungsmodell der SQL-Datenbank
  • Startrate zu Spitzenzeiten
  • Anzahl der bereitgestellten Desktops

In XenDesktop-Skalierbarkeitstests hat Citrix für das Transaktionsprotokoll eine Wachstumsrate von 3,5 MB pro Stunde bei Systemleerlauf und eine Wachstumsrate pro Benutzer und Tag von ca. 32 KB beobachtet. In großen Umgebungen muss das Transaktionsprotokoll sorgfältig verwaltet und regelmäßig gesichert werden, um ein übermäßiges Wachstum zu verhindern. Dies ist durch geplante Aufträge oder Wartungspläne möglich.

Überwachungsdatenbank

Von den drei Datenbanken ist die Überwachungsdatenbank in der Regel am größten, da sie Verlaufsinformationen zur Site enthält. Ihre Größe hängt von vielen Faktoren ab. Beispiele sind:

  • Anzahl Benutzer
  • Anzahl Sitzungen und Verbindungen
  • Anzahl Worker
  • Konfiguration des Aufbewahrungszeitraums: Platinum-Kunden können Daten über ein Jahr lang aufbewahren (Standardeinstellung 90 Tage). Kunden mit einer anderen Edition können Daten bis zu 7 Tage aufbewahren (Standardeinstellung 7 Tage).
  • Anzahl Transaktionen pro Sekunde. Der Überwachungsdienst führt in der Regel Aktualisierungen in Batches aus. Die Anzahl der Transaktionen pro Sekunde liegt selten über 20.
  • Hintergrundtransaktionen aufgrund regelmäßiger Konsolidierungsaufrufe des Überwachungsdiensts.
  • Verarbeitung über Nacht zum Entfernen von Daten, die außerhalb des konfigurierten Aufbewahrungszeitraums liegen.

Die folgende Tabelle enthält die geschätzte Größe der Überwachungsdatenbank pro Zeitraum in verschiedenen Szenarien. Bei diesen Daten handelt es sich um eine Schätzung, die auf XenApp und XenDesktop-Skalierungstestdaten und der Annahme einer 5-tägigen Arbeitswoche beruht.

Benutzer Typ 1 Woche (MB) 1 Monat (MB) 3 Monate (MB) 1 Jahr (MB)
1000 HSD 20 70 230 900
10.000 HSD 160 600 1.950 7.700
100.000 HSD 1500 5.900 19.000 76.000
1000 VDI 15 55 170 670
10.000 VDI 120 440 1.400 5500
40.000 VDI 464 1.700 5.400 21.500

Schätzungen unter Annahme von 2 Verbindungen und 1 Sitzung pro Benutzer in einer 5-tägigen Arbeitswoche

Benutzer Typ 1 Woche (MB) 1 Monat (MB) 3 Monate (MB) 1 Jahr (MB)
1000 HSD 30 100 330 1.300
10.000 HSD 240 925 3.000 12.000
100.000 HSD 2.400 9.200 30.000 119.000
1000 VDI 25 85 280 1.100
10.000 VDI 200 750 2.500 9.800
40.000 VDI 800 3.000 9.700 38.600

Hinweis

Die Tests mit 100.000 gehosteten, freigegebenen Desktops (HSD) beruhen auf einer Testumgebung mit folgenden Elementen:

  • 2 Delivery Controllern
  • 43 gehosteten, freigegebenen Desktopworkern
  • 3 SQL-Servern mit Datenbanken in einer AlwaysOn-Verfügbarkeitsgruppe

Weitere Informationen finden Sie im Citrix Supportartikel XenDesktop 7.x Database Sizing.

Die Größe des Transaktionsprotokoll der Überwachungsdatenbank lässt sich nur schwer schätzen. XenApp und XenDesktop-Skalierbarkeitstests ergaben eine Wachstumsrate von etwa 30,5 MB pro Stunde bei Systemleerlauf und eine Wachstumsrate pro Benutzer und Tag von ca. 9 KB.

Konfigurationsprotokollierungsdatenbank

Die Konfigurationsprotokollierungsdatenbank ist in der Regel die kleinste der drei Datenbanken. Ihre Größe und die des zugehörigen Transaktionsprotokolls hängen von den alltäglichen Verwaltungsaktivitäten ab, die über Studio, Director oder PowerShell-Skripts initiiert werden und ist daher schwer abzuschätzen. Je mehr Konfigurationsänderungen durchgeführt werden, desto größer wird die Datenbank. Beispiele von Faktoren, die sich auf die Größe der Datenbank auswirken:

  • Anzahl der in Studio, Director und PowerShell ausgeführten Aktionen.
  • Minimale Transaktionen, die in der Datenbank auftreten, wenn keine Konfigurationsänderungen stattfinden.
  • Transaktionsrate bei Aktualisierungen. Aktualisierungen werden möglichst in Batches durchgeführt.
  • Manuell aus der Datenbank entfernte Daten. Daten in der Konfigurationsprotokollierungsdatenbank unterliegen keiner Aufbewahrungsrichtlinie und werden daher nur entfernt, wenn dies ein Administrator manuell tut.
  • Aktivitäten mit Auswirkungen auf Sitzungen oder Benutzer, z. B. Sitzungsabmeldung und Zurücksetzung.
  • Für die Bereitstellung von Desktops verwendeter Mechanismus.

In XenApp-Umgebungen ohne MCS liegt die Datenbankgröße tendenziell zwischen 30 und 40 MB. Bei Umgebungen mit MCS kann die Datenbankgröße aufgrund der Protokollierung sämtlicher VM-Builddaten leicht 200 MB überschreiten.

Temporäre Datenbank

Neben der Site-, Überwachungs- und Konfigurationsprotokollierungsdatenbank wird eine systemweite temporäre Datenbank (tempdb) von SQL Server bereitgestellt. Die temporäre Datenbank wird zum Speichern von Read-Committed-Snapshot-Isolationsdaten verwendet. XenApp 7.x und XenDesktop 7.x verwenden dieses SQL Server-Feature, um die Zahl von Sperrkonflikten in XenApp und XenDesktop-Datenbanken zu reduzieren. Citrix empfiehlt die Verwendung der Read-Committed-Snapshot-Isolation für alle XenApp 7.x- und XenDesktop 7.x-Datenbanken. Weitere Informationen finden Sie unter How to Enable Read-Committed Snapshot in XenDesktop.

Die Größe der tempdb-Datenbank hängt von der Anzahl der aktiven Transaktionen ab, sollte jedoch normalerweise ein paar MB nicht übersteigen. Die Leistung der tempdb-Datenbank hat keine Auswirkungen auf die Leistung des XenApp und XenDesktop-Brokerings, da alle Transaktionen, die neue Daten generieren, tempdb-Speicherplatz benötigen. Die Transaktionen von XenApp und XenDesktop sind tendenziell kurzlebig und tragen daher zu einer gleichbleibend geringen Größe der tempdb-Datenbank bei.

Die tempdb-Datenbank wird auch verwendet, wenn Abfragen große Zwischenergebnissätze generieren. Einen Leitfaden und Informationen zur Dimensionierung der tempdb-Datenbank finden Sie in dem Microsoft TechNet-Artikel tempdb-Datenbank.

Provisioning Services

Die Provisioning Services-Farmdatenbank enthält statische Konfigurationsdaten und Konfigurationsprotokollierungsdaten (Auditliste). Die unten beschriebenen Datensatzgrößen-Anforderungen können verwendet werden, um die Größe der Datenbank zu bemessen:

Konfigurationselement Erforderlicher DB-Speicherplatz (KB) Anzahl der Elemente (Beispiel) Gesamt (KB)
Grundlegende Farmkonfiguration 112 - 112
Benutzergruppe mit Farmzugriff 50 10 250
Site 4 5 20
Gerätesammlung 10 50 500
Farmansicht 4 10 40
Farmansicht/Gerät-Beziehung 5 1 5.000
Siteansicht 4 5 20
Siteansicht/Gerät-Beziehung 5 1 5.000
Geräte 2 5.000 10.000
Gerätebootstrap 10 - -
Gerät/Datenträger-Beziehung 35 1 175.000
Gerät/Drucker-Beziehung 1 - -
Gerätecharakterdaten 1 - -
Gerätestatus (gestartet) 1 5.000 5.000
Benutzerdefinierte Geräteeigenschaft 2 - -
vDisk 1 20 20
vDisk-Version 3 5 300
Datenträger-Locator 10 1 200
Benutzerdefinierte Eigenschaft für Datenträger-Locator 2 - -
Server 5 10 50
Server-IP 2 1 20
Serverstatus (gestartet) 1 20 20
Benutzerdefinierte Servereigenschaft 2 - -
vDisk-Speicher 8 5 40
vDisk-Speicher/Server-Beziehung 4 1 40
Verbindung zu XenServer (VirtualHostingPool) 4 - -
vDisk-Updatetask 10 10 100
Administrative Änderung (Überwachung aktiviert) 1 10.000 10.000
Gesamt     211.732 KB (~212 MB)

Während der Einrichtung der PVS-Farm wird eine Datenbank mit einer anfänglichen Dateigröße von 20 MB erstellt. Aufgrund der Art der Daten in der PVS-Farmdatenbank wird erwartet, dass das Transaktionsprotokoll nicht sehr schnell wächst, es sei denn, es erfolgen umfassende Konfigurationen.

Im Gegensatz zu XenApp, wo auch administrative Änderungen verfolgt werden können, werden die zugehörigen Informationen nicht in eine dedizierte Datenbank, sondern direkt in die Provisioning Services-Farmdatenbank geschrieben. Um die Größe der Provisioning Services-Datenbank zu begrenzen, wird empfohlen, die Auditlistendaten regelmäßig zu archivieren.

Entscheidung: Datenbankspeicherort

XenApp und XenDesktop verwendet drei Datenbanken: zur Standortkonfiguration, Überwachung und Konfigurationsprotokollierung. Die drei Datenbanken können auf einem Server oder auf verschiedenen Servern gehostet werden. Ideal wäre das Hosten der Überwachungsdatenbank auf einem Server und der Standortkonfigurations- und Konfigurationsprotokollierungsdatenbank auf einem anderen. Es empfiehlt sich, die Überwachungsdatenbank separat zu hosten, da in ihr mehr Daten aufgezeichnet werden, häufiger Änderungen auftreten und die Daten nicht als so kritisch gelten wie die in den anderen Datenbanken.

Hinweis

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

Entscheidung: hohe Verfügbarkeit

In der folgenden Tabelle werden die Auswirkungen auf XenApp, XenDesktop und Provisioning Services bei einem Datenbankausfall aufgeführt:

Komponente Auswirkungen eines Datenbankausfalls
Sitekonfigurationsdatenbank Die Benutzer können keine Verbindung zu einem virtuellen Desktop herstellen bzw. wiederherstellen. Hinweis: Der lokale Hostcache ermöglicht Benutzern mit gehosteten freigegebenen Desktops, gehosteten Windows- und Browseranwendungen sowie persönlichen Desktops die Wiederherstellung der Verbindung zu ihren Anwendungen und Desktops, selbst wenn die Sitedatenbank nicht verfügbar ist.
Überwachungsdatenbank Director zeigt keine historischen Daten an und Studio kann nicht gestartet werden. Das Brokering eingehender Benutzeranforderungen und bestehender Benutzersitzungen wird nicht beeinträchtigt.
Konfigurationsprotokollierungsdatenbank Wenn “Änderungen zulassen, wenn die Verbindung zur Datenbank getrennt ist” in den XenApp und XenDesktop-Protokollierungseinstellungen aktiviert wurde, hat ein Ausfall der Konfigurationsprotokollierungsdatenbank keine Auswirkungen (außer dass Konfigurationsänderungen nicht protokolliert werden). Andernfalls können Administratoren keine Änderungen an der XenApp und XenDesktop-Sitekonfiguration vornehmen. Die Benutzer sind nicht betroffen.
Provisioning Services-Farmdatenbank Falls die Offline-Datenbankunterstützung aktiviert ist und die Datenbank ausfällt, verwendet der Streamprozess eine lokale Kopie der Datenbank zum Abrufen von Informationen über den Provisioning-Server und die von ihm unterstützten Zielgeräte. Dadurch bleiben die Provisioning-Server und Zielgeräte betriebsbereit. Wenn die Datenbank offline ist, stehen allerdings die folgenden Konsolen- und Verwaltungsfunktionen nicht zur Verfügung: automatisches Hinzufügen von Zielgeräten, vDisk-Erstellung und -Aktualisierung, Active Directory-Kennwortänderungen, Starten des Streamprozesses, Image-Updatedienst, PowerShell- und MCLI-basierte Verwaltung. Wenn die Offline-Datenbankunterstützung nicht aktiviert wurde, steht keine Verwaltungsfunktion zur Verfügung und Starten und Failover von Zielgeräten schlagen fehl.

Hinweis

Optionen für hohe Verfügbarkeit bei Datenbanken von Drittanbietern (z. B. App-V, SCVMM oder vCenter) können beim jeweiligen Softwarehersteller erfragt werden.

Zusätzlich zu den integrierten Datenbank-Redundanzoptionen bieten Microsoft SQL Server und der zugrundeliegende Hypervisor (in virtuellen Umgebungen) eine Reihe von Funktionen für hohe Verfügbarkeit. Auf diese Weise können Administratoren sicherstellen, dass Ausfälle einzelner Server keine oder nur minimale Auswirkungen auf die XenApp und XenDesktop-Infrastruktur haben. Die folgenden SQL-/Hypervisor-Funktionen für hohe Verfügbarkeit stehen zur Verfügung:

  • Hohe Verfügbarkeit auf VM-Ebene: Diese Option ist nur für virtuelle SQL-Server verfügbar, die auf Hypervisorebene als hoch verfügbar markiert werden müssen. Im Falle eines unerwarteten Herunterfahrens der virtuellen Maschine oder des zugrundeliegenden Hypervisorhosts versucht der Hypervisor, die VM sofort auf einem anderen Host neu zu starten. Hohe Verfügbarkeit auf VM-Ebene kann zwar Ausfallzeiten bei Stromausfall minimieren, schützt jedoch nicht vor Beschädigung des Betriebssystems. Diese Lösung ist kostengünstiger als Spiegelung oder Clustering, da ein integriertes Hypervisorfeature verwendet wird. Das automatische Failover ist jedoch langsamer, da es dauern kann, bis ein Ausfall erkannt und der virtuelle SQL-Server auf einem anderen Host gestartet wird. Dabei kann es zu Dienstunterbrechungen für die Benutzer kommen.
  • Spiegelung: Eine Datenbankspiegelung erhöht die Datenbankverfügbarkeit mit fast sofortigem Failover. Die Datenbankspiegelung kann verwendet werden, um eine einzelne Standby- bzw. Spiegeldatenbank für eine Prinzipal- bzw. Produktionsdatenbank zu betreiben. Die Datenbankspiegelung erfolgt entweder im synchronem Betrieb mit hoher Sicherheit oder im asynchronem Betrieb mit hoher Leistung. Im Hochsicherheitsmodus mit automatischem Failover (empfohlen für XenDesktop) ist als dritte Serverinstanz ein “Zeugenserver” erforderlich, sodass der Spiegelserver als unmittelbar betriebsbereiter Standbyserver fungieren kann. Ein Failover von der Prinzipaldatenbank auf die Spiegeldatenbank erfolgt automatisch und dauert in der Regel nur wenige Sekunden. Es empfiehlt sich, hohe Verfügbarkeit auf VM-Ebene (oder eine ähnliche automatische Neustartfunktion) zumindest für den Zeugenserver zu aktivieren, um die Verfügbarkeit des SQL-Diensts bei einem Ausfall mehrerer Server sicherzustellen.

Hinweis

Microsoft plant, die Spiegelung als Hochverfügbarkeitsoption in einer zukünftigen Version von SQL Server zu entfernen, und rät von deren Verwendung in neuen Netzwerken ab. Weitere Informationen finden Sie in dem Microsoft-Artikel Datenbankspiegelung (SQL Server).

  • AlwaysOn-Failoverclusterinstanzen: Failoverclustering bietet hohe Verfügbarkeit für eine gesamte Microsoft SQL Server-Instanz. Ein Failovercluster besteht aus zwei oder mehr Knoten oder Servern, die einen gemeinsamen Speicher verwenden. Die mit Microsoft SQL Server 2012 eingeführte AlwaysOn-Failoverclusterinstanz wird im Netzwerk als einzelner Computer angezeigt, bietet jedoch ein Failover von einem Knoten zum nächsten, wenn ein Knoten ausfällt. Der Übergang von einem Knoten zum anderen ist für Clients, die mit dem Cluster verbunden sind, nahtlos. AlwaysOn-Failoverclusterinstanzen erfordern eine WSFC-Ressourcengruppe (Windows Server Failoverclustering). Die Zahl der Knoten, die in der WSFC-Ressourcengruppe unterstützt werden, hängt von der SQL Server-Edition ab. (Siehe Tabelle im Abschnitt Entscheidung: Edition oben.) Weitere Informationen finden Sie auf MSDN unter AlwaysOn-Failoverclusterinstanzen (SQL Server).
  • AlwaysOn-Verfügbarkeitsgruppen: AlwaysOn-Verfügbarkeitsgruppen sind eine Lösung für hohe Verfügbarkeit und Notfallwiederherstellung für Unternehmen, die mit SQL Server 2012 eingeführt wurde und es Administratoren ermöglicht, die Verfügbarkeit für eine oder mehrere Benutzerdatenbanken zu maximieren. AlwaysOn-Verfügbarkeitsgruppen erfordern, dass die Microsoft SQL Server-Instanzen auf WSFC-Knoten (Windows Server Failover Clustering) residieren. Wie beim Failoverclustering wird den Datenbankbenutzern nur eine virtuelle IP bzw. nur ein Netzwerkname bereitgestellt. Im Gegensatz zum Failoverclustering ist kein gemeinsamer Speicher erforderlich, da die Daten über eine Netzwerkverbindung übertragen werden. Es wird die synchrone und die asynchrone Replikation auf einen oder mehrere sekundäre Server unterstützt. Im Gegensatz zur Spiegelung oder zum Clustering können sekundäre Server aktiv für die Verarbeitung eingehender Read-Only-Anforderungen, Backups und Integritätsprüfungen verwendet werden. Mit diesem Feature können in XenDesktop-Umgebungen Benutzerressourcen-Enumerationsanforderungen an einen sekundären SQL-Server abgeladen werden, um die SQL Server-Infrastruktur im horizontal zu skalieren. Da die Daten auf aktiven sekundären Servern mehrere Sekunden hinter dem primären Server zurückbleiben können, kann das Read-Only-Routing derzeit nicht für andere XenDesktop-Datenbankanforderungen verwendet werden. Weitere Informationen finden Sie auf MSDN unter AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Die folgende Tabelle enthält die empfohlenen Hochverfügbarkeitsfeatures für Citrix Datenbanken:

Bedeutung der Angaben:

  • J = empfohlen.
  • o = machbar.
  • N = nicht unterstützt.
  • T = nur für Testumgebungen.
Komponente HA auf VM-Ebene Spiegelung AlwaysOn-Failoverclusterinstanzen AlwaysOn-Verfügbarkeitsgruppen
Sitedatenbank T J o o
Konfigurationsprotokollierungsdatenbank T o o o
Überwachungsdatenbank T J o o
Provisioning Services-Farmdatenbank T J o o
DesktopPlayer-Datenbank T N o o

Citrix Lizenzierung

Citrix bietet Unternehmen die Flexibilität mehrerer Lizenzierungsmodelle für gängige Nutzungsszenarien. Die Lizenzierungsmodelle variieren je nach Citrix Produkt, können jedoch das Konzept “pro Benutzer/Gerät” und “pro gleichzeitiger Benutzer” umfassen. Bei mehreren Citrix Produkten wird der Lizenzserver verwendet, für andere muss eine Lizenz im Produkt installiert werden.

Citrix Lizenzserver

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

Im Produkt:

  • NetScaler
  • NetScaler Gateway

Weitere Informationen zur XenDesktop 7.x-Lizenzierung finden Sie unter CTX128013.

Weitere Informationen zur Microsoft-Lizenzierung finden Sie im Microsoft-Dokument Licensing Microsoft’s Virtual Desktop Infrastructure Technology.

Entscheidung: Dimensionierung

Interne Skalierbarkeitstests haben gezeigt, dass ein einzelner virtueller Lizenzserver mit zwei Kernen und 2 GB RAM etwa 170 Lizenzen pro Sekunde oder 306.000 Lizenzen pro halbe Stunde ausstellen kann. Bei Bedarf kann der Lizenzserver horizontal skaliert werden, um mehr Lizenzanforderungen pro Sekunde zu unterstützen.

Entscheidung: hohe Verfügbarkeit

In einer typischen Umgebung genügt ein Lizenzserver. Fällt der Lizenzserver aus, beginnt für abhängige Citrix Produkte eine 30-tägige Kulanzfrist, die genug Zeit für das Beheben von Verbindungsproblemen und/oder die Wiederherstellung des Lizenzservers bietet.

Hinweis

  • Wenn Lizenzserver und Citrix Produkt nicht innerhalb von 2 Takten (5–10 Minuten) kommunizieren, beginnt für das Citrix Produkt eine Kulanzfrist, die bis zu 30 Tage lang Verbindungen zulässt. Sobald die Kommunikation mit dem Lizenzserver wiederhergestellt ist, stimmt dieser die temporären und tatsächlichen Lizenzen ab.
  • Ein CNAME-Eintrag in DNS ist eine praktische Möglichkeit, auf den Lizenzserver zu verweisen. Die Verwendung eines CNAME-Eintrags ermöglicht die Änderung des Lizenzservernamens ohne die Citrix Produkte zu aktualisieren.

Für Fälle, in denen zusätzliche Redundanz erforderlich ist, unterstützt Citrix die folgenden Hochverfügbarkeitslösungen für den Lizenzserver.

  • Windows-Clustering: Clusterserver sind Gruppen von Computern, die zusammen die Verfügbarkeit erhöhen. Durch Clustering ist im Fehlerfall ein automatisches Failover der Lizenzserverrolle möglich. Weitere Informationen zum Clustering finden Sie im Citrix-Artikel Lizenzservercluster.
  • Duplizierung des Lizenzservers: Erstellen Sie ein Backup des Lizenzservers auf VM-Ebene. Das Backup darf nicht auf demselben Host wie der Lizenzserver gespeichert werden. Stattdessen muss es an einem sicheren Ort, etwa in einem hochverfügbaren Speicher oder auf Band oder einem Datenträger gespeichert werden. Der doppelte Server ist nicht aktiv und verbleibt im Standbymodus, bis der aktive Lizenzserver wiederhergestellt werden muss. Muss der Lizenzserver mit dem Backup wiederhergestellt werden, müssen jegliche neuen Lizenzen erneut auf den Server heruntergeladen werden.

Weitere Informationen finden Sie in den Citrix eDocs unter Die Lizenzierungsarchitektur im Überblick.

Bei allen Methoden kann der Administrator einen Lizenzserver mit einem anderen ersetzen, ohne dass es zu einer Dienstunterbrechung kommt, vorausgesetzt, der Austausch findet im Kulanzzeitraum statt und es werden folgende Einschränkungen beachtet.

  • Die Lizenzdateien referenzieren den bei der Zuweisung angegebenen Server. Das bedeutet, dass die Lizenzdateien nur auf einem Server mit denselben Bindungsinformationen (Hostname) verwendet werden können wie der zuvor angegebene Server.
  • Zwei Windows-basierte und zu einer Domäne gehörende Lizenzserver können nicht denselben Namen haben und gleichzeitig in der Umgebung aktiv sein.
  • Da Lizenzserver nicht miteinander kommunizieren, müssen zusätzliche Lizenzen sowohl auf dem aktiven als auch auf dem Backuplizenzserver platziert werden.

Entscheidung: Optimierung

Die Leistung des Lizenzservers kann durch die Einstellung der Anzahl der Empfangs- und der Verarbeitungsthreads optimiert werden. Wird eine zu niedrige Threadanzahl festgelegt, werden Anforderungen in die Warteschlange gestellt, bis ein Thread verfügbar wird. Umgekehrt wird der Lizenzserver überlastet, wenn eine zu hohe Threadanzahl festgelegt wird.

Die optimalen Werte hängen von der Hardware, der Sitekonfiguration und der Zahl der Lizenzanforderungen ab. Citrix empfiehlt, verschiedene Werte zu testen und auszuwerten, um die richtige Konfiguration zu bestimmen. Ein guter Ausgangspunkt für eine große Bereitstellung ist die Festlegung der maximalen Anzahl von Verarbeitungsthreads auf 30 und der maximalen Anzahl von Empfangsthreads auf 15.

Dies verbessert die Fähigkeit des Citrix Lizenzservers, Lizenzen bereitzustellen, indem seine Fähigkeit zum Empfangen und Verarbeiten von Lizenzanforderungen erhöht wird.

Weitere Informationen finden Sie in der Citrix-Dokumentation unter Erhöhen der Leistung durch Festlegen der Threadnutzung.

Delivery Controller

Entscheidung: Serverdimensionierung

Die Skalierbarkeit des Delivery Controllers basiert auf der CPU-Auslastung. Je mehr Prozessorkerne verfügbar sind, desto mehr virtuelle Desktops kann ein Controller unterstützen. Jede Start-, Registrierungs-, Enumerations- und Startanforderung eines Desktops wirkt sich auf den Prozessor des Controllers aus. Je mehr Anforderungen, umso größer die CPU-Auslastung des Controllers. Erreicht die CPU den kritischen Schwellenwert von etwa 80 %, muss die Site vertikal oder horizontal skaliert werden.

Durch das Hinzufügen zusätzlicher CPU-Kerne zu einem Delivery Controller wird die CPU-Auslastung insgesamt gesenkt, sodass er eine größere Anzahl von Desktops unterstützen kann. Das ist nur bei virtualisierten Controllern machbar, da das Hinzufügen virtueller CPUs relativ einfach ist. Die Alternative besteht darin, der Site einen weiteren Controller hinzuzufügen. Der Controller hätte die gleiche Konfiguration wie andere Controller, und die Last würde gleichmäßig auf alle Controller verteilt, was dazu beiträgt, die Gesamtlast auf jedem einzelnen Controller zu reduzieren.

Tests haben gezeigt, dass ein Delivery Controller mit der folgenden Konfiguration mehr als 5.000 Desktops unterstützen kann.

Komponente Spezifikation
Prozessor 4 vCPUs
Speicher 4 GB RAM
Netzwerk Verbundene virtuelle NIC
Hostspeicher 40 GB freigegebener Speicher
Betriebssystem Windows Server 2012 R2
XenDesktop 7

Mit der folgenden Formel kann die Anzahl der für eine Citrix Site erforderlichen Delivery Controller berechnet werden.

Abbildung: Anzahl Delivery Controller

Entscheidung: hohe Verfügbarkeit

Ist der Server, auf dem der Delivery Controller gehostet wird, nicht verfügbar, können die Benutzer nicht auf ihre virtuellen Desktops und veröffentlichten Anwendungen zugreifen. Daher sollten mindestens zwei Delivery Controller (n+1-Redundanz) pro Zone auf separaten physischen Servern bereitgestellt werden, damit diese Komponente keine einzelne Schwachstelle darstellt. Wenn ein Controller ausfällt, können die anderen die Verwaltung der Verbindungen und der Site übernehmen.

Die Speicherorte aller Delivery Controller werden auf dem VDA angegeben, sodass dieser ein automatisches Failover durchführen kann, wenn die Kommunikation mit einem Delivery Controller nicht möglich ist. Folgende Speicherorte werden vom VDA nacheinander überprüft, bis der Delivery Controller gefunden ist:

  1. Ein Speicherort für den persistenten Speicher für die automatische Aktualisierung. Dieser Speicherort enthält die Controllerinformationen, wenn die automatische Aktualisierung aktiviert ist und der VDA erfolgreich zum ersten Mal nach der Installation registriert wurde. Bei der ersten Registrierung nach der Installation bzw. wenn die automatische Aktualisierung deaktiviert ist, überprüft der VDA die folgenden Speicherorte.
  2. Richtlinieneinstellungen (Delivery Controller, Delivery Controller-SIDs).
  3. Die Delivery Controller-Informationen sind im VDA-ListOfDDCs Registrierungsschlüssel. Diese Werte stammen ursprünglich vom VDA-Installationsprogramm, basierend auf den Informationen, die bei der Installation des VDAs eingeben wurden.
  4. Auf Organisationseinheiten basierende Discovery. Dies ist eine ältere Methode die zugunsten der Abwärtskompatibilität beibehalten wird.
  5. Die durch die Maschinenerstellungsdienste erstellte Datei Personality.ini.

Citrix Consulting empfiehlt die Verwendung der automatischen Aktualisierung (= standardmäßig aktiviert). Dieses Feature vereinfacht die Verwaltung der Umgebung, weil VDAs beim Hinzufügen und Entfernen von Delivery Controllern aktualisiert werden.

Entscheidung: lokaler Hostcache

Selbst wenn die SQL-Datenbank hoch verfügbar ist, besteht die Gefahr, dass kein Zugriff auf die Datenbank besteht, wenn die Netzwerkverbindung zwischen dem Delivery Controller und der SQL-Datenbank fehlschlägt. Dies ist ein wichtiges Anliegen für geografisch verteilte Sites.

Zur Risikovermeidung kann für Delivery Controller ein lokaler Hostcache verwendet werden. Dabei wird eine lokale Kopie der SQL-Datenbank erstellt, die nur zum Einsatz kommt, wenn der Delivery Controller die Verbindung mit der Datenbank verliert.

Bei Verwendung des lokalen Hostcache muss Folgendes berücksichtigt werden:

  • Wahlen: Wenn die Zonen den Kontakt mit der SQL-Datenbank verlieren, erfolgt eine Wahl, in der ein einzelner Delivery Controller als Master nominiert wird. Alle verbleibenden Controller wechseln in den Leerlaufmodus. Eine einfache alphabetische Reihenfolge bestimmt den Gewinner der Wahl.
  • Dimensionierung: Bei Verwendung des lokalen Hostcache ist ein einzelner Delivery Controller für alle VDA-Registrierungen, Enumerierungen, Starts und Aktualisierungen verantwortlich. Der gewählte Controller muss über genügend Ressourcen (CPU und RAM) verfügen, um die gesamte Last der Zone zu bewältigen. Ein einzelner Controller kann auf 10.000 Benutzer skalieren, was das Zonendesign beeinflusst.
    • RAM: Die lokalen Hostcache-Dienste können je nach Dauer des Ausfalls und der Anzahl der Benutzerstarts während des Ausfalls 2 oder mehr GB RAM belegen.
    • CPU: Der lokale Hostcache kann bis zu 4 Kerne eines einzelnen Sockets verwenden.
    • Speicher: Im Modus mit lokalem Hostcache erhöhte sich der Speicherplatz alle 2–3 Minuten um 1 MB bei durchschnittlich 10 Anmeldungen pro Sekunde.
  • Energieoptionen: ausgeschaltete virtuelle Ressourcen werden nicht gestartet, wenn sich der Delivery Controller im Modus mit lokalem Hostcache befindet. Gepoolte virtuelle Desktops, die am Ende einer Sitzung neu gestartet werden, werden in den Wartungsmodus versetzt.
  • Konsolen: Bei Verwendung des lokalen Hostcache sind Studio und PowerShell nicht verfügbar.

Entscheidung: XML-Dienstverschlüsselung

In einer typischen Sitzung übergibt der StoreFront-Server Anmeldeinformationen an den Citrix XML-Dienst auf einem Delivery Controller. Das Citrix XML-Protokoll verwendet beim Austausch von Daten Klartext, Ausnahme sind Kennwörter, die mit Obfuskation übertragen werden.

Wenn der Datenverkehr zwischen den StoreFront-Servern und den XenDesktop-Controllern abgefangen werden kann, ist er für die folgenden Angriffe anfällig:

  • Angreifer können den XML-Datenverkehr abfangen und Ressourcensatzinformationen und Tickets stehlen.
  • Angreifer mit der Fähigkeit, die Obfuskation zu entschleiern, können sich Benutzeranmeldeinformationen verschaffen.
  • Angreifer können sich als XenDesktop-Controller ausgeben und Authentifizierungsanforderungen abfangen.

Bei den meisten Organisationen ist der Citrix XML-Datenverkehr in einem dedizierten physischen oder virtuellen Datencenter-Netzwerk isoliert und ein Abfangen unwahrscheinlich. Aus Sicherheitsgründen sollten Sie jedoch die SSL-Verschlüsselung verwenden, um StoreFront-Daten über eine sichere HTTP-Verbindung zu senden.

Entscheidung: Serverbetriebssystem-Lastverwaltung

Standardrichtlinien für die Lastverwaltung werden auf alle Serverbetriebssystem-Bereitstellungsgruppen angewendet. In den Standardeinstellungen wird die maximale Anzahl von Sitzungen, die ein Server hosten kann, mit 250 angegeben, die CPU- und Speicherauslastung werden nicht berücksichtigt. Die Obergrenze der Sitzungszahl liefert keinen echten Hinweis auf die Last, was zu einer Überlastung der Serverbetriebssystem-Bereitstellungsgruppen und in der Folge zu einer Leistungsverschlechterung führen kann oder aber zu einer Unterauslastung der Serverbetriebssystem-Bereitstellungsgruppen und einer ineffizienten Ressourcennutzung.

Citrix Consulting empfiehlt, auf Grundlage von Leistungs- und Skalierbarkeitstests für jede Bereitstellungsgruppe eigene Lastverwaltungsrichtlinien zu erstellen. Je nach den Ressourcenengpässen, die bei den Tests festgestellt wurden, können für jede Bereitstellungsgruppe unterschiedliche Regeln und Schwellenwerte angewendet werden. Weitere Informationen zu den Richtlinienkonfigurationen für die Lastverwaltung finden Sie in der Citrix Dokumentation unter Einstellungen der Richtlinie “Lastverwaltung”.

Wenn keine ausreichenden Tests vor der Produktion durchgeführt werden können, empfiehlt Citrix Consulting die Implementierung der folgenden “benutzerdefinierten” Lastverwaltungsrichtlinie, die auf alle Server als Grundlinie angewendet werden kann:

  • CPU-Auslastung: Volllast: 80 %
  • CPU-Nutzung ausschließlich Prozesspriorität: Unter normal oder Niedrig
  • Speicherauslastung: Volllast: 80 %
  • Speichernutzung - Ausgangslast: Nulllast (MB) melden: 786
  • Sitzungshöchstanzahl: X

Die Richtlinie “Sitzungshöchstanzahl” wird für Deckelungszwecke verwendet, dies gilt als bewährte Methode für Resilienz. Organisationen können als Anfangswert 250 (= X oben) wählen. Es wird dringend empfohlen, diesen und andere Werte basierend auf den Ergebnissen von Skalierbarkeitstests anzupassen.

Cloud Connector

Der XenApp und XenDesktop Service in Citrix Cloud verwendet eine Reihe von Diensten, die im Citrix Cloud Connector enthalten sind. Ein redundanter Satz virtueller Cloud Connector-Maschinen muss in jedem Datencenter bzw. an jedem Ressourcenstandort mit VDA-Hosts platziert werden.

Entscheidung: Serverdimensionierung

Die Cloud Connector-Skalierbarkeit basiert auf der CPU-Auslastung. Je mehr Prozessorkerne verfügbar sind, desto mehr virtuelle Desktops kann ein Cloud Connector unterstützen. Jede Start-, Registrierungs-, Enumerations- und Startanforderung eines Desktops wirkt sich auf den Prozessor des Cloud Connectors aus. Je mehr Anforderungen, umso größer die CPU-Auslastung des Cloud Connectors. Erreicht die CPU den kritischen Schwellenwert von etwa 80 %, muss die Site vertikal oder horizontal skaliert werden.

Tests haben gezeigt, dass ein Cloud Connector-Controller mit der folgenden Konfiguration 5.000 Desktops unterstützen kann.

Komponente On-Premises-Spezifikationen Spezifikationen für Hosting mit Azure
Anzahl der VMs (mit N+1 Fehlertoleranz) 3 6 Standard_A2_V2-Instanzen
Prozessoren pro VM 4 vCPUs 2 vCPU
Arbeitsspeicher pro VM 4 GB RAM 4 GB RAM
Hostspeicher pro VM 40 GB freigegebener Speicher 200 GB Temp-Speicher
Betriebssystem Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) verwendet Streamingtechnologie, um die Bereitstellung virtueller und physischer Maschinen zu vereinfachen. Das Provisioning und Neuprovisioning von Computern kann so in Echtzeit von einem einzigen freigegebenen Datenträgerimage erfolgen. Administratoren müssen damit nicht mehr einzelne Systeme verwalten oder patchen. Die gesamte Imageverwaltung erfolgt auf dem Masterimage.

Entscheidung: Topologie

Eine Provisioning Services-Farm stellt die oberste Ebene der Provisioning Services-Infrastruktur dar, die weiter in Sites unterteilt werden kann. Alle Provisioning-Server in einer Farm verwenden dieselbe SQL-Datenbank und denselben Citrix Lizenzserver.

Jede Site bildet eine logische Entität mit Provisioning-Servern, vDisk-Pools und Zielgerätesammlungen. Obwohl alle Sites einer Farm dieselbe Datenbank verwenden, können Zielgeräte nur ein Failover auf andere Provisioning-Server in der gleichen Site durchführen.

Abbildung der PVS-Sitestruktur

Bei der Bestimmung der allgemeinen Provisioning Services-Topologie müssen diverse Faktoren berücksichtigt werden:

  • Netzwerk: Provisioning-Server kommunizieren ständig mit der Farmdatenbank, um Systemkonfigurationseinstellungen abzurufen. Daher müssen für alle physischen Standorte mit Zielgeräten separate Farmen erstellt werden, es sei denn, sie sind über eine schnelle und stabile Verbindung mit dem Datenbankserver verbunden.
  • Verwaltung: In manchen Organisationen müssen Verwaltungsaufgaben in Abteilungen, Regionen oder Ländern getrennt werden. Zusätzliche Provisioning Services-Farmen führen zu mehr Komplexität bei der Verwaltung der Umgebung. Dieser Mehraufwand beschränkt sich jedoch in der Regel auf die Erstkonfiguration, die Desktoperstellung und Imageupdates.
  • Organisation: Ein praktischer Grund für den Aufbau mehrerer Sites können organisatorische Veränderungen sein. Das ist beispielsweise der Fall, wenn zwei Unternehmen fusioniert haben, ihre Ressourcen jedoch während der Integration getrennt halten müssen. Durch Konfigurieren separater Sites ist eine Trennung der Unternehmen unter zentraler Verwaltung über die Provisioning Services-Konsole möglich.

Erstellen Sie nur zusätzliche Sites, wenn die geschäftlichen Anforderungen dies rechtfertigen. Eine einzelner Site pro Farm ist einfacher zu verwalten und erfordert keine zusätzliche Konfiguration.

Entscheidung: Gerätesammlungen

Mit Gerätesammlungen erstellen und verwalten Sie logische Zielgerätegruppen. Das Erstellen von Gerätesammlungen erleichtert die Geräteverwaltung, da die Aktionen auf Sammlungsebene anstatt auf Zielgerätebene durchgeführt werden können.

Abbildung einer Gerätesammlungsstruktur

Gerätesammlungen können physische Standorte, Subnetzbereiche, Gehäuse oder Abteilungen einer Organisation abbilden. Über Sammlungen können auch Produktionszielgeräte logisch von Test- und Wartungsgeräten getrennt werden.

Gerätesammlungen sollten ggf. basierend auf der vDisk-Zuweisung erstellt werden, damit der Status aller einer vDisk zugewiesenen Zielgeräte schnell identifiziert werden kann.

Entscheidung: hohe Verfügbarkeit

Provisioning Services sind eine wichtige Komponente der virtuellen Desktopinfrastruktur. Die folgenden Empfehlungen sollten befolgt werden, um zentrale Ausfallpunkte zu vermeiden:

  • Provisioning-Server: Pro Site sollten mindestens zwei Provisioning-Server implementiert werden. Das Design muss über ausreichende Redundanz verfügen, damit die Gesamtzahl der Zielgeräte, die pro Site unterstützt werden können, nicht durch den Ausfall eines einzelnen Servers reduziert werden kann. Die Provisioning Services-Startdatei sollte für hohe Verfügbarkeit konfiguriert werden. In der Startdatei können bis zu vier Provisioning-Server aufgeführt werden. Die Zielgeräte versuchen, die Server in der Reihenfolge zu kontaktieren, in der sie aufgeführt sind. Der antwortende Server ist nicht unbedingt derjenige, der Streamingdienste für das Zielgerät bereitstellt. Ist Lastenausgleich aktiviert, können Zielgeräte einem anderen Server in der Site zugewiesen werden, dessen Last geringer ist.
  • vDisks und Speicher: Für vDisks in einem DAS (Direct Attached Storage) oder einem SAN (Storage Area Network) sollte die Replikation zur Speichersynchronisierung verwendet werden. Bei Verwendung von NAS (Network Attached Storage) stellen Sie sicher, dass die vDisks in einer hoch verfügbaren Netzwerkfreigabe gehostet werden.
  • Netzwerk: Provisioning-Server müssen redundante Netzwerkkarten besitzen. Wird ein Provisioning-Server als physischer Server bereitgestellt, sollten redundante Netzwerkkarten im Team verwendet werden, wird er als virtueller Server bereitgestellt, dann sollte der Hypervisor redundante Netzwerkkarten enthalten.

Hinweis

Zielgeräte führen nur ein Failover auf diejenigen Netzwerkkarten durch, die sich in demselben Subnetz wie die Netzwerkkarte für den PXE-Startvorgang befinden.

Trivial File Transfer Protocol (TFTP) ist ein Kommunikationsprotokoll, das für die Übertragung von Konfigurations- oder Startdateien zwischen Maschinen verwendet wird. Provisioning Services kann TFTP zur Bereitstellung der Bootstrapdatei auf Zielgeräten verwenden. Es stehen mehrere Optionen zur Verfügung, um den TFTP-Dienst hoch verfügbar zu machen. Gängige Optionen:

  • DNS-Roundrobin: Für den TFTP-Dienst wird ein DNS-Eintrag mit A-Einträgen erstellt, die den TFTP-Diensten entsprechen, die auf den Provisioning-Servern in der Farm ausgeführt werden. Diese Methode wird nicht empfohlen, da der Zustand des TFTP-Diensts nicht überwacht wird. Clients könnten daher an einen nicht funktionierenden Server gesendet werden.
  • Hardware-Load-Balancer: Mit einem Hardware-Load-Balancer wie etwa Citrix NetScaler erstellen Sie virtuelle IPs erstellen, die den Provisioning-Servern entsprechen. NetScaler kann Datenverkehr dann zwischen den Provisioning-Servern verteilen. Fällt ein Server aus, routet NetScaler keine TFTP-Anforderungen mehr an diesen Server. Dies ist die beste Methode, um TFTP hoch verfügbar zu machen, die Einrichtung kann aber kompliziert sein.
  • Mehrere DHCP-Option 66-Einträge: Diese Methode ist einfach zu implementieren, erfordert jedoch einen DHCP-Dienst, der die Eingabe mehrerer Einträge in Option 66 unterstützt. Der Microsoft-DHCP-Server lässt einen Option-66-Eintrag zu, daher ist die Methode in Umgebungen mit Microsoft DHCP nicht geeignet. Wenn Sie einen DHCP-Server oder eine DHCP-Appliance eines anderen Herstellers als Microsoft verwenden, bringen Sie bei diesem in Erfahrung, ob mehrere Option-66-Einträge unterstützt werden.

Es gibt weitere Optionen, die das gleiche Ergebnis ohne Einsatz von TFTP erzielen:

  • Proxy-DHCP: Verwenden Sie den PXE-Dienst des Provisioning-Servers, um die Bootstrapinformationen bereitzustellen. Fällt ein Server aus, kann der nächste verfügbare Server in der Farm die Bootstrapinformationen bereitstellen. Bei dieser Methode müssen sich die Provisioning-Server in derselben Broadcastdomäne befinden wie die Zielgeräte. Wenn andere PXE-Dienste im Netzwerk ausgeführt werden (Altiris, SCCM usw.), sind ggf. mehrere VLANs erforderlich, um zu verhindern, dass sich die PXE-Dienste gegenseitig stören.
  • Startgerätmanager: Erstellen Sie mit dem Startgerätmanager eine Bootstrapdatei, die entweder auf der lokalen Festplatte abgelegt oder als bootfähige ISO-Datei verwendet wird. Wenn die ISO-Datei verwendet wird, konfigurieren Sie die Zielgeräte so, dass sie vom CD-/DVD-ROM-Laufwerk gestartet werden, und speichern Sie die ISO-Datei an einem hoch verfügbaren freigegebenen Netzwerkspeicherort oder im lokalen Speicher jedes Zielgeräts. Bei Einsatz einer der beiden Methoden wird der TFTP-Dienst nicht verwendet.

Hohe Verfügbarkeit muss immer in das Provisioning Services-Design integriert werden. Hohe Verfügbarkeit erfordert zwar ggf. zusätzliche Ressourcen und verursacht höhere Kosten, sie bietet jedoch eine stabile Umgebung, in der die Benutzer bei Dienstausfällen nur minimale Auswirkungen erfahren.

Entscheidung: Bootstrapbereitstellung

Zielgeräte laden beim Starten zunächst ein spezielles Bootstrapprogramm, das die Streamingsitzung zwischen Zielgerät und Provisioning-Server initiiert. Es gibt drei Methoden, wie ein Zielgerät das Bootstrapprogramm empfangen kann:

Verwenden von DHCP-Optionen:

  1. Wenn das Zielgerät gestartet wird, sendet es einen Broadcast zur Anforderung der IP-Adresse und Startinformationen. DHCP verarbeitet die Anforderung und stellt eine IP sowie die Bereichsoptionseinstellungen 66 (Name oder IP-Adresse des Provisioning Services-TFTP-Servers) und 67 (Name der Bootstrapdatei) bereit.

    Hinweis

    Bei Verwendung eines Load Balancers für den TFTP-Dienst wird dessen Adresse in Option 66 eingegeben.

  2. Eine Anforderung für die Bootstrapdatei wird mit TFTP vom Zielgerät an den Provisioning-Server gesendet. Das Zielgerät lädt die Startdatei vom Provisioning-Server herunter.

  3. Das Zielgerät startet das zugewiesene vDisk-Image.

Hinweis

UDP/DHCP Helper muss konfiguriert werden, wenn sich Zielgeräte nicht im selben Subnetz wie die DHCP-Server befinden, damit letztere PXE-Broadcasts empfangen.

Verwendung von PXE-Broadcasts:

  1. Wenn ein Zielgerät über das Netzwerk gestartet wird, sendet es einen Broadcast zur Anforderung einer IP-Adresse und von Startinformationen. DHCP verarbeitet diese Anforderung und stellt eine IP-Adresse bereit. Darüber hinaus geben alle Provisioning-Server, die den Broadcast empfangen, Informationen zum Startserver und zum Namen der Startdatei zurück. Das Zielgerät führt die empfangenen Informationen zusammen und beginnt den Startvorgang.

  2. Eine Anforderung für die Bootstrapdatei wird per TFTP vom Zielgerät an den Provisioning-Server gesendet, der zuerst geantwortet hat. Das Zielgerät lädt die Startdatei vom Provisioning-Server herunter.

Hinweis

  • Stellen Sie sicher, dass keine anderen PXE-Dienste (z. B. Altiris PXE) im selben Subnetz verwendet werden, oder isolieren Sie solche Dienste mithilfe von VLANs, da sonst Konflikte mit Provisioning Services auftreten können.
  • UDP/DHCP Helper muss konfiguriert werden, wenn sich Zielgeräte nicht im selben Subnetz wie die DHCP- und PVS-Server befinden, damit die Server PXE-Broadcasts empfangen.

Verwenden des Startgerätmanagers: Der Startgerätmanager (BDM) erstellt eine Startdatei, die den Zielgeräten über eine CD/DVD, ein ISO-Image oder eine zugewiesene virtuelle Festplatte bereitgestellt wird. Eine BDM-Partition kann auf dreierlei Weise aktualisiert werden:

  • Über die Sammlung
  • Über eine Gruppe markierter Geräte
  • Für ein Gerät

Eine Zusammenfassung der Vor- und Nachteile jeder Bereitstellungsmethode ist in der folgenden Tabelle aufgeführt:

Bereitstellungsmethoden Vorteile Nachteile
DHCP-Optionen Einfach zu implementieren Erfordert Änderungen am DHCP-Dienst in der Produktion. Der DHCP-Dienst lässt ggf. nur einen Option-66-Eintrag zu. Erfordert UDP/DHCP Helper für Zielgeräte, die in einem anderen Subnetz sind.
PXE Einfach zu implementieren Konflikt mit anderen PXE-Diensten im selben Subnetz möglich. Erfordert UDP/DHCP Helper für Zielgeräte, die in einem anderen Subnetz sind.
BDM-ISO Erfordert kein PXE oder TFTP Mehraufwand für den Start physischer Zielgeräte. BDM-ISO ist zentraler Ausfallpunkt, wenn nur eine Datei verwendet wird.
BDM-Partition Das Upgrade der BDM-Startpartition erfordert kein PXE, TFTP oder TSB. Es ist ein Einphasen-Bootloader, beim Starten werden automatisch alle relevanten PVS-Serverinformationen gefunden und keine externen, von PXE, TFTP oder TSB bereitgestellten Dienste benötigt. Für jedes Zielgerät wird eine zusätzliche 8-MB-Partition erstellt.

Hinweis

Bei der Konfiguration der Bootstrapdatei können bis zu vier Provisioning-Server aufgelistet werden. Die Reihenfolge, in der die Provisioning-Server in der Liste erscheinen, bestimmt die Reihenfolge, in der auf die Provisioning-Server zugegriffen wird. Wenn der erste Server nicht antwortet, wird der nächste Server in der Liste kontaktiert.

Entscheidung: vDisk Format

Provisioning Services unterstützt die Verwendung von vDisks mit fester und mit dynamischer Größe:

  • vDisks mit fester Größe: Bei vDisks im privaten Modus verhindert eine feste Größe die Fragmentierung und bietet eine im Vergleich zu vDisks mit dynamischer Größe überlegene Schreibleistung.
  • vDisks mit dynamischer Größe: Solche vDisks benötigen weniger Speicherplatz als vDisks mit fester Größe, sie bieten jedoch eine deutlich geringere Schreibleistung. Auf vDisks im Modus “Shared Image” finden zwar keine Schreibvorgänge statt, bei vDisks mit dynamischer Größe dauern Zusammenführungsvorgänge jedoch länger. Dies kommt nicht oft vor, da in immer mehr Umgebungen bei Aktualisierungen neue vDisks erstellt werden.

Da die meisten Lesevorgänge am Systemcache im RAM erfolgen, gibt es keine signifikanten Leistungsunterschiede bei vDisks mit fester und dynamischer Größe. vDisks mit dynamischer Größe erfordern darüber hinaus deutlich weniger Speicherplatz. Daher werden vDisks mit dynamischer Größe empfohlen.

Entscheidung: vDisk-Replikation

vDisks, die in einem lokalen DAS (Direct Attached Storage) oder in einem SAN gehostet werden, müssen bei jeder Erstellung oder Änderung einer vDisk zwischen vDisk-Speichern repliziert werden. Provisioning Services unterstützt die Replikation von vDisks aus Provisioning-Server-lokalen Speichern und eine Replikation über mehrere Sites hinweg, die Speicher gemeinsam verwenden. Die Replikation von vDisks kann manuell oder automatisch erfolgen:

  • Manuell: Die manuelle Replikation ist einfach, kann jedoch je nach Anzahl der vDisk- und vDisk-Speicher zeitaufwendig sein. Wenn während des Replikationsprozesses ein Fehler auftritt, können Administratoren diesen sofort erkennen und Schritte zur Behebung ergreifen. Das Risiko einer manuellen Replikation besteht in vDisk-Inkonsistenz auf den Provisioning-Servern, was dazu führt, dass Lastausgleich und Failover nicht ordnungsgemäß funktionieren. Beispiel: Wenn eine vDisk über drei Server repliziert wird und dann eine vDisk aktualisiert wird, ist diese vDisk nicht mehr identisch und wird bei einem Serverfailover nicht berücksichtigt. Selbst wenn dasselbe Update an den anderen zwei vDisks ausgeführt wird, ist der Zeitstempel unterschiedlich und daher sind die vDisks nicht mehr identisch.
  • Automatisch: In großen Umgebungen ist die automatische Replikation aufgrund der Anzahl der erforderlichen vDisks und vDisk-Speicher schneller als die manuelle. Einige automatisierte Tools, wie z. B. Microsoft DFS-R unterstützen Bandbreiteneinschränkung und CF-RDC (Cross File Remote Differential Compression), wobei per Heuristik ermittelt wird, ob Zieldateien der zu replizierenden Datei ähneln. In diesem Fall verwendet CF-RDC Blöcke aus diesen Dateien, um die Menge der über das Netzwerk übertragenen Daten zu minimieren. Das Risiko einer automatisierten Replikation besteht darin, dass der Administrator die Replikation in der Regel nicht in Echtzeit überwacht und bei einem Fehler nicht schnell reagiert, es sei denn, das Automatisierungstool bietet ein Warnfeature. Manche Tools können so konfiguriert werden, dass der Kopiervorgang im Fehlerfall automatisch neu gestartet wird. Robocopy unterstützt beispielsweise “Kopieren wiederaufnehmen”, falls die Netzwerkverbindung unterbrochen wird.

Verwenden Sie für mittlere und große Projekte ein Tool, um die vDisk-Replikation zu automatisieren. Wählen Sie ein Tool, das nach Netzwerkunterbrechungen die Kopie wiederaufnehmen kann, Dateiattribute kopiert und den ursprünglichen Zeitstempel beibehält.

Hinweis

Lastausgleich und hohe Verfügbarkeit funktionieren nur, wenn vDisks identische Zeitstempel haben.

Entscheidung: Serverdimensionierung

Für Provisioning-Server gilt in der Regel folgende Spezifikation:

Komponente Spezifikation
Modell Virtuell
Prozessor 4–8 vCPUs
Speicher 2 GB + (Anzahl vDisks * 2 GB)
Netzwerk 10-Gbit/s-NIC
Netzwerk 40 GB freigegebener Speicher
vDisk-Speicher Abhängig von der Anzahl der Images/Revisionen
Betriebssystem Windows Server 2012 R2

Modell

Citrix Provisioning Services kann auf virtuellen und physischen Servern installiert werden:

  • Virtuell: Bietet schnelle Serverbereitstellung, Snapshots für schnelle Wiederherstellung bzw. schnelles Rollback und die Möglichkeit, Serverressourcen ad hoc anzupassen. Virtuelle Provisioning-Server ermöglichen die Verteilung von Zielgeräten auf mehr Server, wodurch die Auswirkungen von Serverausfällen verringert werden können. Durch Virtualisierung werden Systemressourcen effizienter genutzt.
  • Physisch: Bietet mehr Skalierbarkeit pro Server als bei virtuellen Servern. Bei physischen Provisioning-Servern werden die Risiken, die durch das Konkurrieren virtueller Maschinen um Hypervisor-Ressourcen entstehen können, vermieden. Im Allgemeinen werden virtuelle Provisioning-Server bevorzugt, wenn ausreichende Prozessor-, Arbeitsspeicher-, Datenträger- und Netzwerkressourcen verfügbar sind und ihre Verfügbarkeit gewährleistet ist.

Hinweis

Stellen Sie für hohe Verfügbarkeit sicher, dass virtuelle Provisioning-Server auf mehrere Virtualisierungshosts verteilt sind. Durch die Verteilung der virtuellen Server auf mehrere Hosts werden zentrale Ausfallpunkte vermieden, sodass bei einem Hostausfall nicht die gesamte Provisioning Services-Farm ausfällt.

CPU

Provisioning Services ist nicht CPU-intensiv. Ein Zuweisung von zu wenigen CPUs wirkt sich jedoch negativ auf die Optimierung der Netzwerkstreams aus. Die Anzahl Netzwerkstreams, die ein Provisioning Services-Server gleichzeitig ausführen kann, kann anhand der folgenden Formel ermittelt werden:

Maximale Anzahl der Streams = Anzahl der Ports x Anzahl der Threads/Port

Standardmäßig ist der Streamingdienst mit 20 sequentiellen Netzwerkports und 8 Threads pro Port konfiguriert. Daher kann ein Provisioning-Server standardmäßig 160 gleichzeitige Ziele unterstützen. Wenn mehr als 160 Streams erforderlich sind, wechselt Provisioning Services kontinuierlich zwischen dem Streaming verschiedener Zielgeräte.

Für Umgebungen, die über 160 Ziele unterstützen müssen, kann die Anzahl der Ports und Threads pro Port in der Provisioning Services-Konsole angepasst werden. Die beste Leistung wird erreicht, wenn die Anzahl der Threads pro Port die Anzahl der Kerne des Provisioning-Servers nicht übersteigt. Wenn der Provisioning-Server nicht über ausreichend Kerne verfügt, erfährt er eine höhere CPU-Auslastung und bei Zielgeräten, die auf die Verarbeitung von Anforderungen warten, ist die Leselatenz höher.

Provisioning Services ist zwar nicht CPU-intensiv, doch die Zuweisung von 2 CPUs erfordert einen größeren zusammenhängenden Bereich an Netzwerkports.

  • Für kleine Umgebungen (bis zu ca. 500 virtuelle Maschinen) werden 4 vCPUs empfohlen.
  • Für größere Umgebungen werden 8 vCPUs empfohlen.

RAM

Das Windows-Betriebssystem, das Provisioning Services hostet, speichert die vDisks teilweise im RAM (Systemcache), wodurch die Anzahl Lesevorgänge aus dem Speicher reduziert wird. Das Lesen aus dem Speicher ist deutlich langsamer als das Lesen aus dem RAM. Daher muss Provisioning-Servern ausreichend RAM zugewiesen werden, um den Nutzen dieses Cachingprozesses zu maximieren.

Die optimale RAM-Größe für Provisioning-Server kann anhand der folgenden Formel berechnet werden:

𝑆𝑒𝑟𝑣𝑒𝑟-𝑅𝐴𝑀 gesamt = 2 𝐺𝐵 + (Anzahl 𝑣𝐷𝑖𝑠𝑘𝑠 ∗ 2 𝐺𝐵)

Netzwerk

Im Gegensatz zu den meisten anderen XenApp und XenDesktop-Komponenten führt Provisioning Services nicht zu CPU-Engpässen. Die Skalierbarkeit von Provisioning Services basiert auf dem Netzwerkdurchsatz.

Die folgende Tabelle enthält die ungefähre Datenmenge, die Provisioning Services zum Starten verschiedener Betriebssysteme benötigt:

Betriebssystem Durchschnittliche Datennutzung beim Starten (MB)
Windows 10 x64 240
Windows 8 x86 178
Windows 8 x64 227
Windows 7 x86 166
Windows 7 x64 210
Windows 2012 225
Windows 2012 R2 232
Windows 2008 R2 251
Windows Vista x86 190
Windows Vista x64 240

Die zum Starten der Zielgeräte benötigte Zeit kann anhand der folgenden Formel geschätzt werden:

Abbildung der Formel zur Berechnung der Startdauer

Betriebssystem Anzahl VMs Netzwerkdurchsatz Startdauer
Windows 10 x64 500 1 Gbit/s 960 Sekunden (16 Minuten)
Windows 10 x64 500 10 Gbit/s 96 Sekunden (1 Minute, 36 Sekunden)

Für Provisioning Services wird ein 10-Gbit/s-Netzwerk empfohlen. Wenn kein 10-Gbit/s-Netzwerk verfügbar ist, sollten Sie die Verwendung der Verbindungsaggregation erwägen, um den Provisioning-Servern zusätzliche Bandbreite bereitzustellen, oder aber den Einsatz eines dedizierten physischen Streamingnetzwerks.

Tipp

Firewalls können die Latenz erhöhen und in Provisioning Services-Umgebungen Bandbreitenengpässe bewirken. Wenn die Verwendung von Firewalls nicht vermieden werden kann, finden Sie im Citrix Whitepaper CTX101810 (Communication Ports Used By Citrix Technologies) eine Liste der Ports, die für die volle Funktionalität aktiviert werden müssen.

Wachstum

Bei einem Wachstum der Farm müssen Administratoren entscheiden, ob den Provisioning-Servern mehr Ressourcen hinzugefügt oder der Farm weitere Provisioning-Server hinzugefügt werden sollen.

Ob Provisioning-Server horizontal oder vertikal skaliert werden sollten, hängt von diversen Umgebungsfaktoren ab:

  • Redundanz: Die Verteilung der Benutzerlast auf zusätzliche, weniger leistungsstarke Server verringert die Zahl der Benutzer, die von einem Ausfall eines Servers betroffen sind. Ist der Verlust eines Einzelservers mit hoher Spezifikation aus geschäftlichen Gründen nicht akzeptabel, sollte eine horizontale Skalierung in Betracht gezogen werden.
  • Failoverzeiten: Je mehr Zielgeräte mit einem einzelnen Provisioning-Server verbunden sind, desto länger dauert das Failover, wenn der Server ausfällt. Mit einer horizontalen Skalierung kann das Failover von Zielgeräten beschleunigt werden.
  • Datencenterkapazität: Das Datencenter verfügt möglicherweise über wenig Platz, Strom und/oder Kühlung. Ziehen Sie in diesem Fall eine vertikale Skalierung in Betracht.
  • Hardwarekosten: Eine vertikale Skalierung kann anfänglich kostengünstiger sein. Es wird jedoch ein Punkt erreicht, an dem die horizontale Skalierung kostengünstiger wird. Um diesen Punkt zu bestimmen, ist eine Kostenanalyse erforderlich.
  • Hostingkosten: Je nach Anzahl der physischen Server können Hosting- und/oder Wartungskosten entstehen. In diesem Fall sollten Sie eine vertikale Skalierung in Betracht ziehen, um die langfristigen Kosten in diesem Bereich zu senken.

Entscheidung: Netzwerkkonfiguration

Wie bereits erwähnt, muss das Netzwerk korrekt dimensioniert werden, um Engpässe, die hohe Festplattenzugriffszeiten verursachen und sich direkt auf die Leistung des virtuellen Desktops auswirken, zu vermeiden. Die folgende Abbildung zeigt eine gängige Provisioning Services-Netzwerkinfrastruktur:

Abbildung einer PVS-Netzwerkkonfiguration

Die folgende Netzwerkkonfiguration wird für die im Diagramm gezeigten Netzwerkabschnitte empfohlen:

  • PVS-Uplink: Der gesamte Datenträgerzugriff von den Zielgeräten wird über den PVS-Netzwerkuplink übertragen. Das bedeutet, dass hunderte oder sogar tausende Geräte diese Netzwerkverbindung verwenden. Daher muss diese Verbindung redundant und ein Failover ohne Ausfallzeiten möglich sein. Darüber hinaus empfiehlt Citrix eine Mindestbandbreite von 1 Gbit/s pro 500 Zielgeräte. Für virtuelle Provisioning-Server muss ein entsprechendes QoS-Kontingent oder ein dedizierter physischer Netzwerkuplink konfiguriert werden, um eine optimale Leistung zu gewährleisten.
  • Hypervisor-Uplink: Wird von allen PVS-Zielgeräten verwendet, die auf einem Hypervisor-Host gehostet werden. Daher wird dringend eine Redundanz mit transparentem Failover empfohlen. Wenn die Zielgeräte keine E/A-intensive Arbeitslast oder E/A-intensive Tasks (z. B. Starten) gleichzeitig ausführen, reicht für diesen Uplink eine Bandbreite von 1 Gbit/s aus.
  • VM-Uplink: Der gesamte Netzwerkverkehr einer virtuellen Maschine, einschließlich PVS-Streamingdatenverkehr, läuft über diese virtuelle Netzwerkverbindung. Sofern die Arbeitslast nicht extrem E/A-intensiv ist, reicht eine Bandbreite von 100 Mbit/s selbst für Spitzenlasten bei E/A-intensiven Tasks wie dem Starten von vDisk aus. Beispielsweise liest ein Windows 2012 R2-Server in einem Zeitraum von 90 Sekunden ungefähr 232 MB von einer vDisk, bis der Windows-Anmeldebildschirm angezeigt wird. In dieser Zeit beträgt die durchschnittliche Datenrate 20,5 Mbit/s mit Spitzen von bis zu 90 Mbit/s.

Folgende Switcheinstellungen werden für Provisioning Services empfohlen:

  • Disable Spanning Tree oder Enable PortFast: In einer Switchingumgebung versetzt das Spanning Tree Protocol (STP) Ports in einen blockierten Zustand, während es BPDUs (Bridged Protocol Data Units) überträgt, und überwacht, dass sich die BPDUs nicht in einer Loopback-Konfiguration befinden. Der Port wird erst in einen Weiterleitungszustand versetzt, wenn das Netzwerk konvergiert, was abhängig von der Größe des Netzwerks möglicherweise so lange dauert, dass PXE-Timeouts auftreten. Um dieses Problem zu beheben, deaktivieren Sie STP für mit Clients verbundene Edgeports oder aktivieren Sie PortFast.
  • Storm Control: Storm Control ist ein Feature von Cisco Switches zum Festlegen eines Schwellenwerts, bei dem Multicast-, Broadcast- oder Unicast-Verkehr unterdrückt werden kann. Dies soll böswillige oder fehlerhafte Absender daran hindern, ein LAN zu überschwemmen und die Netzwerkleistung zu beeinträchtigen. PVS-Server senden große Datenmengen, die einen Storm Control-Schwellenwert überschreiten können. Daher muss dieses Feature entsprechend konfiguriert werden.
  • Broadcast Helper: Der Broadcast Helper ist erforderlich, um Broadcasts von Clients auf Server zu leiten, die sonst nicht weitergeleitet würden. In einer PVS-Umgebung müssen PXE-Startanforderungen weitergeleitet werden, wenn Clients sich nicht im selben Subnetz wie die Server befinden. Nach Möglichkeit sollten PVS-Server im selben Subnetz sein wie die Zielgeräte. Dadurch wird das Risiko einer Dienstverschlechterung durch andere Netzwerkinfrastrukturkomponenten verringert.

Die folgenden Netzwerkschnittstellenfeatures sollten bei der Auswahl einer Netzwerkschnittstelle für Provisioning Services berücksichtigt werden:

  • TCP-Abladung: Die Abladung von E/A-Tasks an die Netzwerkschnittstelle vermindert die CPU-Auslastung und verbessert die Gesamtsystemleistung. Wenn “Abladung großer Sendungen” aktiviert wird, kann sie sich jedoch aufgrund der zusätzlichen Last am Netzwerkadapter negativ auf den PVS-Streamingdienst auswirken. Bei vielen Netzwerkadaptern ist “Abladung großer Sendungen” und “TCP-Prüfsummenabladung” standardmäßig aktiviert.

Hinweis

Wenn “Abladung großer Sendungen” aktiviert ist und der Switch, den der Datenverkehr durchläuft, die von dem Modul gesteuerte Framegröße nicht unterstützt, lässt der Switch den Frame aus und es kommt zu einer erneuten Datenübertragung. Bei der erneuten Übertragung segmentiert das Betriebssystem die Frames anstelle des Netzwerkadapters, was zu schweren Leistungseinbußen führen kann.

  • Empfangsseitige Skalierung: Mit diesem Feature können von einem Netzwerkadapter empfangene Pakete über mehrere CPUs verteilt werden. Dadurch ist ein Lastausgleich eingehender TCP-Verbindungen und das Verhindern von Engpässen an einzelnen CPUs möglich. In Windows Server 2008 R2 und Windows Server 2012/2012 R2 ist die empfangsseitige Skalierung standardmäßig aktiviert.

Hinweis

Weitere Informationen zu bewährten Methoden bei der Netzwerkkonfiguration für PVS Sie unter Best Practices for Configuring Provisioning Services Server on a Network.

Bei Provisioning Services-Implementierungen in Netzwerken mit geringer Bandbreite (bis 1 Gbit/s) kann die Leistung verbessert werden, indem der Streamingdatenverkehr vom anderen Netzwerkverkehr im LAN isoliert wird.

Microsoft unterstützt kein NIC-Teaming mit Hyper-V unter Windows Server 2008 R2; Lösungen von Drittanbietern sind jedoch verfügbar. Microsoft unterstützt NIC-Teaming mit Hyper-V unter Windows Server 2012/2012 R2. Alle Support-Anfragen bezüglich Teaming und Hyper-V sind an den NIC-Hersteller zu richten.

Entscheidung: Subnet Affinity

Provisioning Services Subnet Affinity ist ein Lastausgleichalgorithmus, der sicherstellt, dass Zielgeräte mit dem bestgeeigneten Provisioning-Server verbunden werden. Beim Konfigurieren von Subnet Affinity stehen folgende Optionen zur Verfügung:

  • None: Ignoriert Subnetze und verwendet den am geringsten ausgelasteten Server.
  • Best Effort: Verwendet die am geringsten ausgelastete Server/Netzwerkkartenkombination in demselben Subnetz. Wenn im Subnetz keine Server/Netzwerkkartenkombination verfügbar ist, wird der am geringsten ausgelastete Server außerhalb des Subnetzes ausgewählt. Falls im ausgewählten Subnetz mehrere Server verfügbar sind, wird zwischen den Servern der Lastausgleich ausgeführt. Dies ist die Standardeinstellung.
  • Fixed: Verwendet die am geringsten ausgelastete Server/Netzwerkkartenkombination in demselben Subnetz. Führt den Lastausgleich zwischen den Servern im Subnetz aus. Wenn im selben Subnetz keine Server/Netzwerkkartenkombination vorhanden ist, werden die der vDisk zugewiesenen Zielgeräte nicht gestartet.

Die folgenden Beispiele zeigen gängige Netzwerkkonfigurationen für physische Provisioning-Server. Ähnliche Konfigurationen können für virtuelle Provisioning-Server implementiert werden, ohne dass die Leistung oder Funktionalität beeinträchtigt werden.

Blade-Design

Die Provisioning-Server und von ihnen unterstützte Zielgeräte befinden sich im selben Gehäuse. In den meisten Fällen besitzt das Gehäuse einen dedizierten 10-Gbit/s-Switch, der von allen Blade-Servern im Gehäuse gemeinsam genutzt wird.

Abbildung: Blade-Gehäuse

Die Subnet Affinity-Option “Best Effort” wird verwendet, um den Provisioning Services-Datenverkehr im Gehäuse zu halten. Fällt der Provisioning-Server aus, erfolgt ein Failover der Zielgeräte auf den zweiten Provisioning-Server im zweiten Gehäuse in derselben Provisioning Services-Site.

Rack-Design

Das zweite Beispiel basiert auf einem Rack-Design, in dem Rack-Switches eingesetzt werden, um den Provisioning-Datenverkehr im Rack zu behalten.

Abbildung: PVS-Rack-Design

Im Gegensatz zum Blade-Design wird das Subnet Affinity-Feature nicht verwendet. Stattdessen wird pro Server-Rack eine Provisioning Services-Site mit zwei Provisioning-Servern konfiguriert. Dadurch wird sichergestellt, dass das Streaming der Zielgeräte von Provisioning-Servern im gleichen Rack erfolgt.

Praxiserfahrung

Fertigung: Ein Fertigungbetrieb entwirft eine Provisioning Services-Lösung zur Unterstützung von fünftausend virtuellen Desktops. Es wird befürchtet, dass der Streaming-Datenverkehr von Provisioning Services einen Engpass im Netzwerk verursachen könnte, der sich auf andere Anwendungen auswirkt. Das Unternehmen entscheidet sich für die Nutzung von Blade-Servern, damit der Provisioning-Datenverkehr im Blade-Gehäuse verbleibt und sich nicht auf den anderen Datenverkehr im Netzwerk auswirkt.

Entscheidung: Lesecache

Mit PVS Accelerator kann ein PVS-Proxy in der XenServer-Steuerdomäne auf einem Host residieren, sodass das Streaming einer Provisioning Services-vDisk auf dem Proxy zwischengespeichert wird, bevor die Weiterleitung an die VM erfolgt. Mit dem Cache können nachfolgende Starts (bzw. jegliche E/A-Anforderungen) der virtuellen Maschine auf dem gleichen Host vom Proxy statt vom Server über das Netzwerk gestreamt werden. PVS Accelerator erfordert mehr lokale Ressourcen auf dem XenServer-Host, das Streaming vom Server über das Netzwerk spart jedoch Ressourcen, wodurch die Leistung verbessert wird.

Abbildung: PVS-Lesecache

PVS Accelerator ist nur unter XenServer verfügbar. Diese integrierte Technologie senkt die PVS-Serverlast, die Netzwerklast und den Zeitaufwand zum Starten einer virtuellen Maschine.

Abbildung: PVS Accelerator

Weitere Informationen über die Beziehung zwischen XenServer und Provisioning Services finden Sie im folgenden Blog: XenServer and PVS: Better Together.

Entscheidung: Schreibcache

Da Masterimages schreibgeschützt sind, besitzt jede virtuelle Maschine einen beschreibbaren Datenträger, auf dem alle Änderungen gespeichert werden können. Der Administrator muss entscheiden, wo der Schreibcachedatenträger gespeichert werden soll.

PVS-Server – lokaler Speicher

Der lokale Provisioning Services-Speicher enthält die Schreibcache-Laufwerke für jede virtuelle Zielmaschine. Dies ist zwar die Standardeinstellung, sie erhöht jedoch die Anforderungen an die Netzwerkbandbreite und die Last des Provisioning Services-Servers.

Abbildung: lokaler Speicher auf dem Server

PVS-Server – freigegebener Speicher

Dem Provisioning Services-Server zugewiesener freigegebener Speicher enthält die Schreibcache-Laufwerke für jede virtuelle Zielmaschine. Dies erhöht die Anforderungen an die Netzwerkbandbreite und die Last des Provisioning Services-Servers. Außerdem werden temporäre Daten (Schreibcache) auf kostspieligem freigegebenem Speicher platziert.

Abbildung: für den Server freigegebener Speicher

VM – lokaler Speicher

Der virtuellen Maschine zugewiesener lokaler Speicher enthält die Schreibcache-Laufwerke für jede virtuelle Zielmaschine. Es wird kostengünstiger lokaler Speicher genutzt und es werden keine zusätzlichen Ressourcen auf dem Provisioning Services-Server verbraucht. Der lokale Speicher muss jedoch die IOPS aller virtuellen Maschinen auf dem Host unterstützen.

Abbildung: lokaler Speicher der VM

VM – Cache im RAM

Der virtuellen Maschine zugewiesener RAM enthält die Schreibcache-Laufwerke für jede virtuelle Zielmaschine. Diese Option bietet eine hohe Leistung aufgrund der Geschwindigkeit von RAM. Wenn der RAM-Cache voll wird, wird die virtuelle Maschine allerdings unbrauchbar. Für diese Option müssen jeder virtuellen Maschine erhebliche Mengen RAM zugewiesen werden, was die Gesamtkosten erhöht.

Abbildung: VM – Cache im RAM

VM – Cache im RAM mit Überlauf auf Datenträger

Für den Schreibcache wird eine Kombination aus RAM und lokalem Speicher verwendet. Schreibvorgänge werden zunächst im RAM-Cache gespeichert, was eine hohe Leistung bietet. Wird der RAM-Cache voll, werden große Blöcke aus dem RAM-Cache auf den lokalen Schreibcache-Datenträger übertragen. Diese Option bietet hohe Leistung bei niedrigen Kosten dank lokalem Speichern.

Die Verwendung dieser integrierten Technologie reduziert Schreib-IOPS um 95 %.

Abbildung: VM – Cache im RAM

Cache im RAM mit Überlauf auf Datenträger ist die empfohlene Option.

Abbildung: VM – Cache im RAM

Entscheidung: Antivirensoftware

Standardmäßig scannen die meisten Antivirenprodukte alle Dateien und Prozesse, was sich erheblich auf die Leistung von Provisioning Services auswirkt. Informationen dazu, wie Antivirensoftware für Provisioning Services optimiert werden kann, finden Sie unter CTX124185 (Provisioning Services Antivirus Best Practices).

Antivirensoftware kann Probleme durch Sperren von Dateien auf Provisioning-Servern verursachen. Der vDisk-Speicher und der Schreibcache sollten von Antivirenscans ausgeschlossen werden, um Probleme mit gesperrten Dateien zu vermeiden.

Wenn ein virtueller Datenträger im Standardmodus ausgeführt wird und neu gestartet werden muss, werden alle zuvor geladenen Virendefinitionen heruntergeladen. Dies kann zu Leistungsverschlechterung führen, wenn mehrere Zielgeräte gleichzeitig neu gestartet werden, was häufig zu einem Netzwerkengpass während des Vorgangs führt. In extremen Fällen werden Zielgeräte und Provisioning-Server sehr langsam und verbrauchen mehr Ressourcen als nötig. Wenn die Antivirensoftware dies unterstützt, sollten Definitionsdateien auf das Schreibcache-Laufwerk umgeleitet werden, damit sie zwischen Neustarts beibehalten werden.

Maschinenerstellungsdienste

Maschinenerstellungsdienste (MCS) verwendet Technologie zum Klonen von Datenträgern zur Vereinfachung der Bereitstellung virtueller Maschinen. Das Provisioning und Neuprovisioning von Computern kann so in Echtzeit von einem einzigen freigegebenen Datenträgerimage erfolgen. Administratoren müssen damit nicht mehr einzelne Systeme verwalten oder patchen. Die gesamte Imageverwaltung erfolgt auf dem Masterimage.

Entscheidung: Speicherort

Mit den Maschinenerstellungsdiensten können Administratoren einen virtuellen Desktop in mehrere Komponenten aufteilen und diese auf verschiedenen Speicherarrays speichern.

Freigegebener Speicher

Die erste Option verwendet freigegebenen Speicher für den Betriebssystemdatenträger und den differenzierenden Datenträger.

Abbildung: freigegebener Speicher in MCS

Bei dieser Option kann das Masterimage zwar über mehrere Hypervisor-Hosts hinweg genutzt werden, die Last für das Speicherarray ist jedoch höher, da es auch den differenzierenden Datenträger, d. h. temporäre Daten, hosten muss.

Hybridspeicher

Die zweite Option verwendet freigegebenen Speicher für den Betriebssystemdatenträger und den lokalen Hypervisor-Speicher für den differenzierenden Datenträger.

Abbildung: Hybridspeicher in MCS

Dies ist die gebräuchlichste Option mit dem Vorteil, dass das Masterimage über mehrere Hypervisor-Hosts verteilt und teure temporäre Schreib-IOPS auf kostengünstigen lokalen Hypervisor-Speicher abgeladen werden.

XenServer IntelliCache-Speicher

Die dritte Option verwendet freigegebenen Speicher für den Betriebssystemdatenträger, den lokalen Hypervisor-Speicher für den differenzierenden Datenträger und den lokalen XenServer-Speicher für den lokalen Cache des Betriebssystemdatenträgers.

Diese Option ist nur für XenServer-Implementierungen verfügbar. Sie bietet den gleichen Wert wie der Hybridspeicher und reduziert zudem die Lese-IOPS des freigegebenen Speichers. IntelliCache kann mit dem XenServer-RAM-basierten Lesecache koexistieren, wenn der XenServer-RAM begrenzt ist.

Abbildung: IntelliCache in MCS

Entscheidung: Klontyp

Maschinenerstellungsdienste umfasst zwei Klontechniken.

  • Thin-Klons: Jede VM in einem Katalog verwendet einen einzelnen schreibgeschützten virtuellen Datenträger für alle Lesevorgänge. Für jede VM erfasst ein eigener zweiter virtueller Datenträger alle Schreib-E/A-Aktivitäten.
  • Vollständige Klons: Jede VM im Katalog erhält eine vollständige Kopie des Masterdatenträgerimages. Jede VM besitzt die Festplatte vollständig, wodurch Lese-/Schreibaktivitäten ermöglicht werden. Vollständiges Klonen ist nur für persönliche virtuelle Desktops verfügbar, auf denen eine dedizierte virtuelle Maschine alle Änderungen auf einem lokalen Datenträger speichert.

Bei der Entscheidung zwischen Thin-Klons und vollständigen Klons sollte Folgendes berücksichtigt werden:

  Thin-Klons Vollständige Klons
Speicherplatzbedarf Höchste Speicherplatzeinsparung. Ein einzelnes Masterdatenträgerimage wird für mehrere VMs verwendet. Nur der differenzierende Datenträger (Schreibvorgänge) verbraucht Speicherplatz, der wächst, bis die VM neu gestartet wird. Hoher Speicherplatzbedarf. Jede VM erhält eine vollständige Kopie des Masterimages. Die Größe nimmt zu, wenn Änderungen an der VM vorgenommen werden.
Backups/Wiederherstellung Schwierig. Viele Backuplösungen von Drittanbietern unterstützen keine Snapshot-/Delta-Datenträger. Thin-VMs können daher nur mit Mühe oder gar nicht gesichert oder auf andere Speicherarrays verschoben werden. Einfach. Die VM befindet sich auf einem virtuellen Datenträger, was die Backup und Wiederherstellung vereinfacht.
Provisioninggeschwindigkeit Schnell. Erfordert nur ein Datenträgerimage. Langsam (kann verbessert werden). Jede VM erfordert eine vollständige Kopie des Masterimages. Speicheroptimierungstechnologien können zur Verbesserung beitragen.
Leistung Langsamer. Lese-E/A-Vorgänge können zweimal erfolgen, einmal für den Masterdatenträger und einmal für den differenzierenden Datenträger, wodurch die Lese-IOPS erhöht werden. Schneller. Alle Lese-/Schreibvorgänge erfolgen direkt auf einem einzigen Datenträger.
Boot Storm Hohe Auswirkungen. Bei einem Boot Storm wird die Größe aller differenzierenden Datenträger so angepasst, dass alle Schreibvorgänge des Windows-Starts gespeichert werden können. Durch die Gleichzeitigkeit der Vorgänge wird der Speicher stark belastet. Geringe Auswirkungen.

Entscheidung: Lesecache

Während des Startens und der Anmeldung verursachen virtuelle Desktops viele Speicherlese-IOPS, die das Speichersubsystem stark belasten können. Bei der Bereitstellung unter Citrix XenServer verwenden freigegebene und gepoolte VDI einen RAM-basierten Lesecache, der auf jedem XenServer gehostet wird.

Abbildung: Lesecache in MCS

Die Verwendung dieser integrierten Technologie reduziert Lese-IOPS um 50–80 %.

Abbildung: Lesecacheraster in MCS

Entscheidung: Schreibcache

Im normalen Zustand verursachen virtuelle Desktops viele Speicherschreib-IOPS, die das Speichersubsystem stark belasten können. Freigegebene und gepoolte VDI können einen RAM-basierten Schreibcache verwenden, indem nicht ausgelagerter Pool-RAM des VM-Betriebssystems genutzt wird.

Abbildung: Schreibcache in MCS

Die Verwendung dieser integrierten Technologie reduziert Schreib-IOPS um 95 %.

Abbildung: Schreibcacheraster in MCS

Sicherheit

Der zu implementierende Sicherheitsstandard hängt von den gegebenen Anforderungen ab. Es ist ratsam, folgende Dokumentation zu konsultieren:

Designmethodik Steuerungslayer