Сколько может быть мастеров?

Уровни управления в etcd: лидер и мастеры

Вопрос требует уточнения, поскольку термин "мастер" (master) в контексте системы управления конфигурацией etcd — который часто используется в инфраструктуре Kubernetes и упоминается в контексте Go — можно интерпретировать по-разному. В архитектуре Raft (алгоритм консенсуса, лежащий в основе etcd) нет концепции "мастеров". Вместо этого есть Лидер (Leader) и Последователи (Followers).

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

Детали по количеству узлов в кластере

Если же вопрос подразумевает: "Сколько всего узлов (членов) может быть в кластере etcd?", то это уже о размере кластера (cluster size). Рекомендации и ограничения здесь следующие:

• Рекомендуемое количество: Нечетное число узлов: 3, 5 или 7.
• Теоретический максимум: Не имеет строгого ограничения "сверху" в коде, но на практике редко превышает 7 узлов из-за возрастающих накладных расходов.

Почему нечетное число? Это связано с алгоритмом Raft и необходимостью выбора Кворума (Quorum) — минимального большинства узлов, которые должны быть доступны для подтверждения операций. Для кластера из N узлов кворум равен (N/2) + 1. Нечетное число гарантирует, что кластер может пережить отказ того же количества узлов (F), что и четный кластер большего размера, но при этом использует меньше ресурсов. Например:

    *   Кластер из **3** узлов (`N=3`): кворум = 2. Он может пережить отказ **1** узла (`F=1`).
    *   Кластер из **4** узлов (`N=4`): кворум = 3. Он также может пережить отказ только **1** узла (`F=1`), но требует согласия большего числа узлов для каждой операции, что менее эффективно.

Практический пример настройки кластера

Вот как выглядит типичная инициализация кластера из 3 узлов с помощью клиентской библиотеки etcd на Go:

package main

import (
    "context"
    "fmt"
    "go.etcd.io/etcd/client/v3"
    "time"
)

func main() {
    // Конфигурация клиента для подключения к кластеру из 3 "мастеров" (узлов)
    cfg := clientv3.Config{
        Endpoints: []string{
            "http://etcd-node-1:2379",
            "http://etcd-node-2:2379",
            "http://etcd-node-3:2379",
        },
        DialTimeout: 5 * time.Second,
    }

    // Создание клиента
    cli, err := clientv3.New(cfg)
    if err != nil {
        panic(err)
    }
    defer cli.Close()

    // Использование клиента для операции записи (она автоматически
    // отправится текущему Лидеру)
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    _, err = cli.Put(ctx, "sample_key", "sample_value")
    if err != nil {
        panic(err)
    }
    fmt.Println("Запись успешно выполнена через Лидера кластера.")
}

Ключевые выводы

1. Терминология: В контексте etcd/Raft корректнее говорить Лидер (Leader) и Последователи (Followers), а не "мастеры". Лидер — один.
2. Размер кластера: Практически целесообразное количество узлов — 3, 5 или 7. Это обеспечивает отказоустойчивость и эффективность. Кластер из 3 узлов — наиболее распространенный выбор для баланса между устойчивостью и производительностью.
3. Накладные расходы: С увеличением количества узлов растут затраты на:

    *   Сетевой трафик для репликации данных и выборов лидера.
    *   Латентность операций записи (требуется подтверждение от большего числа узлов).
    *   Сложность управления и обслуживания.

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