Vamos a partir hablando del Rol de Exchange. Si bien éste comparte el mismo nombre que en las dos últimas versiones de Exchange, es totalmente diferente. En Exchange 2007, el rol de Client Access Server proporciona autenticación, proxy/redirección y llevar a cabo la presentación de datos para los protocolos de internet hacia los clientes (Outlook Web App, EAS, EWS, IMAP y POP). En el caso de Exchange 2010, la presentación del protocolo MAPI fue movida hacia el rol de Client Access Server.

En Exchange 2013, el rol de Client Access Server (CAS) no realiza presentación de funcionalidad de datos. El rol de CAS ahora solo realiza la autenticación y Proxy, dando apoyo a los protocolos de internet hacia los clientes, transporte y mensajería unificada. Como resultado del cambio en la arquitectura, el rol de CAS no tiene estado (desde la perspectiva de sesión de protocolo, los datos que se pueden utilizar en la solución de problemas o se genera un análisis de tendencias de registro, de forma natural).

Afinidad de sesión

Exchange 2013 ya no requiere la afinidad de sesiones en el equilibrador de carga. Para entender mejor esto, tenemos que ver cómo funciona el rol de CAS en Exchange 2013. Desde la perspectiva de los protocolos ocurre lo siguiente:

1. Un cliente resuelve mediante el nombre asignado para la IP virtual del balanceador.
2. El balanceador de carga asigna la sesión a un miembro de CAS en el pool del balanceador.
3. CAS realiza la autenticación y realiza una consulta hacia Active Directory para obtener la siguiente información:  a) Versión del buzón          b)Ubicación del buzón
4. CAS realiza una decisión sobre si debe redirigir la solicitud a otra infraestructura de CAS dentro del bosque o realizar un proxy con la conexión hacia el Mailbox.
5. CAS realiza una consulta a una instancia de administración de activos para determinar en qué servidor de mailbox se encuentra la copia activa de la base de datos para el buzón solicitado.
6. CAS realiza un proxy de la solicitud al servidor que hospeda la copia activa del buzón.

El protocolo utilizado en el paso 6 depende del protocolo usado para conectar los servidores de CAS. Si el cliente utiliza el protocolo HTTP, entonces el protocolo utilizado entre el CAS y el servidor de Mailbox será HTTP (protegido vía SSL utilizando un certificado autofirmado).

Si el protocolo utilizado por el cliente es IMAP o POP, entonces el protocolo utilizado entre el servidor de CAS y Mailbox será IMAP o POP. Las solicitudes telefónicas, sin embargo, son únicas. En lugar de enviar la solicitud en el paso 6, CAS volverá a dirigir la petición al servidor de buzones que hospeda la copia activa de la base de datos del usuario, como el dispositivo telefónico utilizado necesita establecer sus sesiones por SIP y RTP, se establece la comunicación directamente con los componentes de mensajería unificada en el servidor de Mailbox.

Figura 1: Arquitectura de protocolos para CAS Exchange 2013

Además de no presentar datos, el paso 5 es el cambio fundamental que permite la eliminación de sesiones en el balanceador de carga. Para una sesión de protocolo, el CAS sostiene una relación 1:1 con el servidor de Mailbox que mantiene la información del usuario. En el caso de que la copia de la base de datos activa se mueva a un servidor de buzón diferente, CAS cierra las sesiones con el servidor anterior y establece sesiones al nuevo servidor. Esto significa que todas las sesiones, independientemente de su punto de origen (es decir, los miembros del CAS en la matriz de equilibrio de carga), terminan en el mismo lugar, el servidor de buzones que hospeda la copia de base de datos activa.

Ahora muchos de ustedes pueden estar pensando, espera ¿Cómo funciona la autenticación? Bueno para las solicitudes HTTP, POP, IMAP o que utilizan autenticación básica, NTLM o autenticación Kerberos, la solicitud de autenticación se pasa como parte de la carga útil de HTTP, por lo que cada CAS autenticará el requerimiento de manera natural. La autenticación basada en formularios (FBA) es diferente. FBA fue una de las razones por las cuales se requiere la afinidad de sesión para OWA en versiones anteriores de Exchange – la razón es que las cookies utilizan una clave para el cifrado por servidor, por lo que, si otro CAS recibe una solicitud, este no podía descifrar la sesión. En Exchange 2013, ya no nos aprovechamos de una clave de sesión por servidor, en vez de eso, aprovechamos la clave privada del certificado que está instalado en el CAS. Siempre que todos los miembros de la matriz de CAS compartan exactamente el mismo certificado, podrán descifrar las cookies.

Proxy vs Redirección

Anteriormente se habló acerca de cómo el CAS realiza un proxy de las solicitudes hacia el servidor de Mailbox que mantiene la copia activa de la base de datos. Antes de eso CAS tiene que tomar la decisión de re direccionar hacia otro CAS, o realizar el proxy. CAS solo realizará una redirección bajo las siguientes circunstancias:

1. La solicitud es telefónica
2. Para solicitudes Outlook Web App, si el buzón de mailbox se encuentra ubicado en otro sitio de Active Directory y hay un servidor de CAS en ese sitio que tiene la ExternalURL poblada, entonces el servidor de CAS de origen re direccionará la solicitud, a menos que la ExternalURL sea la misma que el servidor de origen, en cuyo caso, CAS realizará el proxy (este es un escenario con múltiples sitios y un solo espacio de nombres).

Figura 2: Ejemplo de Proxy y redirección de Client Access Server Exchange 2013

3. Para solicitudes OWA, si la versión del buzón de mailbox es Exchange 2007, entonces CAS Exchange 2013 re direccionará hacia el CAS Exchange 2007.

Conexión vía Outlook

Se habrán dado cuenta que hasta el momento solo se ha hablado de HTTP, POP e IMAP. No se ha mencionado en ningún momento RCP/TCP como solución de conectividad que soporta el CAS, y esto es por una razón muy específica, CAS de Exchange 2013 no es compatible con RCP/TCP, solo es compatible con RCP/HTTP (también conocida como Outlook Anywhere). Este cambio de arquitectura se realiza para conducir un modelo de conectividad más estable y fiable.

Para entender el por qué, es necesario tener en mente los siguientes principios:

1. Recuerde, el CAS de Exchange 2013 es un servidor de Proxy/redirección y de autenticación. CAS Exchange 2013 no realiza procesamiento de datos (ni muestra ni transformación). Solamente realiza el proxy de las solicitudes hacia el Mailbox utilizando el protocolo de cliente (en este caso HTTP).
2. CAS y Mailbox de Exchange 2013 no se encuentran unidos por una afinidad de usuarios o de manera geográfica. Es posible tener el CAS en un datacenter autenticando y realizando las solicitudes mediante proxy hacia un servidor Mailbox en otro datacenter. Para poder habilitar eso fue necesario realizar un cambio en los protocolos de comunicación utilizado entre los roles. Alejándose del protocolo RPC, hacia los protocolos de clientes los cuales son más tolerantes ante la latencia de conexiones WAN/Internet.
3. Para un buzón dado, el protocolo que da servicio a la solicitud siempre va a ser la instancia del protocolo del servidor de buzones que hospeda la copia activa de la base de datos para el buzón del usuario. Esto se hizo para acabar con los problemas de versiones y funcionalidad que hemos visto en las últimas dos generaciones.

El último elemento está relacionado al por que ya no se utiliza el protocolo RCP/TCP como solución de conectividad. En todas las versiones anteriores del RCP endpoint era un FQDN. De hecho, el cambio hacia el nivel medio para el procesamiento de RCP en CAS de Exchange 2010 introdujo un nuevo espacio de nombres compartidos, el RCP Client Access Namespace. Moviendo el acceso de cliente de vuelta al rol de Mailbox en Exchange 2013. Esto nos obligado a utilizar el Mailbox FQDN para el RCP Endpoint o nombres compartidos para el DAG.Ninguna de las opciones es adecuada y añade complejidad al soporte de la infraestructura. En cambio, ahora utilizamos un GUID. El GUID del buzón es único dentro de la organización, por lo que independientemente de donde se activa la base de datos y se monta, CAS puede descubrir la ubicación y realizar el proxy de la solicitud hacia el servidor de Mailbox correcto.

Figura 3: Cambios en el RCP endpoint

Este cambio en la arquitectura significa un modelo de conexión más fiable, para un determinado número de sesiones que se dirigen al CAS, CAS de Exchange 2013 siempre tendrá una relación de 1:1 con el servidor de Mailbox que hospeda el buzón del usuario. Esto significa que en un entorno de Exchange 2013, el cliente Outlook no requerirá un reinicio cuando se muevan los buzones.

Simplificación de nombres

Otro de los beneficios de la arquitectura de Exchange 2013 es que el modelo de espacios de nombres puede ser simplificados (especialmente para las migraciones desde Exchange 2010). En Exchange 2010, un cliente que quiere implementar una solución de site-resilent para dos Datacenter requería los siguientes nombres:

1. Nombre de protocolo de internet para primer DataCenter
2. Nombre de protocolo de internet para segundo Datacenter
3. Nombre de recuperación para OWA de primer Datacenter
4. Nombre de recuperación para OWA de segundo Datacenter
5. Nombre para RCP Client Access de primer Datacenter
6. Nombre para RCP Client Access de segundo Datacenter
7. Autodiscover
8. Legacy Namespace
9. Transport Namespace

Como se mencionó anteriormente, esto se simplificó eliminando el RCP Client Access namespace.

Recordemos que el servidor de CAS envía las solicitudes de proxy hacia el servidor que mantiene la copia activa de las bases de datos. Esta lógica de proxy no se limita a los límites del sitio de Active Directory. Un CAS de Exchange 2013 en un sitio de Active Directory puede realizar la solicitud de proxy a un servidor de Mailbox que se encuentre en otro sitio de Active Directory. Si la utilización de la red, la latencia y rendimiento no son una preocupación, esto significa que no necesitamos los espacios de nombres adicionales para escenarios de resistencia de sitio, eliminando de este modo otros tres espacios de nombres (protocolo de Internet secundaria y los dos espacios de nombres de recuperación de OWA).

 Por ejemplo, digamos que tengo una infraestructura en dos datacenter en Norte América, que tienen una configuración de red de tal manera que la latencia, el rendimiento y la utilización entre los dos datacenter no es una preocupación. También quería simplificar la arquitectura de mi namespace con la implementación de Exchange 2013 para que mis usuarios utilicen un único nombre para el acceso desde internet, independientemente de donde se encontrará su buzón. Si despliego una arquitectura como la mostrada a continuación, entonces la infraestructura CAS de ambos datacenter podrían utilizarse para enrutar el tráfico y el proxy para los servidores de Mailbox que alojan las copias activas. Como no estamos preocupados por el tráfico de red, puedo configurar DNS round robin entre las VIP de los balanceadores de carga en cada datacenter. El resultado en un sitio con resistencia a perdida mientras acepta que la mitad del trafico proxy estará fuera del sitio.

Figura 4: Único espacio de nombre en Exchange 2013.

Transporte

El servidor de Client Access puede realizar de proxy para las sesiones de SMTP. Esto es manejado por un nuevo componente, el servicio de transporte Front-End, El servicio de transporte front-end maneja todo el tráfico SMTP externo de entrada y salida de la organización de Exchange, así como, puede ser un cliente endpoint para el tráfico SMTP. Las funciones del servicio de transporte front-end funciona como proxy de capa 7 y tiene acceso completo al protocolo de conversación, el servicio de transporte front-end no tiene una cola de mensajes. Además, el servicio de transporte front-end no realiza bifurcación del mensaje.

El servicio de transporte front-end utiliza los puertos TCP25, TCP587, y TCP717 como se ve en el siguiente diagrama:

Figura 5: Arquitectura del servico de transporte front-end.

El servicio de transporte front-end proporciona protección a la red, un sistema centralizado, balanceador de carga para la salida/entrada hacia la organización de Exchange, ya sea por clientes POP/IMAP, Sharepoint, o aplicaciones de terceros.

Para los mensajes de salida, el servicio de transporte front-end se utiliza como proxi cuando los conectores de envió (que se encuentran ubicados en los servidores de Mailbox) tienen el conjunto de propiedades de FrontEndProxyEnabled. En esa situación, aparecerá que el mensaje se originó a partir del CAS.

Para los mensajes entrantes, el servicio de transporte front-end debe encontrar rápidamente un servicio de transporte saludable en un servidor de Mailbox que reciba una transición del mensaje, independientemente de la cantidad o el tipo de destinatarios:

• Para mensajes con un único destinatario, se seleccionará el servidor de Mailbox en el grupo de entrega de destino, y se dará preferencia en el servidor que se encuentre más cercano basado en las configuraciones de los sitios de Active Directory
• Para los mensajes con múltiples destinatarios, los primeros 20 destinatarios utilizaran el servidor de Mailbox más cercano basado en las configuraciones de los sitios de Active Directory.
• Si el mensaje no tiene destinatarios, se seleccionará un servidor de Mailbox al azar en el sitio local de Active Directory.

En conclusión, el rol de Client Access Server simplifica la capa de red. La afinidad de sesiones en el balanceador de carga ya no se requiere en CAS de Exchange 2013. CAS introduce una mayor flexibilidad en la implementación, ya que permite simplificar la arquitectura de su namespace, lo que podría consolidar en un único nombre a nivel regional o mundial para los protocolos de internet. La nueva arquitectura también simplifica la historia de actualización e interoperabilidad, como CAS puede actuar como proxy o redirigir a multiples versiones de Exchange, lo que permite actualizar los servidores de Mailbox a su propio ritmo.

Ernesto León, Consultor Infraestructura, Blue Latam.