virtualizace CPU: technologie, která řídí ekonomiku cloudu

Můžeme si pronajmout tolik nebo tak málo výpočetní kapacity nebo úložiště nebo konektivity, kolik chceme, a můžeme to získat, když to budeme chtít. A my nemusíme udržovat ani účtovat žádný z tohoto hardwaru. Skvělý nápad, tenhle mrak. Proč se to už dávno neudělalo? A společnosti poskytující všechny tyto zdroje nám stále více usnadňují používání. Život ve světě IT se zdá být dobrý.

Ti, kteří nám poskytují cloud, však vědí, že – jako u většiny všeho – tento dobrý život přichází s několika kompromisy. Rozhodně nejde o to, že by tato upozornění byla skrytá, je to jen o tom, že k snadnému vysvětlení je zapotřebí určité technické zázemí. Proč je například jeden den výkon mé cloudové aplikace skvělý a druhý den ne, i když jsou všechny ostatní – z našeho pohledu – stejné? Možné příčiny opravdu není tak těžké pochopit. Takže se zde zaměříme na virtualizaci procesorů, soubor technických konceptů, které jsou základem alespoň části cloudu.

Opravdu máte možnost tomu nerozumět? Jak jsem četl v nedávném článku na The Next Platform: „Společnosti dnes fungují jednou nohou on-premise a jednou v cloudu. Tato kombinace soukromých a veřejných aktiv poskytujících základní obchodní služby je známá jako hybridní podnik a stala se novou normou. I když tento model může snížit náklady a zlepšit produktivitu zaměstnanců, může být pro IT také noční můrou pro správu.“ Zde by vám mělo pomoci trochu znalostí navíc.

Budeme se určitě bavit o tom, co pohání výkon, ale toto není – a mělo by to být samozřejmé – článek o výpočetním výkonu obecně; je to článek o rozdílech mezi používáním veřejného a soukromého majetku.

Tak se pohodlně usaďte a pojďme si vytvořit pár mentálních představ o tom, co se skutečně děje v těch oblacích.

VÝCHOZÍ BOD

Jistě, součástí krásy cloudu je, že si můžete pronajmout jeho zdroje. Umožňuje to ale poměrně jednoduchý fakt; obvykle využíváte pouze malé procento výpočetních prostředků dostupných na hardwaru, na kterém spouštíte. Pokud používáte – řekněme – pouze 10 procent, proč platíte i za zbývajících 90 procent? Místo toho si pronajměte, co potřebujete.

Ti, kdo provozují cloud, samozřejmě mají a zaplatili za hardware a tedy i veškerou výpočetní kapacitu, která je s ním spojena. A často hodně. A jsou naprosto ochotni vám umožnit sdílet – do určitého limitu – tento hardware, zaplatit za toto privilegium nominální částku, a přesto mít záruku, že jste funkčně izolováni od všech ostatních obyvatel cloudu. O tom je vlastně virtualizace procesorů; sdílení hardwaru nějakým bezpečným způsobem, ale takovým způsobem, aby byla plně využita kapacita tohoto hardwaru.

Když vidíme obrázky toho, co ve skutečnosti tvoří cloud(y), určitě to vypadá, že naše vlastní stopy použití jsou v něčem nepředstavitelně masivním nepochopitelně malé; každý vypadá jako hromady a hromady výpočetní kapacity, paměti, trvalého úložiště a propojení s obrovskou šířkou pásma. Křičíte v něčem tak velkém a očekáváte, že uslyšíte ozvěnu; tedy i když bylo slyšet cokoli jiného než chladicí ventilátory.

Ale ne, ve skutečnosti to tak není. Každý cloud je postaven z velké části z hardwaru, který již znáte a máte rádi. Mnohé z nich jsou masivní replikace jedné až několika desek podporujících SMP (Symmetric Multi-Processor), každá s jedním až několika procesorovými čipy, každý čip s velkou hrstkou procesorových jader, každé s poměrně malým množstvím mezipaměti a celkovou pamětí. v dosahu terabajtu paměti. A tyto stavební bloky zase podporují připojení k sousedům, dalším I/O zařízením a vnějšímu světu přes PCI-Express, Ethernet, InfiniBand a další. Ve srovnání s nepříliš dávnou dobou jsou i tyto jednotlivé stavební bloky SMP mocnými entitami. A pro ty, kteří potřebují více, více za vyšší cenu, stále existují větší SMP systémy – nebo podobné GPU – které by mohly být podobně replikovány. mrak není ani tak masivní mlha, jako spíše velké množství horkých sněhových koulí; je to cloud, protože nepotřebujete vědět, kde jste, když jste v něm, a ne že je to jen na vás, abyste ho mohli používat.

Tyto jednotky SMP se mohou samy o sobě zdát velké – výpočetní kapacita několika desítek procesorů a stovky gigabajtů paměti – ale jsou konečné. Úkolem poskytovatele cloudu je uspokojit a překročit vaše potřeby výkonu, snížit vaše náklady a zároveň minimalizovat jejich náklady – které zahrnují obrovské náklady na energii – a maximalizovat jejich zisky, přičemž vás i ostatní začlení do těchto omezených zdrojů. Vyvažování zátěže k dosažení tohoto cíle je zde povýšeno na vysokou vědu.

Neposkytují instanci operačního systému a jeho aplikacím celou desku procesoru; místo toho vám poskytují něco mnohem abstraktnějšího, výpočetní kapacitu. Vy a desítky, stovky, možná tisíce dalších instancí OS – aka, oddílů – sdílíte celkovou kapacitu jedné jednotky SMP. Opět nekupujete nebo dokonce nutně nepronajímáte určitý počet procesorových jader, sdílíte tento zdroj a pronajímáte si část jeho kapacity.

Uzavřeli jste smlouvu na určitou úroveň kapacity; stejně jako mnoho, mnoho dalších. poskytovatelé cloudu vezmou vaše požadované a skutečné potřeby výkonu, podívají se na kapacitu, která je k dispozici v každém jejich skutečném a aktuálně aktivním hardwaru, upraví spotřebu energie a rozhodnou, kde v tomto obrovském cloudu bude váš oddíl na chvíli sídlit; sídlící tam, v té jednotce SMP, spolu s celou řadou dalších.

To je výchozí bod. Dále se trochu ponoříme a uvidíme, co to znamená a jak to můžete cítit.

CO JE KAPACITA?

Sledovali jste někdy grafy využití CPU na vaší pracovní stanici? Pro většinu účelů je v pořádku používat využití procesoru jako velmi hrubé měřítko toho, o kolik více práce mohou vaše procesory vykonat. Ale pro tuto diskusi předpokládejme, že využití CPU poskytuje určitou značnou přesnost v měření kapacity.

Předpokládejme, že měříte nějakou jednotku práce, kterou nazýváte „transakcí“. Předpokládejme, že právě teď váš systém srazí 1 000 transakcí za sekundu. A všimli jste si, že využití CPU je – řekněme – 20 %. Jaký je váš automatický předpoklad o dostupné kapacitě vašeho systému? Pravděpodobně si myslíte, že 20% využití CPU znamená, že moje procesory mohou zabrat 5krát více práce. Měl bych tedy být schopen získat zhruba 5krát více transakcí – 5krát větší propustnost; to předpokládá, že tento SMP je omezen na procesor – nikoli I/O. Takže, 5 krát 1 000, celková dostupná kapacita je přibližně 5 000 transakcí za sekundu. Opět platí, že to je vaše automatické odebrání, když se podíváte na využití CPU.

Možná jste také změřili svou propustnost založenou na transakcích v průběhu času a všimli si nejrůznějších zajímavých vztahů o rychlostech transakcí v průběhu času, možná dokonce mapování na využití CPU. Možná jste zašli tak daleko, že jste určili výpočetní kapacitu počtu jader potřebnou k řízení této propustnosti v průběhu času; pokud byl váš 16jádrový systém často využíván na 25 procent, možná byste mohli stejnou práci udělat se 4 jádry. Všimli jste si, že obvykle potřebujete jen malý zlomek svých – řekněme – šestnácti jader; mohli byste si vystačit s kapacitou dostupnou v těchto mnoha méně jádrech, ale velmi příležitostně víte, že byste mohli využít více. Pěkná práce. Jste připraveni nakoupit jednu nebo více ekonomických nabídek Cloudu.

Věřte tomu nebo ne, v té pěkné analýze jste udělali spoustu předpokladů, mnohé z nich dostatečně validní, jiné – no – o nich budeme mluvit za chvíli.

Kapacita je koncepčně blízká pojmu propustnost. Mít schopnost – příležitost – produkovat vyšší propustnost – vyšší transakce/sekundu – také znamená mít vyšší kapacitu. Transakční rychlost je mírou propustnosti; kapacita je maximální transakční rychlost, které lze dosáhnout. Není: Kolik je ve vašem kbelíku? Je to: Jak velký je váš kbelík?

Kapacita může být funkcí výkonu s jedním vláknem, ale tyto dva koncepty se velmi liší. Je jisté, že čím dříve může jediné vlákno pracovat na jádře procesoru, tím dříve bude tento procesor k dispozici pro další práci. Toto rychlejší jedno jádro může znamenat větší kapacitu. Ale v závislosti na typu práce může stejnou kapacitu produkovat i více pomalejších procesorů.

CO JE K DISPOZICI?

Existuje mnoho různých poskytovatelů cloudových služeb, ale vyberme si pouze jednoho, většinou proto, abychom získali koncept, ne proto, že je nebo není lepší.

Pokud navštívíte web Amazon Web Services (AWS) a vyhledáte ceny, všimnete si, že ceny jsou alespoň částečně založeny na představě ECU (EC2 Compute Unit). Na určité úrovni se jedná o sebereferenční hodnotu představující relativní výpočetní kapacitu každé z jejich nabídek. 26 znamená, že taková nabídka má zhruba dvojnásobnou kapacitu než 13. Jen s touto znalostí si však uvědomíte, že nemáte ponětí, co 13 představuje. Když se ponoříte dále, zjistíte, že jedna ECU představuje výpočetní kapacitu jednoho a konkrétního jádra procesoru s konkrétním návrhovým bodem s konkrétní dobou cyklu; tomuto referenčnímu systému by byla přiřazena hodnota 1. ECU zhruba představuje výkonovou kapacitu dostupnou v jádře procesoru, i když konkrétního staršího jádra. Je to stabilní, neměnné měřítko kapacity, které na tomto procesoru vykonává určitou kombinaci práce. Dobře, to může pomoci, ale stále ještě nemáte nutně odkaz na svůj svět. Chci říct, kolik svých vlastních transakcí/minutu byste mohli vyrobit s ECU dokonce 1?

Hodnocení jako 13 nebo 26 – nebo jaké máte vy – se určují pomocí několika srovnávacích testů a magických testů výkonu, spuštěných na příslušném hardwarovém prostředí, s výsledky ve srovnání s referenčním systémem. Lidé z Amazonie dobře vědí, že existuje mnoho různých způsobů, jak tyto systémy používat, a jejich výkonnostní prostředí si některé z nich vyzkouší. Uvědomte si však, že mezi nimi mohou existovat značné relativní odchylky od pracovního zatížení k pracovnímu zatížení a ještě více, jak přecházíme od systému k systému. Jak se říká: "Vaše výsledky se mohou lišit." Tato hodnocení ECU jsou výsledkem kombinace zvoleného pracovního zatížení; kterákoli z pracovních zátěží může nebo nemusí produkovat dvojnásobnou propustnost na 26 oproti 13. Používají tedy mix; mohli by zveřejnit všechny své výsledky, ale všichni chceme rychlou referenci o relativní kapacitě, jako jsou ECU. Přesto je to dobrý přístup, pokud to, co hledáte, je jednočíselné vyjádření relativní kapacity.

Vysvětlení trochu dále: I při použití jediného jádra existuje mnoho způsobů, jak lze dosáhnout daného hodnocení; prostřednictvím hardwarové technologie, doby cyklu, jemnozrnného paralelismu, velikosti a topologie mezipaměti, šířky pásma sběrnice, rychlosti paměti a tak dále. Také bychom mohli zhruba zdvojnásobit kapacitu z 13 na 26 zdvojnásobením počtu jader. Opět platí, že takové rozdíly v designu mohou znamenat rozdíly ve výkonu konkrétních úloh.

To je AWS. Jiné systémy se pokoušejí reprezentovat svou kapacitu systému pomocí jiných koncepčně podobných hodnocení. (Jako příklad, z mého vlastního prostředí IBM Power Systems, existuje CPW, zkratka pro Commercial Performance Workload a volně založený na online testu zpracování transakcí TPC-C.) Některé nabízejí podstatně jemnější granularitu kapacity vaší instance. A to je to, co kupujete, kapacita instance OS, obvykle zlomek kapacity celého jediného SMP. Jde tedy o to, že s ECU skutečně získáváte vyjádření zlomku celkové kapacity dostupné v rámci nějakého většího fyzického systému SMP. Instance OS, kterou si zakoupíte, sdílí stejný hardware – alespoň na chvíli – s několika dalšími instancemi; každý získává část této celkové kapacity. Jak již bylo zmíněno, úkolem cloudové služby je částečně určit, jak je nejlépe sbalit s ohledem na kapacitní požadavky každé takové instance.

Na rozdíl od ECU má AWS další metriku, kterou nazývají vCPU, zkratka pro virtuální CPU. Jiné mají příbuzné pojmy jako VP (virtuální procesor). Budu používat oba termíny zaměnitelně. I toto je abstraktní pojem. Co to není, je nějaké konkrétní jádro v rámci nějakého SMP, které instance vašeho operačního systému uchovává na dobu neurčitou. Každý VP je místo toho abstraktní entita, které OS přiděluje práci (aka, práce je úkol nebo vlákno). Když se zjistí, že VP vašich operačních systémů do něj byla odeslána práce, tento VP se následně na určitou dobu přiřadí k jádru. Rozdíl se v tomto bodě může zdát nenápadný, ale je důležitý pro výkon způsoby, do kterých se za chvíli dostaneme. VP není jádro, je to abstrakce procesoru.

Když tedy říkáte, že vaše instance operačního systému má – řekněme – čtyři vCPU, ve skutečnosti říkáte, že váš operační systém zná čtyři entity, kterým může odesílat úlohy. Neznamená to, že váš operační systém má v tu chvíli čtyři konkrétní jádra – a kapacitu, kterou představují – na kterých mohou vaše úkoly provádět své instrukční toky. VCPU místo toho představuje maximální možnou úroveň paralelismu procesoru SMP. Hodnocení vCPU čtyři znamená, že operační systém může mít čtyřikrát více souběžně prováděných úloh, než je možné u OS s počtem vCPU jedna.

Počet VP svým způsobem také představuje maximální kapacitu v tom, že operační systém se čtyřmi VP je omezen na počet souběžně a nepřetržitě prováděných úloh; nezískáte větší propustnost, než je k dispozici při stálém běhu se čtyřmi VP, stejně jako nezískáte více, než když běžíte nepřetržitě na čtyřech jádrech. Pokud neexistovala žádná představa o ECU a pouze počet vCPU představující kapacitu, hodnota vCPU 4 říká, že máte kapacitu až čtyř souběžně prováděných úloh, pokud jsou nepřetržitě prováděny. Hodnota kapacity ECU se pak stane limitem kapacity nižším, než je toto maximum založené na vCPU.

Stojí za zmínku, že to, co představuje VP nebo vCPU, je u poskytovatelů nekonzistentní. Brzy se do toho dostaneme – a související důležité efekty na výkon – jak později probereme vícevláknové technologie, ale někteří VP jsou spojeni s kompletními jádry a jiní jsou spojeni s hardwarovými vlákny vícevláknových jader.

Na závěr této části byly nastíněny dva koncepty:

Můžete si pronajmout výpočetní kapacitu představující určitý zlomek celkové výpočetní kapacity některého jednotlivého SMP.

Můžete určit úroveň paralelismu SMP; kolik úloh lze provádět současně.

Vždy si ale představte, že existují další instance operačního systému, jako je ta vaše, které mohou – nebo nemusí – sdílet stejné prostředky procesoru.

CO JE PROCESOR?

Dřív bylo, že termíny – Procesor nebo CPU – byly docela dobře srozumitelné. Ale jak hardwarové, tak softwarové změny způsobily, že obojí je poněkud špatně definované a často zneužité. Zvažte SMT (Simultaneous Multi-Threading) nebo zhruba analogický Intel Hyper-Threading. V obou z nich je umožněn lépe definovaný pojem procesorového jádra, který mu umožňuje současně provádět více toků instrukcí. Namísto toho, aby byly úlohy/vlákna odesílány jednotlivě na jádra procesoru, lze tato jádra považovat za souběžně provádějící instrukce jménem více vláken.

Tak proč to zmiňovat v diskusi o virtualizaci? Odpovězte na toto: Co je VP nebo vCPU? Je VP jádro se všemi svými hardwarovými vlákny SMT pohromadě, nebo je VP jediným hardwarovým vláknem, jedním z více v jádře? V druhém případě VP představuje provádění jediného toku instrukcí; v prvním případě VP představuje toky instrukcí více úloh.

Vzhledem k tomu, že neexistuje žádný rozdíl ve výkonu, lze otázku považovat za diskutabilní. Ale je tu rozdíl a je dost podstatný.

Jako převážně koncepční příklad si vezměte následující příklad převzatý z obrázku představujícího zvýšení propustnosti u procesoru Power8, který má až osm vláken na jádro. Z hlediska celkové propustnosti má každé jádro podstatně větší kapacitu – větší potenciál propustnosti – díky 8cestnému SMT (aka SMT8); jádro Power8 může podporovat až 8 vláken. Ta extra kapacita je dobrá věc. Všimněte si ale také propustnosti referenčního vlákna – řekněme toho modrého – protože nejprve začíná samostatně na jádře (tj. pruh vlevo) a poté sdílí stejné jádro s jedním, pak třemi a poté sedmi dalšími. vlákna. Individuální propustnost tohoto vlákna výrazně klesá. Toto je zcela normální chování; každé vlákno může být pomalejší, ale kvůli SMT se alespoň spouští; stejné vlákno by nemělo žádnou propustnost během doby, kdy čeká na „vlákno SMT“, pokud by taková schopnost SMT neexistovala.

power8-threading

Proč tedy tento tutoriál? Pamatujete si otázku? Je vCPU spojeno s kompletním jádrem – zde může podporovat až 8 vláken – nebo je vCPU spojeno s jedním vláknem SMT – jedním z až osmi na každém jádru? Pokud je to druhé, fyzické jádro pak také podporuje více vCPU; znovu si připomeňte, že při definování nové instance OS definujete také maximální počet VP/vCPU, které hodláte použít. Takže pokud jste zadali dva VP, dostáváte se na kapacitu dvou jader nebo dvou vláken SMT?

Prozatím řekněme, že vCPU je hardwarové vlákno SMT, nikoli celé jádro (s více vlákny SMT). Předpokládejme také, že máte instanci OS se dvěma vCPU a oběma jsou přiřazeny úkoly, což znamená, že oba chtějí být přiřazeny k „procesoru“. Je zcela možné, že vCPU vašeho operačního systému mohou být přiřazeny k různým jádrům a žádné vCPU jiného operačního systému v tu chvíli tato jádra nesdílejí. Skvělý. Vaše úkoly začínají využívat všechny zdroje těchto jader a v důsledku toho se vykonávají tak rychle, jak jen mohou. Nebo řekněme, že vCPU vašeho operačního systému mohou být oba přiřazeny ke stejnému jádru. Dobře, pokud jsou sami spolu, provádějí oba, ale každý pomaleji než v předchozím případě.

Cloud ale ve skutečnosti není o samotném spouštění v SMP; existují i ​​jiné operační systémy, jejichž vCPU sdílejí stejný systém. Pojďme tedy zvýšit využití systémů a mít zaneprázdněné i ostatní operační systémy. Kde jsou jejich vCPU přiřazeny? Jistě, mohly by být dočasně přiřazeny k různým jádrům, ale jejich vCPU by mohly být přiřazeny ke stejnému jádru (jádrům), kde je v daném okamžiku přiřazeno jedno nebo více vCPU vašeho operačního systému. Ve srovnání se samostatným spouštěním na jádře se s rostoucím využitím systému zvyšuje pravděpodobnost, že vaše vCPU budou sdílet jádra, a proto poběží relativně pomaleji.

Řečeno jinak, předpokládejme, že váš operační systém má právě nyní aktivní pouze jeden vCPU – a tedy pouze jedno vlákno. Můžete očekávat, že toto vlákno by mělo být spuštěno úplně stejně jako modré vlákno v levém sloupci výše. Ve skutečnosti jste tento účinek mohli opakovaně zažít a nevěděli jste o tom; systém byl lehce používán a to byl výsledek. Pojďme tedy – aniž by o tom aplikační vlákno tohoto OS vědělo – zvýšit využití všech ostatních operačních systémů a vCPU na stejném SMP. Vaše vlákno bude stále používat „procesor“, ale nyní mnohem častěji sdílí jádro s řadou dalších aktivních vCPU. Výsledkem je pomalejší provádění. A kvůli očekávané funkční izolaci operačních systémů není ve vašich operačních systémech nic, co by vám dokázalo říct, proč se výkon aplikace zpomalil.

Problém je samozřejmě méně intenzivní s maximálně pouze dvěma vlákny na jádro, ale základní koncept platí.

Je tedy vCPU jádro nebo vlákno SMT? Pro hypervizor ESXi od VMware: „Vzhledem k tomu, že 1 vCPU se rovná 1 CPU, je v zájmu zjednodušení předpoklad, protože vCPU jsou naplánovány na logických CPU, což jsou kontexty provádění hardwaru. Tyto úlohy mohou chvíli trvat v případě jednojádrového CPU, CPU, které mají pouze 1 vlákno na jádro, nebo mohou být pouze vláknem v případě CPU, které má hyper-threading.

VCPU s hypervizorem ESXi VMware je vlákno SMT. S IBM PowerVM hypervisorem je pojem virtuálního procesoru (tj. VP) odlišný; VP je spojen s jádrem fyzického procesoru, včetně všech vláken SMT jádra najednou. VP zde není nutně vázáno na konkrétní jádro; dispečer úloh operačního systému přiřadí jednu nebo více úloh VP – jako by to bylo fyzické jádro – a poté hypervizor přiřadí VP dostupnému jádru a v případě potřeby jádro dynamicky uvolní.

Vidíte rozdíl mezi VMware ESXi a IBM PowerVM? S PowerVM stále platí, že jádro může souběžně spouštět jedno nebo více vláken. Ale pokud je více vláken, s PowerVM, všechna vlákna spouštěná na nějakém jádře patří ke stejnému OS. Pokud, řekněme, využití vašeho operačního systému bylo dostatečně nízké na to, aby měl pouze jedno vlákno na VP, tato vlákna se budou spouštět samostatně, a tedy rychleji, když je každý VP také připojen k jádru. S VMware, i když má váš operační systém přesně jedno spouštěcí vlákno – toto vlákno je spojeno samostatně s vCPU – je možné, že toto vlákno sdílí jádro s vCPU(y) jiných OS; zvýšené využití vyskytující se v jiných OS může zpomalit výkon jiných OS.

Ale ani s PowerVM nejsou všechny broskve a smetana. Pokud je VP aktivní i s jedním vláknem, hypervizor přiřadí tento VP k jádru. Tímto zadáním se využívá celá kapacita jádra; žádný jiný VP to pak nemůže použít, i když tam běží pouze jedno vlákno. Jak jste viděli na obrázku SMT výše, s jedním spuštěným vláknem je ve skutečnosti k dispozici docela dost kapacity, ale s tímto přístupem musí zůstat nevyužitá. Celá kapacita jádra pak musí být započítána jako využitá. VMware, který zachází s každým vláknem SMT, jako by to byl jen další fyzický procesor, místo toho přiřadí vCPU (tj. vždy jedno vlákno) kterémukoli dostupnému vláknu SMT v rámci jakéhokoli jádra. Jde o to, že s přístupem PowerVM, protože určitá kapacita může zůstat v jádře nevyužitá, jiná vlákna OS, která by mohla tuto kapacitu využít, místo toho čekají na dostupné jádro. (Zajímavé je, že znám alespoň jeden PowerVM OS – a možná i více – který se pokouší zabalit vlákna do VP až do určitého bodu, aby se tento efekt snížil.)

Spousta detailů, ano, ale vidíte ten zásadní efekt? Výkon vašich operačních systémů se může do značné míry lišit v závislosti na úrovni využití jiných operačních systémů, které sdílejí – a v současnosti sdílejí – stejný systém.