1
00:00:00,000 --> 00:00:08,000
En este tema vamos a hablar de implantación y soluciones de alta disponibilidad.

2
00:00:09,539 --> 00:00:14,839
Objetivo de la unidad sería analizar las distintas configuraciones de alta disponibilidad,

3
00:00:15,859 --> 00:00:20,480
comprender la importancia de un buen análisis de riesgos en sistemas críticos

4
00:00:20,480 --> 00:00:22,739
y aprender a solventar posibles problemas.

5
00:00:24,280 --> 00:00:27,960
¿Cuáles son las soluciones para la alta disponibilidad?

6
00:00:27,960 --> 00:00:49,579
Pues, tendríamos una serie de características que nos van a dirigir para buscar esas soluciones. Esas claves serían el funcionamiento ininterrumpido, la duplicidad de las comunicaciones, almacenamiento redundante, balanceo de carga, virtualización de sistemas.

7
00:00:49,579 --> 00:00:54,600
y objetivo sería asegurar la continuidad del sistema sin interrupciones

8
00:00:54,600 --> 00:00:58,420
basado en la replicación de elementos asequibles, lo veremos,

9
00:00:58,600 --> 00:01:01,420
y alternativa a sistemas individuales tolerantes a fallos.

10
00:01:03,009 --> 00:01:04,109
¿Qué tipo de sistemas hay?

11
00:01:04,609 --> 00:01:07,930
Tenemos sistemas de alta disponibilidad y sistemas tolerantes a fallos.

12
00:01:08,530 --> 00:01:13,909
Los sistemas de alta disponibilidad son los que se pueden provocar tiempos inactivos,

13
00:01:14,129 --> 00:01:16,150
puede haber variamientos en el que esté inactivo.

14
00:01:17,709 --> 00:01:20,549
En cambio, los sistemas tolerantes a fallos detectan la parte que falla,

15
00:01:20,549 --> 00:01:25,250
toman medidas para restablecer los servicios rápidamente, entonces el impacto tiene que ser mínimo.

16
00:01:25,829 --> 00:01:33,689
En los sistemas de alta disponibilidad es más asequible que los tolerantes a fallos y la línea entre ambos sistemas es verdad que cada vez es más difusa.

17
00:01:36,230 --> 00:01:47,989
Con lo cual, tenemos que alta disponibilidad puede aceptar pequeñas interrupciones, tolerancia a fallos, se quiere evitar toda interrupción que pueda producirse.

18
00:01:47,989 --> 00:02:14,610
Bien, objetivo, hemos dicho que era evitar interrupciones en sistemas críticos. ¿Qué tipo de interrupciones hay? Hay interrupciones previstas e imprevistas. Bien, lógicamente las previstas son las que ocurren cuando se paraliza el sistema para hacer una actualización, una mejora o se puede planificar para minimizar el impacto.

19
00:02:14,610 --> 00:02:24,430
En cambio, las imprevistas pueden ser de distinta índole, apagones, fallos de hardware, de software, problemas de seguridad, etc.

20
00:02:24,729 --> 00:02:33,229
Parámetros claves en la alta disponibilidad, vamos a hablar de tres tiempos, que serán el tiempo entre fallos, el tiempo de recuperación y el tiempo fuera de servicio.

21
00:02:34,210 --> 00:02:45,150
Bien, el tiempo entre fallos, sería el MTTF, sería aquel que se mide en el tiempo medio hasta que un dispositivo falla.

22
00:02:45,870 --> 00:02:52,050
Entre el MTTR o tiempo medio de recuperación es el que mide el tiempo medio en restablecer el sistema.

23
00:02:52,169 --> 00:02:55,909
Lo que tarda el sistema, una vez que ha caído, en restablecerse.

24
00:02:55,909 --> 00:03:03,909
El tiempo fuera de servicio es una fórmula matemática que implicaría la proporción de tiempo que el sistema no está disponible.

25
00:03:04,669 --> 00:03:09,569
Y sería el cociente entre el tiempo de recuperación y el tiempo entre fallos.

26
00:03:12,569 --> 00:03:16,650
Nivel de disponibilidad mide el tiempo inactivo de un sistema.

27
00:03:16,650 --> 00:03:37,349
Y el objetivo ideal es que tengamos cinco minutos de inactividad por año tan solo. Ejemplo de sistemas críticos, pues hay infinidad, pero bueno, aquí pongo algunos, que serían los hospitales, el control aéreo, transporte marítimo, instalaciones militares, universidades, instituciones públicas, comercio electrónico y sistemas bancarios.

28
00:03:37,349 --> 00:03:53,680
Funcionamiento ininterrumpido. Hay que decir que para tener un funcionamiento ininterrumpido necesitaremos unas condiciones climáticas adecuadas de temperatura y humedad.

29
00:03:53,680 --> 00:04:21,660
El hardware clave para la alta disponibilidad. Se utilizan en los CPDs salas frías para que no se produzcan esos cambios de temperatura, con ventiladores, con climatizadores. Y luego tenemos los llamados sistemas de alimentación ininterrumpida, los SAIs, los que nos van a permitir que podamos, en una caída eléctrica, podamos tener una determinada estabilidad eléctrica durante un pequeño tiempo.

30
00:04:23,680 --> 00:04:40,980
Aquí os pongo una tabla de todo lo necesario, hablo tanto del hardware que es clave, que sería, por ejemplo, uso de servidores redundantes como discos SSD, fuentes de alimentación dual, condiciones climáticas adecuadas,

31
00:04:40,980 --> 00:04:47,360
que el CPD tenga unos sensores de temperatura y que siempre esté a una misma temperatura y también de humedad.

32
00:04:47,839 --> 00:04:56,720
Subministro energético estable, pues con las SAIs y generadores de respaldo en caso de cortes.

33
00:04:57,399 --> 00:05:05,560
Ventiladores y climatizadores, pues una climatización automática en raquete de servidores con ventilación forzada.

34
00:05:05,560 --> 00:05:10,560
Y por último, sistemas de alimentación interrumpida, que es el SAI con batería.

35
00:05:10,980 --> 00:05:36,300
Puede durar a lo mejor 15 minutos en caso de una caída. También tenemos que hablar de duplicar fuentes de alimentación en equipos críticos, duplicar los dispositivos de conectividad y duplicar los sistemas de cableado. Si veis, duplicar todo para que el tiempo ininterrumpido de todo el sistema sea el mínimo.

36
00:05:36,300 --> 00:06:03,079
También tenemos que hablar de la integridad de datos y de la recuperación del servicio. La integridad de datos es la que asegura que no han sido modificados por personas no autorizadas. Entonces, ¿qué situaciones se pueden dar? Pues una modificación maliciosa por malware, por errores de software o fallos del sistema, acceso no autorizado, problemas de transmisión de datos, técnicas de protección, firma digital y hash.

37
00:06:03,079 --> 00:06:09,160
En todos estos casos se puede afectar la integridad de los datos

38
00:06:09,160 --> 00:06:16,100
y aquí os he puesto algunos ejemplos como un ransomware, un corte de energía que corrompe la base de datos

39
00:06:16,100 --> 00:06:19,100
un empleado que edita un registro de contables sin autorización

40
00:06:19,100 --> 00:06:23,019
una red inestable, un archivo puede corromperse durante la transferencia

41
00:06:23,019 --> 00:06:30,459
o un documento firmado digitalmente que mostrará errores si alguien lo modifica

42
00:06:30,459 --> 00:06:35,040
La integridad de datos asegura que la información no ha sido modificada, ya lo he dicho, por usuarios no autorizados

43
00:06:35,040 --> 00:06:37,980
Y esta es crucial, lógicamente, en los sistemas críticos.

44
00:06:38,399 --> 00:06:42,459
¿Métodos de protección? Pues tenemos métodos de protección como puede ser la firma digital o el hashing.

45
00:06:43,300 --> 00:06:51,180
La firma digital, tenemos que si el contenido ha sido alterado, pues la verificación en la firma digital fallaría.

46
00:06:51,759 --> 00:06:56,399
Y en el hashing, si cambias una sola letra del archivo, pues el hash generado será totalmente distinto.

47
00:06:59,589 --> 00:07:06,209
¿Riesgos para la integridad de los datos? Lo hemos visto antes, pues tenemos los malware que pueden modificar los datos sin autorización.

48
00:07:06,209 --> 00:07:14,269
Un ejemplo sería un software que cifra todos los archivos del sistema y cambia sus nombres, haciendo imposible acceder a ellos sin pagar un rescate.

49
00:07:15,089 --> 00:07:20,189
Tendríamos también los rootkits, que alteran los archivos del sistema y ocultan su presencia.

50
00:07:21,129 --> 00:07:29,689
Por ejemplo, un rootkit que se instala en un servidor y modifica archivos del sistema operativo para esconder procesos maliciosos, como abrir puertas traseras, etc.

51
00:07:29,689 --> 00:07:43,149
Y luego tendríamos que meter aquí también los errores humanos o fallos del sistema que pueden corromper datos esenciales. Por ejemplo, un técnico que borra accidentalmente una tabla de entrada de una base de datos. Hay que ser para borrarla.

52
00:07:44,209 --> 00:07:58,810
Herramientas para la detección de vulnerabilidades. Pues existen varias herramientas. Aquí hablamos concretamente de la obra virtual del Rootkit Hunter o RK Hunter. Es una de las herramientas más utilizadas en el virus.

53
00:07:59,689 --> 00:08:04,970
Funciones, es una herramienta de código abierto que detecta rootkits y otros tipos de malware.

54
00:08:06,310 --> 00:08:10,310
Para Windows también nos habla el aula virtual de SFC.

55
00:08:11,470 --> 00:08:23,410
En cuanto a funciones principales de RKHunter, examina permisos de archivos ejecutables, busca rootkits conocidos, verifica la integridad de los archivos del sistema, detecta archivos acutos o sospechosos.

56
00:08:23,410 --> 00:08:46,639
En cuanto a la instalación, aquí estaría cómo instalarlo y cuál sería el archivo de configuración. Como todo tiene su archivo de configuración, sería este de aquí. Aquí aparece un ejemplo de parámetros a modificar, para actualizar automáticamente la lista de servidores o para especificar el comando del navegador web.

57
00:08:46,639 --> 00:09:09,740
Aquí tenemos también varios parámetros más de RK Hunter en el que podemos modificar en su archivo de configuración, en el que tenemos que, para chequear la versión, para actualizar la base de datos de propiedades de los archivos del sistema,

58
00:09:09,740 --> 00:09:12,460
hashes para actualizar

59
00:09:12,460 --> 00:09:14,200
la base de datos de firmas y archivos del sistema

60
00:09:14,200 --> 00:09:18,649
tenemos aquí

61
00:09:18,649 --> 00:09:21,049
para actualizar

62
00:09:21,049 --> 00:09:22,769
la base de datos, como he dicho antes

63
00:09:22,769 --> 00:09:24,269
pues seríamos a través de

64
00:09:24,269 --> 00:09:26,750
este comando, para chequear

65
00:09:26,750 --> 00:09:29,070
para realizar un chequeo de seguridad, pues sería este otro

66
00:09:29,070 --> 00:09:30,990
y para evitar una interacción

67
00:09:30,990 --> 00:09:32,509
manual, pues tendríamos este

68
00:09:32,509 --> 00:09:35,909
he puesto aquí

69
00:09:35,909 --> 00:09:38,389
los recortes

70
00:09:38,389 --> 00:09:40,610
del aula virtual, en el que

71
00:09:40,610 --> 00:09:41,370
aquí

72
00:09:41,370 --> 00:09:54,909
Y lo he añadido por partes, en el que sería el propio chequeo, los propios imágenes capturadas por el propio aula virtual,

73
00:09:54,909 --> 00:10:02,610
en el que primero, una vez que la he instalado, como la comprobación de comandos y archivos del sistema,

74
00:10:02,610 --> 00:10:11,690
que lo que hace a través del comando check es verificar las herramientas del sistema y revisar que no estén alteradas.

75
00:10:13,330 --> 00:10:22,570
Después puede hacer una búsqueda de rootkits conocidos, entonces compara archivos y directorios del sistema con firmas de rootkits populares

76
00:10:22,570 --> 00:10:41,289
Y veis aquí que no encuentra ninguno de ellos. Luego se realiza una revisión adicional de JavaScript y de malware. Hace revisiones adicionales y el resultado es que no encuentra ninguna anomalía.

77
00:10:41,289 --> 00:11:00,269
En cuanto a la revisión del sistema y de advertencias, también chequea configuraciones locales como interfaces promiscuas, archivos de arranque y configuraciones SH. Aparecen varias advertencias aquí, que serían estas dos de aquí, con respecto a archivos de contraseñas.

78
00:11:00,269 --> 00:11:22,080
Y por último, en el resumen final nos dice que ha verificado 149 archivos y que solo ha encontrado un archivo sospechoso. El chequeo de rootkit analizado son 479 rootkits y no encuentra ninguno detectado.

79
00:11:22,080 --> 00:11:43,259
Con respecto a SFC, que sería la herramienta que podremos utilizar en Windows, pues también nos muestra las opciones disponibles del mismo y que servirá para verificar y reparar archivos protegidos del sistema de Windows. Opciones destacadas serían todas estas que aparecen aquí.

80
00:11:43,259 --> 00:12:09,159
Bien, pasamos a servidores redundantes o sistemas de clústeres. La redundancia, ya hemos visto que nuestra finalidad al final es duplicar todo. Entonces, redundancia, elementos adicionales que permiten recuperar información en caso de que haya un fallo. Así de básico. Aplicando a servidores, serían servidores redundantes. Si falla uno, siempre podríamos disponer de otro en caso de una incidencia.

81
00:12:09,159 --> 00:12:30,860
En cuanto a redundancia con respecto a componentes internos, también un servidor podría aplicar esa redundancia a su componente interno, como puede ser el almacenamiento con los sistemas RAID, o lo que serían tener varios discos independientes por el caso de fallo de uno de ellos.

82
00:12:30,860 --> 00:12:37,200
¿Y eso qué hace? Pues que duplica la información y asegura la integridad y disponibilidad de manera continua.

83
00:12:37,200 --> 00:13:07,080
Aquí tenemos dentro de la redundancia el almacenamiento, los distintos RAID, el RAID 0 que distribuye los discos entre dos o más discos, esto se llama stripping, el RAID 1 que se duplica los datos en dos discos, el RAID 5 que distribuye los datos y la paridad entre tres o más discos, el 6 que sería similar al 5 pero que con doble paridad y el RAID 10 que combina el RAID 1 y el 0, tanto espejo como stripping.

84
00:13:10,090 --> 00:13:20,889
¿Qué sistemas de clúster hay? Aquí te aparecen los tres sistemas de clúster que nos aparecen ahora virtual, que sea el clúster de alta eficiencia, el clúster de alto rendimiento y el de alta disponibilidad.

85
00:13:22,950 --> 00:13:34,710
Con respecto al de alta eficiencia, ¿qué es lo que busca? Lo que va a buscar es optimizar el uso de los recursos y la energía y se va a enfocar siempre al menos consumo posible.

86
00:13:35,509 --> 00:13:41,549
Un ejemplo de este sería una empresa con un centro de datos que distribuye tareas según carga para ahorrar energía.

87
00:13:41,549 --> 00:13:45,809
Eso enciende nodos adicionales si es necesario, manteniendo un balance entre rendimiento y consumo.

88
00:13:46,509 --> 00:13:52,629
Luego teníamos, este sería el HPCC, el clúster de alto rendimiento, que sería el HPCC,

89
00:13:53,149 --> 00:13:58,549
el que están diseñados para realizar, pues serían cálculos complejos y masivos rápidamente.

90
00:13:59,590 --> 00:14:04,690
Un ejemplo sería el centro de investigación científica, que hacen simulaciones meteorológicas o cálculos de genética

91
00:14:04,690 --> 00:14:11,210
y usan clústeres de este tipo para obtener resultados en horas en lugar de semanas, ¿vale?

92
00:14:12,049 --> 00:14:19,610
Y el tercero sería, pues, el HACC o HACC o Cluster de Alta Disponibilidad,

93
00:14:20,230 --> 00:14:25,190
que es un conjunto de servidores que trabajan juntos para garantizar que un servicio nunca se detenga,

94
00:14:25,570 --> 00:14:27,269
incluso si uno de los servidores falla, ¿vale?

95
00:14:27,769 --> 00:14:30,370
Pues, un ejemplo, pues, sería, pues, un hospital.

96
00:14:30,370 --> 00:14:42,950
Lógicamente, en un hospital, en el sistema de gestión de pacientes, esto no puede fallar. El sistema tiene que estar funcionando sin cortes durante todo el tiempo.

97
00:14:45,470 --> 00:14:52,509
¿Qué componentes tiene un clúster? Tendrá nodos, tendrá el software base, tendrá almacenamiento, comunicaciones y mediaware.

98
00:14:52,509 --> 00:15:21,889
En cuanto a los nodos, los equipos físicos, que pueden ser físicos o virtuales, luego el software de base, que puede ser multiproceso, multishorario, Linux, Unix, almacenamiento, tanto de discos internos locales, NAS, SAN, comunicaciones, lógicamente incluirá interfaces de red, conexiones físicas, protocolos de comunicación y luego el middleware, que es el software que coordina y gestiona todo el clúster.

99
00:15:24,659 --> 00:15:43,200
Herramientas para clústeres de alta disponibilidad, pues mira, aquí tenemos Proxmox, Veritas, Keeper Live y luego el Linux HA, que será el que veremos un poco mejor. En cuanto al Proxmox, es una plataforma de virtualización de código abierto y basada en Debian.

100
00:15:44,200 --> 00:15:50,919
Permite gestionar máquinas virtuales y contenedores y soporta clustering de alta disponibilidad automática.

101
00:15:51,399 --> 00:16:02,759
En cuanto a Veritas es más una solución empresarial y de clustering y este sería un poco más complejo que el que es Proxmox.

102
00:16:02,759 --> 00:16:08,779
Luego tenemos Keep Alive, que sería una herramienta de failover y de balanceo de carga para Linux Virtual Server.

103
00:16:09,879 --> 00:16:21,700
Y por último tendremos el Linux HA, que es un conjunto de herramientas que ahora lo veremos, como PagePaker y Corosim, para crear el cluster thread durante el software.

104
00:16:23,039 --> 00:16:26,519
Gestionar recursos, dependencias y frauleadores de servicios.

105
00:16:29,759 --> 00:16:39,899
Veis aquí que esta sería la estructura de Linux HA en la que tenemos el Herbit para la comunicación y luego el Pacemaker, que sería para la gestión de recursos.

106
00:16:40,679 --> 00:16:46,820
Herbit es la infraestructura de clúster para gestión de comunicación y pertenencia.

107
00:16:49,159 --> 00:16:56,659
Características de Herbit, pues puede ser configurable en modo activo y modo pasivo y es compatible con múltiples nodos.

108
00:16:56,659 --> 00:17:24,119
Bueno, hemos visto que el Linux HA estaría formado por estos dos elementos y nos describe aquí en esta diapositiva que realmente HA es un conjunto de tecnologías, no es una herramienta específica, sino que va a incluir otro tipo de herramientas.

109
00:17:24,119 --> 00:17:52,400
Y en todas esas herramientas estarían estas tres que aparecen aquí. En cuanto a Hervit, es una herramienta dentro del proyecto en el que, como he dicho antes, se encarga de la comunicación entre los nodos del cluster. Detecta fallos, memoria del cluster. En cambio, Pacemaker sería el gesto de recursos. Hervit no funciona como gesto de recursos. Sería el que lo realiza Pacemaker. Inicia, para o mueve servicios, decide qué hacer si uno falla, etc.

110
00:17:52,400 --> 00:18:00,299
Digámoslo así que dentro del clúster el cerebro sería el pacemaker.

111
00:18:01,980 --> 00:18:18,319
Balanceadores de carga son dispositivos que van a distribuir la carga entre varios servidores, aseguran que el servicio continúe operativo y permiten una mejor distribución de los recursos y, lógicamente, mantienen la estabilidad del sistema.

112
00:18:18,319 --> 00:18:33,059
Aquí tenemos un ejemplo de la imagen de un balanzador de carga, como es el Linux Virtual Server, que va a repartir las peticiones entre estos servidores de aplicaciones que aparecen aquí.

113
00:18:33,059 --> 00:18:43,019
Y los servidores de aplicaciones se conectan a una base de datos central. Si esta base de datos está replicada, pues muchísimo mejor, como aparece aquí.

114
00:18:43,859 --> 00:18:51,079
Y hay tres servidores de aplicaciones y que van a ofrecer servicios de página web, archivos y otros servicios.

115
00:18:51,079 --> 00:18:56,079
Estos están conectados al balanceador para repartir el trabajo y mejorar el rendimiento y la disponibilidad.

116
00:18:56,079 --> 00:19:21,920
El software de balanceo de carga tendríamos, como hemos visto anteriormente, un LVS que funciona a nivel de kernel, por lo que es muy rápido y eficiente. Equipa Live, que es un complemento para el LVS que supervisa el estado del clúster. Y luego el IPV-SDM, que es una herramienta para administrar el LVS.

117
00:19:21,920 --> 00:19:34,180
Esta herramienta se encargará de ver qué servidores están recibiendo tráfico, agregar o quitar servidores del clúster, definir el método de balanceo, si va a ser un row-robin, etc.

118
00:19:35,400 --> 00:19:51,000
En cuanto a las técnicas de balanceo de carga, el balanceador modifica, podemos tener o el NAT, el TUN o un direct routing. En cuanto al NAT, el balanceador lo que actúa es un aporte de enlace para los servidores.

119
00:19:51,920 --> 00:20:12,210
Entonces, un cliente quiere acceder a una página web, entonces el EUS recibe la petición, la redirecciona a un servidor backend y modifica la IP del cliente. Aquí está el proceso NAT, el servidor responde a través del balanceador que reenvía la respuesta al cliente.

120
00:20:12,210 --> 00:20:35,559
En el caso de TUN, lo que usa es túneles IP para la distribución de carga. Entonces, ahora se utiliza un túnel para enviar la petición al backend que responde directamente al cliente, ya no pasa por el LVS. Por último, el direct routing sería un balanceo ultra rápido sin modificar los paquetes de red. Entonces, el balanceador redirige los paquetes directamente sin modificarlos.

121
00:20:35,559 --> 00:20:45,700
Entonces, el LVS recibe una petición y la reenvía sin modificarla a un servidor backend. Ese servidor responde directamente al cliente sin pasar por el balanceado.

122
00:20:46,700 --> 00:20:59,240
Aquí tenemos cómo, de los tres modos de balanceo de carga, si modifica los paquetes o no los modifica. El único que los modificaría sería el caso de NAT.

123
00:21:00,299 --> 00:21:08,119
¿Quién responde al cliente? En NAT respondía LVS, pero en los otros dos respondía Backend.

124
00:21:08,119 --> 00:21:19,819
Y, bueno, en cuanto a la velocidad, ideal para qué tipo de redes. El de R sería para alto rendimiento, pues su velocidad es muy alta y luego tendríamos para redes más simples sería el caso de NAT.

125
00:21:19,819 --> 00:21:42,839
En cuanto al algoritmo de balanceo, tenemos múltiples algoritmos de balanceo. Podemos tener un balanceo round-robin. Acordaos, el round-robin se da un tiempo. Cuando ese cuánto termina, se pasa al siguiente servidor. Esto procura una distribución equitativa entre servidores.

126
00:21:43,680 --> 00:22:00,500
Una redistribución también basada en round robin, pero con pesos, en el que ahora se va a realizar el mismo cuantum, pero los servidores pueden tener un mayor o menor peso para tener una mayor o menor redistribución.

127
00:22:01,460 --> 00:22:22,940
Luego tenemos el ListConnection, que envía peticiones a servidores con aquellos que tienen menos conexiones. El mismo, pero basado también en el peso. El siguiente, que prioriza servidores con menos carga o incluso una tabla Hash para asignar solicitudes.

128
00:22:22,940 --> 00:22:43,150
Y por último tendríamos el source hashing, que asignaría peticiones según direcciones IP de origen. Esto nos explica un poquito más cada uno de ellos, de los más importantes, y pasaríamos después a la configuración del HAProxy.

129
00:22:43,150 --> 00:22:47,430
El HAProxy

130
00:22:47,430 --> 00:22:49,890
como se configura tendrá un archivo de configuración

131
00:22:49,890 --> 00:22:51,869
que sería este que aparece aquí

132
00:22:51,869 --> 00:22:55,890
y tenemos que

133
00:22:55,890 --> 00:22:57,710
especificar en el mismo tanto

134
00:22:57,710 --> 00:22:59,950
el tipo de balanceo, que en este caso

135
00:22:59,950 --> 00:23:01,890
aquí han añadido

136
00:23:01,890 --> 00:23:03,990
que el balanceo sea round robin

137
00:23:03,990 --> 00:23:07,750
que pueda usarse para

138
00:23:07,750 --> 00:23:08,990
balanceo en servicios HTTP

139
00:23:08,990 --> 00:23:12,990
igual serían los servicios

140
00:23:13,150 --> 00:23:42,779
Aquí los servidores virtuales serían el 1.10 y el 1.0. Aquí tenemos un montón de parámetros de configuración del HAProxy para ver si un servidor falla, cómo distribuir la petición, para el tipo de algoritmo que se va a utilizar, si queremos para habilitar el chequeo de salud, etc.

141
00:23:42,779 --> 00:23:57,700
Otro tenemos que sería la configuración del KeepAlive, en el que tendríamos que el archivo de configuración sería este de aquí y aquí tendríamos un apartado de cómo realizamos la configuración.

142
00:23:57,700 --> 00:24:18,099
Aquí también tiene varios parámetros. Ahora el LBRR sería posible el algoritmo de balanceo. Estamos diciendo que tenga un algoritmo de balanceo round-robin. También el tipo de balanceo que queríamos. Ya vimos que había tres tipos, el NAT, TUN y DR. Aquí estamos indicándole que haga un DROOTING.

143
00:24:18,099 --> 00:24:29,660
el protocolo que va a usar, el balanceo, el chequeo del estado del servidor y un poco más.

144
00:24:36,299 --> 00:24:38,440
Pasamos a la virtualización de sistemas.

145
00:24:39,099 --> 00:24:46,099
En cuanto a la virtualización de sistemas, nos va a permitir la ejecución de varios...