Exchange Server 2010. Implantación de infraestructuras altamente disponibles

1. Exchange Server 2010.Implantación de infraestructuras altamente disponibles Joshua Sáenz G. jsaenz@informatica64.com www.saenzguijarro.com

2. Contenido • Introducción a la alta disponibilidad • Retos aún existentes en Exchange Server 2007 • Novedades de alta disponibilidad en Exchange Server 2010 • Alta disponibilidad en el servidor de buzones • Alta disponibilidad en el transporte • Alta disponibilidad en el servidor de acceso de cliente • Planificación de la recuperación ante desastres • Prácticas recomendadas • Configuración de periodos de retención de buzones y mensajes • Planificación de copias de seguridad • Restauración de almacenes de datos y buzones • Herramienta Eseutil • Herramienta ISInteg

3. Introducción a la alta disponibilidad

4. Introducción a la alta disponibilidad en Exchange Server • Los sistemas de mensajería son componentes críticos en las organizaciones • Fallos de software, cortes de energía, errores de operación o desastres naturales afectan a la disponibilidad del sistema • La disponibilidad se refiere a un nivel de servicio proporcionado por aplicaciones, servicios o sistemas. • Los sistemas de alta disponibilidad tienen un tiempo de inactividad mínimo, ya sea previsto o imprevisto.

5. Introducción a la alta disponibilidad • La métrica empleada para medir la disponibilidad es el porcentaje de tiempo que un sistema es capaz de realizar las funciones para las que está diseñado. • Porcentaje de disponibilidad = (tiempo total transcurrido – suma del tiempo de inactividad)/tiempo total transcurrido • 99,9 % equivale a un tiempo de inactividad anual de 8,76 horas / año sobre una base de 24x7x365

6. Introducción a la alta disponibilidad • La alta disponibilidad se logra con el reforzamiento de estos componentes: • La tecnología • Las personas • Los procesos • Además de los niveles de disponibilidad, se debe tener en cuenta también el rendimiento y la escalabilidad del sistema.

7. Introducción a la alta disponibilidad • Se deben identificar claramente los objetivos de la alta disponibilidad para la organización • Se debe realizar un análisis de riesgos • Se deben establecer Acuerdos de Niveles de Servicio

8. Estrategias y escenarios de alta disponibilidad

9. Introducción a la alta disponibilidad • Para hacer que su organización de Exchange 2010 sea lo más tolerante a errores posible, debe reducir al mínimo los puntos únicos de error en su infraestructura de mensajería. • Se deben implementar medidas de tolerancia a errores en los niveles siguientes: • Medidas de sistema operativo y de aplicaciones • Medidas de nivel de componentes • Medidas de nivel del sistema

10. Retos aún existentes en Exchange Server 2007

11. Retos existentes en Exchange Server 2007 • Exchange Server 2007 redujo los costes de alta disponibilidad y de resistencia a nivel de sitio • Esto fue posible gracias a tecnologías como CCR o SCR • Sin embargo seguían existiendo algunos retos • Administradores intimidados por la complejidad de los servicios de clustering de Windows Server • Lograr un alto nivel de disponibilidad podría requerir mucha intervención del administrador • Cada tipo de replicación continua se gestionaba de forma separada y diferente • La característica «transportdumpster» del Hub, solo podía proteger los mensajes ante un fallo de entrega al servidor de buzones

12. Retos existentes en Exchange Server 2007 • Exchange Server 2007 en clúster requería de hardware dedicado • Solo el rol de servidor de buzones podía ser instalado en el nodo de un clúster • Para obtener una redundancia completa se necesitaban un mínimo de 4 servidores (2 HUB + CAS y 2 Mailbox) • El failover ocurría a nivel de servidor, por lo tanto si una base de datos fallaba, se tenía que mover todo el servidor a otro nodo. • Esto interrumpía el servicio temporalmente a todos los usuarios del servidor de buzones

13. Novedades de alta disponibilidad en Exchange Server 2010

14. Novedades de alta disponibilidad en Exchange Server 2010 • Exchange Server 2010 integra tecnología de alta disponibilidad en su propia arquitectura, utilizando una plataforma unificada. • Se ha rediseñado completamente teniendo como base el concepto de movilidad de base de datos.

15. Alta disponibilidad en el servidor de buzones

16. Alta disponibilidad en el servidor de buzones • Objetivos • Proporcionar una solución de alta disponibilidad y resistencia a nivel de sitio completamente integrada en Exchange. • Utilización de almacenamiento menos costoso y menos complejo • Simplificar la administración y reducir los costes de soporte • Incrementar la disponibilidad “end to end” • Soportar nativamente los servicios de Exchange 2010 Online

17. Alta disponibilidad en el servidor de buzones • Exchange 2010 combina CCR y SCR en una nueva solución denominada DAG (DatabaseAvailabilityGroup) • Despliegue incremental • Posibilidad de implantar bases de datos en un entorno altamente disponible después de que Exchange se haya instalado

18. Alta disponibilidad en el servidor de buzones • DatabaseAvailabilityGroups • Proporciona una recuperación automática a nivel de base de datos en vez de servidor. • Puede tener hasta 16 miembros y otros roles implantados como CAS, HUB o UM • Todas las réplicas se pueden copiar mediante VSS • Si una base de datos falla, Active Manager automáticamente seleccionará una copia pasiva y la activará

19. Alta disponibilidad en el servidor de buzones • Cambios en la arquitectura • Exchange Server 2010 ya no es una aplicación clusterizada (clusteraware) • Se eliminan los recursos de clúster y exres.dll • Las bases de datos no están vinculadas a un servidor • Cada servidor puede mantener hasta 100 bases de datos (Activas y pasivas) • Desaparecen los grupos de almacenamiento • La replicación de logs ya no utiliza SMB, ahora usa TCP (puerto 64327) y soporta cifrado y compresión de datos

20. Alta disponibilidad en el servidor de buzones • Active Manager • Remplaza el modelo de servicios utilizado en los clúster de Exchange 2007 • Corre en todos los servidores de buzones que son miembros de un DAG • Existen dos roles de Active Manager • Primary Active Manager (PAM). Responsable de monitorizar los cambios de topología. reaccionar ante fallos de servidor y seleccionar la base de datos óptima para un failover. • Standby Active Manager (SAM). Responsable de proporcionar información de que servidor tiene la copia activa de una base de datos a otros componentes como RPC Client Access o HubTransport Server

21. Alta disponibilidad en el servidor de buzones • Active Manager selecciona la mejor base de datos y la activa en caso de fallo • Ignora los servidores que no se pueden contactar o cuya activación está temporalmente bloqueada • Ordena las copias por nivel de actualización para minimizar la pérdida de datos • Utiliza el valor de preferencia de activación en caso de encontrar réplicas igualmente actualizadas • Selecciona de la lista ordenada la replica optima según el estado de copia

22. Alta disponibilidad en el servidor de buzones • Otras ventajas • Las copias soportan la configuración de ReplayLagTime hasta en 14 días • El tamaño máximo recomendado de la base de datos en alta disponibilidad se amplía de los 200GB hasta los 2TB • Se reduce el tiempo de failover desde 2 min. a 30 seg. aprox. • Este tamaño supone eliminar técnicas obsoletas de recuperación de bases de datos como copias de seguridad. • Las copias de seguridad se deben mantener por motivos legales, de almacenamiento a largo plazo o recuperación de elementos individuales.

23. Alta disponibilidad en el servidor de buzones • Consideraciones importantes de implantación de un DAG • Todos los servidores deben pertenecer al mismo dominio de Directorio Activo • Cada DAG debe disponer de una red MAPI y una red de replicación • DAG utiliza algunas funcionalidades de Windows FailoverClustering, por lo tanto solo se puede habilitar en servidores que ejecute Windows Server 2008 Enterprise Edition o DatacenterEdition • Windows Server 2008 debe tener instaladas las herramientas de administración de clustering • ServerManagerCmd –i RSAT –Clustering • Los DAG con miembros pares harán uso de un testigo (witness server) para alojar el recurso File Share Witness • Se recomienda que el testigo sea otro servidor Exchange • Si no es un servidor Exchange, hay que agregar el grupo Exchange TrustedSubsystem al grupo de Administradores locales.

24. Alta disponibilidad en el transporte

25. Alta disponibilidad en el transporte • Se logra con una combinación de redundancia de servidores, balanceo de carga y Round Robin de DNS • Para el transporte perimetral (EDGE) • Implantación de múltiples servidores • Creación de múltiples registros MX con diferentes prioridades para proporcionar failover • Configuración de NLB para proporcionar balanceo de carga activo • Configuración de Round Robin para proporcionar balanceo de carga pasivo

26. Alta disponibilidad en el transporte • Para el concentrador de transporte (HUB) • Implantación de múltiples servidores por cada sitio • Transporte de Hub a Hub (en la misma organización) • El algoritmo de transporte automáticamente balancea la carga entre los servidores disponibles • Transporte de Mailbox a Hub • El servicio Mail Submission automáticamente balancea la carga entre los servidores disponibles en el mismo sitio • Transporte UM a Hub • El servidor UM automáticamente balancea la carga entre todos los servidores Hub disponibles en el mismo sitio • Transporte Edge a Hub • Automáticamente se balancea la carga del correo entrante SMTP entre todos los servidores Hub del mismo sitio al cual está suscrito el servidor perimetral.

27. Alta disponibilidad en el transporte • Limitaciones en Exchange Server 2007 • Transport dumpster de Exchange 2007 no protege ante fallos en el transporte • Solo protege ante fallos de bases de datos replicadas. • Shadow Rendundacy se añade al Transport Dumpster para proteger los mensajes ante fallos del transporte. • La eliminación de un mensaje de la base de datos de transporte se retrasa hasta que el servidor de transporte verifica que se ha entregado correctamente el mensaje.

28. Alta disponibilidad en el Acceso de Clientes

29. Alta disponibilidad en el Acceso de Clientes • Se logra con balanceo de carga mediante NLB o hardware de terceros • Se debe implantar un CAS en cada sitio en donde haya un servidor de buzones. • Se recomienda que cada sitio tenga su propio espacio de nombres único

30. Planificación de copias de seguridad.

31. Planificación de copias de seguridad • Exchange 2010 introduce cambios sustanciales que hay que tener en cuenta desde el punto de vista de las copias de seguridad • Se eliminan los grupos de almacenamiento • Se remplazan los grupos de recuperación por bases de datos de recuperación • No están soportadas las copias de tipo streaming • Se incrementa el número máximo de BD por servidor hasta 100 • Se añade movilidad a las bases de datos y los grupos de disponibilidad • Cambia el lugar en donde se almacena la información de las bases de datos en el Directorio Activo • Desaparece el cluster de copia única(SCC) y la replicación local (LCR)

32. Planificación de copias de seguridad • Desaparecen comandos de PowerShell • ClusteredMailboxServer • Get-ClusteredMailboxServerStatus • Enable-DatabaseCopy • Restore-LocalDatabaseCopy • Enable/disable-LocalDatabaseCopy • Tareas de StorageGroupCopy • Comandos de Get-StorageGroupCopyStatus

33. Planificación de copias de seguridad • ¿Entonces que opciones tenemos?

34. Planificación de copias de seguridad • Exchange 2010 automáticamente registra el proveedor VSS cuando se instala tanto en Server 2008 como 2008 R2 • La funcionalidad de copia de Windows Server no permite seleccionar elementos de Exchange, por lo tanto se requiere hacer una copia del volumen completo • Una vez finalizada la copia completa, Exchange eliminará los ficheros .log

35. Planificación de copias de seguridad • Se debe ejecutar el proceso de copia en la base de datos activa y en local (no hay soporte remoto) • Durante la recuperación se puede seleccionar únicamente los datos de aplicación Exchange Más información: http://technet.microsoft.com/en-us/library/dd876874.aspx

36. Bases de datos de recuperación

37. Bases de datos de recuperación • Una base de datos de recuperación (RDB) es un tipo de base de datos de buzones que permite montar una base de datos de buzones restaurada y extraer los datos como parte del proceso de recuperación. • Remplaza a los antiguos grupos de recuperación. • Restaurar datos en una base de datos de recuperación puede hacerse de dos maneras: • Si ya existe una base de datos de recuperación, la aplicación puede desmontarla, restaurar los datos en una base de datos de recuperación y registrar los archivos para, a continuación, volver a montar la base de datos. • La base de datos y los archivos de registro se pueden restaurar a cualquier ubicación de disco. Exchange analiza los datos restaurados y reproduce los registros de transacción para actualizar la bases de datos; después, puede configurarse una base de datos de recuperación para que apunte a los archivos de base de datos que ya se han recuperado.

38. Bases de datos de recuperación • Una RDB se crea mediante el Shell de administración de Exchange. • No se puede enviar correo de o a una RDB. • Cualquier acceso de protocolo de cliente a una RDB (SMTP, POP3 y IMAP4) se bloquea. • El acceso de cliente MAPI mediante Microsoft Office Outlook o aplicación web de Outlook se bloquea. • El acceso MAPI se admite para una base de datos de recuperación, pero solo en el caso de aplicaciones y herramientas de recuperación. Debe especificarse tanto el GUID del buzón como el de la base de datos cuando se una MAPI para iniciar sesión en un buzón de una RDB. • Los buzones de una RDB no se pueden conectar a cuentas de usuario. • Para permitir que un usuario tenga acceso a los datos de un buzón de una RDB, el buzón debe combinarse con un buzón existente, o exportarse a una carpeta.

39. Bases de datos de recuperación • No se aplican las directivas de administración de buzones y del sistema. • El diseño evita que los elementos de una RDB puedan ser eliminados por el sistema durante el proceso de recuperación. • No se lleva a cabo un mantenimiento en línea para bases de datos de recuperación. • No se puede habilitar el registro circular para bases de datos de recuperación. • No se puede usar una RDB para recuperar datos de carpetas públicas. • Solo se puede montar una RDB en un servidor de buzones. • El uso de una RDB no incide en el límite de base de datos de 100 por servidor de buzones. • No se pueden crear copias de base de datos de una RDB. • Se puede usar una RDB como destino para operaciones de restauración, pero no para operaciones de copia de seguridad. • Una base de datos de recuperación que se monta como una RDB no está ligada de ningún modo al buzón original.

40. Bases de datos de recuperación • Se puede usar una RDB para recuperar datos en distintas situaciones, como las siguientes: • Recuperación de tonos de marcado del mismo servidor. • Recuperación de tonos de marcado del servidor alternativo. • Recuperación de buzón. • Recuperación de elementos concretos.

41. Crear una base de datos de recuperación • New-MailboxDatabase -Recovery -Name RDB1 -Server MBX2 • New-MailboxDatabase-Recovery -Name RDB2 -Server MBX1 -EdbFilePath "C:\Recovery\RDB2\RDB2.EDB" -LogFolderPath "C:\Recovery\RDB2"

42. Recuperación de buzones desde una RDB • Debe crearse una base de datos de recuperación • La base de datos y los archivos de registro que contienen los datos recuperados deben restaurarse o copiarse en la estructura de carpetas de la base de datos de recuperación que se creó cuando se creo la propia base de datos de recuperación. • Solo se puede utilizar para recuperar bases de datos de Exchange 2010 • La base de datos debe estar en un estado de cierre correcto. • Eseutil /mh «C:\Ruta\BaseDatos.mdb» | findstrstate • Eseutil /r E01 /a

43. Recuperación de buzones desde una RDB • Restore-Mailbox -Identity Scott -RecoveryDatabaseRDB1 • Restore-Mailbox -Identity Scott -RecoveryDatabase RDB1 -RecoveryMailbox John -TargetFolderRecovery • Restore-Mailbox-Identity Scott -RecoveryDatabase RDB1 -SubjectKeywords "Meeting" -ContentKeywords "Halo 3" -IncludeFolders \Inbox,\Calendar • La línea de asunto contiene la palabra "Meeting" (reunión) • El cuerpo del mensaje contiene la frase "Halo 3" • El mensaje está en la Bandeja de entrada o en la carpeta Calendario • Get-Mailbox -Database DB1 | Restore-Mailbox -RecoveryDatabaseRDB1 • Restaura todos los buzones de la base de datos de buzones DB1 que están también presentes en RDB1.

44. Portabilidad de bases de datos

45. Portabilidad de bases de datos • La portabilidad de bases de datos es una característica que permite que una base de datos de buzones de Microsoft Exchange Server 2010 se pueda mover o montar a cualquier otro servidor de buzones de la misma organización • Las bases de datos de buzones de correo de versiones anteriores de Exchange no pueden moverse a un servidor de buzón que ejecuta Exchange 2010

46. Portabilidad de bases de datos • Se confirman los archivos de registro • ESEUTIL /R <Enn> • Se crea una nueva base de datos en el nuevo servidor • New-MailboxDatabase -Name DB1 -Server MBX1 -EdbFilePath C:\Databases\DB1\DB1.edb -LogFolderPath C:\Databases\DB1 • Se habilita la restauración • Set-MailboxDatabase <DatabaseName> -AllowFileRestore:$true • Se mueven los archivos de la base de datos (archivo .edb, archivos de registro y catálogo de búsqueda de Exchange) a la ubicación correspondiente. • Se monta la base de datos • Mount-Database <DatabaseName> • Se actualiza la configuración de los buzones • Get-Mailbox -Database <SourceDatabase> |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database <TargetDatabase>

47. Planificación de la recuperación ante desastres • Qué necesitamos proteger de Exchange Server 2010: • Datos del servidor de buzón • Datos del servidor de transporte de concentrador • Datos del servidor de transporte de perímetro • Datos del servidor de acceso de cliente • Datos de los servidores de mensajería unificada • Datos de Active Directory • Datos del cliente

48. Datos del servidor del buzón

49. Datos del servidor de transporte de concentrador

50. Datos del servidor de transporte de perímetro