Rušičky pro optiku vážně i nevážně

Vždy jsem si myslel, že pro optiku existují jen dvě rušičky: Buldozer a cikán s krumpáčem. Minulý týden jsem ale objevil ještě další rušičku, se kterou jsem opravdu nepočítal. Článek je jako novoroční trochu nevážný. Popisované okolnosti mě ale přiměly k zcela serioznímu zamyšlení nad vylepšením dostupnosti našich serverů.

Začnu tím, že optické spoje mám rád. Zkušenost mi jednoznačně ukázala, že se jedná o velmi spolehlivý prostředek spojení. Na rozdíl od bezdrátových spojů. Ty může ovlivňovat a rušit mnoho vlivů. Optický spoj, jak jsem vždy rád říkal, má jen dvě možné rušičky, výše uvedené. 🙂

Přirozeně, snažím se mít vlastní i zákaznickou infrastrukturu umístěnou tam, kde připojení využívá výhradně optické spoje. Jen výjimečně, jednou za několik roků dojde k selhání nějaké komponenty. Ta bývá v krátkém čase vyměněna, protože se s takovýmto selháním počítá.

Tentokrát byl však výpadek delší než jeden den. Trochu mě to zaskočilo.

Samozřejmě se tak stalo v době, kdy jsem měl rozjetých několik marketingových kampaní (nejen pro nás), závislých zcela na fukcionalitě internetových prezentací. A webový server, na kterém jsou umístěny, je právě v této postižené lokalitě. Nádhera. Rázem jsem byl pod palbou naštvaných zákazníků. K čemu vlastně došlo?

Příčinou bylo porušení optického kabelu

U našeho poskytovatele připojení je krátký úsek optického spoje veden vzduchem. A právě na tento úsek se zaměřil nově objevený typ rušičky, vtělený do pracovníka ostrahy. Ten si usmyslel, že rampouchy mohou na někoho spadnout. Proto vzal klacek a rampouchy otloukl. Bohužel, bušil tak zdatně, že zničil i optické jádro kabelu.

Poučení pro mě

Takové případy se prostě stávají. I když při čtení vypadají takovéto historky skoro neuvěřitelně. Pro mě to ale znamenalo poučení: I když je optika extrémně spolehlivá, pro infrastrukturu bude třeba realizovat jedno z následujících opatření:

  • Přemístit ji do datového centra s autonomním systémem
  • Vybudovat pro ni vlastní autonomní oblast se záložním spojením
  • Připravit nouzovou migraci na jiné servery (pro webový server, případně i pro poštovní server)

Aktuálně jsme zvolili poslední z uvedených možností, především z důvodu ceny realizace.

DNS servery

DNS systém distribuovaný do různých lokalit, již máme od jeho zřízení.

Mail exchanger

Poštovní systém jsme distribuovaný v minulosti do dvou lokalit měli také. Ovšem díky vysoké spolehlivosti spojení i robustnosti serverového řešení jsem toto uspořádání zrušil.

Něco to stálo, a správa byla také znatelně náročnější. A protože se tehdy jednalo o plnohodnotný server se synchronizací konfigurace s primárním serverem, nikoli jen o záložní mail exchanger, stačil pouhý restart primárního serveru k tomu, aby začal „požírat“ emaily zákazníků. Při správě s jeho fungováním bylo třeba počítat a server zastavit. Záložní poštovní server jsem tedy nejprve jen vypnul a později smazal.

Za čtyři roky od definitivního zrušení jsem toho zalitoval poprvé. Ze striktně ekonomického pohledu se nám poštovní servery ve dvou lokalitách nevyplatí. Slouží převážně pro naši interní potřebu. Těch několik zákazníků, který náš interní server využívá, další instanci nezaplatí. Výpadky při poruchách byly vždy velice krátké, málokdy je některý z těchto zákazníků vůbec zaznamenal.

Tentokrát si toho ale, samozřejmě, všichni všimli.

Web server

Web server distribuovaný do lokalit jsme neměli a nemáme. Ekonomicky mi to nedávalo nikdy smysl. A oproti například poštovnímu systému, který je na to již v principu připraven, je toto řešení také technicky náročnější.

Aplikační servery

Aplikační servery v produkční řadě již tento problém měly vyřešeny, a dobře, jak se ukázalo.

Co uděláme v průběhu následujících měsíců?

  • Zřídíme pro vlastní potřebu záložní poštovní server v jiné lokalitě. Server bude příjmat poštu pouze v případě výpadku serveru v hlavní lokalitě. Pro případ střednědobého výpadku bude v záložní lokalitě připravena aktuální záloha primárního poštovního serveru.
  • Připravíme postup pro odzálohování webového serveru, transport zálohy do jiné lokality a odzálohy. Pro případ, kdy aktuální zálohu nebude možné získat a nebo dopravit do záložní lokace, připravíme automatickou údržbu poslední denní zálohy webového serveru v záložní lokaci.

Pokud vás budou zajímat podrobnosti, časem je doplním v dalším dílu.

 

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.