Sliboval jsem, že někdy lehce odkryju, jak je Simplia (hlavně eshopy) vymyšlena po technické stránce. Zavádíme teď nový server, součástí čehož jsou drobná vylepšení, takže to mám v živé paměti a můžu vám lehce popsat jak fungujeme. Nečekejte ale nic konkrétního. Nepovím vám, kolik máme serverů, ani na jaké konfiguraci a podobně. Už takhle tu dávám solidní návod, jak postavit kvalitně zázemí :)
Upozorňuji, že tu asi místy zmíním naprosté samozřejmosti, ale tento blog čtou i čistě podnikatelé bez technických znalostí, tak rozšíříme obzory :)
Jaké jsou možnosti?
Sdílený hosting
Je třeba se spoléhat na třetí stranu, doufat, že někdo ze sousedů server neshodí a celkově je to pro větší projekt dost špatné řešení. Na druhou stranu velmi levné
VPS
Virtuální server – existuje jeden skutečný server a ten je je rozdělen na několik virtuálních serverů, které jsou pronajímány. V poslední době se tento způsob dost rozmáhá, ale není to moc dobrá volba. Možná dočasně, ale dlouhodobě určitě ne.
Managed server
Dostanete od hostingu vyhrazený server a domény si spravujete přes administraci. Poměrně jednoduché, všechny starosti jsou outsorcované, ale pro nás moc svazující.
Housing
Pronájem jen místa v serverovně a přípojky. Server vlastní. A to je konečně náš případ :)
Už od začátku jsme se vrhli do vlastního řešení. Vlastní servery, vlastní systém. Dokonce máme kolegu, který se stará jen o to, aby všechny běžely, byly zabezpečené, nevytížené, … Poslední dobou mám skoro dojem, že jen sedí s nohama nahoře a kouká na barevné grafy :)
“Takže nemáte jen jeden server?”
Ne. Jsou vlastně dvě možnosti, jak k housingu přistoupit.
a) Koupit si velký nabušený server za milion a na něm mít všechno. (Případně si koupit normální server a na něm mít všechno, ale to už není úplně správně :o))
b) Mít více normálních serverů
Když jsme začínali, tak jsme šli druhou cestou. Jednak proto, že jsme neměli milion na server, který by větráčkem sfouknul prasátkům všechny tři domečky a druhak proto, že mi tenkrát přišlo lepší mít radši více serverů a tudíž možnost záložních kapacit i při velkých problémech.
Líbí se mi ta možnost v případě problému přesunout provoz z jednoho serveru na jiný (resp ho rozložit mezi více) a zatím vyřešit problém. Ale o tom dále.
Disky
Kupříkladu disky jsou všechny zrcadlené v RAIDu – místo aby byl v serveru jeden disk, tak jsou dva (nebo více) a jsou datově identické. Pokud se zapíše změna, tak se zapíše na všechny. Pokud se čte, tak se střídají (případně se čte z každého něco jiného). Obrovskou výhodou je, že pokud jeden disk odejde do křemíkového nebe (což se stává), tak to příliš nevadí, protože data zůstávají funkční. Návštěvník na eshopu ani nepozná, že disk vypadl. Možná se mu stránka místo 0,21s bude načítat 0,3s, ale pořád je to lepší, než když eshop vypadne úplně. Pak stačí přijít k serveru, špatný disk vytáhnout, vložit nový a ten si stáhne zase kopii dat a jede se dál. V praxi se to spíš dělá tak, že se nejdřív přesune alespoň část provozu jinam. Je to stejná logika, jako když píchnete auto a jedete na rezervě. Taky se pak vyhýbáte každé díře, protože druhou rezervu už nemáte :)
Kromě toho, že jsou zrcadlené, tak jich je v serveru více. Na jednom poli běží jen ostré verze eshopů, na dalším je systém, na dalším jen zálohy, …
RAID má ještě jednu sympatickou výhodu. Po půlroce můžete přijít k serveru, jeden disk odpojit a nahradit ho novým – tzn. průběžně je obměňovat.
Disková pole jsou i hostingů samozřejmost. Alespoň jsem si to myslel. Tento týden mě ale jeden poskytovatel opět přesvědčil, že to až tak samozřejmé není. Poznáte, do koho rýpu? :)
Správa serverů
Když máte server jeden, není až takový problém ho spravovat. Zapnete konzoli, vše si upravíte. Případně si na to uděláte nějaký skriptík. Ale aplikujte si to pří více serverech :)
V začátku jsme zkoušeli různá hotová řešení – cPanel, Plesk, … Ale nic neodpovídalo našim požadavkům. Takže máme vyrobený vlastní systém. Z mého pohledu vypadá tak, že si otevřu náš IS a tam mám hezky pohromadě s ostatním grafíky vytížení, správu domén, emailů, … a to vše hezky z jednoho místa. Pokud jde o eshopy, tak mi je při správě úplně jedno, který je na kterém serveru. Je to navrženo tak, že systém pozná, kde má změnu provést.
Na všechno jsou ale hlavně klikátka. Nemusím lézt do FTP účtů, vybírat jaký server chci spravovat, nastavovat cesty a podobně. Jen vlezu do eshopu, kliknu, že chci vytvořit FTP účet. Když se pak přesune eshop, přesune se i FTP :) Ono se FTP ani na nic jiného než přístup k šabloně pro klienty nepoužívá.
Balancování
Aby byly servery rovnoměrně zatížené, tak se musí správně rozdělit eshopy. K tomu používáme především dva grafy – absolutní návštěvnost (resp hits) a denní/hodinovou zátěž. Každý eshop má špičky v jiných časech a jiných dnech v týdnu. Zajímavé třeba je, že sexshop a kočárky mají hodinové návštěvnosti (procentuálně) prakticky stejné :) Vybírají se tedy eshopy, které složením grafů vytvoří rovnou čáru.
Ale časté převody domén způsobují výpadky eshopů, že? Není pravda. Díky tomu jak je systém nastaven by bylo teoreticky možné přehazovat eshopy mezi servery v poledne. Nikdo by nic nepoznal. V praxi se to ale stejně radši dělá v noci. Přesun teď vypadá tak, že v našem IS kliknu, že chci eshop přesunout jinam a on se přesune :)
Z toho plyne i důsledek, který jsem zmínil výše. Pokud by měl být nějaký problém, je možné velmi rychle přesunout veškerý provoz jinam.
Zálohování
Dříve jsme měli zálohy nastavené tak, že probíhali non-stop a postupně zálohovaly všechno a když dojely na konec, tak se jelo znova. Eshopy měli proto zálohu v průměru z každých 15ti minut. Teď jsme systém ale ještě více vylepšili a máme… no…jak to nazvat…. absolutní zálohy! Sedla si k počítači vaše ratolest a podařilo se jí smazat půlku katalogu? Není problém. Obnovíme eshop ze zálohy v 15 hodin 32 minut a 17 sekund.
Zálohy samozřejmě slouží primárně pro různé živelné katastrofy a ne pro obnovy uživatelských omylů. Ale pokud je klient milý a příjemný, tak mu v zálohách najdeme co potřebuje.
Zálohy se navíc ještě zálohují mezi servery. V důsledku to znamená, že pokud na jeden spadne meteorit, tak je možné během chvíle obnovit provoz domén na ostatních serverech a to prakticky od okamžiku pádu. Hezké, že? Každý server v sobě tedy má všechny eshopy + jejich historii.
Zatím mají historii kompletní, až se začnou moc roztahovat, tak je připraven šuplík s diskem, na který se sesypou nejstarší zálohy a archivují.
Bezpečnost?
Při takové míře zálohování se data docela naběhají, není nebezpečná takhle je vystavovat po síti? Ne. Data pobíhají po vnitřní síti v serverovně. Kromě toho používáme VPN – data tak pobíhají jen šifrovaně.
VPN je další věc, kterou bych rád zmínil. U většiny hostingů se pro nabourání musíte dostat přes nějaké silné heslo či certifikát. U nás je přidán ještě jeden prvek a sice VPN. Pokud nemáte certifikát pro připojení k VPN, tak se na serveru nepřipojíte prakticky k ničemu. Původně ale nevzniklo z bezpečnostních důvodů, ale spíše z praktických. Díky VPN máme možnost dívat se vzájemně na “locahosty”, používat sdílené síťové disky (třeba pro přístup k šablonám eshopů) a celkově je to dost pohodlné. Bezpečnostní prvek je spíš bonus.
Například editace šablon vypadá takto: otevřu si síťový disk (vpn, heslo, …) a tam mám seznam šablon všech eshopů. Kodéři mají nižší práva, tak vidí jen jejich šablony. Hezké je, že tady jsou sice všechny šablony pohromadě, ale v reálu jsou z různých serverů. Kde který je ví systém a mě to může být jedno :)
Verze eshopů
Všechny eshopy jsou ve stejné verzi. Používáme pro vývoj repozitáře Mercurial, které mají proti třeba SVN výhodu, že jsou decentralizované. Není problém mít jich několik a posílat změny kaskádově. Takže si kolega něco u sebe vyvíjí, pak to pošle do společného vývojového repozitáře, zkontroluje se kompatibilita s jinou novinkou, projde to testy a pak jde do ostrých verzí. Systém se postará, aby dostaly servery novou verzi najednou, updatovaly se, případně změnily strukturu databází apod.
S odstupem času jsem dost rád, že se nám podařilo hlavně v začátku udržet vývoj tak, aby byla jen jedna ostrá verze zdrojáků. změny v eshopech to pak výrazně zjednodušuje. A díky systému distribuce změn s tím ani není moc práce. Vlastně jen jedno kliknutí.
Přátelé, nechci se vás dotknout…
… ale kdo z vás to má? :)
Podobný princip samozřejmě není aplikovatelný všude. Kdyby například stejně zálohoval klasický hosting, tak bude každý den dokupovat další a další disky. Chtěl jsem vám je nastínit, jak jsme si to pěkně vymysleli na míru, pro naše potřeby.
A příště?
Tento článek je první z menšího seriálu, kterých bych interně nazval “Simplií chlubítka”. Postupně bych chtěl psát články popisující různé drobnosti, které máme myslím hezky vyřešené. Dnes to byly servery, příště opět něco technického a pak pár videií s popisem z administrace e-shopů. Neberte to jako chlubení, ale spíš inspiraci – co vám do teď nechybělo, ale brzo bude :) Navíc je mi jasné, že jen co tu představím některé vychytávky z adminu, tak to vzápětí bude “konkurence” nabízet taky. Pak bude vtipný závod, jestli je frekvencí novinek (které ale my máme třeba už dva roky) uštvu :o)
22:53 on Únor 12th, 2010
jenom bych se rád ještě zeptal jak to máte vyřešené s IP adresami… pokud přesunete doménu, musíte změnit i záznamy na DNS serverech… chápu, že i to jde automatizovat, ale už se mi stalo, že jsem změnil všechny potřebné záznamy pro přesun domény, během minut se změna rozšířila, ale routery O2 změnu nějak odmítly či co… a museli jsme jim napsat a chybu opravili asi po týdnu dohadování (pokud se nepletu, není to úplně nedávná zkušenost), hrozně zvláštní chyba, protože během toho týdne nám na web chodili jen lidé od jiných providerů (tomu říkám diskriminace) … ale zajímalo by mě, jestli jsou přesuny e-shopů u vás tak běžná záležitost jak to při čtení článku vypadá i z tohoto pohledu
23:07 on Únor 12th, 2010
Především máme vlastní dns servery, tak se s tím dobře manipuluje. Velké eshopy mají hlavně svoje IP adresy, takže se přehazují i s nimi.
23:11 on Únor 12th, 2010
Není to komplikace to sledování zátěže jednotlivých eshopů a ruční přehazování na jiný server. Nejsem úplně odborník, ale co clustery?
23:22 on Únor 12th, 2010
Ano, je to možnost. Ale s balancováním není totilk práce, aby bylo potřeba to řešit. Servery jsou dost málo zatížené, takže je to spíš záležisto občasného se podívání a případného dovážení.
Taky na to nejsem odborník, ale na tomhle řešení se mi líbí, jak jsou vlasně všechny servery nezávislé.
07:12 on Únor 13th, 2010
thonic: U mě jednou zabralo vytvoření nového NSSET, ale jestli to funguje univerzálně, to nevím.
10:45 on Únor 13th, 2010
Díval jsem se na některé věci, jak je vedete ve skutečnosti, a popravdě jsem docela překvapený, že to funguje tak perfektně, jak píšeš. :-) Každopádně se těším na další díl Chlubítka — články ze zákulisí jsou vždycky nejzajímavější. :-)
LLook:pokud byl obsah toho NSSETu stejný, tak to byla čistě náhoda, protože technicky je to jenom interní element registru, ale člověk s ním při běžné práci nepřijde vůbec do styku.
11:16 on Únor 13th, 2010
Pekne simplia vychloubatko , ale proc ne kdyz to tak pekne funguje:-)
11:23 on Únor 13th, 2010
frances: Abych pravdu řekl, tak jsem se při psaní nejvív bál toho, že zrovna druhý den se něco posere :D
12:28 on Únor 13th, 2010
xHire: Už nemám O2, takže to nemůžu ověřit. Změnou NSSETu se ve whois změní kolonka „changed“. Je možné, že jejich software do whois nahlíží a v případě, že je doména podle něj změněná, tak si obnoví její zónu. Je to jenom teorie, bylo by to divné chování, nicméně ne nemožné.
16:15 on Únor 13th, 2010
Pekny clanek, i kdyz popravde neni tam nic co se nedalo cekat a u vetsich projektu to je tak vsude, takze paroubkovo heslo je tam tak trochu smesne:-)
Jen dve veci: ta manualni kontrola, nebylo by lepsi klasicky load balancing na serveru?
Pises, ze kdyz spadne meteorit na server, prevezme to druhy, mate oddelene i serverovny – jine lokace, nebo az tak ne?.-)
16:21 on Únor 13th, 2010
Jirin: Automatika je samozřejmě další level. Zatím mě do toho nic netlačí. Ono to balancování aktuálně není kvůli řešení špiček, ale spíš, aby bylo vše rovnoměrně zatížené. Tzn není to tak, že by se blížila špička, tak se přehodí eshopy jinam. Spíš se jednou za čas koukne a řekne „hele, tenhle má zátěž 8% a tenhle 12%.. to vypadá hloupě… srovnáme to…klik klik.. hotovo“
20:38 on Únor 13th, 2010
Zajímavé pro laiky, ale bylo by dobré, kdybys nastínil i použité technologie. Např. DRB vs. rsync vs. GFS vs. glusterfs… dále způsoby load balancingu, zálohování, cluster mysql vs. master x slave atd atd
Jestli se pochlubíš, tak se ti v komentářích pochlubím já zase svými zkušenostmi a mohla by vzniknout zajímavá diskuse i s dalšími :)
21:12 on Únor 13th, 2010
LLook: díky, příště to prověřím
02:01 on Únor 14th, 2010
dobrý článek,, jsem v očekávání co přinesou další chlubítka ,o)
11:21 on Únor 14th, 2010
Nejsem v tom odbornik, ale kdyz pominu to co se tyka vylozene systemu eshopu, tak mi to prijde jako klasicke vybaveni lepsiho hostingu. Aspon to tak pusobi: vlastni server, vlastni sw na spravu, zalohy. V cem je to jine? Tohle ma kazdej. Nebo se pletu?
11:23 on Únor 14th, 2010
Hlavně je to celkově koncipované jinak než to mají hostingy. Má to taky jiné využití.
A pokud jde jen o eshopy, tak ostatní poskytovatelé (kromě těch opravdu velkých) mají obvykle jeden VPS či managed server.
Většina firem to hlavně outsourcuje, kdežto my to máme pod sebou. Samozřejmě je s tím více práce, více starostí, ale je to zkrátka cesta, kterou jsme se vydali.
15:57 on Únor 15th, 2010
Stejně jako jindy opět z hovna senzace aneb chlubíme se tím co je jinde běžné.
Tvoje řešení s rozmístěním a přehazováním shopů na jednotlivé servery je naprostý nesmysl, v případě HW poruchy na serveru musíš nejprve zjistit poruchu, pak vše z toho serveru přestěhovat (překlikat) na jiný, dojet do servrovny zjistit co se v počítači poškodilo, sehnat náhradní díly, provést opravu, nahodit server a opět vše překlikat zpět. A co budeš dělat až ti zdechce server na kterém máš ty nástroje. Navíc toto řešení vyžaduje nutnost převést správu DNS na Vaše servery, bez toho je to nepoužitelné.
Rozhodně lepším řešením je dát servery do clusteru. Z důvodu možné poruchy serveru (odejde zdroj, …) mně přijde výhodnější právě managed server, kde mam jistotu, že odstávka serveru do výměny jeho vadných částí nebude trvat déle než 30 minut, což v tvém případě bude takový server mimo provoz několik hodin.
Tady by se hodilo uvést také na pravou míru lživý údaj, že máte vlastní DNS servery, ty nemáte, ale využíváte DNS serverů poskytovatele služeb. Docela by mně zajímalo jak je to také ve skutečnosti s těmi Vašimi servery, protože co sem měl informace z minulého roku, tak ste ve skutečnosti žádné neměli a používali ste jen jeden VPS server.
Jediné co mně zde zaujalo je to online zálohování, ale to mně hlava nepobírá jak může být v podstatě řešeno. Dokážu si představit zálohování databáze způsobem, že budete někam ukládat všechny nonselect SQL dotazy, ale jak by ste chtěli zálohovat třeba fotky produktů online to mně hlava nepobírá.
16:59 on Únor 15th, 2010
„online zálohování“ filesystému je možné pouze věcí, která se jmenuje „versioning filesystem“. Neznám nikoho, kdo by to měl nasazeno v produkčním prostředí. Ale pak bych opravdu měl teoreticky verzi z každého časového okamžiku.
„online zálohování“ databáze se dá udělat master x slave konfigurací, kdy schovávám i plné binární logy s časovým razítkem. Pak opravdu dokážu zrekonstruovat stav databáze v každém časovém okamžiku. Samozřejmě se musí počítat se zajištěním konzistence dat. To už jsem v produkci viděl.
Je škoda, že je článek psán příliš populárním stylem a detaily se nerozebírají. Docela bych si o tom rád popovídal, high availibily dělá v CZ málokdo a člověk musí zkušenosti vyměňovat v zahraničí.
17:51 on Únor 15th, 2010
reklamnikobecny:
Ano, píšu tu samozřejmé věci. Dokonce to hned na začátku článku i píšu. Půlka čtenářů tohoto blogu umí perfektně pracovat s ROI, RPSN a cashflow, ale hosting je pro ně černá skříňka.
K tvým jednotlivým námitkám:
V případě poruchy se přehodí IP adresy a obnoví se provoz automaticky. Není to samozřejmě přesně v okamžiku výpadku, ale je to otázkou zhruba minuty max. V tuto chvíli přijatelné. Nástroje pro správu jsou na všech serverech. Teoreticky by mohl být hlavní server kterýkoliv. V praxi ale používám pro správu jeden, protože ho mám v záložkách :)
Závadu hledat nemusím. Ono to může klidně týden počkat. To jssem se článkem snažil sdělit :) Že nejdeme cestou outsorcované techniky, ale spíš cestou postradatelných serverů, když to řeknu jednoduše.
Cluster pro nás není vhodný. Podle toho co jsem tu psal to tak možná vypadá (taky jsem se po dopsání zamyslel), ale potřebujeme trochu jiný přístup, kvůli pokladním serverům a podobně. Ale o tom se tu nechci rozepisovat. Reps. ne teď.
S DNS ti asi nerozumím. Je možné, že jsem se někde upsal, není zrovna můj boro, tak prosím omluv nepřesnosti.
ad VPS – zajíamlo by mě, okdud tahle informace je. Kdysi (3-4 roky zpátky) jsme začínali na dedikovaném serveru, ale VPS jsme nikdy neměli. Nepleteš si nás s jiným poskytovatelem eshopů, u kterého se právě jeho jedno VPS řešilo?
Online zálohování – ono to není řešeno úplně superefektivně a spotřebujete nějakou část výkonu. Ale můžeme si to dovolit, tak proč to tak nedělat. Ikdyž pořád doufám, že kolega přijde ještě s nějakým hezčím řešením.
MArtin: Ano, článek je spíš seznámení s oblastí. Jednak samozřejmě proto, že tohle vůbec není můj obor a vím jen to co potřebuji. Druhak proto, že tu zatím nechci zveřejňovat úplně všechno.
Ještě k té samozřejmosti. Kdyby to bylo zcela samozřejmé a běžné, tak neomezeny-hosting.cz po výpadku disku neoznámí úplnou ztrátu dat a konec činnosti, jistý poskytovatel eshopů nemá výpadky při každé špičce a tak dále.
Mimochodem tenhle článek jsem sepsal na základě žádostí, které se objevili v komentářích, tak doufám, že někomu něoc přinesl. A ještě jednou opakuji – ano, většina věcí, které píšu by měla být samozřejmost.
18:43 on Únor 15th, 2010
reklamnikobecny: zbytečně soptíš :) mi ten článek přijde zajímavý a byť je to možná to co mají všude, tak nikde o tom nemluví, což je možná chyba, protože by to nezainteresované zajímalo ;)
Souki: to zálohování mi přijde nějaký zvláštní – to musí zabírat obrovské množství místa ne? Jak dlouho zpětně držíte zálohy?
18:46 on Únor 15th, 2010
Rdm: Zabírá :) Ale z velké části se zálohují jen změny a těch v eshopech není tolik. To je právě výhoda proti hostingu a můžeme si to dovolit. Zálohy by měly být uchovávány v řádech let. Samozřejmě je možné, že do budoucna se to sníží, ale stejně je to spíš hračka a nečekám, že by někdy bylo potřeba tahat něco z 2 roky staré zálohy. Ale proč je nemít, když je místo.