Evite que VRRP Master se convierta en Master una vez que haya fallado

12

Tengo dos máquinas (A y B, A es Master) que ejecutan VRPP (desde keepalived) para una IP virtual.

¿Cómo puedo evitar que A se convierta en Maestro nuevamente si ha fallado y vuelve a subir (por cualquier razón)?

Estoy haciendo esto para que tengamos una sola conmutación por error al segundo cuadro, y volver a la normalidad requeriría una intervención manual.

linux keepalived vrrp

— MrMagu
fuente

Soy demasiado nuevo para crear la etiqueta "VRRP"

— MrMagu

14

De acuerdo con este hilo relativamente antiguo en la lista de desarrolladores keepalived, se puede hacer. Configura ambos servidores para que tengan la misma prioridad (o ninguno), y no declara el estado como MAESTRO o RESPALDO, y en su lugar establece el estado en IGUAL para ambos.

EDITAR (07-dic-2017):

Parece que EQUAL no es realmente un estado válido, a pesar de que parece proporcionar el efecto deseado en el momento en que se publicó esta respuesta. Tenga en cuenta los comentarios a continuación, en particular el enlace a la lista de problemas actuales para keepalived proporcionado por @cristi.

— James Sneeringer
fuente

3

Gracias. También vale la pena tener en cuenta que, usando la configuración anterior (de igual prioridad y usando "IGUAL") si ningún maestro se ha hecho cargo, la instancia VRRP con la IP más baja se convertirá en MAESTRA.

— MrMagu

1

Esto está mal. Vea este mensaje de los desarrolladores: github.com/acassen/keepalived/issues/707

— cristi

@cristi: era una solución que funcionaba en el momento en que se publicó (2009), que a su vez se basó en información que reconocí claramente que era antigua incluso en ese momento (2003). He actualizado el enlace en mi respuesta a uno que funciona ya que osdir.com ya no parece tener los archivos keepalived-devel. Supongo que, en ese momento, el software ignoró silenciosamente la EQUALdirectiva inválida y la trató como si no se hubiera establecido ninguna prioridad (que resultó tener el efecto deseado).

— James Sneeringer

8

La forma en que resolvimos esto es agregando la nopreemptbandera a nuestro archivo de configuración keepalived. No tuve que cambiar nada más (todavía dejó uno como MASTERy uno como BACKUPy así sucesivamente). Básicamente, esto le dice que no cambie los maestros solo porque un nuevo servidor se conectó, solo cambie cuando el maestro actual falle.

— davr
fuente

44

de " article.gmane.org/gmane.linux.keepalived.devel/1537 " Si "estado" se establece en MAESTRO, "nopreempt" se ignora básicamente ya que cuando la máquina con "estado MAESTRO" regresa, simplemente tomará la IP de la máquina con "copia de seguridad del estado" sin siquiera tener una elección. Tuve que configurar mis dos máquinas para que indiquen COPIA DE SEGURIDAD con una de mayor prioridad para que "nopreempt" funcione según lo previsto.

— MrMagu el

Se eliminó la prioridad y el estado y se agregó nopreempt. Funciona bien para mí

— Rihard Novozhilov

-1

Según tengo entendido, cuando aparece un nuevo servidor VRRP, obliga a una elección, y el servidor actual no obtiene ningún beneficio, por lo que el viejo maestro vendrá y ganará la elección. Dudo que haya mucho que puedas hacer para detener esto, más allá del brutal Shoot The Other Node In The Head. Keepalive puede tener alguna configuración para controlar el proceso de elección. Lamentablemente no tengo tiempo para comprobarlo ahora, pero intentaré mirar más tarde.

— David Pashley
fuente

Hay una bandera de configuración para hacer esto, por lo que esta respuesta es incorrecta.

— davr

La respuesta votada es correcta para una implementación general de vrrp en la que no desea que un maestro se haga cargo cuando regrese al servicio. Como usted dice, también hay una forma de hacer esto más actualizada que probablemente sea más correcta cuando se hacen cosas de Linux HA en lugar de simplemente usar vrrp para proporcionar redundancia L3 para una ruta predeterminada (la razón más tradicional para usar vrrp).

— chris