Currently Being Moderated

El post de hoy se puede resumir en algo muy sencillo: Lo mismo que ha pasado con los servidores y las VMs lo estamos haciendo con las cabinas de almacenamiento y las SVMs.

 

Una SVM (Storage Virtual Machine) no es más que un servidor de almacenamiento virtualizado que corre en nuestro Clustered ONTAP, para prestar servicios de almacenamiento unificado sobre una serie de recursos hardware. Y para los que no quieran seguir leyendo, pego el dibujo de alto nivel de esta arquitectura:

 

SVM_logico.jpg

 

La primera alternativa es tener esa SVM sobre los recursos hardware que vendemos en NetApp, nuestros sistemas FAS, con el mismo hardware que veníamos utilizando.

 

Hay una posibilidad intermedia, mediante otra capa de virtualización (esto se complica), que permite utilizar disco externo (de otro fabricante) conectado a una controladora FAS … es lo que llamamos V-Series, y salvo por el disco en uso, se comporta como un FAS más:

 

SVM_vseries.jpg

 

La tercera posibilidad es tener esta SVM sobre un hardware de propósito general, es decir, un servidor, y su correspondiente hypervisor; más detalles en el siguiente post.

 

Y la última, pues el Cloud, que modelos económicos a parte, viene a ser una derivada de alguna de las anteriores.

 

La posibilidad de definir un servicio de almacenamiento, independiente del hardware que lo soporta, que tiene movilidad online de un equipo a otro, que está aislado del resto de servicios, que tiene sus recursos acotados, etc.,  parece una gran idea, pensad en lo que han supuesto los servidores virtualizados en el mundo de sistemas.

 

¿A quién no se le cayó la lagrimilla la primera vez que vio un vMotion en funcionamiento?

 

Pues eso mismo, bueno, lo llamamos Data Motion, lo podemos hacer con una SVM, moviendo los puertos de servicio de una controladora a otra, y los datos de unos discos a otros, sin tener que redefinir ni reconfigurar la SVM, y sin parar el servicio.

 

Para gestionar todo esto utilizamos nuestra herramienta estándar, System Manager, y si vemos la gestión de uno de nuestros clusters de laboratorio tenemos esta pantalla:

 

SVM1.jpg

 

Podéis ver a la izquierda que se separa la gestión del cluster, nodos y VServers (o SVMs) en 3 pestañas diferentes. Los dos primeros son la configuración de la infraestructura hardware, y con las SVMs gestionamos los servicios de almacenamiento. En la derecha podéis ver los detalles de las 5 SVMs que tenemos definidas y los protocolos habilitados en cada una.

 

Dentro de una de ellas, la que da servicio al VMware de nuestro laboratorio, podéis ver los diferentes elementos a configurar:

 

SVM_detalles.jpg

 

Los más importantes, pues el almacenamiento (los volúmenes) y los interfaces de red por los que se da servicio a los diferentes protocolos. A la derecha tenéis algunos de los volúmenes de esta SVM, como podéis ver sobre diferentes agregados o pools de discos (que están en 3 nodos diferentes y con discos de diferente tipo, como indican los nombres).

 

En la parte de interfaces de red tenemos las diferentes direcciones IP y WWN (World Wide Name) que permiten a los clientes conectarse con este servidor virtualizado:

 

SVM_network.jpg

 

Evidentemente hay muchos más detalles, pero con esto tenemos ya lo básico para prestar un servicio de almacenamiento: los puertos de servicio o front-end, y los datos (LUNs o sistemas de ficheros) que servir.

 

En otro post hablaremos de cómo se mueven ambos.

 

Saludos

Comments

Filter Blog

By date:
By tag: