Dos réplicas en vez de tres ocuparon un 33,3 % menos de bloques asignados en los volúmenes nuevos que comparé en Longhorn. Con los mismos 512 MiB iniciales, la suma de todas las copias pasó de 1.682,039 a 1.121,359 MiB. El ahorro de espacio fue claro. El rendimiento dependió de la carga: tres copias favorecieron la lectura aleatoria y dos las operaciones secuenciales, mientras la escritura aleatoria dejó resultados próximos.
Ese ahorro supone conservar una copia menos. La comparación permite valorar capacidad y rendimiento en esa colocación concreta de mi Harvester, sin medir fallos ni reconstrucciones. Tampoco mide cuánto espacio libera reducir las réplicas de un volumen antiguo. Para interpretar el tercio ahorrado, primero hay que separar el tamaño que ve la aplicación de lo que ocupan los discos.
Primero, contar el espacio correcto#
Cada volumen ofrecía 1 GiB a la aplicación. Ese tamaño lógico era idéntico, con independencia de las copias que Longhorn mantenía por debajo. Para el programa que escribe, seguía siendo el mismo espacio disponible.
La planificación cambia: dos réplicas suponen 2 GiB nominales y tres suponen 3 GiB. Pero eso tampoco dice cuántos bloques están ocupados en ese momento. Un volumen recién creado y otro con datos y snapshots pueden tener historias muy diferentes.
Por eso medí los bloques asignados en los directorios de cada réplica y sumé todas las copias. Estos fueron los resultados:
| Medida | Dos réplicas | Tres réplicas |
|---|---|---|
| Tamaño lógico del volumen | 1.024 MiB | 1.024 MiB |
| Capacidad nominal replicada | 2.048 MiB | 3.072 MiB |
| Datos iniciales escritos | 512 MiB | 512 MiB |
| Bloques asignados, sumando las copias | 1.121,359 MiB | 1.682,039 MiB |
Con el mismo contenido inicial, la diferencia fue de unos 561 MiB. Es espacio asignado por los sistemas de archivos que alojan las réplicas, incluidos sus metadatos. Para este ensayo, mantener la tercera copia tenía un coste de disco perfectamente visible.
Aquí hay una trampa al mirar cifras. El tamaño aparente de un archivo disperso puede indicar cuánto podría ocupar, aunque todavía no tenga todos esos bloques asignados. Y el campo actualSize de Longhorn tampoco fue la suma física utilizada en esta comparación. La cifra de la tabla salió de medir cada directorio, no de multiplicar un indicador del panel.
También hay una diferencia práctica entre comparar dos volúmenes nuevos y reducir las copias de uno antiguo. Esta prueba no mide cuánto tarda una reducción de réplicas en devolver espacio. El historial de escritura y los snapshots importan, como explica la documentación de tamaño de Longhorn. No daría por liberado un tercio del disco solo por cambiar un ajuste.
Menos copias no significó más velocidad en todo#
Para comprobar el rendimiento utilicé el mismo cliente y la misma configuración de los volúmenes, salvo el número de réplicas. Ejecuté tres tandas por opción para cada carga, alternando el orden. En la tabla aparecen las medianas y, entre paréntesis, los valores mínimo y máximo.
| Carga | Dos réplicas | Tres réplicas |
|---|---|---|
| Lectura aleatoria, bloques de 4 KiB | 6.409 IOPS (6.401–6.431) | 9.871 IOPS (9.834–9.899) |
| Escritura aleatoria, bloques de 4 KiB | 1.651 IOPS (1.587–1.722) | 1.640 IOPS (1.586–1.695) |
| Lectura secuencial, bloques de 256 KiB | 215,03 MiB/s (183,73–215,43) | 158,72 MiB/s (125,87–161,64) |
| Escritura secuencial, bloques de 256 KiB | 104,85 MiB/s (76,61–104,98) | 51,18 MiB/s (12,19–53,04) |
Las IOPS cuentan operaciones de entrada y salida por segundo. En lectura aleatoria, tres réplicas completaron más operaciones. En las cargas secuenciales, dos copias transfirieron más datos por segundo. La escritura aleatoria dejó resultados próximos y rangos solapados, sin una ventaja útil acreditada para ninguna opción.
La escritura secuencial merece detenerse un momento. Con tres copias, una tanda cayó hasta 12,19 MiB/s. En esa misma opción, el percentil 99 de latencia de finalización llegó a unos 1.116 ms en una tanda. Es decir, hubo una cola de operaciones con esperas bastante mayores que las que sugiere mirar solo la velocidad mediana.
Ese resultado forma parte de la prueba. No identifiqué su causa, así que no lo convertiría en una penalización fija de la tercera réplica.
La colocación ayuda a entender el alcance: ambas opciones tenían una copia local al cliente y otra en un segundo nodo. La configuración de tres añadía una copia en un tercer nodo, con discos heterogéneos. Es una comparación de esa colocación real en mi Harvester compartido, con cargas breves y un conjunto pequeño de datos. El efecto del disco adicional y el del número de copias no están aislados.
Por eso no bajaría réplicas buscando una aceleración general. Para decidir sobre rendimiento, me interesa la carga concreta que voy a ejecutar. En este caso, la lectura aleatoria ya basta para desmontar la idea de que quitar una copia siempre hace todo más rápido.
La tercera copia compra margen durante una avería#
El ahorro de capacidad tiene una contrapartida sencilla. En la colocación comprobada, cada copia estaba en un nodo distinto. Con dos copias sanas, perder una deja una. Con tres, perder una deja dos.
Lo que cambia es el margen mientras se repara el problema o se reconstruye la réplica. Con una sola copia restante, otra pérdida antes de recuperar la redundancia tiene consecuencias diferentes. Ese margen también ocupa disco.
Esto describe las copias y su colocación, no una prueba de continuidad: no provoqué fallos de nodo, disco o red ni medí tiempos de reconstrucción. Tampoco equivale a garantizar que tres réplicas mantengan el servicio con dos nodos caídos. Para que el clúster funcione importan además el cliente, la red y el plano de control.
Y una réplica no sustituye a un backup independiente. Si se borra un archivo o se propaga una corrupción lógica, tener más copias del estado actual no proporciona por sí solo una versión anterior recuperable.
Qué haría con dos y qué conservaría con tres#
Me parece razonable considerar dos réplicas para datos que puedo reproducir o cuya recuperación independiente tengo resuelta, si acepto el menor margen durante una avería. En esos casos, recuperar capacidad puede ser más útil que mantener una tercera copia.
Para datos donde me importe conservar más margen durante la reparación, mantendría tres. La decisión depende de lo que cuesta recuperar el servicio y de qué otra protección tengo, además del espacio libre.
La prueba me deja un criterio concreto: dos copias ahorraron un tercio de los bloques asignados en estos volúmenes, pero no ganaron todas las cargas. Eso sostiene una decisión de capacidad, no una reducción global de réplicas por defecto.
Cuando vuelva a mirar un volumen de 1 GiB, distinguiré lo que ve la aplicación de lo que guardan los discos. La copia que quite puede dejar espacio para otra máquina. También será una copia menos si algo falla.