2009-03-15 21 views
12

Spędziłem dzień eksperymentując z AWS po raz pierwszy. Mam uruchomioną instancję EC2 i zamontowałem Elastic Block Store (EBS), aby zachować bazy danych MySQL.EBS do przechowywania baz danych a plików stron WWW

Czy ma sens umieszczanie moich plików aplikacji internetowych na EBS, czy powinienem je wdrożyć w normalnym systemie plików EC2?

+0

Nikt nie zna Twoich wymagań poza Tobą. Może powinieneś wyhodować ... –

+0

Wziął udział w obronie, ponieważ jest to całkowicie uzasadnione pytanie. –

+0

Jak podkreśla Kevin Peterson w swojej odpowiedzi, bardzo istotne byłoby wiedzieć, czy chodziło o wdrożony kod lub pliki danych. – Jonik

Odpowiedz

7

Kiedy wypowiadasz swoje pliki aplikacji internetowych, nie jestem pewien, do czego dokładnie się odwołujesz.

Jeśli chodzi o wdrożony kod, prawdopodobnie nie ma sensu korzystanie z EBS. To, co chcesz zrobić, to stworzyć AMI z wymaganiami wstępnymi, a następnie mieć skrypt do utworzenia instancji tego AMI i wdrożenia najnowszego kodu. Gorąco polecam zautomatyzować i przetestować ten proces, ponieważ łatwo zapomnieć o niektórych ustawieniach, które musisz ręcznie zmienić.

Jeśli przechowujesz pliki danych, które są modyfikowane przez uruchomioną aplikację, EBS może mieć sens. Jeśli jest to coś w rodzaju obrazów przesłanych przez użytkownika lub podobnych, najprawdopodobniej okaże się, że S3 daje o wiele prostszy model.

EBS byłoby dobre dla: baz danych, indeksów lucenowych, baz danych na plikach, repozytoriów SVN lub czegoś podobnego do tego.

+1

+1, jest to najwyraźniejsza odpowiedź tutaj.Ponadto, jeśli OP będzie się zastanawiał nad szybkością EBS i pamięci instancji, powinien to sprawdzić: http://serverfault.com/questions/111594/which-is-faster-for-read-read-on-ec2-local -drive-or-ebs – Jonik

2

EBS zapewnia stałe przechowywanie, więc jeśli wystąpienie EC2 nie powiedzie się pliki nadal istnieją. Wygląda na to, że ich wydajność IO jest większa, ale chciałbym to sprawdzić.

2

Jeśli twoje pliki będą się często zmieniać (tak jak robi DB) i nie chcesz ich synchronizować z S3 (lub gdzieś indziej), to dobrym rozwiązaniem jest EBS. Jeśli wprowadzasz nieczęste zmiany i możesz ręcznie (lub skryptowo) zsynchronizować pliki w razie potrzeby, zapisz je w S3. Jeśli chcesz zamknąć lub utracisz instancję z dowolnego powodu, po prostu możesz je usunąć podczas uruchamiania nowej instancji. Zakłada to również, że zależy Ci na koszcie. Jeśli koszt nie stanowi problemu, korzystanie z EBS jest mniej skomplikowane. Nie jestem pewien, czy planujesz mieć oddzielne EBS dla twojego DB i twoich plików sieciowych, ale jeśli planujesz tylko mieć jeden EBS i masz wystarczająco dużo wolnego miejsca na to dla twoich plików sieciowych, to znowu, EBS jest mniejszy skomplikowane. Jeśli chodzi o wydajność, o którą się martwisz, jak wspomniano, najlepiej przetestować konkretną aplikację.

1

Nasze podejście polega na umieszczeniu skryptu w naszym AMI, który pobiera najnowszą i najlepszą wersję kodu z kontroli źródła. Ułatwia to szybkie uruchamianie nowych instancji lub aktualizowanie wszystkich działających instancji (usuwamy je z rotacji równoważenia obciążenia po jednym na raz, uruchamiamy skrypt i umieszczamy z powrotem w rotacji).

UPDATE:

Czytając między wierszami to wygląda jakbyś montażu oddzielny wolumin EBS do instancji-store backed instancji. AWS niedawno wprowadził instancje wspomagane EBS, które mają mnóstwo korzyści w porównaniu ze starszymi wersjami sklepu z instancjami. Nadal montuję dane MySQL na oddzielnej partycji EBS, dzięki czemu mogę w razie potrzeby łatwo zamontować go na innym serwerze.

Zdecydowanie sugeruję instancję wspieraną przez EBS z oddzielnym woluminem EBS dla danych MySQL.