Cómo aprovechar al máximo su Pirámide Invertida de la Perdición

La arquitectura 3-2-1 o Pirámide Invertida de la Perdición se ha convertido en un paria de la industria de TI por muchas razones. Lamentablemente, para muchas empresas, solo se enteran de los peligros asociados a este diseño después de que los componentes han llegado y el dinero ha salido de las cuentas.

Algunas empresas tienen suerte y detectan este error con suficiente antelación como para poder devolver sus compras y empezar de nuevo con una fase adecuada de diseño y decisión antes de la adquisición de nuevo hardware y software. Esto, sin embargo, es una situación ideal y muy poco frecuente. En el mejor de los casos, normalmente podemos esperar cargos por reposición de existencias y, mucho más comúnmente, el equipo no puede devolverse en absoluto o los cargos son tan elevados que lo vuelven inútil.

A lo que se enfrenta la mayoría de las empresas es a la necesidad de “aprovechar al máximo” la situación de cara al futuro. Una de las mayores preocupaciones es que las partes implicadas, ya sean los interesados financieros que acaban de gastar mucho dinero en el nuevo hardware o los interesados técnicos que ahora quedan mal por haber permitido que se comprara este equipo, sucumban a una reacción emocional que las lleve a caer en la falacia del costo hundido. Es vital que no se permita que esta reacción emocional e ilógica se afiance, ya que socavará la toma de decisiones crítica.

Hay que entender que el dinero gastado en la pirámide invertida de la perdición ya se ha gastado y se ha ido. Que el dinero se haya desperdiciado o cuánto se haya desperdiciado es irrelevante para la toma de decisiones en este punto. Si el sistema fue un regalo o si costó mil millones de dólares no importa; ese dinero se ha ido y ahora tenemos que arreglárnoslas con lo que tenemos. Un posible “truco” aquí sería incorporar a un responsable de decisiones financieras, como un director financiero, explicarle que está a punto de producirse una reacción emocional ante un dinero ya gastado y hablar de la falacia del costo hundido antes de abordar el problema real, de modo que la gente esté consciente y sea lógica, y la persona capacitada (eso esperamos) para manejar mejor este tipo de situación esté presente y lista para atajar las emociones del costo hundido. Es importante gestionar con cuidado una reacción que podría estar alimentada por las emociones. Este no es el momento de intentar encubrir los errores financieros o técnicos, que es lo que la reacción emocional está provocando. Es necesario que todas las partes se comuniquen y se mantengan distantes y lógicas para poder atender las necesidades. Algunas empresas manejan esto bien, muchas no y quedan atrapadas tratando de seguir adelante con malas decisiones que ya se tomaron, probablemente con la esperanza de que no ocurra nada malo y de que nadie lo recuerde o lo note. Combata esa reacción. Todos la tenemos; es la respuesta emocional natural de “lucha o huida” de la amígdala.

Ahora que estamos preparados para combatir las reacciones emocionales ante el problema, podemos empezar a abordar “qué hacemos a partir de aquí”. La buena noticia es que el punto en el que nos encontramos suele ser una posición de tener “demasiado” en lugar de “demasiado poco”. Así que tenemos la oportunidad de ser un poco creativos. Afortunadamente, por lo general existen buenas opciones que nos permiten avanzar en varias direcciones.

Algo muy importante que conviene señalar es que estamos buscando exclusivamente soluciones que sean más fiables, no menos fiables, que la arquitectura de pirámide invertida de la perdición que pretendemos reemplazar. Una IPOD es un diseño muy frágil y peligroso, y podríamos extendernos mucho demostrando conceptos como el análisis de riesgos, los puntos únicos de fallo, las falacias de la falsa redundancia, fijarse en la redundancia en lugar de en la fiabilidad, las cadenas de dependencia, etc., pero lo que es absolutamente crítico que todas las partes entiendan es que un único servidor, funcionando con almacenamiento local, es más fiable de lo que sería toda la infraestructura IPOD. Esto es tan importante que hay que repetirlo: si un único servidor es de “disponibilidad estándar”, la IPOD está por debajo de eso. Es más arriesgada. Si en esta etapa alguien teme una “falta de redundancia” o una “falta de complejidad” en las soluciones resultantes, debemos volver a esto: nada de lo que vamos a comentar es tan arriesgado como lo que ya se había diseñado y comprado. Si hay algún temor al riesgo de cara al futuro, ese temor debería haber sido mayor antes de que mejoráramos la fiabilidad del diseño. Esto no puede recalcarse lo suficiente. Las IPOD se venden porque confunden fácilmente a quienes no están capacitados en análisis de riesgos y parecen fiables cuando, de hecho, son todo lo contrario.

Entender lo anterior y utilizar una técnica llamada “leer hacia atrás” la arquitectura IPOD aceptada nos indica que la empresa en cuestión aceptaba no tener alta disponibilidad (ni siquiera disponibilidad estándar) en el momento de comprar la IPOD. Quizás creían que la estaban obteniendo, pero la arquitectura no podía proporcionarla, así que, de cara al futuro, tenemos la opción de “arreglárnoslas” con nada más que un único servidor, funcionando sobre su propio almacenamiento local. Esto es simple y sencillo, y mejora casi todos los aspectos del diseño IPOD previsto. Cuesta menos operar y mantener, a menudo es más rápido y es mucho menos complejo, a la vez que es ligeramente más fiable.

Pero lo más probable es que simplemente reducirnos a un único servidor y esperar encontrar usos para el resto del equipo comprado “en otro lugar” no vaya a ser nuestra mejor opción. En situaciones en las que la IPOD estaba destinada a usarse únicamente para una sola carga de trabajo o conjunto de cargas de trabajo, y otras áreas del negocio también necesitan equipo, puede resultar muy beneficioso optar por el enfoque del “servidor único” para la carga de trabajo IPOD prevista y utilizar el equipo restante en otras partes del negocio.

El enfoque más común que se adopta al reaprovechar una pila IPOD es reconfigurar los dos (o más) nodos de cómputo para que sean nodos de pila completa que contengan su propio almacenamiento. Este paso puede no requerir compra alguna, dependiendo del almacenamiento que ya se haya adquirido, un traslado de discos entre sistemas o, a menudo, la compra relativamente pequeña de discos duros adicionales para este propósito.

Estos nodos pueden entonces configurarse en uno de dos modelos de alta disponibilidad. En el pasado, una opción de diseño común, por razones de costo, era utilizar un modelo de replicación asíncrona (a menudo conocido como el enfoque Veeam) que replica las máquinas virtuales entre los nodos y permite encender las VM muy rápidamente, lo que posibilita un tiempo de inactividad, desde el momento del fallo del nodo de cómputo hasta la recuperación, de tan solo unos pocos minutos.

Hoy en día, la tolerancia a fallos totalmente síncrona está disponible de forma tan común y gratuita que ha reemplazado de hecho al modelo asíncrono en casi todos los casos. En este modelo, el almacenamiento se replica en tiempo totalmente real entre los nodos de cómputo, lo que permite que la conmutación por error ocurra de forma instantánea, en lugar de con unos minutos de retraso, y con cero pérdida de datos en lugar de una pequeña ventana de pérdida de datos (por ejemplo, un RPO de cero).

En este punto, parece ser común que la gente reaccione ante la replicación con el temor a una pérdida de capacidad de almacenamiento provocada por la replicación. Por supuesto, esto es cierto. Es necesario entender que es precisamente esta replicación, ausente en el diseño IPOD original, la que proporciona la base firme para una alta fiabilidad. Si se omite esta replicación, la alta disponibilidad es un sueño inalcanzable y los nodos de cómputo individuales que utilizan almacenamiento local en modo “autónomo” son la opción potencial más fiable. Las soluciones de alta disponibilidad se basan en la replicación y la redundancia para construir la fiabilidad necesaria que les permita calificar como de alta disponibilidad.

Esto resuelve la cuestión de qué hacer con nuestros nodos de cómputo, pero nos deja con qué podemos hacer con nuestro dispositivo de almacenamiento compartido externo, el punto único de fallo o el “vértice” del diseño de pirámide invertida. Para responder a esta pregunta, deberíamos empezar por observar qué podría ser este almacenamiento.

Hay tres tipos comunes de dispositivos de almacenamiento que se utilizarían en un diseño de pirámide invertida: DAS, SAN y NAS. Podemos agrupar DAS y SAN, ya que ambos son dos aspectos diferentes del almacenamiento por bloques y pueden utilizarse esencialmente de forma intercambiable en nuestra discusión: solo se diferencian por la existencia de conmutación, que puede añadirse o eliminarse según sea necesario en nuestros diseños. El NAS se diferencia por ser almacenamiento de archivos en lugar de almacenamiento por bloques.

En ambos casos, almacenamiento por bloques (DAS o SAN) o de archivos (NAS), uno de los usos más comunes de este dispositivo ahora superfluo es como destino de copia de seguridad para nuestra nueva infraestructura de virtualización. En muchos casos, el dispositivo puede ser excesivo para esta tarea, generalmente con más rendimiento y muchas más funciones de las necesarias para un simple destino de copia de seguridad, pero un buen almacenamiento de copias de seguridad es importante para cualquier infraestructura empresarial crítica, y pecar de excesivos no es necesariamente algo malo. Las empresas a menudo intentan escatimar en sus infraestructuras de copia de seguridad, y esta es una oportunidad para invertir fuertemente en ella sin gastar dinero adicional.

En la misma línea que el almacenamiento de copias de seguridad, el dispositivo de almacenamiento externo podría reaprovecharse como almacenamiento de archivo histórico u otro “nivel inferior” de almacenamiento donde no se justifique la alta disponibilidad. Este es un enfoque menos común, generalmente porque toda empresa necesita un buen sistema de copia de seguridad, pero solo algunas tienen forma de aprovechar un nivel de almacenamiento de archivo histórico.

Más allá de estos dos modelos de almacenamiento comunes y universales, un caso de uso habitual para los dispositivos de almacenamiento externo, especialmente si el dispositivo es un NAS, es aprovecharlo en su función nativa como servidor de archivos independiente de la infraestructura de virtualización. Para muchas empresas, el servicio de archivos no es tan crítico en cuanto a tiempo de actividad como la infraestructura central de virtualización, y las copias de seguridad son mucho más fáciles de mantener y gestionar. Al descargar el servicio de archivos a un dispositivo NAS ya adquirido, esto puede reducir los requisitos de servicio de archivos de la infraestructura de virtualización, tanto al disminuir el número de VM que deben ejecutarse allí como al trasladar lo que suele ser uno de los mayores consumidores de almacenamiento a un dispositivo independiente, lo que puede reducir tanto los requisitos de rendimiento de la infraestructura de virtualización como sus requisitos de capacidad. Al hacer esto, potencialmente reducimos el costo de obtener los discos duros adicionales necesarios para el almacenamiento local de los nodos de cómputo, como indicamos antes, por lo que este puede ser un método muy popular para que muchas empresas atiendan sus necesidades de reaprovechamiento.

Cada empresa es única y existen potencialmente muchos lugares donde el equipo de almacenamiento sobrante podría utilizarse de forma eficaz, desde laboratorios hasta archivos o almacenamiento por niveles. Con un poco de creatividad y pensando fuera de lo convencional, se puede aprovechar el conjunto único de equipo del que dispone y el conjunto único de necesidades y exigencias de su empresa para encontrar el mejor lugar donde utilizar este equipo, allí donde quede desacoplado de la infraestructura central y crítica de virtualización, pero pueda seguir aportando valor a la organización. Al evitar la pirámide invertida de la perdición, podemos obtener el máximo valor del equipo en el que ya hemos invertido en lugar de generar nueva deuda técnica que luego tengamos que esforzarnos por superar innecesariamente.