:::: MENU ::::

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 míří do Prahy

Od konání HYPERCONu v Novém Jičíně uběhl již skoro měsíc a za necelý měsíc se s vámi potkáme v Praze! Do Prahy přivážím o dva speakery více (Ondřej Bačina – DELL, Markus Klein – Orange Networks) a celé dva dny se budou konat v největším sále Microsoftu v přízemí. Organizační přípravy jsou v plném proudu, obsahy přednášek podstupují finální ladění a laby zatěžují náš hardware na 110%.

Aktuálně nejdůležitější informace pro vás je spuštění registrace. Pořadatelem pražského konání je pod mým vedením společnost KPCS a právě zde najdete proklikem registrační formulář. Veškeré info a zmíněnou registraci najdete na webu www.hypercon.cz.

Velice se na vás těším a věřím, že budete opět více než spokojeni s konferencí a náležitě si ji užijete!


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

 


Hledám posilu do System Center teamu

Je to už nějaká chvilka, co jsem se přesunul do spol. KPCS a mám na starost implementace System Center a souvisejících technologií. Jelikož máme práce víc než dost, tak hledám posilu do svého System Center teamu! Pokud máte zkušenost s nasazením a správou především SCCM, SCOM, SCSM a SCDPM, tak jste možná ten/ta, koho/kterou hledáme. Více informací najdete na webu KPCS zde.


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.)


Kolik dat upraví sysprep?

Dělal jsem teď měření, kolik dat se změní v OS, když projde sysprepem. Budu průbežně info aktualizovat, jak se dostanu k dalšímu OS.

  • Windows Server 2016 TP4 („Core“ edition) = 1 118 208 kB

Není to úplně málo, co říkáte? Je asi jasné, že to dost záleží například i na hardware, který musí OS detekovat. Naměřené hodnoty jsou z VM na Hyper-V.


Jak vzdáleně povolit PowerShell Remoting

Anglicky by ten titulek zněl ještě líp – How to remotely enable PowerShell Remoting 🙂

Samozřejmě to nejlépe uděláte přes GPO například. Pokud to ale potřebujete ihned, tak můžete použít PSEXEC (ať žije Mark! :))

A pak už to valí a můžete třeba přes Enter-PSSession jít na CLIENTPC1 a powershellit.


OneDrive připojený jako síťový disk

Od Windows 10 máme „skvělý“ nový engine OneDrivu, který neumí on-demand stáhnout soubor z cloudu a musíte si tedy navolit, které složky chcete synchronizovat. Problém je v tom, že složky/soubory, které nesynchronizujete, neuvidíte na disku vůbec. Škoda, tuhle funkci jsem měl v předchozí verzi rád.

Já si teda ještě mapuji svůj OneDrive jako network drive. Jak na to?

  1. Přihlašte se přes onedrive.com na svůj onedrive.
  2. Klikněte vlevo v navigaci na Soubory (Files)
  3. Nyní by URL měla vypadat nějak takto: https://onedrive.live.com/?id=root&cid=00AAB3D7DDF12AF7
  4. Vykopírujte si z URL to poslední ID. V mém příkladu tedy 00AAB3D7DDF12AF7
  5. Teď klasicky ve File Exploreru namapujte nový disk svými OneDrive credentials pomocí cesty: https://d.docs.live.net/00AAB3D7DDF12AF

A je to. Enjoy!


Povolení Isolated User Modu ve WS 2016 TP4

Isolated User Mode je funkce, která zajišťuje, aby určitá security related data (např. NT Hash, kterou drží v paměti proces LSASS.EXE) byla managována izolovanými procesy pomocí Virtual Secure Modu. VSM je paměťově kompletně oddělený prostor OS a funguje pomocí HW virtualizace stejně jako Hyper-V.

IUM povolíte třeba PowerShellem takto:


Stránky:1234567...22