Mejores prácticas para la topología de HA de Exchange 2010 teniendo en cuenta 6 x licencias de Exchange y TMG 2010

¿Cuál sería la mejor topología teniendo en cuenta que:

6 x licencias estándar de Exchange 2010
2 x ubicaciones separadas que se supone que admiten redundancia en caso de problemas de enlace
4 x Forefront TMG 2010 con Forefront Security y Forefront Protection / Security

Múltiples ubicaciones en todo el mundo utilizando esos Exchange. La mayoría de las ubicaciones estarán conectadas con el Túnel VPN (las que alojan Exchange con seguridad).

Estaba pensando en algo como esto:

Ubicación PRINCIPAL (aproximadamente 70-100 personas):

2x TMG 2010 en NLB
1x Exchange 2010 CAS / HUB Rol
2x rol de buzón de Exchange 2010 (activo + pasivo)

APOYO a la ubicación (unas 20 personas):

2x TMG 2010 en NLB
1x Exchange 2010 CAS / HUB Rol
2x rol de buzón de Exchange 2010 (activo + pasivo)

La gerencia quiere asegurarse de que en caso de problemas en la ubicación principal (falla de energía, pérdida de enlace, etc.) la segunda ubicación pueda soportar todo el tráfico de todo el mundo y viceversa. Tenemos entre 6 y 7 ubicaciones y más por venir (no grandes, pero como 10+ personas por cada ubicación).

Sé que CAS / HUB es un único punto de falla (y no NLB), pero simplemente me faltan más licencias para hacer algo de redundancia en eso.

¿Qué opinas sobre este enfoque? ¿Cuál sería el mejor enfoque según usted?

exchange-2010 best-practices topology

— Chico loco
fuente

Esa configuración no me parece demasiado ridícula, y no cambiaría mucho. Supongo que se ha realizado todo el trabajo preparatorio (como múltiples sitios de Active Directory, controladores de dominio en cada sitio, etc.), por lo que no entraré en detalles sobre eso. Si puede estirar un poco su presupuesto, ajustaría un poco su topología CAS para eliminar el SPOF.

Puede instalar la función de transporte de concentradores en sus servidores de buzones y se cargarán automáticamente según el sitio de Active Directory en el que residan. Esa es una ganancia rápida y fácil, y no puedo ver esa razón para no hacerlo. .

Si su presupuesto puede acomodar 2 equilibradores de carga de hardware, también puede instalar la función CAS en los servidores de buzones. Luego crearía registros A en DNS para sus equilibradores de carga y configuraría las bases de datos de buzones apropiadas en cada sitio para utilizar la matriz CAS para el sitio.
Para hacer esto, emita el comando New-ClientAccessArray -Fqdn "ex-sitename-casarray.acme-widgets.com" -Site "AD-Site-MAIN"para cada sitio (reemplazando sus registros A y los nombres reales del sitio AD, según corresponda).
Luego emita Set-MailboxDatabase "<<Appropriate Database>>" -RpcClientAccessServer <<site-casarray-name.acme-widgets.com>>para asegurarse de que sus bases de datos de buzones de correo usen la matriz CAS.

Es mejor tener una copia local del buzón de un usuario en el mismo sitio que el usuario, por lo que crearía 2 bases de datos de buzón, cada una de las cuales se replicaría en un servidor de buzón en el mismo sitio, así como en el otro sitio (he hecho un diagrama para visualizarlo por ti). Para los usuarios en el sitio PRINCIPAL, guarde su buzón en la base de datos del buzón principal y para los usuarios en el sitio de APOYO, guarde sus buzones en la base de datos del buzón de soporte. texto alternativo

— Ben Pilbrow
fuente

No estoy realmente seguro de estar de acuerdo con su afirmación de que el servidor de buzones del usuario debe estar en el mismo sitio. Esto puede haber sido cierto hace 10 años, pero todas las versiones de Exchange a partir de 2003 admiten el modo en caché. Combine eso con la pequeña cantidad de usuarios en el sitio de soporte y dudo que alguien note una diferencia. Es mejor crear bases de datos basadas en factores distintos a la ubicación física. Los límites de almacenamiento, el nivel de clasificación, la necesidad de archivar o los objetivos de tiempo de recuperación se utilizan mejor para separar los buzones en las bases de datos.

— Jason Berg

Gracias por el comentario @ Jason Berg, agradezco su aporte. Si el sitio SUPPORT está listo para manejar el tráfico del sitio PRINCIPAL, supongo que el enlace WAN sería bastante bueno, por lo que sí, los usuarios probablemente no notarán una diferencia. La razón por la que expuse eso es simple, y es porque el instructor en mi curso de capacitación dijo que hiciera eso. Para ser honesto, fue más una pasada "cuando estás creando una base de datos de buzones, la pones en el mismo sitio que los usuarios" y luego pasó a otra cosa. No parecía una sugerencia estúpida, por lo que realmente no pensé nada más.

— Ben Pilbrow

TMG 2010 (nuevo ISA) tiene equilibrio de carga, por lo que no sería un gran problema, pero poner cada función en cada caja parece un poco exagerado. Sé que el rol de CAS es un SPOF y no estoy seguro de qué hacer con esto sin poner todo en una sola canasta. Estamos obteniendo las 6 licencias de la asociación de forma gratuita y tendremos que comprar algo de hardware, además de algunas CAL, así que no creo que mi cliente quiera pagar un precio adicional por eso. Pero me aseguraré de ponerlo en el documento para asegurarme de que entiendan los riesgos (es decir, el tiempo de inactividad).

— MadBoy

Si TMG puede equilibrar la carga de los servidores CAS, eso es genial (no pretendo saber nada sobre TMG). ¿Puedo preguntar por qué no te apetece poner todos los roles en todas las cajas, crees que habrá un gran éxito en el rendimiento? Sin tratar de sonar como un imbécil (realmente no quiero parecer así), en mi opinión, no existe la exageración: creas una solución más redundante, que es lo que buscas. ¿Podría sugerir poner el Hub Hub extra en 1 servidor de buzones y CAS en el otro para aligerarlo un poco? (Teniendo en cuenta que el CAS todavía necesita equilibrio de carga).

— Ben Pilbrow

También podría hacerlo 4 servidores en la ubicación principal y 2 con todos los roles en el otro con equilibrador de carga. Esto podría ofrecer una ubicación principal con libros de mejores prácticas y una ubicación de soporte con una solución todo en uno.

— MadBoy