Uncategorized

Node divinus: post-mortem

V minulém týdnu ve dnech od 11.10. –  13.10. (neděle – úterý) došlo k několika samovolným vypnutím node divinus a tím k významným výpadkům dostupnosti VPS části našich zákazníků.

Tento příspěvěk má za cíl osvětlit celou situaci, to jak jsme postupovali a jak budeme výpadky kompenzovat. Text je delší, ale věříme, že pravdivým a podrobným popisem situace dokážeme vysvětlit, že jsme pro řešení situace udělali vše, co bylo v našich silách.

Omlouváme za zpožděné vydání, ale celý týden jsme prioritně řešili následky výpadku.

V případě, že Vás podrobný popis nezajímá, můžete přejít rovnou na závěr, kde jsou informace o kompenzaci.

Technický popis node divinus

Všechny naše služby  provozujeme na komponentách firmy Supermicro. Tato společnost je osvědčeným a dlouholetým výrobcem serverového hardware. Samotný divinus je pak osazen dvěma procesory Intel Xeon E5-2620v2 2.1GHz a DDR3, paměťmi Hynix certifikovanými přímo pro desky Supermicro. Disky jsou v Linuxovém RAID 1 (mirror). Server byl zakoupen před dvěma lety.

Chronologický popis situace

11.10.2015 (Neděle)

15:38 – Jeden z našich dohledových systémů nás upozornil na nedostupnost node divinus. Naši administrátoři se situací začali okamžitě zabývat. Jako první krok jsme si ze serverovny vyžádali vzdálený přístup přes KVM abychom se připojili přes internet přímo na monitor a klávesnici serveru.

Při čekání na připojení ze strany server housingu jsme informovali zákazníky o problému emailem a na Facebooku.

15:52 – Po připojení na KVM jsme zjistili, že server na nic neraguje a to ani na vzdálený reset přes zásuvku. Po několika pokusech o oživení ve spolupráci se zaměstnancem dohledu, který je přímo na místě, jsme se rozhodli přesunout do serverovny.

16:25 – Po příjezdu na místo zjišťujeme, že server nabíhá a působí zcela normálně. Rozhodli jsme se jej podrobit několika testům vč. Memtestu. Protože server je osazen 96 GB RAM, trvá Memtestu zhruba 40 minut než nalezne první vadný modul. Následně do deseti minut je nalezen druhý.

17:15 – Vyměnujeme vadné moduly a zapínáme server. Podrobujeme jej dalšímu krátkému testování v Memtest. Server resetujeme a kontrolujeme, že systém nabíhá v pořádku a vše je “na svém místě”.

17:34 – Postupně zapínáme virtuální servery zákazníků. Nedostupnost byla ukončena. Následující hodinu sledujeme stav na místě.

18:30 – Vše se zdá být v pořádku. Informujeme zákazníky o situaci, opouštíme serverovnu a považujeme věc za uzavřenou.

Výpadek trval necelé dvě hodiny. Během zbytku neděle a v průběhu pondělí pak monitorujeme situaci. Veškeré hodnoty jsou, až na synchronizaci polí, v normě.

13.10.2015 (Úterý)

00:02 – Velmi krátce po půlnoci dostáváme opět hlášení o nedostupnosti z externí sítě. Žádáme o KVM ze server housingu.

00:20 – Příznaky jsou stejné jako při nedělním incidentu. Balíme se a vydáváme do serverovny.

00:45 – Po příjezdu server vypínáme. Protože je hluboká noc, a předpoklad je, že dopad na zákazníky a jejich služby je minimální, rozhodli jsme se vzít si potřebný čas a server důkladně prozkoumat. Vyměnili jsme zdroj za nový, “poutahovali kabely”, zkontrolovali funkčnost všech ventilátorů a nanesli nově teplovodivou pastu na oba procesory. Opět jsme sputili testování pamětí RAM.

03:50 – Po výše uvedných krocích a po zhruba další hodině a půl testování jsme nezjistili žádný problém. Server se choval stabilně, žádný vadný modul nebyl nalezen. Nicméně jsme se rozhodli, že hardware nedůvěřujeme. Začínáme analyzovat možnosti.

04:20 – Padlo rozhodnutí, že ještě tentýž den v noci přemigrujeme všechny zákazníky na jiný server. Jedná se o node tursiops.

Potíž s tursiopsem je, že v tu chvíli není plně osazen. Chybí jedno CPU a část RAM. To znamená, že nemůžeme migrovat ještě totéž ráno. Zapínáme zákaznické VPS. A doufáme, že divinus vydrží do úterního večera.

05:10 – Zákazníkům oznamujeme nastálou situaci emailem.

06:30 – Komunikujeme s naším dodavatelem hardware o možnostech dodání zbytku komponent pro node tursiops. Tímto děkujeme společnostem Compos a Avatech za excelentní komunikaci a rychlost.

V průběhu dopoledne pak komunikujeme s rozladěnými zákazníky a snažíme se situaci vysvětlit. Rozladěnost naprosto chápeme. Dále bedlivě sledujeme parametry node divinus.

13:10divinus bohužel opět padá. Tentokrát jsme připraveni i s připojeným KVM, server na dálku vypínáme, nahazujeme VPS. Výpadek trvá zhruba 15 minut.

17:22 – Opět výpadek. Nahazujeme a do pěti minut zapínáme VPS. V tu dobu už máme u sebe potřebné komponenty do node tursiops a připravujeme plán migrace. Zákazníkům oznamujeme emailem další postup.

21:10 – Přijíždíme do serverovy, ladíme postup migrace a připravujeme node tursiops.

22:23 – Do této chvíle divinus běží bez potíží. Vypínáme tedy zákaznické VPS standardním způsobem (ACPI), zahajujeme migraci. Během migrace děláme i několik vedlejších kroků v rámci sítě a operačního systému. O těchto budeme informovat v dalším příspěvku.

01:00 – Končíme s migrací, kontrolujeme poslední detaily a zapínáme zákaznické VPS už na node tursiops. Vizuálně kontrolujeme všechny servery přes VNC a ujišťujeme se, že nabíhají v pořádku. Vypínáme servery, které mají zašifrovaný disk a nebootují.

Poté ještě doděláváme práce na node tursiops a sledujeme situaci.

03:30 – Jsme sbalení a těsně před odjezdem ze serverovny. Při poslední kontrole zjišťujeme, že jeden z procesů v systému nestandardně vytěžuje CPU.

Po patnácti minutách pátrání docházíme k tomu, že se jedná o bug v aktuální verzi RHELpotažmo CentOS. Je třeba aktualizovat jádro ze speciálního repozitáře, kde byla tato chyba nedávno opravena.

03:50 – Aktualizujeme systém, opět vypínáme zákaznické VPS a restartujeme node tursiops.

03:59 – Zapínáme VPS a sledujeme situaci. Chyba byla aktualizací odstraněna.

04:10 – Informujeme zákazníky emailem. Odjíždíme domů. Po příjezdu ještě node kontrolujeme. Vše se zdá být v pořádku

Během zbytku týdne pak dochází k postupné synchronizaci všech polí na node tursiops. To způsobuje zvýšený load, který řešíme s jednotlivými zákazníky individuálně.

Závěr

Ještě jednou přijměte naši upřímnou omluvu za způsobené problémy, stres a nedostupnost. Uvědomujeme si, že už pár minut nedostupnosti dokáže pošramotit dlouho budovanou důvěru.

Za pět let (od září 2010), kdy hosting virtuálních serverů provozujeme, byl toto náš první vážný incident takového rozsahu. Udělali jsme vše proto, abychom situaci – do které jsme se nedostali vlastní chybou – vyřešili co nejrychleji a s minimem škod.

Co se týká samotného node divinus, tak po týdnu testování máme vážné podezření na vadnou základní desku.

Kompenzace

Jako kompenzaci nabízíme všem postiženým zákazníkům z node divinus 100% slevu na jeden měsíc.

Tato sleva bude rozložena do dvou po sobě jdoucích faktur. Prakticky to znamená, že Vaše následující měsíční faktura bude zlevněna o 50 % a ta následující po ní taktéž. Slevy začneme uplatňovat od pátku 22.10. včetně. Pokud máte fakturaci čtvrtletní, půlroční a nebo roční, odečteme slevu najednou.

Chystané změny

Na začáku příštího týdne vydáme další článek, ve kterém rozebereme chystané novinky a to, kam naše služba směřuje. Včetně vylepšení některých “procesů”, které se ukázaly, na základě této události, býti slabšími.

Nakonec děkujeme Vám, našim zákazníkům, za trpělivost a mnohdy i projevenou účast a povzbuzení. Děkujeme.

Standard

One thought on “Node divinus: post-mortem

  1. xHire says:

    Díky za tak podrobné rozebrání situace! Hodně si Vašeho přístupu cením (jak během událostí k problémům, tak teď po – být takto otevřený chce značnou odvahu, a většina firem ji nemá).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*