1
00:00:06,059 --> 00:00:10,980
Este tema vamos a hablar de implantación y soluciones de alta disponibilidad.

2
00:00:12,779 --> 00:00:17,820
Objetivo de la unidad. Objetivo de la unidad sería, pues, analizar las distintas configuraciones de alta disponibilidad,

3
00:00:18,660 --> 00:00:25,739
comprender la importancia de un buen análisis de riesgos en sistemas críticos y aprender a solventar posibles problemas.

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

5
00:00:30,960 --> 00:00:52,560
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.

6
00:00:52,560 --> 00:01:04,420
Y objetivo sería asegurar la continuidad del sistema sin interrupciones, basado en la replicación de elementos asequibles, lo veremos, y alternativa a sistemas individuales tolerantes a fallos.

7
00:01:05,719 --> 00:01:10,560
¿Qué tipo de sistemas hay? Tenemos sistemas de alta disponibilidad y sistemas tolerantes a fallos.

8
00:01:11,480 --> 00:01:19,140
Los sistemas de alta disponibilidad son los que se pueden provocar tiempos inactivos, puede haber variamientos en los que esté inactivo.

9
00:01:19,140 --> 00:01:36,680
En cambio, los sistemas tolerantes a fallos detectan la parte que falla, toman medidas para restablecer el servicio rápidamente, entonces el impacto tiene que ser mínimo. 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.

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

11
00:01:54,230 --> 00:02:17,590
Bien, objetivo, hemos dicho que era evitar interrupciones en sistemas críticos. ¿Qué tipos 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.

12
00:02:17,590 --> 00:02:25,030
En cambio, las imprevistas pueden ser de distinta índole, apagones, fallos de hardware, de software, problemas de seguridad.

13
00:02:27,629 --> 00:02:36,229
Parametros 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.

14
00:02:37,210 --> 00:02:48,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.

15
00:02:48,849 --> 00:02:55,030
Entre el MTTR o tiempo medio de recuperación es el que mide el tiempo medio en restablecer el sistema.

16
00:02:55,169 --> 00:02:58,889
Lo que tarda el sistema, una vez que ha caído, en restablecerse.

17
00:02:58,889 --> 00:03:06,889
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.

18
00:03:07,650 --> 00:03:12,569
Y sería el cociente entre el tiempo de recuperación y el tiempo entre fallos.

19
00:03:15,569 --> 00:03:19,650
Nivel de disponibilidad mide el tiempo inactivo de un sistema.

20
00:03:19,650 --> 00:03:40,330
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.

21
00:03:40,330 --> 00:04:00,259
Funcionamiento ininterrumpido. Hay que decir que para tener un funcionamiento ininterrumpido necesitaremos unas condiciones climáticas adecuadas de temperatura y humedad, el hardware clave para la alta disponibilidad.

22
00:04:00,259 --> 00:04:02,680
se utilizan

23
00:04:02,680 --> 00:04:04,580
en los CPDs, se utilizan salas frías

24
00:04:04,580 --> 00:04:06,699
para que no se produzcan esos cambios

25
00:04:06,699 --> 00:04:08,900
de temperatura, con ventiladores

26
00:04:08,900 --> 00:04:10,680
con climatizadores y luego

27
00:04:10,680 --> 00:04:12,639
tenemos los llamados sistemas de

28
00:04:12,639 --> 00:04:14,520
alimentación ininterrumpida, los SAIS

29
00:04:14,520 --> 00:04:16,480
los que nos va a permitir

30
00:04:16,480 --> 00:04:18,300
que podamos

31
00:04:18,300 --> 00:04:20,639
en una caída eléctrica

32
00:04:20,639 --> 00:04:22,319
podamos tener una determinada

33
00:04:22,319 --> 00:04:24,660
estabilidad eléctrica durante un pequeño tiempo

34
00:04:24,660 --> 00:04:27,879
aquí os pongo una tabla

35
00:04:27,879 --> 00:04:39,040
de todo lo necesario, hablo tanto del hardware que es clave, que sería por ejemplo uso de servidores redundantes

36
00:04:39,040 --> 00:04:43,980
como discos SSD, fuentes de alimentación dual, condiciones climáticas adecuadas,

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

38
00:04:50,360 --> 00:05:17,480
El suministro energético es estable, pues con la SAIS y generadores de respaldo en caso de cortes. Ventiladores y climatizadores, pues una climatización automática en raquete de servidores con ventilación forzada. Y por último, sistemas de alimentación interrumpida, que es el SAIS con batería. Puede durar a lo mejor 15 minutos en caso de una caída.

39
00:05:17,480 --> 00:05:28,899
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

40
00:05:28,899 --> 00:05:39,300
Si veis, pues duplicar todo para que el tiempo ininterrumpido de todo el sistema sea el mínimo

41
00:05:39,300 --> 00:05:44,769
También tenemos que hablar de la integridad de datos y de la recuperación del servicio

42
00:05:44,769 --> 00:05:51,449
La integridad de datos es la que asegura que no han sido modificados por personas no autorizadas

43
00:05:51,449 --> 00:06:06,089
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.

44
00:06:06,089 --> 00:06:12,170
En todos estos casos se puede afectar la integridad de los datos

45
00:06:12,170 --> 00:06:19,089
y aquí os he puesto algunos ejemplos como un ransomware, un corte de energía que corrompe la base de datos

46
00:06:19,089 --> 00:06:22,110
un empleado que edita un registro de contables sin autorización

47
00:06:22,110 --> 00:06:26,009
una red inestable, un archivo puede corromperse durante la transferencia

48
00:06:26,009 --> 00:06:29,889
o un documento firmado digitalmente que mostrará errores si alguien lo modifica

49
00:06:29,889 --> 00:06:38,060
La integridad de datos asegura que la información no ha sido modificada, ya lo he dicho, por usuarios no autorizados

50
00:06:38,060 --> 00:06:40,959
Y esta es crucial, lógicamente, pues en los sistemas críticos.

51
00:06:41,399 --> 00:06:45,459
Métodos de protección, pues tenemos métodos de protección como puede ser la firma digital o el hashing.

52
00:06:46,319 --> 00:06:54,160
La firma digital, tenemos que si el contenido ha sido alterado, pues la verificación en la firma digital fallaría.

53
00:06:54,740 --> 00:06:59,379
Y en el hashing, si cambias una sola letra del archivo, pues el hash generado será totalmente distinto.

54
00:07:02,589 --> 00:07:09,209
Riesgos para la integridad de los datos, lo hemos visto antes, pues tenemos los malware que pueden modificar los datos sin autorización.

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

56
00:07:18,050 --> 00:07:23,170
Tendríamos también los rootkits, que alteran los archivos del sistema y ocultan su presencia.

57
00:07:24,129 --> 00:07:32,709
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.

58
00:07:32,709 --> 00:07:46,129
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.

59
00:07:47,209 --> 00:08:01,790
Herramientas para la detección de vulnerabilidades. Pues existen varias herramientas. Aquí hablábamos concretamente de la obra virtual del Rootkit Hunter o RK Hunter. Es una de las herramientas más utilizadas en Linux.

60
00:08:02,709 --> 00:08:07,970
Funciones, es una herramienta de código abierto que detecta rootkits y otros tipos de malware.

61
00:08:09,310 --> 00:08:13,290
Para Windows también nos habla el aula virtual de SFC.

62
00:08:14,470 --> 00:08:26,389
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 ocultos o sospechosos.

63
00:08:26,389 --> 00:08:49,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.

64
00:08:49,639 --> 00:09:12,730
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,

65
00:09:12,730 --> 00:09:15,450
hashes para actualizar

66
00:09:15,450 --> 00:09:17,190
la base de datos de firmas y archivos del sistema

67
00:09:17,190 --> 00:09:21,649
tenemos aquí

68
00:09:21,649 --> 00:09:24,049
para actualizar

69
00:09:24,049 --> 00:09:25,789
la base de datos como he dicho antes

70
00:09:25,789 --> 00:09:27,269
pues sería a través de

71
00:09:27,269 --> 00:09:29,750
este comando, para chequear

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

73
00:09:32,070 --> 00:09:33,990
y para evitar una interacción

74
00:09:33,990 --> 00:09:35,490
manual pues tendríamos este

75
00:09:35,490 --> 00:09:38,929
he puesto aquí

76
00:09:38,929 --> 00:09:41,870
los recortes pues de

77
00:09:41,870 --> 00:09:43,850
la aula virtual en el que bueno

78
00:09:43,850 --> 00:10:05,590
Aquí lo he añadido por partes, en el que sería el propio chequeo, los propios imágenes capturadas por el propio aula virtual, en el que primero, una vez que la he instalado, como la comprobación de comandos y archivos del sistema,

79
00:10:05,590 --> 00:10:10,049
que lo que hace a través del comando check

80
00:10:10,049 --> 00:10:12,590
es verificar las herramientas del sistema

81
00:10:12,590 --> 00:10:14,669
y revisar que no estén alteradas.

82
00:10:16,330 --> 00:10:20,250
Después puede hacer una búsqueda de rootkits conocidos.

83
00:10:22,029 --> 00:10:23,889
Entonces compara archivos y directorios del sistema

84
00:10:23,889 --> 00:10:25,549
con firmas de rootkits populares

85
00:10:25,549 --> 00:10:30,470
y veis aquí que no encuentra ninguno de ellos.

86
00:10:30,470 --> 00:10:44,289
Con respecto a, luego se realiza pues en revisiones adicionales de JavaScript y de malware. Hace revisiones adicionales y el resultado es que no encuentra ninguna anomalía.

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

88
00:11:04,600 --> 00:11:13,259
Y por último, en el resumen final, nos dice que ha verificado 149 archivos y que solo ha encontrado un archivo sospechoso.

89
00:11:13,259 --> 00:11:25,139
El chequeo de rootkit analizado son 479 rootkits y no encuentra ninguno detectado.

90
00:11:25,139 --> 00:11:42,870
Con respecto a SFC, que sería la herramienta que podremos utilizar en Windows, también nos muestra las opciones disponibles del mismo y que servirá para verificar y reparar archivos protegidos del sistema de Windows.

91
00:11:43,590 --> 00:11:46,250
Opciones destacadas serían todas estas que aparecen aquí.

92
00:11:46,250 --> 00:12:12,129
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 permitan 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 poner el poder de otro en caso de una incidencia.

93
00:12:12,129 --> 00:12:33,850
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.

94
00:12:34,850 --> 00:12:40,190
¿Eso qué hace? Pues que duplica la información y asegura la integridad y disponibilidad de manera continua.

95
00:12:40,809 --> 00:12:51,730
Aquí tenemos dentro de la redundancia el almacenamiento, los distintos RAID, el RAID 0, que distribuye los discos entre dos o más discos,

96
00:12:52,330 --> 00:13:01,409
esto se llama stripping, el RAID 1, que duplica los datos en dos discos, el RAID 5, que distribuye los datos y la variedad entre tres o más discos,

97
00:13:01,409 --> 00:13:09,909
el 6, que sería similar al 5, pero que con doble paridad, y el RAID 10, que combina RAID 1 y el 0, en despejo como este.

98
00:13:13,120 --> 00:13:23,879
¿Qué sistema 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.

99
00:13:23,879 --> 00:13:44,539
Con respecto al de alta eficiencia, lo que va a buscar es optimizar el uso de los recursos y la energía y se va a enfocar siempre al menor consumo posible. Un ejemplo de este sería una empresa con un centro de datos que distribuye tareas según carga para ahorrar energía.

100
00:13:44,539 --> 00:13:48,759
Eso enciende nodos adicionales si es necesario, manteniendo un balance entre rendimiento y consumo.

101
00:13:49,940 --> 00:13:55,620
Luego tenemos, este sería el HPCC, el clúster de alto rendimiento, que sería el HPCC,

102
00:13:56,139 --> 00:14:01,539
el que están diseñados para realizar, pues serían cálculos complejos y masivos rápidamente.

103
00:14:02,580 --> 00:14:07,720
Un ejemplo sería el centro de investigación científica, que hacen simulaciones meteorológicas o cálculos de genética

104
00:14:07,720 --> 00:14:13,860
y usan clústeres de este tipo para obtener resultados en horas en lugar de semanas.

105
00:14:14,539 --> 00:14:30,080
Y el tercero sería el HACC o Cluster de Alta Disponibilidad, que es un conjunto de servidores que trabajan juntos para garantizar que un servicio nunca se detenga, incluso si uno de los servidores falla.

106
00:14:30,080 --> 00:14:45,940
Un ejemplo sería un hospital. 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.

107
00:14:45,940 --> 00:14:55,509
¿Qué componentes tiene un clúster? Pues tendrá nodos, tendrá el software base, tendrá almacenamiento, comunicaciones y mediaware.

108
00:14:55,509 --> 00:15:15,889
En cuanto a los nodos, pues son los equipos físicos, que pueden ser físicos o virtuales. Luego el software de base, pues que puede ser, tendrá que ser multiproceso, multishorario, Linux, Unix, almacenamiento, pues tanto discos internos locales, NAS, SAN, comunicaciones.

109
00:15:15,889 --> 00:15:24,909
Entonces, 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.

110
00:15:27,879 --> 00:15:38,179
Herramientas para clústeres de alta disponibilidad, pues mira, aquí tenemos Proxmox, Veritas, KeeperLive y luego el Linux HA, que será el que veremos un poco mejor.

111
00:15:38,179 --> 00:15:46,179
En cuanto al Proxmox, es una plataforma de virtualización de código abierto y basada en Debian.

112
00:15:47,179 --> 00:15:53,899
Permite gestionar máquinas virtuales y contenedores y soporta clustering y alta disponibilidad automática.

113
00:15:54,379 --> 00:16:05,740
En cuanto a varitas, es más una solución empresarial y de clustering y este sería un poco más complejo que el que es Proxmox.

114
00:16:05,740 --> 00:16:11,779
Luego tenemos Keep Alive, que sería una herramienta de failover y de balanceo de carga para Linux Virtual Server.

115
00:16:12,860 --> 00:16:24,940
Y por último tendremos el Linux HA, que es un conjunto de herramientas que ahora lo veremos, como PagePaker y Corosim, para crear clústeres redondantes autónomos.

116
00:16:26,059 --> 00:16:29,519
Gestionar recursos, dependencias y frauleadores de servicios.

117
00:16:32,440 --> 00:16:42,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.

118
00:16:43,659 --> 00:16:49,820
Herbit es la infraestructura de clúster para gestión de comunicación y pertenencia.

119
00:16:52,179 --> 00:16:59,600
Características de Herbit, pues puede ser configurable en modo activo y modo pasivo y es compatible con múltiples modos.

120
00:17:07,069 --> 00:17:21,650
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,

121
00:17:21,650 --> 00:17:27,109
no es una herramienta específica, sino que va a incluir otro tipo de herramientas.

122
00:17:27,430 --> 00:17:29,769
Y en todas esas herramientas estarían estas tres que aparecen aquí.

123
00:17:29,769 --> 00:17:55,390
En cuanto a Herbit, es una herramienta dentro del proyecto en la que, como he dicho antes, se encarga de la comunicación entre los nodos del cluster. Detecta fallos, membresía del cluster. En cambio, Pacemaker sería el gestor de recursos. Herbit no funciona como gestor de recursos. Sería quien lo realiza Pacemaker. Inicia, para o mueve servicios, decide qué hacer si uno falla, etc.

124
00:17:55,390 --> 00:18:03,289
Digámoslo así que dentro del clúster el cerebro sería el pacemaker.

125
00:18:04,970 --> 00:18:21,309
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.

126
00:18:21,309 --> 00:18:36,049
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í.

127
00:18:36,049 --> 00:18:45,990
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í.

128
00:18:45,990 --> 00:18:59,410
Y hay tres servidores de aplicaciones y que van a ofrecer servicios de página web, archivos y otros servicios. Estos están conectados al balanceador para repartir el trabajo y mejorar el rendimiento y la disponibilidad.

129
00:18:59,410 --> 00:19:24,910
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 Alive, que es un complemento para el LVS que supervisa el estado del clúster. Y luego el IPV-SADM, que es una herramienta para administrar el LVS.

130
00:19:24,910 --> 00:19:37,170
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.

131
00:19:38,430 --> 00:19:53,990
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.

132
00:19:54,910 --> 00:20:15,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, servidor responde a través del balanceador que reenvía la respuesta al cliente.

133
00:20:15,210 --> 00:20:27,789
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.

134
00:20:28,130 --> 00:20:38,579
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.

135
00:20:38,579 --> 00:20:48,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 balanceador.

136
00:20:49,680 --> 00:21:06,299
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, quien responde al cliente.

137
00:21:06,299 --> 00:21:22,799
En el NAT respondía LVS, pero en los otros dos respondía backend. Y, bueno, en cuanto a la velocidad, ideal para qué tipo de redes. El DR sería para alto rendimiento, puesto que su velocidad es muy alta, y luego tendríamos para redes más simples sería el caso de NAT.

138
00:21:22,799 --> 00:21:45,819
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.

139
00:21:46,680 --> 00:22:03,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.

140
00:22:04,440 --> 00:22:25,900
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.

141
00:22:25,900 --> 00:22:46,140
Y por último tendríamos el source hashing, que asinarí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.

142
00:22:46,140 --> 00:22:50,420
El HAProxy

143
00:22:50,420 --> 00:22:52,880
como se configura tendrá un archivo de configuración

144
00:22:52,880 --> 00:22:54,859
que sería este que aparece aquí

145
00:22:54,859 --> 00:22:58,900
y tenemos que

146
00:22:58,900 --> 00:23:00,700
especificar en el mismo tanto

147
00:23:00,700 --> 00:23:02,960
el tipo de balanceo, que en este caso

148
00:23:02,960 --> 00:23:04,900
aquí han añadido

149
00:23:04,900 --> 00:23:06,980
que el balanceo sea round robin

150
00:23:06,980 --> 00:23:10,740
que pueda usarse para

151
00:23:10,740 --> 00:23:11,940
balanceo en servicios HTTP

152
00:23:11,940 --> 00:23:15,900
igual serían los servicios

153
00:23:16,140 --> 00:23:29,960
virtuales. Aquí los servidores virtuales serían el 1.10 y el 1.0. Aquí tenemos un montón de parámetros de configuración

154
00:23:29,960 --> 00:23:42,460
del HAProxy para ver si un servidor falla, cómo distribuir la petición, el tipo de algoritmo que se va a utilizar,

155
00:23:42,460 --> 00:23:46,019
si queremos para habilitar el chequeo de salud, si no, etc.

156
00:23:48,190 --> 00:23:50,430
Otro tenemos que sería la configuración del Keep Alive,

157
00:23:50,589 --> 00:23:52,849
en el que tendríamos que el archivo de configuración sería este de aquí,

158
00:23:53,289 --> 00:24:00,670
y bueno, pues aquí tendríamos un apartado de cómo realizamos la configuración.

159
00:24:00,829 --> 00:24:03,369
Aquí también tiene varios parámetros.

160
00:24:03,890 --> 00:24:07,650
Ahora el LBRR sería el algoritmo de balanceo,

161
00:24:07,710 --> 00:24:11,670
estamos diciendo que tenga un algoritmo de balanceo, pues, Round Robin.

162
00:24:11,670 --> 00:24:32,609
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 direct routing. El protocolo que va a usar, el balanceo, el chequeo del estado del servidor y poco más.

163
00:24:32,609 --> 00:24:48,890
En cuanto a la virtualización de sistemas, nos va a permitir la ejecución de varios