CloudFlare elesett

Közösségi kerekasztal

Se CDN, se Workers elérés, se Dashboard login nem működik.

A DNS megy, de minek.

Más is ezt látja?

Ugyanitt szakértsük meg, hogy lehetne olyan multi-cloud infrastruktúrát összerakni - nyilván két krajcárért, tehát a helyezzünk el 100+ DC-ben szervert ötletek nem játszanak -, hogy az ilyet el lehessen kerülni. Nekem a fő kérdésem, hogy a DNS-t hogy lehet átirányítani ilyenkor másik cloudban felálló infra-ra, ha alapesetben CloudFlare-nél van a DNS. Nyilván fordítva, Amazon Route 53 is el tud romlani.

  • 2816 megtekintés

( pepelopez | 2025. 11. 18., k – 13:08 )

"CloudFlare valaki más számítógépe" :)))

 

"Budapest CloudFlare Error"

( asm v | 2025. 11. 18., k – 13:47 )

Ilyenkor mindenki ezzel a multi-cloud otletelessel jon. Csak ha kiszamoljuk, hogy atlagosan evente egyszer van vmi glitch par orara, akkor kiszamolhato, hogy nem eri meg beruhazni vmi jo komplex megoldasra (aminek a komplexitasabol fakadoan lesznek outage-ek :) ).

Főleg, hogy a Cloudflare inkább egy komplementer megoldás, a CDN témakörben. Tipikusan az alkalmazás és adat réteged az egy másik cloud providernél lesz ígyis-úgyis, vagy akár on-premise.

Persze közben jön fel egy csomó szolgáltatással a Cloudflare is, van lehetőség kódvégrehajtásra és adattárolásra is náluk, de azért ez még eléggé korlátosan alkalmazható teljes üzleti logika kiszolgálására.

Na, azóta eltelt egy kis idő (6 év?), már K8s alapú az egész, ugyanígy 5 DC, három VPS szolgáltató, két földrész, árban kb. ugyanazt, csak sokkal több resource van már alatta. Múltkor említésre méltó röccenés nélkül kibírta, amikor leégett az OVH adatközpontja, viszont annyi SPOF került bele, hogy az Amazon Route53 van DNS szolgáltatóként, ha az megborul és pont valami egyéb gebasz is van, akkor nem nagyon tud átállni másik DC-re, addig round-robin szar lesz a kieső DC vagy node.

Nyilván lehet RDBMS alapokon is, csak komplexebb és törékenyebb a multi region cluster, a Cassandra meg erre készült alapvetően.

https://iotguru.cloud

( wladek1 | 2025. 11. 18., k – 14:18 )

Erdekes modon a fizetos csomagok mukodnek gond nelkul...:)

Error: nmcli terminated by signal Félbeszakítás (2)

( gelei v | 2025. 11. 18., k – 14:27 )

nyilván két krajcárért, tehát a helyezzünk el 100+ DC-ben szervert ötletek nem játszanak

Valamilyen SPOF úgyis lesz a rendszerben, legfeljebb ha több lóvét szánsz a problémára, akkor nagyobb rugalmassággal döntheted el, hogy hol legyen.

Az nem arról szól, hogy a DNS szerver bizonyos szabályok alapján (round-robin, kliens geo-ip lookup) alapján oldja fel a DNS neveket?

Ez hogy oldja meg azt, ha az egyik DNS szerver az adott domainhez olyan szolgáltatónál van, aminek az admin API-ja nem működik, ezért nem tudod az IP-ket átállítani hogy a jó helyre mutassanak? Mert ma konkrétan ez történt. Akinek a CloudFlare-nél volt a DNS-e, az nem tudta módosítani, hiába működött a feloldás.

Nem, az arról szól, hogy egy rekordban több cím van már alapból és hacsak nincs súly beállítva, a kliensek round robin alapon kapnak/választanak. Nem kell közben konfighoz nyúlni, pont ez adja a megoldást még akkor is ha ez egy hosszú időre cache-elhető rekord. Az egyetlen hátulütő, hogy a DNS timeout hosszú, így amelyik kliens elsődlegesnek a hibás ág címét kapta, csak percek után vált a következő lábra

Ez egyetlen dolgot tud megoldani, hogy ne legyen SPOF a DNS. Ennyi, többre nem vállalkozik a két NS rekord két szolgáltatótól. A tegnapi eset ellen nyilván nem védett volna, ahol amúgy nem is a DNS, sokkal inkább a proxying volt a gond, ami már másik rétegbeli kérdés.

( flatline | 2025. 11. 18., k – 15:55 )

Most kezdenek visszaterni. London, Becs, Munchen mar megy(eget).

I don't run often, but when I do, I run as administrator.

( nagyjoco | 2025. 11. 18., k – 20:17 )

A hup mièrt volt lenn?

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( gabrielakos v | 2025. 11. 19., sze – 08:17 )

Kicsit az az érzésem hogy "worldwide" túl sokat pofáztak bele a managerek a mérnökök dolgába - nyilván a spórolás irányába - és ennek meglett a következménye.

Hát nekem az jut eszembe, hogy az egyik helyemen évekig ment a BCP (több DC-vel) és minden évben többször ki volt próbálva (ahogy kell) és a cég mégis simán fejre állt, mert valaki elkefélte a BGP szabályokat és 3-4 DC együtt masírozott a halálba egy fél napra. A router volt a SPOF, azóta máshol van.

https://naszta.hu

Én az első munkahelyemen a szemétből (konkrétan a selejt raktárból) gubázva építettem majdnem-redundáns infrát. Kis Pentium 160 meg 200 gépek, mindegyikben 3 hálókártya, és egy floppy amiről bebootolt a Coyote Linux. Routolt és iptables alapon csomagszűrt. Volt hét ilyen gép, a főiskola 7 szegmensére, a gépek nevei a Hófehérke törpéi voltak. És volt a nyolcadik gép, név szerint Lámpás*, ami arra várt, hogy ha valamelyik törpe megnyekken, akkor beugrik a helyére, ő volt a redundancia a rendszerben, hideg tartalékként.

Sok évig jól működött, még azután is, hogy eljöttem onnan, szóval kiállta az idő próbáját. Az egyetlen nem triviális de időnként jelentkező hibája a rendszernek hálózati lassulás képében jelentkezett. De ilyenkor csak egy csepp olaj kellett az adott gép CPU ventillátorának a tengelyére, (vagy ha a gazdasági helyzet megengedte, venti csere cirka egy ezresért) és máris repesztett az internet.

Valahol vicces, hogy régen milyen egyszerű módon oldottuk meg, hogy a kollégisták pornót tölthessenek az internetről, míg most ugyanezt a célt mennyivel bonyolultabban és menyivel drágább eszközökkel érjük el. :-)

* Mert: "Nyolc törpe volt, de sötét és mély a bánya ..."

Inkább ezt olvassátok el: https://blog.cloudflare.com/18-november-2025-outage/

Szerintem a hibának semmi köze "memory error"-hoz, amivel nyit a videóban. Tovább ezek után nem volt kedvem nézni.

Egy független rendszer olyan invalid (túl nagy) konfigurációs inputot generált, amitől a core proxyjuk elkezdett pánikolni. De mivel  az invalid konfigok nem determinisztikusan jöttek létre eleinte, ezért volt az, amit mi is láttunk, hogy esett-kelt a CF. Ezért akik keresték a hibát, először egy támadásra gyanakodtak, ami a CF-nél napi probléma.

Jó eséllyel a korábbi (nem Rust) verzió is ugyanígy kezelte az invalid konfigot, mert egy rewrite-nál a korábbi verzió testsuite-jával szokás ellenőrizni az új verziót.

A probléma valószínűleg ott volt, hogy az error reporting nem volt elég részletes: a log rendszerükben ott kellett volna villognia a rengeteg invalid config miatti pánikról szóló hibának, amivel sokkal hamarabb megtalálták volna a problémát.

PS: Minden defenzíven programozott rendszerben megadunk maximális hosszt minden inputra, és bizonyos invalid inputokra a pánik / crash /kilépés lehet érvényes válasz. Egy ilyen rendszerben nem szokás túl nagy extra maximális méretet hagyni, mert az szükségtelenül megnöveli a maximális memóriafogyasztást + egy támadónak lehetővé teszi, hogy nagy mennyiségű, potenciálisan veszélyes külső adatot juttasson be a szoftver címterébe.

Inkább ezt olvassátok el: https://blog.cloudflare.com/18-november-2025-outage/

Ezt próbálta elemezni a jóember, csak mivel Rust-fóbiás, ezért elment az egész a Rust-rant irányába. Igen, nyilván a Rust tehet arról, hogy egy teljesen másik rendszer kétszer akkora fájlt generált, mint kellett volna és az input validáció miatt a Bot Management system tátott szájjal befutott a faszerdőbe... 99,9+ százalék valószínűséggel az előző cucc is ezt tette volna. Amatőr hiba, de van ilyen.

https://iotguru.cloud

ühüm. stress-testing? interface resilience test?

Mit akarnál ezekkel tesztelni? Azt írták le, hogy a feature-list fájl beolvasva fix memóriaterületre kerül, performance okokból, ahogy példálóztak, a hibásan kreált fájl meg nagyobb volt ennél. Nyilvánvalóan nem fért volna el a nagyobb konfig, a konfig nélkül a cucc nem tud dolgozni -> crash-restart.

Majd most megtanulja Kumar. Vagy nem.

Ebből két módon tudnak kijönni:

a, nem fix memóriaterületre olvassák be a feature-list fájlt, de gondolom ennek van némi performace problémája.

b, amikor legyártják az új fájlt, akkor validálják, hogy el fog-e férni.

Szerintem a bé, a bé... :)

https://iotguru.cloud

Könnyű utólag okosnak lenni, mert tudod melyik paraméter milyen értékét kell tesztelni. Max elméletben az egyetemen láttam matematikailag igazoltan hibamentes kódot, bármi ami a hello world-nél bonyolultabb, ott a tesztelés elméletben sem tud lefedni minden esetet. Ha felsorolod szerinted a világ összes esetét, tuti mondok legalább egyet amire nem gondoltál. Ha más nem, nem-determinisztikus fizikait, mint ingadozó feszültség, fémes porszemcsék a memória slot lábai közt, nagyenergiájú részecske, stb.