En aquest post intentaré explicar alguns conceptes erronis sobre la redundància amb què em trobo en el meu dia a dia. Ser capaç d’explicar a un client per a què sirveix la redundància i quines no formen part dels seus principals avantatges ajudarà als clients a evitar expectatives errònies.
Qué significa redundància en una infraestructura de TI?
El concepte de redundància en TI és senzill: crear diverses còpies d’un recurs per a que, en cas de fallada, una altra còpia del recurs pugui realitzar la tasca. La redundància és la pedra angular per a eliminar els punts únics de fallada i aconseguir així infraestructures d’alta disponibilitat.
Però la redundància no només funciona com un sistema de “commutació per error”, sinó que en alguns components com el servidor web, s’utilitza per a distribuir la càrrega de manera uniforme i augmentar el nombre de connexions que una aplicació pot suportar (com s’explica en el meu article previ sobre concurrència .)
Quins són els errors més comuns sobre la redundància?
Redundància no significa millof rendiment. Sovint, em trobo intentan explicar a un client per què tenir un clúster percona (3 servidors mysql) no millorarà el rendiment general de la base de dades per 3. De fet, en alguns components el rendiment serà una mica pitjor o igual que en una configuració d’instància única:
Cluster Mysql: En una configuració de clúster mysql, totes les operacions d’escriptura han de ser replicades en els 3 nodes. Això augmentarà tant el temps que triga l’operació en ser conscient com la probabilitat de que es produeixi el bloqueig de la taula. D’altra banda, si l’aplicació està preparada (o si es fa servir un proxysql), es poden configurar les peticions a clúster, de manera que les operacions d’escriptura es facin en un node, i les de lectura en els altres dos (això pot augmentar una mica el rendiment per a les operacions de lectura).
Processos PHP: PHP és single threaded per naturalesa i agafará només una CPU per cada petició. La petició d’un usuari serà processada amb el mateix rendiment que amb 4 o 24 CPUs (sempre que el servidor pugui manejar-ho sense colls d’ampolla). El rendiment en PHP està més relacionat amb els Ghz i les instruccions de la CPU.
Varnish: En els servidors de caché, el rendiment hauria de ser el mateix que en el cas de redundància. L’única (però important) CON és que cada instància de caché s’ha d’escalfar per separat (pot utilitzar Varnish Enterprise i Clúster per evitar aquest problema).
La redundància no és un balafiament. Si provens d’un entorn industrial o de producció com jo, segur que hauràs sentit el terme LEAN “Muda”. A vegades em trobo discutint amb un client amb aquest tipus de mentalitat sobre la conveniència de la redundància en un servei i com afectarà aquest “balafiament” al cost de la infraestructura. La conveniència de la redundància és un compromís entre “quant costarà la solució” i “quant temps d’inactivitat puc permetre’m”. Si la teva aplicació és de missió crítica (com un ecommerce amb un elevat porcentatge de les seves vendes procedents d’aquest canal), s’ha d’adoptar un enfocament per a dissenyar una infraestructura d’alta disponibilitat.
