Exchange 2013. Principios de Diseño (1)

Exchange 2013 14 junio 2014 | 0 Comments

Siguiendo los dos post anteriores:

Exchange 2013: Disponibilidad y fiabilidad (Conceptos)

Exchange 2013: Disponibilidad y fiabilidad (conclusiones)

podemos lanzar unas recomendaciones sobre los principios que pueden guiar el diseño de Exchange 2013.

Disponibilidad

Es el primer principio que depende de lo que hemos explicado en los primeros post y que se cumple en la nueva arquitectura de Ex13. Tenemos varios roles por servidor, en la medida de lo posible, y tenemos que realizar un diseño sencillo, basado en redundar los componentes de los dominios de fallo, independientes en su disponibilidad, y no los componentes, dependientes de otros para su disponibilidad.

Funcionalidad y productividad

Realizar un despliegue de los buzones, usando el buzón como el único repositorio de datos a bajo coste y realizar el incremento de valor con Lync y SharePoint. Aproximar el diseño a la nube, como puente de proyectos más complejos.

Operaciones

Enlazar los equipos hacía el servicio o flujos de trabajo, no sólo hacía la tecnología. En esto, nada mejor que dar un repaso a la inmadurez de muchos servicios IT, enfocados sólo a la tecnología como si fuera necesario batir un record conocer un sistema y no el servicio.

Simplificar y optimizar la administración con procesos orientados a la gestión de eventos, incidentes, problemas y mejora continua.

Coste

Medir el «total cost of the ownership» (TCO) para establecer el rendimiento de la solución, junto a la comoditización del hardware, llevados por lo que hemos desarrollado en la Disponibilidad y el hacer un desarrollo de lo nativo, sin excentricidades. Esto se llama evitar la complejidad.

El cambio

Si hemos entendido el multi-rol y la redundancia dentro de los dominios del fallo, entenderemos que el diseño sería algo así:

 

modelo_ex13

Por diseño, instalamos los roles, componentes como dominios de fallo, independientes, y dependientes con el resto, en el mismo servidor, o al menos sólo en dos. Redundamos cada dominio, el CAS con el balanceo de carga y el MBx con la replica en varios servidores. Desaparecen los dominios de error intermedios, del almacenamiento y red, por lo que redundamos los dominios necesarios.

Podemos comoditizar el hardware al poder usar drivers ya que ha bajado los requerimientos de Exch13:

  • Los requerimientos de Exchange para I/O   se reducen un 95%comparado con Exchange 2003
  • Las bases de datos de Exchange  ~10 IOPS; una solo disco Nearline SAS  proporciona ~60 IOPS

Exchage controla la disponibilidad y la redundancia, software y no el hardware, no la infraestructura. Copias redundantes de bases de datos, ya no hace necesario RAID o backup y la redundancia de servidores ya no hace necesaria la redundancia de otros dominios de errores: nic teamin o MPIO.

En los siguientes post veremos cada elemento que acabamos de introducir. Un saludo

 

Leave a Reply