¿Cómo Funciona una Arquitectura Tecnológica Entre Centros de Datos?

Arquitectura - Tecnológica

Durante mi experiencia en áreas productivas de TI , y si quiero hacer la aclaración que esta publicación esta basada en mi experiencia personal y no en una regla universal, ya que es posible que no todos estén 100% de acuerdo, sin embargo espero que en algún momento la información pueda ser de utilidad para la comunidad, sin mas demos paso a una serie de puntos que he recolectado como resultado de dar respuesta a las siguientes preguntas ¿Por qué si la arquitectura dice que hay alta disponibilidad no se puede cambiar fácilmente entre coberturas? o ¿Por qué si la arquitectura dice que hay alta disponibilidad existen caídas? o ¿Por qué el tiempo de recuperación es considerablemente alto?, seguro que en sus mentes hay otros tantos cuestionamientos, pero los iremos descifrando.

Ahora bien no voy a decir que lo que aquí se diga serán reglas preestablecidas o ley en ningún sentido, lo que si espero es que después de responder a la mayor cantidad de preguntas de forma individual en diversas ocasiones si he podido identificar “patrones” de comportamiento que se han repetido escenario por escenario, implementación por implementación, voy a tratar de explicar esto en una respuesta mas general a esas y otras preguntas relacionadas con la alta disponibilidad en una Arquitectura simple que desde mi particular punto de vista son situaciones que se repiten constantemente, no quiero generalizar ni decir que esto es en todo el mundo, pero ya que lo he visto mas de una vez y me lo han preguntado en mas de una ocasión, así que no veo porque no hablar del tema, y poder dar luz a alguien que aun no lo ha notado o poder recibir una nueva idea de algo que no me ha tocado vivir, o mejor aún poder debatir al respecto.

Tabla de Contenido

Arquitectura de Ejemplo

Habiendo dicho lo anterior permítanme usar el siguiente diagrama para ponerlos en perspectiva y describirles cual es el escenario:

Diagrama de Arquitectura Completa
Diagrama de Arquitectura Completa

Imaginemos que tenemos 2 Centros de Datos, cada uno tiene 3 capas divididas en Front End / Middleware / Back End y en cada una tenemos un conjunto de servidores vinculados por un Balanceador de Cargas que esta uniendo cada una de las capas, se menciona que en la capa superior del Front End entre Centros de Datos hay una configuración Activa/Activa mientras que en el Middleware no hay visibilidad directa entre Centros de Datos y finalmente la ultima capa en el Back End, hay un Activo/Pasivo configurado.

Analizando posibilidades entre centros de datos

Cuando vemos un diagrama como el anterior y alguien nos dice que hay alta disponibilidad y que quieren un cambio de flujo en las transacciones entre centros de datos con un solo botón o con una sola acción (Control de Cambios), tenemos varios escenarios, que nos permitirán responder si se puede o no y porque.

Primer Escenario: Imaginen que ahora se tiene una petición de cambiar el flujo de entrada de las transacciones hacia uno u otro o ambos Centros de Datos,

Esto se puede hacer con un cambio solicitado al área de Redes pidiéndole modificar una configuración en el primer balanceador que esta recibiendo la información, marcado en rojo en la imagen debajo, en ese punto seria posible interrumpir o permitir el trafico de acuerdo a la solicitud.

Diagrama de Arquitectura Web Servers I
Ejemplo I de Modificación del Flujo de EntradaEjemplo I de Modificación del Flujo de Entrada

Otra posibilidad para controlar el flujo es a través de los balanceadores que se encuentran en la entrada de cada centro de datos, marcados en rojo en la imagen de abajo, el cambio tiene que ir en el mismo sentido que el punto anterior atender con el área de Redes un cambio para poder bloquear o permitir desde el balanceador el flujo hacia las instancias de los Web Servers.

Diagrama de Arquitectura Balanceadores
Ejemplo II Modificación del Flujo de Entrada

Finalmente, si hacer cambios con el equipo de Redes resulta muy complicado, existe otra posibilidad que es solicitar al área dueña de los Servidores Web apagar o encender las instancias de los Web Servers que se quiere modifiquen su comportamiento de acuerdo a la solicitud que se tenga, mirar la siguiente imagen.

Diagrama de Arquitectura Web Servers
Ejemplo III Modificacion del Flujo de Entrada desde los Web Servers

Recordemos que los balanceadores están configurados para sondear puertos de un equipo en especifico y que al estar abajo el servicio que usualmente ocupa el puerto, este a nivel del Sistema Operativo no existe, por tanto el censo que realiza el balanceador responde en FALSO y por tanto ignora ese camino.

Pero ¿Qué pasa con el siguiente bloque de infraestructura en la misma capa de Front End?, como recordaran debajo de los Servidores Web aun tenemos otros balanceadores y un grupo de servidores que son los Servidores de Aplicación, si se están preguntando si es posible hacer lo mismo que con los Servidores Web, la respuesta es SI, tanto con los balanceadores como con las instancias de los Servidores de Aplicación es posible aplicar las mismas acciones para un cambio de cobertura entre Centros de Datos, la única diferencia es que generalmente hay mas Servidores de Aplicaciones que Servidores Web, pero el efecto es el mismo.

Diagrama de Arquitectura Application Servers II
Ejemplo IV Modificación de Flujo de Trafico desde los Application Servers

Ahora hay que entender porque esta conexión si daría el mismo resultado que la anterior y porque mas adelante veremos que se rompe toda la arquitectura de alta disponibilidad entre los dos Centros de Datos, en la imagen que sigue, noten la relacion que existe entre el Balanceador del Centro de Datos 1 y el 2 antes de los Servidores de Aplicaciones.

Diagrama de Arquitectura Application Servers
Relación entre Balanceadores de ambos Centros de Datos

Segundo Escenario: Se solicita no tocar toda la capa del Front End y solo hacer el cambio en la capa de Midleware, ya que es la que esta presentando el incidente, y por las razones que fueren se requiere hacer el cambio ahí.

En este momento no sería posible hacerlo, al menos no con el tipo de arquitectura que tenemos, recuerdan la línea que entre los balanceadores de la anterior capa, les dije que seria importante, bueno aquí es donde adquiere relevancia, en nuestro diagrama original no existe.

Diagrama de Arquitectura MIddleware
Configuración de Middleware sin Relación entre Centros de Datos

Claramente la solución sería establecer dichos vínculos y asunto arreglado, hay multiples razones por las que en algunas ocasiones no se tiene esa relación y pocas veces es un problema de redes, sin embargo hay que considerar que en medio puede haber routers, firewalls, clouds, pero en general no es algo que no se pueda resolver con un poco de tiempo, los problemas mas difíciles de resolver por lo general están en el código de las soluciones, pero de eso les platicare en otra oportunidad.

También quiero aclarar que aunque a modo de ejemplo se uso la capa de middleware, no necesariamente tiene que ocurrir en esta capa, o entre estas tecnologías, bien podría darse entre otras tecnologías y en otras capas, según lo complicada de la arquitectura y la cantidad de componentes.

Tercer Escenario: Este esta orientado a querer hacer que el cambio del trafico se haga solo en el Back End, ya que en algún momento es la capa que pudiera estar teniendo dificultades o necesidades para ser cambiada entre uno y otro Centro de Datos.

Es mas común de lo que se pueden imaginar que esta capa este configurada en un entorno ACTIVO/PASIVO, lo cual no permite o dificulta aun mas la transición entre los Centros de Datos como se puede ver en el esquema que les muestro debajo. En este sentido es muy común observar que se requiere de la participación de los equipos de middleware para desplegar algún cambio que apunte al otro Centro de Datos, además de los equipos de BDs que tienen que hacer el Faile Over entre las Bases de Datos de los Centros de Datos, en conclusión el tema no es tan simple, pero que de igual forma podría resultar mucho mas cómodo si el cambio de direccionamiento se pudiera hacer desde una capa intermedia sin tener que tocar los componentes del middleware y claro que estuvieran en un esquema ACTIVO/ACTIVO.

Diagrama de Arquitectura Bases de Datos
Migración de Trafico en el Back End

Claro que todo lo anterior dependerá siempre del tamaño de la empresa, de la cantidad de servidores, de la cantidad de tecnologías de los sistemas intermedios que no se están viendo en este momento, pero les reitero que este diagrama es a modo ilustrativo con la intención de poder identificar componentes y relaciones entre las diferentes capas y sus componentes, así que la próxima vez que vean una arquitectura con características similares y que les digan que es 100% activa/activa y les pidan hacer un cambio de Centro de Datos de alguna capa que no sea donde inicia el silo, defiendan con conocimiento y evidencias el porque no es fácil, trivial, o como si se lograría si se logran resolver los temas que permitan tener realmente las comunicaciones o vínculos entre los componentes donde al momento no existen.

En un post siguiente les contare de aquellos factores que hay alrededor de los componentes físicos y los diagramas que dificultan la transición entre coberturas.

De antemano muchas gracias.

Que tengan un buen día.

Saludos.

Te puede interesar

Memo1

Guillermo Granillo

Blogger

Conoce a Guillermo Granillo, un apasionado explorador, narrador de historias y la fuerza creativa detrás del blog "Blogging With Memo". Con una curiosidad y una sed insaciable de nuevas experiencias.

Te Puede Interesar

Publicaciones Relacionadas

BloggingWithMemo-suscripcion-icono

Suscríbete

Recibe las últimas noticias y actualizaciones de la familia Bloggingwithmemo.