En este post intentaré explicar algunos conceptos erróneos sobre la redundancia con los que me encuentro en mi día a día. Ser capaz de explicar a un cliente para qué sirve la redundancia y cuáles no forman parte de sus principales ventajas ayudará a los clientes a evitar expectativas erróneas.
¿Qué significa redundancia en una infraestructura de TI?
El concepto de redundancia en TI es sencillo: crear varias copias de un recurso para que, en caso de fallo, otra copia del recurso pueda cumplir la tarea. La redundancia es la piedra angular para eliminar los puntos únicos de fallo y conseguir así infraestructuras de alta disponibilidad.
Pero la redundancia no sólo funciona como un sistema de «conmutación por error», sino que en algunos componentes como el servidor web, se utiliza para distribuir la carga de manera uniforme y aumentar el número de conexiones que una aplicación puede soportar (como se explica en mi artículo previo sobre concurrencia .)
¿Cuáles son los errores más comunes sobre la redundancia?
Redundancia no significa mejor rendimiento. A menudo, me encuentro intentando explicar a un cliente por qué tener un cluster percona (3 servidores mysql) no mejorará el rendimiento general de la base de datos por 3. De hecho, en algunos componentes el rendimiento será un poco peor o igual que en una configuración de instancia única:
Cluster Mysql: En una configuración de cluster mysql, todas las operaciones de escritura deben ser replicadas en los 3 nodos. Esto aumentará tanto el tiempo que tarda la operación en ser consistente como la probabilidad de que se produzca el bloqueo de la tabla. Por otro lado, si la aplicación está preparada (o si se usa un proxysql), se pueden configurar las peticiones a cluster, de forma que las operaciones de escritura se hagan en un nodo, y las de lectura en los otros dos (Esto puede aumentar un poco el rendimiento para las operaciones de lectura).
Procesos PHP: PHP es single threaded por naturaleza y tomará sólo una CPU para cada petición. La petición de un usuario será procesada con el mismo rendimiento que con 4 o 24 CPUs (siempre que el servidor pueda manejarlo sin cuellos de botella). El rendimiento en PHP está más relacionado con los Ghz y las instrucciones de la CPU.
Varnish: En los servicios de caché, el rendimiento debería ser el mismo que en caso de redundancia. El único (pero importante) CON es que cada instancia de caché se debe calentar por separado (puede utilizar Varnish Enterprise y Cluster para evitar este problema).
La redundancia no es un despilfarro. Si vienes de un entorno industrial o de producción como yo, seguro que habrás oído el término LEAN «Muda». A veces me encuentro discutiendo con un cliente con este tipo de mentalidad sobre la conveniencia de la redundancia en un servicio y cómo afectará este «despilfarro» al coste de la infraestructura. La conveniencia de la redundancia es un compromiso entre «cuánto costará la solución» y «cuánto tiempo de inactividad puedo permitirme». Si tu aplicación es de misión crítica (como un ecommerce con un alto porcentaje de sus ventas procedentes de este canal), se debe adoptar un enfoque para diseñar una infraestructura de alta disponibilidad.
