Split-brain, Quorum и Fencing. Говоря о распределенных систем | //АйТи интерн

Split-brain, Quorum и Fencing.

Говоря о распределенных системах многие по умолчанию подразумевают, что они должны быть высокодоступны (high availability - HA ) и по возможности еще и отказоустойчивы ( fault tolerance).

Упрощенно высокую доступность можно свести к автоматическому включению в работу запасного ресурса при остановке или проблемах основного. Что-то упало - мы запускаем его другую копию, которая уже должна быть готова к этому.

Допустим у нас есть 3 сервера “A”, “B”, “C” на которых запущены копии одного приложения. Они умеют общаться друг с другом по сети. У этих копий есть основной экземпляр (главноый, main, master) и есть запасные. Другими словами у нас есть кластер какого-то приложения.

Тут сразу же возникают вопросы: сколько копий (по-умному это называется “реплика”) нам нужно запускать, как отличить падение мастера от реплики? Например, у сервера “C” (картиночка ниже отдельным постом) пропал доступ к сети, и он не может коммуницировать с “А” и “B”. При этом запросы в систему приходят на “B” и на одинокий “C” (почему такое возможно обсудим позже).

Это и есть фундаментальная проблема распределенных систем - Split-brain.

Split-brain возникает при расщеплении распределенной системы на несколько частей, которые не могут взаимодействовать друг с другом. Эту проблему должен уметь решать любой софт, который пытается обеспечить HA. Основными методами решения этой проблемы - Quorum и Fencing. Многие инструменты, которые используют разработчики в своей работе, умеют с этим справляться из коробки, но если вы пишите свое кластерное решение, то вам придется это сделать самим.

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

@it_intern

#архитектура #распределенные_системы