Паксос для сборщика систем

Question

Почему в Paxos для System Builder требуется отдельная фаза выборов лидеров, а не фаза подготовки к выборам лидеров? Какие преимущества дает эта дополнительная фаза перед использованием неявной фазы подготовки?

Answer 1

Вы правы в том, что в Paxos нет необходимости реализовывать определенный алгоритм выбора лидера, как описано в Paxos Made Simple. Вам просто нужно рандомизировать тайм-ауты, чтобы увидеть прогресс от лидера, и появится стабильный лидер. Больше ничего не требуется, вы просто повторно отправляете сообщения и тайм-аут на лидера, и вы запускаете Prepare. Я опишу это подробно здесь.

Тем не менее, вы можете использовать собственный механизм выбора лидера, который вы предпочитаете, например,

1. Тот, где вы можете доказать, что не будет бесконечных лидерских поединков
2. Один оптимизирован для среднего времени восстановления
3. Один оптимизирован, чтобы гарантировать, что восстановление произойдет в течение определенного времени
4. Один оптимизирован для простоты и минимального кода

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

Paxos для сборщиков систем: обзор гласит:

"Паксос" жив так же, как и протокол о выборах его лидера

Подтверждение важности выбора лидера избирательного протокола для обеспечения жизнедеятельности. Они также спрашивают:

Какие жизненные свойства гарантирует [имплементация Паксоса]?

также

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

а также

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

Это не до конца статьи они говорят:

Эти детали являются критически важными компонентами для создания высокопроизводительного, высокодоступного механизма репликации на основе Paxos.

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

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

Раздел 3 дает сильный намек на их мышление:

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

Они также говорят:

Сильный L1 требует, чтобы прогресс был достигнут даже перед лицом (быстро) меняющегося большинства. Мы полагаем, что ни один Paxos-подобный алгоритм не сможет удовлетворить это требование. Если большинство меняется слишком быстро, то оно никогда не будет достаточно стабильным, чтобы завершить протокол выборов лидера.

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

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

ИМХО практичные сборщики систем должны использовать случайные таймауты по умолчанию. Рандомизированные тайм-ауты - самая простая вещь, которая может работать, но они не гарантируют, что они не будут бесконечными поединками лидера. Это просто невероятно. Тем не менее, рандомизированные тайм-ауты очень привлекательны с точки зрения простоты и минимального кода, и поэтому менее вероятно, что они будут содержать ошибки. Вот почему алгоритм Рафта использует их. Существует огромное количество практических алгоритмов, стохастических по своей природе.

Практически вы можете жить со случайными таймаутами, поскольку простейшая вещь, которая может работать, зависит от вашего варианта использования. Это очень типичный вариант использования для репликации только метаданных, а не основных данных, с использованием алгоритма строгой согласованности. Есть много в конечном итоге непротиворечивых систем, которые полагаются на строго согласованную конфигурацию, но имеют высокопроизводительную прямую запись. Поэтому часто можно создавать системы, в которых произошел сбой лидера Paxos, но система все еще работает и принимает операции чтения или записи с различными гарантиями. В таких системах использование "случайных" тайм-аутов для выборов лидеров с экспоненциальной отсрочкой может быть "достаточно хорошим". Корфу является примером высокопроизводительного строго согласованного движка, который использует Paxos для отображения того, какие диапазоны записи реплицируются на какие узлы. Тем не менее, клиенты пишут напрямую на несколько узлов, используя цепную репликацию, а не через лидера. Он гарантированно будет правильным, если каждый узел будет иметь единообразное представление о членстве в кластере. Тем не менее, эти изменения медленно через Paxos и большие объемы записей Корфу могут продолжаться во время выборов лидера Paxos, так что случайные таймауты могут быть достаточно хорошими.

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