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

HYPERCON 3.0: Datumy fixnuty

Další HYPERCON bude, o tom snad nebylo pochyb 🙂 V tuto chvíli už jsou dány i datumy a místa konání.

V Novém Jičině se opět potkáme ještě tento rok (21.-22.11.) a v Praze až v roce 2018 (24.1.-25.1.).

Program připravujeme. Těšit se už teď ale můžete na super přednášky a nově i workshopy! Nebudou chybět zas zajímavé ceny. Nezapomeňte si tedy již vyblokovat kalendář.

Registrace je v tuto chvíli otevřena pro lokalitu Nový Jičín.

Sledujte www.hypercon.cz


Ohlédnutí za HYPERCON 2.0 a co dál…

Tento týden v úterý skončila pražským konáním konference HYPERCON 2.0. Dovolte mi tedy krátké ohlédnutí za oběma místy konání a také reakci na některé z vašich komentářů.

Když jsem poprvé organizoval HYPERCON, tedy edici 2016, tak jsem byl velice mile překvapen počtem účastníků. Druhá edice, 2.0, ale bohužel nebyla počty lepší a v Praze dokonce horší než minulý ročník. Bohužel to bylo způsobeno poměrně pozdní organizací, což bylo zapříčiněno mým naprostým nedostatkem času.

Každopádně věřím, že se nám podařilo doručit obsah, který jsme slibovali a který byl pro vás zajímavý. V Novém Jičíně se vám mohli poprvé na HYPERCONu představit kolegové Dan Hejda (www.defense-ops.com) a Ondřej Výšek (www.optimalizovane-it.cz) a v Praze k nim přibyli ještě další tři noví přednášející – Ondřej Bačina (Dell), Lukáš Radil (KPCS CZ) a host Markus Klein (Orange Networks).

Dostal jsem ovšem samozřejmě i negativní reakce, které věřte, že vnímám a pokusím se je maximálně odladit na příštím HYPERCONu 3.0. Zapracujeme na cateringu, řízení teploty v přednášecích sálech, relevantnosti obsahu a časovém rozložení.

Tento ročník jsem vás také obdarovali zajímavými cenami. V Novém Jičíně jsme rozdávali volný vstup na příští HYPERCON, slevu na kurzy v Amenit školícím centru a technologickými assessmenty. V Praze jsme se rozhodli jít více materiální cestou a tak jsme vás potěšili něčím dobrým k pití, kvadroptérou, multimediálním centrem na Raspberry Pi a dvěma robotickými zařízeními.

Fotografie, komentáře a reakce účastníků naleznete na twitteru @hyperconcz #hyperconcz20.  Prezentace a skripty z obou lokalit HYPERCONu 2.0 se co nejdříve objeví na webu www.hypercon.cz.

A co dál? Už teď začínám plánovat obsah dalšího HYPERCONu, vydání 3.0. Stále zůstaneme věrni Hyper-V, ale již se více podíváme i na jeho související technologie v cloudu. Protože dnes již není otázka zda „jít“ do cloudu, ale kdy. A navíc, jak říká kolega Ondra Výšek – Cloud nebolí. Nebojte se ale – moje úchylné přednášky jako např. Hyper-V Internals určitě v programu najdete.

Závěrem bych rád poděkoval partnerům KPCS, Amenitu, Gopasu a WUGu za jejich podporu, kolegům a kamarádům za jejich skvělé přednášky a především vám za účast!


Pokračování mé přednášky na téma Hyper-V Internals

V říjnu jsem měl na WUGu v Praze přednášku na Hyper-V Internals, ale nestihl jsem samozřejmě probrat vše, co jsem chtěl. Díky WUGu se tedy podařilo najít termín na pokračování, kde se dozvíte víc o Hyper-V Clusteru, Hyper-V Replica, Shielded VMs a když zbyde čas tak se určitě ještě mnoho témat najde. Více info a registrace zde.

Těším se na vás a doufám, že vás přijde opět hodně! Možná přinesu i nějaké dárky 😉


Jak jednoduše docílit BSOD ve VM

Používal jsem historicky různé způsoby jak „sestřelit“ OS, aby člověk mohl zkoušet debugging, simulovat Guest OS reboot apod. Od Windows Server 2012 R2/Windows 8.1 Hyper-V lze tohoto docílit přímo pomocí powershellu z hostitelského OS. Použije se cmdlet Debug-VM. Ten samozřejmě není jen k vyvolání BSOD, ale k celkovému debuggingu.

Pro BSOD použijete následující příkaz, který spustíte v parent partition:


Vzhled blogu a ESXo v Hyper-V

Po delší době jsem se rozhodl konečně dokončit úpravu vzhledu blogu, aby se lépe četl a přinášel vám především zajímavé informace (a ne na vás pálil jedno logo za druhým 🙂 ). Snad se vám nový look & feel líbí a bude pro vás příjemnější pro čtení.

Aby ale tenhle post nebyl úplně zbytečný, tak se mi dnes podařilo rozjet VMware vSphere ESXi server ve virtuálce provozované na Windows Server 2016 Hyper-V. Hned jak dotestuji, že se tam dá spustit i nested virtuálka, tak sem hodím návod, jak na to. Zatím jen screenshot ať se můžete pokochat a těšit (ano, nemám IP adresu, ale to je jen tím, že nemám v labové síti žádné DHCP).

esx65-nested-in-hv2016.png


HYPERCON 2.0 se blíží

Již za dva dny začíná konáním v Novém Jičíně pokračování mé konference HYPERCON zaměřené na Hyper-V a související technologie. Na konci ledna hned navážeme pražským termínem. Můžete se opět těšit na maximum zajímavých informací a praktických ukázek. Pokud jste se ještě nezaregistrovali, tak neváhejte – počet volných míst velice rychle klesá. Registraci na pražšké konání otevřeme již brzy.

Přípravy jsou samozřejmě již v plném proudu, vlastně již téměr v cíli 🙂 Laby jsou připravené a prezentace vyladěné. Tento rok se na vás chystáme i s hardwarem, na kterém všechny ukázky budou probíhat. Tento ročník (do Prahy) máme také dva hosty a to ze společnosti DELL (CZ) a Orange Networks (DE).

Těším se na Vás!

Více informací na http://www.hypercon.cz

 


Sledování využití CPU uvnitř Hyper-V VM

Skoro na každém školení nebo přednášce se zmíním o tom, jak Task Manager lže nebo o tom, že nemáte sledovat využití prostředků performance countery uvnitř VM.

Proč lže task manager?

Témeř v každé verzi Windows Serveru nebo Windows klienta byl nějaký problém se zobrazováním dat v task manageru. Od 2008 do 2012 R2 vám bude uvnitř VM ukazovat vždy maximální hodnotu paměti jakou VM nafoukne během svého celého běhu. To samozřejmě mluvím o Dynamic Memory.

Hyper-V 2016 se dokonce chystá i možnost snížení statické paměti za běhu VM. V tom případě opět task manager uvnitř VM zas nesníží paměť, kterou zobrazuje v horní části. Podobných příkladů bych našel ještě více.

A proč nemáte monitorovat VM „zevnitř“, ale použít Hyper-V performance countery?

Nejdříve trochu k architektuře. Hypervisor nad sebou spravuje dva typy partitions – root partition a child partitions. Root je specifická v tom, že spravuje fyzické zařízení, řídí podřízené child partitions, zajišťuje endpoint pro správu atd., prostě se stará o vše kromě procesorového času a přidělování paměti. To má na starost samotný hypervisor, který běží níže na ringu -1.
Child Partition reprezentuje VM. Tedy prostředí, kde běží virtuální počítač.

Root ani child partitions nekontrolují APIC (programovatelný kontroler přerušení), Power Management Timer, správu adres, atd., což znamená, že nemají žádnou reálnou představu o čase, který je jim tedy dodáván virtuálně. Ano, i root partition (tedy hlavní řídící OS nedostává skutečný čas z HW). Tomu navíc nepřidává ani to, že virtuální procesory využívají fyzické procesory přepínaným přístupem.

Teď k samotným performance counterům. Co se týče procesoru, tak asi nejvíce známý je % Processor Time. Ten detailně ukazuje celkové množství CPU využité procesem. Nepočítá čas, kdy CPU nic nedělá (je idle).

Když teda např. mrkneme uvnitř totálně zatížené VM na tenhle counter, tak uvidíme využití CPU na 100%.

Pokud se ale v tu samou chvíli podíváme na „hezčí“ counter na úrovni root partition – Hyper-V Hypervisor Guest Run Time – tak tam uvidíme číslo menší (cca 80%)!!!

Jak to? Který tedy ukazuje správnou hodnotu? Z pohledu architektury oba. Z pohledu skutečného využití prostředků vůči fyzickému hardware má pravdu ten Hyper-V counter. Proč?

Counter uvnitř VM říká toto – systém konzumuje 100% procesorového času, který mu hypervisor dal, tedy pokaždé, když hypervisor přidělil čas, tak ho systém všechen využil. To je pravda přece, ne? VM opravdu žere 100% dodaného času do virtuálního procesoru.

Jelikož ale hypervisor má ještě v rezervě nějaký čas, který tráví přepínáním a který má k dispozici i pro jiné VM, tak ukazuje číslo nižší.

Podobně zvláštně se to bude chovat i s counterem % Processor Time na úrovni root partition. Opět nebude říkat úplně správná čísla, jelikož jeho pojem o čase je také zkreslený. Je proto tedy nutné sledovat Hyper-V Hypervisor Logical Processor. Logický procesor odpovídá jednomu vláknu (pokud máte fyzické CPU s podporou HT (hyperthreading)), které zatežuje jádro.

Závěrem dodám, že pokud bychom se bavili o sledování prostředků např. Microsoft SQL Server uvnitř VM, tak nemáte jinou možnost než použít SQL performance countery uvnitř VM. Komplexní obrázek využití prostředků základních komponent (paměť, procesor, disk a síť) dostanete vždy ale jen z root partition.

 


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


Stránky:123