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

Question

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

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

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

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

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

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

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

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

_{^{Вопрос в основном скопированы из Persistent storage for Apache Mesos, заданный zerkms на Programmers Stack Exchange.}}

Answer 1

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

1. Persistent volumes (0,23): При запуске задачи, вы можете создать том, что существует за пределами песочницы данных задачи и будет сохраняться на узле даже после того, как умирает задача/завершает. Когда задача завершается, ее ресурсы, включая постоянный том, могут быть возвращены в структуру, так что среда может снова запустить ту же задачу, запустить задачу восстановления или запустить новую задачу, которая потребляет результат предыдущей задачи как его вход.
   • Текущее обходное решение: сохраняйте свое состояние в каком-либо известном месте вне песочницы, и ваши задачи попытаются восстановить его вручную. Возможно, это будет сохраняться в распределенной файловой системе/базе данных, чтобы к ней можно было получить доступ с любого узла.
2. DiskIsolation (0,22): Принудительно квоты диска на песочницах, а также постоянные объемы. Это гарантирует, что ваш ресурс, основанный на хранении, не сможет засорить диск и предотвратить запуск других задач.
   • Текущее обходное решение: использование дискового пространства вне диапазона и выполнение периодических работ по очистке.
3. Dynamic Reservations (0,23): После запуска задачи, вы можете резервировать ресурсы ваших использования задач (в том числе постоянных томов), чтобы гарантировать, что они предлагают вернуться к вам при выходе из задачи, вместо того, чтобы идти в зависимости от того, рамки дальше ниже его справедливой доли.
   • Текущий обход: используйте флаг slave --resources, чтобы статически резервировать ресурсы для вашего фреймворка при запуске ведомого устройства.

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

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

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

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

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

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