Czy istnieje dobry sposób na wykonanie kopii zapasowej petabajta danych i przechowywanie ich?

Zaczynam widzieć klientów z setkami terabajtów danych (w instalacjach SQL Server). Ponieważ łączna ilość danych w niektórych przedsiębiorstwach zbliża się do znacznych ułamków petabajta, chciałbym przeszukać zbiorową bazę wiedzy, aby zobaczyć, co robią ludzie zajmujący się tak dużą ilością danych, aby ją zabezpieczyć.

Oczywistym problemem jest to, że przechowywanie wielu kopii zapasowych tak dużej ilości danych jest nadmiernie drogie, przy użyciu pamięci masowej klasy korporacyjnej, do diabła, nawet po prostu RAID-5.

Opcje, które widzę, są następujące:

1. Utwórz kopię lustrzaną danych w innym centrum danych i stale wysyłaj do nich różnice (używając dowolnego mechanizmu dostępnego dla źródła danych - np. Wysyłanie dziennika lub dublowanie bazy danych za pomocą SQL Server)
2. Rób regularne tworzenie kopii zapasowych za pomocą mocny algorytm kompresji (prawdopodobnie odpowiedni tylko wtedy, gdy dane nadaje się również do bycia mocno skompresowany)
3. Wykonuj fragmentaryczne kopie zapasowe krytycznych / zmieniających się części danych.
4. Nie twórz kopii zapasowych danych i ufaj bogom korupcji.

Widzę, że opcja nr 4 została przyjęta jako domyślna, a jako ekspert HA / DR jest to naprawdę przerażające, ale co radzę jako alternatywę? Myślę, że nr 1 jest najlepszym podejściem, ale „nie sądzę” to zwykła odpowiedź, gdy sugerowane są alternatywy oprócz nr 4 i ewentualnie nr 3.

Teraz oczywiście zależy to od szybkości zmian i krytyczności danych. Nie muszę na to odpowiadać, ponieważ byłem odpowiedzialny za wszystkie funkcje HA programu SQL Server podczas pracy w firmie Microsoft, więc jestem dobrze zaznajomiony z argumentami „to zależy” - to moja fraza :-)

Byłbym bardzo zainteresowany, aby usłyszeć o wszelkich alternatywach, które przegapiłem, lub usłyszeć, że wszyscy inni są na tej samej łodzi i nie ma realistycznej alternatywy dla wydawania dużych pieniędzy na więcej miejsca.

Z góry dziękuję - należne uznanie otrzymają wszystkie przemyślane i wyrażone odpowiedzi.

Pomysł na ścianę - czy wszystkie przechowywane informacje są potrzebne, a nawet przydatne?

Ile faktycznie warte są informacje? Wydaje się oczywiście absurdalne wydawanie więcej na utrzymanie i zarządzanie, niż są warte dane.

Czy dane w bazie danych są odpowiednie do przechowywania w bazie danych? Na przykład, czy przechowywanie skompresowanych plików wielogigabajtowych w bazie danych organizacji wsparcia naprawdę przynosi jakieś rzeczywiste korzyści?

Czy w bazie danych jest dużo zduplikowanych danych? Na przykład, czy tysiąc osób przechowuje dziesięć egzemplarzy każdego tygodniowego biuletynu 10 MB?

Czy niektóre dane mają „datę ważności”, po której nie podają żadnej wartości? Wracając do przykładu organizacji wsparcia, z różnych powodów praktycznie nie ma korzyści z przechowywania podstawowych plików klienta dłużej niż kilka miesięcy po dostarczeniu poprawki.

Kolejna myśl - to utrzymywanie tylu danych otwierających firmę na zobowiązania. Niektóre dane należy zgodnie z prawem przechowywać. Niektóre dane powinny być jednak „niszczone” ze względu na ryzyko związane z przypadkowym lub złośliwym udostępnieniem nieodpowiednim stronom.

Tak, inną opcją jest wirtualizacja pamięci masowej: urządzenie, które znajduje się między serwerami a siecią SAN, takie jak IBM SVC. SVC zarządza kopiami SAN-do-SAN i może przeprowadzać zdalną replikację (chociaż jest to oczywiście dość bolesne na poziomie petabajtów, chyba że masz naprawdę niskie szybkości zmiany danych i naprawdę dużą przepustowość).

Zręczne jest to, że cały proces jest niewidoczny dla zaangażowanych serwerów. Jeśli używasz programu SQL Server, projektujesz swoje grupy plików, aby utrzymać rzeczy o niskim współczynniku zmian razem (np. Archiwa sprzedaży sprzed> 3 lat) oraz rzeczy o wysokim współczynniku zmian (jak bieżąca sprzedaż) w oddzielnej grupie plików. Nie muszą nawet być całkowicie do odczytu - po prostu chcesz to zaprojektować, aby można było używać różnych metod replikacji dla każdej grupy plików. Sprzęt SAN może synchronizować jednostki LUN za pośrednictwem sieci, taśmy lub SAN - co oznacza, że ​​możesz wysyłać części SAN tam iz powrotem. Jest to bardziej skuteczne w przypadku sprzętu takiego jak LeftHand, gdzie SAN składa się z puli jednostek uczestniczących.

Następnie możesz automatycznie zsynchronizować rzeczy o niskim współczynniku zmian na przewodzie i zsynchronizować wysoki wskaźnik zmian z sneakernet. (Wygląda na to, że mam to do tyłu, ale to prawda - nie możesz zsynchronizować rzeczy o wysokiej szybkości zmian w przewodzie z powodu głośności.) Nawet niektóre urządzenia z niższej półki akceptują to teraz: LeftHand umożliwia replikację do innych Jednostki LeftHand w centrum danych, a następnie dostarcz je do swojego centrum danych poza siedzibą firmy. Podłącz je, dołącz do zdalnej strony, zmieniając adresy IP i grupy, a teraz są częścią zdalnej kopii zapasowej SAN. Skala sprzedaży LeftHand w tym zakresie jest po prostu genialna: skonfiguruj dwie sieci SAN obok siebie w głównym centrum danych, zsynchronizuj je, a następnie możesz wysłać ich część do zdalnego centrum danych, a niektóre pozostaną w bieżącym centrum danych do synchronizacji. Stopniowo przesuwaj

Jednak nie zrobiłem tego na poziomie petabajtów. Wiesz, co mówią - w teorii, w teorii i w praktyce są takie same. W praktyce...

Opcja 1 to tworzenie kopii lustrzanych, co jest prawie tak samo złe jak nr 4: każdy błąd, który uszkadza dane i nie zostanie wykryty natychmiast, spowoduje uszkodzenie obu kopii.

Jeśli dane są krytyczne, rozważ dedykowane rozwiązania; przeczytaj na przykład o produktach IBM Shark lub konkurencyjnych produktach EMS itp. Mają one funkcje takie jak Flash-copy, które pozwalają natychmiast utworzyć logiczną kopię pliku bez podwajania wymagań dotyczących dysku; a następnie możesz wykonać kopię zapasową tej kopii na (np.) taśmie. Zajrzyj także do automatycznego tworzenia kopii zapasowych na taśmach.

Wskaż te, które chcą przechowywać Petabajt danych, które nie są tanie.

Mam dość ludzi jęczących z powodu braku dodatkowego terabajta pamięci online, ponieważ dysk jest tani - dysk może być, ale pamięć zarządzana na pewno nie jest.

Jeśli przechowywanie kopii zapasowych jest zbyt drogie, to przechowywanie danych w bezpieczny sposób jest zbyt drogie, więc proponowane rozwiązanie nie jest wykonalne.

Jednym z najważniejszych powodów tworzenia kopii zapasowych jest ochrona przed błędami użytkownika (większość problemów z awarią sprzętu można rozwiązać za pomocą rozwiązań sprzętowych), ale nawet dublowanie bazy danych nie zapewnia ochrony przed upuszczeniem tabeli (OK, można przed tym zabezpieczyć, ale nadal jest możliwe jest uzyskanie nieusuwalnego guffa do twojego DB - chyba że powodem tego, że DB jest tak duży, że zawsze wydaje wstawienia).

Widzę, że taśma nie jest już realnym rozwiązaniem - teraz taniej jest po prostu pracować z macierzami dyskowymi (chociaż fizyczne przechowywanie może być niewygodne). Myślę więc, że twoją jedyną opcją jest jakaś metoda dzielenia danych na fragmenty wystarczająco małe, aby można je było przywrócić w rozsądnym czasie, a następnie regularne wprowadzanie ich do miejsca na dysku (i tutaj rozwiązania typu EMS mogą pomóc, jeśli masz gotówkowy).

Ciekawe wideo przedstawiające architekturę myspace.com (backend SQL2005). Nie jestem pewien, czy mają pojedyncze petabajty dbs, ponieważ skalują się z wieloma dbs. Używają kopii zapasowych SAN Snap.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Jasne, wciąż się dopiero zaczyna, ale istnieje wiele obszarów, w których ZFS jest zaprojektowany do obsługi właśnie takich rzeczy. Po pierwsze, jest w stanie obsłużyć dużą ilość danych, a także wiele różnych urządzeń pamięci masowej (lokalna, SAN, światłowód itp.), A wszystko to przy zachowaniu bezpieczeństwa danych dzięki sumom kontrolnym i „naruszeniu” świadomości stanu urządzenia awarie. Jak to jednak pomaga rozwiązać problem tworzenia kopii zapasowych tak dużej ilości danych?

Jedną z metod jest użycie migawek. Zrób migawkę, wyślij ją na taśmę / dysk / sieć w celu przesłania do strony zdalnej. Kolejne migawki wysyłają tylko dane, które zostały wysłane, aw razie potrzeby możesz przechowywać dane na obu końcach.

Drugim jest użycie oprogramowania Solaris Cluster, w którym (o ile masz wystarczającą przepustowość sieci) możesz mieć dublowanie na żywo między dwoma serwerami, a jeśli jeden z nich ulegnie awarii, drugi może przejąć kontrolę. Jest to bardziej przydatne, gdy ważna jest wysoka dostępność (HA), ale zgaduję, że większość miejsc z tak dużą ilością danych potrzebuje HA.

I mówisz, że ZFS nie jest obsługiwany w systemie Windows, zwykłym miejscu, w którym można znaleźć serwer sqlserver, może uruchamiasz Sun / ZFS na backendie i łączysz się przez iSCSI. Może to także okropny pomysł, ale warto przynajmniej przemyśleć, żebyś wiedział, czego nie robić.

Czy szukałeś opcjonalnie lodowca Amazon?

IMO, chyba że masz sprzęt na poziomie godzilla, jeśli masz tyle danych, powinieneś używać technologii kompresji kopii zapasowej. Najbardziej znam LiteSpeed, ale istnieją podobne produkty innych dostawców i (oczywiście) podobna funkcja jest wbudowana w SQL2008. Możesz nie uzyskać kompresji 10 do 1, ale zmniejsza wymagania dotyczące miejsca na kopię zapasową, a także może zmniejszyć wymagania dotyczące okna kopii zapasowej. Jeśli Twoim celem jest utrzymanie wielu zestawów kopii zapasowych (wczoraj plus dzień wcześniej, plus jeden z ostatniego tygodnia i jeden z ostatniego miesiąca lub seria różnic i pełnych, które mogą stać się duże, jeśli zmienisz dużo danych w baza danych), to prosta kwestia miejsca do przechowywania.

Tworzenie kopii zapasowych w oparciu o grupę plików (IOW, umieszczanie nieulotnych danych na niektórych FG i rzadkie tworzenie kopii zapasowych) nigdy nie wydaje się latać, ponieważ deweloperzy lub użytkownicy nie mogą lub nie mogą zdecydować, które dane są niestabilne, a które nie, i w brownfield scenariusze, których często nie możesz zaryzykować.

Jeśli wymagana jest witryna przełączania awaryjnego, oprócz myślenia o dublowaniu bazy danych) możesz porozmawiać z dostawcą pamięci masowej swoich klientów, aby sprawdzić, czy oferują coś takiego jak SRDF, czyli sprzętową technologię replikacji danych. Oczywiście replikacja (dowolnego rodzaju, ale szczególnie replikacja w czasie rzeczywistym lub prawie w czasie rzeczywistym) nie zastępuje kopii zapasowych.

Nie sądzę, żebyś miał duży wybór tutaj na taśmie v. Disk. Taśma najprawdopodobniej nie wycina jej w zwykłym oknie kopii zapasowej, chyba że ją rozłożysz, i nie jestem pewien, czy jest niezawodna.

Więc jesteś gotowy do tworzenia kopii zapasowych dysków. Czy przechowujesz wersje? Czy martwisz się, że wrócisz do kopii zapasowej 2 (bieżąca baza danych minus 2 kopie zapasowe)? Czy kopia zapasowa 3? W takim przypadku możesz mieć problemy, ale prawdopodobnie masz do czynienia z kopiami zapasowymi dziennika, a nie tyloma kopiami zapasowymi danych.

Jeśli możesz podzielić niektóre dane jako tylko do odczytu / bez zmian, być może masz możliwe do zarządzania rozmiary / okna kopii zapasowych. A przynajmniej masz nadzieję, że technologia tworzenia kopii zapasowych i przepustowość nadążają za wzrostem ilości danych.

Nie sądzę, że tworzysz kopie zapasowe w takim samym stopniu, w jakim przechowujesz drugą kopię w celu odzyskania po problemach z podstawowym. Oznacza to sprzęt, uszkodzenie itp. I codziennie modlisz się, aby błędy nie były wysyłane do drugiej kopii. Kopie najprawdopodobniej powstają w technologii SAN-SAN, z wykorzystaniem technologii snap-shot. chociaż oryginalna kopia może być przesyłana za pośrednictwem Fed-Ex, a nie przez sieć. Przepustowość do przeniesienia 100 TB nie jest łatwa do zdobycia dla nikogo.

Myślę, że potrzebujesz kombinacji 1, 2 i 3 (nie 4) z doskonałym zarządzaniem kopiami zapasowymi dziennika.

Właściwie uważam, że w każdej chwili naprawdę przeglądasz 3 kopie swoich danych. Uruchomienie CHECKDB na 1 kopii, podczas gdy druga kopia jest używana do faktycznego odbierania zmian. Następnie zrób migawkę drugiej kopii do pierwszej i kontynuuj. Przy tak dużej ilości danych wyobrażam sobie, że potrzebowałbyś tutaj odrobiny staranności. Paul, jak działa checkdb na bazie danych o pojemności 100 TB, która jest online, dla wielu użytkowników?

Jak wspomniano, czy kopie zapasowe dziennika i prawdopodobnie czytnik dziennika nie są krytyczne? Czy nie musisz odzyskiwać tabel upuszczania / błędów użytkownika z dzienników zamiast kopii zapasowej? Możesz potencjalnie to skrócić, wysyłając kopie SAN z pewnym opóźnieniem, ale nie widziałem tej technologii. SAN wysyłania dziennika, który może opóźnić zmiany o 4 godziny (lub o pewien odstęp czasu), aby umożliwić Ci odzyskanie się po problemach przed zastąpieniem danych. A może jakieś narzędzie do zmiany bloków SAN-czytnika dziennika? Bez tego musisz zarządzać tymi dziennikami transakcji, co może być zupełnie innym poziomem śledzenia kopii zapasowych w różnych systemach plików przez około xxx godzin, aby umożliwić potencjalne odzyskanie po błędach innych niż krytyczne.

Technicznie rzecz biorąc, przechowywanie jest tanie, ale na poziomie petabajtów nie tyle. To naprawdę zależy od aplikacji, ale powiedziałbym, że odpowiedzią będzie kombinacja strategii nr 2 i nr 3, z podanym numerem 2 i nr 3 w zależności od tego, ile możesz zainwestować w pamięć i rodzaj pamięć masową i moc obliczeniową we / wy, które pozwolą ci uniknąć jak najmniej inkrementalizmu i możliwie dyskretnej, pełnej kopii zapasowej.

Alternatywnie, coś takiego jak Amazon S3 może również wejść w grę w zależności od przepustowości i ilości zmian w danych - w tym woluminie, umieszczając przynajmniej część tego na serwerach innych osób i pozwalając im martwić się o nadmiarowość, staje się coraz bardziej opłacalny.

Porozmawiaj ze swoim dostawcą pamięci masowej, będą mieli produkt do deduplikacji, z którego korzystali wcześniej, w połączeniu ze zwykłą kompresją często możesz zmniejszyć ślad danych o 70%. Oczywiście każdy, kto ma pieniądze na petabajt przestrzeni dyskowej, prawdopodobnie będzie miał również budżet na zakup przyzwoitego rozwiązania do tworzenia kopii zapasowych - jeśli nie, to musisz po prostu zapytać go, jaka utrata tego petabajtu kosztowałaby ich firmę.

W dużej hurtowni danych duża część danych pochodzi ze źródeł, których kopie zapasowe zostały już utworzone. Pracowałem nad instalacjami Teradata i ODW, w których wybrali opcję nr 4, ale wiedziałem, że mogą przywrócić dzień lub dwa dane transakcyjne i przekształcić je z systemów źródłowych.

W przypadku jednego klienta detalicznego (w czasie, gdy miał jeden z 5 największych DW na świecie, przy około 200 TB ... daje wyobrażenie o tym, jak dawno to było), wybrał opcję 1 po zakupie nowego Petabyte -klasowy serwer Teradata. Stare węzły posłużyłyby do utworzenia migawki systemu z poprzedniego dnia, podczas gdy nowy utrzymał istniejący. Było to również miłe z punktu widzenia przełączania awaryjnego - od czasu do czasu zajmowali się konserwacją, a my po prostu przestawialiśmy się na używanie starego, powolnego serwera z codziennymi danymi.

Szczerze mówiąc, wydawało się to dużym marnotrawstwem przetwarzania / przechowywania / itp., Aby utrzymać to w ruchu ... szczególnie, gdy największą zaletą było to, że ich administratorzy i technicy NCR musieli pracować mniej wieczorów, aby wykonywać nieregularną konserwację.