Gestaltungsmethodik-Kontrollschicht

Hinweis

Dieser Artikel wurde maschinell übersetzt. Haftungsausschluss

Auf Englisch anzeigen

Die Kontrollschicht ist die vierte Ebene der Entwurfsmethode.

Active Directory

Entscheidung: Forest Design

Bereitstellungen mit mehreren Gesamtstrukturen verfügen standardmäßig nicht über domänenübergreifende Vertrauensstellungen zwischen den Gesamtstrukturen. Ein AD-Administrator kann Vertrauensstellungen zwischen den mehreren Gesamtstrukturen herstellen, sodass Benutzer und Computer aus einer Gesamtstruktur authentifizieren und auf Ressourcen in einer anderen Gesamtstruktur 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. Wenn die entsprechenden Vertrauensstellungen nicht konfiguriert sind, müssen für jede Gesamtstruktur mehrere XenDesktop-Sites konfiguriert werden. In diesem Abschnitt werden die Speicheranforderungen je Produkt beschrieben und die Dimensionierungsberechnungen bereitgestellt. Weitere Informationen finden Sie im Citrix-Artikel:CTX134971— Erfolgreiche Bereitstellung von XenDesktop in einer komplexen Active Directory-Umgebung

Entscheidung: Struktur der Organisationseinheit

Infrastrukturkomponenten für eine XenApp- und XenDesktop-Bereitstellung sollten sich innerhalb ihrer eigenen dedizierten Organisationseinheiten (OUs) befinden und Arbeitskräfte und Controller für Verwaltungszwecke voneinander trennen. Durch ihre eigenen Organisationseinheit haben die darin enthaltenen Objekte eine größere Flexibilität bei der Verwaltung, während Citrix Administratoren delegierte Kontrolle erhalten können.

Eine Beispielstruktur der Citrix OU ist unten zu sehen.

Citrix OU-Image

Entscheidung: Benutzergruppen

Wenn möglich, sollten Berechtigungen und Autorisierung Benutzergruppen anstelle einzelner Benutzer zugewiesen werden, wodurch beim Erstellen, Ändern oder Löschen von Benutzerkonten keine großen Mengen an Ressourcenberechtigungen und Benutzerrechten mehr bearbeitet werden müssen. Beispiel für die Berechtigungsanwendung:

  • Eine Anwendung, die für eine Gruppe von 1.000 Benutzern veröffentlicht wird, erfordert die Validierung von nur einem Objekt für alle 1.000 Benutzer.
  • Dieselbe Anwendung, die in 1.000 einzelnen Benutzerkonten veröffentlicht wurde, erfordert die Validierung aller 1.000 Objekte.

Datenbank

Für die meisten Citrix Produkte, die in diesem Dokument behandelt werden, ist eine Datenbank erforderlich. Die folgende Tabelle beschreibt die Verwendung pro Produkt:

In dieser Tabelle:

  • Y gleich “Verfügbar”.
  • O zeigt Optional an.
Produkt Konfigurationsdaten Laufzeitdaten Audit-/Änderungsprotokolldaten Überwachungsdaten
XenDesktop Y Y Y Y
Provisioning Services Y   O  
Desktop Player Y Y Y Y

Entscheidung: Edition

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

Die Standard-Edition bietet eine ausreichende Anzahl an Funktionen, um den Anforderungen der meisten Umgebungen gerecht zu werden. Weitere Informationen zu den Datenbanken, die mit Citrix Produkten unterstützt werden, finden Sie unterSupport-Matrix für Citrix Datenbanken. Verschiedene Versionen von Citrix Produkten unterstützen verschiedene Versionen des SQL-Servers. Daher ist es wichtig, die Support-Matrix zu überprüfen, um sicherzustellen, dass die Version des verwendeten SQL-Servers mit dem bereitgestellten Citrix Produkt kompatibel ist.

Entscheidung: Dimensionierung des Datenbankservers

Der SQL Server muss korrekt dimensioniert sein, um die Leistung und Stabilität einer Umgebung zu gewährleisten. Da jedes Citrix Produkt SQL Server auf andere Weise verwendet, können keine generischen, allumfassenden Dimensionsempfehlungen bereitgestellt werden. Stattdessen werden im Folgenden Empfehlungen zur Größenbestimmung von SQL Servern pro Produkt bereitgestellt.

XenApp und XenDesktop

XenApp und XenDesktop Broker verwenden die Datenbank als Nachrichtenbus für Broker-Kommunikation, speichern Konfigurationsdaten und speichern Überwachungs- und Konfigurationsprotokolldaten. Die Datenbanken werden ständig verwendet und die Leistungsauswirkung auf den SQL-Server kann als hoch angesehen werden.

Basierend auf Ergebnissen der internen Citrix Skalierbarkeitstests werden die folgenden SQL Server-Spezifikationen für einen Server empfohlen, der alle XenDesktop-Datenbanken hostet:

  • 2 Kerne / 4 GB RAM für Umgebungen mit bis zu 5.000 Benutzern
  • 4 Kerne / 8 GB RAM für Umgebungen mit bis zu 15.000 Benutzern
  • 8 Kerne / 16 GB RAM für Umgebungen mit mehr als 15.000 Benutzern

Die Datenbankdateien und Transaktionsprotokolle sollten auf separaten Festplatten-Subsystemen gehostet werden, um eine hohe Anzahl von Transaktionen bewältigen zu können. Beispielsweise verursacht das Registrieren von 20.000 virtuellen Desktops während eines 15-minütigen Bootsturms ~ 500 Transaktionen/Sekunde und 20.000 Benutzer, die sich während eines 30-minütigen Anmeldesturms anmelden, ~ 800 Transaktionen/Sekunde in der XenDesktop-Site-Datenbank.

Provisioning Services

Neben der Bereitstellung von statischen Konfigurationsdaten speichern Server Laufzeit- und Überwachungsinformationen in der Datenbank. Je nach Start- und Verwaltungsmuster können die Performance-Auswirkungen der Datenbank als gering 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 des SQL-Servers zu ermitteln.

Entscheidung: Instanzgröße

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

  • Datenbankdatei — Enthält die in der Datenbank gespeicherten Daten und Objekte wie Tabellen, Indizes, gespeicherte Prozeduren und Ansichten.
  • Transaktionsprotokolldatei — Enthält einen Datensatz aller Transaktionen und Datenbankänderungen, die von jeder Transaktion vorgenommen wurden. Das Transaktionslog ist eine kritische Komponente der Datenbank, und wenn ein Systemfehler vorliegt, kann das Transaktionslog erforderlich sein, um die Datenbank wieder in einen konsistenten Zustand zu versetzen. Die Verwendung des Transaktionslogs hängt davon ab, welches Datenbank-Wiederherstellungsmodell verwendet wird:
    • Einfache Wiederherstellung — Keine Protokollsicherungen erforderlich. Der Protokollspeicher wird automatisch zurückgewonnen, um den Speicherplatzbedarf gering zu halten, wodurch die Verwaltung des Transaktionsprotokollspeichers überflüssig wird. Änderungen an der Datenbank seit der letzten Sicherung sind ungeschützt. Im Falle einer Katastrophe müssen diese Änderungen erneut durchgeführt werden.
    • Vollständige Wiederherstellung — Erfordert Protokollsicherungen. Aufgrund einer verlorenen oder beschädigten Datenbankdatendatei geht keine Arbeit verloren. Daten eines beliebigen Zeitpunkts können wiederhergestellt werden (z. B. vor der Anwendung oder Benutzerfehler). Für die Datenbankspiegelung ist eine vollständige Wiederherstellung erforderlich.
    • Massenprotokolliert — Erfordert Protokollsicherungen. Dies ist ein Zusatz des vollständigen Wiederherstellungsmodells, das Hochleistungsmassenkopiervorgänge ermöglicht. Es wird normalerweise nicht für Citrix Datenbanken verwendet.

Weitere Informationen finden Sie im Microsoft Developer Network —SQL Server-Wiederherstellungsmodelle.

Um den Speicherbedarf zu schätzen, ist es wichtig, den Festplattenspeicherverbrauch für gemeinsame Datenbankeinträge zu verstehen. In diesem Abschnitt werden die Speicheranforderungen je Produkt beschrieben und die Dimensionierungsberechnungen bereitgestellt. Weitere Informationen finden Sie im Citrix-Artikel:CTX139508— XenDesktop 7.x Database Sizing.

XenDesktop Allgemein

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

  • Standortkonfigurationsdatenbank — Enthält statische Konfiguration und dynamische Laufzeitdaten
  • Überwachungsdatenbank — Enthält Überwachungsdaten, auf die über Director zugegriffen werden kann
  • Konfigurationsprotokollierungsdatenbank — Enthält einen Datensatz für jede administrative Änderung innerhalb der Site (zugänglich über Studio)

Site-Datenbank

Da die Datenbank einer XenApp- oder 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, sondern auch von den Benutzermustern ab. Die folgenden Faktoren wirken sich alle auf die Größe der Datenbankdatei aus:

  • Die Anzahl der verbundenen Sitzungen
  • Die Anzahl der konfigurierten und registrierten VDAs
  • Die Anzahl der Transaktionen, die während der Anmeldung auftreten
  • VDA-Heartbeat-Transaktionen

Die Größe der Standortdatenbank basiert auf der Anzahl der VDAs und aktiven Sitzungen. Die folgende Tabelle zeigt die typische maximale Datenbankgröße, die Citrix beim Skalieren von XenApp und XenDesktop mit einer Beispielanzahl von Benutzern, Anwendungen und Desktop-Bereitstellungsmethoden beobachtet hat.

Benutzer Anwendungen Desktop-Typen Erwartete maximale Größe (MB)
1,000 50 Gehostete gemeinsame Nutzung 30
10,000 100 Gehostete gemeinsame Nutzung 60
100,000 200 Gehostete gemeinsame Nutzung 330
1,000 N/A Gehosteter Pool 30
10,000 N/A Gehosteter Pool 115
40,000 N/A Gehosteter Pool 390

Hinweis:

Diese Größenangaben sind nur ein Leitfaden. Die tatsächlichen Datenbankgrößen können je nach Bereitstellung leicht abweichen, da Datenbanken gepflegt werden.

Die Ermittlung der Größe des Transaktionslogs für die Standortdatenbank ist schwierig aufgrund von Faktoren, die das Protokoll beeinflussen können, einschließlich:

  • Das Wiederherstellungsmodell der SQL-Datenbank
  • Startrate zu Spitzenzeiten
  • Die Anzahl der ausgelieferten Desktops

Während XenDesktop-Skalierbarkeitstests beobachtete Citrix die Wachstumsrate des Transaktionsprotokolls bei 3,5 MB pro Stunde, wenn sich das System im Leerlauf befindet, und eine Wachstumsrate pro Benutzer und Tag von ~ 32 KB. In einer großen Umgebung erfordert die Verwendung von Transaktionsprotokollen eine sorgfältige Verwaltung und eine regelmäßige Sicherung, um ein übermäßiges Wachstum zu verhindern. Dies kann durch geplante Aufträge oder Wartungspläne erreicht werden.

Überwachungsdatenbank

Von den drei Datenbanken wird erwartet, dass die Monitoring-Datenbank die größte ist, da sie historische Informationen für den Standort enthält. Seine Größe hängt von vielen Faktoren ab, darunter:

  • Anzahl der Benutzer
  • Anzahl der Sitzungen und Verbindungen
  • Anzahl der Arbeitnehmer
  • Konfiguration des Aufbewahrungszeitraums — Platinum-Kunden können Daten über ein Jahr aufbewahren (standardmäßig 90 Tage). Nicht-Platinum-Kunden können Daten für bis zu 7 Tage aufbewahren (Standard 7 Tage).
  • Anzahl der Transaktion pro Sekunde. Der Überwachungsdienst neigt dazu, Aktualisierungen in Batches auszuführen. Es ist selten, dass die Anzahl der Transaktionen pro Sekunde über 20 geht.
  • Hintergrundtransaktion, die durch regelmäßige Konsolidierungsaufrufe vom Überwachungsdienst verursacht wird.
  • Nacht-Verarbeitung durchgeführt, um Daten außerhalb des konfigurierten Aufbewahrungszeitraums zu entfernen.

Die folgende Tabelle zeigt die geschätzte Größe der Überwachungsdatenbank über einen bestimmten Zeitraum in verschiedenen Szenarien. Bei diesen Daten handelt es sich um eine Schätzung, die auf Daten basiert, die innerhalb von XenApp und XenDesktop (unter der Annahme einer 5-Tage-Arbeitswoche) gesehen wurden.

Benutzer Typ 1 Woche (MB) 1 Monat (MB) 3 Monate (MB) 1 Jahr (MB)
1,000 HSD 20 70 230 900
10,000 HSD 160 600 1,950 7,700
100,000 HSD 1,500 5,900 19,000 76,000
1,000 VDI 15 55 170 670
10,000 VDI 120 440 1,400 5,500
40,000 VDI 464 1,700 5,400 21,500

Schätzungen mit 2 Verbindungen und 1 Sitzung pro Benutzer mit einer 5-Tage-Arbeitswoche

Benutzer Typ 1 Woche (MB) 1 Monat (MB) 3 Monate (MB) 1 Jahr (MB)
1,000 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
1,000 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 100.000 HSD-Tests basieren auf einer Testumgebung bestehend aus:

  • 2 Delivery Controller
  • 43 Hosted Shared Desktop Worker
  • 3 SQL-Server, konfiguriert mit Datenbanken, die innerhalb einer Always On-Verfügbarkeitsgruppe gespeichert sind.

Weitere Informationen finden Sie im Citrix Support-Artikel —XenDesktop 7.x Datenbankgröße.

Die Größe des Transaktionsprotokolls für die Überwachungsdatenbank ist sehr schwer zu schätzen, aber XenApp- und XenDesktop-Skalierbarkeitstests zeigten eine Wachstumsrate von etwa 30,5 MB pro Stunde, wenn sich das System im Leerlauf befindet, und eine Wachstumsrate pro Benutzer und Tag von ~ 9 KB.

Konfigurationsprotokollierungsdatenbank

Die Konfigurationsprotokollierungsdatenbank ist normalerweise die kleinste der drei Datenbanken. Seine Größe und die Größe des zugehörigen Transaktionsprotokolls hängen von den täglichen administrativen Aktivitäten ab, die von Studio, Director oder PowerShell-Skripten initiiert werden. Daher ist seine Größe schwer zu schätzen. Je mehr Konfigurationsänderungen durchgeführt werden, desto größer wird die Datenbank. Einige Faktoren, die die Größe der Datenbank beeinflussen können, sind:

  • Die Anzahl der Aktionen, die in Studio, Director und PowerShell ausgeführt werden.
  • Minimale Transaktionen, die in der Datenbank auftreten, wenn keine Konfigurationsänderungen stattfinden.
  • Die Transaktionsrate bei Aktualisierungen. Aktualisierungen werden, wann immer möglich, in Batches gehandelt.
  • Daten manuell aus der Datenbank entfernt. Daten in der Konfigurationsprotokollierungsdatenbank unterliegen keiner Aufbewahrungsrichtlinie, daher werden sie nur entfernt, wenn dies manuell von einem Administrator durchgeführt wird.
  • Aktivitäten, die Auswirkungen auf Sitzungen oder Benutzer haben, z. B. Sitzungsabmeldung und Zurücksetzen.
  • Der Mechanismus, der für die Bereitstellung von Desktops verwendet wird.

In XenApp-Umgebungen, die MCS nicht verwenden, liegt die Datenbankgröße in der Regel zwischen 30 und 40 MB. Für MCS-Umgebungen kann die Datenbankgröße aufgrund der Protokollierung aller VM-Build-Daten leicht über 200 MB liegen.

Temporäre Datenbank

Zusätzlich zu den Datenbanken Site, Überwachung und Konfigurationsprotokollierung wird eine systemweite temporäre Datenbank (tempdb) von SQL Server bereitgestellt. Diese temporäre Datenbank wird zum Speichern von Read-Commitmitted Snapshot-Isolationsdaten verwendet. XenApp 7.x und XenDesktop 7.x verwenden diese SQL Server-Funktion, um Sperrenkonflikte in den XenApp- und XenDesktop-Datenbanken zu reduzieren. Citrix empfiehlt, dass alle XenApp 7.x- und XenDesktop 7.x-Datenbanken Read-Committed-Snapshot-Isolation verwenden. Weitere Informationen finden Sie unterAktivieren von Read-Commitmitte-Snapshot in XenDesktop.

Die Größe der tempdb-Datenbank hängt von der Anzahl der aktiven Transaktionen ab, aber im Allgemeinen wird nicht erwartet, dass sie mehr als ein paar MBs wachsen wird. Die Leistung der tempdb-Datenbank hat keinen Einfluss auf die Leistung von XenApp- und XenDesktop-Brokering, da alle Transaktionen, die neue Daten generieren, Tempdb-Speicherplatz benötigen. XenApp und XenDesktop haben in der Regel kurzlebige Transaktionen, die dazu beitragen, die Größe der tempdb klein zu halten.

Die tempdb wird auch verwendet, wenn Abfragen große Zwischenergebnissätze generieren. Anleitung und Dimensionierung der tempdb finden Sie im Microsoft TechNet-ArtikelOptimieren der Tempdb-Leistung.

Provisioning Services

Die Provisioning Services-Farmdatenbank enthält statische Konfigurations- und Konfigurationsprotokollierungsdaten (Audit-Trail). Die unten aufgeführten Anforderungen an die Datensatzgröße können verwendet werden, um die Größe der Datenbank zu erleichtern:

Konfigurationselement Erforderlicher DB-Speicherplatz (KB) Anzahl der Elemente (Beispiel) Gesamt (KB)
Konfiguration der Basisfarm 112 - 112
Benutzergruppe mit Farmzugriff 50 10 250
Website 4 5 20
Gerätesammlung 10 50 500
Blick auf den Bauernhof 4 10 40
Farmsicht zu Gerätebeziehung 5 1 5000
Site-Ansicht 4 5 20
Site-Ansicht zu Gerätebeziehung 5 1 5000
Gerät 2 5000 10,000
Geräte-Bootstrap 10 - -
Beziehung zwischen Gerät und Festplatte 35 1 175,000
Gerätedrucker-Beziehung 1 - -
Persönlichkeitsdaten des Geräts 1 - -
Gerätestatus (beim Booten) 1 5000 5000
Benutzerdefinierte Geräteeigenschaft 2 - -
vDisk 1 20 20
vDisk-Version 3 5 300
Festplattensuche 10 1 200
Benutzerdefinierte Eigenschaft des Datenträgerlocators 2 - -
Server 5 10 50
Server IP 2 1 20
Serverstatus (beim Booten) 1 20 20
Benutzerdefinierte Servereigenschaft 2 - -
vDisk-Speicher 8 5 40
vDisk-Store-zu-Server-Beziehung 4 1 40
Verbindung zu XenServer (VirtualHostingPool) 4 - -
vDisk-Update-Aufgabe 10 10 100
Administrative Änderung (Auditing aktiviert) 1 10,000 10,000
Gesamt     211,732KB (~212MB)

Während der Installation 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 das Transaktionsprotokoll nicht sehr schnell wachsen, es sei denn, es wird eine große Menge an Konfiguration durchgeführt.

Im Gegensatz zu XenApp, das auch die Möglichkeit bietet, administrative Änderungen nachzuverfolgen, werden die zugehörigen Informationen nicht in eine dedizierte Datenbank geschrieben, sondern direkt in die Provisioning Services-Farmdatenbank. Um die Größe der Provisioning Services-Datenbank zu begrenzen, wird empfohlen, die Überwachungsprotokolldaten regelmäßig zu archivieren.

Entscheidung: Speicherort der Datenbank

XenApp und XenDesktop nutzen drei verschiedene Datenbanken: Standortkonfiguration, Überwachung und Konfigurationsprotokollierung. Alle drei Datenbanken können auf demselben Server oder auf verschiedenen Servern gehostet werden. Eine ideale Konfiguration wäre, die Überwachungsdatenbank auf einem anderen Server als den Datenbanken für die Standortkonfiguration und Konfigurationsprotokollierung zu hosten. Es ist vorzuziehen, die Überwachungsdatenbank zu trennen, da sie mehr Daten aufzeichnet, Änderungen häufiger auftreten und die Daten nicht als so kritisch angesehen werden wie die anderen Datenbanken.

Hinweis:

Der Speicherort der Konfigurationsprotokolldatenbank kann nicht geändert werden, wenn die obligatorische Protokollierung aktiviert ist.

Entscheidung: Hochverfügbarkeit

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

Komponente Auswirkungen des Datenbankausbruchs
Standortkonfigurationsdatenbank Benutzer können keine Verbindung zu einem virtuellen Desktop herstellen oder erneut herstellen. Hinweis: Mit dem lokalen Hostcache können Benutzer mit gehosteten freigegebenen Desktops, gehosteten Windows- und Browseranwendungen und Personal Desktops erneut eine Verbindung zu ihren Anwendungen und Desktops herstellen, selbst wenn die Standortdatenbank nicht verfügbar ist.
Überwachungsdatenbank Director zeigt keine historischen Daten an, und Studio kann nicht gestartet werden. Das Verteilen eingehender Benutzeranforderungen und bestehender Benutzersitzungen wird nicht beeinträchtigt.
Konfigurationsprotokollierungsdatenbank Wenn Änderungen zulassen, wenn die Verbindung der Datenbank getrennt wird, innerhalb der XenApp- und XenDesktop-Protokollierungseinstellungen aktiviert wurde, hat ein Ausfall der Konfigurationsprotokollierungsdatenbank keine Auswirkungen (außer Konfigurationsänderungen werden nicht protokolliert). Andernfalls können Administratoren keine Änderungen an der XenApp- und XenDesktop-Sitekonfiguration vornehmen. Benutzer sind nicht betroffen.
Provisioning Services-Farmdatenbank Wenn die Offlinebatenbankunterstützung aktiviert ist und die Datenbank nicht verfügbar wird, verwendet der Streamingprozess eine lokale Kopie der Datenbank, um Informationen über den Provisioning-Server und die vom Server unterstützten Zielgeräte abzurufen. Dadurch bleiben die Provisioning-Server und die Zielgeräte betriebsbereit. Wenn die Datenbank offline ist, sind die Konsole und die unten aufgeführten Verwaltungsfunktionen nicht verfügbar: Zielgeräte automatisch hinzufügen; vDisk-Erstellung und -Updates; Active Directory-Kennwortänderungen; Stream-Prozessstart; Image-Update-Dienst; PowerShell- und MCLI-basierte Verwaltung. Wenn die Offline-Datenbankunterstützung nicht aktiviert wurde, sind alle Verwaltungsfunktionen nicht verfügbar und der Start und das Failover von Zielgeräten schlägt fehl.

Hinweis:

Bitte überprüfen Sie die HA-Optionen für Datenbanken von Drittanbietern (z. B. App-V, SCVMM oder vCenter) beim jeweiligen Softwarehersteller.

Zusätzlich zu den integrierten Datenbank-Redundanzoptionen bieten Microsoft SQL Server sowie der zugrunde liegende Hypervisor (in virtuellen Umgebungen) eine Reihe von Hochverfügbarkeitsfunktionen. Dadurch können Administratoren sicherstellen, dass einzelne Serverausfälle (falls vorhanden) nur minimal auf die XenApp- und XenDesktop-Infrastruktur auswirken. Die folgenden SQL / Hypervisor Hochverfügbarkeitsfunktionen sind verfügbar:

  • HA auf VM-Ebene — Diese Option für hohe Verfügbarkeit ist nur für virtuelle SQL-Server verfügbar, die auf der Hypervisorebene für hohe Verfügbarkeit gekennzeichnet werden müssen. Im Falle eines unerwarteten Herunterfahrens der virtuellen Maschine oder des zugrunde liegenden Hypervisorhosts versucht der Hypervisor, die VM sofort auf einem anderen Host neu zu starten. Während HA auf VM-Ebene Ausfallzeiten in Energieszenarien minimieren kann, kann sie nicht vor Beschädigungen auf Betriebssystemebene schützen. Diese Lösung ist kostengünstiger als Spiegelung oder Clustering, da sie eine integrierte Hypervisorfunktion verwendet. Der automatische Failover-Prozess ist jedoch langsamer, da es Zeit dauern kann, einen Ausfall zu erkennen und den virtuellen SQL-Server auf einem anderen Host zu starten. Dies kann den Dienst für Benutzer unterbrechen.
  • Spiegelung— Datenbankspiegelung erhöht die Datenbankverfügbarkeit mit fast sofortigem Failover. Die Datenbankspiegelung kann verwendet werden, um eine einzelne Standby- oder Spiegeldatenbank für eine entsprechende Prinzipal- oder Produktionsdatenbank zu verwalten. Die Datenbankspiegelung wird entweder mit synchronem Betrieb im Hochsicherheitsmodus oder asynchronem Betrieb im Hochleistungsmodus ausgeführt. Im Hochsicherheitsmodus mit automatischem Failover (empfohlen für XenDesktop) ist eine dritte Serverinstanz erforderlich, die es dem Spiegelserver ermöglicht, als Hot-Standby-Server zu fungieren. Failover von der Prinzipaldatenbank in die Spiegeldatenbank erfolgt automatisch und wird in der Regel innerhalb weniger Sekunden abgeschlossen. Es empfiehlt sich, die HA auf VM-Ebene (oder eine ähnliche automatische Neustartfunktion) zumindest für den Zeugen zu aktivieren, um die Verfügbarkeit des SQL-Dienstes bei einem Ausfall mit mehreren Servern sicherzustellen.

Hinweis:

Microsoft plant, Spiegelungen als Hochverfügbarkeitsoption in einer zukünftigen Version von SQL Server zu entfernen und entmutigt seine Verwendung in der neuen Netzwerkentwicklung. Weitere Informationen finden Sie im Microsoft-Artikel Datenbankspiegelung (SQL Server)

  • AlwaysOn-Failoverclusterinstanzen — Failoverclustering bietet Unterstützung für hohe Verfügbarkeit für eine gesamte Instanz von Microsoft SQL Server. Ein Failovercluster ist eine Kombination aus zwei oder mehr Knoten oder Servern, die einen gemeinsam genutzten Speicher verwenden. Eine Microsoft SQL Server AlwaysOn-Failoverclusterinstanz, die in SQL Server 2012 eingeführt wurde, wird im Netzwerk als einzelner Computer angezeigt, verfügt jedoch über Funktionen, die Failover von einem Knoten zum anderen bereitstellt, wenn der aktuelle Knoten nicht verfügbar ist. Der Übergang von einem Knoten zum anderen Knoten erfolgt nahtlos für die Clients, die mit dem Cluster verbunden sind. AlwaysOn-Failoverclusterinstanzen erfordern eine WSFC-Ressourcengruppe (Windows Server Failover Clustering). Die Anzahl der Knoten, die in der WSFC-Ressourcengruppe unterstützt werden, hängt von der SQL Server-Edition ab. (Bitte beachten Sie die TabelleEntscheidung: Editionweiter oben in diesem Kapitel.) Weitere Informationen finden Sie unter MSDN —AlwaysOn-Failoverclusterinstanzen (SQL Server).
  • AlwaysOn-Verfügbarkeitsgruppen — AlwaysOn-Verfügbarkeitsgruppen sind eine Lösung für hohe Verfügbarkeit und Notfallwiederherstellung, die in Microsoft SQL Server 2012 eingeführt wurde, mit der Administratoren die Verfügbarkeit für eine oder mehrere Benutzerdatenbanken maximieren können. AlwaysOn-Verfügbarkeitsgruppen erfordern, dass sich die Microsoft SQL Server-Instanzen auf Windows Server-Failoverclustering-Knoten (WSFC-Knoten) befinden. Ähnlich wie beim Failover-Clustering wird ein einzelner virtueller IP/Netzwerkname den Datenbankbenutzern zur Verfügung gestellt. Im Gegensatz zum Failoverclustering ist freigegebener Speicher nicht erforderlich, da die Daten über eine Netzwerkverbindung übertragen werden. Sowohl die synchrone als auch die asynchrone Replikation auf einen oder mehrere sekundäre Server wird unterstützt. Im Gegensatz zur Spiegelung oder Clusterbildung können sekundäre Server aktiv für die Verarbeitung eingehender schreibgeschützter Anforderungen, Sicherungen oder Integritätsprüfungen verwendet werden. Diese Funktion kann verwendet werden, um Benutzerressourcenaufzählungsanforderungen an einen sekundären SQL-Server in XenDesktop-Umgebungen zu verlagern, um eine SQL-Server-Infrastruktur im Wesentlichen zu skalieren. Da die Daten auf aktiven sekundären Servern mehrere Sekunden hinter dem primären Server zurückbleiben können, kann das schreibgeschützte Routingfeature zu diesem Zeitpunkt nicht für andere XenDesktop-Datenbankanforderungen verwendet werden. Weitere Informationen finden Sie unter MSDN —AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

In der folgenden Tabelle werden die empfohlenen Hochverfügbarkeitsfunktionen für Citrix Datenbanken beschrieben:

In der Tabelle:

  • Y gleich “empfohlen”.
  • o gleich “möglich”.
  • N angegeben Nicht unterstützt.
  • T gibt nur für Testumgebungen an.
Komponente VM-Ebene - HA Spiegelung AlwaysOn-Failoverclusterinstanzen AlwaysOn-Verfügbarkeitsgruppen
Site-Datenbank T Y o o
Konfigurationsprotokollierungsdatenbank T o o o
Überwachungsdatenbank T Y o o
Provisioning Services-Farmdatenbank T Y o o
DesktopPlayer-Datenbank T N o o

Citrix Lizenzierung

Citrix bietet Unternehmen die Flexibilität von mehreren Lizenzierungsmodellen, die mit gängigen Nutzungsszenarien übereinstimmen. Die verschiedenen Lizenzmodelle variieren je nach verwendetem Citrix Produkt, können jedoch pro Benutzer/Gerät und pro gleichzeitigem Benutzer enthalten. Mehrere Citrix Produkte verwenden den Lizenzserver, während andere Produkte eine Lizenz auf dem Produkt selbst installieren müssen.

Citrix Lizenzserver

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

Auf dem Produkt:

  • NetScaler
  • NetScaler Gateway

Weitere Informationen zur XenDesktop 7.x-Lizenzierung finden Sie unterCTX128013- XenDesktop-Lizenzierung.

Weitere Informationen zur Microsoft-Lizenzierung finden Sie im Microsoft-Dokument —Lizenzierung der Virtual Desktop Infrastructure Technologie von Microsoft.

Entscheidung: Sizing

Interne Skalierbarkeitstests haben gezeigt, dass ein einziger virtueller Lizenzserver mit zwei Kernen und 2 GB RAM ca. 170 Lizenzen pro Sekunde oder 306.000 Lizenzen pro halbe Stunde ausstellen kann. Bei Bedarf kann die Spezifikation des Lizenzservers skaliert werden, um eine höhere Anzahl von Lizenzanforderungen pro Sekunde zu unterstützen.

Entscheidung: High Availabiity

Für eine typische Umgebung reicht ein einzelner Lizenzserver aus. Sollte der Lizenzserver nicht verfügbar sein, werden abhängige Citrix Produkte in einen Zeitraum von 30 Tagen eintreten, der mehr als genug Zeit bietet, um Verbindungsprobleme zu beheben und/oder den Lizenzserver wiederherzustellen oder neu zu erstellen.

Hinweis:

  • Wenn der Lizenzserver und das Citrix Produkt nicht innerhalb von 2 Heartbeats (5-10 Min.) kommunizieren, tritt das Citrix Produkt in eine Übergangsfrist ein und ermöglicht Verbindungen für bis zu 30 Tage. Sobald die Kommunikation mit dem Lizenzserver wiederhergestellt wurde, wird der Lizenzserver die temporären und tatsächlichen Lizenzen abgleichen.
  • Ein CNAME-Eintrag in DNS ist eine bequeme Möglichkeit, auf den Lizenzserver zu verweisen. Mit CNAMEs kann der Name des Lizenzservers geändert werden, ohne die Citrix Produkte zu aktualisieren.

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

  • Windows-Clusterunterstützung — Clusterserver sind Gruppen von Computern, die zusammenarbeiten, um die Verfügbarkeit zu erhöhen. Durch das Clustering kann die Lizenzserverrolle bei einem Ausfall automatisch Failover ausführen. Weitere Informationen zum Clustering finden Sie im Citrix Docs-Artikel —Cluster-Lizenzserver.
  • Duplizierung des Lizenzservers — Erstellen Sie eine Sicherung auf VM-Ebene des Lizenzservers. Diese Sicherung sollte nicht auf demselben Host wie der Lizenzserver gespeichert werden. Stattdessen sollte es an einem sicheren Ort gespeichert werden, z. B. an einer hochverfügbaren Speicherlösung, oder auf Band oder Festplatte gesichert werden. Der doppelte Server ist nicht aktiv und bleibt im Standby-Modus, bis der aktive Lizenzserver wiederhergestellt werden muss. Sollte der Lizenzserver mit dieser Sicherung wiederhergestellt werden, müssen alle neuen Lizenzen erneut auf den Server heruntergeladen werden.

Weitere Informationen finden Sie unter Citrix eDocs —Übersicht über die Lizenzierungsarchitektur.

Jede Methode ermöglicht es einem Administrator, einen einzelnen Lizenzserver ohne Unterbrechung des Dienstes gegen einen anderen auszutauschen; vorausgesetzt, dass die Änderung während der Nachfrist erfolgt und die folgenden Einschränkungen berücksichtigt werden.

  • Lizenzdateien verweisen auf den während des Zuweisungsvorgangs angegebenen Server. Das bedeutet, dass die Lizenzdateien nur auf einem Server mit denselben Bindungsinformationen (Hostname) wie der zuvor angegebene Server verwendet werden können.
  • Zwei Windows-basierte Lizenzserver, die einer Domäne beigetreten sind, können nicht denselben Namen verwenden 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 Backup-Lizenzserver platziert werden.

Entscheidung: Optimierung

Die Leistung des Lizenzservers kann optimiert werden, indem die Anzahl der Empfangs- und Verarbeitungsthreads optimiert wird. Wenn die Threadanzahl zu niedrig ist, werden Anfragen in die Warteschlange gestellt, bis ein Thread verfügbar ist. Umgekehrt wird der Lizenzserver überlastet, wenn die Thread-Anzahl zu hoch eingestellt ist.

Die optimalen Werte hängen von der Serverhardware, der Standortkonfiguration und dem Lizenzanforderungsvolumen ab. Citrix empfiehlt, verschiedene Werte zu testen und auszuwerten, um die richtige Konfiguration zu bestimmen. Das Festlegen der maximalen Anzahl von Verarbeitungsthreads auf 30 und die maximale Anzahl der empfangenden Threads auf 15 ist ein guter Ausgangspunkt für große Bereitstellungen.

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

Weitere Informationen finden Sie in den Citrix Docs —Verbessern der Leistung durch Angabe der Threadverwendung.

Delivery Controller

Entscheidung: Servergröße

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 Desktop-Start-, Registrierungs-, Aufzählungs- und Startanforderung wirkt sich auf den Prozessor des Controllers aus. Mit zunehmender Intensität des Sturms erhöht sich die CPU-Auslastung des Controllers. Wenn die CPU einen kritischen Schwellenwert von etwa 80% erreicht, muss der Standort entweder vertikal oder horizontal skaliert werden.

Durch das Hinzufügen zusätzlicher CPU-Kerne zu einem Delivery Controller wird die gesamte CPU-Auslastung gesenkt, wodurch eine größere Anzahl von Desktops möglich ist, die von einem einzelnen Controller unterstützt werden. Dies ist wirklich nur möglich, wenn es um virtualisierte Controller geht, da das Hinzufügen virtueller CPUs ziemlich einfach und unkompliziert ist. Die andere Alternative besteht darin, einen weiteren Controller zur Standortkonfiguration hinzuzufügen. Der Controller hätte die gleiche Konfiguration wie andere Controller, und die Last würde gleichmäßig auf alle Controller verteilt, wodurch die Gesamtlast auf jedem einzelnen Controller reduziert wird.

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

Komponente Spezifikation
Prozessor 4 vCPU
Speicher 4 GB RAM
Netzwerk Angebundene virtuelle Netzwerkkarte
Host-Speicher 40 GB freigegebener Speicher
Betriebssystem Windows Server 2012 R2
XenDesktop 7

Die folgende Formel kann verwendet werden, um die Anzahl der Delivery Controller zu berechnen, die für einen Citrix Standort erforderlich sind.

Anzahl des Images der Bereitstellungscontroller

Entscheidung: Hochverfügbarkeit

Wenn der Server, auf dem der Delivery Controller gehostet wird, nicht verfügbar ist, können Benutzer nicht auf ihre virtuellen Desktops oder veröffentlichten Anwendungen zugreifen. Daher sollten mindestens zwei Delivery Controller (N + 1-Redundanz) pro Zone auf verschiedenen physischen Servern bereitgestellt werden, um zu verhindern, dass diese Komponente zu einem einzigen Fehlerpunkt wird. Wenn ein Controller ausfällt, können die anderen Verbindungen verwalten und die Site verwalten.

Die Speicherorte aller Delivery Controller sind auf dem VDA angegeben, sodass der Failover automatisch ausgeführt werden kann, wenn die Kommunikation mit einem Delivery Controller nicht verfügbar ist. Der VDA überprüft die folgenden Speicherorte in der Reihenfolge und stoppt an der ersten Stelle, an der er den Delivery Controller findet:

  1. Ein dauerhafter Speicherort, der für die automatische Aktualisierung beibehalten wird. Dieser Speicherort enthält Controller-Informationen, wenn die automatische Aktualisierung aktiviert ist und nachdem sich der VDA zum ersten Mal nach der Installation erfolgreich registriert hat. Für seine erste Registrierung nach der Installation oder 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 unter dem VDA ListofDDCs-Registrierungsschlüssel. Das VDA-Installationsprogramm füllt diese Werte zunächst basierend auf den bei der Installation des VDA angegebenen Informationen auf.
  4. OU-basierte Entdeckung. Dies ist eine Legacy-Methode, die für die Abwärtskompatibilität beibehalten wird.
  5. Die Datei Personality.ini, die von Machine Creation Services erstellt wurde.

Citrix Consulting empfiehlt die Verwendung der automatischen Aktualisierungsfunktion (standardmäßig aktiviert). Diese Funktion vereinfacht die Verwaltung der Umgebung, da die VDAs beim Hinzufügen und Entfernen von Delivery Controllern aktualisiert werden.

Entscheidung: Lokaler Host-Cache

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 Standorte, die sich über geografische Standorte erstrecken.

Um dieses Risiko zu überwinden, können die Delivery Controller die lokale Host-Cache-Funktion verwenden, die eine lokale Kopie der SQL-Datenbank erstellt, die nur verwendet wird, wenn der Delivery Controller den Kontakt mit der Datenbank verliert.

Bei der Verwendung des lokalen Host-Cache muss Folgendes berücksichtigt werden:

  • Wahlen — Wenn die Zonen den Kontakt mit der SQL-Datenbank verlieren, erfolgt eine Auswahl, bei der ein einzelner Delivery Controller als Master nominiert wird. Alle verbleibenden Controller gehen in den Leerlauf. Eine einfache alphabetische Reihenfolge bestimmt den Sieger der Wahl.
  • Dimensionierung — Bei Verwendung des lokalen Host-Cache-Modus ist ein einzelner Delivery Controller für alle VDA-Registrierungen, Aufzählungen, Starts und Aktualisierungen verantwortlich. Der gewählte Controller muss über genügend Ressourcen (CPU und RAM) verfügen, um die gesamte Last für die Zone zu verarbeiten. Ein einzelner Controller kann auf 10.000 Benutzer skaliert werden, was das Zonendesign beeinflusst.
    • RAM — Die lokalen Host-Cache-Dienste können 2 + GB RAM belegen, abhängig von der Dauer des Ausbruchs und der Anzahl der Benutzerstarts während des Ausbruchs.
    • CPU — Der lokale Host-Cache kann bis zu 4 Kerne in einem einzigen Socket verwenden.
    • Speicher — Im lokalen Host-Cache-Modus erhöhte sich der Speicherplatz alle 2-3 Minuten um 1 MB und durchschnittlich 10 Anmeldungen pro Sekunde.
  • Energieoptionen — Die ausgeschalteten virtuellen Ressourcen werden nicht gestartet, wenn sich der Delivery Controller im lokalen Host-Cache-Modus befindet. Gepoolte virtuelle Desktops, die am Ende einer Sitzung neu gestartet werden, werden in den Wartungsmodus versetzt.
  • Konsolen — Bei Verwendung des lokalen Host-Cache-Modus sind Studio und PowerShell nicht verfügbar.

Entscheidung: XML Service Encryption

In einer typischen Sitzung übergibt der StoreFront-Server Anmeldeinformationen an den Citrix XML-Dienst auf einem Delivery Controller. Das Citrix XML-Protokoll verwendet Klartext, um alle Daten auszutauschen, mit Ausnahme von Kennwörtern, die durch Verschleierung übertragen werden.

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

  • Angreifer können den XML-Datenverkehr abfangen und Ressourcensatzinformationen und Tickets stehlen.
  • Angreifer mit der Fähigkeit, die Verschleierung zu knacken, können Benutzeranmeldeinformationen erhalten.
  • Angreifer können die Identität des XenDesktop-Controllers ausgeben und Authentifizierungsanforderungen abfangen.

Für die meisten Unternehmen wird der Citrix XML-Datenverkehr in einem dedizierten physischen oder virtuellen Rechenzentrumsnetzwerk isoliert, wodurch das Abfangen unwahrscheinlich ist. Aus Sicherheitsgründen sollten Sie jedoch die SSL-Verschlüsselung verwenden, um StoreFront-Daten über eine sichere HTTP-Verbindung zu senden.

Entscheidung: Lastverwaltung des Serverbetriebssystems

Standardladeverwaltungsrichtlinien werden auf alle Bereitstellungsgruppen des Serverbetriebssystems angewendet. Die Standardeinstellungen geben die maximale Anzahl von Sitzungen an, die ein Server mit 250 hosten kann, und berücksichtigen nicht die CPU- und Speicherauslastung. Die Anzahl der Capping Session liefert keinen echten Hinweis auf die Last, was zu einer Überlastung der Serverbetriebssystembereitstellungsgruppen führen kann, die zu einer Leistungsbeeinträchtigung oder einer Unterauslastung der Serverbetriebssystembereitstellungsgruppen führen kann, was zu einer ineffizienten Ressourcennutzung führt.

Citrix Consulting empfiehlt, auf Basis von Leistungs- und Skalierbarkeitstests einzigartige “benutzerdefinierte” Lastverwaltungsrichtlinien für jede Bereitstellungsgruppe zu erstellen. Abhängig von den verschiedenen Ressourcenengpässen, die während des Tests festgestellt wurden, können für jede Bereitstellungsgruppe unterschiedliche Regeln und Schwellenwerte angewendet werden. Weitere Informationen zu den verfügbaren Load Management-Richtlinienkonfigurationen finden Sie unter Citrix Docs —Richtlinieneinstellungen für die Lastverwaltung.

Wenn vor der Produktion keine ausreichenden Tests durchgeführt werden können, empfiehlt Citrix Consulting, die folgende “benutzerdefinierte” Load Management-Richtlinie zu implementieren, die als Baseline auf alle Server angewendet werden kann:

  • CPU-Auslastung - Volllast: 80%
  • CPU-Auslastung ausgeschlossen Prozesspriorität — Unter Normal oder Niedrig
  • Speicherauslastung - Volllast: 80%
  • Basislast für Speichernutzung — Nulllast (MBs) melden: 786
  • Maximale Anzahl von Sitzungen — X

Die Richtlinie “Maximale Anzahl von Sitzungen” ist für Zwecke der Begrenzung enthalten — dies gilt als bewährte Vorgehensweise für die Ausfallsicherheit. Organisationen können einen Anfangswert von 250 wählen (bezeichnet mit “X” oben). Es wird dringend empfohlen, diesen Wert und andere Werte basierend auf den Ergebnissen der Skalierbarkeitstests anzupassen.

Coud Stecker

Der XenApp- und XenDesktop-Dienst in Citrix Cloud nutzen eine Reihe von Diensten, die im Citrix Cloud Connector enthalten sind. Ein redundanter Satz virtueller Cloud Connector-Maschinen muss an jedem Rechenzentrum/Ressourcenstandort platziert werden, der VDA-Hosts enthält.

Entscheidung: Servergröße

Die Skalierbarkeit von Cloud Connector basiert auf der CPU-Auslastung. Je mehr Prozessorkerne verfügbar sind, desto mehr virtuelle Desktops kann ein Cloudconnector unterstützen. Jede Anforderung zum Starten, Registrieren, Auflisten und Starten von Desktops wirkt sich auf den Prozessor des Cloudconnectors aus. Mit zunehmender Intensität des Sturms erhöht sich die CPU-Auslastung des Cloudconnectors. Wenn die CPU einen kritischen Schwellenwert von etwa 80% erreicht, muss der Standort entweder vertikal oder horizontal skaliert werden.

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

Komponente Technische Daten vor Ort Azure Hosted Spezifikationen
Anzahl der VMs (mit N + 1-Fehlertoleranz) 3 6 Standard_A2_V2-Instanzen
Prozessoren pro VM 4 vCPU 2 vCPU
Arbeitsspeicher pro VM 4 GB RAM 4 GB RAM
Hostspeicher pro VM 40 GB freigegebener Speicher 200 GB temporärer Speicher
Betriebssystem Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) verwendet Streaming-Technologie, um die Bereitstellung virtueller und physischer Maschinen zu vereinfachen. Computer werden in Echtzeit von einem einzigen freigegebenen Datenträgerimage bereitgestellt und neu bereitgestellt. Dadurch können Administratoren die Notwendigkeit, einzelne Systeme zu verwalten und zu patchen, vollständig eliminieren. Stattdessen wird die gesamte Image-Verwaltung auf dem Masterimage durchgeführt.

Entscheidung: Topologie

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

Jede Site ist eine logische Entität, die Provisioning-Server, vDisk-Pools und Zielgerätesammlungen enthält. Obwohl alle Standorte innerhalb einer Farm dieselbe Datenbank verwenden, können Zielgeräte nur Failover auf andere Provisioning-Server innerhalb desselben Standorts durchführen.

PVS-Websitestrukturbild

Es gibt Faktoren, die bei der Bestimmung der allgemeinen Provisioning Services-Topologie berücksichtigt werden müssen:

  • Netzwerk — Provisioning-Server kommunizieren ständig mit der Farmdatenbank, um Systemkonfigurationseinstellungen abzurufen. Daher sollten für jeden physischen Standort, an dem sich die Zielgeräte befinden, separate Farmen erstellt werden, es sei denn, sie sind über eine schnelle und robuste Verbindung mit dem Datenbankserver verbunden.
  • Verwaltung — Unter Umständen müssen Organisationen die Trennung der Verwaltungsaufgaben auf regionaler, regionaler oder landesweiter Ebene aufrechterhalten. Zusätzliche Provisioning Services-Farmen erhöhen die Komplexität der Verwaltung der Umgebung. Dieser Overhead ist jedoch in der Regel auf die Erstkonfiguration, die Erstellung von Desktops und Image-Updates beschränkt.
  • Organisation — Ein praktischer Grund für die Erstellung mehrerer Standorte ist auf organisatorische Änderungen zurückzuführen. Beispielsweise haben sich zwei Unternehmen kürzlich durch Akquisition zusammengeschlossen, müssen aber die Ressourcen getrennt halten, während die Integration stattfindet. Die Konfiguration der Organisation für die Verwendung separater Standorte ist eine Möglichkeit, die Unternehmen getrennt zu halten, aber zentral über die Provisioning Services-Konsole verwaltet zu werden.

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

Entscheidung: Gerätesammlungen

Gerätesammlungen bieten die Möglichkeit, logische Gruppen von Zielgeräten zu erstellen und zu verwalten. Das Erstellen von Gerätesammlungen vereinfacht die Geräteverwaltung, da Aktionen auf Erfassungsebene statt auf Zielgeräteebene ausgeführt werden können.

Gerätesammlungsstrukturbild

Gerätesammlungen können physische Standorte, Subnetzbereiche, Gehäuse oder verschiedene Abteilungen innerhalb einer Organisation darstellen. Sammlungen können auch verwendet werden, um Produktionszielgeräte logisch von Test- und Wartungsgeräten zu trennen.

Erstellen Sie Gerätesammlungen basierend auf der vDisk-Zuweisung, damit der Status aller Zielgeräte, die einer bestimmten vDisk zugewiesen sind, schnell erkannt werden kann.

Entscheidung: Hochverfügbarkeit

Provisioning Services ist eine wichtige Komponente der virtuellen Desktop-Infrastruktur. Die folgenden Empfehlungen sollten befolgt werden, um einzelne Fehlerpunkte zu beseitigen:

  • Provisioning Server — Pro Standort sollten mindestens zwei Provisioning-Server implementiert werden. Eine ausreichende Redundanz sollte in das Design integriert werden, damit ein einzelner Serverausfall die Gesamtzahl der Zielgeräte, die pro Standort unterstützt werden können, nicht verringert. Die Provisioning Services-Startdatei sollte für hohe Verfügbarkeit konfiguriert werden. Bis zu vier Provisioning-Server können in der Startdatei aufgeführt werden. Zielgeräte versuchen, die Server in der Reihenfolge zu kontaktieren, in der sie aufgeführt sind. Der Server, der antwortet, ist möglicherweise nicht notwendigerweise der Server, der Streamingdienste für das Zielgerät bereitstellt. Wenn der Lastenausgleich aktiviert ist, wird das Zielgerät möglicherweise einem anderen Server an der Site zugewiesen, der weniger geladen ist als die anderen.
  • vDisks und Speicher — Bei vDisk-Stores, die auf lokalen, Direct Attached Storage (DAS) oder Storage Area Network (SAN) gehostet werden, sollte die Replikation zur Synchronisierung der vDisks verwendet werden. Wenn Sie Network Attached Storage (NAS) verwenden, stellen Sie sicher, dass die vDisks auf einer hoch verfügbaren Netzwerkfreigabe gehostet werden.
  • Netzwerk — Die Provisioning-Server sollten über redundante Netzwerkkarten verfügen. Wenn der Provisioning-Server als physischer Server bereitgestellt wird, sollten redundante Netzwerkkarten zusammengeführt werden, und wenn der Provisioning-Server als virtueller Server bereitgestellt wird, sollte der zugrunde liegende Hypervisor redundante Netzwerkkarten enthalten.

Hinweis:

Die Zielgeräte führen nur ein Failover zu Netzwerkkarten aus, die sich im selben Subnetz wie die PXE-Start-NIC befinden.

Trivial File Transfer Protocol (TFTP) ist ein Kommunikationsprotokoll, das für die Übertragung von Konfigurations- oder Boot-Dateien zwischen Computern verwendet wird. Provisioning Services kann TFTP verwenden, um die Bootstrapdatei an Zielgeräte zu übermitteln. Es gibt mehrere Optionen, um den TFTP-Dienst hochverfügbar zu machen. Einige der am häufigsten verwendeten Optionen sind:

  • DNS-Round Robin — Für den TFTP-Dienst wird ein DNS-Eintrag mit mehreren A-Datensätzen erstellt, die den TFTP-Diensten entsprechen, die auf den Provisioning-Servern in der Farm ausgeführt werden. Diese Methode wird nicht empfohlen, da der Status des TFTP-Dienstes nicht überwacht wird. Clients könnten möglicherweise an einen nicht funktionierenden Server gesendet werden.
  • Hardware Load Balancer — Verwenden Sie einen Hardware-Load Balancer wie Citrix NetScaler, um virtuelle IP-Adressen zu erstellen, die den Provisioning-Servern entsprechen. NetScaler kann den Datenverkehr intelligent zwischen den Provisioning-Servern weiterleiten. Für den Fall, dass einer der Server nicht verfügbar ist, stoppt NetScaler das Weiterleiten von TFTP-Anforderungen an diesen Server automatisch. Dies ist die beste Methode, um TFTP hochverfügbar zu machen, kann aber kompliziert sein, einzurichten.
  • 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. Microsoft DHCP-Server erlaubt eine Option 66-Eintrag, so dass diese Methode in Umgebungen mit Microsoft DHCP-Diensten nicht möglich ist. Wenn Sie einen DHCP-Server oder -Appliance verwenden, überprüfen Sie den Hersteller, ob mehrere Einträge der Option 66 unterstützt werden.

Es gibt andere Optionen, die das gleiche Ergebnis erzielen können, ohne TFTP verwenden zu müssen:

  • Proxy DHCP — Verwenden Sie den PXE-Dienst des Provisioning-Servers, um die Bootstrapinformationen bereitzustellen. Wenn einer der Server ausfällt, kann der nächste verfügbare Server in der Farm die Bootstrap-Informationen bereitstellen. Diese Methode erfordert, dass die Provisioning-Server in derselben Broadcastdomäne sind wie die Zielgeräte. Wenn im Netzwerk andere PXE-Dienste ausgeführt werden (Altiris, SCCM usw.), sind möglicherweise mehrere VLANs erforderlich, um zu verhindern, dass die PXE-Dienste sich gegenseitig stören.
  • Startgerätmanager — Verwenden Sie den Startgerätmanager, um eine Bootstrapdatei zu erstellen, die entweder auf der lokalen Festplatte gespeichert 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 legen Sie die ISO-Datei an einem hoch verfügbaren freigegebenen Netzwerkspeicherort oder einem lokalen Speicher jedes Zielgeräts ab. Wenn eine der beiden Methoden verwendet wird, wird der TFTP-Dienst überhaupt nicht verwendet.

Hohe Verfügbarkeit sollte immer in das Provisioning Services-Design integriert werden. Obwohl hohe Verfügbarkeit zusätzliche Ressourcen und höhere Kosten erfordern kann, bietet sie eine äußerst stabile Umgebung, so dass Benutzer aufgrund von Serviceausfällen minimale Auswirkungen haben.

Entscheidung: Bootstrap Delivery

Ein Zielgerät startet den Startvorgang, indem zuerst ein Bootstrap-Programm geladen wird, das die Streaming-Sitzung zwischen dem Zielgerät und dem Provisioning-Server initialisiert. Es gibt drei Methoden, bei denen das Zielgerät das Bootstrap-Programm empfangen kann:

Verwenden von DHCP-Optionen

  1. Wenn das Zielgerät gestartet wird, sendet das Zielgerät eine Übertragung für IP-Adresse und Boot-Informationen. DHCP verarbeitet diese Anforderung und stellt eine IP- und Scope-Optionseinstellungen 66 (Name oder IP-Adresse des Provisioning Services TFTP-Servers) und 67 (Name der Bootstrap-Datei) zur Verfügung.

    Hinweis:

    Wenn Sie einen Load Balancer für den TFTP-Dienst verwenden, wird die Adresse des Load Balancers in Option 66 eingegeben.

  2. Mit TFTP wird eine Anforderung für die Bootstrap-Datei 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:

Der UDP/DHCP -Helper muss konfiguriert werden, wenn sich Ziele nicht im selben Subnetz wie die DHCP-Server befinden, um PXE-Broadcasts zu empfangen.

Verwenden von PXE-Übertragungen

  1. Wenn ein Zielgerät vom Netzwerk gestartet wird, sendet das Zielgerät eine Übertragung für eine IP-Adresse und Boot-Informationen. DHCP verarbeitet diese Anfrage und gibt eine IP-Adresse an. Darüber hinaus geben alle Provisioning-Server, die die Broadcastübertragung empfangen, Informationen zum Startserver und zum Startdateinamen zurück. Das Zielgerät führt die empfangenen Informationen zusammen und startet den Startvorgang.

  2. Mit TFTP wird eine Anforderung für die Bootstrap-Datei 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 in demselben Subnetz wie dem Altiris PXE-Dienst verwendet werden, oder isolieren Sie mithilfe von VLANs, andernfalls können Konflikte mit Provisioning Services auftreten.
  • Der UDP/DHCP -Helper muss konfiguriert werden, wenn sich Ziele nicht im selben Subnetz befinden wie die DHCP- und PVS-Server, um PXE-Broadcasts zu empfangen.

Verwenden des Startgeräte-Managers — Der Boot Device Manager (BDM) erstellt eine Startdatei, die Zielgeräte über eine physische CD/DVD, ein bereitgestelltes ISO-Image oder als virtuelle Festplatte erhalten, die dem Zielgerät zugewiesen ist. Eine BDM-Partition kann auf drei Arten aktualisiert werden:

  • Nach Sammlung
  • Durch eine Gruppe hervorgehobener Geräte
  • Mit einem einzigen Gerät

Eine Zusammenfassung der Vor- und Nachteile für die einzelnen Liefermethoden ist in der folgenden Tabelle aufgeführt:

Versandart Vorteile Nachteile
DHCP-Optionen Einfach zu implementieren Erfordert Änderungen am Produktions-DHCP-Dienst. Der DHCP-Dienst darf nur einen Eintrag der Option 66 zulassen. Erfordert UDP/DHCP -Helfer für Ziele in verschiedenen Subnetzen.
PXE Einfach zu implementieren Kann andere laufende PXE-Dienste im selben Subnetz beeinträchtigen. Erfordert UDP/DHCP -Helfer für Ziele in verschiedenen Subnetzen.
BDM ISO Benötigt keine PXE- oder TFTP-Dienste Zusätzlicher Aufwand, um physische Zielgeräte zu starten. BDM ISO wird als Single Point of Failure angesehen, wenn eine einzelne Datei verwendet wird.
BDM-Partition Das Upgrade der BDM-Boot-Partition erfordert keine PXE, TFTP oder TSB; es gilt als einstufiger Bootloader, beim Booten findet es automatisch alle relevanten PVS-Serverinformationen und benötigt keine externen Dienste, die von PXE, TFTP oder TSB bereitgestellt werden. Für jedes Zielgerät wird eine zusätzliche 8MB Partition erstellt.

Hinweis:

Bei der Konfiguration der Bootstrap-Datei werden möglicherweise bis zu vier Provisioning-Server aufgelistet. Die Reihenfolge, in der die Provisioning-Server in der Liste angezeigt werden, 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 fester Größe oder dynamischen vDisks:

  • Festplatte fester Größe — Bei vDisks im privaten Modus verhindert die Festplattenfragmentierung und bietet eine verbesserte Schreibleistung gegenüber dynamischen Datenträgern.
  • Dynamische Datent räger — Dynamische Datenträger benötigen weniger Speicherplatz als Festplatten mit fester Größe, bieten jedoch eine deutlich geringere Schreibleistung. Obwohl vDisks im freigegebenen Modus keine Schreibvorgänge auf die vDisk ausführen, erhöht sich die Zeit, die zum Abschließen von vDisk-Zusammenführungsvorgängen erforderlich ist, mit dynamischen Datenträgern. Dies ist kein häufiges Vorkommen, da mehr Umgebungen beim Aktualisieren neue vDisks erstellen.

Da die meisten Lesevorgänge in den Systemcache im RAM vorgenommen werden, gibt es keine signifikante Leistungsänderung bei Verwendung von Festplatten mit fester Größe oder dynamischen Datenträgern. Darüber hinaus benötigen dynamische Festplatten deutlich weniger Speicherplatz. Daher werden dynamische Datenträger empfohlen.

Entscheidung: vDisk-Replikation

vDisks, die auf einem lokalen, Direct Attached Storage oder einem SAN gehostet werden, müssen zwischen vDisk-Stores repliziert werden, wenn eine vDisk erstellt oder geändert wird. Provisioning Services unterstützt die Replikation von vDisks aus lokalen Stores auf dem Provisioning-Server sowie die Replikation über mehrere Standorte hinweg, die gemeinsam genutzten Speicher verwenden. Die Replikation von vDisks kann manuell oder automatisch durchgeführt werden:

  • Manuell — Die manuelle Replikation ist einfach, kann jedoch zeitaufwändig sein, abhängig von der Anzahl der vDisks und vDisk-Stores. Wenn während des Replikationsprozesses ein Fehler auftritt, können Administratoren diese sofort abfangen und die entsprechenden Schritte ausführen, um sie zu beheben. Das Risiko einer manuellen Replikation besteht in der Inkonsistenz von vDisk über die Provisioning-Server hinweg, was dazu führt, dass Lastausgleich und Failover nicht ordnungsgemäß funktionieren. Wenn beispielsweise eine vDisk über drei Server repliziert wird und dann eine der vDisks aktualisiert wird, ist diese vDisk nicht mehr identisch und wird bei einem Server-Failover nicht berücksichtigt. Selbst wenn die beiden anderen vDisks dieselbe Aktualisierung vorgenommen wird, unterscheiden sich die Zeitstempel auf den beiden anderen vDisks, und daher sind die vDisks nicht mehr identisch.
  • Automatisiert — In großen Umgebungen ist die automatische Replikation aufgrund der Anzahl der erforderlichen vDisks und vDisk Stores schneller als die manuelle Methode. Einige automatisierte ToolsMicrosoft DFS-R, z. B. unterstützen Bandbreiteneinschränkung und Cross File Remote Differential Compression (CF-RDC), die Heuristik verwenden, um festzustellen, ob Zieldateien der Datei ähnlich sind repliziert. Wenn ja, verwendet CF-RDC Blöcke aus diesen Dateien, um die über das Netzwerk übertragene Datenmenge zu minimieren. Das Risiko einer automatisierten Replikation besteht darin, dass der Administrator Replikationsereignisse in der Regel nicht in Echtzeit überwacht und bei Auftreten von Fehlern nicht schnell reagiert, es sei denn, das Automatisierungswerkzeug verfügt über eine Warnfunktion. Einige Tools können so konfiguriert werden, dass der Kopiervorgang im Falle eines Fehlers automatisch neu gestartet wird. BeispielsweiseRobocopyunterstützt “Kopieren fortsetzen” für den Fall, dass die Netzwerkverbindung unterbrochen wird.

Verwenden Sie für mittlere und große Projekte ein Tool zur Automatisierung der vDisk-Replikation. Wählen Sie ein Werkzeug aus, das von Netzwerkunterbrechungen fortgesetzt, Dateiattribute kopiert und den ursprünglichen Zeitstempel beibehalten kann.

Hinweis:

Lastenausgleich und hohe Verfügbarkeit funktionieren nur, wenn die vDisks identische Zeitstempel aufweisen.

Entscheidung: Servergröße

Im Allgemeinen ist ein Provisioning Server mit den folgenden Spezifikationen definiert:

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

Modell

Citrix Provisioning Services können auf virtuellen oder physischen Servern installiert werden:

  • Virtuell — Bietet schnelle Serverbereitstellung, Snapshots für schnelle Recovery- oder Rollback-Szenarien und die Möglichkeit, Serverressourcen im laufenden Betrieb anzupassen. Virtual Provisioning-Server ermöglichen die Verteilung von Zielgeräten auf mehr Server und helfen dabei, die Auswirkungen von Serverausfällen zu reduzieren. Durch die Virtualisierung werden Systemressourcen effizienter genutzt.
  • Physisch— Bietet eine höhere Skalierbarkeit pro Server als virtuelle Server. Physische Provisioning-Server mindern die Risiken, die mit virtuellen Maschinen verbunden sind, die um zugrunde liegende Hypervisorressourcen konkurrieren. Im Allgemeinen werden virtuelle Provisioning-Server bevorzugt, wenn ausreichende Prozessor-, Arbeitsspeicher-, Festplatten- und Netzwerkressourcen zur Verfügung gestellt und garantiert verfügbar sind.

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 wird ein einzelner Fehlerpunkt eliminiert und bei einem Hostausfall nicht die gesamte Provisioning Services-Farm heruntergefahren.

CPU

Provisioning Services ist nicht CPU-intensiv. Unter Zuweisung der Anzahl der CPUs wirkt sich jedoch auf die Optimierung der Netzwerkströme aus. Die Anzahl der Streams, die ein Provisioning Services-Server gleichzeitig ausführen kann, kann durch die folgende Formel bestimmt werden:

Max. Anzahl der Streams = Anzahl der Ports x Anzahl der Threads/Port

Standardmäßig ist der Streaming-Dienst 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 benötigt werden, wechselt Provisioning Services kontinuierlich zwischen verschiedenen Zielgeräten

Wenn die Umgebung mehr als 160 gleichzeitige Ziele unterstützen muss, kann die Anzahl der Ports und Threads pro Port in der Provisioning Services-Konsole angepasst werden. Die beste Leistung wird erreicht, wenn die Threads pro Port nicht größer sind als die Anzahl der Kerne, die auf dem Provisioning-Server verfügbar sind. Wenn der Provisioning-Server nicht über ausreichende Kerne verfügt, zeigt der Server eine höhere CPU-Auslastung an, und Zielgeräte, die darauf warten, dass Anforderungen verarbeitet werden, haben eine höhere Leselatenz.

Obwohl Provisioning Services nicht CPU-intensiv ist, erfordert die Zuweisung von 2 CPUs einen größeren zusammenhängenden Netzwerkportbereich.

  • Kleine Umgebungen (bis zu 500 virtuelle Maschinen) 4 vCPUs werden empfohlen.
  • Größere Umgebungen werden 8 vCPUs empfohlen.

RAM

Das Windows-Betriebssystem, das Provisioning Services hostet, speichert die vDisks teilweise im Arbeitsspeicher (Systemcache), wodurch die Anzahl der Lesezugriffe aus dem Speicher reduziert wird. Das Lesen aus dem Speicher ist deutlich langsamer als das Lesen aus dem Speicher. Daher sollte den Provisioning-Servern genügend Arbeitsspeicher zugewiesen werden, um den Vorteil dieses Caching-Prozesses zu maximieren.

Die folgende Formel kann verwendet werden, um die optimale Speichermenge zu ermitteln, die einem Provisioning-Server zugewiesen werden soll:

Gesamt Server-RAM = 2GB + (Anzahl vDisks x 2GB)

Netzwerk

Im Gegensatz zu den meisten anderen XenApp- und XenDesktop-Komponenten stellt Provisioning Services keine Engpässe für die CPU dar. Die Skalierbarkeit von Provisioning Services basiert auf dem Netzwerkdurchsatz.

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

Betriebssystem Durchschnittliche Boot-Datenverwendung (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 2012R2 232
Windows 2008 R2 251
Windows Vista x86 190
Windows Vista x64 240

Bestimmen, wie viel Zeit benötigt wird, um die Zielgeräte zu starten, kann anhand der folgenden Formel geschätzt werden:

Sekunden zum Starten des Formelabbilds

Betriebssystem Anzahl der VMs Netzwerkdurchsatz Startzeit
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 die Verwendung mit Provisioning Services wird ein 10-Gbit/s -Netzwerk empfohlen. Wenn kein 10-Gbit/s -Netzwerk verfügbar ist, sollten Sie die Linkaggregation berücksichtigen, um zusätzliche Bandbreite für die Provisioning-Server oder ein dediziertes physisches Streamingnetzwerk bereitzustellen.

Tipp

Firewalls können Latenz hinzufügen und Bandbreitengpässe in Provisioning Services-Umgebungen verursachen. Wenn die Verwendung von Firewalls nicht vermieden werden kann, finden Sie im Citrix Whitepaper CTX101810— Communication Ports Used By Citrix Technologies (Communication Ports Used By Citrix Technologies) eine Liste der Ports, die für die volle Funktionalität aktiviert werden sollten.

Wachstum

Wenn die Farm wächst, müssen Administratoren entscheiden, ob sie den Provisioning-Servern weitere Ressourcen oder der Farm weitere Provisioning-Server hinzufügen möchten.

Bei der Ermittlung, ob die Provisioning-Server skaliert oder skaliert werden sollen, müssen eine Reihe von Umgebungsfaktoren berücksichtigt werden:

  • Redundanz — Die Verteilung der Benutzerlast auf zusätzliche, weniger leistungsfähige Server trägt dazu bei, die Anzahl der Benutzer zu reduzieren, die von einem einzelnen Provisioning-Server-Ausfall betroffen sind. Wenn das Unternehmen den Verlust eines einzelnen Servers mit hoher Spezifikation nicht akzeptieren kann, sollten Sie eine Skalierung in Erwägung ziehen.
  • Failoverzeiten — Je mehr Zielgeräte mit einem einzelnen Provisioning-Server verbunden sind, desto länger dauert das Failover für den Fall, dass der Server ausfällt. Ziehen Sie eine Skalierung in Betracht, um den Zeitaufwand für das Failover von Zielgeräten auf einen anderen Server zu verkürzen.
  • Kapazität des Rechenzentrums — Das Rechenzentrum ist möglicherweise nur begrenzt Platz, Stromversorgung und/oder Kühlung verfügbar. In diesem Fall sollten Sie eine Skalierung in Erwägung ziehen.
  • Hardwarekosten — Anfänglich kann die Skalierung kostengünstiger sein. Es wird jedoch einen Punkt geben, an dem die Skalierung tatsächlich kostengünstiger wird. Zu dieser Feststellung sollte eine Kostenanalyse durchgeführt werden.
  • Hostingkosten — Je nach Anzahl der verwendeten physischen Server können Hosting- und/oder Wartungskosten entstehen. Wenn ja, sollten Sie eine Skalierung in Erwägung ziehen, um die langfristigen Kosten dieser Gemeinkosten zu reduzieren.

Entscheidung: Netzwerkkonfiguration

Wie bereits erwähnt, ist es wichtig, dass das Netzwerk korrekt dimensioniert ist, um Netzwerkengpässe zu vermeiden, die hohe Laufwerkzugriffszeiten verursachen und sich direkt auf die Leistung des virtuellen Desktops auswirken. Im folgenden Diagramm wird eine gemeinsame Provisioning Services-Netzwerkinfrastruktur dargestellt:

Beispielbild für die pvs-Netzwerkkonfiguration

Die folgende Netzwerkkonfiguration wird für die Netzwerkabschnitte innerhalb des Diagramms empfohlen:

  • PVS-Uplink — Der gesamte Festplattenzugriff von den Zielgeräten wird über den PVS-Netzwerk-Uplink übertragen. Dies bedeutet, dass Hunderte oder sogar Tausende von Geräten diese Netzwerkverbindung verwenden. Daher ist es wichtig, dass diese Verbindung redundant ist und Failover ohne Ausfallzeiten möglich ist. Darüber hinaus empfiehlt Citrix eine Mindestbandbreite von 1 Gbit/s pro 500 Zielgeräte. Für virtuelle Provisioning-Server sollte ein entsprechendes QoS-Kontingent oder ein dedizierter physischer Netzwerk-Uplink konfiguriert werden, um eine optimale Leistung zu gewährleisten.
  • Hypervisor-Uplink — Wird von allen PVS-Zielgeräten verwendet, die auf einem bestimmten Hypervisor-Host gehostet werden. Daher wird dringend Redundanz mit transparentem Failover empfohlen. Sofern die Zielgeräte keine sehr E/A-intensive Arbeitslast ausführen oder E/A-intensive Aufgaben (z. B. Booten) gleichzeitig ausführen, reicht für diesen Uplink eine Bandbreite von 1 Gbit/s aus.
  • VM-Uplink — Der gesamte Netzwerkverkehr für eine virtuelle Maschine, einschließlich des PVS-Streaming-Datenverkehrs, durchquert diese virtuelle Netzwerkverbindung. Sofern die Arbeitslast nicht extrem E/A-intensiv ist, reicht eine Bandbreite von 100 Mbit/s aus, um auch Spitzenlasten bei E/A-intensiven Aufgaben zu bewältigen, z. B. beim Booten von vDisk. Ein Windows 2012 R2-Server liest etwa 232MB während eines Zeitraums von 90 Sekunden von der vDisk, bis der Windows-Anmeldebildschirm angezeigt wird. In diesem Zeitraum kann eine durchschnittliche Datenrate von 20,5 Mbit/s mit Spitzen bis zu 90 Mbit/s beobachtet werden.

Die folgenden Switch-Einstellungen werden für Provisioning Services empfohlen:

  • Spanning Tree deaktivieren oder PortFast aktivieren — In einer Switching-Umgebung versetzt das Spanning Tree Protocol (STP) Ports in einen blockierten Zustand, während es Bridged Protocol Data Units (BPDUs) überträgt und überwacht, um sicherzustellen, dass sich die BPDUs nicht in einer Loopback-Konfiguration befinden. Der Port wird erst dann in einen Weiterleitungszustand versetzt, wenn das Netzwerk konvergiert, was je nach Größe des Netzwerks genügend Zeit zur Folge hat, um PXE-Zeitüberschreitungen (Preboot Execution Environment) zu verursachen. Um dieses Problem zu beheben, deaktivieren Sie STP auf Edgeports, die mit Clients verbunden sind, oder aktivieren Sie PortFast.
  • Storm Control - Storm Control ist eine Funktion, die auf Cisco Switches verfügbar ist, mit der ein Schwellenwert festgelegt werden kann, durch den Multicast-, Broadcast- oder Unicastverkehr unterdrückt werden kann. Sein Zweck besteht darin, bösartige oder fehlerhafte Absender daran zu hindern, ein LAN zu überfluten und die Netzwerkleistung zu beeinträchtigen. PVS-Server senden möglicherweise einen großen Datenverkehr nach Entwurf, der innerhalb eines Sturmsteuerungsschwellenwertes liegt. Daher sollte die Funktion entsprechend konfiguriert werden.
  • Broadcast-Helfer — Der Broadcast-Helfer ist erforderlich, um Broadcasts von Clients auf Server zu leiten, die sonst nicht weitergeleitet werden würden. In einer PVS-Umgebung ist es notwendig, PXE-Startanforderungen weiterzuleiten, wenn sich Clients nicht im selben Subnetz wie die Server befinden. Der empfohlene Netzwerkentwurf besteht nach Möglichkeit darin, PVS-Server im gleichen Subnetz wie die Zielgeräte zu verwenden. Dies mindert das Risiko einer Service-Verschlechterung durch andere Netzwerk-Infrastrukturkomponenten.

Bei der Auswahl einer Netzwerkschnittstelle für Provisioning Services sollten die folgenden Netzwerkschnittstellen-Features berücksichtigt werden:

  • TCP-Auslagerung — Das Verlagern von E/A-Tasks auf die Netzwerkschnittstelle reduziert die CPU-Auslastung und verbessert die Systemleistung. PVS Streaming-Dienste können jedoch negativ beeinflusst werden, wenn Large Send Offload aufgrund der zusätzlichen Arbeit am Netzwerkadapter aktiviert ist. Bei vielen Netzwerkadaptern ist die Standardeinstellung “Large Send Offload” und “TCP-Prüfsummenabladung” aktiviert.

Hinweis:

Wenn Large Send Offload aktiviert ist und der Switch, den der Datenverkehr durchläuft, die von der Large Send Offload Engine gesendet wird, nicht unterstützt, lässt der Switch den Frame ab, der die Datenübertragung verursacht. Bei der erneuten Übertragung segmentiert das Betriebssystem die Frames anstelle des Netzwerkadapters, was zu erheblichen Leistungseinbußen führen kann.

  • RSS (Receive Side Scaling) — Die Empfangsseitige Skalierung ermöglicht den Ausgleich von Paketen, die von einem Netzwerkadapter empfangen werden, über mehrere CPUs hinweg, wodurch eingehende TCP-Verbindungen Lastenausgleich ausgeführt werden können, wodurch Engpässe an einer einzelnen CPU entstehen. In Windows Server 2008 R2 und Windows Server 2012/2012 R2 ist RSS standardmäßig aktiviert.

Hinweis:

Weitere Informationen zu bewährten Methoden für PVS-Netzwerke finden Sie unterBest Practices für die Konfiguration des Provisioning Services-Servers in einem Netzwerk.

Für Provisioning Services-Implementierungen in Netzwerken mit geringer Bandbreite (1 Gbit/s oder langsamer) kann die Leistung verbessert werden, indem der Streaming-Datenverkehr vom anderen Netzwerkverkehr im LAN isoliert wird.

Microsoft unterstützt keine 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 Supportabfragen bezüglich der Teaming-Verbindung mit Hyper-V sollten an den NIC-OEM weitergeleitet werden.

Entscheidung: Subnetzaffinität

Die Provisioning Services-Subnetzaffinität ist ein Lastausgleichsalgorithmus, mit dem sichergestellt wird, dass Zielgeräte mit dem am besten geeigneten Provisioning-Server verbunden sind. Bei der Konfiguration der Subnetzaffinität stehen die folgenden Optionen zur Verfügung:

  • Keine — Subnetze ignorieren; verwendet den am wenigsten ausgelasteten Server.
  • Bester Aufwand— Verwendet die am wenigsten ausgelasteten Server/NIC -Kombination aus demselben Subnetz. Wenn im Subnetz keine Server/NIC -Kombination verfügbar ist, wählen Sie den am wenigsten ausgelasteten Server außerhalb des Subnetzes aus. Wenn mehrere Server innerhalb des ausgewählten Subnetzes verfügbar sind, führen Sie Lastenausgleich zwischen diesen Servern durch. Dies ist die Standardeinstellung.
  • Behoben— Verwenden Sie die am wenigsten ausgelasteten Server/NIC -Kombination innerhalb desselben Subnetzes. Führen Sie Lastausgleich zwischen Servern innerhalb dieses Subnetzes durch. Wenn keine Server/NIC -Kombination im selben Subnetz vorhanden ist, booten Sie keine Zielgeräte, die dieser vDisk zugewiesen sind.

Die folgenden Beispiele zeigen allgemeine 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 wird.

Klingendesign

Die Provisioning-Server und die von ihnen unterstützten Zielgeräte sind in demselben Gehäuse. In den meisten Fällen verfügt das Gehäuse über einen dedizierten 10-Gbit/s -Switch, der von allen Blade-Servern innerhalb des Gehäuses gemeinsam genutzt wird.

Design des Blade-Gehäuses

Die Subnetzaffinitätsoption “Bester Aufwand” wird verwendet, um Provisioning Services-Datenverkehr innerhalb desselben Gehäuses beizubehalten. Sollte der Provisioning-Server nicht verfügbar sein, erfolgt ein Failover auf den zweiten Provisioning-Server im zweiten Gehäuse, jedoch auf denselben Provisioning Services-Site.

Rack-Design

Das zweite Beispiel basiert auf einem Rack-Design, das Rack-Switches verwendet, um den Provisioning-Datenverkehr im Rack zu halten.

PVS-Rack-Entwurfsbild

Im Gegensatz zum Blade-Gehäusedesign wird die Subnetz-Affinitätsfunktion nicht verwendet. Stattdessen wird pro Server-Rack ein Provisioning Services-Site mit zwei Provisioning-Servern konfiguriert. Dadurch wird sichergestellt, dass die Zielgeräte von Provisioning-Servern innerhalb desselben Racks gestreamt werden.

Erfahrung aus dem Feld

Fertigung — Ein Fertigungsunternehmen entwickelt eine Provisioning Services-Lösung zur Unterstützung von fünftausend virtuellen Desktops. Das Unternehmen hat Bedenken, dass Provisioning Services-Streaming-Datenverkehr einen Engpass im Netzwerk verursachen kann, der andere Anwendungen betrifft. Das Unternehmen hat sich dafür entschieden, die Umgebung auf Bladeservern zu erstellen, sodass das Provisioning des Datenverkehrs im Bladegehäuse enthalten ist und keinen Einfluss auf den anderen Netzwerkverkehr hat.

Entscheidung: Lesecache

Mit PVS Accelerator kann sich ein PVS-Proxy in der Steuerungsdomäne des XenServers auf einem Host befinden, auf dem das Streaming einer Provisioning Services-vDisk im Proxy zwischengespeichert wird, bevor sie an die virtuelle Maschine weitergeleitet wird. Über den Cache kann nachfolgendes Booten (oder alle E/A-Anforderungen) der virtuellen Maschine auf demselben Host vom Proxy gestreamt werden, anstatt vom Server über das Netzwerk zu streamen. PVS Accelerator erfordert mehr lokale Ressourcen auf dem XenServer-Host, aber das Streaming vom Server über das Netzwerk spart Ressourcen und verbessert die Leistung effektiv.

PVS Lesecache-Bild

PVS Accelerator ist nur eine XenServer-Funktion. Durch die Verwendung dieser integrierten Technologie wird die Belastung des PVS-Servers reduziert, die gesamte Netzwerkauslastung reduziert und der Zeitaufwand für den Start einer virtuellen Maschine reduziert.

PVS-Beschleunigerbild

Weitere Informationen zur Beziehung zwischen XenServer und Provisioning Services finden Sie im BlogXenServer und PVS: Gemeinsam besser.

Entscheidung: Schreibcache

Da das Masterimage schreibgeschützt ist, verfügt jede virtuelle Maschine über eine beschreibbare Festplatte, in der alle Änderungen gespeichert werden können. Der Administrator muss entscheiden, wo der Schreib-Cache-Datenträger gespeichert werden soll.

PVS-Server — Lokaler Speicher

Der lokale Provisioning Services-Speicher enthält die Schreib-Cache-Laufwerke für jede virtuelle Zielmaschine. Obwohl dies die Standardeinstellung ist, erhöht sie die Anforderungen an die Netzwerkbandbreite und erhöht die Auslastung des Provisioning Services-Servers.

Serverseitiges lokales Speicherabbild

PVS-Server — Gemeinsamer Speicher

Gemeinsamer Speicher, der dem Provisioning Services-Server zugeordnet ist, enthält die Schreib-Cache-Laufwerke für jede virtuelle Zielmaschine. Diese Option erhöht die Anforderungen an die Netzwerkbandbreite und erhöht die Auslastung des Provisioning Services-Servers. Es platziert auch temporäre Daten (Schreibcache) auf teuren gemeinsam genutzten Speicher.

Server-seitiges freigegebenes Speicherabbild

VM — Lokaler Speicher

Der lokale Speicher, der der virtuellen Maschine zugeordnet ist, enthält die Schreib-Cache-Laufwerke für jede virtuelle Zielmaschine. Diese Option verwendet kostengünstiger lokaler Speicher und verbraucht keine zusätzlichen Ressourcen auf dem Provisioning Services-Server. Der lokale Speicher muss jedoch in der Lage sein, die IOPS aller virtuellen Maschinen auf dem Host zu unterstützen.

Image für lokales VM-Speicher

VM — Cache im RAM

Der mit der virtuellen Maschine verknüpfte RAM enthält die Schreib-Cache-Laufwerke für jede virtuelle Zielmaschine. Diese Option bietet eine hohe Leistung aufgrund der Geschwindigkeit des RAM. Wenn der RAM-Cache jedoch nicht genügend Speicherplatz hat, wird die virtuelle Maschine unbrauchbar. Um diese Option zu verwenden, muss jeder virtuellen Maschine erhebliche Mengen an RAM zugewiesen werden, was die Gesamtkosten erhöht.

VM-Cache im RAM-Image

VM — Cache im RAM mit Überlauf auf Festplatte

Eine Kombination aus RAM und lokalem Speicher wird für den Schreibcache verwendet. Erstens werden Schreibvorgänge im RAM-Cache gespeichert, was eine hohe Leistung bietet. Während der RAM-Cache verbraucht wird, werden große Blöcke aus dem RAM-Cache entfernt und auf dem lokalen Speicherschreib-Cache-Datenträger platziert. Diese Option bietet ein hohes Maß an Leistung bei niedrigen Kosten des lokalen Speichers.

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

VM-Cache im RAM-Image

Cache im RAM mit Overflow to Disk ist die empfohlene Option.

VM-Cache im RAM-Image

Entscheidung: Antivirus

Standardmäßig scannen die meisten Antivirenprodukte alle Dateien und Prozesse, was sich erheblich auf die Leistung von Provisioning Services auswirkt. Weitere Informationen darüber, wie Antivirensoftware für Provisioning Services optimiert werden kann, finden Sie unterCTX124185— Provisioning Services Antivirus Best Practices.

Antivirussoftware kann Probleme beim Sperren von Dateien auf Provisioning-Servern verursachen. Der vDisk Store und der Schreibcache sollten von Antiviren-Scans ausgeschlossen werden, um Probleme mit Dateikonflikten zu vermeiden.

Wenn ein virtuelles Laufwerk im Standardmodus ausgeführt wird und neu gestartet werden muss, werden alle zuvor geladenen Virendefinitionen heruntergeladen. Dies kann zu Leistungseinbußen führen, wenn mehrere Zielgeräte gleichzeitig neu gestartet werden, was häufig zu Netzwerküberlastungen führt, während der Vorgang fortbesteht. Im Extremfall können das Zielgerät und der Provisioning-Server langsamer werden und mehr Ressourcen verbrauchen als nötig. Wenn die Antivirensoftware dies unterstützt, sollten Definitionsdateien auf das Schreib-Cache-Laufwerk umgeleitet werden, damit sie zwischen Neustarts beibehalten werden.

Maschinenerstellungsdienste

Machine Creation Services (MCS) verwendet Datenträger-Cloning-Technologie, um die Bereitstellung virtueller Maschinen zu vereinfachen. Computer werden in Echtzeit von einem einzigen freigegebenen Datenträgerimage bereitgestellt und neu bereitgestellt. Dadurch können Administratoren die Notwendigkeit entfallen, einzelne Systeme zu verwalten und zu patchen. Stattdessen führen Administratoren die gesamte Image-Verwaltung für das Masterimage aus.

Entscheidung: Lagerort

Mit den Machine Creation Services können Administratoren einen virtuellen Desktop in mehrere Komponenten aufteilen und diese in verschiedenen Speicher-Arrays speichern.

Gemeinsamer Speicher

Bei der ersten Option wird gemeinsam genutzter Speicher für den Betriebssystemdatenträger und den differenzierenden Datenträger verwendet.

MCS freigegebenes Speicherabbild

Obwohl diese Option die Freigabe des Master-Images über mehrere Hypervisor-Hosts ermöglicht, belastet sie das Speicher-Array, da es auch den differenzierenden Datenträger hosten muss, d. h. temporäre Daten.

Hybrid-Speicher

Bei der zweiten Option werden gemeinsam genutzter Speicher für den Betriebssystemdatenträger und lokaler Hypervisorspeicher für den differenzierenden Datenträger verwendet.

MCS Hybrid-Speicherabbild

Dies ist die gebräuchlichste Option, die dem Administrator die Vorteile bietet, das Masterimage über mehrere Hypervisor-Hosts freizugeben und gleichzeitig teure temporäre Schreib-IOPS auf den preiswerten lokalen Hypervisor-Speicher zu verlagern.

XenServer IntelliCache-Speicher

Bei der dritten Option werden gemeinsam genutzter Speicher für die Betriebssystemfestplatte und lokaler Hypervisorspeicher für den differenzierenden Datenträger und lokaler XenServer-Speicher für einen lokalen Cache der Betriebssystemfestplatte verwendet.

Dies ist nur eine Option für XenServer-Implementierungen. Es bietet den gleichen Wert wie der Hybridspeicheransatz und reduziert gleichzeitig die Lese-IOPS von gemeinsam genutztem Speicher. IntelliCache kann mit dem XenServer RAM-basierten Lesecache koexistieren, wenn der XenServer-RAM begrenzt ist.

MCS IntelliCache-Bild

Entscheidung: Klontyp

Machine Creation Services umfasst zwei Arten von Klonen.

  • Dünn — Jede VM im Katalog verwendet für alle Lesevorgänge ein einziges, schreibgeschütztes virtuelles Laufwerk. Ein zweites virtuelles Laufwerk, das für jede VM einzigartig ist, erfasst alle Schreib-E/A-Aktivitäten.
  • Vollständig — Jede VM im Katalog erhält eine vollständige Kopie des Master-Disk-Images. Jede VM besitzt die Festplatte vollständig und ermöglicht Lese-/Schreibaktivitäten. Vollständige Cloning-Technologie ist nur für persönliche virtuelle Desktops verfügbar, bei denen eine dedizierte virtuelle Maschine alle Änderungen auf einem lokalen Datenträger speichert.

Administratoren sollten bei der Entscheidung zwischen Thin und Full Cloning-Technologien Folgendes berücksichtigen:

  Thin Clone Vollständiger Klon
Speicherplatzbedarf Höchste Speicherplatzeinsparung. Ein einzelnes Master-Disk-Image wird für mehrere VMs freigegeben. Nur der differenzierende Datenträger (Schreibvorgänge) belegt Speicherplatz, der bis zum Neustart der VM weiter wächst. Hoher Speicherplatzbedarf. Jede VM erhält eine vollständige Kopie des Masterimage. Die Größe wächst weiter, wenn Änderungen an der VM vorgenommen werden.
Sicherung/Wiederherstellung Schwierig. Viele Backup-/DR -Lösungen von Drittanbietern unterstützen keine Snapshot-/Delta -Festplatten, wodurch Thin bereitgestellte VMs schwer oder unmöglich sind, eine Sicherung oder einen Wechsel zu anderen Speicher-Arrays zu ermöglichen. Ganz ruhig. Die VM befindet sich in einem einzigen virtuellen Laufwerk, was die Sicherung und Wiederherstellung vereinfacht.
Provisioninggeschwindigkeit Schnell. Erfordert nur ein einzelnes Diskimage Langsam (kann gemildert werden). Für jede VM ist eine vollständige Kopie des Masterimage erforderlich. Speicheroptimierungstechnologien können zur Minderung beitragen.
Leistung Langsamer. Eine Lese-E/A kann zweimal auftreten, eine für Master-Festplatte und eine für Differenzierung der Festplatte, wodurch die Lese-IOPS erhöht wird. Schneller. Alle Lese-/Schreibzugriff direkt auf eine einzelne Festplatte.
Boot Sturm Hohe Schlagkraft. In einem Boot-Sturm starten alle unterschiedlichen Datenträger neu, um alle Schreibvorgänge von Windows zu speichern, und legen eine hohe Last auf dem Speicher, wie es alles auf einmal geschieht. Geringe Schlagkraft

Entscheidung: Lesecache

Während des Bootens und der Anmeldung entstehen für virtuelle Desktops hohe Speicher-IOPS, wodurch das zugrunde liegende Speichersubsystem belastet werden kann. Bei der Bereitstellung auf Citrix XenServer verwenden die VDI-Modi für gemeinsam genutzte und gepoolte VDI-Modi einen RAM-basierten Lesecache, der auf jedem XenServer gehostet wird.

MCS Lesecache-Image

Durch die Verwendung dieser integrierten Technologie wird die Lese-IOPS um 50- 80% reduziert.

MCS Lesecache-Rasterbild

Entscheidung: Schreibcache

Während des Steady State haben virtuelle Desktops einen hohen Grad an Speicherschreib-IOPS, was das zugrunde liegende Speichersubsystem belastet. Gemeinsam genutzte und gepoolte VDI-Modi können einen RAM-basierten Schreibcache verwenden, indem der nicht ausgelagerte Pool-RAM aus dem Betriebssystem der virtuellen Maschinen verwendet wird.

MCS Schreibcache-Image

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

MCS Schreibcache-Rasterbild

Sicherheit

Abhängig von den Anforderungen der Organisation sollten unterschiedliche Sicherheitsstandards innerhalb der Lösung implementiert werden. Es ist ratsam, sich auf die folgenden Papiere zu beziehen:

Haftungsausschluss

The official version of this content is in English. Some of the Citrix documentation content is machine translated for your convenience only. Citrix has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Citrix product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Citrix, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Citrix will not be held responsible for any damage or issues that may arise from using machine-translated content.

Gestaltungsmethodik-Kontrollschicht