Amazon AutoScaling и GlusterFS
- Опции Dcom.sun.management являются расширением Sun JVM. Это не часть спецификации JVM, и поэтому они не доступны в OpenJDK!
Так или иначе, даже с помощью JVM Sun, я получил фатальную ошибку при развертывании приложений на моем рабочем кластере. Возможно, это является намеренным Sun, потому что они продали расширение для контроля SNMP.
Является ли GlusterFS хорошим решением для обмена данными между всеми экземплярами в группа Autoscaling?
Возможно .. Однако единственный способ получить окончательный ответ - это провести собственные тесты. В прошлом я настраивал кластер веб-серверов из 4 узлов на экземплярах Linode, используя GlusterFS для распространения / совместного использования каталога ресурсов изображений и так далее.
Мы обнаружили две основные проблемы с этим подходом:
- GlusterFS является довольно интенсивным оператором ввода-вывода и очень хорошо работает на оборудовании с неконтролируемым вводом-выводом.
- Иногда сервер 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 такими же идентичными, как и вы может получить).
Я обнаружил, что в прошлом такая установка достаточно хорошо работала для веб-серверов, которыми я управлял.