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.

  • 2444 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 ..."