Introducción

Este es el segundo artículo de una serie de 3 acerca de la configuración de SQL Server 2005 Mirroring con MOSS. En el primero (SQL Server 2005 Mirroring con MOSS – Parte 1: Preparacion de entorno y configuracion de VPCs) muestro el entorno de trabajo, las bases de datos que finalmente obtengo en la instalación y la población de MOSS con contenido generado automáticamente. En este artículo presentaré cómo configurar el back-end de MOSS en un escenario de mirroring de alta disponibilidad (con failover automático), lo que requiere un servidor testigo (witness server) y por supuesto un servidor espejo (mirror server), que será el que finalmente asuma el rol de servidor primario de base de datos para MOSS cuando simulemos el desastre en el siguiente artículo (SQL Server 2005 Mirroring con MOSS – Parte 3: Simulación de Desastre y Reconfiguración de MOSS).

Acerca del Mirroring

El mirroring en SQL Server 2005 es una técnica de software que permite mantener copias espejo por cada base de datos en un servidor, en otro servidor que corra bajo la misma versión de SQL Server que el servidor primario. Esta técnica tiene 3 modos de operación: Alta disponibilidad (High availability mode), Alta protección (High protection mode) y Alto rendimiento (High performance mode).

El modo de alta disponibilidad sincroniza automáticamente los logs de transacciones hacia el servidor espejo, y permite un failover automático (failover es la adopción del rol principal por parte del servidor espejo, suplantando al servidor principal). Este modo requiere un servidor testigo que verifique el estado tanto del servidor principal como del servidor espejo para poder determinar si es necesario realizar un failover.

El modo de alta protección también sincroniza los logs de transacciones entre el servidor principal y el testigo, aunque el failover es manual y por tanto un servidor testigo no es requerido, aunque se puede habilitar.

El modo de alto rendimiento no sincroniza los logs de transacciones entre los servidores y asume que todo va bien entre ellos, por tanto se consigue mayor rendimiento, aunque el riesgo de pérdida de datos es mayor y el failover en este caso es también manual (se aumenta el rendimiento ya que se reduce el impacto en el ancho de banda producto de la sincronización de logs entre servidores, además del uso de CPU que ello conlleva).

NOTA: ten en cuenta que el beneficio real del SQL Mirroring es que el proceso sea automático, por tanto es recomendado utilizar el modo de alta disponibilidad para evitar pérdidas de datos y minimizar el tiempo de caída de los servicios que dependan de un back-end SQL Server.

En cuanto a seguridad, el mirroring emplea sesiones TCP para sincronizar los logs de transacciones y para monitorear el estado de los servidores (por parte del servidor testigo), lo cual emplea autenticación a nivel de sesión, empleando dos posibles métodos: Autenticación Windows (NTLM o Kerberos) y Certificados. Siguiendo los lineamientos del documento en el cual baso esta prueba, emplearemos encriptación autenticación por Certificados y encriptación con el algoritmo AES para las comunicaciones entre servidores –el mirroring soporta también el algoritmo RC4 para la encriptación de las comunicaciones, pero ciertamente AES es más fuerte que RC4, y es recomendado utilizar AES en todos los casos posibles.

Respecto a los límites del mirroring, se recomienda que por cada sesión de mirroring no se configuren mas de 10 bases de datos, ya que cada sesión crea por lo menos dos threads por cada base de datos, de modo que mientras se añadan mas bases de datos la performance del sistema se degrada hasta llegar a ser inutilizable.

Configuración de mirroring con certificados

La topología que configuraremos es la siguiente:

El gráfico muestra dos bases de datos dentro del servidor principal con un espejo en el servidor mirror, pero en nuestro caso debemos configurar 8 bases de datos en SQLPRINCIPAL con un espejo cada una en SQLMIRROR. Cabe resaltar que un servidor espejo debe tener siempre una correspondencia uno-a-uno con el servidor principal. Es decir, si en un servidor principal tengo 4 bases de  datos, entonces el espejo para ese servidor debe tener también 4 bases de datos. Una topología distinta a ésta no es soportada, aunque recomiendo revisar la teoría de mirroring para saber cuáles son las topologías soportadas. En el caso de MOSS, en donde podemos tener varias bases de datos en distintos servidores esta aclaración es de suma importancia, y sobre todo que la base de datos de configuración y la base de datos de contenido del sitio de administración central DEBEN ESTAR SIEMPRE en el mismo servidor físico, tanto principal como espejo.

Para aclarar dudas, muestro un ejemplo de topología no soportada:

Antes de empezar instalé el Service Pack 1 de SQL Server (ya está disponible también el Service Pack 2 de SQL Server) en todos los servidores SQL, ya que mis instalaciones no contaban con ningún SP y el mirroring está deshabilitado por defecto, además de no ser soportado por Microsoft (una implementación de mirroring en un entorno de producción estará soportada por Microsoft única y explusivamente si es que los servidores SQL emplean Service Pack 1 o Service Pack 2). OK. Vamos a utilizar scripts en T-SQL para configurar cada una de las 8 bases de datos que tenemos en SQLPRINCIPAL para que tengan una copia en SQLMIRROR, crear los certificados que permitan la autenticación, crear los respectivos endpoints TCP en los 3 servidores para la comunicación entre ellos, y la habilitación de SQLWITNESS. Para esto es necesario encender SQLPRINCIPAL (con sólo 348 MB de RAM), luego MOSS (con tan solo 512MB de RAM) ya que me loguearé como MIDOMINIO\Administrador en los servidores SQL; luego enciendo  SQLMIRROR con 348 MB de RAM tembién. Una vez que tenemos las VPCs en línea, me interesa saber con qué bases de datos cuento. Para ello voy a Management Studio donde podré emplear Catalog Views para obtener la información. En este caso utilizaré el catalog view sys.databases el cual me mostrará todas las bases de datos que tengo en SQLPRINCIPAL.

Por qué utilizar un catalog view? Mmmm… de acuerdo a la información oficial “Recomendamos el uso de Catalog Views porque son la interfaz general con la metadata del catálogo y proveen el modo mas eficiente para visualizar, obtener, transformar y presentar información específica de este tipo. Toda la metadata del catálogo disponible para el usuario es expuesta a través de Catalog Views”. Bien… mi propósito es mucho mas simple… yo prefiero utilizar esto para poder copiar y pegar los nombres de las bases de datos y utilizarlos con los scripts de T-SQL --han visto el nombre de la base de datos de contenido de la administración central? Si no es copy/paste entonces COMO? J

Entonces empecemos con la configuración del servidor principal y del espejo (http://msdn2.microsoft.com/es-es/library/ms186384.aspx)

Paso 1: En SQLPRINCIPAL creamos el certificado cifrado en la instancia de servidor con el fin de utilizarlo en las conexiones salientes para la creación del mirror de la base de datos. También creamos el endpoint TCP

Ahora tenemos que copiar el certificado desde C:\backup\SQLPRINCIPAL_cert.cer (en SQLPRINCIPAL) hacia SQLMIRROR en el directorio C:\backup\. No trates de insertar una ruta de red en la sentencia T-SQL porque obtendrás un error, así que hazlo manualmente.

Paso 2: en SQLMIRROR creamos el Master Key, el certificado para la autenticación, el endpoint para mirroring y hacemos backup del certificado, que luego copiaremos hacia SQLPRINCIPAL

Ahora tenemos que copiar el certificado desde C:\backup\SQLMIRROR_cert.cer (en SQLMIRROR) hacia SQLPRINCIPAL en el directorio C:\backup\. No trates de insertar una ruta de red en la sentencia T-SQL porque obtendrás un error, así que hazlo manualmente.

Paso 3: Debemos configurar las conexiones entrantes en cada servidor (http://msdn2.microsoft.com/es-es/library/ms187671.aspx). En SQLMIRROR creamos un login para SQLPRINCIPAL y lo asociamos a su certificado

Paso 4: en SQLPRINCIPAL creamos un login para SQLMIRROR y lo asociamos a su certificado

Ahora tenemos que crear una copia de las bases de datos en nuestro servidor espejo, antes de poder iniciar la sesión de mirroring.

Paso 5: En SQLPRINCIPAL configuramos las bases de datos para que usen Full Recovery Model, luego hacemos backup de todas las bases de datos. En este ejemplo lo haremos con la base de datos de configuración (SharePoint_Config) pero  debemos repetirlo con todas las demás (para eso ya las tienes identificadas gracias a sys.databases)

TIP: le pongo comillas dobles (“) al nombre de la base de datos porque cuando trates de hacerle backup a la base de datos de contenido de la administración si no especificas el nombre con comillas SQL te dará un error --esto se debe a los guiones (-) que lleva el nombre de la BD.

Paso 6: copiamos estos archivos de backup que acabamos de obtener hacia el servidor SQLMIRROR.

Paso 7: en SQLMIRROR restaura todas las bases de datos que copiaste de SQLPRINCIPAL. El ejemplo muestra cómo hacerlo con la base de datos de configuración (SharePoint_Config), pero hay que repetirlo con todas las bases de datos

TIP: si te preguntas cómo harás para copiar el nombre de las bases de datos sin equivocarte, es bien fácil, sólo mira dentro del directorio C:\backup J

Aprieta F5 en el Object Explorer y nota el estado de las bases de datos restauradas (esto es por la opción WITH NORECOVERY a la hora de la restauración)

Paso 8: en SQLMIRROR iniciamos el database mirroring por cada base de datos. En este ejemplo lo haremos con la base de datos de búsqueda (WSS_Search_MOSS) pero esto se debe hacer con todas las bases de datos

Paso 9: en SQLPRINCIPAL iniciamos el database mirroring por cada base de datos. En este ejemplo lo haremos con la base de datos de configuración (SharePoint_Config) pero esto se debe hacer con todas las bases de datos

Configuración de Servidor Testigo

Una vez realizado lo anterior, nuestras bases de datos ya se encuentran sincronizadas, aunque en caso de desastre tendríamos que realizar un cambio de roles manual. Para evitar ello, vamos a configurar el servidor testigo SQLWITNESS, el cual enciendo con 256 MB de RAM asignadas.

Paso 1: En SQLWITNESS creamos el Master Key, creamos el certificado cifrado en la instancia por defecto del servidor, el endpoint para mirroring y hacemos backup del certificado, que luego copiaremos hacia SQLPRINCIPAL y hacia SQLMIRROR

Paso 2: Copiamos el certificado de SQLWITNESS hacia SQLPRINCIPAL y SQLMIRROR, y también copiamos los certificados de SQLPRINCIPAL y SQLMIRROR hacia SQLWITNESS (finalmente todos tendrán los certificados de todos)

Paso 3: En SQLWITNESS creamos logins para SQLPRINCIPAL y SQLMIRROR, asociándolos con sus certificados

Paso 4: en SQLPRINCIPAL creamos un login para SQLWITNESS, lo asociamos a su certificado y le damos permiso de conexión al endpoint

Paso 5: En SQLMIRROR creamos un login para SQLWITNESS, lo asociamos a su certificado y le damos permiso de conexión al endpoint

Paso 6: En SQLPRICIPAL, indicamos que SQLWITNESS es el testigo. En este ejemplo lo haremos con la base de datos de configuración (SharePoint_Config) pero esto debe ser repetido por cada una de las bases de datos de MOSS

Podemos comprobar la conexión entre los servidores mediante netstat –a. En este caso lo haré desde el servidor SQLPRINCIPAL, pero lo ideal es hacerlo desde todos los 4 servidores SQL para estar seguros de que la comunicación está dada y que la sesión de mirroring está activa

Conclusión

-.M.-