Wieczorem 11 lipca 2024 r. fireTMS doświadczył poważnej awarii w wyniku incydentu z naszym dostawcą usług w chmurze OVH, co doprowadziło do nieoczekiwanego wyłączenia naszej głównej bazy danych. Główna baza danych ma kluczowe znaczenie dla naszej działalności, obsługuje wszystkie dane użytkowników i transakcje. W tym raporcie przedstawiamy harmonogram zdarzeń, naszą reakcję i kroki podjęte w celu przywrócenia pełnej funkcjonalności naszych usług.
Serwer repliki – Serwer repliki to kopia głównego serwera bazy danych, która przechowuje te same dane i jest w czasie rzeczywistym synchronizowana z głównym serwerem. Maszyna jest w innej lokalizacji niż główna baza danych.
Wirtualizacja – technologia umożliwiająca uruchamianie wielu wirtualnych maszyn na jednym fizycznym serwerze, co pozwala na lepsze wykorzystanie zasobów, elastyczność i izolację środowisk.
Serwer roboczy – to serwer, który przetwarza zadania w tle, obsługując różne zdarzenia i operacje zewnętrzne, odciążając główną aplikację.
RAID – to technologia łącząca wiele dysków w jeden system, zwiększająca wydajność i zapewniająca ochronę danych przed awarią dysku. Serwer UI – to serwer, który zarządza interakcjami użytkownika z interfejsem aplikacji, przetwarzając żądania i dostarczając odpowiedzi w czasie rzeczywistym.
– 21:59:15: OVH nieoczekiwanie wyłączyło główny serwer bazy danych fireTMS.
– 07:28: Odkryliśmy, że serwer bazy danych nie działa i próbowaliśmy uzyskać do niego dostęp poprzez protokół IPMI panelu OVH. Jedyne co zobaczyliśmy to „Powered Off”.
Szybkie wyszukiwanie strony statusu OVH pokazało, że na naszym serwerze miał miejsce „Incydent”.
Z niejasnymi informacjami:
– 07:37: Przełączyliśmy się do naszej replikowanej bazy danych w serwerowni zapasowej w innej lokalizacji.
– 07:57: Po przełączeniu do replikacyjnej bazy danych, zrestartowliśmy serwery interfejsu użytkownika.
– 08:12: Stwierdziliśmy obniżoną wydajność aplikacji z powodu niewystarczających zasobów procesora w instancji maszyny wirtualnej. Serwer roboczy również nie działał dobrze, co skłoniło nas do zaplanowania przeniesienia go do serwerowni zapasowej.
– 22:20: Pomyślnie przełączyliśmy serwer roboczy na serwer zapasowy w innej lokalizacji, co spowodowało poprawę wydajności konsumpcji zdarzeń.
– Decyzja: Zdecydowaliśmy się na zakup dwóch nowych serwerów UI w serwerowni zapasowej z 24-godzinnym czasem dostawy, ponieważ czas dostawy podobnego serwera do naszej głównej bazy danych wyniósł ponad 72 godziny.
– 19:08: OVH włączyło nasz główny serwer bazy danych.
– 10:00: Rozpoczęliśmy prace do przejścia na nowe serwery w zapasowej serwerowni i został sprawdzony stan głównego serwera bazy danych.
– 10:14: Wykryliśmy brak partycji RAID. Diagnostyka potwierdziła problem, co doprowadziło do utworzenia zgłoszenia do pomocy technicznej OVH w celu wymiany wadliwych dysków.
– Decyzja: Oczekiwanie na wymianę uszkodzonych dysków przez OVH, ponieważ serwer może w każdej chwili przejść w tryb offline, zakłócając synchronizację danych.
– 17:54: Przekierowaliśmy cały ruch na serwery w serwerowni zapasowej i wstępne testy wydajności wypadły pozytywnie.
– 08:19: Odnotowaliśmy obniżoną wydajność fireTMS.
– 09:02: Wprowadziliśmy poprawki i ponowne uruchomienie serwera w celu rozwiązania problemów z wydajnością, ale jako główną przyczynę zidentyfikowano wyczerpanie operacji zapisu i odczytu na dysku.- 13:26: Otrzymaliśmy wiadomość e-mail od OVH dotyczącą planowania wymiany dysku.
– 21:20: OVH rozpoczęło prace nad wymianą dysków.
– Poranek: Zauważyliśmy, że wymiana dysku została zakończona i rozpoczęto odbudowę głównej bazy danych. Ze względu na niską dostępność zasobów operacji zapisu/odczytu, zespół postanowił przenieść prace na godzinę 15:00.
– 15:00: Rozpoczęła się ponowna synchronizacja bazy danych i trwała do 21:22.
– 22:34: Uruchomiliśmy pierwszy serwer UI w docelowej lokalizacji wraz z przekierowaniem ruchu.- 21:55: Cała infrastruktura została przywrócona do stanu sprzed incydentu.
Ze względu na wewnętrzny incydent w OVH, została wyłączona nasza główna baza danych, więc dokonaliśmy przejścia na infrastrukturę zapasową. Po zauważeniu problemów z wydajnością zostały dokupione dodatkowe serwery w serwerowni z zapasową infrastrukturą.
Po ponownym uruchomieniu głównego serwera przystąpiliśmy do prac nad synchronizacją danych. Po zsychronizowaniu danych, ruch został przekierowany z powrotem na główną serwerownię.
Mamy nadzieję, że dzięki tym szczegółowym informacjom technicznym udało się lepiej zrozumieć, co się wydarzyło i jak poradziliśmy sobie z problemem.
1. Udoskonalenie procedury tworzenia kopii zapasowych: Zmiany na serwerze repliki odnośnie tworzenia kopii zapasowych i przełączania awaryjnego, aby zapewnić szybsze działanie aplikacji w przyszłych incydentach.
2. Optymalizacja zasobów: Przekonfigurowanie serwerów, tak aby maszyny wirtualne miały odpowiednie zasoby procesora i zapisu/odczytu, aby obsłużyć w pełni ruch aplikacyjny.
3. Uaktualnienie infrastruktury zapasowej: Usunięcie wirtualizacji z serwera bazy danych replik i zmodernizowanie naszej infrastruktury zapasowej, aby była w stanie obsłużyć cały ruch produkcyjny bez pogorszenia wydajności.
Regularnie dostarczamy informacji o naszym systemie oraz na tematy z branży TSL.
Zapisz się do newslettera i bądź na bieżąco.
Zespół fireTMS
Artykuł został napisany przez zespół fireTMS, w oparciu o wiedzę, doświadczenie i znajomość branży TSL.
Z tego artykułu dowiesz się o nowych funkcjach i ulepszeniach: Plik z rejestrem załadunków i rozładunków do 4Trans Z nową wersją FireTMS wprowadziliśmy możliwość wygenerowania pliku z rejestrem załadunków i rozładunków przeznaczonego do programu 4Trans. Zestawienie to można wygenerować z listy ze wszystkimi zleceniami, wybierając odpowiedni zakres dat. Dla każdego z kierowców zostanie wygenerowany wtedy […]
2 minuty czytania
Z tego artykułu dowiesz się o nowych funkcjach i ulepszeniach: Dodawanie dokumentów metodą Drag and Drop Aby ułatwić i przyspieszyć pracę naszym użytkownikom, dodaliśmy możliwość zbiorczego załączania dokumentów do systemu metodą Drag and Drop. Wystarczy na przykład zaznaczyć preferowane pliki z komputera i przeciągnąć je do FireTMS do sekcji z dokumentami. Metodę tą można zastosować […]
1 minuta czytania
Z tego artykułu dowiesz się o nowych funkcjach i ulepszeniach: Zadania przypisywane do większej ilości użytkowników O funkcjonalności zadań wspominaliśmy już we wcześniejszych wpisach. Dzięki tej funkcji użytkownik może tworzyć zadania i przypisywać je do wybranych osób. Każde z tych zadań będzie miało określony termin realizacji, może dotyczyć dowolnej kwestii albo być powiązane z ładunkiem […]
2 minuty czytania