Puede que en determinados escenarios necesitemos mover el vol0 o volumen root de NetApp de un agregado a otro. Uno de los casos en los que me he encontrado ha sido una NetApp donde, en un primer diseño, habían discos SAS y SATA mezclados repartidos de forma homogénea en las dos controladoras del chasis y tras la compra de más discos se decidió mover los rápidos a una controladora y los lentos a la otra.
De forma esquemática el caso del ejemplo tenía la siguiente distribución de discos:
NetApp1: 6+1 SPARE discos SAS formando el aggr0 (root) y 6+1 SPARE discos SATA formando el aggr1
NetApp2: la misma disposición de discos siendo también root el agregado SAS
Ampliación: 6 discos SAS y 6 discos SATA
Para optimizar el rendimiento en este escenario se tuvo en cuenta:
a) Si se reparten los discos de forma homogénea 3+3 quedan los agregados con 9 discos SAS y 9 discos SATA (por controladora). Si se hace el movimiento y se reagrupan todos los discos se obtienen agregados de 18 discos (a mayor número de discos más rendimiento). En este caso además los RGs son inicialmente de 6 discos por lo que tras el movimiento se pueden configurar 2 RGs de 9 discos para un rendimiento más óptimo.
b) El rendimiento general de una controladora no es óptimo si ésta tiene que cambiar su velocidad de acceso cuando lee/escribe SAS o SATA.
Por tanto la posibilidad de mover el volumen de root es determinante para la optimización del sistema de almacenamiento en este escenario. La forma de proceder es la siguiente:
1) Asignación de los nuevos discos SAS a NetApp1: esto se haría de forma habitual con los comandos disk assign.
2) Cambiar el tamaño máximo de los RGs a 9: con esto conseguimos formar RG0 y RG1 de 9 discos cada uno.
3) Ampliación del agregado aggr0 de la NetApp1 con los 6 discos: en este punto la controladora dispondrá de un RG0 de 9 discos y un RG1 de 3.
4) Movimiento de los datos del aggr0 SAS de NetApp2 a aggr0 SAS de NetApp1: esto normalmente implica una parada técnica de servicio que puede ser planificada para minimizar el impacto en el negocio.
5) El mismo procedimiento se sigue para el caso de SATA en NetApp2: se asignan los discos nuevos, se ajusta el tamaño de RG a 9 y se mueven los datos de aggr1 en NetApp1 a aggr1 de NetApp2.
6) Una vez se han movido todos los datos SATA de NetApp1 entonces el aggr1 se puede destruir mediante aggr destroy. Los discos SATA se reasignan a la controladora NetApp2 mediante los comandos disk.
7) Ampliación de aggr1 de NetApp2 con los 6 discos asignados provenientes de NetApp1. Esta controladora queda con el aggr1 formado por RG0 de 9 discos y el RG1 de otros 9. Ahora solo falta que aggr1 sea root para poder liberar los 6 discos SAS y asignarlos a NetApp1.
8) En NetApp2 creación de nuevo volumen en aggr1 con el mismo tamaño que el volumen de root (puede ser mayor pero no menor):
vol create “nuevo_root” aggr1 40g
9) Copiar el contenido del volumen de root al nuevo volumen:
vol restrict “nuevo_root”
vol copy start vol0 “nuevo_root”
NOTA: normalmente NetApp nombra el volumen de root como vol0.
10) Una vez finalizada la copia lanzar el comando vol online “nuevo_root” y posteriormente lanzar el comando:
vol options “nuevo_root”root
Con este comando traspasamos la propiedad root al nuevo volumen (el antiguo root deja de serlo de forma automática)
11) Reiniciar la controladora NetApp2 y verificar que el “nuevo_root” es root mediante el comando vol options “nuevo_root” (en la salida del comando veremos si lo es). El reinicio de la controladora se puede hacer mediante una combinación takeover/giveback para minimizar el impacto.
12) Si todo ha ido bien se puede destruir el volumen root antiguo así como el agregado aggr0 SAS de NetApp2.
13) Asignación de los 6 discos SAS a NetApp1 y ampliación del agregado aggr0 quedando los 2 RGs 9+9.
Con este procedimiento la cabina queda configurada para un rendimiento óptimo aunque se ha sacrificado espacio neto para datos. Este punto es muy importante tenerlo en cuenta y saberlo transmitir correctamente para no encontrarnos con sorpresas. Repasemos:
a) Partíamos de agregados de 6 discos con RGs en RAID-DP por lo que 2 de los 6 discos eran de paridad. En este diseño quedan 4 discos para datos (hay que descontar formateos, metas, WAFL, …).
b) Si añadíamos los discos de forma homogénea, como hemos visto no óptimo, quedaban los agregados con 9 discos (sin cambiar el tamaño de los RGs, que por defecto es de 16 discos, 7 de ellos quedan para datos). De esta forma todo el espacio nuevo es “neto”.
c) Si hacemos el movimiento siguiendo el procedimiento anterior pero en el punto de ajustar el tamaño de los RGs en vez de configurarlo a 9 lo hacemos a su máximo (en general 28 discos en SAS y 20 discos en SATA) no formamos el nuevo RG1 en cada controladora por lo que no se “pierden” discos de datos.
d) Con el cambio de configuración del tamaño de los RGs hemos forzado la creación de 2 nuevos para SAS y 2 para SATA (uno para cada controladora) por lo que hemos perdido la friolera de 4 discos SAS y 4 discos SATA. Si se necesita más espacio o hay una previsión a corto/medio plazo de más capacidad quizás sería conveniente adquirir un número mayor de discos para poder hacer los RGs más grandes. Ahora bien no es recomendable tener RGs demasiado grandes aunque esté soportado ya que el tiempo de reconstrucción en caso de fallo de discos es mucho mayor y por tanto el impacto al sistema también lo es.
Resumiendo es importante tener especial cuidado con las decisiones de diseño en cada caso y defenderlas en función de los criterios y especificaciones. Habrá entornos en los que la inversión de 6 discos será muy importante para mejora de rendimiento y sobretodo mayor espacio para datos y otros donde se priorizará el acceso a disco lo más rápido posible por las exigencias de las aplicaciones o del negocio.
This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
¿Te ha gustado este artículo? ¡Suscríbete!
Artículos Relacionados
