Un equipo de proyectos me mostró una propuesta de instalación de BizTalk para soportar alta disponibilidad y me preguntó si eso funcionaría.

La instalación de BizTalk era algo como se muestra en la figura 1. Es un balanceador de carga con dos nodos corriendo BizTalk y un cluster MSSQL 2005.

Ahora, la respuesta como siempre dice Dagum "depende". Voy a tratar de dar algunas luces de esto =) y asumiendo algunas cosas, evitar el depende.

Bueno, primero aclaremos algunas cosas. BizTalk Server 2006 está hecho por diseño para ser instalado en un ambiente "High Availability" [1].

La instalación de BizTalk Server en alta disponibilidad implica tener cada componente funcional en una instalación redundante. BizTalk server simplifica enfrentar estos escenarios separando conceptualmente las responsabilidades de almacenamiento de datos de las de procesamiento de estos. Por lo tanto, para tener una instalación de alta disponibilidad se necesitan correr múltiples Host de BizTalk contra un MSSQL en Cluster.

Fig1. Instalación BizTalk

Hasta ahora vamos bien. Avancemos un poco. ¿Qué pasa con la recepción de mensajes, orquestaciones y envío de mensajes si cae un Host de BizTalk?

Aquí hay que entender en concepto de Host y Host Instance de BizTalk Server antes de avanzar.

Un Host BizTalk es un contenedor lógico creado dentro de un BizTalk Server Group que puede contener objetos de BizTalk como Adapter Handler, recive Location (incluidos sus PipeLine) y orquestaciones. Típicamente se agrupan en un Host los objetos que son del mismo contexto de aplicación [3].

Una vez que se crean los Host (contenedores lógicos) estos se pueden asignar a diferentes nodos que tengan el servicio BizTalk corriendo, pasando a ser una "Host Instance".

La figura 2 muestra una instalación con dos nodos, 3 Host y 6 Host Instance que tienen como servidor de datos un cluster MSSQL. Un detalle de este ejemplo puede verse en MSDN [4].

Fig2. Instalación BizTalk de ejemplo con Host.

Ahora, qué diferencia hay entre el dibujo que se me presentó (Fig. 1) y la instalación la segunda instalación (Fig 2.). Principalmente dos puntos muy importantes.

Primero, en la segunda figura se presenta un esquema de Host BizTalk, que es la manera natural de hacer instalaciones en alta disponibilidad. Esto no está claro en el primer diagrama.

Segundo, en la primera instalación hay un SLB[3]. Si se trabaja con Host de BizTalk no es necesario usar un SLB porque BizTalk Server de manera automática distribuye la carga entre los múltiples nodos que corren una Host Instance. Esto es una muy buena solución! Pero tiene la limitante que si usted utiliza recepción de mensajes HTTP, SOAP o MSMQT va a necesitar un SLB para que los mensajes puedan ingresar a un Host por diferentes Host Instance.

Por eso, la respuesta por defecto "depende" sigue siendo válida, pero con un poco mas de información la respuesta podría ser categórica y precisa.

Referencias

[1] MSDN BizTalk Sever, http://msdn2.microsoft.com/en-us/library/aa560847.aspx

[2] MSDN BizTalk Server, http://msdn2.microsoft.com/en-us/library/aa577430.aspx

[3] Wikipedia, http://en.wikipedia.org/wiki/Load_balancing_(computing)

[4] MSDN ejemplo de instalación, http://msdn2.microsoft.com/en-us/library/aa578057.aspx

Los clientes pueden llegar a ser una inspiración, porque algunas veces te hacen preguntas cuyas respuestas te hacen pensar, estudiar y ordenar conceptos.

Aquí tengo una interesante……

De todos los aspectos necesarios para implantar una solución de autorización basada en roles ¿Qué debo hacer sí o sí?

Para lograr un correcto uso por ejemplo de Azman como herramienta de autorización basada en roles (RBAC) es necesario hacer un diseño del modelo de autorización que se desea implementar.

Esto es definir los principales aspectos que cruzan a todas las aplicaciones, que permitan a los diferentes equipos de desarrollo un uso natural de Azman dentro de las nuevas aplicaciones que desarrollen. Algunos de los aspectos a definir son:

• Administración de Roles en la organización.

La ingeniería de roles para RBAC es el proceso de definición de roles, permisos y asignación de permisos para cada role. Esto es esencialmente un proceso de ingeniería de requerimientos de roles (RE). La ingeniería de roles es el primer paso hacia la implementación de un sistema RBAC.

•  Mantención operativa del PROVISIONING

Dentro de las actividades de mantención operativa se encuentra el concepto de PROVISIONING. Esto es el proceso de asegurar que, en todo momento durante la carrera con un empleador, el personal tenga todos los privilegios de acceso necesarios, equipamiento y otros recursos de IT que pueda necesitar. Administrar esto acertada y eficientemente puede ser extremamente difícil, pero AzMan puede ayudar en gran medida, apoyando el proceso de permitir el acceso a sistemas y aplicaciones empresariales como particulares.

•  Mantención operativa Delegación de la administración

Para poder realmente cumplir con el objetivo de bajar los costos de operación es necesario poder delegar la administración de las aplicaciones. Esto ayuda también a mejorar la calidad de servicio a los usuarios cuando solicitan cambios de roles y permite administrar muchas aplicaciones de manera federada. La delegación se hace a nivel de STORE de AZMAN. Un STORE almacena una o más aplicaciones.

•  Mantención operativa Auditoria

Con Authorization Manager se pueden tener dos clases de auditoría, en tiempo de ejecución (runtime auditing) y control de cambios de authorization store (change auditing). Cuando se habilita runtime auditing, las aplicaciones generan auditorias al utilizar las políticas que están definidas en el authorization store. Se puede configurar esta auditoría para controlar los éxitos, las fallas o ambos. Esta auditoría graba en un log los clientes de contexto y los controles de acceso (access checks).

Cuando se habilita authorization store change auditing, las auditorias son generadas cada vez que el authorization store es modificado. La auditoria guarda todos los eventos, éxitos y fallas.