Crear un centro de datos en la nube privada es como construir un automóvil deportivo desde cero. Se deben elegir el motor, las piezas y el equipo adecuados para satisfacer las demandas de rendimiento de la carretera y el conductor. Gracias a las innovaciones de hardware y software, los arquitectos de TI pueden componer sus centros de datos para que funcionen más como un Lamborghini y menos como un cacharro antiguo.
Las nubes privadas locales requieren supervisión, administración y mantenimiento constantes. Los costos de operación, como el reemplazo de las unidades o el aprovisionamiento excesivo, pueden incrementar rápidamente con el tiempo. Esto aumenta el costo total de propiedad (CTP) de los centros de datos y afecta los resultados de una empresa. Especialmente con el hecho de que la captura, la creación y la utilización de datos están creciendo exponencialmente cada año.
Esos problemas son precisamente la razón por la que actualmente se está desarrollando lo que Seagate llama la megatendencia de composibilidad. Un centro de datos moderno y con capacidad de composición permite que cada servidor de nube privada esté formado por componentes que están desagregados pero interconectados con tipos de estructura y ancho de banda óptimos. La composibilidad proporciona una forma flexible de administrar y acceder a los datos en múltiples aplicaciones y flujos de trabajo de datos.
Los arquitectos de TI deben decidir si van a utilizar una solución de nube privada local o una nube pública o privada alojada por un tercero. Las nubes públicas comparten servicios informáticos entre diferentes clientes y están alojadas en un centro de datos externo. Los proveedores de nube de terceros también ofrecen nubes privadas alojadas, que también están alojadas externamente pero los servicios no se comparten.
Las nubes privadas locales son administradas y mantenidas por el propio centro de datos de una empresa y no comparten servicios con otras organizaciones. Los principales beneficios de utilizar una nube privada local incluyen una mayor sensación de seguridad, flexibilidad y mayor rendimiento. Los usuarios pueden personalizar sus recursos y servicios para que el hardware coincida específicamente con los requisitos del software, en lugar de tener un enfoque único para todos. Los usuarios también tienen control total sobre la seguridad, la capacidad de expansión y la configurabilidad de sus servidores.
A medida que las demandas de las aplicaciones aumentan o disminuyen, los componentes y los servidores se comunican entre sí para cambiar la carga de trabajo. Los arquitectos de TI ahora pueden diseñar centros de datos con una matriz más amplia de hardware y componentes de varios fabricantes. De hecho, están desarmando, o desagregando, la infraestructura del centro de datos tradicional. Una vez que se destruye la carcasa, el centro de datos se puede reconstruir para tener un uso más eficiente de los recursos instalados. Los arquitectos de TI pueden evitar la compra de hardware innecesario a un costo adicional y los componentes se pueden reemplazar fácilmente sin tiempo de inactividad.
La desagregación y la composibilidad del centro de datos en la nube privada evolucionaron de la arquitectura de red tradicional a la infraestructura dinámica actual que permite el funcionamiento de sistemas potentes y exigentes. La desagregación de la infraestructura componible tiene varios beneficios clave, que incluyen una latencia reducida y una mayor seguridad y control sobre los datos.
Limitaciones del centro de datos tradicional
La arquitectura de TI tradicional está llegando a sus límites debido al crecimiento exponencial de los datos y la creciente complejidad de las aplicaciones de software. Las unidades de procesamiento central (CPU), las unidades de memoria de acceso dinámico (DRAM), las unidades de memoria de clase de almacenamiento (SCM), las unidades de procesamiento gráfico (GPU), las unidades de disco de estado sólido (SSD) y las unidades de disco duro (HDD) se encuentran entre los componentes críticos que contiene un centro de datos. Estos componentes suelen estar alojados juntos en una caja o servidor y son los cimientos sobre los que se construye el centro de datos. En esta arquitectura de nube empresarial tradicional, cada componente, como una unidad de disco duro, se conecta directamente al resto del servidor.
Los centros de datos operaban originalmente bajo el paradigma de una aplicación por caja. Y cuando las aplicaciones superaron las capacidades de almacenamiento y procesamiento de datos que los servidores individuales podían proporcionar, los arquitectos de TI comenzaron a agrupar varios servidores en clústeres, los cuales podían utilizarse como un conjunto de recursos. Las soluciones patentadas de empresas como IBM, EMC, NetApp y el propio equipo Dot Hill de Seagate lideraron la incursión inicial de la industria en recursos de servidores agrupados.
Los centros de datos podían aumentar la escala y de esta manera satisfacer las necesidades de las aplicaciones de software a medida que crecían en complejidad: si una aplicación requería más almacenamiento, ancho de banda o potencia de la CPU, se podían agregar servidores o nodos adicionales al clúster. El modelo de agrupación de recursos en clústeres forma la base de lo que ahora conocemos como infraestructura de nube empresarial convergente e hiperconvergente, que utiliza las aplicaciones de un hipervisor empresarial como VMware y otras.
Los clústeres de nodos cumplieron su propósito en la infancia de la nube, pero son propensos al aprovisionamiento excesivo. Esto ocurre cuando los arquitectos de TI compran más servidores, que seguramente contendrán más recursos de un tipo u otro de los que son necesarios, pero luego estos recursos no se utilizan. Aunque el enfoque de implementación de un sistema de clúster tiene sus beneficios, como garantizar suficiente capacidad de almacenamiento y procesamiento, los recursos que no se utilizan dentro de los servidores son ineficientes. Sin embargo, los arquitectos de TI tenían que depender del aprovisionamiento excesivo para cumplir con la escala, ya que los centros de datos no tenían forma de escalar dinámicamente solo los recursos o las cargas de trabajo específicas para las demandas de las aplicaciones del software. Los costos excesivos son una consecuencia natural del aprovisionamiento excesivo.
Los arquitectos de TI también estaban limitados en términos de los componentes de hardware que podían usar para formar un servidor. El hardware para cada servidor o clúster tenía que comprarse a fabricantes únicos por motivos de compatibilidad. Y no había interfaces de programación de aplicaciones (API, por sus siglas en inglés) abiertas disponibles para ayudar al hardware de varios fabricantes a comunicarse y coordinarse. Si los arquitectos querían cambiar una CPU por una más rápida, por ejemplo, una de otro fabricante, a menudo no tenían suerte debido a la incompatibilidad. El hardware de diferentes fabricantes no podía comunicarse ni coordinarse entre sí.
Pero las incompatibilidades de hardware no son lo único que pone a prueba la infraestructura de datos tradicional. También está el problema de las enormes cantidades de datos que deben recopilarse, almacenarse y analizarse. La explosión de grandes volúmenes de datos no solo está superando los límites de almacenamiento de los clústeres de nube privada tradicionales, sino que también está creando un embotellamiento en el procesamiento de datos. Cada CPU suele estar demasiado ocupada en el procesamiento de datos locales para compartir recursos con otras aplicaciones, lo que genera ineficiencias generales a la hora de escalar los recursos del centro de datos.
Por ejemplo, las aplicaciones complejas de inteligencia artificial (IA) se basan en la capacidad de procesar grandes cantidades de datos en poco tiempo. Cuando una aplicación de IA utiliza un centro de datos implementado en un clúster, tienden a producirse embotellamientos en la recopilación y en el procesamiento de datos. Y si la aplicación necesita más potencia de procesamiento, no hay forma de transferir la carga de trabajo adicional a otros clústeres. La latencia, o retrasos en la transmisión de datos entre dispositivos, es otra consecuencia negativa.
Por ejemplo, puede haber dos clústeres de servidores en el mismo centro de datos, uno de los cuales está sobrecargado y el otro infrautilizado. La aplicación que usa el clúster sobrecargado puede ralentizarse o tener problemas de rendimiento. Este problema podría resolverse fácilmente integrando el clúster con aprovisionamiento excesivo y el clúster infrautilizado para ayudar. Pero el grupo de recursos que la aplicación puede extraer está estrictamente limitado al único clúster dedicado para esa aplicación. Esta es una ilustración perfecta de por qué los arquitectos de TI han estado buscando formas más eficientes de componer un centro de datos.
La era de la propiedad está llegando a su fin, si es que aún no lo ha hecho. Las aplicaciones de software sofisticadas exigen más capacidad de procesamiento y almacenamiento de la que puede proporcionar un centro de datos implementado en un clúster tradicional. Y los arquitectos de TI tienen limitaciones en cuanto al hardware que pueden utilizar debido a la falta de API abiertas que permitan la comunicación entre dispositivos. Para que los arquitectos de TI avancen, necesitarán una comprensión más profunda de cómo las aplicaciones modernas impactan la arquitectura de la nube privada y cómo la capacidad de composición puede ayudar a superar los desafíos de la infraestructura de TI tradicional.
Cómo las aplicaciones impactan en el centro de datos de la nube privada
Una de las mayores fuerzas que impulsan la megatendencia de composibilidad son las demandas de las aplicaciones de software. El software como la inteligencia artificial o la analítica empresarial exige un conjunto cada vez más complejo de requisitos específicos de hardware para satisfacer las necesidades de esa aplicación. Esto crea una feroz competencia por los grupos de recursos de almacenamiento y procesamiento.
Como se señaló, los centros de datos tradicionales ahora han llegado a un punto de ruptura, donde la potencia de procesamiento requerida por varias aplicaciones excede regularmente los límites de un modelo de agrupación en clúster. Los requisitos de las aplicaciones también evolucionan constantemente con el tiempo y los cambios pueden producirse rápidamente. La nueva versión de una aplicación empresarial, por ejemplo, puede exigir el doble de capacidad de almacenamiento o procesamiento que la anterior. Si esta excede los límites de su clúster dedicado, se debe comprar más hardware. Los avances en software enfatizan lo que puede ofrecer un centro de datos implementado en un clúster tradicional.
La composibilidad brinda a las aplicaciones acceso a grupos de recursos fuera de su clúster dedicado, lo que desbloquea la potencia de procesamiento, u otros recursos, disponibles dentro de los servidores aprovisionados en exceso. Cada CPU, GPU o nodo de almacenamiento se puede escalar de forma independiente de acuerdo con las necesidades de precio de cada aplicación.
Las demandas de procesamiento adicionales también crean embotellamientos dentro de la estructura del centro de datos tradicional. La estructura del centro de datos es lo que conecta varios nodos y clústeres. Idealmente, una estructura con capacidad de composición que satisfaga las necesidades de las aplicaciones de software modernas debe crear un conjunto de capacidad de estructura flexible. Esta estructura debe configurarse instantáneamente para aprovisionar la infraestructura y los recursos de forma dinámica a medida que aumentan las necesidades de procesamiento de una aplicación. El objetivo es proporcionar aplicaciones avanzadas no solo con un procesamiento más rápido, sino con un procesamiento en tiempo real que facilite que estas aplicaciones se ejecuten a velocidades óptimas.
La composibilidad y la desagregación son esenciales para satisfacer las demandas de las aplicaciones de software avanzado. La arquitectura implementada en un clúster tradicional simplemente no está a la altura de las circunstancias, por lo que la información no puede viajar a través de estructuras Ethernet de una forma lo suficientemente rápida como para permitir que las aplicaciones avanzadas como la IA funcionen correctamente. Al desagregar los componentes dentro de una caja de servidor y darles una forma de comunicarse con los protocolos API, los centros de datos pueden servir para aplicaciones complejas de manera rentable.
Los beneficios de la desagregación de la nube privada
Desagregar un centro de datos en la nube privada significa eliminar por completo el modelo de caja de servidor tradicional. Los componentes de recursos, como el almacenamiento en las CPU, las GPU, todos los niveles de memoria, las SSD y las HDD, se pueden desagregar y volver a componer a la medida dentro de sus estructuras adecuadas. Luego, estos recursos se pueden utilizar en función de las necesidades específicas de una aplicación, no en función de cómo se configuran los componentes dentro de un servidor físico específico. Todo a lo que se pueda acceder en una estructura de red se puede desagregar y luego volver a componer.
Por ejemplo, el grupo de recursos de almacenamiento en el que se basa una aplicación puede estar compuesto de unidades de disco duro en 10 bastidores de servidores diferentes en varias ubicaciones en un centro de datos. Si la aplicación necesita más almacenamiento del que está usando actualmente, una HDD puede simplemente comunicarse con otra HDD que tenga espacio y transmitir datos de manera ininterrumpida. La carga de trabajo de procesamiento también se puede cambiar dinámicamente cuando aumentan las demandas de la aplicación. Por el contrario, cuando las demandas de las aplicaciones disminuyen, el almacenamiento y el procesamiento se pueden reasignar de la manera más eficiente posible en términos de energía para reducir o eliminar el costoso aprovisionamiento excesivo.
Es un cambio radical de los sistemas JBOD, o simplemente un montón de discos, que se limita a un solo bastidor de servidor. Los JBOD se convirtieron en grupos a los que las aplicaciones pueden recurrir en cualquier momento, lo que hace que la asignación de recursos del centro de datos sea más inteligente. Luego, los arquitectos comenzaron a recurrir a un almacenamiento externo estandarizado que pudieran comunicarse con los demás.
La desagregación también introduce el monitoreo de interfaz estandarizado y permite a los arquitectos de TI administrar un centro de datos con una completa capacidad de composición. La selección de hardware basado en requisitos, ya sean SSD, HDD, CPU o componentes de estructura, es solo una parte de la desagregación del centro de datos tradicional y el cambio hacia la creación de uno con capacidad de composición. Los arquitectos aún requieren los protocolos API abiertos correctos, como Redfish o Swordfish, para una integración ininterrumpida y una única interfaz de usuario para administrar el centro de datos. Una API abierta permite que el hardware y el software que hablan diferentes idiomas se comuniquen y trabajen juntos.
Dejar que la aplicación defina cómo está compuesto el centro de datos, y no al revés, da como resultado redes definidas por software (SDN, por sus siglas en inglés) y el almacenamiento definido por software (SDS, por sus siglas en inglés). La próxima evolución de las SDN y el SDS es el centro de datos hipercompuesto. Esto podría poner la arquitectura de la nube privada a la par con algunos de los hiperescaladores como Amazon Web Services (AWS) y Microsoft Azure. Los hiperescaladores son grandes proveedores de centros de datos que pueden aumentar el procesamiento y el almacenamiento a una escala masiva. Las estructuras Ethernet, la columna vertebral de la red de un centro de datos, pueden incluso personalizarse para funcionar en conjunto con dispositivos HDD y SSD de baja latencia. Esta personalización reduce las demoras en el tráfico o el procesamiento de datos, ya que las aplicaciones pueden utilizar grupos de recursos desagregados que operan en tejidos de baja latencia.
Los protocolos API abiertos como Redfish y Swordfish son fundamentales para que todos los componentes desagregados funcionen en armonía. Seagate tiene su propia API de transferencia de estado representacional (REST, por sus siglas en inglés) heredada que mantiene para su clase específica de productos de centro de datos que promueven la operatividad entre dispositivos. En el pasado, cambiar los dispositivos para instalarlos e integrarlos podía llevar semanas. Los protocolos API permiten a los arquitectos de los centros de datos adoptar un enfoque de instalación automática a la medida para adquirir el hardware. Se pueden instalar y poner en funcionamiento nuevos dispositivos de distintos fabricantes en un tiempo récord.
Desagregar el centro de datos es lo que hace posible la composibilidad. Una vez que los arquitectos han elegido los dispositivos de hardware específicos para satisfacer sus necesidades de aplicaciones de software, pueden construir, operar y optimizar el centro de datos con la capacidad de composición del futuro.
La eficiencia de un centro de datos moderno y con capacidad de composición para la nube privada
La composibilidad del centro de datos no solo conecta todos los componentes desagregados, sino que también ayuda a mejorar los indicadores clave de rendimiento (KPI, por sus siglas en inglés) relacionados con la rentabilidad y el rendimiento de los centros de datos. En los centros de datos tradicionales, el aprovisionamiento excesivo representa una de las mayores pérdidas presupuestarias. Cuando los centros de datos tienen un aprovisionamiento excesivo, los servidores y los recursos se pagan pero no se utilizan. En esencia, los arquitectos de TI están pagando por grupos de recursos que se infrautilizan, lo que provoca que esas unidades de disco duro no estén aprovisionadas.
Los recursos desaprovisionados dan como resultado lo que se conoce como grupos huérfanos, o grupos de recursos que no tienen un hogar debido a la infrautilización. Esto puede incluir la CPU, la GPU, la matriz de puerta programable en campo (FPGA, por sus siglas en inglés), la memoria dinámica de acceso aleatorio (DRAM, por sus siglas en inglés), la SSD, la HDD o la memoria de clase de almacenamiento (SCM, por sus siglas en inglés). Estos elementos se componen dinámicamente para crear el hardware específico de la aplicación a través del API del software.
Antes de la arquitectura del centro de datos de código libre con capacidad de composición, las nubes privadas se construían normalmente con el hardware de un solo proveedor. Los centros de datos conectados físicamente son más costosos desde el principio y las organizaciones a menudo están atrapadas en una arquitectura que depende de un proveedor específico y que se vuelve costosa con el tiempo.
La tendencia de composibilidad comenzó a ganar fuerza como parte de las arquitecturas de nube pública. Productos como AWS y Microsoft Azure son dos ejemplos. Se puede adoptar un enfoque similar en términos de implementaciones de nube privada, ahorrando recursos monetarios al evitar depender de los proveedores y al acoplar centros de datos con dispositivos de múltiples proveedores.
Esto permite a los administradores de TI asignar más recursos presupuestarios a una mayor capacidad de almacenamiento que les permite extraer conocimiento y valor de los datos almacenados.
Las organizaciones ahora pueden usar una solución de almacenamiento de terceros, colocarla en su centro de datos e integrarla de manera ininterrumpida con una API de código libre. Si un arquitecto de TI quiere una SSD de un fabricante, pero su centro de datos está construido con componentes de un fabricante diferente, esa SSD puede colocarse en el centro de datos sin problemas. Las API garantizan que todos los componentes funcionen en conjunto. Los administradores de los centros de datos no necesitan obsesionarse con la forma en la que los componentes se comunicarán a través de la telemetría, por ejemplo, al reducir el costo y el estrés asociados con las piezas de los proveedores de los que el centro de datos no está compuesto actualmente.
Otro beneficio clave de la memoria agrupada o compartida es la oportunidad de que las aplicaciones sobrevivan ahora a una falla de nodo sin una interrupción del estado de las máquinas virtuales o de los contenedores de clústeres afectados por este nodo. La idea es que otros nodos ahora puedan copiar el último estado de la memoria de la máquina virtual en su propio espacio de memoria (en el caso de arquitecturas de memoria agrupadas) o usar un proceso de copia cero mediante la redirección del puntero a través de la estructura de latencia ultrabaja y continúen donde el nodo fallido los dejó sin problemas (en el caso de arquitecturas de memoria compartida). Esto puede considerarse una evolución significativa en las capacidades de tolerancia a fallas sin fisuras de los centros de datos para proporcionar una mayor fiabilidad y disponibilidad.
Una arquitectura componible también permite una recopilación y procesamiento más rápidos de datos de múltiples fuentes y, en general, un uso más eficiente de los recursos instalados. La arquitectura de la fuente de datos componible generalmente incluye sensores físicos, simulaciones de datos, información generada por el usuario y comunicaciones de telemetría. Los administradores de los centros de datos pueden entonces poner en marcha los recursos en cuestión de minutos, compartiéndolos entre aplicaciones sobre la marcha.
Una vista única de todos los recursos
Organizar y administrar un centro de datos en la nube privada también es más fácil con una arquitectura componible que utiliza un cliente de orquestación en contenedores. Todo el hardware se puede desagregar, componer y monitorear desde una única interfaz. Los administradores del centro de datos pueden obtener una imagen clara y en tiempo real de qué grupos de recursos se están utilizando y asegurarse de que no haya un aprovisionamiento excesivo. En muchos casos, la gestión se realizará con software estándar. Puede ser propietario o de código libre.
La implementación de nuevas aplicaciones de software en un entorno de código libre en contenedores también es más flexible, especialmente debido a la flexibilidad con la que se pueden comprar y distribuir los recursos de almacenamiento. Por ejemplo, los arquitectos de los centros de datos ya no necesitan sobreaprovisionar los costosos niveles de almacenamiento flash. Esto se debe a que cualquier carga de trabajo de la aplicación se puede cambiar instantáneamente a un conjunto existente de recursos de SSD según sea necesario, sin importar dónde se encuentre físicamente. Esto evita el aprovisionamiento excesivo, así como el espacio físico que se puede utilizar para otros fines, como una mayor capacidad de almacenamiento sin procesar.
La creación de más capacidad de almacenamiento sin procesar es cada vez más necesaria debido al crecimiento y la explosión de datos sin procesar. Además, las organizaciones se esfuerzan por obtener aún más valor y conocimientos prácticos a partir de más de esos datos para permitir nuevas oportunidades que mejoren los resultados finales. Lo que es crucial es que los arquitectos de TI puedan diseñar infraestructuras que recopilen, almacenen y transmitan cantidades masivas de datos. Los diseños de hardware informático más eficientes indican que hay más espacio disponible para el almacenamiento masivo sin procesar necesario para el entorno de grandes volúmenes de datos actual.
La solución es el centro de datos componible que conecta cualquier CPU y cualquier grupo de almacenamiento con otros dispositivos según sea necesario. Todos los demás dispositivos utilizan CSI, Redfish y Swordfish para conectarse a la red de gestión, orquestada por motores de software. Todos los demás elementos básicos del centro de datos se pueden componer dinámicamente para convertirse en aplicaciones específicas a través de la API de software.
Costo, rendimiento, eficiencia
La tendencia de desagregación y composibilidad en los centros de datos está impulsada por el costo, el rendimiento y la eficiencia. Atrás quedaron los días en los que la CPU era el centro del universo conocido, con todos los demás dispositivos metidos en la misma caja junto con ella. Los arquitectos de la nube privada ahora pueden elegir los dispositivos, el hardware y el software más apropiados según el caso de uso y las necesidades específicas.
Los centros de datos implementados en contenedores de clústeres tradicionales abrieron la puerta a las aplicaciones más complejas, pero el software actual tiene un rendimiento tan alto que se ha hecho necesaria una arquitectura más dinámica. Y en el futuro, las GPU, las FPGA y las memorias con capacidad de composición se habilitarán mediante interfaces de latencia ultrabaja.
La composibilidad indica que la carga de trabajo de procesamiento se distribuye en tiempo real, compartiendo la carga con dispositivos infrautilizados y eliminando grupos de datos huérfanos. El resultado es una infraestructura de nube privada completamente orquestada que ayuda a los centros de datos a procesar las cargas de trabajo más rápido y cuesta menos dinero para operar. Con la desagregación y la composibilidad, los arquitectos de TI pueden satisfacer las necesidades de las aplicaciones de software más exigentes. Un centro de datos con capacidad de composición es realmente más que la suma de sus partes.
