Infrastrukturní DevOps s HPE OneView

• Infrastrukturní DevOps s HPE OneView (1) – Infrastructure as Code
• Infrastrukturní DevOps s HPE OneView (2) – API
• Infrastrukturní DevOps s HPE OneView (3) – Message bus
• Infrastrukturní DevOps s HPE OneView (4) – PowerShell
• Infrastrukturní DevOps s HPE OneView (5) – PowerShell skripty
• Infrastrukturní DevOps s HPE OneView (6) – Python
• Infrastrukturní DevOps s HPE OneView (7) – Python skripty
• Infrastrukturní DevOps s HPE OneView (8) – vaše vlastní aplikace s Grommet
• Infrastrukturní DevOps s HPE OneView (9) – Ansible a infrastruktura
• Infrastrukturní DevOps s HPE OneView (10) – Ansible a Blade networking
• Infrastrukturní DevOps s HPE OneView (11) – Ansible a síťový fabric
• Infrastrukturní DevOps s HPE OneView (12) – Ansible a servery

Vítejte na startu nového seriálu na cloudSvět, který se zaměří na DevOps v infrastrutuře. Při vývoji a provozu aplikací se stala automatizace klíčem ke zvýšení rychlosti a především zajištění opakovatelnosti, udržitelnosti, konzistence, bezpečnosti a kvality. S příchodem cloudových nástrojů jsme se naučili využívat podobných principů v mračnech cloudové virtuální infrastruktury a přišel trend známý dnes jako Infrastructure as Code. Díky nástroji OneView se konečně něco podobného dostává do světa té infrastruktury skutečné, do hardwaru, který je chloubou vašeho datového centra.

Podívejme se nejprve co Infrastructure as Code je a jak k němu přistupuje HPE a pak si nastíníme, co vás v tomto seriálu čeká.

Infrastructure as Code

Víte co se dá dělat s kódem? Můžete ho například verzovat. Držíte si kopie kódu v různých stádiích a jste kdykoli schopni vyvolat jeho jakoukoli předchozí podobu, provést downgrade či upgrade. Můžete na něm spolupracovat – snadno se sdílí a kód může psát víc lidí a systémy typu Git udržují konzistenci a umožňují spolupráci a změnové řízení. Kód se také dá testovat. Ještě než ho pošelete do produkce, spustíte si ho a můžete automatizovat některé testy, které poznají, zda jste tím aplikaci rozbili nebo ne. Kód je také svou vlastní dokumentací – kdo mu rozumí, zjistí přesně, co se děje. V moderním světě se prakticky nemůže stát, že by zdrojový kód (dokumentace) neodpovídal tomu, co běží (protože nikdo už dnes do běžícího kódu nezasahuje, jde do zdrojáků a udělá novou verzi).

A co děláme v infrastruktuře? Opak. Své infrastrukturní nastavení obvykle nejsme schopni uložit v nějaké “verzi”, která ji zahrnuje celou (jaké servery, jak propojené, jaké image, jaká data, jakou bezpečnost). Když chceme společně postupovat narážíme na oddělené světy lidské i technologické a buď naše akce vedou k problémům (jedna skupina té druhé něco “ustřelí”) nebo k zmražení změn a nasazení (dnes snad už víc a víc překonané) ITIL organizace, která udělá změny tak neuvěřitelně komplikované a zdlouhavé, že pak raději byznys uteče od svého IT do cloudu. Změny v infrastruktuře většinou moc netestujeme, alespoň ne ve všech souvislostech. Dokumentace je zastaralá a nepřesná (pokud vůbec nějaká) a akční plán před provedením změn je jen neověřeným odhadem. Je neopakovatelná, protože je z většiny manuální (při jejím provádění dojde k odchylkám) a nepřesná. Navíc provádíme změny kódu za běhu – někdo jde a cosi pošteluje. Nic pak není stejné a opakovatelné, vzniká efekt “configuration drift” a to má nejen špatný vliv na rychlost a kvalitu operations, ale také na bezpečnost (není nic horší, než mít 1000 systémů, kdy každý je zcela jiný – má jiné zranitelnosti, jiné attack vektory, jiné opravy).

Co je Infrastructure as Code? Pojďme popsat infrastrukturu tak, že samotný popis slouží jako dokumentace a současně jako předpis, na základě kterého automaty uvedou infrastrukturu do požadovaného stavu (desired state). Nechť ji můžeme verzovat a udělat třeba rollback do předchozího stavu (ne image virtuálky, ale celé infrastruktury – virtuálek, serverů, firewallů, balancerů, storage, aplikací i dat). Připravme si také testovací kód, který bude ověřovat, že stav infrastruktury odpovídá požadavkům a nalezené odchylky opraví. Ať je vše opakovatelné a zavládne maximální míra jednotnosti. Ať nemáme “havarjní procesy” spočívající ve manuální změně něčeho vystresovaným člověkem. Proč máme takový proces? Protože ten normální trvá nekonečně dlouho a není vhodný pro řešení potíží. Změňme to – nechť je běžný proces zavádění změny nejen bezpečný, opakovatelný a vratitelný, ale také rychlý, automatizovaný.

Jak to udělat? Potřebujeme způsob jak popsat infrastrukturu. Něco, co skončí jako jednoduchý dokument (čitelný i pro neprogramátora, nemusí jít nutně o kód v klasickém slova smyslu), podle kterého roboti uvádí infrastrukturu do požadovaného stavu. Aby něco takového bylo možné, musíme mít schopnost infrastrukturu programovatelně ovládat, mít pro ni API. OneView je API pro vaší klasickou, konvergovanou i nejnovější komponovatelnou infrastrukturu. Nad API stavte skripty, roboty, orchestrátory. Ke všemu se v tomto seriálu dostaneme.

OneView a cesta z krabiček přes konvergenci ke komponovatelné infrastruktuře

OneView a rackové servery

Rackový server je do svého okolí připojen různými dráty s různou funkcí, což mu víceméně znemožňuje dramaticky ovlivňovat svojí infrastrukturní konfiguraci a roli. Něco je ale přecijen pro server důležité a programovatelně dosažitelné – nastavení BIOSu, lokálního RAIDu apod. To je do značné míry závislé na tom, co chcete se serverem dělat. OneView vám přináší flexibilitu řešit to bez grafické konzole nebo nutnosti nastavovat parametry server po serveru. Jednoduše si vytvoříte profily těchto nastavení pro různé role serveru v organizaci – některé s RAID 1 (třeba pro hypervisor/OpenStack), některé s RAID 5 (pro databázi), některé bez RAIDu (Hadoop či object store). Někde potřebuje PowerCapping, někde bootování z USB či SD karty, někde musíte mít SR-IOV a vypnutý hyper-threading (třeba síťové aplikace typu NFV), někde potřebujete vypnout UEFI (legacy OS). A jak řešit firmware?

OneView vám i pro rackový server přinese Infrastructure as Code, je to dobrý začátek na cestě k novým konceptům. Reinstalace pěti serverů z jedné role do druhé? Nemusíte se hrabat v útrobách BIOSu a mačkat tlačítka v ten správný čas – přesuňte profil.

OneView a blade servery, konvergence

Konvergovaná a hyperkonvergovaná řešení umožňují sjednotit dříve nesourodé světy výpočetních prostředků (tedy serverů), ukládání dat (storage) a konektivity (co jak je kam připojeno, tedy přístup do fabric – ten zatím typicky není přímo ovládaný konvergovaně zejména v části core, ale i tímto směrem svět postupně jde). Co vám přináší programovatelný přístup v této éře? Jste schopni ovládat infrastrukturu jednotnou sadou API komplexněji, například v případě potřeby vytvořit fyzické servery (včetně jejich rozchození viz předchozí odstavec), ale i logické jednotky ve storage (ať už v klasickém poli typu 3PAR nebo ve storage softwarově definované jako je StoreVirtual), propojit je správným a bezpečným způsobem mezi sebou a namapovat server na správné vstupní místo do fabric ať už po stránce fyzické (které porty) či logické (které sítě).

OneView a komponovatelná infrastruktura

Komponovatelná infrastruktura jako je HPE Synergy jde ještě o kus dál. Vydává se směrem, kdy si automatizovaně přes API nebudou aplikace a “cloudy” sestavovat infrastrukturu jen ze stavebních bloků server, diskový oddíl a konektivita, ale dostanou větší granularitu. Například mnoho datově orientovaných aplikací (object store, NoSQL, databáze, Exchange, Hadoop) má nejraději lokální disky (výkon, latence, cena), ale ty jsme obvykle řešili fyzickým zacvaknutím. V okamžiku nákupu serveru tak musím odhadnout kolik má mít diskových šachet (nechci dávat zbytečně moc, protože přicházím o místo, které může obsadit třeba paměť nebo mi takový design zvyšuje cenu či zhoršuje chlazení nebo spotřebu…ale zase když jich bude málo, budu muset koupit jiný server) a to v dnešním světě odhadovat těžko. Navíc díky automatizaci je zcela reálné, aby se přes den některé servery věnovaly transakčním operacím (denní byznys) a v noci se transformovaly do Hadoopových chroupačů dat s obrovskou lokální diskovou kapacitou. Komponovatelná infrastruktura tohle dokáže – stavebním blokem není server, ale třeba server a disky a mix si dokáže například orchestrátor namíchat dle potřeby sám.

Synergy je také schopno samo provisionovat nejen samotný server, ale také jeho image – a to ne zdlouhavou a nespolehlivou instalací, ale přímo nabootováním immutable serveru ze zabudovaného repozitáře image. Tak jak v cloudu – server se může z čista jasna objevit ve správném stavu, aniž byste museli přepojovat dráty nebo instalovat OS, hypervisor či Hadoop. Jednou šablonou se výpočetního serveru stane softwarově definovaná bloková storage (třeba StoreVirtual), nebo objektová storage (Scality, Swift) nebo chroupač (Hadoop, Spark). Komponovatelný fabric se pak umí vypořádat s daleko víc síťovými úkoly, než je pouhé připojení.

Přidejte k tomu, že nastupují technologie jako perzistentní DIMM a NVRAM. Schopnost seskládat si zdroje ne při nákupu, ale softwarově při provozu, a to s možností měnit tato rozhodnutí každý měsíc nebo i každou hodinu, je pro Nové IT zásadní.

OneView a The Machine, dokonalá komponovatelnost

Kam komponovatelnost směřuje? Grafický procesor (GPU) je pro některé úlohy (logicky ty grafické, ale nejen to – třeba k prolamování šifer) o několik řádů výkonnější (vzhledem k ceně a spotřebě), než dělat totéž v generickém CPU (což samozřejmě lze, ale není to efektivní). S příchodem technologií jako je FPGA (hardwarový transformer čip, který se propojí podle mikrokódu), ARM, SoC a jiných optimalizovaných procesorů bude čím dál důležitější použít ten správný hardware na tu správnou úlohu. Navíc nastupují non-volatilní paměti, které se rychlostí blíží klasické SDRAM, ale mají nižší spotřebu a hlavně data ukládají trvale. Budeme potřebovat plnou komponovatelnost a pružně ji měnit i za života aplikace – přihodit specializované zdroje, přemapovat paměti nebo některé sdílet, přelévat I/O. Na to budeme muset komponenty propojit opticky a zrušit tak vzdálenostní omezení elektrické komunikace. To je projekt HPE The Machine – dokonalá komponovatelnost.

OneView už několik let představuje softwarově definovanou inteligenci a API nad infrastrukturou. HPE Synergy je krokem jak vyvynout hardware nové generace s podporou komponovatelnosti. Budou s vyvíjet dál a přidávat postupně vlastnosti The Machine až bude dosaženo plné komponovatelnosti.

Co si vyzkoušíme v tomto seriálu?

Krok první: API

Každá automatizace začíná v možnosti ovládat systémy způsobem, který je příjemný pro roboty a software. Krásné grafické rozhraní je jistě ideální pro lidské uživatele, ale pro automatizační software je simulace klikání na webu více než nepohodlná. To je důvod proč OneView implementuje moderní rozhraní pro nadstavbové aplikace a skripty – RESTful API. V dalším díle se tedy podíváme co nabízí a vyzkoušíme si s ním pracovat.

Krok druhý: skriptování

API je sadou úloh, volání. Tak jak kliknete na webu a vytvoříte serverový profil, tak můžete zavolat API, aby udělalo totéž. Přestože jde o jednoduchý formát využívající HTTP protokolu a JSON kódování datových struktur, asi není nutné pokaždé znovu konstruovat potřebné hlavičky a parsovat odpovědi. To se dá udělat v nějakém programovacím jazyce jednou a využívat znovu a znovu ve formě knihovny, která vám práci značně zpříjemní. OneView nabízí open source knihovny pro jazyky Python, PowerShell, Ruby, Go či Javascript. My se v seriálu podíváme na Python, což je jeden z nejoblíbenějších a nejjednodušších programovacích a skriptovacích jazyků. Pro příznivce Microsoft platforem možná bude přirozenější PowerShell, takže ten rozebereme také.

Krok třetí: Automated Configuration Management

Psát si vlastní skripty a aplikace je velmi flexibilní, ale vyžadujete to základní znalosti programování. Navíc musíte vyřešit některé další věci – například zajistit opakovatelnost, modularizaci a udělat to tak, aby i vaši kolégové bez programátorských znalostí mohli vaší práci využívat. Možná se tedy raději poohlédnete po nástroji z kategorie Configuration Management, tedy po řešeních, které bez programování dokáží uvést infrastrukturu do požadovaného stavu. OneView má připravené moduly do dvou velmi známých a často používaných – Ansible a Chef. Na oba se podíváme.

Krok čtvrtý: orchestrace

Tím ovšem integrační možnosti nekončí. Třeba budete chtít, aby se fyzická infrastruktura díky OneView stala součástí vyšších nástrojů a umožnila jim se poprvé vypořádat i s hardwarem. Třeba vás osloví Oneview ve formě zásuvného modulu do HPE Helion CloudSystem a Cloud Service Automation. Tak jak ovládáte svoji virtualizaci, on-premise cloud (například Helion OpenStack) či public cloud (AWS, Azure), tak můžete ze stejného nástroje orchestrovat i přímo fyzickou infrastrukturu. A pokud koukáte po nových kontejnerizovaných technologiích vězte, že díky pluginům do Docker si může tento nový svět provisionovat fyzické zdroje. Na to všechno se v seriálu také zaměříme.

Příště už opravdu začneme – povídáme se na OneView API.