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.
- Zalecanym sposobem jest odłączenie woluminu, wykonanie migawki i ponowne podłączenie - zwykle nie jest to praktyczne.
- Kolejna najlepsza opcja obejmuje opróżnienie pamięci podręcznej zapisu na dysk, zamrożenie systemu plików i wykonanie migawki
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:
- Woluminy EBS niedostępne:
- RAID1 - bezużyteczny, ponieważ nie można uzyskać dostępu do danych
- bin-log - bezużyteczny, chyba że wyeksportowałeś go do S3 - prawdopodobnie opóźnienie, jeśli to zrobiłeś
- Instancja nieoczekiwanie kończy się:
- RAID1 - dyski są dostępne, ale nie są spójne, baza danych może samodzielnie odzyskać niespójność
- bin-log - twoje dane powinny być dostępne, chociaż może być konieczne przejrzenie ostatnich kilku zdarzeń
- Ktoś uruchamia DROP DATABASE jako root:
- RAID1 - masz dwie idealne kopie nieistniejącej bazy danych
- bin-log - powinieneś być w stanie odtworzyć zdarzenia do momentu tuż przed poleceniem, więc powinieneś być w porządku
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
- Używaj migawek - są świetne - znacznie skracają przestoje, bardziej niż je powodują
- Oddziel dane i wolumin główny, być może nawet umieszczając bazy danych na własnym woluminie, i w razie potrzeby wykonaj migawkę przed aktualizacją
- Użyj bin-log, aby pozostać „gorącym”, jak to możliwe - prześlij to (skompresowane) do S3
- Upewnij się, że faktycznie pobierasz dane z instancji (nawet jeśli dane są nienaruszone na woluminie EBS, sam wolumin może być tymczasowo niedostępny).
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).