Presentando discos virtuales como iSCSI

Hola Mundo

Cada vez son más las organizaciones que optan por la virtualización y los escenarios de alta
disponibilidad ya son un panorama habitual en muchas empresas.
Hay veces que se necesita levantar un cluster sobre un cluster o generar algún ambiente de laboratorio y es necesario presentar unidades de disco por iSCSI.

El problema está en que muchas empresas no tienen permitido presentar unidades de iSCSI directamente desde el storage hacia máquinas virtuales por políticas de administración, seguridad y respaldo.

Desde versiones anteriores a Windows Server 2012 R2 es posible presentar unidades como iSCSI utilizando herramientas que se descargan y se instalan, o bien, era posible usar Windows Server Storage.

En Windows Server 2012 R2 es posible presentar discos duros virtuales como unidades iSCSI hacia  otras máquinas, a través de la instalación y configuración de un rol.

Para empezar, instalar el rol iSCSI Target Server



Una vez que ya está instalado el rol, ir a las máquinas donde se presentará esta unidad por iSCSI y abrir el iSCSI Initiator.

Al momento de abrir la herramienta de configuración, dará este aviso la primera vez. Se debe hacer click en Yes para que la configuración completa funcione. De otra manera, el cliente no podrá ver la unidad del servidor.

Ya que el servicio está habilitado, se mostrará la ventana principal de la herramienta:
Nada más que hacer en la herramienta, por el momento, en el cliente. Se continúa la configuración en el servidor.
Párrafos más arriba se explicita que las unidades que se presentan como iSCSI son archivos de disco duro virtual. A raíz de esto, hay que tener especial cuidado acerca del disco físico donde estarán estas unidades virtuales y de la carga de trabajo que tendrán.
Para crear una unidad, desde la consola de Server Manager navegar hasta la administración del rol e invocar al asistente:
Luego seleccionar el servidor y volumen que contendrá a esta unidad virtual que se creará:
Ingresar los datos de nombre y descripción de la nueva unidad que se está creando:
Definición de tamaño y tipo de unidad virtual a crear:
En mi laboratorio, tengo dos unidades creadas. Si no tienen unidades creadas, el listado les aparacerá vacío y solo estará la disponible la opción de crear un target nuevo:
Completar la información del nuevo target:
La misma herramienta se encarga de corregir el nombre del target en caso de que tenga caracteres no permitidos:
Este paso es muy importante, ya que se definirá quién (máquina) podrá acceder a este recurso. En primera instancia, el listado aparecerá vacío. Se deben agregar los accesos con la herramienta:
En Add se abrirá una ventana donde se seleccionará quien tendrá acceso. Se puede escoger a través del nombre de la máquina o se puede seleccionar desde el listado, si es que nuestro servidor ya conocía a la máquina cliente:
Una vez ya seleccionada la máquina, aparecerá la dirección en el listado (obviamente se puede agregar más de uno):
En este ejemplo, la autenticación no será necesaria:
Confirmación de la nueva unidad a crear:
La creación de la unidad dependerá del tamaño que se haya definido y del tipo de unidad que se escogió:
La unidad ya está creada, ahora se debe conectar a través de la herramienta iSCSI Initiator en la máquina cliente. La herramienta ya es conocida. Se debe escribir el nombre del servidor y hacer click en Quick Connect:
¡Listo! La unidad ya está disponible en la herramienta Disk Management para ser inicializada y formateada y dar un buen uso:
Si esta configuración se usará en un ambiente productivo, se recomienda realizar pruebas de rendimiento para conocer el, valga la redundancia, rendimiento de la unidad.
Espero que sea de utilidad.
¡Hasta la próxima!


Configurar Mirroring en SQL Server

Database Mirroring aparece en la versión 2005 y  es la evolución de Log Shipping. Tal como su nombre lo indica,  sirve para tener una base de datos «espejada» en otro servidor.  Puede trabajar de 3 Formas:

modos de funcionamiento | Fuente: guillesql.es
modos de funcionamiento | Fuente: guillesql.es

De foma más simple, la principal diferencia entre la configuración síncrona o asíncrona es:

  • De modo síncrono, el servidor principal espera a que las transacciones hagan commit en el servidor espejo para poder continuar.
  • De modo asíncrono, el servidor principal trabaja sin esperar al secundario.

Algunas diferencias entre LogShipping y Mirroring (Hay muchas más, pero aquí están las que más me llaman la atención):

  • Database Mirroring es capaz de configurar una conexión segura entre ambos puntos.
  • Database Mirroring provee la capacidad de hacer failover automático.

Log Shipping no hace ninguna de las dos anteriores.

Para configurar Database Mirroring se puede hacer a través del asistente o se puede hacer a través de instrucciones en t-sql. En este caso, utilizaremos el asistente para ahorrar tiempo.

Antes de partir la configuración nos debemos asegurar que la base de datos esté en modo de recuperación Full y debemos crear un respaldo de la base de datos del servidor primario y restaurarla con la opción WITH NORECOVERY en el servidor que será espejo.

Esta configuración requiere algunas configuraciones en el firewall de ambos equipos. En el servidor principal y en el espejo se debe abrir el puerto TCP 5022. Ahora, si se decide usar otro puerto, hay que estar seguro que el puerto está disponible y se puede abrir para las conexiones.

Una vez que se tiene la configuración previa lista, se hace el asistente que permitirá configurar el mirroring

Abrir asistente
Abrir asistente

En la ventana principal se debe iniciar el asistente

Ventana Principal
Ventana Principal

Se inicia el asistente

Inicio del asistente
Inicio del asistente

Se puede o no configurar un testigo. El testigo servirá para poder tener un failover automático. En este artículo no configuraré un testigo.

Configuracion del testigo
Configuracion del testigo

Configuración del equipo principal. Se puede cambiar el puerto (pero recuerden que ya habíamos abierto el puerto 5022). Además, se puede seleccionar si se quiere cifrar o no la conexión.

Configuracion del primario
Configuracion del primario

Para la configuración del secundario es necesario conectarse antes (recordar abrir el puerto 1422 en el secundario). La ventana de configuración es exactamente igual al primario.

Configuracion del Secundario
Configuracion del Secundario

El servicio debe estar configurado con una cuenta de dominio. Se debe indicar la cuenta del servicio del servidor primario y del espejo.

Cuentas de servicio
Cuentas de servicio

Para Finalizar:

Finalizar
Finalizar

Al momento de finalizar, se inicia el proceso de configuración del mirroring. Si aparece este mensaje, es porque está todo bien

Progreso de Configuracion
Progreso de Configuracion

Al terminar el asistente, aparecerá una ventana así en la cual nos preguntará si queremos iniciar Mirroring al tiro o no. En mi caso, no  configuré el testigo, por lo que no activaré el mirroring para hacer una configuración antes de partir.

Iniciar mirroring
Iniciar mirroring

Antes de comenzar el mirroring, lo configuré como asíncrono y luego inicié el mirroring

Mirroring Funcionando
Mirroring Funcionando

 

Si por algún motivo, te aparece el error 1478 cuando echas a andar el mirroring, es porque debes respaldar el transaction log del servidor primario y luego tienes que hacer un restore with norecovery en el servidor espejo. Luego de eso, ya puedes echar a andar el mirroring.

Chau!

Modelos de cluster: Activo-Pasivo y Activo-Activo

En las organizaciones donde tienen un centro de datos y aplicaciones que requieren alta disponibilidad (HA), nos podemos encontrar con dos tipos de configuraciones de HA:

Activo-Pasivo

En esta configuración existen al menos dos nodos. Uno ofrece el servicio y el otro está a la espera que el nodo 1 deje de funcionar para entregar los servicios que el nodo 1 deja de dar. Cuando el nodo uno está funcionando sin problemas (activo), el segundo nodo está atento (pasivo).

Activo-Activo

Esta configuración, al igual que la anterior, requiere al menos 2 nodos para funcionar. Se diferencia con la primera, en que cada nodo tiene distintos servicios corriendo activamente y en caso de falla, uno de los nodos asume los servicios que prestaba el nodo que falló. Por ejemplo: El servicio de DHCP y File Server están corriendo, activamente, uno en cada nodo, pero pasivamente en el otro nodo. Si el nodo 1 falla, el nodo 2 prestará ambos servicios.

Si yo tuviera que elegir, me quedo con la configuración activo-activo, porque no pierdo los recursos de un servidor que está solo a la espera de que uno falle.  Obviamente todo dependerá del escenario al cual me esté enfrentando.

 

Saludos!