Fabrizio Mario Corzo Acuña 202111240

Santiago Molina González 202112137

Josue Vega Valbuena - 202213040

Caso 4:

Dimensionamiento y Definición de la
Infraestructura Tecnológica Caso SUPEREPS

1. Entendimiento del problema

En este punto se identificarán los requerimientos de procesamiento y almacenamiento que
debe satisfacer la infraestructura, según la información.
1. Carga de trabajo: Identifique el tipo de transacciones que debe soportar la
infraestructura (tenga presentes los factores mencionados en clase: quién lo hace, qué
hace, cómo lo hace).
2. Para cada aplicación, identifique y cuantifique sus requerimientos de procesamiento
discriminados por tipo (desempeño, capacidad, escalabilidad o disponibilidad).
Justifique brevemente los requerimientos seleccionados para cada aplicación (qué
información usó, y cómo cuantificó)

1.1 Carga de Trabajo

a. Transacciones de Recepción de Documentos

• Quién lo hace: 500 funcionarios.

• Qué hace: Gestionan la recepción de documentos relacionados con trámites de salud,
utilizando un sistema de gestión de procesos de negocio (BPM) que encadena los
procesos de validación de datos.
• Cómo lo hace: Las transacciones son probablemente interactivas y frecuentes, con
una necesidad de respuesta rápida para mantener la eficiencia del flujo de trabajo.

b. Transacciones de Afiliación

• Quién lo hace: Entidad externa contratada.

• Qué hace: Reporta diariamente información de nuevas afiliaciones para ser
procesada en forma batch.
 • Cómo lo hace: Estas transacciones son intensivas en entrada/salida debido a la
actualización de las bases de datos con nueva información de afiliación.

c. Transacciones de Recaudo

• Quién lo hace: Operadores de recaudo a nivel nacional.

• Qué hace: Reportan diariamente las transacciones de recaudo para ser procesadas en
batch; también realizan conciliaciones financieras.
• Cómo lo hace: Intensivas en procesamiento y entrada/salida, especialmente hacia el
final del mes cuando el volumen de transacciones aumenta significativamente.

d. Consultas de Historia Médica

• Quién lo hace: IPS y afiliados.

• Qué hace: Las IPS consultan la historia médica para solicitar autorizaciones; los
afiliados la consultan para verificar su información médica.
• Cómo lo hace: Las transacciones requieren un tiempo de respuesta mínimo y son
realizadas frecuentemente a lo largo del día. Cada consulta es intensiva en acceso a
datos.

e. Pago a IPS

• Quién lo hace: La empresa a principios de cada mes.

• Qué hace: Procesa los pagos a las IPS, lo cual dura diez días en procesarse en forma
batch.
• Cómo lo hace: Debido al impacto social y financiero de estos pagos, estas
transacciones son críticas y requieren un alto nivel de fiabilidad y contingencia.

f. Consultas Web y Acceso a la Información

• Quién lo hace: Usuarios generales y afiliados a través del portal web.

• Qué hace: Los usuarios acceden al portal para obtener información sobre el sistema
de salud, consultar la historia médica, y realizar otras transacciones electrónicas.
• Cómo lo hace: Estas transacciones son realizadas a través de la interfaz web y deben
ser altamente disponibles y rápidas para garantizar una buena experiencia de usuario.
El sistema debe soportar un alto volumen de usuarios concurrentes, especialmente
durante horarios laborales y picos de acceso web.

g. Procesamiento de Pagos y Deudas

• Quién lo hace: La empresa, tratando con aportantes y afiliados.

• Qué hace: Gestiona y procesa información sobre pagos y deudas de las empresas
colombianas y trabajadores independientes.
• Cómo lo hace: Estas transacciones requieren un alto grado de seguridad y precisión,
dada la sensibilidad de la información financiera. Es crítico mantener la integridad y
confidencialidad de los datos a través de mecanismos robustos de seguridad y
respaldo.
h. Sincronización y Respaldo de Datos

• Quién lo hace: Sistemas de TI internos.

• Qué hace: Realiza respaldos regulares y sincroniza los datos entre el centro de datos
principal y el alterno.
• Cómo lo hace: Estas operaciones deben ser eficientes y discretas para no afectar el
rendimiento del sistema durante las horas pico. Es fundamental garantizar la
consistencia de los datos entre los sitios primarios y secundarios para la recuperación
ante desastres.

i. Manejo de Incidentes y Recuperación ante Desastres

• Quién lo hace: Equipos de TI en respuesta a incidentes.

• Qué hace: Gestiona incidentes que podrían afectar la disponibilidad o integridad de
los sistemas de información y datos.
• Cómo lo hace: Estas operaciones requieren una infraestructura de TI diseñada para
alta disponibilidad y resiliencia, con sistemas automatizados de alerta y mecanismos
de respuesta rápida para minimizar el tiempo de inactividad.

j. Actualizaciones y Mantenimiento del Sistema

• Quién lo hace: Equipos de TI.

• Qué hace: Realiza actualizaciones regulares del software y mantenimiento del
hardware para asegurar el funcionamiento óptimo del sistema.
• Cómo lo hace: Estas operaciones deben ser planeadas y ejecutadas de manera que
interfieran mínimamente con las operaciones diarias, posiblemente realizándose en
horarios de bajo uso.

k. Interacciones con Entidades Externas

• Quién lo hace: Sistema de la empresa interactuando con entidades de afiliaciones,

recaudo, Supersalud y el ministerio correspondiente.
• Qué hace: Intercambia datos y realiza transacciones con estas entidades para cumplir
con requisitos reglamentarios y operativos.
• Cómo lo hace: Estas transacciones requieren conexiones seguras y confiables para
el intercambio de datos, posiblemente utilizando servicios web o APIs con altos
estándares de seguridad.

1.2 Requerimientos
Abordaremos cada aplicación clave, cubriendo aspectos de almacenamiento y procesamiento
según las necesidades y los volúmenes de operaciones esperados.

Aplicación de Recepción de Documentos

 • Tipo de aplicación: BPM
• Descripción: Esta aplicación está diseñada para automatizar, monitorizar y optimizar
los procesos de negocio continuos, en este caso, la gestión y validación de
documentos recibidos. Un sistema BPM es adecuado aquí debido a la necesidad de
encadenar procesos de validación de datos e información de manera eficiente.
• Requerimientos de almacenamiento:
o Suposición: Cada transacción genera aproximadamente 10KB de datos
debido a la documentación digitalizada y la información del proceso.
o Cálculo: 500 funcionarios, asumiendo 100 transacciones diarias cada uno:
500*100*10KB*30 días/mes=150,000,000KB/mes o aproximadamente
144GB/mes.
o Almacenamiento promedio anual requerido: 144GB*12 = 1,728GB
• Requerimientos de procesamiento:
1. Procesar la validación de documentos en menos de 2 segundos (Desempeño).
2. Manejar múltiples solicitudes de transacciones simultáneamente con una
capacidad para escalar durante picos de trabajo (Capacidad).
3. Garantizar una disponibilidad del sistema del 99.99% durante las horas
laborales (Disponibilidad)
4. Automatización en la actualización de estados de trámite en tiempo real o
cuando se restablece la conectividad (Capacidad).

Proceso de Recaudo
• Tipo de aplicación: ERP
• Descripción: El proceso de recaudo maneja transacciones financieras, conciliaciones
y generación de reportes, lo que lo hace adecuado para ser manejado por un ERP. Los
sistemas ERP integran diversas funciones empresariales en un sistema unificado,
proporcionando una visión coherente y facilitando la gestión financiera y contable.
• Requerimientos de almacenamiento:
o Suposición: Cada transacción de recaudo genera aproximadamente 5KB,
teniendo en cuenta datos de transacciones y registros financieros.
o Cálculo: 800,000 transacciones en días pico:
800,000*5KB=4,000,000KB o 3.81GB en un día pico.
o Almacenamiento promedio anual requerido:
3.81GB*30 días/mes*12=1,369.2GB
• Requerimientos de procesamiento:
1. Conciliaciones financieras tripartitas en menos de 5 segundos por transacción
(Desempeño).
2. Actualizar registros de recaudo en tiempo real o tan pronto como se recupere
la conectividad (Desempeño).
3. Mantener una disponibilidad del 99.999% especialmente en días pico de
recaudo (Disponibilidad).
4. Notificaciones automáticas a los usuarios sobre el estado de sus transacciones
(Capacidad).

Historia Medica
 • Tipo de aplicación: Sistema de Información de Salud (Health Information System -
HIS)
• Descripción: Esta aplicación gestiona datos médicos y de salud de los afiliados,
permitiendo a los médicos y afiliados acceder y actualizar información médica en
tiempo real. Aunque se asemeja a un CRM en términos de gestión de relaciones con
clientes (pacientes en este caso), se clasifica específicamente bajo HIS debido a su
enfoque en datos de salud.
• Requerimientos de almacenamiento:
o Suposición: Cada consulta o actualización de la historia médica implica
aproximadamente 50KB debido a la inclusión de imágenes y textos médicos.
o Cálculo: 15,000 consultas diarias: 15,000*50KB=750,000KB o 732MB/día
o Almacenamiento promedio anual requerido: 732MB*365=267.18GB
• Requerimientos de procesamiento:
1. Proporcionar acceso a la información médica en menos de 3 segundos
(Desempeño).
2. Actualizaciones en tiempo real de las historias médicas post-consulta o
tratamiento (Desempeño).
3. Disponibilidad del sistema del 99.999% para garantizar acceso continuo
(Disponibilidad).
4. Generar alertas médicas inmediatas si hay desviaciones en los tratamientos
prescritos (Desempeño).

Pagos a IPS

• Tipo de aplicación: Sistema de Gestión Financiera

• Descripción: Similar al proceso de recaudo, el sistema de pagos a IPS se ocupa
principalmente de transacciones financieras, pero está específicamente adaptado para
gestionar pagos a proveedores de servicios de salud. Este podría ser un módulo
especializado dentro de un sistema ERP más amplio que gestiona compromisos
financieros y pagos.
• Requerimientos de almacenamiento:
o Suposición: Cada transacción de pago genera 20KB, incluyendo detalles de
transacciones y recibos.
o Cálculo: 500,000 transacciones en un día pico:
500,000*20KB=10,000,000KB o 9.54GB en un día pico.
o Almacenamiento promedio anual requerido: 9.54GB*12=114.48GB
(pagos mensuales).
• Requerimientos de procesamiento:
1. Procesar pagos en menos de 10 segundos por transacción (Desempeño).
2. Actualizar el estado del pago en tiempo real para garantizar transparencia
financiera (Desempeño).
3. Mantener una disponibilidad de sistema del 99.995% para asegurar la
continuidad de pagos (Disponibilidad).
4. Notificar automáticamente a las IPS sobre el estado de los pagos (Capacidad).
Portal Web

• Tipo de aplicación: Sistema de Gestión de Contenidos (CMS)

• Descripción: Este tipo de sistema es ideal para manejar las funciones descritas, como
proporcionar información accesible y gestionar las interacciones con los usuarios a
través de un portal web. Un CMS permitiría una gestión eficiente del contenido y
facilitaría la escalabilidad y el mantenimiento del sistema.
• Requerimientos de almacenamiento:
o Suposición: Las consultas y el acceso a la información generan un registro de
actividades y caché de datos para mejorar la eficiencia y la velocidad de
respuesta. Cada sesión de usuario puede generar aproximadamente 2KB de
datos almacenados por consulta debido a registros de actividad y preferencias
de usuario.
o Cálculo: Suponiendo 8,000 usuarios diarios con un promedio de 10 consultas
por usuario: 8,000*10*2KB=160,000KB o aproximadamente 156MB/día.
o Almacenamiento promedio anual requerido: 156MB*365 = 56.94GB

• Requerimientos de procesamiento:
1. Proporcionar respuestas en menos de 3 segundos para consultas de
información y accesos web, asegurando una experiencia de usuario fluida y
eficiente. (Desempeño)
2. Manejar picos de tráfico especialmente durante horas laborales y eventos de
alto tráfico sin degradación del servicio. (Capacidad)
3. Garantizar una disponibilidad del sistema de al menos 99.99%, con
redundancia y mecanismos de recuperación rápida para minimizar el tiempo
de inactividad. (Disponibilidad)

2. Selección de la infraestructura
De acuerdo con las transacciones y los requerimientos especificados en el punto A:
1. Para cada aplicación, especifique cuál es la problemática más relevante: desempeño,
capacidad, escalabilidad o disponibilidad. Tenga presente que pueden ser varias
problemáticas (o ninguna si se trata de un caso “corriente” que no requiere de medidas
especiales). Justifique sus afirmaciones (por qué sí o por qué no) con los
requerimientos antes planteados. Para los requerimientos de disponibilidad, recuerde
que el cliente no siempre los cuantifica adecuadamente. Para este caso usemos
soluciones de 4 nueves de disponibilidad para responder al requerimiento.
2. Acorde con lo anterior, para cada aplicación (o grupo de aplicaciones), defina qué
tipo de infraestructura se puede utilizar para soportar la problemática en cuestión. En
particular, especifique:
 a. Si es necesario contar con un clúster de servidores, con qué propósito
(desempeño, capacidad, escalabilidad, disponibilidad), y qué tipo de clúster
(failover, balanceo de carga, de aplicación, etc.).
b. Además de enunciar el tipo de clúster, debe describir sus características: capas
que lo componen, tipo de balanceadores de carga (si hay), componentes
replicados, cómo se espera tratar el estado, etc.

2.1
Aplicación de Recepción de Documentos
Problemáticas relevantes: Desempeño, Capacidad y Disponibilidad
• Desempeño: Se requiere procesar la validación de documentos en menos de 2
segundos para mantener la eficiencia del flujo de trabajo.
• Capacidad: Debe manejar múltiples solicitudes de transacciones simultáneamente y
escalar durante picos de trabajo.
• Disponibilidad: Se requiere una disponibilidad del 99.99% durante las horas
laborales, para asegurar que los funcionarios puedan realizar su trabajo sin
interrupciones significativas.

Proceso de Recaudo
Problemáticas relevantes: Desempeño, Capacidad y Disponibilidad
• Desempeño: Se requieren conciliaciones financieras tripartitas en menos de 5
segundos por transacción y actualización de registros en tiempo real.
• Capacidad: Debe soportar 800.000 transacciones en días pico y notificar
automáticamente a los usuarios.
• Disponibilidad: Se requiere una disponibilidad del 99.999% en días pico de recaudo,
para mejorar el volumen elevado de transacciones sin fallos.

Historia Medica
Problemáticas relevantes: Desempeño y Disponibilidad

• Desempeño: Debe proporcionar acceso a la información médica en menos de 3

segundos, dándole un acceso a la información médica rápido.
• Disponibilidad: Se requiere una disponibilidad del 99.99% para garantizar que tanto
la IPS como los afiliados puedan acceder a la información médica en cualquier
momento.
Pagos a IPS
Problemáticas relevantes: Desempeño y Disponibilidad

• Desempeño: Debe procesar pagos en menos de 10 segundos por transacción y

actualizar el estado de pago en tiempo real.
• Disponibilidad: Se requiere una disponibilidad del 99.995% para asegurar que los
pagos se realicen de manera oportuna y sin interrupciones.

Portal Web
Problemáticas relevantes: Desempeño, Escalabilidad y Disponibilidad
• Desempeño: Se asume que debe tener un buen tiempo de respuesta ara garantizar una
buena experiencia al usuario.
• Escalabilidad: Se asume que la infraestructura debe ser capaz de manejar un alto
volumen de usuarios concurrentes, especialmente durante los picos de acceso web.
• Disponibilidad: Debe estar disponible los siete días de la semana entre 7:00 am y 10
pm, por lo que se puede asumir un requisito de alta disponibilidad, como 99.99%

2.2
Aplicación de Recepción de Documentos (BPM)

Se requiere un clúster de servidores de aplicación de balanceo de carga para abordar las

problemáticas de desempeño, capacidad y disponibilidad.

Características

• Clúster de servidores de aplicación BPM en una configuración activo-activo.

• Balanceador de carga para distribuir las solicitudes de validación de documentos
entre los servidores del clúster.
• Replicación de estado de flujos de trabajo y datos de procesos entre los nodos del
clúster para garantizar la consistencia.

Proceso de Recaudo (ERP)

Se requiere un clúster de servidores de aplicación de balanceo de carga para abordar las

problemáticas de desempeño, capacidad y disponibilidad.

Características
 • Clúster de servidores de aplicación ERP en una configuración activo-activo.
• Balanceador de carga para distribuir las transacciones de recaudo entre los nodos
del clúster.
• Replicación de datos financieros y estado de transacciones entre los nodos del
clúster.
• Sesiones distribuidas o almacenamiento compartido para asegurar que las
actualizaciones se reflejen en todos los servidores de manera consistente.

Historia Médica (HIS)

Se requiere un clúster de servidores de aplicación de balanceo de carga para abordar las

problemáticas de desempeño y disponibilidad.

Características

• Clúster de bases de datos en una configuración activo-activo.

• Balanceador de carga para distribuir las consultas y actualizaciones de historiales
médicos entre las instancias de base de datos.
• Replicación de datos de historiales médicos entre las instancias del clúster.

Pagos IPS (HIS)

Se requiere un clúster de servidores de aplicación con balanceo de carga y failover para

abordar las problemáticas de desempeño y disponibilidad.

Características

• Clúster de servidores de aplicación en una configuración activo-pasivo.

• Balanceadores de carga para distribuir las solicitudes de procesamiento de pagos
entre los servidores de aplicación.
• El nodo activo maneja todas las transacciones de pago a IPS.
• Replicación de datos financieros y estado de transacciones entre los nodos activo y
pasivo.
• En caso de falla del nodo activo, el nodo pasivo asume automáticamente la carga de
trabajo.

Portal Web
Se requiere una granja de servidores web con clúster con balanceo de carga y failover para
abordar las problemáticas de desempeño, escalabilidad y disponibilidad.
Características

• Granja de servidores web en una configuración activo-activo.

• Balanceador de carga para distribuir las solicitudes web entre los servidores de la
granja.
• Capacidad de escalar horizontalmente agregando más servidores web a la granja
según sea necesario.
• Replicación de sesiones de usuario y datos de aplicación entre los servidores de la
granja.
• Servidores web redundantes configurados para failover automático en caso de falla
de un servidor.

2.3 Capacidad De la Máquina Virtual

Para efectos de probar la infraestructura actual de la compañía SUPER EPS, se

implementaron ciertas pruebas de carga con el objetivo de ver cuál es la carga que soportan
el servidor y cuantos usuarios recurrente procesa

Especificamente se probó el servidor web con URL: http://172.65.69/proceso_c con el

objetivo de probar las diferentes cargas que podría soportar este servicio
Las métricas para analizar se basaron en el tiempo promedio de respuesta de cada petición,
es decir, cuánto tiempo se demora en responder cada petición enviada al servidor. En este
caso específico la compañía nos pide un tiempo no mayor a 4 segundos, por lo cual se desea
probar cuantas peticiones concurrentes puede el servidor soportar sin sobre pasar esta métrica
Además, se busca que, de todas las peticiones enviadas al servidor, se espera que el 94 % de
estas se completen correctamente, permitiendo un rango del 6 % de peticiones que puedan
no funcionar o que el servidor les devuelva un código HTTP diferente al 200 que aseguraría
que la petición se hizo con éxito.
Los indicadores de interes en los que nos basamos para las metricas fueron:
• Número de Peticiones que se le envía al servidor
• Tiempo de respuesta promedio para cada petición por parte del servidor
En la siguiente tabla se evidencia los datos que se tomaron, con una columna adicional que
representa el porcentaje de error de peticiones que no tuvieron éxito. Para este caso
evidenciamos que todas las pruebas que corrimos tenian un 0% de error por lo cual todas las
peticiones fueron aceptadas.

TABLA CON DATOS DE PRUEBAS DE CARGA

 #Threads TiempoRespuesta ERR
100 0,253 0%
130 0,54 0%
150 1,027 0%
162 1,825 0%
180 0,921 0%
200 1,169 0%
220 1,479 0%
250 1,892 0%
280 2,016 0%
300 1,93 0%
320 2,23 0%
350 2,398 0%
380 2,26 0%
400 2,402 0%
420 2,831 0%
428 2,85 0%
450 2,732 0%
480 2,854 0%
500 3,105 0%
520 3,261 0%
538 3,021 0%
550 3,044 0%

Con estos datos se van a hacer los diferentes análisis parala infraestructura actual de la
compañía buscando cumplir con los objetivos que se plantearon

• Tiempo de respuesta por petición < 4 segundos

• Porcentaje de fallas en peticiones < 6%
Para esto se hizo el análisis de los datos mediante una gráfica de dispersión que busca
expresar cómo se comportan los datos según aumentan la cantidad de peticiones hacia el
servidor y aumenta o disminuye el tiempo dependiendo de esta variable.

GRAFICA DATOS
NUMERO PETICIONES VS TIEMPO DE RESPUESTA
En este caso evidenciamos la gráfica de Numero de Threads o peticiones al servidor,
contrastado con el tiempo de respuesta promedio que se le hace a cada petición que se envía.

• Justificar si este tipo de regresión lineal es óptimo para proyectar la infraestructura

ante un posible incremento de la carga
En este caso implementamos una regresión linear sobre los datos, porque esta regresión nos
ayuda a describir cómo los datos se comportan según aumentan las peticiones. Además de
esto el modelo de regresión lineal se puede usar para predecir el valor de la variable
dependiente para valores de la variable independiente, donde la variable independiente y
dependiente corresponden a el número de peticiones y el tiempo de respuesta promedio
respectivamente.
Dado el análisis que estamos implementando observamos que la predicción de estos datos
para visualizar en qué punto el tiempo de respuesta promedio sobre pasa el límite de tiempo
de respuesta promedio (4 segundos), el modelo de regresión lineal nos ayudara para cumplir
nuestro objetivo principal. A partir de lo recolectado anteriormente, se puede hacer el
siguiente análisis, mediante la gráfica observamos un punto especifico en el número de
peticiones, con 678 peticiones donde el sistema empieza a degradar el tiempo de respuesta,
y el promedio entre las peticiones está en 4 segundos. Por lo que el sistema ya no cumple con
las expectativas que definimos.
De la misma forma para la métrica de 94% de peticiones exitosas, evidenciamos a través de
diferentes tomas de datos, que el servidor tiende a aceptar todas las solicitudes GET, den
donde ante gran cantidad de peticiones se evidencia que el error de peticiones no exitosas
permanece en 0%, especialmente se hicieron pruebas con 10.000 y 100.000 peticiones al
servidor y en ambos casos se evidencio un error de peticiones no exitosas del 0%. Se
evidencia que el servidor actual se desempeña muy bien en este aspecto.
 • Determinar el número de instancias que serían necesarias para procesar 4000
peticiones dentro del límite esperado suponiendo condiciones de linealidad
Adicionalmente para determinar el número de instancias que podrian ser necesaria, podemos
hacer algunos calculos sencillos para determinar que puedan soportar las las 4000 peticiones
que necesitamos. Primero que todo para que estas instancias puedan obtener una ventaja se
debe distribuir la carga entre estas mismas por lo cual necesitamos un balanceador de carga
que nos pueda facilitar esta tarea. A partir de esto sabemos que para cada instancia el número
máximo de peticiones para que cumplan a cabalidad la restricción de tiempo de respuesta
esperado para cada petición es de 678 peticiones.

Por lo cual para cada instancia como máximo debemos distribuir 678 peticiones, si tenemos
4000 peticiones para distribuir entre las diferentes instancias entonces hacemos la siguiente
operación:
4000
= 5,89 instancias
678

Es el número mínimo de instancias para cumplir la restricción, por lo que, aproximando,

necesitamos 6 instancias en las que se pueda distribuir la carga de 4000 peticiones.

3. Diagrama general de la infraestructura

En el diagrama presentado evidenciamos la UI del usuario junto a las diferentes aplicaciones

y como corren en los servidores de la compañía, debido a que estamos buscando una solución
óptima para la compañía que refleje la infraestructura y que no derroche en costos agrupamos
las peticiones que se le pueden hacer a las diferentes aplicaciones para ser más claros con el
proceso.

En primer lugar, evidenciamos las peticiones que se le hacen a tres aplicaciones,

específicamente la recepción de documentos o el BPM, el proceso de recaudos que sería el
ERP y la historia Medica que busca que se consulten las historias clínicas de los clientes A
partir de esto podemos observar que existe un balanceador de carga que distribuye las
peticiones hacia los servidores de la compañía. En especial, estos servidores corren los
procesos de estas tres aplicaciones, dado que no comparten datos, lo representamos como el
servidor que funciona para estos tres procesos y peticiones que envían el usuario o los
empleados. Evidenciamos el balanceo de carga debido a las especificaciones en la selección
de infraestructura y donde se decidió que la mejor forma de solucionar los requerimientos
que solicitaba cada aplicación se implemente el balanceador de carga.

Acá evidenciamos las peticiones que se mandan a dos aplicaciones específicas las cuales son
los PAGOS IPS que son las transacciones que recibe la compañía y el portal web de esta
misma, dado que estas dos aplicaciones no comparten datos y si comparten tácticas por lo
cual las ponemos a correr en el mismo servidor y aplicamos las mismas tacticas sobre estos.
Esto se hace con el objetivo de mejorar los costos para la compañía y no tener que
implementar dos clústeres de servidores nuevos si queremos direccionar las peticiones del
portal web a un nuevo servidor. A partir de esto se evidencia que cada petición que llegue a
alguna de las dos aplicaciones se envía al balanceador de carga específico para después tener
dos clústeres de servidores con el objetivo de implementar una táctica de failover, esto con
el objetivo de mejorar la tolerancia a fallos de estos servicios.