Можно ли подключить Amazon EBS к нескольким инстансам?

В настоящее время мы используем несколько веб-серверов, обращающихся к одному серверу mysql и файловому серверу. Рассматривая переход в облако, могу ли я использовать ту же настройку и подключить EBS к нескольким экземплярам компьютеров или какое еще решение?

ОБНОВЛЕНИЕ (апрель 2015 г.) . Для этого варианта использования вам следует обратить внимание на новую эластичную файловую систему Amazon (EFS) , которая предназначена для множественного присоединения именно так, как вы хотите. Ключевое различие между EFS и EBS заключается в том, что они предоставляют разные абстракции: EFS предоставляет протокол NFSv4, тогда как EBS обеспечивает доступ к необработанному блоку ввода-вывода.

Ниже вы найдете мое первоначальное объяснение того, почему невозможно безопасно смонтировать необработанное блочное устройство на нескольких машинах.

ОРИГИНАЛЬНАЯ СТАТЬЯ (2011 г.):

Даже если вам удалось подключить том EBS к нескольким экземплярам, ​​это будет _REALLY_BAD_IDEA_. По словам Кекоа, «это похоже на использование жесткого диска сразу на двух компьютерах».

Почему это плохая идея? ... Причина, по которой вы не можете прикрепить том более чем к одному экземпляру, заключается в том, что EBS предоставляет абстракцию «блочного хранилища», на которой клиенты запускают файловую систему, такую ​​как ext2 / ext3 / и т. Д. Большинство этих файловых систем (например, ext2 / 3, FAT, NTFS и т.д.) написаны с предположением, что они имеют монопольный доступ к блочному устройству. Два экземпляра, обращающиеся к одной и той же файловой системе, почти наверняка закончились бы слезами и повреждением данных.

Другими словами, двойное монтирование тома EBS будет работать только в том случае, если вы используете кластерную файловую систему, которая предназначена для совместного использования блочного устройства между несколькими машинами. Более того, даже этого было бы недостаточно. EBS необходимо протестировать для этого сценария и убедиться, что он обеспечивает те же гарантии согласованности, что и другие решения для совместно используемых блочных устройств ... т. Е. Что блоки не кэшируются на промежуточных не общих уровнях, таких как ядро ​​Dom0, уровень Xen, и ядро ​​DomU. А еще есть соображения производительности синхронизации блоков между несколькими клиентами - большинство кластерных файловых систем предназначены для работы в высокоскоростных выделенных сетях SAN, а не в обычных сетях Ethernet. Это звучит так просто, но то, о чем вы просите, является очень нетривиальной вещью.

В качестве альтернативы посмотрите, может ли ваш сценарий совместного использования данных быть NFS, SMB / CIFS, SimpleDB или S3. Все эти решения используют протоколы более высокого уровня, которые предназначены для обмена файлами без наличия подсистемы общих блочных устройств. Во многих случаях такое решение действительно более эффективно.

В вашем случае у вас все еще может быть один экземпляр MySql / файловый сервер, к которому обращаются несколько веб-интерфейсов. Затем этот файловый сервер может хранить свои данные на томе EBS, что позволяет создавать резервные копии моментальных снимков каждую ночь. Если экземпляр, на котором запущен файловый сервер, потерян, вы можете отсоединить том EBS и повторно подключить его к новому экземпляру файлового сервера, после чего резервное копирование будет выполнено за считанные минуты.

"Есть ли что-нибудь вроде S3 в качестве файловой системы?" - да и нет. Да, есть сторонние решения, такие как s3fs, которые работают «нормально», но им все равно приходится делать относительно дорогие вызовы веб-сервисов для каждого чтения / записи. Для общего каталога инструментов отлично работает. Для того типа кластерного использования FS, который вы видите в мире высокопроизводительных вычислений, это не шанс. Чтобы добиться большего, вам понадобится новая служба, которая предоставляет двоичный протокол, ориентированный на соединение, например NFS. Предложение такой мультимонтированной файловой системы с разумной производительностью и поведением было бы БОЛЬШОЙ функцией для EC2. Я долгое время был сторонником того, чтобы Amazon создала что-то подобное.

Обновление (2020) Теперь это возможно!

Теперь это возможно благодаря новейшим типам инстансов, запущенным в AWS Nitro в одной зоне доступности. Есть некоторые предостережения, но это отлично подходит для определенных случаев использования, когда требуется скорость EBS и где использование EFS невозможно.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

Оригинальный пост (2009)

Нет, это похоже на использование жесткого диска на двух компьютерах.

Если вам нужны общие данные, вы можете настроить сервер, к которому будут иметь доступ все ваши экземпляры. Если вам нужна простая область хранения для всех ваших инстансов, вы можете использовать службу хранения Amazon S3 для хранения данных, которые распределяются и масштабируются.

При переходе в облако у вас может быть точно такая же настройка, но вы можете заменить файловый сервер на S3 или подключить все свои экземпляры к вашему файловому серверу.

У вас есть много вариантов, но совместное использование жесткого диска между экземплярами, вероятно, не лучший вариант.

Нет, согласно документам EBS: «Том может быть присоединен только к одному экземпляру за раз».

Как вы в настоящее время используете общее хранилище? Если это просто для обслуживания файлов с файлового сервера, рассматривали ли вы возможность настройки системы, чтобы вы могли передавать определенные запросы процессу на файловом сервере, вместо того, чтобы веб-серверы обслуживали эти файлы?

Я почти уверен, что вы не можете, но вы можете клонировать EBS и прикрепить его к другому экземпляру.

Это полезно для фиксированных наборов данных или для тестирования «реальных» данных, но не позволяет более 1 экземпляру работать с одним хранилищем блоков.

Несколько веб-серверов, обращающихся к серверу MySQL и файловому серверу, являются нормальным явлением в AWS. Некоторые из лучших практик, которым следует следовать для вышеупомянутой архитектуры:

Пункт 1) MySQL на EC2 может быть настроен как ведущий-ведомый в асинхронном / полусинхронном режиме в AWS. EBS-OPT + PIOPS в RAID 0 рекомендуется для высокопроизводительных БД.

Пункт 2) В качестве альтернативы вы можете использовать режим Amazon RDS + Multi-AZ. Для масштабирования чтения к MySQL RDS можно подключить несколько реплик чтения RDS.

Пункт 3) Том EBS нельзя подключить к нескольким EC2 одновременно. Вы можете создать файловый сервер на основе GlusterFS на Amazon EC2 с помощью EBS. Несколько веб-серверов могут одновременно взаимодействовать с одной GlusterFS в инфраструктуре AWS.

Пункт 4) Если ваше приложение может быть интегрировано с S3 в качестве хранилища файлов, то это предпочтительнее из-за стабильности, которую он привносит в архитектуру. Вы также можете получить доступ к S3 с помощью таких инструментов, как S3fuse, а также из своего приложения.

EBS только что объявила, что это возможно: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

В мире ИТ есть что-то, известное как Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS ...

Короткий ответ - категорическое «Нет». Другие сказали это выше.

Те, кто сказал «да», ответили не на вопрос, а на другой. Если EFS - это просто служба NFS, то это не ответ на вопрос, как это было изначально указано. И не имеет значения, «развернута ли EFS во всех зонах» или нет, потому что вы можете создать свой собственный экземпляр NFS и установить NFS на нескольких серверах. В этом нет ничего нового, мы уже сделали это в 1992 году. SMB и sshfs, все это всего лишь способы монтировать диски в качестве удаленной файловой системы.

Те, кто сказал «зачем вам это делать» или «все закончится слезами», ошибаются. Мы устанавливаем несколько дисков на несколько серверов в течение десятилетий. Если вы когда-либо работали с SAN (Storage Area Network), возможность подключения одного и того же устройства к нескольким узлам, как правило, через FibreChannel SAN, совершенно нормально. Таким образом, любой, кто запускал серверы десять лет назад до того, как виртуализация / облачные серверы стали повсеместными, имеет некоторое влияние на это.

Вскоре появились кластерные файловые системы, в которых две системы могли читать и писать на один и тот же том. Я считаю, что это началось уже с VAX и Alpha VMS. Кластерные файловые системы используют схему распределенного взаимного исключения, чтобы иметь возможность напрямую управлять блоками.

Преимущество установки одного и того же диска на несколько узлов заключается в скорости и сокращении единичных точек отказа.

Сейчас кластерные файловые системы не стали очень популярными в бизнесе "потребительского" хостинга, это правда. И они сложные, и в них есть подводные камни. Но вам даже не нужна кластерная файловая система, чтобы использовать диск, подключенный к нескольким вычислительным узлам. Что делать, если вам нужен диск только для чтения? Вам даже не нужна кластерная файловая система! Вы просто помещаете в свой / etc / fstab то же физическое устройство, что и только для чтения (ro). Затем вы подключаетесь к 2 или 10 серверам EC2, и все они могут читать прямо с этого устройства!

Это очевидный вариант использования в мире облачных серверов при построении быстро масштабируемых ферм. Вы можете полностью подготовить свой основной системный диск и использовать только очень маленький загрузочный и конфигурационный диск для каждого из серверов. Вы даже можете заставить их всех загружаться с одного загрузочного диска, и прямо перед перемонтированием / в режиме чтения-записи вы можете вставить Union-FS с 3 уровнями:

1. Основной системный диск, доступный только для чтения, с загрузкой, ядром и установкой пользовательской среды
2. Файловая система конфигурации, состоящая только из нескольких файлов (в основном в / etc), специфичных для отдельного сервера. Этот диск может быть записан другим сервером для подготовки к загрузке нового экземпляра. Примеры файлов здесь будут / etc / hostname и очень мало файлов конфигурации, которые должны оставаться разными для каждого узла.
3. Записываемый диск, который может вам вообще не понадобиться, может быть просто / tmp в качестве файловой системы памяти.

Итак, да, вопрос имел большой смысл, и, к сожалению, ответ (все еще) «Нет». И никакой NFS не является отличной заменой для этого варианта использования, поскольку он штрафует все операции чтения с системного диска. Однако сетевая загрузка с системного диска NFS - единственная альтернатива реализации варианта использования, который я описал выше. К сожалению, поскольку настроить сетевой загрузочный агент и NFS гораздо сложнее, чем просто получить доступ к одному и тому же физическому блочному устройству.

PS: Я хотел бы представить более короткую версию этого в качестве комментариев, но я не могу из-за глупого порога в 51 кредитный балл, поэтому я должен написать ответ с тем же важным «Нет», но включить мою точку зрения, почему это актуальный вопрос, на который не получил заслуженного ответа.

PPS: Я только что нашел в StackExchange, что кто-то упомянул iSCSI. iSCSI чем-то похож на NFS, но логически похож на FibreChannel SAN. Вы получаете доступ к физическим блочным устройствам (и их совместное использование). Это упростит совместное использование загрузочного диска, поэтому вам не нужно настраивать загрузку по сети, которая может быть привередливой. Но тогда и на AWS загрузка по сети также недоступна.

Хотя раньше EBS позволяла подключать только один экземпляр EC2 к данному тому, теперь возможно множественное подключение, по крайней мере, для томов io1. Дополнительные сведения см. В этом сообщении в блоге AWS .

Почему бы вам не создать один экземпляр с томом и sshfs для этого тома в других экземплярах?

Вы можете полностью использовать один диск на нескольких серверах в AWS. Я использую sshfs для подключения внешнего диска и совместного использования его с несколькими серверами в EC2.

Причина, по которой мне нужно было подключить один диск к нескольким серверам, заключается в том, чтобы иметь единое место для хранения всех моих резервных копий, прежде чем загружать их локально.