Si tuviera que definir una palabra para describir la tecnología del momento, la palabra sería “Cloud”. Cada vez más aparece “la nube” en cualquier discusión tecnológica y/o proyecto en el que me encuentro. Sea para alabarla o para criticarla, la nube parece que siempre está presente en todo proyecto que se precie últimamente.

Este artículo no va a estar centrado en debatir si es mejor PasS (Platform as a Service), IaaS (Infrastructure as a Service), usar on-premise,…sino para mostrar de una forma visual y sencilla una configuración que hoy en día tiene más cabida de la que nos podemos imaginar…un escenario híbrido contra la nube Azure de Microsoft.

Imaginemos que nuestro negocio tiene una clara vertiente estacional y necesitamos dar solución a la creciente demanda que está generando en la que, por ejemplo solo en los meses de verano el uso de nuestra plataforma aumenta un 600%. Tradicionalmente nos encontramos en un escenario en el que nosotros tenemos compradas las máquinas, tenemos compradas las licencias, montada la infraestructura IT, contratada luz, contratado un buen sistema de comunicaciones,…Ante este escenario, si la demanda de nuestro servicio aumenta drásticamente en determinadas épocas del año, nos encontraremos ante la problemática de qué hacer…¿compramos más máquinas, licencias,…o probamos con la nube?

Obviamente este post va de encajar en un escenario típico y cada vez más común, aplicación global con uso estacionalmente dispar. ¿Por qué nos decantaríamos por Azure en un escenario como el planteado en el ejemplo?, Se me ocurren bastantes cosas pero hay dos bastante importantes en el caso planteado:

  • Necesitamos elasticidad en la plataforma
    • Azure te ofrece poder añadir-quitar recursos a tu infraestructura en un abrir y cerrar de ojos. Ya no hablo solo de tener worker roles con escalabilidad automática, hablo de disponer en minutos de una máquina funcional completa con SQL Server 2012 SP2 y empezar a dar servicio, por ponerte un ejemplo.
    • Además, una vez los recursos no te son necesarios los puedes desasignar directamente y dejar de pagar por ellos (aunque estén ahí configurados a la espera de que se vuelvan a levantar llegado el momento)
  • Necesitamos que la plataforma Cloud tenga buenos tiempos de respuesta al rededor del globo
    • Una de las ventajas de Azure es que tus servicios cloud pueden estar alojados en los CPD que MS proporciona…y eso implica que puedes tener una zona dando soporte en la región de Este USA, Oeste USA, Oeste Europa, Este Asia,…mejorando los tiempos de respuesta para los usuarios independientemente de la parte del globo en que se encuentren.

Este artículo no tienes que verlo como algo que te fuerce a ti a poner parte de tu infraestructura en la nube, sino como algo para que te plantees que hay soluciones muy capaces en Azure. Vamos a ver lo fácil que es añadir nodos en la nube con suscripciones a máquinas on-premise de tu infraestructura local. Hay muchas razones por las que esto te puede ser útil y muchas otras por las que en tu caso igual no aplica, pero eso lo dejaremos como debate para más adelante si os apetece.

Lo que deseamos construir es una arquitectura como la que veis aquí abajo y que tiene las siguientes características:

  • Permite escalar el nº de instancias SQL Server horizontalmente y de esta forma poder mejorar el rendimiento
    • Obviamente tus aplicaciones deben soportarlo, en eso no entraremos ahora
  • Soporta balanceo de carga automático de cadenas de conexión desde nuestras capas de negocio
    • En principio nos da igual a qué instancia conectarnos y pondremos un balanceador automático para que nuestras aplicaciones conecten automáticamente a cada instancia
  • Podemos montar el entorno en un espacio de tiempo de varias horas
    • Depende únicamente del tamaño de datos de la primera sincronización (despliegue de snapshot desde on-premise a SQLRepublicador)
    • Aprovisionamiento de máquinas en minutos
  • No es necesario crear una VPN
  • No es necesario tener conectividad desde entorno productivo hacia la nube, basta con que lo tenga el distribuidor
  • Podemos montar toda la solución con instancias SQL Server versión Standard

Arquitectura de la solución planteada

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

 

 

Montar este escenario como comentamos es bastante rápido ya que nos aprovecharemos de los templates de Azure y la facilidad de aprovisionar máquinas.

Introducido el escenario ahora, lo que vamos a hacer paso a paso es montar su infraestructura:

  • Crear nuestra red virtual
  • Crear nuestro dominio active directory en Azure (si no lo tenemos ya)
    • No vamos a tener que vincularlo con nuestro dominio privado on-premise
  • Añadir una máquina llamada SQLRepublicador así como las máquinas que actuarán como subscriptores
  • Crear la publicación on-site y subscribirnos con SQLRepublicador
  • Crear la publicación en SQLRepublicador y subscribirnos desde SQL2012std-1 y SQL2012std-2
  • Crear balanceador automático para acceso a datos

 

Crear nuestra red virtual

Este es el primer paso que deberías tomar para poder crear tu infraestructura cloud correctamente y generalmente es el paso que uno acaba olvidándose y teniendo que repetir al final mucho de lo realizado J.

Al igual que haces cuando montas una infraestructura privada on-premise, también deberías hacer tu mapa de red cloud para tener una buena infraestructura de direccionamientos de servicios cloud. Para ello debemos recurrir a montar nuestros propios espacios de direccionamientos, cosa que se hace con el servicio “network service” de Azure.

1. Creamos nuestro grupo de afinidad en la región que elijamos

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

2. Creamos el network service seleccionando el espacio de direcciones y máscara de red, así como el grupo de afinidad al que va a pertenecer (obviamente al que acabamos de crear en el ejemplo anterior)

La parte DNS Server todavía no existe porque precisamente vamos a montarlo en el siguiente apartado J

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

3. Ahora configuramos nuestra infraestructura indicando las subredes que vamos a querer. Por ejemplo, indicaremos que queremos una única subred a la que llamaremos “Subnet-1” y cuyas IP irán de la 10.0.0.4 a la 10.31.255.254 (un montón de VMS J)

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

De momento ya hemos acabado con las “redes virtuales”, aunque volveremos a ella más adelante para indicar el servidor DNS

Crear nuestro dominio Active Directory en Azure

Si vas a montar tu infraestructura en Azure, es importante montar tu propio dominio, puesto que estamos montando nuestra infraestructura cloud y esto siempre la primera acción que deberías tomar.

El proceso es muy sencillo y rápido, como vas a poder ver:

1. Recuerda crear previamente el grupo de afinidad y la red virtual (punto anterior)

2. Creas una máquina virtual capaz de contener los servicios DNS y Active Directory (yo los pongo en la misma máquina por facilidad a la hora de escribir este artículo)

a. Una Windows Server 2012 R2 es buena idea

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

3. Una vez esté online, vas al server mánager y añades los roles DNS y Active Directory

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

4. Configuramos Active Directory

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

5. Pinchamos en “more

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

6. Pinchamos en “promote this server to a domain”

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

7. Configuramos DNS como necesitemos (si no quieres hacer nada más ahí, para este artículo no vamos a hacer nada mas)

Simplemente ahora validamos el estado en que está la IP de esta máquina que actuará de controlador de dominio (durante el proceso anterior se habrá reiniciado alguna que otra vez)

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

[box type=”warning”] NOTA: Esta VM no debes apagarla nunca, recuerda que es tu controlador de dominio. Las buenas prácticas aconsejan crear 2, pero para este artículo lo dejaremos así.[/box]

Por último, ahora debemos volver a la configuración de nuestra red virtual y asignarle la IP de esta máquina como servidor principal DNS. Haciendo esto, conseguiremos que las nuevas máquinas que utilicen la red virtual que hemos llamado “solidqnetwork1”, tengan automáticamente configurado como servidor principal DNS, a nuestro servidor DNS y por lo tanto formen parte de nuestra red y sean capaces de verse entre todas ellas.

Para ello, entra en la configuración de tu red virtual y añade la IP de tu servidor DNS que acabas de configurar como servidor DNS primario.

Replicación híbrida y escalabilidad con SQL Server OnPremise y Azure (1/4)

 

En este punto ya tenemos una red cloud interna para todos nuestros servicios cloud de esta arquitectura. En este caso concreto no necesitamos crear ningún cluster ni nada y además vamos a utilizar replicación transaccional, por lo que podemos optar por una instancia SQL Server 2012 Standard.

En el siguiente post, continuaremos añadiendo nuestras máquinas de republicación y los primeros subscriptores en Azure. Estate atento!

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like