Паксос и Дискавери
Предположим, я добавляю несколько машин в эластичный кластер и хочу запустить в них какой-то согласованный алгоритм (скажем, Paxos). Предположим, они знают начальный размер сети, скажем, 8 машин.
Таким образом, они запустят согласованный алгоритм, и кворум равен 5.
Теперь рассмотрим эти случаи:
- Я вижу, что процессор слишком низкий, и я уменьшаю размер кластера вдвое, до 4 машин.
- Существует разделение на разделы, и каждый разделитель получает 4 машины.
Если я возьму текущий размер кластера, чтобы получить кворумы, я буду разделен на разделы. Поскольку для базового кластера ситуации (1) и (2) выглядят одинаково. Однако, если я использую фиксированное число, я не могу уменьшить кластер (и я могу столкнуться с несоответствиями из-за разделения, если я увеличу его).
У меня есть третий вариант - информирование всех машин о размере кластера при масштабировании, но есть вероятность, что раздел произойдет, например, непосредственно перед увеличением, и этот раздел не получит новый размер и не будет иметь достаточного кворума для консенсус, используя старый размер.
Является ли Paxos (и любые другие безопасные алгоритмы консенсуса) непригодным для использования в эластичной среде?
2 ответа
Консенсусные протоколы на основе кворума в основном требуют наличия кворума для работы. И Multi-Paxos, и Raft могут использоваться в средах с динамически меняющимися размерами кластеров и кворумов, но это должно выполняться контролируемым образом, который всегда поддерживает согласованный кворум. Например, если вы в настоящее время используете кластер размером 8 и хотите уменьшить этот кластер до размера 4. Вы можете сделать это. Однако решение об уменьшении размера кластера до 4 должно быть согласованным решением, которое было согласовано в первоначальной версии 8.
Ваш вопрос немного неясен, но звучит так, как будто вы спрашивали, можете ли вы безопасно уменьшить размер кластера до 4 в качестве механизма восстановления в случае, если какой-то сетевой раздел делает ваш исходный кластер из 8 неработоспособным. Ответ на этот вопрос фактически отрицательный, поскольку решение сделать это не может быть согласованным, и попытка обойти алгоритм консенсуса практически гарантированно приведет к несоответствиям. Как будет определен новый набор из 4? Как бы вы гарантировали, что все сверстники пришли к одному и тому же выводу? Как вы гарантируете, что все они принимают одно и то же решение одновременно?
Конечно, вы могли бы принять все эти решения вручную и заставить систему восстановиться, отключив консенсусную службу в каждой системе и перенастроив их определение кворума вручную. Предполагая, что вы не облажаетесь (что является чрезвычайно большим предположением для любого реального развертывания), это будет безопасно. Однако лучшим подходом было бы спроектировать систему так, чтобы один или два сетевых раздела либо не останавливали систему (множество сайтов), либо использовали модель возможной согласованности, которая изящно обрабатывает случайные сетевые разделы. Там нет волшебной пули для обхода ограничений CAP.
Paxos и друзья могут масштабироваться эластичным способом (несколько). Однако вместо изменения размера кворума просто добавьте учащихся. Учащиеся - это узлы, которые не участвуют в консенсусе, но принимают все решения. Так же, как и акцепторы, учащиеся принимают чтения и пересылают записи руководителю.
Есть два стиля обучения. Первый слушает все события от акцепторов; во втором лидер передает все совершенные переходы ученикам