Design und Implementierung eines virtuellen SANs
Werbung
WHITEPAPER Design und Implementierung eines virtuellen SANs In diesem Dokument wird beschrieben, wie mithilfe der DataCore™ SANsymphony™-V Software, unter Verwendung des lokalen Speichers und des Flash-Speichers der Anwendungsserver, ein leistungsstarker und hochverfügbarer gemeinsamer Speicherpool erstellt werden kann. Diese Konfiguration wird als virtuelles SAN bezeichnet. Virtuelle SANs erfüllen die Anforderungen an schnellen, zuverlässigen Zugriff auf Speicherressourcen über einen Serververbund, ohne dass dazu eine eigenständige externe SAN-Infrastruktur erforderlich ist. Inhalt DataCore Virtual SAN ...............01 Glossar .....................................02 Komponenten und Leistungsmerkmale von Virtual SAN ................03 Architektur – Übersicht ............05 Überlegungen Speicherumgbung ...................06 Überlegungen zum Netzwerk .................................08 Prozessorkonfiguration der Knoten im virtuellenSAN .........09 Speicherkonfiguration der Knoten im virtuellen SAN .....................10 Hypervisor-Konfiguration der Knoten im virtuellen SAN . .......11 Fazit .........................................11 Zusätzliche Ressourcen ............12 Global Leader in Software Defined Storage Virtuelle SANs von DataCore können alle Kombinationen aus Flash-Speicher, SSD (Solid State Disks) und Festplattenspeicher nutzen, um Anwendungen so nah wie möglich dauerhaft Speicherdienste zu bieten, ohne das Netzwerk verwenden zu müssen. Virtuelle Datenträger, die vom virtuellen SAN bereitgestellt werden, können auch von einem Serververbund gemeinsam verwendet werden, um dynamische Migrationen und Failover von Anwendungen zwischen Knoten (Servern) zu unterstützen. Die folgende technische Übersicht behandelt die grundlegenden Betriebs- und Implementierungsrichtlinien von SANsymphony-V, zum Implementieren eines virtuellen SANs aus nicht initialisierten Speichergeräten. Hinweis: Wenn der Speicher aktive Daten enthält, die zum virtuellen SAN migriert werden sollen, müssen weitere Schritte ausgeführt und Vorkehrungen getroffen werden, die nicht Gegenstand dieses Leitfadens sind. Es wird vorausgesetzt, dass der Leser mit den Schritten zum Installieren von SANsymphony-V vertraut ist. Installationsanweisungen finden Sie auf der Supportwebsite von DataCore. Auf den SANsymphony-V-Hilfeseiten finden Sie zusätzliche Informationen. Wenn Sie zu bestimmten Aspekten weitere Einzelheiten suchen, lesen Sie in diesem Leitfaden den Abschnitt „Referenzen“. WHITEPAPER Ideale Anwendungsfälle für DataCore‘s Virtual SAN Ziehen Sie DataCore’s Virtual SAN-Lösung in folgenden Fällen in Betracht: Latenzsensible Anwendungen Beschleunigen Sie die Antwortzeiten und den Durchsatz, indem Sie Flash-Speicher als persistenten Speicher nahe der Anwendungen nutzen und Lese- und Schreibzugriffe in noch schnellerem Server-DRAM-Arbeitsspeicher cachen. Kleine Serververbände an Remotestandorten, in Zweigstellen und kleinen Rechnerräumen Nutzen Sie die internen Speicherkapazitäten Ihrer Server als gemeinsame Ressource. Schützen Sie Ihre Daten bei Serverausfällen, indem Sie einfach SANsymphony-V-Software hinzufügen. Implementierung von VDI (virtual Desktop) Führen Sie auf den Servern mehr virtuelle Desktops aus und skalieren Sie sie über mehrere Server, ohne die Komplexität und die Ausgaben eines aufwendigen externen SANs in Kauf nehmen zu müssen. Glossar Datastore VMware-ESXi-Container zum Speichern von Datenträger- und Konfigurationsdateien für virtuelle Maschinen von VMware. Disk Pool DataCore-Container zum Bündeln verschiedener physikalischer Festplatten in eine gemeinsame Verwaltungsstruktur. LUN Logical Unit Number (logische Gerätenummer). Bezieht sich allgemein auf das Volume eines physischen Datenträgers. Root-Partition Partition, auf der sich die lokale Installation von Microsoft Windows befindet. SANsymphony-V kann auf dieser Partition mit oder ohne Hypervisor (z. B. Hyper-V) vorhanden sein. RDM VMware’s Raw Disk/Device Mapping Server Group Logische DataCore-Gruppe, die alle zu verwalteten Knoten im virtuellen SAN enthält Smart Deployment Wizard (SDW) Der Smart Deployment Wizard ist ein DataCore Tool, das beim ersten implementieren eines virtuellen SANs behilflich ist. Das Tool ist aber nicht zwingend erforderlich, um ein virtuelles SAN bereitzustellen. Virtual Disk DataCore-Festplattenobjekt, das den Knoten im virtuellen SAN bereitgestellt wird. VHD Datei für virtuelle Datenträger von Microsoft Hyper-V. VMDK Datei für virtuelle Datenträger von VMware. Virtual SAN Node Physikalischer Server, auf dem DataCore SANsymphony-V installiert ist. Seite 02 Global Leader in Software Defined Storage Komponenten und Leistungsmerkmale von Virtual SAN WHITEPAPER Übersicht Komponenten Virtual SAN und Knoten des virtuellen SAN’s Ein virtuelles SAN von DataCore besteht aus mindestens zwei physikalischen x86-64-Servern mit lokalem Speicher und darauf gehosteten Anwendungen. Bis zu 32 Server können innerhalb einer zentral verwalteten Gruppe konfiguriert werden. Auf jedem Server, der Teil des virtuellen SANs ist, muss eine ordnungsgemäß lizenzierte Instanz von SANsymphony-V ausgeführt werden. Diese physischen Server werden auch als Knoten im virtuellen SAN bzw. einfach als Knoten bezeichnet. Grundsätzlich trägt jeder Knoten Speicher zum gemeinsamen Pool der Gruppe bei. Sie können außerdem SANsymphony-V-Knoten konfigurieren, die keinen Speicher zum Pool beitragen, sondern Anwendungen hosten, von denen auf die Speicherpools zugegriffen wird. Speichergeräte im virtuellen SAN Mit Ausnahme des Startlaufwerks können nicht initialisierte Blockspeichergeräte, die an einen Knoten angeschlossen sind, in das virtuelle SAN eingeschlossen werden. Es kann jede Kombination aus Flash-Speicher, SSD und Festplattenspeicher verwendet werden. USB-Wechseldatenträger werden nicht unterstützt, da ihre Präsenz nicht gewährleistet werden kann. Optionen zur Implementierung von SANsymphony-V Je nach Betriebssystem oder Server Hypervisor zum Steuern des physischen Geräts, gibt es drei Möglichkeiten, die Software SANsymphony-V auf den Anwendungsservern zu konfigurieren. 1. Physischer Windows Server (kein Server Hypervisor installiert) SANsymphony-V wird direkt auf dem Windows Server-Betriebssystem ausgeführt. Alle nicht initialisierten lokalen Blockspeichergeräte werden automatisch als geeignet für den Pool erkannt. Anwendungen wie Microsoft Exchange oder SQL können gemeinsam mit SANsymphony-V installiert werden. Es können Windows-Failovercluster oder andere Clustertechnologien verwendet werden, um Anwendungsfailover zwischen Servern zu erstellen. 2. Windows Server mit Hyper-V SANsymphony-V wird in der Root-Partition (auch als übergeordnete Partition bezeichnet) auf dem Windows ServerBetriebssystem ausgeführt. Alle nicht initialisierten lokalen Blockspeichergeräte werden automatisch als geeignet für den Pool erkannt. Die Microsoft Hyper-V-Hypervisor-Rolle wird gemeinsam mit SANsymphony-V installiert. 3. VMware ESXi und weitere nicht auf Windows basierende Hypervisoren SANsymphony-V wird auf einer dezidierten virtuellen Maschine für Windows Server ausgeführt. Der Administrator weist nicht initialisierte Speichergeräte vom Server Hypervisor der virtuellen Maschine für SANsymphony-V als RDM-Datenträger (RDMs in ESXi) zu. Die Implementierung von RDM-Datenträgern ist vorzuziehen, jedoch je nach den Fähigkeiten des Hypervisors und/oder lokalen RAID-Controllers, nicht immer möglich. HINWEIS: Alle lokalen Datenträger-RDM-Mappingdateien, die SANsymphony-V bereitgestellt werden, müssen sich im lokalen Datenspeicher des Knotens befinden (nicht in einem virtuellen Volume, das von SANsymphony-V bereitgestellt wird). Im Abschnitt „Referenzen“ dieses Leitfadens finden Sie spezifische Dokumente zu dieser Funktion. Seite 03 Global Leader in Software Defined Storage WHITEPAPER Übersicht Leistungsmerkmale Enterprise-Funktionen des SANs SANsymphony-V bietet die folgenden Enterprise-Speicherfunktionen: • Automated Storage Tiering • Advanced Site Recovery* • Analyse und Berichterstattung • Asynchrone Replikation* • Channel Load Balancing • Continuous Data Protection (CDP)* • Fibre Channel-Unterstützung* • High Speed Caching • iSCSI-Unterstützung • NAS/SAN (Unified Storage) •Snapshot • Storage Migration und Pass-through Disks •Speicher-Pooling • Synchrones Spiegeln • Thin Provisioning * Optionale Funktion Lizenzierung von Virtual SAN Es ist eine SANsymphony-V-Lizenz je Knoten erforderlich. Lizenzen richten sich nach der Größe des physikalischen Speichers, die der Knoten zum gemeinsamen Pool beiträgt. Einige Funktionen werden separat lizenziert. Wenden Sie sich an einen autorisierten DataCore-Experten, um sich genauer über Lizenzen und Preise informieren zu lassen. Disk Pool In SANsymphony-V werden Speichergeräte in Disk Pools organisiert. Sie können innerhalb eines Knotens im virtuellen SAN mehrere Disk Pools erstellen, um zu bestimmen, wie jeder Ressourcenpool zu verwenden ist. So könnten Sie einen Disk Pool für die Produktion und einen für Testzwecke erstellen, um zu unterscheiden, welche Speichergeräte der Produktion zugeordnet werden und welche sich am besten zu Testzwecken eignen. Auto-Tiering innerhalb von Disk Pools Die Mitglieder eines Disk Pools können sich hinsichtlich ihrer Leistungscharakteristiken unterscheiden. SANsymphony-V beherrscht Sub-LUN-Auto-Tiering, um für eine gegebene Arbeitslast dynamisch das am besten geeignete Gerät zu finden. Als Basis dazu dient die Häufigkeit, mit der auf Speicherblöcke zugegriffen wird. So wird sichergestellt, dass Daten, auf die häufiger zugegriffen wird, sich auf schnelleren Datenträgern innerhalb des Pools befinden, während Daten, auf die seltener zugegriffen wird, sich auf langsameren Datenträgern befinden. Virtual Disks Virtuelle Datenträger, die mit Thin Provisioning aus dem Disk Pool erstellt wurden, können gemeinsam mit anderen Knoten im virtuellen SAN verwendet werden. Sie erscheinen den Betriebssystemen oder Hypervisoren, denen sie explizit bereitgestellt werden, als logische Laufwerke. Seite 04 Global Leader in Software Defined Storage WHITEPAPER High Speed Cache Jeder Knoten im virtuellen SAN benötigt eine gewisse Menge RAM, der als schneller Cache dient. Die Menge des zugeordneten RAMs kann nach Bedarf angepasst werden. Generell werden mindestens 4 GB bzw. 10 % des insgesamt verfügbaren RAMs des Hosts (je nachdem, was mehr ist) als Cache empfohlen. Der Cache dient als Hochgeschwindigkeits-Puffer zur Beschleunigung von Schreibzugriffen und als großer Zwischenspeicher für Lesezugriffe. So lässt sich eine Steigerung der nativen Leistung von Festplattenspeichern um mindestens das Drei- bis Fünffache erzielen. Die Verwendung von RAM als Lese-/Schreibcache bedeutet einen erheblichen Leistungsvorteil gegenüber anderen virtuellem SAN Produkten, bei denen langsamerer Flash-Speicher nur als Lesecache verwendet wird. Hohe Verfügbarkeit mit synchronem Spiegeln SANsymphony-V bietet auch dann kontinuierlichen Zugriff auf die gemeinsamen Speicherpools, wenn ein Knoten im virtuellen SAN ausfällt. Kritische Daten werden zwischen Knotenpaaren im virtuellen SAN synchron gespiegelt, um hohe Verfügbarkeit zu erreichen. RAID-Schutz innerhalb jedes Knotens bietet zusätzlichen Schutz vor Fehlern auf Komponentenebene. Architektur – Übersicht In diesem Dokument werden die am häufigsten verwendeten Implementierungen von virtuellen SANs behandelt, die für SANsymphony-V empfohlen werden. Außerdem werden einige der wichtigsten Überlegungen für jede Komponente von virtuellen SANs behandelt, um die Vielseitigkeit der SANsymphony-V-Plattform darzustellen. So funktioniert Virtual SAN Im folgenden Diagramm finden Sie ein beispielhaftes virtuelles SAN. SANsymphony-V (rot) wird in den jeweiligen Knoten auf einer dezidierten virtuellen Maschine (VM) ausgeführt. Daneben sind weitere VMs vorhanden, auf denen Anwendungen gehostet werden. Im Diagramm sind die beiden linken Knoten für die Freigabe eines hochverfügbaren virtuellen Datenträgers für die anderen Knoten verantwortlich, aus denen die Servergruppe besteht. Jeder Knoten bündelt seinen lokalen Flash-Speicher und seine magnetischen Speichergeräte in einem Pool. Aus diesen Pools werden virtuelle Datenträger erstellt, die zwischen den beiden Knoten synchron gespiegelt werden. Sie werden im Netzwerk/Fabric als Multipfad-Datenträger bereitgestellt. Die virtuellen Datenträger können nach Bedarf dimensioniert werden. Eine „Überzeichnung“ des Speichers ist zulässig, da der tatsächliche Kapazitätsverbrauch der virtuellen Datenträger durch Thin Provisioning minimiert wird. Seite 05 Global Leader in Software Defined Storage WHITEPAPER Die beiden linken Knoten sowie die anderen Knoten im virtuellen SAN können über das Netzwerk/Fabric auf den virtuellen Datenträger zugreifen. Der Hypervisor jedes Knotens erkennt den virtuellen Datenträger als verfügbare Datenträgerressource. Auf die gleiche Art können auch andere Knoten zur Gesamtkapazität des gemeinsamen Speicherpools beitragen. Jeder Knoten trägt Speicher, Rechenleistung, Netzwerk- und I/O-Kapazitäten zur Gruppe bei. Überlegungen zur Speicherumgebung Konfiguration der lokalen Speichergeräte SANsymphony-V nutzt Blockspeicher, der mit den Knoten des virtuellen SANs verbunden ist. Anhand folgender Erwägungen lassen sich Leistung und Ausfallsicherheit der Gruppe steigern. Lokale Fehlertoleranz durch RAID Das Bereitstellen einzelner Non-RAID-Datenträger für SANsymphony-V wird vollständig unterstützt. Es wird dennoch empfohlen, innerhalb jedes Knotens im virtuellen SAN für einen gewissen Sicherheitslevel durch RAID zu sorgen, um die Beeinträchtigungen durch unvorhergesehene Laufwerksfehler zu minimieren. Dies lässt sich auf zwei Arten erzielen: 1. 2. Hardware-RAID-Controller innerhalb jedes Knotens im virtuellen SAN Spiegeln des Disk Pools durch SANsymphony-V Beim linken Knoten im Diagramm oben sind vier Datenträger (grün) vom lokalen Hardware-RAID-Controller als RAID-5-Gruppe konfiguriert. Sie werden SANsymphony-V als einzelnes Laufwerk mit hoher Kapazität angezeigt. Beim mittleren Knoten werden SANsymphony-V vier Datenträger (gelb und blau) einzeln angezeigt. Für diese vier Datenträger wurde ein Mirroring des Datenträgerpools aktiviert. Seite 06 Global Leader in Software Defined Storage WHITEPAPER Der Screenshot oben zeigt einen Datenträgerpool, der in SANsymphony-V auf einem der Knoten im virtuellen SAN (SSV-VSA01) unter Verwendung von vier Flash-Datenträgern und einem SAS-Datenträger erstellt wurde. Die Flash-Datenträger wurden gespiegelt und als Datenträger der Klasse 1 (schnellste Stufe) klassifiziert. Der SAS Datenträger wurde als Datenträger der Klasse 2 klassifiziert. Es werden bis zu 15 Speicherklassen unterstützt. Weitere wichtige Informationen und Erwägungen zur Leistung von Datenträgerpools finden Sie auf der DataCore-Supportsite im Best Practice-Handbuch. Hohe Verfügbarkeit durch synchrones Mirroring Zusätzlich zur Ausfallsicherheit auf Komponentenebene durch das lokale RAID, werden von SANsymphony-V die Virtual Disk synchron über die Knoten gespiegelt. Eine Virtual Disk kann zwischen zwei Knoten gespiegelt werden. So entsteht Redundanz auf Datenebene und im gesamten virtuellen SAN lässt sich eine hochverfügbare Lösung erzielen. Wenn ein Knoten ausfällt oder gewartet werden muss, werden Anforderungen automatisch von dem Knoten in der Gruppe bearbeitet, der eine identische Kopie der kritischen Daten enthält. Innerhalb einer Servergruppe können einige oder alle Knoten im virtuellen SAN paarweise am synchronen Spiegeln beteiligt werden. So kann ein virtueller Datenträger, der sich auf Knoten 1 befindet, auf Knoten 2 gespiegelt werden. Gleichzeitig kann ein anderer virtueller Datenträger, der sich auf Knoten 1 befindet, auf Knoten 3 gespiegelt werden. Auf Knoten 1 können sich auch virtuelle Datenträger befinden, die nicht gespiegelt werden. Sobald für einen virtuellen Datenträger ein Spiegel eingerichtet wurde, lässt sich ganz einfach und unterbrechungsfrei ändern, von welchen Knoten der Spiegel bereitgestellt wird. Seite 07 Global Leader in Software Defined Storage Überlegungen zum Netzwerk WHITEPAPER Konfiguration der lokalen Netzwerkgeräte Bei Umgebungen mit virtuellem SAN, in denen für Speicherdienste iSCSI genutzt wird, wird empfohlen, dass von Frontend- und Spiegelpfaden separate und dezidierte physikalische Netzwerkpfade verwendet werden, um eine Aus- bzw. Überlastung von Kanälen zu vermeiden. Unterstützte Netzwerk- und Fabric-Typen Vom virtuellen SAN werden Ethernet-Netzwerke mit 1 GB, 10 GB, 40 GB und 56 GB für iSCSI-Datenverkehr sowie 4 GB, 8 GB und 16 GB bei Fibre Channel-Fabrics unterstützt. Zusätzliche Details zur Unterstützung von verschiedenen Hardware-, Netzwerk- und Fabric-Komponenten finden Sie in den FAQ’s (häufig gestellten Fragen) zu qualifizierten Hardwarekomponenten auf der DataCore-Supportsite. Netzwerkredundanz Das Niveau der Netzwerkredundanz (mehrere NICs/HBAs und Switches) ist ein wichtiger Gesichtspunkt. Es ist vom IT-Budget und dem Typ der Anwendungen abhängig, die in der Umgebung ausgeführt werden. Es wird angemessene Redundanz empfohlen, um Unterbrechungen aufgrund von Hardwarefehlern zu vermeiden. Beispielsweise würde in einem einzigen Initiator-/Zielnetzwerk ein LAN-Fehler alle Knoten im virtuellen SAN an Zugriffen auf Daten im gemeinsamen Speicherpool hindern. Der Einsatz mehrerer Netzwerk-Uplinks, die mit mehreren Switches verbunden sind, erhöht die Ausfallsicherheit der Gruppe. Netzwerkisolierung Das Isolieren von Frontend-Pfaden (Initiator/Ziel), Spiegelpfaden und Verwaltungspfaden auf Pro-Host-Basis wird dringend empfohlen. Idealerweise tritt jeder Datenverkehrstyp nur auf seinem dezidierten virtuellen Switch mit dezidiertem NetzwerkUplink auf. So ist gewährleistet, dass die Datenverkehrstypen sich nicht gegenseitig beeinträchtigen. Überlegungen zur Feinabstimmung des iSCSI-Netzwerks Es gibt mehrere Parameter zur Feinabstimmung des Netzwerks, mit denen sich die Speicherleistung insgesamt steigern lässt. Seite 08 Global Leader in Software Defined Storage WHITEPAPER Die folgenden Microsoft Windows-Einstellungen haben unter kontrollierten Testbedingungen eine bessere Gesamtleistung ergeben. Daraus folgt jedoch nicht zwangsläufig, dass dies auch auf Ihre spezifische Umgebung zutrifft. Lesen Sie die Konfigurationshandbücher zu Ihrem Hypervisor, Ihrem Betriebssystem und Ihrer Hardware, um sich näher über diese Einstellungen zu informieren. Die folgenden Parameter zur Feinabstimmung des Netzwerks beziehen sich auf jede Instanz von SANsymphony-V in der Gruppe. Führen Sie mit Administratorberechtigungen auf der Instanz von Windows Server, auf der SANsymphony-V gehostet wird, in der Befehlszeile die folgenden Befehle aus (einige können je nach Version des Windows-Betriebssystems abweichen): o netsh int tcp set global rss=enabled o netsh int tcp set global chimney=disabled o netsh int tcp set global autotuninglevel=normal o netsh int tcp set global congestionprovider=ctcp o netsh int tcp set global ecncapability=disabled o netsh int tcp set global timestamps=disabled Vergewissern Sie sich, dass „Receive Side Scaling“ in den Eigenschaften der einzelnen Netzwerkkarten, die auf dem Server installiert sind, ausdrücklich aktiviert ist. Passen Sie die Registrierungseinstellung „MaxInitiators“ so an, dass sie der Anzahl von Initiatoren in der Servergruppe entspricht. Wenn sich beispielsweise 16 physische Hosts in der Gruppe des virtuellen SANs befinden, legen Sie „MaxInitiators“ auf 16 fest. In den meisten Fällen muss der folgende Schlüssel erstellt werden: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DcsIs\Parameters DWORD-32-Bit-Eintrag: MaxInitiators = xx (xx entspricht der Anzahl der Hosts) Es ist ein Neustart jeder SANsymphony-V-Instanz erforderlich, an der diese Änderungen vorgenommen wurden, damit sie wirksam werden. Prozessorkonfiguration der Knoten im virtuellen SAN CPU-Konfiguration mit Root-Partition-Instanzen In Root-Partition-Instanzen ist die maximale Anzahl an CPUs, die für SANsymphony-V verfügbar sind, von der Anzahl der verfügbaren CPU-Sockets und der verfügbaren Cores je Socket abhängig. Ein Server mit zwei physischen CPU-Sockets, die je acht Cores aufweisen, hätte beispielsweise 16 Cores. SANsymphony-V würde bis zu zehn Cores für „Worker Threads“ nutzen. CPU-Konfiguration mit Instanzen von virtuellen Maschinen Bei Instanzen in virtuellen Maschinen ist die maximale Anzahl an CPUs, die für das System verfügbar sind, von der Anzahl an CPUs abhängig, die zur Verwendung mit der jeweiligen Instanz einer virtuellen Maschine konfiguriert sind. Eine virtuelle Maschine mit zwei virtuellen Sockets und vier Cores würde beispielsweise insgesamt acht Cores aufweisen. SANsymphony-V würde bis zu sieben Cores für „Worker Threads“ nutzen. Seite 09 Global Leader in Software Defined Storage WHITEPAPER CPU-Konfiguration mit Instanzen in virtuellen Maschinen Bei Instanzen in virtuellen Maschinen ist die maximale Anzahl an CPUs, die für das System verfügbar sind, von der Anzahl an CPUs abhängig, die zur Verwendung mit der jeweiligen Instanz einer virtuellen Maschine konfiguriert sind. Eine virtuelle Maschine mit zwei virtuellen Sockets und vier Cores würde beispielsweise insgesamt acht Cores aufweisen. SANsymphony-V würde bis zu sieben Cores für „Worker Threads“ nutzen. Da die virtuelle Maschine der Ressourcenplanung durch den Hypervisor unterworfen ist, wird empfohlen, die CPU-Reservierung für die virtuelle Maschine zu maximieren, um die vollständige Nutzung der SANsymphony-V zugewiesenen CPUs zu gewährleisten. Überlegungen zur CPU-Feinabstimmung Für den Hostserver, auf dem SANsymphony-V ausgeführt wird, werden folgende Einstellungen empfohlen: • Hyper-Threading ggf. aktiviert (wird im BIOS konfiguriert) • Hohe Leistung in den BIOS-Einstellungen gewählt • Hohe Leistung in den Energieeinstellungen von Windows Server gewählt Speicherkonfiguration der Knoten im virtuellen SAN Speicherkonfiguration mit Root-Partition-Instanzen In Root-Partition-Instanzen beansprucht SANsymphony-V standardmäßig 50-65 % der insgesamt verfügbaren physikalischen Speicherressourcen. Da SANsymphony-V in der Root-Partition ausgeführt wird, ist der gesamte verfügbare physikalischer RAM des Systems für SANsymphony-V sichtbar. Es wird empfohlen, diesen Wert auf 10 % (oder 4 GB, je nachdem was größer ist) zu senken und so RAM für die virtuellen Maschinen freizumachen, die vom Stamm-Hypervisor gesteuert werden. Speicherkonfiguration mit Instanzen in virtuellen Maschinen Bei Instanzen in virtuellen Maschinen beansprucht SANsymphony-V standardmäßig 50-65 % der gesamten zugewiesenen Speicherressourcen der virtuellen Maschinen. Da SANsymphony-V auf einer virtuellen Maschine ausgeführt wird, ist nur die Menge an RAM, die der virtuellen Maschine vom Administrator zugewiesen wurde, für SANsymphony-V sichtbar. In diesem Fall wird empfohlen, die SANsymphony-V-Cachezuweisung auf 80 % zu erhöhen und sicherzustellen, dass die RAM-Menge, die der virtuellen Maschine zugewiesen ist, etwa 10 % der physikalischen RAM-Kapazität des Hosts (oder 4 GB, je nachdem was größer ist) entspricht. Seite 10 Global Leader in Software Defined Storage WHITEPAPER Hypervisor-Konfiguration der Knoten im virtuellen SAN Hypervisor-Konfiguration mit Root-Partition-Instanzen Da SANsymphony-V in der Root-Partition als Peer des Hypervisors ausgeführt wird, müssen auf Hypervisor-Ebene keine Änderungen für SANsymphony-V vorgenommen werden. Hypervisor-Konfiguration mit Instanzen in virtuellen Maschinen Da SANsymphony-V in einer virtuellen Maschine unter Kontrolle eines Hypervisors ausgeführt wird, werden einige Änderungen auf Hypervisor-Ebene empfohlen, um das ordnungsgemäße Funktionieren von SANsymphony-V zu gewährleisten: • Vergewissern Sie sich, dass die SANsymphony-V-Instanz nicht für eine Live-Migration oder andere Funktionen bei laufendem Betrieb innerhalb des Hypervisor-Clusters vorgesehen ist. • Vergewissern Sie sich, dass der Host, auf dem SANsymphony-V ausgeführt wird, nicht Teil von Energieverwaltungsfunktionen innerhalb des Hypervisor-Clusters ist. • Vergewissern Sie sich, dass die SANsymphony-V-Instanz nicht Teil von Hochverfügbarkeitsfunktionen innerhalb des Hypervisor-Clusters ist. Konfiguration von VMware ESXi 5.x mit Instanzen von virtuellen Maschinen Wenn SANsymphony-V auf einer virtuellen Maschine ausgeführt wird, die von VMware ESXi 5.x gesteuert wird, lassen sich mit den folgenden Änderungen deutliche Leistungsverbesserungen erzielen: • Deaktivieren von Interruptzusammenführung • ethernet#.coalescingScheme = „disabled“ (vSphere 5.1) o (# ist die Adapternummer) • Reduzieren von Wartezeiten bei Aktivieren aus dem Leerlauf o monitor.idleLoopSpinBeforeHalt = „true“ (vSphere 5.1) o VM-Einstellungen → Optionen-Registerkarte → Latenzempfindlichkeit → Hoch(vSphere 5.5) Fazit Mit der Software SANsymphony-V von DataCore zum Erstellen eines virtuelles SANs, lässt sich ein hochflexibles Modell für die unternehmensweite Implementierung von Speicherdiensten, erstellen. Dieses Implementierungsmodell bietet eine hoch konsolidierte Server- und Speicherumgebung, mit erhöhter Anwendungsleistung, hoher Verfügbarkeit und geringeren Gesamtbetriebskosten. Seite 11 Global Leader in Software Defined Storage WHITEPAPER Zusätzliche Ressourcen Es sind viele hervorragende Ressourcen als Unterstützung zur Implementierung von DataCore SANsymphony-V, in virtuellen SAN Umgebungen sowie mit physikalischen SAN’s, verfügbar. Sie finden diese Informationen auf der DataCore-Supportwebsite: Support-Startseite Best-Practices-Handbuch Onlinehilfe FAQ’s (Häufig gestellte Fragen) Für die meisten Supportressourcen ist ein Supportkonto erforderlich. Rufen Sie dazu den Support-Registrierungslink auf: Supportregistrierung Referenzen Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs (Best Practices für die Leistungsfeinabstimmung bei latenzempfindlichen Arbeitslasten in vSphere-VMs) http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5 (Bereitstellen extrem latenzempfindlicher Anwendungen in VMware vSphere 5.5) http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf VMware Raw Device Mapping for local storage (VMware-Raw-Festplattenzuordnung für lokalen Speicher) http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&ext ernalId=1017530 Modifying the MaxInitiators Registry Value (Ändern des Registrierungswerts „MaxInitiators“) http://datacore.custhelp.com/app/answers/detail/a_id/1235/kw/maxinitiators DataCore Qualified Hardware Components (DataCore-Liste qualifizierter Hardwarekomponenten) http://datacore.custhelp.com/app/answers/detail/a_id/283 Netsh commands for Interface Transmission Control Protocol (Netsh-Befehle für Interface Transmission Control Protocol) http://technet.microsoft.com/de-de/library/cc731258%28v=ws.10%29.aspx 0714 Weitere Informationen finden Sie unter www.datacore.com oder senden Sie uns eine E-Mail an: [email protected] ©2014 DataCore Software Corporation. Alle Rechte vorbehalten. DataCore, das DataCore-Logo und SANsymphony sind Warenzeichen oder eingetragene Warenzeichen der DataCore Software Corporation. Alle anderen hier erwähnten Produkte, Dienstleistungen und Firmennamen sind unter Umständen Warenzeichen der jeweiligen Eigentümer. Global Leader in Software Defined Storage
