Podobne pytania zostały zadane, ale muszę wiedzieć, co byłoby zalecane w danych okolicznościach, aby wiedzieć, czy brakuje mi czegoś w rozumieniu używania EC2.
Mały startup prowadzi swoją działalność w sieci EC2 i poprosił mnie o porady dotyczące opcji tworzenia kopii zapasowych. Są w tej chwili samofinansujące się i robią, co mogą, aby obniżyć koszty, gdy jest to wykonalne. Nie zagłębiając się zbytnio w konfigurację ich systemów, podam serwer WWW jako przykład; to prosty serwer WWW z bazą danych. Pocieszeniem jest to, że nie chcą, aby serwer został zdjęty.
Osoba przeprowadzająca konfigurację uważa, że powinna albo okresowo robić zrzuty bazy danych i przechowywać ją na S3, albo tworzyć skrypty, które odbudowałyby nowy serwer w Amazon, gdy będą potrzebne, tworząc kopię zapasową wybranych folderów zawierających informacje o konfiguracji . Zasugerował, że tworzenie migawek serwera byłoby marnotrawstwem, ponieważ zajmują dużo miejsca na dysku, a w zasadzie między dużymi zrzutami danych występowałoby gnicie danych, dzięki czemu migawka szybko stałaby się nieaktualna.
Myślałem o zrobieniu migawki maszyny wirtualnej, a następnie o okresowych zrzutach bazy danych i przechowywaniu w S3. Jeśli mieliby utracić instancję EC2 lub mieć coś w rodzaju aktualizacji uniemożliwiającej jej użytkowanie, mogliby użyć migawki, aby stosunkowo szybko utworzyć kopię zapasową serwera przy użyciu najnowszego zrzutu bazy danych, zamiast zacząć od nowa, aby zbudować nową instancję z całkowicie nowy AMI.
Rozumiem, że zrobienie migawki instancji EC2 (lub sklepu EBS) będzie wymagało przestojów, na co się wahają. Przeczytałem również, że powinieneś wyłączyć serwer, aby zachować spójność systemu plików podczas wykonywania migawki. Ponieważ nie mają jeszcze klastra za balansem, ograniczają one opcje związane z migawkami.
Skrypty do budowania serwerów, chyba że jest coś specyficznego dla Amazon, którego nie znam, wymagałoby stworzenia serwera Chef lub Puppet, który mógłby wdrożyć nowe serwery z powiązanymi rolami na EC2. W tej chwili startup nie ma środków na utrzymanie tego rodzaju serwera na skrzydłach, a teraz tak naprawdę nie muszą wdrażać tak wielu serwerów.
Idealnie byłoby, gdyby mieli fundusze na utworzenie szeregu serwerów za wirtualnym modułem równoważącym lub usługą równoważenia Amazon, a następnie zdejmowali serwery pojedynczo, aby wykonywać aktualizacje lub migawki. W tej chwili byłbym zdenerwowany pomysłem wykonania aktualizacji, ponieważ jeśli robisz zrzuty bazy danych, to nie pomoże, jeśli aktualizacja systemu zmieni bibliotekę, na której opiera się ich aplikacja, a usługa przestanie działać.
Przypuszczałem również, że inną opcją jest uruchomienie skryptu, który tworzy wolumin EBS, montuje go, a na serwerze uruchom coś w rodzaju rsync, aby przechwycić większość informacji o systemie plików na woluminie EBS, a następnie skompresować i skopiować zawartość do S3, odłączyć wolumin i zniszcz go, aby zaoszczędzić na kosztach przechowywania, a następnie wykonaj zrzut bazy danych, aby przechwycić dane w locie, które w przeciwnym razie byłyby niespójne. W przypadku niektórych serwerów najprawdopodobniej konieczne będzie zapisanie tymczasowych woluminów EBS w miarę wzrostu potrzeb bazy danych.
Tworzy się piaskownica VMWare w celu odtworzenia ich systemów sieciowych w środowisku, w którym aktualizacje mogą być wstępnie testowane przed zastosowaniem ich w systemach produkcyjnych w Amazon. Mam nadzieję, że zminimalizuje to możliwość, że aktualizacja systemu zabije ich aplikację.
Więc ... biorąc pod uwagę ograniczenia dotyczące uruchamiania jednego serwera z serwerem bazy danych i aplikacji w systemie, staramy się mieć jak najmniej przestojów, jak to możliwe (ograniczając użycie migawek i sprawiając, że proces tworzenia kopii zapasowych jest możliwie „gorący” (jak to możliwe) ( utworzone na żywo bez wyłączania serwera), czy jestem na niewłaściwej ścieżce, aby zasugerować zaplanowanie czasu utworzenia migawki instancji EC2 w jej stanie roboczym, a następnie zrobienia zrzutów bazy danych w celu skopiowania do S3? Czy istnieje lepsza strategia realizacji w tworzeniu kopii zapasowej na żywo serwera, jeśli migawki spowodują przestoje?
źródło
Odpowiedzi:
W tym pytaniu jest coś interesującego - szczególnie w odniesieniu do idei przestojów. Częścią idei jest to, że jeśli aplikacja jest wrażliwa na przestoje, należy również uwzględnić czas odzyskiwania. (Jako ekstremalny argument, żadne kopie zapasowe nie wymagają przestojów, chyba że zdarzy się, że potrzebujesz tych kopii, w którym to przypadku przestój może zbliżyć się do nieskończoności ).
Trochę o EBS
Woluminy i migawki EBS działają na poziomie bloków, co pozwala na wykonywanie migawek podczas działania instancji, nawet jeśli wolumin EBS jest używany. Jednak tylko dane znajdujące się na dysku (tj. Nie w pamięci podręcznej plików) zostaną uwzględnione w migawce. Jest to drugi powód, który rodzi ideę spójnych migawek.
Interesującym punktem jest to, że w obu powyższych przypadkach nie trzeba czekać na zakończenie migawki, aby ponownie podłączyć / odblokować i wznowić zapisywanie na dysku - po zainicjowaniu migawki dane będą spójne z tym momentem. Zazwyczaj zajmuje to tylko kilka sekund, podczas których dysk jest zablokowany. Także ponieważ większość baz danych porządkuje swoje pliki na dysku w rozsądny sposób - istnieje duża szansa, że wstawki mają minimalny wpływ na istniejące bloki - co minimalizuje dane dodane do migawki.
Rozważ punkt kopii zapasowej
Woluminy EBS są już replikowane w strefie dostępności - dlatego wbudowany jest pewien stopień nadmiarowości. Jeśli Twoja instancja się zakończy, możesz po prostu dołączyć wolumin EBS do nowej instancji i (po przejściu przez brak spójności) wznowić tam, gdzie odpuścić. Pod wieloma względami sprawia to, że wolumin EBS przypomina niespójną migawkę, pod warunkiem, że można uzyskać do niego dostęp. To powiedziawszy, większość użytkowników EC2 prawdopodobnie przypomina sobie kaskadowe awarie woluminów EBS z początku 2011 r. - woluminy były niedostępne przez wiele dni, a niektórzy użytkownicy również stracili dane.
RAID1
Jeśli próbujesz zabezpieczyć się przed awarią dysku EBS (tak się dzieje), możesz rozważyć konfigurację RAID1. Ponieważ woluminy EBS są urządzeniami blokowymi, możesz łatwo użyć mdadm, aby skonfigurować je w żądanej konfiguracji. Jeśli jeden z woluminów EBS nie działa zgodnie ze specyfikacją, łatwo ręcznie go zawieść (a później zastąpić innym woluminem EBS). Ma to oczywiście wady - wydłużony czas każdego zapisu, większa podatność na zmienną wydajność, podwójny koszt I / O (pieniężny, a nie pod względem wydajności), brak realnej ochrony przed bardziej powszechną awarią AWS (częstym problemem w zeszłym roku było niemożność odłączenia woluminów EBS, które były w stanie zablokowanym) i oczywiście niespójny stan dysku w przypadku awarii.
S3FS
Opcją dla niektórych aplikacji (zdecydowanie NIE dla baz danych) jest zamontowanie S3 jako lokalnego systemu plików (np. Przez s3fs). Jest to powolne, brakuje niektórych funkcji, których można oczekiwać od systemu plików, i może nie działać zgodnie z oczekiwaniami (ostateczna spójność). To powiedziawszy, w prostym celu, takim jak udostępnianie przesłanych plików między instancjami, może mieć to sens. Oczywiście nie dotyczy to niczego, co wymaga dobrej wydajności odczytu / zapisu.
Bin-log MySQL
Jeszcze jedną opcją specyficzną dla MySQL może być użycie bin-log. Możesz skonfigurować drugi wolumin EBS, w którym będzie przechowywany Twój bin-log (aby zminimalizować efekt dodanych zapisów w bazie danych) i używać go w połączeniu z wszelkimi zrzutami bazy danych, które wykonasz. Być może będziesz w stanie to zrobić za pomocą s3fs, co może mieć wartość, jeśli wydajność jest do zniesienia (rsync prawdopodobnie lepiej by było, niż próbować używać s3fs bezpośrednio, i na pewno będziesz chciał skompresować to, co możesz).
Jednak po raz kolejny wracamy do idei celu. Zastanów się, co by się stało z powyższymi sugestiami:
Tak naprawdę RAID1 jest w większości bezużyteczny, a bin-log zajmuje zbyt dużo czasu - oba mogą mieć zalety w pewnych okolicznościach, ale są dalekie od tworzenia kopii zapasowej pomysłu.
Migawki
Należy zauważyć, że migawki są różnicowe i przechowują tylko te rzeczywiste bloki, które zawierają dane (i są skompresowane). W przeciwieństwie do woluminu EBS, w przypadku gdy masz wolumin 20 GB, ale używasz tylko 1 GB, nadal pobierana jest opłata za „udostępnione” miejsce (20 GB). W przypadku migawki pobierana jest opłata tylko za to, czego używasz. Jeśli między migawkami nie zmieniają się dane, (teoretycznie) nie ma opłaty. (Migawki są pobierane za PUTS / GETS i wykorzystaną pamięć).
Na marginesie gorąco polecam, aby dane aplikacji (w tym bazy danych) nie były przechowywane w woluminie głównym (który być może już masz skonfigurowany). Jedną z zalet jest to, że, mam nadzieję, wolumin główny widzi minimalną zmianę - co oznacza, że jego migawki mogą być rzadziej (lub będą miały minimalną zmianę), zmniejszając koszty i łatwość użytkowania.
Warto również wspomnieć, że można usunąć stare migawki w dowolnym momencie - nawet jeśli są one różnicowe, nie wpłyną na inne migawki. To powiedziawszy, każdy blok przypisany do migawki nie zostanie zrezygnowany, dopóki nie będzie migawki, która nadal odwołuje się do tego bloku.
Problem z okresowymi zrzutami to przede wszystkim czas pomiędzy zrzutami (prawdopodobnie rozwiązany przez użycie bin-logu MySQL), a także trudność odzyskiwania. Zaimportowanie dużego zrzutu i odtworzenie wszystkich zdarzeń z bin-loga zajmuje trochę czasu. Ponadto utworzenie zrzutu nie jest pozbawione wpływu na wydajność. Prawdopodobnie takie zrzuty prawdopodobnie wymagają znacznie więcej pamięci niż migawka. Konfigurowanie woluminu EBS wyłącznie dla baz danych i tworzenie migawek, które byłyby preferowane w większości przypadków (to powiedziawszy, zrobienie migawki ma również trochę wpływu na wydajność).
Zaletą migawek i woluminów EBS jest to, że można ich używać w innych instancjach. Jeśli instancja nie uruchomi się, możesz dołączyć wolumin główny do innej instancji, aby zdiagnozować i naprawić problem - lub po prostu skopiować dane z niego - i możesz przełączyć woluminy główne tylko kilka minut przestoju (zatrzymaj instancję, odłącz wolumin główny, dołącz nowy wolumin główny, uruchom instancję). Ten sam pomysł dotyczy przechowywania danych na drugim wolumenie EBS. Zasadniczo po prostu rozpakowujesz nową instancję z niestandardowego interfejsu AMI i dołączasz do niej swój bieżący wolumin EBS - pomaga to zminimalizować przestoje.
(Można by argumentować (i prawdopodobnie nie poleciłbym tego), że możesz zainstalować dwie kopie MySQL na tym samym serwerze (Master-slave), używając dwóch woluminów EBS, a następnie zamknąć swój slave, aby zrobić migawkę jego Wolumen EBS - będzie spójny, bez przestojów - ale koszty wydajności prawdopodobnie nie są tego warte).
AWS ma funkcję automatycznego skalowania - która będzie w stanie utrzymać stałą liczbę instancji (nawet jeśli ta liczba to 1) - jednak wdrożyłbyś z migawki - więc jeśli twoja migawka nie jest przydatna, wówczas przesłanka nie jest zbyt użyteczna .
Kolejna kilka punktów - możesz wdrożyć tyle instancji, ile chcesz z jednej migawki (w przeciwieństwie do woluminu EBS, który można dołączyć tylko do jednej instancji w danym momencie). Woluminy EBS są również ograniczone do użytku w strefie dostępności, a migawki mogą być używane w obrębie regionu.
Idealnie byłoby, gdyby z migawki serwer przestał działać, możesz po prostu uruchomić nowy przy użyciu ostatniej migawki - szczególnie jeśli oddzielisz wolumin główny od danych, zła aktualizacja powinna spowodować minimalne przestoje (ponieważ po prostu przenieś wolumin EBS zawierający twoje dane - i zrób jego migawkę, aby zachować wszystko, co może zostać uszkodzone z powodu niespójności).
Na marginesie, Amazon stwierdza, że wskaźnik awaryjności woluminów EBS rośnie wraz ze zmianą ilości danych na nich od czasu ostatniej migawki.
Ostateczne rekomendacje
Rekomendowane lektury:
(Wierzę, że napisałem za dużo, ale nie powiedziałem wystarczająco dużo - ale mam nadzieję, że znajdziesz coś wartego przeczytania).
źródło
Możliwe jest wykonanie migawki na żywo woluminu EBS , należy jednak upewnić się, że system plików znajduje się w spójnym stanie, a następnie jest zawieszany podczas inicjowania migawki. Nie wszystkie systemy plików na to pozwalają, choć jest to zdecydowanie możliwe i stanowi podstawę naszego własnego rozwiązania do tworzenia kopii zapasowych.
Migawki EBS są również dość tanie, ponieważ pobierają tylko zmienione dane, a opłaty za dane są bardzo rozsądne same w sobie. Należy jednak pamiętać, że jest to oparte na zmianach na poziomie bloku, więc można to zmienić dość szybko. Dotyczy to również migawek, pobierane są tylko dane zmienione między migawkami. Aby dać wyobrażenie o kosztach, płacimy mniej niż 10 USD miesięcznie za przechowywanie migawek i wykonujemy codzienne migawki, zachowując ostatnie 7 dzienników i ostatnie miesiące cotygodniowych migawek, i mamy 2 serwery zgodne z tym schematem (~ 20 migawek, 20 GB dysków twardych).
źródło
Co powiesz na tanie, niedrogie rozwiązanie do tworzenia kopii zapasowych, takie jak Zmanda Cloud Backup? Używamy go do tworzenia kopii zapasowych około 6 serwerów i 1 SQL Server, a to tylko około 10 USD miesięcznie. Możesz zaszyfrować swoje dane za pomocą samopodpisanego certyfikatu, a oni używają s3 do przechowywania danych (więc nie ma żadnych opłat za transfer danych, jeśli tworzysz kopię zapasową z EC2).
źródło