Kategórie
Novinky Technológie Zákulisie

Ako pokračujeme s novou architektúrou

Doba čítania: 5 min.

Ubehlo približne 11 mesiacov, odkedy sme započali zatiaľ náš najkomplexnejší projekt kompletnej reorganizácie celého IT. Veríme, že v niektorom z nasledujúcich blogov sa dostaneme k detailom dizajnu a samotnej histórii tohto projektu. Dnes sa však zameriame na aktuálny stav.

Nový hardvér, o ktorom ste sa mali možnosť dozvedieť z blogu, k nám dorazil už začiatkom júna. Celá jeho kompletizácia trvala cca mesiac, pričom výsledok je nasledovný:

rack

Nová architektúra však nie je len o novom hardvéri. Nový hardvér je len časťou celej mozaiky, ktorá zahŕňa nasledovné prvky:
– nový hardvér
– virtualizácia / logická infraštruktúra
– konfiguračný manažment
– admin team/change manažment

Už nejakú dobu, obzvlášť však ostatné dva mesiace, pracujeme hlavne na konfiguračnom manažmente, automatizácii a virtualizácii. Pre tieto účely sme boli nútení osvojiť si množstvo nových technológií. Za všetky spomeniem CFEngine3 a OpenStack. Bolo ich však podstatne viac.

Naším cieľom je dosiahnuť automatické vygenerovanie celého systému na nových serveroch, od automatizovanej inštalácie fyzických serverov, cez inštaláciu OpenStacku až po vytvorenie logickej infraštruktúry z virtuálnych serverov pre službu zdieľaného hostingu. Všetko sa to udeje na základe „programu“, ktorý píšeme v jazyku CFEengine3 a predstavuje tak akési DNA nového IT.

Tieto pokusy prebiehajú počas integračného testovania, ktoré prebehlo v auguste už trikrát, pričom každým ďalším pokusom sme dosiahli vyššiu mieru automatizácie. V súčasnosti sme na prahu štvrtého integračného testu, kde už bude doplnená posledná chýbajúca súčasť – automatizovaná inštalácia OpenStacku.

Len pre predstavu: inštaláciu fyzického servera s OS Ubuntu minimal sme boli schopní pomocou automatizácie skrátiť na úroveň 3 minút oproti približnej polhodine a viac, keď sa všetko robilo ručne. Tu sa ukazuje sila automatizácie – 10-násobné skrátenie času bez ľudského zásahu výrazne šetrí čas a znižuje náklady.

OpenStack
OpenStack zažíva v tomto období obrovský rast a denne do jeho projektov pribudnú stovky zmien od jeho vývojárov. Je to komplexný balík projektov, ktoré nie je vôbec jednoduché rozbehať na produkčnú úroveň, i keď existujú rôzne one-click inštalácie. Častokrát je nutné čítanie zdrojových kódov ako dokumentácie, fixovanie rôznych bugov vlastnými alebo už existujúcimi patchmi. Na produkčné nasadenie je nutné prekonať množstvo problémov a naučiť sa rozumieť OpenStacku, čo trvá obyčajne niekoľko mesiacov. U nás toto zoznamovanie prebieha už približne 4-5 mesiacov.

V prípade produkčného nasadenia v rozsahu WebSupportu je nutné zvážiť, čo potrebujeme a čo nie. Najkomplikovanejší sa ukázal byť networking, resp. projekt Neutron, ktorý je určený na vytváranie tzv. Software Defined Network. Tie umožňujú vytvárať rôzne virtuálne siete, vzájomne oddelené pre rôznych tenantov. Tenantom sa chápe niekto, kto má vyhradenú iba časť zdrojov z cloudu.

Zo začiatku neplánujeme poskytovať priamy prístup k API OpenStacku zákazníkom, ale dúfame, že v blízkej budúcnosti to doriešime.

horizon

Networking je však jediná vec, ktorá nás spája so starým IT, takže nezačíname na zelenej lúke, ale musíme byť spätne kompatibilní. Neutron nám to neumožňoval a pre pridanú komplexnosť a nie úplnú pripravenosť sme sa rozhodli SDN aktuálne nepoužiť. Myslíme však na budúcnosť, takže sme premysleli, ako by sa to dalo neskôr zapracovať.

Ďalším prípadom na zváženie bol výber použitia diskového systému na ukladanie obrazov inštancií. V OpenStacku sú možnosti použiť ne-perzistentné diskové obrazy cez aplikáciu Nova alebo perzistentné cez aplikáciu Cinder. Keďže Cinder sa dá prepojiť priamo s diskovým poľom NetApp, voľba je jasná.

Často sa stretávame s názorom, že samotný OpenStack je akási forma virtualizácie. To nie je úplná pravda, vzhľadom na to, že o virtualizáciu sa stará hypervízor ako Xen, KVM a pod. OpenStack je súbor programov s definovaným rozhraním (API), ktoré zabezpečujú orchestráciu (riadenie) procesov v súvislosti so životným cyklom virtuálnych serverov. To, aký hypervízor je použitý, je vyslovene na používateľovi.

Niekoľko rokov už používame na túto orchestráciu súbor vlastných skriptov, ktoré však nie sú také komplexné ako OpenStack, ktorý vyvíjajú stovky vývojárov.

Dlho sme riešili výber medzi Xenom a KVM. Vzhľadom na dlhoročné skúsenosti so Xenom sme boli dlho naklonení tejto alternatíve. Integrácia a podpora KVM do OpenStacku sa však ukázala ako kľúčová, a tak sme sa priklonili ku KVM.

Vytvorenie paralelnej IT infraštruktúry pre nás znamená aj možnosť zahodiť niektoré verzie programov a nahradiť ich novými. K zmene dôjde nasledovne:
– databázy MySQL 5.0 a 5.1 budú presunuté na MariaDB 5.5
– medzi podporované PHP pribudne PHP 5.5
– rušíme podporu eacceleratora a nahradíme ho xcache
– meniť verziu PHP nebude možné cez .htaccess súbor, ale len cez webadmin rozhranie
– v prípade virtuálnych serverov prechadzame zo Xenu na KVM

Všetkým používateľom zároveň odporúčame upgradeovať na verziu PHP 5.3 a vyššie a v prípade MySQL databáz na verziu 5.5 .
Verzie:
– MySQL 4.0,4.1
– PHP 4.4.9

Na hostingu budú použiteľné aj naďalej, avšak nebudú mať k dispozícii toľko zdrojov ako novšie verzie. O všetkých detailných zmenách a samotnej migrácii budeme samozrejme informovať.

9 odpovedí na “Ako pokračujeme s novou architektúrou”

Fajn, že to posuvate na next level. Automatizacia procesov je dnes krok k uspechu // nie len pri administraci, ale aj pri vyvoji SW

Mohli by ste napisat potom nejaku technickejšiu retrospektivu aby sme sa poučili z vašich chyb 🙂

no drzim palce …osobne si myslim ze ste sa pustili do vod neprebadanych….nam vyslo najlepsie z dlhodobeho hladiska vmware + puppet + foreman + jenkins co sa da tak nad gitlabom. management + upgradability je imo o kus inde…ale drzim velmi palce..ked to dotiahnete do stavu ze to bude stabilne odladene a upgradovatelne..bude to imo skvele!

Mame este v plane napisat blogov kde sa detailne budeme venovat jednotlivym dizajnovym rozhodnutiam. vmware bol dlho v plane, ale nevedeli sme postavit biznis plan tak, aby cisla vychadzali dobre, zaroven nam nevyhovoval licencny model ktory by nas nutil bezat dva vmware klastre. Vyber openstacku bol, tak ako vsetko ostatne, kalkulovany risk.

Puppet sme zvazovali a skor aj trochu pouzivali. Problemom sa nam o.i. zdala spotreba zdrojov a ruby zavislosti, co moze byt na malych systemoch typu VPS V1 problem . My sme skor Cckari.

gitlab vsak pouzivame tiez 🙂

Chystáte nejaké zmeny čo sa týka Ruby on Rails hostingu? Ruby 2, celkovo lepšia podpora RoR v hostingu, a podobne?

Nie, aktualne je su vsetky zdroje urcene na tento projekt a support (helpdesk), takze najblizsie mesiace urcite nie.

Vyborne, hlavne co sa tyka skusenosti. Technologiu si clovek pozrie ale rozhodnutie castokrat zavisi na detailoch pri prevadzke. Vdaka, usetrili ste nam vela casu.

Presne, preto sa spravnost resp. nespravnost rieseni ukaze casto az po nejakom case (mesiace/rok) .

Pridaj komentár

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *