Preguntas y respuestas acerca de Exchange: Matrices de CAS: roles del servidor, creación de cliente, equilibrio de carga y más
Henrik Walther
Información básica acerca de roles de servidor
P: Estoy planificando actualizar nuestro entorno de Microsoft Exchange 2007 a Exchange 2010. Esta implementación debe ser redundante en todos los niveles. Como nuestra organización tiene alrededor de 3.000 usuarios, planifico instalar Exchange inicialmente en dos máquinas. Cada una tendrá los roles de servidor Transporte de concentradores (HT), Servidor de acceso de cliente (CAS) y Buzón (MB). Ambos también serán miembros de un grupo de disponibilidad de base de datos (DAG), de manera tal que los servidores replicarán las bases de datos entre sí.
Desde nuestra experiencia con el entorno de Exchange actual, sé que si los roles de HT y MB están en la misma máquina, el servicio de envío de correo de Microsoft Exchange siempre prefiere el servidor HT local. No usa otros servidores de HT en el sitio de Active Directory en operación por turnos, tal como los servidores de MB que no tienen el rol de servidor de HT.
Si es el mismo en Exchange 2010, tenemos un problema. Mantener la recuperación del elemento eliminado de transporte en un miembro de DAG no tiene sentido. Si el servidor miembro no está disponible y las bases de datos del buzón realizan la conmutación por error en el otro miembro de DAG, no es posible volver a enviar los mensajes en la recuperación del elemento de transporte.
R: Entiendo su preocupación. Primero, permítame garantizarle que el grupo del producto de Exchange ha considerado este tipo de escenario. Al comienzo del desarrollo de Exchange 2010, el equipo hizo un cambio en el diseño. Si un servicio de envío de correo de Exchange detecta que se está ejecutando en un servidor de buzón que sea parte de un DAG, no va a preferir el servidor HT local. En lugar de eso, equilibrará la carga en todos los demás servidores de HT en el mismo sitio de Active Directory. Si no encuentra ninguno, volverá al servidor HT local.
El servicio de envío de correo de Exchange que reside en el rol de MB no fue lo único que cambiaron los desarrolladores. Modificaron el rol HT para volver a enrutar un mensaje a otro servidor HT en el sitio de Active Directory si el rol HT está instalado en un servidor que también tiene el rol MB y que es parte de un DAG. El grupo hizo ambos cambios para garantizar una alta disponibilidad cuando coexistan roles de HT y de MB en un servidor que también sea miembro de un DAG.
Diseño de acceso de cliente
P: Estamos diseñando nuestra solución de Exchange 2010 y debemos determinar el número de matrices de servidor de acceso de cliente (CAS) a crear. Tendremos dos centros de datos, cada uno con su propio sitio de Active Directory. ¿Debemos crear una por sitio o tiene sentido que cada uno tenga varias matrices?
Además, usaremos DAG para proteger las bases de datos del buzón y tendremos copias de cada división de base de datos en los dos sitios. ¿Una conmutación por error o el cambio a una copia en el otro sitio, que tiene usuarios conectados, requiere que reconfiguremos de manera manual el DNS para apuntar a clientes a la matriz CAS de ese otro sitio?
R: La decisión acerca del número de matrices CAS debe ser fácil: no pueden crear más que una por sitio de Active Directory. Si lo intentan, obtendrán el mensaje de error que se muestra en la figura 1.
.png)
Figura 1 El mensaje de error que verá si intenta crear una segunda matriz de CAS en un sitio de Active Directory.
Dado que puede obtener acceso a una base de datos de buzón a través de cualquier matriz de CAS en el entorno, no debería existir la necesidad de tener más de una. Incluso si pudiese crear más, sólo se usaría la primera.
En relación a la otra pregunta, mientras al menos un servidor de CAS en la matriz de CAS del sitio 1 esté disponible, no será necesario reconfigurar el DNS para apuntar a los clientes a la matriz del otro sitio luego de un cambio o una conmutación por error. Los servidores de CAS disponibles en el sitio 1 se comunicarán directamente con los servidores del buzón (que almacenan las bases de datos activas para los usuarios del sitio 1) mediante el uso de RPC.
Creación de cliente
P: ¿Tienen algún procedimiento recomendado que compartir para la creación de una matriz de CAS de Exchange 2010 en un sitio de Active Directory?
R: Le aconsejo crear la matriz de CAS antes de hacer cualquier base de datos de buzón o de mover cualquier buzón a un servidor de buzón de Exchange 2010 en un sitio. Las bases de datos de buzón de Exchange 2010 tienen un atributo llamado RpcClientAccessServer. Si no hay una matriz de CAS en el sitio de Active Directory cuando se crea la base de datos, se rellenará con el FQDN de servidor de un servidor de CAS de Exchange 2010 en el sitio de Active Directory. Si crea la matriz de CAS antes de cualquier base de datos de buzón, este atributo recibirá el FQDN de la matriz de CAS, tal como se muestra en la figura 2.
.png)
Figura 2 Atributo RpcClientAccessServer en una base de datos de buzón.
¿Por qué esta es una buena idea? El cliente de Outlook (ya sea Outlook 2003, 2007 ó 2010) no elegirá automáticamente el cambio. Si usa Outlook 2007 ó 2010, podrá hacer que se actualice el perfil haciendo que el extremo de RPC antiguo no esté disponible o haciendo una reparación del perfil. Pero Outlook 2003 no puede cambiar el extremo y no incluye una característica de reparación de perfil. Eso lo obliga a cambiar manualmente el perfil, eliminando nombre de usuario, volviendo a agregarlo y haciendo clic en el botón “Comprobar nombre”). Esto no es lo ideal, y además implica a los usuarios finales, por lo que realmente debe crear la matriz de CAS de antemano.
Equilibrio de carga de las matrices de CAS
P: Estamos planificando usar un equilibrador de carga de hardware en lugar de NLB de Windows para nuestra matriz de CAS, por lo que nos preguntamos si es posible definir puertos estáticos para el nuevo servicio de acceso de cliente RPC de Exchange 2010. El proveedor al que adquirimos el equilibrador de carga de hardware nos recomienda que no usemos puertos dinámicos. Si podemos definir puertos estáticos para este servicio, ¿nos recomiendan alguno específico?
R: Tal como con las versiones anteriores, en Exchange 2010 puede definir puertos estáticos para el servicio CA de RPC. Necesita hacerlo para el servicio y también para el servicio de la libreta de direcciones de Exchange, porque Outlook se comunica con ambos a través de MAPI. Las conexiones de carpetas públicas siguen ocurriendo también contra los servidores de buzón.
Para definir un puerto estático para el servicio CA de RPC en un servidor de CAS, necesita abrir el registro en cada servidor de CAS de la matriz de CAS e ir a: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. Cree una clave nueva llamada ParametersSystem, y bajo esta clave cree una REG_DWORD llamada Puerto TCP/IP. El valor para la DWORD debe ser el número de puerto que desea (consulte la figura 3).
No existe un procedimiento recomendado en lo que respecta a los puertos RPC estáticos más allá de la recomendación que use un puerto no asignado y no usado en la red corporativa. Microsoft IT eligió usar el puerto TCP/IP 7575 en la red corporativa de la empresa. Debe usar el adecuado para su situación.
Para definir un puerto estático para el servicio de la libreta de direcciones de Exchange, abra el archivo microsoft.exchange.addressbook.service.exe.config ubicado en C:\Program Files\Microsoft\Exchange Server\V14\Bin en el Bloc de notas. Luego cambie el valor del puerto TCP/IP que desea usar. No puede usar el mismo puerto TCP/IP para CA de RPC y para el servicio de la libreta de direcciones de Exchange.
.png)
Figura 3 Configuración de un puerto estático para el servicio CA de RPC en un servidor de CAS.
Una vez que haya configurado el puerto, deberá reiniciar la libreta de direcciones de Microsoft Exchange y el servicio de acceso de cliente de RPC de Microsoft Exchange. Para definir un puerto estático para las conexiones de carpetas públicas, siga los mismos pasos que realizó para cambiar el puerto TCP/IP usado en el servicio CA de RPC. La única diferencia es que debe hacerlo también en los servidores de buzón de Exchange 2010, porque las conexiones de carpetas públicas se producen contra el servicio CA de RPC en el rol de servidor de buzón. Cuando el puerto se ha definido para conexiones de carpetas públicas, debe reiniciar el servicio de acceso de cliente de RPC de Microsoft Exchange en cada servidor de buzón.
Conexiones de Outlook
P: He oído que sólo Outlook 2007 y 2010 pueden conectarse a un servicio CA de RPC o a una matriz de CAS. ¿Es realmente cierto?
R: En el pasado, la documentación de Exchange 2010 establecía de manera incorrecta que no podía conectarse al servicio CA de RPC o a una matriz de CAS mediante el uso de un cliente de Outlook 2003. Era un llamado error en un documento. Los clientes de Outlook 2003 son completamente compatibles. Sólo necesita asegurarse de que habilita el cifrado de RPC en el perfil de Outlook o de que deshabilita el requerimiento de cifrado de RPC en los servidores de CAS. Desde un punto de vista de la seguridad, Microsoft recomienda que habilite el cifrado de RPC en el perfil de Outlook. Puede hacerlo mediante una directiva de grupo. Para ver los pasos, consulte el artículo de la KB “Problemas de conexión de Outlook con buzones de Exchange 2010 debido al requerimiento de cifrado de RPC.”
Equilibrio de carga con NLB de Windows
P: Cuando usa el equilibrio de carga de red de Windows (WNLB) para equilibrar la carga del tráfico a una matriz de CAS de Exchange 2010, ¿el FQDN del WNLB debe coincidir con el de la matriz de CAS?
R: No es un requisito en absoluto. Por ejemplo, cuando use NLB de Windows para equilibrar la carga del tráfico que va a la matriz de CAS, podría especificar un FQDN para el NLB de Windows de, digamos, casarray01.contoso.com y asignar la matriz de CAS outlook.contoso.com. Esto funcionaría bien y es totalmente compatible. Todo irá bien, siempre y cuando el registro de DNS interno de la matriz de CAS apunte a la IP virtual del WNLB.
Henrik Walther es un MVP experto certificado de Microsoft de Exchange 2007 y Exchange con más de 15 años de experiencia en el campo de TI. Trabaja como Arquitecto tecnológico para Timengo Consulting (Microsoft Gold Partner en Dinamarca) y como escritor técnico para Biblioso Corporation (una empresa con base en EE. UU. que se especializa en documentación administrada y servicios de localización). Puede escribir un correo electrónico a Walther a exqa@microsoft.com.