12:49
5/6/2012

Wczorajsza kilkuminutowa awaria części instalacji zasilających w serwerowni Beyond miała krótkotrwały wpływ na kilka dużych polskich serwisów i dość poważny wpływ na klientów chmury obliczeniowej e24cloud.com. Poniżej opis zdarzenia i wyjaśnienia właścicieli serwerowni.

Powód problemu: awaria zasilania

O ile awaria sieci zasilającej dla klientów marki Beyond.pl była nieznaczna i po kilku minutach wszystko wróciło do normy, to skutki chwilowego braku prądu mocno dotknęły użytkowników usługi e24cloud.com, która zlokalizowana jest w tej samej serwerowni pod Starym Browarem w Poznaniu.

Jak udało nam się dowiedzieć, zanik zasilania spowodował uszkodzenie podstawnej i zapasowej macierzy dyskowej w stopniu uniemożliwiającym odbudowę danych z grup RAID, wobec czego zespół techniczny podjął decyzję o uruchomieniu środowiska e24cloud.com na nowych urządzeniach. Jak mówi Anna Adamowicz, dyrektor supportu e24cloud.com:

“Oddanie do dyspozycji naszych klientów pełnego pakietu usług e24cloud.com jest dla nas najwyższym priorytetem. Po całej nocy wytężonej pracy udało nam się przed chwilą uruchomić chmurę .”

e24cloud.com na bieżąco informował swoich klientów o przywracanych do życia zasobach w tym wątku na forum.

Techniczne szczegóły

e24cloud.com zbudowane jest z trzech głównych segmentów – środowiska produkcyjnego, środowiska billingowo-administracyjnego i środowiska backupowego. Na skutek awarii zasilania uszkodzone zostało środowisko produkcyjne e24cloud.com, na które składają się dwie redundantne grupy macierzy zbudowane z grup dysków twardych w RAID 6 (dopuszczalne uszkodzenie 2 dysków z każdej grupy).

“Niestety (jak mawiają, pech jest też redundantny) wiele dysków “nie przeżyło” utraty zasilania – w najgorszym przypadku straciliśmy 60% dysków z grupy raidowej.” – wyjaśnia Anna Adamowicz.

Drugie środowisko, rozliczeniowo-administracyjne na skutek awarii nie ucierpiało, ale w tej chwili jest jeszcze wyłączone, aby nie opóźniać operacji przywracania backupów. Wszystkie dane rozliczeniowe klientów są bezpieczne. W tym momencie dostępna jest już “czysta” chmura. Trwa odzyskiwanie danych klientów i jak wynika z komunikatów e24cloud.com na FB i Twitterze, przywrócone jest już ok 50% środowisk.

Będziesz robił backupy

Ważna informacja jest taka, że trzecie środowisko backupowe dla klientów e24cloud.com nie utraciło integralności danych. Dane zapisane na backupach są już dostępne dla klientów i zostały przywrócone w normalnym dla tego typu przypadków czasie, a jak twierdzą przedstawiciele e24cloud.com wszyscy klienci, którzy “zainwestowali” tę usługę (ok. 50 groszy tygodniowo (2 zł miesięcznie) za 1GB danych), mogą już teraz przywrócić swoje dane na świeżouruchomionym środowisku produkcyjnym.

Co z tymi, którzy nie zainwestowali w backupy?

Pracownicy e24cloud.com tuż po wewnętrznej diagnozie uszkodzonych macierzy podjęło decyzję o transporcie macierzy do Katowic, do firmy zajmującej się odzyskiwaniem danych. Co ciekawe, paradoksalnie najszybciej można było tam dojechać samochodem. Dwie zapytane w Poznaniu firmy zajmujące się wynajmem awionetek i helikoptera nie były wstanie dostarczyć przesyłki w krótszym czasie (samolot potrzebował 4-ech godzin na skompletowanie załogi, a helikopter Robinson nie mógł zabrać ładunku wynoszącego ponad 200 kg).

Dane z uszkodzonych macierzy dostarczono do Katowic, w godzinach popołudniowych. Wg naszych informacji polskie laboratorium traktuje sprawę priorytetowo, jednak nadal nie oszacowano czasu potrzebnego do odzyskania danych z uszkodzonych dysków.

Przedstawiciele firmy e24cloud.com wystosowali przeprosiny dla wszystkich osób korzystających z ich usług:

“Szanowni Klienci – jako poważne przedsiębiorstwo nie uciekamy od odpowiedzialności biznesowej i zamierzamy zrekompensować naszym Klientom niedogodności związane z awarią. Zapewniamy ze – natychmiast po zakończeniu wszelkich prac technicznych związanych z testami ponownie uruchomionych systemów, przystąpimy do indywidualnego ustalania sposobu rekompensowania faktu niedostępności serwisów. Jednocześnie wprowadzamy usługę jednorazowego – darmowego backupu dla wszystkich naszych klientów. Dziękujemy za wsparcie i pomoc.”

Aktualizacja 6.6.2012
Specjalnie dla Grześka z Antyweb (pozdrawiamy!), informujemy, że Beyond krytykować będziemy jak będzie ku temu konkretna podstawa, tj. Beyond w końcu odpowie nam na zadane wczoraj pytania dotyczące tego co konkretnie spowodowało awarię macierzy podstawowej i backupowej jednocześnie. Póki takiej odpowiedzi nie mamy, nie będziemy spekulować co się stało. Jeśli ktoś jest zainteresowany domysłami wszeliej maści specjalistów bazującymi na braku jakichkolwiek sensownych informacji co do przyczyn awarii lub interesuje się stawianiem pytań bez odpowiedzi, to odsyłamy na inne strony. Bo to że Beyond zaliczył faila, chyba nie trzeba nikomu pisać boldem i chyba dość jasno wynika to z tytułu tego wpisu.

Zwracamy też uwagę na to, że ci, którzy wykupili backup na e24cloud, dane odzyskali (chyba, że ktoś nie odzyskał, wtedy prosimy o kontakt) i przypominamy, że przed wykupieniem hostingu należy zapoznać się z regulaminem i sprawdzić czy jest w nim zapis gwarantujący klientowi wykonywanie backupów przez serwerownie (domyślnie i za darmo). Osobom ignorującym potrzebę posiadania regularnego backupu swoich danych życzymy powodzenia i szczęścia oraz wspieramy modlitwą do $DEITY, dotyczy to zarówno klientów chmury e24cloud jak i klientów jakiejkolwiek innej chmury, czy też jakiekokolwiek innego hostingu. Jak to się mówi, ludzi dzieli się na dwie grupy, tych co wykonują backupy i tych co będą je wykonywali. You have learned the hard way ;)

Aktualizacja 6.6.2012, 17:30
e24cloud rozesłał swoim klientom następującą wyjaśnienia:

(…) Przyczyną przerwy w dostępności zasilania był fatalny zbieg okoliczności – nałożenie
się sytuacji awaryjnych w kluczowych punktach instalacji:
a. awaria układu automatycznego sterowania rozdzielniami elektrycznymi,
b. awaria jednego z głównych wyłączników układu SZR,
c. nieprecyzyjne dane na temat czasu pracy na bateriach – urządzenia podają 25 minut podczas kiedy faktycznie ten czas jest krótszy (15min).
Dodatkowym okolicznością, która wpłynęła na przebieg awarii był tzw. czynnik ludzki – tak skomplikowany przebieg awarii zwiększył poziom stresu, co negatywnie wpłynęło na szybkość podejmowania decyzji. (…)


Przeczytaj także:



86 komentarzy

Dodaj komentarz
  1. Zanik zasilania uszkodził *fizycznie* dyski?

    • Czasami zanik zasilania powoduje także inne zjawiska, które po prostu mogły “spalic” elektronikę tych dysków

    • Jakie inne znawiska? Ktoś nie przewidział że wentylatory trzeba właczyć manualnie? Pilot od klimy się zgubił? To niepojęte, przecież zanik zasilania *nic* nie powinien zrobić w prawidłowo zaprojektowanej serwerowni. Pierwszą rzeczą jaką robi projektant to scenariusz braku prądu i powrotu. Czy tam ktoś kupował zasilacze “czterysetki” na allegro że strzeliło im w cholere wszystko przy byle przepięciu?

      Wiadomo co tam się *naprawdę* stało?

    • Dyski SSD są troszkę inne niż wczesniejsze generacje :)

    • Podejrzewam że raczej przywrócenie zasilania spowodowało przepięcie (co też teoretycznie nie powinno się stać) i coś poszło

    • Gwałtowny zanik napięcia, paradoksalnie, może spowodować nagły chwilowy wzrost napięcia (przez indukcję magnetyczną), taki momentalny pik. To mogło spowodować awarię.

  2. Można by było się ładnie przyznać, że po prostu nie mają systemu awaryjnego zasilania środowiska produkcyjnego, ot i co.

    “Drugie środowisko, rozliczeniowo-administracyjne na skutek awarii nie ucierpiało”
    Ale sprawy administracyjno-gotówkowe muszą być sprawne. Kasa nigdy nie przepadnie ;)

    • W samym Beyondzie są co najmniej 2 nitki zasilające od różnych dostawców energii + generator na paliwo. Wczorajszy komunikat mówił, że właśnie podczas wykonywania testów zasilania awaryjnego nastąpiła usterka.

    • Paliwa zabrakło? Myszki kabelki pogryzły? Coś słabo zadziałał potrójny backup energetyczny.

      Jak dla mnie to czyste niedopatrzenie, ale mogę się mylić.

    • Prąd nie ogranicza się do “jest” i “nie ma”, taki generator na paliwo jest bezwartościowy jeśli nie ma przed nim UPS-a i jakiegoś zespołu miękkiego startu, w grę wchodzi wiele czynników z fizyki i matematyki fal

  3. Nie mają w tej serwerowni redundantnego zasilania?
    I czemu macierz podstawowa i zapasowa są w tym samym ośrodku???

  4. Często bywa tak, że urządzenia mechaniczne (dyski/wentylatory/itp.) działają poprawnie aż do odłączenia zasilania. Później już nie chcą wstać :) To w przypadku awarii mechanicznej. Ewentualnie może to być jeszcze przepięcie elektryczne, ale to raczej było filtrowane :)

  5. To jakaś wielka ściema. Padnięcie zasilania w jakiejkolwiek sprzętowej macierzy nie powoduje uszkodzenia RAIDu ani dysków. W tej sprawie jest jakieś głębsze tło.

    • Nie wspominając już o supporcie producenta…

    • Nie wspominając również o zabezpieczeniach takich jak walidacja macierzy – wszakże awaria dysku (powierzchni) jest rozpoznawana dopiero gdy głowica się po danym obszarze przejedzie – walidacja czyli odczytywanie całej macierzy sektor po sektorze powinna być prowadzona regularnie (np. 1-2 godziny na dobę). Utrata 60% dysków w macierzy sugeruje brak walidacji macierzy i skomasowanie błędów dysków w momencie awarii zasilania, gdy potrzebne jest odbudowanie macierzy – po prostu nie wiedzieli w jakim stanie mają dyski przed awarią. W normalnej sytuacji, dyski padają mniej więcej pojedynczo od czasu do czasu. Detektorem awarii jest właśnie proces walidacji.
      Problem powstał w momencie odbudowy macierzy, gdy ten faktyczny stan nie walidowanych dysków się ujawnia bo dyski w macierzy w całości są odczytywane.
      Druga sprawa to podtrzymanie bateryjne cachy kontrolerów, które w zasadzie ma zabezpieczać sprzętową macierz przed degradacją w momencie awarii zasilania. Skoro prądu nie było kilka minut, to awaria o takich rozmiarach raczej nie powinna mieć miejsca.

    • Mam nadzieję, że stawiasz takie wyroki poparte własną praktyką?

    • @xbartex – kolega ma racje , normlnym jest wsadzanie “bateryjek” do kontrolerow w normalnych serwerach, wlasnie zeby nie bylo przeciazen podczas wlanczania i wylanczania
      jak dla mnie to wyglada jak sprzet w serwerowni byl kupiony na stoliku u znajomego ruska
      sorki ale ja rozumiem rozne rzeczy ale takich pierdol to juz dawno nie czytalem, tlumaczenie 8- latka
      ja bym proponowal zeby PR tej firmy zamiast nawijac bez sensu pomogl jakiemus technikowi opisac problem, bedzie bardziej zrozumialy od tego PR-oskiego belkotu

  6. “Dane z uszkodzonych macierzy dostarczono do Katowic, w godzinach popołudniowych.” Ależejak dostarczono dane? Myślałem, że całe macierze pojechały do Katowic. ;)

    • W wiaderkach pewnie je przewozili ;-)

  7. Tło jest takie, że macierz zapewne była kiepska. Przeżyłem wiele padów zasilania w serwerowni, a jakoś nie zdarzyło się, żeby z tego powodu poleciały dyski twarde w dobrym sprzęcie.

    • Popsucie czegoś nawet w “tanim” sprzęcie przez zanik zasilania nie zdarza się często (co najwyżej raid rebuild), może ktoś zrobił coś “nie według procedur” podczas włączania zasilania, tak czy inaczej dziwne że padły 2.

  8. Niech napiszą jaką mieli macierz, warto wiedzieć, który producent na rynku taki szajs sprzedaje.

  9. Nikt nie powiedział, że zasialnie padło. Mówimy o usterce, czyli np. przez pomyłkę elektrycy podłączyli napięcie międzyfazowe (~360V) zamiast normalnych ~240V

    • I to mieliby robić w ramach ‘rutynowych testów infrastruktury’? Bez przesady…

    • a nie 230 przypadkiem?

    • zdarza się, w jednym z bloków “wielka płyta'” zmierzyłem 90VAC między rurą z ciepłą i zimną wodą

    • @Kamil Figiela
      A przypadkiem nie poleciałby wtedy bezpiecznik w zasilaczu chroniąc cały układ? A poza tym od kiedy podłącza się sprzęt IT do siły nie wspominając o zupełnie innej wtyczce siłowej. Jak dla mnie wtyczki zwykłe i siły różnią się na tyle, iż nie sposób się pomylić.

  10. Żadnej awarii nie było, sprzątaczka nie miała gdzie odkurzacza podpiąć i macierz wyłączyła ;)

  11. Myślę, że firma e24cloud.com powinna zainwestować trochę kasiory i podłączyć się do jakiejś chmury, żeby nie było, że zwyczajnie oszukiwali klientów mówiąc, że chmurę oferują. Bo co to za chmura co siedzi w jednej piwnicy?

  12. Nie wierze w te bajeczki, wielokrotnie miałem braki prądu, w macierzach FC, ISCSI, jbodach z kontrolerem po SAS itp Miałem różne konfiguracje Raid i dyski, po zaniku prądu twardziele psują się bardzo rzadko i są to pojedyncze przypadki wręcz marginalne. Nawet zabytki sobie z tym radzą :) Doszukiwał bym się błędów w oprogramowaniu lub sztuczek z cache. Uważam że robienie z klientów baranów jest najgorszym z możliwych wyjść.

  13. 80% komentujących taka mądra, jakby na miejscu siedziała i widziała co się dzieje.
    Wiadomo tyle, że grzebali przy awaryjnym zasilaniu i coś się im zesrało (lub sami popsuli). Wnioskowanie na poziomie szkoły podstawowej prowadzi do absurdalnie prostego, ale dla niektórych nieosiągalnego wniosku: jak miało zadziałać awaryjne zasilanie, skoro właśnie ten system uległ awarii?
    Dalej: panów niedowierzających w elektryczne uszkodzenie dysków zapraszam do oględzin dowolnego komputera po np. padzie zasilacza lub poważnym przepięciu w sieci. Parę woltów więcej to tylko najprostsza przyczyna, a spece od drutów i zasilania zapewne znajdą więcej.

    Pewnie coś popsuli podczas tych “rutynowych testów” i poszło jakieś przepięcie, bo innej opcji na fizyczne uwalenie 60% dysków nie ma.

    • Nie byłbym taki pewny co do przepięcia, z pewnością używają SSD a to dziadostwo pada nawet od zaników napięcia choć nie mam pojęcia dlaczego.

    • “[…]wiele dysków “nie przeżyło” utraty zasilania[…]”

      naprawdę trudno uwierzyć że *utrata* zasilania zabiła dyski. Ktoś tu sciemnia. W zdaniu powyżej nie ma nic o zabawach z zasilaniem awaryjnym ani o podpinaniu fazy.

    • No każdy mądry zza klawiatury a jakby przyszło się zmierzyć z taką gromadą maszyn i nagłą awarią to kupa w spodniach i tydzień nieprzespany.

    • No jest tylko jedno ‘ale’ jeżeli się podobno spełnia te warunki dla ‘Tier 4’ to czy takie coś może w ogóle mieć miejsce? Takie frywolne testy, które położyły pół serwerowni i całą chmurę?
      Szczerze współczuję beyond i oczywiście klientom, bo nie oszukujmy się za dużo tych danych to nie odzyskają IMO max 50-60% nie więcej.

    • Serwerownia Tier 4 może i spełniała, ale pan Staszek, elektryk z gazety zapomniał doczytać, a że musiał coś podłączyć to odłączył zasilanie, dużą wajchą z napisem “wyłącznik główny” ;)

    • @Dawid
      Chyba jednak SSD są jeszcze stanowczo za drogie jak na serwery. Ich maksymalna pojemność te jeszcze nie imponuje. Co najwyżej mogą ewentualnie być nośnikiem samego systemu operacyjnego serwera. Póki co zwykłe dyski wciąż są górą jeśli chodzi o pojemność i koszt 1 GB.

    • Oczywiście, że SSD występują w macierzach przypiętych do serwerów.
      Spotkałem się z instalacją, gdzie macierz składała się z dysków ssd i zwykłych.
      głównym zadaniem macierzy było zapewnienie miejsca dla bazy Oracle. Dyski SSD w grupie tworzyły bufor z dużymi szybkościami IO dla danych często używanych, kiedy zwykłe dyski robiły przestrzeń dla danych rzadziej używanych.
      W związku z przebudową zasilania serwerownia była już kilka razy wygaszana i uruchamiana od zera. Nigdy żadne dane nie zginęły. Fakt, macierz świeżutka, uruchomiona pod koniec 2011 roku.

  14. e24cloud:
    >>Sprawdziliśmy stan Twojego backupu – niestety system FreeBSD nie zapisywał prawidłowo backupów, co było jedną z przyczyn wycofania go z naszej oferty. Po analizie Twojej sytuacji z przykrością musimy stwierdzić, że Twój backup nie został prawidłowo zapisany i niestety nie ma możliwości przywrócenia danych.<<

    Primo. Proszę nie wprowadzać ludzi w błąd, odnośnie możliwości przywrócenia danych z waszego backupu. Secundo. A dla czego nie zostałem poinformowany w odpowiednim czasie, że FreeBSD "nie zapisywał prawidłowo backupów"? Posiadając taką informację, nie powierzyłbym przechowania części danych Waszemu systemowi backupów. Który de facto nie działał i – co więcej – mieliście tego świadomość

  15. TIER IV charakteryzuje się tym, że o takich sytuacjach nie może być mowy!!!!!!!!!!!!! TIER IV to redundancja na poziomie 2(n+1) – czyli info, że beyond posiada TIER IV to tylko chwyt marketingowy!!

    Przez takie DC cierpi wizerunek cloud computing!

  16. W pewnej elektrowni atomowej też kiedyś coś “poszło nie tak podczas testów”… Dziś wiemy, że zawinił czynnik ludzki. Podejrzewam, że w Beyond.pl jest podobnie. Zobaczymy.

  17. Zastanawia mnie czy macierze (podstawowa i zapasowa) jechały jednym samochodem, czy dwoma. :)

  18. Gadająć z pracownikiem, oficjalna wersja jest taka że przy rutynowych testach, Ale co z UPSami, Generatorem i drugą linią to nie może powiedzieć …

  19. Problemem nie był brak zasilania a jego nadmiar. Uzyskałem info, że awarię spowodowała zewnętrzna firma dokonująca audytu. Kolo nie zastosował się do procedur w wyniku czego serwery przez chwile dostały zasilanie z kilku źródeł, zwarcie etc. i najnormalniej w świecie częściowo poszły z dymem. Na serwerach średnio się znam ale z tego co mi tłumaczyli zrozumiałem, że usługa backupu danych z chmury jest usługą premium i dodatkowo płatną. Dlatego ci co opłacili dodatkowy backup nie mają już problemu a Ci co nie wykupili tej opcji muszą liczyć na cud, że uda się odzyskać dane z tego co zostało po dyskach.

    • Nie mogę uwierzyć, że przy takich rozbudowanych zabezpieczeniach (UPSy, generator) nie mają zabezpieczenia przez skokami napięcia. Gdyby wina było po stronie zewnętrznej firmy audytującej to już dawno by na nich zrucili całą winę, ale najwyraźniej sami też są winni.

  20. #facepalm (polish version nowadays)

    http://beyond.darkserver.it/facepalm.png

  21. Tak sobie teoretyzuję, że dane mogły zepsuć same macierze, jeśli doszło do uszkodzenia danych a nie bloków na dyskach. Czy awaria zasilania mogła uszkodzić dane na w wystarczającej ilości miejsc, żeby filesystem stał się nieodzyskiwalny (a mechanizm replikacji uszkodzenie to przeniósł na drugą macierz)? Nie wiem, nie potrafię wyrokować.

  22. abdrgsdf: Macierz dyskowa to nie jest “dowolny komputer”, a serwerownia to nie jest instalacja elektryczna z aluminium w Leningradzie.

  23. http://beyond.darkserver.it/facepalm.png #facepalm (polish version nowadays)

  24. Możliwe że generator spalinowy był niewłaściwie podłączony lub miał usterkę regulatora napięcia. W takim przypadku mógł podać zawyżone napięcie a przetwornice impulsowe nie lubią takich skoków.

  25. Taka dość mocno skondensowana ta chmura…

    • chmura smrodku :P ?

  26. Może to przez ten DDoS na kwejka, który właśnie się wtedy przenosił na Beyond(bo OVH nie wydolilo ddos’a)? :D

  27. FreeBSD ??

    O to ciekawa informacja. Wygląda na to, że tezar ma rację i pojechali ostro po taniości.
    Zarówno sprzętu (60% dysków) jak i w oprogramowaniu (freebsd do backupu).

    Nie oszukujmy, zamknięte rozwiązania enterprise są bardziej niezawodne i przewidywalne.

  28. Przestańcie w bajki wierzyć. Chmura w kontekście e24cloud czy Beyond to jest tylko i wyłącznie VPS z dwoma dodatkowymi benefitami: a) skalowalność do maksymalnie wielkości jednej maszyny fizycznej z rozliczeniem godzinowym, b) odporność na awarię node’ów (nie macierzy!), gdyż system wirtualizacji przeniesie dyski na innego node’a.

    Ot i tyle. Ktokolwiek wierzy w rozproszenie geograficzne takich usług w kontekście replikacji danych “na żywo” zwyczajnie za dużo studiował marketingowych broszur, a za mało informatyki :-).

  29. Przestańcie w bajki wierzyć. Chmura w kontekście e24cloud czy Beyond to jest tylko i wyłącznie VPS z dwoma dodatkowymi benefitami: a) skalowalność do maksymalnie wielkości jednej maszyny fizycznej z rozliczeniem godzinowym, b) odporność na awarię node’ów (nie macierzy!), gdyż system wirtualizacji przeniesie instancje na innego node’a.

    Ot i tyle. Ktokolwiek wierzy w rozproszenie geograficzne takich usług w kontekście replikacji danych “na żywo” zwyczajnie za dużo studiował marketingowych broszur, a za mało informatyki :-).

  30. Moderatorze, usuń pierwszego mojego posta, popełniłem mały błąd merytoryczny :-).

  31. Czegoś nie zrozumiałem. e24cloud.com sądzi, że uwierzę w to , że padły dwie macierze (w tym zapasowa) co sugeruje uszkodzenie ich w całości 9redundancja danych w każdej z macierzy). Parafrazując reklamę , takie rzeczy tylko w e24cloud.com

  32. Hostingowy fail roku.
    Będę się trzymał od tej formy z daleka i znajomych też ostrzegę.

  33. @watta
    bo to była chmura burzowa, walneło piorunem i polowe dysków uwaliło :D

  34. Miało być tanio i jest … Backup na tą samą macierz co dane produkcyjne – bajer za 5 zł. Było zrobić za 15 zł w ZETO i byłby spokój.

  35. 26 lat temu też miały być rutynowe testy, i jak wiadomo coś poszło nie tak. Ba, nawet jakaś chmura brała w tym udział…

  36. Zacznijmy od zasilania :)
    Ktoś napisał, że są dwie linie zasilające + agregat prądotwórczy.
    Nikt nic nie pisał o UPS’ach, ale zapewne takie urządzenie przynajmniej na jednej linii zasilającej powinno się znaleźć. Nie chce mi się wnikać w wymagania TIER IV, ale pewnie powinno być na obu liniach.
    Po UPS’ach w szafach powinno być oznaczone, która listwa zasilająca należy do której linii zasilania i odpowiednio podłączone zasilacze A – linia 1, B – linia 2. Co do tego chyba nikt nie ma wątpliwości i mając dwa zasilania tak właśnie postąpi. No właśnie, do czasu jak mu zaczyna brakować gniazd zasilania, którejś linii w szafie, a trzeba coś podłączyć. Kabel krótki, to dwa zasilacze pod jedną linię, może nikt nie zauważy ;) Jak ktoś przy serwerowniach pracuje, to wie, że nie jest to jakiś wyjątek.
    Katastrofa zaczęła się od zasilania, więc na tym się skupmy. Z któregoś posta wiemy, że trudno uzyskać wiedzę o tym, co się stało.
    Test zasilania: Wyłączamy linię 1 i zobaczymy co będzie.
    Wajcha w dół, linia 1 wyłączona. UPS bierze na siebie połowę obciążenia (zakładając, że drugie zasilacze są podłączone do linii 2). USP działa i upada, w końcu ma 7 lat i bateryjki trochę zaniemogły(zakładam, że firma hostingowa istniejąca od 7 lat zaczynała z UPS, a tego się za często nie wymienia).
    Przy prawidłowym podłączeniu wszystkich zasilaczy nic się nie dzieje, druga linia utrzymuje zasilanie drugich zasilaczy.
    Test 2 – praca z agregatu
    Do położonej linii 1 dołączany jest agregat. Agregat wstaje, rozpędza się, po kilkunastu sekundach uzyskuje pełną moc (tak, są takie), automatyka przestawia wajchę i w linii 1 jest napięcie. Dalej nic się nie dzieje.
    Test 3 – przejście z pracy UPS na pracę z agregatu
    Agregat wstaje, daje pełną moc. Automatyka wykrywa przejście napięcia (lub prądu) przez 0 i przełącza zasilanie. Tylko po co robić to między UPS a serwerami? Zapewne agregat przyłączony będzie przed UPS od strony zasilania. Jako elektryk tak bym zrobił, układ wejściowy UPS’a jest przystosowany do różnych “śmieci” w zasilaniu. O stronę serwerów się nie martwię, załatwia to UPS.

    Fakty, które warto odnotować:
    1. W wyniku testów padło zasilanie, co położyło serwerownię. Gdyby przyczyną awarii było przepięcie, jak się sugeruje, uszkodzeniu uległyby wszystkie podłączone do tego zasilania urządzenia.
    2. Cześć usług wróciła w kilka minut po padzie zasilania, co tym bardziej wskazuje na to, że zasilanie zostało wyłączone, po czym serwery się podniosły. Przy przepięciu oberwałaby większa ilość urządzeń. Serwerownia to nie tylko serwery. Mamy całą masę przełączników, routerów, Loadbalancerów, Firewali itd. To też by padło, a serwisy wstawałby tak szybko, jak szybko udałoby się organizować nowy sprzęt.
    3. Ucierpiało środowisko chmury, a tak prawdę mówiąc dane tego środowiska. Serwery na których to działa nie ma większego znaczenia w całym zajściu. Serwery padły i wstały, zaczęły przypinać przypisane im LUN’y z macierzy i ich nie znalazły.
    4. RAID 6 w zasadzie niewiele różni się od RAID 5, ma dodatkowy blok parzystości rozsiany po wszystkich dyskach w raidgrupie. Przy padzie dwóch dysków, można sobie jeszcze wyliczyć brakujące dane z tego co zostało i jest fajnie. Na dwa dni tracimy na wydajności, ale jakoś nam się to odbuduje. Pad 3 dysku i możemy zakładać raidgrupę od nowa i wgrywać dane z backupu. Informacja, z forum, że śmigłowiec nie mógł zabrać ładunku cięższego niż 200kg sugeruje, że macierz miała więcej niż 3 dyski :) Pewnie bliżej 70 lub 100. Ile Raidgrup? Jedna, dwie, 15? Tak czy inaczej, za mało.
    5. O części softwerowej nikt nic nie pisze i ciężko zgadywać co to może być i jaki miało wpływ na katastrofę. Backup na FreeBSD może rzucać cień podejrzenia, że całość działała na podobnym wynalazku, ale to wiedzą tylko admini.

    Co dziwi najbardziej:
    1. Jak się to stało, że nie było zasilania w żadnej z linii zasilających serwerownie?
    2. Jak się to stało, że padły dyski w macierzy, a nie padły żadne inne urządzenia?
    3. Dlaczego macierze pojechały do serwisu, a nie serwis do macierzy?

    Na te i inne pytania, odpowiedź w następnym odcinku ;)

    PS. Tak się rozpisałem, że mi się nie chce czytać za błędami w składni, wybaczcie :)

    • “2. Jak się to stało, że padły dyski w macierzy, a nie padły żadne inne urządzenia?”

      Właśnie:

      1. Awaria zasilania dotyka całą serwerownię (część “chmurową” i “zwykłą”)
      2. Część “zwykła” wstaje niemal chwilę po awarii (czyli zero problemów ze sprzętem)
      3. Część “churowa” ma fizycznie popsute całe stosy dysków

      Może to ktoś w miarę prosto objaśnić?

    • 1. Mam takie pytanie jakim cudem twierdzisz że przepięcie powinno spalić wszystkie urządzenia ? Tylko przy piorunie widziałem wszystko spalone łącznie z instalacją elektreyczną,
      2. Skąd wiesz na której lini zasilania poszło przepięcie?
      3. Może inne urządzenia miały np. UPS na lini na której poszło przepięcie ?
      4. przepięcie jest jedynym sensownym wytłumaczeniem przy tak dużej liczbie uszkodzonych dysków,

    • “3. Dlaczego macierze pojechały do serwisu, a nie serwis do macierzy?”

      To akurat jest proste do wytłumaczenia. Macierze nie pojechały do serwisu, a do firmy OnTrack specjalizującej się w odzyskiwaniu danych. Firma ta pracuje stacjonarnie, bo tylko u siebie ma komplet sprzętu, części zapasowych itd.

    • Przepięcie nie tłumaczy niczego co związane z dyskami. Jedyna informacja jaka jest, mówi o uszkodzeniu 60% dysków w macierzy.

      Przy RAID 6 wystarczą 3 padnięte dyski i pozostałe 70 z grupy można zaorać i stawiać wszystko od nowa. Informacja o 60% mogła być podana dla uspokojenia klientów. Oto mamy problem, ale tylko 60% dysków jest uszkodzona, czyli odzyskamy 40% danych. Klient patrzy i myśli, że to jego dane są w tych 40%.
      Przy uszkodzeniu więcej niż 3 dysków z RAID 6 wszystkie pozostałe można traktować jako uszkodzone, ponieważ dane na dyskach sprawnych są bezużyteczne.

      Jeszcze raz chcę podkreślić, że wszystkie serwisy poza chmurą wstały po kilku minutach, czyli po czasie niezbędnym do uruchomienia serwerów, przełączników itd. Przepięcie zabijające dyski zabiłoby kilkanaście innych urządzeń (nie mówię że wszystkie). Powrót wszystkich serwisów kilka minut po padzie może przemawiać za tym, że przepięcia nie było.

      Jak ktoś już wspominał, często jest tak, że starsze urządzenia w serwerowniach, działające od kilku lat bez przerwy, działają “siłą rozpędu”. Położone, nie wstają, albo wstają z taką ilością błędów, że i tak zaraz się kładą.

      Backup na tą samą macierz, jest ogólnie poza jakimkolwiek komentarzem. Backup na drugą (fizycznie) macierz i dodatkowo na taśmy powinien być standardem przy przechowywaniu nie swoich danych. Pozwala na szybkie przywrócenie danych z macierzy backupowej, a w przypadku awarii macierzy backup wolniejsze przywracanie z taśmy. No ale do tego trzeba zainwestować.

      Ogólnie odnoszę wrażenie, że e24cloud.com został wdrożony jako eksperyment na polskim rynku hostingowym. O temacie chmury coraz głośniej, więc weźmy jakąś starą macierz, kilka serwerów i postawmy na tym środowisko chmurowe. Zobaczymy, czy znajdą się klienci. Jak się klientów znajdzie odpowiednia ilość, to pomyślimy nad inwestycją w sprzęt.

      Drodzy forumowicze, nie ma co się oszukiwać, każdy przedsiębiorca oszczędza gdzie się da, najczęściej na infrastrukturze.
      Po co mi przełącznik za 2000zł, jak mogę mieć prawie taki sam za 250zł.
      Po co mi dwa serwery, jeden da radę być intranetem, serwerem dla księgowości i jeszcze serwerem www ze sklepem internetowym
      Po co mi dwie macierze, podzielę jedną na dwa LUNy, jeden będzie produkcyjny, drugi backup, a taśmy to nie, bo to trzeba zmieniać i jakieś drogie w przeliczeniu na GB/zł.

  37. Ciekawe jakby wyglądały statystyki akcji “Przeciw ACTA” podczas takiej awarii “super” chmury ;)

  38. Tutaj żałość…:
    http://woblink.com/

  39. Co to za serwerownia, że nie ma urządzeń TVSS czy SPD. Na UPS-ach też chyba ktoś postanowił zaoszczędzić, do zastosowań krytycznych wykorzystuje się “double conversion” UPS, a takie zasilają serwery bezpośrednio z baterii, i wszelkie odchyły napięcia są odcinane pred baterią.
    Kolejny fail to RAID 6, obecnie nikt kto ceni sobie swoje dane nie korzysta z jakiegokolwiek RAID-u z parzystością, dyski sa tak tanie że w zastosowania krytycznych wykorzystuje się wyłącznie RAID 10. Kiedyś byłem świadkiem odbudowy takiej macierzy, RAID 5, oszczowany czas odbudowy wachał się w granicy miesiąca, odbudowa RAID 6 trwa dłużej. A przy macierzy 12TB i większej mamy 100% na trafienie na uszkodzony sektor w pozostałych dyskach i cała macierz jest utracona.

    • Kolego dyski twarde mają SMART, kontrolery RAID są bardzo wyczulone na sprawność dysku, jężeli jakiś parametr SMART jest poza tolerancją dysk jest autoamtycznie ze statusem uszkodzony trafienie bad sectora przy takim rozwiązaniu jest raczej trudne, czas odtwarzania RAIDa zależy od kontrolera.

    • NIE WOLNO ! ! !
      Stosować produkcyjnie macierzy opartych o raid5 raid6 z dyskami o rozmiarach > 1.5 TB.

      Sam przyznam, że nie wiedziałem tego do nie dawna, a google z kimśtam w 2007 (5lat!) temu udowodniło to na jakiejś koferencji naukowej.

      To teraz przyznać się, kto ma raid5 z takimi dyskami :)

      What is UBE? All hard drives have unrecoverable bit error ratings (UBER) which indicate how many bits a drive can likely transfer before encountering an UBE. Normally a drive can cope with bit errors and life moves on as usual. But when a drive encounters an unrecoverable bit error, bad things happen. SATA desktop drives have a UBER of 1 in 10^14 or 12.5TB. A 2TB drive equals roughly 1/6 of this UBER. A 5 drive RAID set would equal 5/6 of the UBER. Should a single drive fail in this RAID configuration there is an 83% probability that the RAID set will experience an UBE during RAID rebuild. Although these drives are not the standard in higher-end drive arrays, some are making their way into the datacenter in an effort to get prices lower.

      Most array vendors will push “cheap and deep” near-line SATA or SAS drives with a UBER of 1 in 10^15 or 125TB. This increased UBER would mean that our 5 drive RAID set mentioned above would have an 8.3% probability of experiencing an UBE during rebuild thus preventing successful RAID data recovery. Even though the relative risk is lower, imagine telling your management (or regulator) that the corporate data has a 91.7% chance of surviving a single drive failure on that new, expensive RAID array you just convinced them to buy? Probably wouldn’t have the effect you were looking for (unless, of course, you were wanting another job and then it might have just the effect you were looking for!)

      What is the answer? For one thing, quit thinking that all hard drives are equal and the only thing that matters is the cost. They aren’t and it isn’t. Make sure the drives your vendor is quoting meet the criticality of data they will be storing. If you insist on using desktop class drives use RAID 10 instead of RAID 5 (although this added capacity overhead may negate the cost savings of the lower-end drives). Second, make sure your storage vendor subscribes to the ANSI T10 Data Integrity Field (DIF). DIF is a standard that provides end-to-end data integrity.

  40. A co wy z tym backupem na freebsd? To nie system backupowy byl na freebsd, tylko maszyna uzytkownika. Ja tam czekam na jakies case study, z dokladna historia jak to sie stalo, bo to wrecz historia rodem z X-files

  41. Problem jest taki, ze Beyond nadwereza zaufanie nie tylko do siebie (pomijam brednie o Tier4, ktory w Polsce nie wystepuje z natury rzeczy-vide zasilanie od 2 sieci dystrybucyjnych), ale także do innych porządnych serwerowni polskich takich jak Datahouse.pl. (tam tez byly krotkotrwale problemy, lecz one przeważnie były spowodowane DDOSami, ale i tak dostalismy rekompensate). Nie tracmy wiary w polskich inżynierów przez ściemy tych nieudolnych z browaru. Pewnie to piwo zamulilo ich.

  42. Z jednej strony podzielam opinie ze dali ciała z drugiej, (jako że z wykształcenia jestem też elektrykiem) wiem ze, jeśli w tym, co napisali jest przynajmniej 60% to nie ważne, jakie mili by zabezpieczenia to wynik był by ten sam.

    Nikt z was nie odniósł się do pkt. b w wytłumaczenia e24cloud.com z ostatniej aktualizacji. w gwoli wyjaśnienia to SZR to system załączania rezerwy – automatyka, która w ciągu setnych sekundy ma przełączyć zasilanie na jedna z pozostałych linia zasilających podpiętych to systemu wewnętrznego tj., jeśli macie 2 linie i jedna padnie do druga ma się załączyć i w tym momencie, jako trzecia wchodzi generatory, które w tym momencie powinny się załączyć i zacząć chodzić, jako trzecia linia zasilająca – niestety automatyka nie zadziałała a UPS nie stanowią w takich systemach zasalania awaryjnego jak większość z wac ma a jako system chwilowego podtrzymania zasilania na czas zadziałania SZR. Proszę was system baterii takiego zasilania bateryjnego kosztowałby więcej i zajmowałby więcej jak ich cala serwerownia.

    Nawet, jeśli UPS miały by podtrzymać macierze to one tez wymagają czasu na to by się wyłączyć (chyba ze – taki żarcik – baterie w kontrolerach RAID się wyczerpały albo ich nie był :P ktoś chciał na bateryjce za 20zł zaoszczędzić :P)
    Co na 100% możemy wyczytać to to ze na pewno 2 backup i macierz administracyjna miały odrębne zasilanie awaryjne, które w momencie zaniku zasilania głównego wymusiły wyłączenie macierzy to, co nie było w macierzy podstawowej i 1 backupie.

    Co do freebsd … Korzystam od bardzo dawna i nigdy, ale to nigdy nie tworzył mi bladych backupów i tu na 100% zawinił czynnik ludzki – ludzie się wycofują z *bsd, bo specjalistów jest mało i są drodzy nie to, co z linuxem.
    Czynnik ludzki był tu największym powodem awarii:
    1. Przed przystąpieniem to testu systemu awaryjnego nie sprawdzono właściwego działania systemu SZR
    2. Nie sprawdzono stanu baterii akumulatorów awaryjnych, co 3-5 lat wymagana jest wymiana – a sprawdzić ich wytrzymałość można tylko pod obciążeniem wiec zwykle mierzenie napięcia baterii to nieporozumienie, dlatego nie wytrzymały 25 min a co dopiero mówić o 15 min
    3. Brak 3 nitki zasilania – dwie na clud tej wielkości to małe nieporozumienie
    4. Nie włączenie sytemu generatorów na czas testu – może akurat SZR by zadziałał jak by były włączone
    5. Człowiek, który nie przestrzegał procedur i nie przewidział awarii, które są rzeczami podstawowymi a nie jakimiś anomaliami

    Polecam by e24cloud zrewidowali swoje procedury i jeszcze raz skontrolowało ludzi, którzy to obsługują – a w przyszłości do projektowania infrastruktury sieci inteligentnej i zasilającej zatrudnili profesjonalistów.

    A tak, jeśli chodzi o zabezpieczenia to powiem ze w Polsce może z 15 lat temu w jednej z 3 najnowocześniejszych elektrowni w Polsce mimo wielu zabezpieczeń – najnowszej generacji – które powinny zadziałać przy awarii nie zadziałały i wał generatora wyskoczył przez obudowę grubości prawie 1m (stal wysokiej jakości 50cm i pręty miedziane), przebił dach i poleciał na odległość prawie 5 kilometrów w pole – a powodem było, że jedna osoba złe przekręciła przełącznik – po tym incydencie zrewidowano procedury i zabezpieczenia.

    • Hej,

      Czy to nie była elektrownia opalana gazem, gdzie rozdrzany czujnik temperatury, ponownie podpalił gaz w komorze spalania (po wyłączeniu pieca) :)

      Otrzymałem komentarz, że przyczyną awarii było przejście na UPS, start agregatu, i przejście na zwykłe zasilanie, bez podładowania UPS. Potem gdy znów coś padło UPS był juz rozładowany i nie utrzymał całości do czasu załączenia agregatu.

      Oczywiście jeszcze pytanie na ile mocny mieli UPS.
      Możliwe, że był obliczony na mniejsze obciążenie, a serwerów z czasem przybywa….

  43. do poprawki: “domysłami *wszeliej* maści”

  44. Macie te swoje bezpieczne chmury.
    Jak podstawy sa do d$%&%^ to i chmura nie pomorze, zenada i wstyd.

  45. pomoże* oh.

  46. Czytam sobie komentarze i czasem zastanawiam się, czy ci komentujący widzieli choć raz serwerownię. Pewne rzeczy mogą się zdarzyć – takie teoretycznie nieprzewidywalne. Mnie awaria bardzo pomogła marketingowo.
    Widziałem już wiele przerw w dostawie prądu, która trwała parę sekund – ale zrestartowany serwer, który jest mocno obciążony po podniesieniu np. ma uszkodzone bazy mySQL – to jest powszechne. Czasem (z tym też się spotkałem) tych baz nie da się naprawić w prosty sposób.
    Inna sprawa, że miałem u siebie raid 10 na wypasionym kontrolerze 3ware/LSI i uszkodzenie jednego dysku zablokowało całą macierze – naprawdę – tak się da … choć w pierwszej chwili byłoby to niby niemożliwe – bardzo pomógł support LSI, ale jednak przygotowanie przez nich skryptów do odzyskania dostępu do macierzy trwało bardzo długo (liczone w godzinach, ale jak serwer nie działa, to wydaje się, jakby to były doby). Oczywiście wtedy się odpala całość z backupu na nowym sprzęcie a potem ew. dogrywa dane odzyskane – ale to wszystko trwa …
    Zatem krótki restart zasilania – może uszkodzić dużo … Oczywiście teoretycznie nie powinno do niego dojść, niemniej znowu … widziałem już np. restart ups-a z powodu … przegrzania – tak poinformował ups i się zrestartował. Ups był markowy, potężny onlinowy 10kW potworek. Zatem czasami zdarzają się rzeczy nieprzewidywalne … :-)

  47. widze, ze nie-bezpiecznik już zaczął kasować komentarze. rozumiem, że krytyka sponsora poprzedniego pochwalnego artykułu boli, ale nie kasujcie krytycznych komentarzy.

    • Jaki niby komentarz został skasowany?

  48. […] względu na awarię e24cloud, która obiła się mocny echem w polskim Internecie i o której też pisaliśmy na Niebezpieczniku. “Chmura nie jest ani dobrem ani złem, to po prostu narzędzie którym […]

  49. […] utraconych danych klientów chmury e24cloud.com zostało już zakończone. Teraz przyszedł czas na dokładną analizę i naukę na błędach. […]

  50. Znowu fail – poniedziałku 05.12.12

  51. w 2012 mieli awarie macierzy, w 2013 mieli awarie macierzy i teraz też mają awarię ….. coś jest nie tak…

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: