люди просветите нехрамотного что такое devops?

А я не люблю пробки на дорогах. И что?

А то, что народ робит по постоплате.

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

Причем здесь, заправляют бухгалтера и другие директора? Я вам говорю о том, как оно в подавляющем большинстве случаев робит.
Простая аналогия, строите вы дом, вы же не оплачиваете 100% вперед. И имхо это вполне логично, дома-то ещё нет, с какого оплачивать все 100% за не существующее.

Я вам говорю о том, как оно в подавляющем большинстве случаев робит.

Это очень большая ошибка считать, что везде так же как у тебя. Не делай так.

Простая аналогия, строите вы дом, вы же не оплачиваете 100% вперед.

Вообще не аналогия. Даже близко.

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

На непродолжительное время это другое. Тут возражений нет.

Ну и то, что ты работаешь там, где никому нет дела до того, что твой сервис недоступен потому что «лежит». Он не является важной частью бизнеса.

Та нет, я в том числе работал в месте где «сервис» это не что-то эфемерное в виде батиков, а вполне себе не иллюзорно осязаемое. И за «не работу» этого «не иллюзорно осязаемого» прилетают вполне себе «не иллюзорные живительные люли».

Это очень большая ошибка считать, что везде так же как у тебя. Не делай так.

Хочу вам посоветовать того же.

Вообще не аналогия. Даже близко.

Именно вполне конкретная аналогия. Вы ещё не получили услугу, вам только пообещали, а с вас требуют 100% предоплаты.

И за «не работу» этого «не иллюзорно осязаемого» прилетают вполне себе «не иллюзорные живительные люли».

Так чего же ты тогда мне мозги компостируешь? :) Вряд-ли там в момент дикой нагрузки приходилось что-то согласовывать с генеральным. Более того, там точно изначально было заложено больше ресурсов, чтобы быть готовым к «пикам».

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

Хочу вам посоветовать того же.

Я в курсе о том, что существует мелкие, слабо завязанные на интернет, фирмочки. DevOps практики не для них по большей части.

Вы ещё не получили услугу, вам только пообещали, а с вас требуют 100% предоплаты.

Это разовая услуга. И дорогостоящая. Там совершенно другие правила. И, да, ты скорее всего можешь договориться с хостером про постоплату, но ты должен быть очень крупным клиентом, чтобы они под тебя специально подстраивались.

Слушай, а ты, подгоняльщик софта под железо, сложнее LAMP чего-нибудь в жизни видел?

А что, девопс нужен еще для чего-то? 😁

Более того, там точно изначально было заложено больше ресурсов, чтобы быть готовым к «пикам».

В целом да, но расскажу историю одной из систем, изначально всё именно так и было «заложено больше ресурсов», но апетиты стали расти по экспоненте, в результате за достаточно короткий промежуток времени всё стало достаточно печально. Не смертельно, но очень тоскливо.

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

Арендованные ресурсы удобны для «ненужного», т.е. того что не страшно потерять. Потерять в двух смыслах: «было и пропало» и «попало в чужие руки». Второй вариант я проходил ИРЛ.
Впрочем первый тоже, но там всё закончилось хорошо.

Я в курсе о том, что существует мелкие, слабо завязанные на интернет, фирмочки.

Вот как раз «мелкие, слабо завязанные на интернет, фирмочки. » скорее и могут по какой-то причине робить по предоплате.

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

Договориться? Вы сказали: Договориться? Да они сами счета для юриков постфактум выставляют.

но ты должен быть очень крупным клиентом

И для мелких тоже бывает такая же хня.

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

Функционировать в подобной парадигме могут разве что какие-нибудь внутриигровые чатики васянской индюшатины или хипстосервис по предоставлению сервиса.

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

но апетиты стали расти по экспоненте

Чьи аппетиты то? Ничего не понял.

Потерять в двух смыслах: «было и пропало» и «попало в чужие руки».

Слушай, это уже совсем из пальца высосано. Если ты не умеешь в шифрование и бэкапы, то даже системным администратором работать нельзя.

Часто восяновский набор контенеров, в один контейнер свожу (почти бареметалл получается, но с контейнером проще).

Результат:
Выигрыша на ab (на количество обработаных запросов) не вижу.
Если эникеи с Prometheus, Grafana не намудрили (с десяток раз встречал они колом систему вешали + солидная нагрузка на создание отчётов).
Но выигрыш в надёжности и скорости запуска (оркестровке) не хилый получается.
ну и экономия на спичках: на месте на дисках получается (на фоне обьёма инфы обрабатываемой это копейки)

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

Чувак, это реально любой современный сервис, рассчитанный более чем 100000 активных клиентов. От крупных интернет-магазинов, online игр до каких-нибудь криптобирж. Практически все, что ты видишь в современном интернете работает именно так.

Ты о чем сейчас?

Чувак, это реально любой современный сервис, рассчитанный более чем 100000 активных клиентов. От крупных интернет-магазинов, online игр до каких-нибудь криптобирж. Практически все, что ты видишь в современном интернете работает именно так.

Во-первых, вопрос касался конкретного примера, а не «любого современного сервиса», потому что

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

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

Более того, один из моих подопечных - не просто интернет-магазин, а франшиза, которая предоставляет API и ведет все БД включая фронто-бекенды для интернет-магазинов. Здесь не просто 100000 клиентов, здесь под миллион. Правда на нодежс. https://ibb.co/6RmhMB5W

В-третьих, твои 100000 - туфта, с которой справится даже админ-джун.

root@host-92-204-175-255:~# ps aux | grep php-fpm | wc -l
433042
root@host-92-204-175-255:~# 

Это пиндосский сервис для шаринга музыкальных треков. pm ессесно ondemand.

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

Про онлайн игры - можно подробнее, что ты имеешь в виду под онлайн-играми? Игровой сервак, поднимаемый одним единственным бинарем?

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

- - -

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

Заметил еще вот что, из личных наблюдений: админы-технари, производительность\нагрузку измеряют в метрической системе. Запросы в секунду, мегабайты в секунду, IOPS и так далее.

Вебмакаки меряют в каких-то абстрактных «активных клиентах» или еще какой-то похожей дичи, из чего делается вывод что либо они сами не понимают, как оно работает; либо они настолько упороты что реально отдают на откуп новым железкам (апскейлингу, на их обезьяньем) то, что можно обработать правкой десятка строчек конфига\кода.

Прекрати позориться.

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

Да. На opencart’е с сотней товаров. Авторитет, блин. Я писал про активных пользователей, а не просто всех когда-либо что-купивших.

433042

Да, phpшники очень странные люди. Там наверное еще и mysql один и без репликаций. Чего б нет.

Игровой сервак, поднимаемый одним единственным бинарем?

Нет, я про бэкенд online игр. Где и базы с уровнями и сессии игроков и куча аналитики.

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

Ты правда думаешь, что криптобиржа - это только нода блокчейна? Смешно.

Специалист, блин.

меряют в каких-то абстрактных «активных клиентах» или еще какой-то похожей дичи

Я конечно не «веб-макака», но с тобой только на пальцах (пользователях). И то плохо понимаешь. :(

ps aux | grep php-fpm | wc -l

pgrep -c php-fpm, к слову.

Да. На opencart’е с сотней товаров. Авторитет, блин. Я писал про активных пользователей, а не просто всех когда-либо что-купивших.

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

433042 Да, phpшники очень странные люди. Там наверное еще и mysql один и без репликаций. Чего б нет.

Чего б и нет. Потому что ты еще и не понимаешь что для каждой задачи существует свой инструмент, хотя я в принципе знаю что вебмакаки выучили NoSQL, только не понимают зачем оно нужно, вот и пихают его везде. Я бы тебе еще и про достоинства хранения некоторых данных на уровне ФС (и сравнения производительности с БД) бы рассказал, но пока что не решил стоит ли с тобой дискутировать с т.з. практики.

Нет, я про бэкенд online игр. Где и базы с уровнями и сессии игроков и куча аналитики.

Чувак, бекенд может быть только там, где есть фронтенд. В играх фронтенда нет. В играх есть клиент, обменивающийся данные с сервером. В роли сервера чаще всего выступает готовый бинарник, запущенный в foreground, т.е. на переднем плане; иногда распространяемый готовый дистрибутив. Для этого даже девопс не нужен, ты что на приколе? Железку купил, настроил вручную или автоматически, загрузил, запустил. Всё. Ну ты че, никогда линяжный сервер в глаза не видел?

Нахрена тут вообще девопс? :))

Ты правда думаешь, что криптобиржа - это только нода блокчейна? Смешно.

Я не думаю, я тебя читаю. Если ты хочешь донести какую-либо инфу - значит доноси в точности так как тебя должны понять. Мы здесь не телепаты.

- - -

Короче к крупным проектам ты отношения никакого не имеешь. Исключительно теоретик.

pgrep -c php-fpm, к слову.

https://ibb.co/C5CfMr9x - разницы не заметил.

К слову, знаешь недостаток пгрепа, из-за которого я им не пользуюсь?

Чего б и нет. Потому что ты еще и не понимаешь что для каждой задачи существует свой инструмент

Логично. Потому что твой opencart с сотней товаров тебе даже на два хоста не разнести. Он требует прямой доступ к mysql. Причем даже не через пул коннекций. Один клиент - одно соединение. И тебе приходится держать одну жирную дорогую машину с запасом производительности на новый год, 8 марта и т.д.

В роли сервера чаще всего выступает готовый бинарник, запущенный в foreground, т.е. на переднем плане; иногда распространяемый готовый дистрибутив.

Ты даже не представляешь насколько ты не в теме.

Короче к крупным проектам ты отношения никакого не имеешь. Исключительно теоретик.

Смешно.

разницы не заметил

В том и смысл. Букв меньше, труб меньше (ноль), а разницы нет.

К слову, знаешь недостаток пгрепа, из-за которого я им не пользуюсь?

Не знаю.

Я бы тебе еще и про достоинства хранения некоторых данных на уровне ФС (и сравнения производительности с БД) бы рассказал

А расскажи. Особенно с момента, когда тебе там надо что-то найти.

А расскажи. Особенно с момента, когда тебе там надо что-то найти.

Практику подтвердишь - продолжим. Даже тесты тебе заскриню на фоне ЛОРчика.

Даже тесты тебе заскриню

Тесты чего? Поиска данных?

Тесты чего? Поиска данных?

Чувак, поиск данных - это настолько тупорыло-примитивная операция, что с ней даже grep справляется.

Я думал ты усложнишь задачу, ну там допустим перекрестную переписку между сотней тысяч пользователей за пять лет попросишь сэмулировать.

Теперь мне окончательно все ясно. Спокойной ночи.

тупорыло-примитивная операция, что с ней даже grep справляется

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

выучили NoSQL, только не понимают зачем оно нужно

Ух ты. Ты даже redis не используешь в своем opencart-e? Бедный mysql.

Чьи аппетиты то?

Тех кто заказывал девушку разработку.

Слушай, это уже совсем из пальца высосано. Если ты не умеешь в шифрование и бэкапы, то даже системным администратором работать нельзя.

Ну шифрование как-то с натягом ещё принять можно, но вот бэкапы это уже не смешно. Ну есть у вас бэкапы, где вы их разворачивать будете в случае часа П? И так же не забывайте, что время слития/заливки бэкапа от дяди к другому дяде != время разворота локального бэкапа, т.е. в случае часа П, он у вас может превратиться в Полный П.

В том и смысл. Букв меньше, труб меньше (ноль), а разницы нет.

Это только на первый взгляд.

На самом деле:

https://ibb.co/qY3PmGQS

Ну есть у вас бэкапы, где вы их разворачивать будете в случае часа П?

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

А вообще важные сервисы всё-таки дублируются и кластеризируются.

Блин. Спасибо!

Почитал твои коменты, особенно вот этот последний. Как будто вернулся в свой 2010-ый. Как же тогда было всё просто. ))

С ключиком f труб и букв все еще меньше. И результат чище.

Чувак, поиск данных - это настолько тупорыло-примитивная операция, что с ней даже grep справляется.

Полнотекстовый поиск данных по многосоттерабайтной базе грепом... Да ты крут. Когда я работал в одном маленьком книжном магазине, у нас для этого помимо множества инстансов с самим поисковиком держался кластер redis в несколько терабайт оперативы. А так как нужно было обеспечить отказоустойчивость, это всё дублировалось трижды в географически распределённых датацентрах.

Я реально тебе завидую.

Пока я не ушёл в сторону разработки и занимался поддержкой прода, у нас было три одновременно запущенных инстанса каждого сервиса. Всегда. Даже если сейчас нагрузки нет. В случае нагрузки(чёрная пятница, внезапный ддос, весенние распродажи), мы дежурили круглосуточно и на лету поднимали ресурсы, потому что в такие моменты автоматика не справлялась и нужен был ручной контроль. Поэтому в случае часа П(такой был, например, три года назад, когда на «чёрную пятницу» нас одновременно начали ddos'ить), мы потеряли один из датацентров, но нагрузка перешла на два других. После окончания атаки, всё снова вернулось и равномерно распределилось по трём.

мы дежурили круглосуточно и на лету поднимали ресурсы

Автоматическое масштабирование IRL.

Нет. Это, когда критическая ситуация. На моей практике такое было два раза.

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

Так в остальное время же «было три одновременно запущенных инстанса каждого сервиса. Всегда. Даже если сейчас нагрузки нет». Автоматическое масштабирование IRL #2.

по многосоттерабайтной базе

Начинать надо отсюда.

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

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

Текстовый размер повести «Война и мир» - ~4000Kb в UTF-8, т.е. под четыре мегабайта. Полный.

Под словом «несколько» чаще всего подразумевают «три».

В одном террабайте содержится один миллион мегабайт.

Один миллион разделить на четыре - это 250 тысяч. Двести пятьдесят тысяч умножить на «три» террабайта оперативы - это семьсот пятьдесят тысяч полнотекстовых книг размером с «Войну и мир». Пусть меньше, хидеры там, все дела. Пол-миллиона. Библиотека Конгресса может вам завидовать, у вас это все оцифровано =)

А так как нужно было обеспечить отказоустойчивость, это всё дублировалось трижды в географически распределённых датацентрах.

Если не секрет - отказоустойчивость для чего именно, и как победили падение ДНСов? А то вот у нас в\на, месяцок назад отказоустойчивые ресурсы посыпались, из-за пожара на местном ДЦ, где один наш незалежний регистратор хранил НСы. Совпало что меняли батареи на одной линии в то время пока света не было на второй линии, гы.

А ты точно понимаешь, что такое «полнотекстовый поиск»?

Если не секрет - отказоустойчивость для чего именно, и как победили падение ДНСов?

Отказоустойчивость для того, чтобы сервис работал всегда. Например, как ты говоришь, если один датацентр сгорел. В нашем случае ничего не сгорало, но под атакой один из них временно лёг. Но даже если бы он сгорел, это бы не затронуло работу остальных. Просто пришлось бы срочно разворачивать такой же где-то в другом месте, что делается в полуавтоматическом режиме.

DNS - несколько разных способов. Во-первых, опять же географическое разнесение. Во вторых, round-robin с исключениями выпавших. В-третьих, автоматическая корректировка на пограничных шлюзах. Даже за мою личную зону отвечает сейчас два NS'а(третий я пока переделываю, но скоро верну в строй), каждый из которых может стать мастером в любой момент. Потерять зону... Ну я не знаю, как это возможно.

Три инстанса, потому что для большинства сервисов(тот же самый in-memory-кеш) нужен кворум. Т.е. три - это минимум. Если один из них слёг, нагрузку надо распределить. Повторюсь, такая ситуация - это форс-мажор, который бывает очень редко и по очень нестандартному стечению обстоятельств. Поэтому нужно проследить, что всё прошло нормально. В 99% случаев работает автоматика.

Т.е. если в одном из датацентров выключилась стойка, нам на это плевать, нагрузка перераспределится сама. Потом, утром, посмотрим в мониторинг, пнём лабопсов, они пойдут и разберутся со стойкой. Но когда из сети выпал датацентр, оно тоже автоматом распределится по двум оставшимся, но за этим стоит приглядывать.

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

В 2009-м я устроился на одну галеру, которая обслуживала хостинговую компанию современного на тот момент образца. Кластер из десятка веб-серверов, мыло-серверов, БД-серверов, доступы по RSA-брелку, все дела. Только на миграции на один кластер с одного хостинга на наш, переносилось более 20 тысяч сайтов. И как-то выжили без девопсов =) Утерянные технологии предков)

Миграция сайтов... Мыло-серверов... Я же говорю, ностальгия. :)

А тут нужно не просто уметь мигрировать, а смотреть в код, понимать структуру той же бд. Ты вот там выше ругался на NoSQL(я тоже ругаюсь, хотя полтора года занимался именно кешем), там простой миграцией не обойтись(хотя там тоже есть свои особенности со сбросом кеша на диск и переносом между серверами). Там надо вникать в код, понимать, как сервис с ним работает. Например, перестройка структуры redis-кластера по-разному влияет на работу java-софта и golang-софта. Потому что библиотеки разные, в разных версиях ведут себя по-разному(прости за тавтологию). И там, где достаточно послать SIGHUP, чтобы оно перечитало конфигурацию доступных тысяч нод - это хорошо. А там, где для того же нужно запушить изменения в конфиги, раскатать это всё на инстансы(в нашем случае ansible), уже сложнее.

И(заранее) не надо тут говорить про быдлокодеров, которые ничего не понимают и ничего не умеют. У них тоже свои сложные задачи. А мы, девопсы(я лично себя называю админом, скатившимся до девопса) должны сделать так, чтобы их код работал. Как раньше, когда я был «чистым» админом, я должен был сделать так, чтобы сервер был доступен клиенту. Тогда было проще. Сейчас поменялись инструменты, растолстела инфраструктура, но это неизбежно с ростом завязанных на эту инфраструктуру сервисов и увеличения требований к этому всему.

Когда мы стремимся к пресловутой 99%-ой доступности и непрерывному циклу разработки, когда нас в команде таких не один человек, утерянные технологии предков уже не работают. Нельзя копировать сайтики по ftp/scp, нельзя держать базы без репликации, нельзя держать кеш без кластеризации и многие другие «нельзя».

А что, появилась какая-то HA которая не только нормально срабатывает при поломке одной ноды, но и умеет без остановки и танцев с бубном подцепить новую железку вместо сломавшейся и всё на ней восстановить как было?

Например,в GKE --enable-autoprovisioning-autorepair ? И например, установить на него cloud native кластер типа CNPG в качестве примера HA приложения?

Конечно это не мгновенное переключение как vSphere, но подождать несколько десятков секунд, не потратив при этом на vSphere несколько лишних десятков тысяч долларов, наверно, не так уж и плохо?

Кстати у cloud native CockroachDB задержка при сбое будет уже намного лучше (меньше)?

Скорей же сообщи название, а то я со времён недоделанного Remus’а такое ищу. Чтобы несколько серваков у которых идентичное содержимое на дисках и в памяти, один IP на всех, никакого мастера, все равноправные и если ломается тот, который прямо сейчас обслуживает клиента то клиент ничего кроме единичной мизерной задержки в сотню микросекунд не ощущает вообще. Ни разрыва связи, ни потери пакета, ничего.

А причём тут эта академическая поделка/недоделка, у которой overhead более 80%? К 3027 году будет готов к релизу?

vSphere Fault Tolerance? Но узлы сам вроде не добавляет?

И главное, чего Remus так нихрена и не достиг - чтобы вместо сломавшегося сервака можно было подключить свежий, пусть даже с неким предустановленным и специально настроенным софтом, но «пустой», и оно само без каких-либо танцев с бубном восстановило бы на нём актуальное состояние системы - синхронизировало состояние диска и памяти с другими нодами и подключило в кластер.

Я так и не понял, зачем ты притащил сюда этот экспериментальный проект, который к проду абсолютно непригоден?

А то что-то всё то, что нынче называется HA - какой-то одноразовый недоделанный шлак, как правило намного хуже Remus’a. Оно может быть даже сработает как надо один раз при поломке, и то не факт что какое-нибудь соединение не порвётся

или чего-ниубдь недозапишется куда-нибудь,

Нужно использовать synchronous replication, только и всего?

а вот потом, при подключении новой железки один хер надо будет всё останавливать, говорить специальные заклинания, переводить какую-то ноду в мастера, ждать пока всё синхронизируется, переводить обратно в masterless режим и запускать. Дерьмо, в общем, а не HA.

Это ты про клипопс мартышек, которые не умеют в cloud-native ?

Заменяется оборудование/переписывается софт.

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

Зачем тебе мнение лорчан, ОП?

IMHO это какой-то массовый троллинг по предварительному сговору. Stanson не может писать такую хрень, находясь в здравом рассудке и трезвом виде.

Если под HA имеется в виду High Availability - то поржал, это скорей у докеромакак сего не имеется, поскольку докеромакака оперирует не производительностью\оптимизацией, а количествои инстансов, которые сперва упираются в количество железок, а потом в количество денег на покупку новых и новых железок.

Какая связь между HA и оптимизацией производительности?

Мониторинг чего? Если серверной инфраструктуры, то любой админ еще 15 лет назад после поднятия прода, первым делом ставил Нагиос, если извращенец, то Жабикс. Если инфраструктуры до 10 серверов, то хватало и простейших пингдома и иже с ним.

Не то что нынешние «дураки» выдумали систему мониторинга 5-ого поколения Netdata, да?

Например,в GKE

С каких пор кубернетес относится к HA?

но подождать несколько десятков секунд

Какие несколько десятков секунд в HA? Совсем, что-ли?

А причём тут эта академическая поделка/недоделка, у которой overhead более 80%? К 3027 году будет готов к релизу?

При том, что это единственное что похоже на HA. Неубиваемая виртуальная машина которая работает одновременно на нескольких железяках и все эти железяки - одно. Единственное что работает отлично, никак не привязано к софту который крутится на этой штуке, и у которого отсутствует вообще понятие «переключения». При сдыхании железки ни один клиент вообще ничего не замечает, а система продолжает работать даже если железка вообще сгорела синим пламенем. Отличнейшая штука и единственная известная мне нормальная реализация HA. Ну пока не понадобится поднять заменённую ноду.

И с оверхедом ты загнул. Около 50%. В общем-то насрать на такую мелочь.

vSphere Fault Tolerance?

Убогое подобие Remus. Ещё и требует общее хранилище зачем-то. Т.е. добавляется задача сделать это общее хранилище тоже HA, что, внезапно, можно только Remus’ом. Ещё и бредовые требования про процессоры идентичные вплоть до степпинга и пр.

Кроме того, при экспериментах путём выдёргивания шнура питания ведущей ноды из розетки, только в 3 случаях из 10 эта хрень не облажалась.

И да, подключение новой тачки вместо сдохшей - ещё больший цирк с конями чем у Remus.

Я так и не понял, зачем ты притащил сюда этот экспериментальный проект, который к проду абсолютно непригоден?

Этот «экспериментальный проект» у меня на проде уже 10 лет трудится. Ни разу не подводил. Но при замене сдохшей ноды нужны танцы с бубном, что раздражает, ибо нельзя просто послать монтажника с новым серваком чтобы он его просто воткнул взамен сдохшего и ничего не нужно было бы больше делать в принципе.

Нужно использовать synchronous replication, только и всего?

Synchronous replication чего именно?

Это ты про клипопс мартышек, которые не умеют в cloud-native ?

Это я про состяние дел с HA.