Administración de Exchange en DAG
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
Sobre la Preferencia de activación
En la demo vemos como la preferencia de activación de una base en conjunto al script RedistributeActiveDatabases.ps1 nos sirve para balancear donde se encuentran montadas las bases de datos, la idea es que si tenemos muchas bases no queden todas montadas en un mismo servidor y de esta manera aprovechar mejor los recursos.
Nuevo a partir de Exchange 2016 CU2
Algo nuevo en este sentido con el CU2 de Exchange 2016 es que de forma automática cada 1 hora se balancea donde se encuentran activas las bases en función a como este configurada la preferencia de activación.
Por este motivo cada 1 hora vamos a ver que las bases se pueden «mover solas» (si no se encuentran montadas en el servidor «preferido»).
Si deseamos deshabilitar este comportamiento (de tal forma que sea manual el proceso), podemos ejecutar:
Set-DatabaseAvailabilityGroup -Identity DAG01 -PreferenceMoveFrequency ([TimeSpan]::Zero)
Respaldo de bases de datos
Para respaldar bases de datos podemos utilizar Windows Server Backup o podemos utilizar aplicaciones de terceros. El proceso es similar si el servidor se encuentra en alta disponibilidad o no, lo mismo a nivel de restauración.
En cuanto a aplicaciones de terceros, podemos encontrar algunas que requieren instalación de un agente a nivel de servidor con Exchange y otras que lo hacen a través del hipervisor sin instalar nada en el servidor (en caso de estar virtualizado). Si la herramienta permite respaldar desde la copia pasiva esto sería lo ideal.
La mayoría de las empresas utilizan aplicaciones de terceros para realizar respaldos, esto ofrece múltiples ventajas como por ejemplo administración centralizada, posibilidad de respaldar copias pasivas, simplicidad a nivel de restauración y en general flexibilidad si comparamos con las opciones que tenemos en Windows Server Backup.
Sin embargo si deseamos respaldar utilizando Windows Server Backup podemos hacer lo siguiente:
Instalar característica de Windows Server Backup
- Ir al servidor con Exchange
- Abrir el shell como administrador (Run As Administrator) y ejecutar:
Install-WindowsFeature Windows-Server-Backup
Realizar backup completo de las bases
- Abrir Windows Server Backup
- Ir a Local Backup – Backup Once
- En Backup Configuration, seleccionar Custom
- En Select items for backup hacer clic en Add items y seleccionar unidades de bases y logs
- En Advanced Settings – VSS Settings seleccionar VSS Full Backup
- En Specify Destination Type seleccionar Local Drive (o unidad de red)
- En Backup destination seleccionar la unidad para respaldos y avanzar hasta comenzar a respaldar
A tener en consideración si usamos Windows Server Backup:
- Los respaldos son a nivel de volumen (no de carpeta, es decir que debemos seleccionar los volumenes con bases y logs)
- Debemos tomar el respaldo donde se encuentra la base activa
- Los respaldos se hacen localmente y se puede respaldar a una unidad de red o un disco local
Resembrado de bases de datos
El resembrado de las bases implica copiar todo el archivo EDB y posteriormente replicar logs que puedan faltar. Para esto utilizamos el cmdlet Update-MailboxDatabaseCopy con el parámetro «DeleteExistingFiles» en $true.
Esto no es tan importante cuando tenemos los servidores en el mismo sitio, el tema es cuando los tenemos en sitios separados.
Si tenemos varios sitios conectados por enlaces lentos debemos tratar de mantener al mínimo el tamaño de las bases (o tener en cuenta alternativas en caso de un eventual resembrado).
Este es otro de los motivos por los que conviene tener múltiples bases «chicas» frente a pocas «grandes».
Qué pasa si por un tema de costos debemos usar la versión Standard de Exchange y estamos limitados a 5 bases de datos?
En este caso las bases van a ir creciendo y frente a la situación donde una copia en contingencia deba ser resembrada, hacerlo a través del enlace «lento» podría llevar horas, días e incluso directamente no poder hacerse por intermitencias en el enlace.
Esto me ha pasado en varias ocasiones.
Qué podemos hacer en este caso?
La solución más directa y sin impacto es la siguiente:
- Hacer un respaldo de la base de tipo copia. No «full» porque la idea es que no se eliminen los logs ya que posteriormente los vamos a precisar para resincronizar las diferencias.
- Llevar el respaldo a contingencia. En los casos que he tenido que recurrir a este método se han presentado ocasiones donde es tan simple como tomarse un taxi al sitio de contingencia con un disco externo, así como casos más complejos debido a las distancias, donde no queda otra que coordinar el envío por avión.
- Restaurar los datos en la ubicación original. Los archivos deben quedar en las mismas rutas configuradas originalmente.
- Suspender la réplica en contingencia. Para suspender la réplica usamos Suspend-MailboxDatabaseCopy. Esto lo hacemos para poder utilizar en el punto 5 el cmdlet para reanudar la replicación.
- Reanudar la réplica en contingencia. Una vez que el estado de la copia figure como suspendido, hacer Resume-MailboxDatabaseCopy. En este punto se reanuda la replicación de logs y se resincronizan las bases.
Algo importante dentro de todo este proceso es que hasta que no estén las réplicas sincronizadas no deberíamos hacer respaldo completo de la base.
De esta manera evitamos hacer el resembrado a través del enlace y lo único que tenemos que replicar son las diferencias desde que se tomó el respaldo hasta que se restauró la copia en contingencia.
Instalación de actualizaciones para Exchange en DAG
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
Sobre actualizaciones…
El tema de las actualizaciones en servidores en producción puede ser riesgoso. Han sido varias las ocasiones donde una actualización afecta la funcionalidad del producto o de alguna dependencia.
En general, salvo que una actualización aplique puntualmente a un problema que estemos teniendo no conviene aplicarla de forma inmediata. Lo ideal sería validar la instalación en algún tipo de ambiente de laboratorio, de esta manera reducimos el riesgo, el tema es que esto no aplica a la mayoría de los casos.
En este sentido, considerando las actualizaciones de Windows, no sería conveniente tratar Exchange como a otros servidores. En este caso la recomendación es instalar manualmente las actualizaciones con el servidor en modo mantenimiento. En adición, sería recomendable revisar las actualizaciones que se instalan, por ejemplo se ha dado de que una actualización al .Net Framework genere problemas en Exchange. La actualización era de Windows pero afectó a Exchange.
En cuanto a las actualizaciones específicas para Exchange, los Cumulative Updates (CU), estos son liberados aproximadamente cada 3 meses y para estar dentro de lo «soportado» debemos estar usando la última o penúltima versión. Muchos casos de soporte se resuelven simplemente actualizando el servidor.
Algunas cosas a tener en mente:
- La mayoría de los CU requieren primero extender el esquema o preparar de algún modo Active Directory. Esto requiere que en el primer servidor donde se corra la actualización se requieran permisos especiales como administrador de esquema (Schema Admin) y de empresa (Enterprise Admin). En los servidores siguientes ya no es necesario, incluso esta preparación puede ser ejecutada por separado
- Poner el servidor en modo mantenimiento e ir actualizando de a un servidor a la vez
- Recordar sacar el servidor del modo mantenimiento una vez finalizada la actualización