teched 2009: Hyper-V Deployment Considerations

Arno Mihm – Senior Program Manager Windows Server, Hyper-V

Vijay Tewari, Pricipal Program Manager, WIndows Server, Hyper-V

meine erste interactive Session . mal sehen wie es wird

(die allgemeine Übersicht, was Hyper-V ist, spare ich mir)

Storage Options:

der VMBus ist nicht zwischen virt. Maschinen geshared, sondern pro Vm gibt es einen dedizierten Bus

sehr geringer Overhead, weil alles im Kernel Mode bleibt

Hyper-V Storage Options

Parent/Physical –

DAS (SCSI, SATA, eSATA, USB, Firewire)

SAN (iSCSI, Fibre Channel, SAS), Shared, blockbased required for cluster and live Migration

NAS ist nicht supportet, wenn darauf virtuelle Maschinen laufen

Guest View:

DAS: virtual SCSI, virtual IDE

iSCSI direct via software initiator (required for guest cluster) – vorsicht: Hyper-V VMs booten immer von der virtuellen IDE Platte, d.h. diese Lösung geht für Cluster oder Dtaendisks, nciht für OS Disks

passthrough Disks / iScsi direct

LUN dedicated to a VM, LUN > 2040 GB, No VSS Snapshot support (weil ja die VM die Storage bedient)

Virtual Hard Disk – max. 2040 GB pro VHD, Storage Management from Host, 3 Typen: Fixed VHD (Performancevorteil gegenüber dynamic disks in R2 nicht mehr so bedeutend), Dynamically expanding VHD (Vorsicht: hier muss ich aufpassen, dass ich immer genug Platz auf der physischen Disk habe), Differencing Disk (Master Image read Only, alle schreibvorgänge gehen über die Client Disk – eher für Testing, eher nciht für Production Environment)

Hyper-V Storage Empfehlungen

• Spindels, Spindels, Spindels (nur weils virtualisiert ist, hast du nicht weniger I/Os)
• use MPIO für Redundanz und Performance (wos is des ?)
• Production Environment – verwende fixed disk/pass through,dynamic expanding (wenn genug Platz),
• distribute I/O über multiple disks, dedicated SAN network (wenn SAn verwendet wird)

Cluster Shared Volumes

designed for Hyper-V

ich definiere Cluster und Cluster-Disks – die kann ich zu einem Cluster Shared Volume definieren – damit sehen alle Clusternodes das Storage gleichzeitig, alle Nodes können auf dieses Storage zur gleichen Zeit zugreifen

im CSV läuft NTFS

einer der Nodes im Cluster hat das Recht, die Metadaten zu ändern – d.h. alle Metadatensyncronisation erfolgt über das Netzwerk – da es um grosse files geht, ist das kein Problem, weil die Datentransfer ja direkt geht – was ist, wenn der Metadatanode stirbt ? Wenn dieser Node stirbt, übernimmt automatisch ein anderer Node diese Rolle – in dieser Zeit werden die IOs gequed, dann geht es weiter. Metadata operation sind im Bezug auf Virtualisation sehr gering – die meiste Zeit gehen die IOs direkt auf die Platte (soweit ich das verstanden habe, ist Metadata z.b. wenn ein Host ein VHD öffnen will – das ist Metadata)

Network Architektur

Der Switch am Host ist ein Layer 2 Switch – ein learning Layer 2 Switch

jeder Switch ist einer physischen Netzwerkkarte zugeordnet

auch hier ist der Overhead sehr gering

Network-Queuing passiert direkt auf der physischen Netzwekrkarte, wir mappen die physische Queue mit der virtuellen Netzwerkkarte – wenn die Netzwerkkarte das unterstützt, passiert das automatisch (derzeit nur Intel Networkcard (einige Nics) die VMQ unterstützen) –Benefit sehe ich erst bei 10 Gb Networkcards

VM Chimney – gleiche Idee hinter VMQ – reduzieren der CPU Belastung – TCP Offload ist am besten für Long life connection  - z.b. LifeMigration oder Fileserver die profitieren davon (im Gegensatz z.b. zu einem Webserver, der viele kurze Verbindungen hat) – schau dir vorher die workload an, bevor du es aktivierst

Jumbo Frames: Fileserver, iSCSI direct.  da bekome ich grosen Benefit . Vorsicht: Jumbo Frames nciht nur auf der virtuellen Maschine aufdrehen, sondern in meiner ganzen Infrastruktur (sonst bringts nix ;)  )

Netzwerkplanung

seperate private network for at least 1 GB for Live Migration

seperate private Network for Cluster and CSV

seperate public network for management OS

seperate private network for Storage (iSCSI)

seperate public networks for VMs

use syntetic devices

wenn ich das richtig verstanden habe, ist die Empfehlung bei einem Cluster mit iSCSI Anbindung mind. 5 Netzwrkkarten pro Node (idealerweise)

Was, wenn ich nur 2 NICs habe ? (da sollten beide 10 Gb haben): 1 für Live Migration & CSV Cluster, 1 für Management und VM Traffic

alles was keinen direkten Traffic von den virtuellen Maschinen treibt, erzeuge keinen virtuellen Switch (lifemigration, Cluster, network Management, Storage)

Hyper-V Server 2008 R2

Vorteil: die ParentPartition ist wesentlich kleiner, weil ja nur die Virtualisierung drinnen ist

sind aber sonst die gleichen Bits, die gleichen Funktionen wie beim “grossen” Windows Server

Administration passiert ausschliesslich remote (ausser Startkonfiguration)

Best practice:

• Wichtig: Du musst verstehen, welcher Workload deine VMs erzeugen werden ! (Virtualisierung erzeugt nicht wundersamerweise mehr ressourcen !)
• jede Virtualisierung erzeugt Overhead – hängt von der Applikation ab – beobachten und mit einberechnen
• Group DIFFERENT workloads on one physical system (nicht alle Exchange-Storeserver auf einen Node)
• Verstehe die Support Requirements deiner Applikationen (nicht jeder Hersteller unterstützt Virtualisierung)
• verstehe den Einfluss von Anti-Virus Software (in der Parent Partition) https://support.microsoft.com/kb/961804 (exkludiere VHD, virt. Services, …)
• Benutze deinen Hausverstand !

 

Sizing and Tuning

viel Doku im Netz

WIndows Server 2008 Performance Tuning Guide (https://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx )

ad Storage: Schau beim Storagehersteller, was der empfiehlt, ev. hat er spezielle Integration für Hyper-V

Download and use das MAP Tool (Microsoft Assesment and Planning Toolkit) – das gibt dir gute Empfehlungen über Virtualisierung

Tipps

verwende den gleichen virtual network switch namen auf allen Nodes ! (sonst findet die VM das Netzwekrk nicht !)

Cluster MEtric: Cluster creates metric value automatically, CSV verwendet die lowest metric, Live Migration verwendet die 2nd lowest

verwende unbedingt Server CORE für den Host, verwende Remote Management, starte keine Apps am Server Core (Websurfing oder so)

vergiß nicht, die Integration Services zu installieren !

Live Migration

verwende Hardware mit Windows Server Logo+Failover Cluster Configuration Program (FCCP)

Storage: Cluster Shared Volumes, Storage with Windows Logo+FCCP, Multi-Path IO is your friend

Networking: Standardize the name of your virtual switches, Multiple Interfaces, CSV verwendet seperate network

Verwende ISOs, nicht physische CD/DVD (du kannst keine VM migrieren, die ein physisches DVD system zugeordnet hat)

Fragen:

physisches Nic Teaming am Host: nicht wirklich empfohlen, es gibt ein Whitepaper, was geht, Support gibt der Vendor der Lösung

habe ich einen Vorteil, wenn ich in meinem Netzwerk für LiveMigration Jumbo Frames aktiviere: JA, definitiv ! bessere Performance

Paging File am Host: nicht abschalten, aber die Größe = gesamtes Memory – memory, das den VMs zugeordnet ist (weil das wird nie gepaged)

local attached Storage Empfehlungen: Raid 10, aber kommt drauf an…

Super Vortrag, hat mir einige Dinge beantwortet…

Christian – live von der teched in Berlin