Written by 
- 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 minulém díle jsme si ukázali API a doufám, že vás to inspirovalo k přemýšlení co všechno je díky němu možné realizovat nad ním. Ještě než ho ale začneme využívat ukažme si ještě jeden velmi důležitý koncept – message bus.
Nemusíte řídit, jen poslouchejte co vás zajímá
Představte si následující scénář. Máte řešení typu Blade, kde je integrovaný propojovací prvek. Ten je připojen do sítě. V okamžiku kdy vytvoříte síťový profil s nějakou VLAN, je nutné tuto VLAN také přiřadit na správné porty v externí síti. Co kdybychom to zautomatizovali?
Pokud používáme API máme možnost pravidelně načítat seznam síťových profilů a jakmile se objeví nějaký nový načíst ho, zjistit si VLAN a tu nastavit na externím prvku. To by šlo, ale takové pravidelné načítání asi nebudeme dělat každou vteřinu, takže bude docházet ke zpoždění, zbytečné komunikaci a celkově to nebude nijak hezké.
Potřebovali bychom se tedy asynchronně dozvědět, že právě teď vznikl nebo byl přiřazen nový profil. Mohli bychom možná poslouchat syslog. To je ale také velmi nepratické. Museli bychom posílat syslog do každé aplikace, která má zájem. Hlášky bychom dostávaly všechny (zbytečně) a museli je filtrovat, což se v tomto případě dělá jen parsováním textu (není to nejspolehlivější). Navíc v syslog hlášce je málo informací, takže zjistíme třba jen jméno profilu a musíme se napojit, vyhledat ho a pak teprve se dostaneme k jeho URI, kde si přečteme co potřebujeme. Syslog také není ideální.
Hledáme tedy něco, co nám umožní zaregistrovat se k odběru zpráv, které nás zajímají. V našem příkladu chceme dostávat informace o změnách v connection profilech, ale nic víc. Chceme, aby tato zpráva byla obsahově bohatá, tedy byly v ní informace o URIl o změnách které se nad profilem provádí a ideálně aby to bylo ve formě datové struktury (např. JSON) a ne jen holý text. Takové řešení si dnes ukážeme.
A mimochodem – ten příklad má praktickou implementaci. Takhle totiž funguje integrace OneView a HPE iMC (nástroje pro správu sítě různých výrobců) nebo OneView a Arista (výrobce prvků).
OneView Message bus
Interní fungování OneView využívá asynchronního zpracování a ve svém srdci má message bus. Tím se jednotlivé části systému informují o událostech a změnách stavu. Tato sběrnice je otevřená a vaše aplikace či skripty z ní mohou také číst. Informace včetně příkladů pro programátory v Java a Python najdete v online dokumentaci vaší OneView appliance:
Tento message bus je postaven na standardu AMQP a k dispozici jsou ve OneView dva. Jeden je zaměřen na informace o změnách stavu různých částí systému (State-Change Message Bus) a druhý na sběr metrik (Metric Streaming Message Bus).
Například v rámci SCMB jsou všechny zprávy kategorizované a můžete se zapsat buď k odběru všeho nebo jen určitých informačních okruhů:
- scmb = dostáváte všechno
- scmb.server-profiles = dostáváte pouze události týkající se serverových profilů
- scmb.server-profiles.Created = dostáváte pouze události vytváření serverového profilu
- scmb.server-profiles.Update./rest/server-profiles/04eda0fc-b59d-4110-9a99-738b232e5509 = dostáváte informace o události typu změna jednoho konkrétního profilu
Co tedy můžete dostávat? Prakticky všechny události. Zapnutí, vypnutí, restart serveru. Zasunutí nové žiletky do šasí. Přiřazení profilu k serveru. Dokončené nabootování serveru. Dokončený provisioning jeho OS (s HPE ICsp integrací nebo v HPE Synergy s Image streamer). Alokace či vytvoření nového síťového propojení nebo SANky. Vznik nebo snapshot Volume ve storage a tak dále.
Vyzkoušejme si
Příkady pro programátory jsou ve zmíněné dokumentaci, my raději použijeme testovací utilitku, kterou vyvinuli lidé z kompetenčního centra. Nemusíme ji nijak instalovat, stačí mít Docker hostitele a spustíme si ji v kontejneru:
docker run --rm --name ovmq -p 8888:8080 didierlalli/hpovmessagebusexplorer
Teď v tomto Docker hostiteli najdete testovací aplikaci na adrese:
http://localhost:8888/HPEOVMsgBus/
Nejprve vyplníme údaje pro přístup do naší OneView appliance.
Zaregistrujme se třeba k odběru informací o hardware.
Vygenerujeme nějakou akci, například zapneme jeden ze serverů.
Prozkoumejme jaké jsme dostali zprávy.
Můžeme se podívat na podrobnosti v JSON formátu – najdeme tam detaily dané události.
První hláška říká, že se začalo pracovat na vypnutí serveru.
A druhá, že bylo dokončeno.
Tímto způsobem tedy můžete poslouchat to, co vás zajímá. Například HPE iMC, aby mohlo nastavit VLAN v externím prvku, rozhodně zajímá situace, kdy k serverovému profilu přidáme spojení ven.
iMC si registruje tento okruh zpráv, takže se události dozví.
