miércoles, 28 de marzo de 2012

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 8 - Acerca de Ruby on Rails y Computing Grid


Para el reporte de esta semana decidí hablar un poco de teoría de Ruby and Rails y Grid Computing, ya que me mencionaron algunos compañeros que esos fueron los últimos temas que se agregaron para el equipo clúster en la clase del martes pasado.

Como yo no tenía conocimiento de estos temas decidí investigar para informarme y ayudar a compañeros en la misma situación que yo (intenté recordar elpassword de mi usuario en wiki pero no lo logré XD)


Grid Computing


La principal función de este sistema de computación distribuido es compartir los recursos que no están centralizados de manera geográfica para resolver problemas de escala grande.

Con recursos me refiero a PC's , PDA, portátiles, móviles, software, datos e información.

Pienso que el método para compartir estos recursos será por VPN's, porque mis compañeros ya realizaron la configuración e hicieron pruebas, además me parece perfecto porque no es necesario estar en la misma ubicación geográfica, basta con estar conectado al mismo servidor de VPN para simular una red local, donde el medio de comunicación es internet.


¿Qué ventajas nos va a ofrecer Grid Computing?


La opinión que dan algunos autores es que ofrece una perfecta integración de sistemas y de dispositivos heterogéneos, lo que nos va de maravilla ya que de eso hablamos en la junta pasada, sobre la compatibilidad de máquinas, cosa con la que obviamente debe contar un clúster. Además grid computing se trata de una solución escalable, potente y flexible ya que evita problemas de falta de recursos.


¿Qué desventajas existen con Grid Computing?


Algunas desventajas son el manejo de recursos heterogéneos, la computación grid debe poder manejar cualquier tipo de recurso que maneje el sistema, sino no servirá de nada.

También en algunas fuentes mencionan problemas de comunicación, dicen que la comunicación es lenta y no uniforme, yo digo que la principal razón son los medios de comunicación. Como se supone que los recursos no están en la misma ubicación geográfica, pues cada recurso se conecta de manera distinta y con distintas velocidades de transmisión.
Se recomienda que todas las comunicaciones se hagan de manera cableada para evitar problemas de interferencia y baja señal de wifi en las comunicaciones inalámbricas.


Ruby on Rails


Ruby on Rails es un framework de aplicaciones web de código abierto escrito en Ruby, este framework trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del mundo real escribiendo menos código que con otros frameworks y con un mínimo de configuración.

Para descargas, videos y documentación, aquí les dejo la liga del sitio oficial en español:



Rails es un conjunto de librerías diseñado específicamente para crear aplicaciones de web. Como está hecho en ruby, es compatible con la filosofía de DRY. En vez de configuración, Rails prefiere convención y anotaciones. Esto proviene principalmente de las frustraciones con plataformas que obligan a uno a repetir en archivos de configuración XML una historia que ya se ha dicho en código.



La liga anterior te lleva a un tutorial muy completo de Ruby on Rails, cuenta con teoría y ejemplos prácticos.

No se todavía para que querrán este framework mis colegas, pero recuerdo que en la junta hablaron sobre una idea que tuvo Juan Carlos sobre colocar nuestro código en una plataforma para poder correrlo, así todos podían probar sus códigos, yo pienso que para eso quieren hacer uso de este framework.

Bueno mi meta para la siguiente semana es moverme más en estos campos que acabo de mencionar para así poder apoyar a mis compañeros y no cargarles tanto la mano.

También quiero preguntar a Juan Carlos y Rafa sobre su servidor de VPN's para hacer pruebas de conexión y que me pasen algún tutorial que siguieron para montar mi propio servidor, porque lo ocuparé en otras materias.


Quiero nominar a Juan Carlos por comentar en su blog sobre los temas que hablaron en la clase pasada (no pude asistir).

También nominar a Jonathan y José por los tutoriales y explicaciones que subieron a la wiki (sobre "MPI" e "Hilos en máquina virtual de java" respectivamente)


Espero recordar la contraseña de la wiki o que me puedan asignar otra cuenta :(



Saludos!




Sistemas Distribuidos (Clase y Laboratorio)

Reporte 8 - Acerca de Ruby on Rails y Computing Grid


Para el reporte de esta semana decidí subir hablar un poco de teoría de Ruby and Rails y Computing Grid, ya que me mencionaron algunos compañeros que esos fueron los último temas que se agregaron para el equipo clúster en la clase del martes pasado.

Como yo no tenía conocimiento de estos temas decidí investigar para informarme y ayudar a compañeros en la misma situación que yo (intenté recordar el password de mi usuario en wiki pero no lo logré XD)

  • Computing Grid

La principal función de este sistema de computación distribuido es compartir los recursos que no están centralizados de manera geográfica para resolver problemas de escala grande.

Con recursos me refiero a PC's , PDA, portátiles, móviles, software, datos e información.

Pienso que el método para compartir estos recursos será por VPN's, porque mis compañeros ya realizaron la configuración e hicieron pruebas, además me parece perfecto porque no es necesario estar en la misma ubicación geográfica, basta con estar conectado al mismo servidor de VPN para simular una red local, donde el medio de comunicación es internet.

¿Qué ventajas nos va a ofrecer Grid Computing?


La opinión que dan algunos autores es que ofrece una perfecta integración de sistemas y de dispositivos heterogéneos, lo que nos va de maravilla ya que de eso hablamos en la junta pasada, sobre la compatibilidad de máquinas, cosa con la que obviamente debe contar un clúster. Además grid computing se trata de una solución escalable, potente y flexible ya que evita problemas de falta de recursos.

¿Qué desventajas existen con Grid Computing?


Algunas desventajas son el manejo de recursos heterogéneos, la computación grid debe poder manejar cualquier tipo de recurso que maneje el sistema, sino no servirá de nada.

También en algunas fuentes mencionan problemas de comunicación, dicen que la comunicación es lenta y no uniforme, yo digo que la principal razón son los medios de comunicación.Como se supone que los recursos no están en la misma ubicación geográfica, pues cada recurso se conecta de manera distinta y con distintas velocidades de transmisión.
Se recomienda que todas las comunicaciones se hagan de manera cableada para evitar problemas de interferencia y baja señal de wifi en las comunicaciones inalámbricas.


  • Ruby on Rails




jueves, 22 de marzo de 2012

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 7 - Los nuevos planes que surgieron en la junta


El martes pasado nos juntamos en casa de Saúl para ponernos de acuerdo sobre configuraciones, el SO que correría cada nodo del cluster y también para aportar ideas de qué es lo que podriamos correr en el cluster.


Los acuerdos fueron los siguientes:

  • Todos los nodos deben contar con Ubuntu 10.04 de 64 bits
  • Crear en el nuevo Ubuntu el usuario "cluster" con password "trollFaceits"

Los compañeros del equipo de algoritmos hablaron sobre los programas que podían correr en el cluster, yo espero para futuras entradas también aportar algo sobre este tema porque me interesa aprender a programar algortimos paralelos.


Lo que más me llamó la atención fue que algunos compañeros ya realizaron VPN's para conectar sus pc's y nos dijeron que una vez teniendo nuestro ubuntu de 64 bits podíamos formar parte de la VPN para poder realizar las pruebas entre todos los nodos (todos los compañeros del salón). Por esta razón quiero nominar a los compañeros Rafael y Juan Carlos.


También una idea que me pareció buena es el comentario que hicieron que podiamos subir nuestros programas al server para probar nuestros códigos.


Decidimos hacer una calendario para organizar las futuras tareas, el calendario lo publicó la compañera Gaby en el grupo Alumnos ITS, pero aquí les dejo la imagen:






Espero quede todo configurado y listo para ya poder aprender a hacer y correr programas para el cluster.

Saludos!


domingo, 11 de marzo de 2012

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 6 - Principales servicios que debe cubrir nuestro clúster


Para esta entrada se me ocurrió ir listando los aspectos más importantes que debe cubrir nuestro clúster, para que nos sea más fácil y práctico buscar el software que cumpla con estos servicios, por ejemplo para buscar software que nos de alta disponibilidad de servicio, etc.

En estos días es posible tener una alta capacidad computacional (mucha capacidad de priocesamiento y de memoria) mediante clusters de computadoras sencillas o de baja capacidad, por ejemplo Google.

Por medio de la computación paralela podemos podemos realizar métodos de programación que utilicen recursos compartidos, como el procesador, la memoria, los datos y servicios.

Para llevar a cabo todo esto se necesitan distintos tipos de librerías de paso de mensajes y algunas consideraciones de diseño de aplicaciones (los programas paralelos se programan de forma distinta que uno convencional).

Considero estos los principales servicios que debe ofrecer un clúster, mi idea es posteriormente ir juntando programas que se encarguen de proveer estos servicios:

  • Poder computacional: Para tareas que requieran de gran procesamiento y memoria.
  • Máxima disponibilidad de servicios: Esto se puede empezar mediante las herramientas de monitoreo (esa información está en el wiki).
  • Completar el mayor número de tareas en el menor tiempo posible
Mi idea es que en base a estos servicios ir buscando el software que pueda cumplir con las tareas de manera eficiente, incluso podriamos programarlo.


Poder Computacional

Para el poder computacional es más que obvio que es necesario de un buen hardware en cada nodo, o también (esta es la idea) componer un clúster de un alto número de nodos (con un hardware modesto cada nodo).

De manera que la unión de todo este hardware componga algo más potente.


Máxima Disponibilidad

Para la máxima disponibilidad de servicios, mencionan muchos tutoriales que la clave o lo más importante está en las herramientas de monitoreo, porque nos dirán cuando un servicio está caído o pronostica una caída, esto debido a la alta demanda de recursos.

Sin embargo podemos contar con herramientas o técnicas que nos provean redundancia física y protección contra fallos de un sistema.

Lo que más me llama la atención en esto de la disponibilidad es como las empresas que cuentan con estos servicios gastan demasiado dinero en redundancias, por ejemplo para la conexión física entre nodos, por lo menos cada nodo cuenta con doble fuente de poder, doble cableado, incluso doble espacio de almacenamiento, donde cada dato tiene su réplica en un mirror.

Para mayor información sobre la alta disponibilidad les dejo este link que me pareció muy interesante: http://www.lintips.com/?q=node/119


Sobre tareas y tiempo

En este apartado también considero importante las herramientas de monitoreo, pero todavía más importantes son los cálculos que ya hemos hecho en clase, sobre cuanto tiempo tardaría la ejecución de ciertas programas, tomando como parámetros la cantidad de cores del procesador y también la cantidad de hilos en ejecución.

Espero para la próxima entrada encontrar o desarrollar un software que nos ayude a cumplir con estos servicios de manera eficiente.



Cualquier duda o aclaración pueden dejarla en comentarios.

Saludos!