Una de las características más conocidas de la versión de SQL Server 2012 Enterprise Edition es AlwaysOn. Se ha diseñado para satisfacer la necesidad cada vez mayor de «Alta Disponibilidad» (HA). AlwaysOn no utiliza tecnologías totalmente nuevas, sino que hace un uso más eficaz de las tecnologías existentes que han sido probadas. Su objetivo es proporcionar un control más granular para lograr la Alta Disponibilidad. Actualmente, dependiendo de su entorno, podría estar utilizando ya uno o varios de los siguientes componentes de HA que existían en versiones anteriores de SQL Server:
- Single Site Windows Server Failover Clustering
- Multi-Site Windows Server Failover Clustering
- San level Block Replication
- Transaction Log Shipping
- Database Mirroring
- Transactional Replication
- Peer-to-Peer Replication
- Utilizar las API de WSFC para realizar las conmutaciones por error. No es necesario el almacenamiento compartido
- Utilizar la duplicación de bases de datos para la transferencia de datos a través de TCP/IP
- proporcionar una combinación de duplicación síncrona y asíncrona
- proporcionar una agrupación lógica de bases de datos similares a través de grupos de disponibilidad
- Crear hasta cuatro réplicas secundarias legibles
- Permitir la realización de copias de seguridad en una réplica secundaria
- Realizar sentencias DBCC contra una réplica secundaria
- Emplear la compresión incorporadain Compression &Encriptación
- Configure su AAG en la réplica primaria (Su AAG contiene el grupo de BDs que desea agrupar para hacer failover a sus réplicas secundarias)
- Deberá configurar entre una y cuatro réplicas secundarias, con cualquier combinación de Mirroring Síncrono (Máximo de dos) y Asíncrono (Su réplica primaria está disponible para la conectividad de lectura y escritura, mientras que sus réplicas secundarias pueden ser configuradas para el acceso de sólo lectura, intento de lectura o sin acceso)
- Copias de seguridad de la base de datos
- Copia de seguridad completa con Copy_Only
- Copias de seguridad del registro de transacciones
- DBCC CheckDB
- Informes
- Instancias de la base de datos
- Una única base de datos secundaria
- La base de datos reflejada es accesible a través de una instantánea de la base de datos sólo hasta que se produce la conmutación por error
- Falta de soporte para MSDTC (transacciones distribuidas)
- Las bases de datos relacionadas no son capaces de agruparse
- Soporta Modos de Disponibilidad Alternativos
- Soporta Múltiples formas de Failover de AAG
- Soporta la Configuración de las Réplicas Secundarias en Modo de Lectura
- .Sólo lectura
- Soporta la configuración de las réplicas secundarias para realizar copias de seguridad
- Soporta la reparación automática de páginas
- Soporta el cifrado y la compresión
- Soporta la gestión a través de
- TSQL
- PowerShell
- Asistentes de la interfaz gráfica de usuario
- Servicios de gestión.
- Dashboard
- Management Studio
- Rápida conmutación por error de aplicaciones mediante el uso de AlwaysOn Availability Group Listeners (AAGLs)
- Una réplica primaria que le permite emprender capacidades de lectura y escritura contra aquellas bases de datos que han sido configuradas en el AAG
- Hasta cuatro réplicas secundarias que le permiten tener capacidades de sólo lectura contra aquellas bases de datos que han sido configuradas en el AAG. También permite configurar la capacidad de realizar copias de seguridad en estas secundarias.
- Automático – Soportado por el modo Synchronous-Commit – Sin pérdida de datos
- Manual – Soportado por el modo Synchronous-Commit – Sin pérdida de datos
- Forzado – Soportado por Asynchronous-Commit – Posible pérdida de datos
- Nombre de red virtual (VNN)
- Puerto del oyente
- Una o más direcciones IP virtuales (VIP)
- Base de datos primaria
- Réplica de lectura secundaria
- Asistente para crear grupos de disponibilidad
- TSQL
- PowerShell
- Windows Server Failover Clustering
- Mirrorización de bases de datos
- Encriptación transparente de datos
- Compresión de copias de seguridad
- Copias de seguridad de bases de datos
- Patrones de diseño de alta disponibilidad y recuperación ante desastres de SQL Server 2012 AlwaysOn
- .
- Guía de soluciones AlwaysOn de Microsoft SQL Server para alta disponibilidad y recuperación ante desastres
- http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instance.aspx
- http://www.brentozar.com/archive/2010/11/sql-server-denali-database-mirroring-rocks/
- http://www.sqlmag.com/article/sqlserverdenali/sql-server-2012-configure-alwayson-141127
- http://msdn.microsoft.com/en-us/library/ms189134.aspx
Algunos de ellos pueden llevar tiempo y recursos para su implementación, y, por lo tanto, pueden no satisfacer sus necesidades actuales. Aquí es donde SQL Server 2012 AlwaysOn puede ayudar, ya que proporciona las ventajas de:
Necesitaremos explicar algunos de estos componentes de AlwaysOn
Windows Server Failover Clustering (WSFC)
La tecnología de clustering ha existido durante bastante tiempo, comenzando con Microsoft Clustering Services (MCS) en los días de NT 4.0 días. La tecnología para WSFC es parte de la columna vertebral de AlwaysOn. Un clúster WSFC es un grupo de servidores independientes que trabajan juntos para aumentar la disponibilidad de las aplicaciones y los servicios. Para ello, supervisa la salud del nodo activo y conmuta a un nodo de reserva, con transferencia automática de la propiedad de los recursos, cuando se detectan problemas.
Aunque el WSFC es capaz de abarcar múltiples subredes, un SQL Server que sea compatible con el clúster no ha podido, hasta ahora, soportar una instancia de SQL Server en clúster a través de múltiples subredes: Por lo tanto, ha sido bastante costoso configurar la agrupación en varios centros de datos debido a que el WSFC requiere un almacenamiento compartido en ambos centros de datos, así como la replicación SAN a nivel de bloque. Esto ha requerido mucho trabajo con sus proveedores de almacenamiento para conseguir la configuración correcta.
Reflejo de bases de datos
El reflejo de bases de datos le da la capacidad de sincronizar completamente las bases de datos de una instancia de SQL Server a otra, tanto si la segunda instancia se encuentra en el mismo servidor, en un servidor diferente en el mismo centro de datos o en un servidor en otro centro de datos. A continuación, puede cambiar los roles con la base de datos reflejada en la conmutación por error. Uno de los problemas de la duplicación de bases de datos es que no puede realizar automáticamente la conmutación por error de un grupo de bases de datos interrelacionadas. Si tiene varias bases de datos que residen en una instancia de SQL Server y una de esas bases de datos falla a la ubicación secundaria a través de su configuración de réplica de bases de datos, esta base de datos puede depender de una o más de las otras bases de datos en la instancia también. En este caso, su aplicación podría no funcionar correctamente. Otra desventaja es que la base de datos reflejada no es accesible. Puede evitarlo utilizando snapshots de la base de datos para obtener una copia de «sólo lectura».
Nodos AlwaysOn
Los nodos que utilizará en su solución AlwaysOn de SQL Server 2012 tienen que formar parte de un WSFC. El primer paso que debemos llevar a cabo para preparar nuestros nodos AlwaysOn es añadir la característica Failover Cluster a cada nodo. Entraré en detalle más adelante en este artículo.
Almacenamiento AlwaysOn
Las versiones de SQL Server anteriores a SQL Server 2012, al ser configuradas como instancia clusterizada en un WSFC requieren que el almacenamiento se presente como almacenamiento compartido. Este requisito hace que el almacenamiento sea más caro y un poco más complicado de configurar y administrar. Con SQL Server 2012 AlwaysOn su solución no tiene que utilizar el almacenamiento compartido, pero puede utilizar SAN, DAS, NAS o disco local en función de su presupuesto y sus necesidades. Le sugiero que trabaje con sus proveedores de almacenamiento para encontrar la solución que necesita.
Synchronous & Asynchronous Mirroring
AlwaysOn utiliza la tecnología de mirroring existente de SQL Server. El mirroring síncrono, como su nombre indica, requiere que las transacciones se escriban en ambos sitios para que la transacción se complete. Aunque esto puede provocar un aumento de la latencia en el sistema, no supone ninguna pérdida de datos. AlwaysOn admite hasta dos réplicas secundarias replicadas sincrónicamente por grupo de disponibilidad. La réplica asíncrona, por otro lado, es más rápida pero aumenta el riesgo de pérdida de datos ya que no tiene el requisito de completar la transacción en el sitio secundario. Una de las ventajas que tiene AlwaysOn sobre el mirroring es que permite tener varios secundarios utilizables de la base de datos. Otra ventaja es la capacidad de tener una combinación de Synchronous & Asynchronous Mirroring en su configuración para alcanzar el mejor compromiso entre rendimiento y fiabilidad. Dependiendo de sus requisitos de HA/DR, podría tener una configuración sincrónica en un servidor de su centro de datos local y una configuración asincrónica en un servidor de un centro de datos secundario.
Grupos de disponibilidad
SQL Server 2012 AlwaysOn permite un control más granular de su entorno con la introducción de los grupos de disponibilidad AlwaysOn (AAG). Los AAG le permiten configurar grupos de bases de datos que le gustaría conmutar por error todos juntos cuando hay un problema con el servidor anfitrión. Al configurar sus AAG’s usted:
Más adelante se cubre más información en profundidad sobre los Grupos de Disponibilidad.
Tareas de mantenimiento/informes
AlwaysOn le permite utilizar las réplicas secundarias que habría creado cuando configuró sus AAG para llevar a cabo algunas tareas regulares de mantenimiento de la base de datos para eliminar algunos de los gastos generales de rendimiento de su servidor de producción principal. Algunas de las tareas que podría considerar emprender en una réplica secundaria son:
.
Licencias
SQL Server 2012 ha sido lanzado con un nuevo modelo de licencia. Con la capacidad de SQL Server 2012 AlwaysOn de tener múltiples secundarios, debe tener en cuenta el licenciamiento cuando vaya a implementar múltiples secundarios. El modelo de licencia requiere que usted licencie su SQL Server Activo (Primario) en su Cluster AlwaysOn. Se le permite un servidor pasivo (secundario) que no necesita licenciar. Si tiene más de un servidor secundario, debe licenciar ese servidor, ya sea activo o pasivo. Para obtener más información sobre las licencias, consulte la Guía de referencia de licencias de SQL Server 2012 y hable con su distribuidor de licencias.
¿Qué es activo y qué es pasivo? Su primario es activo porque está accediendo a él y utilizando la base de datos. Si configura un servidor secundario para realizar cualquiera de las tareas enumeradas anteriormente en Tareas de mantenimiento/Informes, entonces este secundario también está activo y necesita ser licenciado. Recuerde: si usted accede a él, está activo. Por ejemplo: Si tuviéramos un Servidor Primario (Activo), tres Servidores Secundarios (uno Activo, dos Pasivos) tendríamos que licenciar tres de los cuatro servidores.
Seguridad
& Rendimiento
Para poder disfrutar de todas las ventajas de la alta disponibilidad, habrá mucho movimiento de datos. Esto conlleva riesgos de seguridad y mayores exigencias de ancho de banda. Para minimizar estos requisitos, la Encriptación Transparente de la Base de Datos (TDE) y la Compresión de Copias de Seguridad se incluyen en la Edición Enterprise,
Implementación de AlwaysOn
Ahora que hemos cubierto los aspectos básicos de lo que podría ser una solución AlwaysOn, estamos listos para empezar y planificar la implementación de esta solución para satisfacer sus crecientes requisitos de alta disponibilidad y necesidades de DR.
Su solución final podría ser algo así:
Imagen 1 – Solución AlwaysOn de SQL Server 2012
Construyendo su Cluster AlwaysOn
En este escenario vamos a construir un Cluster AlwaysOn de SQL Server 2012 de dos nodos. Para ello, todos los nodos que van a participar en el Cluster AlwaysOn de SQL Server necesitan tener .NET Framework 3.5.1 y la característica Failover Clustering habilitada.
Imagen 2 – Características requeridas
Ahora que hemos habilitado ambas características podemos construir nuestro WSFC. Desde el Panel de Control | Herramientas Administrativas | Gestor de Cluster de Conmutación por error | Validar una configuración, podemos validar si nuestros servidores están bien para participar en un WSFC.
Imagen 3 – Validar Cluster
Se iniciará el Asistente de ‘Validación de una configuración de Cluster’. Haga clic a través de este asistente y se le preguntará qué pruebas desea ejecutar. Yo he seleccionado todas las pruebas para esta validación. Tendrás que añadir todos los nodos que vayas a añadir a tu WSFC.
Imagen 4 – Nodos del Clúster
Al final de la Validación, siempre y cuando todo haya sido aprobado, deberías recibir la siguiente notificación:
Imagen 5 – Validación del clúster exitosa
Construyendo su Windows Server Failover Cluster
No hay ninguna diferencia entre la tarea de construir su WSFC para usar con SQL Server 2012 AlwaysOn y su WSFC previamente construido para SQL Server 2008 R2. Si nunca has construido un WSFC antes, puedes leer más sobre esto aquí Guía paso a paso de Failover Cluster. En este artículo, no voy a ir a través de la construcción de WSFC, pero tengo que mencionar que su construcción WSFC necesita pasar todas las reglas de validación con el fin de darle un WSFC soportado.
SQL Server 2012 Setup
Ahora que tenemos nuestros dos nodos en nuestro WSFC, estamos listos para iniciar el proceso de construcción de nuestro SQL Server 2012 AlwaysOn Cluster. Tenemos que asegurarnos de que tenemos nuestro medio de instalación que está disponible para su descarga desde Microsoft SQL Server 2012 Downloads.
En el Nodo1, iniciamos el setup.exe para comenzar el proceso de instalación. Nos recibe la pantalla inicial. Debe navegar a la pestaña de instalación para iniciar la instalación, seleccionando ‘Nueva instalación independiente de SQL Server o añadir características a una instalación existente’.
Imagen 6 – Instalación independiente
Las reglas de instalación deberían completarse con éxito y puede hacer clic en ‘Aceptar’ para continuar. Una vez que se haya completado el análisis de la actualización del producto, haga clic en «Siguiente».
Siga las indicaciones hasta que llegue a la pantalla de tipo de instalación, asegúrese de seleccionar «Realizar una nueva instalación de SQL Server 2012», haga clic en «Siguiente».
Imagen 7 – Nueva instalación
Ingrese su clave de producto, haga clic en ‘Next’.
Imagen 8 – Clave del producto
Acepte los términos y condiciones, haga clic en ‘Next’.
Asegúrese de seleccionar ‘SQL Server Feature Installation’, haga clic en ‘Next’.
Imagen 9 – Instalación de características de SQL Server
Elija las características que necesita instalar, haga clic en ‘Next’.
Imagen 10 – Características de SQL Server
Se comprobarán sus reglas de instalación y, siempre que no haya problemas, podrá continuar con la instalación haciendo clic en ‘Siguiente’.
Ingrese el nombre de su instancia de SQL Server 2012 para la instancia que está construyendo, haga clic en ‘Siguiente’.
Imagen 11 – Nombre de la Instancia
Normalmente recomendaría tener diferentes cuentas de servicio para cada uno de los Servicios SQL que está instalando. Sin embargo, en esta instalación sólo estoy usando las cuentas locales por defecto. Tendrás que tener las cuentas de servicio de tu Dominio creadas y establecer las contraseñas en esta pantalla de Configuración del Servidor en la instalación. Una vez que haya establecido las contraseñas, asegúrese de hacer clic en la pestaña Collation para configurar su Collation para la Instancia, haga clic en ‘Next’.
Imagen 12 – Detalles de la cuenta de servicio
En la pantalla de Configuración del motor de base de datos hay tres pestañas a las que debemos prestar atención. En la pestaña de Configuración del Servidor es donde se establece el modo de seguridad, ya sea Windows (recomendado) o Modo Mixto. Recuerde añadir la cuenta actual con la que está ejecutando la instalación, así como cualquier otro individuo o grupo que necesite ser miembro del grupo SysAdmins.
Imagen 13 – Detalles de la configuración del servidor
La pestaña de directorios de datos le permite especificar dónde quiere tener sus bases de datos de usuario, TempDB y las ubicaciones de las copias de seguridad para ser almacenadas. Tradicionalmente tendría cuatro ubicaciones de unidad separadas dependiendo de su almacenamiento para los archivos de Datos, Archivos de Registro, TempDB y Copias de Seguridad.
La Pestaña FileStream le permite Habilitar Filestream si esta es una opción requerida que necesita en su entorno. Haga clic en este enlace para obtener más información sobre FileStream.
Haga clic en «Siguiente» hasta llegar a la pantalla «Listo para instalar». En este momento debe revisar lo que se va a instalar y, si está conforme, entonces Haga clic en el botón Instalar.
Imagen 14 – Listo para instalar
Recuerde que estos mismos pasos deben completarse en el segundo nodo que está incluyendo en su Clúster AlwaysOn de SQL Server 2012.
Configuración de SQL Server 2012
Ahora que hemos instalado dos instancias independientes de SQL Server 2012 en nuestros dos servidores en el WSFC necesitamos llevar a cabo alguna configuración posterior a la instalación. Esto se consigue utilizando el Administrador de configuración de SQL Server que está disponible desde Inicio | Todos los programas | Microsoft SQL Server 2012 | Herramientas de configuración.
Debido a que las transferencias de datos por parte de SQL Server 2012 AlwaysOn se realizan a través de TCP/IP debemos habilitarlo en los Protocolos de configuración de red. Por defecto estará deshabilitado. Cambie el valor a Enabled y haga clic en ‘OK’.
Ahora estamos en el punto principal con la configuración de nuestro SQL Server 2012 AlwaysOn Cluster. Anteriormente, estábamos creando una Instancia de SQL Server en Clúster y tuvimos que emprender la Opción de Construcción en Clúster. Habréis observado que hemos instalado instancias independientes de SQL Server en cada uno de los nodos que participan en el WSFC. Necesitamos habilitar los Grupos de Disponibilidad AlwaysOn. En el «Administrador de configuración de SQL Server», seleccione la instancia de SQL Server, haga clic con el botón derecho y seleccione Propiedades. En la pestaña ‘AlwaysOn High Availability’ marque la casilla ‘Enable AlwaysOn Availability Groups’.
Haga clic en ‘OK’. Los cambios no tendrán efecto hasta que se reinicie la Instancia. Deberá repetir este paso en la segunda instancia que instalamos. (Esto deberá hacerse en cada instancia de su Cluster AlwaysOn de SQL Server 2012)
Imagen 15 – Habilitar los Grupos de Disponibilidad AlwaysOn
Ya estamos listos para empezar a configurar nuestros Grupos de Disponibilidad.
Configuración de los Grupos de Disponibilidad AlwaysOn de SQL Server 2012
Antes de SQL Server 2012, una de las opciones disponibles para construir su solución de Alta Disponibilidad (HA) era utilizar Database Mirroring. La tecnología de Database Mirroring es muy buena para lo que fue creada. Sin embargo, tiene algunas limitaciones cuando se trata de su solución de HA. Las limitaciones incluyen:
Las AAG de SQL Server 2012 resuelven la mayoría de estos problemas dándole más flexibilidad sobre su entorno y un control más granular sobre el mismo para cumplir con sus siempre crecientes y complejos requisitos de HA.
Con la implementación de las AAG de SQL Server 2012, que sigue utilizando la tecnología Database Mirroring para transferir sus datos a través de TCP/IP de forma sincrónica o asincrónica a una o más réplicas, pero dándole la ventaja añadida de poder acceder a estas réplicas. Todavía no soporta la consistencia transaccional para aquellas bases de datos que participan en un grupo de disponibilidad.
Grupos de Disponibilidad
Como su nombre indica, un Grupo de Disponibilidad es una agrupación de bases de datos relacionadas. Cuando se configuraba la duplicación de bases de datos Antes de SQL Server 2012, se podían configurar varias réplicas, pero sólo se podía configurar para duplicar una sola base de datos a la vez. Si tiene varias bases de datos que dependen unas de otras para que la aplicación funcione, no hay una forma sencilla de garantizar que todas las bases de datos fallen juntas. Los grupos de disponibilidad le permiten ahora agrupar las bases de datos adecuadas. Puede configurar hasta 10 AAG por instancia. A través de estos 10 Grupos de Disponibilidad puede tener hasta 100 bases de datos de réplica que participan.
Los beneficios que da un Grupo de Disponibilidad son que:
Réplicas de disponibilidad
Las réplicas de disponibilidad le proporcionan la capacidad de configurar:
Modos de disponibilidad
Como se ha mencionado anteriormente, a la hora de configurar sus Grupos de Disponibilidad AlwaysOn de SQL Server 2012, hay algunas consideraciones que deben tenerse en cuenta a la hora de determinar qué tipo de modo de disponibilidad puede utilizar.
Si está deseando utilizar los AAG para un proceso de elaboración de informes, podría tener su réplica secundaria ubicada en el mismo centro de datos físico e implementar el modo synchronous-commit para proporcionarle un grupo de bases de datos de sólo lectura en tiempo cercano contra el que elaborar informes sin impactar en el rendimiento de las bases de datos primarias con sobrecargas de informes. Probablemente no consideraría este tipo de modo de disponibilidad cuando hay grandes distancias entre los centros de datos.
Si tiene el requisito de un proceso de informes, que no requiere que los datos estén cerca del tiempo real, podría considerar la implementación de su réplica secundaria en un centro de datos separado que puede estar a más de 30-40 Kilómetros de distancia. Si este es el caso, debería considerar la implementación de compromisos asíncronos para su AAG. Al implementar un método asíncrono-commit, reduciría la latencia de las transacciones en el sitio primario, pero se abriría a la posibilidad de pérdida de datos.
Como puede configurar varias réplicas secundarias, puede configurar diferentes modos de disponibilidad en su entorno. Cada AAG se configura por separado; por ejemplo: puede tener dos implementaciones síncronas y dos asíncronas.
En este ejemplo tendría sus bases de datos primarias en AAG1 residiendo en DC1. A continuación, configura una réplica secundaria que también se encuentra en DC1 en un modo síncrono-commit, lo que le permite ejecutar sus requisitos de informes sin que la sobrecarga de informes afecte a su base de datos primaria. Esto también le permite cumplir con sus requisitos de HA, al tener un entorno secundario que es transaccionalmente consistente con la capacidad de conmutación por error en el caso de un problema con sus bases de datos primarias. A continuación, podría configurar réplicas secundarias en DC2, DC3 & DC4 en modo asíncrono-commit. Estas réplicas secundarias asíncronas le permiten cumplir con sus requisitos de DR al tener varias copias en múltiples ubicaciones geográficas dispersas, con la capacidad de conmutación por error en caso de un problema en el sitio primario.
Cambio por error
Al igual que con Database Mirroring y Windows Server Failover Clustering, los grupos de disponibilidad AlwaysOn proporcionan la capacidad de conmutación por error entre las réplicas primarias y secundarias que ha configurado. Hay tres formas de conmutación por error que se pueden llevar a cabo con los AAG:
El modo de disponibilidad que se utilice dependerá de si está implementando la alta disponibilidad o la recuperación de desastres. Esto afecta a la configuración de conmutación por error que va a implementar en su entorno SQL Server 2012 AlwaysOn.
Availability Group Listener
Para aprovechar las distintas soluciones que hemos pisado en este artículo, necesitamos configurar y permitir que las aplicaciones mantengan la conectividad con las Bases de Datos de SQL Server después de una conmutación por error. Aquí es donde entran en juego los AlwaysOn Availability Group Listeners (AAGL’s).
Un Availability Group Listener es un Virtual Server Name al que se conectan las aplicaciones. Desde el punto de vista de las aplicaciones, no importa dónde esté activa y disponible para su uso la Base de Datos de Disponibilidad. El AAGL consta de:
Para que su aplicación se conecte, puede configurar una cadena de conexión para su AAGL o conectarse directamente a su Instancia de SQL Server. Sin embargo, una conexión directa no ofrece el soporte de conmutación por error para el que se ha construido esta tecnología.
Cuando se produce una conmutación por error para un AAG, la conexión del cliente se termina. Para volver a tener acceso, el cliente tiene que volver a conectarse a la AAGL. Para lograr esto, la aplicación debe ser diseñada y construida para sondear la AAGL. Dependiendo de la conexión que estés utilizando:
Tendrás que configurar tu ‘ApplicationIntent’ en tu cadena de conexión AAGL adecuadamente.
Con estos puntos en mente, ya estamos en condiciones de crear nuestra primera AAG de varias maneras, que son
Desplegando el árbol de AlwaysOn High Availability | clic derecho Grupos de disponibilidad | Asistente para nuevo grupo de disponibilidad
Imagen 16 – Asistente para nuevo grupo de disponibilidad AlwaysOn
Nombre su AAG, haga clic en ‘Siguiente’.
Seleccione las bases de datos que necesita incluir en el AAG, haga clic en ‘Siguiente’.
Imagen 17 – Bases de datos de disponibilidad
Su réplica primaria estará automáticamente disponible para que la configure. Elija el modo de disponibilidad, la estrategia de conmutación por error y los requisitos secundarios legibles. Haga clic en «Añadir réplica», conectándose a sus servidores secundarios apropiados. Asegúrese de configurar su secundario igual que su primario.
Imagen 18 – Réplicas de disponibilidad
Seleccionando la pestaña Listener, dé a su AAGL un nombre, un número de puerto y las direcciones IP apropiadas, haga clic en ‘Next’.
Imagen 19 – Réplicas de disponibilidad
Cada réplica necesita tener acceso a una ubicación compartida para acceder a las copias de seguridad de las bases de datos creadas y utilizadas para sincronizar las bases de datos secundarias. Introduzca su ruta compartida, haga clic en ‘Siguiente’.
Imagen 20 – Sincronización inicial de datos
Asegúrese de que recibe todas las marcas verdes para su validación, haga clic en ‘Siguiente’.
Imagen 21 – Validación
Revise el resumen, haga clic en ‘Finish’.
Imagen 22 – Finish
Disfrute configurando su nuevo entorno SQL Server 2012 AlwaysOn.
0 comentarios