Desmitificación del objeto de matriz CAS: parte 2

Artículo original publicado el jueves 29 de marzo de 2012

¡Bienvenidos de nuevo! En el artículo Desmitificación del objeto de matriz CAS: parte 1 analizamos estos tres puntos para comenzar a desmitificar determinadas cuestiones relacionadas con el objeto de matriz CAS en Exchange Server 2010.

1. El objeto de matriz CAS no equilibra la carga del tráfico.
2. El objeto de matriz CAS no presta servicios OWA, ECP, EWS, de Detección automática, IMAP, SMTP o POP
3. No es necesario que el objeto de matriz CAS forme parte del certificado SSL.

En la parte 2 analizaremos los tres elementos siguientes para librarnos, de una vez por todas, del misterio que rodea a los objetos de matriz CAS y ayudarles a corregir las implementaciones existentes y a realizar una planificación más estratégica de cara a implementaciones futuras.

4. Los clientes externos no deben poder resolver los objetos de matriz CAS a través del DNS.
5. El objeto de matriz CAS no debe configurarse ni modificarse tras crear las bases de datos de los buzones de Exchange Server 2010 y mover los buzones a las bases de datos.
6. Es necesario configurar el objeto de matriz CAS incluso si solo dispone de un CAS o de un único servidor de múltiples roles.

4. Los clientes externos no deben poder resolver los objetos de matriz CAS a través del DNS.

Tal como se ha mencionado en la parte 1 (al menos dos veces, ya que he dejado de contar), el FQDN del objeto de matriz CAS no debe ser el mismo que el FQDN usado para otros servicios como, por ejemplo OWA, ECP, EWS, EAS, la Detección automática o para el nombre del host externo de Outlook Anywhere.

La razón principal por la que el nombre no debe ser el mismo es porque los clientes de Outlook Anywhere tratarán, en primer lugar, de resolver el FQDN del objeto de matriz CAS mediante DNS para averiguar si deben tratar de establecer una conexión RPC (mediante TCP) o probar directamente con HTTPS. ¿Permiten ustedes que las conexiones RPC (mediante TCP) procedentes de Internet tengan acceso directo a su intranet? Espero que no lo hagan y si lo hacen, sabed que aparecerá una gran marca roja en el informe del Programa de evaluación del estado y el riesgo de Exchange. Si el cliente trata de establecer la conexión en primer lugar con RPC (mediante TCP) porque ha podido resolver el FQDN del objeto de matriz CAS, podría producirse un importante retraso antes de que vuelva a tratar de establecer una conexión HTTPS a la URL del proxy de Outlook Anywhere. Este retraso, a su vez, puede dar lugar a un mayor número de llamadas al servicio de atención al cliente por bajo rendimiento o interrupción del servicio.

Para evitar esta situación, basta con que el FQDN del objeto de matriz CAS interno sea único para el DNS interno como, por ejemplo, outlook.corp.contoso.com, y usar para el resto de URL de servicios que no sean RPC (mediante TCP) algo así como mail.contoso.com de forma interna y externa mediante DNS divididos.

Para aquellos que no hayan tenido la oportunidad de usar DNS divididos, diremos que es cuando tenemos un conjunto de servidores DNS interno Y externo para administrar solicitudes de la misma zona de búsqueda de reenvío, por ejemplo contoso.com. Las dos infraestructuras DNS están totalmente aisladas entre sí. No hay transferencias de zonas ni se usan mutuamente como reenviadores DNS. Esta configuración permite a los usuarios internos usar la infraestructura DNS interna para resolver el host mail.contoso.com a una dirección IP interna (por ejemplo, 192.168.1.10) que apunta a la VIP del equilibrador de carga, mientras que los usuarios externos lo resuelven a la dirección IP pública, que puede apuntar a la infraestructura Forefront TMG/UAG orientada a Internet de su red perimetral. Es muy común que la dirección IP del objeto de matriz CAS y la dirección IP interna de las URL de los servicios no RPC (mediante TCP) (OWA, ECP, EWS, etc.) sea la misma VIP del equilibrador de carga, aunque usan distintas comprobaciones de conexión para la correcta detección del estado del servicio.

¿Devuelve el DNS una respuesta comodín?

Me he topado con al menos un cliente que tenía un servidor DNS externo que usaba un registro comodín como respuesta a cualquier consulta que recibía de nombres de host no existentes. De este modo, no importaba si se enviaban solicitudes DNS como, por ejemplo, NombreRaroQueNoExiste.contoso.com, ya que el servidor DNS siempre devolvía la dirección IP del sitio web corporativo. (Los registros comodín son totalmente válidos desde el punto de vista de los estándares de Internet. Consulte el apartado 4.3.3 de RFC 1034 para obtener más detalles, -Editor).

Debido a esto, sus clientes de Outlook Anywhere siempre lograban resolver el FQDN del objeto de matriz CAS y siempre trataban de establecer una conexión RPC (mediante TCP) antes de cambiar a HTTPS. Si se encuentra en una situación similar con un servidor DNS externo que usa respuestas comodín para una zona de búsqueda determinada, os recomiendo evitar usar dicha zona de búsqueda para la URL del proxy de Outlook Anywhere.

Es necesario hacer un pequeño inciso para recordaros que no debéis olvidar configurar los supervisores de estado de servicio correctos para la solución de equilibrio de cargas. Para obtener los mejores resultados de supervisión de servicio, consulte con su proveedor de solución de equilibrio de cargas. Consulte Implementación de equilibrador de cargas en Exchange Server 2010 para obtener una lista de proveedores de equilibradores de carga que hayan realizado pruebas de solución en Exchange 2010, así como vínculos a sus páginas web correspondientes (para Exchange 2010). Tened en cuenta que esta *no* es una lista definitiva de proveedores de equilibrio de cargas compatibles, solo es una lista de proveedores que han decidido colaborar directamente con Microsoft para probar la solución y ofrecer soporte.

Un ejemplo rápido e informal puede ser que los FQDN basados en servicios HTTPS lleven a cabo pruebas de conexión ante respuestas TCP/443 y la solución de equilibrado de cargas deje de enviar el nuevo tráfico de cliente al servidor de acceso de cliente que, a su vez, deja de responder a TCP/443. El FQDN del servicio RPC (mediante TCP) del objeto de matriz CAS puede llevar a cabo pruebas de estado en el asignador de extremos RPC en TCP/135 además de en los dos puertos TCP estáticos seleccionados para el servicio de acceso cliente RPC y el servicio de libreta de direcciones. En caso de que alguno de estos tres puertos deje de responder en un servidor de acceso de cliente, la solución de equilibrado de cargas no enviará el nuevo tráfico de cliente al CAS para RPC (mediante TCP) hasta que los puertos vuelvan a responder. Si no se configuran puertos TCP estáticos, Exchange seleccionará un puerto TCP dinámico para cada servicio en el inicio, lo que dificultará, o incluso impedirá, a las soluciones de equilibrado de cargas la realización de las pruebas de conexión.

5. El objeto de matriz CAS no debe configurarse tras crear las bases de datos de Exchange Server 2010

Muchas veces tenemos muy poco tiempo para instalar los servidores de los buzones o crear las bases de datos de los buzones, con lo que, a menudo, iniciamos las pruebas de validación de la solución de almacenamiento con Jetstress. Yo recomiendo tomar el proceso con cierta calma para evitar tener problemas más adelante. Aunque muchos consideran que los servidores de buzones de correo son el rol de servidor más importante, no es bueno que la puerta permanezca cerrada por el simple hecho de que no es posible tener acceso a los buzones mediante los servidores de acceso de cliente.

Si se crean las bases de datos de los buzones de correo antes de crear el objeto de matriz CAS, aparecerá un servidor de acceso de cliente aleatorio en el mismo sitio de Active Directory en el atributo RpcClientAccessServer de cada base de datos.

Este debería ser su aspecto (usando el FQDN del objeto de matriz CAS):

Figura 1: Si se crea un objeto de matriz CAS, la propiedad RpcClientAccessServer de la base de datos del buzón de correo tomará el FQDN del objeto de matriz CAS.

Sin embargo, tendrá el aspecto siguiente:

Figura 2: Si no se crea el objeto de matriz CAS, la propiedad RpcClientAccessServer de la base de datos del buzón de correo tomará el FQDN del servidor de acceso cliente.

Los perfiles cliente tendrán el aspecto siguiente:

Figura 3: Si no se crea el objeto de matriz CAS, los clientes de Outlook se configurarán con el FQDN del servidor de acceso de cliente.

Los clientes se conectarán del modo siguiente:

Figura 4: Los clientes se conectan al FQDN del servidor de acceso de cliente.

Así a simple vista, no parece que haya ningún problema y todo parece funcionar correctamente; sin embargo, tendrá problemas más adelante. Si mueve los buzones de correo a Exchange Server 2010 con esta configuración, Outlook usará el nombre CAS del campo “Servidor” del perfil de usuario. En principio, funcionará sin problemas, a menos que el servidor de acceso de cliente deje de estar disponible o deje de estar disponible y se sustituya por un servidor con distinto nombre. Apuesto a que muchos de vosotros utilizaréis un grupo de servidores de acceso de cliente de carga equilibrada cuando esto suceda. Seguro que no me equivoco.

Seguro que muchos pensarán: "Muy bien. Si llega ese día, crearé un objeto de matriz CAS y solucionaré el problema de RpcClientAccessServer en las bases de datos y todo en orden”. Sin embargo, yo estoy aquí precisamente para deciros que esto solo funcionará para los buzones que se muevan a Exchange 2010 tras haberse dado el caso. Todos los usuarios con un perfil de Outlook preexistente configurado para que apunte a un nombre de CAS en lugar de al objeto de matriz CAS seguirán conectándose al nombre de CAS, por lo que no se actualizarán para usar el FQDN del objeto de matriz CAS.

El perfil no se actualizará porque el cliente no recibirá ninguna respuesta ecWrongServer de CAS. La razón por la que no recibirá esta respuesta es porque cualquier CAS es, en realidad, un punto de conexión válido a cualquier base de datos de buzón a través de RPC (mediante TCP), por lo que los clientes pueden sobrevivir a eventos de cambio/conmutación por error sin que sea necesario volver a configurarlos. Lo único que el administrador debe hacer es voltear el registro DNS del objeto de matriz CAS para que apunte a un grupo de CAS que haya sobrevivido a los eventos de CAS. En estos momentos, la única manera de corregir los problemas de perfiles de buzón de correo es mediante la reparación manual del perfil en Outlook con la publicación de un archivo PRF de Office a través de GPO (no válido para máquinas no unidas por dominio) o con la retirada del servidor CAS al que se hace referencia en los perfiles de usuario para que el extremo deje de estar disponible. Esta última opción (deberán probar hasta la saciedad) conlleva la reparación completa del perfil por parte del servicio de Detección automática en Outlook 2007 o Outlook 2010. En Outlook 2003, solo se puede corregir el problema con una reparación de perfil o mediante un archivo PRF. Tal como se indica en este artículo, la Detección automática no sirve para actualizar el perfil con un nuevo nombre de servidor como parte del proceso de Detección automática normal, que actualiza la configuración de Outlook Anywhere y detecta las URL de EWS para otras características como, por ejemplo, la administración de fuera de la oficina, libre/ocupado o la administración de las reglas de la bandeja de entrada.

Esto también implica que si se mueve un buzón de una base de datos de un sitio de AD Site-A que use un objeto de matriz CAS con el nombre Boston-CASArray a una base de datos de un sitio de AD Site-B que use un objeto de matriz con el nombre Redmond-CASArray, el perfil no se actualizará y el campo del nombre del servidor seguirá teniendo el valor del FQDN de Boston-CASArray. Es necesario tener esto en cuenta si se va a migrar un grupo de usuarios a otros sitios debido a cambios de trabajo o si se van a mover los buzones de forma masiva a otro sitio. Si no se crean las bases de datos de Exchange 2010 antes del objeto de matriz CAS, es de vital importancia corregir el atributo RpcClientAccessServer de las bases de datos para que usen el objeto de matriz CAS antes de mover los buzones a las bases de datos.

6. Es necesario configurar el objeto de matriz CAS incluso si solo dispone de un CAS o de un único servidor de múltiples roles.

Piensen un momento en lo que se ha tratado en el punto anterior: los clientes no se actualizan de forma automática para usar un objeto de matriz CAS si se agrega con posterioridad. ¿Qué ocurre si solo tenemos un CAS? Probablemente piensen que eso no tiene importancia. Seguro que podríamos discutir si realmente tiene o no importancia cuando llegue el momento, pero ¿por qué no prepararnos de cara al futuro y evitar problemas y frustraciones? Piensen, por un momento, que dentro de un año pueden necesitar sustituir el CAS. Si los perfiles de sus clientes apuntan a un nombre de CAS, me temo que no podrán hacer el cambio sin interrumpir el servicio y sin realizar tareas manuales. Tendrán que reparar los perfiles con uno de los métodos descrito para después de agregar un nuevo CAS o tendrán que retirar el CAS existente y agregar un nuevo CAS con el mismo nombre de host, lo que también implicará algún tiempo de inactividad. Para mí, ninguna de estas opciones es aceptable.

Imaginen que cambian sus necesidades empresariales y necesita un elevado nivel de disponibilidad de acceso de clientes. La única manera de satisfacer esta necesidad es mediante la incorporación de un segundo CAS y de una solución de equilibrado de cargas. Si llega el caso, estará totalmente acorralado y, de nuevo, tendrá que reparar todos los perfiles siguiendo uno de los métodos ya descritos. Nuevamente, estas opciones no son aceptables bajo mi punto de vista.

Por ello recomiendo crear un objeto de matriz CAS desde el principio. ¿Cómo crear el objeto de matriz CAS si no tenemos equilibrador de cargas y un único CAS? Muy fácil: basta con configurar el objeto de matriz CAS con normalidad, asignarle un nombre, un sitio de AD, un FQDN y, a continuación, especificar que apunte al registro ‘A’ DNS de la IP como único CAS existente o al servidor de múltiples roles que tenga en ese momento. De esta forma, estará preparado de cara el futuro y si alguna vez es necesario sustituir el CAS simple o el servidor de múltiples roles, lo único que tendrá que hacer es crear el nuevo servidor y cambiar la dirección IP del registro DNS para que todo siga funcionando. Si alguna vez necesita agregar mayor disponibilidad, bastará con tener la solución de equilibrado de cargas operativa y modificar la dirección IP del registro DNS del objeto de matriz CAS para que apunte a la VIP de la solución de equilibrado de carga. Así de sencillo.

Espero que este artículo haya resultado de utilidad para esclarecer algunos de los conceptos erróneos que giran en torno a los objetos de matriz CAS y para facilitar la migración a Exchange Server 2010.

Brian Day
Ingeniero de campo principal, Mensajería

Esta es una entrada de blog localizada. Puede consultar el artículo original en Demystifying the CAS Array Object - Part 2