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


381

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?



również „mikro” jest dostępne tylko wtedy, gdy używasz instancji wspieranych przez EBS.
Ali,

1
Woluminy ze Sklepu Instancji są znacznie szybsze i nie zajmują miejsca w pamięci sieciowej!
Matt

Ja osobiście używam magazynu instancji do zrzucenia mojej działającej kolekcji MongoDB i umieszczenia jej w S3 z dwóch powodów. Najpierw jest oddzielony i nie zmniejszy prędkości zapisu na mojej 10-woluminowej macierzy RAID EBS. Po drugie, jest znacznie szybszy niż EBS, a ponieważ pochodzi z mojej instancji, nie ma sensu tworzyć dodatkowych woluminów EBS, aby wykonać zrzut i zniszczyć je po umieszczeniu ich w S3. mam nadzieję, że to pomoże, a nie konstruktywnie…
Maziyar,

2
Jestem w połowie drogi do Podręcznika użytkownika AWS (700 stron). Przeczytałem uważnie o EBS i pamięci masowej instancji. Nadal nie rozumiem, dlaczego istnieją takie różnice. I jeszcze bardziej zdziwiony, dlaczego sklep Instance jest odpowiednikiem S3, ale ma inną nazwę. Pytanie musi zostać ponownie otwarte, aby uzyskać większy wkład w przydatne odpowiedzi.
polimeraza

Odpowiedzi:


293

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.


4
Tak, powyższe również były moimi przemyśleniami ... Mam nadzieję, że w jakiś sposób tutaj pisze o swoich preferencjach dotyczących sklepu-instancji jako porównania ...
HelloWorldy,

5
EC2 wspierane przez sklep z instancjami można również ustawić tak, aby nie zostało przypadkowo zakończone.
Jim Soho,

44
Właściwie przełączam większość moich instancji EC2 wspieranych przez EBS na używanie magazynów instancji. To naprawdę zależy od tego, co chcesz osiągnąć. Zmieniam się z powodu lepszego IO i dlatego, że widzę każdą instancję EC2 jako jednorazową w każdej chwili, lub: zepsuje się z każdą minutą i stracę wszystko, co jest w takiej instancji. Architektura w ten sposób pomaga uzyskać prawdziwy system HA. Zobacz także stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html
Jim Soho

2
@Jim: Przynajmniej kiedy napisałem odpowiedź rok temu, masz dużo lepsze IO poprzez rozłożenie wielu instancji EBS w programowej konfiguracji RAID niż korzystanie z pamięci instancji. O wiele szybsze jest także uruchomienie instancji zastępczej z kopii zapasowej EBS niż z kopii zapasowej S3 (pamięć instancji jest ładowana z S3, co może być powolne). Przez ostatnie 6 miesięcy niewiele zrobiłem na AWS; rzeczy mogły się zmienić.
Eric J.

2
Wydaje się to trochę jednostronne - chociaż możliwe jest uruchamianie instancji wspieranych przez EBS i utrzymywanie dużego nacisku na możliwość recyklingu, myślę, że posiadanie nowych osób, które oglądają ten post, a następnie tworzenie instancji wspieranych przez EBS jest niebezpieczne, ponieważ prawdopodobnie nie utrzymają tego taki sam nacisk na recykling, który jest być może najważniejszym elementem każdej infrastruktury chmurowej. A znaczna większość ludzi, którzy na to patrzą, z pewnością będzie nowa w tych sprawach
Peter Berg,

69

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.


1
Czy jest jakaś znacząca poprawa wydajności IO dzięki wielkościom EBS IOPS w porównaniu ze standardowymi? Załóżmy, że powyższe dotyczy również woluminów EBS IOPS.
honzajde

4
Obie technologie ewoluują. Łączę ten komentarz w 2014 r., Kiedy mam „Provisioned IOPS” EBS, ale - „instancja sklepu” to teraz dysk SSD, który jest nawet szybszy niż wcześniej !! Przechowywanie efemeryczne zawsze wygrywa pod względem szybkości. Więc używam obu - zachowaj „trwałe” rzeczy w EBS, mając wszystkie pliki tymczasowe, logi, bazę danych „TempDB”, plik wymiany i inne rzeczy w sklepie Instance. KORZYŚCI Z OBU!
Alex

Co jeśli potrzebujesz rozproszonej bazy danych, która musi przechowywać swoje dane w sposób rozproszony i trwały. Czy nie potrzebujesz EBS, ponieważ pamięć instancji nie jest trwała?
CMCDragonkai

@CMCDragonkai Oczywiście, że tak. Obecnie dostępnych jest wiele opcji, np. AWS zaczęło oferować pamięć masową na dyskach SSD. Przejrzałbym je i ponownie przeprowadzę analizę (single vs. RAID itp.). Zastanowiłbym się również nad uzyskaniem jak największej liczby przypadków z powodu przepustowości sieci. EBS nadal stanowi problem w instancjach takich jak t1.micro.
Do

Część tej odpowiedzi na temat wydajności sieci jest dość przestarzała - od dłuższego czasu istniało wiele różnych przypadków, które można „zoptymalizować pod kątem EBS” za niewielką dodatkową opłatą, a niektóre takie są domyślnie (bez dodatkowej opłaty) ), które mają dedykowane interfejsy sieciowe do EBS, por. docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
Josip Rodin

41

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


6
Netflix przedstawia te same rekomendacje.
Kingz

2
Gdzie więc przechowujesz trwałe pliki oparte na blokach?
CMCDragonkai

17

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)


S3 ma wbudowaną redundancję. EBS nie ma żadnego , więc musisz wdrożyć oprogramowanie redundancji na nim.
Pacerier

2
@Pacerier To jest niepoprawne, według oficjalnej dokumentacji na docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html
Josip Rodin

16

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


13

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.


9

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ć

4

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.


2

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

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

wprowadź opis zdjęcia tutaj

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 wprowadź opis zdjęcia tutaj


0

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. wprowadź opis zdjęcia tutaj 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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.