Průvodce aspekty návrhu prostředků infrastruktury virtualizace

 

Komu je tato příručka určená? Specialisté na informační technologie (IT) ve středně velkých až velkých organizacích, kteří odpovídají za návrh prostředků infrastruktury virtualizace, které podporují mnoho virtuálních počítačů. Ve zbývající části tohoto dokumentu se tito pracovníci označují jako správci prostředků infrastruktury. Pracovníci, kteří spravují virtuální počítače hostované v prostředcích infrastruktury, se nazývají správci virtuálních počítačů. Ti ale nejsou cílovou skupinu pro tento dokument. V rámci vaší organizace můžete zastávat obě role.

Jak vám může tento průvodce pomoct? V tomto průvodci můžete porozumět tomu, jak navrhnout prostředky infrastruktury virtualizace, které umožní hostovat velký počet virtuálních počítačů v organizaci. V tomto dokumentu se kolekce serverů, hypervisorů a hardwaru pro úložiště a sítě využívaných k hostování virtuálních počítačů v rámci organizace označuje jako prostředky infrastruktury virtualizace. Příklad prostředků infrastruktury virtualizace je na následujícím obrázku.

Prostředky virtualizace

Obrázek 1:Příklad prostředků infrastruktury virtualizace

Poznámka: Každý diagram v tomto dokumentu se nachází na samostatné kartě dokumentu Průvodce aspekty návrhu prostředků infrastruktury virtualizace. Můžete si ho stáhnout klepnutím na název obrázku v jednotlivých popiscích tabulky.

Přestože každé řešení prostředků infrastruktury virtualizace zahrnuje jednak servery pro úložné a hostovací virtuální počítače, jednak sítě, které je propojují, návrh prostředků infrastruktury virtualizace se bude v jednotlivých organizacích pravděpodobně lišit od příkladu znázorněno na obrázku 1, a to kvůli různým požadavkům.

Tento průvodce detailně popisuje sérii kroků a úloh, které vám můžou usnadnit navržení prostředků infrastruktury virtualizace, které budou vyhovovat jedinečným požadavkům vaší organizace. Ve všech krocích a úlohách uvádí průvodce relevantní technologie a možnosti funkcí, které máte k dispozici pro naplnění požadavků na funkční úroveň a kvalitu služeb (například dostupnost, škálovatelnost, výkon, možnosti správy a zabezpečení).

Ačkoli vám tento dokument může pomoct při navrhování spravovatelných prostředků architektury virtualizace, nezabývá se aspekty návrhu a možnostmi pro správu a provozování prostředků architektury virtualizace s produktem, jako je Microsoft System Center 2012 nebo System Center 2012 R2. Další informace najdete v tématu System Center 2012 v knihovně TechNet.

Tento průvodce vám pomůže navrhnout prostředky architektury virtualizace pomocí Windows Serveru 2012 R2 a Windows Serveru 2012 a hardwaru bez ohledu na dodavatele. Některé funkce popsané v dokumentu jsou jedinečné pro Windows Server 2012 R2, na což v dokumentu vždycky upozorníme.

Předpoklady: Máte nějaké zkušenosti s nasazením Hyper-V, virtuálních počítačů, virtuálních sítí, souborových služeb Windows Serveru a převzetí služeb při selhání a nějaké zkušenosti s nasazením fyzických serverů, úložiště a síťového vybavení.

Další zdroje informací

Než se pustíte do návrhu prostředků architektury virtualizace, mohly by být pro vás užitečné informace v následujících dokumentech:

Oba tyto dokumenty přinášejí základní koncepty, které je možné vysledovat v různých návrzích prostředků architektury virtualizace, a můžou sloužit jako základ pro jakýkoli návrh prostředků architektury virtualizace.

Váš názor: Pokud nám chcete sdělit svůj názor na tento dokument, pošlete nám e-mail na adresu virtua@microsoft.com.

Přehled aspektů návrhu

Zbývající část tohoto dokumentu přináší sadu kroků a úloh, podle nichž můžete navrhnout prostředky infrastruktury virtualizace, které budou nejlépe vyhovovat vašim požadavkům. Kroky uvádíme v seřazené posloupnosti. Aspekty návrhu, s nimiž se seznámíte v dalších krocích, můžou vést k tomu, že budete muset změnit rozhodnutí, která jste udělali v dřívějších krocích, a to kvůli konfliktům. V celém dokumentu vyvíjíme maximální snahu, abychom vás na potenciální konflikty návrhu upozorňovali.

K návrhu, který bude nejlépe vyhovovat vašim požadavkům, se dopracujete tak, že kroky projdete tolikrát, kolikrát bude potřeba pro to, abyste zapracovali všechny aspekty uvedené v tomto dokumentu.

Krok 1: Stanovení požadavků na prostředky virtuálních počítačů

Krok 2: Plánování konfigurace virtuálních počítačů

Krok 3: Plánování skupin hostitelů virtualizace serverů

Krok 4: Plánování hostitelů virtualizace serverů

Krok 5: Plánování konceptů architektury prostředků infrastruktury virtualizace

Krok 6: Plánování charakteristik počátečních kapacit

Krok 1: Stanovení požadavků na prostředky virtuálních počítačů

Prvním krokem při navrhování prostředků architektury je stanovit požadavky na prostředky virtuálních počítačů, pro které budou prostředky infrastruktury hostitelem. Prostředky infrastruktury musí zahrnovat fyzický hardware potřebný pro naplnění těchto požadavků. Požadavky na prostředky virtuálních počítačů vyplývají z operačních systémů a aplikací, které na virtuálních počítačích poběží. Ve zbývající části tohoto dokumentu se kombinace operačního systému a aplikací, které na virtuálním počítači poběží, označuje jako zatížení. Úlohy v tomto kroku vám pomůžou definovat požadavky na prostředky pro zatížení, která potřebujete.

Tip: Namísto vyhodnocování požadavků na prostředky pro jednotlivá zatížení a následného navrhování prostředků infrastruktury virtualizace, které dokážou podporovat každé z nich, se můžete rozhodnout pro návrh prostředků infrastruktury virtualizace, které naplňují potřeby většiny běžných zatížení. A potom samostatně dořešit zatížení s jedinečnými potřebami.

Příkladem takových prostředků infrastruktury virtualizace jsou ty, které nabízejí poskytovatelé veřejných cloudů, jako je Microsoft Azure (Azure). Další informace najdete v tématu Velikost služeb pro virtuální počítače a cloud pro Azure.

Poskytovatelé veřejných cloudů obvykle nabízejí řadu konfigurací virtuálních počítačů, které naplňují potřeby pro většinu zatížení. Pokud se rozhodnete pro tento postup, můžete rovnou přeskočit na Krok 2: Plánování konfigurace virtuálních počítačů v tomto dokumentu. Další výhody tohoto postupu:

  • Pokud se rozhodnete pro migraci některých z vašich místních virtuálních počítačů k poskytovateli veřejného cloudu a pokud jsou typy konfigurací těchto místních virtuálních počítačů podobné konfiguracím u veřejného poskytovatele, migrace virtuálních počítačů bude snazší, než kdyby se typy konfigurací lišily.

  • Může vám to usnadnit předvídání požadavků na kapacitu a poskytnout možnost samoobslužného zřizování prostředků architektury virtualizace. To znamená, že správci virtuálních počítačů v rámci organizace můžou automaticky samoobslužně zřizovat nové virtuální počítače bez zapojení správců prostředků infrastruktury.

Úloha 1: Stanovení požadavků na prostředky u zatížení

Každé zatížení vyžaduje následující prostředky. Nejprve bude dobré si u každého z vašich zatížení odpovědět na následující otázky.

  • Procesor: Jaká procesorová rychlost nebo architektura (Intel nebo AMD) nebo jaký počet procesorů je potřeba?

  • Síť: Jaká síťová šířka pásma v gigabitech za sekundu (Gb/s) je potřebná pro příchozí a odchozí přenosy? Jaký je maximální rozsah latence sítě, při kterém bude ještě zatížení fungovat správně?

  • Úložiště: Kolik gigabajtů (GB) úložiště vyžadují soubory operačního systému a aplikací u daného zatížení? Kolik GB úložiště vyžaduje zatížení pro svoje data? Kolik vstupně-výstupních operací za sekundu (IOPS) potřebuje zatížení při přístupu ke svému úložišti?

  • Paměť: Kolik paměti v gigabajtech (GB) zatížení vyžaduje? Podporuje zatížení architekturu NUMA?

Kromě posouzení právě uvedených požadavků je taky důležité stanovit následující:

  • Jestli jde o minimální, nebo doporučené požadavky na prostředky.

  • Jaké jsou jednotlivé požadavky na hardware ve špičce a jaké v průměru, a to v hodinové, denní, týdenní, měsíční nebo roční perspektivě.

  • Přijatelný objem výpadků za měsíc pro zatížení a jeho data, a to v minutách. Při určování tohoto údaje zvažte tyto faktory:

    • Běží zatížení jenom na jednom virtuálním počítači, nebo v kolekci virtuálních počítačů, která funguje jako celek, například v kolekci serverů s vyrovnáváním síťového zatížení, kde na všech běží stejné zatížení? Pokud používáte kolekci serverů, mělo by být u deklarovaného objemu výpadků jasno, jestli se platí pro každý server v kolekci, pro všechny servery v kolekci, nebo na úrovni kolekce.

    • Pracovní a nepracovní doba. Pokud například nebude zatížení nikdo používat od 21:00 do 6:00 hodin, ale je velmi důležité, aby bylo k dispozici v maximální míře od 6:00 do 21:00 hodin, s přijatelným měsíčním objemem výpadků v rozsahu pouhých 10 minut, je třeba tento požadavek stanovit.

  • Přijatelný objem datových ztrát v případě neočekávaného selhání virtuální infrastruktury. Vyjadřuje se v minutách, protože strategie replikace virtuální infrastruktury jsou obvykle založené na čase. Přestože se často jako požadavek objevují nulové ztráty, vezměte v úvahu, že jejich dosažení s sebou obvykle nese vyšší cenu a může taky znamenat nižší výkon.

  • Jestli soubory nebo data v rámci zatížení musí být zašifrovaná na disku a jestli se musí tato data šifrovat mezi virtuálními počítači a koncovými uživateli.

Ke stanovení výše uvedených požadavků na prostředky máte tyto možnosti.

Možnost

Výhody

Nevýhody

Ruční vyhodnocování a protokolování využití prostředků

Schopnost vykazovat, cokoli si zvolíte

Může vyžadovat značné úsilí.

Automatické vyhodnocování a protokolování využití prostředků pomocí sady Microsoft Assessment and Planning Toolkit

  • Vytváří celou řadu sestav využití prostředků.

  • Nevyžaduje instalaci agenta u zatížení.

Sestavy můžou, ale nemusí poskytovat všechna data, která potřebujete.

Poznámka: Pokud se rozhodnete stanovit požadavky na prostředky ručně, můžete si stáhnout listy v Průvodci aspekty návrhu prostředků infrastruktury virtualizace a zadávat informace do listu požadavků na prostředky u zatížení. Tento průvodce na určité listy v uvedeném dokumentu odkazuje.

Úloha 2: Definování charakteristik zatížení

Ve svém prostředí si můžete definovat libovolný počet charakteristik zatížení. Následující příklady jsme vybrali proto, že každý z nich vyžaduje jinou konfiguraci komponent prostředků architektury virtualizace. Ty dál probereme v pozdějších krocích.

  • Bezstavové: Po svém počátečním zřízení a přiřazení jedinečných názvů počítačů a síťových adres nezapisují na místní pevný disk žádné jedinečné informace. Můžou ale zapisovat jedinečné informace do odděleného úložiště, například do databáze. Bezstavová zatížení jsou optimální pro prostředky architektury virtualizace, protože pro virtuální počítač se dá vytvořit „hlavní“ image. Tato image se dá v prostředcích architektury virtualizace snadno kopírovat a spouštět, aby se u zatížení zvětšil rozsah škálování nebo aby se dal rychle nahradit virtuální počítač, který se stane nedostupným v případě selhání hostitele virtualizace. Příkladem bezstavového zatížení je webový server, na kterém běží front-endová webová aplikace.

  • Stavové: Po svém počátečním zřízení a přiřazení jedinečných názvů počítačů a síťových adres zapisují na místní pevný disk jedinečné informace. Ty můžou zapisovat i do odděleného úložiště, například do databáze. Stavová zatížení obvykle vyžadují složitější strategie zřizování a škálování než bezstavová zatížení. Strategie vysoké dostupnosti pro stavová zatížení může vyžadovat sdílení stavu s jinými virtuálními počítači. Příkladem stavového zatížení je databázový stroj SQL Serveru.

  • Se sdílením stavu: Stavová zatížení, která vyžadují nějaký sdílený stav s jinými virtuálními počítači. Tato zatížení často k dosažení vysoké dostupnosti používají clustering s podporou převzetí služeb při selhání ve Windows Serveru, což vyžaduje přístup ke sdílenému úložišti. Příkladem zatížení se sdílením stavu je Microsoft System Center – Virtual Machine Manager.

  • Jiné: Charakterizuje zatížení, která se v prostředcích architektury virtualizace nemusí vůbec spustit nebo nepoběží optimálně. Pro taková zatížení je typické, že vyžadují:

    • Přístup k fyzickým periferním zařízením. Příkladem takové aplikace je zatížení zajišťující telefonii, které komunikuje se síťovým adaptérem pro telefonii na fyzickém hostiteli.

    • Požadavky na prostředky jsou mnohem vyšší než u většiny vašich dalších zatížení. Příkladem je aplikace v reálném čase, která mezi aplikačními vrstvami vyžaduje nižší latenci než 1 milisekunda.

    Tyto aplikace se v prostředcích architektury virtualizace můžou, ale nemusí spouštět nebo můžou vyžadovat velmi specifický hardware nebo konfiguraci, kterou nebude sdílet většina vašich dalších zatížení.

Poznámka: Charakteristiky zatížení si můžete definovat na listu Nastavení a pak vybrat příslušnou charakteristiku pro každé zatížení v listu Požadavky na prostředky u zatížení.

Krok 2: Plánování konfigurace virtuálních počítačů

V tomto kroku definujete typy virtuálních počítačů, které budete potřebovat k naplnění požadavků na prostředky, a charakteristiky zatížení, které jste definovali v kroku 1.

Úloha 1: Definování výpočetní konfigurace

V této úloze je nutné určit objem paměti a procesorů, které vyžaduje každý virtuální počítač.

Úloha 1a: Definování typu generování virtuálních počítačů

Windows Server 2012 R2 přinesl 2. generaci virtuálních počítačů. Virtuální počítače 2. generace podporují hardwarové a virtualizační funkce, které se nepodporují u jejich 1. generace. Je důležité udělat správné rozhodnutí z hlediska vašich požadavků, protože po vytvoření virtuálního počítače už nejde jeho typ změnit.

Virtuální počítače 2. generace poskytují následující nové funkce:

  • Spouštění pomocí technologie PXE s použitím standardního síťového adaptéru

  • Spouštění z virtuálního pevného disku SCSI

  • Spouštění z virtuálního disku DVD SCSI

  • Zabezpečené spouštění (povolené ve výchozím nastavení)

  • Podpora firmwaru UEFI

Virtuální počítače 2. generace podporují následující hostované operační systémy:

  • Windows Server 2012 R2

  • Windows Server 2012

  • 64bitová verze Windows 8.1

  • 64bitová verze Windows 8

  • Konkrétní verze Linuxu Seznam distribucí a verzí, které podporují virtuální počítače 2. generace, najdete v tématu Virtuální počítače s Linuxem v technologii Hyper-V.

V následující tabulce najdete výhody a nevýhody 1. a 2. generace virtuálních počítačů.

Možnost

Výhody

Nevýhody

1. generace

  • Podporuje všechny podporované hostované operační systémy Hyper-V.

  • Zajišťuje kompatibilitu s virtuálními počítači Azure.

  • Podporuje předchozí verze Hyper-V.

Bez přístupu k novým funkcím virtuálních počítačů

2. generace

  • Podporuje nové funkce.

  • Přináší mírné zlepšení, pokud jde o dobu spouštění virtuálních počítačů a dobu instalace hostů.

  • Ke spuštění virtuálního počítače používá zařízení SCSI nebo standardní síťový adaptér.

  • Pokud je povolená funkce Zabezpečené spouštění, brání spuštění neautorizovaného firmwaru, operačních systémů nebo ovladačů rozhraní UEFI.

  • Omezená podpora pro hostované operační systémy

  • Nekompatibilní s virtuálními počítači Azure

  • Bez podpory pro RemoteFX

  • Bez podpory pro virtuální diskety

Důležité: Linuxové virtuální počítače 2. generace nepodporují zabezpečené spouštění. Když vytváříte virtuální počítač a máte v úmyslu nainstalovat Linux, musíte vypnout zabezpečené spouštění v nastavení virtuálního počítače.

Další informace:

Přehled virtuálních počítačů 2. generace

Úloha 1b: Definování paměti

Velikost paměti virtuálního počítače byste měli naplánovat stejně, jako to obvykle děláte u serverových aplikací na fyzickém počítači. Měla by přiměřeně zvládat očekávanou běžnou zátěž a i zátěž ve špičce. Nedostatečná paměť může významně prodloužit doby odezvy, zvýšit využití procesoru nebo navýšit vstupně-výstupní operace.

Statická paměť nebo dynamická paměť

Statická paměť je množství paměti přidělené virtuálnímu počítači. Vždycky se přidělí, když se virtuální počítač spustí, a při jeho běhu se nemění. Všechna paměť se virtuálnímu počítači přidělí při spuštění a kapacita paměti, kterou virtuální počítač nevyužívá, není k dispozici pro jiné virtuální počítače. Pokud na hostiteli není k dispozici dost paměti pro přidělení virtuálnímu počítači při jeho spuštění, nepůjde virtuální počítač spustit.

Statická paměť je dobrá pro zatížení, která jsou náročná na paměť, a pro zatížení, která mají vlastní systémy správy paměti, jako je SQL Server. Tyto typy zatížení budou líp fungovat se statickou pamětí.

Poznámka: Neexistuje žádné nastavení, kterým by zapnula statická paměť. Statická paměť je zapnutá, když není zapnutá dynamická paměť.

Dynamická paměť vám umožní lepší využití fyzické paměti v systému díky vyrovnávání celkové fyzické paměti mezi několika virtuálními počítači, přičemž se přiděluje víc paměti využívanějším virtuálním počítačům a odebírá se míň využívaným. To může vést k vyšším konsolidačním poměrům, zejména v dynamických prostředích, jako je Infrastruktura virtuálních klientských počítačů (VDI) nebo webové servery.

Pokud se při používání statické paměti přidělí virtuálnímu počítači 10 GB paměti, ale ten pak využívá jenom 3 GB, zbývajících 7 GB paměti nebude k dispozici pro použití jinými virtuálními počítači. Pokud je u virtuálního počítače povolená dynamická paměť, virtuální počítač využívá jenom potřebnou velikost paměti, ale ne míň než nakonfigurovanou minimální velikost paměti RAM. Tím se uvolní víc paměti pro jiné virtuální počítače.

V následující tabulce najdete výhody a nevýhody statické a dynamické paměti.

Možnost

Výhody

Nevýhody

Statická paměť

  • Neustále poskytuje virtuální počítače s dostupnou nakonfigurovanou pamětí.

  • Poskytuje lepší výkon.

  • Dá se používat s virtuálním uzlem NUMA.

  • Paměť nevyužívanou virtuálním počítačem nejde přidělit jinému virtuálnímu počítači.

  • Virtuální počítače se nespustí, pokud není k dispozici dost paměti.

Dynamická paměť

  • Poskytuje lepší hustotu virtuálních počítačů při běhu nečinných nebo málo využívaných zatížení.

  • Umožňuje přidělení nevyužité paměti tak, aby ji mohly využívat jiné virtuální počítače.

  • Nakonfigurovanou paměť můžete přidělit nadměrnému počtu procesů.

  • Správa přidělování paměti vyžaduje dodatečnou režii.

  • Není kompatibilní s virtuálním uzlem NUMA.

  • Není kompatibilní se zatíženími, které implementují vlastní nástroje pro správu paměti.

Nastavení konfigurace paměti je následující:

  • Paměť RAM při spuštění: Určuje velikost paměti, která je potřebná ke spuštění virtuálního počítače. Tato hodnota musí být dostatečně vysoká, aby umožňovala spuštění hostovaného operačního systému, ale musí být co nejnižší, aby umožňovala optimální využití paměti a potenciálně vyšší konsolidační poměry.

  • Minimální paměť RAM: Určuje minimální velikost paměti, která by měla být virtuálnímu počítači po jeho spuštění přidělená. Hodnotu jde nastavit v rozsahu od 32 MB po maximální hodnotu rovnou hodnotě paměti RAM při spuštění. Toto nastavení je k dispozici, jenom pokud je zapnutá dynamická paměť.

  • Maximální paměť RAM: Určuje maximální množství paměti, kterou může tento virtuální počítač používat. Tato hodnota může být v rozsahu od hodnoty paměti RAM při spuštění po 1 TB. Virtuální počítač ale může používat jenom tolik paměti, kolik odpovídá maximálnímu množství podporovanému v hostovaném operačním systému. Pokud například zadáte 64 GB pro virtuální počítač s hostovaným operačním systémem, který podporuje maximálně 32 GB, nemůže použít víc než 32 GB. Toto nastavení je k dispozici, jenom pokud je zapnutá dynamická paměť.

  • Váha paměti: Poskytuje Hyper-V s možností určit, jak se bude distribuovat paměť mezi virtuálními počítači, pokud na hostiteli není k dispozici dost fyzické paměti, aby bylo možné každému virtuálnímu počítači poskytnout požadovanou velikost. Virtuální počítače s vyšší váhou paměti mají přednost před virtuálními počítači s nižší vahou.

Poznámky:

  • Funkce dynamické paměti a virtuální architektury NUMA se nedají používat zároveň. Virtuální počítač s efektivně povolenou dynamickou pamětí má jenom jeden virtuální uzel NUMA a bez ohledu na nastavení virtuální architektury NUMA se mu nepředkládá žádná topologie NUMA.

  • Při instalaci nebo upgradu operačního systému virtuálního počítače odpovídá velikost paměti, která je k dispozici pro virtuální počítač během procesu instalace a upgradu, hodnotě zadané jako paměť RAM při spuštění. I v případě, že pro virtuální počítač byl nakonfigurovaná dynamická paměť, bude využívat jenom takové množství paměti, které je nakonfigurované v nastavení paměti RAM při spuštění. Zkontrolujte, jestli hodnota paměti RAM při spuštění splňuje požadavky na minimální velikost paměti operačního systému během procesu instalace nebo upgradu.

  • Hostovaný operační systém běžící ve virtuálním počítači musí podporovat dynamickou paměť.

  • Složité databázové aplikace jako SQL Server nebo Exchange Server implementují své vlastní nástroje pro správu paměti. Podle dokumentace daného zatížení určete, jestli je zatížení kompatibilní s dynamickou pamětí.

Další informace:

Přehled dynamické paměti

Úloha 1c: Definování procesorů

Při konfiguraci virtuálních počítačů je třeba stanovit následující konfigurační parametry:

  • Určit počet procesorů potřebný pro každý virtuální počítač. Často se bude rovnat počtu procesorů vyžadovaných zatížením. Technologie Hyper-V podporuje maximálně 64 virtuálních procesorů na virtuální počítač.

  • Určit způsob řízení prostředků pro každý virtuální počítač. Dají se nastavit limity, které zajistí, aby si žádný virtuální počítač nemohl monopolizovat všechny procesorové prostředky hostitele virtualizace.

  • Definovat topologii NUMA. Pro vysoce výkonná zatížení s podporou architektury NUMA můžete zadat maximální počet procesorů, povolenou velikost paměti na jednom virtuálním uzlu NUMA a maximální počet uzlů povolených na jednom soketu procesoru. Další informace najdete v tématu Přehled virtuální architektury NUMA v Hyper-V.

Poznámka: Virtuální architektura NUMA a dynamická paměť se nedají používat zároveň. Pokud se rozhodujete, jestli používat dynamickou paměť, nebo architekturu NUMA, odpovězte si na následující otázky. Pokud na obě otázky odpovíte kladně, zapněte virtuální architekturu NUMA, ale ne dynamickou paměť.

  1. Používá zatížení běžící na virtuálním počítači architekturu NUMA?

  2. Bude virtuální počítač využívat víc prostředků, procesorů nebo paměti, než je k dispozici v jednom fyzickém uzlu NUMA?

Úloha 1d: Definování podporovaných operačních systémů

Je nutné, abyste se ujistili, že operační systém vyžadovaný daným zatížením se podporuje jako hostovaný operační systém. Vezměte v úvahu tyto informace:

Poznámka: Hyper-V obsahuje softwarový balík pro podporované hostované operační systémy, který zlepšuje výkon a integraci mezi fyzickým počítačem a virtuálním počítačem. Tato kolekce služeb a softwarových ovladačů se označuje jako integrační služby. Pro maximální výkon by na virtuálních počítačích měly běžet nejnovější integrační služby.

Správa licencí

Je nutné zajistit, aby hostované operační systémy byly řádně licencované. Nahlédněte prosím do dokumentace dodavatele, jestli neuvádí nějaké specifické licenční požadavky při provozování virtualizovaného prostředí.

Automatická aktivace virtuálního počítače (AVMA) je funkce, která byla zavedená ve Windows Serveru 2012 R2. AVMA váže aktivaci virtuálního počítače na licencovaný virtualizační server a aktivuje virtuální počítač po jeho spuštění. Tím se eliminuje potřeba zadávat licenční informace a aktivovat jednotlivě každý virtuální počítač.

AVMA vyžaduje, aby na hostiteli běžel Windows Server 2012 R2 Datacenter a aby hostovaným operačním systémem virtuálního počítače byl Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard nebo Windows Server 2012 R2 Essentials.

Poznámka: AVMA musíte nakonfigurovat na každém hostiteli nasazeném v prostředcích architektury virtualizace.

Další informace:

Automatická aktivace virtuálního počítače

Úloha 1e: Definování zásad vytváření názvů virtuálních počítačů

Vaše stávající strategie vytváření názvů počítačů možná vychází z toho, kde se počítač nebo server fyzicky nachází. Virtuální počítače se můžou přesouvat mezi hostiteli, dokonce i mezi různými datovými centry, takže taková strategie už nebude použitelná. Aktualizace existujících zásad tak, aby indikovaly, že počítač běží jako virtuální, může usnadnit dohledání, kde virtuální počítač běží.

Úloha 2: Definování síťové konfigurace

Každý virtuální počítač bude přijímat nebo odesílat různé druhy síťových přenosů. Každý typ síťového přenosu bude mít odlišné požadavky na výkon, dostupnost a zabezpečení.

Virtuální počítače 1. generace můžou mít nejvýše 12 síťových adaptérů – 4 síťové adaptéry starší verze a 8 virtuálních síťových adaptérů. Virtuální počítače 2. generace nepodporují síťové adaptéry starší verze, takže maximální podporovaný počet adaptérů je 8.

Úloha 2a: Určení typů síťových přenosů

Každý virtuální počítač bude odesílat a přijímat odlišné typy dat, jako například:

  • Data aplikací

  • Zálohování dat

  • Komunikace s klientskými počítači, servery nebo službami

  • Komunikace v rámci clusteru, pokud je zatížení součástí clusteru s podporou převzetí služeb při selhání pro hostované virtuální počítače

  • Podpora

  • Úložiště

Pokud už máte sítě, které jsou vyhrazené pro různé typy síťových přenosů, můžete se je rozhodnout použít pro tuto úlohu. Pokud sítě koncipujete nově, aby podporovaly prostředky architektury virtualizace, můžete u každého virtuálního počítače definovat, které typy síťových přenosů bude podporovat.

Úloha 2b: Definování možností výkonu síťových přenosů

Každý typ síťového přenosu má požadavky na maximální šířku pásma a minimální latenci. Následující tabulka uvádí strategie, jak vyhovět různým nárokům na síťový výkon.

Strategie

Výhody

Nevýhody

Oddělení typů přenosů na různé fyzické síťové adaptéry

Odděluje přenosy, aby se nemusely dělit s jinými typy přenosů.

  • Na hostiteli musí být nainstalované samostatné fyzické síťové adaptéry pro jednotlivé typy síťových přenosů.

  • Vyžaduje se dodatečný hardware pro každou síť, u které se vyžaduje vysoká dostupnost.

  • Neumožňuje snadné škálování při vysokém počtu sítí.

Správa šířky pásma Hyper-V (Hyper-V QoS)

  • Poskytuje QoS pro přenosy virtuální sítě.

  • Umožňuje vynucovat minimální a maximální šířku pásma pro tok přenosů, který je určený podle čísla portu virtuálního přepínače Hyper-V.

  • Umožňuje nakonfigurovat minimální a maximální šířka pásma na port virtuálního přepínače Hyper-V buď pomocí rutin PowerShellu, nebo přes rozhraní WMI (Windows Management Instrumentation).

  • Umožňuje nakonfigurovat víc virtuálních síťových adaptérů v Hyper-V a jednotlivě zadat QoS na každém virtuálním síťovém adaptéru.

  • Poskytuje dodatek k zásadám QoS pro fyzickou síť.

  • QoS pro software a QoS pro hardware by se nemělo používat současně na stejném síťovém adaptéru.

  • Je nutné si správně naplánovat zásady QoS pro síť a Hyper-V, aby se vzájemně nepřepisovaly.

  • Když u virtuálního přepínače nastavíte režim pro kvalitu služby, nepůjde ho změnit.

  • Virtuální počítače nemůžete migrovat na hostitele s virtuálním přepínačem, který je nastavený na použití jiného režimu QoS.

  • Migrace se zablokuje, pokud nepůjde dodržet absolutní hodnoty nakonfigurované pro virtuální počítač.

SR-IOV

  • Poskytuje nejnižší latenci sítě pro virtuální počítač

  • Poskytuje nejvyšší úroveň vstupně-výstupních operací pro virtuální počítač

  • Snižuje nároky na procesory ze strany virtuálních sítí.

  • Potřebujete síťový adaptér a ovladač s podporu SR-IOV na hostiteli a na každém virtuálním počítači, který bude mít virtuální funkci přiřazenou.

  • Virtuální síťové adaptéry s podporu SR-IOV nemůžou být součástí týmu síťových adaptérů na hostiteli.

  • Pro vysokou dostupnost sítě je třeba na hostiteli nainstalovat nejmíň dva síťové adaptéry SR-IOV a na virtuálním počítači je nutné nakonfigurovat seskupování síťových adaptérů.

  • SR-IOV by měly využívat jenom důvěryhodná zatížení, protože přenosy obcházejí přepínač Hyper-V a mají přímý přístup k fyzickému síťovému adaptéru.

  • V případě konfigurace seznamů řízení přístupu u portů virtuálního přepínače nebo funkcí QoS technologie Hyper-V, RouterGuard a DHCPGuard nebude možné SR-IOV používat.

  • SR-IOV se nepodporuje u virtuálních počítačů spuštěných v Azure.

Virtuální škálování na straně příjmu

  • Podporuje virtuální škálování na straně příjmu, které virtuálním počítačům umožňuje distribuci zátěže síťového zpracování mezi více virtuálních procesorů (vCPU), aby se zvýšila propustnost sítě v rámci virtuálních počítačů.

  • Poskytuje kompatibilitu s těmito funkcemi:

    • Seskupování síťových adaptérů

    • Migrace za provozu

    • NVGRE

  • Virtuální škálování na straně příjmu vyžaduje fyzický síťový adaptér pro podporu Fronty pro virtuální počítače (VMQ) a musí být povolené na hostiteli.

  • Není kompatibilní s virtuálním síťovým adaptérem s podporou SR-IOV.

  • Na virtuálních počítačích musí běžet Windows Server 2012 R2 nebo Windows 8.1.

  • Ve výchozím nastavení se vypne, pokud adaptér VMQ má nižší kapacitu než 10 Gb/s.

Rámce typu Jumbo

  • Umožňuje přenosy většího množství dat při každé ethernetové transakci, přičemž snižuje počet rámců, které je třeba přenášet.

  • Obvykle se používá ke komunikaci s úložištěm, ale dá se používat pro všechny typy komunikace.

  • Snižuje nároky na virtuální počítače, síťová zařízení a koncový server, na který se data odesílají.

  • Jsou nakonfigurované pro komunikaci v rámci datacentra, kde můžete řídit nastavení jednotek MTU (Maximum Transmission Unit) u všech segmentů směrování.

  • Poskytuje mírně nižší pravděpodobnost detekce chyb.

  • Rámce typu Jumbo musí podporovat každé síťové zařízení na cestě a musí na něm být nakonfigurované stejné nebo vyšší nastavení jednotek MTU. K ověření globálních nastavení jednotek MTU použijte příkaz Ping.

  • Pokud rámce typu Jumbo nepodporuje jeden segment směrování nebo pokud je na něm nakonfigurovaná nižší hodnota MTU, dojde ke ztrátě paketů.

Úloha 2c: Definování možností dostupnosti síťových přenosů

Seskupování síťových adaptérů, označované taky jako vyrovnání zatížení a převzetí služeb při selhání (LBFO), umožňuje seskupení více síťových adaptérů za účelem agregace šířky pásma a převzetí služeb při selhání při přenosech. Tím se zachová připojení při selhání některé síťové součásti. Seskupování síťových adaptérů je obvykle nakonfigurované na hostiteli, a když vytvoříte virtuální přepínač, naváže se na skupinu síťových adaptérů.

Režim seskupování síťových adaptérů určují nasazené síťové přepínače. Výchozí nastavení ve Windows Serveru 2012 R2 by mělo být dostatečné pro většinu nasazení.

Poznámka: SR-IOV není kompatibilní se seskupováním síťových adaptérů. Další informace o SR-IOV viz Úloha 2b: Definování možností výkonu síťových přenosů.

Další informace:

Přehled seskupování síťových adaptérů

Úloha 2d: Definování možností zabezpečení síťových přenosů

Každý typ síťového přenosu může mít jiné požadavky na zabezpečení, například požadavky související s izolací a šifrováním. Následující tabulka vysvětluje strategie, jak vyhovět různým nárokům na zabezpečení.

Strategie

Výhody

Nevýhody

Oddělení na různé síťové adaptéry

Přenosy oddělené od jiných síťových přenosů

Nedá se jednoduše škálovat. Čím víc sítí máte, tím víc síťových adaptérů musíte nainstalovat a spravovat na hostiteli.

IPsec se snižováním zátěže úloh IPsec

  • Podporuje snižování zátěže úloh IPsec pro šifrování síťových přenosů do a z virtuálních počítačů pomocí Hyper-V.

  • Šifruje přenosy při jejich cestě po síti.

  • Nastavení je složité.

  • Řešení problémů může být obtížnější, protože nejde otevřít přenosy na hostitele a virtuální počítače a z nich.

  • Vyšší nároky na procesor, když fyzické síťové adaptéry na hostiteli nepodporují snižování zátěže úloh IPsec.

Označování příznaky VLAN

  • Už ho používá většina společností.

  • Kompatibilní se zásadami QoS

  • Podporuje privátní sítě VLAN.

  • Podporuje páteřní režim sítě VLAN pro virtuální počítače.

  • Snižuje počet fyzických adaptérů, které je třeba nainstalovat na hostiteli.

  • Omezuje se na 4094 sítí VLAN.

  • Přepínače, hostitelé a virtuální počítače vyžadují konfiguraci.

  • Nesprávné změny nastavení konfigurace sítě VLAN můžou vést k problémům specifickým pro server nebo celosystémovým síťovým potížím.

Virtualizace sítě Hyper-V

  • Nabízí flexibilní umísťování úloh, včetně izolace sítě a opakovaného používání IP adres bez sítí VLAN.

  • Umožňuje snazší přesuny zatížení do cloudu.

  • Podporuje migraci za chodu mezi podsítěmi, aniž by bylo třeba vkládat novou IP adresu na nový server.

  • Umožňuje víceklientská síťová řešení.

  • Zajišťuje zjednodušené navrhování sítě a lepší využití serverových a síťových prostředků. Nepružnost sítí VLAN společně se závislosti umístění virtuálních počítačů na infrastruktuře fyzické sítě má obvykle za následek předimenzování a nedostatečné využití.

  • Správa Virtualizace sítě Hyper-V vyžaduje System Center 2012 R2 – nástroj Virtual Machine Manager nebo řešení správy od jiného výrobce než Microsoftu.

  • Na bráně Virtualizace sítě Hyper-V musí být povolená komunikace mimo virtuální síť.

DHCPGuard

  • Brání virtuálními počítači v provádění nabídek DHCP přes virtuální síť.

  • Konfiguruje se pro jednotlivé virtuální síťové adaptéry.

  • Nebrání virtuálními počítači z přijetí adresy ze serveru DHCP.

V případě zapnutí má minimální dopad na výkon.

RouterGuard

  • Blokuje následující pakety:

    • ICMPv4 typ 5 (přesměrování zprávy)

    • ICMPv4 typ 9 (inzerování směrovače)

    • ICMPv6 typ 134 (inzerování směrovače)

    • ICMPv6 typ 137 (přesměrování zprávy)

  • Konfiguruje se pro jednotlivé virtuální síťové adaptéry.

V případě zapnutí má minimální dopad na výkon.

Rozhodnutí, jaké řešení použít – Můžete si stáhnout listy v Průvodci aspekty návrhu prostředků infrastruktury virtualizace a změnit ukázková data na listu konfigurací virtuálních počítačů tak, aby odrážela rozhodnutí, která jste udělali ve všech předchozích úlohách v tomto kroku. U následujících rozhodnutí, jaké řešení použít, odkazuje tento dokument na konkrétní listy v tomto průvodci, do kterých můžete zadat data.

Úloha 2e: Definování virtuálních síťových adaptérů

Potom co porozumíte typům přenosů vyžadovaným ze strany virtuálních počítačů a strategiím v oblasti výkonu, dostupnosti a zabezpečení v souvislosti s přenosy, můžete určit, kolik virtuálních síťových adaptérů bude každý virtuální počítač vyžadovat.

Virtuální síťový adaptér je připojený k virtuálnímu přepínači. Existují tři typy virtuálních přepínačů:

  • Externí virtuální přepínač

  • Interní virtuální přepínač

  • Privátní virtuální přepínač

Externí virtuální přepínač poskytuje virtuálnímu počítači přístup k fyzické síti prostřednictvím síťového adaptéru, který je přidružený k virtuálnímu přepínači, k němuž je připojený. Fyzický síťový adaptér na hostiteli může být přidružený jenom k jednomu externímu přepínači.

Virtuální počítače 1. generace můžou mít nejvýše 12 síťových adaptérů – 4 síťové adaptéry starší verze a 8 virtuálních síťových adaptérů. Virtuální počítače 2. generace nepodporují síťové adaptéry starší verze, takže maximální podporovaný počet adaptérů je 8. Pokud není virtuální síťový adaptér nakonfigurovaný v páteřním režimu, může mít přiřazené jedno ID sítě VLAN.

Pokud se chystáte přiřadit přenosy virtuálních počítačů k jiným sítím VLAN, musí být na hostiteli nainstalovaný síťový adaptér, který podporuje sítě VLAN, a musí být přiřazený k virtuálnímu přepínači. Pro virtuální počítač můžete v jeho vlastnostech nastavit ID sítě VLAN. ID sítě VLAN, který je nastavené na virtuálním přepínači, představuje údaj, který se přiřadí virtuálnímu síťovému adaptéru přiřazenému k hostovanému operačnímu systému.

Poznámka: Pokud máte virtuální počítač, který vyžaduje přístup k více sítím, než odpovídá počtu dostupných adaptérů, můžete u síťového adaptéru virtuálních počítačů povolit režim VLAN Trunk pomocí rutiny Set-VMNetworkAdapterVlan ve Windows PowerShellu.

Úloha 2f: Definování strategie IP adres

Je nutné určit, jak budete virtuálním počítačům přiřazovat IP adresy. Pokud to neuděláte, může docházet ke konfliktům IP adres, což může mít negativní dopad na jiné virtuální počítače a fyzická zařízení v síti.

Kromě toho můžou neoprávněné servery DHCP způsobit zmatek v síťové infrastruktuře a může být obzvláště složité je vysledovat, když server běží jako virtuální počítač. Síť si můžete před neoprávněnými servery DHCP běžícími na virtuálním počítači chránit povolením DHCPGuardu v nastavení vašich virtuálních počítačů. DHCPGuard poskytuje ochranu před škodlivým virtuálním počítačem, který se prezentuje jako server DHCP s cílem podniknout útoky třetí osobou (man-in-the-middle).

Další informace:

Přehled protokolu DHCP (Dynamic Host Configuration Protocol)

DHCPGuard

Přehled správy IP adres (IPAM)

Úloha 3: Definování konfigurace úložiště

Při určování konfigurace úložiště je třeba definovat typy dat, které budou virtuální počítače ukládat, a typ úložiště, který potřebují.

Úloha 3a: Definování typů dat

Následující tabulka uvádí typy dat, které by virtuální počítač mohl potřebovat ukládat, a kam se daný typ dat často ukládá.

Typ dat

Umístění úložiště pro typ dat

Soubory operačního systému

V souboru virtuálního pevného disku, který uchovává hostitel virtualizace. Aspekty volby úložiště pro hostitele virtualizace se podrobněji probírají v části Krok 4: Plánování hostitelů virtualizace serverů dál v tomto dokumentu.

Stránkovací soubor Windows

Často se ukládá do stejného umístění jako soubory operačního systému.

Soubory aplikačních programů

Často se ukládá do stejného umístění jako soubory operačního systému.

Konfigurační data aplikací

Často se ukládá do stejného umístění jako soubory operačního systému.

Data aplikací

Často se ukládají odděleně od souborů aplikací a operačního systému. Pokud se například jedná o databázovou aplikaci, databázové soubory jsou často uložené ve vysoce dostupném, efektivním a síťovém řešení úložiště, které je oddělené od umístění, kde jsou uložené soubory operačního systému nebo aplikačních programů.

Sdílené svazky clusteru (CSV) a disk s kopií clusteru (požadováno pro clustering hostovaných virtuálních počítačů)

Často se ukládají odděleně od souborů aplikací a operačního systému.

  • Úložiště CSV je tam, kam ukládají data aplikace clusteru, takže je dostupné pro všechny uzly v clusteru.

  • Disk s kopií clusteru je disk v úložišti clusteru obsahující kopii databáze konfigurace clusteru. Cluster s podporou převzetí služeb při selhání obsahuje disk s kopií clusteru pouze v případě, že je to určeno v rámci konfigurace kvora.

Soubory s výpisem stavu systému

Často se ukládá do stejného umístění jako soubory operačního systému.

Úloha 3b: Definování typů úložišť

Následující tabulka uvádí typy úložišť, které se dají použít pro typy dat definované v Kroku 2, Úloze 2a výše.

Typ úložiště

Požadavky

Virtuální disk IDE

Virtuální počítače 1. generace:

  • 2 řadiče IDE, přičemž každý řadič může podporovat maximálně 2 zařízení IDE pro maximálně 4 zařízení IDE.

  • Spouštěcí disk, někdy taky označovaný jako spouštěcí disketa, musí být připojený k jednomu z těchto zařízení IDE jako virtuální pevný disk nebo fyzický disk.

Virtuální počítače 2. generace nepodporují zařízení IDE.

Virtuální SCSI

  • U každého řadiče se podporují 4 virtuální řadiče SCSI, které podporují až 64 zařízení, takže celkový počet je 256 zařízení SCSI.

  • Vzhledem k tomu, že virtuální počítače 2. generace podporují jenom jednotku SCSI, podporují spouštěcí disky SCSI.

Iniciátor iSCSI na virtuálním počítači

  • Můžete využívat výhod úložiště pro sítě SAN bez instalace adaptérů Fibre Channel na hostiteli.

  • Nejde použít pro spouštěcí disk.

  • K zajištění dostupnosti správné šířky pásma pro úložiště a další síťové přenosy můžete použít zásady QoS.

  • Není kompatibilní s Replikou technologie Hyper-V. V případě používání back-endu úložiště sítě SAN použijte možnosti replikace sítě SAN poskytované dodavatelem úložiště.

Virtuální technologie Fibre Channel

  • Vyžaduje jeden nebo více hostitelských adaptérů Fibre Channel (HBA) nebo konvergované síťové adaptéry Fibre Channel over Ethernet (FCoE) na každém hostiteli virtuálních počítačů s virtuálními adaptéry Fibre Channel.

  • Ovladače HBA a FCoE musí podporovat virtuální Fibre Channel.

  • Síť SAN s podporou přenosů NPIV

  • Vyžaduje další konfiguraci pro podporu migrace za chodu. Další informace o migraci za chodu a virtuálním Fibre Channel viz Technologie Hyper-V Virtual Fibre Channel – přehled.

  • Není kompatibilní s Replikou technologie Hyper-V. V případě používání úložiště sítě SAN byste měli použít možnosti replikace sítě SAN poskytované dodavatelem úložiště.

  • Virtuální počítač může mít až čtyři virtuální porty.

  • Virtuální logické jednotky (LUN) Fibre Channel nejde použít jako spouštěcí médium pro virtuální počítač.

SMB 3.0

Umožňuje přístup k souborům uloženým ve sdílených složkách SMB (Server Message Block) 3.0 přímo z virtuálního počítače.

Úloha 3c: Definování formátu a typu virtuálního pevného disku

Pokud používáte typ úložiště založený na virtuálním pevném disku (VHD), musíte nejprve z možností uvedených v následující tabulce vybrat požadovaný formát VHD.

Formát disku

Výhody

Nevýhody

VHD

  • Podporováno všemi verzemi technologie Hyper-V

  • Podporováno místními implementacemi i službou Azure

  • Maximální kapacita úložiště je 2040 GB.

  • Maximální virtuální pevný disk podporovaný službou Azure je 1 TB.

  • Nepodporováno virtuálními počítači 2. generace

VHDX

  • Maximální kapacita úložiště je 64 terabajtů (TB).

  • Ochrana proti poškození dat během výpadku proudu

  • Vylepšené seřazení u formátu virtuálního pevného disku, aby mohl dobře fungovat na discích s velkými sektory

  • Virtuální disk s 4kB logickými sektory, který umožňuje vyšší výkon při používání ze strany aplikací a zatížení, které jsou navržené pro 4kB sektory

  • Dá se používat jako sdílené úložiště pro virtuální počítače, které vyžadují clustering s podporou převzetí služeb při selhání.

  • Aktuálně nepodporováno virtuálními počítači v Azure

  • Nejde používat s verzemi technologie Hyper-V před Windows Serverem 2012

Sdílené VHDX

Používá se pro sdílené úložiště pro clustery hostovaných virtuálních počítačů.

  • Vyžaduje Windows Server 2012 R2 na hostiteli, na kterém běží Hyper-V.

  • Mezi podporované hostované operační systémy pro hostované clustery, které používají sdílený virtuální pevný disk, patří Windows Server 2012 R2 a Windows Server 2012. Aby byl jako hostovaný operační systém podporovaný Windows Server 2012, musí být na hostovi (virtuálním počítači) nainstalované integrační služby Windows Serveru 2012 R2.

  • Následující funkce nejsou kompatibilní se sdíleným VHDX:

    • Replika technologie Hyper-V

    • Změna velikosti virtuálního pevného disku při běhu kteréhokoli z nakonfigurovaných virtuálních počítačů

    • Migrace úložiště za chodu

    • Zálohování VSS na úrovni hostitele. Zálohování na úrovni hosta by se mělo provádět pomocí stejných metod, které byste použili pro cluster běžící na fyzických serverech.

    • Kontrolní body virtuálních počítačů

    • QoS úložiště

Potom z možností uvedených v následující tabulce vyberte požadovaný typ disku.

Typ disku

Výhody

Nevýhody

Pevný

  • Menší pravděpodobnost nežádoucí fragmentace než u jiných typů disku

  • Nižší nároky na procesory než u jiných typů disku

  • Po vytvoření souboru virtuálního pevného disku se není třeba tolik starat o volné místo jako u jiných typů disku.

  • Podporováno místními implementacemi i službou Azure

  • Vytvořený virtuální pevný disk vyžaduje, aby byl k dispozici celý odpovídající prostor, a to i v případě, že ho virtuální počítač plně nevyužívá.

  • Pokud není dostatek místa k dispozici, virtuální pevný disk se nevytvoří.

  • Nevyužité místo na virtuálním pevném disku nejde přidělit jiným virtuálním pevným diskům.

Dynamický

Využívá jenom tolik místa na disku, kolik je potřeba – ne celé zřízené místo.

  • Aktuálně se nepodporuje v Azure, ačkoli dynamické disky se dají převádět na pevné disky.

  • Při používání dynamických virtuálních pevných disků je důležité monitorovat volné místo na disku. Pokud není k dispozici místo na disku pro rozšíření dynamického virtuálního pevného disku, virtuální počítač přejde do stavu „pozastaveno, kritické“.

  • Soubor virtuálního pevného disku se může fragmentovat.

  • Oproti pevnému typu disku se mírně zvýší nároky na procesor při operacích čtení a zápisu.

Rozdílový

Může využívat míň místa na disku, pokud stejnou nadřazenou položku používá víc rozdílových disků.

  • Aktuálně se nepodporuje v Azure.

  • Změny provedené na nadřazeném disku můžou způsobovat datové nekonzistence na podřízeném disku.

  • U vysokých zatížení s intenzivním vstupně-výstupním provozem se mírně zvýší nároky na procesor při operacích čtení a zápisu.

Při výběru typu a formátu souboru virtuálního pevného disku zvažte následující:

  • Pokud používáte formát VHDX, dá se použít dynamický disk, protože kromě úspory místa (díky tomu, že se přiděluje jenom v případě nutnosti) nabízí i zaručenou odolnost.

  • Pevný disk se dá taky použít, a to bez ohledu na formát, když se aktivně nemonitoruje úložiště na hostitelském svazku. Tím se zajistí, že bude k dispozici dostatek místa na disku, když se za běhu rozbalí soubor virtuálního pevného disku.

  • Kontrolní body (dříve označované jako snímky) virtuálního počítače vytvoří rozdílový virtuální pevný disk, kam se budou ukládat zápisy na disky. Nastavení jen několika kontrolních bodů může zvýšit nároky na procesor při vstupně-výstupních operacích úložiště, což ale nemusí mít zaznamenatelný dopad na výkon (s výjimkou vysokých serverových zatížení s intenzivním vstupně-výstupním provozem).

    Ovšem nastavení dlouhého řetězce kontrolních bodů může výkon ovlivnit výrazně, protože čtení z virtuálních pevných disků může vyžadovat kontrolu požadovaných bloků v mnoha rozdílových discích. Pro zachování dobrého vstupně-výstupního výkonu disků je důležité udržet řetězce kontrolních bodů krátké.

Úloha 3d: Definování typů úložiště, které se mají používat s jednotlivými datovými typy

Potom co definujete datové typy, které budou virtuální počítače ukládat, a typy úložiště, můžete určit, jaký typ úložiště a jaký formát a typ virtuálního disku budete používat pro jednotlivé datové typy.

Úloha 4: Definování strategie dostupnosti virtuálních počítačů

I když za dostupnost prostředků infrastruktury zodpovídají správci této platformy, konečnou zodpovědnost za dostupnost konkrétních virtuálních počítačů mají jejich správci. Správce virtuálních počítačů by proto při navrhování odpovídající strategie dostupnosti pro své virtuální počítače měl dobře rozumět možnostem prostředků infrastruktury.

V následujících tabulkách se analyzují tři strategie dostupnosti pro virtuální počítače, na kterých poběží zatížení s charakteristikami, které jsou definované výše v kroku 1, úloze 2. Obvykle správce prostředků infrastruktury informuje správce virtuálních počítačů o plánovaných odstávkách prostředků infrastruktury předem, aby ti mohli odpovídajícím způsobem přizpůsobit své plány. Tady jsou zmíněné tři strategie dostupnosti:

  • Bezstavové

  • Stavové

  • Se sdílením stavu

Bezstavové

Možnost

Požadavky

Migrace virtuálních počítačů za chodu na úrovni hostitele

  • Pokud je třeba odstavit některého hostitele kvůli plánované údržbě, běžící virtuální počítače se dají migrovat na provozuschopného hostitele, aniž by na virtuálních počítačích došlo k výpadkům. Další informace o aspektech souvisejících s hostiteli najdete níže v části Úloha 5: Definování strategie pro dostupnost hostitelů virtualizačních serverů.

  • Pokud virtuální počítače nejsou uložené v úložišti, která je přístupné pro oba hostitele, je třeba během migrace za chodu přesunout úložiště virtuálních počítačů.

  • Pokud hostitel neočekávaně selže, všechny na něm běžící virtuální počítače se zastaví. Virtuální počítače musíte rozběhnout spuštěním stejného zatížení na jiném hostiteli.

Clustery s vyrovnáváním zatížení (pomocí služby Vyrovnávání zatížení sítě ve Windows)

  • Vyžaduje, aby správce virtuálních počítačů měl minimálně dva virtuální počítače, na kterých běží stejné zatížení, s různými hostiteli.

  • Službu Vyrovnávání zatížení sítě (NLB) nakonfiguruje správce virtuálních počítačů přímo na nich.

  • Tato služba vyžaduje, aby síťovým adaptérům byly přiřazené statické IP adresy. Přiřazování adres DHCP se nepodporuje.

  • Správce virtuálních počítačů musí při získávání virtuálních IP adres, které se mají používat pro virtuální IP adresu služby Vyrovnávání zatížení sítě, a při vytváření požadované položky DNS spolupracovat se správcem prostředků infrastruktury.

  • Povolte falšování adres MAC pro virtuální síť, kterou služba Vyrovnávání zatížení sítě používá u hostů. To se dá udělat z nastavení síťového adaptéru na každém virtuálním počítači, který je účastníkem clusteru služby Vyrovnávání zatížení sítě jako uzel. Můžete vytvářet clustery NLB, přidávat uzly a aktualizovat konfigurace zmíněných clusterů bez restartování virtuálních počítačů.

  • Všechny virtuální počítače, které jsou účastníky clusteru NLB, musí být ve stejné podsíti.

  • Aby se zajistila dostupnost zatížení (i v případě selhání hostitele), musí správce prostředků infrastruktury virtuálního počítače zajistit, aby virtuální počítače běžely na různých hostitelích.

Clustery s vyrovnáváním zatížení (pomocí hardwarového zařízení)

  • Tuto možnost je třeba zajistit na úrovni prostředků infrastruktury a právě správci těchto prostředků musí nakonfigurovat clustery s vyrovnáváním zatížení pro virtuální počítače, které je vyžadují. Nebo můžou správcům virtuálních počítačů umožnit, aby si je nakonfigurovali prostřednictvím portálu pro správu hardwarového zařízení pro vyrovnávání zatížení.

  • Vyžaduje, aby správce virtuálních počítačů měl minimálně dva virtuální počítače, na kterých běží stejné zatížení a jejichž hostitelem jsou prostředky infrastruktury.

  • Další informace najdete v produktové dokumentaci od dodavatele hardwaru.

Stavové

Možnost

Požadavky

Cluster Hyper-V

  • Vyžaduje konfiguraci clusteru s podporou převzetí služeb při selhání.

  • Vyžaduje úložiště pro soubory CSV sdílené mezi všemi uzly v clusteru. Může to být úložiště SAN nebo sdílená složka SMB 3.0.

  • Když cluster zjistí problém s hostitelem nebo Hyper-V zjistí problém se sítěmi nebo úložištěm virtuálních počítačů, může se virtuální počítač přesunout na jiného hostitele. Virtuální počítač během přesunu dál poběží.

  • Pokud dojde ke katastrofickému selhání hostitele, můžou se virtuální počítače, které na něm běžely, spustit na jiných uzlech v clusteru. Kritické virtuální počítače může být nakonfigurované na automatické spouštění. Tím se v případě katastrofického selhání hostitele omezí doba výpadku.

  • Hostitele je možné opravovat, aniž by to mělo vliv na běžící virtuální počítače, díky Aktualizacím pro clustery.

  • Můžete nakonfigurovat nastavení bránící spřažení virtuálních počítačů, aby neběžely na stejném uzlu. Pokud například používáte dva webové servery, které poskytují front-endové služby pro back-endovou aplikaci, nebudete chtít, aby oba běžely na stejném uzlu.

  • Uzel je možné převést do režimu údržby a služba clusteru s podporou převzetí služeb při selhání přesune běžící virtuální počítače do jiného uzlu v clusteru. Pokud na uzlu nejsou žádné běžící virtuální počítače, může požadovaná údržba proběhnout.

    Cluster s podporou převzetí služeb při selhání nepřesune virtuální počítače na uzel v režimu údržby. Před přepnutím uzlu do režimu údržby se ujistěte, že na ostatních uzlech v clusteru Hyper-V je dostatečná kapacita pro provozování existujících virtuálních počítačů při udržení rozsahu smluv SLA pro vaše zákazníky.

Se sdílením stavu

Při provozování zatížení, která podporují rozdělení v clusteru, můžete poskytnout dodatečnou vrstvu dostupnosti povolením hostovaného clusteringu virtuálních počítačů. Hostovaný clustering podporuje vysokou dostupnost pro zatížení v rámci virtuálního počítače. Hostovaný clustering poskytuje ochranu pro zatížení, které běží na virtuálních počítačích, i v případě, že hostitel selže tam, kde běží příslušný virtuální počítač. Protože je zatížení chráněné clusteringem s podporou převzetí služeb při selhání, činnost může automaticky převzít virtuální počítač na druhém uzlu

Možnost

Požadavky

Hostovaný clustering virtuálních počítačů

  • Vyžaduje sdílené úložiště, které je současně přístupné pro nejmíň dva virtuální počítače. Mezi podporované typy připojení patří:

    • iSCSI

    • Virtuální technologie Fibre Channel

    • Sdílené VHDX

  • Můžete nakonfigurovat nastavení bránící spřažení virtuálních počítačů, aby oba neběžely na stejném uzlu clusteru.

  • Hostovaný clustering virtuálních počítačů se nepodporuje v Azure.

  • Následující funkce nejsou kompatibilní se sdíleným VHDX:

    • Replika technologie Hyper-V

    • Změna velikosti virtuálního pevného disku při běhu kteréhokoli z nakonfigurovaných virtuálních počítačů

    • Migrace úložiště za chodu

    • Zálohování VSS na úrovni hostitele. Zálohování na úrovni hosta by se mělo provádět pomocí stejných metod, které byste použili pro cluster běžící na fyzických serverech.

    • Kontrolní body virtuálních počítačů

    • QoS úložiště

Další informace:

Nasazení hostovaného clusteru pomocí sdíleného virtuálního pevného disku

Používání hostovaného clusteringu pro vysokou dostupnost

Zotavení po havárii

Pokud dojde k havárii, jak rychle dokážete znova zprovoznit požadovaná zatížení, aby opět poskytovala služby klientům? V některých případech může být vyhrazený čas jenom několik minut.

Aby se zajistilo, že se budou moct replikovat nejnovější data s přijatelnou mírou ztrát z důvodu zpoždění, vyžaduje se replikace dat z vašich hlavních datových center do center zajišťujících zotavení po havárii. Při provozování zatížení na virtuálních počítačích můžete replikovat virtuální pevné disky a konfigurační soubory virtuálních počítačů z primárního webu na web představující repliku.

V následující tabulce se porovnávají možnosti zotavení po havárii.

Možnost

Požadavky

Replika technologie Hyper-V

  • Cenově nenáročné a bez nutnosti duplikovat hostitelský a úložný hardware na webech zajišťujících zotavení po havárii

  • Pro správu replikace se používají stejné nástroje jako ke správě virtuálních počítačů.

  • Konfigurovatelné intervaly replikace k nastavení konkrétních požadavků v oblasti datových ztrát

  • Možnost nakonfigurovat jiné IP adresy, které se budou používat na webu repliky

  • Minimální dopad na síťovou infrastrukturu

  • Nepodporuje se pro virtuální počítače nakonfigurované s fyzickými disky (taky označovanými jako průchozí disky), virtuálním úložištěm Fibre Channel nebo sdílenými virtuálními pevnými disky.

  • Replika technologie Hyper-V by se neměla používat jako náhrada za úložiště pro zálohování a načítání dat.

  • Pokud jsou nakonfigurované další body obnovení, bude se na webu představujícím repliku vyžadovat další úložiště.

  • Míra intervalu replikace určuje rozsah datových ztrát.

  • Pokud je nakonfigurovaný virtuální počítač s velkým množstvím změn a krátkým intervalem replikace, vyžaduje se na webu představujícím repliku další úložiště

Zálohování

  • Kompletní virtuální počítač můžete zálohovat pomocí řešení zálohování, které podporuje technologii Hyper-V, jako je System Center Data Protection Manager.

  • Datové ztráty budou záviset na stáří poslední zálohy.

  • Virtuální počítače nakonfigurované se sdíleným souborem VHDX nejde zálohovat na úrovni hostitele. Nainstalujte na virtuální počítač agenta zálohování a zálohujte data přímo z virtuálního počítače.

Poznámky:

  • Pokud chcete při používání nástroje System Center 2012 R2 – Virtual Machine Manager centrálně spravovat a automatizovat replikaci, je třeba použít Microsoft Azure Site Recovery.

  • Replikace virtuálních počítačů do Azure pomocí Microsoft Azure Site Recovery: Replikace virtuálního počítače do Azure je aktuálně v režimu Preview.

Další informace:

Microsoft Azure Site Recovery

Důležité:

  • Pomocí nástroje Hyper-V Replica Capacity Planner můžete porozumět dopadu, který bude mít Replika technologie Hyper-V na síťovou infrastrukturu; na využití procesorů na primárních serverech, serverech replik a serverech rozšířených replik; na využití paměti na primárních serverech a serverech replik; a na vstupně-výstupní diskové operace za sekundu na primárních serverech, serverech replik a serverech rozšířených replik, které jsou založené na vašich stávajících virtuálních počítačích.

  • Vaše zatížení může mít vestavěné řešení pro zotavení po havárii, jako jsou Skupiny dostupnosti AlwaysOn na SQL Serveru. V dokumentaci zatížení si ověřte, jestli podporuje Repliku technologie Hyper-V.

Další informace:

Replika technologie Hyper-V

System Center Data Protection Manager

Úloha 5: Definování typů virtuálních počítačů

Můžete vytvořit virtuální počítače s jedinečnými nároky na prostředky, abyste naplnili potřeby jednotlivých zatížení a zajistili pro ně podporu. Alternativně můžete podobný postup použít u veřejných poskytovatelů hostitelských služeb virtuálních počítačů (což se označuje taky jako infrastruktura jako služba (IaaS)).

V tématu Velikost služeb pro virtuální počítače a cloud pro Azure najdete popis konfigurací virtuálních počítačů, které nabízí infrastrukturní služby Microsoft Azure. V době vzniku tohoto textu podporovala tato služba 13 konfigurací virtuálních počítačů, přičemž každá nabízela jinou kombinaci parametrů pro procesory, paměť, úložiště a vstupně-výstupní operace.

Rozhodnutí, jaké řešení použít – Rozhodnutí, která učiníte v jednotlivých úlohách tohoto kroku, si můžete zaznamenat do listů konfigurací virtuálních počítačů.

Krok 3: Plánování skupin hostitelů virtualizace serverů

Před definováním jednotlivých serverových hostitelů můžete být vhodné nejprve definovat skupiny hostitelů. Skupiny hostitelů představují, jednoduše řečeno, pojmenovanou kolekci serverů, které jsou seskupené s cílem zajistit plnění společných cílů. Ty popisujeme v následujících úlohách tohoto kroku.

Úloha 1: Definování fyzických umístění

Hardwarové prostředky budete pravděpodobně seskupovat a spravovat podle fyzického umístění, takže bude vhodné nejdříve definovat umístění ve vaší organizaci, která budou zahrnovat prostředky architektury.

Úloha 2: Definování typů skupin hostitelů

Skupiny hostitelů můžete vytvořit z nejrůznějších důvodů, například k hostování zatížení s určitými:

  • Charakteristikami zatížení

  • Požadavky na prostředky

  • Požadavky na kvalitu služeb

Následující obrázek znázorňuje organizaci, která si vytvořila pět skupin hostitelů na dvou místech.

Skupina hostitelů

Obrázek 2:Příklad skupiny hostitelů

Organizace si tyto skupiny hostitelů vytvořila z důvodů uvedených v následující tabulce.

Skupina hostitelů

Důvody pro její vytvoření

Bezstavové a stavové zatížení

  • Tyto charakteristiky zatížení jsou v této organizaci nejobvyklejší, a proto má tento typ skupiny hostitelů v obou místech.

  • Tato zatížení mají podobné požadavky na výkon a úroveň služeb.

Stavová a bezstavová zatížení účetního oddělení

Přestože hardwarová konfigurace serverů v této skupině hostitelů je stejná jako jiné skupiny hostitelů bezstavových a stavových zatížení v prostředí této organizace, účetní oddělení má aplikace, které mají vyšší požadavky na zabezpečení než v případě jiných oddělení. Z tohoto důvodu si pro ně organizace vytvořila vyhrazenou skupinu hostitelů, kterou šlo zabezpečit jinak než ostatní skupiny hostitelů v prostředcích infrastruktury.

Zatížení se sdílením stavu

Zatížení hostovaná v této skupině hostitelů vyžadují sdílené úložiště, protože k udržování své dostupnosti využívají clustering s podporou převzetí služeb při selhání ve Windows Serveru. Hostitelem těchto zatížení je vyhrazená skupina hostitelů, protože konfigurace těchto virtuálních počítačů se liší od jiných virtuálních počítačů v této organizaci.

Stavová zatížení s vysokým vstupně-výstupním provozem

Všichni hostitelé v této skupině hostitelů jsou připojení k sítím s vyšší rychlostí než hostitelé v jiných skupinách hostitelů.

Přestože si organizace mohla skupiny hostitelů nastavit tak, aby pokrývaly obě místa, sestavila si je tak, aby všichni členové skupin spadali pod stejné místo, čímž si usnadnila jejich správu. Jak vidíte z tohoto příkladu, skupiny hostitelů je možné vytvářet z nejrůznějších důvodů a tyto důvody se budou mezi organizacemi lišit. Čím víc typů skupin hostitelů si v organizaci vytvoříte, tím složitější prostředí budete muset spravovat, což v konečném důsledku zvýší náklady na hostování virtuálních počítačů.

Tip: Čím standardizovanější je serverový hardware v rámci skupiny hostitelů, tím snazší bude škálování a údržba skupiny hostitelů v průběhu času. Pokud dospějete k názoru, že chcete v rámci skupiny hostitelů standardizovat hardware, můžete standardizovaná konfigurační data přidat do listu skupin hostitelů, který najdete v listech v Průvodci aspekty návrhu prostředků infrastruktury virtualizace. Další informace o aspektech týkajících se fyzického hardwaru najdete v části Krok 4: Plánování hostitelů virtualizace serverů.

Vezměte v úvahu, že v současné době pro většinu poskytovatelů veřejných cloudů, kteří jsou hostiteli virtuálních počítačů, platí následující:

  • Hostí jenom virtuální počítače, které nevyžadují sdílený stav.

  • Nabízejí často jenom jednu sadu metriky kvality služeb, kterou poskytují všem zákazníkům.

  • Nevyhrazují konkrétní hardware pro konkrétní zákazníky.

Doporučujeme, abyste začali s jedním typem skupin hostitelů, který bude obsahovat identický hardware, a další typy přidávali, jenom když z toho plynoucí výhody převáží nad souvisejícími náklady.

Úloha 3: Určení, jestli členy skupiny hostitelů umístit do clusteru

V minulosti se clustering s podporou převzetí služeb při selhání ve Windows Serveru používal jenom ke zvýšení dostupnosti serveru, ale od té doby se rozrostl a poskytuje výrazně víc funkcí. Informace v následující tabulce vám můžou usnadnit rozhodování, jestli bude vhodné členy skupiny hostitelů umístit do clusteru.

Možnost

Výhody

Nevýhody

Členové skupiny hostitelů jsou součástí clusteru převzetí služeb při selhání.

  • Pokud kterýkoli hostitel selže, virtuální počítače, které hostí, se automaticky restartují na zbývajících uzlech.

  • Virtuální počítače se dají přesunout do jiného uzlu v clusteru, pokud uzel, na kterém aktuálně běží, zjistí problém s uzlem nebo na virtuálním počítači.

  • Pomocí Aktualizací pro clustery můžete snadno aktualizovat uzly v clusteru bez dopadu na běžící virtuální počítače.

  • Hostitelé vyžadují specifickou konfiguraci, aby mohli být členy clusteru.

  • Hostitelé musí být členy domény služby Active Directory.

  • Clustering s podporou převzetí služeb při selhání s sebou nese další požadavky na sítě a úložiště.

Členové skupiny hostitelů nejsou součástí clusteru převzetí služeb při selhání.

  • Hostitelé nevyžadují specifickou konfiguraci clusteru.

  • Hostitelé nemusí být členy domény služby Active Directory.

  • Nevyžadují se další sítě a úložiště.

Virtuální počítače běžící na hostiteli, který selže, je třeba ručně (nebo můžete použít nějaký způsob automatizace) přesunout na dál fungujícího hostitele a restartovat.

Rozhodnutí, jaké řešení použít – Rozhodnutí, která učiníte v jednotlivých úlohách tohoto kroku, si můžete zaznamenat do listu nastavení.

Krok 4: Plánování hostitelů virtualizace serverů

V tomto kroku definujete potřebné typy hostitelů pro virtuální počítače, které plánujete provozovat ve svých prostředcích architektury virtualizace. Počet konfigurací hostitelů je vhodné omezit, v některých případech na jedinou, abyste snížili náklady na nákup a podporu. Kromě toho se při nákupu nesprávného vybavení zvýší náklady na nasazení.

Cloud Platform System

Microsoft přenáší své zkušenosti s provozováním datacenter a cloudových služeb, které patří mezi ty úplně největší, do konstrukčně integrovaného a plně prověřeného konvergovaného systému. Cloud Platform System (CPS) kombinuje osvědčené softwarové produkty Microsoftu, jako jsou Windows Server 2012 R2, System Center 2012 R2 a Windows Azure Pack, s cloudovými servery a úložným a síťovým hardwarem od společnosti Dell. CPS funguje jako škálovatelný stavební blok pro váš cloud, čímž zkracuje čas nutný na realizaci projektů a vytváří konzistentní cloudové prostředí.

CPS poskytuje samoobslužné, víceklientské cloudové prostředí pro virtuální počítače na bázi modelu Platforma jako služba nebo na bázi Windows a Linuxu a zahrnuje optimalizované balíčky pro nasazení aplikací Microsoftu, jako je SQL Server, SharePoint a Exchange. Konstrukční integrace snižuje rizika a složitost a zkracuje dobu nasazení z měsíců na dny. Zjednodušený proces podpory a automatizace rutinních infrastrukturních úloh navíc uvolňuje zdroje v oddělení IT. Tito pracovníci se tak můžou zaměřit na inovace.

Další informace najdete na webu Cloud Platform System.

Fast Track

Namísto toho, abyste si museli hardwarovou (a softwarovou) konfiguraci navrhovat sami, můžete si zakoupit předkonfigurované hardwarové konfigurace od různých partnerů, kteří nabízejí hardware, prostřednictvím programu Microsoft Private Cloud Fast Track.

Program Fast Track je výsledkem společného úsilí Microsoftu a jeho partnerů, kteří vyvíjejí hardware, poskytovat ověřená a předkonfigurovaná řešení, která snižují složitost a rizika spojená s implementací prostředků architektury virtualizace, jakož i nabídnout nástroje pro jejich správu.

Program Fast Track přináší zákazníkům flexibilitu při volbě řešení a možnost výběru mezi technologiemi od různých dodavatelů hardwaru. Využívá základní funkce operačního systému Windows Server, technologie Hyper-V a Microsoft System Centera, které nabízí jako stavební bloky pro privátní cloud na bázi modelu Infrastruktura jako služba (IaaS).

Další informace:

Web Microsoft Private Cloud Fast Track

Úloha 1: Definování výpočetní konfigurace

V této úloze určíte velikost paměti, počet procesorů a verzi Windows Serveru, které jsou požadované pro jednotlivé hostitele. Počet virtuálních počítačů, které poběží na hostiteli, se určí podle hardwarových součástí popsaných v této části.

Poznámka: Abyste měli jistotu, že je vaše řešení plně podporované, musí mít veškerý hardware, který si zakoupíte, logo „Certified for Windows Server“ pro vámi používanou verzi Windows Serveru.

Toto logo dokládá, že serverový systém splňuje nejvyšší technické parametry Microsoftu v oblasti zabezpečení, spolehlivosti a správy. V kombinaci s jinými certifikovanými zařízeními a ovladači může podporovat role, funkce a rozhraní pro cloudová a podniková zatížení a pro nepostradatelné firemní aplikace.

Nejnovější seznam hardwaru certifikovaného pro Windows Server najdete v Katalogu Windows Serveru.

Úloha 1a: Definování procesorů

Technologie Hyper-V prezentuje logické procesory jednotlivým aktivním virtuálním počítačům jako jeden nebo víc virtuálních procesorů. Běhovou efektivitu můžete dál zvýšit použitím procesorů, které podporují technologie pro překlad adres druhé úrovně (SLAT), jako jsou tabulky EPT (Extended Page Tables) nebo NPT (Nested Page Tables). Technologie Hyper-V ve Windows Serveru 2012 R2 podporuje maximálně 320 logických procesorů.

Co je třeba zvážit:

  • Zatížení, která nemají intenzivní nároky na procesor, by měla být nakonfigurovaná na používání jen jednoho virtuálního procesoru. Monitorujte využití procesoru hostitele v průběhu času, abyste měli jistotu, že máte procesory přidělené s maximální efektivitou.

  • Zatížením, která mají intenzivní nároky na procesor, by měly být přiřazené dva nebo víc virtuálních procesorů. Maximálně můžete virtuálnímu počítači přiřadit 64 virtuálních procesorů. Počet virtuálních procesorů rozpoznávaných virtuálním počítačem závisí na hostovaném operačním systému. Například Windows Server 2008 s aktualizací Service Pack 2 rozpoznává jenom čtyři virtuální procesory.

Další informace:

Přehled technologie Hyper-V

Ladění výkonu u Hyper-V Serverů

Úloha 1b: Definování paměti

Fyzický server vyžaduje dostatek paměti pro hostitele i běžící virtuální počítače. Hostitel vyžaduje paměť k efektivnímu provádění vstupně-výstupních operací jménem virtuálních počítačů a operací, jako je kontrolní bod virtuálního počítače. Technologie Hyper-V zajišťuje, aby byl k dispozici dostatek paměti pro hostitele, a umožňuje přiřazování zbývající paměti virtuálním počítačům. Virtuální počítače by měly mít velikost vycházející z očekávané zátěže u každého z nich.

Hypervisor virtualizuje hostovanou fyzickou paměť, aby virtuální počítače izoloval od sebe navzájem a poskytoval souvislý paměťový prostor s nulovým základem pro každý hostovaný operační systém, stejně jako v nevirtualizovaných systémech. Abyste měli jistotu, že dostanete maximální výkon, minimalizujte dopady virtualizace paměti na výkon pomocí hardwaru využívajícího technologii SLAT.

Velikost paměti virtuálního počítače stanovte stejně, jako to obvykle děláte u serverových aplikací na fyzickém počítači. Množství paměti přidělené virtuálnímu počítači by mu mělo umožňovat přiměřeně zvládat očekávanou zátěž v běžném provozu i ve špičce, protože nedostatečná paměť může významně prodloužit dobu odezvy, využití procesoru nebo objem vstupně-výstupních operací.

Paměť, která se přidělí virtuálnímu počítači, sníží množství paměti, která je k dispozici pro ostatní virtuální počítače. Pokud na hostiteli není k dispozici dost paměti, virtuální počítač se nespustí.

Dynamická paměť umožňuje dosažení vyšších konsolidačních hodnot s lepší spolehlivostí pro operace restartování. To může vést k nižším nákladům, zejména v prostředích, která mají mnoho nečinných nebo slabě zatížených virtuálních počítačů, jako jsou třeba sdružená prostředí VDI. Změny konfigurace dynamické paměti za běhu můžou snížit prostoje a zajistit pohotovější reakce na změny požadavků.

Další informace o dynamické paměti najdete v části Úloha 1b: Definování paměti, v níž se probírá, jak stanovit paměť pro virtuální počítač.

Další informace:

Přehled dynamické paměti

Přehled virtuální architektury NUMA

Úloha 1c: Definování edice operačního systému Windows Server

Sady funkcí v edicích Windows Server Standard a Windows Server Datacenter jsou úplně stejné. Windows Server Datacenter poskytuje neomezený počet virtuálních počítačů. S Windows Serverem Standard jste omezení na dva virtuální počítače.

Windows Server 2012 R2 přináší navíc funkci Automatická aktivace virtuálního počítače (AVMA). AVMA umožňuje na správně aktivovaný server instalovat virtuální počítače, aniž by se musely pro každý virtuální počítač samostatně spravovat kódy Product Key. Dá se to dělat i v odpojených prostředích.

AVMA vyžaduje, aby se jako hostované operační systémy používal Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard nebo Windows Server 2012 R2 Essentials. Jednotlivé edice porovnává následující tabulka.

Edice

Výhody

Nevýhody

Standard

  • Zahrnuje všechny funkce Windows Server.

  • Přijatelné pro nevirtualizovaná nebo lehce virtualizovaná prostředí

Omezeno na dva virtuální počítače

Datacenter

  • Zahrnuje všechny funkce Windows Server.

  • Umožňuje neomezený počet virtuálních počítačů.

  • Přijatelné pro vysoce virtualizovaná privátní cloudová prostředí

Vyšší nákladnost

Technologii Hyper-V je možné nainstalovat jako možnost instalace serverového jádra Windows Serveru. Instalace serverového jádra snižuje požadované místo na disku, potenciální prostor pro napadení a obzvláště požadavky na údržbu. Instalace serverového jádra se řídí prostřednictvím příkazového řádku, Windows PowerShellu nebo vzdálené správy.

Je důležité si přečíst licenční podmínky jakéhokoli softwaru, který máte v plánu použít.

Microsoft Hyper-V Server

Microsoft Hyper-V Server poskytuje jednoduché a spolehlivé řešení virtualizace umožňující organizacím zlepšovat využití serverů a snižovat náklady. Jde o samostatný produkt, který obsahuje jenom hypervisor Windows, model ovladače pro Windows Server a virtualizační součásti.

Hyper-V Server dokáže zapadnout do existujících IT prostředí zákazníků, takže budou moct využívat své stávající procesy pro zřizování a správu a nástroje podpory. Podporuje stejný seznam kompatibility hardwaru jako odpovídající edice Windows Serveru a integruje se plně s Microsoft System Centerem a technologiemi Windows, jako je Windows Update, Active Directory a Clustering s podporou převzetí služeb při selhání.

Hyper-V Server je zdarma ke stažení a po instalaci je okamžitě aktivovaný. Každý operační systém, který běží na hostovaném virtuálním počítači, ale vyžaduje řádnou licenci.

Další informace:

Automatická aktivace virtuálního počítače

Microsoft Hyper-V Server

Vzdálená správa Hyper-V Serveru

Úloha 2: Definování síťové konfigurace

V kroku 2, úloze 2 výše jsme probrali důležité aspekty navrhování sítí virtuálních počítačů. Teď se zaměříme na aspekty nastavení sítě pro hostitele. Existuje několik typů síťových přenosů, které je nutné při nasazování Hyper-V vzít v úvahu a se kterými je třeba počítat. Při návrhu konfiguraci sítě byste měli sledovat tyto cíle:

  • Zajištění síťové technologie QoS

  • Dosažení síťové redundance

  • Izolace přenosů na definované sítě

Úloha 2a: Definování typů síťových přenosů

Při nasazování clusteru Hyper-V musíte počítat s několika typy síťových přenosů. Typy přenosů shrnuje následující tabulka.

Typ přenos

Popis

Správa

  • Poskytuje připojení mezi serverem, na kterém běží Hyper-V, a základními funkcemi infrastruktury.

  • Používá se ke správě operačního systému hostitele Hyper-V a virtuálních počítačů.

Cluster a sdílené svazky clusteru

  • Používá se pro komunikaci mezi uzly v clusteru, jako je prezenční signál clusteru a přesměrování sdílených svazků clusteru (CSV).

  • Jenom v případě, že technologie Hyper-V byla nasazená pomocí Clusteringu s podporou převzetí služeb při selhání

Migrace za provozu

Používá se pro migraci virtuálních počítačů za chodu a migraci za chodu bez sdílení.

Úložiště

Používá se pro přenosy SMB nebo přenosy iSCSI.

Replika

Používá se pro replikační přenosy virtuálních počítačů prostřednictvím funkce Replika technologie Hyper-V.

Přenosy virtuálních počítačů (klientů)

  • Používá se pro připojení virtuálních počítačů.

  • Obvykle k obsluhování žádostí klientů vyžaduje externí síťové připojení.

Poznámka: Nahlédněte do části Krok 2: Plánování konfigurace virtuálních počítačů, kde najdete seznam typů přenosů virtuálních počítačů.

Zálohování

Používá se k zálohování souborů virtuálních pevných disků.

Úloha 2b: Definování možností výkonu síťových přenosů

Každý typ síťového přenosu bude mít požadavky na maximální a minimální šířku pásma a na minimální latenci. Níže najdete strategie, jak vyhovět různým nárokům na síťový výkon.

Technologie QoS spravovaná pomocí zásad

Když nasadíte cluster Hyper-V, potřebujete minimálně 6 vzorců provozu nebo sítí. Každá síť vyžaduje síťovou redundanci. Pro začátek mluvíme o 12 síťových adaptérech na hostiteli. Je možné nainstalovat víc čtyřportových síťových adaptérů, ale v určitém okamžiku zaplníte všechny sloty na hostiteli.

Síťové vybavení se zrychluje. Není to tak dávno, co 1GB síťové adaptéry představovaly úplnou špičku. Čím dál obvyklejší jsou na serverech 10GB adaptéry a ceny za podporu 10GB infrastruktur jsou čím dál přijatelnější.

Instalace dvou seskupených 10GB síťových adaptérů poskytuje větší šířku pásma než dva čtyřportové 1GB adaptéry, vyžaduje míň přepínacích portů a redukuje nároky na kabeláž. Když konvergujete víc typů síťových přenosů na seskupené 10GB síťové adaptéry, umožní vám technologie QoS spravovaná pomocí zásad řídit síťové přenosy tak, aby to vyhovovalo potřebám vaší infrastruktury virtualizace.

Technologie QoS spravovaná pomocí zásad vám umožní nastavit řízení šířky pásma sítě, a to na základě typu aplikace, uživatelů a počítačů. Zásady QoS vám umožní naplnit požadavky na služby u zatížení nebo aplikace, a to díky měření šířky pásma sítě, detekci změn stavu sítě (například při zahlcení nebo dostupnosti šířky pásma) a nastavování priorit (nebo omezení) síťových přenosů.

Kromě schopnosti vynucovat maximální šířku pásma poskytují zásady QoS ve Windows Serveru 2012 R2 novou funkci pro správu šířky pásma: minimální šířku pásma. Na rozdíl od maximální šířky pásma, což je její horní limit, představuje minimální šířka pásma její dolní mez a slouží k přiřazení určité velikosti šířky pásma k danému typu přenosu. Současně můžete implementovat minimální i maximální limit šířka pásma.

Výhody

Nevýhody

  • Spravováno prostřednictvím zásad skupiny

  • Dá se snadno použít u sítí VLAN, aby se zajistilo správné nastavení šířky pásma, když na síťovém adaptéru běží víc sítí VLAN nebo jsou síťové adaptéry seskupené.

  • Technologie QoS spravovaná pomocí zásad se dá použít u přenosů IPsec.

  • Neposkytuje správu šířky pásma pro přenosy, které používají virtuální přepínač.

  • Hostitelé Hyper-V musí být připojení k doméně.

  • Současně by se neměly používat softwarové zásady QoS i hardwarové zásady QoS (DCB).

Další informace:

Přehled technologie QoS (Quality of Server)

Technologie QoS (Quality of Service) spravovaná pomocí zásad

Přemostění datacenter

Přemostění datacenter (DCB) zajišťuje hardwarové přidělování šířky pásma konkrétnímu typu provozu a zlepšuje spolehlivost přenosu sítě Ethernet použitím řízení toku založeného na prioritách. DCB se doporučuje při použití FCoE a iSCSI.

Výhody

Nevýhody

  • Podpora pro Microsoft iSCSI

  • Podpora pro FCoE

  • Vyžaduje investice do hardwaru, včetně těchto zařízení:

    • Adaptéry sítě Ethernet podporující DCB

    • Hardwarové přepínače podporující DCB

  • Složité nasazení a správa

  • Nezajišťuje správu šířky pásma pro přenosy na virtuálních přepínačích.

  • Současně by se neměly používat softwarové zásady QoS i zásady DCB.

Další informace:

Přehled přemostění datacenter (DCB)

SMB Direct

SMB Direct (SMB prostřednictvím vzdáleného přímého přístupu do paměti neboli RDMA) je protokol úložiště ve Windows Serveru 2012 R2. Umožňuje přímé datové přenosy z paměti do paměti mezi serverem a úložištěm. Má jenom minimální nároky na procesor a využívá standardní síťové adaptéry podporující RDMA. Tím zajišťuje extrémně rychlou odezvu na síťové požadavky. Díky tomu jsou doby odezvy u vzdáleného úložiště souborů srovnatelné s přímo připojeným blokovým úložištěm.

Výhody

Nevýhody

  • Vyšší propustnost: Využívá úplnou propustnost vysokorychlostních sítí, kde síťové adaptéry koordinují přenos velkých objemů dat rychlostí dané linky.

  • Nízká latence: Zajišťuje extrémně rychlou odezvu na síťové požadavky. Díky tomu vzdálené úložiště působí jako přímo připojené blokové úložiště.

  • Nízké využití procesoru: Využívá míň cyklů procesoru při přenášení dat přes síť, což uvolní víc procesorových cyklů pro virtuální počítače.

  • Migrace za chodu může být nakonfigurovaná tak, aby pro svůj rychlejší průběh využívala SMB Direct.

  • Ve výchozím nastavení je tato možnost na hostiteli povolená.

  • Klient SMB automaticky zjišťuje a používá víc síťových připojení, pokud se podaří identifikovat odpovídající konfiguraci.

  • Nakonfigurujte správu šířky pásma SMB a nastavte limity pro migraci za chodu, virtuální počítače a výchozí přenosy v úložišti.

  • SMB Multichannel nevyžaduje adaptéry s podporou RDMA.

  • Síťové adaptéry s podporou RDMA nejsou kompatibilní se seskupováním síťových adaptérů.

  • Vyžaduje nasazení dvou nebo více síťových adaptérů s podporou RDMA na každém hostiteli, aby se zajistila vysoká dostupnost.

  • Aktuálně se omezuje na následující typy síťových adaptérů:

    • iWARP

    • Infiniband

    • RoCE

  • RDMA s RoCE vyžaduje DCB pro řízení toku.

Slučování přijatých segmentů

Slučování přijatých segmentů (RSC) snižuje nároky na CPU při zpracování příchozích síťových přenosů tím, že úlohy přesměrovává z procesoru na síťový adaptér podporující RSC.

Výhody

Nevýhody

  • Díky snížení nároků na zpracování velkého množství příchozích síťových přenosů zlepšuje škálovatelnost serverů.

  • Minimalizuje procesorové cykly, které se spotřebovávají pro účely síťového úložiště a migrací za chodu.

  • Vyžaduje síťový adaptér podporující RSC.

  • Neposkytuje výrazné zlepšení pro zatížení s velkými nároky na odesílání.

  • Není kompatibilní s přenosy šifrovanými v protokolu IPsec.

  • Platí pro přenosy hostitele. Aby se RSC dalo používat u přenosů virtuálního počítače, musí v něm běžet Windows Server 2012 R2 a musí být v konfiguraci se síťovým adaptérem SR-IOV.

  • Není ve výchozím nastavení povolené na serverech upgradovaných na Windows Server 2012 R2.

Škálování na straně příjmu

Škálování na straně příjmu (RSS) umožňuje síťovým adaptérům distribuovat zátěž související se síťovým zpracováním v režimu jádra mezi více jádry procesoru ve více počítačích představujících jádra. Distribuce tohoto zpracování umožňuje podporovat větší objemy síťových přenosů, než by bylo možné při použití jediného jádra. RSS toto dosahuje rozložením zátěže související se síťovým zpracováním mezi mnoho procesorů a aktivním vyrovnáváním této zátěže, což pak dokončuje protokol TCP (Transmission Control Protocol).

Výhody

Nevýhody

  • Rozloží monitorování přerušení na více procesorů, aby všechna vstupně-výstupní přerušení nemusel zpracovávat jediný procesor, což bylo běžné u předchozích verzí Windows Serveru.

  • Funguje se seskupováním síťových adaptérů.

  • Funguje s přenosy v protokolu UDP (User Datagram Protocol).

  • Vyžaduje síťový adaptér podporující RSS.

  • Deaktivuje se, pokud je virtuální síťový adaptér vázaný na virtuální přepínač. Pro síťové adaptéry vázané na virtuální přepínače se namísto RSS používá Fronta pro virtuální počítače (VMQ).

SR-IOV

Hyper-V podporuje síťová zařízení s funkcí SR-IOV a umožňuje přímé přiřazení virtuální funkce SR-IOV fyzického síťového adaptéru k virtuálnímu počítači. Zvyšuje se tím propustnost sítě, snižuje latence sítě a klesá taky zátěž hostitelského procesoru nutná pro zpracovávání síťových přenosů.

Další informace o SR-IOV viz Úloha 2b: Definování možností výkonu síťových přenosů výše.

Úloha 2c: Definování strategie vysoké dostupnosti síťových přenosů a agregace šířky pásma

Seskupování síťových adaptérů, označované taky jako vyrovnání zatížení a převzetí služeb při selhání (LBFO), umožňuje seskupení více síťových adaptérů za účelem agregace šířky pásma a převzetí služeb při selhání při přenosech. Tím se usnadní zachování připojení při selhání některé síťové součásti.

Tuto funkci dříve poskytovali dodavatelé síťových adaptérů. Počínaje verzí Windows Server 2012 je Seskupování síťových adaptérů funkcí operačního systému Windows Server.

Seskupování síťových adaptérů je kompatibilní se všemi síťovými funkcemi ve Windows Serveru 2012 R2 se třemi výjimkami:

  • SR-IOV

  • RDMA

  • Ověřování 802.1X

Z hlediska škálovatelnosti ve Windows Serveru 2012 R2 se do jedné skupiny dá přidat minimálně 1 a maximálně 32 síťových adaptérů. Na jednom hostiteli je možné vytvořit neomezený počet skupin.

Další informace:

Přehled seskupování síťových adaptérů

Microsoft Virtual Academy: Seskupování síťových adaptérů ve Windows Serveru 2012

Rutiny pro Seskupování síťových adaptérů (NetLBFO) ve Windows PowerShellu

Nasazení a správa Seskupování síťových adaptérů (NetLBFO) ve Windows Serveru 2012 R2

Konvergované datové centrum s úložištěm na souborových serverech

Úloha 2d: Definování strategie izolace a zabezpečení síťových přenosů

Každý typ síťového přenosu může mít jiné požadavky na zabezpečení, pokud jde o funkce jako izolace a šifrování. Následující tabulka uvádí strategie, jak vyhovět různým nárokům na zabezpečení.

Strategie

Výhody

Nevýhody

Šifrování (IPsec)

Přenosy jsou při průchodu po lince zabezpečené.

  • Šifrování a dešifrování přenosů má dopad na výkon.

  • Složitá konfigurace, správa a řešení problémů

  • Nesprávné změny konfigurace IPsec můžou způsobit síťová přerušení nebo nedostatečné šifrování přenosů.

Oddělené fyzické sítě

Síť je fyzicky oddělená.

  • Vyžaduje instalaci dalších síťových adaptérů na hostiteli.

  • Pokud síť vyžaduje vysokou dostupnost, jsou nutné nejmíň dva síťové adaptéry pro každou síť.

Virtuální místní síť (VLAN)

  • Izoluje přenosy použitím přiřazeného ID sítě VLAN.

  • Podpora protokolu pro režim VLAN Trunk.

  • Podpora pro privátní sítě VLAN

  • Už je používá mnoho podnikových zákazníků.

  • Platí omezení na 4094 sítí VLAN a většina přepínačů podporuje jenom 1000 sítí VLAN.

  • Vyžaduje dodatečnou konfiguraci a správu síťového vybavení.

  • Sítě VLAN nemůžou zahrnovat víc ethernetových podsítí, což omezuje počet uzlů v jedné síti IP a možnost umístění virtuálních počítačů, a to na základě fyzického místa.

Úloha 2e: Definování virtuálních síťových adaptérů

Když porozumíte typům přenosů vyžadovaným hostiteli virtualizačních serverů a strategiím v oblasti výkonu, dostupnosti a zabezpečení přenosů, můžete stanovit, kolik fyzických síťových adaptérů je u jednotlivých hostitelů potřeba a jaké typy síťových přenosů se budou přes jednotlivé adaptéry přenášet.

Úloha 2f: Definování virtuálních přepínačů

Abyste mohli připojit virtuální počítač k síti, musíte připojit síťový adaptér k virtuálnímu přepínači Hyper-V.

Existují tři typy virtuálních přepínačů, které se dají vytvořit v Hyper-V:

  • Externí virtuální přepínač

    Externí virtuální přepínač použijte, pokud chcete virtuálním počítačům poskytnout přístup k fyzické síti, aby mohly komunikovat s externě umístěnými servery a klienty. Tento typ virtuálního přepínače taky umožňuje vzájemnou komunikaci virtuálních počítačů na stejném hostiteli. Tento typ sítě může být taky k dispozici pro použití v hostitelském operačním systému, a to v závislosti na vaší síťové konfiguraci.

    Důležité: Fyzický síťový adaptér může být najednou vázaný jenom na jeden virtuální přepínač.

  • Interní virtuální přepínač

    Interní virtuální přepínač použijte, pokud chcete povolit komunikaci mezi virtuálními počítači na stejném hostiteli a mezi virtuálními počítači a hostitelským operačním systémem. Tento typ virtuálního přepínače se obvykle používá při sestavování testovacího prostředí, ve kterém je potřeba se připojovat k virtuálním počítačům z hostitelského operačního systému. Interní virtuální přepínač není vázaný na fyzický síťový adaptér. V důsledku toho je interní virtuální síť izolovaná od externích síťových přenosů.

  • Privátní virtuální přepínač

    Privátní virtuální přepínač použijte, pokud chcete povolit komunikaci jenom mezi virtuálními počítači na stejném hostiteli. Privátní virtuální přepínač není vázaný na fyzický síťový adaptér. Privátní virtuální přepínač je izolovaný od všech externích síťových přenosů na serveru a od všech síťových přenosů mezi hostitelským operačním systémem a externí sítí. Tento typ sítě je užitečný, když potřebujete vytvořit izolované síťové prostředí, například izolovanou testovací doménu.

    Poznámka: Pro privátní a interní virtuální přepínače nejsou nijak přínosné funkce hardwarové akcelerace, které jsou k dispozici pro virtuální počítač, který je připojený k externímu virtuálnímu přepínači.

Rozhodnutí, jaké řešení použít – Rozhodnutí, která učiníte v jednotlivých úlohách tohoto kroku, si můžete zaznamenat do listů pro virtualizační hostitele.

Tip: Názvy virtuálních přepínačů na různých hostitelích, které se připojují ke stejné síti, by měly být stejné. Tím se eliminují nejasnosti, ke kterému virtuálnímu přepínači se má virtuální počítač připojit, a zjednodušuje se přesouvání virtuálního počítače z jednoho hostitele na jiný. Pokud se na cílovém hostiteli nenajde virtuální přepínač se stejným názvem, rutina prostředí Windows PowerShell Move-VM selže.

Úloha 3: Definování konfigurace úložiště

Kromě úložiště požadovaného pro hostitelský operační systém vyžaduje každý hostitel přístup k úložišti, kde jsou uložené konfigurační soubory virtuálních počítačů a virtuální pevné disky. Tato úloha se zaměřuje na úložiště virtuálních počítačů.

Úloha 3a: Definování typů dat

Níže jsou příklady typů dat, které je nutné vzít v úvahu při určování požadavků na úložiště.

Typ dat

Umístění úložiště pro typ dat

Soubory hostitelského operačního systému

Obvykle na místním pevném disku

Stránkovací soubor hostitele a výpisy stavu systému Windows

Obvykle na místním pevném disku

Sdílený stav clusteru s podporou převzetí služeb při selhání

Sdílené síťové úložiště nebo sdílený svazek clusteru

Soubory virtuálního pevného disku a konfigurační soubor virtuálního počítače

Obvykle ve sdíleném síťovém úložišti nebo sdíleném svazku clusteru

Zbytek tohoto kroku se zaměřuje na úložiště požadované pro virtuální počítače.

Úloha 3b: Možnosti úložiště

Pro uložení konfiguračních souborů virtuálních počítačů a virtuálních pevných disků jsou k dispozici následující možnosti.

Možnost 1: Přímo připojené úložiště

Přímo připojené úložiště označuje počítačový úložný systém, který je přímo připojený k serveru (namísto přímého připojení k síti). Přímo připojené úložiště se neomezuje jenom na interní úložiště. Může taky využívat externí diskovou skříň, která obsahuje pevné disky, a to včetně skříní JBOD (just-a-bunch-of-disks) a skříní připojených přes SAS nebo jiný řadič disku.

Výhody

Nevýhody

  • Nevyžaduje síť úložiště.

  • Vstupně-výstupní diskové operace jsou rychlé, takže požadavky na úložiště nemusí putovat po síti.

  • Může se jednat o interní úložiště nebo o externí diskovou skříň, včetně skříní JBOD.

  • Ve skříni JBOD můžete pomocí technologie Prostory úložiště sloučit všechny fyzické disky ve fondu úložiště a pak z volného místa ve fondu vytvořit jeden nebo víc virtuálních disků (nazývaných Prostory úložiště).

  • Skříně JBOD jsou obvykle levnější a často nabízejí větší flexibilitu a jednodušší správu než skříně RAID, protože pro správu úložiště používají namísto vyhrazených adaptérů RAID operační systémy Windows nebo Windows Server.

  • Platí pro ně omezení, pokud jde o počet serverů, které se dají připojit k externí diskové skříni.

  • Jenom externí sdílené úložiště, jako je sdílené SAS s Prostorami úložiště, poskytuje podporu pro Clustering s podporou převzetí služeb při selhání.

Možnost 2: K síti připojené úložiště

Zařízení úložiště připojeného k síti připojují úložiště k síti, kde jsou přístupná prostřednictvím sdílených složek. Na rozdíl od přímo připojeného úložiště nejsou připojené přímo k počítači.

Zařízení úložiště připojeného k síti podporují ethernetová připojení a obvykle správci umožňují správu místa na disku, nastavení diskových kvót, zajištění zabezpečení a používání technologií pro kontrolní body. Zařízení úložiště připojeného k síti podporují víc protokolů. Patří mezi ně souborové systémy připojené k síti, CIFS (Common Internet File System) a SMB (Server Message Block).

Výhody

Nevýhody

  • Jednodušší nastavení než úložiště SAN, s nižšími nároky na vyhrazený úložný hardware

  • Technologie Plug and Play

  • Může využívat stávající ethernetovou síť.

  • Zařízení úložiště připojeného k síti musí podporovat SMB 3.0 – CIFS se nepodporuje.

  • Bez přímého připojení k hostitelským serverům, které přistupují k úložišti

  • Pomalejší než ostatní možnosti

  • Obvykle pro optimální výkon vyžaduje vyhrazenou síť.

  • Omezená správa a funkčnost

  • Hyper-V podporuje zařízení úložiště připojeného k síti, která podporují SMB 3.0. Nepodporuje se SMB 2.0 a CIFS.

  • Může, ale nemusí podporovat RDMA.

Možnost 3: Síť SAN

Síť SAN (Storage Area Network) je vyhrazená síť, která vám umožní sdílet úložiště. Skládá se z paměťového zařízení, propojovací síťové infrastruktury (přepínače, adaptéry hostitelské sběrnice a kabeláž) a serverů, které jsou připojené k této síti. Zařízení sítě SAN poskytují nepřetržitý a rychlý přístup k velkým objemům dat. Mechanismus komunikačních a datových přenosů pro konkrétní nasazení se běžně označuje jako prostředky infrastruktury úložiště.

Síť SAN představuje samostatnou síť, která obvykle není přístupná pro jiná zařízení v místní síti. Síť SAN je možné spravovat pomocí SMI-S (Storage Management Initiative Specification), SNMP (Simple Network Management Protocol) nebo vlastního protokolu pro správu.

Síť SAN neposkytuje souborovou abstrakci, jenom operace na úrovni bloků. Nejběžněji používané protokoly pro sítě SAN jsou iSCSI, Fiber Channel a Fiber Channel over Ethernet (FCoE). Protokol SMI-S nebo vlastní protokol pro správu může poskytovat další funkce, jako je zónování a mapování disků, maskování logických jednotek a řízení chyb.

Výhody

Nevýhody

  • Síť SAN představuje samostatnou síť, takže má jen omezený dopad na datovou síť.

  • Poskytuje nepřetržitý a rychlý přístup k velkým objemům dat.

  • Obvykle poskytuje další funkce, jako je ochrana a replikace dat.

  • Můžou ji sdílet různé týmy.

  • Podpora pro Virtual Fibre Channel nabízející přímý přístup k logickým jednotkám úložiště

  • Podpora pro clustering hostů

  • Virtuální počítače, které potřebují přístup k objemům dat větším než 64 TB, můžou využívat Virtual Fibre Channel pro přímý přístup k logickým jednotkám.

  • Nákladné

  • Vyžaduje specializované dovednosti pro nasazení, správu a údržbu.

  • Síťové adaptéry HBA nebo FCoE je nutné nainstalovat na každém hostiteli.

  • Migrace clusteru Hyper-V vyžaduje dodatečné plánování a způsobí výpadek omezeného rozsahu.

  • K poskytování správy šířky pásma pro přenosy FCoE jsou nutné hardwarové zásady QoS, které využívají přemostění datacenter.

  • Přenosy FCoE se nedají směrovat.

Možnost 4: Sdílené složky SMB (Server Message Block) 3.0

Hyper-V může ukládat soubory virtuálních počítačů, jako jsou konfigurační soubory, soubory virtuálních pevných disků a kontrolní body, na sdílené složky, které používají protokol SMB (Server Message Block) 3.0. Sdílené složky se obvykle nacházejí na souborovém serveru se škálováním na více systémů, aby se zajistila redundance. Pokud provozujete souborový server se škálováním na více systémů a selže jeden uzel, sdílené složky budou dál k dispozici z jiných uzlů tohoto serveru.

Výhody

Nevýhody

  • Možnost využívat stávající sítě a protokoly

  • SMB Multichannel poskytuje agregaci síťové šířky pásma a toleranci chyb, pokud je k dispozici víc cest mezi serverem, na kterém běží Hyper-V, a sdílenou složkou SMB 3.0.

  • Ve skříni JBOD můžete pomocí technologie Prostory úložiště sloučit všechny fyzické disky ve fondu úložiště a pak z volného místa ve fondu vytvořit jeden nebo víc virtuálních disků (nazývaných Prostory úložiště).

  • SMB Multichannel se dá používat pro migrace virtuálních počítačů.

  • Míň nákladné než nasazení sítí SAN

  • Flexibilní konfigurace úložišť na souborovém serveru s Windows Serverem

  • Oddělení služeb Hyper-V od služeb úložiště, což umožňuje škálovat jednotlivé služby podle potřeby

  • Při provozování clusteru Hyper-V nabízí flexibilitu při upgradu na novou verzi. Můžete upgradovat servery, na kterých běží Hyper-V, nebo souborové servery se škálováním na více systémů, a to v libovolném pořadí a bez prostojů. V clusteru potřebujete dostatečnou kapacitu k odebrání jednoho nebo dvou uzlů, aby byl možný upgrade.

  • Souborový server se škálováním na více systémů poskytuje podporu pro sdílené VHDX.

  • Správa šířky pásma SMB umožňuje nastavit mezní hodnoty pro migraci za chodu, virtuální pevný disk a přenosy výchozího úložiště.

  • Podpora pro šifrování přenosů SMB s minimálním dopadem na výkon

  • Můžete ušetřit místo na disku díky odstranění duplicitních dat u nasazení VDI.

  • Nevyžaduje specializované dovednosti pro nasazení, správu a údržbu.

  • Vstupně-výstupní výkon není tak rychlý jako u nasazení sítí SAN.

  • Odstranění duplicitních dat se nepodporuje na běžících virtuálních počítačích, s výjimkou nasazení VDI.

SMB Direct

SMB Direct funguje jako součást sdílených složek SMB. Vyžaduje síťové adaptéry a přepínače, které podporují RDMA a poskytují tak přístup k úložišti s plnou rychlostí a nízkou latencí. SMB Direct umožňuje, aby se vzdálené souborové servery jevily jako místní a přímo připojené úložiště. Kromě přínosů SMB jako takového se SMB Direct vyznačuje následujícími výhodami a nevýhodami.

Výhody

Nevýhody

  • Funguje s plnou rychlostí a nízkou latencí při velmi nízkých nárocích na procesor.

  • Umožňuje souborovému serveru se škálováním na více systémů poskytovat úložiště s výkonem a odolností, které jsou podobné jako u tradiční sítě SAN, a to díky využití řešení úložiště od Microsoftu a nenákladného sdíleného úložiště s přímým připojením.

  • Poskytuje nejrychlejší možnost pro migrace za chodu a migrace úložiště.

  • Nepodporuje se se Seskupováním síťových adaptérů.

  • Pro redundantní připojení k úložišti se vyžadují nejmíň dva síťové adaptéry s podporou RDMA.

Souborový server se škálováním

Obrázek 3:Příklad souborového serveru se škálováním na více systémů, který používá konvergované síťové propojení s RDMA

Další informace:

Zřízení nákladově efektivního úložiště pro úlohy Hyper-V pomocí Windows Serveru

Konvergované datové centrum s úložištěm na souborových serverech

Nasazení Hyper-V přes SMB

Dosažení víc než 1 milionu IOPS u virtuálních počítačů Hyper-V v clusteru souborových serverů se škálováním na více systémů za použití Windows Serveru 2012 R2

Úloha 3c: Definování typů architektury fyzických disků

Typ architektury fyzických disků, který vyberete pro své řešení úložiště, ovlivní jeho výkon. Další informace o typech disků najdete v části 7.1 článku Architektura produktové řady Infrastruktura jako služba (IaaS).

Úloha 3d: Definování síťového typu úložiště

Typ paměťového řadiče a síťového řadiče úložiště, které budete používat, vyplývají z varianty úložiště, kterou vyberete pro jednotlivé skupiny hostitelů. Další informace najdete v tématu Úloha 3b: Možnosti úložiště.

Úloha 3e: Stanovení typů úložiště, které se mají používat s jednotlivými datovými typy

Teď když jste porozuměli svým datovým typům, můžete stanovit, která varianta úložiště, paměťový řadič, síťový řadič úložiště a architektura fyzických disků nejlépe vyhovují vašim požadavkům.

Rozhodnutí, jaké řešení použít – Rozhodnutí, která učiníte v této úloze, si můžete zaznamenat do listu pro virtualizační hostitele.

Další informace:

Síťové konfigurace pro Hyper-V přes SMB ve Windows Serveru 2012 a Windows Serveru 2012 R2

Plakát s architekturou Hyper-V ve Windows Serveru 2012 a doprovodné reference

Přehled úložných technologií

Úloha 4: Definování jednotek škálování hostitelů virtualizačních serverů

Nákup jednotlivých serverů s sebou nese jejich pořízení, instalaci a konfiguraci. Jednotky škálování umožňují zakoupit kolekce serverů (které obvykle obsahují identický hardware). Ty jsou předkonfigurované, což vám umožní rozšiřovat kapacitu datového centra přidáváním jednotek škálování, nikoli jednotlivých serverů.

Následující obrázek ukazuje jednotku škálování, která by se dala zakoupit jako předkonfigurovaná od celé řady dodavatelů hardwaru. Zahrnuje rack, nepřerušitelný zdroj napájení (UPS), dvojici redundantních síťových přepínačů pro servery obsažené v racku a deset serverů.

Jednotka škálování hostitele

Obrázek 4:Příklad jednotky škálování hostitelů virtualizačních serverů

Jednotka škálování se poskytuje jako předkonfigurovaná a předem připojená k UPS a síťovým přepínačům. Jednotku stačí jednoduše přidat do datacentra, připojit k elektrickému napájení a pak připojit k síti a úložišti. Pak je připravená k použití. Pokud by jednotlivé komponenty nebyly zakoupené jako jednotka škálování, musel by je zákazník jednotlivě vkládat do racku a zapojovat.

Rozhodnutí, jaké řešení použít – Pokud se rozhodnete používat jednotky škálování hostitelů virtualizačních serverů, můžete pro ně definovat hardware na listu jednotek škálování hostitelů.

Tip: Předkonfigurované jednotky škálování si můžete koupit od celé řady partnerů Microsoftu, kteří nabízejí hardware, prostřednictvím programu Microsoft Private Cloud Fast Track.

Úloha 5: Definování strategie pro dostupnost hostitelů virtualizačních serverů

Hostitelé virtualizačních serverů se můžou stát nedostupnými z plánovaných důvodů (například údržba) i neplánovaných důvodů. Tady je několik strategií, které se dají použít v obou případech.

Plánované

Virtuální počítače můžete přesunout z jednoho hostitele na jiný pomocí migrace za chodu. To si u virtuálních počítačů nevyžádá žádný výpadek.

Neplánované

Tento scénář závisí na charakteristikách zatížení, která obsluhuje tento hostitel.

  • U zatížení se sdílením stavu použijte Clustering s podporou převzetí služeb při selhání v rámci virtuálních počítačů.

  • U stavových zatížení ho spusťte jako virtuální počítač s vysokou dostupností v clusteru Hyper-V.

  • U bezstavových zatížení spusťte nové instance ručně nebo přes nějaké automatizované prostředky.

Pokud používáte Clustering s podporou převzetí služeb při selhání ve Windows Serveru s Hyper-V, zvažte použití funkcí uvedených v následující tabulce. Další informace o jednotlivých funkcích získáte kliknutím na hypertextový odkaz.

Funkce

Požadavky

Monitorování aplikace Hyper-V

Virtuální počítač je třeba monitorovat z hlediska selhání sítí a úložiště, která nemonitoruje služba Clustering s podporou převzetí služeb při selhání.

Nastavení priority virtuálního počítače

  • Je třeba nastavit prioritu virtuálního počítače, a to na základě příslušného zatížení. Virtuálním počítačům s vysokou dostupností (taky označovaným jako clusterové virtuální počítače) můžete přiřadit následující priority:

    • Vysoká

    • Střední (výchozí)

    • Nízká

    • Bez automatického spuštění

  • Clusterové role s vyšší prioritou se spouštějí a umísťují na uzly před těmi, které mají nižší prioritu.

  • Při přiřazení priority Bez automatického spuštění nepřejde role po selhání do online režimu automaticky, takže prostředky zůstanou dostupné pro spuštění dalších rolí.

Nastavení proti spřažení virtuálních počítačů

U virtuálních počítačů, které se nemají spouštět na stejném uzlu v clusteru Hyper-V, zakažte spřažení. Může se to týkat virtuálních počítačů, které poskytují redundantní služby nebo jsou součástí clusteru hostovaných virtuálních počítačů.

Poznámka: Nastavení proti spřažení se konfigurují přes Windows PowerShell.

Automatizované vyprazdňování uzlů

  • Než uzel přejde do režimu údržby nebo se na něm budou dělat jiné změny, cluster ho automaticky vyprázdní (přesune na něm běžící clusterové role na jiný uzel).

  • Po operacích údržby se role vrátí na původní uzel.

  • Správci můžou uzel vyprázdnit jednou akcí ve Správci clusteru s podporou převzetí služeb při selhání nebo pomocí rutiny Windows PowerShellu Suspend-ClusterNode. Je možné zadat cílový uzel pro přesunuté clusterové role.

  • Aktualizace pro clustery využívá vyprazdňování uzlů v automatizovaném procesu při nasazování softwarových aktualizací na uzly clusteru.

Aktualizace pro clustery

  • Aktualizace pro clustery umožňuje aktualizovat uzly v clusteru bez dopadu na virtuální počítače běžící v clusteru.

  • Během procesu aktualizace musí zůstat k dispozici dostatečný počet uzlů clusteru pro zpracování zátěže z běžících virtuálních počítačů.

Přerušování virtuálních počítačů na základě priority

Dalším důvodem pro nastavení priority virtuálních počítačů je, že clusterová služba může virtuální počítače s nižší prioritou uvést do offline režimu, když není dost paměti a jiných prostředků ke spuštění virtuálních počítačů s vysokou prioritou.

  • Přerušování začne u virtuálního počítače s nejnižší prioritou a pokračuje k virtuálním počítačům s vyšší prioritou.

  • Přerušené virtuální počítače se později restartují podle pořadí priority.

Poznámka: Clustery Hyper-V můžou mít maximálně 64 uzlů a 8000 virtuálních počítačů.

Krok 5: Plánování konceptů architektury prostředků infrastruktury virtualizace

Tento krok vyžaduje definování logických konceptů, podle kterých se bude architektura modelovat.

Úloha 1: Definování domén údržby

Domény údržby jsou logické kolekce serverů, které se obsluhují společně. Tyto činnosti můžou zahrnovat upgrady hardwaru a softwaru nebo změny konfigurace. Domény údržby obvykle obstarávají víc skupin hostitelů určitého typu nebo na určitém místě, ale nemusí to tak být. Účelem je zabránit, aby údržba serverů neměla nepříznivý vliv na zatížení u kterýchkoli uživatelů.

Poznámka: Tento koncept se vztahuje na fyzickou síť a komponenty úložiště.

Úloha 2: Definování fyzických domén selhání

Skupiny hostitelů virtualizačních serverů často selhávají najednou v důsledku selhání sdílené komponenty v infrastruktuře, jako je síťový přepínač nebo nepřerušitelný zdroj napájení (UPS). Fyzické domény selhání zlepšují odolnost v rámci prostředků architektury virtualizace. Je důležité porozumět, jaký dopad má doména selhání na jednotlivé skupiny hostitelů, které jste si v prostředcích architektury definovali.

Poznámka: Tento koncept se vztahuje na fyzickou síť a komponenty úložiště.

Podívejte se na příklad na následujícím obrázku, v němž naznačujeme překrývání domén údržby a fyzických domén selhání v rámci kolekce skupin hostitelů v datacentru.

Doména chyby

Obrázek 5:Příklad definování domén údržby a fyzických domén selhání

V tomto příkladu je každý rack serverů definovaný jako samostatná a očíslovaná fyzická doména selhání. Důvodem je to, že každý rack obsahuje v horní části síťový přepínač a v dolní části UPS. Všechny servery v rámci racku závisí na těchto dvou komponentách, a pokud některá selže, následně selžou i všechny servery v racku.

Vzhledem k tomu, že všechny servery v racku jsou zároveň členy jedinečných skupin hostitelů, bylo by důsledkem tohoto řešení, že by v případě selhání kterékoli z fyzických domén selhání neexistovalo nic, co by zmírnilo dopady. Aby se tyto problémy zmírnily, mohli byste přidat fyzické domény selhání u každého typu skupiny hostitelů. V prostředích menšího měřítka byste mohli potenciálně do každého racku přidat redundantní přepínače a zdroje napájení nebo pro hostitele virtualizačních serverů napříč fyzickými doménami selhání použít Clustering s podporou převzetí služeb při selhání.

Na obrázku 5 definuje každý rámeček vyznačený barevnou přerušovanou čárou doménu údržby (jsou označené MD 1 až 5). Všimněte si, že se každý ze serverů v clusteru virtuálních počítačů s vyrovnáváním zatížení nachází na hostiteli virtualizace serverů, který je obsažený v samostatné doméně údržby a samostatné fyzické doméně selhání.

To správci prostředků infrastruktury umožňuje vypnout všechny hostitele virtualizačních serverů v rámci domény údržby bez výrazného dopadu na aplikace, které mají víc serverů rozložených napříč doménami údržby. Taky to znamená, že aplikace běžící v clusteru s vyrovnáváním zatížení nezůstane úplně nedostupná, pokud selže fyzická doména selhání.

Rozhodnutí, jaké řešení použít – Rozhodnutí, která učiníte v úloze 1 a 2, si můžete zaznamenat do listu nastavení.

Úloha 3: Definování rezervní kapacity

Selhání jednotlivých serverů v prostředcích infrastruktury je nevyhnutelné. Návrh prostředků infrastruktury musí se selháním jednotlivých serverům počítat, stejně jako počítá se selháním kolekcí serverů v doménách selhání a údržby. Následující obrázek je stejný jako obrázek 5, ale jsou v něm červeně označené tři servery, které selhaly.

Servery s chybami

Obrázek 6:Servery, které selhaly

Na obrázku 6 selhali hostitelé virtualizace serverů v následujících skupinách hostitelů, doménách údržby a fyzických doménách selhání.

Skupina hostitelů

Fyzická doména selhání

Doména údržby

2

2

3

3

3

2

4

4

2

Aplikace běžící v clusteru s vyrovnáváním zatížení budou dál k dispozici, přestože selhal hostitel ve fyzické doméně selhání 2, ale aplikace bude fungovat s kapacitou o třetinu nižší.

Popřemýšlejte, co by se stalo, pokud by selhal i hostitel virtualizace serverů, který je hostitelem jednoho z virtuálních počítačů ve fyzické doméně selhání 3, nebo pokud by byla kvůli údržbě vypnutá doména údržby 2. V těchto případech by se kapacita pro aplikaci snížila o 2/3.

Můžete dospět k závěru, že pro vaše prostředky architektury virtualizace je to nepřijatelné. Aby se zmírnil dopad selhání serverů, můžete zajistit, aby každá z fyzických domén selhání a domén údržby měla dostatečnou rezervní kapacitu, aby kapacita nikdy neklesla pod přijatelnou úroveň, kterou definujete.

Další informace o výpočtu rezervní kapacity najdete v části Rezervní kapacita v tématu Referenční architektura základu Cloudových služeb – principy, koncepty a vzory.

Krok 6: Plánování charakteristik počátečních kapacit

Po dokončení všech úloh v tomto dokumentu dokážete stanovit počáteční náklady na hostování virtuálních počítačů a úložiště v prostředcích architektury, a to vedle počátečních úrovní kvality služeb, které prostředky infrastruktury můžou splňovat. Žádnou z těchto úloh ale nebudete moct finálně uzavřít, dokud neimplementujete nástroje pro správu prostředků infrastruktury a lidské zdroje, což se probírá v části Další kroky v tomto dokumentu.

Úloha 1: Definování počátečních metrik smluv o úrovni služeb pro úložiště a virtuální počítače

Jako správce prostředků infrastruktury budete pravděpodobně definovat smlouvu o úrovni služeb (SLA) s detailním popisem metrik kvality služeb, které budou splňovat. Vaši správci virtuálních počítačů to budou potřebovat znát, aby si mohli naplánovat, jak budou prostředky infrastruktury využívat.

Minimálně to nejspíš bude zahrnovat metriku dostupnosti, ale může tady být i jiné metriky. Pokud si chcete udělat základní představu o metrikách SLA pro prostředky infrastruktury virtualizace, můžete si projít ty, co nabízí poskytovatelé veřejných cloudů, jako je Microsoft Azure. Pro hosting virtuálních počítačů tato SLA zaručuje, že pokud zákazník nasadí dvě nebo víc instancí virtuálního počítače, na kterých běží stejné zatížení, a nasadí tyto instance v různých doménách selhání a upgradu (ty v tomto dokumentu označujeme jako domény údržby), nejmíň jeden z těchto virtuálních počítačů bude k dispozici 99,95 % času.

Úplný popis smlouvy SLA pro Azure najdete v tématu Smlouvy o úrovni služeb. Optimálně budou vaše prostředky architektury virtualizace na stejné nebo vyšší úrovni než u poskytovatelů veřejného cloudu.

Úloha 2: Definování počátečních nákladů na hostování úložiště a virtuálních počítačů

Po navržení prostředků architektury budete taky moct vypočítat:

  • Náklady na hardware, místo, napájení a chlazení prostředků infrastruktury

  • Hostingovou kapacitu prostředků infrastruktury

Tyto informace v kombinaci s vašimi dalšími náklady, jako jsou náklady na nástroje pro správu prostředků infrastruktury a lidské zdroje, vám umožní určit konečné náklady na hostování virtuálních počítačů a úložiště.

Pokud si chcete udělat základní představu o nákladech na virtuální počítače a úložiště, můžete si projít náklady na hosting u poskytovatelů veřejných cloudů, jako je Microsoft Azure. Další informace viz Podrobnosti o cenách virtuálních počítačů.

I když tomu tak vždycky není, obvykle zjistíte, že vaše náklady na hosting jsou vyšší než u poskytovatelů veřejných cloudů, protože vaše prostředky infrastruktury budou mnohem menší než u velkých poskytovatelů, kteří díky nim můžou dosáhnout na množstevní slevy na hardware, prostory datacenter a napájení.

Další kroky

Po dokončení všech úloh v tomto dokumentu budete mít návrh prostředků infrastruktury, který bude splňovat požadavky vaší organizace. Taky budete mít definici počátečních charakteristik služeb, která bude zahrnovat náklady a metriky úrovní služeb. Finální metriky úrovně služeb a náklady nebudete moct zjistit, dokud nestanovíte náklady na lidské zdroje, nástroje pro správu a procesy, které budete u svých prostředků infrastruktury používat.

Microsoft System Center 2012 poskytuje komplexní sadu funkcí, které vám umožní zřízení, monitorování a údržbu vašich prostředků infrastruktury virtualizace. Další informace o tom, jak se pro správu prostředků infrastruktury používá System Center, najdete v následujících zdrojích:

Knihovna technické dokumentace System Centera

Průvodce architekturou správy prostředků