Как обеспечивается совершенно бесперебойная работа сервера?
Ситуация 1:
Сервер с очень важной программой требовательной к дискам, как по скорости, так и по объему.
Тут на сервер упал кирпич (насквозь пробил) или его осветил священник, в общем сервер помер, софт тоже не работает. Как такого избежать?
Ситуация 2:
То же самое - сервер+важное ПО.
Пришла буря, одну подстанцию поджарила молнией, от второй оторвала провода. Два хитрых охранника слили по полбака солярки из генератора каждый, ИБП отработали нормально и сохранили работу серверов и теперь остаётся молиться, чтобы электрики починили свет, глядя на то, как быстро убывает % заряда АКБ....
Как избежать и такого?
Вы по большому счёту пишете о рисках.
Самое первое, что нужно сделать - посчитать стоимость простоя. Самостоятельно или с помощью профи - решать Вам. Причём стоимость простоя на уровне сервисов. Не работает вообще всё, не работает 1С, не работает сайт, не работает почта... И так далее.
К примеру, простой в работе ХХХ стоит 10 рублей в час. Обеспечивается работоспособность ХХХ сервером и админом рядом с ним. Условно простой вероятен 2 часа в месяц (болезни админа, остановка для апгейда, вырубание искричества...). Считается он обычно исходя из документации - производителя сервера, владельца ЦОДа и тому подобное. Есть несколько методологий рассчёта, но всё сложно.
Вы смотрите и понимаете, что затраты на резервирование не стоят свеч - 20 рублей в месяц это ниачом.
Допустим, простой стоит 999999 рублей в час. ОК, можно взять специализированный сервис, который гарантирует 99.9999999999% доступности. И это будет выгодно.
Допустим, Вы насчитали нечто среднее. Обычно так и бывает. И начинается самое интересное - перечисление и оценка рисков. И тут уже мрак, потому как за Вас эту работу никто качественно и бесплатно не сделает (даже если можно делать долго). И всех рисков Вы не учтёте никогда. Можете попробовать застраховать. Говорят, зарубежом это работает. В РФ - не верю, но это во-первых ИМХО, а во-вторых предложение-то есть.
И вот только когда у Вас будет перечень рисков можно задавать вопросы. А пока всё описанное Вами сводится к тому, что к оборудованию имеют доступ безответственные идиоты.
Вариант №1 - создание отказоустойчивого кластера - два физических сервера работают в паре, при этом один сервер выполняет работу, а второй сервер работает в резерве, при этом получает актуальные копию данных с первого сервера, делается разными инструментами. В случае гибели первого сервера, второй берет нагрузку на себя.
Вариант №2 - применим для веб-сайтов - пользовательские запросы направляются на сервера по определенным правилам на несколько серверов, в случае выход из строя одного из серверов - нагрузка вырастает на оставшиеся.
Вариант №3 - географически разнесенные дубликаты сервисов - самый надежный вариант, но кластер на длинных расстояниях сделать очень сложно - возникают проблемы с пропускной способностью, задержкой передачи и временными перерывами связи - не все протоколы, работающие в локальной сети способны справиться с этой проблемой.
В целом задача решается с применением известных решений с учетом специфики решаемой задачи и существующей архитектуры сервиса.
Простого решения - панацеи от всех проблем нет.
В одном ДЦ - можно heartbeat или pacemaker https://habr.com/post/107837/
Для горячей копии данных удобно использовать DRBD или распределеннные ФС.
Для географически распределенной системы решается только с помощью архитектуры.
В простых случаях, когда нужно только раздавать контент, то можно обойтись балансировкой. Например, с помощью round robin DNS и нескольких балансеров на haproxy перед серверами с контентом. Но это тоже не панацея, если ляжет вся DNS зона. В некоторых случаях полезно завести несколько доменов в разных зонах.
Синхронизация и распределение по регионам. Сервис высокой доступности или отказоустойчивости.
В любом случае требуется минимум двойной избыток мощности.
Взрослые дяди выносят прогу (сервис) на виртуальную машину, виртуальная машина поднимается на кластере физ серверов с гипервизорами, в случае отказа одного физ сервера виртуалка переезжает через какой-нибудь vmotion на другой, ну и Жесткие диски стоят в вынесенной СХД, подключаемой по fibrechannel. Естественно каждый физ сервер подключен к разным коммутаторам и маршрутизаторам. Так работает в рамках одного помещения (ЦОДа), для территориально разнесенных цодов надо уже думать исходя из инфраструктуры этих цодов. А если этого мало, то считаем, сколько там допустимо время простоя в месяц, каково допустимое время восстановления, и уже исходя из этого выполняем ряд мероприятий.
Во а можно чуть подробнее как виртуалка переезжает с сервера на сервер?
или как оно там вообще все происходит? Просто я даже представить не могу.
И сколько по времени это занимает?
И можно ли вместе с двуми серверами использовать две СХД? Ну точнее два стораджа или как там оно правильно называется. Чтобы небыло точки отказа.
Валентин, vmoton не обеспечивает отказоустойчивость https://www.vmware.com/ru/products/vsphere/vmotion.html - тут ни слова об этом , оно и понятно, если хост или сторадж ляжет - живую миграцию сделать будет невозможно.
для решения этой проблемы есть отдельная технология- VMware Fault Tolerance
здесь по делу описана суть и особенности этой технологии: https://www.vmgu.ru/news/vmware-fault-tolerance-in...
Законы физики здесь тоже обойти не удалось - внизу статьи перечислены все существенные ограничения для этой технологии. Чуда не случилось.
hx510b, я дал автору вопроса отправные точки для гугления. Можно добавить Netscaler с технологиями GSLB и отдельные подсистемы для репликации данных для реально разнесенных ЦОДов. А хотите реально масштабируемую и отказоустойчивую систему, посмотрите как работает сотовая связь (отдельное разнесение сигнализации и данных, SCTP на транспорте для дубляжа передаваемых данных, кластеризация территориально разнесенных баз данных Академию HLR). Только тогда система золотой станет.
Валентин, поэтому проблему решают на этапе проектирования архитектуры ИС. Тогда возможно решить задачу элегантно и относительно бюджетно. Все крупные проекты в Интернет идут по такому пути. Можно почитать блог Ивана Блинкова об архитектуре крупных проектов.
Для гигантов индустрии характерен переход к использованию географически распределенных файловых систем для хранения файлов, где задача отказоустойчивости решена уже. Применению реплицируемых сервисов баз даных и nosql хранилищ. И балансировка трафика между экземплярами сервиса. т.е. роль экземпляра сервиса сведена лишь к исполнению кода и без локального хранения чего-либо существенного.
на уровне 1-2х серверов вы все равно не сделаете высокую отказоустойчивось которая бы по форс мажерам/стихийным бедствиям противостояла.
Для такой отказоустойчивости вам необходимо:
1. Отделить софт от железа, используя виртуализацию, упаковав в контейнер софт.
2. Разместить контейнер в облаке, там такие задачи будут автоматически решаться на уровне "оркестрации" контейнеров.
Контейнер в облаке - физически контейнер на физической машине облачного провайдера - это значит, что в случае отказа - контейнер и его данные будут недоступны. можно ли будет достать когда-либо актуальные данные - неизвестно.
Облако - это маркетинговое понятие, которое натянуто на вполне обычные технологии виртуализации, которые сами по себе никаких чудес сделать не могут.
Конкретно с Амазон были аварии, когда лёг весь регион и много клиентов пострадало.
и не все данные были восстановлены. У rackspace несколько дней лежал DNS, положив всё у клиентов. Облако - это иллюзия с точки зрения отказоустойчивости.
Облако хорошо для динамического получения и распределения вычислительных ресурсов. Для экономии затрат на железо за счет высокой плотности приложений.
Можно еще напомнить про пожар hosting.ua, где сгорело все здание датацентра.
Поэтому если хочется получить действительно отказоустойчивый сервис - нужно это закладывать в архитектуру. И в этой архитектуре должен быть решен вопрос репликацией данных "на живую".
контейнер в облаке - физически контейнер на физической машине облачного провайдера - это значит, что в случае отказа - контейнер и его данные будут недоступны.
ему бесполезно объяснять.
у него "микросервисы головного мозга"
как видит это модное слово - микросервисы, контейнеры, виртуализация - так сразу говорит, что она решает все проблемы.
он не представляет а как на самом деле проблемы решаются.
Простой
