Estoy usando Docker Swarm que abarca múltiples centros de datos. The Swarm se ejecuta en una "nube privada virtual".
Uno de los centros de datos que participan en la instalación tiene un enlace algo más lento que los demás. Me gustaría evitar que se programe un servicio particularmente sensible a la latencia en ese centro de datos.
- Puedo utilizar restricciones de ubicación, pero eso afectará la disponibilidad. Si por alguna razón el centro de datos "lento" fuera el único en funcionamiento, las restricciones garantizarán que el servicio restringido nunca se programe en ese centro de datos. Afecta la disponibilidad.
- Puedo utilizar las preferencias de ubicación, pero eso es sólo una preferencia. Si agregué la etiqueta
lowlatencya todos los nodos excepto a los del centro de datos "lento", es posible que el servicio aún esté programado allí. Después de todo, es sólo una preferencia.
¿Existe alguna manera de restringir de alguna manera un servicio a ciertos nodos, pero permitir que Docker programe el servicio en otros nodos si los nodos preferidos no están disponibles?
Respuesta1
No, esta no es una función integrada en el modo Swarm.
La única preferencia de ubicación disponible actualmente es distribuir la carga de trabajo entre los valores de una etiqueta. Esto se utiliza para evitar que todas las réplicas se programen en una única zona de disponibilidad, por ejemplo, todas las cargas de trabajo en el mismo rack, centro de datos, etc. No existe ninguna preferencia de ubicación que actuaría como una restricción suave.
La otra opción disponible en la programación de enjambres es una restricción, y es una restricción estricta. Las cargas de trabajo no se programarán en nodos que no cumplan con la restricción, incluso si eso significa que no se pueden programar en ningún lugar y el servicio permanece inactivo.
Lo más cerca que puede llegar a su objetivo deseado es ejecutar un proceso adicional para detectar la interrupción de todos los demás centros de datos y ajustar la restricción de su servicio; sin embargo, sospecho que eso tendrá dos problemas correspondientes. En primer lugar, con los otros centros de datos inactivos, es probable que haya perdido quórum con sus gerentes, no se producirá ninguna actividad de programación y los comandos a cualquier gerente en ejecución fallarán debido a la pérdida de un líder. Y en segundo lugar, si tiene quórum, los nodos en el centro de datos restante probablemente quedarán sobreaprovisionados debido a las otras cargas de trabajo que se están reprogramando. Esto se conoce como el problema del rebaño atronador que requiere establecer requisitos de CPU y memoria en sus contenedores. Esos requisitos bloquearían la programación de nuevos trabajos en el nodo para evitar una nueva interrupción y evitar que su servicio modificado encuentre un nodo con capacidad.