Hardware-Schicht der Entwurfsmethodik

Hinweis

Dieser Artikel wurde maschinell übersetzt. Haftungsausschluss

Auf Englisch anzeigen

Dieser Abschnitt behandelt die Hardwaregröße für die Server der virtuellen Infrastruktur, virtuelle Desktops und Hosts der virtuellen Anwendung. Die Größe dieser Server erfolgt in der Regel auf zwei Arten.

  • Der erste und bevorzugte Weg besteht darin, Hardware basierend auf den Anforderungen der Arbeitslast zu planen und zu erwerben.
  • Die zweite Möglichkeit besteht darin, vorhandene Hardware in der besten Konfiguration zu verwenden, um die unterschiedlichen Anforderungen an die Arbeitslast zu unterstützen.

In diesem Abschnitt werden Entscheidungen in Bezug auf beide Methoden diskutiert.

Entscheidung: Trennung der Arbeitslast

Beim Implementieren einer XenApp- und XenDesktop-Bereitstellung können die Arbeitslasten für die Infrastruktur-, XenDesktop- und XenApp-Arbeitslasten in dedizierte Ressourcencluster getrennt oder auf denselben physischen Hosts gemischt werden. Citrix empfiehlt die Verwendung von Ressourcenclustern, um die Arbeitslasten zu trennen, insbesondere in einer Enterprise-Bereitstellung. Dies ermöglicht eine bessere Host-Dimensionierung, da jede Arbeitslast spezifische Anforderungen wie Overcommit-Verhältnisse und Speicherauslastung hat.

In kleineren Umgebungen, in denen Ressourcen-Cluster kostspielig sind, können die Arbeitslasten in einer Weise gemischt werden, die dennoch eine hochverfügbare Umgebung ermöglicht. Die führende Praxis von Citrix besteht darin, die Arbeitslasten zu trennen, jedoch sind gemischte Arbeitslasten eine kostenbasierte Geschäftsentscheidung.

Entscheidung: Physischer Prozessor (pCPU)

Die folgende Tabelle enthält Anleitungen zur Anzahl der virtuellen Desktops, die für leichte, mittlere und schwere Arbeitslasten pro physischen Kern unterstützt werden können. Jeder Desktop korreliert mit einem einzigen gleichzeitigen Benutzer, wobei davon ausgegangen wird, dass das Betriebssystem optimiert wurde.

Benutzerarbeitslasten

  • Leicht
Betriebssystem Benutzer pro physischen Kern
Windows 7 13
Windows 8 12
Windows 10 12
Windows 2008R2 18
Windows 2012R2 21
Windows 2016 21
  • Mittel
Betriebssystem Benutzer pro physischen Kern
Windows 7 10
Windows 8 9
Windows 10 9
Windows 2008R2 12
Windows 2012R2 14
Windows 2016 14
  • Schwer
Betriebssystem Benutzer pro physischen Kern
Windows 7 5
Windows 8 4
Windows 10 4
Windows 2008R2 6
Windows 2012R2 7
Windows 2016 7

Die Schätzung für “Benutzer pro physischen Kern” ist eine Basisnummer, auf der Microsoft Office 2010 ausgeführt wird. Die Basisnummer muss auf der Grundlage spezifischer Infrastrukturanforderungen angepasst werden. Als allgemeine Richtlinie sind die folgenden Merkmale Basisänderungen der Serverdichte.

Charakteristisch Auswirkungen auf die Serverdichte
Virenschutz (nicht optimiert) 25% Abnahme
Echtzeitüberwachung 15% Abnahme
Office 2013 20% Abnahme
Office 2016 25% Abnahme
Hyper-Threading 20% Erhöhung

Verwenden Sie für jede Benutzergruppe die folgende Formel, um die Gesamtanzahl der physischen Kerne zu schätzen, die für die XenApp- und XenDesktop-Arbeitslast erforderlich sind:

Abbildung der Arbeitslastformel

Σ ist die Summe aller Benutzergruppenkombinationen “i”.

Usersi = Anzahl gleichzeitiger Benutzer pro Benutzergruppen

UsersPerCorei = Anzahl der Benutzer pro physischen Kern

AV = Auswirkungen auf das Virenschutzprogramm (Standard = 0,25)

Mon = Auswirkungen der Überwachungswerkzeuge (Standard = 0,15)

Off13 = Auswirkungen auf Office 2013 (Standard = .2)

Off16 = Auswirkungen auf Office 2016 (Standard = 0,25)

HT = Hyper-Threading-Auswirkungen (Standard = .2)

Wenn Arbeitslasten getrennt werden (XenApp- und XenDesktop-Arbeitslasten), sollte die Formel zweimal berechnet werden, einmal für alle XenDesktop-Benutzer und die zweite für alle XenApp-Benutzer, um

Entscheidung: Physischer Speicher (pRAM)

Die empfohlene Methode für die Dimensionierung des Speichers für einen physischen Host ist die Größe basierend auf dem Gesamtspeicher, der für die Unterstützung der virtuellen Maschinen erforderlich ist, und der CPU-Kapazität des Hosts. Um den für XenApp und XenDesktop benötigten Gesamtspeicher zu berechnen, multiplizieren Sie einfach die Anzahl der virtuellen Maschinen mit dem Arbeitsspeicher, der den virtuellen Maschinen zugewiesen ist. Die Summe aller Maschinenkataloge entspricht dem Gesamtarbeitsspeicher, der für XenApp- und XenDesktop-Hosts benötigt wird. Dies wird in der folgenden Formel gezeigt.

Abbildung der Arbeitslastformel

Σ ist die Summe aller Benutzergruppenkombinationen “i”.

VMi = Anzahl gleichzeitiger Benutzer pro Benutzergruppen

vRAMi = Menge des Arbeitsspeichers, der jeder virtuellen Maschine zugewiesen ist

Wenn Arbeitslasten auf verschiedene Hosts (XenApp- und XenDesktop-Arbeitslasten) getrennt werden, sollte die Formel zweimal berechnet werden, einmal für alle XenDesktop-Benutzer und die zweite für alle XenApp-Benutzer.

Entscheidung: Physischer Host (pHost)

In den meisten Situationen ist die Anzahl der physischen Hosts (pHost) zur Unterstützung der XenApp- und XenDesktop-Arbeitslasten auf die Anzahl der verfügbaren Prozessorkerne begrenzt. Die folgende Formel liefert eine Schätzung für die Anzahl der Hosts, die für die Benutzerarbeitslasten erforderlich sind. Die Formel basiert auf der bewährten Vorgehensweise zum Trennen der XenApp- und XenDesktop-Arbeitslasten aufgrund der unterschiedlichen empfohlenen CPU-Überkommit-Verhältnisse für die einzelnen Workloads.

XenDesktop pHost = (Gesamt XenDesktop pCPU/Kerne pro pHost + 1)

XenApp pHost = (Anzahl XenApp-pCPU/Kerne pro pHost + 1)

Sobald die Anzahl der physischen Hosts basierend auf Prozessorkernen ermittelt wurde, wird die Menge an RAM für jeden Host berechnet.

XenDesktop pRAM pro pHost = HyperVisorRAM + (Gesamt XenDesktop pRAM / XenDesktop pHosts -1)

XenApp-pram pro pHost = HyperVisorRAM + (Gesamt XenApp pRAM / XenApp pHosts -1)

Entscheidung: GPU

Hosts, die zur Bereitstellung grafischer Arbeitslasten verwendet werden, erfordern Grafikprozessoren, um eine hohe Benutzererfahrung zu bieten. Für die Unterstützung von High-End-Grafiken mit HDX 3D Pro sind bestimmte Hardware-Hosts und Grafikkarten erforderlich. Eine aktualisierte Liste der getesteten Hardware ist in einem Knowledge Base-Artikel verfügbar. Die Größe der Desktop- und Anwendungshosts von High-End-Grafikbenutzern sollte auf den GPU-Anforderungen basieren, um sicherzustellen, dass der Host dann über ausreichende CPU- und Speicherressourcen verfügt, um die Arbeitslast zu unterstützen.

NVIDIA GRID-Karten können mit vGPU-Profilen verwendet werden, um mehrere Benutzer zu unterstützen. Die Größenrichtlinien werden von NVIDIA in der folgenden Tabelle bereitgestellt.

In der Tabelle gibt Y an, dass Anwendungszertifikate verfügbar sind.

NVIDIA GRID Grafikkarte Virtuelles GPU-Profil Anwendungszertifizierungen Grafikspeicher Max. Anzeigen pro Benutzer Max. Auflösung pro Display Max vGPU pro Grafikkarte Anwendungsfall
GRID K2 K280Q Y 4.096 MB 4 2560 x 1600 2 Designer
  K260Q Y 2.048 MB 4 2560 X 1600 4 Designer/Poweruser
  K240Q Y 1.024 MB 2 2560 x 1600 8 Designer/Poweruser
  K220Q Y 512 MB 2 2560 x 1600 16 Wissensarbeiter
  K200   256 MB 2 1900 x 1200 16 Poweruser
GRID K1 K180Q Y 4.096 MB 4 2560 x 1600 4 Poweruser
  K160Q Y 2.048 MB 4 2560 x 1600 8 Poweruser
  K140Q Y 1.024 MB 2 2560 x 1600 16 Poweruser
  K120Q Y 512 MB 2 2560 x 1600 32 Poweruser
  K100   256 MB 2 1900 x 1200 32 Wissensarbeiter

Speichergröße

Entscheidung: Speicherarchitektur

Die primären Speicherarchitekturen lauten wie folgt:

  • Lokaler Speicher - Verwendet Festplatten, die direkt an das Computersystem angeschlossen sind. Die Datenträger können nicht für andere Computersysteme freigegeben werden. Wenn der Computer jedoch gepoolte oder gehostete freigegebene Desktops hostet, ist eine gemeinsam genutzte Speicherlösung nicht erforderlich. In vielen Fällen kann sowohl der lokale Speicher als auch der gemeinsame Speicher ausgeführt werden. Die Skalierbarkeit ist auf die Anzahl der Laufwerkschächte beschränkt, die im Computersystem verfügbar sind. Viele Blade-Server verfügen beispielsweise über nur zwei Laufwerkschächte. Daher ist die Verwendung von lokalem Speicher zur Unterstützung einer XenDesktop-Bereitstellung möglicherweise nicht optimal.
  • DAS - Speicher-Subsystem, das direkt mit einem Server oder einer Workstation über ein Kabel verbunden ist. Es verwendet Speicher auf Blockebene und kann eine Festplatte lokal im Computersystem oder ein Festplattenfach mit mehreren Festplatten sein, die mittels externer Verkabelung verbunden sind. Im Gegensatz zu lokalen Festplatten erfordern Festplattenböden eine separate Verwaltung. Speicherregale können mit mehreren Servern verbunden werden, sodass die Daten oder Festplatten gemeinsam genutzt werden können.
  • NAS - Bietet Speicher auf Dateiebene für Computersysteme über Netzwerkdateifreigaben. Das NAS arbeitet als Dateiserver, und NAS-Systeme sind vernetzte Appliances, die eine oder mehrere Festplatten enthalten, die häufig in logische, redundante Speichercontainer oder RAID-Arrays angeordnet sind. Der Zugriff erfolgt in der Regel über standardmäßige Ethernet- und Netzwerkdateifreigabeprotokolle wie NFS, SMB/CIFS oder AFP.

Hinweis:

NAS kann zu einem einzigen Fehlerpunkt werden. Wenn die Netzwerkfreigabe nicht verfügbar ist, sind auch alle Zielgeräte, die von der Festplatte gestreamt werden, nicht verfügbar.

  • SAN — Dediziertes Speichernetzwerk, das Zugriff auf konsolidierte Massenspeicher auf Blockebene ermöglicht. SANs ermöglichen es Computern, eine Verbindung zu verschiedenen Speichergeräten herzustellen, sodass kein Server Eigentümer des Speichersubsystems ist, sodass Daten auf mehreren Computern gemeinsam genutzt werden können. Ein SAN verfügt in der Regel über ein eigenes dediziertes Netzwerk von Speichergeräten, auf die im Allgemeinen nicht standardmäßig über das Netzwerk zugegriffen werden kann. Um ein Gerät an das SAN-Netzwerk anzuschließen, ist ein spezieller Adapter namens Host Bus Adapter (HBA) erforderlich. SANs sind hochgradig skalierbar, ohne dass sich die Leistung spürbar ändert, da mehr Speicher und Geräte angeschlossen sind. SANs können sowohl in Bezug auf Kapital als auch in Bezug auf die Zeit, die benötigt wird, um die Technologie zu lernen, bereitzustellen und zu verwalten.
  • Hybrid - Ein NAS-Kopf bezieht sich auf ein NAS, das über keinen integrierten Speicher verfügt, sondern stattdessen eine Verbindung zu einem SAN herstellt. Sie fungiert als Übersetzer zwischen den NAS-Protokollen auf Dateiebene (NFS, CIFS usw.) und den SAN-Protokollen auf Blockebene (Fibre Channel und iSCSI). So kann es die Vorteile beider Technologien kombinieren und ermöglicht Computern ohne Host-Bus-Adapter (HBA) die Verbindung zu zentralisiertem Speicher.

In der folgenden Tabelle werden die verfügbaren Speicheroptionen zusammengefasst und deren Eignung für XenDesktop-Bereitstellungen beschrieben.

Speichereigenschaften Lokal DAS NAS SAN
Implementierungskosten Niedrig Mittel Mittel Hoch
Verwaltung Niedrig Mittel Mittel Hoch
Leistung Hoch Mittel - Hoch Mittel - Hoch Hoch
Redundanz Niedrig - Med Mittel - Hoch Mittel - Hoch Hoch
Skalierbarkeit Niedrig Mittel - Hoch Mittel - Hoch Hoch
Typischer Anwendungsfall Kleine bis mittlere Produktions- und Testumgebungen Kleine bis mittlere Produktionsumgebungen Kleine bis mittlere Produktionsumgebungen Mittlere bis große Produktionsumgebungen

Hinweis:

Hyper-V 2008 R2 unterstützt keine NAS-Technologie. Hyper-V 2012/2012 R2 unterstützt nur NAS-Lösungen, die das SMB 3.0-Protokoll unterstützen. Weitere Informationen finden Sie in den Abschnitten HyperV 2008 R2 und Hyper-V 2012 R2 des Handbuchs.

Lokaler Speicher eignet sich am besten zum Speichern virtueller Maschinen, die keine hohen Verfügbarkeitsanforderungen oder persistenten Daten aufweisen, wie z. B. zufällige (gepoolte) Desktops oder gehostete freigegebene Desktops. Local und DAS eignen sich zum Speichern von Benutzerdaten und Home-Verzeichnisdateien. Bei Verwendung von Maschinenerstellungsdiensten müssen Masterimages sowie Updates auf jeden Server repliziert werden.

NAS- und SAN-Speicher eignen sich am besten für Infrastrukturserver, die die XenDesktop-Umgebung unterstützen, sowie für virtuelle Maschinen mit persistenten Daten wie statische (dedizierte) Desktops.

Entscheidung: RAID-Level

Um den optimalen RAID-Level zu wählen, ist es notwendig, das IOPS und das Lese-/Schreibverhältnis zu berücksichtigen, das von einer bestimmten Anwendung oder einer bestimmten Arbeitslast generiert wird, in Kombination mit den individuellen Fähigkeiten eines RAID-Levels zu berücksichtigen. Für das Hosten leseintensiver Arbeitslasten, z. B. des vDisk-Speichers Provisioning Services, sind RAID-Level, die für Lesevorgänge wie RAID 1, 5, 6, 10 optimiert sind, optimal. Dies liegt daran, dass diese RAID-Stufen Lesevorgänge gleichzeitig auf alle Festplatten innerhalb des RAID-Sets verteilt werden können.

Für das Hosten schreibintensiver Arbeitslasten wie Provisioning Services Write-Cache und Machine Creation Services unterschiedliche Datenträger sind RAID-Level wie RAID 1 oder 10 optimal, da diese für Schreibvorgänge optimiert sind und eine geringe Schreibbeanspruchung aufweisen.

In der folgenden Tabelle werden die wichtigsten quantitativen Attribute der am häufigsten verwendeten RAID-Level beschrieben:

RAID Kapazität (%) Fehlertoleranz Leseleistung Schreibleistung Minimale Anzahl von Festplatten
0 100 Keine Sehr hoch Hoch (Schreibstrafe 1) 2
1 50 Ausfall eines Laufwerks Sehr hoch Mittel (Schreibstrafe 2) 2
5 67 - 94 Ausfall eines Laufwerks Hoch Niedrig (Schreibstrafe 4) 3
6 50 - 88 Ausfall mit zwei Laufwerken Hoch Niedrig (Schreibstrafe 6) 4
10 50 Ausfall eines Laufwerks in jedem Subarray Sehr hoch Mittel (Schreibstrafe 2) 4

Hinweis:

Die Schreibstrafe ist inhärent bei RAID-Datenschutztechniken, die mehrere Festplatten-E/A-Anforderungen für jede Anwendungsschreibanforderung erfordern, und reicht von minimal (gespiegelten Arrays) bis zu erheblich (RAID-Level 5 und 6).

Entscheidung: Anzahl der Festplatten

Um die Anzahl der benötigten Festplatten zu bestimmen, ist es wichtig, die Leistungsmerkmale der einzelnen Festplatten, die Eigenschaften des RAID-Levels und die Leistungsanforderungen der gegebenen Arbeitslast zu verstehen. Die grundlegende Berechnung für die Bestimmung der Gesamtzahl der benötigten Festplatten ist:

Gesamtzahl der Festplatten = Lese-IOPS gesamt + (Schreib-IOPS gesamt x RAID-Strafe)) / Datenträgergeschwindigkeit-IOPS

Ein Datenträgerhersteller meldet beispielsweise, dass ein bestimmter Datenträgerarray eine Gesamtarbeitslast-IOPS von 2000 hat. Die unformatierten IOPS pro Festplatte sind 175. So ermitteln Sie, wie viele Festplatten erforderlich sind, um eine Arbeitslast mit 20% Lesevorgängen und 80% Schreibvorgängen auf RAID 10 zu unterstützen:

Anzahl der Festplatten = ((20% x 2000) + (80% x 2000) x 2) / 175 = 20,57 oder 21 Festplatten

Basierend auf dem vorherigen Beispiel zeigt die folgende Tabelle, wie die Anzahl der Festplatten abhängig vom RAID-Level und dem Lese-/Schreibverhältnis variieren wird.

RAID RAW-IOPS (pro Festplatte) Arbeitslast-IOPS Lesen % Schreiben % Datenträgeranzahl
0 175 2000 20 80 12
  175 2000 80 20 12
1 / 10 175 2000 20 80 21
  175 2000 80 20 14
5 175 2000 20 80 39
  175 2000 80 20 19

Entscheidung: Datenträgertyp

Festplattenlaufwerke (HDDs) sind die traditionelle Variante von Festplattenlaufwerken. Diese Arten von Scheiben bestehen aus rotierenden Platten auf einer motorbetriebenen Spindel innerhalb eines Schutzgehäuses. Die Daten werden mit Lese-/Schreibköpfen magnetisch auf die Platte geschrieben und von der Platte gelesen.

Verschiedene Implementierungen dieser Technologie sind auf dem Markt verfügbar, die sich in Bezug auf Leistung, Kosten und Zuverlässigkeit unterscheiden.

  • Serial ATA (SATA) Datenträger übertragen Daten seriell über zwei Leiterpaare. Ein Paar ist für die differenzielle Übertragung von Daten und das andere Paar ist für den differentiellen Empfang von Daten. SATA-Laufwerke sind weit verbreitet in Consumer-Desktop- und Laptop-Computern. Typische SATA-Laufwerke verfügen über Übertragungsgeschwindigkeiten von 1500 bis 6000 Mbit/s und unterstützen Hot-Swapping nach Design.
  • SCSI (Small Computer Systems Interface) Festplatten verwenden eine gepufferte Peer-to-Peer-Schnittstelle, die Handshake-Signale zwischen Geräten verwendet. Viele SCSI-Geräte benötigen einen SCSI-Initiator, um SCSI-Transaktionen zwischen dem Host und SCSI-Ziel zu initiieren. SCSI-Festplatten sind in Workstations und Servern üblich und haben Durchsätze zwischen 40 und 5120 Mbit/s. iSCSI (Internet Small Computer System Interface) ist eine Zuordnung des regulären SCSI-Protokolls über TCP/IP, häufiger über Gigabit Ethernet.
  • Die Fibre-Channel-Festplatte (FC) ist der Nachfolger der parallelen SCSI-Festplatte und ist in SAN-Speichergeräten üblich. Fibre Channel-Signale können über eine elektrische Schnittstelle oder Glasfaserkabel ausgeführt werden. Der Durchsatz kann zwischen 1 und 20 Gbit/s liegen und Verbindungen sind Hot-Plug-fähig.
  • Serial Attached SCSI (SAS) -Festplatte verwendet ein serielles Kommunikationsprotokoll der neuen Generation, um Datenübertragungen mit höherer Geschwindigkeit als SATA-Festplatten zu ermöglichen. Der Durchsatz kann zwischen 2400 und 9600 Mbit/s liegen.

Im Gegensatz zu herkömmlichen Festplatten verwenden Solid State Disks (SSDs) Mikrochips, um Daten in NAND-nicht-flüchtigen Speicherchips (Flash) oder DRAM zu speichern und enthalten keine beweglichen Teile. SSDs sind weniger anfällig für physische Schocks, haben niedrigere Zugriffszeiten und Latenz und haben höhere E/A-Raten. SSDs haben eine deutlich höhere zufällige Leseleistung. Ein SSD-Laufwerk kann überall zwischen 5.000 und 20.000 zufällige Lesevorgänge pro Sekunde erreichen. SSDs sind auch teurer pro Gigabyte (GB) und unterstützen in der Regel eine begrenzte Anzahl von Schreibvorgängen über die Lebensdauer der Festplatte.

Flash-speicherbasierte SSDs können entweder auf Multi-Level-Zellen (MLC) oder Single-Level-Zellen (SLC) basieren. SLC-Geräte speichern nur ein Informationsbit in jeder Zelle. MLC-Geräte können mehrere Bits an Informationen mit jeder Zelle speichern. Flash-basierte SSDs kosten niedriger als DRAM-basierte SSDs, führen aber langsamer aus. DRAM-basierte SSD-Geräte werden in erster Linie verwendet, um Anwendungen zu beschleunigen, die sonst durch die Latenz von Flash-SSDs oder herkömmlichen Festplatten zurückgehalten würden.

Aufgrund der hohen Kosten, der geringen Kapazität und des schnellen Verschleißes der Laufwerke waren SSDs bisher nicht für Enterprise-Speicherlösungen geeignet. Verbesserungen in der SSD-Technologie und Senkung der Kosten machen sie gegenüber HDDs günstiger. Solid-State-Hybridlaufwerke (SSHD) kombinieren die Funktionen von SSDs und Festplatten, indem sie ein großes HDD-Laufwerk mit einem SSD-Cache enthalten, um die Leistung häufig zugegriffen Daten zu verbessern.

Der Vergleich von SSDs und Festplatten ist schwierig, da Festplattenbenchmarks darauf ausgerichtet sind, Leistungsaspekte wie Rotationslatenzzeit und Suchzeit zu finden. Da SSDs sich nicht drehen oder suchen, können sie in solchen Tests große Überlegenheit zeigen. SSDs haben jedoch Probleme mit gemischten Lese- und Schreibvorgängen, und ihre Leistung kann sich im Laufe der Zeit verschlechtern.

Die folgende Tabelle vergleicht die Übertragungsraten einiger der gängigsten Speichertypen, die heute auf dem Markt verfügbar sind.

Technologie Rate (MBit/s)
iSCI über Fast Ethernet 100
Ultra-2 Wide SCSI (16 Bit/40 MHz) 640
iSCI über Gigabit Ethernet 1,000
SATA Rev. 3 6,000
SAS 3 9,600
FCoE über 10 GbE 10,000
SATA Rev 3.2 - SATA Express 16,000
iSCI über Infiniband 32,000

SCSI- und SATA-Festplatten eignen sich am besten zum Speichern von Daten, die keine hohen Leistungsanforderungen wie den PVS vDisk-Speicher aufweisen. SAS-, Fibre-Channel- oder SSD-Laufwerke eignen sich am besten zum Speichern von Daten mit hohen Leistungsanforderungen wie dem PVS-Schreibcache.

Entscheidung: Speicherbandbreite

Speicherbandbreite ist die Konnektivität zwischen Servern und dem Speichersubsystem. Das Verständnis der Bandbreitenanforderungen kann dazu beitragen, die richtige Hardware für die Bereitstellung von Daten und Anwendungen mit Geschwindigkeiten für eine positive Endbenutzererfahrung zu ermitteln. Für die meisten Rechenzentren ist 10Gbps Ethernet oder 10Gbps FCoE ausreichend für Speicherverbindungen. Kleinere Umgebungen benötigen jedoch möglicherweise nur eine Bandbreite von 1 Gbit/s. In virtualisierten Umgebungen ist es nicht nur wichtig, die Bandbreitenanforderungen des physischen Host- und Speichersubsystems zu betrachten, sondern auch zu bestimmen, wie viel Bandbreite für jede virtuelle Maschine benötigt wird.

Um die erforderliche Bandbreite zu planen, müssen die Durchsätze für jedes einzelne System ermittelt werden, das eine freigegebene Komponente oder einen Netzwerkpfad verwendet. Beispielsweise werden die folgenden Informationen für eine Umgebung mit 100 ähnlichen virtuellen Maschinen bereitgestellt (gehostet auf 10 Virtualisierungshosts und mit einem NAS-Kopf verbunden).

  Durchschnitt Gipfel
Durchsatz pro VM 10 Mbit/s 30 Mbit/s
Durchsatz pro Host 100 Mbit/s (10 VMs x 10 Mbit/s) 300 Mbit/s (10 VMs x 30 Mbit/s)
Durchsatz pro Speicher 1 Gbit/s (10 Hosts x 100 Mbit/s) 3 Gbit/s (10 Hosts x 300 Mbit/s)

Die für die Speicherkommunikation verwendete NIC muss ein 1-Gbit/s -Adapter sein, um die Spitzenlast zu bewältigen. Der NAS-Kopf und seine Netzwerkverbindung müssen Datenverkehr im Wert von 3 Gbit/s unterstützen, um die Spitzenlast aller Systeme zu unterstützen.

Entscheidung: Tiered Storage

Eine Einheitsgröße für alle Speicherlösungen ist unwahrscheinlich, dass sie die Anforderungen der meisten virtuellen Desktop-Implementierungen erfüllt. Die Verwendung von Speicher-Tiers bietet einen effektiven Mechanismus, um eine Reihe verschiedener Speicheroptionen anzubieten, die sich durch Leistung, Skalierbarkeit, Redundanz und Kosten unterscheiden. Auf diese Weise können verschiedene virtuelle Arbeitslasten mit ähnlichen Speicheranforderungen zusammengefasst und ein ähnliches Kostenmodell angewendet werden.

Beispielsweise kann eine XenDesktop-Implementierung mit Tiered Storage wie folgt aussehen:

  • Tier-1-Speichergruppe — Schreibintensive Dateien wie der Schreibcache und differenzierende Datenträger werden in einer Speichergruppe platziert, die aus SSDs besteht.
  • Tier-2-Speichergruppe — geschäftskritische Daten oder Daten, die eine hohe Verfügbarkeit erfordern, werden in einer Speichergruppe platziert, die aus kostengünstigeren Hochleistungslaufwerken besteht.
  • Tier-3-Speichergruppe — Selten verwendete Datendateien, schreibgeschützte Dateien oder andere nicht geschäftskritische Daten, die in einer Speichergruppe gespeichert werden, die aus kostengünstigen Laufwerken mit geringerer Leistung besteht.

Entscheidung: Thin Provisioning

Thin Provisioning ermöglicht es, den virtuellen Maschinen mehr Speicherplatz bereitzustellen, als im Speicher-Repository tatsächlich verfügbar ist. Dadurch werden die Speicherkosten gesenkt, da virtuellen Maschinen Zugriff auf häufig ungenutzte Festplattenspeicher gewährt wird. Dies ist besonders vorteilhaft für Machine Creation Services, die einen Linked-Clone-Ansatz für die Bereitstellung virtueller Maschinen verwenden. Die Thin Provisioning minimiert den Speicherplatz, der für die Masterimagekopien benötigt wird, die zum Erstellen virtueller Maschinen verwendet werden. Thin Provisioning ist auf der physischen Speicherschicht möglich, eine Funktion, die normalerweise bei den meisten SAN-Lösungen verfügbar ist, und auf der virtuellen Ebene. NFS-basierte Speicherlösungen haben normalerweise Thin Provisioning standardmäßig aktiviert.

Auf der physischen Speicherschicht muss sichergestellt werden, dass genügend Speicher verfügbar ist, um zu verhindern, dass virtuelle Maschinen in einem Speicherszenario “Overcommit” nicht verfügbar sind, wenn der verfügbare Speicherplatz ausgeschöpft ist. Unternehmen sollten entscheiden, ob die Kosteneinsparungen durch Thin Provisioning das damit verbundene Risiko überwiegen, und prüfen, ob die Speicherlösung dies unterstützt.

Hinweis:

Virtuelle Maschinen funktionieren möglicherweise nicht, wenn Speicherplatz erschöpft ist. Daher ist es wichtig, dass ein Prozess durchgeführt wird, entweder durch Warnungen oder Benachrichtigungen, die Administratoren genügend Zeit geben, um der Speicherlösung weitere Datenträger hinzuzufügen, damit die XenDesktop-Umgebung nicht beeinträchtigt wird.

Entscheidung: Datendeduplizierung

Die Datendeduplizierung ist eine Datenkomprimierungstechnik, bei der doppelte Daten durch Zeiger auf eine einzelne Kopie des ursprünglichen Elements ersetzt werden. Dies reduziert den Speicherbedarf und die Kosten, indem die Speicherauslastung verbessert wird, kann sich jedoch auf die Speicherleistung auswirken.

Es stehen zwei Implementierungen der Deduplizierung zur Verfügung:

  • Deduplizierung nach dem Prozess — Die Deduplizierung wird ausgeführt, nachdem die Daten auf den Datenträger geschrieben wurden. Die Post-Process-Deduplizierung sollte außerhalb der Geschäftszeiten geplant werden, um sicherzustellen, dass die Systemleistung nicht beeinträchtigt wird. Die Postprozess-Deduplizierung bietet minimale Vorteile für zufällige Desktops, da der Schreib-Cache-/Differenzdatenträger normalerweise täglich zurückgesetzt wird.
  • Inline-Deduplizierung — Überprüft Daten, bevor sie auf den Datenträger geschrieben werden, sodass keine doppelten Blöcke gespeichert werden. Die zusätzlichen Prüfungen, die vor dem Schreiben der Daten auf die Festplatte durchgeführt werden, können manchmal zu einer langsamen Leistung führen. Wenn diese Option aktiviert ist, sollte die Inline-Duplizierung sorgfältig überwacht werden, um sicherzustellen, dass die Leistung der XenDesktop-Umgebung nicht beeinträchtigt wird.

Wenn die Speicherlösung dies unterstützt, wird die Aktivierung der Datendeduplizierung nach dem Prozess empfohlen, um die XenDesktop-Leistung zu minimieren.

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.

Hardware-Schicht der Entwurfsmethodik