Design

Das Gestalten einer Desktop-Virtualisierungslösung basiert vor allem auf dem Befolgen eines bewährten Verfahrens unter Berücksichtigung organisatorischer und anwenderbezogener Anforderungen. Ohne ein bewährtes Standardverfahren neigen Architekten dazu, willkürlich von Thema zu Thema zu springen, was zu Verwirrung und Fehlern führt. Der empfohlene Ansatz konzentriert sich auf fünf Schichten:

Bild des fünfschichtigen Designmodells

Die oberen drei Schichten werden individuell für jede Benutzergruppe entworfen, die bei der Analyse im Abschnitt zur Benutzersegmentierung identifiziert wurde. Diese Schichten definieren die Benutzerressourcen und wie Benutzer auf diese Ressourcen zugreifen. Nach Fertigstellung dieser drei Schichten werden die Grundlagenschichten (Steuerung und Hardware) für die gesamte Lösung gestaltet.

Dieses Verfahren erläutert, wie Entscheidungen für die oberen Schichten das Design der unteren Schichten beeinflussen.

Schicht 0: Konzeptionelle Architektur

Die konzeptionelle Architektur unterstützt die Definition grundlegender Strategien für die gesamte Lösung basierend auf den Geschäftszielen und der Struktur der Organisation.

Obwohl sich die konzeptionelle Architektur einer Organisation mit den Jahren ändern wird, lohnt es sich, zu Beginn der Designphase die langfristigen Ziele in Bezug auf Bereitstellungsmodelle und die physische, geografische Verteilung der Lösung zu definieren.

Entscheidung: Bereitstellungsmodell

Eine XenDesktop- und XenApp-Lösung kann auf verschiedene Weise bereitgestellt werden. Die Geschäftsziele der Organisation helfen bei der Auswahl des richtigen Ansatzes. Selbst wenn die Infrastruktur für alle Bereitstellungsmodelle gleich bleibt, ändert sich der Verwaltungsumfang des IT-Teams vor Ort.

  • On-premises – Alle Komponenten werden im lokalen Datencenter der Organisation gehostet. Beim On-premises-Modell muss die gesamte Lösung vom lokalen IT-Team verwaltet werden.

Bild einer On-premises-Architektur

  • Öffentliche Cloud - Alle Komponenten werden mit IaaS (Infrastructure as a Service) in einer öffentlichen Cloud gehostet. Beim Modell mit öffentlicher Cloud wird die Hardware nicht mehr vom lokalen IT-Team verwaltet.

Bild einer Architektur mit öffentlicher Cloud

  • Hybridcloud – Eine einzelne Implementierung wird sowohl in einem On-premises-Datencenter und in der öffentlichen Cloud ausgeführt. Obwohl Komponenten der Lösung über verschiedene Anwender gehostet werden, bleibt es eine einzelne Lösung, die denselben Code verwendet und als eine Entität verwaltet wird. Das lokale IT-Team verwaltet weiterhin alle Aspekte der Lösung mit Ausnahme der Hardware, die mit den Cloud-gehosteten Ressourcen verknüpft ist.

Bild einer Hybridcloud-Architektur

  • Citrix Cloud – Der XenApp und XenDesktop Service von Citrix Cloud unterteilt eine typische Bereitstellung in mehrere Verwaltungsdomänen. Die Komponenten der Zugriffs- und Steuerungsschicht werden von Citrix in der Citrix Cloud gehostet und verwaltet, während die Komponenten der Ressourcenschicht weiterhin vom lokalen IT-Team verwaltet werden: entweder on-premises, als öffentliche Cloud oder als Hybridcloud-Modell. Citrix verwaltet Hardware, Dimensionierung und Aktualisierung der Zugriffs- und Steuerungskomponenten, während das lokale IT-Team die Ressourcen verwaltet. Werden die Ressourcen in der öffentlichen Cloud gehostet, muss das lokale IT-Team die Ressourcenhardware nicht verwalten. Das Citrix Cloud-Angebot zur Unterstützung bestimmter Benutzeranwendungen wird kontinuierlich erweitert. Weitere Informationen zur gesamten Angebotspalette finden Sie in den Workspace-Diensten von Citrix Cloud.

Bild einer Citrix Cloud-Architektur

Entscheidung: Sitetopologie

Eine XenApp und XenDesktop-Site gruppiert Desktops und Anwendungen in einer einzigen Architektur- und Verwaltungseinheit. Alle persistenten und dynamischen Daten für die Site, einschließlich Sitekonfiguration, Desktopzuweisungen und Sitzungszustand, werden in einer Sitedatenbank gespeichert.

Eine Site kann einen einzelnen Standort umfassen, sich über mehrere Standorte erstrecken oder Teil eines Standorts sein. Durch rigorose Tests kann eine einzelne XenApp/XenDesktop-Site 40.000 oder mehr gleichzeitige Sitzungen unterstützen.

Bild von Bereitstellungssite 1

Bild von Bereitstellungssite 2

Bild von Bereitstellungssite 3

Sites können in Zonen unterteilt werden, die oft mit geografischen Standorten verknüpft sind. Bei der Bestimmung der Gesamttopologie der XenApp und XenDesktop-Lösung sind mehrere Faktoren zu berücksichtigen:

  • Risikotoleranz – Erstellen Sie mehrere XenDesktop-Sites, um die Auswirkungen eines siteübergreifenden Ausfalls zu minimieren. Beispielsweise könnte bei Beschädigung der XenDesktop-Sitedatenbank die Verfügbarkeit der gesamten Site beeinträchtigt werden. Für viele Organisationen überwiegt die höhere Sicherheit durch mehrere implementierte Sites den zusätzlichen Verwaltungsaufwand und die erforderliche Unterstützungsinfrastruktur.

Praxiserfahrung

Finanzwesen – Ein großes Finanzinstitut hostet 10.000 Desktops in einem einzelnen Datencenter. Um das Risiko zu verringern, wird festgelegt, dass keine Site mehr als 5000 Desktops umfassen darf. Es werden zwei Sites erstellt, obwohl Desktops über ein schnelles und redundantes Netzwerk miteinander verbunden sind.

  • Sicherheit – Trotz verfügbarer delegierter Administration müssen manche Organisationen mit hohem Sicherheitsbedarf zur Einhaltung bestimmter Servicelevelziele Umgebungen vollständig trennen.

Praxiserfahrung

Einzelhandel – In einem Einzelhandelsunternehmen müssen alle Mitarbeiter, die Finanzdaten verwalten, vollständig getrennt werden. Um diese Anforderung zu erfüllen, werden im Datencenter zwei separate Sites eingerichtet: eine Site für Finanzangestellte und eine Site für alle übrigen Mitarbeiter.

  • Verwaltungsgrenzen – Aufgrund von Abrechnungs- und Rückbelastungsanforderungen oder der IT-Struktur sind möglicherweise mehrere Sites erforderlich, um Verwaltungsgrenzen zu trennen.

  • Geographische Konnektivität – Obwohl eine Site mit implementierten Zonen mehrere geografische Standorte umfassen kann, muss zwischen Satellitenzone und primärer Zone genügend Bandbreite vorhanden sein, um die Sitzungsinformationen in der Sitedatenbank zu erfassen. Eine höhere Latenz oder größere Zonen beeinflussen die Reaktionszeiten für den Benutzer.

Variable XenApp und XenDesktop 7.13 XenApp und XenDesktop 7.11
Latenz (ms) 90 250
Gleichzeitige Anfragen 48 48
Durchschnittliche Reaktionszeit 3,7 7,6
Vermittelte Anforderungen pro Sekunde 12,6 6,3
Startzeit für 10.000 Benutzer 13 Minuten 26 Minuten
Sitzungsanzahl Max. gestartete gleichzeitige Sitzungen Min. siteübergreifende Bandbreite Max. Latenz für siteübergreifende Roundtrip-Zeit
Weniger als 50 20 1 MBit/s 250 ms
50 bis 500 25 1,5 MBit/s 100 ms
500 bis 1000 30 2 MBit/s 50 ms
1000 bis 3000 60 8 MBit/s 10 ms
Mehr als 3000 60 8 MBit/s 5 ms

Im Allgemeinen sollten Administratoren möglichst wenige XenDesktop-Sites und -Zonen verwenden, um die Komplexität der Architektur und den Verwaltungsaufwand zu verringern.

Entscheidung: Imageverwaltungsstrategie

Eine XenApp und XenDesktop-Lösung erfordert die Erstellung und Verwaltung von Masterimages. Organisationen müssen frühzeitig entscheiden, welche Imageverwaltungsstrategie sie verfolgen möchten.

Installierte Images

Für ein installiertes Image muss der Administrator das Betriebssystem und die Anwendungen für jedes Image installieren. Dieser Ansatz ist unkompliziert, sorgt jedoch für duplizierte Prozesse, da Betriebssystem und Kernanwendungen auf mehreren Masterimages installiert werden müssen.

Die Pflege von Masterimages ist ebenfalls aufwändig, da die Betriebssystemversion und Kernanwendungen Teil mehrerer Images sind, die alle denselben Aktualisierungsprozess erfordern.

Skriptbasierte Images

Administratoren können zahlreiche Aufgaben, die mit installierten Images verbunden sind, mit Skript- oder Automatisierungstools vereinfachen. In vielen Betriebssystem- und Anwendungsinstallationen können Automatisierungsskripts den Aufwand verringern, der durch duplizierte Prozesse bei installierten Images entsteht.

Leider ist das Lernen, Erstellen und Verwalten eines Skriptframeworks für das gesamte Image eine anspruchsvolle und zeitaufwändige Aufgabe. Die Skripterstellung für einen kompletten Build dauert Zeit und führt häufig zu unerwarteten Fehlern, wenn Verzeichnisstrukturen sich ändern, Prozesse zu lange dauern oder ein Dateiname sich ändert.

Layerimages

Jedes Betriebssystem (Windows 10, Windows 2012R2 und Windows 2016), jede Plattform (XenApp/XenDesktop 7.13 VDA, XenApp/XenDesktop 7.14 VDA und XenApp/XenDesktop 7.15 VDA) und jede Anwendung (Microsoft Office, Adobe Acrobat, Google Chrome und Mozilla Firefox) bilden eine Schicht. Ein Masterimage verbindet eine Betriebssystemschicht, eine Plattform und zahlreiche Anwendungen.

Ein Design mit Layerimages vermeidet einen verdoppelten Aufwand durch installierte und skriptbasierte Images. Jede eindeutige Schicht ist für jedes Masterimage verfügbar. Wenn eine Anwendung aktualisiert werden muss, empfängt diese Schicht die Updates. Alle Masterimages, die diese Schicht verwenden, erhalten dann das Update. Wenn für eine Organisation zehn eindeutige Windows 10-Images erforderlich sind, wird für jedes der zehn Images dieselbe Windows 10-Schicht verwendet. Wenn der Administrator auf zehn Images den VDA von Version 7.14 auf 7.15 aktualisieren muss, aktualisiert der Administrator nur eine einzelne Plattformschicht.

Zunächst erfordert der Layerimage-Ansatz mehr Zeit für die Bereitstellung, da der Administrator eine Bibliothek aller Schichten für die Organisation erstellen muss. Sobald die Schichten jedoch verfügbar sind, verkürzt dies die Zeit für die Imagepflege enorm.