Saltar navegación

Activa JavaScript para disfrutar de los vídeos de la Mediateca.

Taller: Alta disponibilidad y grandes instalaciones

Ajuste de pantalla

El ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:

Subido el 23 de febrero de 2010 por EducaMadrid

1068 visualizaciones

Taller de la la Moodle Moot Madrid 09 titulado "Alta disponibilidad y grandes instalaciones" realizado por Antonio Jesús Lozano.

Más información Transcripción

Descargar la transcripción

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. 00:00:00
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, 00:00:18
la red, la disposición de los distintos clusters que vamos a ver a lo largo de la presentación, etc. 00:00:29
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, 00:00:38
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. 00:00:52
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. 00:01:06
Luego, la arquitectura distribuida, diferentes puntos de vista, diferentes focos, cómo podemos hacerlo, cómo podemos desplegarlo, qué diferentes opciones tenemos. 00:01:16
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. 00:01:26
Moodle, todos sabéis que es un entorno dinámico, orientado a la armonía del catálogo. 00:01:36
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. 00:01:44
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. 00:02:00
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. 00:02:25
Ejecuta en otros entornos, por ejemplo en Windows, podemos tener la MySQL, un Apache y el PHP compilado y ejecutando sobre un servidor Windows. 00:02:40
Corre en sistemas Mac OS X, preferiría esto antes que Windows prácticamente, pero bueno, también es adaptable. 00:02:49
Y permite, aparte de MySQL, en las últimas versiones, la 1.7.7 hacia adelante, pues admite Microsoft SQL Servers y Oracle. 00:03:02
Postgres 8.0 también se admite, de hecho para entornos de alto rendimiento se aconseja incluso Postgres. 00:03:13
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. 00:03:22
Es como partner de MySQL y tenemos un gran respaldo en esa parte. 00:03:33
Vamos a pasar a la arquitectura monolítica, es decir, todo en un solo servidor. 00:03:41
Que componentes ya hemos visto, que es un sistema operativo, un Linux, un MySQL, un Apache y el PHP incluido dentro del Apache. 00:03:48
Es decir, hay que tener Apache con las extensiones del PHP. 00:03:59
¿Qué tenemos? Pues lo dicho, solo un único servidor. 00:04:04
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. 00:04:08
Tenemos que extenderlo para acá, tirar a otro servidor, etc. 00:04:17
Pero si ese servidor se cae, se congestiona, etc., pues no podemos seguir dando servicio. 00:04:21
El escalado, el único escalado que se puede hacer es el vertical. 00:04:29
Supongo que hay dos tipos de escalado, el horizontal y el vertical. 00:04:33
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. 00:04:37
Pues el escalado es pobre, digo que es pobre porque como tenemos tanto Apache como la base de datos corriendo en el mismo servidor, 00:04:46
si necesitamos más disco para la base de datos, se lo están dando a todos. 00:04:52
Es decir, no puedes repartir y decir, pues solo compro disco para esto, solo compro memoria porque Apache necesita más memoria, etc. 00:04:58
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. 00:05:06
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. 00:05:15
No podemos hacer una actualización en caliente, hay que parar, etc. 00:05:28
Si queremos actualizar sistema operativo también por tema de parches, etc., o problemas de seguridad, hay que parar el servicio. 00:05:32
No solo el servicio, sino hay que parar la máquina. 00:05:39
Si hay que hacer un poquito de actualización en la base de datos, hay que hacerlo parando. 00:05:42
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. 00:05:47
Diversos problemas de seguridad porque tenemos la base de datos en primera línea, lógicamente, solo tenemos un servidor. 00:05:56
No tenemos ni frontend, ni backend, ni VMZ, ni ningún tipo de vered. 00:06:03
Si algún concepto, por favor, no lo entendéis, decídmelo, ¿eh? 00:06:09
Porque tampoco es el nivel de todos. 00:06:13
Bien. 00:06:17
Problemas de seguridad porque tenemos la base de datos en primera línea. 00:06:19
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. 00:06:22
Cuello de botella, quiero decirles, lógicamente, tenemos un solo servidor. 00:06:40
Si tenemos 100 usuarios, empezamos a dar de alta nuevos centros, 100 subcentros, pues se empiezan a dar nuevos alumnos, nuevos usuarios. 00:06:44
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. 00:06:52
Es decir, está claro que con el aumento de usuarios y de servicios provistes por esa model, el cuello de botella está ahí. 00:07:04
Un único servidor sin posibilidad de escalar. 00:07:16
O sea, para escalar ese servidor tendríamos que empezar a desplegar servicios, que es lo que veremos a continuación. 00:07:19
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. 00:07:25
¿No se ve bien por atrás? 00:07:39
Bueno, esa es la infraestructura monolítica, estándar. 00:07:41
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. 00:07:46
Entonces, para evolucionar esta arquitectura monolítica de un único servidor, pero con una seguridad perimetral, a varios servidores con dos niveles, etc. 00:08:06
Bueno, y ahora pasamos a la arquitectura distribuida y escalable. 00:08:22
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. 00:08:26
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. 00:08:44
Entonces, ¿qué beneficios tenemos con esta arquitectura? 00:09:02
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. 00:09:05
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. 00:09:21
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. 00:09:30
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. 00:09:49
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í. 00:10:05
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. 00:10:22
La alta disponibilidad, es decir, un servidor se nos rompe, se nos quema y entonces tenemos el otro servidor dando servicio. 00:10:38
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? 00:10:48
Es que os veo levantándose por allí. 00:11:02
Sí, sí, sí, sí, luego ya os daré el PowerPoint, lo pondré en la red y para que cualquiera lo tenga, ¿vale? 00:11:07
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. 00:11:18
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. 00:11:31
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. 00:11:46
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. 00:11:56
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. 00:12:07
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. 00:12:30
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. 00:12:52
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. 00:13:05
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. 00:13:32
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. 00:13:59
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. 00:14:25
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. 00:14:52
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. 00:15:12
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. 00:15:25
Si alguien quiere que le aclare algo, porque a veces veo caras de no sé si...¿de acuerdo? 00:15:56
¿Qué objetivos tenemos que perseguir o queremos conseguir con un entorno distribuido y en alta disponibilidad? 00:16:03
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. 00:16:15
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. 00:16:39
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. 00:16:48
Es decir, tenemos que implementar sistemas de alta disponibilidad en esos servidores, bien por NFS, bien por GFS, etc. 00:17:08
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. 00:17:17
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. 00:17:32
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. 00:17:44
Es decir, un usuario, una petición o un usuario, dos usuarios, 1-2, sería 1-2. 00:17:54
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. 00:18:01
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. 00:18:18
Y siempre disponible, esto me gusta mucho porque hay mucha gente que pone lo de los 5-9, el 99,999% disponible. 00:18:32
Claro, si no parcheamos, no subimos de sistema ni nada y no tenemos ningún problema, serían 100%. 00:18:41
Como mucho podríamos parar 5 minutos, que creo que el 0,001% me salían 5 minutos o cosa así. 00:18:48
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. 00:18:55
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. 00:19:07
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. 00:19:23
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. 00:19:38
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í. 00:19:54
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. 00:20:11
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. 00:20:27
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. 00:20:47
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. 00:21:07
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. 00:21:23
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. 00:21:47
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. 00:22:04
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. 00:22:22
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. 00:22:41
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. 00:23:09
En fin, todo eso es ya un poquito más complejo y ya veremos que se pueden aplicar tecnologías mixtas. 00:23:27
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. 00:23:36
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. 00:24:07
Dos podrían llevarlo por GFS y otros tres por NFS, o los cinco por GFS o los cinco por NFS. 00:24:26
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. 00:24:34
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. 00:24:58
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. 00:25:28
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. 00:25:39
Entorno ideal, carísimo e ideal. 00:25:51
Sería algo así. Tenemos el acceso prescindido de los otros elementos de base de datos, de seguridad perimetral, etc. 00:25:54
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. 00:26:10
Por detrás estará la base de datos, pero en este punto lo que nos interesa es este reparto. 00:26:31
¿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. 00:26:35
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. 00:26:51
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. 00:27:05
¿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. 00:27:21
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. 00:27:32
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. 00:27:41
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. 00:27:50
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. 00:28:00
Es decir, la política de 1-1-1 se convertiría en 1-1 porque ese otro servidor queda fuera de servicio directamente. 00:28:13
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. 00:28:22
Es decir, todo aquel que tenga una base de datos en primera línea, que la cambie. 00:28:31
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. 00:28:38
Y la base de datos siempre tiene que estar en la parte de atrás. 00:28:48
Generalmente se denomina backend. 00:28:52
Los servidores web siempre han estado en frontend. 00:28:54
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. 00:28:57
Y detrás tendríamos nuestra MySQL, nuestra Postgres o nuestro Oracle RAC. 00:29:10
¿Qué es un clúster activo-pasivo? 00:29:19
Pues lo que os he estado comentando. 00:29:22
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, 00:29:24
esperando, que se denomina pasivo, por si el otro servidor cae. 00:29:36
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. 00:29:42
Luego está Oracle RAC, una pasta que es activo-pasivo. 00:29:57
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. 00:30:03
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. 00:30:16
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. 00:30:30
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. 00:30:41
Oracle RAC es Real Application Cluster, como veis nosotros vamos por lo libre. 00:30:53
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. 00:31:06
Le asigne un segundo o una modificación mínima a la fila que se está modificando. 00:31:22
Y por último Postgres. 00:31:28
Postgres, ahora últimamente tiene más nombre MySQL porque MySQL tiene mucho más marketing. 00:31:30
SAN la ha comprado antes de que SAN fuera comprado por Oracle y le dio mucho bombo. 00:31:40
Hay un entorno profesional de MySQL disponible a través de SAN, etc. 00:31:45
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. 00:31:53
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. 00:32:03
Yo no sé si alguien ha tocado Postgres o tiene Postgres. 00:32:11
Postgres. Eso se hace solo en Postgres. 00:32:24
La dificultad de saber configurar eso. La configura sin más funciona, pero se ha configurado con los parámetros de funcionamiento muy bajos. 00:32:29
Nosotros en el portal Educamadrid tenemos Postgres desplegada. 00:32:42
Utilizamos Postgres. 00:32:50
Lo que pasa es que también tenemos MySQL. 00:32:52
El aula de formación que os presentaré ahora después está desplegada sobre MySQL. 00:32:56
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. 00:33:00
MySQL es algo más sencillo. 00:33:23
Por ejemplo, el caché de consultas de MySQL tú lo puedes configurar. 00:33:26
Postgres ya lo hace solo. 00:33:30
Ya se ocupa de ese tema, que es algo de lo que más he batallado, el tema del cacheo de consultas. 00:33:32
Postgres da mejor rendimiento que una MySQL, pero para un entorno mucho más heterogéneo. 00:33:39
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. 00:33:47
Aunque hay un proveedor que da servicios profesionales de Postgres, pero no recuerdo ahora mismo. 00:33:59
Esta sería la parte de backend. 00:34:07
Luego ya os engancharé las dos opciones, os engancharé las dos transparencias y ya veréis la parte completa y compleja. 00:34:09
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. 00:34:19
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. 00:34:28
Lo comento luego un poquito. 00:34:38
Y esta es nuestra super arquitectura guay del Paraguay. 00:34:42
Tenemos todos los alumnos accediendo. 00:34:47
Se me ha olvidado el router, lo siento, el router está ahí. 00:34:51
En medio tenemos la seguridad perimetral, dos cortafuegos en alta disponibilidad, activo o pasivo. 00:34:56
Dos balanceadores de carga, no lo pone pero estos son ciscos. 00:35:02
Dos ciscos en activo o pasivo que reparten la carga según la política que le hemos establecido. 00:35:07
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. 00:35:11
Servidor NFS lo he dejado en modo, o sea nosotros no estamos usando NFS, pero si te refieres a una NAS o algo así. 00:35:26
No, me refiero a que si ahí habla que hay... 00:35:37
Ah, sí, no. 00:35:40
Si saca NFS... 00:35:42
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. 00:35:44
O estos cuatro por GFS. 00:35:54
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. 00:35:56
¿Del NFS? 00:36:16
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. 00:36:18
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. 00:36:30
Pues en caso de utilizar NFS yo, si dispone de los recursos, los medios, tarjetas, etcétera, pondría una red solo para NFS. 00:36:38
Ni SSH ni tráfico que haya por ahí, nada, NFS. 00:36:46
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. 00:36:49
Lo que pasa es que hay muchos sitios en los que el servidor tiene a lo mejor una o dos tarjetas de red. 00:37:01
Comprar una quad ya te supone a lo mejor mil euros solo lo que es la tarjeta, etcétera, etcétera. 00:37:06
¿Alguna cuestión más? 00:37:13
Bueno, sigo adelante. 00:37:16
Os voy a comentar otras opciones que podemos tener en consideración. 00:37:19
Dime. 00:37:22
Una SAN puede ser tan complicada como tú quieras. 00:37:38
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. 00:37:41
¿No estás hablando de una SAN? 00:37:52
No, no, no. 00:37:54
Un cajoncito no, no, no. 00:37:56
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. 00:37:59
Luego le enganchabas otro cajón igual, maestro también, podías interconectarlo. 00:38:15
Si te iba por completo un cajón, pues siempre tenías el mirror en el otro. 00:38:21
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. 00:38:25
O sea, es un término, lo he puesto muy genérico, pero entendiendo las distintas opciones que se pueden añadir. 00:38:38
Bueno, otras opciones o otras consideraciones que podríamos tener en un entorno, por ejemplo, la virtualización. 00:38:47
Podemos virtualizar servidores, por ejemplo, si tenemos un servidor muy grande, pues a lo mejor distribuirlo en dos servidores. 00:38:54
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. 00:39:02
Y de esta forma podemos aislar o compartimentar el uso de recursos que se hacen. 00:39:16
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. 00:39:23
Luego también podríamos distribuir los cursos por plataformas. 00:39:32
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. 00:39:37
Pues, aunque pase de la técnica a la superior, no hay relación entre una y otra. 00:39:48
Podrías tener unos servidores dedicados a un entorno y otros servidores dedicados al otro. 00:39:54
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. 00:40:00
Son distintas, no tienen relación entre ellos y cada una va por separado y son entornos similares. 00:40:07
Mezcla de conceptos, que es lo que llevo todo el rato comentando. 00:40:12
GFS, no GSF. 00:40:16
GFS más NFS. 00:40:21
Oracle RAC. 00:40:23
ScalaDB, que estuve viendo hace poco una presentación y era algo similar a Oracle RAC, pero independientemente de la base de datos. 00:40:25
Podría ser MySQL, Postgres. 00:40:33
Y, bueno, la nube, que todo el mundo habla del cloud computing, pues tener los servidores alojados, etc. 00:40:34
No voy a entrar en eso porque, en fin. 00:40:42
Y, por último, os voy a presentar el caso práctico de EducaMadrid. 00:40:45
Esta es una infraestructura que existe, que la mantenemos, la hemos desplegado y hay usuarios accediendo a ella. 00:40:50
¿En qué se basa? 00:40:59
Pues tenemos el sistema operativo base, es una reja de Linux Enterprise Server 5.3. 00:41:00
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. 00:41:07
La base de datos en backend es una MySQL, como os comentaba antes. 00:41:17
La arquitectura es AMD Opteron Quad Core. 00:41:22
Cada servidor tiene 4 Quad Cores, es decir, 16 Cores. 00:41:26
24 GB de memoria RAM. 00:41:31
Tenemos los 4 servidores, son HP ProLiant DL585 G5. 00:41:34
Es este pequeñito. 00:41:40
¿Veis? Todos esos son discos que se le pueden ir ampliando localmente. 00:41:42
Pero no nos interesa el almacenamiento del servidor. 00:41:45
Y un almacenamiento compartido de SAN Microsystem 2540. 00:41:49
Ese sí nos interesa a los discos, que es el que da servicio. 00:41:55
Aquí sí tenemos un único punto de fallo, porque sólo tenemos una SAN. 00:41:59
Entre comillas. 00:42:02
Esa SAN tiene doble fuente de alimentación y los discos están en RAID. 00:42:04
Se me tienen que ir las dos fuentes de alimentación simultáneamente. 00:42:08
Esperemos que no. 00:42:12
Y dos o tres discos que formen un RAID 5 o un RAID 1. 00:42:14
Y el disco de espera de resincronización que no esté disponible para asumir tal carga. 00:42:19
Pero en principio con un almacenamiento de este estilo podemos dormir más o menos tranquilos los que administramos la plataforma. 00:42:25
Y por último, la URL, la de formación EDUKAMADRIARG de EDUKAMADRI. 00:42:34
Y estos son algunos datos de los dos que tenemos. 00:42:39
El primero es formación del profesorado, con 4.800 usuarios dados de alta ahora mismo. 00:42:45
Se prevé que llegue a unos 6.200 a lo largo del presente curso. 00:42:53
Ahora mismo cursos activos sólo hay 23, nueve se van a incorporar. 00:42:57
Están ya dados de alta, digamos, o que se conoce de ellos. 00:43:03
Luego se podrán ir dando de alta más. 00:43:08
Y la otra infraestructura es la de centros educativos, en la que tenemos 15.000 usuarios. 00:43:10
Se prevén unos 3.000 más, 18.000. 00:43:15
Y tiene 600 cursos activos. 00:43:18
Así mismo tenemos 200 centros educativos con espacio virtual en ese centro de formación. 00:43:20
Pues... no lo sé. 00:43:31
Sí. 00:43:37
Pues... la verdad es que no lo sé. 00:43:39
Si no lo sé es porque no es un problema. 00:43:43
Si no lo sé digo que no es problema. 00:43:50
No hombre, nosotros sí tenemos balanceo de carga por hardware, etc. 00:43:53
Y el número de usuarios concurrentes pues a lo mejor puede ser 500, pero claro, en los dos servidores. 00:43:58
250 por servidor, más otros 250 en los otros dos servidores. 00:44:03
Tenemos dos infraestructuras. 00:44:08
Aparte de que el profesorado pues no es algo que vayan todos concurrentemente. 00:44:10
Es una distribución de carga bastante lineal. 00:44:15
Esta es la página principal de formación. 00:44:19
Bueno, ya conocéis todos una Moodle. 00:44:22
Sois más expertos que yo en esa parte. 00:44:24
Y bueno, pues esto es... 00:44:26
Esta es la infraestructura de Educamadrid. 00:44:29
De la parte de formación del profesorado de Educamadrid. 00:44:32
Como ya os he comentado es un Rehash Cluster con GFS, etc. 00:44:36
Si veis el almacenamiento no hay dos. 00:44:40
Hay uno. 00:44:43
Es decir, ese almacenamiento es compartido con los datos de Moodle y con los de base de datos. 00:44:44
No nos importa porque ese almacenamiento es escalable verticalmente. 00:44:51
Horizontalmente también, pero horizontalmente ya está copado. 00:44:55
Es decir, ya están todos los discos puestos y sería vertical... 00:45:00
Perdón, es escalable horizontalmente. 00:45:03
Es decir, podemos añadir más cajones con más discos, etc. 00:45:05
Y está compartido. 00:45:09
Hay una red de almacenamiento por fibra para que tanto los servidores activo-activo del web 00:45:11
como el activo-pasivo de MySQL puedan acceder a su región de datos asignada. 00:45:18
Es decir, ese cajón, ese almacenamiento externo tiene un panel de control 00:45:23
y yo puedo asignar recursos a uno o a otro. 00:45:28
Bueno, pues esta es la infraestructura que tenemos allí en Educamadrid. 00:45:34
Preveemos meter dos servidores más de... 00:45:40
Espacio en disco cuando tenemos para la Moodle. 00:45:56
Para el Moodle Data, 200 gigas o algo así, asignados. 00:46:00
No me acuerdo. 00:46:06
Date cuenta que es un cajón con 12 discos de 360 gigas y no me importa. 00:46:10
O sea, no es un problema a corto plazo. 00:46:18
Le dimos bastante espacio. Yo creo que son entre 100 y 200 gigas. 00:46:21
No, 300 gigas más bien. 00:46:24
Para la Moodle Data. 00:46:27
Más o menos debe ser eso. 00:46:31
Bueno, tenemos previsión de añadir otros dos servidores. 00:46:34
Todavía no tenemos claro si va a ser por GFS o por NFS. 00:46:38
Haremos pruebas de una parte o de otra. 00:46:44
Sí, sí, dime, dime. 00:46:50
Acelerador de la hoja de HP. 00:47:08
Sería un servidor, ni menos, desde el HTML. 00:47:10
¿LiveHTTP y demás? 00:47:15
¿LiveHTTP? 00:47:18
LiveHTTP y acelerador. 00:47:20
No. 00:47:23
Tampoco habéis probado... 00:47:25
Es un cuestionario más de rendimiento, de realidad. 00:47:29
Tampoco habéis probado la versión... 00:47:34
La versión final de HPD. 00:47:37
Nos hemos centrado en parte más estándar. 00:47:42
Sobre todo para prestar el servicio, porque esto está en producción. 00:47:46
En este verano fue montar la infraestructura y dar servicio. 00:47:51
Miento, este verano no, a principios de año fue montar la infraestructura. 00:47:56
Y cuando empiezas con temas... 00:48:00
No quiero decir de laboratorio. 00:48:03
Pero que ya te sales un poco de la norma. 00:48:08
Prefieres dar el servicio con algo que ya está probado y lo conoces. 00:48:13
¿Y última cuestión? 00:48:18
No lo sé. 00:48:22
Ya os digo que yo voy de la parte... Creo que es la 1.8. 00:48:24
Es muy significativo. 00:48:28
La 1... Perdona, la 1.9.5. 00:48:33
La 1.9.5. 00:48:37
Ya digo que es que yo no entro a administrar la Moodle. 00:48:39
Sencillamente despliego el entorno y me encargo de que funcione. 00:48:43
La última versión... Creo que la última actualización la hizo un compañero. 00:48:48
Esa parte ya es más de aplicaciones, del equipo de aplicaciones. 00:48:52
Más que de sistemas. 00:48:56
Pero me comenta que la 1.9.5 es la que tenemos desplegada. 00:48:58
¿Habéis tenido algún problema en su acuerdo? 00:49:02
La conclusión de saber si se concentra ese... 00:49:05
No, porque usamos GRBD. 00:49:08
Para el acceso a la Moodle. 00:49:11
Al Moodle Data. 00:49:13
Es que si no lo configuras correctamente... 00:49:15
De hecho, no sería necesario tener clúster. 00:49:19
Ya que los servidores van a acceder de forma simultánea. 00:49:23
Y da igual que se me caiga este, tiene que seguir. 00:49:26
Sin embargo, hay que establecer un clúster completo en Red Hat. 00:49:28
Para que ese acceso sea... 00:49:30
Para que certifique eso. 00:49:33
Para que ese acceso no tenga corrupción de datos. 00:49:37
O sea, tiene una parte un poco compleja en esa parte. 00:49:40
Para el tema de acceso a la Moodle Data. 00:49:44
Cuello de botella en la base de datos. 00:49:53
Añades otro servidor. 00:50:01
Añades otro virtual. 00:50:03
Pero van a cargar todos en una base de datos. 00:50:05
Ahí es donde está el problema. 00:50:08
Nosotros, es lo que decíamos. 00:50:18
Tanto para Postgres como MySQL. 00:50:20
Es optimizar, hacerle tuning. 00:50:23
Los parámetros. 00:50:25
Porque es un servidor y es una interfaz. 00:50:27
Puedes tener más interfaces. 00:50:28
Dar más capacidad. 00:50:30
Pero al final, al backend, es una base de datos. 00:50:32
Ya si tienes un problema serio. 00:50:34
En el acceso a base de datos. 00:50:36
Tendrás que irte a un entorno estilo Oracle RAC. 00:50:38
O hay una solución. 00:50:41
¿De Postgres? 00:50:48
No, yo lo único que encontré fue la parte esta. 00:50:51
De SolidDB. 00:50:53
Que es como una especie de capa intermedia. 00:50:55
No, perdón. 00:50:57
Capa intermedia entre el gestor de base de datos. 00:50:59
O los N gestores de base de datos. 00:51:01
Y el acceso a la tabla. 00:51:03
Entonces, él es el que se encarga de distribuir. 00:51:05
Hace lo que Oracle RAC. 00:51:07
Solo que independiente del gestor de base de datos. 00:51:09
Pero ya te digo. 00:51:11
Fue una presentación así por encima. 00:51:13
Que tampoco me dio tiempo a preguntarle cómo es. 00:51:15
Bueno, os dejo unos cuantos enlaces. 00:51:21
Para que luego los veáis. 00:51:23
Sobre todo el del PEN. 00:51:24
Y el de ScalaDB. 00:51:26
Que es el que más os interesa. 00:51:28
Y bueno, pues ya lo he terminado. 00:51:32
Si queréis preguntarme algo. 00:51:34
Dime. 00:51:36
Habla un poco más alto. 00:51:50
Ponte de pie, ponte de pie. 00:51:54
Cinco. 00:52:09
Claro. 00:52:25
En Santa Julia no lo tendréis, ¿verdad? 00:52:41
En Santa Julia no lo tendréis, ¿verdad? 00:52:43
Sí. 00:52:51
Porque eso no es alta disponibilidad. 00:52:52
O sea. 00:52:54
Eso es business recovery. 00:52:56
Eso es establecer un sistema de recuperación de negocio. 00:52:58
Es que sí, sí, sí. 00:53:11
El único problema que tendrías es tirar fibra. 00:53:13
De cuatro gigas mínimo entre un centro y el otro. 00:53:17
Ya está. 00:53:23
Es tan sencillo como eso. 00:53:29
Y lo tenéis por fibra. 00:53:32
O incluso fibra óptica. 00:53:35
Es que es alta disponibilidad. 00:53:52
¿Qué base de datos tenéis? 00:53:54
¿Tenéis eso y no tenéis Oracle y RAC? 00:53:56
Es que, por ejemplo, lo normal es que eso es caro. 00:54:01
Tú lo sabrás mejor. 00:54:06
Sin embargo, hay otra solución a corto plazo. 00:54:08
Que es tener un site de respaldo. 00:54:10
Es decir, tú tienes allí. 00:54:12
En vez de tener cuatro servidores arriba y dos abajo. 00:54:14
Pues tienes dos servidores solo. 00:54:17
Y por la noche o a cada hora. 00:54:19
Replicas esos datos en ese servidor. 00:54:22
En ese centro de respaldo. 00:54:24
Si se te quema ese CPD. 00:54:26
Automáticamente hablas con tu operador. 00:54:28
Y redireccionas el servicio al otro. 00:54:30
Y pierdes a lo mejor una hora de datos. 00:54:32
O si lo tienes un hot site. 00:54:34
Pues entonces lo tienes completamente replicado online. 00:54:38
Pero eso es pasta. 00:54:41
Y a Santa Julia no lo llevéis. 00:54:43
¿No sabéis dónde está Santa Julia? 00:54:45
Eso está en Mérida. 00:54:47
La Consejería de Educación de Mérida. 00:54:50
A Santa Julia no. 00:54:52
Bueno, ¿alguna cuestión más? 00:54:55
Hablamos también de la opción de Oracle. 00:55:16
Lo que pasa es que no funcionaba bien con Google. 00:55:18
Al final, las operaciones de Google con Oracle no nos daban problemas. 00:55:21
Entonces la opción a la que tú hemos dado que ese problema parecía un poco justito. 00:55:25
Para una cantidad de usuarios. 00:55:29
Ha sido Postgres. 00:55:31
Lo que pasa es que en Postgres. 00:55:33
Si no recuerdo mal. 00:55:35
No permite balanceo de carga entre varios servidores. 00:55:37
Entonces tenemos una única máquina con Postgres. 00:55:40
Que está funcionando bien. 00:55:43
Hemos encontrado el mayor pepino que hemos visto. 00:55:44
Pero bueno, estamos con 20.000 usuarios. 00:55:47
Y la carga que tienen es importante. 00:55:50
Pero ¿tenéis dos niveles también y demás? 00:55:52
Sí, tenemos todos los niveles. 00:55:55
Pero la base de datos es una única máquina. 00:55:57
Me refiero a que no hay otros problemas de congestión de red. 00:56:00
Sí, los servidores web han sobrado. 00:56:03
Tenemos balanceo de carga. 00:56:05
Tenemos acciones. 00:56:07
Y el mayor problema el encontramos en la base de datos. 00:56:09
Cuando tenemos 300 usuarios. 00:56:12
Estamos escribiendo en la base de datos. 00:56:15
La base de datos. 00:56:17
Sí. 00:56:19
Sí. 00:56:21
Estoy comentando que en WeDevice.org. 00:56:23
Nos encontramos sobre todo. 00:56:25
En la base de datos de Postgres. 00:56:27
Que tenemos. 00:56:29
Y entonces estamos buscando. 00:56:31
La manera de optimizar al máximo. 00:56:33
Esa base de datos. 00:56:35
Por cierto es que la máquina en sí. 00:56:37
Depende del FPU. 00:56:39
Pero creo que quizás el código de llamada. 00:56:40
Lo tenemos a nivel de disco. 00:56:43
A nivel de hacer una gran cantidad de escrituras. 00:56:45
Es simplemente la base de datos. 00:56:48
A mí me interesaría conocer también. 00:56:50
Los que habéis trabajado con Postgres. 00:56:52
Que tenéis instalaciones grandes. 00:56:55
Ver un poco como lo habéis optimizado. 00:56:57
¿Qué tipo de sistema de archivos? 00:56:59
¿Cómo tienes los datos? 00:57:01
¿La data de Postgres? 00:57:03
¿Dónde está? 00:57:05
No, no, el Moodle Data no. 00:57:07
¿Con un RAID hardware y demás? 00:57:09
O sea, contención en disco no hay. 00:57:12
El sistema operativo va ahí también. 00:57:21
El sistema operativo está en los mismos discos. 00:57:23
No, no, me refiero a los mismos discos. 00:57:28
Que la base de datos. 00:57:30
Me refiero porque, por ejemplo. 00:57:39
Repartir la carga de lecturas y escrituras a disco. 00:57:51
O sea, a lo mejor no hay contención de disco. 00:57:54
Pero a lo mejor repartiendo la carga entre unos y otros. 00:57:56
Pues puedes hacer algo. 00:57:59
Entonces a lo mejor hay que optimizar un poquito el acceso a disco. 00:58:09
Aparte de los parámetros de base de datos. 00:58:13
Porque date cuenta que no es solo Postgres el que está escribiendo ahí. 00:58:15
La SOAP está ahí. 00:58:19
El sistema operativo está ahí. 00:58:21
Con hardware. 00:58:25
Postgres. 00:58:35
Y parámetros de Postgres. 00:58:39
O tenerlo por fibra externa, etc. 00:59:02
A veces el rendimiento va de la mano del dinero. 00:59:05
No tanto. 00:59:08
No tanto, hombre. 00:59:13
Hay un poquito menos, pero sí. 00:59:15
Bueno, pues si no tenéis ninguna duda más. 00:59:17
Muchas gracias. 00:59:19
Perdón. 00:59:20
No lo sé. 00:59:34
Cuando se cachean consultas. 00:59:35
Si la MySQL tú le puedes asignar un espacio de memoria para esas consultas. 00:59:38
Y si la consulta es complicada y se repite varias veces. 00:59:43
Pues ya la tienes en memoria y te la da inmediatamente. 00:59:46
El problema a veces no es solo las consultas. 00:59:49
Es las escrituras que se están haciendo en la base de datos. 00:59:51
Que para eso no hay caché. 00:59:53
Para eso es escribir. 00:59:55
Es escribir un buen acceso a disco. 00:59:57
Una red a 4 gigas, por ejemplo, de almacenamiento. 00:59:59
Y, por ejemplo, usar fsync. 01:00:02
En Postgres hay un parámetro de fsync que mantiene en memoria muchas escrituras. 01:00:04
Y cuando está un poco lleno ese buffer o baja la carga, lo se escribe. 01:00:12
Y cuando pasamos a la versión 1.9.5. 01:00:31
Hemos pasado de la versión 1.6 y pico a la versión 1.9.5. 01:00:34
Donde ya se incorporaban los bugs. 01:00:38
Entonces cuando llegamos a esa versión. 01:00:40
La primera sensación fue. 01:00:43
Esto se nos tiene abajo. 01:00:46
En cuanto levantamos el servidor. 01:00:48
Y el problema fue. 01:00:50
Lo resumimos. 01:00:52
Pasando. 01:00:54
Cambiando el engine. 01:00:56
De las tablas. 01:00:58
Que eran las tablas de rol. 01:00:59
Cambiando el engine de MyISAM. 01:01:02
A InnoDB. 01:01:07
Porque el bloqueo de MyISAM es a nivel de tabla completo. 01:01:09
Y el bloqueo de InnoDB a nivel de apertura. 01:01:14
Y eso producía un encolamiento enorme sobre los roles. 01:01:18
Que desapareció completamente. 01:01:22
Simplemente cambiando esas tres tablas. 01:01:24
Y bueno. 01:01:26
Cambio abismal. 01:01:28
Todos esos cambios son optimizaciones. 01:01:30
Pero esa parte es más visible por alguien del aplicativo. 01:01:33
Porque por ejemplo a mí me dices. 01:01:38
Yo te lo puedo ver. 01:01:41
Te puedo ver donde está el S. 01:01:43
En este caso a nivel de la base de datos. 01:01:45
Nosotros le pedíamos a MySQL. 01:01:47
Que nos diera el show connection seed. 01:01:50
Y nos lo ordenara por el tiempo que llevaba esperando cada consulta. 01:01:53
Inmediatamente le diríamos. 01:01:56
En la cabecera de esas peticiones esperando. 01:01:58
Con tres o cuatro tablas más. 01:02:01
Había una consulta que estábamos añaditando. 01:02:04
Y a nivel de base de datos es para lo que actuamos. 01:02:07
Nosotros vamos desde el punto de vista de conocer el aplicativo. 01:02:09
Sino desde database manager. 01:02:12
Ver los bloqueos y ver los accesos. 01:02:15
Vale. 01:02:18
Muchas gracias a todos. 01:02:20
Espero que os haya servido. 01:02:22
Y bueno pues nada. 01:02:23
Que ustedes disfruten la alta disponibilidad. 01:02:25
Valoración:
  • 1
  • 2
  • 3
  • 4
  • 5
Eres el primero. Inicia sesión para valorar el vídeo.
Idioma/s:
es
Autor/es:
Antonio Jesús Lozano
Subido por:
EducaMadrid
Licencia:
Reconocimiento - No comercial - Sin obra derivada
Visualizaciones:
1068
Fecha:
23 de febrero de 2010 - 12:09
Visibilidad:
Público
Enlace Relacionado:
Comité Organizador Moodle Moot 09
Descripción ampliada:
Taller práctico sobre Moodle en grandes servidores e instalaciones que requieren de un gran número de usuarios concurrentes y de mucha fiabilidad.
Duración:
1h′ 02′ 42″
Relación de aspecto:
1.26:1
Resolución:
448x356 píxeles
Tamaño:
462.06 MBytes

Del mismo autor…

Ver más del mismo autor

EducaMadrid, Plataforma Educativa de la Comunidad de Madrid

Plataforma Educativa EducaMadrid