Názory k článku
Výpadek AWS byla chyba souběhu dvou procesů, které se starají o DNS

Tak ono staci se podivat trocha na coalescing... jak ty zavisle ukoly planovat tak, aby se to nezahltilo.

Problem je velice podobny tomu s cim se musi vyporadat napr cron - pokud ukol trva dele nez hodinu a mate to naplanovano v hourly, tak jaky pristup zvolit? Nasilne dodrzovat plan, ze se to bude poustet co hodinu ale riskujete zahlceni.. anebo se pozadavek vypusti, kdyz dana vec se nestihla dokoncit v ramci sveho periodickeho okna?

A zrovna tu vec s cronem resi elegatne systemd timer.

To jednak, ale už dinosauři programovali tak, že si to hlídalo samo, zda to neběží dvakrát. Potom se to z cronu dá spouštět každou minutu a poběží to pouze jednou.

doporučuji tohle vyzkoušet, když máš výraznou zátěž (např. násobky počtu jader), pak se ty cron procesy umí přednánět, flock nebo listen socket v tom udělají pěkný čurbes a neplatí, že to běží jen jednou. Naopak u systemd timer se mi tohle nestalo.

Jako dinosauři jsme s tímhle právě problémy měli.

if [ -f lock.file ]
then
touch lock.file
delejNecoUzitec­neho.sh
rm lock.file
fi

Lépe (atomicky) to tedy neumím...

Jakože je tak náročný problém, aby si program při spuštění nejdřív zkontroloval, jestli už neběží?

Hlavně to, prosím, neříkejte mému wrapperu na crony, jo? Ještě by se tak po těch letech bezchybného provozu začal chovat.

Tyhle tasky na velkých infrastrukturach resi typicky globalni nadřazené job plannery. Nikd pricetny tohle nebude řešit přímo na stroji kde task bezi.

28. 10. 2025, 09:53 editováno autorem komentáře

DNS byla jen prvni (kratsi, asi tri hodinova) vlna problemu. Pak nasledovaly dalsi dve, co incident natahly v souctu asi na patnact hodin - a ty byly fatalnejsi. Nejdriv DropletWorkflow Manager starajici se o "pronajmy" pro EC2 umlatil DynamoDB pozadavkama a kdyz se vyhrabali z tohoto, tak si umlatili prozmenu Network Manager starajici se o sitovani EC2 a balancery jako dusledek vyhazovaly instance, ktere kvuli tomu nebyly jeste dostupne. Aneb typicky to cele dopadalo na EC2 s jepicim zivotem.

Realne to ukazalo, ze AWS to nema moc nachystane na nejake disaster-recovery. Automatizace pocitala s beznym cvrkotem, ne s tim ze se to muze vysypat cele.

Zajímalo by mě, kdo má (v tomto rozsahu).

Azure nebo Google Cloud. Oba proklamují, že jednotlivá lokality řídí samostatně a ani u jednoho se podobný problém nestal, u AWS už ponělikáté jim to spadlo celé kvůli jedné lokalitě.

GCP nemá takový share, zabijí produkty a služby…
Azure má problémy se škálovaním CP pro compute, firewalls na storage, rozbijí vlastní SDK klienty upgradem velikosti certifikátů, nefungující time sync na VMs…
Každý cloud má svoje gotchas, ale AWS je pořád top

GCP zabiji produkty? Ktere? Google ano, ale GCP je v tomto stabilni na urovni AWS, tj. zabiji stare rady compute a verze managed aplikaci, ale jinak pokud vim nic.

Google Cloud je na tom lepe, ale AWS ted nepadlo "cele".

Padl jenom region us-east-1, ktere je default v menu, bezi v nem nektere single-homed interni AWS sluzby a AWS tam deployuje jako prvni. A je tam pulka internetu single-homed, takze manazment a zakaznici lepe chapou, kdyz mate vypadek jako vsichni 18h, nez kdyz mate hodinove spomaleni kvuli vypadku availability zony us-east-2a, o kterem nevi nikdo.

I v Googlu treba multiregion, kdyz chcete 5 devitek.

Azure má každou chvíli nějaký problém. Naposled jeho Front Door nejel pro celou Evropu a blízký východ, snad více než 8 hodin a rozhodně to nebylo letos poprvé. Jejich patchem na AKS nám vyřadili na týden celý cluster a aby se to po týdnu samo opravilo s dalším patchem.

Přesně. Azure sice možná nepadne globálně ale na to, aby mě zcela přešly naivní představy o stabilitě mi stačily dva roky nepříliš intenzivního používání.

Vždycky je to DNS

Do Not Serve ;-)

Tak DNS jsou složitá a nespolehlivá služba. Když jsme adminům v minulé práci jako vývojáři reklamovali hlášky typu "Name or service not known" tak nám bylo řečeno že DNS jsou nespolehlivý ;-)

On je v praxi docela problém s negative ttl, tedy že si resolver pamatuje, že nějaký záznam na serveru neexistuje. Problém je, když někdo okopíruje SOA záznam, kde je negative nastaveno třeba na měsíc a klienti se zeptají dřív, než tam ten nový záznam skutečně je. To potom to dns někde funguje a jinde ne podle toho, kdo se kdy zeptal.

Tak ono to pole historicky melo vicero vyznamu (zminuje treba RFC2308)... a lidi jsou radi otroky minulosti, kdy casto SOA proste tupe kopiruji a vlastne nad temi cisly moc nedumaji :-) Takovy zonemaster ma na to i test, ktery hlida rozpeti od 300 do 86400 sekund a cokoliv mimo tento interval failne. Mimo to, resolver se tim ridit ani nemusi - realne to pole rika, jak dlouho muzu tu negativni odpoved drzet, ale je to optional. A treba v Bindu se to ridi pomoci max-ncache-ttl - kdy vychozi hodnota je 3 hodiny a vic nez tyden to ani nezkousne, v Unboundu je to podobne cache-max-negative-ttl, kde default je hodina. Aneb panem sani je ve finale tady spravce resolveru a ne spravce zony... :-)

Akorát, že tady to DNS vlastně vůbec nebylo. Resp. je to stejné jako byste napsal: Vždycky je to IP nebo vždycky je to Ethernet. Protože DNS bylo v tomto případě jenom posel špatných zpráv...

Doporučuju tento kanál na YT: https://www.youtube.com/@kevinfaang

Je to plné podobných příběhů, poslední je o tom, jak zálohovací skript od HP smazal v LUSTRE FS desítky milionů souborů (prostě někdo změnil právě běžící bash skript).

zajímavé, neznal jsem ;)

Jo, změnit si pod rukama běžící bash skript, to se mi už taky podařilo. Sice s mnohem menším dopadem, ale i taky si to od té doby hlídám. :D

Já bash moc nepoužívám (pouze onelinery) a tohle mě fakt po těch letech překvapilo. On to bere po řádcích přímo ze souboru.

Takhle fungují snad všechny Unixové shelly (bash, ash, ksh, zsh…). Je to jen o tom, že unixové shelly v době svého vzniku neměly na počítačích k dispozici mnoho RAM (~60. léta, tj. řádově kB). Celý skript do paměti načítají až interpretované jazyky (perl, python, ruby,…) nebo powershell, které parsují celou strukturu souboru (AST), ale to už počítače měly k dispozici řádově MB RAM (~90. léta).

Historickému kontextu rozumím, ale proč je to tak i dnes to netuším. Ten interpretr netřeba měnit, jen stačí načíst ten soubor při otevření celý.

Nebo se někde využívá toho, že skript modifikuje sám sebe při svém běhu?

AWS (US-EAST-1) DynamoDB Outage report explained in plain English.

1. A race condition in DynamoDB’s DNS automation deleted its main endpoint record.

2. This happened when 2 DNS systems updated Route 53 at the same time and removed all IPs.

3. DynamoDB went offline, and services that depend on it like EC2, Lambda, Redshift, and IAM stopped working.

4. EC2 could not launch new instances because it uses DynamoDB to track server state.

5. Network and Load Balancer systems failed next, causing connection errors across AWS.

6. Engineers fixed the DNS issue, full recovery took about 15 hours.

If you are a DevOps or Cloud Engineer, this is a great use case to understand.

A small DNS automation glitch can bring half the internet down.

V Cloudu ma kazda sluzba vlastni sit a CIDR rozsahem, ktery nemusi byt unikatni.
Private endpoint je IPcko ve vasi siti, ktere reprezentuje sluzbu z jine site. Je to IPcko pres ktere se NATuje pristup k jine sluzbe. V tomhle prepade to byla IPcka DNS serveru.

Jak se zda tak v jednu dobu bezely dva terraformy, ktere nejak manipulovaly s temi endpointy a vysledkem te operace bylo, ze vsechny DNS endpointy byly smazany.

Neni to tak davno co si nejaka firma odpalila DNS a pak zjistila, ze bez DNS nefunguje AD (v prepade AWS IAM) a bez access managementu se neda DNS opravit.

Není potřeba si vymýšlet, co se stalo. Ve zprávičce je odkaz na post-mortem analýzu od Amazonu, kde je to podrobně popsané.

To nic neni, ale ted si predstavte, ze mate postel za 3k USD, platite predplatne 200 $ / rok - a postel vam zacne topit, piskat, nebo nejde sklopit a nejde na ni spat, muste ji odpojit od elektriny, protoze vypadlo AWS a ona je tak dobre napsana, ze se z toho zblaznila ;-)

https://www.youtube.com/watch?v=SMA6TvLvbTw

No, pokud si někdo něco takového koupí, tak pak se dá říct jen "dobře ti tak, máš co jsi chtěl".

Postel jeste vytahnete ze zasuvky.. ale v rodine se stalo ze privreli auto vratama od garaze. A ted to ma false readingy na znacky a buhvi co a neda se s tim jezdit protoze to keca velice nevybiravym zpusobem do rizeni :D (mozna na asistencni systemy je pojistka.. ale zatim to vypada na odtah.. pritom takova pitomost).

Ona ta blbost začíná už uraženým zrcatkem. Topný tělíska, serva zrcátka, kamera a osvětlení prahu. To vše je v háji. A po montáži nakalibrovat bird view.

To je postel pro techniky AWS :-D Za nás stačila SMSka z NAGIOSu, oni se asi chtějí probouzet jinak :-D

Nám zas když nepřišla smska věděli jsme ze budem v novinách... nemej monitoring cisla na vlastni siti. A samozřejmě jsme používali megadrahy monitoring úplně k ničemu a s hromadou "konzultantu" kolem.

29. 10. 2025, 12:52 editováno autorem komentáře