DPM 2007: Restauración de una Web Application Sharepoint

En artículos anteriores hemos detallado el proceso de instalación de DPM, con la respectiva configuración para proteger Sharepoint, y el proceso de restauración de una granja Sharepoint completa.

En este articulo detallaremos el proceso de restauración de una Web Application completa en Sharepoint 2007 utilizando DPM 2007 con SP1.

La restauración de items en Sharepoint solo es soportada utilizando el Sharepoint Content Migration Object Model.  Este modelo de objetos permite un mayor control de los escenarios de migración de datos.  Usando este modelo se pueden migrar desde un Sitio Web hasta un ítem en una lista, o un documento en una librería.  Se puede ademas incluir información sobre seguridad, versionamiento, roles de usuario y otra metadata relacionada al objeto a ser migrado.

Este tipo de restauración fue validada luego del trabajo conjunto entre el equipo de DPM y el equipo de Sharepoint, para asegurar que este escenario de recuperación sea completamente soportado por Sharepoint.  Es técnicamente posible otros tipos de restauración granular, como extraer un objeto de una base de datos de contenido e insertarlo en otra, sin embargo esto puede provocar corrupción de datos y por lo tanto no es un método de restauración soportado.

Este escenario de recuperación, así como cualquier tipo de restauración granular en Sharepoint 2007 utilizando DPM 2007 requiere la existencia de una granja de recuperación (Recovery Farm), la cual es usada temporalmente para hospedar una versión restaurada de la base de datos de contenido que contiene el objeto Sharepoint que se desea recuperar.

Una Recovery Farm no requiere el mismo Hardware de la granja principal que se quiere restaurar y puede utilizarse una maquina virtual para tales efectos.  Algunas consideraciones al momento de preparar la Recover Farm son:

• Versiones de software y updates identicos a la granja protegida, aunque no se requiere que sean las mismas ediciones (ej. SQL Enterprise / Standard).
• Features y Templates habilitadas en la recovery Farm, idénticas a la granja protegida.  Si se utilizan Language Packs, estos también deben ser instalados en la Recovery Farm.  Si a la granja protegida se le agregan Features o Templates adicionales, estas también deben ser instaladas en la Recovery Farm.
• La Recovery Farm no debe ser instalada sobre el servidor que hospeda Active Directory, o sobre servidores que hospeden otras granjas Sharepoint o DPM.
• Se debe utilizar la misma version de SQL Server o una mas reciente que la utilizada al momento del respaldo.
• La Recovery Farm debe ser una instalacion Stand Alone (unico servidor), que incluya tanto Sharepoint como SQL Server.
• La Recovery Farm debe tener instalado el agente DPM y se debe tener habilitado el VSS Writer.
• Se debe crear una Web Application con el nombre "DPMRecoveryWebApplication".  No se deben agregar Bases de Datos de contenido adicionales a esta Web Application.
• la Recovery Farm debe contener espacio suficiente para almacenar temporalmente la base de datos de contenido completa del sitio a restaurar.

Mayores antecedentes para la creación de la Recovery Farm, lo pueden ver en el sitio Microsoft Technet.

Además de lo anterior, para poder realizar una restauración granular en Sharepoint, la granja donde se realizará la restauración debe contar con una Site Collection con la misma ruta que el sitio protegido.  Si la Site Collection no existe, se puede crear una site collection vacía en la granja antes de realizar la restauración.

El siguiente diagrama explica el proceso de restauración granular en DPM 2007.

• Como se puede apreciar, el primer paso de la restauración es la restauración de la base de datos de contenido que contiene el objeto a ser recuperado, en la Recovery Farm utilizando el agente DPM.
• Esta base de datos es adjuntada a la Web Application creada previamente (DPMRecoveryWebApplication) y el objeto es exportado a una carpeta temporal usando la API de Migración de Contenido.  Esta API es la misma utilizada por el comando stsadm import/export en Sharepoint.
• Un archivo CMP es enviado a una carpeta temporal en el servidor Web Front-End en la granja protegida, utilizando el agente DPM.
• El API de Migración de Contenido es usado en el WFE para importar el paquete en la jerarquia de objetos Sharepoint y lo asocia a la base de datos SQL correspondiente.

La necesidad de contar con una Recovery Farm y todo este procedimiento de restauración es una limitación de la API de Migración de Contenido de Sharepoint y no de DPM como tal.  Esta limitación es superada en Sharepoint 2010, donde en conjunto con DPM 2010 se podrán realizar restauraciones granulares sin la necesidad de contar con una Recovery Farm, haciendo que el proceso de restauración sea mucho más sencillo y ágil.

A continuación detallaremos el procedimiento de restauración de un sitio completo, ya sea en una ubicación alterna dentro de la misma granja (diferente URL), o en la misma ubicación (sobrescribiendo el sitio).

Restauración en una ubicación alterna.

Antes de comenzar con la restauración se deben tener las siguientes consideraciones:

• La ubicación alterna (Web Application, Site Collection) donde se realizará la restauración debe existir antes de iniciar el proceso de restauración.
• El sitio tiene que haber sido creado utilizando el mismo Template del sitio a restaurar, incluyendo el idioma respectivo.

1.  Creamos la Web Application requerida en la granja Sharepoint protegida por DPM.

2.  Creamos un Site Collection en blanco dentro de dicha Web Application, donde se restaurará el sitio.  En nuestro caso lo realizamos por linea de comando:

stsadm.exe -o createsite -url http://URL:Puerto -ownerlogin Dominio\Usuario -owneremail usuario@dominio.com -title SitioRecuperado -lcid 3082

En nuestro caso ademas utilizamos el parámetro LCID, el cual especifica el idioma en que se creará el sitio.  Nosotros utilizamos idioma español.

3. Ingresamos a la consola DPM, en la sección "Recovery" nos dirigimos al Tab "Browse.  Aqui expandimos el servidor protegido e ingresamos a All Protected Sharepoint Data.

4.  Hacemos doble click sobre la base de datos que contiene el sitio a restaurar.  A continuación seleccionamos el Recovery Point que utilizaremos para la restauración, utilizando el calendario desplegado en la sección superior derecha. Hacemos click derecho sobre el sitio a restaurar y seleccionamos "Recover".

5.  Se nos abrirá el asistente de Restauración, aquí se nos muestra el detalle de lo que restauraremos.  Hacemos click en siguiente para continuar.

6.  A continuación seleccionamos el tipo de restauración, en nuestro caso seleccionamos "Recover to an alternate Site.  Hacemos click en Next.

7.  A continuación debemos ingresar los datos requeridos acerca de la Recovery Farm:

• Nombre Servidor de la Recovery Farm
• Nombre de la Instancia SQL
• Ubicación de los archivos de Base de Datos.

Al seleccionar la ubicación para los archivos de Base de Datos, se debe seleccionar una carpeta que sea accesible desde el servidor SQL de la Recovery Farm, o el proceso generará errores.

     

En este punto debemos seleccionar ademas la URL alterna donde se restaurará el sitio en cuestion.  Esta URL debe coincidir con la especificada al momento de crear la Web Application del paso 1.  Hacemos click en Next.

8.  En el siguiente punto debemos seleccionar la Staging Location, en el servidor WFE donde se restaurará el sitio, requerida para almacenar el archivo CMP a utilizar para la restauración.  Hacemos click en Next.

9.  A continuación se seleccionan las opciones de recuperación.  En primer lugar seleccionamos si se aplicarán las configuraciones de seguridad existentes en la ubicación de destino donde se realizará la restauración, o se utilizarán las configuraciones de seguridad existentes al momento de la creación del Recovery Point.  Esta configuración se refiere a la seguridad aplicada a los datos a ser restaurados.

En este punto ademas seleccionamos si utilizaremos la opción de recuperación mediante una SAN, utilizando Hardware Snapshots.  Se debe contar con una SAN que permita esta funcionalidad, y que se encuentre conectada tanto al servidor DPM, como a la granja protegida.

Si tenemos las alertas y notificaciones configuradas en DPM, en este punto además podemos configurar el envío de una notificación cuando finalice el proceso de recuperación.  Hacemos click en Next.

10.  Se nos muestra el resumen de la restauración a realizar, damos click en Next para comenzar la recuperación.

11.  Finalmente, el asistente nos mostrará un mensaje indicando que la actividad se completó satisfactoriamente.

En estos momentos, podemos ingresar al sitio recuperado con la URL especificada en el paso 1 de este procedimiento.

Restauración en la misma ubicación.

A continuación, detallaremos el procedimiento para restaurar un sitio en su ubicación original, sobrescribiendo el contenido existente.

1.  Repetimos los pasos del 3 al 5 del procedimiento descrito anteriormente (Restauración en una ubicación alterna)

2.  Seleccionamos el tipo de restauración.  En este caso seleccionamos "Restore to original site"

3.  A continuación debemos ingresar los datos requeridos acerca de la Recovery Farm:

• Nombre Servidor de la Recovery Farm
• Nombre de la Instancia SQL
• Ubicación de los archivos de Base de Datos.

Al seleccionar la ubicación para los archivos de Base de Datos, se debe seleccionar una carpeta que sea accesible desde el servidor SQL de la Recovery Farm, o el proceso generará errores.

      

En este punto no es necesario indicar ubicación alterna, ya que estaremos sobrescribiendo el sitio original.

4.  Repetimos los pasos del 8 al 11 del procedimiento anterior (Restauración en una ubicación alterna), con lo cual nuestro sitio se encontrará restaurado completamente en su ubicación original.


Consideraciones adicionales

Para restaurar un sitio Sharepoint 2007 utilizando DPM 2007, el sitio debe existir con anterioridad a la ejecución de la restauración, sino está fallará.

Ahora, ¿Que sucede si yo borro por accidente una Web Application y quiero restaurarla?.  En esta situación, si se intenta realizar una restauración sobrescribiendo el sitio original, el asistente fallará debido a que no encuentra la Web Application a sobrescribir.

Para poder realizar esta restauración, se debe seguir el procedimiento que detalla la restauración en una ubicación alterna, sin embargo, en el punto 7 de dicho procedimiento, al momento de ingresar la URL del sitio, se ingresa la URL del sitio que fue borrado.

En siguientes artículos detallaremos el procedimiento de restauración granular de ítems como subsitios, listas, librerias, etc.

Read More

DPM 2007: Restauración de una Farm Sharepoint

En un articulo anterior se describieron los pasos para la instalación de DPM 2007 con SP1 y la configuración requerida para proteger una granja Sharepoint Server 2007.

En este articulo describiremos el procedimiento a seguir ante el necesidad de restaurar completamente la Granja Sharepoint producto de algún tipo de contingencia.  Paradójicamente este es el escenario mas sencillo para realizar una restauración en Sharepoint, al no requerir la existencia de una granja de recuperación (Farm Recovery).

La recuperación de una granja Sharepoint completa es posible usando DPM.  Esto incluye las bases de datos de configuración y Central Administration.  Es importante considerar que la restauración de una granja Sharepoint requiere que todas las bases de datos (de configuración y contenido) en la granja, sean recuperadas juntas en el mismo punto en el tiempo.  Es posible seleccionar las bases de datos para ser restauradas individualmente, pero esto no es soportado por Microsoft.

Lo anterior se debe a que DPM usa VSS, lo que permite tener un Snaptshot (foto) de todas las bases de datos en una granja Sharepoint.  Por esta razón la restauración de la base de datos de configuración y de la Central Administration sea soportada solo cuando se recupera una granja completa.

Al restaurar una granja Sharepoint, el servicio de búsqueda puede no estar disponible por algunos minutos (u horas dependiendo de que tan grande es la infraestructura), mientras que el contenido es re-indexado luego del Restore.   Este proceso se puede evitar si junto con proteger el contenido Sharepoint, se protegieron también las búsquedas.

Hay dos escenarios de restauración de una granja Sharepoint con DPM, el primero es la restauración mientras la granja aun se encuentra disponible, y el segundo es la restauración cuando la granja no se encuentra disponible por alguna falla mayor de Software o Hardware.  En este articulo detallaremos el procedimiento a seguir en ambos escenarios.

Restaurando una granja Sharepoint que esta disponible.

En este escenario hay pocos requerimientos que deben ser considerados para una restauración exitosa:

• Los servidores Web Front-End deben estar configurados como se encontraban en el momento de que el punto de recuperación fue creado en DPM.  Diferencias de configuración pueden presentar fallas.
• Las instancias SQL deben estar configuradas con los mismos nombres usados al momento de la creación del punto de restauración.

Una vez cumplidos estos requerimientos, se deben seguir los siguientes pasos para restaurar la granja.

1.  En la consola de administración de DPM, nos vamos al Tab "Recovery". En la sección izquierda de la consola, expandimos el servidor Sharepoint el cual contiene la granja que queremos restaurar.

2.  Bajo el nombre del servidor, hacemos click sobre "All Protected Sharepoint Data". Esto mostrará los datos de la granja en el panel inferior derecho.

3.  En el panel superior derecho, seleccionamos el día y la hora del Recovery Point que utilizaremos para la restauración.

4. En la lista de Items recuperables, seleccionamos la granja que será restaurada.  Hacemos click derecho sobre este item y seleccionamos la opción "Recover"

5. Se nos abrirá el asistente de restauración, damos click en Next.

6. Si la restauración es por un evento de falla mayor en la granja Sharepoint y se requiere su recuperación, se elige la opción "Recover all Sharepoint content and components.  Esta opción restaura las bases de datos de contenido y configuración en su ubicación original.

Si en cambio se requiere restaurar la granja Sharepoint para otros requerimientos, o simplemente para para restaurar la granja en una ubicación alternativa (otros servidores), se selecciona la opción "Copy all Sharepoint content and component files to a network folder".

Presionamos Next para continuar.

7.  Si se cuenta con una SAN que tenga la funcionalidad de Snapshot habilitada, y esta se encuentra conectada al servidor DPM y al servidor protegido, entonces se puede utilizar esta funcionalidad seleccionando la opción "Enable SAN based recovery using hardware snapshot".  Esto permite una restauración mucho más rapida.  Presionamos OK para continuar.

8.  El asistente nos mostrará la ventana resumen con la lista de los items a restaurar, el tamaño total del respaldo, el medio de recuperación (en este caso desde disco), y si se configuró alguna notificación para la finalización del proceso.

9.  Hacemos click en "Recover" para iniciar la restauración de la granja.

10.  Una vez que el proceso culmina exitosamente, el asistente nos mostrará la siguiente ventana:

Después que la recuperación esta completa y la granja se encuentra restaurada, los usuarios serán capaces de navegar en su contenido inmediatamente.  Si no se restaura la búsqueda, así como los indices de la búsqueda, estos tendrán que ser reconstruidos con el correspondiente tiempo que esto implica.  Esto ultimo además puede provocar demoras menores en los tiempos de respuesta al usuario producto de la actualización de los indices de búsqueda.  En otro articulo detallaremos el proceso de respaldo y restauración de la búsqueda.


Restaurando una granja Sharepoint que no esta disponible.

En el evento de un incidente mayor, que produzca una falla catastrofica en la granja sharepoint ya sea de Hardware o Software (o ambas) la granja Sharepoint puede necesitar ser restaurada a una nueva instalación.    Al instalar los nuevos servidores para restaurar Sharepoint, se deben tener las siguientes consideraciones:

1. El nombre de los servidores Web Front-End y de las instancias SQL deben tener el mismo nombre que los servidores que hospedaban la granja Sharepoint cuando se realizó el Recovery Point.
2. Instalar el agente DPM en los servidores WFE, en el servidor de Index (si aplica), y en los servidores SQL que contienen las bases de datos de contenido y configuración de Sharepoint.  El procedimiento es detallado en el siguiente link.
3. Se habilita el servicio WSS Writer en el servidor Web Front-End.  Procedimiento en el siguiente link (punto 20).
4. Seguimos los pasos del 1 al 10 del procedimiento de restauración detallado para granjas Sharepoint que se encuentran disponibles.
5. Una vez que la restauración se completa, se debe ejecutar el Wizard de configuración de Sharepoint y se desconectan todos los servidores Web Front-End de la granja
6. Si el servidor principal de la granja Sharepoint no es el servidor Web Front-End que DPM usa para proteger la granja, este servidor también deberá ser desconectado de la granja
7. Se abre la consola de administración de IIS (Internet Information Services) y se borran todos los sitios web y Application Pools de la granja que esta siendo restaurada.
8. Se ejecuta el Wizard de configuración de Sharepoint en el servidor principal y se selecciona la opción de conectar a una granja Sharepoint existente.
9. Especificamos el nombre del servidor SQL y de la base de datos.  Como mencionamos antes, estos deben ser los mismos nombres usados cuando se creó el Recovery Point.
10. Los pasos 7 al 9 debe ser repetidos en cada servidor que forma parte de la granja Sharepoint.
11. En el servidor que hospedará el sitio de Central Administration, al momento de ejecutar el Wizard de Configuración de Sharepoint, en la sección "Completing the Sharepoint Productos and Technologies Configuration Wizard", se hace click en "Advanced Settings" y se hace click en Next.
    A continuación seleccionamos la opción "Use this machine to host the web site" y completamos el Wizard.

Al igual que en el procedimiento anterior, después que la recuperación esta completa y la granja se encuentra restaurada, los usuarios serán capaces de navegar en su contenido inmediatamente.  Si no se restaura la búsqueda, así como los indices de la búsqueda, estos tendrán que ser reconstruidos con el correspondiente tiempo que esto implica.  Esto ultimo además puede provocar demoras menores en los tiempos de respuesta al usuario producto de la actualización de los indices de búsqueda.  En otro articulo detallaremos el proceso de respaldo y restauración de la búsqueda.

En siguientes artículos detallaremos el procedimiento de restauración de un sitio en particular, y de ítems dentro de un sitio Sharepoint (listas, subsitios, etc.)

El procedimiento oficial de Microsoft se puede obtener en el siguiente Link.

Read More

Lanzamiento Data Protection Manager 2010 Release Candidate

El dia de ayer (8 de febrero) Microsoft liberó la versión Release Candidate (RC) de la tercera versión de System Center Data Protection Manager (DPM), previamente llamado "DPM v3" o "Zinger"

DPM nos permite proveer de protección continua de datos en aplicaciones y servidores Windows, ya sea en disco o en unidades de cinta.  Algunas de las tecnologías cubiertas por DPM son:

• Windows Server 2003 o superior
• SQL Server 2000 o superior
• Exchange Server 2003 o superior
• Sharepoint Server 2003 o superior
• Protección para ambientes de virtualización Microsoft
• Virtual Server 2005 R2
• Hyper-V 2008 y 2008 R2
• Entre otros.

Este Release Candidate puede ser descargado desde el siguiente link:

http://connect.microsoft.com/site840/Downloads/DownloadDetails.aspx?DownloadID=26452

Espero les sea de utilidad.  Prepararé un laboratorio para probar las funcionalidades de esta nueva versión de DPM, y les contaré mis impresiones.

Read More

Ejecutar Timer Jobs inmediatamente con STSADM

Muchas veces nos encontramos con que algún cambio en Sharepoint queda pendiente hasta la ejecución de un Job.  Este Job puede ser forzado con el siguiente comando:

stsadm -o execadmsvcjobs

Esto será de mucha utilidad cuando no queremos o no podemos esperar hasta la hora en que esté programado el Job.

Read More

Sharepoint Link Checker

Excelente herramienta obtenida desde Codeplex, Sharepoint Link Checker nos permite realizar un scan de nuestros Site Collections y reportar los Links rotos que sean encontrados en el contenido publicado.

Una vez descargada la Solution, se debe subir y deployar en la granja Sharepoint.  Junto con la Solution se descarga un archivo .BAT con los comandos para realizar esto.

Luego de deployada la Solution, nos dirigimos a la Central Administration -> Site Actions -> Site Settings

Una vez aqui ingresamos a la sección "Site Collection Features" y activamos la feature correspondiente.

Una vez activada, en la página "Application Management" de la Central Administration, en la sección "SharePoint Site Management", aparecerá una nueva opción "Scan for Broken links"

Accedemos a esta opción y seleccionamos la Site Collection que a la que se le aplicará el Scan y presionamos "Immediate Scan".  En esta pagina además podremos ver los reportes anteriores que hayan sido completados.

Dependiendo del tamaño de la Site Collection, el Scan puede durar bastante.  Si se desea ver si un Scan esta en progreso, nos debemos dirigir a la opción "Timer Job Status" en la pagina de "Operations" de la Central Administration y buscar el timer job "Link Checker"

Read More

Herramientas para pruebas de carga en WSS 3.0 y MOSS 2007

Extraido del Blog del CIIN, una excelente recopilación de herramientas para hacer pruebas de carga en Sharepoint 2007 y WSS 3.0.

Uno de los aspectos a tener en cuenta en cualquier despliegue de SharePoint 2007 (especialmente en el caso de MOSS) es el comportamiento que va a tener en términos de rendimiento. Para evaluarlo, es necesario estresar el despliegue y realizar los correspondientes tests de carga. ¿Qué posibilidades tenemos para hacer estos tests de carga y estas pruebas de rendimiento? Pues por fortuna, tenemos varias opciones disponibles. Os resumo a continuación algunos recursos relevantes en torno a la realización de estos tests de carga:

• Otras herramientas:
  • SharePoint 2007 Test Data Population Tool: http://www.codeplex.com/sptdatapop. Esta herramienta no está oficialmente soportada por Microsoft.
  • MOSS Load Test: http://mossloadtest.codeplex.com/
  • SharePoint Perfomance Testing: http://www.sharepointconfig.com/2009/12/introducing-the-sharepoint-performance-test-codeplex-project/
  • Herramienta gratuita de test de carga, WCat:http://www.iis.net/downloads/default.aspx?tabid=34&i=1466&g=6
• Ceración de pruebas de carga para SharePoint 2007 con VS 2008:
  • http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=679
  • http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=683
• Otros recursos:
  • Post del equipo de SharePoint al respecto: http://blogs.msdn.com/sharepoint/archive/2007/01/05/performance-updates-and-tool.aspx
  • Recopilatorios de enlaces sobre tests de carga en SharePoint 2007:
    • http://jopx.blogspot.com/2009/05/web-testing-and-load-testing-sharepoint.html
    • http://blogs.msdn.com/sanjaynarang/archive/2009/04/18/sharepoint-performance-stress-load-testing.aspx
  • WebCast sobre este tema: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-CA&EventID=1032394588&CountryCode=CA
    
    

Read More

Diagrama de migraciones a Sharepoint 2010

Del blog de Hector Insua, aqui tenemos el diagrama completo de las Migraciones desde SharePoint 2003 y 2007 a SharePoint 2010 extraido del articulo de Technet que se encuentra actualizado, como siempre recuerden que mientras estamos en BETA, toda esta documentacion puede sufrir cambios.

http://technet.microsoft.com/en-us/library/ee947141(office.14).aspx


Adicionalmente podemos obtener información adicional del proceso de migración desde Sharepoint Portal Server 2003 a Sharepoint Server 2010 en el siguiente enlace.

Read More

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í. 

Read More