Кластеры и почему они не дешевые?

Question

[Роман]

Приветствую! Де-факто опыта администратора у меня дай бог два месяца, и для меня кластер в плане отказоустойчивости это - n - количество нодов смотрят на один большой диск, и если нода сдохнет то пользователя можно переключить на другую - диск то один и информация на нем одна. Можно сделать такой же второй диск и очень быстро гонять туда данные, спастасаясь от того что большой диск может помереть.

А остальные решения - это производные от этой схемы как делать это более эффективно и менее затратно.

Тоесть при любых раскладах - заклад в пару лямов на хранилку(Или гораздо меньше? в JBOD хотябы террабайт 20 и наш терминальный сервер влезет)

Скорее всего мое понимание в корне неправильно, и я надеюсь что мне это пояснят. Начальник свято верит что это можно организовать с тем что есть/за очень мало, и я впринципе не против, только не знаю как и правильно ли я вообще пониманию "кластеризацию".

Comments

[Alexey Dmitriev]

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

Answer 1

[rPman]

Кластер это философия, отказоустойчивые системы можно организовать даже на лечении железе, собственно гугл с этого начинал

Без четкого понимания как это работает, самостоятельно ничего не получится, советую изучить вопрос получше.

И кстати, начинает нужно с четкого из, что собственно хотите получить, какие задачи решаются, какие сценарии failure и т.п.

Например если защищаться только от аппаратных сбоев, то очень дёшево делать такие системы на базе виртуализации или паравиртуализации, когда приложения прозрачно для них самих могут перемещаться между нодами, даже без остановки работы (есть и такие но они сложнее) или кратковременно (секунды). Например бесплатно такое можно сделать на базе xen

upd. NAS тоже можно собрать на коленке из компьютера и linux, получите некоторую защиту от сбоящих дисков (особенно дешевых, у которых вероятность сбоя может быть порядка 5% за 3 года, что очень критично)

Comments

[Роман]

Де-факто мы хотим реплику терминал сервера, что будет постоянно актуально жива для всех пользователей, вплоть до открытых программ и файлов. Чтоб и в случае сбоя пересесть на нее и в случае техработ шаманить над ней а потом актуализировать текущий. Терминал это виртуалка на которую летят пользователи по rdp и там по профилям сидят, работают в 1c и файловой системе.

Вот собственно такова задача. Про xen погуглю, благодарю.

[rPman]

открытые программы и файлы - сложнее всего, постарайтесь не заморачиваться до абсурда (есть такие технологии, бесплатно теоритически можно пилить скрипты свои на основе kvm)

По факту, будет что то типа управляемой миграции, когда запущенная виртуалка переезжает по сети suspend - copy - resume (время - копирование памяти на максимальной скорости сети) по команде администратора, но не автоматически при смерти железки. При смерти же железа, все будет продолжать работать так будто на сервере нажали резет - перезагрузились и продолжили работать (время простоя - запуск ОС и программ). И да, в этой схеме нужен адекватный NAS (резервирование на котором на основе raid, на выбор 1 или 5 или 6 или любая комбинация) и самое главное - быстрая сеть, иногда ее физически разделяют, для накопителей отдельный сегмент (помимо iscsi протоколов есть по проще/дешевле по железу - nbd или еще более простой и быстрый aoe, но винда поддерживает адекватно только iscsi)

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

[Роман]

Ну тогда нам и обычная Hyper-V реплика подходит. Написать банальный PS скрипт с имитацией "свидетеля" труда не составит , а функционал уже проверили - снапшот пользователя на 70 гигов(сам пользователь, cнапшот сам поменьше) каждые 15 секунд вполне незаметно переезжал. И в принципе файн - если мы таки реализуем переезд 1с-ки в веб. Она до сих пор для меня черный ящик в который я и не планирую залезать(и надо оно на самом деле. как сказал один из работадателей - дальше конфигуратора и пользователей в нем забота 1с-программиста), но когда она переедет в браузер должно быть по идее попроще. Hadoop какой-нибудь.

Answer 2

[RStarun]

Начать стоит с правильной постановки задачи.
Если такой вопрос встал, значит что-то сбоит, где-то проблема. Где? Сколько был простой после последних сбоев? Какие были причины простоя?

Может синий экран в терминалке появляется постоянно, тогда кластеризация hyper-v не поможет. Виртуалка будет уходить в синий экран как и ранее.
Может сеть отваливается? Тогда смотрим в сторону резервирования по сети (несколько коммутаторов, несколько сетевух).

Кластер на hyper-v это просто и не очень дорого (зависит от кластера конечно). Просто ценник одной системы умножаем на 2,5. Серверов нужно минимум 2 шт, они должны быть идентичными, им нужна хранилка. Подключение хотя бы DAS (полка), это если серверов два. Если больше двух, то уже SAN (классика). Хранилка на 20тб iscsi 10g двухконтроллерная (нам ведь надежность, резервирование контроллера) от 2 млн. Диски в нее в зависимости от хотелок, но SAS. SAS SSD стоит значительно дороже чем SATA|nvme. Производительность хранилки будет сильно ниже чем DAS. Есть вариант без SAN, называется гиперконвергентная система, но может получиться дороже. Там требования к железу и лицензиям более строгие.
Коммутаторы 2 шт 10г, чтобы резервировать сеть и MPIO получить. ВМ должны занимать не более 50% всех ресурсов кластера из двух серверов. Логично чтобы поднять ВМ на втором сервере при падении первого нам нужно иметь свободные ресурсы. То есть купили вы 800 гб озу, но в работе у вас максимум 400 всегда.

При зависании/отключении и т.п. одного сервера, вм поднимается на втором автоматически. Для вм это внезапное отключение питания, так что будет простой в несколько минут загрузки ОС и приложений. Сервер БД в это время может пострадать сильнее. т.к. БД не любит внезапных отключений и возможны потери последних транзакций.

Про лицензии я промолчу, ибо не знаю что у вас уже есть. Там в принципе на версии стандарт поднимается все (кроме гиперконвергентности).

Comments

[Роман]

Про простои более теоретические сценарии, больше про техработы без влияния на основной сервер. Я тоже слабо понимаю зачем компании за 50 пк что то кроме просто стабильной сети не из низов ценового сегмента.
Простаиваем и простаивали в 99% случаев из-за новаторских решений в виде полумертвого микротика, интернета через тарелку и то что это все покоится на подоконнике.

spoiler

нашей инфраструктуре угрожает швабра уборщицы

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

Потому терпим да думаем. В озвученный им бюджет не укладывается раз в 10, но спасибо за разъяснение

Answer 3

[SunTechnik]

Так вопрос в чем ?
Из чего состоит кластер ?
Сколько от стоит и хватит ли у Вас денег ?
Можно ли собрать кластер на Вашем оборудовании ?

Так непонятно, сколько у Вас денег и какое оборудование есть.
А понятие дорого/дешево - у каждого свое. И стоимость бизнеса разная.
Если день простоя компании стоит несколько миллионов, то оборудование может оказаться и не дорогим,
а если весь бизнес стоит пару миллионов, то нужен ли кластер ?

Побуду чуть-чуть гуглом:
Пример стоимости массивов:
https://www.hparts.ru/catalog-hp/hpe-msa-2060-storage

Как сделать кластер из двух серверов:
https://habr.com/ru/articles/354228/

Обзор Hyper-V
https://servermall.ru/blog/obzor-gipervizora-micro...

И учтите, что стоимость лицензий может составить очень значительную сумму...

И да, кластреы бывают разные.
Это может быть кластер виртуализациии, а может быть кластеризованное приложение.....