Reporte Grupal

Reporte grupal

Hola, esta entrada trata sobre el reporte grupal, el equipo para esta actividad está conformado por mi compañero Alejandro Avendaño, Jonathan Alvarado y yo (Carlos Triana), los ejercicios que teniamos que desarrollar para esta actividad son los siguientes:

Formulen el sistema que quieren controlar en términos de espacio de estados.

En la forma normal controlable.

También en la forma normal observable.

Utilizando los vectores y los valores propios, diagonalicen a un forma normal -Jordan

Las investigaciónes, desarrollos y cálculos realizados se encuentran en la siguiente liga (blog de mi compañero Alejandro Avendaño): http://autoycontrolave.blogspot.mx/2012/11/blog-post_12.html

Bibliografía:

http://usuarios.multimania.es/automatica/temas/tema4/pags/ftec/ejemtransass.htm

http://www.scribd.com/doc/7110427/Espacio-de-Estados-Presentacion

Saludos!

Puntos extras

Control estructural por medio de sensores wireless y cómputo integrado

El origen del tema que escogí para esta entrada es el décimo tercero simposio anual internacional en materiales y estructuras inteligentes. Se llevó acabo en San Diego California en Febrero y Marzo del 2006.

A grandes rasgos el contenido de la publicación trata sobre el campo de la ingeniería estructural (o de estructuras, en específico la ingeniería civil) apoyado por la ingeniería informática-electrónica para la investigación de sensores wireless (todavía no implementados en la ingeniería civil) de bajo costo para su uso en sistemas de monitoreo estructural.

La finalidad de esta investigación e implementación es ahorrarse tanta labor y costos asociados  a las instalaciones hechas con largas extensiones de cables coaxiales en los actuales sistemas de control de estructuras, los autores mencionan que esta tecnología es el futuro para los sensores de control de estructuras.

Bien, lo que este sistema propone es que los sensores wireless son diseñados para cumplir 3 tareas principales en el sistema de control: 

1 - Los sensores inalámbricos son responsables de la recolección de datos de las respuestas estructurales.

2 - Los sensores inalámbricos son responsables del cálculo de las fuerzas de control.

3 - También son responsables de emitir comandos a los actuadores.

En la publicación se menciona que un prototipo de sistema "Wireless Structural Sensing and Control (WiSSCon)" fue presentado en el simposio.

Y para evaluar el desempeño de este prototipo se llevan acabo experimentos a media escala con 3 estructuras de acero en las que un amortiguador magnetoreológico está instalado. El funcionamiento del sistema de WiSSCon se ha demostrado que es efectivo y fiable.

Los autores y creadores de este sistema dicen que WiSSCon no es más que un prototipo diseñado para estar sensando y retroalimentando de información en "tiempo real" por wireless al sistema de control.  También mencionan que la comunicación por wireless es usada para la retroalimentación de la respuesta estructural para así calcular soluciones de control basadas en la información que se envío.

Para que les haga más sentido la transmisión de la información y cálculos realizados con la misma, dejo este gráfico que describe perfectamente el sistema (La imagen fue obtenida de la misma publicación: http://www-personal.umich.edu/~jerlynch/papers/SPIE2006Control.pdf)

La arquitectura del hardware de la unidad de control por wireless utilizado para este prototipo (WiSSCon) es la siguiente (se puede apreciar la interacción del cómputo embebido):

Y para los que creian que la clase de cómputo integrado no era tan importante, el módulo de control de señales (que se ilustra en la imagen siguiente) está hecho con mictrocontroladores ATmega128 (los usados en las tarjetas Arduino) y amplificadores operacionales, además de convertidores Digital-Analógicos.

Y así se ve en conjunto el módulo de control de la señal conectado al sensor wireless (básicamente es el aparato situado debajo de la estructura en la imagen 1, nótese la antena de emisión/recepción del módulo)

Campos de aplicación y conclusiones

En  la ingeniería civil, el mejoramiento a la respuesta (datos del movimiento de estructuras) de estructuras debido a la fuerte excitación dinámica es un reto difícil.

Como ya antes mencioné, el sistema WiSSCon ha demostrado que es efectivo y fiable por lo cual no dudo en la futura aplicación de este y similares sistemas de control en las estructuras civiles.

Las personas que trabajaron en esta investigación son: Yang Wang, Andrew Swartz, Jerome P. Lynch, Kincho H. Law, Kung-Chun Lu, Chin-Hsiung Loh

Y la liga de la publicación es:
http://www-personal.umich.edu/~jerlynch/papers/SPIE2006Control.pdf

Las palabras clave para encontrar la publicación aquí presentada fueron:
Keywords: structural control, wireless communication, embedded computing
 
La redacción total de este post fue hecha por mí, y todas las imágenes fueron obtenidas de la misma publicación.

PD: La publicación no contenía gran información de los temas tratados en la materia, por tal motivo no puse ecuaciones, técnicas o conceptos estudiados durante el semestre.


Saludos!
 

Sistemas Distribuidos (Clase y Laboratorio)

Semana 16 -  Unión a VPN y clúster

Hola, esta última semana una parte del equipo de clúster nos juntamos con la idea de reunir a muchos nodos para formar un clúster más grande que el que ya habiamos hecho anteriormente. La idea era presentarlo en el salón el martes, para que luego los demás compañeros pudieran correr aplicaciones sobre él.

Bueno, solo pudimos reunir 7 máquinas, ya estando en el salón de clases los planes cambiaron a un mejor plano.

Decidimos unirnos al clúster que habían creado los compañeros Juan Carlos y Rafael. Los compañeros ofrecieron darnos acceso para unirnos a su servidor de VPN, para luego ser parte del clúster.

El día de hoy algunos  compañeros (los que reunimos las características del SO: "Ubuntu 10.04, 64 bits")  logramos conectarnos al clúster mediante la VPN antes mencionada. 

Lo que hicimos todos fue descargar los bash que creó el compañero Juan Carlos, los bash se encargaban de descargar algunos paquetes, copiar carpetas y archivos e instalar y configurar todo lo necesario.

Después de descargar y configurar todo, descargamos Ganglia para monitorear el clúster, también por medio de los bash.

Al final el compañero Rafael nos agregó al clúster y luego mediante el siguiente link (monitoreo) me di cuenta que ya estaba dentro del clúster.

http://node1.hopto.org/ganglia/

A continuación les dejo algunas impresiones de pantalla que saqué:

Con esto me di cuenta la dirección ip que tenía asignada dentro del túnel de VPN, pueden notar como se creo una nueva conexión llamada "tun0-00" (mi ip es: 10.6.0.10)

Aquí mediante la herramienta de monitoreo se puede observar que el estado del nodo 10.6.0.10 es UP, también se logra ver el estado de actividad de mi nodo.

Y aquí se puede ver la actividad de los nodos que se agregaron al clúster la última hora, los que tienen instalado el ubuntu en su HDD les aparece su nombre de equipo (por ejemplo el del compañero Juan Carlos: "en rojo"), los que estabamos corriendo el SO en la USB solo nos aparece la dirección ip del equipo (mi dirección es 10.6.0.10, soy el de amarillo :p).

No quise poner nada de esto en la wiki porque ya había puesto información sobre Ganglia y también buena parte de esto ya estaba posteado, además no fui yo quien inició la implementación de esta buena herramienta.

Quiero nominar a mis compañeros:


- Juan Carlos: Por haber creado los .sh para descargar, instalar y configurar todo lo necesario.- http://jcecdps.blogspot.mx/2012/05/dps-class-contributions-week-15.html

- Rafael: Por haber implementado las herramientas de monitoreo y creado el servidor de VPN (junto con Juan).

-José: Por habernos guiado a mí y otros 2 compañeros con la instalación y configuración para unirnos al clúster.

Lo que yo espero para la tarde de mañana es que podamos correr aplicaciones con todos los nodos que nos agregamos hoy y después comparar los tiempos de ejecución de los programas con los tiempos que se hacian antes de que nos agregaramos nosotros.

 Saludos!

Sistemas Distribuidos (Clase y Lab)

Reporte 15 - Complemento sobre investigación de Grids

Para la semana 15 de Sistemas Distribuidos, decidí complementar en la wiki sobre el tema que investigó mi compañero Rodolfo de grids computacionales, ya que ya había leido con anterioridad sobre estos temas pero no los había puesto en la wiki.

También estuve trabajando con RMI pero con bastantes fallas debido a que nunca pude hacer la conexión entre computadoras, Java me tomaba una ip desconocida a la mia y nunca se pudo establecer conectividad, investigaré ese tema posteriormente más a detalle. La conexión solo la he logrado en mi misma máquina, pero así no tiene chiste, no se aprovecha las ventajas de RMI.

Bueno, mi corta aportación está en esta liga:

 http://elisa.dyndns-web.com/progra/Computacion%20Grid%28Malla%20de%20Ordenadores%29

Nominaciones:

• Rodolfo: Por la aportación de Grids computacionales en la wiki.

Saludos! 

Reporte 14 - Benchmark (Clase)

Reporte 14 - Benchmark (Clase)

Anteriormente ya había hablado sobre benchmarks y pruebas que podemos realizarle a nuestro clúster, pero solo había comentado sobre teoría y algunas aplicaciones que nos podian servir al equipo clúster.

En esta ocasión para el reporte de la clase de esta semana instalé y corrí el System Profiler y Benchmark llamado "HardInfo".

 

HardInfo es una pequeña aplicación que muestra información sobre el hardware y sistema operativo.

El post de esta semana se encuentra en la siguiente liga:

http://elisa.dyndns-web.com/progra/Benchmark%20HardInfo

Y para mayor información acerca de la aplicación HardInfo pueden visitar la página web del desarrollador:  http://hardinfo.berlios.de/HomePage

Saludos! 

Reporte 14 (Laboratorio)

Reporte 14 - Grid de computadoras (Laboratorio)

Hola, para el laboratorio de sistemas distribuidos esta semana investigué sobre grid de computadoras.

Bueno vamos a empezar con la definición de este interesante concepto. Llamamos grid al sistema de computación distribuido que permite compartir recursos no centrados geográficamente (sistemas centralizados) para resolver problemas de gran escala. Los recursos compartidos pueden ser computadoras, supercomputadoras, PDA, móviles, software, datos, información ,etc.

En las publicaciones donde investigué hacen una interesante analogía entre las redes de subestación eléctrica y las grids de cómputo, mencionan que en una red o grid de poder eléctrico distintas subestaciones, campos nucleares, sistemas de viento te pueden proveer del servicio de la electricidad eléctrica sin que tu lo sepas, es decir, tu solamente conectas el dispositivo que vayas a usar al tomacorriente esperando que a la empresa eléctrica a la que le estas pagando te de el servicio y puedas encender tu licuadora, refrigerador, computadora, etc.

Mencionan que en una grid de computadoras es algo similar. Tu puedes estar almacenando tus canciones o películas en servidores que ni siquiera son de tu propiedad (aunque pagues una renta de uso), inclusive están muy lejos de ti geográficamente pero ni siquiera te das cuenta.  

Las grids computacionales se están usando para hacer posible la ejecución de proyectos que serían imposibles de realizar sin el poder computacional de la grid.

Hay un buen número de grid computacionales en todo el mundo.

Campos de aplicación de las grids

• Los biólogos emplean grids para simular miles de posibles drogas en sus computadoras con el objetivo de descubrir una molécula capaz de bloquear proteínas específicas de ciertas enfermedades.
• Los científicos de la tierra emplean grids para registrar los niveles de ozono, usando satélites, descargando diariamente cientos de GB de datos.
  
   
• Los físicos de altas energías aplican grids en su búsqueda por una mejor comprensión del Universo, sobre la base de una grid de decenas de miles de computadoras de escritorio para almacenar y analizar los 10 Petabytes de datos producidos anualmente por el gran Colisionador de Hadrones. Miles de físicos en docenas de universidades alrededor del mundo quieren analizar esos datos.
  
   
• Los ingenieros usan las grid para estudiar energías alternativas, tales como la fusión de energía.
  
   
• Los artistas usan las grid para crear complejas animaciones para las películas.
  
   
• Los cientistas sociales estudian la vida de las abejas, el maquillaje que emplea nuestra sociedad  y los secretos de la historia, mediante el uso de las grid

Como podemos apreciar, es casi ilimitada la cantidad de aplicaciones en que se puede aplicar la tecnología de grids computacionales.

Lo relevante de esto es que las grid computacionales no solo nos provee de recursos para manejar grandes cantidades de datos sino que también estos datos están distribuidos por todo el mundo, es decir, se pueden formar grupos de trabajo de investigadores, ingenieros y científicos sin tener la limitante de estar unidos geográficamente.


Se puede decir que la base de esta idea de grid computacional es el compartimiento de recursos.


La  computación grid aspira a involucrar a todos en las ventajas de compartir recursos y en los beneficios de incrementar la eficiencia.


Las siguientes son algunas de las ventajas que te dan las grid computacionales:

• Las grid te dan acceso a pode computacional adicional.
• Una grid también te puede dar acceso directo a software, computadoras y datos remotos.
• Una grid te puede dar acceso a sensores remotos (lo que planean hacer algunos compañeros de domótica), telescopios y otros aparatos que no son de nuestra propiedad, pero los podemos rentar o los dueños pueden hacerlos de uso público.

Confiabilidad y seguridad

Después de todo lo mencionado anteriormente podría surgir la pregunta ¿A quiénes les confiaremos nuestros recursos computacionales?, es decir no conocemos a toda la gente que "tomará prestados" nuestros recursos.

Al pertenecer nosotros a una grid estamos expuestos a que se haga mal uso de nuestros recursos, por ejemplo, cuando tu quieras usar los recursos de tu computadora otro podría estar usándolos o podría ser al revés.

Es por eso que cuando alguien decide compartir sus recursos computacionales en la grid, normalmente pondrían condiciones para el uso de sus recursos, especificando límites temporales para que los recursos puedan ser utilizados y explicitando qué se puede hacer con ellos.

Acceso seguro

El acceso seguro a recursos compartidos es para mi el tema más desafiante hablando de la grid de computadoras, como he mencionado antes, tus recursos y datos están en juego cuando eres parte de la grid. Es por eso que para asegurar el acceso seguro, los desarrolladores de grid necesitan manejar 3 cosas de máxima relevancia.

• Políticas de acceso: ¿Qué se comparte?, ¿A quién se le permite compartir?, ¿Cuándo se permite compartir?
• Autenticación: ¿Cómo identificas a un usuario o a un recurso?
• Autorización: Cómo determinar si una operación específica es consistente con las reglas.

Las grid necesitan seguir la pista de esta información, que puede cambiar día a día, de modo eficiente. Esto implica que las grid deben ser extremadamente flexibles y contar con un mecanismo de reportes fiable. Por ejemplo lo que he visto que es muy usado en equipos que en los cuales entran varias personas es que se tiene un sistema de acceso, el sistema te dice quienes estuvieron ocupando tales recursos y también te dicen los movimientos que hizo cada usuario, esto puede usarse para saber quienes han violado un protocolo de seguridad, etc (creo que esto también lo queriamos implementar en el equipo de clúster).

Conexiones entre las grid

Ya hemos comentado que las distancias geográficas entre los nodos de la grid no importa, ya que todos estos nodos son unidos por internet  y los datos pueden ser compartidos por todo el mundo.

También hemos mencionado que para algún tipo de actividades es necesario manejar mucha cantidad de datos, aquí empieza el problema, cuando se está trabajando con una gran cantidad de datos obviamente la velocidad con que viajan estos datos también debe ser grande ya que de otra manera, se llevaría mucho tiempo en este tipo de actividades.

Algunos investigadores tienen necesidades computacionales que hacen que incluso las conexiones más rápidas parezcan lentas: algunos científicos incluso necesitan conectividad de aún más alta velocidad, por sobre las decenas de gigabits por segundo (Gbps); otros, necesitan latencias ultra bajas, de modo tal que no hayan retardos cuando estén trabajando de modo remoto y en tiempo real con sus colegas.

Otros quieren asegurar que la entrega de datos a través de la grid sea “justo a tiempo”, de modo tal que aquellos cálculos complejos que requieren de comunicación constante entre los procesadores puedan ser desarrollados. Para evitar los cuellos de botella en las comunicaciones, los desarrolladores de grid también deben determinar las vías para compensar fallas como errores de transmisión y fallas de los PC.

Para satisfacer estos requerimientos críticos, se deben solucionar muchos temas de las redes de alto rendimiento, incluyendo la optimización de los Protocolos de Transporte y el desarrollo de soluciones técnicas tales como el switching Ethernet de alto rendimiento.   

Es por esto que yo pienso que este tipo de técnicas y tecnologías de grid computacionales no se ha extendido en todo el mundo, porque se requieren de altas velocidades de transmisión de los datos, no todos los usuarios contamos con este tipo de conexiones, pero pienso que en un futuro si podría extenderse el uso de grids de computadoras.

Arquitectura

Voy a cerrar con este tema de grid de computaduras, platicando sobre la arquitectura de las grids, la arquitectura de una grid se refiere al modo en que la grid ha sido diseñada.

Usualmente se describe la arquitectura de grid en términos de capas, donde cada capa cumple una función específica. Las capas superiores están generalmente centradas en el usuario, mientras que las capas inferiores están más enfocadas en las computadoras y las redes: centradas en el hardware.

Las capas de una grid están distribuidas de la siguiente manera:

• La capa más baja es la red, ella conecta los recursos de grid.
  
   
• Sobre la capa de red descansa la capa de recursos: los actuales recursos de grid, tales como computadores, sistemas de almacenaje, catálogos de datos electrónicos, sensores y telescopios que están conectados a la red.
  
   
• La capa intermedia, el middleware, proporciona las herramientas que permiten a los distintos elementos (servidores, almacenaje, redes, etc) participar en una grid. Algunas veces la capa intermedia es “el cerebro” tras la computación grid.
  
   
• La capa que se ubica más arriba en la estructura es la de aplicaciones, que incluye aplicaciones en ciencia, ingeniería, negocios, finanzas y más, además de portales y grupos de herramientas de desarrollo cuya función es apoyar a las mismas aplicaciones. Esta es la capa que “ven” los usuarios de grid y con ella interactúan. La capa de aplicación usualmente incluye un servicio de uso (serviceware), que desempeña funciones de manejo de carácter general, tales como el rastreo de quiénes proveen recursos grid y de quiénes los están usando.

  

Para finalizar les dejo la dirección de un blog donde hablan sobre temas y proyectos con grids:
http://gridcast.web.cern.ch/Gridcast/ 

Saludos!

Sistemas Distribuidos (Clase)

Reporte 13 - Avances en clúster y RMI desde VPN

Hola que tal, esta semana estuve trabajando en programas RMI y también realicé aportaciones para el funcionamiento del clúster (especialmente en temas de VPN con hamachi), cabe señalar que del grupo que nos juntamos para realizar el clúster a mi no me funcionó, concluimos que fue por mi distribución de Ubuntu(11.10), ya que todos tienen 10.04 y pues a mi parecer si fue eso porque todos realizamos los mismos pasos.

Se puede decir que para mi esta fue una semana de pruebas fallidas. Como ya había mencionado en entradas anteriores (fue la anterior), trabajé con RMI junto con mis compañeros Esteban y Avendaño, desde computadoras remotas, todo iba bien, cada quien desde su máquina nos respondiamos los pings (nos encontrabamos cada quien en sus casas), pero al momento de yo correr el "servidor" y ellos el cliente y querer ejecutar un método de mi clase les decía que no podían hacer conexión con mi ip (dándoles una ip muy diferente a la mia) lo cual se me hizo extraño porque ellos si me respondian los pings.

De esto no sacamos conclusiones más que podía ser una medida de seguridad de Hamachi (fue mi conclusión)

Otra cosa en la que estuvimos trabajando fue en la creación del clúster desde nuestras casas gracias a túneles VPN, aquí también todo empezó bien con la creación de una red en Hamachi, luego todos nos unimos a la red y todos contestábamos los pings de todos.

Incluso generamos las llaves de SSH copiamos las llaves generadas de todos los nodos(ellos no podian copiar mis llaves), después intentamos entrar por SSH todos contra todos, yo podia entrar a las computadoras de todos, pero ellos no podian copiar las llaves que yo había generado, probamos varias veces sin éxito, al final concluimos que podría ser la versión de mi Ubuntu, pero no estoy seguro.

Al final mis compañeros (Jonathan y Avendaño) con los que estuve trabajando pudieron hacer funcionar el clúster (los 2 tienen Ubuntu 10.04) incluso corrieron un programa de fractales en python.

Bueno, para ir descartando posibles fallas yo me cree una USB con Ubuntu 10.04, instalaré todos los paquetes necesarios para realizar la prueba nuevamente.

Nomino a los compañeros Jonathan y Avendaño por crear el clúster de manera exitosa y correr aplicaciones en él (pronto me les uniré :p).

Saludos!

,

Sistemas Distribuidos (Laboratorio)

Reporte 13 - Benchmark

Hola que tal, hoy platicando con un amigo sobre el clúster mencionamos que sería bueno poder medir las capacidades de ejecución de cada nodo o computadora que componía el clúster, ya entrado en el tema decidí investigar sobre aplicaciones o programas que pudieran realizar esta función; encontré conceptos interesantes relacionados a este tema.

En esta entrada hablaré sobre Benchmarks. 

Un Benchmark, es un programa que mide las prestaciones de una computadora, o de una parte de la misma. Estos programas no solo pueden ayudarnos en la comparación de diferentes sistemas sino que además son capaces de evaluar las prestaciones de un equipo con diferentes configuraciones de Software y Hardware. Los benchmarks son pruebas para medir el rendimiento y poder verificar que el hardware funciona de forma óptima o para comparar distintas configuraciones. 

Se trata de programas que se instalan de la misma forma que una aplicación clásica. En la mayoría de los casos, el benchmark inicia una aplicación o conjunto de aplicaciones (ofimática, rendimiento 3D, cálculo científico, etc.) y mide el tiempo necesario para ejecutar una tarea. Los benchmarks 3D no miden el tiempo de ejecución sino el número de imágenes mostradas por segundo durante la escena y calculan el promedio. 

Pero como menciono arriba existen distintos tipos de tests o pruebas Benchmark.

Cada test o prueba Benchmark realiza un trabajo diferente. Algunos de estos nos indican lo rápido que es una computadora generando documentos, otros indican lo veloz que es en los gráficos y rellenos de pantalla, otros determinan la velocidad en operaciones matemáticas. Algunos hacen una mezcla de todos estos test. Para obtener resultados que nos sean útiles deberemos utilizar Benchmarks que reflejen el uso que le daremos al equipo.


Existen dos niveles de Benchmark: componentes y sistemas:

• Componentes
  
  
  Evalúan únicamente partes específicas de una computadora, como por ejemplo el procesador, el disco duro, la tarjeta gráfica, etc. Serán por tanto útiles a la hora de seleccionar componentes específicos para un determinado sistema.
  
  
• Sistema
  
  
  Evalúan el rendimiento global del sistema, miden las prestaciones del procesador, memoria, vídeo, disco duro, etc., trabajando conjuntamente en la computadora. Este tipo de pruebas permiten comparar sistemas diferentes. Responde a cuestiones como ¿Este equipo es más rápido que el equipo? o ¿Puede mi aplicación ejecutarse mas rápidamente en el caso de aumentar la velocidad del procesador, o esta limitada por otros subsistemas?
  
  Estos Benchmark miden prestaciones globales del sistema.

Bueno, apartir de estos conceptos se podrían sacar conclusiones sobre la utilidad de estas pruebas Benchmark, pero de igual manera mencionaré por qué estás pruebas son necesarias:

• Adecuar apropiados estándares de rendimiento que tomen en cuenta las diferentes características del software de 32-bits y las nuevas posibilidades de multitarea, video y 3D que las viejas pruebas no tienen en cuenta.

• Una medida más precisa de las diferencias de rendimiento relativo entre dos computadoras distintas, permitiéndole aumentar la vida útil de una PC con la vista puesta en el futuro.

• Ayudarle a prevenir que tenga que aumentar su inversión antes de tiempo, mostrándole la verdadera diferencia de rendimiento entre dos sistemas.  

En una página de IBM encontré información sobre el LINPACK benchmark, ellos realizaron una prueba o test a si Linux clúster, los pasos para la instalación y la ejecución se detallan en la siguiente liga:

http://www.ibm.com/developerworks/linux/library/l-cluster2/

El benchmark Linpack puede conseguirse en versión Fortran, C y como un applet de Java.

LINPACK Benchmark 

Como tema de interés también descubrí que existe LINPACK para Android, funciona exactamente para lo mismo, con LINPACK for Android tu puedes obtener mediciones de las prestaciones de tu teléfono móvil con Android, también aplica para tabletas.

Ya obtenidas las mediciones de tu dispositivo, también tiene la opción de compararlas con otros equipos.

El benchmark Linpack fue desarrollado en el Argone National Laboratory por Jack Dongarra en 1976, y es uno de los más usados en sistemas científicos y de ingeniería.

Su uso como benchmark fue accidental, ya que originalmente fue una extensión del programa Linpack cuyo propósito era resolver sistemas de ecuaciones que otorgaba el tiempo de ejecución del programa en 23 máquinas distintas.
Luego fueron agregándose cada vez mayor cantidad de máquinas.
Hoy en día, el programa Linpack ha sido reemplazado por el paquete Lapack, el cual hace un uso mucho mejor de las características de la arquitectura RISC (en esencia, sus técnicas algorítmicas fueron modificadas para que pase menor tiempo moviendo datos).

Aquí les dejo un video sobre un Linpack en un móvil con Android:

Pueden encontrar más información y videos sobre este benchmark en el siguiente link:

http://www.greenecomputing.com/

Aquí les dejo una imágen con el benchmark LINPACK for Android en ejecución:

(Linpack for Android)

Saludos!

Sistemas Distribuidos (Laboratorio)

Reporte 12 - Seguridad de la información en el clúster

En esta entrada para laboratorio mencionaré buenas prácticas que se acostumbran hacer en un clúster para mantener la seguridad y confidencialidad.

Sería bueno que la información de nuestro clúster sea conocida y accedida solamente por aquellos que estén debidamente autorizados (confidencialidad).

También la información solo puede ser modificada, creada o eliminada por quienes estén autorizados (integración), para este tipo de seguridad, yo recomendaría las técnicas y procedimientos que se aplican en algunas empresas como Alestra, para administrar equipos de red (routers, switches, etc) ellos primero tienen que autenticarse con user y password.

Hacen esto por medio de  TACACS


TACACS (Terminal Access Controller Access Control System) es un protocolo de autenticación remota, propietario de cisco, que se usa para comunicarse con un servidor de autenticación comúnmente usado en redes Unix. TACACS permite a un servidor de acceso remoto comunicarse con un servidor de autenticación para determinar si el usuario tiene acceso a la red.

Cuando el administrador de la empresa quiere tener acceso a un router, primero se le pide un user y un password, luego estos datos proporcionados por el administrador van y se comparan a este servidor TACACS, luego si tus datos están registrados en el servidor y todo coincide tendrás acceso al equipo, de otra manera es "imposible" entrar a cualquier equipo.

No digo que utilicemos esta herramienta en específico porque es propietario de Cisco, por lo tanto es de paga, pero podemos hacer uso de algo similar, incluso se me hace sencillo programarlo, con algo de Mysql debe quedar rápido.

Por otro lado, los sistemas que albergan datos e información deben garantizar disponibilidad cuando se requiera por quienes tienen los privilegios.


Buenas prácticas en seguridad dentro de la red

• Mantener servicios y sistemas actualizados, en cuanto a parches y bug fixes, en este aspecto yo considero que nosotros estamos bien, porque todos tendremos la misma versión de SO además que es la LTS.
  
  
  
  
  
  
  
  
  
  
• Definir y emplear puntos y procedimientos de acceso (mecanismos de autenticación), aquí considero buena opción realizar un simulador de un servidor TACACS donde cada nodo cuente con su user y password guardados en el master, luego cuando queramos entrar al clúster, que nos pida autenticarnos y nuestros datos se comparen con los guardados en el master, de esta manera una persona no autorizada no podría entrar a nuestro clúster.
  
  
  
  
  
  
  
  
  
  
  
• Normar y controlar el acceso a las instalaciones físicas de los sistemas.
  Para este punto yo creo que es más aplicable a empresas donde si requieren de un nivel de seguridad máximo, donde su información si es muy importante.
  Es bien sabido y he escuchado de muchos expertos que si no tienes una seguridad física de tus equipos, entonces no sirve de nada tu seguridad "virtual", incluso me han platicado de equipos cisco con candado físico, creo yo para proteger puertos.
  
  
  
  
  
  
  
  
  
  
  
  
• Implementar sistemas de respaldo. La mayoría de las empresas de IT cuentan con sistemas de respaldo, donde cada moviemiento de información se va actualizando en un disco duro.
  En este tipo de sistemas, así como en los sistemas de redundancia (equipos secundarios que entran en acción cuando el principal falla), es muy importante que se verifique periódicamente su buen funcionamiento.
  
  Actualmente está de moda el concepto de "la nube", incluso es una opción para respaldar la información del clúster, pero yo no la considero como una buena opción ya que dependes del servicio de alguien que ni siquiera le pagas para que te aloje tus datos, por lo tanto no te garantiza confiabilidad y disponibilidad. Peor aún dependes de una conexión a internet que debe ser muy segura y poco intermitente, a los proveedores de internet si les pagas, pero igual nunca garantizan confiabilidad.
  
  Yo considero mejor opción un servidor de respaldo propio, que funcioné con la conexión local, por si el internet llega a fallar, tomando en cuenta que nuestro clúster estará dentro de un mismo salón.
  
  
  
  
  
  
  
  
  
  
• Cifrar o proteger con contraseñas los datos e información importante del clúster. Para eso nosotros estamos trabajando con SSH, con SSH estamos habilitando el establecimiento de conexiones completamente cifradas.
  
  
  
  
  

 

Esperemos que nos quede tiempo para implementar estas medidas de seguridad que en un futuro serán necesarias, cuando quede listo nuestro clúster.

Saludos a todos! 


 

Sistemas Distribuidos (Clase)

Reporte 12 - Hamachi + SSH

En esta semana estuve trabajando con mi compañero Avendaño en realizar un túnel de VPN para poder hacer el clúster desde nuestras casas (el túnel lo hicimos con Hamachi), hicimos esto para llevar algo que ofrecer o proponer en nuestra junta de clúster (creo que ya habían hecho algo parecido).

Esto de realizar el túnel ya lo habiamos intentado antes pero no resultó debido a problemas con el Firewall de Ubuntu, esta vez mi compañero pudo resolver ese problema, luego tiramos ping cada uno de nosotros a nuestras computadoras y si se respondían.

Después de comprobar que entre nuestras computadoras si había conexión, decidimos entrar de forma remota mediante SSH, logramos entrar cada uno a la computadora remota y además intentamos realizar el clúster pero no funcionó.

En la siguiente liga de la wiki documenté todo el proceso que llevamos a cabo para realizar la conexión:

http://elisa.dyndns-web.com/progra/Hamachi%2BSSH

Como ya mencioné en la publicación de la wiki, quiero dar crédito y nominar a mis compañeros Avendaño y Adriana por haber trabajado y apoyado en este "mini proyecto".

Planeo hacer futuras pruebas de RMI aprovechando las facilidades y ventajas que nos da Hamachi.

También nomino al compañero Jonathan por la explicación de su código: http://elisa.dyndns-web.com/progra/Passing%20Arguments%20to%20Threads

Saludos!

 

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 11 - RMI desde computadoras remotas

Para esta entrada decidimos mi compañero Esteban y yo utilizar el feature de Java RMI, decidimos realizar esta tarea en pareja para aprovechar al máximo las funcionalidades de RMI, ya que anteriormente solo lo hice desde mi propia computadora.


Lo que hicé esta semana fue solamente documentar (bases) las cosas que necesitaremos para relizar nuestro mini "proyecto", luego esperemos para la siguiente semana implementar el código para poder hacer uso de este interesante feature.


Hicimos está documentación con la intención de ampliarla más adelante con los códigos que vayamos implementando y por supuesto los resultados que conseguimos, si  obtenemos buenos resultados les haremos saber (mediante la wiki o una entrada) para así intentar implementarlo con todos los compañeros.


Les dejo la liga del wiki, donde podrán ver la documentación que relicé para poder llevar acabo este proyecto (es solo las ideas, pasos y teoría, luego subiremos nuestras implementaciones de código).


Liga: http://elisa.dyndns-web.com/progra/Documentaci%C3%B3n%20RMI


Saludos!

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 10

Java Remote Method Invocation (RMI)

RMI es un mecanismo ofrecido por Java que nos permite utilizar funciones (métodos) de un programa, desde otro programa que reside en otra computadora, obviamente para poder hacer esto se necesita que las computadoras participantes estén en red, además de otras cosas que mencionaré a continuación. Wikipedia dice:

La arquitectura RMI puede verse como un modelo de 4 capas (esto como las capas del modelo ISO OSI ayudan a hacer el troubleshooting en una red con complicaciones, al separar el proceso en layers que cumplen una función en específico):

• Primera capa

La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.

• Segunda capa

La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

• Tercera capa

La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.

• Cuarta capa

La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

Lo primero que se debe implementar para establecer comunicación entre los programas es el servidor. Vamos a crear una interface que enumere las funciones provistas por el objeto a ser exportado por la red osea que queramos invocar de forma remota (solo se declara, no se define). Esta interfaz es compartida entre cliente-servidor. Del lado del servidor vamos a crear una clase que implemente esta interfaz que acabo de mencionar.

Después por el lado del cliente también se accede a esa misma interfaz, pero existe una clase stub que es la que se encarga a establecer el envío del mensaje por red, y recibir una respuesa.

Ejemplo

El programa ejemplo se compone de 2 ventanas, una para el cliente y una para el servidor. El cliente tiene una caja de texto donde se escriben los mensajes a enviar; dichos mensajes se envían utilizando un método remoto(el método se encuentra en la clase RmiServidor.java). Mientras, el servidor posee un area de texto donde se muestran los mensajes que recibe de los posibles clientes.


Para descargar el código vayan a la siguiente liga, también podrán encontrar explicación detallada de cómo funciona RMI, el código no lo hice yo, esta es la página del autor: http://casidiablo.net/rmi-%C2%BFque-es-un-ejemplo-sencillo-con-rmi/

El código se compone de 5 clases:

• RmiServidor.java
• GUIServidor.java
• InterfazReceptorMensajes.java
• RmiCliente.java

En la clase RmiServidor se define el puerto de escucha en 3232 y se despliega la información enviada por el cliente en la GUI del servidor.

La clase GUIServidor solo nos servirá para mostrar los procesos que el servidor realicé, osea mostrar el String escrito que le llega al Servidor desde el Cliente.

La clase InterfazReceptorMensajes es una interfaz que hereda de la clase Remote ( de java.rmi.) aquí es donde anteriormente mencioné que se declara el método recibirMensaje (solo se declara, se definirá en la clase RmiServidor.java)

La clase RmiCliente declara un objeto de la interfaz InterfazReceptorMensajes y dos objetos String en donde colocaremos la dirección IP del servidor a conectarnos y el puerto.

Como pueden ver en el código, la dirección del server es la 127.0.0.1, eso quiere decir que el servidor lo correré en la misma computadora (es la dirección localhost), lo ideal es hacerlo en 2 computadoras, también hacer la prueba con más clientes.

El método enviarMensaje es el que realmente utiliza RMI. Dicho método utiliza la función recibirMensaje del objeto rmiServidor, es decir: utiliza el método remoto del servidor a través de la interfaz.

Explicación más detallada del código pueden encontrarla en la liga antes mencionada (página del autor del código). Para la próxima sesión modificaré el código e intentaré correrlo en más computadoras para aprovechar este feature ofrecido por java.

Yo corrí los códigos con éxito y estos son los pantallazos (para compilarlo pueden hacer como con cualquier otro programa de java, yo hice javac *.java):








Saludos!