AWS: использование обычной файловой системы на многопользовательском томе EBS в сценарии с одним писателем и многими читателями

AWS: использование обычной файловой системы на многопользовательском томе EBS в сценарии с одним писателем и многими читателями

Я хочу поделиться данными между несколькими экземплярами AWS с высокой производительностью и низкой задержкой. Предоставление всем экземплярам доступа только для чтения (кроме одного экземпляра, который будет обрабатывать записи) — это нормально. Два момента об этом варианте использования:

  1. Узлы, подключенные к тому, могут появляться и исчезать в любое время (запускаться, останавливаться, завершаться и т. д.).
  2. Общие данные включают в себя тысячи потенциально небольших файлов, которые необходимо перечислить и проверить метаданные.

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

Итак, теперь я рассматриваю EBS multi-attach. Однако, чтобы предотвратить повреждение данных, AWS рекомендует использовать только кластерную файловую систему, такую ​​как GFS2 или OCFS. Обе они кажутся сложными и капризными в настройке, а также хрупкими для использования в кластере, где узлы могут появляться и исчезать в любое время. Например, GFS2 требует перезапуска программного обеспечения кластера на всех узлах, если количество узлов увеличивается с более чем 2 до ровно 2; или добавление нового узла подразумевает вход в текущий узел, выполнение некоторых команд и, возможно, повторное распространение обновленного файла конфигурации на все остальные узлы. Это просто кажется действительно негибким, а также большим количеством дополнительных накладных расходов.

Но если бы я был уверен, что только 1 экземпляр будет выполнять запись на диск (или, возможно, каждый экземпляр мог бы писать только в свою собственную подпапку или даже раздел диска), мог бы я использовать обычную файловую систему, например XFS, для этого тома и избежать этого? Или возникнут ли бы тонкие проблемы с повреждением данных, даже если доступ технически только для чтения или доступ на запись ограничен подпапками или разделами, специфичными для экземпляра?

Или есть совершенно другое решение, которое я упускаю?

решение1

Я протестировал это (XFS), и это не работает. Вам нужна кластерная файловая система. Лучше всего использовать кластерную файловую систему. Рассмотрите другие варианты, такие как Veritas Infoscale.

решение2

Совместное использование статического содержимого тома, по-видимому, работает нормально с multi-attach и обычной XFS. Горячие «добавления» к тому видны только экземпляру, который записал данные. Установив это, я не тестировал горячие «обновления» или «удаления», предполагая, что они также будут видны только автору, но могут потенциально нарушить доступ к этим данным для других экземпляров. Перезагруженные, перезапущенные и/или повторно подключенные экземпляры видят последнее состояние тома. Таким образом, вариант использования, когда один экземпляр записывает новые данные нечасто, что вызывает, например, принудительные перезагрузки для других, чтобы в конечном итоге увидеть эти данные, по-видимому, является вариантом использования, который эта технология может поддерживать.

Связанный контент