Włamanie do 2be.pl

[theONE 526]

Sorry ale jako hosting to raczej będą tylko jako case study. Jak ktoś bardziej nagłośni to po 4-5 takim padzie u klientów wzrośnie świadomość.

[lucaspl 18]

Wygrają tylko home i nazwa na tym - będzie kolejny argument, aby wybierać klasyki. Zresztą, już taki argument słyszałem już od 2 moich znajomych którzy szukali w ciągu ostatnich dni hostingu.

[przemon 35]

 

Dlatego ja osobiście nigdy nie byłem i nie będę zwolennikiem rozwiązań b. dużych macierzy w hostingu współdzielonym, z których korzysta kilka/naście serwerów, chociaż diler IBMa nas na na dużą macierz namawia od lat Nawet jak mamy dwie to i tak jest jakieś ryzyko dużego padu (vide dawny pad w beyond, czy w oktawave). Max 2-3TB per maszyna i wystarczy. Średnie wykorzystanie u mnie to 1,5TB per serwer, disaster recovery po gigabicie to max 4h przerzucania. Pozatym jak padnie, to nie działa 2% klientów, a nie 100%. Polecam

 

BTW

Kiedy Oktawave zaliczyło pad storage?

[Gość]

BTW

Kiedy Oktawave zaliczyło pad storage?

Oj zaliczyło - nie wiem kiedy to było ale przynajmniej przez kilka/naście godzin były duże problemy z działaniem - oczywiście nie stracili żadnych danych ale problem był jak pamiętam dość poważny. Jest tu pewnie przedstawiciel Oktawave to się wypowie. Było to gdzieś ze dwa lata temu może.

pozdr.

[Gość patrys]

W Oktawave to nie był problem z łączem ?

E24cloud faktycznie miał problem z tą macierzą raid50, no ale odzyskali dane ( nie wiem czy w całości ).

 

[Gość Adam Szendzielorz]

W Oktawave to nie był problem z łączem ?

Z łączem też mieli różne problemy swego czasu (ataki ddos).

 

E24cloud faktycznie miał problem z tą macierzą raid50, no ale odzyskali dane ( nie wiem czy w całości ).

Chyba w całości. Oktawave na 100% miało poważną awarię storagu - pamiętam to bardzo dokładnie. Tym niemniej - od tamtego czasu nie słyszałem o większych problemach.

[AdminX 1]

 

Dokładnie się zgadzam! To samo mieliśmy na strukturze ghost po 4 latach macierz się wysypała i gdyby nie to że zauważyliśmy problem wcześniej udało nam się migrować dość płynnie pomimo że sypało błędami. Jak sobie pomyślę co by było gdyby to padło z godziny na godzinę to ogólnie patrząc po prostu masakra. Nikt mi nie powie że to takie proste jest ,przywracanie danych powiązanych z tysiącami witryn, kontaktów, poczty, baz danych i prywatnych ustawień. Wszystko pięknie zawsze wygląda a jak sytuacja dotyczy bezpośrednio twoich klientów to dostajesz kopa i nagle okazuje się że te wszystkie przygotowania, procedury są o kant dupy. Obecnie maksymalna macierz używana w zestawie dla hostingu to 8TB a i to rozbijemy na pojedyncze serwery w oparciu o SSD 4 x 1TB. Szkoda po prostu nerwów, a druga sprawa należymy do grupy malutkich robiących po prostu swoje w oparciu o zależność - mało stresu = zadowolony klient na ile jest to możliwe. Pomyłki ,błędy zawsze się zdarzają ale w tym przypadku problem dotyczy nie sprzętu niestety.

Są takie projekty, że macierz jest konieczna. Znam sajt, gdzie są 2 macierze (IBMa zresztą, stare FastT (RIP) ) które chodzą już ponad 9 lat. Nigdy nie było dużych problemów z nimi, chociaż niektóre elementy były wymieniane, bo nie przechodziły self testu. A sajt był/jest momentami tak obciążony, że wysycały się w w szczytowych godzinach łącza do netu, chociaż były najszybsze dostępne w danym czasie, co zresztą było odnotowywane w mediach (nie w Polsce). Nie wyobrażam sobie padu takiej macierzy (na wszelki wypadek były potem 2 i replikacja synchroniczna, awaryjne centrum bez ruchu produkcyjnego) ale po takim czasie mogę powiedzieć, że taki pad całości nie miał i nigdy nie będzie mieć miejsca, o ile zna się "fochy" urządzeń. Ale każdy może mieć swoje zdanie. Za to raz pad głupiego dysku prawie położył sajt- odbudowa R10, ale nie o tym miałem pisać. Argument że padnie macierz zatem do mnie nie przemawia, natomiast argument że się nie opłaca - dużo bardziej.

 

 

U mnie np. mamy specjalny algorytm - każdy serwer (wirtualny) jest klasyfikowany punktowo za zużycie CPU, I/O i fizyczna pojemność i według tego system proponuje ew. migracje użytkowników między maszynami, tak żeby zoptymalizować zużycie pojemności dyskowej i jednocześnie rozłożyć obciążenie równo pomiędzy wszystkie dostępne maszyny. Na większości "ustabilizowanych" już serwerów mam zajętość dysków na poziomie 90% (nigdy jeszcze mi się nic nie zapchało), a zużycie CPU dążymy żeby było średnio na poziomie <50%.

 

 

 

Fajny pomysł na optymalizację, ale przenoszenie klienta pomiędzy serwerami wymaga zmiany mu IP? Czy jak to robicie?

[przemon 35]

Z łączem też mieli różne problemy swego czasu (ataki ddos).

 

 

Chyba w całości. Oktawave na 100% miało poważną awarię storagu - pamiętam to bardzo dokładnie. Tym niemniej - od tamtego czasu nie słyszałem o większych problemach.

 

 

Korzystam z Oktawave i największy down ze storage miało 4.12.2013r 15:09 - 16:54 i 18:07-19:45 to było tier-1 w PL-001 - tyle mi max pokazuje w statach i porównuję to do ticketów które im wysłałem.

 

No chyba że się wysypało w PL-002 lub PL-003 - tam instancji nie miałem, więc nie wiem.

 

W E24cloud leżało bodajże 8 dni.

Tutaj chyba 10 dzień leci.

 

Nie faworyzuję Oktawave, ale nie wrzucaj wszystkich do jednego worka bo awarię trwającą 3,5h w sumie ciężko porównać do kilkudniowych padów.

[Gość Adam Szendzielorz]

Fajny pomysł na optymalizację, ale przenoszenie klienta pomiędzy serwerami wymaga zmiany mu IP? Czy jak to robicie?

Jeżeli serwer nie ma własnego IP to oczywiście trzeba zmienić - ale i tak jest to prawie niewidoczne dla klienta (maksimum to 5 minut jak ktoś ma naprawdę b. dużo plików na ich synchronizację). Jako, że takich migracji wykonujemy maksymalnie kilkanaście (no, może kilkadziesiąt) w ciągu miesiąca i robimy to zawsze w nocy (od 1.00) to nie stanowi to żadnego większego problemu dla klientów - jak dotąd nikt chyba nawet nie zauważył takowej Sama migracja to m.in. obniżenie ~2 dni wcześniej TTL w DNSach i przesłanie kopii danych na nowy serwer, później już sama zmiana IP w DNS, uruchomienie reverse-proxy na czas zmiany IP / propagacji DNS, szybka synchronizacja plików, szybkie odświeżenie ustawień pocztowych na serwerach pocztowych, replikacja baz mysql na drugi serwer z szybkim przełączeniem na nowy po migracji. Ogólnie dość skomplikowany ale zautomatyzowany proces - migracja użytkownika ~500 tys plików i ~50GB danych trwa maksymalnie 5 minut

 

Na "starych" maszynach zwykle dość powoli przyrasta ilość danych i średnio wystarczy migrować jeden, dwa serwery wirtualne w ciągu miesiąca na inną maszynę. Nie powiem - sam proces tworzenia tego algorytmu był dość skomplikowany ale dzięki niemu mamy obciążenie CPU i I/O oraz zajętość dysków pod pełną kontrolą i zoptymalizowane

Nie faworyzuję Oktawave, ale nie wrzucaj wszystkich do jednego worka bo awarię trwającą 3,5h w sumie ciężko porównać do kilkudniowych padów.

Skoro wszystko było zduplikowane, podzielone na dwie niezależne szafy etc - to taki pad powinien trwać maksymalnie minutę Może po prostu mieli dużo szczęścia i wszystko udało się rozwiązać w 3,5h, może ta awaria nie wyrządziła aż takich szkód jak ta w beyond - nie wiem - ale awaria systemu storage była i to nie podlega wątpliwości. Nie wrzucam nikogo do jednego worka, troche offtopicznie w tym wątku zaczęliśmy dyskutować o macierzach w zastosowaniach na hostingu współdzielonym.

[HaPe 242]

Progreso, cały Extranet oparty jest o Perl, a frontend webowy to tylko nakładka komunikująca się z backendem?

[tgx 575]

zaczęło się od włamu na be2 a kończy się na opisie procesów migracji na progreso bo dysk się im kończy

 

 

[Gość Adam Szendzielorz]

Progreso, cały Extranet oparty jest o Perl, a frontend webowy to tylko nakładka komunikująca się z backendem?

Tak - komunikacja z jądrem realizowana via json - normalnie via tcp. Ale w sumie - to rzeczywiście jest już offtopic

[Gość]

Wszystko wszystkim, ale... gdy nad serwerami utrzymującymi więcej niż tysiąc stron + całą infrastrukturą domenową itd dość sporego przedsiębiorstwa nie czuwa żaden administrator stale, nie dogląda, nie sprawdza... to nawet ciężko to nazwać gówniarską nieodpowiedzialnością.

 

Można dyskutować o tym było tam potrzebne mniej czy więcej osób, ale jak dobrze pamiętam 2be słynęło z dość wysokich cen, stąd dziwi mnie cała ta sytuacja. Ktoś się trochę przeliczył.

[AdminX 1]

Wszystko wszystkim, ale... gdy nad serwerami utrzymującymi więcej niż tysiąc stron + całą infrastrukturą domenową itd dość sporego przedsiębiorstwa nie czuwa żaden administrator stale, nie dogląda, nie sprawdza... to nawet ciężko to nazwać gówniarską nieodpowiedzialnością.

 

if (cstring.strcomp(twojeMiasto,'Kraków')){

int stapaniePoCienkimLodzie=1;

int GlupioMi=1;

}

 

 

To może być taka krakowska szkoła prowadzenia biznesu. Znam przynajmniej kilka firm krakowskich mających oddziały w stolicy, które mają podobny modus operandi. Choć, przyznam, ten przypadek mnie jeszcze zadziwił, choć wydawało mi się że już widziałem wiele ze strony Krakusów...

[Pan Kot 1535]

Wszystko wszystkim, ale... gdy nad serwerami utrzymującymi więcej niż tysiąc stron + całą infrastrukturą domenową itd dość sporego przedsiębiorstwa nie czuwa żaden administrator stale, nie dogląda, nie sprawdza... to nawet ciężko to nazwać gówniarską nieodpowiedzialnością.

 

Można dyskutować o tym było tam potrzebne mniej czy więcej osób, ale jak dobrze pamiętam 2be słynęło z dość wysokich cen, stąd dziwi mnie cała ta sytuacja. Ktoś się trochę przeliczył.

 

Dokładnie tak. Ktoś stwierdził, że jak działa dobrze to po co ruszać, decyzje o zatrudnieniu dodatkowych osób podejmuje się najczęściej już wtedy kiedy jest właśnie za późno - ta awaria nie wynika nawet ze złośliwości rzeczy martwych, ale z samego faktu nieodpowiedzialności, bo gdyby zwolnionemu administratorowi zrevokowano klucze i resztę dostępów to nie mógłby w nocy po kryjomu zrobić rm -rf / (czy inny wariant z dd).

 

Jeśli ktoś nad tym by czuwał, to raczej nie doszłoby do takiej sytuacji.

[Gość]

dodatkowych osób

Stary, żeby mówić o dodatkowych, muszą być jakiekolwiek...

 

 

if (cstring.strcomp(twojeMiasto,'Kraków')){

int stapaniePoCienkimLodzie=1;

int GlupioMi=1;

}

 

 

To może być taka krakowska szkoła prowadzenia biznesu. Znam przynajmniej kilka firm krakowskich mających oddziały w stolicy, które mają podobny modus operandi. Choć, przyznam, ten przypadek mnie jeszcze zadziwił, choć wydawało mi się że już widziałem wiele ze strony Krakusów...

 

Mnie dziwi, że firma z 12letnim doświadczeniem, gdzie właściciel ma także agencję PR, pozwala sobie na zagrywki znane z wakacyjnych hostingów prowadzonych przez gimnazjalistów.

Edytowano Marzec 8, 2016 przez Gość (zobacz historię edycji)

[SecurityHost 17]

FB profil właściciela:

Słuchajcie szukam kogoś z firmy lub kto zna kogoś w gdyńskiej firmie HEKKO. Być może to rozwiązanie naszych problemów serwerowych.
ps. Udostępniajcie proszę.

Ps. W trakcie dnia opiszę gdzie teraz jesteśmy, część usług ruszyła.

[Oktawave 7]

 

 

Korzystam z Oktawave i największy down ze storage miało 4.12.2013r 15:09 - 16:54 i 18:07-19:45 to było tier-1 w PL-001 - tyle mi max pokazuje w statach i porównuję to do ticketów które im wysłałem.

 

No chyba że się wysypało w PL-002 lub PL-003 - tam instancji nie miałem, więc nie wiem.

 

W E24cloud leżało bodajże 8 dni.

Tutaj chyba 10 dzień leci.

 

Nie faworyzuję Oktawave, ale nie wrzucaj wszystkich do jednego worka bo awarię trwającą 3,5h w sumie ciężko porównać do kilkudniowych padów.

 

Hej,

 

wszędzie zdarzają się awarie, jednak w Oktawave jesteśmy na to przygotowani.

 

Naszym klientom dajemy gwarancję dostępności na poziomie 99,96% miesięcznie, co oznacza, że nasze usługi mogą być niedostępne przez około 17 minut w miesiącu.

 

Tutaj możecie poczytać więcej, jak dbamy o bezpieczeństwo naszej infrastruktury http://www.spidersweb.pl/2014/07/zabezpieczenia-danych-w-chmurze.html

[Mekon 6]

Słuchajcie szukam kogoś z firmy lub kto zna kogoś w gdyńskiej firmie HEKKO.

 

Ciekaw jestem na jakiej zasadzie chcą się zgłosić do Hekko, czyżby dzwonili do różnych adminów firm hostingowych gotowych poświęcić trochę czasu przy sprzątaniu ich spraw?

Bo jak chcą się skontaktować z firmą to telefony odbierają natychmiast, na maile również odpisują szybko.

 

[Bartosz Z 236]

czyżby dzwonili do różnych adminów firm hostingowych gotowych poświęcić trochę czasu przy sprzątaniu ich spraw?

 

Mają już skład, który ogarnia resztki po incydencie. Edytowano Marzec 8, 2016 przez Bartosz Z (zobacz historię edycji)

[Maciej Kuźniar 1]

Skoro wszystko było zduplikowane, podzielone na dwie niezależne szafy etc - to taki pad powinien trwać maksymalnie minutę Może po prostu mieli dużo szczęścia i wszystko udało się rozwiązać w 3,5h, może ta awaria nie wyrządziła aż takich szkód jak ta w beyond - nie wiem - ale awaria systemu storage była i to nie podlega wątpliwości. Nie wrzucam nikogo do jednego worka, troche offtopicznie w tym wątku zaczęliśmy dyskutować o macierzach w zastosowaniach na hostingu współdzielonym.

 

Cześć,

 

No dobrze, skoro już zostaliśmy przywołani do tablicy (Oktawave) to spróbuję wyjaśnić. Faktycznie prawdą jest że były przerwy w dostępie do storage'u - głównie końcówka 2013 i część 2014 ale one nie nigdy nie były spowodowane padem storage'u a zawsze zanikiem komunikacji ze storagem. Nie wiem ile osób pamięta, ale wykorzystujemy (do tej pory) stosunkowo egzotyczną technologię w warstwie sieci dostępowej do danych - tj. konkretnie Infiniband i to głównie w tym obszarze były problemy. A to problem z driverami, a to niestabilne HCA albo pad któregoś i tym podobne. Był to poniekąd efekt uboczny dążenia do maksymalnej wydajności, przy ograniczonym wsparciu vendorów sprzętu/softu.

 

Nigdy natomiast nie było u nas awarii storage'u której efektem była by utrata jakichkolwiek danych czy też konieczność odzyskiwania z backupu. Natomiast faktycznie mogły mieć miejsce zdarzenia w których po utracie komunikacji IO z dyskami, poszczególne VM'ki musiały zostać zrestartowane i wykonać pełne skanowanie dysków - co czasami niestety trwało i było wyjątkowo irytujące dla klientów (im większy dysk tym bardziej)

 

Tak czy owak, jasne jest że takie zdarzenia nie powinny mieć miejsca z drugiej strony była to (przynajmniej dla nas) ogromna innowacja która już obecnie po ustabilizowaniu pozwala spokojnie uzyskiwać w Oktawave prędkości zapisu/odczytu danych dochodzące (czy nawet przekraczające 3GB/s ) dla wolumenów dyskowych podłączanych do OCI (vm'ek) na poziomie min. Tier-2 w górę.

 

Ktoś zna ofertę hostera/chmury który jest w stanie dostarczyć takie parametry per vm - ręką w góre :-)

 

P.S nie mówię że takie prędkości są niezbędne, ale dzięki takim wysiłkom świat jednak idzie do przodu

[chmuri 89]

@off top:

Dyskusja trochę zmieniła tor. Bardzo proszę aby osoby które chcą wydać miliony na infrastrukturę aby to zrobiły skoro twierdzą że to jest idealne rozwiązanie z de-duplikacją replikacją HBA i innymi technologiami które praktycznie w 100% gwarantują bezpieczeństwo w każdym przypadku, nawet usunięcie przez pokłóconego administratora danych.

 

Fakt że każdy ma jakieś potknięcia jest nie nieunikniony bo daną firmę czy to jest 2be czy to Oktawave czy nawet Beyond albo jakakolwiek inna. Klient nie poznaje się na firmie jak wszystko działa bo jedynie co widzi to banery i informacje która służy do identyfikacji jego zakupionej usługi, czyli praktycznie klika i nie wie za co płaci bo widzi tylko informację która jest zapewnieniem. Firma naprawdę pokazuje jak jest naprawdę w momentach kryzysowych bo nie oszukujmy się każdy z nas miał pady i zawsze klienci narzekali na up-time odzyskiwanie danych etc. Kwestia tylko zachowania i "ogarnięcia" tematu w sposób który dana osoba poszkodowana będzie w stanie zrozumieć.

 

Więc bardzo proszę jeśli ktoś twierdzi że dana technologia jest lepsza to proszę zakupić za swoje pieniądze otworzyć biznes i w przypadku padu powiedzieć "a nie mówiłem". Bo każdy chce mieć dane replikowanie na macierzach w innych DC ale szukajcie klienta który za to zapłaci.

 

@temat posta

 

Fakt że zachowanie osoby która bierze ta te usługi pieniądze jest bardzo wątpliwe może wskazywać tylko na źle przemyślaną strategię w postaci zarządzania infrastrukturą usług które po prostu stały się nie dostępne dla klientów i osób zarządzających.

[AdminX 1]

W 2be oddali już bazy danych. Nawet ssla już mają bez Drowna, widać udało się Ubuntu zaktualizować.

 

 

@off top:

Dyskusja trochę zmieniła tor. Bardzo proszę aby osoby które chcą wydać miliony na infrastrukturę aby to zrobiły skoro twierdzą że to jest idealne rozwiązanie z de-duplikacją replikacją HBA i innymi technologiami które praktycznie w 100% gwarantują bezpieczeństwo w każdym przypadku, nawet usunięcie przez pokłóconego administratora danych.

 

 

 

Fakt że każdy ma jakieś potknięcia jest nie nieunikniony bo daną firmę czy to jest 2be czy to Oktawave czy nawet Beyond albo jakakolwiek inna. Klient nie poznaje się na firmie jak wszystko działa bo jedynie co widzi to banery i informacje która służy do identyfikacji jego zakupionej usługi, czyli praktycznie klika i nie wie za co płaci bo widzi tylko informację która jest zapewnieniem. Firma naprawdę pokazuje jak jest naprawdę w momentach kryzysowych bo nie oszukujmy się każdy z nas miał pady i zawsze klienci narzekali na up-time odzyskiwanie danych etc. Kwestia tylko zachowania i "ogarnięcia" tematu w sposób który dana osoba poszkodowana będzie w stanie zrozumieć.

 

Więc bardzo proszę jeśli ktoś twierdzi że dana technologia jest lepsza to proszę zakupić za swoje pieniądze otworzyć biznes i w przypadku padu powiedzieć "a nie mówiłem". Bo każdy chce mieć dane replikowanie na macierzach w innych DC ale szukajcie klienta który za to zapłaci.

 

 

@temat posta

 

Fakt że zachowanie osoby która bierze ta te usługi pieniądze jest bardzo wątpliwe może wskazywać tylko na źle przemyślaną strategię w postaci zarządzania infrastrukturą usług które po prostu stały się nie dostępne dla klientów i osób zarządzających.

 

Nikt tu nie mówił o bezpieczeństwie macierzy, że jest bezpieczniejsza jak ktoś będzie chciał zrobić kuku. Na moje pytanie o kasowaniu systemu plików - ile może zająć im odzyskiwanie - nikt nie odpowiedział.

 

Co do uwag o milionach szekli, DC itd - kwestia skali. Dla jednego klienta się nie opłaca tego kupować, to oczywiste.

 

/SIGNOFF

 

 

 

 

 

 

 

 

[Bartosz Z 236]

Na moje pytanie o kasowaniu systemu plików - ile może zająć im odzyskiwanie - nikt nie odpowiedział.

 

Jak odzyskać dane z partycji nadpisanych z /dev/urandom?

[theONE 526]

Na macierzy przynajmniej to się szybko wykona