Сравнение ПО построения кластера

я, для запуска стороннего по на кластере, выбрал pacemaker.
я не выбирал из нескольких. гугл первым сказал про него. прочитал, вроде все ок.
работает.
доволен

нечего обсуждать, или читай википедию. «кластер» — это обьединение. вот и все значение этого слова. соответственно кластеры бывают разные, в зависимости от решаемых задач, и сравнивать их так же некорректно как сравнивать дом и самолет. есть hpc, есть ha, есть ft, есть distributed systems; есть кластеры обработки данных. что конкретно тебя интересует и главное зачем? в твоем сообщении нет ни одного правдивого утверждения, от «openshift форк кубернетеса» и до «в тренде 2 подхода построения linux кластеров».

Если вкратце, меня интересует, - когда лучше использовать mesos, а когда - openstack.

Kubernetes и его форк OpenShift - нужны для service discovery и восстановления упавших сервисов (?).

ШТО?

kubernetes - примерно то же самое, что и mesos. Это системы оркестрации для контейнеров.

openstack - по сути, vsphere для бедных; система управления VM.

есть ha, есть ft

Это не одно и то же?

Ты все в одну кучу смешал. Грубо в двух словах. Pacemaker в связке с coro/hb это система управления ресурсами-приложениями. Openstack и ко - система управления машинами (например виртуальными). Это разные уровни абстракции.

Можно скажем машины связать одним, а уже на них приложения расставить другим.

Посмотри вики openstack про pcmk, там в первом абзаце сказано что и зачем

Что ты имеешь в виду под ресурсами-приложениями? И в чём именно заключается «управление машинами»?

Логическая единица того чем ты управляешь в данной системе. В pcmk это приложение/сервис. В openstack это обычно vm. Да, можно обмазаться докером и kvm чтоб скажем управлять вм в pcmk, но надо ли оно?

Наверно нет.

Меня больше всего интересует mesos. Если я правильно понял, он, согласно фреймворку, запускает docker контейнер с заданным лимитом ресурсов - т.е. админ не обязан указывать машину, на которой должно разворачиваться приложение - фреймворк (aurora, marathon) сам определяет, где делать деплой.

Или не так?

хз, я больше по pcmk. То что ты написал - да, скорее всего. Но помни что ты все равно скорее всего должен будешь указать сколько примерно должно жрать твое приложение (этот самый лимит для контейнера), или его могут запихать в какое-нибудь узкое место

почитал вики мезоса. Жаба идет во все поля. Ты уверен что ресурса хватит? Там один только zookeeper чего стоит. Да и кстати - так тебе что размещать-то надо? Приложение или виртуалку? А то если тебе докер распихивать без всякого ha и ресурсов то может и сварма хватить

Ты будешь смеяться,

я пишу курсовую на тему разворачивания scala сервиса, использующего twitter finagle на базе mesos.

хм, ну что сказать, такой курсач интереснее точения карандаша лопаткой.

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

Тут я почему про приложение и виртуалку спросил - с докером вопрос слегка тонкий. Смотря как ты смотришь на контейнер и смотря что тебе от него нужно. У меня скажем pcmk вращает и докером тоже, т.к. для меня контейнер - это просто приложение (скажем tomcat с приложением), и цепляться в сам контейнер я не буду, проброса портов хватит, и нужна в первую очередь ha. Если же это будет полноценная вм на манер lxc - тогда это уже лучше рассматривать как машину.

Не смотрел в сторону xCAT? Вроде ничего так работает в N кластерах. Виртуалки управляет как железные узлы.

Это не одно и то же?

смотря кого спрость. как ты понимаешь, четких определений нет, но обычно под high availability подразумевают системы способные быстро восстановиться после сбоя, чаще всего это фейловер. возможна потеря данных in flight, например тех что обрабатывались умершей нодой, сессионной информации для веб-систем и тп. fault tolerant системы же подразумевают полную прозрачность потери узлов системы, причем в целом этот термин применим к любым узлам, не только к инфраструктуре — хотя чаще всего имеют ввиду именно отказ ноды фт кластера. это следующий уровень доступности, как правило гораздо более дорогой в случае с классическими, не-distributed системами.

Если вкратце, меня интересует, - когда лучше использовать mesos, а когда - openstack.

Mesos если ты строишь правильную расспределенную систему (твой софт про это знает), и тебе надо систему эффективного шедулинга подсистем твоего сервиса на вычеслительных узлах.

OpenStack если тебе надо построить IaaS решение.

Ты можешь, и как правило будешь, использовать эти системы совместно при построении сложной системы — OpenStack для провижена физических ресурсов, Mesos для обьединения их в общий вычислительный пул и шедулинга твоего дистрибьютед софта. Им же можно шедулить и управляющие узлы опенстека.

он говорил про openshift а не openstack. openshift — это неплохое опенсорсное PaaS решение. хотя это абсолютно не добавляет смысла тому что ты процитировал =)

mesos кстати это не только и не столько про контейнеры — это вообще про так называемые «фреймворки», например Chronos (distributed крон, с очень вкусными возможностями). на месосе реализованы в частности фреймворк Aurora, который похож на гугловский Борг и наш tupperware, а значит и на kubernetes (который переписанный опенсорсный Борг), и фреймворк Marathon, который PaaS, примерно как OpenShift. не мезосе удобно ранить всю инфраструктуру Хадупа например, там под все тоже фреймворки есть. мезос — это просто базовая инфраструктура кластерного шедулера.

Первый раз услышал про этот xCAT. Посмотрел. Это же провиженинг система?

чтот тогда слишком богатые конторы её юзают, чего не скажешь о vsphere, которую себе ставит каждая шарага.

Ну, можно сказать и так. Предназначен для полной настройки инфраструктуры кластера. Настройка сети, DNS, dhcp, подготовка и деплоймент образов на узлы, управление (включение-выключение и т.п.) узлами.

+1, попенстек зачастую поынтерпрайзнее vsphere бывает.

кстати, почему у тебя ник опять такой странный? Говорю же, erzentddqd - так точно банить не будут