:::: MENU ::::
Posts tagged with: Hyper-V

Sítě v Hyper-V Clusteru

Jinými slovy, sítě potřebné pro Windows Failover Cluster (WFC) sloužící k provozu vysoce dostupných VM.

V dnešním článku se zaměřím právě na sítě, které potřebujete k provozu stabilního Hyper-V clusteru. Sítě clusteru se v základu dělí na 3 typy:

  1. Síť využitá pouze pro cluster komunikaci.
  2. Síť využitá jak pro cluster komunikaci, tak připojení vnějších zařízení (klientů).
  3. Síť, na které je cluster komunikace zakázána.

Zvolení vhodného typu sítě lze provést přímo přes Failover Cluster Manager (dále jen FCM) nebo za použití PowerShellu (property Role na objektu Cluster Network, Get-ClusterNetwork).

Aby bylo jasné toto rozdělení, uveďme si pár příkladů.

  1. Cluster Heartbeat
  2. Cluster Management
  3. iSCSI konektivita

V rámci jednotlivých nodů clusteru je každý Hyper-V host připojen do těchto cluster sítí pomocí virtuálních adapterů WFC. Tyto koncové endpointy jsou interpretovány NetFT (Network Fault-Tolerant) adapterem (v Device Manageru ho najdete pod skrytým zařízením „Microsoft Failover Cluster Virtual Network Adapter“). Ten byl zaveden od Windows Server 2008 v rámci naprosto přepsaných funkcionalit WFC a jsou pomocí něj zajištěny klíčové funkce.

MAC toto adapteru je vytvořena z MAC fyzického adapteru. Ovladačem je Cluster Virtual Miniport Driver (netft.sys), který běží v kernel modu (ring 0) a běží vždy současně s cluster službou.

Když prozkoumáte IP konfigurace tohoto síťové rozhraní, tak najdete na IPv4 nastavenou APIPA a na IPv6 Link-Local adresu. Není potřeba tyto adresy jakkoli měnit (ani to není obecně dobrý nápad dělat), jelikož veškerá tato komunikace je tunelována přes odpovídající validní síťové rozhraní.

Co se týče „tvrdých“ požadavků na sítě v Hyper-V clusteru, tak existuje jen jediný: mít dostupné minimálně dvě sítě pro cluster komunikaci.

Díky tomu je NetFT spolu s dalším komponentami (Topology Manager, FTI, Interface Manager) schopen například postavit celou routovací strukturu, aby byla zajištěna maximální míra vysoké dostupnosti.

Není samozřejmě nejvhodnější konfigurace postavit cluster pouza na dvou sítích, protože je pak např. nedostatečně zajištěna potřebná šířka pásma pro jednotlivé typy komunikace a tím hrozí snížení vysoké dostupnosti.

Typy samotných komunikací v rámci clusteru lze rozdělit takto:

  1. Cluster komunikace
  2. Komunikace pro správu clusteru
  • Komunikace VM
  1. Live Migration
  2. Komunikace na úložiště
  3. Komunikace Hyper-V Replica

Nejdůležitějším požadavkem pro následné samotné rozdělení na logické sítě je existence odlišných dedikovaných sítí. Nelze v rámci WFC definovat sítě pro rozdílné typy komunikace na identických subnetech.

Pro oddělení cluster komunikace se používá již zmíněné nastavení na začátku článku. V rámci této sítě “tečou” i jedny z nejdůležitějších komunikací clusteru – cluster heartbeat (HB). Ty jsou malé, ale velice citlivé na latenci. Pokud neprojde HB z jednoho nodu na druhý, může být tato situace interpretována jako výpadek nodu. Je tedy také ještě velmi vhodné nastavit pomocí QoS prioritu (802.1p PCP hodnota) na komunikaci na portu, který HB používá (unicast UDP 3343) pomocí PowerShellu (New-NetQoSPolicy –IPDstPort 3343 –Piority 6)

Pro zvolení sítě pro správu je vhodné ještě toto nastavení kombinovat s určitou formou zabezpečení komunikace (které možná stejně je požadáno), čímž jste následně schopni tuto komunikaci rozpoznat.

Komunikace VM není v rámci clusteru nutné žádným způsoben definovat, jelikož se jedná o data tekoucí přes rozhraní, které nemá vůbec aktivní TCP/IP stack (externí Hyper-V switch) a proto není clusterem jakkoli využívané.

Live Migration (LM) je v rámci funkcionalit Hyper-V samotného možné nastavit na TCP (výchozí stav je s komprimací) nebo SMB (s využitím SMB Direct v případě použití síťových karet podporujících RDMA). Oddělení komunikace je nastaveno přímo v FCM, kde se checkboxy volí požadované sítě pro LM, nebo pomocí PowerShellu, kde se naopak nastavuje parametr sítí, které nemají být použity pro LM (Set-ClusterParameter –Name MigrationExcludeNetwork).

Komunikace s úložištěm může být částěčně dána přenosovým médiem a protokolem (např. v případě FC tedy není opět nutné nic oddělovat, jelikož se nejedná o síť s TCP/IP). Pokud se jedná o blokový přístup (např. iSCSI), tak je vhodné na těchto sítích zakázat cluster komunikaci (opět viz. začátek článku). Pokud se jedná o SMB úložiště, tak je tok dat řízen pomocí SMB Multichannel, kde pomocí PowerShellu opět vymezíme dedikované sítě (New-SMBMultichannelConstraint).

K omezení komunikace Hyper-V replikace lze použít jedině trvalé statické routy (route add –p).

Trochu ošemetnou otázkou ještě zůstává, co dělat s metadaty a případným redirected přístupem u Cluster Shared Volume (CSV). Důležitou částí odpovědi je fakt, že od Windows Server 2012 používá CSV vždy pro metadata SMB protokol, tedy konkrétně SMB Multichannel. Tím je zajištěn maximální možný výkon v případě redirected accesu (tedy funkci, která se používá, když některý z nodů clusteru ztratí přímý přístup k úložišti). Jelikož SMB Multichannel je použit i pro metadata, použije se síť, které má povolenou SMB MC komunikaci. Pokud není dostupná žádná síť s SMB MC, tak je zpětně komunikace přepnuta na NetFT. V tom případě se použije cluster síť s nejnižší metrikou. Metriky si ve výchozím stavu řídí cluster sám automaticky, ale je možné je nastavit na vlastní hodnotu (Get-Cluster Network). Vhodné je také nastavit opět QoS obecně pro SMB (New-NetQoSPolicy –SMB –MinimumBandwidthWeightAction).

Závěrem bych ještě rád upozornil na to, že vaše Hyper-V servery mohou (a v mnoha případech by měly) mít další typy komunikace, které bude nutné/vhodné izolovat v rámci clusteru (např. backup). Nezapomínejte také na závislosti jendotlivých používaných funkcí, které celkově značně ovlivňují síťovou architekturu WFC (např. NIC Teaming vs. SMB Multichannel, FCoE, HNV apod.)


Moje přednášky na konferenci MS INDEED We Can

logo_indeed

S kolegou Romanem vyrážíme za pár týdnů přednášet do Sofie na Microsoft konferenci INDEED We Can. Máme tam jednu společnou přednášku a pak každý pár svých samostatně. Rád bych vás tedy dnes seznámil s mými přednáškami a tím vás pozval na tuto velkou evropskou konferenci:

  • Microsoft Hyper-V Best Practices
  • Hybrid Infrastructure Automation Deep-Dive (Jan Marek, Roman Nedzelský)

Pro úplnost kolega Roman Nedzelský bude mít tyto přednášky:

  • Optimization methods in Project Management using integration, SharePoint Server and Project Server
  • Supporting Business Processes PowerBI & Workflows

Více info zde.


windows server 2016 tp3 je tady!

Další milestone konečně k dispozici. TP3ka přináší další plánovaná vylepšení. Jestli tedy čekáte stějně netrpělivě jako já na další verzi Windows Server – já tedy především Hyper-V Winking smile – tak stahujte TP3!

Já se nejvíc v TP3 těším na kontejnery a SET (už bylo dost toho teamování a následních ManagementOS adaptérů v Hyper-V switchi).

Více info zde a sosat můžete odtud.

Jo a současně vychází System Center 2016 TP3 Winking smile


DISM příkaz na povolení hyper-V

Pokud už musíte použít DISM tool na povolení Hyper-V role ve Windows Server, tak dejte pozor na to, že název funkce je case-sensitive! Dnes jsem zažil opět další z tisíce připomínek, že přes DISM to prostě nejde… Jde, ale musí se to pořádně napsat  Winking smile

Když si vylistujete všechny features pomocí:

tak uvidíte, že Hyper-V role je schovaná pod Microsoft-Hyper-V názvem.

K povolení tedy musíte dodržet velká a malá písmena, tedy:

Radši to ale přes DISM vůbec nedělejte a použite místo toho PowerShell…



jeden ze scénářů existence adresáře clusterstorage.000

Dnes jsem řešil takový zajímavý problém, který hezky demonstruje to, jak je důležité nehrát si s produkčním prostředím.

Prostředí je velice jednoduché: dva Hyper-V servery v clusteru s iSCSI storagem. Konfigurace OS, sítí, Hyper-V atd. naprosto v pořádku a cluster prošel při formování bez ztráty kytičky. Za to musím zákazníka pochválit a ocenit ho dle Červeného trpaslíka hodnocením pět a půl pračky whirlpool.

Bohužel problém nastal ve chvíli, kdy si jeden z kolegů chtěl pohrát s clusterem a připojit si k němu další iSCSI pole. Protože mu to ale pořádně nešlo, tak si začal lehce hrát s kdečím. Finálem byla nemožnost zapnutí několika produkčních VMs z konkrétního CSV disku. Po bližším prozkoumání jsem našel na jednom z nodů adresář ClusterStorage.000, který seděl hned vedle správného ClusterStorage, a obsahoval data nespustitelných VM. Tento adresář (.000) vzniká typicky v případech, kdy cluster node nedokáže úplně jasně určit cestu, kterou se má připojit k datům.

image

 

Jak postupovat? Nejjednodušší způsob (než se začnete vrtat v clusterlogu) je spustit starý dobrý Cluster Validation test na tomto “vadném” CSVčku. V mém případě bylo výstupem následující.

image

A když jsem se pak mrknul na seriáky a signatury, tak byla opravdu vidět duplicita,

image

což jasně s pomocí tohoto screenshotu ukazuje na špatně nastavené (čtěte nenastavené) MPIO.

Jasně, není to nic moc převratného, ale myslím si, že je zajímavé vidět, jak na takto simple věc reaguje WFC.




microsoft hyper-v best practices přednáška v praze

LogoUž příští týden se konečně se svou šňůrou na témat MS Hyper-V Best Practices dostanu do Prahy. Tato přednáška má za cíl ukázat nejvhodnější možnosti konfigurace virtualizační platformy Microsoft Hyper-V. Na několika praktických příkladech si vysvětlíme, jak nakonfigurovat Hyper-V v oblasti hostitelů, virtuálních strojů, sítí, úložiště, vysoké dostupnosti a disaster recovery tak, aby byla zajištěna stoprocentní podpora, bezpečnost a výkon. Celá přednáška čerpá ze mých zkušeností z velkého množství projektů implementace a podpory Microsoft Hyper-V.

Pokud jste se ještě nezaregistrovali, tak mrkněte na stránky WUGu.

Těším se na vás!


windows cannot find the microsoft software license terms

Tak na tuhle chybovku můžete narazit v mnoha případech, teď se jedná ale o situaci, kdy instalujete OS do virtuálky.

os-install-error-ram-less-than-768mb

První co by vás asi napadlo je, že máte poškozené médium nebo ISO soubor. Problém je ale jinde a to v množství operační paměti (v tomto případě tedy virtuální). Pro instalaci Windows Server 2012 R2 obecně platí, že je potřeba 512MB RAM. Moje VM ale měla 512MB RAM a stejně setup hlásil tuto chybovku. Ono to totiž není tak jednoduché. Když instalujete OS do VM, tak jsou nároky o něco vyšší. Když si přečtete oficiální dokumentaci zde, tak se všimněte důležitého textu v rámečku:

os-install-virtual-memory-issue

V 99% procentech případů jsem prostě zvýšil virtuální RAM na 768MB a instalace prošla bez problémů – viz tedy řešení zmíněné v prvním bullet pointu (ano píše se tam 800MB, ale z praxe mi stačilo 768MB :)).

Teď si možná říkáte – “Proč bych instaloval WS2012R2 jen s 512MB nebo s 768MB RAM? Vždyť pod 1,5GB RAM se to chová pekelně pomale.”. Ano při statické paměti tohle v mnoha případech dává smysl, ale berte v potaz Dynamic Memory na VM. Tam se typicky každý snaží do hodnoty Startup Memory nacpat čislo, které stačí pro boot OS (to se typicky odvíjí od paměti pro instalaci).

hyper-v-2012-r2-dynamic-memory

Tam tedy pozor na to, že ani tam nedávejte 512MB (narovinu – on ten WS2012R2 s 512MB nabootuje :)), ale aspoň 768MB. Tím pádem to tam v klidu nainstalujete a pak už si přes Integration Service – Dynamic Memory sáhne pro více paměti až bude VM potřebovat. Mimochodem, do Minimum RAM klidně můžete dát i méně než 512 MB 🙂

Aby to bylo kompletní, tak musím ještě dodat, že pokud vytváříte VM ze šablony (takže po startu tam projíždí jen sysprep), tak to v klidu najede i s 512MB samozřejmě.


Stránky:123