Implementacin de SQL Server en modo Espejo con TestigoMircoles, 24 de julio de 2013eManuHola a todos,He tenido que montar un piloto para probar que tal se comporta los servidores SQL en modo espejo y aadiendo un tercer servidor que realice las tereas de testigo, para realizar la alta disponibilidad y de esta manera tener el mnimo tiempo posible el acceso a la BBDD cado.

El piloto se realiza con 2 servidores de produccin, y un servidor testigo. En todos los servidores se ha instalado la misma versin de sistema operativo y de MS-SQL Server: Windows Server 2008 R2 y SQL-Server 2008 R2. En el equipo de testigo, se podra haber instalado un SQL-Express 2008, ya que en ningn momento tendr la instancia de BBDD, y simplemente recoge informacin de quien tiene el rol activo.Instalacin de MS-SQLAunque la instalacin de SQL SERVER tiene bastantes opciones en el momento de instalar, deberemos de tener en cuenta varias indicaciones del asistente de instalacin para despus est todo operativo correctamente.Deberemos de instalar .NET FrameWork 3.5.1 e iniciar el setup de instalacin, pasando, como se observa en la imgen, todas las operaciones de control con Passed, y en el caso de tener Warning, intentar solucionarlo.

En caso de tener Failed, no podramos continuar hasta solucionar el requerimiento de instalacin.Instalamos una instancia estandard de SQL SERVER.

En mi caso, es necesario la instalacin de Analysis y Reporting Services. Tendremos que seleccionar las herramientas de administracin, para tener acceso a SQL-SEVER Management Studio. No olvidar seleccionar SQL Server Replication, ya que ser la tecnologa que vamos a utilizar para realizar el modo espejo.

He generado una tabla Excel (GruposM) con informacin deACLs en un recurso compartido, para realizar las pruebas.Configuracin de modo de espejo con testigoLo 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 exportacin 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 modoRestoring, nos iremos al TSQL01 e inicimos el proceso de Espejo.Pulsaremos botn derecho encima de la BBDD que requiera estar en Espejo, y pulsamos enTasks > Mirror

Pulsamos enConfiguring Securitye iniciamos el Wizard de configuracin de seguridad.

Como en nuestra solucin vamos a incluir un testigo, vamos a indicar que SI lo vamos a utilizarIndicamos que la configuracin se va a guardar tanto en los servidores principales, como en los de Espejo y marcamos la opcin 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 contrasea.

Realizamos las mismas acciones en cada uno de los servidores espejos que vamos a utilizar, indicando el nombre del servidor y pulsando enConnectpara 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 enFinishdel wizard que inicie la configuracin de Espejo.

Esperamos a que finalic la configuracin.

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 validacin 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, estarn en modo (Mirror, Synchronized /Restoring)

Provando la Alta disponibilidadLo 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, slo podremos indicar 1 servidor SQL para realizar la conexin, y en caso de Failover, deberemos configurar el ODBC para que apunte al otro servidor SQL (o crear 2 origenes ODBC).

Indicaremos informacin 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 opcin deAdjuntar nombre del archivo de la base de datos.

Pulsamos a finalizar para acabar la configuracin 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, tendramos el generado con el driver SQL-Server del sistema, que no nos dara la posibilidad de realizar la acciones de Alta disponibilidad.Provando la alta disponibilidadAl 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_tablaWhere dbo_tabla.INHERIT=NO;Y a continuacin probaremos el Filover y sin cerrar el access , volveremos a lanzar la consulta.

Nos indicar que se ha perdido la conexin 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.

Tips SQL Server Espejado de Base de Datos Mirroring15 de junio de 2012 en 1:19 | Publicado enSQL Server|Deja un comentarioEtiquetas:SQL Server

Database Mirroring es una tecnologa de Alta Disponibilidad basada en un modo defuncionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos.Database Mirroring slo est disponible en las ediciones SQL Server 2005 Enterprise y Developer (actualizado 24/07/2009: en la Standard tambin), por lo tanto, no podremos utilizar Database Mirroring en SQL Server 2005 Workgroup, ni Express. Sin embargo, la Instancia que realice el papel deServidor Testigo (Witness), puede ser de cualquier edicin de SQL Server 2005, de tal modo, que sera posible ejecutar el Servidor Testigo sobre un servidor SQL Server 2005 Express en una mquina separada de los Servidores Principal y Espejo (ms adelante se detallan los distintos roles de una topologa de Database Mirroring)Los roles disponibles son los siguientes: Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a travs de la cual, se ofrece el servicio a los usuarios. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal. Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database), y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo. Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solucin de Database Mirroring. Sin embargo, si deseamos que nuestra solucin de Database Mirroring ofrezca recuperacin automtica ante fallos (automatic failover), entonces s ser necesario implementar un Servidor Testigo (Witness Server), pues ste es quin monitorizar los Servidores Principal y Espejo partcipes de una Sesin de Espejo (Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo en caso de una cada de servicio o prdida del primero (es decir, en caso de cada del Servidor Principal, se asignar el papel de Principal al Servidor Espejo, mantenindose as el servicio). El trabajo realizado por el Servidor Testigo (Witness) no es muy intenso, por lo cual, no requiere de grandes recursos, y adems, un mismo servidor puede actuar como Servidor Testigo (Witness) para mltiples sesiones de espejo, sin prdida de rendimiento.Database Mirroring ofrece tres modos de funcionamiento: Modo de Alta Disponibilidad (sncrono y con testigo). Las transacciones son aplicadas de forma sncrona a las base de datos principal y espejo. Requiere de un Servidor Testigo (Witness) ubicado sobre una tercera mquina (que no sea ni el Servidor Principal ni el Servidor Espejo), gracias al cual es posible la recuperacin automtica ante fallos (automatic failover) o conmutacin automtica de roles. En caso de fallo del Servidor Principal durante el envo de transacciones, el Servidor Espejo tiene que terminar las transacciones encoladas antes de poder levantarse como Servidor Principal. Por supuesto tambin es posible la recuperacin manual ante fallos (manual failover) o conmutacin manual de roles. En caso de una cada o prdida del Servidor Espejo, la base de datos principal se mantendr activa. Modo de Alta Proteccin (sncrono y sin testigo). Las transacciones son aplicadas de forma sncrona a las base de datos principal y espejo. Sin embargo, no utiliza un Servidor Testigo (Witness). En este modo de funcionamiento, no es posible la existencia de prdida de datos, pero la recuperacin ante fallos se realiza de forma manual (manual failover). En caso de una cada o prdida del Servidor Espejo, la base de datos principal dejar de estar activa, al haber perdido el Quorum. Modo de Alto Rendimiento (asncrono y sin testigo). Las transacciones son aplicadas de forma asncrona a la base de datos espejo, ofreciendo mejor rendimiento que los anteriores modos de funcionamiento, pero pagando como precio la existencia de posibles prdidas de transacciones (y en consecuencia, potenciales prdidas de datos). Evidentemente, la recuperacin ante fallos se realiza de forma manual (manual failover), hablando de conmutacin forzada (es decir, cambio de roles sin comprobacin de datos escritos en el servidor espejo). En caso de una cada o prdida del Servidor Espejo, el Servidor Principal no se ver afectado.Aqui un poco la introduccion sobre este tema que estare ahondando en los proximos post