Amazon AutoScaling и GlusterFS

Является ли GlusterFS хорошим решением для обмена данными между всеми экземплярами в группе Autoscaling?

Возможно ... Единственный способ получить окончательный ответ - это провести собственные тесты. Раньше я настраивал кластер веб-серверов из 4 узлов на экземплярах Linode, используя GlusterFS для распространения / совместного использования каталога ресурсов изображений и т. Д.
Мы обнаружили 2 основные проблемы с этим подходом:

1. GlusterFS требует довольно много операций ввода-вывода и отлично работает на оборудовании с неконтролируемым вводом-выводом
2. Иногда сервер Linode может получать неоптимальный доступ к серверной сети SAN, и время ожидания ввода-вывода резко возрастает. Когда это происходило, Gluster копировал больше данных между оставшимися узлами, что, в свою очередь, приводило к снижению производительности ввода-вывода на этих узлах. В результате небольшая ошибка ввода-вывода, вызванная неоптимальной конфигурацией SAN или разделением времени, будет означать, что весь кластер веб-серверов перестанет работать, и вся совместно используемая файловая система может стать недоступной.

Чисто анекдотические свидетельства, но я бы никогда больше не запускал GlusterFS на виртуальной машине с SAN / общим хранилищем.

Гарантирует ли Gluster отсутствие потери данных?

Это может ... В Gluster 3.0 улучшено распознавание «пулов репликации», где вы можете определить, сколько копий данных существует в кластере. Установка уровня репликации 2 означает, что на всем кластере есть 2 копии. Это фактически вдвое уменьшает емкость хранилища, но означает, что вы получаете большую устойчивость к сбоям узла.
Важно отметить, что это также означает, что вам необходимо добавить дополнительные узлы, кратные уровню репликации, в данном случае пары узлов.

Что произойдет, если все экземпляры в автомасштабировании будут прекращены, я потеряю пользовательские данные?

Если экземпляры используют только временное хранилище экземпляров, да. Если они основаны на EBS или используют смонтированные экземпляры EBS, тогда нет.

Что произойдет, если пользователь загрузит изображение, и сервер, обрабатывающий запрос, выйдет из строя?

Это во многом зависит от того, как разработано ваше приложение. Я сильно подозреваю, что пользователь потеряет свои данные (почти наверняка в наивно спроектированном решении).

Повлияет ли отказ клиентов на ввод-вывод?

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

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

Хорошим правилом при работе с облачными системами является сопоставление службы с экземпляром 1: 1. Не пытайтесь заставить экземпляр делать слишком много. Архитектурно это помогает при масштабировании вещей.

У вас уже есть хорошие ответы на свои вопросы по Gluster, однако я хотел бы упомянуть кое-что, что может быть полезно.

В зависимости от вашего варианта использования вы можете обнаружить, что следующим легче управлять и меньше подвержены ошибкам:

• Все EC2 идентичны, код извлекается из репозитория, чтобы поддерживать его в актуальном состоянии (вы можете управлять этим несколькими способами через процессы развертывания)
• Любые пользовательские загрузки идут прямо на S3 через s3fs или вызовы API, интегрированные в ваше приложение (python / php и т. Д.).

Преимущества S3 очевидны:

• Платите только за то, что вы используете (не нужно платить за целую кучу неиспользуемых ресурсов в EC2, текущие расходы, репликацию на несколько машин и т. Д., Также не требуется никакого управления)
• Избыточность встроена в S3, поэтому ваши файлы в безопасности в тот момент, когда они попадают в s3 (безопасный означает, что они находятся в управляемом сервисе в нескольких местах по всему миру. AWS сообщает, что они никогда не теряли файл в s3)

Если вы хотите пройти лишнюю милю, вы можете настроить свой (linux) сервер так, чтобы он отправлял все журналы на «сервер журналов» (при этом все EC2 остаются идентичными, а также настолько упрощенными, насколько это возможно).

Я обнаружил, что в прошлом такая установка достаточно хорошо работала для веб-серверов, которыми я управлял.