Korzyści z EBS w porównaniu do instancji-sklepu (i odwrotnie) [zamknięte]

Nie jestem pewien, jakie korzyści czerpię z EBS vs. sklep z instancjami dla moich instancji na Amazon EC2. Jeśli już, wydaje się, że EBS jest znacznie bardziej użyteczny (stop, start, utrzymywanie + lepsza prędkość) przy stosunkowo niewielkiej różnicy kosztów ...? Czy są też jakieś dane, czy więcej osób korzysta z EBS, gdy jest on dostępny, biorąc pod uwagę, że wciąż jest stosunkowo nowy?

Najważniejsze jest to, że prawie zawsze powinieneś używać instancji wspieranych przez EBS.

Dlatego

• Instancje wspierane przez EBS można ustawić tak, aby nie mogły (przypadkowo) zostać zakończone przez interfejs API.
• Instancje wspierane przez EBS można zatrzymać, gdy ich nie używasz, i wznowić, gdy będziesz ich ponownie potrzebować (np. Wstrzymywanie wirtualnego komputera), przynajmniej przy moich wzorcach użytkowania, które pozwalają zaoszczędzić znacznie więcej pieniędzy niż wydam na kilkadziesiąt GB pamięci EBS.
• Instancje wspierane przez EBS nie tracą pamięci instancji podczas awarii (nie jest to wymagane dla wszystkich użytkowników, ale znacznie przyspiesza odzyskiwanie)
• Możesz dynamicznie zmieniać rozmiar pamięci instancji EBS.
• Możesz przenieść pamięć instancji EBS do zupełnie nowej instancji (przydatne, jeśli sprzęt w Amazon, na którym działałeś, staje się niestabilny lub umiera, co zdarza się od czasu do czasu)
• Szybciej jest uruchomić instancję wspieraną przez EBS, ponieważ obrazu nie trzeba pobierać z S3.
• Jeśli sprzęt, na którym instancja wspierana przez EBS jest zaplanowana do konserwacji , zatrzymanie i uruchomienie instancji automatycznie migruje na nowy sprzęt. Mogłem również przenieść instancję wspieraną przez EBS na niesprawny sprzęt, wymuszając jej zatrzymanie i ponowne uruchomienie (przebieg może się różnić w przypadku awarii sprzętu).

Jestem dużym użytkownikiem Amazon i przestawiłem wszystkie moje instancje na pamięć masową wspieraną przez EBS, gdy tylko technologia wyszła z wersji beta. Byłem bardzo zadowolony z wyniku.

EBS wciąż może zawieść - nie srebrna kula

Należy pamiętać, że każda część infrastruktury chmurowej może ulec awarii w dowolnym momencie. Zaplanuj odpowiednio swoją infrastrukturę. Podczas gdy instancje wspierane przez EBS zapewniają pewien poziom trwałości w porównaniu do efemerycznych instancji pamięci masowej, mogą i nie działają. Posiadaj interfejs AMI, z którego możesz uruchamiać nowe wystąpienia w razie potrzeby w dowolnej strefie dostępności, tworzyć kopie zapasowe ważnych danych (np. Baz danych), a jeśli pozwala na to budżet, uruchamiać wiele wystąpień serwerów w celu równoważenia obciążenia i nadmiarowości (najlepiej w wielu strefach dostępności ).

Kiedy nie do

W niektórych momentach szybsze IO w instancjach Sklepu może być tańsze. Był czas, kiedy to z pewnością była prawda. Teraz istnieje wiele opcji przechowywania EBS, zaspokajających wiele potrzeb. Opcje i ich ceny stale ewoluują wraz ze zmianami technologii. Jeśli masz znaczną liczbę instancji, które są naprawdę jednorazowe (nie mają większego wpływu na twoją firmę, jeśli po prostu odejdą), zrób matematykę na podstawie kosztów i wydajności. Instancje wspierane przez EBS mogą również umrzeć w dowolnym momencie, ale moje praktyczne doświadczenie jest takie, że EBS jest bardziej trwały.

99% naszej konfiguracji AWS nadaje się do recyklingu. Więc dla mnie tak naprawdę nie ma znaczenia, czy zakończę instancję - nic nigdy nie zostanie utracone. Np. Moja aplikacja jest automatycznie wdrażana na instancji z SVN, nasze logi są zapisywane na centralnym serwerze syslog.

Jedyną zaletą pamięci instancji, którą widzę, są oszczędności. W przeciwnym razie wygrywają instancje wspierane przez EBS. Eric wspomniał o wszystkich zaletach.

[2012-07-16] Odpowiedziałbym dziś inaczej.

W ciągu ostatniego roku nie miałem dobrego doświadczenia z instancjami wspieranymi przez EBS. Ostatnie przestoje w AWS również mocno zniszczyły EBS.

Zgaduję, że usługa taka jak RDS również korzysta z pewnego rodzaju EBS i wydaje się, że w większości działa. W przypadkach, w których sami sobie radzimy, w miarę możliwości pozbyliśmy się EBS.

Pozbywamy się zakresu, w którym przenieśliśmy klaster bazy danych z powrotem na żelazo (= prawdziwy sprzęt). Jedynym pozostałym elementem naszej infrastruktury jest serwer DB, w którym umieszczamy wiele woluminów EBS w programowej macierzy RAID i wykonujemy kopię zapasową dwa razy dziennie. Bez względu na to, co zostanie utracone między kopiami zapasowymi, możemy z tym żyć.

EBS jest dość płatną technologią, ponieważ jest to zasadniczo wolumin sieciowy: wolumin podłączony do twojego serwera zdalnie. Nie neguję pracy z tym związanej - jest to niesamowity produkt, ponieważ zasadniczo nieograniczone trwałe miejsce do przechowywania jest po prostu wywołaniem API. Ale nie nadaje się do scenariuszy, w których wydajność we / wy jest kluczowa.

Poza tym, jak zachowuje się pamięć sieciowa, cała sieć jest współdzielona w instancjach EC2. Im mniejsza instancja (np. T1.micro, m1.small), tym gorzej się dzieje, ponieważ interfejsy sieciowe w rzeczywistym systemie hosta są współużytkowane przez wiele maszyn wirtualnych (= instancja EC2), które działają na niej.

Im większa instancja, tym lepiej . Lepiej tutaj oznacza w granicach rozsądku .

Gdy wymagana jest wytrwałość, zawsze radziłbym ludziom używać czegoś takiego jak S3 do centralizacji między instancjami. S3 to bardzo stabilna usługa. Następnie zautomatyzuj konfigurację instancji do punktu, w którym możesz uruchomić nowy serwer, który sam się przygotuje. Wówczas nie ma potrzeby posiadania pamięci sieciowej, która żyje dłużej niż instancja.

Podsumowując, nie widzę żadnej korzyści dla instancji wspieranych przez EBS. Raczej dodaję minutę do bootstrapu, a następnie uruchamiam z potencjalnym SPOF.

Lubimy sklep instancji. Zmusza nas to do uczynienia z naszych instancji całkowicie nadających się do recyklingu i możemy łatwo zautomatyzować proces budowania serwera od podstaw na danym interfejsie AMI. Oznacza to również, że możemy łatwo zamienić AMI. Ponadto EBS od czasu do czasu ma problemy z wydajnością.

Eric prawie go przybił. My ( Bitnami ) jesteśmy popularnym dostawcą darmowych AMI dla popularnych aplikacji i środowisk programistycznych (PHP, Joomla, Drupal, masz pomysł). Mogę powiedzieć, że AMI wspierane przez EBS są znacznie bardziej popularne niż wspierane przez S3. Ogólnie myślę, że instancje wspierane przez s3 są używane do rozproszonych zadań o ograniczonym czasie (na przykład przetwarzanie danych na dużą skalę), w których jeśli jedna maszyna ulegnie awarii, druga zostanie po prostu rozkręcona. Wspierane przez EBS systemy AMIS są zwykle używane do „tradycyjnych” zadań serwerowych, takich jak serwery sieciowe lub bazodanowe, które utrzymują stan lokalnie, a zatem wymagają dostępności danych w przypadku awarii.

Jednym aspektem, o którym nie wspomniałem, jest fakt, że podczas wykonywania można wykonywać migawki instancji wspieranej przez EBS, co skutecznie pozwala na tworzenie bardzo ekonomicznych kopii zapasowych infrastruktury (migawki są oparte na blokach i przyrostowe)

Na moim ostatnim stanowisku miałem dokładnie takie same doświadczenia jak Eric. Teraz w mojej nowej pracy przechodzę przez ten sam proces, który przeprowadziłem podczas mojej ostatniej pracy ... przebudowując wszystkie ich AMI dla instancji wspieranych przez EBS - i być może jako maszyny 32-bitowe (tańsze - ale nie mogę używać tego samego AMI na 32 i 64 maszyny).

Instancje wspierane przez EBS uruchamiają się wystarczająco szybko, abyś mógł zacząć korzystać z Amazon AutoScaling API, który pozwala używać metryk CloudWatch do wyzwalania uruchamiania dodatkowych instancji i rejestrowania ich w ELB (Elastic Load Balancer), a także do wyłączania ich, gdy już nie wymagany.

Tego rodzaju dynamiczne skalowanie automatyczne jest tym, o co chodzi w AWS - gdzie mogą się pojawić prawdziwe oszczędności w infrastrukturze IT. Prawidłowe skalowanie jest prawie niemożliwe przy użyciu starych instancji s3 „InstanceStore”.

Zaczynam dopiero korzystać z EC2, więc nie jestem ekspertem, ale z własnej dokumentacji Amazon wynika :

zalecamy korzystanie z lokalnego magazynu instancji dla danych tymczasowych, a dla danych wymagających wyższego poziomu trwałości zalecamy korzystanie z woluminów Amazon EBS lub tworzenie kopii zapasowych danych w Amazon S3.

Podkreśl moje.

Robię więcej analiz danych niż hosting, więc trwałość nie jest dla mnie tak ważna, jak dla witryny internetowej. Biorąc pod uwagę rozróżnienie dokonane przez samą Amazonkę, nie zakładam, że EBS jest odpowiedni dla wszystkich.

Postaram się pamiętać, aby ponownie ważyć po użyciu obu.

EBS jest jak wirtualny dysk maszyny wirtualnej:

• Trwałe instancje wspierane przez EBS można dowolnie uruchamiać i zatrzymywać (oszczędzając pieniądze)
• Można wykonać migawkę w dowolnym momencie, aby uzyskać kopie zapasowe w określonym momencie
• Pliki AMI można tworzyć z migawek EBS, więc wolumin EBS staje się szablonem dla nowych systemów

Pamięć instancji to:

• Lokalnie, więc ogólnie szybciej
• Brak połączenia z siecią, w normalnych przypadkach We / Wy EBS wiąże się z kosztem przepustowości sieci (z wyjątkiem przypadków zoptymalizowanych pod kątem EBS, które mają osobną przepustowość EBS)
• Ma ograniczoną liczbę operacji we / wy na sekundę we / wy. Nawet zabezpieczone wejścia / wyjścia maksymalne przy kilku tysiącach IOPS
• Kruchy. Gdy tylko instancja zostanie zatrzymana, stracisz wszystko w pamięci instancji.

Oto gdzie użyć każdego z nich:

• Użyj EBS do tworzenia kopii zapasowej partycji systemu operacyjnego i pamięci trwałej (dane DB, dzienniki krytyczne, konfiguracja aplikacji)
• Użyj pamięci instancji dla danych w procesie, niekrytycznych dzienników i przejściowego stanu aplikacji. Przykład: zewnętrzna pamięć sortowania, pliki tymczasowe itp.
• Pamięć instancji może być również używana do danych krytycznych pod względem wydajności, gdy występuje replikacja między instancjami (bazy danych NoSQL, rozproszone systemy kolejek / komunikatów oraz bazy danych z replikacją)
• Użyj S3 do danych współużytkowanych przez systemy: wejściowy zestaw danych i przetworzone wyniki lub do danych statycznych używanych przez każdy system po uruchomieniu.
• Użyj AMI dla wstępnie uruchomionych serwerów, które można uruchomić

Większość osób decyduje się na użycie instancji wspieranej przez EBS, ponieważ jest ona stanowa. Jest to bezpieczniejsze, ponieważ wszystko, co masz uruchomione i zainstalowane w nim, przetrwa zatrzymanie / zatrzymanie lub awarię dowolnego wystąpienia.

Sklep instancji jest bezstanowy, tracisz go wraz ze wszystkimi danymi w przypadku awarii instancji. Jest jednak bezpłatny i szybszy, ponieważ wolumin instancji jest powiązany z serwerem fizycznym, na którym działa maszyna wirtualna.

Dla kogoś nowego w tym wszystkim i jeśli przypadkiem tu wylądował

Obecnie wszystkie AMI w sekcji Szybki start są wspierane przez EBS

Istnieje również dobre wyjaśnienie w oficjalnym dokumencie dotyczące różnicy między EBS a sklepem Instance

i ten obraz w zasadzie podsumowuje

Jeśli uruchamiasz wiele instancji i przypisujesz zaplanowaną usługę wystąpienia AWS jako jeden z priorytetów unikania nieoczekiwanych opłat , odradzam korzystanie z magazynu instancji .

Jak wyjaśniono w dokumentacji Woluminów EBS i odpowiedzi od j2d3 i Siddharth Sharma, sklep z instancjami może działać tak długo, jak chcesz, ale nie można go zatrzymać . Oznacza, że ​​usługi nie można zaplanować za pomocą automatycznego uruchamiania / zatrzymywania lub odzyskiwania instancji .

Co więcej, dla tego rodzaju schematu nie ma również korzyści z korzystania z EBS Backed na Elastic Beanstalk, ponieważ ma on zapewnić, że wszystkie potrzebne zasoby będą działały . Zawsze będzie automatycznie uruchamiać ponownie wszelkie zatrzymane usługi. Przeglądając całą resztę , spośród wszystkich opłat za używanie VPC , EBS i ELB dodanych do EC2-Classic , EC2-VPC z ELB jest w większości najlepszym wyborem, w przeciwieństwie do EC2-Classic , zatrzymana instancja zachowuje powiązaną Elastyczność Adresy IPi wolumin EBS jest zapisywany automatycznie.

Podsumowując , biorąc główną część pytania:

wydaje się, że EBS jest o wiele bardziej użyteczny (stop, start, utrzymywanie + lepsza prędkość) przy stosunkowo niewielkiej różnicy kosztów ...?

Odpowiedź brzmi tak, ale jeśli twoja instancja jest oparta na EBS, można ją zatrzymać. Pozostanie na twoim koncie, nie zostaniesz za to obciążony . Będziesz obciążać tylko wolumen, ale EBS jest naliczany co godzinę . Możesz także wziąć pod uwagę, że spośród wszystkich dostępnych typów masz swobodę zmiany rozmiaru woluminu EBS .

Oprócz korzyści wymienionych już przez Erica , należy również pamiętać, że pod względem kosztu S3 może, ale nie musi, być tańszy niż EBS . Zgadzam się, że relatywnie niewielka różnica w kosztach, jeśli cały czas działa oba typy instancji na tej samej platformie i architekturze aplikacji.

Jeśli jednak istnieje scenariusz uruchomienia aplikacji w ramach usługi o niższych kosztach, wyciągnij wszystkie nieobsługiwane zadania i przypisz je do VPC / EBS za pomocą rurociągu lub lambda w krótkim czasie, powiedz <1 godzina dziennie, co jest niemożliwe, gdy użyj sklepu z instancjami , to będzie inna historia.