Preskočiť na obsah
Kategórie
Novinky Technológie Zákulisie

Sprístupnili sme DNA našej infraštruktúry

Websupport je obrovským “spotrebiteľom” opensource softvéru, bez ktorého by sme nemohli fungovať. Používame desiatky aplikačných serverov, rôzných verzií a nástrojov. Po rokoch pasivity sme sa však aj my rozhodli prispieť opensource komunite zverejnením zdrojových kódov aplikácií, ktoré sme vyvinuli na našej github stránke https://github.com/websupport-sk .

Práca admin tímu vo Websupporte obnáša aj nemalú dávku programovania. Vačšinou ide o jednoúčelové programy, obyčajne o migračné skripty, napísané v jazyku Bash, Python alebo C, ale pozeráme aj po jazyku Go. Stretneme sa však aj s množstvom patchov a modulov do Apache, nginx, memcached, Openstack a pod.

S príchodom novej infraštruktúry pribudlo aj množstvo programovania v jazyku CFEngine, na ktorom je prakticky celá infraštruktúra kompletne postavená, a ktorým je zároveň aj riadená.

Dnes si predstavíme dve najdôležitejšie aplikácie, na ktorých Websupport stojí:

rum

rum je MySQL query router, ktorý skrýva počet databázových serverov, ktoré používame za jednu adresu databázového servera.

V roku 2010 sme sa dostali do stavu, kedy sme museli prejsť z jedného monolitického databázového servera na viac menších, z dôvodu problematického škálovania MySQL 5.0 . Problémom bolo, že tisícky našich klientov malo napevno napísanú adresu tohto databázového servera vo svojich skriptoch ako ‘localhost’,’/tmp/mysql50.sock’,’db50.websupport.sk’ a podobne. Pri rozdeľovaní databázového servera by sme museli premigrované databázy, resp. weby k nim upravovať, čo je prakticky nemožné pri tisíckach weboch.

Preto sme museli tieto adresy databázového servera zachovať a “skryť” celú našu MySQL infraštruktúru za túto jednu adresu. V tom čase však žiadne použiteľné riešenie neexistovalo, takže sme si to museli naprogramovať sami.

Po niekoľkých týždňoch programovania, môj kolega @stanojr rozšíril svoj pôvodný rum, ktorý bol len klasický TCP/IP redirektor, o schopnosť smerovať MySQL spojenia podľa používateľského mena, na konkrétny databázový server. Z tohto dôvodu musíme udržiavať reláciu jedného používateľa na jednu databázu.

Toto bol významný krok, ktorý nám umožnil narásť do dnešných rozmerov. Za jednou adresou databázoveho servera, sa v súčasnosti skrýva viac ako 22. databázových serverov, z každej MySQL verzie 5.0 a 5.1 . Výhodou je aj to, že je možné tieto databázy migrovať medzi týmito databázovými servermi, a tým rozkladať záťaž. O toto automatické distribuovanie databáz, resp. záťaže, sa stará iný náš projekt, s názvom rrhad, z dielne Maťa Čapkoviča (@capkovic).

ocf

Projekt ocf si kladie za cieľ postaviť a udržiavať automatizovane openstackovú a virtualizovanú infraštruktúru na serveroch.

Nám sa pomocou tohto projektu podarilo postaviť hostingovú infraštruktúru Websupportu za približne tri hodiny, plne automatizovane. Proces prebiehal nasledovne:

  1. reštartovali sa prázdne servery, aby sa nabootovali cez sieť
  2. po nabootovaní sa nainštalovali z inštalačného servera, ktorý bol sám o sebe nakonfigurovaný automatizovane
  3. po nainštalovaní servera, si server ako posledný krok stiahol CFEngine predpis, ktorý zadefinoval jeho úlohu a konfiguráciu. Treba pripomenúť, že existujú dva typy serverov:
    1. openstack manažment – server, na ktorom beží API openstacku
    2. compute nodu, kde beží samotná zvirtualizovaná infraštruktúra
  4. spustila sa konfigurácia Openstacku na serveroch
  5. po úspešnej konfigurácii sa začala vytvárať zvirtualizovaná infraštruktúra zdieľaného hostingu
  6. po štarte virtuálneho servera, (napr. apache24-php53-1) si stiahol svoj CFEngine predpis
  7. na základe tohto predpisu sa nakonfiguroval celý server

ocf je teda možné chápať ako také DNA, na základe ktorého vyrastie celá IT infraštruktúra, podobne ako zo zrnka vyrastie rastlina. Netreba ho však chápať len ako nástroj na deployment Openstackovej infraštruktúry. CFEngine3 sa postará aj o udržiavanie tejto konfigurácie a akékoľvek odchýlky, vráti naspäť do pôvodnej konfigurácie.

Počas vývoja našej openstackovej infraštruktúry sme museli opatchovať aj niektoré aplikácie ako je napr. libvirt alebo nova-compute, aby fungovali tak, ako sme potrebovali. Výsledkom je mierne odlišná varianta Openstack Grizzly balíčkov na našom Ubuntu repozitári repo.websupport.sk . V tomto repozitári sa nachádza aj balíček pre rum. Ak si ho chcete pridať k svojim repozitárom, je nutné pridať

deb http://repo.websupport.sk/ubuntu precise main

do /etc/apt/sources.list alebo /etc/apt/sources.list.d . Kľúč nájdete na adrese http://repo.websupport.sk/debian/pub.txt .

O niečo detailnejší popis si môžete pozrieť na našej prezentácií, ktorú sme mali na Config Management Campe v Belgicku.

Tieto projekty môžete voľne používať v zmysle licencie GPLv3 .

Tešíme sa na vaše patche ! 🙂

10 odpovedí na “Sprístupnili sme DNA našej infraštruktúry”

Myslim, ze sa uvazovalo o nejakej skupinovej exkurzii do datacentra, tak vramci toho 🙂

Odpovedať

Neskúšali ste Chef alebo Puppet na správu serverov?

Odpovedať

Skusali sme puppet, ale nakoniec sme sa rozhodli pre CFEengine3.

Vyhodou CFEngine3 oproti Chef/Puppet je mnozstvo ruby zavislosti. Nie je nutne so sebou vsade tahat ruby stack, spotreba zdrojov je nizsia. CFEngine3 je napisany v jazyku C v ktorom mame podstatne viac skusenosti ako s ruby (v ktorom nemame ziadne) . Teoreticky background (Promise theory) CFEngine3 by mal zabezpecit dostatocny zaklad vdaka ktoremu budeme mat iste, ze sa veci nezmenia len tak a budu fungovat aj o roky a roky dopredu.

Zaroven ma CFEngine3 podporu pre model based monitoring ( http://bit.ly/1i1iVGD ), takze uz napisanim predpisu pre dany stroj ho mozme monitorovat.CFEngine3 sa vsak aj uci ake hodnoty su na stroji normalne a ake nenormalne (vypocitavanim anomalii z nameranych hodnot) a na zaklade toho sa daju nasadit rozne akcie.

Nejake dalsie rozdiely je mozne najst v mojom talku pre rubyslavu http://slidesha.re/1mM8oAX .

Odpovedať

no, ten rum nie je moc dobra zalezitost, lebo to sa malo vyriesit inak. zas nie je problem nehat to tak a tie nove nazvy serverov nechat pouzivat tym, co maju nove produkty a zbytek nech ostane na starom, dokym nejakyma regularnyma vyrokmi nezmenia tie skripty na nove adresy.
a vobec … rum je uz pouzivane meno, cize by nebolo zle pouzit iny nazov. alebo zlikvodovat tu aplikaciu kompletne.
k tomu ocf povim len tolko, ze na kereho boha pouzivaju ludie tieto veci, ked nakonec aj tak potrebuju nejake skripty, aby im to riesilo problemy. to sa potom clovek na to cele moze rovno vysrat a pisat si vlastne skripty kere kontroluju tie VM a hotovo.

Odpovedať

suhlasim. rum podla mna nie je idealne riesenie, vzniklo tak single point of failure a bottleneck (teda ak ho nemate nejakym inym ofajcom urobene HA a naskalovane co asi nemate). vidim este aj ine riesenie ako nechat starych dopouzivat to co maju a novych posielat na nove db servery. a to natvrdo si nastavit na webserveroch IP adresy pre ten host db50.websupport.sk.
inak blahozelam k uvolneniu vlastneho softu ako opensource. zacinam odpocitavat, kolko bude trvat hacknut websupport 🙂

Odpovedať

rum je praveze idealne riesenie pretoze nam umoznil skalovat. Co nie je zrejme z blogu jasne je to, ze rum bezi na kazdom jednom webserveri a teda nie je SPOF pre celu skupinu webserverov.

Pristup „starych dopouzivat to co maju a novych posielat na nove db servery“ v praxi nefunguje pretoze to dlho trva a pretoze sa situacia neustale meni aj na starych databazach. Na hostingu sa moze situacia zmenit z minuty na minutu, neustale sme pod utokmi botnetov alebo niekto moze deploynut neefektivny kod. Svoje pridavaju aj stranky ktore maju vyspamovane fora s desiatkami tisic prispevkami a podobne.
V takych situaciach treba reagovat promptne.

Ak by sme kazdej skupine dali db server na samostatnej adrese, bolo by nutne v pripade zmeny,tuto adresu zmenit aj na hostingu klienta co nie je jednoducha zalezitost pokial nie je jasne kde vsade je nutne prihlasovacie udaje zmenit. Hostingy mozu mat miliony suborov alebo stovky GB velke. Prejst to nejakym regexpom by trvalo dlho a generovalo IO load na serveri navyse.

Kontaktovanie klienta taktiez nepomoze, pretoze sa moze ozvat az o niekolko dni.

Abstrahovanim adresy databazy od jej realneho umiestnenia nam umoznilo samostatne skalovat skupinu web a db serverov. Nastavenie IP adresy natvrdo by taketo skalovanie neumoznilo .

Odpovedať

Hmm a pouzivanie db.zakaznik.sk v zakaznickych skriptoch by to nevyriesilo? (Akurat by bol problem pri tych, co maju DNS u seba)

Odpovedať

Na prvy pohlad sa to javi ako dobry napad, ale ma tieto problemy:

– ti co maju DNS u seba alebo na serveroch mimo WS by si museli do zony svojej domeny vlozit zaznam pre seba. To je velka bariera pre mnohych pouzivatelov. Takze predpokladam, ze by pouzivali skor ci neskor priamo IP adresu. Tym padom by sme prisli o abstrakciu ktoru by DNS ponukalo a databaza by bola naviazana na server kde existuje. V pripade zrusenia servera by to predstavovalo zvysenu reziu kvoli komunikacii s klientmi. Zaroven vlozit do ruk cast fungovania svojich sluzieb tretej strane ktorej konfiguraciu neviete ovplyvnit nie je dobry napad. Cize taketo riesenie by viedlo k zvyseniu komplexnosti, znizeniu flexibility,skalovatelnost a zvyseniu rezie ako adminov tak aj helpdesku.

– v roku 2010 sme mali uz asi 10 000 hostingov, vacsina s minimalne jednou databazou. Vsetky uz pouzivali ako host na databazu ‚localhost‘,’db50.websupport.sk‘,‘:/tmp/mysql50.sock‘ a pod . Pouzitie DNS systemu by znamenalo prepisat vsetky tieto umiestnenia ma db.zakaznik.sk, co je riesenie ktore by viedlo ku chybam, pretoze webove aplikacie mozu byt napisane rozne a nie vzdy sa da vygrepovat umiestnenie definicie databazoveho hosta.

– webove aplikacie su roznej kvality a logika pripojenia web app. k databaze moze byt prekvapujuco zlozita. Niekedy vedia zobrat unix socket, niekedy iba localhost. PHP sa v pripade host ‚localhost‘ pripoji interne na defaultny unixovy socket . My mame napr. patchovane php ktore interne presmeruje requesty na spojenia na dbX.zakaznik.sk na lokalny socket resp. rum . Zaroven mame patch v PHP ktore nastavuje mysql.default_socket uz na konkretny unix socket na ktorom pocuva rum. Toto nastavenie sa da vykonat per hosting, takze nove hostingy sa mozu uz pripajat automaticky na nove verzie MySQL, pricom vzdy co treba zadat je ‚localhost‘, co byva defaultne takze pouzivatel pri instalacii CMS zada iba login a heslo.

– db.zakaznik.sk by znamenalo, ze klient musi premyslat kam sa pripojit. Treba brat do uvahy, ze existuje skupina klientov ktory ani nevedia co je databaza,DNS,zona,A zaznamy, takze pouzitim iba ‚localhost‘ zjednodusime zivot ako pouzivatelom tak aj helpdesku.

– DNS system by znamenal, ze databazy by museli mat verejne IP adresy (samozrejme, DNS moze vracat aj lokalne IP adresy). V 2010 sme mali db servery na lokalnych IP adresach a vzdialeny pristup sa povoloval na zaklade IP adresy alebo cez stunnel, pricom remotny pristup bol v zasade zablokovany.

– DNS zaznamy maju TTL a obycajne sa cachuju, takze pri migracii databazy treba pockat kym vyexpiruje tato cache. Pokial by mal hosting DNS servery inde a TTL napr. 7200 sekund, trvalo by 2h kym by db.zakaznik.sk zacal ukazovat na novu adresu. Samozrejme nie je to neriesitelny problem (podla RFC 1035 moze byt TTL aj 0s, ale potom treba mat silne DNS servery 🙂 , ale v pripade rum, zmena umiestnenia znamena len pregenerovat cdb databazu co je velmi rychle (par sekund) a co je atomicka operacia.

Pridaj komentár

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