Configurando Mirroring SQL 2005 para Sharepoint

En este articulo detallaremos el procedimiento para configurar un Mirroring de SQL Server 2005 para proveer de alta disponibilidad a una implementación Sharepoint.

Introducción.

Mirroring es una tecnologia en SQL Server que permite entregar soluciones de Alta Disponibilidad para redundancia de Bases de Datos.  Cuando se crea un mirror (espejo) de una base de datos, se puede contar una base de datos secundaria que pueda reemplazar a la principal en el caso de una falla.  Se puede ademas proveer de un servidor Witness (testigo) que monitoree el estado del mirror y pueda ser usado para realizar un Failover automático.

Mirroring se implementa por Base de Datos (no a nivel de servidor SQL), y trabaja solo con bases de datos que utilizan el modelo "Full Recovery" (las BD de SSP en Sharepoint Server por defecto están configuradas con el modelo Simple Recovery).  Otros modelos no soportan Mirroring.

Cuando se desea crear un Mirroring, se debe tener especial consideración con el espacio para almacenamiento.  Si se espera tener una Base de Datos de 10GB, entonces se debe proveer de dichos 10GB en cada uno de los servidores que componen el Mirroring de SQL.  A diferencia de un Failover Cluster, en una configuración Mirroring no se utiliza un repositorio central para ambos servidores SQL, sino que cada uno no los nodos debe contar con espacio de almacenamiento suficiente para mantener cada una de las Bases de Datos.  A pesar del costo adicional que esto supone, Mirroring tiene la ventaja de que el repositorio donde se almacenan las Bases de Datos no se transforma en un punto único de falla.

Adicionalmente, se debe tener en cuenta que cuando se realiza mirroring de SQL, el envío de transacciones entre los servidores impactará el desempeño del servidor principal, por lo que además se debe proveer de un ancho de banda adecuado entre los servidores que componen el Mirroring, para evitar cuellos de botella en la red que podrían repercutir aun más en el desempeño del servidor.

Cuando se usan mirroring de Base de Datos se pueden realizar Failovers automáticos, manuales o forzados, sin embargo, estos Failover no son reconocido automáticamente por Sharepoint.  No obstante lo anterior, se puede configurar un script para el proceso de Failover, que se ejecute cuando se produzca algún evento de falla en el Mirror.

Mirroring en SQL cuenta con tres niveles de seguridad para las transacciones, de los cuales depende la técnica de Failover que se pueda utilizar.  Los niveles de seguridad y las técnicas de Failover se pueden ver en la siguiente imagen:

Sharepoint soporta cualquiera de estos métodos de Failover, sin embargo los Failover Manual y Forzado pueden causar perdida de datos y debiera ser considerada como el ultimo recurso.  La recomendación es utilizar un Failover Automático, a pesar de lo cual aun es necesario realizar pasos manuales (o un script) para reconectar la granja Sharepoint.

En el procedimiento descrito en este articulo se detallarán los pasos requeridos para configurar un Mirroring con Failover Automático (con servidor Witness), así como los scripts necesarios para que Sharepoint se reconecte automáticamente luego de producirse un Failover.

Información adicional sobre Mirroring, lo pueden ver en el sitio Microsoft Technet.

Alcances y requisitos previos

En este articulo no se detallará la instalación de SQL Server 2005.  Se asume que contamos con 2 instancias SQL para conformar el Mirroring, así como una instancia adicional que se utilizará como Witness (Testigo).  En nuestro caso se utilizarán maquinas virtuales sobre Hyper-V para cada uno de los servidores requeridos.

Cuando se configura una base de datos Mirror, se deben configurar los permisos para los logins requeridos en ambos servidores SQL que formarán el Mirror.  Se deben configurar al menos:

• La cuenta del Application Pool de la Administracion Central de Sharepoint, la cual debiera tener el rol de DBCreator y SecurityAdmin en ambos servidores SQL.
• Todas las cuentas de Application Pool y la cuenta del servicio de busqueda y de default content access debieran tener un login SQL Server, aunque no se requiere que ningún rol de SQL les sean asignadas.
• Miembros del grupo de administradores de la granja Sharepoint debieran tener también un login SQL y debieran cumplir los mismos roles que la cuenta del Application Pool de la Administración Central.

Todos los servidores SQL (principal, mirror y witness) deben ejecutar la misma edición de SQL Server.  En nuestro caso utilizamos SQL Server 2005 SP1.  Mirroring solo está disponible en las ediciones Standard, Developer y Enterprise de SQL Server.  No obstante lo anterior, el servidor Witness puede correr cualquier versión de SQL Server 2005, incluyendo SQL Server Express.

Configuración Mirror


1.  Nos conectamos al motor de base de datos SQL en el servidor principal y en el mirror (Utilizamos SQL Server Management Studio)

2.  En el servidor principal realizamos un respaldo de las bases de datos que se configurarán en Mirroring. 

3. Transferimos el archivo de respaldo al servidor Mirror y restauramos el respaldo (en el mirror) usando la  opción "NORECOVERY" 

4.  En el servidor principal hacemos click derecho sobre la base de datos, apuntamos al menú Tasks y seleccionamos "Mirror".  En las ventana que se nos abre hacemos click en "Configure Security"

5. Se iniciará el Wizard de configuración del Mirror, donde hacemos click en Next.

6. A continuación seleccionamos si incluiremos o no un Witness.  En nuestro caso seleccionaremos "Yes" y hacemos click en Next. 

7.  Se seleccionan los servidores que se configurarán.  En nuestro caso nos aseguramos que los tres roles (principal, mirror y witness) se encuentren seleccionados.  Hacemos click en Next.

8.  En la sección "Principal Server Instance" se selecciona el puerto del Listener, y si se quiere usar encriptación.  Hacemos click en Next

9.  En la sección "Mirror Server Instance" se selecciona cual servidor actuará como Mirror.  Aquí también seleccionamos el puerto del Listener y si se desea usar encriptación.  Hacemos click en Next.

10.  En la sección "Witness Server Instance" se selecciona cual servidor actuará como Witness.  Aquí también seleccionamos el puerto del Listener y si se desea usar encriptación.  Hacemos click en Next.

11.  Si las instancias utilizan distintas cuentas como cuentas de servicio, se deben ingresar las cuentas en la sección "Service Accounts".  Si todas las instancias utilizan las mismas cuentas, se deja en blanco esta sección.  Hacemos click en next. 

12.  A continuación vemos el resumen de la configuración seleccionada.  Hacemos click en Finish para terminar el asistente.

13.  Nos aparecerá una ventana en la que debemos indicar si iniciaremos el Mirroring inmediatamente, o lo haremos más adelante.  En nuestro caso iniciamos el Mirroring inmediatamente. 

14.  En algunos casos, cuando se producen muchas transacciones en una Base de Datos, es posible que el Mirror no se inicie ya que el respaldo y restauración realizados en los puntos 2 y 3 no incluyó todas las transacciones.  Para superar este problema, se debe realizar un nuevo respaldo de la base de datos en el servidor principal, pero esta vez solo respaldaremos los Transaction Logs.  De la misma forma, al momento de restaurarlos en el servidor Mirror, se debe seleccionar la opción "NORECOVERY".  Luego intentamos iniciar nuevamente el Mirror, el cual debiera iniciarse sin problemas.

15.  Repetimos los pasos del 2 al 15 para todas las bases de datos que se quieran configurar en Mirror.

Configuración de Alias de Conexión SQL.

Una vez que tenemos el Mirroring configurado en SQL Server, debemos realizar la configuración requerida para que Sharepoint pueda reconectarse automáticamente cuando se produce un Failover en el Mirroring.

Para poder trabajar en Sharepoint con un mirror SQL, utilizaremos alias de conexión SQL Server para conectar Sharepoint a las bases de datos configuradas en Mirroring.  Un alias de conexión es un nombre alternativo para configurar una conexión a una instancia SQL.

1.  En cada uno de los servidores que conformarán la granja Sharepoint, ingresamos a la aplicación SQL Server Client Network Utility ejecutando el comando "cliconfg.exe".  Una vez aquí nos vamos a la sección de Alias y seleccionamos la opción "Add" para crear un nuevo alias.

2.  A continuación indicamos el nombre que le asignaremos al alias del servidor, en nuestro caso "MOSSMIRROR".  Seleccionamos el tipo de conexión (TCP/IP), el nombre del servidor y la instancia del servidor SQL principal (MONTBARD\MOSS) y el puerto de conexión (1433).

3.  Damos OK para guardar los cambios, quedando de la siguiente forma:

Nota:  Cuando se instale Sharepoint, al momento de ejecutar el Wizard de configuración se debe configurar la conexión a la base de datos apuntando al alias recién creado, y no directamente a uno de los servidores SQL.

En este punto, de producirse un Failover en el Mirroring SQL, solo bastaria con modificar el alias recién creado para que apunte al servidor que cumpla el rol de servidor Principal en el Mirroring.  En los puntos siguientes detallaremos el procedimiento para automatizar este cambio.

Configuración Failover automatico para Sharepoint.

Ya con el Mirroring y los Alias configurados, debemos automatizar el Failover para que Sharepoint pueda reconectarse a SQL sin necesidad de intervención manual.

Para poder lograr este objetivo, utilizaremos alertas y Jobs en SQL Server para monitorear el Mirroring y realizar los cambios necesarios una vez que se produzca un Failover.  Realizaremos tres configuraciones principales en ambos servidores que conforman el Mirroring:

• Alertas: Detectar el Failover de una unica Base de Datos, o de toda la instancia SQL del servidor Principal al Mirror.
• Job: Ejecutar el Failover de todas las bases de datos restantes (en caso de producirse un Failover solo en una base de datos) al servidor Mirror.
• Job: Actualización de los alias de conexión SQL.

1. En primer lugar configuraremos la alerta y el Job para aquellas situaciones en que se produzca un Failover de todas las bases de datos, producto de una perdida de conectividad o apagado (o reinicio) del servidor Principal del Mirroring.  Las alertas y Jobs deben configurarse en ambos nodos del Mirroring.

1.1.  Nos dirigimos a la sección SQL Server Agent -> Alerts en el Management Studio de SQL.

1.2.  Aqui damos un click derecho y seleccionamos "New Alert".

1.3.  Se nos abrirá una ventana donde configuramos la alerta.  Aquí indicamos en primer lugar el nombre que le asignaremos a la alerta, en nuestro caso "MonitoreoAuto".

1.4.  Luego seleccionamos el tipo de alerta a configurar, en este caso "WMI Event Alert".

1.5.  A continuación ingresamos la Query con la cual realizaremos el monitoreo.  Hay una serie de cambios de estado que pueden ser monitoreados, a continuación una lista de ellos:

• 0 = Null Notification
• 1 = Synchronized Principal with Witness
• 2 = Synchronized Principal without Witness
• 3 = Synchronized Mirror with Witness
• 4 = Synchronized Mirror without Witness
• 5 = Connection with Principal Lost
• 6 = Connection with Mirror Lost
• 7 = Manual Failover
• 8 = Automatic Failover
• 9 = Mirroring Suspended
• 10 = No Quorum
• 11 = Synchronizing Mirror
• 12 = Principal Running Exposed
• 13 = Synchronizing Principal

En nuestro caso utilizaremos el cambio de estado 5, el cual alertará cuando el servidor Principal pierda conectividad o se apague (o reinicie).  Nuestra consulta quedará de la siguiente forma:

"SELECT * FROM Database_MIRRORING_STATE_CHANGE WHERE State=5"

1.6.  En la sección Response, creamos un nuevo Job e ingresamos el nombre de éste.  En nuestro caso "FailOverAuto"

1.7.  Ingresamos luego a la sección "Steps" del Job para especificar las acciones que se realizarán en el Job, una vez se gatille la alerta.

1.8.  Seleccionamos "New" para crear un nuevo Step o paso.  El primer paso a realizar es la configuración de los servidores que componen la granja Sharepoint para que apunten al servidor que actúa como Principal una vez que se produce un FailOver.  Este cambio de configuración se realiza modificando una llave de registro en los servidores Sharepoint.

1.9.  Indicamos el nombre del Step, en nuestro caso RegistroAignant (Aignant es el nombre de uno de los servidores Sharepoint).  Indicamos luego el tipo de paso a realizar, en este caso seleccionamos "Operating System (CmdExec)".  

1.10. A continuación seleccionamos el comando a ejecutar para modificar la llave de registro que configura el Alias SQL: 

reg add \\SHAREPOINT\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo /v MOSSMIRROR /t REG_SZ /d "DBMSSOCN,SERVIDORSQL\MOSS,1433" /f

"SHAREPOINT" debe ser reemplazado por el nombre de uno de los servidores que componen la granja Sharepoint.

"SERVIDORSQL\MOSS" debe ser reemplazado por el nombre del servidor y la instancia del servidor donde se está creando la alerta.  La lógica es que el servidor donde se gatilla la alerta, actuará como servidor Principal luego del Failover, por lo que Sharepoint debe apuntar a este servidor.

1.11.   Los pasos del 1.8 al 1.10 deben repetirse por cada uno de los servidores Sharepoint que compongan la granja.  En nuestro caso se crean 3 Steps, debido a que nuestra granja cuenta con 3 servidores.

1.12.  Damos click en OK para guardar los cambios en el Job creado y luego OK para guardar los cambios en la alerta creada.

1.13.  Repetimos los pasos del 1.1 al 1.12 para crear la Alerta y el Job en el servidor que actúa como Mirror.

1.14.  Podemos probar la alerta y el Job realizando un reinicio o apagado del servidor que actua como Principal en el Mirroring SQL.  Cuando esto se produce, el servidor Witness se encarga de desencadenar el Failover de las bases de datos, para que el servidor Mirror pase a actuar como servidor Principal.  Cuando esto se produce, se gatilla la Alerta configurada, ejecutando el Job creado, el cual apunta los servidores Sharepoint al servidor que ahora actúa como Principal.

2. A continuación crearemos la Alerta y el Job para aquellas situaciones en que se produzca el failover de solo una de las bases de datos del Mirroring SQL.  Cuando esto sucede, se debe realizar el Failover del resto de las bases de datos, ya que Sharepoint no soporta tener las bases de datos separadas en 2 instancias SQL distintas.

2.1.  Repetimos los pasos del 1.1 al 1.5 para crear la alerta y la nombramos "MonitoreoUnitario".  No obstante, la Query que gatillará la alerta queda de la siguiente forma:

SELECT * FROM Database_MIRRORING_STATE_CHANGE WHERE State=3 AND (databasename='SharePoint_AdminContent' OR 

databasename='SharePoint_Config' OR 

databasename='SSO' OR 

databasename='SSP_DB' OR 

databasename='SSP_Search_DB' OR  

databasename='WSS_Content_MySites' OR 

databasename='WSS_Content_SSP' OR 

databasename='WSS_Search_AIGNANT' )

Esta alerta será gatillada cuando una de las bases de datos en el servidor Principal, cambie su estado a Mirror, debido a que se haya producido un Failover de una base de datos en particular.  Adicionalmente, esta consulta debe especificar el nombre de cada una de las bases de datos que se encuentran configuradas en Mirroring, y sobre las cuales se generará el Monitoreo.

2.2.  En la sección Response, creamos un nuevo Job e ingresamos el nombre de éste.  En nuestro caso "FailOverUnitario"

2.3.  Ingresamos luego a la sección "Steps" del Job para especificar las acciones que se realizarán en el Job, una vez se gatille la alerta.

2.4.  Seleccionamos "New" para crear un nuevo Step o paso.  El primer paso a realizar es la configuración de los servidores que componen la granja Sharepoint para que apunten al servidor que actúa como Principal una vez que se produce un FailOver.  Este cambio de configuración se realiza modificando una llave de registro en los servidores Sharepoint.

2.5.  Indicamos el nombre del Step, en nuestro caso RegistroAignant (Aignant es el nombre de uno de los servidores Sharepoint).  Indicamos luego el tipo de paso a realizar, en este caso seleccionamos "Operating System (CmdExec)".  

2.6. A continuación seleccionamos el comando a ejecutar para modificar la llave de registro que configura el Alias SQL: 

reg add \\SHAREPOINT\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo /v MOSSMIRROR /t REG_SZ /d "DBMSSOCN,SERVIDORSQL2\MOSS,1433" /f

"SHAREPOINT" debe ser reemplazado por el nombre de uno de los servidores que componen la granja Sharepoint.

"SERVIDORSQL2\MOSS" debe ser reemplazado por el nombre del servidor y la instancia del servidor que actúa como Principal para la base de datos que sufrió el Failover.  La lógica es que el servidor donde se gatilla la alerta, pasará a actuar como servidor Mirror luego del Failover, por lo que Sharepoint no debe apuntar a este servidor, sino que al otro nodo del Mirroring SQL.

2.7.  Los pasos del 2.4 al 2.6 deben repetirse por cada uno de los servidores Sharepoint que compongan la granja.  En nuestro caso se crean 3 Steps, debido a que nuestra granja cuenta con 3 servidores.

2.8.  A continuación se debe crear un Step adicional, en el cual se realizará el Failover de las bases de datos restantes, para que de esta forma todas las bases de datos se encuentren en el mismo servidor Principal.

2.9.  Se ingresa el nombre del Step, en nuestro caso "Failover Manual".  Se selecciona además el tipo de Step a configurar, en este caso "Transact-SQL Script (T-SQL).

2.10.  Ingresamos los comandos T-SQL para realizar el FailOver de cada una de las bases de datos que están configuradas en el Mirroring.  Se debe ingresar una linea por cada base de datos a las que se le ejecutará un FailOver.

ALTER DATABASE SharePoint_Config SET PARTNER FAILOVER 

ALTER DATABASE SharePoint_AdminContent SET PARTNER FAILOVER

ALTER DATABASE SSO SET PARTNER FAILOVER 

ALTER DATABASE SSP_DB SET PARTNER FAILOVER 

ALTER DATABASE SSP_Search_DB SET PARTNER FAILOVER

ALTER DATABASE WSS_Content_MySites SET PARTNER FAILOVER 

ALTER DATABASE WSS_Content_SSP SET PARTNER FAILOVER

ALTER DATABASE WSS_Search_AIGNANT SET PARTNER FAILOVER  

2.11.  Al finalizar la creación de los pasos creados, el Job queda de la siguiente forma:

2.12.  Repetimos los pasos del 2.1 al 2.11 para crear la Alerta y el Job en el servidor que actúa como Mirror.

2.13.  Podemos probar la alerta y el Job realizando un FailOver manual en alguna de las bases de datos en el servidor que actua como Principal en el Mirroring SQL.  Cuando esto se produce, se gatilla la Alerta configurada, ejecutando el Job creado, el cual se encarga de desencadenar el Failover de las restantes bases de datos, para que el servidor Mirror pase a actuar como servidor Principal, y apunta los servidores Sharepoint al servidor que ahora actúa como Principal.

Conclusión

Al completar los pasos anteriores, podemos tener una plataforma SQL en alta disponibilidad, y con Failover automático para Sharepoint.

En artículos anteriores hemos descrito el proceso para proteger una plataforma Sharepoint montada sobre un Mirroring SQL, utilizando DPM 2007.  Pueden revisar ese articulo haciendo click aquí. 

Posted in: Mirroring,Sharepoint,Sharepoint 2007,SQL Server