Puntos de Mejora, En Una Arquitectura De Centros De Datos

Memo

Mientras escribía el anterior articulo, me quede pensando en el resto de los factores que normalmente han provocado que no se pueda responder de manera efectiva al momento de hacer un cambio de trafico entre los Centros de Datos, y que no tiene nada que ver con lo que es el diseño de la arquitectura donde ya vimos que existen sus porque de algunas cosas, y la necesidad de que existan otras, la razones por las que se establecen de esa manera son múltiples, pero ahora quiero dedicar las siguientes líneas en compartirles mis experiencias con la operación, con el día a día de las aplicaciones productivas, y los hallazgos al momento de querer pasar alguna parte de la solución al Centro de Datos secundario o mantener ambos funcionando al mismo tiempo.

Entre las cosas que he identificado que pueden influir en los resultados, se encuentran a groso modo, código, procesos, procedimientos y aspectos administrativos que giran alrededor de las soluciones y que bien vale la pena tener en mente o a la vista para darle una revisada de vez en cuando.

Esto ha sido mas común de lo que yo quisiera admitir, por alguna razón la persistencia de las sesiones y/o variables entre ambientes es un inconveniente a superar cada vez que se piensa en una solución HOT to HOT o ACTIVA / ACTIVA, entre dos Centros de Datos, las historias que he escuchado tienen que ver con:

Una cookie que tiene almacenado el nombre del Centro de Datos o Cobertura que inicialmente atendió al cliente, y posteriormente ese valor se usa para verificar a que Centro de Datos se debe direccionar la siguiente petición desde el mismo cliente, finalmente el valor va viajando a través de las siguientes capas para mantener un silo dentro de la solución hasta la mas profunda línea de aplicaciones que se requiera para el funcionamiento.
Uso de variables de sesión que se almacenan en la memoria de los servidores, generalmente visto en servidores de aplicaciones aunque no limitativo, es común notar que la solución que se construyo tiene variables de sesión que se comparten entre el clúster formado por los servidores del mismo centro de datos, por lo que el balanceo entre estos es posible, sin embargo cuando uno quiere trasladarse al otro centro, la falta de sincronización entre estos provoca que haya una dificultad a la hora de transferir el flujo a menos que se de baja aquella cobertura que tiene el control.
Finalmente, el almacenamiento de datos o variables de sesión que se almacenan en dispositivos externos como Bases de Datos, pero estos últimos tienen configuraciones ACTIVO/PASIVO por lo que aun cuando no se tiene la dependencia de las memorias de los equipos si se tiene una dependencia de la replica y el retraso que esta tiene mas el procedimiento para hacer el fail over hacia el otro Centro de Datos.

Estas son situaciones que pasan comúnmente, y es que en ocasiones no están diagramadas en la arquitectura o por múltiples razones no fueron plasmadas cuando si se convino que debían ser plasmadas, entonces las discrepancias comienzan a aparecer.

Yo no puedo decirles si es correcto o incorrecto el que la solución trabaje de dichas maneras, ya que es necesario revisar caso por caso, y entender si lo que se definió es correcto y lo que esta incorrecto es la expectativa que se tiene sobre la misma, por tanto lo que si creo que debería de ser correcto es que todos tanto los arquitectos, como los equipos de desarrollo/implementación, el negocio y los jefes tengan el mismo entendimiento de la situación real con la que se esta trabajando y en su defecto corregir lo que sea necesario para que se lleve al escenario que visualizaron y acordaron en conjunto.

Durante la implementación en ocasiones es necesario hacer excepciones a la forma de desplegar una solución, aun cuando el diagrama en un escenario final indica como se debería estar implementando un despliegue en particular, en algunas ocasiones no es posible y el escenario es totalmente valido cuando esta justificado, no así cuando es por alguna omisión o error humano. Permítanme ir un poco más a detalle con un ejemplo de lo que estoy diciendo.

Para esto usemos la imagen debajo en la cual se pueden ver dos ejemplos:

El primero es un ejemplo en donde los servidores de aplicaciones se brincan el balanceador y una capa de equipos que en este caso simulan unos API Gateway, pero podrían ser cualquier otro, este brinco es para tener acceso directo al siguiente bloque de equipos que en este caso están representados por Microservicios, esto podría ser por cuestiones de capacidad o limitantes tecnológicas, pero como se menciono antes también podría ser un tema relacionado a errores humanos. Cualquiera que sea la razón por la que sucedió en la practica y no en el diagrama genera controversias al querer operar el cambio entre Centros de Datos sobre todo cuando tocan esta capa, ya que no seria un cambio rápido aun cuando a nivel de redes ambos centros se puedan comunicar.
El segundo es un ejemplo que indica un vinculo directo desde la capa de Servidores de Aplicación hasta la capa de Base de Datos, esto al igual que en el caso anterior puede tener diversos orígenes, entre la capacidad, la tecnología, el alcance, los tiempos, el diseño y/o los errores humanos, sin embargo sin profundizar demasiado en el origen, la consecuencia esta en la dificultad que se tiene cuando se quiere mover el trafico de un Centro de Datos al otro, sin mencionar que en ocasiones la solución va directo a un servidor y no a un pool de servidores hablando de toda la capa.

Siempre la recomendación será no hacer dichos brincos, aunque en ocasiones las necesidades y urgencias suelen presionar para realizar estas acciones, pero tener la conciencia y el entendimiento de las mismas ayudara siempre a tener mas claro el porque cuando se pide hacer un cambio de coberturas entre Centros de Datos partiendo de este especifico escenario y sobre estas capas, no es algo simple o viable, la mayoría de las veces lo que sucede es que se tiene que solicitar un cambio por cada servidor para hacer las modificaciones en las configuraciones correspondientes para re apuntar todos al nuevo destino, sumen la complejidad de hacerlo en horario productivo y tienen razones de sobra, por lo que traten en sus muy particulares escenario resolver esto lo mas rápido posible y evitar estos escenario en lo mas posible.

En ocasiones por increíble que parezca he visto que la vigencia de los certificados e incluso el certificador que provee el mismo es diferente, en otras ocasiones el DN y las especificaciones del mismo también suelen ser diferentes entre los centros de datos, y probablemente como silo cada Centro de da Datos funciona correctamente pero cuando quieres mover el trafico de uno a otro en alguna capa funcional es común encontrar que dicho certificado no esta dado de alta correctamente y la comunicación no se logra de forma exitosa por lo que resulta complicado y/o imposible el querer mover el trafico de un Centro de Datos a otro cuando no se cuenta con la misma definición técnica entre los ambientes hablando de certificados.

Cabe aclarar que lo anterior es poco común en comparación con los escenarios previos, pero llega a pasar, así que como recomendación no dejen de considerar una doble revisión a sus certificados cuando estén verificando el funcionamiento entre sus múltiples coberturas y háganlas homogéneas desde el principio.

Es muy común o más común de lo que quisiéramos aceptar, pero tener aplicaciones con infraestructuras independientes es en muchos casos muy difícil o imposible, por lo que eso significa en términos de costos, que en mi opinión es la principal causa por la que esto sucede pero no la única, ahora volviendo al punto de este apartado, justo el tener la infraestructura compartida entre dos o mas aplicaciones complica las acciones de mover el trafico de una cobertura a otra, ya que se tendría que mover no solo la aplicación que tiene el impacto sino se debería mover todas, aunque por lo regular los requerimientos son solo sobre un aplicativo, y desean que el o los otros se mantengan sobre el mismo silo de centro de datos, hay excepciones por supuesto como cuando el problema esta en la infraestructura completa, en cuyo caso el impacto es parejo para todos los aplicativos y entonces ahí si no hay que preguntar, todos se mueven.

Veamos la siguiente imagen

En la imagen podemos ver que tenemos una aplicación X y una Y, así como su X1 y Y1, ambas en ambos centros de datos, son independientes, en la capa de Front End, pero en lo que al Midleware y el Back End se refiere comparten infraestructura, y es justo en la capa de Middleware donde podríamos querer dejar de usar uno de los centros de datos en la capa donde esta el API Gateway, de acuerdo a la lógica física de este diagrama al hacer el cambio se movería el trafico de ambas aplicaciones, por lo que se requiere el VoBo de ambas o tener un impacto de incidente en ambas. para autorizar el cambio, de otra manera la reacción se retrasaría hasta coordinar a ambos dueños/responsables.

En fin hay formas lógicas de poder separar las aplicaciones pero en la practica es muy común ver escenarios como el anterior en donde si mueves una te tienes que llevar todas, y eso complica las actividades. Pero ya saben cada caso es particular, aunque quizás en algún momento esta información le ayude a alguien a determinar un mejor camino.

Otro de los temas que tiene gran influencia en poder determinar cuando poder mover el trafico de un centro de datos a otro, esta relacionado a un tema no tecnológico y tiene que ver con la forma en la que internamente la institución determina la responsabilidad que se tiene como área productiva de las aplicaciones y la responsabilidad que tiene el negocio como dueños de la información y funcionalidad de la solución en cuestión.

Hoy en día es difícil determinar con claridad donde termina o empieza una aplicación cuando esta es tan transversal y consume tantos recursos de muchos otros sistemas, en ocasiones dichos sistemas son tan viejos que por si mismos se convirtieron en aplicaciones, entonces se tienen infraestructuras como los mainframes, que aunque son una capa de infraestructura también son consideradas como aplicaciones por si mismos, y hay una o varias áreas de negocio responsables de la misma pieza, operativamente esa administración que no se ha adaptado al mundo moderno en ocasiones se vuelve un obstáculo para poder solventar algunas necesidades con respecto a la gestión de coberturas y el direccionamiento del trafico entre ellas, estar solicitando tantas autorizaciones para tomar una decisión final lleva a los puntos mas críticos de la afectación del servicio.

Por tanto si tu escenario esta en una situación parecida donde tu aplicación esta relacionada con otros aplicativos y no tienes claro que facultades o procedimientos debes seguir para solicitar algún cambio entre centros de datos para poder recuperar tu servicio, es un buen momento para irlo revisando antes de que estés nuevamente en una situación de incidente y con toda la presión de recuperar el servicio moviendo el trafico de la cobertura encima y sin poder hacerlo por no tener VoBo.’s

Este es otro factor que se presenta y que no es realmente una situación técnica, este punto se deriva de un proceso administrativo que se tiene que cumplir pero a veces es tan estricto que no te da oportunidad a maniobrar, en general por experiencia se sabe que es necesario periódicamente hacer ejercicios que permitan validar o garantizar que la cobertura o coberturas de respaldo están funcionando adecuadamente, hasta ahí creo que nadie tiene objeción alguna.

Incluso cuando se tiene infraestructura compartida, se solicitan los VoBo’s de todos los involucrados y al final se logra detonar el escenario de validación, donde participan múltiples áreas y procesos. El problema no esta en iniciar el ejercicio.

El verdadero problema esta en el momento en que quieres interrumpir el ejercicio por un tema operativo y necesitas voltear el trafico al otro Centro de Datos pero no puedes porque están ejecutando alguna prueba de DRP o de HVT o de COB, en mi experiencia, la mayoría de las veces las consecuencias de interrumpirlo son tan estrictas que los dueños de las aplicaciones y los involucrados se lo piensan dos veces antes de tomar la decisión de hacer la interrupción, sobre todo cuando ya se supero el 50% de la prueba y que decir cuando estas a un día o unas horas de concluirla.

En mi opinión si estos procesos de auditoria y certificación se volvieran mas flexibles o al menos consideraran situaciones excepcionales para dar por bueno un ejercicio o para interrumpirlo parcialmente para poder continuarlo, o simplemente determinar que cosas buenas tuvo y cuales no al momento de ser requerida su interrupción, tendría un mayor sentido y beneficio, que solo querer cumplir con un determinado grupo de números.

Después de los escenarios revisados, puedo compartir, que hay muchos casos particulares que van a requerir analisis mucho mas específicos, y no pretendo juzgar las razones que cada quien tiene para enfrentar las situaciones que le llevaron a la situación en la que se encuentra, solo es una exposición de ideas que seguro mas de uno ha experimentado en su propia experiencia y que continúan pasando. A mi me sorprende cuando un directivo me pregunta porque no pude evitar el incidente si se supone que tengo todo para hacerlo?, y es una gran pregunta, que tiene una respuesta simple, no tiene claro cual es su real situación y no esta trabajando para resolverla, pero tampoco podemos culparle, ya que su razón de ser no es conocer técnicamente lo que esta ocurriendo, así que sugiero que seamos mas empáticos con la situación, transmitamos información real y busquemos soluciones reales.

De poco o nada sirve un diagrama que dice una cosa, y una implementación que hace otra y un reporte que dice que va a suceder algo que nunca va a pasar, sensatez y congruencia es en mi opinión, la mejor forma de hacer que las cosas caminen y se solucionen para llegar al resultado deseado.