CANON CZ
facebook
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 

Pokročilá analýza provozu datových sítí

V tomto čtyřdílném seriálu vás seznámíme s různými metodami a přístupy...

1. až 4. díl >>

 

Cesta k efektivnímu identity managementu

Správa identit a přístupů (IAM) je klíčová oblast pro zaručení bezpečnosti...

1. až 9. díl >>

Partneři webu
CVIS Consulting
Správa IT Virtualizace a cloud computing

„Oblíbené“ chyby při výstavbě a provozu datových center



ServerParkPřestože technologie pro návrh a řízení provozu datového centra jsou stále vyspělejší, setkáváme se každoročně s výpadky, které jsou důsledkem chyb a opomíjených hrozeb. Některé z nich se opakují častěji, a proto je můžeme s trochu ironie označit za oblíbené chyby provozovatelů datových center. Jde především o výběr nevhodné lokality a podceňování redundance a výkonu záložních zdrojů, chlazení, ale také o absenci systematického plánu rozvoje datového centra.


Nevhodná lokalita – vodě neporučíte

Bohužel špatně zvolená lokalita je stále často ignorovanou hrozbou, která se následně v reálném provozu už těžko řeší. Pomineme přitom nepochopitelnou situaci, že někdo staví datové centrum v záplavové oblasti, kde samozřejmě nemá datové centrum co dělat. Podobnou chybou ovšem může být i situování datacentra do starší budovy, kde hrozí například riziko v podobě zaplavení při havárii inženýrských sítí (zcela ho neeliminují ani „stříšky“ v datovém sále). Proto je třeba volit lokalitu mimo potenciální riziko zaplavení. Samozřejmě ideální je pro datové centrum vlastní objekt, nejlépe oddělený od ostatních budov, co největší možnou vzdáleností.

Záložními zdroje (UPS) – pozor na vytíženost a redundanci

Značné množství výpadků datacenter je způsobeno výpadkem napájení, zejména poruchou na systému UPS (záložní zdroj napájení) nebo překročením jejich kapacity. Některá z datacenter tak nesplňují ani požadavky TIER III, který vyžaduje mít 2 nezávislé napájecí větve. Mnoho provozovatelů si bohužel neuvědomuje, že na spolehlivosti UPS stojí spolehlivost celého datacentra. Když už disponují 2 nezávislými UPS, často jsou vytíženy na více než 50 %, z čehož vyplývá, že při poruše jedné UPS dojde u druhé z nich k přetížení. Častým prohřeškem bývá jednobateriový string na UPS. Baterie jsou ve stringu zapojeny v sérii a v případě, že některá z nich bude mít poruchu (například vysoký vnitřní odpor), funkce UPS, coby hlavního záložního prvku datacentra, se naruší. A vše se často přijde až při skutečném výpadku napájení z veřejné sítě, kdy už však není pro chyby prostor. Baterie čas od času odchází, na což se většinou přijde při pravidelné revizi UPS, která by se měla provádět minimálně 1x ročně. Jako spolehlivé uspořádání UPS lze považovat 2 nezávislé systémy (v případě modulární UPS nejlépe navíc každá UPS s vnitřní redundancí na bázi modulů N+1), přičemž každý systém UPS by měl disponovat vlastní sadou baterií a ideálně více než 1 stringem na každou UPS. Ty musí být rovněž výkonnostně dostatečně naddimenzovány pro případ poruchy druhé UPS. V datovém centru by se v ideálním případě neměla nacházet žádná jednozdrojová zařízení. Taková zařízení je pak nutné vybavit STS (static switchem) zajišťujícím plynulé přepnutí mezi napájecími větvemi při havárii jedné celé větve bez vlivu na běh zařízení. Jediným provozovatelem v ČR, který STS nabízí jako nadstandardní výbavu racků je VSHosting.

ServerPark

ServerPark


Zásobování naftou – jak dlouho vydržíme při výpadku elektřiny

V únoru tohoto roku postihla VVN rozvodnu na Chodově v Praze porucha vedoucí k asi třicetiminutovému výpadku napájení velké části Prahy. Mnoho provozovatelů datacenter se na twitteru či facebooku chlubilo, jak bravurně zvládlo pomocí generátoru zazálohovat napájení datacentra. Nicméně zde jde o naprosto běžnou situaci, se kterou si datacentrum musí umět poradit naprosto automaticky. Třicetiminutový výpadek by žádnému standardnímu datacentru neměl činit problém. Jaká by však byla situace při výpadku trvajícím 6, 12, 24 hodin nebo déle? S tím souvisí reálný stav zásob nafty pro pohon záložních generátorů datacentra. Řada provozovatelů nemá odpovídajícím způsobem vyřešeno naftové hospodářství s dostatečnou rezervou (TIER III udává objem paliva pro souvislý provoz z generátorů po dobu minimálně 48 hodin). Řada datacenter má generátory včetně nádrží umístěny na střeše, což dělá doplňování paliva značně obtížným. Má-li některé datacentrum sjednané smluvní zavážení nafty, je otázkou, zda v případě výpadku elektřiny budou okolní čerpací stanice fungovat, a tudíž nakolik se na takovou službu při delším blackoutu lze spolehnout.

Chlazení – podceňování souběhu poruch

Nedostatečně řešené chlazení patří rovněž mezi nejčastější důvody výpadku datacenter. Pomineme-li rozdílnost a spolehlivost jednotlivých technologií, podstatná je potom reálná míra redundance a riziko nedostatku takové míry zálohy chlazení. Většina datacenter uvádí, že disponují redundancí na úrovní chlazení N+1. To znamená, že si datové centrum bez vlivu na provoz může dovolit výpadek 1 chladící jednotky. Je to dostatečné? V případě, že se jedná například o přímý výpar, tedy nejčastěji použitou chladící technologii datacenter, každá porucha na chladícím okruhu znamená odstávku jednotky i na několik dní. Znamená to odsát chladivo, provést opravu, vakuovat okruh (několik hodin), doplnit chladivo, zprovoznit jednotku. Klimatizační jednotky tvoří nejporuchovější části datacentra, protože mají spoustu mechanických částí (motory, elektronicky řízené ventily, ventilátory apod.) a jsou trvale v chodu. Riziko souběhu poruch tak existuje a v případě N+1 redundance může jít o kritickou situaci, která způsobí výpadek datacentra. Často provozovatelé datacenter opomíjejí fakt, že kromě chladícího výkonu je nutné řešit objem vzduchu. Trend výrobců serverů je v dnešní době takový, že na stále se snižující příkon serveru připadá stále stejný průtok vzduchu serverem. Může se tak stát, že chladící jednotky mají sice rezervu ve výkonu, nemusí však stačit objem vzduchu, což se může při poruše jednotky projevit velice rychle formou podtlaku ve studené uličce a přehříváním serverů.

ServerPark


Kvalitní projekt – krátkodobý výhled se nemusí vyplatit

Značně opomíjeným prvkem je v rámci bezpečnosti datacenter kvalitní projekt s výhledem do budoucna. Často datacentra vznikají „na koleni“ a rozšiřují se až dle aktuálních potřeb klientů bez řádného projektu. U takových datacenter pak hrozí reálné riziko, že v kritickém případě nezafunguje správně selektivita či nejsou správně spočítané zkratové proudy jistících prvků. Může se tak například stát, že prostá porucha zdroje v serveru vedoucí ke zkratu způsobí popadání jističů až na výstupu z UPS a dojde tak ke kompletnímu výpadku celé větve. V kombinaci s nedostatky z pohledu UPS popsaných výše může tak snadno dojít k výpadku celého datacentra. Výpočet selektivity je jednou z nejdůležitějších částí každého energo projektu datacentra.

Článek byl připraven na základě materiálů společnosti VSHosting.

-vsh-

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.
Alvao

Časopis IT Systems / Odborná příloha Archiv časopisu IT Systems
IT Systems 10/
IT Systems 9/
IT Systems 7-8/
IT Systems 6/
Oborové a tematické přílohy
příloha #1 10/
příloha #1 9/
příloha #1 7-8/
příloha #1 6/
Onlio
Kalendář akcí