Общие файловые системы между несколькими экземплярами AWS EC2
У меня есть несколько экземпляров сервера Windows, работающих на Amazon EC2, и я хотел бы сделать их более отказоустойчивыми, запустив дублирующий экземпляр с балансировщиками нагрузки.
Проблема заключается в конкретных данных, например, нецелесообразно переключаться с одного веб-сервера на другой веб-сервер, если содержимое корневого каталога документа, то есть C: / htdocs / (Apache) или C: / Repositories (VisualSvn Server) не идентичны.
Есть ли способ разделить том между двумя или более экземплярами?
Моя идея - это общая папка между EC2 istances:
прочтите, что невозможно подключить один и тот же том EBS к нескольким экземплярам. Я считаю, что AWS также не поддерживает NFS, если я хочу смонтировать их через NFS.
И, наконец, я также проверил ведро S3, установленное с помощью s3fs, но обнаружило, что это тоже не лучший вариант.
Может ли кто-нибудь помочь мне указать в правильном направлении?
Это вариант использования, который давно используется в AWS. Как описано в эта тема, двумя распространенными способами добиться этого было использование S3 или NFS для разделения доступа к данным между экземплярами.
На 9 апреля 2015 г., Объявила Amazon Amazon Elastic File System (Amazon EFS), который обеспечивает то, что вы просите на своей диаграмме.
Невозможно использовать один том EBS для нескольких экземпляров EC2.
Ваша диаграмма выгружает данные на общий сервер. Однако этот разделяемый сервер - это просто еще одна точка отказа. Таким образом, вы ничего себе не экономите: если зона доступности этого сервера выходит из строя, вы теряете данные, даже если веб-сервер / сервер VisualSVN в другой зоне доступности все еще работает.
Вы должны разделить свой сервер между двумя отдельными функциями на два отдельных сервера / кластера, чтобы они могли обрабатываться независимо друг от друга:
- веб-сервер и
- VisualSVN сервер
Что касается веб-сервера, вам действительно нужно зеркалировать том в сценарии с несколькими экземплярами, или вы можете сохранить свои экземпляры с возможностью завершения в любое время без потери данных? В идеале вы не должны сохранять какие-либо данные локально в экземпляр. Вместо этого вы можете сохранить все данные вне сервера в базе данных или в Amazon S3. Таким образом, данные доступны для всех экземпляров в любое время. Если сервер потерян, никаких данных не будет. Сделайте свой «главный» AMI и создайте все экземпляры в группе автоматического масштабирования из этого главного AMI. При изменении кода вашего веб-сервера разверните новый AMI, завершите работу старых экземпляров и создайте новые из нового AMI.
Для сервера VisualSVN возникает вопрос, может ли VisualSVN обрабатывать изменение объемных данных на нем без заботы об этом запущенного процесса. Например, если запущенный процесс кэширует некоторые данные в ОЗУ, что произойдет, если какой-то процесс синхронизации жесткого диска последует за ним и изменит жесткий диск на нем? Может случиться так, что сервер VisualSVN просто не сможет обработать сценарий с несколькими экземплярами. В зависимости от ответа на этот вопрос вы не сможете кластеризовать сервер VisualSVN. Возможно, что сервер VisualSVN имеет собственную функцию кластеризации. Если да, то вам следует изучить это.
Я считаю, что стандартный подход Windows Server к вашей архитектурной проблеме будет заключаться в реализации блока «Общие файловые системы» на вашей диаграмме с кластеризованным общим пространством хранения Windows с распределением узлов как минимум по двум зонам доступности.
Теоретически это дает вам нечто, что выглядит для приложений как стандартный файловый ресурс, но не имеет единой точки отказа. Это может быть излишним для вашей ситуации, но если вы стремитесь к отказоустойчивости, это поможет защитить от дополнительных сценариев сбоя.
Эта статья об отказоустойчивой кластеризации Windows Server, хотя и не связана с вашей проблемой, может помочь дать представление об объеме усилий: http://aws.amazon.com/microsoft/whitepapers/microsoft-wsfc-sql-alwayson/
это возможно с Amazon EFS, пожалуйста, перейдите по ссылке. https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-shared-file-storage-for-amazon-ec2/