Настройка размера реплик состояной службы

Размер набора реплик для служб с сохранением состояния настраивается с помощью двух параметров.

• TargetReplicaSetSize — показатель количества реплик, которые система создает и поддерживает для каждого набора реплик сервиса.
• MinReplicaSetSize — минимально допустимое количество реплик для каждого набора реплик службы

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

Например, если TargetReplicaSetSize =5, MinReplicaSetSize =3, то обычно (без сбоев) в представлении Service Fabrics набора реплик будет пять реплик. При сбоях представление набора реплик в Service Fabrics будет уменьшаться до тех пор, пока не достигнет MinReplicaSetSize.

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

Это важно

В примере, где TargetReplicaSetSize = 5, MinReplicaSetSize = 3, большинство кворума MinReplicaSetSize равно 2. Это означает, что даже в случае трех одновременных сбоев, которые приводят к тому, что остаются активными только две реплики, Service Fabric всё равно будет считать, что в наборе реплик находятся 3 реплики (две активные и одна неактивная), и наличие двух активных реплик будет достаточно для достижения кворума большинства.

Примеры неоптимальных конфигураций

TargetReplicaSetSize = 3; MinReplicaSetSize = 2

Такая конфигурация часто входит в потерю кворума (когда запланированное и незапланированное переключение резерва происходит одновременно). Чтобы восстановиться после потери кворума, недостаточно, чтобы только одна реплика восстановила свою работу — необходимо, чтобы та самая реплика, которая была частью набора реплик, восстановила свою работу.

1. Раздел имеет три реплики: A, B, C
2. Реплика A выходит из строя, решение Service Fabric уменьшает размер набора реплик до 2 (B, C)
3. Непланированная отработка отказа происходит, реплика B также исчезает. Раздел теперь находится в состоянии потери кворума
4. Если реплика A вернется, раздел останется в состоянии потери кворума, так как A не является частью текущего набора реплик (B, C). Потеря кворума будет исправлена только когда реплика B вернётся.

TargetReplicaSetSize = 3, MinReplicaSetSize = 3

Такая конфигурация часто попадает в потерю кворума (при планировании и незапланированной отработке отказа одновременно). Однако, как только любая из этих реплик восстановится, раздел восстановится после потери кворума.

Предупреждение

Такая конфигурация по-прежнему не является оптимальной, это лишь немного лучше, чем TagetReplicaSetSize =3, MinReplicaSetSize = 2.

1. Раздел имеет три реплики: A, B, C
2. Реплика A идет вниз, набор реплик остается неизменным (A, B, C)
3. Непланированное переключение на резервный сервер происходит, реплика B также выходит из строя. Партиция теперь находится в состоянии потери кворума.
4. Как только любая из реплик A или B возобновляет работу, раздел восстановит кворум, так как и A, и B являются частью текущего набора реплик.

Дальнейшие шаги

• Узнайте о потере кворума и аварийном восстановлении в Azure Service Fabric
• Узнайте о вариантах поддержки Service Fabric.