AdminX

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

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

 

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?

 

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.

 

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

 

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

 

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

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

Sam backup na macierzy też jest ogarnięty i nie jest w niczym gorszy, a wręcz lepszy od półek / dysków podłączanych lokalnie. Standardem są snapshoty co godznię i one zostaną nawet po skasowaniu dd /dev/zero z poziomu OSa, wystaczy w panlelu macierzy przywrócić wolumin ze snapshota, co trwa kika minut MAX...

Dopiero jak ktoś ma prawa, wejdzie na macierz i pokasuje woluminy, to wtedy snapshoty (godziny, dzienny itd.) znikają.

Dlatego ja się zastanawiam kto to był i co robił w tym 2be, że nie ma kompletnie nic. Ile czasu to kasowanie do gołej blachy zajęło??? To jest problem dla całej branży i zaufanie klientów na pewno spadnie do wszystkich firm po tym...