¿Qué son los sistemas distribuidos?

Los sistemas distribuidos dividen el trabajo y los datos en muchas máquinas que funcionan simultáneamente, por lo que un trabajo que podría haber tardado semanas en completarse, una máquina grande puede terminarlo en horas o incluso minutos. Cada máquina, o “nodo”, del sistema tiene su propia CPU, memoria y, a menudo, su propio almacenamiento. Los nodos pueden enviarse mensajes entre sí para coordinar el intercambio de datos, dividir el trabajo y combinarlo hacia un objetivo común.

En un sistema distribuido, las máquinas pueden residir en el mismo rack de servidores (de un centro de datos), en diferentes centros de datos o en entornos de nube híbrida repartidos por todo el mundo. Independientemente de la configuración, los sistemas distribuidos están diseñados para que los usuarios y las aplicaciones de los clientes interactúen con ellos como si se tratara de un solo servicio (“una base de datos”, “un sitio web”, “un servicio de almacenamiento”), no de un montón de servidores individuales.

Los sistemas distribuidos ofrecen a las empresas una solución a un desafío informático moderno apremiante. Muchas de las aplicaciones actuales son demasiado grandes, demasiado ocupadas o críticas para funcionar bien en una sola máquina. Estas aplicaciones manejan con frecuencia volúmenes masivos de datos y solicitudes que podrían abrumar a un solo servidor. Lidian con flujos de tráfico irregulares que requieren capacidades ágiles de balanceo de carga. Gestionan procesos de misión crítica en los que un tiempo de inactividad prolongado puede ser catastrófico (sistemas bancarios, por ejemplo).

Los sistemas distribuidos reparten las cargas de trabajo entre muchos nodos y pueden añadir automáticamente más nodos a la red según sea necesario. Esta escalabilidad permite al sistema dar cabida a más usuarios y más datos incluso cuando los flujos de tráfico son impredecibles. La escalabilidad de los sistemas distribuidos es la razón por la que las plataformas de streaming, por ejemplo, pueden dar servicio a millones de usuarios de todo el mundo, a menudo de forma simultánea.

Los sistemas distribuidos también pueden ayudar a optimizar la fiabilidad y la tolerancia a fallos de una arquitectura informática. Cuando un nodo falla, otros nodos pueden asumir su trabajo para que el servicio general siga funcionando. Esta característica reduce los puntos únicos de fallo y ayuda a las empresas a mantener sistemas de alta disponibilidad, lo cual es crucial para los sistemas que requieren un tiempo de actividad cercano al 100 %.

Además, en un sistema distribuido, los nodos separados cooperan estrechamente pero tienen sus propias bases de datos y sistemas de almacenamiento. Esta disposición facilita a los equipos de TI la creación de arquitecturas modulares en las que las diferentes partes del sistema pueden escalar y evolucionar de forma independiente.

Los sistemas distribuidos comprenden una gama de arquitecturas diferentes, pero todas comparten un conjunto de características básicas.

Para entender cómo funcionan los sistemas distribuidos, tomemos el ejemplo de los juegos multijugador masivos en línea (MMOG).

Los MMOG utilizan arquitecturas distribuidas en las que muchos servidores y nodos trabajan juntos para mantener un universo de juego persistente, de modo que miles de jugadores puedan volar, comerciar, luchar y explorar al mismo tiempo.

Debido a que el mundo del juego es enorme y el número de jugadores es muy alto, el backend del juego se divide en un clúster de máquinas en lugar de ser manejado por un solo sistema. Un conjunto de servidores rastrea las características del universo del juego (posiciones de los jugadores, daño, inventario), mientras que otras partes de la infraestructura gestionan el inicio de sesión del usuario, las características de chat y la persistencia del universo. La división ayuda a que el juego siga respondiendo incluso cuando muchos jugadores están activos en la misma región a la vez.

A lo largo de cada sesión de juego, el sistema debe mantener el estado del juego sincronizado entre todos los jugadores. Cuando un jugador actúa (mover un barco durante una batalla de flotas, por ejemplo), el cliente envía la acción al servidor apropiado para esa parte del mundo del juego. A continuación, el servidor actualiza el estado del juego compartido en tiempo real y comparte el resultado con los demás jugadores que necesitan verlo.

Además, el sistema de juego distribuido utiliza protocolos especializados para ayudar a garantizar que todos los jugadores vean los mismos eventos del juego aproximadamente al mismo tiempo.

Si un servidor falla durante el juego, los demás servidores están diseñados para tomar el relevo y continuar funcionando con normalidad para que los jugadores no tengan ninguna interrupción en su experiencia.

Los sistemas distribuidos son el opuesto funcional de los sistemas centralizados. Mientras que los sistemas distribuidos utilizan una colección de dispositivos para impulsar las operaciones, los sistemas centralizados dependen de un solo servidor principal.

En un sistema centralizado, un nodo central coordina la mayoría o todas las operaciones. Los clientes suelen enviar solicitudes a ese nodo, y el nodo decide cómo procesarlas. Esta dinámica hace que el sistema sea más fácil de entender porque la autoridad se encuentra en un solo lugar.

Sin embargo, un solo nodo significa un único punto de fallo. En un sistema centralizado, si el servidor central se cae, todo el sistema deja de estar disponible, por lo que la centralización puede presentar problemas significativos en situaciones en las que la alta disponibilidad es importante.

Los sistemas centralizados suelen escalar verticalmente. Si un equipo informático quiere mejorar el servidor principal, lo haría dotándolo de más procesadores, memoria o almacenamiento. Desafortunadamente, el escalado vertical no es una práctica sostenible a largo plazo. Con el tiempo, exige demasiado hardware y se vuelve demasiado caro.

Como tales, los sistemas centralizados son más adecuados para situaciones en las que la simplicidad arquitectónica y la supervisión centralizada importan más que una resiliencia ultraalta. La centralización se utiliza habitualmente para redes informáticas más pequeñas, sistemas empresariales internos, servidores de archivos y aplicaciones cliente-servidor en las que una autoridad necesita un control estricto.

En un sistema distribuido, ninguna máquina tiene el control total. Varios nodos cooperan, y cada nodo puede gestionar parte de la carga de trabajo o almacenar parte de los datos. La estructura es inherentemente más flexible, pero requiere coordinación entre nodos.

Los sistemas distribuidos son más tolerantes a los errores porque otros nodos pueden seguir funcionando si un nodo falla. Un sistema distribuido puede seguir fallando, pero tiende a degradarse de forma más gradual que un sistema centralizado.

Los sistemas distribuidos se basan en el escalado horizontal, en el que el sistema añade más máquinas para adaptarse a la creciente demanda de recursos.

En consecuencia, los entornos distribuidos suelen preferirse en situaciones en las que muchos usuarios, grandes conjuntos de datos o la dispersión geográfica hacen que una máquina central sea poco práctica. Los sistemas distribuidos son comunes para servicios web, plataformas en la nube, redes blockchain y servicios a gran escala que requieren alta disponibilidad y escalabilidad.

Los sistemas distribuidos se pueden agrupar en unos pocos tipos comunes, en función de cómo se organizan las máquinas y cómo se comunican.

En un sistema cliente-servidor, un servidor central (o un pequeño grupo de servidores) proporciona servicios, mientras que otras máquinas, los “clientes”, dependen del trabajo del servidor central.

El servidor central, a menudo la máquina más potente en términos de hardware, se encarga de gestionar los recursos compartidos (archivos, bases de datos, impresoras, cuentas de usuario). Los clientes suelen ser máquinas de usuarios finales (ordenadores portátiles, teléfonos móviles, navegadores) que se centran en interactuar con el usuario y gestionar solicitudes y respuestas.

Dado que los clientes y el servidor central se ejecutan en máquinas separadas y se comunican a través de una red, los sistemas cliente-servidor se consideran sistemas distribuidos. Sin embargo, la comunicación entre nodos en una arquitectura cliente-servidor está centralizada.

Cada cliente depende del servidor central para acceder a los recursos compartidos, y los clientes no hablan directamente entre sí sobre esos recursos. En su lugar, la comunicación entre los clientes y el servidor suele seguir un patrón de solicitud-respuesta.

Cuando el usuario realiza una acción (como hacer clic en un botón), el cliente convierte la acción en un mensaje de solicitud y lo envía a través de la red al servidor. El servidor recibe la solicitud, la procesa y luego devuelve una respuesta. A continuación, el cliente interpreta la respuesta y muestra el resultado al usuario de forma legible para los humanos.

Por ejemplo, una aplicación web puede utilizar un navegador (cliente) que envía solicitudes HTTP a un servidor web, que lee o escribe en una base de datos y luego envía una respuesta HTML o JSON.

La comunicación centralizada facilita la actualización de los sistemas cliente-servidor, la aplicación de las políticas de seguridad y la gestión de los datos. Sin embargo, la contrapartida es que la centralización puede crear cuellos de botella y puntos únicos de fallo.

En los sistemas peer-to-peer, todos los nodos, llamados “peers”, tienen roles aproximadamente iguales. Cada peer aporta parte de sus propios recursos y consume los recursos ofrecidos por otros peers. Todos los peers pueden solicitar recursos y proporcionarlos a otros nodos.

Por lo tanto, “cliente” y “servidor” en un sistema P2P son solo roles que desempeña temporalmente un nodo, no identidades fijas.

En un sistema puramente P2P, los peers se descubren entre sí y se comunican a través de una red superpuesta, una red lógica construida sobre conexiones físicas a internet. La red superpuesta decide quién habla con quién y cómo se enrutan los datos entre peers.

Cuando un peer necesita algo (un fragmento de archivo, por ejemplo), envía solicitudes directamente a otros peers que puedan tenerlo. Y cuando otro peer recibe la solicitud, puede responder y devolver los datos solicitados, actuando efectivamente como servidor en ese momento. Más tarde, los roles pueden intercambiarse y los mismos dos nodos pueden invertir quién proporciona datos y quién los solicita.

Como todos los peers pueden dar y recibir, las cargas de trabajo de proceso de datos tienden a distribuirse de forma más uniforme a lo largo de la red. Y a medida que se unen más peers, aportan más capacidad, lo que puede ayudar al sistema a escalar más fácilmente.

Las redes clásicas de intercambio de archivos son un buen ejemplo de sistemas P2P. El ordenador de cada usuario almacena fragmentos de archivos y los sube a otros nodos al tiempo que descarga los fragmentos que faltan.

Los sistemas P2P son más robustos frente a puntos de fallo únicos que los sistemas cliente-servidor. Si un peer se desconecta, todo el sistema suele seguir funcionando porque otros peers tienen copias de los datos o pueden enrutar los datos alrededor del nodo que ha fallado.

Los sistemas multinivel amplían el modelo básico cliente-servidor y lo organizan en múltiples capas claramente separadas, cada una con su propio trabajo. Las formas más comunes son de dos niveles, tres niveles y n.

Un sistema de dos niveles es una arquitectura cliente-servidor con otro nombre. El cliente contiene la mayor parte de la lógica de la aplicación y habla directamente con la base de datos del servidor para ejecutar consultas y actualizaciones. El proceso es sencillo, pero acopla estrechamente la interfaz de usuario a los datos. Cualquier cambio en la estructura de los datos puede forzar cambios en muchos otros clientes.

Las arquitecturas de tres niveles utilizan tres capas. La capa de presentación gestiona la interfaz de usuario (páginas web, IU móvil, IU de escritorio). La capa de aplicación, o “lógica empresarial”, implementa reglas y flujos de trabajo (validaciones, cálculos, decisiones). La capa de datos almacena y recupera datos de bases de datos distribuidas u otros sistemas de almacenamiento.

Los sistemas de N niveles amplían la idea de tres niveles añadiendo capas más especializadas. Por ejemplo, los equipos de TI podrían optar por crear una interfaz de programación de aplicaciones (API) separada o un nivel de servicio que exponga endpoints de REST o GraphQL. También podrían separar una capa de autenticación y una capa de cifrado para gestionar los inicios de sesión y los tokens de los usuarios.

Los niveles extra siguen el mismo principio que los tres primeros. Cada nivel tiene una responsabilidad principal y se comunican a través de interfaces bien definidas. Esta modularidad permite a los equipos trabajar, actualizar o sustituir los distintos niveles de forma independiente, tal vez incluso utilizando tecnologías diferentes para cada uno.

Los sistemas multinivel se utilizan habitualmente para ejecutar sitios web de comercio electrónico y aplicaciones bancarias.

Un clúster es un grupo de ordenadores situados cerca unos de otros que funcionan como si fueran una sola máquina más potente. Los nodos de un clúster están estrechamente acoplados, por lo que suelen estar:

• En el mismo lugar físico (la misma sala o centro de datos).
  
  
• Conectados con enlaces de alta velocidad, como redes de área local (LAN) de gran ancho de banda o interconexiones especializadas.
  
  
• Usando hardware y sistemas operativos similares o idénticos.

Como los nodos son similares y están bien conectados, el clúster puede dividir una tarea grande en partes más pequeñas para procesarlas en paralelo en diferentes nodos y luego combinar los resultados.

Los clústeres se gestionan mediante un software especial, como un middleware de clúster, un planificador o un gestor de recursos. El software decide qué nodos ejecutan qué trabajos, supervisa el estado de los nodos, gestiona el enrutamiento de los datos y equilibra las cargas de trabajo entre los nodos. Esta capa de gestión es lo que convierte “un montón de ordenadores en una red” en un clúster. Permite a los usuarios enviar un trabajo al clúster en su conjunto en lugar de iniciar sesión en cada máquina manualmente.

Los sistemas de clúster son útiles para situaciones que requieren una computación de alto rendimiento, como el análisis de big data, el entrenamiento de modelos de IA y las simulaciones científicas.

La computación en grid consiste en agrupar muchos ordenadores independientes, a menudo dispersos en diferentes ciudades y países, y hacer que cooperen en una única tarea computacional de gran tamaño.

Cada máquina participante en un grid puede pertenecer a una organización o individuo diferente. Todos pueden tener diferentes CPU, tamaños de memoria, sistemas operativos y políticas locales. No obstante, aceptan compartir algunos de sus recursos disponibles para problemas comunes.

Dado que un grid abarca varios dominios administrativos, ninguna organización posee o controla totalmente todas las máquinas. Esta es una diferencia fundamental entre grids y clústeres, donde una institución posee y gestiona servidores que viven en un solo centro de datos.

En un sistema de grid, cada nodo permanece autónomo. Puede unirse al grid o abandonarlo, tiene su propio gestor de recursos local y puede tener diferentes normas de seguridad o prioridades. El middleware del grid proporciona una capa común para enviar trabajos, descubrir recursos disponibles, programar trabajos, mover datos y recopilar resultados. Este middleware permite que todo el grid funcione como un superordenador virtual para los usuarios finales.

Cuando un usuario envía un trabajo grande (como una simulación de plegamiento de proteínas o un cálculo de riesgo financiero), el middleware divide automáticamente el trabajo en muchas tareas más pequeñas. Luego busca máquinas inactivas o infrautilizadas en cualquier parte del grid para asignarles partes del trabajo. Cada máquina funciona por su cuenta y, a continuación, devuelve los resultados que se combinan en la respuesta final.

Es importante destacar que los nodos de grid no se destinan únicamente al grid. Pueden ser ordenadores de sobremesa o servidores normales que donan ciclos de CPU de repuesto cuando no están ocupados con su trabajo local principal.

Los sistemas distribuidos basados en la nube se basan en centros de big data que operan los proveedores de servicios en la nube.

En lugar de poseer servidores físicos, las organizaciones alquilan recursos informáticos distribuidos a través de internet. Estos recursos se exponen como máquinas virtuales (VM), contenedores, bases de datos, colas y otros servicios gestionados.

Los sistemas en la nube son, sobre todo, elásticos. Las empresas pueden solicitar más capacidad de computación, almacenamiento o red cuando aumenta la carga de trabajo y liberar recursos cuando la carga disminuye. También permiten a las empresas pagar solo por los recursos que utilizan, en lugar de comprar el hardware por adelantado.

Con los sistemas en la nube, los equipos de TI pueden implementar procesos dinámicos de escalado horizontal. Los grupos de autoescalado (grupos lógicos de instancias de servidor idénticas) vigilan las métricas de la carga de trabajo para detectar fluctuaciones. Cuando una carga supera los umbrales establecidos, las herramientas de automatización ponen en marcha más instancias del servicio. Cuando la carga disminuye, cierra automáticamente las instancias adicionales para ahorrar dinero.

Las arquitecturas de microservicios son sistemas distribuidos a nivel de aplicación que utilizan múltiples componentes independientes que se ejecutan en diferentes máquinas para construir aplicaciones de software.

A diferencia de las aplicaciones monolíticas, ningún microservicio en una arquitectura de microservicios contiene toda la aplicación. En cambio, cada microservicio es su propio servicio pequeño (con su propio código y, por lo general, su propio almacén de datos) que es responsable de una capacidad específica y se ejecuta independientemente de otros contenedores.

Al ser independientes, los microservicios pueden desarrollarse, implementarse y escalarse por sí solos, pero las ventajas del sistema proceden de la colaboración entre los microservicios.

Cuando los usuarios envían una solicitud, el cliente crea un mensaje y lo envía a un dispositivo de edge (por ejemplo, un balanceador de carga o una pasarela API). El dispositivo de edge envía la solicitud al microservicio adecuado. El microservicio receptor lee el mensaje, ejecuta su propia lógica empresarial y, a continuación, envía una respuesta al dispositivo de edge, que la transmite al usuario.

Los sistemas distribuidos están omnipresentes en el mundo real. Muchas de las herramientas y servicios que la gente utiliza para el ocio, los negocios y la gestión financiera se basan en sistemas distribuidos.

• Escalabilidad: los sistemas informáticos distribuidos destacan por su escalabilidad horizontal, que permite a las empresas añadir simplemente más nodos a la red cuando crecen las cargas de trabajo, en lugar de invertir en costosas actualizaciones de un solo servidor.

• Fiabilidad y tolerancia a fallos: al eliminar los puntos únicos de fallo, los sistemas distribuidos proporcionan una redundancia integrada que mantiene las aplicaciones en funcionamiento para los usuarios, incluso cuando fallan nodos individuales.

• Eficiencia de recursos y ahorro de costes: las arquitecturas distribuidas permiten a las empresas construir potentes entornos informáticos utilizando clústeres de hardware estándar de bajo coste en lugar de costosos superordenadores especializados.

• Distribución y accesibilidad global: los sistemas distribuidos pueden implementar aplicaciones más cerca de los usuarios en todo el mundo, reduciendo la latencia al atender solicitudes de nodos geográficamente más cercanos.