1.000.000 de transacciones por segundo, usando JBoss (y, por supuesto, EJB, que sentido tendría sino usar JBoss?) Repetimos, 1.000.000. Sí, seguro que hay sistemas que soportan más. Pero no deja de ser un buen motivo para querer a JBoss, sobretodo por las herramientas que se integran tan bien con él (jBPM, Cache, etc).

No quiero pensar lo que conseguirían usando scala.

Powered by ScribeFire.

Seguro que a algunos les resultaran útiles las ideas expuestas en los múltiples enlaces del artículo (Filoxeo?).

La tecnología de clusters ha evolucionado en apoyo de actividades que van desde aplicaciones de supercómputo y software de misiones críticas, servidores Web y comercio electrónico, hasta bases de datos de alto rendimiento, entre otros usos.

El cómputo con clusters surge como resultado de la convergencia de varias tendencias actuales que incluyen la disponibilidad de microprocesadores económicos de alto rendimiento y redes de alta velocidad, el desarrollo de herramientas de software para cómputo distribuido de alto rendimiento, así como la creciente necesidad de potencia computacional para aplicaciones que la requieran.

Simplemente, cluster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador, más potente que los comunes de escritorio.

Clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la que es provista por un solo computador tipicamente siendo mas económico que computadores individuales de rapidez y disponibilidad comparables.

De un cluster se espera que presente combinaciones de los siguientes servicios:

1. Alto rendimiento (High Performance)
2. Alta disponibilidad (High Availability)
3. Equilibrio de carga (Load Balancing)
4. Escalabilidad (Scalability)

La construcción de los ordenadores del cluster es más fácil y económica debido a su flexibilidad: pueden tener todos la misma configuración de hardware y sistema operativo (cluster homogéneo), diferente rendimiento pero con arquitecturas y sistemas operativos similares (cluster semi-homogéneo), o tener diferente hardware y sistema operativo (cluster heterogéneo)., lo que hace más fácil y económica su construcción.

Para que un cluster funcione como tal, no basta solo con conectar entre sí los ordenadores, sino que es necesario proveer un sistema de manejo del cluster, el cual se encargue de interactuar con el usuario y los procesos que corren en él para optimizar el funcionamiento.

@titojack, o te viene al Sweetter o nos volvemos al sistema de comentarios en el blog, o incluso el gtalk.

Vaticino que el proximo petardazo gordo, ya sea por probelmas propios, o inducidos externamente, va a ser el Tuenti, que tambien tiene sus momentos allbran... si esto ocurre y es tan insidioso como el twitter... habra que chapar y buscarse otro sitio... ¿Facebook, Orkut, ninguno?

Edit: hablando del tuenti, Pedro Laguna ha publicado un interesante artículo sobre la seguridad en el mismo. Pasaos a echarle un vistazo.

Una vez estuve leyendo un blog de un americano que aseguraba que haciendo una configuración específica a MySQL se podría aumentar su eficencia en la concurrencia. Como no teníamos otra cosa que hacer, lo probamos. Claro, esto de probar las cosas está bien hasta que te pegas el castañazo. Más bien el trompazo. Porque cuando activamos esta nueva configuración, los esclavos de la base de datos empezaron a caer uno detrás de otro como moscas. Menos mal que sólo cambiamos esta configuración en unos cuantos por lo que el portal no sufrió consecuencias y seguía funcionando.

Pero aprendí desde ese momento que cuando alguien en internet habla de escalabilidad o de posibles ideas para solventar este problema tienes que tener claro o seguro que en realidad ha tenido experiencia en ese campo.

Otra anécdota que puedo contar es que en los inicios de tuenti, estábamos otro compañero y yo por la noche haciendo cambios varios sobre la estructura de datos. Hasta que nos topamos con la duda de si aplicar estos cambios a las tablas en el portal. Leyendo la documentación de MySQL 5.0, aseguraba que en un entorno maestro-esclavo hacer cambios en las tablas con ALTER no debiera afectar en absoluto al rendimiento del sistema puesto que el ALTER se realiza sobre una copia temporal de la tabla, por lo que las lecturas podrían seguir sucediendo en la misma tabla durante la operación. Por lo que tanto Kenny como yo decidimos que podríamos hacerlo sin problemas.

Ya podréis saber el resultado de esta acción por cómo estoy empezando esta frase. Si, casi desastre. El maestro comenzó a retener las escrituras sobre la tabla y de esta manera reteniendo las conexiones desde el PHP. Esto hizo que se sobrepasara el límite de conexiones que el servidor tenía previsto -y eso que lo aumentamos en mucho sabiendo que podría pasar... Esto formó una espiral de acontecimientos que nos obligó a cancelar la operación para que el portal no se cayera.

A lo largo de este tiempo, esta son las cosas que creo claves para tener una buena escalabilidad -que es imposible sin experiencia y conocimiento del sector donde te metes , por supuesto:

• Las cosas tienen que ser muy simples: todo lo complicado no es escalable, y menos aquellas cosas que precisamente hacemos complicadas para que escalen. Puesto que la complejidad es el peor enemigo de la escalabilidad.
• Investigación: A la hora de econtrarte con un problema de escalabilidad, probablemente, si no eres uno de los portales más grandes del mundo o con una cierta peculiaridad que no tiene nadie, alguien ha pasado ya por lo mismo que tú. Consulta los blogs, listas de desarrolladores y demás frecuentadas por las personas de otros sitios iguales al tuyo (pero más grandes).
• Priorización: Es muy importante determinar qué cosas son las más importantes para centrarte en la escalabilidad de ellas. Perder demasiado el tiempo en algo que no es importante en tu portal podría mermar otra prioridad que sin embargo necesita ese tiempo.
• Iteración constante en los cuellos de botella: Esta tiene su base en la Administración de Sistemas. Pero en realidad se puede aplicar a todo tipo de disciplina que necesita una escalabilidad. En producto nos econtramos contínuamente con cuellos de botella en el código que no pueden ser resueltos con más servidores...
• Éxito como equipo: Tener en cuenta tus responsabilidades, asumirlas y ejecutarlas es vital para que otros miembros de tu equipo puedan hacer las suyas confiando que tu parte estará hecha. Esto hace que el equipo pueda afrontar los problemas de manera más efectiva.
• Conocer tu plataforma: Tener una buena plataforma y conocerla son claves para poder escalarla. Si estás usando un framework que no conoces por dentro (ruby on rails) puedes encontrarte en una situación donde las propias librerías pueden no ser escalables.

Algunos de estos puntos vienen de leer este comentario en los blogs relacionados con Youtube.

Replicación Master-Slave In a Nutshell:

La idea de montar un master-slave es tener la base de datos maestra para realizar las modificaciones a la base de datos, y usar la/las bases de datos esclavas para realizar las lecturas. De esta forma, las operaciones de lectura, que son las más habituales, se pueden balancear entre diferentes instancias de una base de datos.

Por otro lado, cada vez que se hace una modificación en la maestra, esta modificación se replica en las esclavas, de forma que los datos siempre están sincronizados.

Esta imagen del manual online de MySQL es muy explicativa

Claramente este esquema nos puede ayudar mucho de cara a la escalabilidad de una aplicación, ya que la base de datos es uno de los cuellos de botella típicos.

Lo que necesitamos en este caso, es asegurarnos de que todas las operaciones de escritura van contra la conexión de la maestra, mientras que las lecturas van por una conexión esclava.

Una de las ventajas de usar un framework- en este caso Rails, pero podría haber sido cualquier otro- es que tu aplicación tiene una arquitectura bien definida. O al menos debería. Esto significa que al usar Rails tenemos bajo control las operaciones que se hacen contra la base de datos, con lo que identificar las de lectura y las de escritura debería ser simple. Si seguimos las reglas del framework, las operaciones contra la base de datos pasarán siempre por el modelo y por los métodos que AR nos proporciona.

Al final, el número de métodos que realmente acaban accediendo a la base de datos son más bien pocos, con lo que podríamos jugar un poco con el framework, establecer dos conexiones con la base de datos (una con la maestra, y otra con la esclava) y decidir qué conexión va a usar cada método. Así todos los métodos "find" y similares irían por la esclava, y los "delete", "insert", etc.. irían por la maestra.

Esto mismo es lo que el plugin masochism hace automáticamente por nosotros. El plugin viene de la mano del hiperproductivo Rick Olson.

Uno de estos días tendré que contar en más detalle cómo va, pero el resumen ejecutivo es que lo instalas, le añades una conexión master_connection en tu fichero database.yml, llamas a un método en uno de tus initializers... y te olvidas. A partir de ahí todo funciona de forma transparente (siempre que hayas configurado tu master/slave de MySQL previamente, claro).

De momento le he encontrado una única pega. Entre los métodos que se envían a la base de datos maestra no está el método "execute", que es el típico método que sólo utilizas cuando quieres modificar algo en la base de datos. Sin ir más lejos, el (imprescindible) plugin Foreign Key Migrations usa ese método para crear las FK, por lo que si no nos aseguramos de que se usa la base de datos maestra, podemos tener problemas.

Le he mandado un parche (en realidad es añadir una palabra y una coma) a Rick , a ver si le parece apropiado incuírlo como parte del plugin.

update: y el patch ya ha sido incluído :)

Y a escalar!!

searchwords: scalability, mysql replication, master-slave, javier ramírez

Pero todas las líneas de negocio existentes se van a tomar por el ·@%%&&.  Porque llega el articulazo del siglo. Donde esté un ordenador barato, que se quite uno potente.

Reflexionemos un poco...

Microsoft hace sistemas operativos y sus programas cada vez más pesados, que necesitan cada vez más recursos del sistema. Así todos son felices. Microsoft vende sus sistemas operativos, sus Office, etc, y, como los computadores en un momento determinado no los corren bien, la gente migra más rápidamente a procesadores más rápidos para correr estos programas. Así viene pasando desde Windows 95.

El problema, y el fracaso de Vista, es que ahora las cosas son un poco diferentes...

Por un lado, Vista exageró demasiado en cuanto a los recursos que necesita, no pudiendo correr sino solo en los procesadores más avanzados, impidiendo de esta manera las actualizaciones de XP a Vista. Era necesario comprar una máquina nueva y costosa. Por otro lado, XP sigue siendo suficientemente bueno y no justifica comprarse un nuevo computador para poder disfrutar de Vista.

Sí, sí, sí, sí.... Spectra es malísima. Muy mala. Una cabrona vamos. Cada día hace sus programas más gordos (Creo que les dan harina y maizena), que necesitan más recursos y todos felices. Como los equipos antiguos no pueden, pues a comprar hardware nuevo.

Vista es un fracaso. Y del bueno te digo yo.

O sea, a ver si lo he entendido. Que donde esté un Windows95 o una mini-distribución de Linux, que se quiten las demás. Que donde esté mi procesador 486, que se quiten los demás. Porque todavía tengo uno en casa y le podría instalar un Windows 95. Creéis que ligaría en un bar si le digo a una chica que he instalado un Windows 95 en un 486... Y que funciona?

Me lloran los ojitos porque leo por primera vez en la ciudad de los Krispis que XP sigue siendo suficientemente bueno.... Se estarán pasando poco a poco al lado del mal?

Huelo a conspiración....

Por otro lado, dado el enorme poder de los microprocesadores de hoy, pueden aparecer computadores muy baratos (de menos de $300) y no tan potentes, pero que pueden hacer todo el trabajo cotidiano de oficina (procesador de palabras, hojas de cálculo, presentación gráfica, etc), además de navegar por Internet, correo, mensajería instantánea, etc.

Estos computadores baratos pueden trabajar bien con un sistema operativo no tan pesado como Vista. Funcionan bien con XP o Linux. Y aquí es donde está el problema de Microsoft y la industria en general.

Los computadores pobres de hoy en día pueden hacer el 99% del trabajo cotidiano de oficina y del hogar. ¿Para qué comprarse lo último?. En la mayoría de los casos no se justifica.

Entonces tenemos dos extremos. Por un lado, un computador muy sencillito pero que puede ejecutar el 99% de las cosas, y por el otro, uno muy poderoso (necesario para alimentar a Windows Vista).

En cuanto al primer párrafo no tengo problemas. Es totalmente cierto. Tengo en casa otro PC con 512 RAM y procesador de 1GB y rula con Debian y XP de maravilla. Pero sigo sin ver el problema.

Spectra tiene, para aquellos que se quieran dejar engañar, porque es muy mala, una página dedicada a esos equipitos que no llegan al mínimo para poder acostarse con Vista, y son los llamados Vista Capable.

Lo de los dos extremos me queda muy clarito.

Microsoft se ve forzado a prolongar el XP porque de no hacerlo pierde el mercado de los computadores más sencillos, mercado que crecerá mucho en los próximos años.

No hay aplicaciones que usen tanto poder proveniente de los microprocesadores de hoy. Solo Windows Vista, los juegos y el procesamiento y edición de video, pero en pocos años, todo procesador, hasta el más pobre será capaz de manejar estas cosas. Así que el extremo de computadores muy poderosos, para uso personal tenderá a morir, quedando sólo los computadores económicos de menos de $200. Nadie necesitará un procesador de 16 núcleos, porque no habrá aplicaciones que necesiten tanto poder (para uso personal).

Este inmenso poder de los procesadores del futuro sólo lo usarán los que quieran correr aplicaciones como pronóstico del clima y otras similares, pero nunca una persona en su procesador de palabras, hoja de cálculo o incluso editando video.

Una alternativa para el uso de tanto poder, que es válida incluso hoy en día (en donde un procesador con 2 núcleos de 2 Ghz es mucho más de lo que se necesita en tareas cotidianas) sería que el computador tuviera 2 ó 4 salidas de video, y sus teclados y ratones respectivos. Así un computador manejaría 4 usuarios simultáneamente.

Un computador Core Duo está el 99% del tiempo sin uso, así que con los 4 usuarios estaría de una manera muy similar, y los 4 sentirían todo el poder para cada uno de ellos como si los demás no existieran (salvo en algún que otro momento en donde habría pequeños cuellos de botella).

Si se configura Linux para manejar estos 4 usuarios simultáneamente en un computador, sería el final de Windows, porque con sólo añadirle unas cuantas tarjetas de video (con sus respectivos controladores de teclado y ratón) se abaratarían los costos del computador para las empresas, escuelas, etc: 1 computador $400 + 4 tarjetas de video sencillas $25 c/u dan un total de $500, dividido entre cuatro personas, sale a $125 por "terminal".

Spectra es que es así. Se acojona y tiene que prolongar un producto. A mi también me lo dijo un primo de la novia de un amigo mío. Lo que no me dijo el primo de la novia de un amigo mío es que en la página de soporte de Spectra, tienes todos los datos de soporte, y de ahí es de donde se sacan los DATOS. Si quieres mirar hasta cuando vas a tener soporte (normal y extendido) te puedes pasar para recabar datos malignos. Los tienes para Windows XP e incluso para Windows Vista, así seguro que tienes datos para vaticinar el fin de Windows Vista. Pero claro, eso a una empresa se la repamplinfa. Se la suda que un Windows tenga un soporte de casi 14 AÑOS. Donde esté un Ubuntu licenciado con soporte a 3 años que se quite lo demás. Que me llega una incompatibilidad con una aplicación en mi Ubuntu? pues nada. O MIGRO a una distribución más novedosa, o tiraré de FOROS. Ya estoy viendo un problema de nivel 5 (O sea jodidísimo para la empresa), el soporte Server Ubuntu que se ha terminado (5 añitos), y el SysAdmin de la empresa poniendo todos sus recursos en un forero de 17 años. Qué hijadeputa es Spectra que te da casi 14 AÑOS para que te plantees una migración, te planta los Virtual Lab para que te vayas haciendo a la idea, los recursos para profesionales como los WebCast. Además son malísimos, porque si te has perdido uno, te los graban!

Y claro, el inmenso poder de los procesadores del futuro sólo lo usarán los que quieran correr aplicaciones como pronóstico de clima..... Y para  predecir el futuro creo.... Esto es gracioso, porque yo tengo un procesador de 1GB en casa, pero mi tía que quiere el ordenador para llevar sus tareas de costura "al día", se fue a comprar un equipo, y de menos de dos núcleos no había nada.... Aunque claro, también se puede pasar por DELL y comprar un Ubuntu de igual precio y menores características.

Sobre los dos últimos párrafos.... No comment.... Este no sabe lo que es un AS/400, ni SAP, ni Operations Manager, ni IBM Tivoli Security Operations Manager, ni SMS, ni Dynamics...

O sea, que a ver si no lo he entendido tampoco. Un equipo antiguo, pongámosle (512/256 RAM con un Pentium IV) y un cliente de correo electrónico, la consola de SAP que conecta con un servidor (Ya sabes, definido en el Saplogon.ini), la consola 5250 del AS/400, el office (Word, Excel, PPT, etc..) y accediendo en todo momento a recursos compartidos (Para tenerlo todo un pelín más seguro) va de puta madre no? Y ya no digo de puta madre (que puede ir según el caso y la metodología de trabajo de cada uno), sino que irá de puta madre repartiendo recursos en 4 pantallas tontas. Que eso de la inversión y el reciclado de equipos es una panacea y no vale para nada. Que es preferible un equipo que "gaste" 256 de RAM y los otros 256 de RAM que me sobran (si es que tiene de sobra) lo tengo "por si las moscas". Windows Vista gasta más RAM porque el acceso a ella es MAS RÁPIDO, así deja al disco tranquilo para que nos dure más. Eso de los discos duros híbridos con una memoria de precarga es otra panacea. Otro sacaero de dinero.. Total, el acceso a disco según tú es más rápido que el acceso a RAM. Si se peta seguro que es por un "cuello de botella".

El otro día instalé un IIS 6 en un W2k3 en un PIII con 256 de RAM, un SQL Server 2000 como motor de BBDD y que servía una pequeña Web. Según tú, si me llama el cliente, le diré que cuando el servidor deje de servir páginas con rapidez, será por un "cuello de botella"... O también le puedo decir que los cuellos de botella empiezan cuando haya más de 15 usuarios en paralelo pidiendo servicios...

Microsoft no podría competir con esto. Primero su Windows Vista está hecho para consumir muchos recursos (y producir una obsolescencia planificada de todos los computadores), no sirve para computadores económicos. Por otro lado, a Microsoft no le interesaría vender una sola licencia de XP, por ejemplo, para que 4 usuarios manejen sus "terminales", sino más bien una licencia por cada terminal. Sin embargo, Linux, que es liviano, y puede manejar estos 4 usuarios no tiene ningún problema, y con computadores tan baratos como $125 por persona, no tiene competencia en empresas, escuelas, cybercafés, etc.

Aquí sólo te puedo decir una cosa. En la Universidad tenemos Windows NT y solaris del año de la castaña, y una de las prácticas de Redes era conectar dos Windows 98 a través de una red AdHoc... La práctica de Linux era conectar varios equipos a través de recursos compartidos por Samba. En definitiva, sales con una base cojonuda para la vida real, y los ingenieros están preparados para afrontar un nuevo reto (pasar de una práctica con un Windows98 y WinNT, a un problema en la vida real en un entorno heterogéneo Win-Linux en sus últimas versiones).

En definitiva, creo que esta nueva línea de negocio, hará por fin que el departamento HelpDesk deje de recibir llamadas del tipo "Mi ordenador va lento", "Se me traba", "Esto va como cámara lenta", etc...

Y ya dejo de escribir, porque me lloran los ojitos....

En definitiva, que nos hemos equivocado, y como quiero redimirme, cuelgo aquí la fotografía que me pasó mi hermano Maligno cuando estuvimos en el Asegur@IT II que se celebró en BCN. Como diría el Trianero....

Va por ustedes...

 Fotografía del evento (Renombrar PDF por HTML si la queréis guardar de recuerdo)

1Saludo!!

Aqui teneis las transparencias:

[slideshare id=225697&doc=rails-against-the-machine-1200151509320409-5&w=425]

Descarga el pdf.

También podéis descargar el video [bittorrent] de la charla.