La parte de Service Broker, es un desconocido dentro de SQL Server, y sobretodo es la que mas mezcla la parte de desarrollo con la parte de infraestructura.
Imaginemos que tenemos una infraestructura de alta disponibilidad (Always On), de por ejemplo 4 nodos (Cluster Failover), distribuidos en 2 datacenters, en los cuales disponemos de replicas (Mirroring) síncronas entre algún nodo del mismo datacenter y replicas asíncronas entre otros nodos de distintos datacenter, y además tenemos un nodo destinado a tareas administrativas de backup… Lo normal, es que la base de datos esté activa en modo lectura y escritura en un solo nodo, y que en los otros tres nodos esté replicada ofreciendo solo acceso en modo lectura. Se ha establecido un pool de aplicaciones de Resource Governos para establecer un SLA mínimo y máximo para cuando SQL Server compita por accesos de CPU, memoria y disco (ante este escenario, vemos que somos predecibles, que es una de las cosas necesarias, tanto desde el punto de vista técnico y económico). Pero hay un punto mas allá, en el que nos gustaría tener un escenario activo—activo, y además de escritura y lectura en todos los nodos, y para esto Always On, se apoya en Service Broker, para poder dar a algunas aplicaciones, este tipo de escalabilidad.
Service Broker, se basa en una serie de colas de mensajes, donde los servidores están suscritos, y para cada inserción, transacción, etc..., se publica en la cola y se realiza un multicast, para que todos los servidores que dispongan de la misma base de datos y tengan acceso de lectura y escritura en el mismo momento, no produzcan lecturas sucias, y en caso de existir, por algún problema de red, hay una forma de resolverlo, bien delegando en la aplicación o en SQL Server.
Lo destacable en SQL2012, es la combinación de Always On con Service Broker y el poder establecer multicast de muchos a muchos pero con un único mensaje. Poder darle un Try…Catch para la gestión de errores, dentro de la parte de desarrollo. Y establecer tiempos, en los que nosotros podemos definir, cual es el tiempo máximo de espera en el que puede estar un mensaje recibido por todos los nodos, los cuales estén comunicándose. Al final es sencillo, ya que es crear rutas, y estas rutas están definidas por una serie de servicios que los publican, así como los listener de Always On que van a estar escuchando a las aplicaciones y hacia que direcciones van a ser desplegados… Desde el punto de vista del servidor de aplicación, no tenemos que preocuparnos cuando surge un failover, o cuando ha sufrido una caída uno de los servidores que da servicio a nuestra aplicación, sino que la combinación del listener con la IP y el nombre virtual que están publicadas en la parte del cluster, mas lo que nuestra aplicación haya desarrollado en el Service Broker, va a poder aislarnos o hacer lo mas transparente posible este tipo de operaciones de failover o caídas.
No quiero pasar sin comentar que Service Broker, no es la única solución de mensajería, ni es un sustituto de MQSeries o las colas de Azure…
Si os interesa este tema, recomiendo la lectura de:
Always On. SQL Server 2012
Fuentes:
Microsoft, msdn, TechNet blog...
Apunte y recopilación por Norman M. Pardell
