Arquitecturas de Clustering para Aplicaciones Empresariales: Escalabilidad y Disponibilidad

Los arquitectos de aplicaciones empresariales (AE) a menudo se enfrentan a desafíos al diseñar aplicaciones escalables que puedan satisfacer la creciente demanda de usuarios y brindar disponibilidad las 24 horas del día, los 7 días de la semana. En este artículo, explicaré el significado de la escalabilidad y disponibilidad en AE y exploraré diferentes arquitecturas para lograr estos objetivos.

Escalabilidad

La escalabilidad es la capacidad de una aplicación de soportar un número creciente de usuarios. Es una medida de una serie de factores, como el número de usuarios simultáneos que un clúster puede soportar y el tiempo que lleva procesar una solicitud. Si a PetWebStore le toma de 10 a 30 milisegundos (ms) responder a una solicitud, ¿cuánto tiempo tomará responder a 10,000 solicitudes concurrentes? La escalabilidad infinita permitiría responder a ese gran número de solicitudes en 10 a 30 ms, pero en el mundo real está en algún punto entre 10 ms y un bloqueo. Las aplicaciones bien diseñadas deben poder cumplir con los objetivos de rendimiento a pesar del crecimiento del número de usuarios.

Disponibilidad

La alta disponibilidad se puede definir como redundancia. En el caso de PetWebStore, si un servidor falla mientras maneja solicitudes, otros servidores del clúster deben poder manejar esas solicitudes de la manera más transparente posible. Un servidor fallido se elimina del clúster tan pronto como falla para que las futuras solicitudes no se direccionen al servidor fallido. En AE, la conmutación por error, la resiliencia y la disponibilidad son de suma importancia.

Para lograr la escalabilidad y disponibilidad en AE, utilizamos equilibradores de carga y agrupamos las aplicaciones en diferentes niveles.

Niveles de aplicaciones empresariales

Las aplicaciones empresariales en el lado del servidor se pueden dividir en varios "niveles" lógicos. Estos niveles son divisiones lógicas de los servicios de la aplicación y no necesariamente divisiones físicas entre hardware y software. En algunos casos, todos estos niveles pueden estar ejecutándose en la misma máquina.

Nivel web

Este nivel proporciona contenido estático (páginas HTML estáticas) al cliente. Normalmente, este es el frente de AE. Una AE simple tiene un nivel web que puede tener una o varias máquinas ejecutando Apache, Netscape Enterprise Server o IIS. El equilibrador de carga pasa las solicitudes al nivel web.

Cómo abrir una instancia específica de un formulario en C# .NET

Nivel de presentación

El nivel de presentación proporciona contenido dinámico (es decir, servlets o JSP) a los clientes de AE. Generalmente, el nivel de presentación comprende un clúster de servidores (es decir, Tomcat, WebLogic, WebSphere, etc.) que aloja servlets y / o JSP. Si el clúster también sirve páginas HTML estáticas para su aplicación, abarca tanto el nivel web como el nivel de presentación.

Nivel de objeto

El nivel de objeto proporciona objetos Java (es decir, EJB, clases RMI, grupo de conexiones JDBC, etc.) y su lógica empresarial asociada a una aplicación empresarial. Un clúster de servidores compatible con J2EE que aloja EJB proporciona un nivel de objeto (como WebLogic, WebSphere, Jboss, etc.).

Al agrupar lógicamente estos niveles en uno o varios niveles, podemos obtener diversas arquitecturas de agrupación.

Arquitectura de agrupación

En base a los niveles lógicos mencionados anteriormente, tenemos varias arquitecturas para agrupar AE. La selección de la arquitectura para una AE depende en gran medida del patrón de uso y del tipo de aplicación. PetWebStore tiene contenido estático y dinámico y una gran actividad de transacciones / comercio electrónico. Por lo tanto, vemos un uso intensivo de los tres niveles.

Agrupación de un solo nivel (agrupación básica)

La agrupación de un solo nivel es la forma más simple de agrupación. En esta arquitectura, cada máquina del clúster ejecuta todos los niveles simultáneamente (Ver Figura A). El equilibrador de carga distribuye las solicitudes a los servidores del clúster. La agrupación básica es fácil de administrar. El rendimiento es alto porque todos los niveles están ubicados en el mismo lugar, por lo que no hay tráfico de red para la comunicación entre niveles. También es muy fácil de escalar.

Figura A

Agrupación básica

Esencialmente, el equilibrador de carga distribuye las solicitudes del cliente al servidor, en la mayoría de los casos a través de una distribución round-robin. No considera el uso de recursos para el equilibrio de carga. Por lo tanto, en esta arquitectura, los servidores pueden tener una carga desigual en algún momento, lo que puede degradar el rendimiento del servidor. Además, en caso de una falla del servidor durante el procesamiento de una solicitud, esta puede ser visible para el cliente porque el servidor no puede transferir las solicitudes a otros servidores en caso de falla.

Cómo calcular el último día del mes en Visual Basic

Por lo tanto, en esta arquitectura, las oportunidades para proporcionar equilibrio de carga y resistencia a fallos se reducen. Esta arquitectura se utiliza con menos frecuencia en aplicaciones empresariales.

Agrupación de dos niveles

En la agrupación de dos niveles, los tres niveles básicos se agrupan en dos niveles lógicos. Dado que tenemos más niveles que grupos lógicos y nuestros niveles pueden funcionar solo en una secuencia específica, tenemos dos formas de agrupar los tres niveles en dos con las condiciones descritas anteriormente.

En esta arquitectura, los niveles web y de presentación se ejecutan en máquinas individuales, trabajando en conjunto en un clúster llamado clúster de servidor web. El nivel de objeto se ejecuta en todas las máquinas simultáneamente en el clúster (Ver Figura B). En este caso, el nivel de presentación y el nivel de objeto se encuentran en máquinas diferentes, por lo que tenemos la oportunidad de equilibrar la carga en el nivel de objeto. Esto se logra utilizando stubs o replicaciones conscientes; el servidor de aplicaciones crea estos stubs durante la implementación de los objetos (EJB). Los stubs conscientes de la réplica conocen otros servidores en el clúster que alojan objetos y contienen un algoritmo de equilibrio de carga. Todas las llamadas de método al nivel de objeto se equilibran de carga mediante stubs o replicaciones conscientes. Por lo tanto, en esencia, estos stubs funcionan como el equilibrador de carga entre los niveles de presentación y objeto.

Figura B

Agrupación de dos niveles con niveles en máquinas individuales

La agrupación de dos niveles se utiliza ampliamente en diferentes aplicaciones empresariales. Supongamos que estamos implementando una librería en línea. ¿Cómo utilizan los visitantes la librería en línea? Van a la página de inicio, que es contenido estático o quizás dinámico, por lo que usaremos el nivel web. Los usuarios buscarán un libro, por lo que usaremos el nivel de presentación para crear una página dinámica. Los usuarios también pueden leer reseñas de libros de otros lectores, que pueden ser contenido estático o dinámico. Luego pueden decidir realizar una compra, por lo que usaremos el nivel de objeto (EJB, etc.) en este punto.

A partir del patrón de uso, podemos ver que la mayoría de los clientes utilizarán los niveles web y de presentación en una sesión, por lo que podemos combinar estos dos niveles en un solo clúster. Dado que el uso del nivel de objeto es independiente del nivel web o del nivel de presentación, podemos mantener el nivel de objeto en otro clúster. Con esta arquitectura, tenemos dos niveles de equilibrio de carga y podemos lograr alta escalabilidad y disponibilidad para nuestra aplicación de librería en línea.

En la Figura B, los niveles web se ejecutan en cada servidor del clúster de servidores web. Los niveles de presentación y objeto se ejecutan en conjunto en cada máquina del clúster. El equilibrador de carga distribuye las solicitudes del cliente al nivel de servidor web, que sirve solo contenido estático. Las solicitudes de contenido dinámico se envían a través del complemento de proxy al clúster del servidor de aplicaciones.

Cómo reemplazar un archivo con el comando REPLACE en Windows

Figura C

Agrupación de dos niveles con niveles en una sola máquina

En la Figura C, el complemento de proxy realiza el equilibrio de carga (distribución round-robin) entre los niveles web y de presentación. Pero los niveles de presentación y objeto se ejecutan en la misma máquina, por lo que en esta arquitectura las oportunidades de equilibrar la carga entre los niveles de presentación y objeto se reducen. Debido a esto, se prefiere la arquitectura de la Figura B.

Agrupación multitier

En la agrupación multitier, cada nivel (web, presentación y objeto) se ejecuta en una máquina separada, y cada nivel forma un clúster de sus propias máquinas. En esta arquitectura, tenemos tres niveles de equilibrio de carga:

• Equilibrio de carga antes del clúster del servidor web
• Equilibrio de carga entre los niveles web y de presentación a través del complemento de proxy
• Equilibrio de carga entre los niveles de presentación y objeto a través de stubs o replicaciones conscientes

Figura D

Clúster multitier

La Figura D contiene la arquitectura más compleja y difícil de administrar que hemos discutido hasta ahora en este artículo, pero es la más escalable y altamente disponible. Para una aplicación donde el uso de cada nivel es diferente y hay un gran número de clientes, esta arquitectura puede ser la mejor opción.

En PetWebStore, el patrón de uso sería algo así: El cliente accede a la página de inicio y lee sobre las diferentes especies de mascotas y productos de alimentación para mascotas. Esto es en gran medida contenido estático, por lo que usamos el nivel web. El cliente luego puede buscar productos para mascotas o verificar la disponibilidad de mascotas. Esto es contenido dinámico, por lo que usamos el nivel de presentación para crear una página dinámica. Luego, el cliente puede decidir realizar una compra. En este punto, utilizamos el nivel de objeto.

En esta aplicación, el uso de cada nivel es diferente. Anticipamos un gran número de clientes, por lo que la arquitectura multitier es la mejor opción para la implementación de PetWebStore. Como podemos ver, para esta aplicación es probable que el mayor número de clientes acceda al nivel web, un número menor acceda al nivel de presentación y aún menos acceda al nivel de objeto. Por lo tanto, el número de servidores en cada clúster puede variar según el patrón de uso de cada nivel.

Por qué utilizar un iterador en Java en lugar de una lista o un array

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Desarrollo, allí encontraras muchos artículos similares a Arquitecturas de Clustering para Aplicaciones Empresariales: Escalabilidad y Disponibilidad , tenemos lo ultimo en tecnología 2023.