Archivos de la categoría: Alta Disponibilidad

Filestream Storage en Alta Disponibilidad

¡Que tal! Primer post del año. A cada uno de ustedes que llega por alguna u otra circunstancia, les deseo un año lleno de felicidad y desafíos nuevos.

Hoy les compartiré un torpedo sobre las posibilidades de alta disponibilidad de Filestream Storage. Para que sepan, no se pueden configurar todas las posibilidades de HA que tiene SQL Server cuando se trabaja con filestream storage.

Las posibilidades son:

  • Mirroring:  NO
  • Log Shipping: SI
  • Failover Cluster: SI *
  • Replication; SI
  • Database Snapshot: NO
  • Avalilability Groups: SI **

*: Los filegroups correspondientes que soportan a filestream, deben estar en un volumen compartido en el cluster.

**: Completamente soportado sin fallas desde el reléase del service pack 1 (mas info: http://dangerousdba.blogspot.com.br/2012/07/filetable-with-alwayson-ags-bug.html )

Más información sobre como trabajar con Filestream y otras características de SQL Server, pueden encontrarla aquí: http://technet.microsoft.com/en-us/library/bb895334.aspx

 

Maximizando la disponibilidad de las aplicaciones de mision critica

Hola Mundo.

El día 14 de Noviembre del presente año, se realizó un evento en el Hotel W (Santiago) para mostrar los nuevos productos de Microsoft justo en un momento de muchos lanzamientos. Recordar que este año se lanzó Windows Server 2012, SQL Server 2012, System Center 2012, Windows 8, una nueva versión de Office 365, entre otras cosas.

Fue un evento al cual asistieron mas de 900 personas. Estuvo muy rico en cuando a contenido. Me invitaron como expositor y toqué el tema de Alta Disponibilidad con SQL Server 2012 aprovechando la tecnología de Always On.

Les dejo las slides del evento.

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!

Configurando Log Shipping

Log Shipping es una de las formas más rudimentarias de “alta disponibilidad” y recuperación de desastres. Creo que apareció por primera vez en la versión 2000 y que versión tras versión se ha ido mejorando.
Esta configuración consta de tres etapas:

  1. Respaldo del log de transacciones de la instancia primaria
  2. Copia del log de transacciones desde la instancia primaria hacia la segunda instancia
  3. Restauración de las transacciones en la instancia secundaria

Para configurar Log Shipping se necesita

  1. Una instancia primaria con una base de datos con Full Recovery Mode o Bulk-Logged Recovery Mode.
  2. Una instancia secundaria. Esta puede estar en la misma máquina o en otra máquina.
  3. Ambos servicios de SQL Agent deben estar funcionando y con una cuenta de dominio.
  4. Una carpeta donde la cuenta de dominio de SQL Agent pueda leer y escribir.
  5. Solo si ambas instancias están en servidores separados, el servidor primario debe tener la carpeta compartida donde dejará los logs y el servidor secundario debe tener una carpeta donde la cuenta de SQL Agent pueda escribir y leer.
  6. Una tercera instancia para que sea de testigo (Opcional)

Pasos:

1.- Servicios en marcha
Antes de partir, es necesario revisar que el servicio de SQL Agent se encuentra funcionando en ambos servidores (En este caso utilizaré dos máquinas para configurar Log Shipping). Este servicio debe estar configurado con una cuenta de dominio.

2.- Carpetas
En la máquina primaria, crearemos una carpeta compartida donde la cuenta de SQL Agent tenga permisos de lectura y escritura. La pyeden crear donde quieran. Yo la crearé en C:. También crearé una carpeta en el servidor primario donde la cuenta de SQL Agent tenga permisos de lectura y escritura.

3.- Configuración de la administración remota de SQL Server en la máquina secundaria
En una etapa de la configuración se requiere conectarse a la instancia de la instancia secundaria para poder configurar la base de datos en el destino. Nada más hay que permitir las conexiones por el puerto 1433 TCP en el firewall de la máquina secundaria.

4.- Configuración de log shipping en la base de datos primaria
Se escoge la base de datos y en el menú se escoge: “Ship Transaction Logs”

Ship Transaction Logs

Ship Transaction Logs

Se abrirá una ventana y se debe seleccionar el primer checkbox que aparece. Ese que dice: “Enable this as a primary in a log shipping configuration” y se hace click en el botón Backup Settings.

Configuracion de LogShipping

Configuracion de LogShipping

En Backup settings se configuran las rutas donde irán a parar los log de transacciones en la instancia primaria. Se debe configurar la ruta del recurso compartido y de la carpeta local. Además, se puede configurar la frecuencia de los respaldos, pero para efectos de este artículo no nos meteremos ahí.

BackUp Settings

BackUp Settings

Al momento de hacer click en Ok la ventana se cierra y vuelve a la ventana inicial. Aquí se configura los secundarios.
En la ventana, hacer click en Addy se abrirá otra ventana.

Configuracion Secundario

Configuracion Secundario

Se tienen varias opciones: Respaldar la base de datos automáticamente, copiarla a la otra instancia y restaurarla, restaurar un respaldo ya creado en la segunda instancia, o bien, dejar que todo está OK, siempre y cuando nosotros antes hayamos restaurado la base de datos desde un respaldo.
Para efectos de este artículo, dejaremos que el asistente realice toda la tarea.

Configuracion de Copia de Archvos

Configuracion de Copia de Archvos

Se configura el directorio donde se copiarán los respaldos desde el primario hacia el secundario. Yo configuré la ruta del directorio compartido del servidor secundario.
Una vez que está todo listo, le damos OK a la ventana actual y a la principal.
Aquí comenzará a configurar el servidor primario y el secundario. Una vez que esté listo, mostrará algo así:

Progreso de la configuracion

Progreso de la configuracion

En el servidor secundario ya podemos ver una base de datos que está en constante proceso de restauración.

5.- Prueba
Para ver que todo funcione, bajamos los servicios de SQL Server de la instancia primaria y en el servidor secundario ejecutamos la consulta:
RESTORE MiDB WITH RECOVERY
Y podemos hacer una consulta a los datos que tenemos.

Interesantes puntos

  • El failover no es automático
  • Los Jobs que se encargan de respaldar y restaurar tardan, por defecto, 15 minutos

Nos vemos en la próxima entrega