Rozšiřujeme portfolio našich služeb o plně spravovaný privátní cloudna platformě VMware. Nově si tak můžete vybrat, zda dáte přednost privátnímu cloudu postavenému na open-source řešení Proxmox, nebo zvolíte licencované enterprise řešení od jedničky na trhu virtualizace, VMware.
Přesun aplikací do cloudu má řadu nesporných výhod, ale jeho nejpopulárnější forma nabízená globálními poskytovateli má řadu provozních úskalí: vzdáváte se možnosti nastavit si celé prostředí podle sebe, k vašim datům dáváte přístup třetí straně a vystavujete se riziku vendor lock-inu.
Pokud patříte mezi náročnější klienty, pro svou aplikaci určitě vyžadujete cloud exkluzivní, který je jen pro vás a ušitý na míru. Potřebujete cloud privátní, který se narozdíl od toho veřejného plně přizpůsobí potřebám vaší aplikace.
Privátní cloud bere výhody cloudu veřejného a roubuje je na řešení, které máte plně pod kontrolou, a kde není nijak omezována vaše svoboda.
Příklad infrastruktury Privátního cloudu
Jak vypadá privátní cloud na VMware platformě od vshosting~
Každý privátní cloud stavíme na nejmodernějším hardwaru od HP, DELL, Supermicro, Intel a AMD. Pokud zvolíte variantu na VMwaru, k virtualizaci využíváme nástroj vSphere, a to ve verzích Standard, nebo Enterprise. Samozřejmostí je i celkové zajištění návrhu, realizace a provozu v režimu vysoké dostupnosti. Vše včetně odborného poradenství od našich administrátorů.
K řešením, která poskytujeme, neodmyslitelně patří komplexní správa serverové infrastruktury s unikátní 24/7 podporou a 60 sekundovými reakčními časy. Nejinak je tomu i u privátního cloudu na VMware.
Naši zkušení administrátoři ke správě využívají pokročilý software pro server management, VMware vCenter (verze Standard), který slouží jako centralizovaná platforma pro kontrolu vSphere prostředí. Managed správu pro vás zajistíme, ať už vaše aplikace běží na operačním systému od Windows, nebo od Linux.
Máte zájem o privátní cloud na VMware? Ozvěte se našim konzultantům: konzultace@vshosting.cz a nezávazně se pobavte o možnostech a vymoženostech VMwaru.
Nejpoužívanější účetní softwary. Jaký vybrat?
Každá firma musí vést účetnictví. Pokud se nejedná o malou firmičku o dvou zaměstnancích, potřebuje už účetní systém, který je spolehlivý, aktuální a bez chyb. Nejpopulárnějšími systémy v České republice jsou i nadále POHODA, HELIOS a Money. Aby správně fungovaly, musí běžet na Windows.
Pro rok 2022 se předpokládá, že firmy budou více investovat do účetních softwarů. Dokonce i takové firmy, které si dělaly účetnictví samy, přejdou na účetní systémy. Důvodem je stále rostoucí důraz na integraci s ERP systémy a na automatizaci procesů celkově.
Navíc budou firmy i letos více šetřit čas a finance, a to právě přechodem na externí účetní software. Z toho lze usuzovat, že i české firmy budou na úkor Linuxu poptávat více hostingových řešení na Windows.
Většina firem přejde na externí účetní systém kvůli časové úspoře a automatizaci
Dle statistiky Accounting Today využívá v USA účetní software v cloudu pouze 58 % velkých firem. U malých firem jde dokonce jen o 45 % z nich. V České republice tomu není jinak. Navzdory mnoha alternativám je stále nejpoužívanějším účetním nástrojem Microsoft Excel. Zejména malé firmy jsou velmi konzervativní a na externí software se zdráhají přejít. Časová úspora je ale u současných řešení tak velká a jejich používání natolik intuitivní, že většinu firem postupně přesvědčí k upuštění od excelových tabulek.
Hlavními důvody pro přechod na specializované účetní systémy bude již zmíněná snaha o automatizaci, ale i outsourcing účetních operací. Díky němu budou moci firmy rychleji inovovat a soustředit se na ziskovost z hlavní činnosti svého podnikání.
V Česku dávají firmy stále přednost v účetních softwarech ryze českým firmám
Na předních příčkách popularity se dle průzkumu společnosti Capterra držely ve světě v roce 2021 účetní systémy Quickbooks Online, Carta, Freshbooks a Xero.
V Česku oproti tomu dávají firmy stále přednost ryze českým poskytovatelům účetního softwaru jako je POHODA, HELIOS a Money. Připravili jsme pro vás přehled nejpoužívanějších účetních systémů našich klientů podle velikosti. Toto rozdělení vám určitě pomůže při správném výběru.
Nejpoužívanější účetní systémy klientů vshosting~
Velké podniky
Účetnictvích velkých podniků již bývá komplikované, nároky na účetní systémy jsou enormní a zpravidla se jedná o softwary, které jsou laděny na míru dané firmě. Jsou to robustní softwarová řešení, kde je kladen důraz na vysokou dostupnost.
Střední podniky
Firmy, které se již vyprofilovaly do středních podniků budou potřebovat mnoho pokročilých modulů, aby celou agendu zvládaly nejen z pohledu daní ale také z pohledu legislativy a tak dále. Jaké balíčky a účetní softwary tak budou pro střední firmy přínosné? Musíte hledět na to, jakým směrem se vaše firma zaměřuje a v jakém odvětví pracuje. Pro její řízení stále potřebujete celkem dost funkcí, ale můžete ušetřit tím, že některé nepotřebné oželíte.
Malé podniky
Pokud se podaří z obyčejné živnosti vybudovat menší prosperující firmu, bude na čase zvolit jiný účetní software. Budete totiž potřebovat více pokročilé funkce, které váš stávající „živnostenský“ software již nezvládá. Které softwary se tedy hodí pro malé firmy? Především ty menší, levnější, přesto spolehlivé.
Populární účetní programy v Česku však obvykle nejsou kompatibilní s operačním systémem Linux, který je například u e-shopů velmi oblíbený. Pro svůj běh vyžadují provoz na Windows platformě. Ve vshostingu se specializujeme kromě Linuxu na provoz Windows řešení. Zákazníkům nabízíme plně kompatibilní prostředí pro provoz účetních systémů, ať už používají HELIOS, POHODA nebo Money.
Jaké výhody vám přinese managed služba a co vše zahrnuje
Přívlastek „managed“ se v oblasti hostingových služeb objevuje čím dál častěji. Co ale přesně znamená? A o co se u managed služeb staráte vy a co zajišťuje poskytovatel hostingu?
Liší se nějak význam termínu „managed“ mezi jednotlivými hostingovými firmami? Je to hodně otázek. A na všechny se podíváme v dnešním článku přímo od jednoho z našich seniorních adminů.
Co je to managed služba
Managed, neboli spravovaná služba v hostingu znamená, že váš poskytovatel do nějaké míry pečuje nejen o vaše servery, ale i o softwarové vybavení. Jaký rozsah, kvalitu, rychlost a časovou dotaci taková péče má se však může podstatně lišit, a to poskytovatel od poskytovatele.
Můžete se setkat s tím, že managed služba znamená maximálně 3 hodiny podpory měsíčně, v lepším případě od administrátora s půlroční zkušeností, a týkat se bude pouze základních bezpečnostních aktualizací. A lze ji čerpat jen v pracovní dny od 9 do 17.
Na druhé straně pak jsou firmy jako je ta naše, které v rámci managed služeb poskytují první poslední, v případě zájmu i včetně debuggingu a odborného poradenství. A to, že správu, monitoring i řešení požadavků klienta dělají nonstop. A že na místě v datacentru mají vždy seniorní adminy berou už jako samozřejmost.
Jak k managed správě přistupujeme ve vshostingu
U nás ve vshostingu na kompromisy nehrajeme a managed služby od vshosting~ proto znamenají plnou správu hardwaru i softwarového vybavení serveru. Ta zahrnuje pokročilý monitoring desítek parametrů seniorními admini s 15 lety zkušeností, každodenní bezpečnostní aktualizace, pravidelnou kontrolu zátěže serverů a řešení požadavků klientů. Na telefon reagujeme klientům vždy do 60 sekund. Serveroví specialisté vyřeší požadavky v průměru do 15 minut . Pomůžou i s debuggingem aplikací. Vše je k dispozici nonstop (24/7 i ve dvě v noci o víkendu) od seniorních administrátorů přímo v našem datacentru. Bez časového omezení rozsahu podpory.
Monitoring, optimalizace, reporting
U managed služeb nonstop monitorujeme desítky metrik na každém serveru (performance, stav služeb). Provádíme také optimalizace, debugging, zálohování a instalaci dalšího softwaru na serveru.
Mezi monitorované služby a parametry patří například:
Aktualizace softwaru
Bezpečnostní aktualizace
Bezpečnostní aktualizace na managed serverech provádíme jednou denně v nočních hodinách. Jedná se pouze o minor (setinkové) aktualizace k již nainstalovaným verzím aplikací. Většina aktualizací s sebou nepřináší nedostupnost služeb. U některých komponent (webservery, databáze) ale může být třeba restartovat danou služby po dokončení aktualizace. Klient má možnost si zvolit vyjmutí služeb vyžadujících restart z režimu automatických aktualizací. Pak jsou aktualizace u takového softwaru prováděny ad-hoc. Tento režim aktualizací však není doporučován.
Z automatických aktualizací jsou nicméně vyjmuty aktualizace jádra operačního systému, které vyžadují restart serveru a způsobují tak kratší nedostupnost všech služeb. Aktualizaci jádra operačního systému provádíme individuálně a v závislosti na výskytu kritických chyb, a to vždy po dohodě s klientem.
Automatické aktualizace nejsou aplikovány u služby Managed Cluster. Zde jsou vždy řešeny individuálně v závislosti na aktuální potřebě. Důvodem pro individuální řešení je v tomto případě například nepředvídatelný dopad automatické aktualizace na dostupnost a konzistenci infrastruktury. Pokud má klient vyhrazené testovací prostředí, realizují se aktualizace nejprve zde a teprve poté na produkci. Tímto postupem lze v předstihu odhalit případné problémy s aktualizacemi bez dopadu na produkční prostředí.
Upgrade verze softwaru (mimo operační systém)
Upgrade major verze softwaru provádíme na žádost klienta. A to v případě, že je daný software a jeho nová verze podporována. Buď pro nainstalovanou verzi operačního systému Debian nebo Ubuntu Serveru v oficiálním repozitáři balíčků Debian či Ubuntu, některém z podporovaných neoficiálních repozitářů, repozitáři vshosting, či oficiálním repozitáři tvůrce daného softwaru. Neprovádíme kompilaci softwaru ze zdrojových kódů z důvodu nekoncepčnosti. Instalovaný software musí být podporovaným softwarem na managed serverech.
Upgrade operačního systému
Ve vshostingu provozuje servery na operačním systému Debian či Ubuntu Serveru. A plně respektuje životní cyklus těchto operačních systémů. V případě skončení podpory dané verze operačního systému jeho autory je klient vystaven riziku hacknutí serveru či jiného bezpečnostního incidentu, kterému bez aktualizace nelze zabránit. Proto klienty v takových případech proaktivně kontaktujeme a upgrade nabízíme.
O upgrade může klient také sám požádat, například pokud nelze upgradovat jiný software bez upgradu celé distribuce. Aktualizace operačního systému v případě, že podpora nainstalované verze bude skončena za 24, či méně měsíců, je prováděna bezplatně. Klienti samozřejmě upgrade mohou odmítnout, my je pak bohužel nemůžeme chránit před výše zmíněnými riziky.
Co je u managed služby od vshosting~ v kompetenci klienta?
Zejména u komplexních služeb nemusí být na první pohled jasné, co má na starosti poskytovatel hostingu a co klient. Ukažme si to na příkladu plně spravovaného managed clusteru s Kubernetes od vshostingu.
Rozdělení kompetencí – příklad managed Kubernetes clusteru
Z tohoto příkladu rozdělení u Kubernetes vyplývá, že zatímco my se staráme, aby vše fungovalo, vy se můžete primárně soustředit na vývoj aplikací. A na to, aby váš e-shop či jiný internetový projekt fungoval a vydělával. Pakliže máte dotazy k článku, k rozdělení kompetencí, managed službách, Kubernetes atd. Neváhejte nás kontaktovat: konzultace@vshosting.cz. Rádi vám zodpovíme veškeré dotazy.
5 let provozu datacentra: hlavní byznysové lekce
Co jsme se naučili za 5 let provozu vlastního datacentra a v čem se pořád snažíme zlepšovat.
V srpnu 2015 jsme v pražské Hostivaři oficiálně otevřeli naše vlastní datacentrum ServerPark. Jako poskytovatel hostingových služeb tou dobou vshosting~ fungoval už 9 let, spuštěním ServerParku ale začala nová éra. Nejdůležitější byznysové lekce, které jsme se za 5 let provozu datacentra dostali, by se daly shrnout takto: paranoia = základ úspěchu, „nejde“ neznáme a jak se řídí pytel blech.
Paranoia = základ úspěchu
Jako poskytovatelé hostingových služeb máme paranoiu tak trochu v popisu práce. Když k tomu provozujete i datacentrum, platí to dvojnásob. Maximální bezpečnost a ultra vysoká dostupnost služeb jsou pro naše klienty tím nejdůležitějším. Z toho důvodu jsme v našem datacentru zavedli ještě přísnější opatření než je běžné. Veškerou infrastrukturu máme zdvojenou a ještě k tomu jsme přihodili extra rezervu.
Oproti tomu ve většině jiných datacenter volí pouze zdvojení infrastruktury nebo dokonce jen jednu rezervu. Je to totiž mnohem levnější a šance, že se vám porouchá například víc než polovina klimatizačních jednotek je přeci minimální, ne?
Jak známo, to, že jsme paranoidní, ještě neznamená, že po nás nejdou. Natož že se neporouchají tři klimatizační jednotky najednou. Proto jsme se s tímto standardem nespokojili a můžeme říct, že už se nám to za těch 5 let několikrát vyplatilo. Když už je řeč o klimatizaci: například jsme jednou prováděli revizi jednotlivých přístrojů (na což je pochopitelně třeba je vypnout) a najednou se nám u jedné z těch rezervních zadřel kompresor. Pro standardní datacentrum by to byla pohroma, ale my jeli vesele dál. Akorát jsme teda museli objednat ten kompresor…
Narozdíl od většiny jiných datacenter se tak i po 5 letech můžeme pochlubit zcela bezvýpadkovým provozem. Extra opatrnost se vyplácí a u datacentra to platí dvojnásob.
Zakládáme si taky na velkých zásobách hardware. Tak velkých, že by je mnozí jiní poskytovatelé hostingových služeb označili za zbytečné. Nám se ale opět potvrdilo, že pokud chceme klientům poskytovat excelentní služby za všech okolností, zásobovací paranoia se vyplatí.
Skvělým příkladem byl začátek letošní koronavirové krize. Kvůli zvýšenému zájmu o online nákupy některé e-shopy potřebovaly výrazně navýšit kapacitu – někdy i dvojnásobně. Zároveň pandemie po celém světě v podstatě zastavila pohyb dodávek hardware. Kdybychom potřebné servery teprve objednávali, infrastruktura klientů by se pod náporem zákazníků jednoduše sesypala. My jsme ale servery prostě vytáhli ze skladu a téměř okamžitě nainstalovali.
„Nejde“ neznáme
Další lekce, kterou jsme se provozem datacentra naučili, je nutnost myšlení „mimo krabici“. Jakožto poskytovatelé hostingových služeb a zároveň provozovatelé datacentra musíme klientovy představy o serverové infrastruktuře naplnit od A do Z. A varianta „to nejde“ v tomhle byznysu jednoduše neexistuje. Buď to nějak vymyslíte a nebo v téhle branži „ostrouháte“.
Za 5 let provozování datacentra jsme se setkali s kde čím. Ať už jde o vymýšlení obří infrastruktury pro ty největší lokální e-commerce hráče nebo transformace celého řešení na zbrusu novou, pro nás neznámou technologii, naučili jsme se nikdy nevzdat před bojem. Výsledkem bývají úplně nová, neotřelá řešení z hlav našich skvělých adminů. Jak se říká, že práce admina je celkem stereotypní, tak u nás toto opravdu nehrozí. Výzev pro ně máme víc než dost.
Samozřejmě jsou i požadavky, které jednoduše splnit nejde. Fyzikální zákony jsou holt, málo naplat, fyzikální zákony. Případně se stává, že je cena daného řešení naprosto mimo byznysovou realitu. I v takových případech jsme ale přišli na to, že než se spokojit s oním „nejde“, vždycky se vyplatí hledat alternativní řešení. Jistě, nebude zcela dle původního zadání, ale může se mu co nejvíce přiblížit.
Sečteno, podtrženo: za všech okolností hledáme způsoby, jak klientovým požadavkům vyhovět, nikoliv důvody, proč „to nejde“.
Pytel blech aneb jak uřídit firmu s týmy po celé Praze
Když jsme datacentrum stavěli, bylo nás ve firmě asi 20. Nad datový sál jsme přidali patro s kancelářemi a zázemím s tehdy, zdálo se, nesmyslně velkou kapacitou 50 lidí. Počítali jsme, že nám pěkných pár let potrvá než tolik vyrosteme. Nakonec to trvalo kraťoučké tři roky.
Dneska je nás okolo osmdesáti (plus 5 psů, 1 ještěr a na part time i 1 ježek). Do datacentra se už nějakou dobu nemáme šanci vejít, takže jsme provedli menší decentralizaci. Vývojáři sídlí v Holešovicích a obchod s marketingem v Karlíně. Z hlediska řízení firmy a HR je takové roztříštění firmy velká výzva.
Jaké lekce jsme si odnesli? Primárně že efektivní komunikace je pěkná makačka, která ale stojí za to. S drhnoucí komunikací se koneckonců setkává kdejaká rostoucí firma – jakmile je vás přes 25, informace už nestačí přirozeně předávat ve frontě na kávovar. Když přidáte rozdělení týmů do různých lokalit, efekt se násobí.
Naučili jsme se (a vlastně se pořád ještě učíme) pravidelněji a strukturovaněji předávat informace mezi týmy, aby nevznikala nedorozumění. Protože nedorozumnění plodí zbytečné konflikty, neefektivní práci a všeobecnou frustraci. Na druhou stranu nejsme příznivci nekonečných meetingů všech se všemi. Takže jak na to?
Například pravidelně všem posíláme vnitrofiremní newsletter, do kterého každý tým ve firmě přispěje novinkami o tom, co dělá, jaké další věci chystá, a co se obzvlášť povedlo. Díky tomu i nový obchodník tuší, co pro úspěch firmy dělají technici a admini chápou, proč po nich marketing chtěl zkontrolovat článek. Nabouráváme tak svoje týmové stereotypy a neustále si připomínáme, že všichni táhneme za jeden provaz.
Naše skvělé HR si taky dává záležet, aby se každý týden objevovalo ve všech našich kancelářích. Má tak velmi dobrý pojem o atmosféře všude ve firmě a o preferencích specifických týmů. Příjemným vedlejším účinkem jsou i spontánní popracovní degustace alkoholických nápojů, při kterých se, jak známo, vztahy utužují nejlépe.
Po 5 letech provozu datacentra a 14 letech fungování rozhodně nemáme patent na rozum. Ale jdeme stále kupředu, nepřestáváme na sobě pracovat a hlavně: pořád nás to baví.
Jak jsme upgradovali infrastrukturu GymBeam na megavýkonné EPYC servery
Jak a proč jsme GymBeamu vylepšili infrastrukturu, co je na EPYC serverech tak skvělého a pro koho je tento hardware nejvhodnější.
Posílili jsme infrastrukturu jednoho z největších e-commerce projektů u nás a na Slovensku: GymBeamu. A nejde o ledajaké vylepšení – upgradovali jsme aplikační část jejich clusteru na extra výkonné AMD EPYC servery (celkem 8 kousků).
Jak probíhala instalace, co to pro GymBeam znamená, jaké mají EPYC servery výhody a může se takové vylepšení vyplatit i vám? To vše se dočtete v tomto článku.
Co je na EPYC serverech tak epického?
Donedávna jsme se vshosting~ soustředili na servery s procesory Intel Xeon, které poli nejen serverových produktů dominují dlouhou řadu let. V posledních několika letech nás ovšem zaujalo i značné zlepšení nabídky a výrobních technologií společnosti AMD (Advanced Micro Devices).
Tato společnost nově nabízí procesory, které poskytují lepší poměr cena/výkon, vyšší počet jader na CPU a lepší správu spotřeby energie (mj. díky rozdílné výrobní technologii – AMD Zen 2 7nm vs. Intel Xeon Scalable 14nm). Tyto procesory využívají i extrémně výkonné AMD EPYC servery, které jsme použili pro infrastrukturu GymBeam.
Jde o nejmodernější servery s rekordními procesory, které mají až 64 jader a 128 vláken (!!!). Oproti standardu Intel Xeon Scalable, kde poskytujeme procesory s maximálně 28 jádry na jeden CPU, se objem výpočetních jader na jednotku více než zdvojnásobil.
Procesory EPYC serverů jsou vyráběny 7 nm výrobním procesem a metodou více čipletů v jednom pouzdře, která umožňuje vměstnat všech 64 jader na jedno CPU a zajistit tak opravdu úctyhodný výkon.
Jak probíhala instalace
Instalace prvních serverů založených na této pro nás nové platformě probíhala naprosto standardně. Prvním krokem byl pečlivý výběr komponent a unifikace platformy pro všechny budoucí realizace. Nejdůležitější na samotném začátku bylo ve spolupráci s dodavateli a specialisty správně zvolit nejlepší sestavení platformy, které budeme aplikovat na všechny budoucí instalace AMD EPYC. To zahrnuje výběr vhodného chassis, vhodné serverové desky, periferií včetně výkonnějších 20k RPM ventilátorů pro dostatečné chlazení atd. Nová platforma musí odpovídat vysokým standardům našich ostatních realizací – pro kompromisy není místo.
Výsledkem naší práce se servery s AMD EPYC do naší „flotily“ zařadily velmi hladce a rychle. Servery jsou založené na chassis a základních deskách od výrobce SuperMicro a umíme podle preferencí zákazníka nabízet jak 1Gbps tak 10Gbps přípojku a připojení pevných disků jak on-board tak s pomocí fyzického RAID řadiče. Pevné disky nadále aplikujeme z naší nabídky, a to SATA3//SAS2 či PCI-e NVMe. Přečtěte si víc o rozdílech mezi SATA a NVMe discích.
Jelikož se jedná o novou platformu, samozřejmě jsme zásobili sklad osazenými SPARE zařízeními, která jsme schopni okamžitě použít v případě závady na produkci.
Výhody nového hardwaru pro byznys GymBeam
Rozdíl oproti původním procesorům Intel je obrovský: kromě většího počtu jader je vyšší i výpočetní výkon na jednom jádře. Další navýšení výkonu zajišťuje zapnutí technologie Hyperthreading, které na procesorech Intel z bezpečnostních důvodů vypínáme, ale na procesorech AMD EPYC k tomu není (alespoň zatím) žádný důvod.
Výsledkem celkového navýšení výkonu je zaprvé významné zrychlení načítání webu způsobené vyšším výkonem na jádro. To vítají především zákazníci GymBeam, pro něž je nákup na e-shopu teď ještě příjemnější. Zrychlení webu také zlepší SEO a celkově zvedne vyhledávačovou „karmu“.
Kromě rychlejšího načítání získal GymBeam velkou výkonnostní rezervu pro své marketingové akce. Nová infrastruktura zvládne i několikanásobné zvýšení návštěvnosti v případě intenzivních reklamních kampaní.
V neposlední řadě si teď v GymBeamu mohou být jistí, že fungují na tom nejlepším železe na trhu 🙂
Vyplatí se i vám upgrade na EPYC „železo“?
Zaujaly vás megavýkonné EPYC procesory a zvažujete, jestli by se i vám vyplatily? Pokud vám jde o optimalizaci poměru cena/výkon, otázkou číslo jedna je jak moc výkonnou infrastrukturu váš projekt potřebuje.
Procesory AMD EPYC má smysl zvažovat v situaci, kdy vašim stávajícím procesorům začne docházet dech a upgrade na vyšší řadu Intel Xeon by nedával ekonomický smysl. Ta hranice je aktuálně cca 2x 14core – 2x 16core. Cena vůči nabídnutému výkonu nad tuto hranici je teď u Intelu neúměrně vysoká.
Důvodem upgradu ale samozřejmě nemusí být čistě technický či ekonomický – ten pocit, že provozujete služby na tom nejrychlejším a nejlepším co trh nabízí, má samozřejmě také svoji hodnotu.
Přerostli jste klasický webhosting – a co teď? Srovnali jsme možnosti „upgradu“
Co je lepší – VPS, vlastní server, „dedikáč“ anebo nějaký typ managed služby?
Důvodů proč opustit webhosting je celá řada: možná potřebujete větší flexibilitu nastavení, větší webový limit, dostupnost nebo výkon, případně chcete používat specifické softwarové vybavení, které si s webhostingem zrovna netyká. Webhosting už je Vám prostě malý.
Na druhou stranu webhosting poskytuje poměrně vysokou uživatelskou přívětivost: ovládáte ho přes grafické rozhraní, poskytovatel se stará o vše okolo hardwaru i softwaru a Vy toho vlastně nemusíte moc řešit. Vybrat tedy nové hostingové řešení, které Vám poskytne podobné pohodlí, není tak snadné.
Kam dál?
Flexibilnějších a výkonnějších alternativ webhostingu na trhu potkáte mnoho. Těmi nejpodobnějšími z uživatelského pohledu jsou VPS a managed služby. Zároveň můžete uvažovat i o dedikovaném serveru nebo vlastním fyzickém serveru.
A protože realita umí být pěkná mrcha, každá z těchto variant disponuje kromě mnoha výhod také nevýhodami. Pojďme se na ně podívat.
VPS
Na první pohled nejlákavější možností je takzvané VPS, tj. virtual private server. Oproti webhostingu získáte u VPS plnouvolnost a můžete tak instalovat, jaký software chcete a vše si nastavit k obrazu svému. VPS také vyjde poměrně levně, což je obzvlášť pro začínající projekty lákavé.
Plná volnost ale má i odvrácenou stránku – o všechno se musíte starat sami. Tím myslíme opravdu všechno. Instalace, updaty, bezpečnostní opatření, jakékoliv změny, řešení problémů, zálohování atd. atd. Potřebujete proto vlastního administrátora, který zajistí, že všechno bude dobře fungovat a Váš projekt zůstane v bezpečí.
Při správě vlastního hostingového serveru na Vás totiž číhá plno nástrah, které musíte umět identifikovat a zajistit, že Vás „nedostanou“.
Vlastní fyzický server
Další variantou, na kterou můžete z webhostingu přejít, je pořídit si vlastní server. Získáte tak mnohem vyšší výkon než u webhostingu nebo VPS a zároveň i velkou flexibilitu. Na druhou stranu jsou s ním spojeny podobné nevýhody jako s VPS – všechno si musíte řešit sami. Což je nákladné, otravné a ještě pěkně nebezpečné (pokud Váš administrátor není opravdu borec a nefunguje 24 hodin denně).
Kromě správy softwaru si oproti VPS musíte navíc řešit i vše ohledně hardware – zajistit chlazení, stálý přívod energie (což není tak samozřejmé, jak se zdá – aneb strčit server do zásuvky nestačí), řešit veškeré hardwarové problémy a tak dále. Vlastní fyzický server tak s sebou nese největší riziko výpadku, kybernetických útoků a podobně.
Dedikovaný server
Dedikovaný server se od vlastního fyzického serveru liší tím, že jde vlastně o server jako službu, kde hardwarové záležitosti a často i prvotní instalaci obstará váš poskytovatel. Řeší také všechny nenadálé situace ohledně hardwaru – například u nás ve vshosting~ jakýkoliv hardwarový problém vyřešíme do 60 minut a to ve dne i v noci.
„Dedikáč“ je zároveň umístěn v datacentru, které bývá dobře zabezpečené proti výpadkům elektřiny nebo třeba vniknutí cizích osob. Bude mít také lepší konektivitu, než kdybyste si server zapojili ve vlastní provizorní serverovně.
Oproti webhostingu je dedikovaný server samozřejmě mnohem výkonnější a můžete si na něj nainstalovat v podstatě co chcete. Softwarová stránka věci je ale stále na vás, stejně jako u VPS nebo vlastního fyzického serveru. Bez admina se tedy neobejdete, což představuje náklady navíc.
Managed služby
Nejpříjemnější upgrade z webhostingu je bezpochyby na managed server nebo nějakou robustnější managed službu. Z uživatelského pohledu je to totiž takový webhosting na steroidech: služba se stejně snadno ovládá a poskytovatel hostingu se stará o všechny provozní záležitosti (software i hardware). Zároveň máte k dispozici řádově vyšší výkon a nesrovnatelně větší flexibilitu co se týká nastavení, kompatibility s různými softwary a tak dále.
To v důsledku znamená, že nemusíte mít vlastního administrátora, provoz serveru nemusíte vůbec řešit a všechno funguje, jak má. A když náhodou ne, je na poskytovateli, aby problém co nejrychleji vyřešil. Vy se tak můžete soustředit jen na svůj core business.
Pokud se rozhodnete pro managed službu, nejspíš narazíte na dilema, zda jít do cloudu nebo raději zvolit fyzický server. Nedá se plošně říct, zda je jedno lepší než druhé – záleží na Vaší konkrétní situaci.
V případě, že máte menší, ale rychle rostoucí internetový projekt a je pro Vás zásadní vysoká dostupnost a flexibilita, cloud je pro Vás jasná volba. Vzhledem k nižšímu požadovanému výkonu pro Vás cloudové řešení nejspíš bude i cenově výhodnější. Pokud časem cloud přerostete, můžete bez problému přejít na fyzické řešení.
Jestli Váš byznys vyžaduje velký výkon nebo ukládání velkého množství dat, vyplatí se jít rovnou cestou fyzického serveru. Ten toho totiž „utáhne“ víc a na jednotku výkonu většinou vychází levněji než cloud.
Není managed služba jako managed služba
Managed služby jsou díky své uživatelské přívětivosti čím dál populárnější. Bohužel ne každý poskytovatel chápe „managed“ jako skutečně plnou správu a klienti pak mohou být nepříjemně překvapeni.
V ideálním případě u managed služby poskytovatel provádí prvotní instalaci, veškerý monitoring serveru, updaty operačního systému i řešení všech nenadálých situací – ať už jde o hardwarový nebo softwarový problém. Tak to probíhá například u nás ve vshosting~.
Jiní poskytovatelé si ale pod managed službou mohou představovat pouze prvotní instalaci softwaru a následnou starost o hardware. Případně si za řešení softwarových problémů účtují další poplatky. Doporučujeme tedy dobře prostudovat, co všechno Vámi zvolená managed služba opravdu zahrnuje.
Nejlepší řešení pro Váš projekt
Vybrali jste?
Ze zkušenosti víme, jak těžké rozhodování to je. Všechno je individuální a nejlepšího výsledku zpravidla dosáhnete, když je hosting ušitý přímo na míru Vašemu projektu.
Pokud si stále nejste jistí, kontaktujte nás. Naši experti Vám rádi poradí, jaká varianta bude pro vás nejvýhodnější.
NVMe vs. SATA: Který SSD disk je pro váš server nejlepší?
Porovnáváme 2 typy profesionálních SSD disků: 2,5“ SATA SSD a 2,5“ NVMe.
Vybíráte nový dedikáč nebo managed server a přemýšlíte, který SSD disk je pro Vás nejvhodnější? Ve vshosting~ si zakládáme na maximální kvalitě, ale protože potřeby našich klientů se často výrazně liší, nabízíme 2 typy profesionálních SSD disků: 2,5“ SATA SSD a 2,5“ NVMe (oba od Intelu). Pojďme se podívat, jaké jsou mezi jednotlivými řadami disků, které si u nás můžete vybrat, rozdíly.
Modely disků SATA
2,5“ SATA SSD Intel, řada S4510
– sekvenční čtení a zápis se pohybuje v řádech stovek MB za sekundu
– nejčastěji do cca 500 MB/s, záleží na modelu
2,5“ SATA SSD Intel, řada S4610
– lepší disky s vyšší durabilitou než S4510
– jsou vhodnější pro databázové servery než S4510
– sekvenční čtení a zápis je na obdobné úrovni jako u S4510
Modely disků NVMe
2,5“ NVMe (rozhraní PCIe 3.1 x4) Intel, řada P4510
– sekvenční čtení a zápis se pohybuje v řádech tisíců MB za sekundu
– nejčastěji do cca 3200 MB/s, záleží na modelu
– to je několikanásobně vyšší hodnota v porovnáním s klasickými SATA SSD
2,5“ NVMe (rozhraní PCIe 3.1 x4) Intel, řada P4610
– lepší disky s vyšší durabilitou než P4510
– vhodnější pro databázové servery než P4510
– sekvenční čtení a zápis na obdobné nebo i lepší úrovni jako P4510
Jak SATA tak NVMe servery navrhujeme tak, aby pevné disky byly hot-swap, tzn. vyměnitelné za běhu zařízení a systému. Případné opravy či výměny jsou tak velmi jednoduché. Nepoužíváme NVMe disky rozhraní M.2 PCIe, které se montují přímo na základní desku a jsou tedy pro technika fyzicky nepřístupné.
RAID na NVMe discích oproti SATA SSD
SATA disky většinou konfigurujeme v HW RAIDu (RAID je řízen samostatným diskovým řadičem). NVMe disky však pracují na rozhraní PCIe, diskové řadiče tohoto typu jsou tedy buď výkonnostně nevyhovující anebo neúměrně drahé. NVMe disky jsou v serverech tedy zapojeny přímo na konektory základních desek, kde jednotlivé PCIe linky obsluhuje samotné CPU. NVMe servery realizujeme na SuperMicro řešeních. SuperMicro totiž pro toto použití vyvinulo pro nás vhodné řešení.
Oproti SATA diskům jde tedy RAID řešit na NVMe discích dvěma různými způsoby. První možností je instalace dodatečného hardware klíče na základní desku, což aktivuje funkci Intel VRAID on CPU. V BIOSu serveru jsme schopni následně nakonfigurovat RAID 0/1/10/5 z NVMe disků, operační systém poté pracuje s jedním virtuálním diskem. Druhou variantou je RAID pro systém vůbec nekonfigurovat a řešit jej následně softwarově v rámci OS (například pomocí ZFS atd.).
Tak tedy SATA nebo raději NVMe?
Jednoduše řečeno NVMe disky jsou 6,5 x rychlejší než SATA, což je velké plus. Na druhou stranu jsou o něco dražší, takže volba mezi NVMe a SATA není úplně jednoduchá.
NVMe disky jsou rozhodně vhodnějším řešením pro někoho, kdo shání extrémní datovou propustnost na úložišti, ať už náročného databázového serveru, webserveru či čehokoli jiného s předpokladem vysoké zátěže. Tyto disky ve vshosting~ umíme provozovat jak na managed serverech s Linux (Ubuntu 18, Debian), tak na dedikovaných serverech s Windows, kde je správa OS v režii klienta.
Faktorem ke zvážení je ale i fakt, že NVMe disky lze u vshosting~ používat pouze na současných Intel Xeon Scalable CPUs. Oproti tomu SATA disky můžeme používat takřka na jakoukoliv generaci Intel Xeon procesorů a to díky námi dodávaným samostatným diskovým řadičům.
Výhody Kubernetes od vshosting~ oproti tradičním cloudům
Čím se liší vshosting~ Kubernetes platforma od těch od Amazonu, Googlu nebo Microsoftu? Rozdílů je překvapivě hodně.
Klienti se nás často ptají, čím se naše nová služba Platform for Kubernetes liší od podobných produktů například od Amazonu, Googlu nebo Microsoftu. Rozdílů je poměrně hodně, proto jsme se je rozhodli do detailu popsat v tomto článku.
Individuální návrh infrastruktury
Většina tradičních cloud providerů poskytuje platformu pro infrastrukturu, ale návrh a samotná tvorba infrastruktury je na klientech – respektive na jejich vývojářích. Valná většina vývojářů Vám ovšem potvrdí, že by se mnohem raději věnovali vývoji než četbě 196-stranné příručky o tom, jak používat Amazon EKS. Příručku je navíc, narozdíl od většiny návodů, opravdu potřeba přečíst – nastavování Kubernetes u Amazonu totiž není zrovna intuitivní.
Ve vshosting~ víme, jak moc je tohle pro spoustu firem frustrující. Vývojový tým by se měl zabývat vývojem a neztrácet čas něčím, co ani nepatří do jeho specializace. Proto si zakládáme na tom, že narozdíl od tradičních cloudů, Kubernetes řešení šijeme každému klientovi na míru. Nemusíte si tedy u nás složitě vybírat z předdefinovaných balíčků, číst dlouhé návody ani vymýšlet, jaká infrastruktura bude pro Vaše potřeby nejlepší. Navrhneme infrastrukturu Kubernetes přesně pro potřeby Vaší aplikace, a to včetně load balancingu, networkingu, storage a dalších nezbytností.
Kromě toho Vám rádi pomůžeme s analýzou aplikace pro přechod do Kubernetes, pokud ho ještě nepoužíváte. Na základě Vašich požadavků také poradíme s výběrem těch nejvhodnějších technologií (konzultace je v ceně služby!), aby vše běželo, jak má a následné škálování bylo co možná nejjednodušší.
Když už jsme u škálování, to je u nás mimořádně snadné. Opět se nekoná žádné vybírání z balíčků výkonu atd., u vshosting~ prostě plynule škálujete dle aktuální potřeby. Nabízíme také možnost jemného škálování jen u potřebných prostředků. Potřebuje Vaše aplikace kvůli nárůstu klientů více RAM, nebo větší diskový prostor? Není problém.
Poté, co vytvoříme customizovaný návrh infrastruktury, provedeme individuální instalaci a nastavení Kubernetes i loadbalancerů před předáním do ostrého provozu. Jen pro představu, u Googlu, Amazonu nebo Microsoftu by všechny tyto úkony byly na Vás. U vshosting~ také vše ve spolupráci s Vámi pečlivě odladíme. Po spuštění poběží Kubernetes v našem cloudu nebo na špičkovém hardware v našem vlastním datacentru ServerPark.
Možnost kombinace fyzických serverů a cloudu
Další výhodou Kubernetes od vshosting~ je možnost kombinovat fyzické servery s cloudem – ostatní Kubernetes poskytovatelé toto vůbec neumožňují. Díky tomu si například můžete začít testovat Kubernetes na Virtual Machine s nižším výkonem a teprve poté přejít s projektem do produkce přidáním fyzických serverů (to vše u nás jde za běhu) s případným zachováním stávajících VMs pro vývoj.
Pro srovnání: třeba Google Vám sice nabídne buď možnost on-prem Google Kubernetes Engine nebo variantu v cloudu, ale musíte si vybrat jedno z toho. Navíc on-prem variantu si musíte spravovat „na vlastní triko“. Variantu kombinující fyzické servery a cloud nenajdete ani u Amazonu a Microsoftu.
U nás je možné fyzické servery s cloudem kombinovat dle libosti a navíc se Vám postaráme o kompletní správu – Vy už se můžete soustředit jen a jen na vývoj. Dohlédneme na správu operačních systémů všech Kubernetes nodů a loadbalancerů, zajistíme i průběžné upgrady operačních systémů, kernelu apod. (po domluvě i upgrade Kubernetes).
Vysoké SLA a senior support 24×7
Jedním z nejdůležitějších kritérií výběru dobré Kubernetes platformy je její dostupnost. Možná Vás proto překvapí, že Microsoft AKS ani Google GEK neposkytují SLA („financially-backed service level agreement“) a pouze tvrdí, že se „vynasnaží zajistit alespoň 99,5% dostupnost“.
Amazon EKS sice mluví o 99,9% SLA, ale vzhledem k jejich podmínkám vrácení kreditu jde ve skutečnosti pouze o garanci 95% dostupnosti – Amazon totiž vrací 100 % kreditu teprve při této úrovni dostupnosti. V případě pouze mírného poklesu pod 99,9 % dostupnosti Vám vrátí jen 10 % kreditu.
Ve vshosting~ Vám smluvně garantujeme 99,97% dostupnost, tedy ještě více než poněkud teoretické SLA u Amazonu a výrazně více než negarantovaná dostupnost 99,5 % u Microsoftu a Googlu. Reálně se dostupnost u nás pohybuje dokonce na 99,99 %. Managed Kubernetes řešení u nás navíc funguje v režimu high-availability cluster, tudíž v případě poruchy jednoho serveru nebo části cloudu celé řešení ihned startuje na záložním serveru či v jiné části cloudu.
Zaručujeme také vysokorychlostní konektivitu i neomezené datové toky do celého světa. Každému klientovi navíc garantujeme vyhrazenou šířku pásma do internetu. Naše síť má kapacitu až 1 Tbps a každá trasa je mnohonásobně zálohovaná.
Díky režimu high-availability cluster, vysoké kapacitě sítě a zálohovanému připojení je Kubernetes řešení od vshosting~ mimořádně odolné proti výpadku jakékoliv části clusteru. Kromě toho naše zkušené týmy Vaše řešení neustále monitorují a případné začínající problémy rychle identifikují, než se mohou projevit pro koncového uživatele. Máme také robustní AntiDDoS ochranu, která celý cluster efektivně chrání před kyberútoky.
Debugging a monitoring celé infrastruktury
Oproti tradičním cloud providerům, ve vshosting~ na Vaše řešení dohlížejí týmy senior administrátorů a techniků neustále 24/7, sedí přímo v našem datacentru a v případě problému reagují do 60 sekund – a to klidně v sobotu ve 2 ráno. Tito experti za Vás neustále monitorují desítky parametrů celého řešení (hardware, loadbalancery, Kubernetes) a díky tomu dokážou většině problémů zabránit předtím, než se pořádně projeví. Navíc garantujeme opravu nebo výměnu nefunkčního serveru do 60 minut.
Pro maximální zjednodušení od nás dostanete jeden servisní kontakt pro všechny služby: ať jde o Kubernetes jako takový, jeho správu nebo cokoliv ohledně infrastruktury. Vyřešíme běžnou údržbu i složitý debugging. V rámci ceny služby Platform for Kubernetes nabízíme také konzultace ohledně konkrétní podoby Dockerfiles (3 hodiny měsíčně).
Privátní cloud od vshosting~
Pohodlí cloudu s maximální bezpečností vyhrazeného řešení: Private Cloud od vshosting~
Ať se nám to líbí nebo ne, žijeme v době cloudové. Zvykli jsme si na možnost snadno a prakticky okamžitě přidávat další výkon a zase ho odebírat, když zátěž opadne.
Na první pohled to vypadá krásně – platíme jenom za kapacitu, kterou skutečně potřebujeme a jenom tehdy, když ji potřebujeme. Neřešíme sklad náhradních dílů, nemusíme vstávat ve tři ráno k rozbitému serveru. Tato idylka má ale i své nevýhody, které nemusí být na první pohled zřejmé.
Přesunutím aplikací do cloudu jsme se vzdali možnosti si nastavit celé prostředí podle sebe, výkon musíme přidávat a odebírat po připravených “balíčcích”, naše data dáváme třetí straně s myšlenkou, že “přeci je nebudou zajímat data českého miniprojektu” a zavádíme si do aplikace zbytečný vendor lock-in přes různá SDK a API služeb cloudu. Vzdali jsme se architektonické svobody a výměnou za ni jsme dostali pohodlí.
Ale co když to jde i jinak? Co když můžeme vzít výhody cloudu a nasadit je na řešení, které budeme mít plně pod kontrolou? Co když si můžeme postavit náš vlastní, soukromý cloud?
Proxmox – virtualizační platforma
První krok je vždy ten nejtěžší a nejinak tomu bylo i tentokrát, když jsme ve vshosting~ vybírali platformu, na které řešení privátních cloudů postavíme. Do užšího výběru se dostalo několik softwarových balíků, z nichž jsme nakonec vybírali mezi dvěma kandidáty a to OpenNebulou a Proxmoxem. Oba tyto nástroje umožňují široké použití, nakonec jsme ale zvolili i s ohledem na jednoduchost administrace Proxmox.
Proxmox sám o sobě je distribuce postavená na aktuálním Debianu s pár vylepšeními. Out-of-the-box podporuje KVM virtualizaci (plnohodnotné virtuální stroje) i LXC kontejnerizaci (linux-only kontejnery), vysokou dostupnost, clusterizaci, migraci virtuálů mezi nody, škálování za běhu virtuálního stroje a další funkce. To všechno zabalené v příjemném webovém rozhraní, CLI nebo REST API. Detailní popis funkcí naleznete na webu Proxmoxu.
Proxmox sám o sobě velmi dobře škáluje od jednoho nodu po několik desítek výpočetních nodů v clusteru (tvrdý limit je kolem 100 nodů v jednom clusteru). Po našich provozních zkušenostech jsme se ale rozhodli omezit velikost jednoho clusteru na 12 nodů. Ostatně větší nasazení je tak jako tak vhodnější rozdělit do menších samostatných clusterů, které mohou být samy o sobě velmi výkonné.
Spřáhnout do jednoho virtualizačního clusteru 12 strojů, kdy každý má v sobě 4 výkonné Xeon procesory s 12 fyzickými jádry (24 vláken) doplněné o 512 GB RAM, nabízí dostatečný výkon i pro největší projekty, které u vshosting~ provozujeme. Ale pokud chcete, umíme udělat i větší a šílenější setupy.
Lehké kontejnery i plnotučné virtuální stroje
Jak už jsem zmínil, Proxmox nabízí dva typy virtualizace – plnou virtualizaci pomocí KVM a kontejnerizaci s LXC. Výhodou KVM je plná emulace hardware, takže není problém do něj nainstalovat kromě Linuxu i MS Windows, Mikrotik RouterOS nebo Android (pokud máte licenci). Nevýhodou KVM je fakt, že nejsou žádné součásti systému sdílené s hypervisorem. Virtuální stroje v KVM jsou tedy paměťově náročnější.
Pokud chcete provozovat linuxové aplikace, vhodnou variantou je použití kontejnerizace LXC. Zde je kernel sdílen s hypervisorem, odpadá tedy nutnost počítat v kontejneru s pamětí pro jádro. Velkou nevýhodou kontejnerů je ale pouze částečná izolace prostředí a ne všechny aplikace si s nimi dovedou poradit. Například se nám v LXC nepovedlo rozjet GlusterFS server nebo NFS exporty.
Obě virtualizační technologie je možné v rámci clusteru libovolně kombinovat dle potřeby.
My šroubky, vy aplikaci
Privátní cloud nabízíme v managed režimu. To znamená, že my se staráme o všechno pod úroveň virtuálních strojů. Hardware, disky, síť, konektivita, elektřina, chlazení, ale i software hypervisorů jako takových – to všechno je naše starost, v tomto není rozdíl proti veřejným cloudům. V čem ale výrazný rozdíl je, to je výkon. Privátní Proxmox běží na fyzických strojích vyhrazených pouze pro konkrétní cluster, zákazník má k dispozici 100 % kapacity. Žádné sdílení prostředků, žádná agregace.
Zákazník si pak už výkon rozděluje mezi jednotlivé kontejnery a virtuální stroje, sám si vybírá, co na nich poběží za operační systém, aplikace, jejich konfiguraci.
Storage, firewall a další služby
V základním setupu se disky virtuálních strojů ukládají na disky přímo v serverech. Toto řešení je velmi výkonné ale neumožňuje live migrace virtuálních strojů mezi nody nebo restart VM na jiném nodu v případě jeho selhání.
Toto lze řešit pomocí síťového storage, který nabízíme pod názvem Cloud storage. V Proxmoxu jej uvidíte jako běžný storage dostupný napříč celým clusterem. Virtuální stroje a kontejnery, které mají své disky umístěny na tomto storage, je možné snadno bez výpadku migrovat mezi nody nebo je automaticky nastartovat na jiném stroji, pokud aktuální výpočetní node selže.
Kromě úložiště disků můžete Cloud storage využít i jako objektový storage kompatibilní s S3, o tom si ale povíme v jiném článku. Jako ke každé naší managed službě si můžete k privátnímu cloudu pořídit managed firewall Cisco ASA, DDoS Protect ochranu nebo až 10Gbps globální konektivitu.
Horizontální škálování MySQL
Jak efektivně rozložit databázi do několika serverů a čeho se vyvarovat.
Databázové servery jsou kritickou částí infrastruktury každého webového projektu a se vzrůstající velikostí roste také jejich význam. Dříve či později se ale dostaneme do stavu, kdy výkonové požadavky na databázi nebude možné řešit pouze přidáváním další paměti a vylepšováním procesorů. Navyšování zdrojů jednoho serveru má své technické limity a časem skončíme u nutnosti rozložit zátěž do více serverů.
Před realizací takového kroku je více než vhodné si ujasnit, čeho chceme dosáhnout. Některé modely distribuce zátěže nám pouze pomohou zvládnout vyšší množství požadavků, některé nám vyřeší i problém případné nedostupnosti jednoho ze strojů.
Škálování, vysoká dostupnost a další pojmy
Nejdříve se pojďme podívat na základní pojmy, se kterými budeme dnes operovat. Není jich mnoho, ale bez jejich znalosti se nehneme dál. Zkušení škálovači mohou tuto část s klidným svědomím přeskočit.
Škálovatelnost (scalability)
Schopnost systému (v našem případě databázového prostředí) reagovat na zvýšenou nebo sníženou potřebu zdrojů. V praxi rozeznáváme dva základní druhy škálování a to škálování vertikální a horizontální.
Při vertikálním škálování zvyšujeme prostředky, které má daná databáze k dispozici. Typicky se jedná o přidávání dostupné paměti serveru a zvyšování počtu jader. Vertikálně lze škálovat prakticky libovolnou aplikaci, dříve či později ale narazíme na hardwarové limity platformy.
Proti tomu stojí horizontální škálování, kdy výkon aplikace zvyšujeme přidáváním dalších serverů. Tímto způsobem můžeme zvyšovat výkon prakticky neomezeně, aplikace musí ale s tímto způsobem distribuce počítat.
Vysoká dostupnost (high availability)
Schopnost systému reagovat na výpadek části systému. Předpokladem pro vysokou dostupnost je schopnost provozovat aplikaci ve více instancích.
Další instance mohou být plnohodnotně zastupitelné a zpracovávat požadavky paralelně (active-active setup) nebo mohou být v režimu stand-by, kdy na sebe pouze zrcadlí data, ale nejsou schopny odbavovat provoz (active-passive setup). V případě problému je vybrána jedna z instancí v passive režimu a je převedena do active.
Master node
Řídící komponenta systému. V případě databází se jedná o instanci v režimu čtení i zápisu. Pokud máme více plnohodnotných master nodů, mluvíme o tzv. multi-master setupu.
Slave node
Záložní kopie dat. V klidovém stavu na sebe zrcadlí data a funguje v režimu pouze pro čtení. Pokud dojde k výpadku master nodu, je jeden ze slave nodů vybrán a převeden do master režimu. Po opravě původního master nodu se buď nový master vráti do stavu slave, nebo zůstává masterem a původní master je připojen jako slave node.
Asynchronní replikace
Po zápisu dat na master nodu je tento zápis potvrzen klientovi a zapsán do transakčního logu. Později v čase je tato změna replikována na slave nody. Dokud nedojde k replikaci, jsou nová nebo změněná data dostupná pouze na master nodu a v případě jeho výpadku jsou nedostupná. Asynchronní replikace je typická pro MySQL.
Synchronní replikace
Klientovi je zápis potvrzen až poté, co jsou data zapsaná na všechny nody v clusteru. Odpadá zde riziko výpadku nových dat (data jsou změněna všude nebo nikde), je ale výrazně náchylnější k problémům na síti mezi nody.
V případě síťového výpadku je výkon clusteru dočasně degradován, nebo je dokonce dočasně zastaven příjem nových požadavků na změnu dat. Tento způsob replikace se využívá v případě multi-master setupů v kombinaci s pluginem Galera.
Master – Slave replikace
Master – slave je základní podoba replikace databázového clusteru. V tomto návrhu máme jeden řídící master node, který přijímá všechny typy dotazů. Slave node (případně více nodů) na sebe zrcadlí změny pomocí asynchronní replikace. Slave nody tedy nemusí mít k dispozici nejnovější kopii dat.
Pokud dojde k výpadku master nodu, je vybrán slave s nejnovější kopií dat a ten je prohlášen za nový master. Každý slave node si ověřuje, o kolik je zpožděn oproti master nodu. Tuto hodnotu můžeme zjistit v proměnné Seconds_behind_master a je velmi důležité ji monitorovat. Vzrůstající hodnota ukazuje na problém v replikaci změn na master nodu.
Slave node funguje v režimu read-only, dokáže tedy odbavovat dotazy typu select. V tom případě mluvíme o tzv. read/write splitu, o kterém se zmíníme dále.
Master – Master replikace
Master – master setup je takový, kde máme právě dva master nody. Oba dva jsou schopni odbavovat všechny typy dotazů, mezi nimi ale probíhá asynchronní replikace. To přináší nevýhodu v případě, kdy data zapsaná na první node nemusí být okamžitě dostupná na druhém nodu. V praxi toto nastavujeme tak, že každý node je zároveň slave nodem druhého.
Tento setup se hodí v okamžiku, kdy před MySQL servery postavíme loadbalancer, který na každý stroj směřuje polovinu spojení. Každý node je ale samostatným masterem, neví nic o tom, že druhý node je taky v master režimu a je tedy nutné nastavit krok auto incrementu na 2. Pokud toto neprovedeme, bude docházet ke kolizím primárních klíčů, které využívají auto increment.
Každý z master nodů může mít u sebe další slave nody, které lze použít pro čtení dat (read/write split) a jako zálohu.
Multi – Master replikace
O multi-master setupu mluvíme v okamžiku, kdy máme v clusteru více než dva master nody. Tento setup nelze postavit v základní MySQL, ale musíme použít implementaci protokolu wsrep, např. plugin Galera.
Wsrep implementuje synchronní replikaci a tedy je velmi náchylný na problém na straně sítě a vyžaduje také časovou synchronizaci všech nodů. Umožňuje ale zasílat všechny typy dotazů na všechny nody v clusteru, takže je velmi vhodný pro řešení loadbalancingu. Nevýhodou je fakt, že všechny replikované tabulky musí používat engine innodb, tabulky využívající jiný engine nebudou replikovány.
Shardování
Shardování je dělení dat na logické segmenty. V MySQL se pro tento způsob ukládání dat používá název partitioning a prakticky znamená, že data jedné tabulky jsou rozkládány na různé servery, různé tabulky nebo různé datové soubory v rámci jednoho serveru.
Shardování dat je vhodné v situaci, kdy máme data, která tvoří oddělené skupiny. Typickou ukázkou jsou např. historické záznamy (shardujeme podle času) nebo data uživatelů (shardy vytváříme podle ID uživatele). Díky rozkladu dat do samostatných skupin můžeme efektivně kombinovat různé druhy storage, kdy aktuální data máme na rychlých SSD discích a starší data, u kterých nepředpokládáme časté využití, ukládáme na levnější rotační disky.
Shardování se velmi často používá v NoSQL databázích, napřiklad ElasticSearch.
Read – Write splitting
V režimu Master-Slave replikace máme k dispozici výkon slave nodů, který ale nemůžeme použít pro zápisové operace. Pokud ale máme aplikaci, kde tvoří většinu dotazů pouze selecty (typicky webové projekty), můžeme jejich výkon využít pro čtení. V tomto případě tedy aplikace směřuje zápisové operace (insert, delete, update) na master node, ale selecty posílá na skupinu slave nodů.
Díky tomu, že jeden master node může mít mnoho slave nodů, pomůže nám read/write splitting se zvýšením odezvy celé aplikace pomocí rozkládání čtecích operací.
Toho chování není potřeba na straně databázového serveru nijak konfigurovat, je ale potřeba jej řešit na straně aplikace. Nejjednodušší variantou je v aplikaci udržovat dvě spojení, jedno pro zápis a druhé pro čtení. Aplikace se pak podle typu dotazu rozhoduje, jaké spojení pro daný dotaz použije.
Druhou variantou, vhodnou pro případ, kdy nejsme schopni implementovat read/write split na úrovni aplikace, je využití aplikační proxy, která rozumí dotazům a je schopna je automaticky předávat na odpovídající nody. Aplikace si drží pouze jedno spojení na proxy a nestará se o druhy dotazů. Typickým představitelem takové proxy je řešení od Maxscale. Bohužel se jedná o komerční produkt, nabízí ale verzi zdarma s omezením na tři databázové nody.
Škálujeme za vás
Nemáte kapacitu či chuť na to, spravovat si a škálovat databáze sami? Uděláme to za vás.
Postaráme se i o velmi složitý provoz a vyladění široké škály databází. Zajistíme jejich maximální stabilitu, dostupnost a škálovatelnost. Náš tým adminů spravuje desítky tisíc databázových serverů a clusterů, takže budete v rukou opravdových expertů.
vshosting~
