Hace una semana empezamos con el ciclo de conferencias técnicas de Exchange 2007. El jueves fue la primera, hicimos un overview. El martes siguiente Carlos Dinapoli y Leandro Amore indagaron un poco con Unified Messaging y Office Communications Server 2007.

En Septiembre se viene la tercer charla del ciclo de conferencias, se programó la charla para el lunes 3 de Septiembre a las 18:30, el título “Cómo Administrar Exchange 2007“.

Manténganse en sintonía que publicaré mayor información a la brevedad, mientras tanto agéndense el evento y chequeen frecuentemente el site: http://www.microsoft.com/argentina/technet/conferencias_tecnicas

Saludos,
Vernocchi Pablo.

 

Conociendo Exchange 2007
Fecha: 2 de Agosto . 18:30 hs.

Inscríbete aquí

Oradores:
Charly Dinapoli y Pablo Vernocchi

Lugar:
IT Training Center. Sarmiento 1113
Piso 3. Buenos Aires

Antispam

La solución antispam incluída con Exchange Server 2007 es implementada bajo el concepto de Transport Agents quienes se encargan del filtrado de los correos. Estos transport agents pueden estar configurados en el Edge Transport (habilitados por defecto) o en el Hub Transport (deshabilitados por defecto).

El filtrado del mensaje es acumulativo, evaluando las características de los mensajes entrantes, filtrando los considerados spam por los Transport Agents, o bien estampando un rating o SCL (Spam Confidence Level) en el header del mensaje que lo acompañará durante todo el proceso de routeo a lo largo de la organización.

El orden de aplicación de los Transport Agents puede graficarse de la siguiente manera:

Connection Filtering

1. El agente de filtro de conexiones examina la lista de direcciones IP permitidas definida por el administrador. Si la dirección IP del servidor remitente se encuentra en la lista de IP permitidas definida por el administrador, el mensaje se procesa mediante el Filtrado de remitentes.
2. El agente de filtro de conexiones examina la lista local de direcciones IP bloqueadas. Si la dirección IP del servidor remitente está incluida en esta lista, se rechazará automáticamente el mensaje y no se aplicará ningún otro filtro.
3. El agente de filtro de conexiones examina la lista de direcciones IP admitidas de todos los proveedores de listas de IP permitidas que tenga. Si la dirección IP del servidor remitente se encuentra en la lista de IP permitidas de los proveedores de listas de IP admitidas, el mensaje se procesa mediante el Filtrado de remitentes.
4. El agente de filtro de conexiones examina las listas de bloqueados en tiempo real (RBL) de cualquier proveedor de listas de direcciones IP bloqueadas que haya configurado. Si la dirección IP del servidor remitente está incluida en esta lista, se rechazará el mensaje y no se aplicará ningún otro filtro.

Sender Filtering

Una vez que se haya aplicado el filtrado de la conexión, Exchange 2007 examinará la dirección de correo electrónico del remitente con la lista de remitentes bloqueados que haya configurado en el filtrado de remitentes. El agente de filtro de remitentes examina la dirección de correo electrónico del remitente incluida en los campos del encabezado From: del mensaje. Si el campo del encabezado De: coincide con la dirección en la lista de remitentes bloqueados, Exchange 2007 rechaza el mensaje en el nivel de protocolo y no se aplican otros filtros.

Recipient Filtering

Si el filtrado de remitentes no rechaza el mensaje, Exchange ejecuta de nuevo el filtrado de conexiones. A continuación, Exchange aplica el agente de filtro de destinatarios. El agente de filtro de destinatarios examina el destinatario con la lista de destinatarios bloqueados que haya configurado el administrador. Si el destinatario deseado coincide con una dirección de correo electrónico de la lista de destinatarios bloqueados, se rechazará el mensaje para ese destinatario en concreto. Además, el agente de filtro de destinatarios comprueba si el destinatario está presente en la organización. Si no está presente, se rechaza el mensaje para este destinatario en concreto.

Sender ID Filtering

Si el mensaje contiene destinatarios válidos después de aplicar el filtrado de destinatarios, se ejecuta el filtro de Sender ID.

El agente del Id. del remitente determina la dirección del mensaje. Este paso es necesario para identificar con exactitud el remitente de los mensajes. A continuación, el agente realiza una búsqueda DNS por el dominio del remitente. Si ese dominio ha publicado el registro SPF (Sender Policy Framework), el agente utilizará el registro SPF para evaluar el mensaje de acuerdo con la especificación para RFC 4408. El resultado de la evaluación se marca en el mensaje en la marca de correo electrónico no deseado. Si ese dominio no tiene un registro SPF publicado, el agente marcará el resultado de “Ninguno” en el mensaje

Si el DNS del remitente proviene de un dominio bloqueado o de una dirección bloqueada, se realizarán la siguientes acciones dependiendo de la configuración de las acciones:

· Rechazar mensaje

· Eliminar mensaje

· Marcar el mensaje con el resultado del Id. del remitente y continuar con el proceso

Content Filtering

El agente de filtro de contenido comprueba las siguientes condiciones en el mensaje. Si se cumple alguna de las condiciones, el mensaje pasará por alto el filtrado de contenido y el filtrado de documentos adjuntos. A continuación, estos mensajes pasan al escaneo antivirus para procesarlos.

· La dirección IP del remitente se encuentra en la lista de IP permitidas para filtrado de conexiones.

· Todos los destinatarios se encuentran en la lista de excepciones para filtrado de contenido.

· El parámetro AntiSpamBypassEnabled está establecido en $True en todos los buzones de los destinatarios.

· Todos los destinatarios han agregado a este remitente a su lista de remitentes seguros de Outlook, que se actualiza en el servidor Edge Transport.

· El remitente se encuentra en la lista de remitentes de la organización que no se filtran.

Si un mensaje no cumple ninguna de las condiciones que se describen anteriormente, se aplicará el filtrado de contenido. El filtrado de contenido asigna una clasificación (rating) de SCL al mensaje. En función de la clasificación de SCL, tiene lugar una de las acciones siguientes:

· Si la clasificación de SCL del mensaje es mayor o igual al umbral de eliminación de SCL y este umbral está habilitado, el agente de filtro de contenido eliminará el mensaje. Si la clasificación de SCL es inferior al valor de umbral de eliminación de SCL, el agente de filtro de contenido no eliminará el mensaje, y se comparará el valor de SCL y el umbral de rechazo de SCL.

· Si la clasificación de SCL del mensaje es mayor o igual al umbral de rechazo de SCL y este umbral está habilitado, el agente de filtro de contenido rechazará el mensaje y enviará una respuesta de rechazo al sistema remitente. Si la clasificación de SCL es inferior al valor de umbral de rechazo de SCL, se comparará el valor del nivel de confianza de correo no deseado con el umbral de cuarentena del nivel de confianza de correo no deseado.

· Si la clasificación de SCL del mensaje es mayor o igual al umbral de cuarentena de SCL y este umbral está habilitado, se enviará el mensaje al buzón de cuarentena de correo electrónico no deseado.

Attachment Filtering

El filtrado de documentos adjuntos bloqueará en función del tipo de contenido MIME, el nombre de archivo o la extensión del nombre de archivo. Si el filtrado de documentos adjuntos detecta un tipo de contenido de nombre de archivo que se ha bloqueado, tendrá lugar una de las acciones siguientes:

· Reject, no se entregará ni el mensaje de correo electrónico ni el documento adjunto al destinatario y el sistema generará un mensaje de error al remitente.

· Silent Delete, no se entregará ni el mensaje de correo electrónico ni el documento adjunto al destinatario. No se notifica al remitente que se ha bloqueado el mensaje de correo electrónico y el documento adjunto.

· Strip, el documento adjunto se seccionará del mensaje de correo electrónico. Se agregará una notificación de que el documento adjunto está bloqueado al mensaje de correo electrónico del destinatario.

Antivirus Scanning

Una vez que se haya aplicado el filtrado de documentos adjuntos, o si se han pasado por alto los destinatarios en el filtrado de contenido, se aplicará la exploración antivirus instalado en el sistema. El proceso de escaneo y las acciones a tomar dependen del vendor del producto.

Outlook Junk E-mail Filtering

Si la clasificación de SCL para el mensaje es mayor o igual al umbral de la carpeta de correo electrónico no deseado de SCL y este umbral está activado, el servidor del buzón colocará el mensaje en la carpeta de correo electrónico no deseado (Junk E-Mail) del usuario. Si el valor de SCL de un mensaje es inferior a los valores de umbral de eliminación, rechazo, cuarentena y carpeta de correo electrónico no deseado de SCL, el servidor del buzón colocará el mensaje en la Bandeja de entrada.

Saludos,
Vernocchi Pablo

STAND BY CONTINUOS REPLICATION en Exchange 2007 con SERVICE PACK 1

Standby continuous replication (SCR) es una nueva característica que esta siendo introducida en SP1 de Exchange 2007

SCR esta diseñado para escenarios que se usan servidores de recuperación en espera. SCR extiendo la característica existente de replicación y habilita a un escenario nuevo de alta disponibilidad de Exchange 2007 para servidores de casillas. SCR usa el mismo log shipping y replay de logs como local continuos replication (LCR) y CCR para proveer un agregado en las opciones de implementación y configuración.

SCR es muy similar a LCR y CCR, pero tiene características únicas:

• SCR suporta multiples destinos por Grupo de almacenamiento. LCR y CCR soporta solo una replicación destino por Grupo de Almacenamiento.
• SCR incluye configurar un delay en la actividad de replicación y permite habilitar al administrador para especificar una delay adicional. Esto tiene una variedad de escenarios por ejemplo en la corrupción lógica de una base de datos activa el delay en la copia podría prevenir la corrupción lógica en la copia de la base en el destino.
• En la version RTM de Exchange 2007, las reglas fueron enfocadas a que en escenarios de CR los archivos de log no fueran borrados a menos y hasta que haya sido realizado un backup y se hayan replicado dentro de la base de datos de Copia. Esta regla fue modificada en SCR ya que permite que los Logs sean depurados desde el SCR origen tan pronto como fueron inspeccionados por todos las maquinas SCR destino.
• Depuración de Logs en SCR no espera hasta que todos los logs hayan sido copiados en todos los SCR destino.

SCR habilita una separación de alta disponibilidad, Por ejemplo SCR puede ser combinado con CCR para replicar Grupos de almacenamiento localmente en un Datacenter Primario y remotamente en un Datacenter de contingencia. El datacenter de contingencia podría contener un nodo pasivo.

SCR destino puede estar alojado en un standy-by Cluster que puede ser rápidamente activado:

· Al usar Restore-StorageGroupCopy, el cual trata de copiar cualquier archivo faltante desde un SCR origen.

· Al usar Setup /RecoverCMS para implementar un reemplazo del Mailbox Custerizado en el Standby Cluster.

SCR Origen y destino

Como con LCR y CCR, SCR usa el concepto de copias activas y pasivas del Grupo de almacenamiento y al igual que CCR, SCR requiere que los paths de la base de datos y logs sean los mismos en el origen y destino. Esto es a causa que SCR extiende el escenario soportado por LCR y CCR, SCR introduce el concepto de origen y destino.

Comenzando por SCR llamado destino, el cual cualquier Grupo de almacenamiento, excepto RSG para cualquiera de las siguientes:

• Un servidor de casillas stand-alone (con o sin LCR habilitado).
• Un Servidor de casilla en un SCC.
• Un servidor de casillas en un entorno de CCR.

Como con LCR y CCR, no se puede habilitar SCR para más de una base de datos por Grupo de almacenamiento, tampoco se puede habilitar SCR para un Grupo de almacenamiento que contenga más de una base datos. Tampoco se puede agregar una segunda base de datos a un Grupo de almacenamiento habilitado para SCR.

El servidor destino o “target” puede ser uno de los siguientes:

• Un servidor stand-alone (sin LCR habilitado para cualquier Grupo de almacenamiento)
• Un nodo en Failover Cluster donde el rol de Mailbox Server esta instalado, pero no ha sido configurado en el Cluster.

Requerimientos para SCR Targets o Destino

Los servidores destino deben esta en el mismo dominio de AD, pero pueden estar ubicados en la misma subnet de AD u en otro Site de AD.

Cada Target puede tener múltiples servidores de origen, ambos el origen y destino deben tener SP1 de Exchange 2007. El OS debe ser cualquier OS soportado por SP1 de Exchange 2007. Los paths de las bases de datos y logs en el origen y en todos los destinos deben ser iguales en todos los Grupos de almacenamiento que están siendo replicados con SCR. Si ambos paths, incluyendo letras de disco no concuerdan no será capaz de habilitar SCR.

 

Links Recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 4
Opciones de alta disponibilidad para Exchange 2007 – parte 3
Opciones de alta disponibilidad para Exchange 2007 – parte 2
Opciones de alta disponibilidad para Exchange 2007 – parte 1

 

Carlos Dinapoli – Microsoft Exchange MVP – MCSE 2003 Messaging

Bienvenidos a la parte 4 de esta nota. En esta oportunidad discutiremos sobre Single Copy Cluster (SCC).

Al igual que las versiones anteriores de Exchange esta solución permite utilizar servidores de casillas agrupados usando un almacenamiento compartido (SAN) para permitir que varios servidores accedan a ese almacenamiento. Esta solución es muy parecida a las características de versiones anteriores de soluciones de Cluster. Se han realizado algunas modificaciones y mejoras.

Single Copy Cluster de ahora en adelante mencionado como SCC requieren el uso de una arquitectura “Sharing nothing” la cual incluye el almacenamiento compartido de disco. En esta arquitectura aunque todos los nodos de un Cluster pueden tener acceso a datos compartidos no pueden tener acceso a ellos al mismo tiempo. Ejemplo si un recursos de disco esta asignado al servidor 1 de un cluster de dos nodos, el servidor 2 no puede tener acceso al recurso de discos hasta que el servidor 1 termina la sesión o Libera el recurso o tiene un error para de esa forma pasar al servidor 2.

 

En SCC un servidor de casillas usa su propia identidad de red no la identidad de un nodo en el cluster. Este nombre de red se llama Servidor de casillas en Cluster. Si el server que ejecuta un servidor de casillas en cluster experimenta problemas, el servidor de casillas agrupado se desconecta durante un corto tiempo hasta que el otro servidor asume el control del servidor agrupado y lo conecta. El almacenamiento que tiene los Storages Groups del servidor en Cluster y las bases de datos se alojan en la SAN disponible a cada servidor posible. Mientras ocurre la conmutación por error el almacenamiento asociado a las casillas en Cluster detecta lógicamente desde el servidor y pasa el control al otro servidor disponible en el Cluster.

Además de la conmutación por error el Administrador puede mover manualmente el control a otro servidor que compone lógicamente el Cluster . Este proceso se conoce como Move Group. Esta operación solo se puede hacer con cmdlet llamado Move-ClusteredMailboxServer.

NOTA: A pesar que desde la herramienta del Cluster Administrator esta disponible esta operación, la misma no es consiente de Exchange por lo tanto no debe usarse para mover los Grupos de Exchange o cambiar el estado de cualquier de los servidores que pertenecen al Cluster.

Servicio de Cluster de Windows

Para crear un SCC Exchange 2007 usa el servicio de Windows. El servicio de Cluster de Windows es una característica que viene en la versión Enterprise de Windows Server 2003. Este es un componente que controla todos los aspectos de los recursos agrupados. Cuando se ejecuta el programa de instalación de Exchange 2007 en un nodo de un Cluster de Windows Server 2003, la versión compatible con Cluster de Exchange se instala automáticamente. Un servidor de casillas de correo contiene los siguientes componentes:

· Almacenamiento compartido: Exchange 2007 es compatible con Cluster de almacenamiento compartido y cluster de almacenamiento no compartido. Los Cluster de Copia única (SCC) usan almacenamiento compartido. Para ver soluciones de Exchange 2007 con almacenamiento no compartido ver la sección de CCR (Cluster Continuos Replication).

· Recurso de DLL: Windows se comunica con los recursos mediante las .dll de recursos. Exchange proporciona su propia DLL de recursos (llamada EXRES.DLL) para comunicarse con el servicio de Cluster de Windows. La comunicación entre el Servicio de Cluster de Windows y Exchange 20076 se personaliza para ofrecer funcionalidad de Cluster.

· Grupos: Exchange 2007 utiliza grupos de Cluster de Windows para incluir y representar un servidor de casillas de Cluster. Un servidor de casillas de Cluster es un Grupo de cluster de Windows que incluye recursos de Cluster como una dirección IP, uno o mas discos físicos, el recurso de System Attendant y otros recursos de Windows.

· Recursos: Los servidores de casillas en Cluster incluyen recursos como recursos de direcciones IPS, recursos de nombre de red y recursos de discos físicos. Los servidores de buzón en Cluster también incluyen sus propios recursos específicos de Exchange. Al crear un servidor de casilla en Cluster, Exchange crea automáticamente los demás recursos específicos de Exchange fundamentales como information Store y la instancia de base de datos.

Implementación de SCC

La implementación de un Cluster de copia única es muy parecida a la implementación de un servidor de Exchange independiente y a la implementación de CCR. Existen algunas diferencias significativas que deben tenerse en cuenta en la implementación.

Requisitos para SCC

Los requisitos de los SCC para implementaciones son los siguientes:

· Chequear que se este ejecutando DNS. El mismo debería admitir actualizaciones dinámicas, mas información en 322856 de la Knowledge Base Microsoft, Cómo configurar DNS para utilizar con Exchange Server..

· Todos los nodos del clúster deben ser servidores miembros del mismo dominio. Exchange 2007 no es compatible en nodos que también sean servidores Active Directory o nodos que sean miembros de dominios Active Directory diferentes.

· El clúster en el que está instalado Exchange 2007 no puede contener Exchange Server 2003, Exchange 2000 Server o cualquier versión de Microsoft SQL Server. No se admite ejecutar Exchange 2007 en un clúster con cualquiera de estas aplicaciones.

· Antes de instalar Exchange 2007, asegúrese que la carpeta en la que va a instalar todos los datos de Exchange en el recurso de disco físico está vacía.

· La cuenta de servicio de clúster debe ser miembro de los administradores de Exchange Server (ServerName) o del grupo de administradores de la organización de Exchange. Además, debe ser miembro del grupo local de administradores en cada nodo que pueda hospedar un servidor de buzones de correo en clúster.

Requisitos de Software

Los requisitos de software de los SCC para implementaciones son los siguientes:

• Todos los nodos del clúster deben tener instalada Microsoft Windows Server 2003, Enterprise Edition en cada nodo del clúster utilizando las mismas letras de unidad de sistema y de inicio.
• Sólo se puede instalar la función del servidor casillas de correo en un clúster. No se pueden instalar más funciones de Windows Server en un equipo que forme parte de un clúster.

Requisitos de Red para SCC

Es importante que las redes que se utilizan en las comunicaciones de los clientes y los clústeres estén configuradas correctamente. Además, debe asegurarse de que el orden de conexión de red esté configurado correctamente para el clúster.

Tener en cuenta lo siguiente a la hora de diseñar la infraestructura de red para la implementación de SCC:

• Cada nodo debe tener, al menos, dos adaptadores de red disponibles para la creación de clústeres con Windows. Los clientes y otros servidores sólo deben tener acceso a los nodos desde uno de los adaptadores de red. Los otros adaptadores de red se utilizan para la comunicación dentro del clúster.
• Disponer de un número suficiente de direcciones IP estáticas al crear servidores de casillas en clúster en una configuración de replicación SCC de dos nodos. Se requieren direcciones IP tanto para redes públicas como privadas. Los requisitos relacionados con las direcciones privadas y públicas son las siguientes:
  • Direcciones privadas Cada nodo requiere una dirección IP estática para cada adaptador de red que se utiliza en una red de clústeres privada. Deben usar direcciones IP estáticas que no estén en la misma subred o red que una de las redes públicas. Se recomienda usar 10.10.10.10, 10.10.10.11 y 10.10.10.12 con una mascara de subred de 255.0.0.0 como direcciones IP privadas para los tres nodos, respectivamente. Si la red pública utiliza una red 10.x.x.x y una máscara de subred 255.0.0.0, se recomienda utilizar direcciones IP de redes privadas alternativas y una máscara de subred. Si configura más de una red privada, se necesitan direcciones y subredes únicas para cada adaptador de red y red privada.
  • Direcciones públicas Cada nodo requiere una dirección IP estática para cada adaptador de red que se utiliza en una red de clústeres pública. Además, se requieren direcciones IP estáticas para el clúster del servidor y el servidor de buzones de correo en clúster para que clientes y administradores puedan tener acceso a ellos. Debe usar direcciones IP estáticas que no estén en la misma subred o red que una de las redes privadas.
• La red privada para todos los nodos de un clúster debe estar en la misma subred, pero puede usar modificadores de LAN virtual (VLAN) en las interconexiones entre dos nodos. Si usa una VLAN, la latencia punto a punto de ida y vuelta debe ser menor de 0,5 segundos. Además, el vínculo entre dos nodos debe aparecer como una única conexión punto a punto desde la perspectiva del sistema operativo Windows que se está ejecutando en los nodos. Para evitar errores puntuales, utilice hardware de VLAN independiente para las diferentes rutas de acceso entre los nodos.
• La red de clúster pública debería proporcionar conectividad a los otros servicios y servidores de Exchange, como Active Directory y DNS.
• Se debe proporcionar una red en clústeres privada separada. La red privada se utiliza para la comunicación de clúster. Esta red puede estar localizada en equipos del clúster y no necesita servicios de DNS.
• El orden de enlazado de la red en clústeres y la prioridad de la red deben estar configurados correctamente.
• Es posible que los requisitos de comunicación no sean los más estrictos de ancho de banda de red pública y de latencia para la configuración de centro de dos datos. Se debe evaluar la carga de red total que incluye cliente, Active Directory, transporte y otro tráfico para determinar los requisitos de red necesarios.

Requisitos de almacenamiento

Un SCC utiliza almacenamiento compartido para el disco de quórum y para almacenar los datos de servidor de casillas en clúster (grupos de almacenamiento y bases de datos). Este almacenamiento se debe configurar antes de la formación del clúster en cada nodo que sea parte del clúster.

Si el almacenamiento se configura correctamente antes de la formación de clúster, la instalación se simplifica ya que los discos se detectan automáticamente y se incorporan al modelo de recurso.

Es obligatorio que el quórum esté configurado y disponible para todos los nodos del clúster después de la formación del clúster. La formación del clúster dará error si el disco compartido de quórum no está disponible.

Cuando se diseña una solución de almacenamiento de SCC , es aconsejable que siga las siguientes prácticas recomendadas:

• Almacenar los archivos de base de datos y los de registros de transacciones en diferentes números de unidad lógica (LUN).
• Utilizar los “Volume Mount Point” del sistema de archivos NFTS para sacar a la superficie los volúmenes del sistema operativo. Esto permitirá ahorrar cantidad del letras lógicas en el Sistema Operativo.
• Utilizar nombres característicos que se puedan relacionar de forma directa y obvia con la base de datos o el grupo de almacenamiento.

Requisitos de Active Directory

SCC tiene los mismos requisitos de infraestructura de Active Directory que un servidor independiente. En una solución de múltiples centros de computos, los dos centros de datos deben tener una compatibilidad adecuada con la infraestructura de Active Directory, ya que alguno de los centros de datos podría hospedar el servidor de casillas de correo en clúster. Esta capacidad debe estar presente incluso si los otros centros de datos no están disponibles. Además, todos los nodos del clúster deben estar en el mismo dominio y la cuenta del servicio de Cluster Server debe tener los permisos adecuados.

Requisitos de Cuenta de servicio

El servicio de clúster de Microsoft Windows Server 2003 se ejecuta bajo una cuenta de usuario de dominio con algún privilegio administrativo de Exchange. La cuenta de servicio de clúster debe tener privilegios de administrador local en los nodos del clúster y privilegios para montar bases de datos de Exchange. Puede establecer esos permisos creando una cuenta de usuario de dominio y dándole los suficientes privilegios para cada servidor de buzones en clúster. Dar a la cuenta privilegios de administrador de Exchange Server será suficiente para este propósito.

NOTAS IMPORTANTES: Debe usar una cuenta del dominio para la cuenta del Servicio de Cluster. Todos los nodos del cluster deben ser miembros del mismo dominio y todos los nodos del clúster deben usar la misma cuenta de servicio Cluster Server.

El grupo de administradores de Exchange Server para un servidor de casillas de correo en clúster se crea durante el proceso de instalación, Por lo que será necesario completar la instalación antes de que la cuenta de servicio de clúster se pueda restringir a esos privilegios. Por lo tanto, puede alterar los privilegios en la cuenta de servicio de clúster.

Si la cuenta de servicio no tiene suficiente derechos para montar bases de datos, el proceso de instalación dará error al montarlas.

Links Recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 3
Opciones de alta disponibilidad para Exchange 2007 – parte 2
Opciones de alta disponibilidad para Exchange 2007 – parte 1

 

Carlos Dinapoli – Microsoft Exchange MVP – MCSE 2003 Messaging

Microsoft lanzó el rollup 3 de Exchange 2007. Este rollup contiene los dos anteriores y agrega:

• 931328 (http://support.microsoft.com/kb/931328/) An integer is added to the end of the legacyExchangeDN attribute of a newly created mailbox in Exchange 2007.
• 930468 (http://support.microsoft.com/kb/930468/) The attachment is not displayed when you use Outlook 2003 to open an e-mail message that contains an attachment.
• 931842 (http://support.microsoft.com/kb/931842/) Error message when the sender or the receiver of a meeting request has a double-byte character set (DBCS) display name in Exchange Server 2007: “The requested property was not found”.
• 932207 (http://support.microsoft.com/kb/932207/) Error message when a user tries to open a forwarded message to accept or to deny a resource request in Exchange Server 2007: “Cannot open the free/busy information”
• 932515 (http://support.microsoft.com/kb/932515/) You receive a 5.2.0 non-delivery report (NDR) message when you send an e-mail message to an Exchange 2007 server that is running the Isinteg.exe tool in a dismounted mailbox store.
• 934887 (http://support.microsoft.com/kb/934887/) DBCS characters are converted into two question marks in a forwarded e-mail message in Exchange 2007.

Links:

Description of Update Rollup 3 for Exchange 2007

Download Update Rollup 3 for Exchange Server 2007

 

Saludos,
Vernocchi Pablo

Como tercera parte, cubriremos Cluster Continuous Replication (CCR). Para simplificar el término, CCR es un LCR pero en otro nodo pasivo que, cuando el activo falla traspasa los recursos al nodo pasivo, através de los servicios de Cluster de Windows.

CCR combina la tecnología de Log Shipping y Log Replay con el servicio de Windows Cluster para brindar una solución que:

• No tiene un punto de fallas único
• No tiene requerimientos especiales de Hardware
• Puede ser configurado en uno o dos datacenters distintos
• Al igual que LCR, reduce la frecuencia de backups.

Al configurar CCR, la primer operación que ocurre se denomina seeding que, básicamente, copia la base de datos del Storage Group al nodo pasivo. Luego que esta operación finaliza, se comienzan las de Log Replay. El comando de PowerShell involucrado en el falivoer es Move-ClusteredMailboxServer. Este cmdlet hace verificaciones para asegurar que el nodo pasivo está listo para recibir los recursos.

CCR combina las siguientes tecnologías para hacer este servicio posible:

• Failover y virtualización provista por el servicio de Windows Cluster.
• Transaction Log Replay y Log Shipping de Exchange Server 2007.
• Una cola de mensajes del Hub Transport llamada Transport Dumpster.

Como la siguiente figura grafica, CCR requiere dos equipos o nodos unidos a un mismo cluster. Estos nodos alojan las bases de datos de buzones, clusterizadas.

 

El cluster utiliza la tecnología ya conocida del servicio de Cluster de Windows, pero agrega una novedad a nivel Quorum. En vez de usar un recurso de cluster, utiliza una nueva tecnología denominada Majority Node Set (MNS) quorum with file share witness.

CCR usa un “testigo” o file share witness en un tercer equipo fuera del cluster, utilizado por los nodos para hacer un seguimiento de cuál nodo tiene el control de los recursos del Cluster. Este recurso es sólo utilizado cuando los nodos pierden comunicación entre ellos, siendo innecesario cuando éstos pueden interactuar entre ellos e intercambiar esta información. El testigo es utilizado cuando:

• Un nodo del cluster se inicia y sólo un nodo es el activo.
• Existe un problema en la red que evita que los nodos se intercomuniquen.
• Un nodo del cluster es quitado.
• Periodicamente para validación. La frecuencia es configurable.

La carga en el File Server que aloja el “testigo” es muy poca.

Requerimientos

Existen ciertas consideraciones a tener en cuenta antes de implementar este tipo de soluciones:

• Se debe utilizar una sóla base de datos por Storage Group.
• Si se cuenta con un sólo servidor de Maiblox en la organización y está en un ambiente de CCR, el servidor puede contener un almacén de Carpetas Públicas. En esta configuración, existe una única base de datos de Public Folders, por lo tanto la replicación está deshabilitada.
• Si se tienen varios Mailbox Servers, y sólo uno tiene una base de Public Folders, esta base puede estar alojada en un CCR. En esta configuración, existe una única base de datos de Public Folders, por lo tanto la replicación está deshabilitada.
• Si más de un Mailbox Server tiene bases de datos de Public Folders, y la replicación está habilitada, las Public Folders no pueden estar alojadas en un CCR.
• Todos los nodos del cluster deben pertenecer al mismo dominio de Active Directory.
• Exchange Server 2007, en CCR, no está soportado si el servidor es también Domain Controller.
• Asegurarse que el cluster sea configurado antes de instalar Exchange Server 2007.
• No pueden existir otras aplicaciones instaladas en los nodos que utilicen el cluster (cluster-aware), como SQL Server o Exchange Server 2000 / 2003. Sí está soportado, por ejemplo, que el nodo corra SQL Server 2005 Express, sin clusterizar.
• Se debe instalar la misma versión de Exchange Server 2007 en todos los nodos pertenecientes al cluster. Adicionalmente, el Sistema Operativo y los binarios de Exchange deben estar instalado en los mismos path y unidades en ambos nodos.
• La cuenta de servicio de Cluster debe ser miembro del grupo Administradores local de cada nodo.

Requerimientos de Software

• Todos los nodos en el cluster deben correr Windows Server 2003 Enterprise, utilizando las mismas unidades para el sistema y booteo.
• El cluster debe tener instalado el fix 921181 
• La carpeta compartida para el quorum de MNS no necesariamente tiene que ser un equipo dedicado. En un ambiente con delegaciones de administración, la recomendación es que el quorum resida en un Hub Transport u otro servidor de Exchange, para que pueda ser controlada por un Administrador de Exchange.
• En CCR sólo se puede instalar el rol de Mailbox Server. No se puede compartir ningún otro rol.

Requerimientos de Red

• Cada nodo debe contar con, al menos, dos interfaces de red disponibles para el servicio de Windows Cluster. Una interfaz será pública, y la otra para las comunicaciones intra-cluster.
• Cada nodo requiere una dirección ip estática para cada uno de los adaptadores que serán utilizados por el servicio de cluster. Las direcciones de los adaptadores no pueden estar en la misma subnet.
• Las interfaces privadas (comunicación intra-cluster) deben estar en la misma subnet.
• Las interfaces públicas deben estar en la misma subnet.

 

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 1
Opciones de alta disponibilidad para Exchange 2007 – parte 2

Saludos,
Vernocchi Pablo

Siendo la primer opción en la parte 1 de esta serie de notas, nos centraremos en LCR (Local Continuous Replication).

LCR es una solución que involucra un sólo servidor y hace uso de la tecnología de Log Shipping y Log Replay built in en Exchange 2007 para crear y mantener actualizada una copia de un Storage Group determinado en un segundo set de discos, conectados al mismo servidor.

Esta tecnología podría graficarse de la siguiente manera:

 

LCR nos da la posibilidad de, manualmente, switchear a la copia pasiva de las bases de un Storage Group determinado ante una fatalidad. Esta tecnología fue básicamente diseñada para:

• Reducir considerablemente el tiempo de recuperación por un error a nivel datos.
• Reducir el número de full backups requeridos para una óptima protección de la información.
• Reducir el impacto de backups en el rendimiento del servidor. Todos los tipos de backups (full, incremental, diferencial y copia) pueden ser tomados de la copia pasiva del Storage Group.

Cuando sea necesario la copia local del Storage Group pasivo puede convertirse en la productiva. LCR no tiene requerimientos específicos de Storage, todos los medios soportados sirven.

LCR es la opción ideal para aquellas empresas o redes que necesitan soluciones de Disaster Recovery rápidas ante fallas o corrupción en los buzones.

Aunque LCR provea ciertas ventajas ante un backup tradicional, no provee una disponibilidad completa. Básicamente porque reside en un mismo servidor, y lo único que lo separa de la base productiva es subsistema de discos distintos.

LCR será la primer barrera ante una falla en la base de datos productiva y un recovery generalmente toma unos 10 minutos únicamente. Teniendo este tiempo de restore tan bajo, podemos empezar a pensar en cuotas de buzones mucho mayores.

Requerimientos

LCR tiene algunos requerimientos de storage y recomendaciones. Justamente una de las recomendaciones es que el storage que almacenará la copia pasiva sea de la misma capacidad y mismo rendimiento que el de la copia activa. Alguna de las mejores prácticas incluyen:

• Utilizar una sola base de datos por Storage Group. Cuando se habilita LCR en un Storage Group, éste sólo puede contener una sóla base de datos.
• No se podrá utilizar LCR en Public Folders si existe más de una base de datos de Public Folders en la organización, debido a la replicación.
• Particiones para rendimiento y recuperación. Generalmente particionando los discos se obtiene un rendimiento mayor y menor volúmen de datos a restaurar. Debería usarse discos y particiones diferentes para:
  • Archivos del sistema operativo
  • Archivos de aplicación de Exchange
  • Bases de datos activas de Exchange
  • Transaction logs activos de Exchange
  • Bases de datos pasivas de Exchange
  • Transaction logs pasivos de Exchange
  • Adicionalmente, los discos de las copias activas y pasivas deberían estar aislados unos de otros.
• Asegurar espacio libre adecuado.
• Asegurar memoria RAM y CPU adecuados para LCR.

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 1
Opciones de alta disponibilidad para Exchange 2007 – parte 3

Saludos,
Vernocchi Pablo

Es, quizás, uno de los requerimientos más solicitados por todos. Tener una alta disponibilidad de servicio de correo y con menor costo. No todas las organizaciones están preparadas para afrontar los costos asociados con las opciones de alta disponibilidad que ofrecen las versiones anteriores de Exchange, por lo tanto en esta nueva versión se establecen nuevas.

• La primer opción se llama Local Continuous Replication (o LCR). Esta solución implica un sólo servidor que usa tecnología de Log Shipping para crear y mantener una copia de un Storage Group en un segundo set de discos, que están conectados al mismo servidor que el Storage Group. LCR provee log shipping, log replay y la posibilidad de switchear rápidamente a la copia de la base.
• La segunda opción es Cluster Continuous Replication (CCR). Es una solución de cluster que utiliza la misma tecnología de log shipping que LCR, pero el Storage Group se mantiene en un servidor separado. CCR fue diseñado para estar en el mismo datacenter o en uno remoto, brindando no sólo alta disponibilidad de hardware sino también de sitios.
• Por último tenemos Single Copy Cluster (SCC). Es una solución de cluster que usa una sóla copia del Storage Group en un storage compartido entre los nodos del cluster. SCC es muy similar a las opciones de cluster de las versiones anteriores de Exchange, con algunos cambios y mejoras.

Tanto CCR como SCC son soluciones que se aplican a cluster con failover. Sólo el rol de Mailbox Server puede ser instalado en esos servidores. Todas las opciones de alta disponibilidad de los roles restantes se pueden obtener con una combinación de redundancia de servidores, Network Load Balancing o DNS Round Robin.

Próximamente estaremos viendo en detalle cada uno de las opciones.

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 2
Opciones de alta disponibilidad para Exchange 2007 – parte 3

Vernocchi Pablo.

En el “Exchange Blog Latino” se publicaron nuevos documentos de Exchange 2007 para el mes de junio.

Link to Nuevos documentos de Exchange Server 2007 – Junio – Exchange Blog Latino

Vale la pena pegarles una leída.

Saludos,
Vernocchi Pablo