Комментарии 14
Теперь мы защищены от неполадок как со стороны СХД, так и со стороны коммутатора. Но что будет, если выйдет из строя сетевой адаптер сервера? Этот сервер потеряет доступ к сети и СХД. Поэтому нужно задублировать также и сетевые адаптеры:
Это уже защита от двойного отказа (карта+сервер), а не единичного(карта или сервер). Если сетевая карта в сервере навернется, то должно произойти переключение на резервный.
так же, не очень понятно зачем в данной схеме коммутаторы (как дополнительные точки отказа и цены), если можно воткнуть контроллеры СХД напрямую, так же крестом =). Т.е. тем кто в теме объяснять не надо, а вот стороннему обывателю будет не ясно.
Вообще, все статьи про резервирование надо начинать с требований.
Надо начинать с прикладного программного обеспечения. Сам по себе отказоустойчивый кластер не означает отказоустойчивых сервисов, а всего лишь способен устойчиво предоставлять вычислительную мощность.
Есть примеры расчета реальных отказоустойчивых кластерных систем (коэффициента готовности)?
Например, нарисовать два дублирующих прямоугольника - не вариант, т.к. обнаружение вторым узлом кластера выхода из строя первого - не стопроцентное и резко снижает надежность кластера в целом.
Минимум 4.
2 узла – это практически гарантированный взаимный отстрел.
3 узла – оставляют 2 после выхода из строя 1, и дальше см. предыдущий пункт.
См. также по этому поводу: https://habr.com/ru/post/281723/
Если я верно понял, то в открытом доступе расчетов надежности реальных отказоустойчивых систем - нет (потому что там видимо больше домыслов).
Про четыре параллельных узла - это про клаcтеры? Примеры есть? Обычно речь про два. Скажу более - в реальности трехузловые системы менее надежны чем двухузловые. Это потому, что узлы кластера сами по себе высоконадежны и добавление узлов уже не так увеличивает общий коэффициент готовности, как добавление нового узла снижает общую надежность за счет дополнительного "распределенного" переключателя резерва, который тоже имеет надежность. В этих расчетах, как правило, уже про оценку надежности кластерного ПО, которое должно определять наличие отказа при условии что он произошел, время переключения, а также ложные срабатывания переключателя на резерв (реально отказа не было, но переключение произошло и один узел ушел в простой).
В окрестностях "пяти девяток" надежность узлов в расчете общего коэффициента готовности уходит на второй план (вклад наработки на отказ каждого узла). Именно это я хотел увидеть на примерах расчета реальных отказоустойчивых систем.
В трёхузловой системе причину отказа можно установить мажоритарным голосованием (что и делает штатное программное обеспечение кластера высокой готовности), в двухузловой – способа достоверно локализовать нефатальный отказ не существует.
О коэффициенте готовности в пять девяток я вообще никогда не слышал, тут не надо путать с надёжностью. Это система без регламентных работ?
История из жизни -система хранения NetApp - две головы актив актив завязанные оптикой и полка с дисками. Вроде бы надёжно ? Но через пару лет вылетела одна голова (сначала ушла в ребут и потом ребутилась по кругу) и вторая голова все запросы приняла на себя. Ой как ей было тяжко... Всё почуствовали -). Этот кейс разбирали неделю!!!... После этого я понял зачем хитрые EMC в свои системы хранения пихают по три головы -).
Да вообще в любой надежной системе должно быть как минимум 3 узла. 2 узла это верная смерть, т.к. split-brain. Как минимум нужен арбитр, он может не быть полноценным 3 узлом.
+
В кач-ве арбитра может быть raspberry pi. Это точно возможно для ceph на proxmox ve.
https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2
2 узла это верная смерть, т.к. split-brain. Как минимум нужен арбитр, он может не быть полноценным 3 узлом.
Выделенный Арбитр (мажоритарной системы) становится единой точкой отказа и "тащит" общую надежность вниз. Каким бы он не был, - полноценным или нет. В кластерных системах пример выделенного "железного" арбитра есть?
Верное замечание. Вот как раз модуль управления AMM у нас недавно и сломался в IBMовской блейд-системе. Весь такой упрощённый и единственный не резервированный (ну и само шасси не резервировано тоже).
Тогда это нифига не арбитр, а ерунда какаято. Речь о том, что в кворумных системах необязательно делать все узлы полноценными. Арбитр может давать голос свой в общее голосование, но не хранить на себе данные например. Его отказ приведет лишь к тому, что два остальных узла будут большинством и система отлично продолжит работать. Похожим образом работает vmware vsan, где арбитром может быть любая дохлая тачка с esxi. И не надо городить еще один полноценный кластер просто чтобы сделать нечетное число узлов.
Отказоустойчивые системы: зачем нужны и как построить