Představte si, že jste uprostřed největší sezony, marketingové kampaně jedou na plné obrátky a objednávky se jen hrnou. Pěkná představa, že? Pokud vám tedy najednou nepřestane fungovat databáze. Nepozorný kolega ji omylem smazal. Anebo třeba selhalo diskové pole –⁠ to je v konečném důsledku jedno, výsledek je stejný. Objednávky začnou padat do černé díry. Netušíte, co si kdo koupil a za kolik, natož kam mu to máte poslat. Databázi máte samozřejmě zálohovanou, ale byla poměrně dost objemná a její obnova může trvat několik hodin. 

Co teď?

Vyhrnout rukávy, začít potřebné informace manuálně tahat z e-mailových logů a dalších temných zákoutí. A doufat. Snad vám nic neuteklo. Těch několik hodin obnovy ale bude opravdu dlouhých a neskutečně drahých. Některé objednávky se navíc zcela jistě ztratí a hodiny výpadku databáze budete naneštěstí ještě několik dní manuálně dohánět.

Klasické zálohování databází (a proč obnova tak trvá)

Standardní zálohování, na které je většina větších e-shopařů zvyklá, probíhá metodou tzv. „dumpu“, kdy se celá databáze uloží jako jeden soubor. V něm jsou obsaženy sekvence příkazů, které lze případně editovat dle potřeby. Tato metoda je velmi jednoduchá na implementaci. A výhodou je i to, že zálohu lze provádět přímo na serveru, na kterém databáze běží. 

Nicméně podstatnou nevýhodou dumpu je rychlost obnovy databáze z takovéto zálohy. A to se týká zejména velkých databází. Každý příkaz se totiž z uloženého souboru musí znovu samostatně nahrát do databáze a celý proces tak může trvat několik hodin. Zároveň můžete obnovit jenom data, která byla obsažena v posledním dumpu –⁠ o ty nejnovější zápisy do databáze, které ještě nebyly zálohovány, přijdete. Výsledkem je nepříjemný scénář popsaný v úvodu –⁠ spousta manuální práce i ušlých tržeb.

Prémiové zálohování s Point-in-time recovery

Aby se naši klienti mohli podobným potížím vyhnout, nabízíme jim prémiové zálohování databází. Umožňuje velmi rychlou obnovu databází, a to do stavu těsně před momentem, kdy došlo k selhání. Toho jsme docílili zkombinováním zálohování snapshoty s replikací binárních logů.

Jak to přesně funguje?

Z primární databáze provádíme asynchronní repliku na zálohovací server. Na zálohovacím serveru děláme backup pomocí snapshotu. Paralelně s tím na zálohovací server průběžně kopírujeme binární logy, které evidují veškeré změny v primární databázi. Logy nám v případě havárie pomohou přesně určit, kdy k problému došlo. Zároveň máme díky nim evidenci o operacích, které havárii těsně předcházely a nejsou tak zálohovány snapshotem.

Kombinací těchto dvou metod dokážeme –⁠ v případě selhání –⁠ databázi rychle obnovit do původního stavu (tzv. Point-in-time recovery, obnova k časovému okamžiku).

Nejdříve obnovíme nejnovější snapshot zálohy a překopírujeme na primární server ze serveru záložního. Následně u binárních logů identifikujeme místo, kdy došlo k destruktivní operaci a použijeme je k obnově nejčerstvějších dat. 

Rychlost celého procesu je oproti obnově z dumpu i 10x vyšší. Limituje ji pouze rychlost zápisu na disk a síťové připojení. U databáze okolo 100 GB se délka celého procesu bude pohybovat v řádu desítek minut.

Co je pro prémiové zálohování potřeba?

Oproti klasickému zálohování metodou dumpu, které můžete provádět přímo na primárním serveru, pro to prémiové potřebujete server záložní. Tento server by měl mít podobný výkon, jako databázový server produkční. Důležitá je i velikost úložiště: doporučujeme zhruba dvojnásobný objem oproti disku s primární databází. Tato kapacita by měla umožnit zálohování snapshoty alespoň za posledních 48 hodin (při zálohách jednou za hodinu).

Přesný objem vám rádi doporučíme během nezávazné konzultace na konzultace@vshosting.cz –⁠ záleží na frekvenci záloh, počtu změn ve vaší databázi a dalších faktorech.

Prémiové zálohování závisí i na volbě databázových technologií. Vzhledem k využití binárních logů ho lze implementovat pouze u relačních databází jako je MariaDB nebo PostgreSQL. NoSQL databáze nemají transakční log a nejsou proto s touto metodou kompatibilní.

Další podmínkou je konzervativnější nastavení databáze na záložním serveru. Úložiště musí být vždy konzistentní, aby bylo možné dělat snapshoty pomocí ZFS. Na záložním serveru nelze využívat upgrady, které upřednostňují výkon databáze na úkor její konzistence. Proto je třeba zvolit rychlejší úložiště než na serveru primárním, ve kterém je realizovatelné nastavení vyššího výkonu snižující konzistenci.

Pro koho je a není prémiové zálohování vhodné?

Pokud si ve vašem byznysu nemůžete dovolit přijít o žádná data, natož fungovat několik hodin bez databáze, naše zálohování s Point-in-time recovery je pro vás vhodné. Příkladem projektu, který z této služby nejvíce vytěží, je e-shop s velkými databázemi, který by mnohahodinový výpadek stál statisíce. Investice do záložního serveru, který je pro prémiové zálohování potřeba, se v takovém případě velmi rychle vrátí.

A naopak, když nemáte příliš velkou databázi, ve které navíc neprobíhá velké množství změn, pravděpodobně si plně vystačíte s klasickým zálohováním metodou dumpu.

Pokud máte nějaké dotazy, rádi vám poradíme během nezávazné konzultace: konzultace@vshosting.cz.

Pravděpodobně ale váš náklad ztroskotá, a vy se budete snažit zachránit co se dá. Aby k tomu nedošlo, doporučujeme se dopředu připravit na očekávané výkyvy v zatížení infrastruktury. Takovými e-commerce špičkami jsou typicky Vánoce a Black Friday.

E-shopaři se na Vánoce již tradičně připravují v létě. Právě tehdy je čas přemýšlet nejen o marketingových akcích, které přilákají co nejvíce zákazníků, ale i o technickém zázemí, které zvládne ustát jejich příliv na web. Základem je vědět, jaká je průměrná návštěvnost vašeho webu. A jaká byla minulou sezónu. Jakmile máte toto srovnání, můžete jednoduchou trojčlenkou zhruba vypočítat, jak velký nárůst můžete očekávat letos. 

Co když se vám ale bude dařit ještě lépe jak loni? To by bylo skvělé, ale buďte i na tuto velmi žádoucí variantu připraveni. Doporučujeme počítat s cca 20% rezervou výkonu. Vždy je ale nejlepší poradit se o rezervě kapacity na míru přímo s vaším poskytovatelem hostingových služeb. 

Jak spočítat potřebnou kapacitu

Pro jednoduchý výpočet kapacity infrastruktury stačí očekávaná čísla porovnat s aktuálními daty. Vyjde se z předpokladu, že aplikace bude škálovat lineárně. A trojčlenkou dojdete k tomu, jaké systémové zdroje potřebujete. 

Výhodou této metody je její rychlost a minimální náklady. Je však hodně orientační. Přesnější alternativou je tzv. performance test. V jeho průběhu se snažíme umělou zátěží dosáhnout na potřebná čísla, přičemž sledujeme, jaké komponenty se stávají bottleneckem. Touto metodou se odhalí i konfigurační nebo technologické limitace. Nicméně, fér je zmínit, že performance testy jsou časově náročné. A i specifické dle použitých technologií. Pro menší a střední e-shopy jsou z tohoto důvodu zbytečně nákladné.

Pro zajímavost: například populární databáze Redis je single threadová, takže když saturuje výkon jednoho jádra, v tu chvíli dosáhla svého maxima a je jedno, že server má desítky volných jader k dispozici. Prostě proto, že tato aplikace je využít neumí.

Technické okénko: 4 věci, kterým věnovat pozornost

CPU – dejte si pozor na zavádějící grafy vytížení procesoru, pokud má zapnutý hyperthreading. Graf agregující výkon přes všechna procesorová jádra pak velmi zkresluje dostupný výkon. Hyperthread sice teoreticky zdvojnásobuje počet jader, ale prakticky nepřidá dvojnásobek výkonu. Pokud na takovém grafu vidíte hodnoty nad 50 %, jste velmi blízko maxima… To se typicky nachází někde mezi 60 a 70 %, dle typu zátěže.

RAM – operační paměť obvykle neroste lineárně. Například u databází jsou některé paměťové alokace globální a jiné jsou pro každé spojení. Často se zapomíná na to, že operační paměť nemůže být zcela zaplněna. Stačí pak potřeba malé alokace a jádro systému zabije proces, který si paměť vyžádala. 

Operační systém rezervu v paměti typicky využívá jako diskovou cache, což má pozitivní vliv na výkon. Pokud není možné dostatečně cachovat, je potřeba diskových operací vyšší.

Disky – nízká rychlost disků je častým důvodem toho, že jsou některé operace pomalé, nebo při vysoké zátěži zcela nefunkční. Zda je řešení dostatečné se ukáže až při vysoké zátěži, nebo u performance testu. Snížit tuto zátěž je možné intenzivnějším cachováním, což vyžaduje více operační paměti. Dále je možné řešit situaci například upgradem ze SATA/SAS SSD na NVMe. 

Nutné je vnímat i kapacitu, protože i ta může mít na výkon vliv. Všechny filesystémy využívající COW (copy-on-write) – tedy například námi používané ZFS, nebo filesystémy jako btrfs, případně WAFL – potřebují pro svůj běh volnou kapacitu. Všechny tyto filesystémy spojuje nepříjemná vlastnost, kdy přibližně od 90 % zabrané kapacity začne rychle degradovat výkon. Je důležité toto nepodceňovat – v době velké zátěže se často vytváří i více dat a kapacita se rychleji spotřebovává.

Síťová vrstva – obzvlášť důležité pro clusterová řešení, kde servery hodně komunikují mezi sebou a snadno se stane, že rychlost pro interní komunikaci není dostatečná. Zde je vhodné vnímat i redundanci – standardem u vshostingu je zdvojení síťové vrsty pomoci technologie LACP. Tedy např. z 2x 1GE uděláme jedno 2GE rozhraní. Vzniká nám tím sice kapacita 2GE, ale prakticky není vhodné zaplnit více jak 1GE, protože v tu chvíli přicházíme na serveru o redundanci. 

Ani to, že řešení využívá 10GE rozhraní neznamená, že takové řešení bude dostačovat vždy a za každých okolností. Stačí drobná chyba vývojáře, kdy jednoduchá query do databáze přenese velké množství nepotřebných dat (typicky select * from… a pak si v aplikaci vezme prvních X řádek) a je snadné i takto velkou šířku pásma vyčerpat.

Můžeme vám poradit s kapacitou infrastruktury? Obraťte se na nás na e-mailu konzultace@vshosting.cz.