1
00:00:00,000 --> 00:00:18,000
Este es el esquema de la presentación, luego al final, si queréis hacer alguna pregunta o si queréis pararme a mitad de la presentación, me levantáis la mano y os comento aquellas dudas que os surjan.

2
00:00:18,000 --> 00:00:29,000
Como os comentaba antes, yo soy ingeniero de sistemas, soy de la parte de sistemas más que del propio aplicativo, aunque conozco el aplicativo, pero me centro más en lo que es servidores,

3
00:00:29,000 --> 00:00:37,000
la red, la disposición de los distintos clusters que vamos a ver a lo largo de la presentación, etc.

4
00:00:38,000 --> 00:00:52,000
He dividido la presentación en estos puntos, un pequeño punto de Moodle que no voy a entrar demasiado, pero al menos para que veamos qué provee Moodle y qué es lo que da Moodle,

5
00:00:52,000 --> 00:01:06,000
para luego ver en qué componentes podemos dividir ese Moodle, es decir, ese aplicativo y distribuirlo para que nos dé alta disponibilidad, alto rendimiento, tolerancia a fallos, etc.

6
00:01:06,000 --> 00:01:16,000
Para eso, primero pasaré a una arquitectura monolítica, es decir, un solo servidor con todo para que veáis cada una de las partes que vamos a distribuir.

7
00:01:16,000 --> 00:01:26,000
Luego, la arquitectura distribuida, diferentes puntos de vista, diferentes focos, cómo podemos hacerlo, cómo podemos desplegarlo, qué diferentes opciones tenemos.

8
00:01:26,000 --> 00:01:34,000
Y por último, os enseñaré el caso práctico del catálogo, con datos reales, un caso real que tenemos desplegado sobre la plataforma.

9
00:01:36,000 --> 00:01:43,000
Moodle, todos sabéis que es un entorno dinámico, orientado a la armonía del catálogo.

10
00:01:44,000 --> 00:01:59,000
Opensource, es decir, cualquiera se lo puede descargar, lo puede evolucionar siempre y cuando respete la licencia GNU y puede distribuirlo siempre y cuando no adquiere esa licencia.

11
00:02:00,000 --> 00:02:24,000
Principalmente basado en plataformas LAM, es decir, sus principales componentes es un sistema operativo Linux con servidor Apache, con el módulo PHP activo en el servidor Apache y una base de datos que generalmente suele ser MySQL o ser un poco más estándar y más adaptada.

12
00:02:25,000 --> 00:02:39,000
Está en constante evolución, la última versión estáble, la 1.9.6, aunque ya hay la 2.0 en desarrollo, preparada para lo mejor en un mes o dos, está en entorno de producción.

13
00:02:40,000 --> 00:02:49,000
Ejecuta en otros entornos, por ejemplo en Windows, podemos tener la MySQL, un Apache y el PHP compilado y ejecutando sobre un servidor Windows.

14
00:02:49,000 --> 00:03:01,000
Corre en sistemas Mac OS X, preferiría esto antes que Windows prácticamente, pero bueno, también es adaptable.

15
00:03:02,000 --> 00:03:12,000
Y permite, aparte de MySQL, en las últimas versiones, la 1.7.7 hacia adelante, pues admite Microsoft SQL Servers y Oracle.

16
00:03:13,000 --> 00:03:21,000
Postgres 8.0 también se admite, de hecho para entornos de alto rendimiento se aconseja incluso Postgres.

17
00:03:22,000 --> 00:03:32,000
Lo que pasa es que MySQL está más extendido y ahora además es un fabricante importante como XAMPP, que ha sido comprado por Oracle, etc.

18
00:03:33,000 --> 00:03:40,000
Es como partner de MySQL y tenemos un gran respaldo en esa parte.

19
00:03:41,000 --> 00:03:47,000
Vamos a pasar a la arquitectura monolítica, es decir, todo en un solo servidor.

20
00:03:48,000 --> 00:03:58,000
Que componentes ya hemos visto, que es un sistema operativo, un Linux, un MySQL, un Apache y el PHP incluido dentro del Apache.

21
00:03:59,000 --> 00:04:03,000
Es decir, hay que tener Apache con las extensiones del PHP.

22
00:04:04,000 --> 00:04:07,000
¿Qué tenemos? Pues lo dicho, solo un único servidor.

23
00:04:08,000 --> 00:04:16,000
Tenemos ese servidor, ahí están los datos, tenemos la base de datos, tenemos el acceso, si ese servidor se quema, se rompe, se falla, nos quedamos sin nada.

24
00:04:17,000 --> 00:04:20,000
Tenemos que extenderlo para acá, tirar a otro servidor, etc.

25
00:04:21,000 --> 00:04:28,000
Pero si ese servidor se cae, se congestiona, etc., pues no podemos seguir dando servicio.

26
00:04:29,000 --> 00:04:32,000
El escalado, el único escalado que se puede hacer es el vertical.

27
00:04:33,000 --> 00:04:36,000
Supongo que hay dos tipos de escalado, el horizontal y el vertical.

28
00:04:37,000 --> 00:04:45,000
El horizontal es añadir más servidores que den servicio y el vertical es esos que tenemos ya, que admitan más peticiones, más memoria, más CPU, etc.

29
00:04:46,000 --> 00:04:52,000
Pues el escalado es pobre, digo que es pobre porque como tenemos tanto Apache como la base de datos corriendo en el mismo servidor,

30
00:04:52,000 --> 00:04:57,000
si necesitamos más disco para la base de datos, se lo están dando a todos.

31
00:04:58,000 --> 00:05:05,000
Es decir, no puedes repartir y decir, pues solo compro disco para esto, solo compro memoria porque Apache necesita más memoria, etc.

32
00:05:06,000 --> 00:05:14,000
Sin alta disponibilidad, lógicamente, si solo tenemos un servidor, pues no podemos balancear servicio ni pasar la carga a otro equipo porque no hay.

33
00:05:15,000 --> 00:05:27,000
El tiempo de downtime para actualizaciones, es decir, si tenemos la versión 1.7.7 y hay un bug o hay que pasar a la 1.7.8 o a la 1.8, sencillamente es que hay que parar el servicio.

34
00:05:28,000 --> 00:05:31,000
No podemos hacer una actualización en caliente, hay que parar, etc.

35
00:05:32,000 --> 00:05:39,000
Si queremos actualizar sistema operativo también por tema de parches, etc., o problemas de seguridad, hay que parar el servicio.

36
00:05:39,000 --> 00:05:41,000
No solo el servicio, sino hay que parar la máquina.

37
00:05:42,000 --> 00:05:46,000
Si hay que hacer un poquito de actualización en la base de datos, hay que hacerlo parando.

38
00:05:47,000 --> 00:05:55,000
Si en la base de datos tenemos que hacer un backup, aunque no haya SQLite admite hacer un backup en caliente, pero tienes que hacer el backup en caliente, o sea, no puedes pararlo, etc.

39
00:05:56,000 --> 00:06:03,000
Diversos problemas de seguridad porque tenemos la base de datos en primera línea, lógicamente, solo tenemos un servidor.

40
00:06:03,000 --> 00:06:08,000
No tenemos ni frontend, ni backend, ni VMZ, ni ningún tipo de vered.

41
00:06:09,000 --> 00:06:12,000
Si algún concepto, por favor, no lo entendéis, decídmelo, ¿eh?

42
00:06:13,000 --> 00:06:16,000
Porque tampoco es el nivel de todos.

43
00:06:17,000 --> 00:06:18,000
Bien.

44
00:06:19,000 --> 00:06:21,000
Problemas de seguridad porque tenemos la base de datos en primera línea.

45
00:06:22,000 --> 00:06:39,000
Un ataque al servidor, cualquier problema, del lado de una mala gestión o de una mala configuración, puede provocar que se cojan todos los datos de esa maillet security o de ese apache, etc.

46
00:06:40,000 --> 00:06:43,000
Cuello de botella, quiero decirles, lógicamente, tenemos un solo servidor.

47
00:06:44,000 --> 00:06:51,000
Si tenemos 100 usuarios, empezamos a dar de alta nuevos centros, 100 subcentros, pues se empiezan a dar nuevos alumnos, nuevos usuarios.

48
00:06:52,000 --> 00:07:03,000
El cuello de botella está en que solo tenemos una máquina atendiendo las peticiones con una única boca de red contra una única base de datos, todo en un mismo hardware y concentrado.

49
00:07:04,000 --> 00:07:15,000
Es decir, está claro que con el aumento de usuarios y de servicios provistes por esa model, el cuello de botella está ahí.

50
00:07:16,000 --> 00:07:18,000
Un único servidor sin posibilidad de escalar.

51
00:07:19,000 --> 00:07:24,000
O sea, para escalar ese servidor tendríamos que empezar a desplegar servicios, que es lo que veremos a continuación.

52
00:07:25,000 --> 00:07:38,000
Esta sería la infraestructura monolítica, estándar, con una seguridad perimetral, el acceso a internet, con ruta que nos daría el acceso, un firewall y nuestro servidor web de base de datos, de PHP y de lo que queramos.

53
00:07:39,000 --> 00:07:40,000
¿No se ve bien por atrás?

54
00:07:41,000 --> 00:07:45,000
Bueno, esa es la infraestructura monolítica, estándar.

55
00:07:46,000 --> 00:08:05,000
Podría ser más sencilla no tener el firewall y estar directamente conectado a internet, pero he querido ponerle algo de seguridad porque en la siguiente diapositiva, en los siguientes despliegues que vamos a ver, no solo vamos a tener un firewall, sino que vamos a tener incluso dos en alta disponibilidad, etc.

56
00:08:06,000 --> 00:08:18,000
Entonces, para evolucionar esta arquitectura monolítica de un único servidor, pero con una seguridad perimetral, a varios servidores con dos niveles, etc.

57
00:08:22,000 --> 00:08:25,000
Bueno, y ahora pasamos a la arquitectura distribuida y escalable.

58
00:08:26,000 --> 00:08:44,000
Primero veremos los beneficios, es decir, en base a lo que hemos estado viendo de un único servidor con todos los servicios, ver qué servicios se pueden ir repartiendo de cada uno del servidor del que partíamos.

59
00:08:44,000 --> 00:09:00,000
Es decir, el sistema operativo tendremos que tener varios, la malla SQL se podrá llevar a otro servidor y el Apache no solo se podrá llevar a un único servidor, sino tener una granja, tener una línea de servidores atendiendo peticiones.

60
00:09:02,000 --> 00:09:05,000
Entonces, ¿qué beneficios tenemos con esta arquitectura?

61
00:09:05,000 --> 00:09:20,000
N servidores, N tienda infinito, pero aquí lo vamos a decir solo como un número genérico de servidores, 2, 4, 6, en fin, ya podríamos entrar, más adelante veremos en qué opciones tenemos aparte de tener más servidores.

62
00:09:21,000 --> 00:09:29,000
Mejor escalado vertical, es decir, como os comentaba antes, si queríamos memoria para el Apache, se la dábamos a Apache, a Malla SQL y a todo lo que estuviera.

63
00:09:30,000 --> 00:09:48,000
Si necesitamos solo memoria para Apache, porque generalmente Malla SQL no consume demasiados recursos en estas plataformas, se consume más a nivel de Apache PHP, pues darle memoria, sin darle memoria, solo a aquellos servidores que ejecutan Apache y que necesitan esos recursos.

64
00:09:49,000 --> 00:10:04,000
Principalmente va orientado esta parte a temas de virtualización, como luego os explicaré un poquito, muy por encima, porque una gran instalación con tema de virtualización, bueno, de todos modos, por el final ya me centraré un poquito en ello.

65
00:10:05,000 --> 00:10:21,000
Y discos para base de datos, si la base de datos crece o el repositorio de datos de Moodle crece, pues solo hay que asignar recursos de disco a esos dispositivos que crecen y no dárselos a toda la plataforma en sí.

66
00:10:22,000 --> 00:10:37,000
El escalado horizontal, pues como os decía antes, ir añadiendo más servidores, por ejemplo, pasar de un servidor web a dos servidores web o a cuatro, en vez de un servidor de base de datos tener dos, en alta disponibilidad, activo, pasivo, etc.

67
00:10:38,000 --> 00:10:46,000
La alta disponibilidad, es decir, un servidor se nos rompe, se nos quema y entonces tenemos el otro servidor dando servicio.

68
00:10:48,000 --> 00:11:01,000
Y la distribución de carga equitativa, aquel cuello de botella que os comentaba de un único servidor que todos los usuarios, 100, 500, 1000, van a acceder, pues con tecnología hardware o tecnología física, no se ve, ¿verdad?

69
00:11:02,000 --> 00:11:04,000
Es que os veo levantándose por allí.

70
00:11:07,000 --> 00:11:15,000
Sí, sí, sí, sí, luego ya os daré el PowerPoint, lo pondré en la red y para que cualquiera lo tenga, ¿vale?

71
00:11:18,000 --> 00:11:30,000
Bien, la distribución de carga equitativa, como decía, pues con técnicas hardware, software, etc., pues ya veremos que podemos enrutar una serie de usuarios a un servidor, otro a otro, otro a otro en función de los que tengamos en la plataforma.

72
00:11:31,000 --> 00:11:45,000
Mayor nivel de seguridad. Ahora os explicaré los conceptos de frontend y backend. Como veíamos antes, la base de datos, voy a hablar de base de datos, está en el servidor que únicamente tenía un firewall para protección.

73
00:11:46,000 --> 00:11:56,000
Ahora la base de datos no va a estar arriba, va a estar abajo. Cuando digo abajo, me refiero que no va a haber un servidor, un cortafuegos protegiendo los datos.

74
00:11:56,000 --> 00:12:06,000
Va a haber dos, uno de acceso a los servidores web y otro entre los servidores web y la base de datos, con lo que acceder al segundo nivel de servidores de nuestra plataforma va a ser más complejo.

75
00:12:07,000 --> 00:12:29,000
Mayor complejidad de administración. Lógicamente no es lo mismo tener un único servidor y que el administrador sepa instalar un Red Hat o una Fedora y con una MySQL, un Apache, etc., que tener que diseñar una infraestructura con dos niveles, con dos servidores, en uno tienes el Apache, en el otro tienes la MySQL, tienes que establecer la conexión, etc., etc.

76
00:12:30,000 --> 00:12:51,000
Ya digo que un poquito más adelante hablaré de ello. Mínimos tiempo de downtime o de paradas técnicas, por así decirlo, pues es lógico, si tenemos dos servidores arriba y dos abajo, yo puedo sacar uno del servicio, actualizarlo, hacer aquellas tareas técnicas que necesite hacer sobre ese servidor, mientras tanto el otro dando servicio y luego a viceversa.

77
00:12:52,000 --> 00:13:04,000
Cambio toda la carga de trabajo al servidor que acabo de actualizar y quito el otro del servicio y lo actualizo y hago todas aquellas tareas técnicas que tenga que hacer sobre el servidor, ya sea sistema operativo, actualización, etc.

78
00:13:05,000 --> 00:13:31,000
Escalado horizontal en caliente, ¿qué significa en caliente? Pues que no necesito parar la plataforma, es decir, yo quiero meter un servidor web más, tengo uno o tengo dos, si quiero uno más, lo único que tengo que hacer es meter ese servidor, instalarle el aplicativo tal y como está en los otros dos compañeros, darle acceso a los datos comunes y habilitar el acceso a la plataforma por balanceo.

79
00:13:32,000 --> 00:13:58,000
Y el escalado vertical en caliente, pues es como lo que os comentaba del downtime, es decir, yo para añadirle más memoria a un servidor web no tengo que parar la plataforma, paro esa línea de servidor web, lo quito del balanceo, actualizo, pongo memoria, CPU, disco, lo que quiera, lo vuelvo a levantar, vuelvo a restaurar el servicio, tiro el otro, le meto memoria, etc.

80
00:13:59,000 --> 00:14:24,000
Todos esos son procedimientos que en mi oficio, por así decirlo, es algo ya estándar, deshabilitas uno de los servidores, cuando ya no hay usuarios conectados, lo quitas definitivamente, actualizas, metes memoria, aplicas parche de sistema operativo y una vez que lo tienes hecho levantas el servicio, cuando el servicio está estable vuelves a la otra pareja.

81
00:14:25,000 --> 00:14:51,000
Esta es la infraestructura básica, un único nivel, seguridad perimetral, pasaríamos como mínimo a una infraestructura de dos niveles, como veis seguimos teniendo esta parte de aquí, pero la base de datos, aparte de tener otro cortafuegos, pertenecer a otro entorno, a otro direccionamiento de red, pues tiene incluso una seguridad interna de cortafuegos.

82
00:14:52,000 --> 00:15:11,000
Con esto lo único que necesitamos es habilitar el tráfico, peticiones de la Moodle, de los servidores Apache con PHP a la MySQL, única y exclusivamente, todo el otro tráfico se bloquea, se quita y nos quitamos ese problema.

83
00:15:12,000 --> 00:15:25,000
La siguiente evolución sería algo parecido a esto, tenemos lo mismo, dos niveles, pero aquí tenemos dos servidores web, los dos están dando servicio y dos servidores de base de datos en la parte de backend.

84
00:15:25,000 --> 00:15:54,000
Ahora después os explicaré un poco más en detalle que podemos hacer con esos servidores de base de datos, depende del producto, depende del dinero y depende de los costes, los podremos tener en activo-activo, es decir, dos servidores atendiendo peticiones o únicamente activo-pasivo, un servidor atendiendo peticiones y en caso de caída de ese servidor pasar los servicios al otro, lo que se llama un cluster de alta disponibilidad en activo-pasivo.

85
00:15:56,000 --> 00:16:03,000
Si alguien quiere que le aclare algo, porque a veces veo caras de no sé si...¿de acuerdo?

86
00:16:03,000 --> 00:16:15,000
¿Qué objetivos tenemos que perseguir o queremos conseguir con un entorno distribuido y en alta disponibilidad?

87
00:16:15,000 --> 00:16:38,000
En principio es un problema, es la coherencia en los datos, es decir, si os dais cuenta tenemos dos servidores web accediendo a la misma base de datos y no solo a la misma base de datos, si habéis administrado Moodle sabéis que está el directorio que se suele denominar Moodle Data que son donde se guardan los datos de los cursos, alumnos, etc.

88
00:16:39,000 --> 00:16:47,000
Ese directorio no va a ser accedido ahora por un único servidor, va a ser accedido por más de un servidor, dos, tres, n, los que tengamos puestos.

89
00:16:48,000 --> 00:17:08,000
Ese acceso hay que cuidarlo porque dos máquinas, dos servidores Linux o dos servidores Windows accediendo al mismo disco, a la misma porción de datos del disco sin ningún tipo de seguridad puede dar una corrupción de datos.

90
00:17:08,000 --> 00:17:16,000
Es decir, tenemos que implementar sistemas de alta disponibilidad en esos servidores, bien por NFS, bien por GFS, etc.

91
00:17:17,000 --> 00:17:32,000
Reparto equitativo de carga, como os decía antes, tenemos un equipo de balanceo de carga a la entrada, ahora lo veremos en la siguiente diapositiva, justo después del router o después de la seguridad perimetral y ese será el que empiece a enviar usuarios.

92
00:17:32,000 --> 00:17:43,000
Para enviar usuarios hay muchas técnicas de reparto de carga, 2-1, 1-1, 50-50, etc. Por ejemplo, uno a un servidor, otro a un servidor, 1-1.

93
00:17:44,000 --> 00:17:54,000
Si tuviésemos un servidor con más características, por ejemplo un quad core y un dual core, podemos decirle que al dual core le mande uno y al quad core le mande dos.

94
00:17:54,000 --> 00:18:00,000
Es decir, un usuario, una petición o un usuario, dos usuarios, 1-2, sería 1-2.

95
00:18:01,000 --> 00:18:17,000
Alto número de alumnos simultáneos, lógicamente si tenemos más de un servidor atendiendo esas peticiones, no solo tenemos uno, podemos tener muchos más alumnos accediendo simultáneamente a los cursos de formación que tengamos en la red.

96
00:18:18,000 --> 00:18:32,000
Sin importarnos, nosotros gestionamos esos cursos en un único servidor y automáticamente, por el acceso a los dos servidores simultáneos, tenemos esos datos instantáneos en nuestra Moodle.

97
00:18:32,000 --> 00:18:40,000
Y siempre disponible, esto me gusta mucho porque hay mucha gente que pone lo de los 5-9, el 99,999% disponible.

98
00:18:41,000 --> 00:18:47,000
Claro, si no parcheamos, no subimos de sistema ni nada y no tenemos ningún problema, serían 100%.

99
00:18:48,000 --> 00:18:54,000
Como mucho podríamos parar 5 minutos, que creo que el 0,001% me salían 5 minutos o cosa así.

100
00:18:55,000 --> 00:19:06,000
Esos 5 minutos son los que necesitaríamos para balancear la carga, ni eso, para balancear la carga a otro servidor, actualizar ese servidor, levantar el otro, etc.

101
00:19:07,000 --> 00:19:23,000
Por ejemplo, en agosto, muchos centros, muchos colegios cierran completamente y a lo mejor en agosto puedes dedicar un día a parar completamente la plataforma, hacer un downtime o un tiempo de parada técnica de un día o de 4 horas y actualizar simultáneamente todos los servidores.

102
00:19:23,000 --> 00:19:38,000
Lógicamente a nivel de administración eso es mucho más sencillo que estar sacando servidores, parando, comprobando que ya no quedan usuarios activos en el sistema, quitarlo, actualizarlo, repartir la carga al nodo contrario, etc.

103
00:19:38,000 --> 00:19:54,000
Pero ya digo, con una alta disponibilidad, distribución de carga, etc., con los que vamos a ver ahora podríamos obtener, salvo imprevistos, 99,999% de disponibilidad.

104
00:19:54,000 --> 00:20:11,000
La coherencia de datos que comentábamos antes. Tenemos varios métodos. En rojo siempre pongo lo malo y os voy a explicar el rsync para que veáis por qué no sería lógico hacerlo así.

105
00:20:11,000 --> 00:20:27,000
La primera parte es GFS. La plataforma que hemos desplegado, que luego os mostraré, la tenemos con Red Hat Cluster y GFS. El GFS es para el acceso concurrente de datos.

106
00:20:27,000 --> 00:20:47,000
Los datos de los cursos se hacen por GFS Global File System, sistema de archivos global. Es decir, no es local, podemos repartirlo en un entorno clusterizado o de alta disponibilidad, podemos hacer un acceso concurrente a esos datos.

107
00:20:47,000 --> 00:21:07,000
Es decir, es un método de evitar esa corrupción de datos o que haya algún tipo de incoherencia en ellos. Imaginemos dos profesores modificando un centro, un curso, justo el mismo capítulo que los dos quieran modificar. Es algo complicado.

108
00:21:07,000 --> 00:21:23,000
Pero imaginemos que quieren los dos modificar en ese preciso instante algo. Pues al sistema operativo o al entorno le costaría trabajo, tendría un problema en decir cuál de los dos es el último que admite la modificación.

109
00:21:23,000 --> 00:21:47,000
Entonces, GFS se encarga de esos parámetros y de esos bloqueos de comunicación. Es decir, establece una especie de semáforos y él va transmitiendo los datos y va modificándolos de forma concurrente, evitando esa corrupción de datos.

110
00:21:47,000 --> 00:22:04,000
Y el NFS. NFS es Network File System. Sería otra opción. En vez de tener GFS, en algunas infraestructuras montar GFS puede resultar algo complicado o tener que tirar fibra óptica, un almacenamiento externo por fibra, etc.

111
00:22:04,000 --> 00:22:22,000
Con NFS podemos tener un almacenamiento local en un servidor, alto almacenamiento, con RAID 1, es decir, con discos en Mirror o con RAID 5, etc. y exportar esos directorios por NFS y que los cojan los otros servidores por NFS.

112
00:22:22,000 --> 00:22:41,000
El NFS ya de por sí lleva un sistema que permite la coherencia de datos. Es decir, como va por red y llega al sistema operativo final, es el sistema operativo final el que se encarga de repartir esas peticiones a un mismo fichero, por ejemplo.

113
00:22:41,000 --> 00:23:09,000
La parte de que vaya por red es la mala. No es lo mismo un acceso directo a una fibra de 4 gigas que tener por NFS un servidor y montar por NFS en una red a 10 o a giga, me da igual, esos datos. El rendimiento es un poco menor, sin embargo la complejidad de la administración es mucho menor que con el GFS.

114
00:23:09,000 --> 00:23:27,000
Y un pasito más adelante con el NFS sería, por ejemplo, tener dos servidores que sirvan por NFS en activo o pasivo a los otros servidores web y que el propio servidor que exporta por NFS tenga también un servidor web y dé él también el servicio.

115
00:23:27,000 --> 00:23:36,000
En fin, todo eso es ya un poquito más complejo y ya veremos que se pueden aplicar tecnologías mixtas.

116
00:23:36,000 --> 00:24:05,000
El rsync es una herramienta que permite sincronizar datos entre directorios, incluso entre archivos. Lógicamente no se puede utilizar esta herramienta porque habría que estar sincronizando de forma continua de uno a otro o del otro a uno, porque las modificaciones tanto serían en uno como en otro, es decir que no sería viable utilizar una herramienta de sincronización de archivos.

117
00:24:07,000 --> 00:24:25,000
Esta es la parte que podría ser tanto para GFS como para NFS. He puesto 5 para que sea impar, no me gustan los impares, pero para que veáis que se puede distribuir en varios servidores distintos y este sería el almacenamiento, lo he pintado como un almacenamiento compartido.

118
00:24:26,000 --> 00:24:34,000
Dos podrían llevarlo por GFS y otros tres por NFS, o los cinco por GFS o los cinco por NFS.

119
00:24:34,000 --> 00:24:58,000
El reparto equitativo de carga. Tenemos tres opciones. El mod proxy balance de Apache, con lo que tendríamos que tener otro servidor Apache por encima para repartir carga entre uno y otro.

120
00:24:58,000 --> 00:25:27,000
También hay una utilidad software muy pequeñita que se llama PEN, que tú le configuras el destino y cuántos quieres que reparta uno y cuántos a otro, pero sigue siendo algo software y requiere de una máquina aparte, porque aunque lo pudiéramos montar en uno de los servidores que dan servicio de Moodle, es decir, servicio web, tendríamos un único punto de fallo.

121
00:25:28,000 --> 00:25:37,000
Por lo que la alta disponibilidad ya se trastoca. Si solo tenemos ese reparto en un único servidor, ya nos fallaría el entorno distribuido.

122
00:25:39,000 --> 00:25:51,000
Y por último, la opción más cara y mejor, son los balanceadores físicos. Un Cisco, un CSS, un Altium, un F5, balanceando carga en activo o pasivo, los dos, etc.

123
00:25:51,000 --> 00:25:53,000
Entorno ideal, carísimo e ideal.

124
00:25:54,000 --> 00:26:10,000
Sería algo así. Tenemos el acceso prescindido de los otros elementos de base de datos, de seguridad perimetral, etc.

125
00:26:10,000 --> 00:26:30,000
Pero es para que veáis, ese componente que hemos identificado aquí, sea Apache, sea PEN, sea un balanceador, admite el grueso de peticiones y ese grueso de peticiones con la política que antes hemos establecido, 1.1.1, 1.2.2, etc., lo distribuye a cada uno de los servidores web.

126
00:26:31,000 --> 00:26:34,000
Por detrás estará la base de datos, pero en este punto lo que nos interesa es este reparto.

127
00:26:35,000 --> 00:26:50,000
¿Alto número de usuarios? Es un resumen de todo lo que hemos visto antes. A más servidores, más usuarios, a mejor ancho de banda, más usuarios, menor retardo en el servir los datos.

128
00:26:51,000 --> 00:27:02,000
Porque, por ejemplo, podemos tener un ancho de banda muy malo y, sin embargo, tener un quad core, cuatro quad cores, allí esperando a que le lleguen las peticiones.

129
00:27:05,000 --> 00:27:19,000
Que sería la imagen global. Estos serían los cursos que se ofrecen, así un poco ideológico, y el balanceo que se hace a través de nuestro servicio de balanceo.

130
00:27:21,000 --> 00:27:31,000
¿Siempre disponible? Como decíamos antes, pues aquí se ve un poco más claro. Vemos el grueso de peticiones y el reparto que se hace a cada uno de los servidores web que tenemos en nuestra plataforma.

131
00:27:32,000 --> 00:27:40,000
Ya digo que paso ahora mismo del tema de la base de datos porque no es algo que en este punto nos suponga mucho problema.

132
00:27:41,000 --> 00:27:49,000
Porque aquí hay otros agentes como acceso a internet, con gestión de datos, etcétera, que no debemos tener en nuestra infraestructura, en nuestro backend.

133
00:27:50,000 --> 00:27:59,000
Es decir, esta parte es la de frontend y la parte de backend está limpia, es algo limpio y es algo interno de la organización y no debe haber ningún tipo de problemas.

134
00:28:00,000 --> 00:28:12,000
Supongamos que queremos actualizar o se nos rompe un servidor, pues este servidor queda fuera y el reparto de carga, pues esta flechita que va para acá, se repartiría en esos otros dos.

135
00:28:13,000 --> 00:28:21,000
Es decir, la política de 1-1-1 se convertiría en 1-1 porque ese otro servidor queda fuera de servicio directamente.

136
00:28:22,000 --> 00:28:30,000
El backend, pues como decía, me gusta llamarlo el lugar de la base de datos porque es el lugar seguro de la base de datos.

137
00:28:31,000 --> 00:28:37,000
Es decir, todo aquel que tenga una base de datos en primera línea, que la cambie.

138
00:28:38,000 --> 00:28:47,000
No, ya en serio, tener la base de datos en primera línea es un riesgo donde se almacenan realmente los datos de usuarios, DNI, etcétera, en la base de datos.

139
00:28:48,000 --> 00:28:51,000
Y la base de datos siempre tiene que estar en la parte de atrás.

140
00:28:52,000 --> 00:28:53,000
Generalmente se denomina backend.

141
00:28:54,000 --> 00:28:56,000
Los servidores web siempre han estado en frontend.

142
00:28:57,000 --> 00:29:09,000
Lo que tenemos entre los servidores web y el router, es decir, la seguridad pedimetral se suele denominar DMZ, que es la zona desmilitarizada, que es en la que se encuentran los cortafuegos externos.

143
00:29:10,000 --> 00:29:18,000
Y detrás tendríamos nuestra MySQL, nuestra Postgres o nuestro Oracle RAC.

144
00:29:19,000 --> 00:29:21,000
¿Qué es un clúster activo-pasivo?

145
00:29:22,000 --> 00:29:23,000
Pues lo que os he estado comentando.

146
00:29:24,000 --> 00:29:36,000
Podemos tener nuestra MySQL en un servidor dando servicio y tener otro servidor completamente configurado y de modo automatizado con Veritas Cluster o Red Hat Cluster o cualquier otro sistema de clustering,

147
00:29:36,000 --> 00:29:41,000
esperando, que se denomina pasivo, por si el otro servidor cae.

148
00:29:42,000 --> 00:29:56,000
Es decir, el otro servidor pierde la interfaz de red, no consigue arrancar Apache por cualquier motivo, perdón, MySQL por cualquier motivo, y le pasaría el servicio al otro servidor, que debería levantar el servicio correctamente.

149
00:29:57,000 --> 00:30:02,000
Luego está Oracle RAC, una pasta que es activo-pasivo.

150
00:30:03,000 --> 00:30:15,000
Es decir, podríamos tener con GFS, en IBM creo que se llama GPFS, que es Global Parallel File System, luego para que tengáis, podáis mirar otra información.

151
00:30:16,000 --> 00:30:29,000
Oracle RAC dispondría de ese GFS en la parte de atrás y por la parte de arriba estaría Oracle, que sería él el que pondría los medios para evitar esa corrupción de datos.

152
00:30:30,000 --> 00:30:41,000
No esa corrupción de datos, la corrupción de datos la haría GFS, pero por ejemplo, a la hora de dar de alta una fila, sabéis que se le asigna un timestamp.

153
00:30:41,000 --> 00:30:52,000
Si el timestamp se diese en los dos servidores a la vez, sin tener Oracle RAC o sin tener otros medios, podría haber un conflicto porque se intentaría meter una fila con un timestamp igual.

154
00:30:53,000 --> 00:31:05,000
Oracle RAC es Real Application Cluster, como veis nosotros vamos por lo libre.

155
00:31:06,000 --> 00:31:21,000
Oracle RAC implementa aquellos métodos para que ese timestamp, en este caso que es una cosa pequeñita, un ejemplo sencillo, ese timestamp no haya problemas, no haya conflictos.

156
00:31:22,000 --> 00:31:27,000
Le asigne un segundo o una modificación mínima a la fila que se está modificando.

157
00:31:28,000 --> 00:31:29,000
Y por último Postgres.

158
00:31:30,000 --> 00:31:39,000
Postgres, ahora últimamente tiene más nombre MySQL porque MySQL tiene mucho más marketing.

159
00:31:40,000 --> 00:31:44,000
SAN la ha comprado antes de que SAN fuera comprado por Oracle y le dio mucho bombo.

160
00:31:45,000 --> 00:31:53,000
Hay un entorno profesional de MySQL disponible a través de SAN, etc.

161
00:31:53,000 --> 00:32:02,000
Sin embargo, Postgres ha venido demostrando mucho tiempo atrás que es un gestor de base de datos de mucho más alto rendimiento que MySQL.

162
00:32:03,000 --> 00:32:10,000
Lo único es que, por ejemplo, el acceso a una MySQL desde línea de comandos es bastante más sencillo que el de una Postgres.

163
00:32:11,000 --> 00:32:13,000
Yo no sé si alguien ha tocado Postgres o tiene Postgres.

164
00:32:24,000 --> 00:32:28,000
Postgres. Eso se hace solo en Postgres.

165
00:32:29,000 --> 00:32:41,000
La dificultad de saber configurar eso. La configura sin más funciona, pero se ha configurado con los parámetros de funcionamiento muy bajos.

166
00:32:42,000 --> 00:32:49,000
Nosotros en el portal Educamadrid tenemos Postgres desplegada.

167
00:32:50,000 --> 00:32:51,000
Utilizamos Postgres.

168
00:32:52,000 --> 00:32:55,000
Lo que pasa es que también tenemos MySQL.

169
00:32:56,000 --> 00:32:59,000
El aula de formación que os presentaré ahora después está desplegada sobre MySQL.

170
00:33:00,000 --> 00:33:23,000
Ya digo que siempre Postgres tiene más nombre, pero tiene el problema de que hay tantos más parámetros en Postgres que resulta bastante complicado llegar a una optimización o a un tuning de la misma que digas que va mejor que una MySQL.

171
00:33:23,000 --> 00:33:25,000
MySQL es algo más sencillo.

172
00:33:26,000 --> 00:33:29,000
Por ejemplo, el caché de consultas de MySQL tú lo puedes configurar.

173
00:33:30,000 --> 00:33:31,000
Postgres ya lo hace solo.

174
00:33:32,000 --> 00:33:38,000
Ya se ocupa de ese tema, que es algo de lo que más he batallado, el tema del cacheo de consultas.

175
00:33:39,000 --> 00:33:46,000
Postgres da mejor rendimiento que una MySQL, pero para un entorno mucho más heterogéneo.

176
00:33:47,000 --> 00:33:58,000
Y lo único, si te apetece meterte con una base de datos que no es tan estándar o que no está mejor que estándar, que no tiene la distribución o difusión que tiene MySQL.

177
00:33:59,000 --> 00:34:04,000
Aunque hay un proveedor que da servicios profesionales de Postgres, pero no recuerdo ahora mismo.

178
00:34:07,000 --> 00:34:08,000
Esta sería la parte de backend.

179
00:34:09,000 --> 00:34:18,000
Luego ya os engancharé las dos opciones, os engancharé las dos transparencias y ya veréis la parte completa y compleja.

180
00:34:19,000 --> 00:34:27,000
Este sería backend, nuestro servidor de base de datos y los datos en un almacenamiento compartido, ya sea para activo o pasivo o para alta disponibilidad.

181
00:34:28,000 --> 00:34:37,000
También he visto por ahí, hay un software que se llama SolidDB, que creo que da acceso simultáneo también a MySQL, etc.

182
00:34:38,000 --> 00:34:39,000
Lo comento luego un poquito.

183
00:34:42,000 --> 00:34:45,000
Y esta es nuestra super arquitectura guay del Paraguay.

184
00:34:47,000 --> 00:34:50,000
Tenemos todos los alumnos accediendo.

185
00:34:51,000 --> 00:34:55,000
Se me ha olvidado el router, lo siento, el router está ahí.

186
00:34:56,000 --> 00:35:01,000
En medio tenemos la seguridad perimetral, dos cortafuegos en alta disponibilidad, activo o pasivo.

187
00:35:02,000 --> 00:35:06,000
Dos balanceadores de carga, no lo pone pero estos son ciscos.

188
00:35:07,000 --> 00:35:11,000
Dos ciscos en activo o pasivo que reparten la carga según la política que le hemos establecido.

189
00:35:11,000 --> 00:35:25,000
Esta sería la parte de DMZ donde están los servidores cortafuegos y esta es la de frontend que es donde están nuestros cuatro servidores web con el almacenamiento SAN, red de área local.

190
00:35:26,000 --> 00:35:36,000
Servidor NFS lo he dejado en modo, o sea nosotros no estamos usando NFS, pero si te refieres a una NAS o algo así.

191
00:35:37,000 --> 00:35:39,000
No, me refiero a que si ahí habla que hay...

192
00:35:40,000 --> 00:35:41,000
Ah, sí, no.

193
00:35:42,000 --> 00:35:43,000
Si saca NFS...

194
00:35:44,000 --> 00:35:53,000
Sí, sí, sí, exactamente. Lo que me refería es que, por ejemplo, estos dos servidores cogen estos datos por GFS y los portan por NFS a estos dos.

195
00:35:54,000 --> 00:35:56,000
O estos cuatro por GFS.

196
00:35:56,000 --> 00:36:08,000
O sea, quería... es que como son muchas opciones he intentado agrupar en una sola transparencia el entorno ideal y de alto rendimiento de toda la plataforma.

197
00:36:16,000 --> 00:36:17,000
¿Del NFS?

198
00:36:18,000 --> 00:36:29,000
No lo hemos utilizado, pero en caso de utilizar un NFS no solo tocaríamos ese parámetro, sino que crearíamos una red solo para el NFS.

199
00:36:30,000 --> 00:36:37,000
Sabes que tenemos la red de frontend, una red de gestión, una red de interconexión entre frontend y backend y una red de backup.

200
00:36:38,000 --> 00:36:45,000
Pues en caso de utilizar NFS yo, si dispone de los recursos, los medios, tarjetas, etcétera, pondría una red solo para NFS.

201
00:36:46,000 --> 00:36:48,000
Ni SSH ni tráfico que haya por ahí, nada, NFS.

202
00:36:49,000 --> 00:37:00,000
Luego ya sí, tocarías algo de tuning de NFS, de parámetros para exportarlo, etcétera, pero teniendo una red a giga, por ejemplo, para el NFS yo creo que el rendimiento es aceptable.

203
00:37:01,000 --> 00:37:05,000
Lo que pasa es que hay muchos sitios en los que el servidor tiene a lo mejor una o dos tarjetas de red.

204
00:37:06,000 --> 00:37:11,000
Comprar una quad ya te supone a lo mejor mil euros solo lo que es la tarjeta, etcétera, etcétera.

205
00:37:13,000 --> 00:37:14,000
¿Alguna cuestión más?

206
00:37:16,000 --> 00:37:17,000
Bueno, sigo adelante.

207
00:37:19,000 --> 00:37:22,000
Os voy a comentar otras opciones que podemos tener en consideración.

208
00:37:22,000 --> 00:37:23,000
Dime.

209
00:37:38,000 --> 00:37:40,000
Una SAN puede ser tan complicada como tú quieras.

210
00:37:41,000 --> 00:37:51,000
Puedes tener un cajón con dos alimentaciones, seis discos, otro cajón con dos alimentaciones, seis discos, establecer un RAID 1 que es mirror de esos seis discos con la otra.

211
00:37:52,000 --> 00:37:54,000
¿No estás hablando de una SAN?

212
00:37:54,000 --> 00:37:55,000
No, no, no.

213
00:37:56,000 --> 00:37:58,000
Un cajoncito no, no, no.

214
00:37:59,000 --> 00:38:14,000
Estoy hablando, por ejemplo, un cajón, hasta hace poco SAN tenía unos 3510 que ya los ha jubilado, pero esos 3510 disponían de doble fuente de alimentación, doble controladora, hasta ocho conexiones de fibra.

215
00:38:15,000 --> 00:38:20,000
Luego le enganchabas otro cajón igual, maestro también, podías interconectarlo.

216
00:38:21,000 --> 00:38:24,000
Si te iba por completo un cajón, pues siempre tenías el mirror en el otro.

217
00:38:25,000 --> 00:38:38,000
O, por ejemplo, una EVA de HP que tú puedes establecer que, bueno, eso ya lo hace ella interna, se lo hace todo y hasta tres piezas, creo, cuatro se tienen que romper para perder servicio.

218
00:38:38,000 --> 00:38:45,000
O sea, es un término, lo he puesto muy genérico, pero entendiendo las distintas opciones que se pueden añadir.

219
00:38:47,000 --> 00:38:53,000
Bueno, otras opciones o otras consideraciones que podríamos tener en un entorno, por ejemplo, la virtualización.

220
00:38:54,000 --> 00:39:01,000
Podemos virtualizar servidores, por ejemplo, si tenemos un servidor muy grande, pues a lo mejor distribuirlo en dos servidores.

221
00:39:02,000 --> 00:39:15,000
Si ese servidor tiene doble fuente de alimentación, tenemos ocho interfaces de red, hay servidores que te permiten pinchar y despinchar elementos hardware según que elementos hardware en caliente, etc.

222
00:39:16,000 --> 00:39:22,000
Y de esta forma podemos aislar o compartimentar el uso de recursos que se hacen.

223
00:39:23,000 --> 00:39:31,000
Por ejemplo, un servidor le das ocho gigas para el PHP, a otro le das cuatro y a ese le das menos uso, en fin.

224
00:39:32,000 --> 00:39:36,000
Luego también podríamos distribuir los cursos por plataformas.

225
00:39:37,000 --> 00:39:47,000
Imaginemos que, como he puesto máster y posgrado, podríamos tener usuarios que no tienen relación entre ellos, por ejemplo, Ingeniería Técnica e Ingeniería Superior.

226
00:39:48,000 --> 00:39:53,000
Pues, aunque pase de la técnica a la superior, no hay relación entre una y otra.

227
00:39:54,000 --> 00:39:59,000
Podrías tener unos servidores dedicados a un entorno y otros servidores dedicados al otro.

228
00:40:00,000 --> 00:40:06,000
Por ejemplo, en EducaMadrid ahora veremos que tenemos dos plataformas, una para aula virtual de centros y otra para formación en línea del profesorado.

229
00:40:07,000 --> 00:40:11,000
Son distintas, no tienen relación entre ellos y cada una va por separado y son entornos similares.

230
00:40:12,000 --> 00:40:15,000
Mezcla de conceptos, que es lo que llevo todo el rato comentando.

231
00:40:16,000 --> 00:40:20,000
GFS, no GSF.

232
00:40:21,000 --> 00:40:22,000
GFS más NFS.

233
00:40:23,000 --> 00:40:24,000
Oracle RAC.

234
00:40:25,000 --> 00:40:32,000
ScalaDB, que estuve viendo hace poco una presentación y era algo similar a Oracle RAC, pero independientemente de la base de datos.

235
00:40:33,000 --> 00:40:34,000
Podría ser MySQL, Postgres.

236
00:40:34,000 --> 00:40:41,000
Y, bueno, la nube, que todo el mundo habla del cloud computing, pues tener los servidores alojados, etc.

237
00:40:42,000 --> 00:40:44,000
No voy a entrar en eso porque, en fin.

238
00:40:45,000 --> 00:40:49,000
Y, por último, os voy a presentar el caso práctico de EducaMadrid.

239
00:40:50,000 --> 00:40:58,000
Esta es una infraestructura que existe, que la mantenemos, la hemos desplegado y hay usuarios accediendo a ella.

240
00:40:59,000 --> 00:41:00,000
¿En qué se basa?

241
00:41:00,000 --> 00:41:06,000
Pues tenemos el sistema operativo base, es una reja de Linux Enterprise Server 5.3.

242
00:41:07,000 --> 00:41:16,000
Con las opciones de Cluster y Global File System, tanto para el entorno de servidores web como el entorno de servidores de base de datos.

243
00:41:17,000 --> 00:41:21,000
La base de datos en backend es una MySQL, como os comentaba antes.

244
00:41:22,000 --> 00:41:25,000
La arquitectura es AMD Opteron Quad Core.

245
00:41:26,000 --> 00:41:30,000
Cada servidor tiene 4 Quad Cores, es decir, 16 Cores.

246
00:41:31,000 --> 00:41:33,000
24 GB de memoria RAM.

247
00:41:34,000 --> 00:41:39,000
Tenemos los 4 servidores, son HP ProLiant DL585 G5.

248
00:41:40,000 --> 00:41:41,000
Es este pequeñito.

249
00:41:42,000 --> 00:41:44,000
¿Veis? Todos esos son discos que se le pueden ir ampliando localmente.

250
00:41:45,000 --> 00:41:48,000
Pero no nos interesa el almacenamiento del servidor.

251
00:41:49,000 --> 00:41:54,000
Y un almacenamiento compartido de SAN Microsystem 2540.

252
00:41:55,000 --> 00:41:58,000
Ese sí nos interesa a los discos, que es el que da servicio.

253
00:41:59,000 --> 00:42:01,000
Aquí sí tenemos un único punto de fallo, porque sólo tenemos una SAN.

254
00:42:02,000 --> 00:42:03,000
Entre comillas.

255
00:42:04,000 --> 00:42:07,000
Esa SAN tiene doble fuente de alimentación y los discos están en RAID.

256
00:42:08,000 --> 00:42:11,000
Se me tienen que ir las dos fuentes de alimentación simultáneamente.

257
00:42:12,000 --> 00:42:13,000
Esperemos que no.

258
00:42:14,000 --> 00:42:18,000
Y dos o tres discos que formen un RAID 5 o un RAID 1.

259
00:42:19,000 --> 00:42:24,000
Y el disco de espera de resincronización que no esté disponible para asumir tal carga.

260
00:42:25,000 --> 00:42:33,000
Pero en principio con un almacenamiento de este estilo podemos dormir más o menos tranquilos los que administramos la plataforma.

261
00:42:34,000 --> 00:42:38,000
Y por último, la URL, la de formación EDUKAMADRIARG de EDUKAMADRI.

262
00:42:39,000 --> 00:42:44,000
Y estos son algunos datos de los dos que tenemos.

263
00:42:45,000 --> 00:42:52,000
El primero es formación del profesorado, con 4.800 usuarios dados de alta ahora mismo.

264
00:42:53,000 --> 00:42:57,000
Se prevé que llegue a unos 6.200 a lo largo del presente curso.

265
00:42:57,000 --> 00:43:02,000
Ahora mismo cursos activos sólo hay 23, nueve se van a incorporar.

266
00:43:03,000 --> 00:43:07,000
Están ya dados de alta, digamos, o que se conoce de ellos.

267
00:43:08,000 --> 00:43:09,000
Luego se podrán ir dando de alta más.

268
00:43:10,000 --> 00:43:14,000
Y la otra infraestructura es la de centros educativos, en la que tenemos 15.000 usuarios.

269
00:43:15,000 --> 00:43:17,000
Se prevén unos 3.000 más, 18.000.

270
00:43:18,000 --> 00:43:20,000
Y tiene 600 cursos activos.

271
00:43:20,000 --> 00:43:27,000
Así mismo tenemos 200 centros educativos con espacio virtual en ese centro de formación.

272
00:43:31,000 --> 00:43:34,000
Pues... no lo sé.

273
00:43:37,000 --> 00:43:38,000
Sí.

274
00:43:39,000 --> 00:43:41,000
Pues... la verdad es que no lo sé.

275
00:43:43,000 --> 00:43:45,000
Si no lo sé es porque no es un problema.

276
00:43:50,000 --> 00:43:52,000
Si no lo sé digo que no es problema.

277
00:43:53,000 --> 00:43:57,000
No hombre, nosotros sí tenemos balanceo de carga por hardware, etc.

278
00:43:58,000 --> 00:44:02,000
Y el número de usuarios concurrentes pues a lo mejor puede ser 500, pero claro, en los dos servidores.

279
00:44:03,000 --> 00:44:07,000
250 por servidor, más otros 250 en los otros dos servidores.

280
00:44:08,000 --> 00:44:09,000
Tenemos dos infraestructuras.

281
00:44:10,000 --> 00:44:14,000
Aparte de que el profesorado pues no es algo que vayan todos concurrentemente.

282
00:44:15,000 --> 00:44:18,000
Es una distribución de carga bastante lineal.

283
00:44:19,000 --> 00:44:21,000
Esta es la página principal de formación.

284
00:44:22,000 --> 00:44:23,000
Bueno, ya conocéis todos una Moodle.

285
00:44:24,000 --> 00:44:25,000
Sois más expertos que yo en esa parte.

286
00:44:26,000 --> 00:44:28,000
Y bueno, pues esto es...

287
00:44:29,000 --> 00:44:31,000
Esta es la infraestructura de Educamadrid.

288
00:44:32,000 --> 00:44:34,000
De la parte de formación del profesorado de Educamadrid.

289
00:44:36,000 --> 00:44:39,000
Como ya os he comentado es un Rehash Cluster con GFS, etc.

290
00:44:40,000 --> 00:44:42,000
Si veis el almacenamiento no hay dos.

291
00:44:43,000 --> 00:44:44,000
Hay uno.

292
00:44:44,000 --> 00:44:49,000
Es decir, ese almacenamiento es compartido con los datos de Moodle y con los de base de datos.

293
00:44:51,000 --> 00:44:54,000
No nos importa porque ese almacenamiento es escalable verticalmente.

294
00:44:55,000 --> 00:44:59,000
Horizontalmente también, pero horizontalmente ya está copado.

295
00:45:00,000 --> 00:45:02,000
Es decir, ya están todos los discos puestos y sería vertical...

296
00:45:03,000 --> 00:45:04,000
Perdón, es escalable horizontalmente.

297
00:45:05,000 --> 00:45:08,000
Es decir, podemos añadir más cajones con más discos, etc.

298
00:45:09,000 --> 00:45:10,000
Y está compartido.

299
00:45:11,000 --> 00:45:17,000
Hay una red de almacenamiento por fibra para que tanto los servidores activo-activo del web

300
00:45:18,000 --> 00:45:22,000
como el activo-pasivo de MySQL puedan acceder a su región de datos asignada.

301
00:45:23,000 --> 00:45:27,000
Es decir, ese cajón, ese almacenamiento externo tiene un panel de control

302
00:45:28,000 --> 00:45:31,000
y yo puedo asignar recursos a uno o a otro.

303
00:45:34,000 --> 00:45:37,000
Bueno, pues esta es la infraestructura que tenemos allí en Educamadrid.

304
00:45:40,000 --> 00:45:43,000
Preveemos meter dos servidores más de...

305
00:45:56,000 --> 00:45:58,000
Espacio en disco cuando tenemos para la Moodle.

306
00:46:00,000 --> 00:46:03,000
Para el Moodle Data, 200 gigas o algo así, asignados.

307
00:46:06,000 --> 00:46:07,000
No me acuerdo.

308
00:46:10,000 --> 00:46:17,000
Date cuenta que es un cajón con 12 discos de 360 gigas y no me importa.

309
00:46:18,000 --> 00:46:20,000
O sea, no es un problema a corto plazo.

310
00:46:21,000 --> 00:46:23,000
Le dimos bastante espacio. Yo creo que son entre 100 y 200 gigas.

311
00:46:24,000 --> 00:46:26,000
No, 300 gigas más bien.

312
00:46:27,000 --> 00:46:28,000
Para la Moodle Data.

313
00:46:31,000 --> 00:46:33,000
Más o menos debe ser eso.

314
00:46:34,000 --> 00:46:37,000
Bueno, tenemos previsión de añadir otros dos servidores.

315
00:46:38,000 --> 00:46:43,000
Todavía no tenemos claro si va a ser por GFS o por NFS.

316
00:46:44,000 --> 00:46:47,000
Haremos pruebas de una parte o de otra.

317
00:46:50,000 --> 00:46:51,000
Sí, sí, dime, dime.

318
00:47:08,000 --> 00:47:09,000
Acelerador de la hoja de HP.

319
00:47:10,000 --> 00:47:13,000
Sería un servidor, ni menos, desde el HTML.

320
00:47:15,000 --> 00:47:17,000
¿LiveHTTP y demás?

321
00:47:18,000 --> 00:47:19,000
¿LiveHTTP?

322
00:47:20,000 --> 00:47:21,000
LiveHTTP y acelerador.

323
00:47:23,000 --> 00:47:24,000
No.

324
00:47:25,000 --> 00:47:26,000
Tampoco habéis probado...

325
00:47:29,000 --> 00:47:31,000
Es un cuestionario más de rendimiento, de realidad.

326
00:47:34,000 --> 00:47:36,000
Tampoco habéis probado la versión...

327
00:47:37,000 --> 00:47:38,000
La versión final de HPD.

328
00:47:42,000 --> 00:47:44,000
Nos hemos centrado en parte más estándar.

329
00:47:46,000 --> 00:47:49,000
Sobre todo para prestar el servicio, porque esto está en producción.

330
00:47:51,000 --> 00:47:55,000
En este verano fue montar la infraestructura y dar servicio.

331
00:47:56,000 --> 00:47:59,000
Miento, este verano no, a principios de año fue montar la infraestructura.

332
00:48:00,000 --> 00:48:02,000
Y cuando empiezas con temas...

333
00:48:03,000 --> 00:48:05,000
No quiero decir de laboratorio.

334
00:48:08,000 --> 00:48:10,000
Pero que ya te sales un poco de la norma.

335
00:48:13,000 --> 00:48:17,000
Prefieres dar el servicio con algo que ya está probado y lo conoces.

336
00:48:18,000 --> 00:48:19,000
¿Y última cuestión?

337
00:48:22,000 --> 00:48:23,000
No lo sé.

338
00:48:24,000 --> 00:48:27,000
Ya os digo que yo voy de la parte... Creo que es la 1.8.

339
00:48:28,000 --> 00:48:29,000
Es muy significativo.

340
00:48:33,000 --> 00:48:35,000
La 1... Perdona, la 1.9.5.

341
00:48:37,000 --> 00:48:38,000
La 1.9.5.

342
00:48:39,000 --> 00:48:42,000
Ya digo que es que yo no entro a administrar la Moodle.

343
00:48:43,000 --> 00:48:47,000
Sencillamente despliego el entorno y me encargo de que funcione.

344
00:48:48,000 --> 00:48:51,000
La última versión... Creo que la última actualización la hizo un compañero.

345
00:48:52,000 --> 00:48:55,000
Esa parte ya es más de aplicaciones, del equipo de aplicaciones.

346
00:48:56,000 --> 00:48:57,000
Más que de sistemas.

347
00:48:58,000 --> 00:49:00,000
Pero me comenta que la 1.9.5 es la que tenemos desplegada.

348
00:49:02,000 --> 00:49:04,000
¿Habéis tenido algún problema en su acuerdo?

349
00:49:05,000 --> 00:49:07,000
La conclusión de saber si se concentra ese...

350
00:49:08,000 --> 00:49:10,000
No, porque usamos GRBD.

351
00:49:11,000 --> 00:49:12,000
Para el acceso a la Moodle.

352
00:49:13,000 --> 00:49:14,000
Al Moodle Data.

353
00:49:15,000 --> 00:49:17,000
Es que si no lo configuras correctamente...

354
00:49:19,000 --> 00:49:22,000
De hecho, no sería necesario tener clúster.

355
00:49:23,000 --> 00:49:25,000
Ya que los servidores van a acceder de forma simultánea.

356
00:49:26,000 --> 00:49:27,000
Y da igual que se me caiga este, tiene que seguir.

357
00:49:28,000 --> 00:49:30,000
Sin embargo, hay que establecer un clúster completo en Red Hat.

358
00:49:30,000 --> 00:49:32,000
Para que ese acceso sea...

359
00:49:33,000 --> 00:49:36,000
Para que certifique eso.

360
00:49:37,000 --> 00:49:39,000
Para que ese acceso no tenga corrupción de datos.

361
00:49:40,000 --> 00:49:43,000
O sea, tiene una parte un poco compleja en esa parte.

362
00:49:44,000 --> 00:49:46,000
Para el tema de acceso a la Moodle Data.

363
00:49:53,000 --> 00:49:54,000
Cuello de botella en la base de datos.

364
00:50:01,000 --> 00:50:02,000
Añades otro servidor.

365
00:50:03,000 --> 00:50:04,000
Añades otro virtual.

366
00:50:05,000 --> 00:50:07,000
Pero van a cargar todos en una base de datos.

367
00:50:08,000 --> 00:50:09,000
Ahí es donde está el problema.

368
00:50:18,000 --> 00:50:19,000
Nosotros, es lo que decíamos.

369
00:50:20,000 --> 00:50:22,000
Tanto para Postgres como MySQL.

370
00:50:23,000 --> 00:50:24,000
Es optimizar, hacerle tuning.

371
00:50:25,000 --> 00:50:26,000
Los parámetros.

372
00:50:27,000 --> 00:50:28,000
Porque es un servidor y es una interfaz.

373
00:50:28,000 --> 00:50:29,000
Puedes tener más interfaces.

374
00:50:30,000 --> 00:50:31,000
Dar más capacidad.

375
00:50:32,000 --> 00:50:33,000
Pero al final, al backend, es una base de datos.

376
00:50:34,000 --> 00:50:35,000
Ya si tienes un problema serio.

377
00:50:36,000 --> 00:50:37,000
En el acceso a base de datos.

378
00:50:38,000 --> 00:50:40,000
Tendrás que irte a un entorno estilo Oracle RAC.

379
00:50:41,000 --> 00:50:43,000
O hay una solución.

380
00:50:48,000 --> 00:50:49,000
¿De Postgres?

381
00:50:51,000 --> 00:50:52,000
No, yo lo único que encontré fue la parte esta.

382
00:50:53,000 --> 00:50:54,000
De SolidDB.

383
00:50:55,000 --> 00:50:56,000
Que es como una especie de capa intermedia.

384
00:50:57,000 --> 00:50:58,000
No, perdón.

385
00:50:59,000 --> 00:51:00,000
Capa intermedia entre el gestor de base de datos.

386
00:51:01,000 --> 00:51:02,000
O los N gestores de base de datos.

387
00:51:03,000 --> 00:51:04,000
Y el acceso a la tabla.

388
00:51:05,000 --> 00:51:06,000
Entonces, él es el que se encarga de distribuir.

389
00:51:07,000 --> 00:51:08,000
Hace lo que Oracle RAC.

390
00:51:09,000 --> 00:51:10,000
Solo que independiente del gestor de base de datos.

391
00:51:11,000 --> 00:51:12,000
Pero ya te digo.

392
00:51:13,000 --> 00:51:14,000
Fue una presentación así por encima.

393
00:51:15,000 --> 00:51:17,000
Que tampoco me dio tiempo a preguntarle cómo es.

394
00:51:21,000 --> 00:51:22,000
Bueno, os dejo unos cuantos enlaces.

395
00:51:23,000 --> 00:51:24,000
Para que luego los veáis.

396
00:51:24,000 --> 00:51:25,000
Sobre todo el del PEN.

397
00:51:26,000 --> 00:51:27,000
Y el de ScalaDB.

398
00:51:28,000 --> 00:51:29,000
Que es el que más os interesa.

399
00:51:32,000 --> 00:51:33,000
Y bueno, pues ya lo he terminado.

400
00:51:34,000 --> 00:51:35,000
Si queréis preguntarme algo.

401
00:51:36,000 --> 00:51:37,000
Dime.

402
00:51:50,000 --> 00:51:51,000
Habla un poco más alto.

403
00:51:54,000 --> 00:51:55,000
Ponte de pie, ponte de pie.

404
00:52:09,000 --> 00:52:10,000
Cinco.

405
00:52:25,000 --> 00:52:26,000
Claro.

406
00:52:41,000 --> 00:52:42,000
En Santa Julia no lo tendréis, ¿verdad?

407
00:52:43,000 --> 00:52:44,000
En Santa Julia no lo tendréis, ¿verdad?

408
00:52:51,000 --> 00:52:52,000
Sí.

409
00:52:52,000 --> 00:52:53,000
Porque eso no es alta disponibilidad.

410
00:52:54,000 --> 00:52:55,000
O sea.

411
00:52:56,000 --> 00:52:57,000
Eso es business recovery.

412
00:52:58,000 --> 00:53:01,000
Eso es establecer un sistema de recuperación de negocio.

413
00:53:11,000 --> 00:53:12,000
Es que sí, sí, sí.

414
00:53:13,000 --> 00:53:15,000
El único problema que tendrías es tirar fibra.

415
00:53:17,000 --> 00:53:19,000
De cuatro gigas mínimo entre un centro y el otro.

416
00:53:23,000 --> 00:53:24,000
Ya está.

417
00:53:29,000 --> 00:53:30,000
Es tan sencillo como eso.

418
00:53:32,000 --> 00:53:33,000
Y lo tenéis por fibra.

419
00:53:35,000 --> 00:53:36,000
O incluso fibra óptica.

420
00:53:52,000 --> 00:53:53,000
Es que es alta disponibilidad.

421
00:53:54,000 --> 00:53:55,000
¿Qué base de datos tenéis?

422
00:53:56,000 --> 00:53:57,000
¿Tenéis eso y no tenéis Oracle y RAC?

423
00:54:01,000 --> 00:54:04,000
Es que, por ejemplo, lo normal es que eso es caro.

424
00:54:06,000 --> 00:54:07,000
Tú lo sabrás mejor.

425
00:54:08,000 --> 00:54:09,000
Sin embargo, hay otra solución a corto plazo.

426
00:54:10,000 --> 00:54:11,000
Que es tener un site de respaldo.

427
00:54:12,000 --> 00:54:13,000
Es decir, tú tienes allí.

428
00:54:14,000 --> 00:54:16,000
En vez de tener cuatro servidores arriba y dos abajo.

429
00:54:17,000 --> 00:54:18,000
Pues tienes dos servidores solo.

430
00:54:19,000 --> 00:54:20,000
Y por la noche o a cada hora.

431
00:54:22,000 --> 00:54:23,000
Replicas esos datos en ese servidor.

432
00:54:24,000 --> 00:54:25,000
En ese centro de respaldo.

433
00:54:26,000 --> 00:54:27,000
Si se te quema ese CPD.

434
00:54:28,000 --> 00:54:29,000
Automáticamente hablas con tu operador.

435
00:54:30,000 --> 00:54:31,000
Y redireccionas el servicio al otro.

436
00:54:32,000 --> 00:54:33,000
Y pierdes a lo mejor una hora de datos.

437
00:54:34,000 --> 00:54:35,000
O si lo tienes un hot site.

438
00:54:38,000 --> 00:54:40,000
Pues entonces lo tienes completamente replicado online.

439
00:54:41,000 --> 00:54:42,000
Pero eso es pasta.

440
00:54:43,000 --> 00:54:44,000
Y a Santa Julia no lo llevéis.

441
00:54:45,000 --> 00:54:46,000
¿No sabéis dónde está Santa Julia?

442
00:54:47,000 --> 00:54:48,000
Eso está en Mérida.

443
00:54:50,000 --> 00:54:51,000
La Consejería de Educación de Mérida.

444
00:54:52,000 --> 00:54:53,000
A Santa Julia no.

445
00:54:55,000 --> 00:54:56,000
Bueno, ¿alguna cuestión más?

446
00:55:16,000 --> 00:55:17,000
Hablamos también de la opción de Oracle.

447
00:55:18,000 --> 00:55:20,000
Lo que pasa es que no funcionaba bien con Google.

448
00:55:21,000 --> 00:55:24,000
Al final, las operaciones de Google con Oracle no nos daban problemas.

449
00:55:25,000 --> 00:55:28,000
Entonces la opción a la que tú hemos dado que ese problema parecía un poco justito.

450
00:55:29,000 --> 00:55:30,000
Para una cantidad de usuarios.

451
00:55:31,000 --> 00:55:32,000
Ha sido Postgres.

452
00:55:33,000 --> 00:55:34,000
Lo que pasa es que en Postgres.

453
00:55:35,000 --> 00:55:36,000
Si no recuerdo mal.

454
00:55:37,000 --> 00:55:39,000
No permite balanceo de carga entre varios servidores.

455
00:55:40,000 --> 00:55:42,000
Entonces tenemos una única máquina con Postgres.

456
00:55:43,000 --> 00:55:44,000
Que está funcionando bien.

457
00:55:44,000 --> 00:55:46,000
Hemos encontrado el mayor pepino que hemos visto.

458
00:55:47,000 --> 00:55:49,000
Pero bueno, estamos con 20.000 usuarios.

459
00:55:50,000 --> 00:55:51,000
Y la carga que tienen es importante.

460
00:55:52,000 --> 00:55:54,000
Pero ¿tenéis dos niveles también y demás?

461
00:55:55,000 --> 00:55:56,000
Sí, tenemos todos los niveles.

462
00:55:57,000 --> 00:55:59,000
Pero la base de datos es una única máquina.

463
00:56:00,000 --> 00:56:02,000
Me refiero a que no hay otros problemas de congestión de red.

464
00:56:03,000 --> 00:56:04,000
Sí, los servidores web han sobrado.

465
00:56:05,000 --> 00:56:06,000
Tenemos balanceo de carga.

466
00:56:07,000 --> 00:56:08,000
Tenemos acciones.

467
00:56:09,000 --> 00:56:12,000
Y el mayor problema el encontramos en la base de datos.

468
00:56:12,000 --> 00:56:14,000
Cuando tenemos 300 usuarios.

469
00:56:15,000 --> 00:56:16,000
Estamos escribiendo en la base de datos.

470
00:56:17,000 --> 00:56:18,000
La base de datos.

471
00:56:19,000 --> 00:56:20,000
Sí.

472
00:56:21,000 --> 00:56:22,000
Sí.

473
00:56:23,000 --> 00:56:24,000
Estoy comentando que en WeDevice.org.

474
00:56:25,000 --> 00:56:26,000
Nos encontramos sobre todo.

475
00:56:27,000 --> 00:56:28,000
En la base de datos de Postgres.

476
00:56:29,000 --> 00:56:30,000
Que tenemos.

477
00:56:31,000 --> 00:56:32,000
Y entonces estamos buscando.

478
00:56:33,000 --> 00:56:34,000
La manera de optimizar al máximo.

479
00:56:35,000 --> 00:56:36,000
Esa base de datos.

480
00:56:37,000 --> 00:56:38,000
Por cierto es que la máquina en sí.

481
00:56:39,000 --> 00:56:40,000
Depende del FPU.

482
00:56:40,000 --> 00:56:42,000
Pero creo que quizás el código de llamada.

483
00:56:43,000 --> 00:56:44,000
Lo tenemos a nivel de disco.

484
00:56:45,000 --> 00:56:47,000
A nivel de hacer una gran cantidad de escrituras.

485
00:56:48,000 --> 00:56:49,000
Es simplemente la base de datos.

486
00:56:50,000 --> 00:56:51,000
A mí me interesaría conocer también.

487
00:56:52,000 --> 00:56:54,000
Los que habéis trabajado con Postgres.

488
00:56:55,000 --> 00:56:56,000
Que tenéis instalaciones grandes.

489
00:56:57,000 --> 00:56:58,000
Ver un poco como lo habéis optimizado.

490
00:56:59,000 --> 00:57:00,000
¿Qué tipo de sistema de archivos?

491
00:57:01,000 --> 00:57:02,000
¿Cómo tienes los datos?

492
00:57:03,000 --> 00:57:04,000
¿La data de Postgres?

493
00:57:05,000 --> 00:57:06,000
¿Dónde está?

494
00:57:07,000 --> 00:57:08,000
No, no, el Moodle Data no.

495
00:57:09,000 --> 00:57:11,000
¿Con un RAID hardware y demás?

496
00:57:12,000 --> 00:57:14,000
O sea, contención en disco no hay.

497
00:57:21,000 --> 00:57:22,000
El sistema operativo va ahí también.

498
00:57:23,000 --> 00:57:25,000
El sistema operativo está en los mismos discos.

499
00:57:28,000 --> 00:57:29,000
No, no, me refiero a los mismos discos.

500
00:57:30,000 --> 00:57:31,000
Que la base de datos.

501
00:57:39,000 --> 00:57:40,000
Me refiero porque, por ejemplo.

502
00:57:51,000 --> 00:57:53,000
Repartir la carga de lecturas y escrituras a disco.

503
00:57:54,000 --> 00:57:55,000
O sea, a lo mejor no hay contención de disco.

504
00:57:56,000 --> 00:57:58,000
Pero a lo mejor repartiendo la carga entre unos y otros.

505
00:57:59,000 --> 00:58:03,000
Pues puedes hacer algo.

506
00:58:09,000 --> 00:58:12,000
Entonces a lo mejor hay que optimizar un poquito el acceso a disco.

507
00:58:13,000 --> 00:58:14,000
Aparte de los parámetros de base de datos.

508
00:58:15,000 --> 00:58:18,000
Porque date cuenta que no es solo Postgres el que está escribiendo ahí.

509
00:58:19,000 --> 00:58:20,000
La SOAP está ahí.

510
00:58:21,000 --> 00:58:22,000
El sistema operativo está ahí.

511
00:58:25,000 --> 00:58:26,000
Con hardware.

512
00:58:35,000 --> 00:58:36,000
Postgres.

513
00:58:39,000 --> 00:58:40,000
Y parámetros de Postgres.

514
00:59:02,000 --> 00:59:04,000
O tenerlo por fibra externa, etc.

515
00:59:05,000 --> 00:59:07,000
A veces el rendimiento va de la mano del dinero.

516
00:59:08,000 --> 00:59:09,000
No tanto.

517
00:59:13,000 --> 00:59:14,000
No tanto, hombre.

518
00:59:15,000 --> 00:59:16,000
Hay un poquito menos, pero sí.

519
00:59:17,000 --> 00:59:18,000
Bueno, pues si no tenéis ninguna duda más.

520
00:59:19,000 --> 00:59:20,000
Muchas gracias.

521
00:59:20,000 --> 00:59:21,000
Perdón.

522
00:59:34,000 --> 00:59:35,000
No lo sé.

523
00:59:35,000 --> 00:59:37,000
Cuando se cachean consultas.

524
00:59:38,000 --> 00:59:42,000
Si la MySQL tú le puedes asignar un espacio de memoria para esas consultas.

525
00:59:43,000 --> 00:59:45,000
Y si la consulta es complicada y se repite varias veces.

526
00:59:46,000 --> 00:59:48,000
Pues ya la tienes en memoria y te la da inmediatamente.

527
00:59:49,000 --> 00:59:50,000
El problema a veces no es solo las consultas.

528
00:59:51,000 --> 00:59:52,000
Es las escrituras que se están haciendo en la base de datos.

529
00:59:53,000 --> 00:59:54,000
Que para eso no hay caché.

530
00:59:55,000 --> 00:59:56,000
Para eso es escribir.

531
00:59:57,000 --> 00:59:58,000
Es escribir un buen acceso a disco.

532
00:59:59,000 --> 01:00:01,000
Una red a 4 gigas, por ejemplo, de almacenamiento.

533
01:00:02,000 --> 01:00:03,000
Y, por ejemplo, usar fsync.

534
01:00:04,000 --> 01:00:11,000
En Postgres hay un parámetro de fsync que mantiene en memoria muchas escrituras.

535
01:00:12,000 --> 01:00:19,000
Y cuando está un poco lleno ese buffer o baja la carga, lo se escribe.

536
01:00:31,000 --> 01:00:33,000
Y cuando pasamos a la versión 1.9.5.

537
01:00:34,000 --> 01:00:37,000
Hemos pasado de la versión 1.6 y pico a la versión 1.9.5.

538
01:00:38,000 --> 01:00:39,000
Donde ya se incorporaban los bugs.

539
01:00:40,000 --> 01:00:42,000
Entonces cuando llegamos a esa versión.

540
01:00:43,000 --> 01:00:45,000
La primera sensación fue.

541
01:00:46,000 --> 01:00:47,000
Esto se nos tiene abajo.

542
01:00:48,000 --> 01:00:49,000
En cuanto levantamos el servidor.

543
01:00:50,000 --> 01:00:51,000
Y el problema fue.

544
01:00:52,000 --> 01:00:53,000
Lo resumimos.

545
01:00:54,000 --> 01:00:55,000
Pasando.

546
01:00:56,000 --> 01:00:57,000
Cambiando el engine.

547
01:00:58,000 --> 01:00:59,000
De las tablas.

548
01:00:59,000 --> 01:01:01,000
Que eran las tablas de rol.

549
01:01:02,000 --> 01:01:06,000
Cambiando el engine de MyISAM.

550
01:01:07,000 --> 01:01:08,000
A InnoDB.

551
01:01:09,000 --> 01:01:13,000
Porque el bloqueo de MyISAM es a nivel de tabla completo.

552
01:01:14,000 --> 01:01:17,000
Y el bloqueo de InnoDB a nivel de apertura.

553
01:01:18,000 --> 01:01:21,000
Y eso producía un encolamiento enorme sobre los roles.

554
01:01:22,000 --> 01:01:23,000
Que desapareció completamente.

555
01:01:24,000 --> 01:01:26,000
Simplemente cambiando esas tres tablas.

556
01:01:26,000 --> 01:01:27,000
Y bueno.

557
01:01:28,000 --> 01:01:29,000
Cambio abismal.

558
01:01:30,000 --> 01:01:32,000
Todos esos cambios son optimizaciones.

559
01:01:33,000 --> 01:01:37,000
Pero esa parte es más visible por alguien del aplicativo.

560
01:01:38,000 --> 01:01:40,000
Porque por ejemplo a mí me dices.

561
01:01:41,000 --> 01:01:42,000
Yo te lo puedo ver.

562
01:01:43,000 --> 01:01:44,000
Te puedo ver donde está el S.

563
01:01:45,000 --> 01:01:46,000
En este caso a nivel de la base de datos.

564
01:01:47,000 --> 01:01:49,000
Nosotros le pedíamos a MySQL.

565
01:01:50,000 --> 01:01:52,000
Que nos diera el show connection seed.

566
01:01:53,000 --> 01:01:55,000
Y nos lo ordenara por el tiempo que llevaba esperando cada consulta.

567
01:01:56,000 --> 01:01:57,000
Inmediatamente le diríamos.

568
01:01:58,000 --> 01:02:00,000
En la cabecera de esas peticiones esperando.

569
01:02:01,000 --> 01:02:03,000
Con tres o cuatro tablas más.

570
01:02:04,000 --> 01:02:06,000
Había una consulta que estábamos añaditando.

571
01:02:07,000 --> 01:02:08,000
Y a nivel de base de datos es para lo que actuamos.

572
01:02:09,000 --> 01:02:11,000
Nosotros vamos desde el punto de vista de conocer el aplicativo.

573
01:02:12,000 --> 01:02:14,000
Sino desde database manager.

574
01:02:15,000 --> 01:02:17,000
Ver los bloqueos y ver los accesos.

575
01:02:18,000 --> 01:02:19,000
Vale.

576
01:02:20,000 --> 01:02:21,000
Muchas gracias a todos.

577
01:02:22,000 --> 01:02:23,000
Espero que os haya servido.

578
01:02:23,000 --> 01:02:24,000
Y bueno pues nada.

579
01:02:25,000 --> 01:02:26,000
Que ustedes disfruten la alta disponibilidad.