Comments 8
Как любой грандиозный проект с грандиозной идеей, он будет на 1% зависеть от идеи и на 99% от реализации. А реализация грозит нам всё тем же:
hw management (как ребутнуть сервер, как заставить данный сервер ТОЧНО загрузиться по pxe?)
hw inventory (какие диски для чего можно использовать? Какие сетевые интерфейсы в какие коммутаторы воткнуты? Как это понять в автоматическом режиме?)
Boot: как загрузить ОС с драйверами под данное железо?
OS level: как установить те версии ПО, которые требуются?
App level: как деплоить нужные версии из нужных брачей и как к ним правильно притягивать зависимости?
conf level: как соотнести конфигурацию приложения с остальными уровнями? (доступные сети и т.д.)
Дальше там мониторинг/балансинг, но это уже дело десятое.
Все эти уровни много раз решались разными людьми под разные специфичные сценарии с разной степенью неуспешности. Решение, которое бы убирало это боль пока не найдено.
Если им получится решить эту проблему — это будет революция. Решат локальные кейсы — ну будет у нас рядом с MaaS+juju, TrippleO+chef и т.д., ещё одна конструкция.
hw management (как ребутнуть сервер, как заставить данный сервер ТОЧНО загрузиться по pxe?)
hw inventory (какие диски для чего можно использовать? Какие сетевые интерфейсы в какие коммутаторы воткнуты? Как это понять в автоматическом режиме?)
Boot: как загрузить ОС с драйверами под данное железо?
OS level: как установить те версии ПО, которые требуются?
App level: как деплоить нужные версии из нужных брачей и как к ним правильно притягивать зависимости?
conf level: как соотнести конфигурацию приложения с остальными уровнями? (доступные сети и т.д.)
Дальше там мониторинг/балансинг, но это уже дело десятое.
Все эти уровни много раз решались разными людьми под разные специфичные сценарии с разной степенью неуспешности. Решение, которое бы убирало это боль пока не найдено.
Если им получится решить эту проблему — это будет революция. Решат локальные кейсы — ну будет у нас рядом с MaaS+juju, TrippleO+chef и т.д., ещё одна конструкция.
Так основная идея месоса и месосферы — разделение ответственности. Раньше можно было вынести в 2 отдельных подразделения сеть и железячную часть, остальное на админах софта. В новой концепции ОС и инфраструктура для масштабирования приложений выделяется в третье подразделение. Теоретически, после такого шага разработчики уже сами могут деплоить, в гугле такое практикуют с мелкими проектами. Либо остаются специальные админы, которые думают только про приложение и его конфигурацию, а не про железо и ОС.
Ничего не понял.
Вот, допустим, у нас «ОС и инфраструктура» в новом подразделении. Мне нужно запустить маленький шардик из эластика для экспериментов.
Сейчас я:
1) Пишу в внутренний саппорт компании «хачу сервера», мне их дают.
2) Я через менюшку self-serving выставляю себе ОС, гружусь
3) Обнаруживаю, что мне нужен отдельный вилан. Пишу сетевикам с номерами портов. Получаю.
4) Ставлю что мне нужно.
А в этой фантазии что происходит и кто это делает?
И, главное, к вопросу о сетевой стене: кто эту милую хипстерскую поделку пустит к консоли управления роутером, через которые сотни гигабит проходят?
Вот, допустим, у нас «ОС и инфраструктура» в новом подразделении. Мне нужно запустить маленький шардик из эластика для экспериментов.
Сейчас я:
1) Пишу в внутренний саппорт компании «хачу сервера», мне их дают.
2) Я через менюшку self-serving выставляю себе ОС, гружусь
3) Обнаруживаю, что мне нужен отдельный вилан. Пишу сетевикам с номерами портов. Получаю.
4) Ставлю что мне нужно.
А в этой фантазии что происходит и кто это делает?
И, главное, к вопросу о сетевой стене: кто эту милую хипстерскую поделку пустит к консоли управления роутером, через которые сотни гигабит проходят?
А вы не можете запустить совсем произвольное приложение, оно должно соответствовать конвенции взаимодействия с месосферой. И заказываете не виртуалки, а просто ресурсы, типа 50 ядер и 100 гиг памяти. Про всякие виланы вам вообще думать не нужно, это все системой должно делаться. По сути, это аналог запуска бинарника на локальной машине, только где-то в дц.
Это я пишу не применительно к конкретному продукту, а к концепции. Пускать или не пускать хипстерское поделие в своем дц каждый решает сам. Скоро будут и решения от крупных вендоров.
Это я пишу не применительно к конкретному продукту, а к концепции. Пускать или не пускать хипстерское поделие в своем дц каждый решает сам. Скоро будут и решения от крупных вендоров.
Интересно видится концепция как «ЦОД из коробки», но там в любом случае это плотная связка под конкретное железо. А вот тут можно развернуться — производителям железа возможно захочется расширить арсенал конкурентных преимуществ (красивых коробочных решений)
Я извиняюсь за резкость. Просто для меня Mesosphere — как красная тряпка для быка. У кого-нибудь из присутствующих здесь, есть положительный опыт использования ЭТОГО в продакшне? Можете им поделиться?
На данный момент, абстракции от самого Mesos вполне достаточны для построения staleless приложений. Например, «запустить N инстансов приложения на серверах, где есть для этого ресурсы» (Marathon, Aurora). Но когда я последний раз проверял это не настолько просто с сервисами, которые хранят данные на диске отдельно для каждого из инстансов (Cassandra, Elasticsearch). Если при падении stateless — сервисов, их можно перезапустить где угодно, то с базами данных все несколько сложнее и Mesos расширяется в данный момент до включения и управления дисковыми ресурсами.
По моему опыту, довольно неплохо работают сервисы (имлементирующие Mesos фреймворк) хранящие данные, например, в Zookeeper. У нас неплохой опыт с развертыванием Storm кластера на Mesos. Остальное было пока на уровне экспериментов и тестов: Spark, Marathon, Chronos, но было вполне работоспособное.
ОС для датацентра, конечно, звучит очень громко на данный момент, но это все вполне возможно и остается дело за реализацией, бОльшая часть которой будет основана на умной имлементации Mesos framework для каждого из интересующих сервисов
Sign up to leave a comment.
ОС для ЦОДов Mesosphere: Что это и для кого