Konfigurace virtuální sítě Hyper-V a osvědčené postupy

Pokud jste ve světě virtualizace nováčkem, konfigurace sítě může být jedním z nejobtížnějších konceptů. Síťování je v Hyper-V také jiné než v jiných hypervizorech, takže i ti s letitými zkušenostmi mohou při prvním setkání s Hyper-V trochu klopýtnout. Tento článek začne tím, že se podíváme na koncepční návrh virtuálních sítí v Hyper-V, konfiguraci a poté projdeme osvědčenými postupy implementace.

Základy práce v síti

Než začnete, může být užitečné ujistit se, že máte solidní přehled o základech sítí Ethernet a TCP/IP obecně. Několik článků, které vysvětlují společné aspekty, začíná tímto vysvětlením modelu OSI.

Virtuální přepínač Hyper-V

Jedinou nejdůležitější součástí sítě v Hyper-V je virtuální přepínač. Na tomto blogu je podrobný článek o virtuálním přepínači Hyper-V, ale kvůli tomuto článku vám poskytnu základní úvod do tohoto konceptu v širším měřítku.

Klíčem k pochopení je uvědomit si, že se skutečně jedná o přepínač, stejně jako o fyzický přepínač. Funguje ve vrstvě 2 jako prostředník pro virtuální porty přepínače. Směruje pakety na MAC adresy. Zvládá VLAN tagování. Může dokonce provádět některé úlohy kvality služeb (QoS). Je také zodpovědný za izolaci síťového provozu na virtuální adaptér, který jej má přijímat. Při vizualizaci by měl být síťový přepínač Hyper-V chápán stejným způsobem jako standardní přepínač:

Další částí pochopení virtuálního přepínače je způsob jeho interakce s hostitelem. Chcete-li tuto diskusi otevřít, musíte se nejprve seznámit s dostupnými typy virtuálních přepínačů.

Režimy virtuálního přepínače

Pro přepínač Hyper-V existují tři možné režimy: soukromý, interní a veřejný. Nezaměňujte je se schématy adresování IP nebo s jakoukoli jinou konfigurací virtuální sítě v jiné technologii.

Soukromý přepínač Hyper-V

Privátní přepínač umožňuje komunikaci mezi virtuálními počítači na svém hostiteli a nic jiného. Ani řídící operační systém se nesmí zúčastnit. Tento přepínač je čistě logický a v žádném případě nepoužívá žádný fyzický adaptér. „Soukromé“ v tomto smyslu nesouvisí s privátním IP adresováním. V duchu si to můžete představit jako přepínač, který nemá schopnost uplinku k jiným přepínačům.

Interní přepínač Hyper-V

Interní přepínač je podobný soukromému přepínači s jednou výjimkou: operační systém pro správu může mít na tomto typu přepínače virtuální adaptér. To umožňuje operačnímu systému pro správu přímo komunikovat s libovolnými virtuálními stroji, které mají také virtuální adaptéry na stejném interním přepínači. Stejně jako soukromý přepínač nemá interní přepínač žádný vztah k fyzickému adaptéru, a proto také nemůže uplinkovat na žádný jiný přepínač.

Externí přepínač Hyper-V

Typ externího přepínače musí být připojen k fyzickému adaptéru. Umožňuje komunikaci mezi fyzickou sítí a operačním systémem pro správu a virtuálními adaptéry na virtuálních počítačích. Nezaměňujte tento typ přepínače s veřejnými schématy adresování IP ani nedovolte, aby jeho název naznačoval, že je třeba jej připojit k systému s připojením k internetu. Pro adaptéry na externím virtuálním přepínači, který používáte ve fyzické síti, ke které je připojen, můžete použít stejný rozsah privátních IP adres. Externí v tomto použití znamená, že se může připojit k systémům, které jsou externí vůči hostiteli Hyper-V.

Jak vytvořit koncept externího virtuálního přepínače

Část toho, co uměle ztěžuje pochopení externího virtuálního přepínače, je způsob, jakým jsou formulována související nastavení. V rozhraní Hyper-V Manager GUI je to formulováno jako Povolit operačnímu systému pro správu sdílet tento síťový adaptér. V rutině New-VMSwitch PowerShellu je parametr AllowManagementOS, který není o nic lepší, a jeho popis – Určuje, zda má mít nadřazený oddíl (tj. operační systém pro správu) přístup k fyzickému síťovému adaptéru vázanému na vytvářený virtuální přepínač. - zhoršuje to. Zdá se, že se až příliš často stává, že je lidé čtou a myslí si o virtuálním přepínači a virtuálních adaptérech takto:

Toto bohužel vůbec není přesná reprezentace virtuální sítě Hyper-V. Jakmile je virtuální přepínač navázán na fyzický adaptér, tento adaptér se již nepoužívá pro nic jiného. TCP/IP a většina dalších položek jsou z něj odstraněny. Operační systém pro správu to prostě není schopen „sdílet“. Pokud se pokusíte připojit k adaptéru cokoli jiného, ​​je docela pravděpodobné, že rozbijete virtuální přepínač.

Ve skutečnosti operační systém pro správu získává svůj vlastní virtuální síťový adaptér. To je to, co se připojí k virtuálnímu přepínači. Tento adaptér není přesně jako adaptéry připojené k virtuálním počítačům; není tak bohatý na funkce. Není to však vůbec nic jako skutečné sdílení fyzického adaptéru způsobem, který ovládací prvky naznačují. Lepší výraz by byl „Připojit operační systém pro správu k virtuálnímu přepínači“. To nastavení opravdu dělají. Následující obrázek je mnohem přesnější zobrazení toho, co se děje:

Jak vidíte, s virtuálním adaptérem operačního systému pro správu se zachází stejně jako s adaptéry virtuálních strojů. Samozřejmě máte vždy možnost vyjmout jeden nebo více fyzických adaptérů z virtuálního přepínače. Ty budou normálně používány operačním systémem pro správu. Pokud to uděláte, nemusíte nutně „sdílet“ adaptér virtuálního přepínače s operačním systémem pro správu:

Jak používat fyzickou síťovou kartu Teaming s virtuálním přepínačem Hyper-V

Od systému Windows Server 2012 je nyní týmová funkce síťového adaptéru nativní funkcí operačního systému Windows Server. Teaming umožňuje kombinovat dva nebo více adaptérů do jednoho logického komunikačního kanálu pro distribuci síťového provozu. Hyper-V Server může také týmovat fyzické adaptéry.

Když je vytvořen týmový adaptér, jednotlivé adaptéry se stále zobrazují ve Windows, ale způsobem velmi podobným virtuálnímu přepínači již nemohou být vázány na nic jiného než na týmový protokol. Po vytvoření týmu je operačnímu systému předložen nový adaptér. Bylo by správné nazývat tento adaptér „virtuálním“, protože fyzicky neexistuje, ale to může způsobit záměnu s virtuálními adaptéry používanými s virtuálním přepínačem Hyper-V. Častějšími termíny jsou týmový adaptér nebo logický adaptér a někdy se používá zkratka tNIC.

Vzhledem k tomu, že týmová práce není ústřední funkcí ani požadavkem Hyper-V, nebude zde podrobně probírána. Hyper-V využívá nativní týmový adaptér s velkým efektem, a proto by se měl používat, kdykoli je to možné. Jako obecné pravidlo byste měli zvolit dynamický algoritmus vyvažování zátěže, pokud nemáte jasně definovanou prvořadou potřebu; kombinuje nejlepší vlastnosti algoritmů Hyper-V Port a Transport Ports. Pokud jde o to, zda použít režim týmové práce nezávislé na přepínači nebo jeden z režimů závislých na přepínači, to je hlubší diskuse, která zahrnuje vyvážení vašich cílů se schopnostmi hardwaru, který máte k dispozici. Mnohem hlubší zpracování tématu teamingu s Hyper-V naleznete v následujících článcích na blogu Altaro:

[thrive_leads id=’17165′]

Hyper-V a konvergence sítě

Konvergence sítě jednoduše znamená, že v jednom komunikačním kanálu je kombinováno více typů provozu. Hyper-V to do určité míry dělá vždy, protože několik virtuálních strojů používá stejný virtuální přepínač, tedy stejný síťový hardware. To vše by se však dalo technicky zařadit pod jeden nadpis „virtuální strojový provoz“, takže to není tak docela konvergence.

V prostoru Hyper-V by skutečná konvergence zahrnovala alespoň jednu další roli a zahrnovala by alespoň dva fyzické síťové adaptéry. Nejjednodušší způsob, jak toho dosáhnout, je spojit dva nebo více adaptérů do týmu, jak je uvedeno v předchozí části, a poté vytvořit virtuální přepínač na vrcholu týmového adaptéru. Když je virtuální přepínač vytvořen, použijte možnost „sdílet“ nebo PowerShell k vytvoření virtuálního adaptéru také pro operační systém pro správu. Pokud se tento adaptér používá pro cokoli v operačním systému pro správu, pak se to považuje za konvergenci. O dalších možných rolích bude řeč později.

I když nejběžnější konvergence obvykle spojuje všechny adaptéry stejné rychlosti do jednoho kanálu, není to podmínkou. Pokud si přejete, můžete použít jeden tým pro provoz virtuálních strojů a druhý pro operační systém pro správu.

Hyper-V a vytváření sítí v rámci clusteru

Failover Clustering má své vlastní speciální síťové potřeby a Hyper-V tyto požadavky dále rozšiřuje. Každý uzel začíná se stejnými požadavky jako samostatný systém Hyper-V: jeden adaptér pro správu a virtuální přepínač. Cluster zvyšuje potřebu provozu souvisejícího s clusterem a živé migrace.

Ve verzích před rokem 2012 jediná podporovaná konfigurace vyžadovala, aby byly všechny tyto role rozděleny do jedinečných gigabitových připojení. Díky vylepšením představeným v letech 2012 a 2012 R2 jsou tyto požadavky mnohem uvolněnější. S novými verzemi nejsou zveřejněny žádné požadavky (ačkoli by se dalo tvrdit, že požadavky pro 2008 R2 nebyly nikdy oficiálně nahrazeny, takže jsou technicky stále vynucovány). V praxi bylo pozorováno, že je naprosto nezbytné, aby existovaly alespoň dvě jedinečné cesty clusteru, ale zbytek lze upravit nahoru nebo dolů v závislosti na vaší pracovní zátěži.

Níže popisuje každou roli a poskytuje stručný popis jejího provozu:

Správa: Tato role bude přenášet veškerý provoz pro zálohování na úrovni hostitele a jakékoli činnosti sdílení souborů související s hostitelem, jako je přístup nebo kopírování obrazů ISO ze vzdáleného systému. V jiných obdobích tato role obvykle nezažívá velké dopravní zatížení. Typické použití je pro provoz vzdálené správy, jako je RDP a WS-Man (PowerShell), které jsou velmi lehké.

Clusterová komunikace: Každý uzel v clusteru nepřetržitě komunikuje se všemi ostatními uzly ve vzoru sítě, aby bylo zajištěno, že cluster je stále v provozu. Tato operace je běžně známá jako „tlukot srdce“, ačkoli se také obchoduje s informacemi o konfiguraci sítě. Srdeční provoz je obvykle velmi slabý, ale je extrémně citlivý na latenci. Pokud nemá vyhrazenou síť, může být snadno přehlušen jinými operacemi, jako jsou kopie velkých souborů, což způsobí, že uzly ztratí kvórum a selžou virtuální stroje, i když se technicky nic neděje.

Sdílené svazky clusteru: Provoz CSV není jedinečnou rolí; cestuje jako součást standardní klastrové komunikace. Když je vše v pořádku, provoz CSV je poměrně minimální, pouze předávání metadat CSV mezi uzly. Pokud soubor CSV přejde do režimu přesměrovaného přístupu, pak veškerý provoz do a z tohoto CSV bude zpracovávat uzel vlastníka. Pokud jakýkoli jiný uzel potřebuje přístup k tomuto CSV, učiní tak prostřednictvím sítě clusteru. Cluster zajistí, že normální komunikace klastru, jako je srdeční tep, nebude obětována, ale jakékoli problémy s šířkou pásma způsobí, že virtuální stroje budou fungovat špatně – a možná se zhroutí. Pokud váš cluster nepoužívá soubory CSV, pak se tento provoz netýká. Živá migrace: Bez omezení bude operace živé migrace využívat tolik šířky pásma, kolik jen může. Typická konfigurace poskytuje vyhrazený adaptér pro tuto roli. U konvergovaných sítí není požadavek tak přísný. Provoz virtuálního počítače: Provoz virtuálních počítačů je pravděpodobně nejdůležitější v clusteru, ale také nebývá příliš těžký. Tradičním přístupem je vyhradit virtuálnímu přepínači alespoň jeden adaptér.

Zatímco starší verze je jednoduše rozdělily na jedinečné vyhrazené gigabitové kanály, nyní máte k dispozici více možností.

Vylepšení SMB pro Cluster Communications

Clusterová komunikace vždy používala protokol SMB. Protokol SMB byl podstatně aktualizován v roce 2012 a nyní má schopnost vícekanálového provozu. Tato funkce bude automaticky vyjednávat mezi zdrojovým a cílovým hostitelem a automaticky rozloží provoz SMB mezi všechny dostupné adaptéry.

Zatímco dříve bylo nutné nastavit sítě pro klastrovou komunikaci a poté upravit přiřazení metrik pro řízení provozu, preferovaným přístupem v 2012 R2 je jednoduše označit dvě nebo více sítí jako klastrové sítě. Hostitelé budou automaticky vyrovnávat zatížení provozu.

Vylepšení pro malé a střední podniky pro migraci za provozu

Pokud jsou všechny uzly clusteru nastaveny na používání SMB pro migraci za provozu, bude využívat stejná vylepšení pro malé a střední podniky, která používá standardní komunikace clusteru. Tímto způsobem lze provoz správy, komunikační provoz clusteru a migraci za provozu provozovat pouze ve dvou různých sítích namísto dvou. To je potenciálně riskantní, zejména pokud je spuštěn režim přesměrovaného přístupu.

Výhody konvergované sítě pro klastrování

Použitím konvergovaných sítí získáte podstatně více možností s menším počtem hardwaru. SMB multichannel rozděluje provoz mezi různé sítě – tedy jedinečné podsítě. Pomocí konvergovaných sítí můžete vytvořit více podsítí, než kolik máte fyzických adaptérů.

To je zvláště užitečné pro adaptéry 10GbE, protože jen málo hostitelů bude mít více než dva. Své místo má i na 1GbE sítích. Všechny fyzické adaptéry můžete jednoduše zkombinovat do jednoho velkého týmu a vytvořit stejný počet logických sítí, jaké byste měli pro tradiční roli, ale každý z nich povolit pro komunikaci v clusteru a migraci za provozu. Tímto způsobem bude SMB multikanál schopen automaticky vyrovnávat zatížení svých potřeb. Pamatujte, že i v případě konvergovaných sítí je nejlepší nekombinovat všechny role do jednoho virtuálního nebo týmového adaptéru. Vícekanálové SMB vyžadují odlišné podsítě, aby mohly plnit svou roli, a týmová práce vyvažuje část provozu podle virtuálního adaptéru.

Přínosy kvality služeb pro klastrování

I když se obavy projevují jen zřídka, je technicky možné, aby jeden typ provozu plně pohltil konvergovaný tým. Existuje řada možností QoS (Quality of Service), aby se tomu zabránilo. Můžete konkrétně omezit provoz SMB a/nebo migrace za provozu a nastavit maxima a minima na virtuálních adaptérech.

Než strávíte hodně času zkoumáním těchto možností, uvědomte si, že většina nasazení nevyžaduje tento stupeň kontroly a bude fungovat naprosto dobře s výchozími nastaveními. Hyper-V bude automaticky pracovat na udržení rovnováhy provozu, která zcela nepřehluší žádný konkrétní virtuální síťový adaptér. Protože složitost konfigurace QoS převažuje nad jejími výhodami v typickém prostředí, nebude toto téma v této sérii zkoumáno. Nejpodrobnější práce na toto téma jsou k dispozici na TechNet.

Jak navrhnout klastrové sítě pro Hyper-V

Jedním kritickým konceptem je, že klastrové sítě jsou definovány podsítí TCP/IP. Clusterová služba zjistí každou IP adresu a masku podsítě na každém uzlu. Z nich vytvoří síť pro každou jedinečnou podsíť, kterou najde. Pokud má některý uzel v podsíti více než jednu adresu IP, klastrová služba použije jednu a zbytek bude ignorovat, pokud nebude první odebrána. Pokud služba najde sítě, pro které mají IP adresy pouze některé uzly, bude síť označena jako rozdělená. Síť bude také označena jako rozdělená, pokud je komunikace clusteru povolena, ale vyskytnou se problémy s tokem provozu mezi uzly. Následující diagram ukazuje některé vzorové sítě a způsob, jakým je shlukování zjistí.

Na obrázku je jedinou platnou sítí Cluster Network 2. Nejhorší je Cluster Network 4. Kvůli způsobu konfigurace podsítě se překrývá se všemi ostatními sítěmi. Clusterová služba automaticky uzamkne adaptér uzlu 2 s adresou IP 192.168.5.11 mimo komunikaci klastru a označí síť jako Žádná, což znamená, že není povolena komunikace klastru.

Před vytvořením clusteru určete podsítě IP, které budete používat. V případě potřeby je naprosto přijatelné vytvořit zcela nové sítě. U klastrové komunikace nebudou uzly záměrně komunikovat s ničím jiným než s uzly ve stejném klastru. Minimální počet unikátních sítí jsou dvě. Jeden musí být označen, aby umožňoval komunikaci klienta a clusteru; toto je síť pro správu. Jeden musí být označen, aby umožňoval komunikaci s klastrem (komunikace s klientem je volitelná, ale nedoporučuje se). Další sítě jsou volitelné, ale umožní clusteru vytvářet další toky TCP, které mohou pomoci s vyrovnáváním zátěže mezi týmovými adaptéry.

Osvědčené postupy pro síť Hyper-V – konfigurace v praxi

Neexistuje žádný jediný „správný“ způsob konfigurace sítě v Hyper-V o nic víc, než jediný „správný“ způsob konfigurace. fyzickou síť. Tato část se bude zabývat řadou osvědčených postupů a postupů, aby vám ukázala, jak se věci dělají, a poskytne pokyny, kde je to možné. Nejlepší rada, kterou vám kdokoli může dát, je nepřemýšlet nad tím. Velmi málo virtuálních strojů bude vyžadovat velkou šířku pásma sítě.

Existuje několik doporučených postupů, které vám pomohou učinit některá základní rozhodnutí o konfiguraci:

Výsledkem konvergované sítě je nejlepší celkové rozložení šířky pásma. Je extrémně vzácné nastat situace, kdy by jedna síťová role neustále využívala celé gigabitové připojení. Vyčleněním jednoho nebo více adaptérů jedné roli zabráníte jakékoli jiné roli v používání tohoto adaptéru, i když je její vlastnící role nečinná. Jeden datový proud TCP/IP může používat pouze jedno fyzické spojení. Jednou z nejvíce matoucích věcí na vytváření týmů, s nimiž se nováčci potýkají, je to, že spojení více odkazů do jednoho týmu automaticky neznamená, že veškerý provoz automaticky využije všechny dostupné odkazy. To znamená, že různé komunikační toky budou vyváženy napříč dostupnými. Nebo, aby to bylo jasnější, potřebujete alespoň čtyři různé komunikační toky k plnému využití čtyř adaptérů v týmu. Nepoužívejte iSCSI nebo SMB 3 přímo s týmem. Je podporováno pro obojí, ale je méně efektivní než použití MPIO (pro iSCSI) nebo SMB multikanál. Je podporováno mít více virtuálních síťových adaptérů v týmu, které jsou nakonfigurovány pro iSCSI nebo SMB multichannel. Nejlepšího výkonu pro síťové úložiště však vždy dosáhnete použitím netýmových adaptérů, které nejsou vázány na virtuální přepínač. Tento článek vysvětluje, jak nakonfigurovat MPIO.

Potřebné kroky k vytvoření týmu byly propojeny dříve, ale zde je opět odkaz: https://www.altaro.com/hyper-v/how-to-set-up- nativní-týmy-na-hyper-v-server-2012/.

Konfigurace adaptéru a TCP/IP

Pokud váš systém používá edici GUI systému Windows Server, můžete nakonfigurovat TCP/IP pro všechny adaptéry pomocí tradičních grafických nástrojů. Pro všechny verze můžete také použít sconfig.cmd pro řízený proces. Tato část ukazuje, jak tyto úlohy provádět pomocí PowerShellu. Aby byl materiál co nejstručnější, nebudou zobrazeny všechny možné možnosti. V úvodním článku o prostředí PowerShell najdete pomoc s používáním objevování možností rutin pomocí Get-Help a dalších nástrojů.

Viz Stav adaptéru (a názvy k použití v jiných rutinách)

Get-NetAdapter

Přejmenujte fyzický nebo týmový adaptér

Rename-NetAdapter Name CurrentName NewName NewName

Nastavte IP adresu adaptéru

New-NetIPAddress InterfaceAlias ​​AdapterName IPAddress 192.168.20.20 PrefixLength 24

Nastavit výchozí bránu adaptéru

New-NetRoute InterfaceAlias ​​AdapterName DestinationPrefix 0.0.0.0/0 NextHop 192.168.20.1

Tip: Pro provedení změn použijte „Set-NetRoute“ nebo pro odstranění brány použijte „Remove-NetRoute“.

Nastavte adresy serveru DNS

Set-DNSClientServerAddresses InterfaceAlias ​​AdapterName –ServerAddresses 192.168.20.5, 192.168.20.6

Zabránění adaptéru v registraci v DNS

Set-DnsClient InterfaceAlias ​​AdapterName RegisterThisConnectionsAddress $false

Jedna poslední možnost, kterou byste měli zvážit, je nastavení Jumbo Frames na vašich virtuálních adaptérech. Jumbo Frame je jakýkoli paket TCP/IP, který přesahuje základní velikost 1514 bajtů. Nejčastěji se používá pro připojení iSCSI, ale může také trochu pomoci s provozem SMB 3 a Live Migration. Pro provoz přes internet to není vůbec užitečné a většina běžného LAN provozu z toho také moc netěží. Pokud jej chcete použít, následující příspěvek to podrobně vysvětluje: https://www.altaro.com/hyper-v/how-to-adjust-mtu-jumbo-frames-on-hyper-v-and -windows-server-2012/. Tento konkrétní článek byl napsán pro rok 2012. Virtuální přepínač v 2012 R2 má ve výchozím nastavení povolené rámce Jumbo Frame, takže stačí postupovat podle částí, které vysvětlují, jak to nastavit na vašich fyzických a virtuálních adaptérech.

Konfigurace virtuálních přepínačů a virtuálních adaptérů

Všechny grafické nástroje pro vytvoření virtuálního přepínače a nastavení jednoho virtuálního adaptéru pro operační systém pro správu byly popsány v tomto předchozím článku ze série. Grafické nástroje nemůžete použít k vytvoření dalších virtuálních adaptérů pro použití operačním systémem pro správu. Pokud chcete řídit jeho zásady QoS, musíte k vytvoření virtuálního přepínače použít také PowerShell. Následující příkazy prostředí PowerShell se zabývají virtuálním přepínačem a jeho adaptéry.

Vytvořte externí virtuální přepínač

New-VMSwitch –InterfaceAlias ​​AdapterName –Name vSwitch –AllowManagementOS $false –EnableIOV $false –MinimumBandwidthMode Weight

O této konkrétní rutině je třeba poznamenat několik věcí:

Výše uvedený parametr „InterfaceAlias“ je ve skutečnosti alias pro „NetAdapterName“. Alias ​​byl vybrán zde, protože odpovídá názvu parametru a výstupu Get-NetAdapter. Rutina byla napsána s „vSwitch“ jako název virtuálního přepínače, ale můžete použít cokoli, co chcete. Pokud je ve vámi zvoleném názvu mezera, musíte ji uzavřít do jednoduchých nebo dvojitých uvozovek. Pokud nezadáte parametr „AllowManagementOS“ nebo pokud jej nastavíte na hodnotu true, automaticky se vytvoří virtuální adaptér pro operační systém pro správu. se stejným názvem jako virtuální přepínač. Přeskočením tohoto automatického vytváření získáte větší kontrolu nad vytvářením a nastavením vlastních virtuálních adaptérů. Pokud si nepřejete povolit SR-IOV na svém virtuálním přepínači, není nutné tento parametr vůbec zadávat. Zde je zobrazeno jako připomenutí, že pokud jej chcete nastavit, musíte jej nastavit při vytvoření přepínače. Toto nemůžete později změnit. Dokumentace nápovědy pro Get-VMSwitch uvádí, že výchozí nastavení pro „MinimumBandwidthMode“ je „Weight“. Toto je nesprávné. Výchozí režim je „Absolutní“. Stejně jako u podpory SR-IOV nelze toto nastavení po vytvoření přepínače upravit.

Vytvoření soukromého virtuálního přepínače

Nový-VMSwitch Název Izolovaný SwitchType Private MinimumBandwidthMode Weight

Mnoho poznámek z vytvoření externího přepínače platí i zde. Přepínač „EnableIOV“ nelze na soukromý nebo interní přepínač vůbec použít. Přepínač „AllowManagementOS“ je nadbytečný: pokud je typ přepínače „Soukromý“, nevytvoří se žádný virtuální adaptér; pokud je typ přepínače „Interní“, pak je jeden vytvořen. Přidáním jednoho virtuálního adaptéru do operačního systému pro správu na soukromém přepínači jej převedete na interní; odebráním všech virtuálních adaptérů operačního systému pro správu z interního přepínače se změní na soukromý.

Trvale odeberte virtuální přepínač

Remove-VMSwitch Name vSwitch

Tato operace je trvalá. Celý přepínač a všechna jeho nastavení jsou ztracena. Všechny virtuální adaptéry v operačním systému pro správu na tomto přepínači jsou trvale ztraceny. Virtuální adaptéry ve virtuálních počítačích připojených k tomuto přepínači jsou odpojeny.

Přidejte virtuální adaptér do operačního systému pro správu

Add-VMNetworkAdapter ManagementOS SwitchName Název vSwitch 'New vAdapter'

První věc, kterou je třeba poznamenat, je, že z nějakého důvodu tato rutina používá pro vytvoření nového objektu slovo „Add“ místo normálního slovesa „New“. Uvědomte si, že tento nový adaptér se zobrazí v položkách Get-NetAdapter jako vEthernet (New vAdapter) a to je název, který budete používat pro všechny takové rutiny bez Hyper-V. Ke konfiguraci použijte stejné rutiny jako v předchozí části

Načtěte seznam virtuálních adaptérů v OS pro správu

Get-VMNetworkAdapter –ManagementOS

Přejmenujte virtuální adaptér v OS pro správu

Rename-VMNetworkAdapter ManagementOS Name CurrentName NewName NewName

Jak nastavit informace VLAN pro virtuální adaptéry Hyper-V

K sítím VLAN lze přiřadit adaptéry pro operační systém pro správu a virtuální počítače. Když k tomu dojde, bude virtuální přepínač Hyper-V zpracovávat proces označování 802.1q pro komunikaci mezi virtuálními přepínači a pro pakety do az fyzických přepínačů. Jak je uvedeno v článku o nastavení virtuálního počítače, můžete použít Správce Hyper-V ke změně VLAN pro libovolný z adaptérů připojených k virtuálním počítačům. PowerShell můžete použít pouze ke změně VLAN pro virtuální adaptéry v operačním systému pro správu.

Získejte přiřazení VLAN pro všechny virtuální adaptéry na hostiteli

GetVMNetworkAdapterVlan

Parametr „ManagementOS“ můžete použít k zobrazení pouze adaptérů v operačním systému pro správu. Parametr „VMName“ s hvězdičkou můžete použít k zobrazení pouze adaptérů připojených k virtuálním počítačům.

Nastavte VLAN pro virtuální adaptér v operačním systému pro správu

Set-VMNetworkAdapterVlan ManagementOS VMNetworkAdapterName vAdapterName Přístup VlanId 10

Nastavte VLAN pro všechny adaptéry virtuálního počítače

Set-VMNetworkAdapterVlan -VMName svtest -Access -VlanId 7

Odstranění VLAN tagování ze všech adaptérů virtuálního počítače

Set-VMNetworkAdapterVlan -VMName svtest –Untagged

Pokud má virtuální počítač více než jeden virtuální adaptér a chtěli byste na něm pracovat samostatně, může to vyžadovat trochu více práce. Když se GUI používá k vytváření virtuálních adaptérů pro virtuální počítač, vždy se jmenují Síťový adaptér, i když jich je několik. Budete tedy muset použít PowerShell k jejich přejmenování, jakmile jsou vytvořeny, nebo je nebudete moci rozlišit pomocí „VMNetworkAdapterName“. Místo toho můžete použít Get-VMNetworkAdapter k nalezení dalších rozlišovacích funkcí a přesměrovat výstup do rutin, které přijímají objekty VMNetworkAdapter. Chcete například změnit VLAN pouze jednoho adaptéru připojeného k virtuálnímu počítači s názvem „svtest“. Pomocí nástrojů v hostujícím operačním systému jste zjistili, že MAC adresa adaptéru, který chcete změnit, je „00-15-5D-19-0A-24“. Pomocí MAC adresy můžete změnit VLAN pouze tohoto adaptéru pomocí následující konstrukce PowerShell:

GetVMNetworkAdapter VMName svtest | kde { $_.MacAddress eq '00155D190A24' } | SetVMNetworkAdapterVlan – VMName Access VlanId 7

Konfigurace sítě clusteru

Pro konfiguraci sítě pro váš cluster s podporou převzetí služeb při selhání je možné použít PowerShell, ale je to velmi neelegantní s aktuálním stavem těchto rutin. V současné době nejsou dobře nakonfigurovány, takže musíte přímo manipulovat s hodnotami vlastností objektů a nastavením registru způsobem, který je riskantní a náchylný k chybám. K provedení těchto nastavení je mnohem lepší použít Správce clusteru s podporou převzetí služeb při selhání, jak je vysvětleno v tomto článku dříve v této sérii.

Pokračovat v prozkoumávání sítí

Ve virtuálních sítích Hyper-V je toho hodně k trávení. To, co jste zatím viděli, jsou skutečně jen základy. Pro relativně zjednodušené nasazení s ne více než několika desítkami virtuálních strojů možná nikdy nebudete potřebovat žádné další informace. S tím, jak hustota začíná stoupat, roste potřeba přesněji vyladit síť. S gigabitovými adaptéry je nejlepší možností škálování. Adaptéry 10GbE vám umožňují překonat fyzická omezení CPU pomocí řady technik snižování zátěže, z nichž hlavní je VMQ. Začněte svůj výzkum na toto téma tím, že začnete s definitivní sérií článků na toto téma, VMQ Deep Dive.

V opačném případě je nejlepším dalším krokem procvičit si rutiny prostředí PowerShell. Naučte se například používat Set-VMNetworkAdapter k úpravě virtuálních adaptérů podobným způsobem, jaký jste viděli v předchozích článcích s GUI. S trochou úsilí budete moci změnit skupiny adaptérů najednou. Síť Hyper-V může být mnohostranná a komplikovaná, ale úroveň kontroly, kterou máte, je stejně široká.