Резервный NFS на Amazon EC2

В AWS использование GlusterFS с Elastic Load Balancer и автоматическое масштабирование инстансов EC2 должно дать желаемый результат. Я не могу комментировать другие IaaS.

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

Серверы Amazon EC2 по сути являются VPS - вы можете настроить на них Heartbeat / Corosync / Pacemaker и т. Д. (Хотя в прошлый раз, когда я проверял, вы не можете использовать широковещательную рассылку в их сети - вы можете использовать одноадресную передачу - udpu).

Вы упомянули две идеи, которые Amazon рассматривает (отчасти) отдельно: отказоустойчивость и избыточность.

В EC2 нет встроенного механизма избыточности, хотя в зависимости от того, что вы ищете, есть несколько способов добиться этого.

• Теоретически S3 разработан с несколькими уровнями резервирования и «предназначен для обеспечения 99.999999999% износостойкость объектов за год ". Их соглашение об уровне обслуживания распространяется на Доступность 99,9% в год. Если вы хотите пойти по этому пути для статических файлов, вы можете смонтировать корзину S3, используя s3fuse в качестве локальной файловой системы. Однако это довольно медленно и не рекомендуется для большинства целей (код, базы данных, серверное программное обеспечение и т. Д.).
• Моментальные снимки EBS предоставят вам сжатый дифференциальный образ вашего тома EBS на определенный момент времени. Они отлично подходят в качестве резервной копии - и вы можете запускать новые экземпляры из моментального снимка - это не так, однако настоящая избыточность.
• Для любого решения фактического резервирования вы должны настроить его самостоятельно. Одним из подходов, разработанных для решения этой проблемы, является GlusterFS. Вы можете настроить свои блоки как распределенные, реплицированные или и то, и другое, и данные будут распределены по системе - он устойчив к удалению отдельных узлов, и у них есть предварительно созданный AMI, из которого вы можете запускать несколько экземпляров для создания кластер.

С другой стороны, отказоустойчивость лучше обеспечивается платформой Amazon:

• Сеть EC2 предлагает несколько регионов и зон доступности, которые (теоретически) предоставляют изолированные и / или географически разделенные центры обработки данных, чтобы избежать единых точек отказа.
• Amazon предлагает мониторинг (Cloudwatch) различных показателей инстанса (ЦП, сеть, дисковый ввод-вывод и т. Д.), А также настраиваемые показатели. Их можно использовать в качестве триггера для запуска новых экземпляров из предварительно созданного AMI, процесса, называемого «Автоматическое масштабирование».
• EC2 имеет эластичные IP-адреса - это общедоступные IP-адреса, которые можно зарезервировать и быстро переназначить на другой экземпляр по запросу, что позволяет избежать задержек распространения DNS, когда экземпляр выходит из строя.
• Наконец, у Amazon есть эластичные балансировщики нагрузки - они должны быть разработаны, чтобы избежать единой точки отказа и масштабироваться с входящим трафиком (они не страдают от тех же ограничений пропускной способности, которым будет подвергаться установка одного экземпляра в качестве балансировщика нагрузки. к). ELB могут отслеживать «работоспособность» внутренних экземпляров и работать с автоматическим масштабированием для поддержания необходимого количества экземпляров.

В дополнение к вышесказанному вы можете передавать настраиваемые параметры своим недавно запущенным экземплярам или довольно легко извлекать информацию о ваших запущенных в данный момент экземплярах, что может позволить вам создать сценарий для некоторых настроек (и, конечно же, у AWS есть API, который позволит вам создать скрипт для всех действий, которые они предлагают - включая переназначение эластичного IP-адреса, запуск новых экземпляров, отсоединение / присоединение томов EBS и т. д.).

Вы описали, что «файлы хранятся на отдельной резервной EBS ... [которая затем] монтируется». Во-первых, в EC2 том EBS может быть присоединен только к одному экземпляру за раз (поэтому для копирования данных на него необходимо присоединить том EBS). Вы должны поддерживать избыточность (вы можете настроить RAID-массивы устройств EBS или сделать что-нибудь еще). Проблема, однако, в том, что иногда тома EBS не отключаются, когда экземпляр действительно выходит из строя - вы можете принудительно отсоединить их (что дает лучший, но не идеальный показатель успеха), и вы можете сделать снимок тома EBS, даже если он используется (что затем вы можете создать новый том EBS и запустить AMI с помощью). Однако лучше (меньше времени на восстановление, более гибко и т. Д.) Поддерживать реплики данных в нескольких экземплярах, а не в нескольких томах EBS в одном экземпляре.

Другой вариант - использовать Zadara Storage, то есть NFS «как услугу». Поскольку это служба, вам не нужно управлять стеком сервера NFS, и по умолчанию это HA. Вам даже не нужно платить за экземпляры сервера NFS. Вы можете подключить все машины EC2 к своим общим ресурсам, используя стандартный NFS.

Раскрытие информации: я с Zadara Storage.