hector

=**__Apuntes de Arquitectura para Altas Prestaciones.__**=

Introducción sobre lo que vamos a ir haciendo durante el curso y lo que haremos en las prácticas esta tarde. Esperábamos una asignatura más hardware, pero bueno, esta bastante en auge la supercomputación mediante sistemas distribuidos, así que también está bien.
 * __21/02/2007__**

Recapitulación?Hoy?Pero si es viernes... Y el último día fué "de prueba". Aun no hay dudas presentes, ya que no hemos entrado en materia... Vamos a ver como esta el panorama de la computación distribuida. Tenemos una reseña referente a este tema en la página de la asignatura del siguiente [|enlace]. //**Curiosidad**: Los procesadores de física son los que se dedican a calcular en los juegos cómo debería caerse un muñequito para que sea lo más realista posible.// ¿Por qué Perl? Porque es el que mejor se sabe el profesor, así que será el que mejor nos podrá explicar. ¿Por qué Ruby? Porque está muy en expansión ultimamente. Veremos como meterle mano a programas planteados. ¿Por qué Javascript? Porque se parece bastante a java y además se puede ejecutar directamente en un browser.
 * __23/02/2007__**
 * **Recapitulación clase anterior**
 * **Dudas clase/prácticas**
 * **Computación distribuida per tutti**

No vamos a aprender como mejorar el hardware (overclocking,...) del que disponemos porque vista la velocidad a la que cambia, es un poco absurdo dedicarse a esto, mejor nos centramos en algo menos específico que podrá aplicarse aún cuando se queden antiguos los equipos de que disponemos actualmente.

Nodo -> Tiene capacidad de procesamiento. Switch -> No tiene capacidad de procesamiento. Escalabilidad: Los sistemas deben ser escalables, porque al agregar más usuarios debe seguir funcionando. Tolerancia a fallos: Depende del diseño. Hay cierto nivel de tolerancia a fallos, no se puede prevenir cualquier fallo y ponerle solución antes de que ocurra el fallo. Transparencia: No todos los sistemas distribuidos son transparentes o absolutamente transparentes, pero tienen cierto nivel de transparencia (no como los pararelos que no están ni de moda ya..).
 * Vamos con la computación distribuida.**

- Sistemas cluster: Puntos de sincronización entre los ordenadores que trabajan en el mismo sistema. Al arrancar suelen descargarse un backup del servidor para tener todos instalado lo mismo (como en las prácticas de la escuela). El administrador debe tener el control de toda la red. - Sistemas grid: Pueden estar geográficamente distantes. Pueden haber varios administradores. - Redes overlay: Se construye entre todos los que estan ejecutando una serie de programas (o protocolos), por ejemplo, emule. - Sistemas P2P: Teóricamente no hay diferencia entre cliente y servidor. Es parte de las redes overlay. //**Curiosidad:** diferencia entre bittorrent y emule -> bittorrent crea la red a nivel de descarga y emule a nivel de aplicación, por lo tanto en bittorrent te estás bajando cosas de gente que se está descargando lo mismo que nosotros o que lo está compartiendo.// - Computación de ciclos redundantes: Sistemas que utilizan los recursos de los hosts de una red cuando dichos hosts no los necesitan. por ejemplo SETI@home o folding@home.
 * Ejemplos de sistemas de computación distribuida:**

__**26/02/2007**__ Hoy acabaremos de ver la introducción de la asignatura y comenzaremos con el primer taller. Comentamos las ventajas de un sistema de supercomputación distribuido respecto a uno monolítico en lo referente a escalabilidad, precio, robustez ante fallos por ejemplo hardware.

//Ejercicios. Bloque 1.1 1. Ejemplos de sistemas P2P. A parte de los sabidos bittorrent, gnutella, emule, edonkey, napster... Dani dice sistemas de TV por internet por ejemplo pplive (o antTV). El profesor dice joost->sistema de comparticion de video parecido a youtube para MAC. Messenger y similares.(Menos google talk). 2. Productos para montar clusters de ordenadores e instalaciones que los usen. (BUSCAR EN INTERNET) openMosix. 3. Producto para sistemas grid y sistemas que lo usen. GridSystems -> IGV.(libre. lo explican con colorines incluso...)//

Como ya sabíamos no vamos a dedicarnos en esta asignatura a ver computación y programación paralela, porque no es algo de lo que dispongamos facilmente.

- La red es fiable: si,ya...obvio, no? Por multitud de motivos, la red no será siempre fiable, aunque como norma general si lo sea. - La latencia es nula: - El ancho de banda es infinito: Vale, venga, yo me pido una red de estas para los reyes... - La red es segura: Dios!! Ya ha quedado bastante claro por qué se llaman falacias de la computación distribuida, no?? No solo hay inseguridad debido a los fallos de la red o de diseño, sino también a los malechores de los usuarios ("todos mienten", Greg House). - La topología no cambia: Esto tampoco es cierto, ya que en un momento dado se puede caer o desconectar un nodo de la red, el fallo podría llegar a afectar a toda una rama (subred) de la red si se produjera un fallo en la puerta de enlace que interconecta dicha subred con el resto de la red. - Hay un solo administrador: Si tenemos una red distribuida gegráficamente distante, esto iba a ser complicado (si, ya internet y procesamiento remoto, pero y si la red esta formada por miles de hosts? Pues eso). - El coste de transporte es nulo: A mi me enseñaron que en esta vida no hay nada con coste nulo y como se indica en las web de la asignatura, y se podía suponer, esto es cierto. - La red es homogénea: Ni en la situación más ideal. Seguro que en un sistema cuyos hosts sean del mismo fabricante y la misma serie, hay algún transistor con características diferentes en cada una de las CPUs.
 * Veamos las características fundamentales de la computación distribuida** (cosas que se suponen,pero no son ciertas).

- Transparencia: - Apertura: - Escalabilidad: - Tolerancia a fallos: - Seguridad:
 * La intención de los sistemas distribuidos es conseguir:**

Continuamos viendo conceptos de empaquetamiento (marshalling) de objetos y datos para transmisión entre sistemas heterogéneos. Veamos los apuntes de la [|página web], que están bastante completos. Sobre CORBA, decir que es un sistema muy completo e independiente del lenguaje de programación, SO,... por lo tanto muy compatible, puede interconectar sistemas muy heterogéneos, pero también es muy complejo. Problemas de .Net -> Pese a que es un estandard independiente de Microsft, es controlado por este. Aunque haya implementaciones de tipo abierto, estas no pueden evitar seguir el camino de Microsoft.

Vemos nuestro primer programa en Perl!! Solo 4 líneas!! 1ª línea -> indica quién será el interprete del resto de fichero (en unix linux, será como en el ejemplo). use - > importar librerias 4ª línea -> shift coge el primer argumento de la línea de comandos, se lo pasa a uri_scape (para que unix nos pueda comprender) 5ª línea -> se crea una cadena de petición http donde indicamos ya el pueblo que buscamos. 6ª línea -> coge el fichero que tiene una expresión regular y guarda en 2 variables lo que hay entre lat y fin d lat y long y fin de long. 7ª línea -> muestra por pantalla el mensaje indicado.

Cómo haríamos esto mismo en ruby?? Pues la verdad es que de una forma muy parecida.

La ventaja de estos lenguajes de scripts, es que son muy rápidos de desarrollar, hay gente que se dedica a desarrollar, documentar y COMPARTIR librerias (en java dependeríamos de Sun), ...

- Descubrir un recurso -> Averiguar que existe usando un mecanismo. - Disponibilidad -> Dependencia de un recurso de uno o varios nodos. - Comunicación a través de la red.
 * Tipos de sistemas de computación distribuida.** **Terminología.**

FIN del primer tema sin dudas.

Enlace a siguiente página de apuntes.