Jakékoliv datové centrum potřebuje ke svému fungování nepřetržitou zásobu elektrické energie. Z tohoto důvodu ve vshostingu nespoléháme jen na zásoby elektřiny ze sítě, ale v případě potřeby si ji dokážeme vyrobit sami prostřednictvím dieselových agregátů. Mechanismus přepnutí provozu na diesel v případě výpadku elektřiny je velmi pečlivě nastaven a má i řadu pojistných mechanismů, ale pro jistotu jeho funkčnost minimálně 4x do roka testujeme.

Test výpadku elektrické energie má za cíl potvrdit funkčnost všech prvků zapojených do procesu náhradního napájení. Nejde jen o samotné dieselové agregáty, nezastupitelnou roli hrají také rozvodny, které automaticky poznají, že došlo k výpadku a spustí procesy nutné k okamžitému nahrazení napájení z našich zdrojů. Dále testujeme i funkčnost UPS a baterií, které při výpadku slouží jako překlenovací a vyrovnávací zdroj napájení do doby, než se plně nastartují dieselové agregáty. 

Průběh testu

Simulace výpadku elektřiny začíná „shozením“ jistícího prvku na hladině nízkého napětí na trafostanici. Tím z pohledu datacentra dojde k výpadku elektrické energie. V návaznosti na to dá systém automatického řízení pokyn ke startu dieselového generátoru. 

Pokud by přiřazený agregát z jakéhokoliv důvodu nenastartoval, automaticky startuje záložní dieselový generátor. Po spuštění dieselového generátoru dojde k přepnutí napájení na jím vyrobenou elektřinu. V době mezi výpadkem napájení a plným přepnutím na elektřinu z dieselu je naše datacentrum zásobeno ze zdroje nepřerušovaného napájení (UPS). 

Jakmile se dodávka standardní elektřiny obnoví, systém to detekuje, ale z bezpečnostních důvodů ještě čeká s přepnutím z dieselu na standardní dodávku elektrické energie pro případ, že by došlo k dalšímu výpadku. Po uplynutí této bezpečnostní pauzy dojde k přepnutí zpět na elektřinu ze sítě a následně k odstavení dieselového generátoru.

Celý proces je nepřetržitě sledován naším vlastním systémem vzdáleného monitoringu i přímo na místě přítomnými technickými pracovníky. Na závěr testu technici zkontrolují stav dieselového generátoru a dle potřeby doplní palivo.

Pár zajímavostí na konec

V zimě termín testu blackoutu záměrně přizpůsobujeme počasí, protože chceme mít jistotu, že generátory nastartují i v mrazech. Každý dieselový generátor má zabudován předehřev, který udržuje teplotu chladící kapaliny kolem 50°C, proto je možný rychlý start velkého motoru generátoru i při teplotách pod nulou.

Žádná ze součástí datacentra nevydrží věčně, a proto mimo tyto kvartální testy výpadku elektrické energie také pravidelně kontrolujeme funkčnost UPS a baterií, klimatizačních jednotek (chlazení serverů je klíčové) a dalších instalovaných zařízení.

Naše datacentrum je rozděleno do tří částí, tzv. etap. Každá etapa má vlastní trafostanici a vlastní dieselový generátor. Dále v datacentru disponujeme záložní trafostanicí a záložním generátorem záložních generátorů. Záložní zdroje lze použít pro kteroukoliv část datacentra.

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

Mnozí se po požáru datacentra OVH ptali: „Jak je možné, že cloud hoří?“

Tento francouzský poskytovatel hostingu patří mezi největší low-cost světové hráče v oblasti dedikovaných serverů. Následkem, de facto úplné destrukce jednoho z jejich datacenter, se začaly množit dotazy ze strany klientů a médií, jaká jsou rizika  provozu datacentra v případě nenadálých okolností, a co vše hrozí jeho klientům. 

Pojďme si to vysvětlit na příběhu budování vlastního datacentra vshostingu, u jehož zrodu a celého procesu jsem stál. Právě na tom si přesně vysvětlíme, jak se liší low-cost datacentra od těch pořádně, solidně vystavených…

Tohle je náš příběh. Když jsem si vysnil vlastní datacentrum, bylo mi skoro 24 let. Neměl jsem zkušenosti s žádnou stavbou, natož stavbou datacentra. Můj prvotní nápad bylo postavit datacentrum v dlouhodobě pronajaté hale, kam bychom „jen“ vestavěli infrastrukturu jako je elektroinstalace, chlazení, zabezpečení, racky a podobně. Tomu jsme našli jeden odpovídající průmyslový areál na Praze 10. Hala byla prostorná, čistá, majitel vypadal ochotně provést drobné stavební úpravy. Poté, co jsme však viděli jakési prodavače vozit haldy oblečení do vedlejší haly, se kterou byla ta „naše“ budoucí oddělená jen úzkou příčkou, rozhodli jsme se od tohoto plánu ustoupit. Co je v té hale za firmu, nám totiž nechtěli říct.

A my jsme se oprávněně báli možného požáru. Navíc jsme zjistili, že upadnul by-li pronajímatel do úpadku, byly by i nájemní smlouvy na dobu určitou vypověditelné. To by bylo pro náš byznys nepředstavitelné. Tento koncept pouhého pronájmu haly jsme tedy po několika prohlídkách zavrhli. Spousta datacenter v České republice však tento koncept využívá. Tím se dosáhne úspory investice do nemovitosti, ale za jakou cenu rizika? Opravdu se vyplatí šetřit na zabezpečení datacentra a bezpečnosti dat, a vůbec celých i stamilionových firem klientů? Ne. Nám ne. Tohle dělat nechceme a nebudeme. Bez debat.

Konektivita: 100% oddělené optické kabely 

Začali jsme hledat vlastní pozemek, který by vyhovoval všem parametrům. Jak už územním regulativům (využití pozemku, zastavitelnost, hluk), tak dostatku dostupné elektrické energie (řádově megawatty na vysokém napětí). A zároveň by bylo možné k pozemku dostat optická vlákna z několika směrů. Zejména poslední parametr se ukázal při hledání vhodného vlastního pozemku skutečně problémem. Ke spoustě pozemkům bylo možné optická vlákna po minimálně ročním martyriu úředního vyřizování týkajícího se územního rozhodnutí dokopat. Ale vždy s problémem souběhu optických kabelů, byť jen u kratších úseků. Cílem bylo, abychom přivedli do datacentra přípojky z opravdu několika směrů a to bez jakéhokoliv souběhu (ani v rámci budovy). Proto jsme se rozhodli zainvestovat a vykopat k těmto optickým kabelům další velmi dlouhý úsek. 

Praha je protkaná obrovským množstvím inženýrských sítí a bez pořádné evidence, co kde je. Standardním postupem je koordinace v rámci územního řízení, ve kterém jsou osloveni všichni provozovatelé inženýrských sítí s tím, aby se vyjádřili, co kde v dané lokalitě mají. Realita je ovšem taková, že pokud řidič bagru prostě blbě hrábne, překopne kabel, a problém je na světě. V optickém kabelu můžou být desítky či stovky optických vláken, a navařit je potom zpět je operace pro havarijní výjezdový tým na mnoho hodin. A offline datacentrum nikdo nechce. Investice do konektivity se tedy ukazuje jako opodstatněná.

Chlazení: N+2 redundance není zbytečný luxus

Pamatuji si na jeden poněkud iritující rozhovor s provozovatelem jiného datacentra, který se mi doslova vysmál, že u chlazení je N+2 redundance zbytečný luxus a riziko malé. O dva roky později jsem byl v zahraničí a dispečink mi volal, že v jedné klimatizační jednotce odešly kompresory, a pár hodin na to se rozbila i druhá jednotka. Oprava klimatizační jednotky je proces na několik dní a výměna kompresoru znamená demontáž, navaření nového kompresoru, vakuování, tlakovou zkoušku, plnění chladivem atd.

Náhradními díly ke klimatizačním jednotkám jsme se zásobili přímo v datacentru. A priori nevěřím dodavatelům na 100 %, a zkrátka čekat až několik týdnů na kompresory do 100kW jednotky, se mi nechtělo.

Všechno to jsou pořád stroje, a žádný stroj nevydrží věčně. Je hloupé si myslet, že se nic nerozbije, neřku-li nemůže rozbít, jen proto, že to někdo řekne. Radši udělám x záloh našich strojů, než abych ohrozil fungování něčí firmy. Firmy našeho klienta. 

Protipožární systém: FM-200

Zkrat v UPS, který zapříčinil požár v datacentru OVH, není nijak neobvyklý. Je to porucha, která se ve světě stala již mnohokrát. I proto jsme u nás vybavili automatickým hašením nejen datový sál se servery, ale také místnost na jednotky s UPS. Při detekci kouře se místnost automaticky zaplní inertním plynem FM-200, který vzniku požáru zabrání. Tím pádem nedojde k výpadku služeb datacentra, ani k poškození serverů klientů.

Někomu by se až mohlo zdát, že jsem přehnaně opatrný, ale praxe s 5letým provozem datacentra ukazuje, že postavit pořádné a drahé datacentrum bylo správné rozhodnutí a je to v zájmu našich klientů.

Poznámka: Pokud by pro vás několikadenní výpadek znamenal milionové škody, a případná destrukce části vašich dat by byla nepřijatelná, dává smysl investice do kvalitního poskytovatele hostingu. Pakliže máte menší firmu a cena je pro vás hlavním kritériem, mohou být pro vás výše zmíněná rizika akceptovatelnou daní za momentální úsporu financí.

Skoro každý, kdo provozuje nějaký ten online projekt, už to asi zažil: dorazí SMS nebo automatický hovor z monitoringu, že něco nefunguje. Vašemu milovanému projektu je ouvej a žádá si vaši pozornost. 

Nemusí to být ani katastrofa typu požár datacentra, nebo zemětřesení – vyřadit systémy zvládne i prasklé potrubí v budově, administrátorská chyba na síti v Indii nebo neodborný zásah uživatele. Pamětníci si jistě vzpomenou na rok 2007 a kauzu s heslem NBUSR123. 

Ve vshosting~ děláme všechno pro to, abychom podobným situacím zabránili – víc se o tom dočtete v článku o našem nekompromisním zabezpečení. Přesto, ne všechny rizikové faktory a skutečnosti jsou v naší moci a vznik nenadálých situací tak nelze vyloučit. Scénář je pak vždy stejný. Najednou, bez jakéhokoliv varování, všechno zhasne a monitoring se rozsvítí rudě. Nic nefunguje. A co teď? 

Můžete si stěžovat, nadávat, panikař… nebo aktivovat svoje disaster recovery plány. Scénáře, které jste sepsali v době klidu pro případ, že se něco hodně, ale hodně pokazí. Dokumenty, o kterých jste doufali, že je nikdy nebudete muset číst.

Co jsou disaster recovery plány a jak mají vypadat

Disaster recovery plány jsou dokumenty, které jasně popisují, jak dostat váš projekt zpět do funkčního stavu. Mají mnoho podob a pokrývají spoustu možných scénářů. Mohou to být jednoduché seznamy krizových přístupů ale i komplexní postupy, které zahrnují úkony napříč několika odděleními ve firmě. 

Vždy by měly obsahovat: 
– co je potřeba udělat
– kdo to má udělat
– jak to má udělat
– kde jsou dostupné zálohy
– v jakém pořadí nahazovat služby
– kdy obnovovat která data

Vhodné je zahrnout i přihlašovací údaje na krizové účty, ať je máte po ruce. Cílem disaster recovery plánů je vždy minimalizovat obchodní dopad katastrofy a co nejrychleji postavit projekt zpátky na nohy. Musí být napsány jasně a stručně. Protože když už podle nich budete postupovat, určitě to nebude v klidu a v pohodě.

Je běžné, že disaster recovery plány nejsou čistě IT charakteru a mají přesah do dalších oddělení ve firmě. Kromě technického zvládnutí problému totiž potřebujete i udržovat kontakt se zákazníky, případně zajistit podklady pro právní oddělení. Proto je potřeba při sepisování disaster recovery plánů přibrat na pomoc zástupce jiných oddělení a konzultovat jednotlivé kroky s nimi. Musíte mít jistotu, že postupy dávají všem smysl a nezapomněli jste na nějaký netechnický dopad.

Při jejich tvorbě můžeme vycházet z principu letectví. Pokud dojde v letadle k problému, platí postup „Aviate, Navigate, Communicate“, tedy udržet letadlo ve vzduchu, zjistit, kde jste a kam se můžete vydat a až pak se zabývat komunikací. 

V IT toto lze využít obdobně. Nejprve se snažte zachránit, co jde (tj. minimalizovat přímé dopady, klidně odstavením systémů). Dostaňte systém do dostatečně stabilní podoby, a až pak zajistěte komunikaci ven. Pokud máte k dispozici více administrátorů, lze proces paralelizovat, a je to i vhodné. Umíte si představit horší situaci, než když admina otravují s dotazy jeho kolegové z obchodu a customer supportu a ptají se, co mají říci klientům?

Krok 1: Udržte projekt „nad vodou“

Když letadlo spadne na zem, je konec. Přišli jste o letadlo, posádku, náklad i pasažéry. Proto je potřeba ho za každou cenu udržet ve vzduchu. 

V IT to funguje podobně. Pokud přijdete o jednu službu, je potřeba minimalizovat dopady na ty další. Zabránit kaskádovému efektu. Nemůžete si dovolit přijít o všechno. A to i za cenu odstávky. Když přijdete o všechna data i systémy, je to pro firmu naprosté existenční riziko. Krátkodobá odstávka projektu je výrazně menší zlo než dlouhodobá obnova dat. 

Typickým příkladem toho je chyba v aplikaci, která při updatu ukládá poškozená data. V tomto případě je mnohem lepší aplikaci odstavit a zabránit zničení většího množství dat, než ji nechat běžet a pracovat na vydání opravy.

Krok 2: Zorientujte se

Výborně, v prvním kroku jste úspěšně zabránili zničení všech dat. Nicméně stále vzniká škoda, aplikace je nedostupná, klienti začínají být naštvaní. To je správná chvíle začít zjišťovat, co se stalo, jaké jsou celkové dopady a připravit plán na obnovu. 

Lze opravit aplikaci jednoduchým fixem? Je potřeba obnovit nějaká data ze zálohy? Jak dlouho bude trvat návrat do minimálního funkčního stavu? A jak dlouho bude trvat kompletní oprava? O kolik dat jste nenávratně přišli? To jsou všechno otázky, které jsou teď na stole, a na které potřebujete rychle znát odpověď.

Krok 3: Komunikujte se zákazníky

V této fázi už víte co se stalo, co musíte udělat i jaké jsou dopady na vaši společnost. Dokonce i jak dlouho bude trvat oprava. V tuto chvíli můžete komunikovat zákazníkům odhad časové náročnosti.

Doporučujeme vyčlenit jednoho pracovníka jako styčný bod pro komunikaci. Někoho, kdo bude od začátku mluvit s obchodem, podporou a se zákazníky. Zároveň bude sloužit jako štít stojící před adminy, kteří zachraňují situaci. Tuto roli se hodí přidělit někomu z řízení projektu, v agile světě by to byl project owner. A důležité je také zajistit, aby všichni ve firmě věděli, na koho se mají obracet s dotazy.

Komunikace ven je bezesporu důležitá, a v krizi o to víc. Avšak, neměla by být na úkor obnovy provozu. Hlavně pro obchod a podporu vždy platí, že informace, které jim předáváme, musí být aktuální a platné v daném časovém bodě. Nemusí být ale 100% přesné a neměnné. Vždy stavíme na tom, co v daném bodě víme. 

Na začátku se situace může zdát snadno opravitelná, ale další průzkum může odhalit mnohem dramatičtější dopady. Anebo naopak. Proto doporučujeme nikdy nekomunikovat termíny a odhady jako definitivní. Pokaždé je potřeba říct „ale situace se může změnit“, vždy je potřeba pro jistotu počítat s výrazným prodloužením obnovy. S tím musí počítat všichni lidi ve firmě.

Pravomoce krizového řízení

V klidných dobách je pochopitelné, že velké investice nebo zásahy do infrastruktury je nutné konzultovat s vedením firmy a důkladně je naplánovat. Můžete déle vybírat nejvýhodnějšího dodavatele, dohodnout s ním dobré obchodní podmínky, zanalyzovat a otestovat dopady řešení. Jakmile ale udeří krize, rozvážnost jde z velké části stranou. 

Záchranný tým potřebuje mít pravomoce činit rozhodnutí rychle a neřešit zcela optimální efektivitu či úspornost. Pokud vám „umře“ nějaký klíčový hardware a nemáte skladem náhradní kus, není prostor na vyjednávání s dodavateli. Je potřeba vzít firemní kartu, sednout do auta a vyrazit do nejbližšího obchodu, který má nový kus skladem. A to i za cenu vyšších nákladů. Je snad dlouhá odstávka vašeho projektu levnější? 

Pokud fungujete v cloudu, záchranný tým musí mít pravomoc ihned spustit další instance – bez ohledu na rozpočet infrastruktury. Případně si dopředu stanovte hranice rozpočtu, přes které nelze jít, ale zvažte přitom náklady na každou minutu, kdy váš projekt nefunguje.

Zálohy, zálohy, zálohy

Zálohy a jejich obnova jsou nedílnou součástí každých disaster recovery plánů. A to nejen zálohy mít, ale jejich funkčnost pravidelně testovat a nastavit optimální zálohovací frekvenci. Bez ohledu na to, jestli máte infrastrukturu v cloud nebo ne.

I v cloudu je třeba zálohovat!

Často se setkáváme s názorem, že infrastrukturu a data v cloudu není třeba zálohovat. Slýcháváme, že: „proto si přece platíme cloud, abychom nemuseli utrácet za zálohy“. Tento přístup je chybný a u jeho zastánců může vést až ke krachu firmy.

V cloudu si pořizujete výpočetní kapacitu, prostor na storage a služby s ním spojené, ale nekupujete si bezpečnost vašich dat. Kupujete si pouze jistotu, že v případě problémů můžete data do cloudu obnovit a spustit novou sadu serverů. Je ale vaše zodpovědnost mít kopii dat k obnově, mít informace o konfiguraci serverů a mít popsaný postup nasazení aplikace. 

Cloud vám poskytuje platformu, ale obchodní hodnotu jí dáváte vy. Cloud je vám v tom schopen pomoci georeplikací, nebo službou na zálohování. Zájem o její využití musíte mít vy, včetně toho dát jí smysl a mít připravený proces obnovy dat.

Testování kvality záloh a optimální backup frekvence

Potřebujete mít také jistotu, že zálohy jste schopni obnovit. Až příliš často se stává, že firma sice krásně zálohovala, ale když došlo na potřebu obnovy, zálohy byly nepoužitelné. A nemusí to být jenom chyba v záloze jako takové. Zálohy mohou být z důvodu problému nedostupné nebo nekompletní. A proto je třeba je pravidelně testovat. Vyzkoušet si, že jste schopni si data ze záloh obnovit, stejně tak, že zálohujete vše, co potřebujete – a v dostatečném množství. 

Nikdy nebudete mít v záloze 100 % dat, vždy o něco přijdete. Zůstává otázkou, jestli můžete ztratit data za týden, za den nebo za hodinu. O kolik dat jste ochotni přijít? Respektive, kolik peněz je vaše firma ochotná do zálohování a obnovy dat investovat? Zde platí nelineární vztah – pokud zálohování 1x denně stojí XY kč, zálohování 2x denně nestojí 2 XY kč, ale klidně 5 XY, nebo 10 XY. Je třeba si říct, jestli mají data mimo zálohu takovou hodnotu, nebo jestli je výhodnější tato data již obětovat.

Co si z toho odnést

Nic není 100% a chyby se stávají. Každý admin už podobnou situaci zažil a nikdy to není příjemné. Přesto se vždy dá na situaci připravit předem a minimalizovat její dopady na chod firmy. 

Není to zadarmo a není to snadné. A v klidných časech to může vypadat, že vám to nic nepřináší, ale zabrání to velkým problémům v budoucnu. A vždy se to vyplatí. Myslete na to.

Chcete se poradit o optimálním režimu zálohování pro váš projekt? Obraťte se na naše experty: konzultace@vshosting.cz. Zdarma vám připraví řešení na míru.

Asi nikoho nepřekvapí, že ve vshosting~ bereme bezpečnost smrtelně vážně. Občas si děláme legraci, že naše opatření hraničí s paranoiou. Ale to je naše práce. Jen díky extrémně přísným opatřením a do detailu vypracovaných krizových scénářů dokážeme provozovat datacentrum bez výpadků od jeho otevření v roce 2015 a zajistit našim klientům maximální spolehlivost.

Pro zajímavost poodhalujeme, jak chráníme servery a data našich klientů před třemi typickými hrozbami: sabotáží nebo krádeží serverů, dlouhým blackoutem a poruchou chlazení.

Apokalyptický scénář 1: Sabotáž či krádež serverů

Kdyby se náhodným vandalům nebo dokonce vaší konkurenci podařilo zmocnit se vašich serverů, byl by to pořádný průšvih. Nejen že by vaše aplikace (např. váš e-shop) přestaly fungovat, ale dotyční by mohli získat i vaše data. Naštěstí pokud jste svou infrastrukturu svěřili nám ve vshosting~, nic takového nehrozí.

Naše datacentrum ServerPark je v podstatě neproniknutelná železobetonová kostka s pancéřovými dveřmi, která je ještě navíc obehnaná vysokým plotem s ostnatým drátem.

Datacentrum ServerPark

Ani to nám ovšem nepřišlo dostatečně bezpečné, a proto jsme přidali sofistikovaný bezpečnostní systém včetně kamer, který se aktivuje jakmile by někdo například přelezl plot nebo se vlamoval do dveří. Do serverovny se dostanete jedině pomocí kombinace několika klíčů, čipů a přístupového kódu. Aby toho nebylo málo, všechny serverové racky jsou samostatně uzamykatelné, takže k jednotlivým serverům se skutečně jen tak někdo neprobojuje.

Za zmínku stojí i naše ochrana před sabotáží kybernetickou: DDoS útoky. Ty se dají poměrně snadno a levně objednat online a útočníci pak mohou přetížit vaši aplikaci a v podstatě ji vyřadit z provozu. Proto jsme vyvinuli vlastní anti-DDoS ochranu, která těmto útokům účinně brání. Sabotéři tedy budou mít smůlu i pokud zvolí softwarovou cestu.

Apokalyptický scénář 2: Několikadenní výpadek elektřiny

Zloději, sabotéři i jiní záškodníci jsou tedy eliminováni, ale co kdyby, řekněme, vypadl proud? Datové centrum spotřebovává obrovské množství elektrické energie – jak bychom tedy zvládli blackout? A co teprve, kdyby výpadek elektrické sítě trval třeba týden? Přesně pro tento případ jsme v ServerParku nainstalovali komplexní systém sestávající z UPS, tj. bateriový záložní zdroj, dieselových generátorů a nádrže na diesel.

2 ze 3 dieselových generátorů v datacentru ServerPark

Všechny tyto prvky u nás navíc provozujeme v takzvaném režimu nx2 a n+1. To v praxi znamená, že v ServerParku máme zapojené dvě naprosto nezávislé napájecí větve (režim nx2). Ka každé větvi je přiřazeno jedno dedikované a jedno „rezervní“ UPS (režim n+1) a každá větev disponuje vlastním diesel generátorem i rozvaděčem. Současně je zapojen i další diesel generátor, který se automaticky zapne, kdyby došlo k poruše některého z dedikovaných generátorů.

Každá napájecí větev také disponuje vlastní sadou baterií a každá sada baterií je složena ze 3 stringů. Je to z toho důvodu, že baterie jsou ve z technických důvodů stringu zapojeny v sérii, takže kdyby by došlo například ke špatnému kontaktu mezi dvěma bateriemi, může dojít k selhání celého stringu. Servery u nás také mají mít instalované 2 zdroje a jsou současně zapojeny do obou nezávislých větví: na nezávislé UPS, nezávislé rozvaděče a nezávislé generátory.

Co by se tedy dělo v případě výpadku? Datacentrum by se automaticky začalo napájet z bateriového systému, zatímco by startovaly dieselové generátory. Naše baterie datacentrum „utáhnou“ déle než 20 minut, což poskytuje velkou rezervu k plnému rozběhnutí generátorů. Poté už by vše běželo na elektřinu vyrobenou z dieselu. Na tu vydržíme jet z vlastních zdrojů více než dva týdny. Pro představu, to je násobně větší rezerva, než má většina nemocnic.

Apokalyptický scénář 3: Porucha chlazení serverového sálu

Blackout jsme tedy zvládli, jsou tu ale i další potenciální zdroje problémů. Takové datacentrum je koneckonců plné elektroniky – co když se nějaká porouchá? A co když to bude zrovna zásadní prvek datacentra, jako třeba chladicí systém?

Servery vyrábějí spoustu tepla, je tedy potřeba je intenzivně chladit, aby se nepřehřívaly. Když dosáhnou moc vysoké teploty, může dojít k jejich poškození, zničení nebo dokonce začít hořet. Proto máme v ServerParku nainstalovaný naddimenzovaný systém chlazení i profesionální hasicí systém na bázi plynu FM200. Na hašení by ale dojít nemělo – servery mají zároveň pojistky, které je při přehřátí vypnou. 

Hasicí systém FM200 v serverovém sálu ServerParku

Náš systém chlazení je podobně naddimenzovaný jako napájení: klimatizačních jednotek i všech dalších prvků máme 2x více, než je potřeba, plus ještě jednu záložní. Mnoho datacenter má pouze tu jednu zálohu, my jsme se s ní však nespokojili. Selhání chlazení je u nás tedy asi tak pravděpodobné, jako že do vás uhodí blesk, zatímco na obloze nebude jediný mrak.

Jak vidíte, naše datacentrum ServerPark je připraveno na nejhorší: ať už jde o pokus o sabotáž, výpadek proudu nebo možnost poruchy, kvalitu našich služeb to neovlivní. Díky našemu nekompromisnímu zabezpečení (i mnoha dalším výhodám) nám svoje projekty svěřili i ty největší české a slovenské internetové firmy. Pokud se chcete dozvědět, jak navzdory pandemii koronaviru zachováváme 100% provoz, přečtěte si náš předchozí článek.

Za posledních 14 let jsme zažili spoustu těžkých období, technické problémy i jiné komplikace. Současná pandemie je v mnoha ohledech odlišná. Na tuto situaci nebylo možné se předem připravit a vytvořit pro ni detailní krizový postup. Samozřejmě to není nic proti firmám, které musely úplně „zavřít krám“.

V prvních dnech jsme udělali některé základní změny, o kterých jsme posléze informovali na sociálních sítích. K situaci jsme přistoupili možná až příliš paranoidně, ale naše intenzivní opatření mají dva cíle: oddálit (nebo ideálně úplně eliminovat) přítomnost nákazy ve firmě a zajistit provoz za všech okolností.

Bráníme nákaze

V první řadě jsme prakticky od počátku zavedli povinné nošení roušek všemi osobami v budově, a to ještě předtím, než to nařídil stát.

Dále jsme přistoupili k zákazu používání MHD a zavedli firemní spolujízdy s využitím kapacit firemních aut. Současně s tím jsme umožnili maximálnímu počtu lidí pracovat z domova, byť v našem případě to jde poměrně složitě a značně se nám tím snížily personální kapacity.

Ve snaze zabránit nákaze jsme také omezili všem cizím osobám vstup do budovy a klienty jsme požádali o to, aby do budovy vstupovali pouze v nejnutnějších případech. Toto opatření jsme posléze zpřísnili a zavedli úplný zákaz vstupu cizích osob i klientů a dodavatelů do budovy vyjma havarijních situací. Naše týmy adminů a techniků všechny ostatní případy řeší za klienty, aby návštěvy nebyly nutné, ale přitom vše fungovalo na 100 %.

Zároveň všem osobám, které do budovy vstupují, měříme teploty, denně dezinfikujeme pracovní místa, kliky, apod. 

Připravujeme se na vše

Hned v první vlně opatření jsme zajistili dodávku paliva do nádrží pro generátory „až po špunty“ (nakoupeny desítky tisíc litrů). Sice neočekáváme, že stát vypne firmám energii, ale chceme být připraveni na vše. Takto bez problému zvládneme i několikatýdenní blackout.

Mimo to jsme rozdělili management tak, abychom zabránili případnému nakažení všech jeho členů. Cílem je zachovat plnou provozuschopnost z pohledu řízení i v případě, že by navzdory našim přísným opatřením někdo z vedení onemocněl.

Paradoxem je, že během této krize objem naší práce zůstal stejný nebo vzrostl. Důvodem je, že většinu našich klientů tvoří e-shopy, které nyní zažívají období podobné tomu předvánočnímu. Nejde jen o potraviny, ale i elektroniku či třeba sportovní náčiní. Díky obětavým kolegům ale vše bez problému zvládáme.

Zvládneme i zákaz vycházení

Nyní jsme připraveni i na nouzový „ostrovní“ chod firmy pro případ, že stát přeci jen zavede zákaz vycházení a datová centra jakožto telekomunikační služba nebudou ve výčtu výjimek. Budova je tedy zásobena potravinami a dalšími nezbytnostmi, aby byl provoz firmy a datového centra zachován.

Velké díky všem kolegům, že všichni k situaci přistoupili odpovědně a obětavě. V těchto vypjatých situacích se vždy ukáže zdraví a síla týmu každé firmy. Zároveň bych naše klienty rád ujistil, že vshosting~ stále běží na 100 % a je připraven na všechny krizové varianty.

Damir Špoljarič
CEO

Procesory obsahují dvě bezpečnostní chyby s názvy Meltdown a Spectre. Ty potenciálně umožňují útočným programům dostat se k datům, která jsou v počítači aktuálně zpracovávána. Meltdown je schopen přerušit bariéru, která je mezi uživatelskými aplikacemi a operačním systémem, a získat tak přístup do paměti v rámci stejného cloudu. Spectre umožňuje aplikacím dostat se do různých míst paměti. Chyba se týká x86-64 procesorů, tedy procesorů používaných ve všech cloudech po celém světě.

Náš bezpečnostní tým a tým infrastruktury na nápravách usilovně pracují. Po vydání updatů pro operační systémy, budeme úpravy nasazovat na všechny managed a interní servery. V médiích se objevují tvrzení o snižování výkonu až o desítky procent, což není aktuáně potvrzeno a bude to záležet na konkrétních případech. U serverů, kde by mohly nastat provozní komplikace v důsledku nedostatku výkonu, budeme klientům doporučovat preventivní navýšení výkonu.

V případě dotazů nás kontaktujte emailem na podpora@vshosting.cz

Doporučení:

Webové aplikace udržujte vždy kompatibilní s aktuálními verzemi PHP a dalších komponent, aby bylo možné udržovat aktuální verzi operačního systému, která je podporovaná komunitou či výrobcem včetně bezpečnostních aktualizací.

Dlouhodobě upozorňujeme uživatele na zastaralost PHP verzí až do verze 5.3 včetně (od jara 2018 od verze 5.4 dále). Zastaralost přináší komplikace z pohledu nutnosti provozování zastaralých verzí souvisejících knihoven a operačních systémů z důvodu kompatibility. Nové verze PHP (7+) navíc disponují výrazně větším výkonem. Nejde samozřejmě jen o verzi PHP, nicméně staré verze PHP nejčastěji tvoří blocker, a vytváří tak zbytečné bezpečnostní riziko.