fireTMS > Blog > Raport o incydencie: awaria i odzyskiwanie bazy danych fireTMS

Raport o incydencie: awaria i odzyskiwanie bazy danych fireTMS

ikona zegara5 minut czytania

19 lipca 2024 / Autor: Zespół fireTMS

Przegląd

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.

Słowniczek

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.

Kalendarium wydarzeń

11 lipca 2024 r

21:59:15: OVH nieoczekiwanie wyłączyło główny serwer bazy danych fireTMS.

12 lipca 2024 r

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ń.

13 lipca 2024 r

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.

14 lipca 2024 r

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.

15 lipca 2024 r

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.

16 lipca 2024 r

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.

Podsumowanie

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.

Następne kroki

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.

Newsletter

Informacje od fireTMS są cenne jak ładunek

Regularnie dostarczamy informacji o naszym systemie oraz na tematy z branży TSL.

Zapisz się do newslettera i bądź na bieżąco.

Obowiązek informacyjny RODO - Administrator danych osobowych

Administratorem Twoich danych osobowych jest fireTMS.com Sp. z o.o. Dane wskazane w niniejszym formularzu będą przetwarzane w celu dostarczenia newsletterów fireTMS.com Sp. z o.o. na podstawie prawnie uzasadnionego interesu – art. 6 ust. 1 lit. f RODO. Podanie danych jest dobrowolne, ale niezbędne do otrzymywania newslettera. Twoje prawa oraz zasady przetwarzania danych osobowych są szczegółowo określone w Polityce prywatości

Tagi
Rate the article!

0

3 ratings, avg: 5
Zespół fireTMS

Zespół fireTMS

Artykuł został napisany przez zespół fireTMS, w oparciu o wiedzę, doświadczenie i znajomość branży TSL.

Zobacz podobne artykuły
Plik z rejestrem załadunków i rozładunków do 4Trans w FireTMS

Plik z rejestrem załadunków i rozładunków do 4Trans

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 […]

ikona zegara2 minuty czytaniaPrzeczytaj więcej
Metoda drag and drop w fireTMS

Dodawanie dokumentów metodą Drag and Drop i inne nowości

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ć […]

ikona zegara1 minuta czytaniaPrzeczytaj więcej
Zadania przypisywane dla wielu użytkowników w fireTMS

Zadania przypisywane dla wielu użytkowników i inne nowości

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 […]

ikona zegara2 minuty czytaniaPrzeczytaj więcej