Постоянное хранилище для Apache Mesos

Недавно я обнаружил такую вещь, как Apache Mesos.

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

Боритесь, как бороться с длительными работами, которые являются работоспособными?

Скажем, у меня есть кластер, состоящий из N машин (и это запланировано через Marathon). И я хочу запустить там сервер postgresql.

Что это - сначала я даже не хочу, чтобы он был очень доступным, а просто одно задание (фактически Dockerized), на котором размещен сервер postgresql.

1- Как организовать его? Ограничить сервер определенным кластером node? Использовать несколько распределенных FS?

2 - DRBD, MooseFS, GlusterFS, NFS, CephFS, один из которых хорошо работает с Mesos и сервисами, такими как postgres? (Я думаю здесь о возможности того, что Мезос/марафон может переместить службу, если спустится)

3- Скажите, не подходит ли мой подход с точки зрения философии (DFS для серверов данных и какое-то переключение для серверов, таких как postgres на вершине Mesos)

_{^{Вопрос в значительной степени скопирован из Постоянное хранилище для Apache Mesos, заданное zerkms on Диспетчер стеков программ.}}

Ответ 1

Отличный вопрос. Вот несколько предстоящих функций в Mesos для улучшения поддержки служб с сохранением состояния и соответствующих текущих обходных решений.

Постоянные тома (0.23): при запуске задачи вы можете создать том, который существует за пределами изолированной области задач, и будет сохраняться на node даже после задача умирает/завершается. Когда задача завершается, ее ресурсы, в том числе постоянный том, могут быть возвращены в структуру, так что среда может снова запустить ту же задачу, запустить задачу восстановления или запустить новую задачу, которая потребляет предыдущий результат задачи как его вход.
- Текущее обходное решение: сохраняйте свое состояние в каком-то известном месте вне песочницы, и ваши задачи попытаются восстановить его вручную. Возможно, это сохранится в распределенной файловой системе/базе данных, так что к ней можно получить доступ из любого node.
Диск Изоляция (0.22): Обеспечить ограничение дисковых квот на песочницах, а также постоянных томов. Это гарантирует, что ваш ресурс, основанный на хранении, не сможет засорить диск и предотвратить запуск других задач.
- Текущее обходное решение: отслеживать использование диска вне диапазона и выполнять периодические задания очистки.
Динамическое резервирование (0.23): после запуска задачи вы можете зарезервировать ресурсы, которые использует ваша задача (включая постоянные тома), чтобы гарантировать, что они будут предложены вам после выхода задачи, вместо того, чтобы перейти к той структуре, которая находится дальше всего ниже ее справедливой доли.
- Текущее обходное решение: используйте ведомый --resources флаг для статического резервирования ресурсов для вашей структуры при запуске ведомого.

Что касается вашего конкретного случая использования и вопросов:

1a) Как организовать его? Вы можете сделать это с помощью Marathon, возможно, создав отдельный экземпляр Marathon для ваших служб с сохранением состояния, чтобы вы могли создавать статические резервирования для роли "stateful", так что гарантированным этим ресурсам будут гарантированы только мануалы с сохранением состояния.

1b) Ограничить сервер определенным кластером node? Вы можете сделать это легко в марафоне, ограничивая приложение определенным именем хоста или любым node с определенным значением атрибута (например, NFS_Access = true). См. Марафонские ограничения. Если вы только хотели запускать свои задачи на определенном наборе узлов, вам нужно было бы создать статические резервирования на этих узлах. И если вам нужна открытость для этих узлов, вы должны проверить Mesos-DNS и/или интеграцию с Marathon HAProxy.

1c) Используйте некоторые распределенные FS? Репликация данных, предоставляемая многими распределенными файловыми системами, гарантировала бы, что ваши данные могут пережить отказ любого одиночного node. Сохранение в DFS также обеспечит большую гибкость в том, где вы можете планировать свои задачи, хотя ценой разницы в латентности между сетевым и локальным диском. Mesos имеет встроенную поддержку для извлечения двоичных файлов из HDFS uris, и многие клиенты используют HDFS для передачи исполняемых двоичных файлов, конфигурационных файлов и входных данных в подчиненные устройства, где выполняются их задачи.

2) DRBD, MooseFS, GlusterFS, NFS, CephFS? Я слышал о клиентах, использующих CephFS, HDFS и MapRFS с Mesos. NFS, похоже, тоже будет легко подходить. Для Mesos не важно, что вы используете, пока ваша задача знает, как получить доступ к ней из любого node, где она была размещена.

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