Ak šéfuješ ľuďom, čo majú na starosti diskové polia, denne bojuješ s tým, ako zabezpečiť beh systémov v rámci svojho prideleného rozpočtu. Každý technický problém ťa stojí peniaze.
Každý výpadok spôsobený ľudskou chybou ťa štve o to viac.
A pri eliminácii ľudských chýb bojuješ s nasledovnými problémami:
- Nemožnosť prideliť obmedzený admin prístup menej skúseným členom tímu
- Neodhalené preklepy v názvosloví spôsobujú nefunkčnosť reportov
- Nejednotná konfigurácia diskových polí
Vo väčšine firiem tieto problémy nikto nerieši. Nie je na to čas, chuť a často presvedčenie, že riešenie je extrémne drahé a tým pádom nie sú ani peniaze.
Riešenie je však relatívne jednoduché a prekvapivo lacné.
Dovoliť konfiguráciu storage adminovi bez skúsenosti?
Slabá granularita admin práv ti zvyšuje náklady na budovanie storage tímu.
“Nemôžem mu povoliť prístup na diskové pole. Nemá všetky školenia a ešte sa nezapracoval. Čo keď nejakému zákazníkovi utrhne živé disky?”
Poznáš ten stav. Šéfuješ storage oddeleniu. Máš tam pár nových ľudí. Tí starší a skúsenejší sa venujú riešeniu problémov, dizajnu, plánovaniu. Tých mladších by si rád použil na bežné úkony typu “zákazník potrebuje okamžite 100GB diskov”. A potrebuje ich hneď, často v noci alebo cez víkend.
Vendori diskových polí kašlú na granularitu práv.
V čom je problém? Diskové polia a FC prepínače bežne umožňujú definovať užívateľov s rôznymi úrovňami prístupových práv. Ich granularita je však mizerná. Jedna úroveň má read-only práva, ďalšia hneď plný admin prístup.
Sú platformy, kde je možné definovať užívateľské “role” a explicitne vymenovať príkazy, ktoré pre danú “rolu” sú povolené. Problém je však v syntaxi príkazov.
Pokiaľ by platforma umožňovala syntax:
create lun | share | zone | interface | …
modify lun | share | zone | interface | …
delete lun | share | zone | interface | …
Riešenie by bolo jednoduché. Menej skúsený operátor by mal oprávnenie len na príkaz “create”. V najhoršom by vyrobil LUN nesprávnej veľkosti a namapoval by ho na nesprávny server.
Oprávnenia na príkazy “modify” a “delete” by mali len skúsenejší užívatelia.
V mojej praxi som sa však stretol len so syntaxou typu:
lun create | modify | delete
share create | modify | delete
zone create | modify | delete
…
Takže ak má užívateľ oprávnenie na príkaz “lun”, môže s ním robiť úplne všetko.
A to hovorím o platformách s možnosťou jemného ladenia užívateľských rolí. Väčšinou je to však len “read-only” alebo “full admin”.
Malý vysoko kvalifikovaný tím alebo veľa ľudí s chýbajúcimi školeniami?
Sú dva spôsoby riešenia.
Máš malý team špecialistov, ktorí sú zodpovední za kompletnú storage administráciu. Všetci sú kvalitne vyškolení a skúsení.
A extrémne preťažení.
Aj tá najmenšia prkotina vyžaduje čas vysoko-kvalifikovaného špecialistu.
Alebo máš rozsiahle oddelenie. Dokonca delené na operatívu (vykonávajúcu bežné úlohy a zákaznícke požiadavky) a “backline”. Keďže všetci majú plné admin práva na všetky storage platformy, musíš všetkých vyškoliť na všetky typy diskových polí a FC prepínačov.
Je to drahé.
Je, ale výpadok zákazníckych služieb spôsobený neodborným zásahom je ešte drahší.
Iná možnosť nie je.
Teda vlastne je. Čítaj ďalej.
Preklep spôsobí vadné kapacitné reporty
Pár preklepov znehodnotí tvoje storage reporty a znemožní správne rozhodovanie.
“Kapacitné reporty nesedia pretože v názvoch grúp máme občas preklep a nesedia nám s názvom servera”.
Drahý reporting SW “zničí” pár preklepov v názvoch
Používaš kvalitný a drahý reporting software. Ale reportom nemôžeš úplne dôverovať, pretože vieš že sú tam chyby.
Klasický príklad - report pridelenej kapacity pre každý server je založený na súčtu veľkosti LUN-ov v hostgrupe, ktorá má rovnaký názov ako meno servera (alebo je meno servera súčasť názvu hostgrupy).
Pokiaľ admin urobí chybu v názve hostgrupy, report pre daný server nezobrazí žiadnu kapacitu.
Pri malom počte serverov si to všimneš, ale ak ich množstvá idú do tisícov, zostanú nezistené aj niekoľko rokov. A ak to aj časom zistíš, opravu musíš riešiť ako plánované zmeny, pretože sa jedná o zásah do produkčného prostredia
Systém, čo nedovolí preklep?
Predstav si systém, ktorý ti nedovolí vyrobiť nesprávne názvy. Dokonca sa ani nepomýliš v názve servra.
Náš magický systém si z tvojho Remedy/Siebel-u/ServiceDesk-u vytiahne zoznam otvorených tiketov vo fronte svojho tímu, kde sa žiada o pridelenie kapacity pre nových server, a tvoj admin len zvolí jeden zo serverov takéhoto limitovaného zoznamu.
Veľkosť LUN-u bude na výber z preddefinovaného zoznamu, pokiaľ tvoje procedúry stanovujú len určité veľkosti. Navyše sa nestane, že namiesto 50GB vyrobíš omylom 50TB LUN.
Podobne takýto magický systém zariadi, že sa najskôr prihlási na server kam chceš priradiť disky, vezme si WWN FC kariet priamo zo servera, takže môžeš mať istotu že FC zóna bude obsahovať správne iniciátory.
Nejednotná konfigurácia?
Cenu za nejednotnú konfiguráciu zistíš, až niečo dôležité “padne na hubu”.
“Upgrade je komplikovaný pretože každý node diskového poľa má inú konfiguráciu.”
“Failover sa nepodaril, pretože na druhom node neboli nakonfigurované všetky služby”.
Robíš audit konfigurácií?
V svojej praxi som túto situáciu zažil niekoľko krát. Nastúpil som do novej firmy, urobil audit produkčných storage systémov a zistil že každý má inú konfiguráciu.
Dokonca každý node failover konfigurácie mal rôzne nastavenia, takže v prípade kritickej situácie by failover pravdepodobne nenastal.
Z operatívy sa nikomu do nápravy nechcelo, pretože sa sa jednalo o zásah do produkčných systémov.
Áno, jasne.
Máš presne zdokumentovanú procedúru ako nakonfigurovať každé nové diskové pole, FC prepínač. U teba žiaden problém nemôže nastať.
Ale môže. Admin omylom vynechá príkaz pri úvodnej konfigurácii alebo počas riešenia technického problému vendor zmení niektorý parameter, ale nikto už potom danú zmenu neprenesie na ostatné nody.
Najhoršie je, že ani nevieš, kedy a kto danú zmenu vykonal. Auditing väčšinou nikto nezapína, pretože generuje na diskových poliach veľké logy.
Ako na plánované konfiguračné zmeny?
Máme tu však náš magický nástroj, ktorý pre každý nový systém neomylne pošle tú správnu sadu konfiguračných príkazov, takže máš istotu že naozaj máš jednotné prostredie.
A dodatočné zmeny? Či už plánované alebo ad-hoc od vendora pri hasení problému?
Tam navrhujem dva možné prístupy.
V tom prvom všetky konfiguračné zmeny vykonávaš pomocou nášho “magického” nástroja. Môžeš zmeniť konfiguráciu viacerých zariadení naraz. Systém uchováva informáciu kto a kedy zmenu vykonal, navyše je možné pridávať referencie do interného systému tiketov alebo textovú poznámku s uvedeným dôvodom na zmenu.
Tento systém nie je moc vhodný, pokiaľ technik vendora sedí priamo za konzolou a skúša množstvo zmien, z ktorých niektorá snáď vyrieši problém.
Vtedy príde vhod druhý - aj keď zložitejší - systém.
V pravidelných intervaloch sa konfigurácie všetkých systémov ukladajú do centrálneho úložiska. Každá zmena voči predošlému stavu vygeneruje incident v tvojom tiket systéme (Remedy/Siebel/ServiceDesk/…).
Incident je buď riešený ako neoprávnená zmena a konfiguráciu je potrebné uviesť do pôvodného stavu alebo sa potvrdí správnosť zmeny s uvedením dôvodu a osoby, ktorá za zmenu zodpovedá
Momentálne neviem o žiadnom takom hotovom systéme a plánujem si ho vytvoriť sám. Ak vieš o niečom hotovom, daj mi prosím vedieť.
Prípadný záujem o môj systém má tiež poteší a urýchli vývoj.
Požiadavky na náš “magický” systém
Už vieme, že potrebuješ nejaký magický systém, čo ťa zachráni. Čo by však mal vedieť? Skúsme to dať dohromady:
- Systém umožní vykonať len presne definované príkazy s presne definovanými a overenými parametrami (to zabráni neúmyselnému zmazaniu alebo zmene existujúcich nakonfigurovaných objektov)
- Pokiaľ je to možné, systém poskytne parametre na výber zo zoznamu (to zabráni preklepom)
- Zoznam môže byť statický (povolené veľkosti LUN-ov)
- Zoznam môže byť dynamický (zoznam serverov čakajúcich na prvotnú konfiguráciu)
- Systém musí ošetrovať vstupy, navrhovať správne názvoslovie
- Systém nesmie dovoliť vykonať príkaz, na ktorý daný užívateľ nemá oprávnenia
- Systém musí vedieť získavať dáta z iných zdrojov
- Systém musí vedieť vytvárať grupy užívateľov, ktorým sú autorizované jednotlivé procedúry
- Systém loguje vykonanie každej procedúry s uvedením času, užívateľa a výsledného stavu ukončenia
Ďalej nasledujú vlastnosti, ktoré by bolo fajn, keby ich systém mal. Nie sú kritické z pohľadu funkčnosti, ale je fajn ich mať:
- Prihlasovanie účtom z ActiveDirectory alebo LDAP
- Možnosť definovania základných funkcií, ktoré je možné spájať do komplexných “workflows” (na toto fakt neviem dosť dobrý preklad)
- Možnosť podmienených operácii (ak neexistuje, vytvor)
- Vizualizácia celej procedúry
- Web GUI (nech nie je potrebné inštalovať platformovo závislú aplikáciu pre každého admina)
- Možnosť definovať vstupné formuláre
- Možnosť bodu uprostred procedúry, ktorý na pokračovanie vyžaduje schválenie užívateľa s vyššími privilégiami
(Možno tento zoznam budem priebežne dopĺňať. Uvítam tvoje nápady.)
Dá sa takýto systém postaviť? Ale on vlastne existuje.
Automatizácia alebo workflow
Skloňované vo všetkých pádoch, ale skoro nikým nepoužívané.
(Google AdWords tvrdí, že “storage automation” je hľadané asi 70 krát mesačne a hľadanie “storage workflow” je pod prahom záujmu Google.)
Automatizácia vytvárania virtuálnych servrov, Oracle databáz,…
Ale automatizácia poskytovania storage kapacity? Do toho sa nikomu nechce.
Nemáš sa ale čoho báť.
Pokiaľ nešéfuješ úplnej anarchii, máš na každú operáciu zdokumentovanú procedúru, definované názvoslovie.
Jednoduchá cesta - existujúce procedúry “obaliť” skriptom
Jednoduchá, lacná ale pritom efektívna cesta k storage automation je pár dobre napísaných skriptov.
Pokiaľ na všetky úkony používaš textové príkazy, máš vyhrané.
Dáš ich dohromady v správnom poradí a obalíš nejakým skriptovacím jazykom.
To je všetko.
Áno, takéto jednoduché to je.
Pokiaľ v svojich postupoch využívaš klikanie v manažment GUI, budeš to musieť najprv zmeniť na verziu s príkazmi.
Užívatelia sa nebudú prihlasovať na diskové pole alebo FC prepínač. Užívateľ sa prihlási na tvoj server, kde mu bude povolené spustiť len konkrétne skripty.
Viem, na čo teraz narážaš. Keď užívateľ môže spustiť skript, ktorý sa na diskovom poli spustí príkaz, môže sa na to pole dostať aj ten užívateľ, nie?
Pokiaľ ideš jednoduchou cestou, tak áno. Vtedy ide o dôveru, že tvoji ľudia vždy použijú skript a nie príkazy priamo na diskovom poli.
Pokiaľ si paranoidný, je cesta, ako oddeliť efektívneho užívateľa spúšťajúceho skript od toho, čo naozaj vykoná príkaz na diskovom poli. Kontaktuj ma a vysvetlím ti, ako na to.
Zložitejšia, ale komplexnejšia cesta
Keď skripty na storage nestačia, použi hotový WorkFlow systém.
V zozname požiadaviek na náš systém je niekoľko, ktoré nie je úplne jednoduché dostať do jednoduchých skriptov. Vyžaduje to už vyššiu úroveň programovania a v konečnom dôsledku skončíš tým, že si necháš napísať kompletné softvérové riešenie na kľúč.
Aby som ťa od toho všetkého ušetril, mám pre teba už jedno hotové riešenie.
Stop, stop, stop!
Nie, nechcem ti teraz predať drahý softvér, za ktorý dostanem províziu.
Viem o hotovom softvére, ktorý je zadarmo.
Je to softvér vyvíjaný komerčnou firmou, dlhé roky pôsobiacou v oblasti diskových polí, a napriek tomu je zadarmo. Síce jeho zamýšľané použitie je na polia danej firmy, ale jeho krása je, že ním môžeš ovládať čokoľvek.
Prosím bubny!
NetApp OnCommand WorkFlow Automation (WFA)
Slušné riešenie za slušné peniaze? A čo rovno zadarmo?
NetApp WFA je softvér, ktorý - podľa špecifikácie - ponúka:
- Designer portal na vytváranie procedúr (workflows). Designer portal obsahuje stavebné bloky (príkazy, vyhľadávače, filtre, funkcie), z ktorých sa skladá konkrétna procedúra. Umožňuje pridávať špeciálne možnosti ako automatický výber zdrojov podľa zadaných kritérií, opakovanie v slučke, body schvaľovania.
Umožňuje taktiež zbierať dáta z externých systémov a použiť ich počas vykonávania procedúry. - Execution portal na vlastné spúšťanie jednotlivých procedúr, kontrola úspešnosti vykonania a kontrola logov.
- Administration portal na konfiguráciu samotného WFA a na manažment užívateľov.
- Web services interface umožňuje volať nakonfigurované procedúry z externých systémov pomocou REST API.
- Storage Automation Store umožňuje stiahnuť hotové procedúry pripravené buď firmou NetApp alebo širokou komunitou užívateľov.
Systém môže byť nainštalovaný buď na Windows alebo Linux servri.
Procedúry môžu byť v powershell-i (Windows) alebo v perl-e (Windows, Linux). Priaznivci Linuxu budú trochu sklamaní, pretože väčšina NetApp alebo komunitných balíčkov je napísaná v powershell-i.
Pokiaľ ale neplánuješ automatizovať akurát platformu NetApp, budeš si pravdepodobne musieť skripty písať aj tak sám.
Veľmi dôležitá informácia je, že software je zadarmo, nevyžaduje žiadnu licenciu. Je potrebné sa len zaregistrovať na NetApp support webe (http://support.netapp.com) a stiahnuť si požadovaný inštalačný balíček.
V ďalšej časti ukážem vzorovú implementáciu jednoduchej procedúry.
Pokiaľ máš záujem, kontaktuj ma, prosím, na Radovan.Turan@radovanturan.com a ja ťa budem informovať o pokračovaní.
(Čím vyšší záujem, tým bude moja motivácia pokračovať vyššia.)