Основы кластеризации (системное администрирование)

Я не знаю, что можно почитать.

Предлагаю начать с рассуждения о том, что вписываться в эту штуку нужно тогда, когда у тебя есть некий сервис, который должен быть доступен 24/7.

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

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

Далее возьмем какой-нибудь http в самом простом игрушечном варианте. Вроде тоже можно поставить рядом два идентичных сервера и проксировать трафик с помощью haproxy. Таким образом, что если первый сервак падает, то трафик уходит на второй сервак. Но уже тут мы получаем одну точку отказа в месте, где стоит harproxy.

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

Балансировка на proxmox с первого взгляда не сложная задача. Есть несколько прокмсмоксов, объединенных к кластер. При умирании одной из прокмоксин другие перетягивают на себя умершие виртуалки. И если конфига виртуалки ( сколько процов, памяти и тп) хранится на каждом сервере кластера, то где им взять виртуальные диски от погибших машин? Для этого используется единое хранилище. Тогда не надо ничего перетягивать, другой прокмокс просто мгновенно запускает умершую виртуалку. И вот здесь уже либо дорого, либо гиморно, либо медленно.

Общий смысл в том, что хранилище у всего кластера общее. это может достигаться дисковой полкой или CEPH или DRBD etc. И у каждого решения есть слабые места. В основном это пропускная способность сети ( под внутренний трафик нужен отдельный vlan c 10Gb свитчами и HBA сетевухами). Если же большой IOP не требуется, то можно тупо замуантить какой-нить qnap на обычных гигабитных сетевухах( и надеятся, что qnap не сдохнет ;)). Короче в этом месте надо очень много считать и читать спеки.

под внутренний трафик нужен отдельный vlan c 10Gb свитчами и HBA сетевухами

Не обязательно, можно объединить линки в один (bonding) получим и надежность и производительность.

Спасибо за развёрнутый ответ.

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

Вроде ты ответил на основные вопросы)

Как это сделать быстрее и проще всего, если не нужна полноценная высокая доступность, в классическом толковании этого термина?

Быстрее и проще всего в таком случае ничего не делать. Когда вы строите отказоустойчивую систему нужно прикидывать цену простоя и доступные ресурсы и уже исходя из этого плясать. Если у вас там одна\две виртуалки и больше ничего то никакие кластеры для увеличения аптайма системы городить смысла нет (да и не получится нормально).

Не обязательно, можно объединить линки в один (bonding) получим и надежность и производительность.

это зависит от объема трафика, IOPS и количества дублирований информации. Иногда можно и 2Гб в бондинге. Ну а 10Gb так не получится, нет в серверах столько сетевух, а ведь еще надо отдать под рабочий трафик что-то)

А еще в последний прокс кластер умеет балансировать без общего хранилища. Ты помечаешь конкретную виртуалку, что она типа HA . Кластер копирует ее на те прокмоксины, которые ты указал. И потихоньку реплицирует. Если прокмоксина умирает, то погибшие виртуалки поднимаются на другом прокмоксе.

Я еще это не тестировал. Могу предположить, что репликация там не мгновенная, те есть риск после краша получить сервис с откатом в час. но зато ТАДАМ! уходят все траблы скорости сетевых дисков, ибо родная шина явно будет работать быстрее, чем что-либо на свете.

с откатом в час

Это недопустимо.

Через что репликация то там?

Через что репликация то там?

где там?

В proxmox. Речь о glusterfs?

В proxmox. Речь о glusterfs?

нет, и я же написал, что не трогал ее еще. Речь, видимо, идет о снепшотах по крону.Но с автоматическим поднятием в случае падения одной из нод. Те как я и предположил, мы получим наш сервис с откатом назад на некоторое время. Для статичных сервисов подходит.

https://pve.proxmox.com/wiki/Storage_Replication

http://docs.cloudstack.apache.org/en/latest/concepts.html