AKTUALIZACJA (kwiecień 2015 r.) : W tym przypadku należy zacząć przyglądać się nowemu systemowi Amazon Elastic File System (EFS) , który został zaprojektowany do wielokrotnego dołączania dokładnie tak, jak chcesz. Kluczowa różnica między EFS i EBS polega na tym, że zapewniają one różne abstrakcje: EFS ujawnia protokół NFSv4, podczas gdy EBS zapewnia nieprzetworzony blokowy dostęp we / wy.
Poniżej znajdziesz moje oryginalne wyjaśnienie, dlaczego nie jest możliwe bezpieczne zamontowanie surowego urządzenia blokowego na wielu maszynach.
ORYGINALNY POST (2011):
Nawet gdybyś mógł podłączyć wolumen EBS do więcej niż jednej instancji, byłby to _REALLY_BAD_IDEA_. Cytując Kekoa: „to tak, jakby używać dysku twardego w dwóch komputerach naraz”
Dlaczego to zły pomysł? ... Powodem, dla którego nie można dołączyć woluminu do więcej niż jednej instancji, jest fakt, że EBS zapewnia abstrakcję „pamięci blokowej”, na której klienci uruchamiają system plików taki jak ext2 / ext3 / etc. Większość tych systemów plików (np. Ext2 / 3, FAT, NTFS itp.) Jest napisana przy założeniu, że mają wyłączny dostęp do urządzenia blokowego. Dwie instancje dostępu do tego samego systemu plików prawie na pewno zakończyłyby się łzami i uszkodzeniem danych.
Innymi słowy, podwójne montowanie woluminu EBS działałoby tylko wtedy, gdyby był uruchomiony klastrowy system plików, który jest przeznaczony do współużytkowania urządzenia blokowego między wieloma komputerami. Co więcej, nawet to nie wystarczy. EBS musiałby zostać przetestowany pod kątem tego scenariusza i aby upewnić się, że zapewnia te same gwarancje spójności, co inne rozwiązania współdzielonych urządzeń blokowych ... tj. Że bloki nie są buforowane na pośrednich niewspółdzielonych poziomach, takich jak jądro Dom0, warstwa Xen, i jądro DomU. Do tego dochodzi kwestia wydajności synchronizacji bloków między wieloma klientami - większość klastrowych systemów plików jest zaprojektowana do pracy w dedykowanych sieciach SAN o dużej szybkości, a nie w standardowej sieci Ethernet. Brzmi to tak prosto, ale to, o co prosisz, jest bardzo nietrywialne.
Możesz też sprawdzić, czy scenariusz udostępniania danych może obejmować NFS, SMB / CIFS, SimpleDB lub S3. Wszystkie te rozwiązania wykorzystują protokoły wyższych warstw, które są przeznaczone do udostępniania plików bez współdzielonego podsystemu urządzeń blokowych. Często takie rozwiązanie jest faktycznie bardziej wydajne.
W Twoim przypadku nadal możesz mieć jedną instancję / serwer plików MySql, do której dostęp ma wiele interfejsów WWW. Ten serwer plików może następnie przechowywać swoje dane na woluminie EBS, umożliwiając tworzenie nocnych kopii zapasowych migawek. Jeśli instancja, na której działa serwer plików, zostanie utracona, można odłączyć wolumin EBS i ponownie podłączyć go do nowej instancji serwera plików, aby w ciągu kilku minut można było zarchiwizować i uruchomić.
„Czy istnieje coś takiego jak S3 jako system plików?” - tak i nie. Tak, istnieją rozwiązania innych firm, takie jak s3fs, które działają „dobrze”, ale nadal muszą wykonywać stosunkowo drogie wywołania usługi sieciowej dla każdego odczytu / zapisu. W przypadku wspólnego narzędzia reż, działa świetnie. W przypadku klastrowego użycia FS, które widzisz w świecie HPC, nie ma szans. Aby działać lepiej, potrzebujesz nowej usługi, która zapewnia binarny protokół zorientowany na połączenie, taki jak NFS. Oferowanie takiego wielomonontowanego systemu plików z rozsądną wydajnością i zachowaniem byłoby WSPANIAŁYM dodatkiem do EC2. Od dawna jestem zwolennikiem Amazon, aby zbudować coś takiego.