Как стать автором
Обновить

Комментарии 5

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


Жил был маленький ceph-кластер, на котором я проверял разные crush map'ы. Для рассказа не важно, что это такое. Важно, что это был настоящий (хоть и маленький кластер). Три монитора, консенсус, PAXOS, пять OSD нод (с данными). Он был готов пережить смерть любого монитора, и любых трёх (!) OSD нод без потери доступности, и смерть двух мониторов и четырёх OSD нод без потери данных.


… Но я решил… Я не помню, что я уже решил. Что-то пошевелить. Я написал ceph osd crush move pp1 root=fast2500… Мониторы это съели.


И обыспались. Краш, и всё.


https://tracker.ceph.com/issues/16525#change-73734


Было три монитора. Все три приняли данные, все три работали на одной и той же копии данных, все три выполнили одну и ту же последовательность операций, которая привела к


(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x80) [0x55cda5fb9fa0]

ЧПОК. Был кластер. надёжный. Нет кластера.


В любом кластере есть фатальный источник correlated failures — это ошибки в ПО. Одинаковое ПО на всех нодах, одинаковые баги, одновременно всюду.


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


Так что кластера — это плохо.


Федерации (когда разные ноды работают на разном ПО) — это хорошо. Сравните с DNS, где, даже если все bind'ы во всём мире одновременно обысыпятся, останутся рабочими powerdns, MS DNS и т.д.

Отличная история!
Но, к сожалению, такой проект, как описан в статье, в виде федерации не сделать. Новые версии Физалии и других компонент EBS накатывается достаточно часто. И многие изменения очень большие. Например, переход EBS io1 к io2 увеличил Durability с трех до пяти 9-ок. Сейчас делают Block Express, там даже сетевой протокол Data Plane поменяли. Представляете, сколько там архитектурно переделали? Поэтому быстро реализовывать, накатывать и откатывать изменения — это не пожелание, а жесткое требование.
Делать федерацию и держать хотя бы две команды, которые будут пилить одно и тоже, просто не реально. И время разработки замедлится во много раз, и управлять этим хозяйством будет не возможно. Поэтому идем кластерной «дорогой», но стараемся контролировать и уменьшать blast radius и время восстановления.

не реально => дорого.


Пока, однажды, таки не случится (условная) 62ая секунда в минуте. Во всех регионах сразу.


Насчёт "скорость разработки". На самом деле, если две команды работают раздельно, то возникает сразу же потребность в контракте и интерфейсе. Что, на удивление, увеличивает надёжность просто по факту ругани между командами в связи с соблюдением/не соблюдением стандарта.

Интересно, возможен ли такой способ разработки, как вы описываете, в реальной жизни?
Можете привести пример разработки коммерческого продукта/сервиса?
DNS, Linux и пр. краудсорс, чур, не рассматривать ;)

Ну вот тут вот пишут: https://ieeexplore.ieee.org/document/8759719


Вроде, говорят, в ответсвенном софте с failover'ом, система на которую failover должна быть независимой.


В принципе, компиляторы так делают — несколько реализаций одного стандарта.

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