2012-02-03 22 views
19

Zastanawiam się, które byłoby lepsze, do hostowania witryny na EC2 z wieloma mikro instancjami lub mniejszych instancji takich jak m1.large. Wszyscy będą siedzieć za jednym lub kilkoma większymi instancjami jako równoważniki obciążenia. Powiem, jakie jest moje zrozumienie, a każdy, kto wie lepiej, może dodać lub poprawić mnie, jeśli się mylę.Serwer EC2, dużo mikro instancji lub mniejszych instancji?

Głównym powodem wyboru mikroinstancji jest koszt. Pojedyncza mikro instancja da średnio 0,35ECU za 0,02 USD/godzinę, podczas gdy jedna mała instancja da 1 ECU za 0,085 USD. Jeśli wykonasz matematykę $/ECU/godz., Mikro wystąpienie wyniesie 0,057 $/ECU/godzinę, podczas gdy dla małej instancji to 0,085 $/ECU/godzinę. Tak więc przy tej samej średniej mocy obliczeniowej wybór 100 mikro instancji byłby tańszy niż 35 małych instancji.

Główny problem z mikroinstancjami to bardziej zmienna wydajność, ale nie jestem pewien, czy będzie to mniejszy problem, gdy masz wiele instancji.

Czy ktokolwiek ma doświadczenie w takich ustawieniach i dostrzega zalety i wady? Daj mi znać, gdy próbuję wybrać, którą drogą iść, dzięki!

PS: artykuł na ten temat, http://huanliu.wordpress.com/2010/09/10/amazon-ec2-micro-instances-deeper-dive/

Odpowiedz

0

powiedziałbym: zależy od tego, jaki rodzaj architektury aplikacja będzie mieć i ile wiarygodne będzie musiała być:

  • AWS równoważenia obciążenia robi nie zapewnia natychmiastowego (może w czasie rzeczywistym jest lepszym słowem?) auto-scale, która różni się koncepcją fail-over. Od czasu do czasu współpracuje z testami kondycji i ma niewielkie opóźnienie, ponieważ jest to odbywa się za pośrednictwem żądań http (więcej narzutów, jeśli wybierzesz https).
  • Będziesz mieć więcej punktów awarii, jeśli wybierzesz więcej instancji w zależności od architektury. Aby tego uniknąć, Twoja aplikacja będzie musiała być asynchroniczna między instancjami.
  • Musisz porównać i przetestować więcej aplikacji, jeśli wybierzesz więcej instancji , aby zagwarantować, że te impulsy nie będą miały wpływu na twoją aplikację.

To jest mój punkt widzenia i byłaby to bardzo przyjemna dyskusja pomiędzy doświadczonymi ludźmi.

+0

Dzięki za odpowiedź. Nie wiem, jak działa ELB (i słyszałem o niezbyt wielkich doświadczeniach z nim związanych od innych ludzi), ale używam HAProxy, a zawieszenie jest generalnie w czasie rzeczywistym (z testami 500 lub 1000 ms) . Sprawdzanie odbywa się również za pomocą żądania HEAD lub OPTION, więc obciążenie nie powinno być tak duże, ale zdecydowanie istnieje. Mam też na myśli głównie serwery aplikacji z bazą danych w innym miejscu, więc same serwery aplikacji są niezależne, a niektóre z nich mogą nie być problemem, ale myślę, że kręcenie instancjami zastępującymi zajmuje trochę czasu, co wpływa na wydajność na pewno. – Jd007

12

Uważaj na mikro-instancje, one mogą Cię ugryźć. W środowisku mikroprzypadkowym mamy środowisko testowe. Ponieważ są po prostu funkcjonalnym środowiskiem testowym, działa sprawnie. Jednak zdarzyło się, że mamy aktualizację jakiejś aplikacji (dobrze, Jetty 7.5.3), która ma błąd związany z wyższym zużyciem procesora. Dzięki temu te instancje były bezużyteczne, ponieważ Amazon ogranicza dostępny procesor do 2%.

Ponadto mikro instancje są wspierane przez EBS. EBS jest niezawodny (ponad sklep-instancję) dla operacji wysokiego poziomu, takich jak te wymagane dla Cassandra or the likes.

Jeśli chcesz zaoszczędzić pieniądze, a twoje oprogramowanie to architected to handle interruptions, możesz wybrać instancje dodatkowe. One zwyklecost less than on-demand ones.

Jeśli to wszystko nie jest dla ciebie problemem, chciałbym powiedzieć, że mikro-instancje to najlepsza droga!:)