Cloudflare traci logi
Jamie Herre
14 listopada 2024 roku firma Cloudflare miała problem, który wpłynął na większość użytkowników Cloudflare Logs. Przez około 3,5 godziny awarii nie dostarczono około 55% logów do klientów i zostały one utracone.
Przez błąd w systemie generującym konfigurację dla usługi Logfwdr, ta ostatnia otrzymała... pustą konfigurację! Innymi słowy, Logfwdr nagle nie miał pojęcia, które logi ma przesyłać dalej. Choć błąd został szybko naprawiony, to uruchomił lawinę kolejnych zdarzeń.
Jednym z mechanizmów zabezpieczających w Logfwdr było "fail open" - w przypadku braku konfiguracji usługa miała przesyłać logi dla wszystkich klientów zamiast dla nikogo. Pomysł był słuszny, ale zaprojektowany dla mniejszej skali. Gdy Logfwdr zaczął przesyłać logi dla 40 razy większej liczby klientów niż zwykle, cały system zaczął się dusić.
Usługa Buftee, pełniąca rolę bufora dla logów, zaczęła tworzyć osobne bufory dla każdego nowego klienta, których nagle było 40 razy więcej. Mimo że Buftee miała mechanizmy zabezpieczające przed taką sytuacją, to... nikt ich nie aktywował. Nietypowe obciążenie osiągnęło poziom, z którym Buftee nie była w stanie sobie poradzić i cały system załamał się, powodując utratę części logów.
Ten incydent pokazał, jak pomyłka w jednej części systemu może wywołać lawinę zdarzeń i sparaliżować kluczowe usługi. Cloudflare wyciągnął z niego ważne wnioski:
- Należy regularnie testować scenariusze przeciążeniowe i sprawdzać, czy mechanizmy zabezpieczające działają poprawnie.
- Systemy powinny być tak zaprojektowane, aby błędy w jednym komponencie nie paraliżowały pozostałych części.
- Konfiguracja zapasowych planów działania jest równie ważna, jak same plany. Nieaktywowane zabezpieczenie jest bezużyteczne.
"Nowy" Gracz w wyścigu pod Wodą
Ingrid Lunden
W czasach, gdy dane są nową walutą, Meta, właściciel Facebooka, Instagrama i WhatsAppa, planuje budowę nowego kabla światłowodowego pod morzem. Chce zwiększyć przepustowość internetu i wzmocnić swoją pozycję jako lider technologii.
Meta planuje zbudować kabel o długości ponad 40,000 km, inwestując w to ponad 10 miliardów dolarów. Kabel będzie całkowicie własnością Meta, co jest nowością dla firmy. To nie tylko infrastruktura, ale strategiczny krok dla niezawodności sieci i bezpieczeństwa danych.
Kluczowe Motywy Budowy
- Własność i Kontrola: Posiadanie własnego kabla pozwala Meta na priorytetowy dostęp do przepustowości, co jest kluczowe dla obsługi miliardów użytkowników na jej platformach.
- Omijanie Terytoriów Konfliktowych: Planowany przebieg kabla ma unikać regionów geopolitycznych napięć, takich jak Morze Czerwone czy Morze Południowochińskie.
- Strategiczne Umiejscowienie: Zakończenie kabla w Indiach może być kluczowe dla rozwoju centrów danych oraz potencjalnej infrastruktury AI w regionie.
Budowa takich kabli jest skomplikowana i czasochłonna. Obecnie istnieje ograniczona liczba statków kablowych zdolnych do realizacji takich projektów. Dodatkowo konkurencja z innymi gigantami technologicznymi, takimi jak Google, może wpływać na dostępność zasobów.
Meta wskazuje na korzystny wpływ swoich inwestycji na lokalne gospodarki, co może przyspieszyć rozwój wielu regionów. Co więcej, w kontekście AI, Indie mogą stać się kluczowym miejscem dla treningu modeli sztucznej inteligencji dzięki niższym kosztom.
Koniec wsparcia dla IPv6 w 2025?
To nie jest żart. Firma DigiCert, globalny dostawca rozwiązań TLS/SSL, PKI, IoT oraz cyfrowych certyfikatów, ogłosiła, że przechodzi na rozwiązanie CDN i kończy wsparcie dla IPv6 10 stycznia.
Monitorowanie BGP w Junos z Pythonem
Menuka-WijayarathneJunosViz 0.1.0 to pakiet Python, który ułatwia monitorowanie i alertowanie sesji BGP, liczników i wskaźników wydajności na urządzeniach Juniper. Łączy tradycyjne monitorowanie SNMP z nowoczesnymi metodami jak NETCONF i gNMI, oferując rozwiązanie dopasowane do Junos.
Cyfrowy Bliźniak Sieci
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj