.. Una de las
características de una arquitectura de almacenamiento basada en controladoras
de NetApp es la alta disponibilidad que ofrece a través de un Cluster Activo /
Activo en sus controladoras.
En este sentido, las bandejas de discos son
conectadas a través de Loops o anillos físicos
a cada una de las controladoras con la finalidad de tener redundancia,
por tanto todas las bandejas conectadas serán visibles desde las controladoras
que conforman el Cluster, de tal manera que en caso que uno de los “caminos” se
pierda, estos discos puedan ser visualizados por la controladora por el “camino”
redundado. Esto ofrece alta disponibilidad en cuanto a conectividad de las
bandejas de discos dentro del Cluster.
Para visualizar que la configuración de
los Loops sea correcta podemos utilizar los siguientes comandos, si todo está
correctamente configurado las bandejas se deberían de ver por dos “caminos”.
Comando para discos SAS
mundo-storage1> sasadmin
shelf
Comando para discos FC
mundo-storage1> fcadmin device_map
Adicionalmente Netapp nos
ofrece la herramienta Config Advisor (antes WireGauge) que nos permite
verificar la correcta configuración de los Loops de las bandejas.
Takeover y Giveback
Como
habíamos mencionado en una arquitectura de NetApp un Cluster (Standard) está configurado en modo ACTIVO / ACTIVO, por tanto cada controladora
administra sus propios discos y por consiguiente sus propios agregados,
volúmenes y Luns para que a través de los diferentes protocolos de acceso, sean
de tipo NAS o SAN, los servidores o Host puedan acceder al almacenamiento.
Para garantizar la alta disponibilidad de los
datos, DataOntap utiliza los procesos denominados TAKEOVER y GIVEBACK.
Estos procesos se utilizan en caso que una
de las controladoras tenga algún fallo de conectividad a nivel de red, de
hardware o se haya producido un “Panic” en el DataOntap, también es utilizado
para realizar mantenimiento, cambio de parámetros o de hardware que requieran
reinicio por parte de las controladoras, desde la controladora que quedará
activa se envía una orden de TAKEOVER a través del comando “cf takeover” y ésta tomará el control de los agregados, volúmenes
y LUNs que servía la controladora caída
o reiniciada, por tanto las sesiones de los diferentes protocolos de acceso
(CIFS, NFS, ISCSI, FC) se reiniciarán en la controladora que queda activa
dentro del Cluster, cuando la controladora caída se reinicia o se recupera
entra en un estado de “WAITING GIVEBACK”, que significa que está esperando una
orden de “GIVEBACK” por parte de la controladora que asumió el control.
A través del comando “cf giveback” nuevamente vuelve a retomar el control sobre sus agregados y volúmenes, de esta forma el Cluster quedará restablecido nuevamente.
A través del comando “cf giveback” nuevamente vuelve a retomar el control sobre sus agregados y volúmenes, de esta forma el Cluster quedará restablecido nuevamente.
Para comprobar que el Cluster está
funcionando correctamente podemos comprobarlo con el siguiente comando.
mundo-storage1>
cf status
Controller
Failover enabled, mundo-storage2 is up.
Negotiated
failover enabled (network_interface).
Interconnect status: up.
Mediante
el comando options cf podemos
configurar todas las opciones del Cluster.
Dentro
de estas opciones se puede configurar que el GIVEBACK se realice automáticamente
una vez se haya restablecido la controladora caída, sin esperar a realizar un “cf giveback”, de igual manera, cuando
se produce un proceso de TAKEOVER / GIVEBACK se envía un autosupport
informando este evento, en caso de que se haya producido por una tarea de
mantenimiento o cambio de hardware es recomendable enviar un autosupport manual,
de forma que tanto NetApp como el mantenedor del almacenamiento estén informados
de este evento.
Cada Nodo mantiene el
control de sus bandejas y discos.
La NVRAM de cada nodo se
encuentra “partida”.
- En una mitad se realizan las escrituras normales
- A través de los Cluster Interconnect cada nodo conoce
el estado del nodo contrario.
- En la otra mitad se mantiene una copia exacta del
nodo contrario, que se sincroniza a través del Cluster Interconnect.
A través de los Cluster
Interconnect cada nodo conoce el estado del nodo contrario.
En caso de fallo de una de
las controladoras.
- El nodo contrario se entera de que ha fallado
- Espera por si es una falsa alarma.
- Si sigue sin responder, asume el control de los anillos
de la controladora fallida.
- Levanta una instancia virtual del filer y se pone a
exportar los volúmenes de la controladora fallida como si fuera la misma.
Bueno
amigos espero que este Post les haya sido de utilidad para entender este
proceso dentro de una cabina de almacenamiento de NetApp
No hay comentarios:
Publicar un comentario