eManu

Hola a todos,

He tenido que montar un piloto para probar que tal se comporta los servidores SQL en modo espejo y añadiendo un tercer servidor que realice las tereas de testigo, para realizar la alta disponibilidad y de esta manera tener el mínimo tiempo posible el acceso a la BBDD caído.

El piloto se realiza con 2 servidores de producción, y un servidor testigo. En todos los servidores se ha instalado la misma versión de sistema operativo y de MS-SQL Server: Windows Server 2008 R2 y SQL-Server 2008 R2. En el equipo de testigo, se podría haber instalado un SQL-Express 2008, ya que en ningún momento tendrá la instancia de BBDD, y simplemente recoge información de quien tiene el rol activo.

Instalación de MS-SQL

Aunque la instalación de SQL SERVER tiene bastantes opciones en el momento de instalar, deberemos de tener en cuenta varias indicaciones del asistente de instalación para después esté todo operativo correctamente.

Deberemos de instalar .NET FrameWork 3.5.1 e iniciar el setup de instalación, pasando, como se observa en la imágen, todas las operaciones de control con «Passed», y en el caso de tener Warning, intentar solucionarlo.

En caso de tener Failed, no podríamos continuar hasta solucionar el requerimiento de instalación.

Instalamos una instancia estandard de SQL SERVER.

En mi caso, es necesario la instalación de Analysis y Reporting Services. Tendremos que seleccionar las herramientas de administración, para tener acceso a «SQL-SEVER Management Studio».  No olvidar seleccionar SQL Server Replication, ya que será la tecnología que vamos a utilizar para realizar el modo espejo.

He generado una tabla Excel (GruposM) con información de ACLs en un recurso compartido, para realizar las pruebas.

Configuración de modo de espejo con testigo

Lo primero que tenemos que realizar es un backup de la BBDD que queremos tener en alta disponibilidad, para esto, necesitamos comprobar que el modo de copia de seguridad tiene que estar en modo FULL.

Desde el servidor en donde está ubicada la BBDD, y desde SQL SERVER Management Studio, realizaremos la exportación de la BBD y del fichero de log:

backup database GruposM to Disk=»C:\BackupBBDD\GruposM.bak»;
backup Log GruposM to Disk=»C:\BackupBBDD\LogGruposM.bak»;

Copiamos el directorio en el servidor SQL que servirá de espejo (TSQL02), y restauraremos la BBDD y el Log.

restore DataBase GruposM from Disk=»C:\BackupBBDD\GruposM.bak» with NORECOVERY;restore Log GruposM from Disk=»C:\BackupBBDD\LogGruposM.bak» with NORECOVERY;

Veremos que la BBDD se queda en modo Restoring…, nos iremos al TSQL01 e inicimos el proceso de Espejo.

Pulsaremos botón derecho encima de la BBDD que requiera estar en Espejo, y pulsamos en Tasks > Mirror…

Pulsamos en Configuring Security e iniciamos el Wizard de configuración de seguridad.

Como en nuestra solución vamos a incluir un testigo, vamos a indicar que SI lo vamos a utilizar
Indicamos que la configuración se va a guardar tanto en los servidores principales, como en los de Espejo y marcamos la opción de Testigo.

Tenemos que abrir en el Firewall de Windows el puerto 5022 en cada uno de los servidores de alta disponibilidad.

Al pulsar conectar, nos indicará que tenemos que realizar logon con un usuario, cambiaremos e indicaremos el usuario SA con su respectiva contraseña.

Realizamos las mismas acciones en cada uno de los servidores espejos que vamos a utilizar, indicando el nombre del servidor y pulsando en Connect… para realizar el Logon en el SQL-SERVER del servidor.

Para el testigo, realizamos las mismas acciones que con un equipo de espejo. Indicar el nombre del servidor y pulsar Conectar para realizar el logon.

Pulsamos en Finish del wizard que inicie la configuración de Espejo.

Esperamos a que finalic la configuración.

Mientras, podremos ver como la BBDD que hemos seleccionado para que esté en alta disponibilidad, va cambiando el estado en cada uno de los servidores espejo, el proceso es de validación de los ficheros la BBDD.

El estado final será que en Servidor Principal, veremos que la BBDD está en modo (Principal, Synchronized), y los servidores en estado Espejo, estarán en modo (Mirror, Synchronized /Restoring…)

Provando la Alta disponibilidad

Lo primero que deberemos hacer es bajarnos el Cliente Nativo para SQL-Server, en mi caso para SQL-Server 2008, para poder configurar los servidores de espejo que tiene nuestro entorno y no perder conectividad con los datos. En caso de utilizar el driver ODBC de SQL Server del sistema, sólo podremos indicar 1 servidor SQL para realizar la conexión, y en caso de Failover, deberemos configurar el ODBC para que apunte al otro servidor SQL (o crear 2 origenes ODBC).

Indicaremos información descriptiva del origen de datos que vamos a crear, y cual es el servidor principal del entorno.

Indicaremos que nos vamos a conectar con el usuario SA o un usuario con permisos en la BBDD.

Indicamos cual es la BBDD que vamos a tener como predeterminada, y la cual, va estar en alta disponibilidad, e informamos de igual manera del servidor de espejo que tenemos en la plataforma.

Deberemos desmarcar la opción de Adjuntar nombre del archivo de la base de datos.

Pulsamos a finalizar para acabar la configuración del enlace ODBC.

Como vemos, en la imagen, tenemos marcada en color rojo, el origen de datos que vamos a utilizar como alta disponibilidad, mientras que en el registro superior, tendríamos el generado con el driver SQL-Server del sistema, que no nos daría la posibilidad de realizar la acciones de Alta disponibilidad.

Provando la alta disponibilidad

Al abrir unos Access 2007 para probar el acceso a datos de alta disponibilidad y realizar el Failover, deberemos de comprobar, que los datos son correctos (previamente han sido configurados en el ODBC del sistema).

Realizamos una consulta a la BBDD, para comprobar que podemos explotar los datos:

SELECT *
FROM dbo_tabla
Where dbo_tabla.INHERIT=»NO»;

Y a continuación probaremos el Filover y sin cerrar el access , volveremos a lanzar la consulta.

Nos indicará que se ha perdido la conexión a la BBDD. Cerraremos Access, volveremos a abrirlo (para que el driver ODBC sepa que tiene que cambiar de servidor origen) y podremos continuar con la tarea, ya que los datos estaran en linea.

En otras aplicaciones como puede ser SharePoint, es capaz de comprobar si el servidor ha cambiado de estado y el rol de Servidor Principal ha cambiado, sin tener que reiniciar el enlace de datos.