Exchange 2013. Principios de Diseño: Recomendación básica

En post anteriores hemos realizado una incursión sobre el nuevo diseño de Exchange 2013 y como hay una justificación para la simplicidad y el ahorro.

Exchange 2013: Disponibilidad y fiabilidad (Conceptos)

Exchange 2013: Disponibilidad y fiabilidad (conclusiones)

Exchange 2013. Principios de Diseño (1)

En este momento vemos que la creación de varios sitios da la posibilidad de que nuestro entorno sea, además de altamente disponible, máximamente resilente. Os podeis hacer una idea en una contribución excelente de Boris Lokhvitsky. Con todo ello, podemos entender la propuesta de Microsoft.

Recordamos algunos principios:

  • Disponibilidad
  • Resilencia
  • Ahorro de costes

 

Simplicidad/Sencillez

Yo hubiera elegido sencillez. Lo que es simple, es complejo, lo es en extremo. Lo que si está claro es que  la posibilidad de un fallo es algo real y, en cierto sentido, inevitable. La forma que hemos visto para mitigar el fallo es establecer redundancia en aquellos dominios independientes para evitar su contagio a los dependientes. Esta redundancia, aún así, es cara si no se toman medidas precisas. En el caso del almacenamiento es así.

El cambio ha sido dejar a un lado el diseño basado en SAN, para pasarlo a un sistema de almacenamiento redundado SAS/SATA en una configuración JBOD. Esto se basa en la replicación del almacenamiento a un coste barato, con una redundancia que cumple con la fiabilidad del sistema.

Esto se ha hecho a través de software, dentro de Exchange, como replica por diseño. Ahora ya no es relevante el tener todos los dominios de fallo redundandos de forma cara y compleja, sino tener un almacenamiento barato, en ordenadores baratos, replicando y creando dominios de fallo independientes.

Costes/Complejidad

Esta sencillez ataca no sólo a los costes, sino también reducimos la complejidad. La complejidad aumenta las posibilidades de fallo. El dejar de atacar la disponibilidad dominio a dominio de fallo, dependientes, por un sistema de redundancia del dominio de fallo más importante, almacenamiento. Siendo un sistema de replica por software, podemos tener un sistema de replicación que predice el fallo. Es un sistema que, dado el caso de fallo, activa el almacenamiento, al activar una copia de la base de datos afectada.

Esta elección tiene unas implicaciones precisas y vamos a desarrollar las posibilidades que tenemos para que el marco de esta recomendación se entienda con toda su amplitud.