¿Dónde pones ProxySQL?

En esta publicación de blog, analizamos cómo implementar ProxySQL.

ProxySQL es un proxy de alto rendimiento, actualmente para MySQL y sus bifurcaciones (como Percona Server para MySQL y MariaDB). Actúa como intermediario de las consultas de los clientes que buscan recursos en la base de datos. Fue creado para DBA por René Cannaò, como un medio para resolver problemas complejos de topología de replicación. Cuando agrego ProxySQL con mis clientes, siempre tengo preguntas sobre dónde colocarlo en la arquitectura. Esta publicación debería aclarar esto.

Antes de continuar, es posible que desee saber por qué debería usar este software. Las características que son de interés incluyen:

  • Cortafuegos MySQL
  • Conexión de agrupación
  • Búsqueda de fragmentos y enrutamiento automatizado
  • Capacidad de lectura/escritura dividida
  • Cambiar automáticamente a otro maestro en caso de falla del maestro activo
  • caché de consultas
  • metros de rendimiento
  • ¡Otras características limpias!

Configuracion inicial

En general, se instala en nodos que no tienen una base de datos MySQL en ejecución. Se administra a través de la línea de comandos de MySQL en otro puerto, generalmente 6032. Una vez que se inicia, la configuración en / etc no se usa, y todo lo hace en la CLI. La base de datos backend es en realidad SQLite, y el archivo db se almacena en /var/lib/proxysql.

Hay varias guías para la inicialización y la instalación, por lo que no cubriré esos detalles aquí. Puede ser tan simple como:

arquitectura proxy SQL

Si bien la mayoría primero piensa en instalar ProxySQL en un nodo independiente entre la aplicación y la base de datos, esto tiene el potencial de influir en el rendimiento de las consultas debido a la latencia adicional de las interrupciones de la red.

Para tener un impacto mínimo en el rendimiento (y evitar saltos de red adicionales), recomendamos instalar ProxySQL en los servidores de aplicaciones. Luego, la aplicación se conecta a ProxySQL (que actúa como un servidor MySQL) en el sitio host, utilizando Unix Domain Socket y evitando latencia adicional. Podría usar sus propias reglas de enrutamiento para comunicarse con los servidores MySQL existentes con su propia agrupación de conexiones. La aplicación no tiene idea de lo que sucede más allá de su conexión a ProxySQL.

ProxySQL

Reducción de la superficie de ataque de su red

Otra consideración es reducir la superficie de ataque de su red. Esto significa tratar de controlar cualquier posible vulnerabilidad en el hardware y software de su red que sea accesible para usuarios no autenticados.

Percona generalmente sugiere que coloque una instancia de ProxySQL en cada host de la aplicación, como en la segunda imagen de arriba. Esta sugerencia es ciertamente válida para reducir la latencia en su entorno de base de datos (limitando las interrupciones de la red). Pero si bien esto es bueno para el rendimiento, puede ser malo para la seguridad.

Cada instancia debe poder abordar:

Como puede imaginar, esto es una pesadilla de seguridad. De todos modos, lo tienes X muchas más conexiones cubriendo su red. aquí vamos X mucha más conexión que un atacante podría explotar.

Sin embargo, puede ser mejor tener una o más instancias de ProxySQL entre su aplicación y los servidores MySQL (como la primera imagen de arriba). Esto proporciona una configuración de tipo DMZ razonable que evita la apertura de demasiadas conexiones en la red.

Dicho esto, ambas arquitecturas son configuraciones de producción válidas, según sus necesidades.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario