Skocz do zawartości

Polecane posty

 

Duże macierze podłączane do kilku serwerów mają podpięcie po szkiełku FCoE - dzisiaj standard 16Gbit. Często w czasie pracy dane z i do macierzy lecą z szybkością wire speed, bo wolumin jest rozłożony np. na 20 dysków i wszystkie pracują. Do tego jest deduplikacja, która działa cuda w takich środowiskach jak hostingi - ile masz tam kopii Wordprssów np.?

 

Enterprisowe rozwiązania dla usług za 200 PLN rok ?

Chyba nie masz pojęcia jakie są realia na hostingu ...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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 ;)

Brawo! doskonałe podejście ,które również podzielam. Na pozostałe posty się nie wypowiadam bo to nie moja sprawa. Przykre ,że wypowiadają się osoby które same nie prowadzą usług hostingowych.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość nrm

 

To jest problem dla całej branży i zaufanie klientów na pewno spadnie do wszystkich firm po tym...

 

Bez przesady. Wpływ tego jest marginalny jeżeli w ogóle jakikolwiek jest. Typowy klient nawet o tym nie słyszał.

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ja chciałbym się dowiedzieć co tam się stało, bo taki przestój to chyba, że musieliby mieć kilkaset TB danych do przepchnięcia gigabitem

 

może wszystko było np na macierzy IBM (pure shit swoją drogą) ^^

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
To jest problem dla całej branży i zaufanie klientów na pewno spadnie do wszystkich firm po tym...

Tylko klienci tej firmy stracą zaufanie do małych firm. I na pewno nauczą się, że ważne dane należy backupować we własnym zakresie, a nie wierzyć tylko w obietnice innych.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ja chciałbym się dowiedzieć co tam się stało, bo taki przestój to chyba, że musieliby mieć kilkaset TB danych do przepchnięcia gigabitem

 

może wszystko było np na macierzy IBM (pure shit swoją drogą) ^^

 

http://hostingnews.pl/wlamanie-na-serwery-adweb/

 

W wersji tl;dr

 

Włamanie nastąpiło przez Roota, serwery i backupy zostały całkowicie wyczyszczone. Firma co prawda posiada część backupów z zeszłego roku, ale to bardzo niewiele. Obecnie Adweb za pomocą nowych adminów z Warszawy, stawia cały system na nowo. Poczta co prawda działa ale tylko POP3, ale i tak największym problemem są strony WWW klientów. Po prostu ich nie ma i nie wiadomo obecnie jak odzyskać.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Bardzo źle. Współczuję firmie. Pomyślcie, przed wrogiem "od środka" nie ma żadnych zabezpieczeń...

 

Jak myślicie, ile da się odzyskać? Są takie opcje - ten BOFH mógł kasować tak, zakładam że tam był ext2 może z "ułutszeniami".

 

rm -rf /

Jak na szybko to pewnie tak robił. Długo by trwało, nie wiem czy w nocke by się wyrobił...

Wtedy krótkie pliki da się odzyskać (jak wchodziły do 1 inody, czyli 12 bloków ). Dłuższych nie, o ile plik był pofragmentowany (jeśli nie był to jest zgadywanie, czy nowa inoda jest początkiem nowego pliku, czy kontynuacją starego. Tak było kiedyś- zmieniło się coś? Jaki wpływ ma dziennik z ext3, czy tam coś zostaje po rm - z ciekawości może ktoś napisze.

 

 

mkext2 (czy tam 3 albo 4)

Kaplica bo kasuje tablice inodów, jak się skończy, a pewnie się skończyło robić... I w miarę szybkie

 

dd if=/dev/zero of=...

Najgorsza opcja. Ale długo by trwało.... Myślę że nierealne (kilka dni)...

Za to najmniej woluminów do wpisania, bo można jechać całe dyski a nie partycje na nich (jak były w ogóle partycje a nie montowane blokowe fsy z kontrolera dyskowego/macierzy...

 

 

 

 

 

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Adam Szendzielorz

 

Duże macierze podłączane do kilku serwerów mają podpięcie po szkiełku FCoE - dzisiaj standard 16Gbit. Często w czasie pracy dane z i do macierzy lecą z szybkością wire speed, bo wolumin jest rozłożony np. na 20 dysków i wszystkie pracują. Do tego jest deduplikacja, która działa cuda w takich środowiskach jak hostingi - ile masz tam kopii Wordprssów np.?

 

Fajnie piszesz ale w hostingu współdzielonym takich urządzeń się po prostu nie stosuje, bo są zbyt drogie.

16Gbit? Trzy oddzielne serwery ze zwykłymi kontrolerami SAS/SATA 6Gbit da większą sumaryczną przepustowość (18Gbit) - i przy okazji (i zapewnie w podobnej cenie biorąc pod uwagę cenę macierzy i zajętość miejsca w szafie takich zestawów) zapewnią przynajmniej 2 x większą ilość CPU i RAM. Już nie mówiąc o tym, że jak do każdego wrzucę nawet jakiś stosunkowo tani SSD na l2arc to wydajność tego zestawu powali tą macierz na kolana :)

 

Deduplikację mogę też bez żadnego problemu włączyć na ZFSie ale tego się nie używa z uwagi na znaczny spadek wydajności filesystemu. Na macierzy będzie to samo :) Goły WordPress zajmuje po rozpakowaniu 24MB. Reszta to już unikalne dane użytkowników. To już mniejszym kosztem można po prostu kompresować w locie cały filesystem. Zresztą - jedno i drugie można robić i na macierzy i na lokalnym filesystemie (ZFS) więc to żaden argument :)

pozdr.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Fajnie piszesz ale w hostingu współdzielonym takich urządzeń się po prostu nie stosuje, bo są zbyt drogie.

16Gbit? Trzy oddzielne serwery ze zwykłymi kontrolerami SAS/SATA 6Gbit da większą sumaryczną przepustowość (18Gbit) - i przy okazji (i zapewnie w podobnej cenie biorąc pod uwagę cenę macierzy i zajętość miejsca w szafie takich zestawów) zapewnią przynajmniej 2 x większą ilość CPU i RAM. Już nie mówiąc o tym, że jak do każdego wrzucę nawet jakiś stosunkowo tani SSD na l2arc to wydajność tego zestawu powali tą macierz na kolana :)

 

Deduplikację mogę też bez żadnego problemu włączyć na ZFSie ale tego się nie używa z uwagi na znaczny spadek wydajności filesystemu. Na macierzy będzie to samo :) Goły WordPress zajmuje po rozpakowaniu 24MB. Reszta to już unikalne dane użytkowników. To już mniejszym kosztem można po prostu kompresować w locie cały filesystem. Zresztą - jedno i drugie można robić i na macierzy i na lokalnym filesystemie (ZFS) więc to żaden argument :)

pozdr.

 

Ja nie chcę nikogo przekonywać bo nie pcham tych towarów jako rep :) Zachęcam jednak potestować, bo jednak trochę myśli programistycznej w macierze jest włożone, i nie można ich traktować jako zdalne RAIDy po kabelku.

 

Jak w serwerach są karty HBA zamiast dysków, to serwery mogą być mniejsze. Macierz zaś zajmuje kilka U. W całej macierzy można mieć wszystko podwójne - zasilacze, kontrolery, półki (w każdym woluminie ustawiają się same dyski z różnych półek). Dowolny element można wyrwać w trakcie pracy i reszta działa.

Jak już jesteśmy przy SSD: SSD w macierzy pozwala robić tiering. Niektóre pliki lub nawet części plików są cały czas na SSD , a niektóre na spndlach, macierz sama je przenosi w zależności od ilości iops (operacji) na poziomie bloków (część dużego pliku np. bazy może przejść na ssd, a część na HDD).

 

Deduplikacja np. robi się w wolnym czasie, a nie podczas zapisu pliku. W macierzy jest takie rozdzielenie fizycznych napędów od logicznych dysków.Po upgradzie softu i paru dniach jak poprawią deduplikację potrafi przybyć 1TB na macierzy znikąd! Jest też thin provisioning - home ma np. 4Tera, ale zajęte jest 50%, w macierzy ta powierzchnia jest wolna, a jak zapotrzebowanie na hoscie wzrasta, to dopiero znika z puli wolnej. Przy 20 serwerach to robi dużą różnicę w ilości dysków, i to jest główna przyczyna dlaczego się opłaca. Na lokalnych dyskach zawsze jakieś 20-40% jest puste i się marnuje.

 

Dobra, kończę ten elaborat, pora brać się do roboty! ZFS jest super i warto go stosować, bo jest otwarty i nie jest się całkiem zależnym od producenta (zamknięty jest tylko firmware w napędach).

 

Pozdr.

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

I ta odłączona sata na zdjęciu.

 

Poważnie podchodząc do tematu to hostingów zwyczajnie nie stać na macierze. Rozproszony system plików po serwerach i może na nowszej instalacji 40G do synchronizacji ale to max, raczej coś prostego na DRBD na wypadek awarii i system backupu na krowy z których odzyskiwanie zajmuje potem masę czasu to norma. Macierz za tą inżynierie dobija takie kwoty że nawet duża firma hostingowa tego nie udźwignie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Bartosz Gadzimski

Co do macierzy to wszyscy zapominają o kosztach obsługi tego, znajdźcie teraz specjalistów od macierzy czy innych mocno komercyjnych rozwiązań.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Adam Szendzielorz

Jak w serwerach są karty HBA zamiast dysków, to serwery mogą być mniejsze.

Mniejsze od 1U być nie mogą, a do takiego np. x3550m5 wrzucisz 8 HDD :) Także to również nie jest żaden argument.

 

Macierz zaś zajmuje kilka U.

Więc zamiast zabierać "kilka U" na macierz - lepiej w te miejsce wrzucić oddzielne maszyny - będzie więcej CPU, RAM etc :)

 

W całej macierzy można mieć wszystko podwójne - zasilacze, kontrolery, półki (w każdym woluminie ustawiają się same dyski z różnych półek). Dowolny element można wyrwać w trakcie pracy i reszta działa.

Ależ ja to wszystko wiem - nie neguję macierzy jako ogólnie złej, tylko jako złego rozwiązania do hostingu współdzielonego. Macierz sprawdzi się idealnie w jakichś dużych środowiskach hostingu dedykowanego - duże serwisy, portale, sklepy etc. Ale dla współdzielonego to zło - ma zdecydowanie więcej wad, niż zalet!

 

Jest też thin provisioning - home ma np. 4Tera, ale zajęte jest 50%, w macierzy ta powierzchnia jest wolna, a jak zapotrzebowanie na hoscie wzrasta, to dopiero znika z puli wolnej. Przy 20 serwerach to robi dużą różnicę w ilości dysków, i to jest główna przyczyna dlaczego się opłaca. Na lokalnych dyskach zawsze jakieś 20-40% jest puste i się marnuje.

Owszem - to jest jedyna chyba mi znana zaleta macierzy. Ale znowu - mówimy o hostingu współdzielonym - czyli o b. dużej ilości względnie małych serwerów, które jest bardzo łatwo migrować między poszczególnymi maszynami - optymalizując wykorzystanie przestrzeni do maksimum. 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%.

 

Oczywiście łatwiej jest podpiąć macierz i zapomnieć o jakichś migracjach - to jest wygodniejsze dla administratora (dla klienta bez znaczenia!). Ale jak ta macierz kiedyś padnie (wiem wiem - wszystko zduplikowane - to samo mówił e24cloud i oktawave jakiś czas temu jak im macierze padały) to klienci Cię zjedzą. Jest różnica, jak pada mały raid z danymi 100 użytkowników (i trzeba go np. odtwarzać z backupu), a duża z danymi 10 tys. użytkowników.

 

Dobra, kończę ten elaborat, pora brać się do roboty! ZFS jest super i warto go stosować, bo jest otwarty i nie jest się całkiem zależnym od producenta (zamknięty jest tylko firmware w napędach).

Pełna zgoda :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dodam jeszcze od siebie że SSD w macierzach nadal są za drogie a w serwerach już nie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Łukasz Tkacz

Niezłe jajca z ich FB

 

 

Wkrótce uruchomimy Państwu dostęp do bazy MySQL -https://mysqladmin.2be.pl, z którego będzie można pobrać aktualną bazę. Klienci, którzy nie posiadają danych dostępowych, proszeni są o kontakt e-mail: 2be@2be.pl.

Najważniejszy problem to Państwa strony www. Na tym etapie jesteśmy niemal pewni, że nie uda nam się odzyskać backupów aktualnych stron www. Najbardziej prawdopodobne są stany z czerwca 2015 roku.

Natomiast treści stron zapisane w bazie danych zostaną zaktualizowane do stanu z dnia 26.02.2016.

Aktualnie serwer backupowy jest diagnozowany w profesjonalnej firmie odzyskującej dane. Nie mamy jeszcze informacji czy uda się z niego przywrócić strony www.

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Bartosz Gadzimski

No tak, tylko wypadałoby backup na taśmach i offline robić :/

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Oczywiście łatwiej jest podpiąć macierz i zapomnieć o jakichś migracjach - to jest wygodniejsze dla administratora (dla klienta bez znaczenia!). Ale jak ta macierz kiedyś padnie (wiem wiem - wszystko zduplikowane - to samo mówił e24cloud i oktawave jakiś czas temu jak im macierze padały) to klienci Cię zjedzą. Jest różnica, jak pada mały raid z danymi 100 użytkowników (i trzeba go np. odtwarzać z backupu), a duża z danymi 10 tys. użytkowników.

 

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość
Temat jest zablokowany i nie można w nim pisać.

×