Gcore - Chmura | Szczegóły incydentu w Amsterdamie – Szczegóły incydentu

Analiza przyczyn źródłowych

Wydanie
4 marca 2026 roku niedobór pojemności pamięci masowej w jednym z klastrów pamięci masowej w regionie Amsterdamu spowodował tymczasowe zablokowanie operacji zapisu. W rezultacie maszyny wirtualne korzystające z systemu pamięci masowej, którego dotyczył problem, doświadczyły awarii wejścia/wyjścia na dysku i zakłóceń w świadczeniu usług.

Problem wystąpił podczas prac konserwacyjnych związanych z aktualizacją platformy pamięci masowej. Chociaż aktualizacja zakończyła się pomyślnie, połączenie redystrybucji danych w tle i nietypowo wysokiej aktywności zapisu spowodowało, że wykorzystanie pamięci masowej przekroczyło próg krytyczny, uruchamiając mechanizm ochronny, który tymczasowo blokował nowe operacje zapisu.
Funkcjonalność usługi została przywrócona po podjęciu działań awaryjnych mających na celu odzyskanie pojemności pamięci masowej.

Oś czasu (UTC)

• 4 marca 2026 r. – 15:50: Zakończenie aktualizacji platformy pamięci masowej i rozpoczęcie redystrybucji danych w tle

• 4 marca 2026 r. – 16:20: Wykorzystanie pamięci masowej osiąga próg krytyczny; klaster przechodzi w stan blokowania zapisu

• 4 marca 2026 r. – 16:21: System monitorowania staje się niedostępny, ponieważ zależne maszyny wirtualne doświadczają błędów pamięci masowej

• 4 marca 2026 r. – 16:23: Wiele raportów klientów wskazuje na powszechne problemy z dostępnością maszyn wirtualnych

• 4 marca 2026 r. – 17:25: Śledztwo wykazało, że przyczyną jest wyczerpanie pojemności magazynowej

• 4 marca 2026 r. – 17:28: Zespół inżynierów ds. pamięci masowej rozpoczyna procedurę awaryjnego odzyskiwania pojemności

• 4 marca 2026 r. – 17:40: Operacje zapisu zostały przywrócone, a dotknięte maszyny wirtualne zaczynają odzyskiwać dane

• 4 marca 2026 r. – 18:00: Funkcjonalność platformy zweryfikowana za pomocą testów systemowych

• 4 marca 2026 r. – 18:59: Pozostałe maszyny wirtualne odzyskano, a incydent zamknięto

Przyczyna źródłowa
Do incydentu doszło z powodu chwilowego wzrostu wykorzystania pamięci masowej, spowodowanego dwoma równoczesnymi czynnikami. Po ponownym uruchomieniu systemu pamięci masowej podczas konserwacji, rozpoczął się automatyczny proces redystrybucji danych, tymczasowo zwiększając wykorzystanie pamięci masowej podczas ponownego równoważenia danych między węzłami.

Jednocześnie, nietypowo wysoka aktywność zapisu w obciążeniu roboczym spowodowała zużycie dodatkowej pojemności pamięci masowej. Ponieważ klaster działał już przy stosunkowo wysokim obciążeniu, łączny efekt spowodował, że użycie pamięci masowej przekroczyło próg bezpieczeństwa systemu. W rezultacie platforma pamięci masowej automatycznie zablokowała operacje zapisu, aby chronić integralność danych, co spowodowało awarie wejścia/wyjścia na dyskach maszyn wirtualnych korzystających z tej pamięci masowej.

Elementy akcji

• Wprowadź obowiązkową procedurę walidacji przed konserwacją, aby mieć pewność, że automatyczne mechanizmy redystrybucji danych zostaną wyłączone lub będą kontrolowane podczas ponownego uruchamiania lub aktualizacji usług pamięci masowej.

• Wprowadź zabezpieczenia pojemnościowe do procedur konserwacyjnych, aby zapobiec przeprowadzaniu modernizacji w sytuacji, gdy wykorzystanie pamięci masowej przekroczy bezpieczne progi operacyjne.

• Zwiększ dostępną pojemność pamięci masowej w regionie objętym problemem, aby zachować wystarczającą ilość miejsca na operacje związane z danymi w tle i nagłe wzrosty obciążenia.

• Przeanalizuj procedury operacyjne dotyczące planowania działań konserwacyjnych, aby zagwarantować odpowiednią wydajność systemu i przejrzystość podczas modernizacji.

Z przyjemnością informujemy, że poważna awaria w Amsterdamie, która wpłynęła na działanie naszych usług w chmurze, została rozwiązana. Jeśli jednak nadal będą Państwo mieli jakiekolwiek problemy, prosimy o kontakt z naszym zespołem wsparcia. Z przyjemnością udzielimy Państwu pomocy i dopilnujemy, aby wszelkie dalsze kwestie zostały niezwłocznie rozwiązane.

Doceniamy Państwa cierpliwość i zrozumienie w związku z tym incydentem i dziękujemy za współpracę.
Obecnie trwają prace nad przygotowaniem formalnej analizy przyczyn źródłowych (RCA), która zostanie opublikowana po jej uzyskaniu.

Aby uzyskać dalszą pomoc, skontaktuj się z naszym zespołem wsparcia pod adresem support@gcore.com

Z przyjemnością informujemy, że nasz zespół inżynierów wdrożył poprawkę, która rozwiązała poważną awarię usługi w chmurze. Nadal jednak uważnie monitorujemy sytuację, aby zapewnić stabilną wydajność.

Poinformujemy Cię o rozwiązaniu problemu, gdy tylko potwierdzimy, że został on całkowicie rozwiązany.