Os voy a comentar las mejoras que aporta Windows Server 2012, sobre soluciones de CSV y Pull de discos, y como pueden afectar a sistemas en cluster.
Hasta ahora teníamos la capacidad de trabajar con dos tipos de discos: Discos de cabina presentados de forma tradicional, con una LUN directa que se establece o dedica para el uso en cluster. Y En Windows Server 2008 R2 se incorpora a nivel de Sistema Operativo la funcionalidad de CSV (Volúmenes de Cluster Compartidos), este tipo de discos dedicados al propósito de “Hyper-V”, lo que permite a dos o mas nodos acceder de forma simultanea en modo de lectura y escritura sobre el almacenamiento. Esto nos proporciona que sea mas sencillo montar soluciones de cluster para entornos de máquinas virtuales, ya que nos permite mover de forma independiente las distintas maquinas virtuales sobre los diferentes nodos del cluster, evitándonos dar una LUN específica a cada máquina, y por consiguiente nos evita mapear al cluster un gran numero de LUN de forma innecesaria.
La novedad que incorpora Windows Server 2012, es que con CSV vamos a poder darle un ámbito mayor, no solo lo vamos a poder utilizar para Hyper-V, si no que también lo vamos a poder utilizar como unidad de almacenamiento de datos que necesitan determinados servicios. Por ejemplo, que un SQL pueda tirar de ese almacenamiento, para que una instancia pueda acceder a una determinada información que quiero que comparta con otra instancia de SQL que está en otro nodo. No realmente vamos a poder hacer este uso del CSV para montar SQL en cluster, pero si vamos a poder establecer, que por ejemplo, un paquete de Integration Services, un Report, Script, tarea… disfrute de esta ventaja, permitiéndonos acceder a la información independientemente del nodo sobre el que se encuentre, sin necesidad de mapear un disco.
Otra de las novedades, son los Pull de disco, esta funcionalidad se incorpora a nivel de S.O. y consiste en coger varias LUN de discos distintos y agruparlos como si fuera un único disco, a partir del cual vamos a poder generar discos virtuales que vamos a poder utilizar en el propio cluster. Este disco virtual, podemos darle un mirror o funcionalidad de paridad, que a nivel de toda la arquitectura de los distintos discos que forman ese Pull, vamos a poder tener una solución de alta disponibilidad basada en software, ("aunque ya es sabido que hay cabinas que desde hace tiempo ofrecen este tipo de soluciones")… A nivel de S.O. vale cualquier tipo de disco para hacer esta funcionalidad, pero para el cluster solo podemos usar discos de tipo SAS (si alguien usa cabinas de tipo iSCASI para una solución de cluster, no va a poder aprovecharse de lo que es el Pull de discos).
Apunte y recopilación por Norman M. Pardell
