Как настроить общее постоянное хранилище для нескольких экземпляров AWS EC2?

Question

У меня есть служба, размещенная на веб-сервисах Amazon. Там у меня несколько экземпляров EC2, работающих с точно такими же настройками и данными, которые управляются с помощью балансировки эластичной нагрузки и масштабирования.

Эти экземпляры представляют собой веб-серверы, на которых запущены веб-приложения на основе PHP. Таким образом, в настоящее время на всех экземплярах размещаются те же файлы и т. Д. Но когда группа ELB/scaling запускает новый экземпляр, основанный на правилах загрузки и т. Д., Файлы могут быть несовременными. Кроме того, я бы предпочел использовать общую файловую систему для сеансов PHP и т. Д., Чем липкие сеансы.

Итак, мой вопрос по этим причинам и, возможно, больше подходит в будущем, я хотел бы иметь общий объект файловой системы, который я могу подключить к своим экземплярам EC2. Какой способ вы могли бы предложить решить эту проблему? Есть ли какие-либо решения, предлагаемые AWS напрямую, поэтому я могу полагаться на их услуги, а не делать это на моем с DRBD и так далее? Какой самый простой подход? DRBD, NFS, ...? Возможна ли S3 для тех, кто намеревается?

Заранее спасибо.

Answer 1

Как упоминалось в комментарии, AWS объявила EFS (http://aws.amazon.com/efs/) общую сетевую файловую систему. В настоящее время он находится в очень ограниченном предварительном просмотре, но, основываясь на предыдущих услугах AWS, я надеюсь, что он будет доступен в течение следующих нескольких месяцев.

В то же время существуют несколько третьей стороны совместно системные решения файлов для AWS, таких как SoftNAS https://aws.amazon.com/marketplace/pp/B00PJ9FGVU/ref=srh_res_product_title?ie=UTF8&sr=0-3&qid=1432203627313

S3 возможно, но не всегда идеально, главным блокатор является его изначально не поддерживает никаких протоколов файловой системы, а все взаимодействия должны осуществляться через API AWS или через HTTP-вызовы. Кроме того, при использовании его для сессионных магазинов модель «в конечном счете последовательная», вероятно, вызовет проблемы.

Это означает, что если вам нужны обновленные ресурсы, вы можете создать простой скрипт для запуска либо как cron, либо при запуске, который загружает файлы из s3.

Наконец, в случае статических ресурсов, таких как css/images, их не хранить на вашем веб-сервере в первую очередь - есть много статей, посвященных сохранению и доступу к статическим веб-ресурсам непосредственно из s3, сохраняя динамические на вашем сервере.

Answer 2

До Amazon EFS показов продукции лучший подход, на мой взгляд, заключается в том, чтобы построить хранилище, экспортирующее NFS из экземпляров EC2, возможно, используя Pacemaker/Corosync для достижения HA.

Вы можете создать том EBS, в котором хранятся файлы, и инструктировать кардиостимулятор для umount/dettach, а затем подключить/подключить том EBS к здоровому узлу кластера NFS.

Answer 3

Для синхронизации сеансов веб-сервера вы можете легко переключиться на Redis или Memcached в качестве обработчика сеанса. Это простая настройка в PHP.ini, и все они могут обращаться к тому же серверу Redis или Memcached для сеансов. Вы можете использовать Elasticache Amazon, который будет управлять экземпляром Redis или Memcache для вас.

http://phpave.com/redis-as-a-php-session-handler/ < - объясняет, как настроить Redis с PHP довольно легко

Для сохранения файлов в синхронизации немного сложнее.

Как мне навязать новые изменения кода ко всем моим веб-серверам?

Вы можете использовать Git. При развертывании вы можете настроить несколько серверов, и он будет перенаправлять ваш филиал (мастер) на несколько серверов. Поэтому каждая новая сборка выходит на все веб-серверы.

насчет новых машин, которые запускают?

Я бы установил новые машины для запуска сценария rsync из надежного источника, вашего веб-сервера. Таким образом, они синхронизируют свои веб-папки с мастером, когда они загружаются и будут идентичны, даже если у AMI были старые веб-файлы.

Как насчет файлов, которые меняются и нуждаются в обновлении?

Хранить любые загруженные пользователем файлы в S3. Поэтому, если пользователь загружает документ на Сервер 1, тогда файл хранится в s3, и местоположение хранится в базе данных. Затем, если другой пользователь находится на сервере 2, он может видеть тот же файл и получать доступ к нему, как если бы он находился на сервере 2. Файл был бы извлечен из s3 и отправлен клиенту.

Answer 4

Привет, мы в настоящее время используем продукт под названием SoftNAS в нашей среде AWS. Это позволяет нам выбирать между резервным хранилищем EBS и S3. Он имеет встроенную репликацию, а также вариант высокой доступности. Может быть, вы можете проверить. Я считаю, что они предлагают бесплатную пробную версию, которую вы можете опробовать на AWS

Answer 5

Из того, что мы можем сказать на этом этапе, ожидается, что EFS обеспечит общий общий доступ к файлам NFS на накопителе с поддержкой SSD. Как только он будет доступен, он будет файловой системой v1.0. Нет шифрования и его AWS-only. Данные полностью находятся под управлением AWS.

SoftNAS - это зрелый, проверенный на основе ZFS NAS Filer, который является полнофункциональным, включая зашифрованные хранилища EBS и S3, снимки хранилищ для защиты данных, записываемые клоны для тестирования DevOps и QA, кеширование ОЗУ и SSD для максимальной IOPS и пропускную способность, дедупликацию и сжатие, межзональную HA и 100% SLA. Он поддерживает NFS с аутентификацией LDAP и Active Directory, CIFS/SMB с пользователями/группами AD, многоадресной рассылкой iSCSI, FTP и (скоро) AFP. Экземпляры SoftNAS и все хранилища полностью находятся под вашим контролем, и вы полностью контролируете шифрование и ключи EBS и S3 (вы можете использовать шифрование EBS или любой подход к шифрованию и управлению ключами Linux, который вы предпочитаете или требуете).

Файловая система ZFS является проверенной файловой системой, которой доверяют тысячи предприятий во всем мире. В настоящее время на SoftNAS работает более 600 миллионов файлов на производстве - ZFS способна масштабироваться в миллиарды.

SoftNAS является кросс-платформенным и работает на облачных платформах, отличных от AWS, включая Azure, Cloud Cloud Cloud, облако Faction, VMware vSPhere/ESXi, VMware vCloud Air и Hyper-V, поэтому ваши данные не ограничены или не блокируются AWS. Планируется больше платформ. Он обеспечивает кросс-платформенную репликацию, позволяя легко переносить данные между любыми поддерживаемыми облачными облачными областями, облачным облаком или центром данных, основанным на предпосылках.

SoftNAS поддерживается отраслевой технической поддержкой специалистов по облачным хранилищам (это все, что мы делаем), что-то вам может понадобиться или нужно.

Это некоторые из наиболее примечательных различий между EFS и SoftNAS. Для более детальной диаграммы сравнения:

https://www.softnas.com/wp/nas-storage/softnas-cloud-aws-nfs-cifs/how-does-it-compare/

Если вы готовы свернуть свой собственный кластер HA NFS, и нести ответственность за его уход, питание и поддержку, то вы можете использовать Linux и DRBD/corosync или любой количество других подходов к кластеризации Linux. Вы должны будете поддерживать его самостоятельно и нести ответственность за все, что происходит.

Существует также GlusterFS. Он хорошо подходит для 250 000 файлов (в нашем тестировании) и, как было замечено, страдает от обхода IOPS при приближении к 1 миллиону файлов, а IOPS отключается от 1 миллиона файлов (по словам клиентов, которые его использовали). Для небольших развертываний он, как сообщается, работает достаточно хорошо.

Надеюсь, что это поможет.

CTO - SoftNAS

Answer 6

Мы используем ObjectiveFS, и она работает хорошо для нас. Он использует S3 для хранения и прямо настроен для настройки.

Они также написали документ о том, как обмениваться файлами между экземплярами EC2. http://objectivefs.com/howto/how-to-share-files-between-ec2-instances

Answer 7

GlusterFS также с открытым исходным кодом распределенной файловой системы используется многими для создания общего хранилища через EC2 экземпляров