Un balanceador de carga de base de datos, o proxy inverso de base de datos, distribuye la carga de trabajo entrante de la base de datos entre varios servidores de base de datos que se ejecutan detrás de él. Los objetivos de tener balanceadores de carga de base de datos son proporcionar un punto final de base de datos único para que las aplicaciones se conecten, aumentar el rendimiento de las consultas, minimizar la latencia y maximizar la utilización de recursos de los servidores de base de datos.
Puede haber dos formas de topología del balanceador de carga de la base de datos:
- Topología centralizada
- Topología distribuida
En esta publicación de blog, cubriremos ambas topologías y comprenderemos algunos pros y contras de cada configuración. Además, ¿sería posible mezclar ambas topologías?
Topología centralizada
En una configuración centralizada, un proxy inverso se encuentra entre el nivel de datos y el de presentación, como se representa en el siguiente diagrama:
Para eliminar un punto único de falla, se debe establecer dos o más nodos de equilibrador de carga con fines de redundancia. Si su aplicación puede manejar múltiples puntos finales de base de datos, por ejemplo, la aplicación o el controlador de la base de datos es capaz de realizar comprobaciones de estado si el equilibrador de carga está en buen estado para el procesamiento de consultas, probablemente pueda omitir la parte de la dirección IP virtual. De lo contrario, ambos nodos del balanceador de carga deben vincularse con un nombre de host común o una dirección IP virtual, para brindar transparencia a los clientes de la base de datos donde solo necesita usar un único punto de conexión de la base de datos para acceder al nivel de datos. También es posible usar DNS o asignación de host si desea omitir el uso de direcciones IP virtuales.
Este enfoque basado en niveles es mucho más simple de administrar debido a su ubicación independiente de host estático. Es muy poco probable que el nivel del equilibrador de carga se escale horizontalmente (agregando más nodos) debido a su base sólida en resiliencia, redundancia y transparencia para el nivel de la aplicación. Probablemente necesite ampliar el host (agregar más recursos al host), lo que normalmente ocurrirá en el futuro, después de que las cargas de trabajo del balanceador de carga se vuelvan más exigentes a medida que su negocio crezca.
Esta topología requiere un nivel y hosts adicionales, lo que puede resultar costoso en una infraestructura básica con servidores físicos. Esta configuración es más fácil de administrar en un entorno de nube o virtual, donde tiene la flexibilidad de agregar un nivel adicional entre el nivel de la aplicación y el de la base de datos, sin que le cueste demasiado el costo de la infraestructura física, como la electricidad, el espacio en rack y los costos de red.
Topología distribuida
En una configuración de topología distribuida, los balanceadores de carga se ubican dentro del nivel de presentación (aplicación o servidores web), como se simplifica en el siguiente diagrama:
Las aplicaciones tratan el balanceador de carga de la base de datos de manera similar a un servidor de base de datos local, donde el el equilibrador de carga se convierte en la representación de las bases de datos remotas desde la perspectiva de la aplicación. Por lo general, el equilibrador de carga escuchará la interfaz de red local como 127.0.0.1 o "localhost", lo que optimizará el host de la base de datos del extremo de la base de datos para las aplicaciones.
Una de las ventajas de ejecutar esta topología es que no necesita hosts adicionales para equilibrar la carga. Al combinar el nivel del balanceador de carga dentro del nivel de presentación, podríamos ahorrar al menos dos hosts. En un entorno completo, esta topología podría ahorrarle mucho dinero a lo largo de los años. En general, la carga de trabajo del equilibrador de carga es mucho menos exigente si se compara con las cargas de trabajo de la base de datos o la aplicación, lo que justifica compartir los mismos recursos de hardware con las aplicaciones.
Cuando se ubica junto con el servidor de aplicaciones, acerca el proxy inverso a la aplicación y elimina el punto único de falla. Esto puede mejorar significativamente el rendimiento de la aplicación cuando hay una separación geográfica entre la aplicación y el nivel de datos, especialmente para los balanceadores de carga de bases de datos que admiten el almacenamiento en caché de conjuntos de resultados como ProxySQL y MaxScale. Por otro lado, la cantidad de balanceadores de carga de la base de datos suele ser igual a la cantidad de nodos de la aplicación, lo que significa que si el nivel de la aplicación se amplía, la cantidad de balanceadores de carga de la base de datos aumentará, lo que podría degradar el rendimiento del estado de la base de datos. servicio de cheques. Tenga en cuenta que las comprobaciones de estado del equilibrador de carga son un poco más conversadoras debido a su responsabilidad de mantenerse al día con el estado correcto de los nodos de la base de datos.
Con la ayuda de las herramientas de automatización de la infraestructura de TI como Chef, Puppet y Ansible junto con las herramientas de orquestación de contenedores, ya no es una tarea imposible automatizar la implementación y la administración de varias instancias de balanceador de carga para esta topología. Sin embargo, habrá otra curva de aprendizaje para que el equipo de operaciones proponga políticas de administración e implementación de grado de producción probadas en batalla para reducir el trabajo excesivo al manejar muchos nodos de balanceador de carga. No se pierda todos los aspectos de administración importantes para el balanceador de carga de base de datos, como copia de seguridad/restauración, actualización/degradación, administración de configuración, control de servicios, administración de fallas, etc.
La topología distribuida se puede combinar con la topología centralizada para algunos balanceadores de carga de bases de datos compatibles, como ProxySQL, como se ilustra en el siguiente diagrama:
Los "servidores" backend de una instancia de ProxySQL pueden ser otro conjunto de ProxySQL en su lugar, nodos. Con esta configuración, una dirección IP virtual no es necesaria para el acceso de punto final único a los nodos de la base de datos, ya que la instancia de ProxySQL local alojada localmente en el servidor de aplicaciones será el acceso de punto final único desde el punto de vista de la aplicación.
Sin embargo, esto requiere dos versiones de configuraciones del balanceador de carga:una que reside en el nivel de la aplicación y otra que reside en los niveles del balanceador de carga. También requiere más hosts, excluyendo la necesidad de aprender sobre la tecnología de dirección IP virtual, la conmutación por error de IP, etc. Las ventajas y desventajas de las configuraciones distribuidas y centralizadas se fusionan en esta topología.
Conclusión
Cada topología tiene sus propias ventajas y desventajas y debe planificarse bien desde el principio. Esta decisión temprana es fundamental y puede influir enormemente en el rendimiento, la escalabilidad, la confiabilidad y la disponibilidad de su aplicación a largo plazo.
