CLUSTER DE ALTA

(1)

PROYECTO DE INVESTIGACIÓN EN MATERIA DE SEGURIDAD PÚBLICA – IUISI

CLUSTER DE ALTA COMPUTACIÓN PARA

APLICACIONES DE

INFORMÁTICA FORENSE

MEMORIA JUSTIFICATIVA

DEPARTAMENTO DE ELECTRÓNICA.

Escuela Politécnica Superior. Ctra. Madrid – Barcelona km 33.600 28871 Alcalá de Henares (Madrid)

Teléfono: 91 885 65 80/85/62/40 Fax: 91 885 6591

Pedro A. Revenga de Toro (Investigador Principal) Alfredo Gardel Vicente

alfredo/[email protected]

DEPARTAMENTO DE ELECTRÓNICA E INFORMÁTICA DEL SERVICIO DE CRIMINALISTICA GUARDIA CIVIL Cte. Ramón García Jiménez

[email protected]

(2)

Pedro A. Revenga de Toro. Universidad de Alcalá.

Alfredo Gardel Vicente. Universidad de Alcalá.

Ramón García Jiménez. Comandante de la Guardia Civil.

CLUSTER DE ALTA COMPUTACIÓN PARA APLICACIONES DE

INFORMÁTICA FORENSE.

INSTITUTO UNIVERSITARIO DE INVESTIGACIÓN SOBRE SEGURIDAD INTERIOR

Noviembre 2009. Madrid

(3)

INSTITUTO UNIVERSITARIO DE INVESTIGACIÓN SOBRE SEGURIDAD INTERIOR

DIRECTORA DEL IUISI:

Consuelo Maqueda Abreu

DIRECCIÓN:

Instituto Universitario de Investigación sobre Seguridad Interior (IUISI).

Francos Rodríguez, 77 – 28039 MADRID.

Teléf: 91 398 85 56 – Fax 91 398 85 55 e-mail: [email protected]

www.iuisi.es

EDITA:

Instituto Universitario de Investigación sobre Seguridad Interior (IUISI).

IMPRIME:

Asociación Pro Huérfanos de la Guardia Civil (Imprenta-Escuela).

Príncipe de Vergara, 248 – 28016 MADRID.

Noviembre 2009.

Depósito Legal: M-49425-2009 ISBN: 978-84-692-7258-9

Las opiniones emitidas en esta publicación son de exclusiva responsabilidad del autor.

Los derechos de explotación de esta obra están amparados por la Ley de Propiedad Intelectual. Nin- guna de las partes de la misma puede ser reproducida, almacenada ni trasmitida en ninguna forma ni por medio alguno, electrónico, mecánico o de grabación, incluido fotocopias, o por cualquier otra forma, sin permiso previo, expreso y por escrito de los titulares del © Copyright.

(4)

lulsl

Instituto Universitario de Investigación sobre Seguridad Interior

Edición 1 1 Revisión ¹ 1 Fecha ¹ 28/06/2009

Nombre/s Fecha

Preparado Pedro Revenga, Alfredo Gardel 22/09/2009

Revisado Alfredo Gardel, 10/10/2009

Aprobado Alfredo Gardel, Pedro Revenga 12/10/2009

Registro revisiones

Página Edición Revisión Fecha

PROYECTO:

"CLUSTER DE ALTA COMPUTACIÓN PARA APLICACIONES DE INFORMÁTICA FORENSE"

(5)

ÍNDICE

1 ALCANCE DEL DOCUMENTO ... 4

2 CLUSTERS DE ALTA COMPUTACIÓN (HPC Clusters) ... 6

3 DESCRIPCIÓN DE PROBLEMAS ... 10

4 NECESIDAD DE UN CLUSTER DE COMPUTACIÓN ... 10

5 PROCESADOR CELL ... 13

5.1 CELL BE EN LA PLAYSTATION 3 - PS3 ... 13

5.2 ARQUITECTURA DEL PROCESADOR CELL ... 15

6 CLUSTER REALIZADO ... 18

6.1 ARQUITECTURA DEL CLUSTER ... 18

6.2 EQUIPAMIENTO DEL CLUSTER ... 19

7 INSTALACION SO LINUX EN PS3 ... 21

7.1 INSTALACIÓN DE OTRO SISTEMA OPERATIVO ... 22

7.2 RECONFIGURACIÓN DEL KERNEL ... 24

7.2.1 Memoria Swap en VRAM ... 25

7.2.2 Driver PS3 GigaEthernet ... 26

8 PUESTA EN MARCHA DEL SERVIDOR ... 27

8.1 CONFIGURACIÓN DE UN SYSLOG CENTRALIZADO ... 28

8.2 CONFIGURACION DHCP INTERFAZ ETH0 ... 28

8.3 ACTUALIZACION DINAMICA DE NOMBRES DE NODOS PS3 ... 29

8.4 ANULACION DHCP INTERFAZ ETH1 ... 30

8.5 AUTENTICACIÓN SEGURA MEDIANTE SSH ... 30

8.6 SISTEMA DE FICHEROS EN RED NFS: CONFIGURACIÓN ... 31

8.7 CONFIGURACION TFTP ... 32

8.8 CONFIGURACION WAKE ON LAN ... 33

8.9 CONFIGURAR SERVICIO DE TIEMPO - NTP ... 34

9 APLICACIONES DESARROLLADAS ... 36

9.1 PROGRAMACION DEL PROCESADOR CELL ... 36

9.2 SIMULADOR CELL ... 38

9.3 INSTALACION DE SLEUTH KIT - APLICACIONES FORENSES... 39

9.4 INTERFAZ AUTOPSY ... 39

9.5 UDP-CAST ... 40

9.6 OPENSSL CELL USANDO MARS ... 41

9.7 HERRAMIENTAS PARALLEL CELL ... 44

9.8 CALCULO MD5 ... 45

9.9 CALCULO MD5 EN PARALELO ... 45

10 DESARROLLO DE UN CASO FORENSE ... 46

11 RESULTADOS Y CONCLUSIONES ... 53

12 TRABAJO FUTURO ... 55

13 REFERENCIAS ... 55

14 ANEXO. CODIGO CALCULO MD5 ... 56

(6)

ÍNDICE F IGURAS

Figura 1. Presentación cluster realizado ... 4

Figura 2. Investigadores junto al cluster que han desarrollado. ... 5

Figura 3. Diagrama de bloques del sistema a validar ... 7

Figura 4. Cluster PS3 en venta de forma comercial ... 7

Figura 5. Nodos PS3 cableados en el cluster desarrollado. ... 9

Figura 6. Vista lógica de un cluster beowulf ... 12

Figura 7. Placa base de pruebas para realizar cambios en la arquitectura de cada nodo PS3 .. 14

Figura 8. Cluster PS3 en venta de forma comercial ... 15

Figura 9. Arquitectura interna de un procesador Cell BE ... 16

Figura 10. Diferentes plataformas de computación basadas en Cell BE ... 17

Figura 11. Ratio coste de computación entre Cell/B.E. y X86 ... 17

Figura 12. Vista general del Cluster y monitor del servidor central ... 18

Figura 13. Diagrama esquemática con la arquitectura del cluster ... 18

Figura 14. Foto armario rack 1911 ... 19

Figura 15. UPS conectadas para estabilizar y mantener la alimentación frente a problemas de red ... 20

Figura 16. Expansor para disco duro externo ... 20

Figura 17. Proceso de instalación y arranque por red ... 22

Figura 18. Servidor central basado en un Quad PowerPC con YDL 6.1 instalado ... 27

Figura 19. Arquitectura hardware del procesador Cell ... 37

Figura 20. Con el sistema Cell Full System Simulator de IBM no es necesario ... 38

Figura 21. Sleuthkit instalado en el servidor y cluster PS3 ... 39

Figura 22. Aceleraciones conseguidas ... 42

Figura 25. Aceleración OpenSSL/MD5 con MARS ... 46

Figura 27. Logo de Autopsy ... 47

Figura 28. Logo de Autopsy ... 47

Figura 29. Nuevo Caso de Autopsy... 48

Figura 30. Introducción de datos del caso con Autopsy ... 48

Figura 31. Creación de un Caso en Autopsy ... 49

Figura 32. Host de almacenamiento de Hash MD5 para el Caso de Autopsy ... 49

Figura 33. Adición de un host al Caso de Autopsy ... 50

Figura 34. Imágenes en Autopsy ... 50

Figura 35. Ubicación datos Caso de Autopsy ... 51

Figura 36. Galería de Casos de Autopsy ... 51

Figura 37. Otras opciones disponibles en Autopsy / SleuthKit ... 52

Figura 38. Diagrama de bloques del sistema a validar ... 54

ÍNDICE DE FIGURAS

(7)

1 ALCANCE DEL DOCUMENTO

Este documento refleja los trabajos desarrollados por el Departamento de Electrónica de la Universidad de Alcalá (en adelante UAH) y el Departamento de Criminalística de Guardia Civil para la realización de proyecto de investigación en materia de seguridad pública, dentro del área de aplicación 1, "Aplicación de tecnologías innovadoras en los diferentes campos de la seguridad ciudadana" que desde el Instituto Universitario de Investigación sobre Seguridad Interior (IUISI) convocadas en septiembre de 2008.

Figura 1. Presentación cluster realizado

(8)

Figura 2. Investigadores junto al cluster que han desarrollado.

(9)

2 CLUSTERS DE ALTA COMPUTACIÓN (HPC Clusters).

A menudo los expertos de informática forense deben hacer frente a tareas de alta carga computacional, como las siguientes:

• Ruptura de claves/descifrado

• Cálculo de cadenas hash: signaturas MD5, SHA1, SHA256 , etc.

• Creación de índices en ficheros

• Búsquedas de cadenas de texto en dispositivos de almacenamiento

• Comparación de signaturas de ficheros, etc.

El hecho de que se tarde en algunas tareas demasiado tiempo hace que se desechen posibles vías de trabajo e investigación. El uso de software comercial no permite la eficiencia necesaria por lo que se realizan dichas tareas en contadas ocasiones, ejecutadas cuando no se hace uso del ordenador destinado a esa labor, por las noches y en fin de semana preferiblemente.

Para tener un sistema capaz de lograr una elevada tasa de procesamiento computacional se puede hacer uso de equipos supercomputadores con un coste desorbitado o como es la propuesta del presente proyecto, desarrollar un cluster de N procesadores de última generación (el procesador Cell consta de 8 núcleos de procesamiento PowerPC) escalable y multi-tarea pero que tengan un razonable coste/operación.

En la actualidad se ha alcanzado el punto límite en el que varios procesadores trabajando en paralelo proporcionan una mayor velocidad de procesamiento que un único procesador a muy alta frecuencia. Todo ello debido a la mejora de las comunicaciones entre los distintos procesadores logrando tener un coste menor por operación de cómputo. Por ello existe un gran auge del procesamiento paralelo y distribuido. El cuello de botella en este sistema de procesamiento es la sobrecarga que el tiempo de comunicación tiene para obtener la tasa total de procesamiento del conjunto como equipo de computación.

Un cluster se compone de un conjunto de procesadores, denominados nodos, enlazados entre ellos mediante una red de interconexión de alta velocidad. El software de procesamiento paralelo debe permitir un funcionamiento conjunto entre todos los procesadores sin tener en cuenta la forma de interconexión. Por otro lado un sistema distribuido tiene una red de comunicación más lenta por lo que los cálculos en cada nodo deben ser relativamente complejos para que la sobrecarga de la comunicación de datos y resultados no ralentice la ejecución total.

Existe una diferencia entre lograr un funcionamiento en paralelo (particionando el conjunto de datos a procesar, teniendo el mismo código de ejecución todos los procesadores pero procesando diferentes datos) y el funcionamiento distribuido (particionando el problema en diferentes tareas distintas entre cada uno de los procesadores). El procesamiento en paralelo requiere que no exista una dependencia entre datos, realizando un procesamiento vectorial de los datos, siendo lo que actualmente realizan sin problema las modernas CPUs de múltiples núcleos.

(10)

La computación en paralelo utiliza múltiples procesadores conjuntamente para resolver problemas de cálculo más rápidamente de lo que lo haría un único procesador. En la siguiente figura se muestra una serie de sistemas procesadores encargados de realizar en paralelo tareas de búsqueda de cadenas de caracteres sobre un disco clonado.

Figura 3. Diagrama de bloques del sistema a validar.

Actualmente existen diferentes procesadores de cálculo muy potentes que deben ser programados a bajo nivel para obtener toda la eficiencia deseada. Destaca entre todos ellos el nuevo procesador desarrollado por IBM, Toshiba y Sony: el procesador Cell. Este procesador ha sido diseñado para realizar cargas de trabajo de cálculo intensivo y aplicaciones de banda ancha con contenido multimedia. Todo ello está conformado por una arquitectura IBM POWER PC y múltiples unidades de cálculo vectorial del tipo SIMD (una instrucción-múltiples datos) capaces de realizar importantes cálculos en coma flotante. Este procesador es escalable y puede utilizarse en una amplia variedad de dispositivos

Por tanto, en el presente proyecto se desea utilizar como sistema procesador de bajo coste, plataformas PS3 readaptadas para que conforme cada una de ellas un nodo del cluster.

Figura 4. Cluster PS3 en venta de forma comercial.

(11)

Como objetivos que se plantearon en la solicitud de realización del presente proyecto cabe enumerar los siguientes.

En la lista siguiente se enumeran los principales hitos que se persiguen con la realización del presente proyecto de investigación:

1. Diseñar una estructura de procesamiento hardware distribuida para el cómputo de búsquedas de textos en paralelo.

2. Analizar el sistema de clonado de discos y dispositivos de almacenamiento para realizar la indexación distribuida de manera simultánea. Incorporación de un splitter o elemento de comunicación que sea capaz de enviar/repartir a todos los nodos los datos copiados.

3. Codificación de algoritmos de software eficientes usando arquitecturas de procesamiento vectorial (MPI, etc.), atendiendo a los requerimientos que actualmente tienen una mayor demanda desde Guardia Civil.

4. Creación de una indexación distribuida de la información, analizando el ancho de banda de las comunicaciones y el tiempo que se emplea en dicha comunicación de datos.

5. Análisis de algoritmos distribuidos para la indexación óptima de cadenas y almacenamiento de datos para búsquedas heurísticas.

6. Desarrollo de una algoritmo que permita gestionar correctamente el balanceado de la carga de cómputo entre los N procesadores disponibles en el cluster.

7. Programación de una herramienta web (codificada en php) que permita a diferentes usuarios realizar el lanzamiento de búsquedas diferentes sobre el cluster.

8. Analizar la posible reutilización del sistema de co-procesamiento hardware como complemento de otras aplicaciones comerciales ya existentes.

(12)

Figura 5. Nodos PS3 cableados en el cluster desarrollado.

(13)

3 DESCRIPCIÓN DE PROBLEMAS

En este apartado se muestran los distintos problemas que las fuerzas de seguridad deben abordar y para los cuales puede resultar muy inteerresante la utilización del cluster desarrollado. En general, cabe mmencionar, cualquier trabaajjoo o aplicación en la que se necesite una eleevvada potencia de cálculo, para buscar informmaacción

en una gran caapacidad de almmaacce

enn amiento (SATA HDD en raaid, etc.).

En particular se han apuntado laas siguientes aplicaciones prácticas:

Indexación de discos (casos pornografía, terrorismo, etc.) Búsqueda de archivos comprometidos

Comparación rápida / búsqueda de ficheros

Creación BBDD imágenes comprometidas (p2p, etc.) RRuptura de criptografía dispositivos, HDD encriptaddo.

Búsqueda de información sobre el contenido de los discos incautados; p.e. buscar otra información como cadenaas de texto, códigos, etc.

4 NECESIDAD DE UN CLUSTER DE COMPUTACIÓN

De forma general, se puede definir un Cluster Beowulf como un sistema informático dedicado a la computación paralela de forma masiva y de altas prestaciones, principalmente, construido a base de un conjunto de componentes hardware estándar. Un cluster Beowulf ejecuta un sistema operativo de libre distribución como Linux o FreeBSD, y se interconecta mmediante una red privada de gran velocidad. Geeneralmente se compone de un grupo de PCs o estaciones de trabajo dedicados a ejecutar tareas que precisan una alta capacidad de cálculo. Los nodos en el clusteerr de computadoras no se ubican en los puestos de trabajo de los usuarios, sino que están totalmente dedicados a las tareas asignadas al cluster. Generalmente, el cluster se haya conectaaddo al mundo exterior por un solo nodo, como es nuestro caso.

Las difeerrentes funcionalidades que puede tener un nodo pueden resumirse en las siguientes:

Nodo de computación

Es en eesste tipo de nodo en donde el cálculo o procesamiento se realiza. Es el típico modo de un nodo del cluster. Cada nodo de computación puede desarrollar una o más tareas basadas en un sistema de ejecución.

Nodo de gestión

Dado que los Clusters son entornos de computación complejos, la gestión de los nodos de forma individual resulta muy immportante. Como capacidades de dicho tipo de nodo cabe resaltar las siguiente: monitorización del estado de los nodos individuales, envío de los comandos de gestión y control de los nodos para corregir algún problema o para realizar funcionees de administración y gesstión como apagado/encendido del nodo, .

(14)

En la mayoría de los clusters, debe existir un nodo con dicha funcionalidad paara que sea sencillo reconfigurar o reinstalaarr un nodo con una nueva imagen. Esta operación puede ser repetida multiples veces. Esta funcionalidad permite que de forma rápida se realice un cambio o una aammpliación de las capacidades de cálculo que posee el sistema de alta computación

Nodos de usuario

A mmeennuudo los nodos de computación no poseen un inteerface de usuario adecuado. En este tipo de nodos, se proporciona al usuario de un interfaz gráfico y aplicaciones de usuario para que se pueda tener acceso a los resultados de cálculos y computación realizados por el cluster.

Nodo de Control

Proporcionan servios adicionales que pueden ayudar a otros nodos en el cluster para poder trabajar en conjunto y así obtener el resultado deseado. Así estas funcionalides se pueden agrupar en dos grandes grupos:

- Servicios de nombrado dinámico como DHCP y DNS. Estas funciones peermiten que se puedan añadir nodos fácilmente al cluster y que se asegure una communicación con el resto de nodos.

- Programación de tareas que indicant el trabajoo que debe realizarse en cada nodo, en cada momento. De esta manera, si un nodo termina el cálculo de una tarea y está disponible para realizar un trabajo adicional, el nodo de control puede asignar a dicho nodo una siguiente tarea.

Nodo de almacenamiento

En algunas aplicaciones ejecutadas en el cluster, necesitaann de un acceso rápido y simultáneo al sisteemma de almacenamiento. Esto se puede lograr de diferentes maneras depeendiendo de los requisitos específicos de la aplicación. Los dispositivos de almacenamiento pueden estar acoplados directamente a los distintos nodos o coneeccttados a un nodo central que se responsabilice de la gestión de los datos almacenados.

En la siguiente figura se muestra la estructura de un típico cluster beowulf.

(15)

Figura 6. Vista lógica de un cluster beowulf

Con este tipo de equipo informático se posibilitará a las fuerzas de seguridad con una herramienta dedicada a la búsqueda en paralelo de diferente tipo de información haciendo uso de distintos nodos fácilmente paralelizables, sistema escalable y con un conjunto de aplicaciones con interfaz web que simplifiquen el funcionamiento y tareas diarias a las que se enfrentan nuestras fuerzas de seguridad especializadas en pericia informática y electrónica forense.

Por otro lado, cada vez más importante, cabe resaltar la reducción de consumo energético que se persigue con el uso de máquinas especializadas en cálculo computacional y no dedicadas al uso de programas de ordenador con aplicaciones en multitarea, ejecución en segundo plano, caché, etc. las cuales tienen una arquitectura enfocada a otras labores que no es la operación forense o búsqueda intensiva de patrones.

Cabe mencionar, que los nodos del cluster no tienen que tener pantalla de monitorización, siendo todos ellos controlados de forma remota por medio de programas específicos de comunicación y control como ssh o similar.

El software y aplicaciones forenses estándar, para ejecutarse más rápido en un sistema Beowulf, debe reestructurars, siendo necesario generalmente particionarlos en tareas paralelas que se comunican usando alguna librería de procesamiento distribuido como MPI o PVM, o sockets o SysV IPC, que serán comentadas posteriormente.

(16)

Por todo lo anterior, se justifica la creación de un clúster (a escala, con 12 nodos) que puede ser replicado y ampliado a conveniencia de los equipos de investigación forense de cada unidad operativa y en los servicios centrales.

5 PROCESADOR CELL

La primera implementación de la arquitectura Cell es la Cell Broadband Engine, también conocida como procesador Cell, que data de 2005 (Figura 1). Desde que se presentó como el procesador para la Sony PlayStation 3, la CPU Cell ha llamado mucho la atención. Y a pesar de que la Playstation (Figura 2) es de hecho la aplicación más difundida de la arquitectura Cell, la más espectacular es la de Roadrunner (Figura 3), con más de 12.000 procesadores Cell [1].

Hay Cells disponibles tanto de IBM como de Mercury Computer Systems. Mercury ha fabricado incluso una tarjeta PCI Express con un ordenador en toda regla dotado de un procesador Cell. Toshiba usa una variación del procesador Cell en sus portátiles Qosmio.

Además de por su potencia y flexibilidad, a Cell también se le conoce por su eficiencia en cuanto a rendimiento energético. Los sistemas basados en Cell ostentan actualmente los siete puestos más altos en la Green 500 List [2] como las supermáquinas más eficientes en cuanto a rendimento energético. En este artículo exploramos la arquitectura Cell y describimos una aplicación de ejemplo que nos ayudará a comenzar a programar para el Cell.

La máquina Cell está especializada en el manejo de problemas que requieren grandes cantidades de potencia informática pero que a la vez son divisibles en subtareas menores. Los procesadores Cell individuales procesan luego las tareas por separado, de forma paralela. Un procesador Cell consiste en un núcleo convencional de procesamiento PPE (Power Processing Element) con una arquitectura IBM Power Architecture de 64 bits y ocho SPEs (Synergistic Processing Elements) (ver la Figura 4). Cada uno de los ocho SPEs tiene 256KB de memoria local y un controlador MFC para DMA (Memory Flow Controller). Un bus de datos llamado EIB (Element Interconnect Bus) comunica los nueve procesadores, la memoria principal y los dispositivos periféricos. Mientras que el sistema operativo del PPE gestiona los recursos del sistema, los SPEs se encargan de las operaciones algebraicas. Sus registros de 128 bits manipulan cuatro números de 32 bits por operación (enteros cortos o comas flotantes de precisión simple) o bien dos figuras de 64 bits (enteros largos o comas flotantes de precisión doble). Esta arquitectura SIMD (Single Instruction, Multiple Data) es parecida a la extensión MMX de los procesadores de PC.

Una peculiaridad de los SPEs es que sólo funcionan con código y datos almacenados en su memoria local; no acceden a la memoria principal ni a los periféricos. Las aplicaciones deben asegurarse de que el código y los datos necesarios están disponibles de forma local. Las operaciones de transferencia de datos entre la memoria principal y la del SPE las organizan los controladores de DMA de los SPEs, por lo que no causan sobrecarga en la SPU

5.1 CELL BE EN LA PLAYSTATION 3 - PS3

Un equipo PS3 incluye una nueva arquitectura de procesamiento denominada Cell BroadBand Engine. Esta arquitectura fue diseñada conjuntamente entre IBM, Toshiba y Sony. Está basada

(17)

en la antigua arquitectura computacional PowerPC desarrollada por IBM. La PlayStation 3 está diseñada con una cierta filosofía hacia aplicaciones abiertas, opensource, etc.

En la figura se muestra una placa base de la PS3, desmontada para realizar cambios en su arquitectura, disco duro y memoria.

Figura 7. Placa base de pruebas para realizar cambios en la arquitectura de cada nodo PS3

Se puede hacer uso de códigos y aplicaciones particulares instalando Linux en la PS3. Existe amplia documentación de ayuda al desarrollador, accesible de forma pública, cuestión muy de valorar dado que el proceso forense debe ser auditado en todos los aspectos y que de forma completa se pueda asegurar el correcto procesamiento de los datos y algoritmos ejecutados.

La mayoría de distribuciones importantes de Linux tiene soporte para ejecutarse en una arquitectura PS3. El software de desarrollo de IBM para Cell es abierto y de acceso público, existiendo múltiples aplicaciones que dotan a los programas realizados de una potencia sin par, en cuanto a coste y procesamiento. Cabe hacer notar que si se igualan costes de procesamiento se podría ampliar considerablemente el número de nodos Cell, superando en operaciones de cálculo a otros supercomputadores.

En la siguiente figura se muestra una comparativa de la PS3 con otras consolas destinadas a ser centros multimedia y de entretenimiento.

(18)

Figura 8. Cluster PS3 en venta de forma comercial.

5.2 ARQUITECTURA DEL PROCESADOR CELL

El núcleo principal del procesador Cell se denomina PPU. Es en definitiva, un núcleo de procesamiento basado en PowerPC. La compatibilidad del SO Linux con procesadores de la familia PowerPC ha hecho posible una migración y creación de múltiples aplicaciones y distribuciones de forma sencilla y rápida. Si se usa únicamente la PPU del procesador Cell, la comparativa con procesadores x86 actuales (Core2, Quad) no resulta muy beneficiosa para el Cell.

La PPU está conectada a 8 unidades coprocesadoras, denominadas SPUs. Y es aquí donde radica la verdadera potencia del procesador Cell. Los procesadores que se integran en la PS3, se reserva una SPU por temas de redundancia y una segunda SPU se utilizada por un hipervisor cuando se desea cargar otro sistema operativo distinto al GameOS de partida. De esta manera, se dispone de una máquina con un procesador central PPU y 6 unidades SPU coprocesadoras.

La unidad gráfica GPU-RSX no es posible utilizarla desde SO Linux, presumiblemente para prevenir que juegos que no sean de la marca pudieran hacer uso de la consola PS3. Por tanto, en cuanto a dispositivos gráficos, sólo se dispone del dispositivo framebuffer, no pudiendo hacer uso de la GPU-RSX para procesamientos computacionales.

En la siguiente figura se muestra el diagrama de bloques que componen la PS3.

(19)

Figura 9. Arquitectura interna de un procesador Cell BE.

El procesador PowerPC funciona a una velocidad de 3.2-GHz con una cache de nivel L2 de sólo 512 KB. Por otro lado, los nuevos procesadores Intel Core i7 920 funcionan a una velocidad de 2.66 GHz a 4 Ghz si se refrigera de manera adecuada, disponiendo de 8 hilos de procesamiento, 6 MB de Cache y 3 canales de comunicación con memorias de tipo DDR3 a 1066 MHz.

En las siguientes figuras se ilustra las capacidades del procesador Cell BE que incorpora la PS3 comparándolo con otras plataformas de computación actuales:

(20)

Figura 10. Diferentes plataformas de computación basadas en Cell BE.

Consumo / coste

Figura 11. Ratio coste de computación entre Cell/B.E. y X86.

(21)

6 CLUSTER REALIZADO

En la siguiente figura se muestra el montaje del cluster realizado con la ayuda proporcionada por el Instituto Universitario de Investigación sobre Seguridad Interior (IUISI).

Figura 12. Vista general del Cluster y monitor del servidor central.

6.1 ARQUITECTURA DEL CLUSTER

En la siguiente figura se muestra un diagrama con la arquitectura del cluster realizado, aplicado a tareas como la estabilización de imágenes procedentes de un sistema de estereovisión.

Figura 13. Diagrama esquemática con la arquitectura del cluster

(22)

6.2 EQUIPAMIENTO DEL CLUSTER

Anteriormente ya se disponía de cierto material:

4 PlayStation3 Armario rack 19"

Figgura 14. Foto armario rack 19"

2 SAIs (MGE Ellipse 600/850) controlables por NUTs, un paquete de software para LLiinux con una arquiteectura cliente/servidor el cual permite que varios equipos aallimentados por un único SAI (y que ejecutan un cliente) puedan hablar, a través de la red, con el equipo que tieene la conexión de datos del SAI (y que ejecuta el servidor). De eesste modo, ante un corte de corriente, todos los eequipos quedan informados y pueden aaccttuar en consecuencia. Lógicamente, la función de un SAI o UPS (manntener la aallimentación durante cortes de luz) es insuficiente para un servidor, ya que es muy probable que no haya nadie para apagar el equipo durante el tiempo de duración de las baterías. La desconexión del SAI se realiza de modo que las baterías no se agotan inútilmente, pues no hay nada que alimentar.

(23)

Figguura 15. UPS conectadas para estabilizar y mantener la alimentación frente a problemas de red.

HDDs de 320 GB / 7200 rpm. El extensor de disco duro (HDXT) proporciona a cada nodo PS3 una conexión SAATTA externa. De esta manera se permite conectar de forma externa cualquier disco duro SATA o IDE (para discos IDE requiere un conversor SATA to IDE). Una forma sencilla y económica de disponer de más capacidad de aalllmacenamiento en cada nodo PS3.

Figurra 16. Expansor para disco duro e terno.

Con la ayuda proporcionada por el IUISI, se ha completado con el siguiente material:

SSeervidor G5 y pantalla

SSwitch gigabit Ethernet de Alta velocidad (24 bocas) 10 PS3

(24)

Cabe mencionar en este apartado la necesidad de usar cables de conexionado Ethernet de Categoría 6, que aseguran una correcta transmisión de los datos a frecuencia Gigabit.

Con todo ello, se dispone de un cluster de 12 nodos PS3 con discos duros de 320 GB a 7200 rpm lo que posibilita un almacenamiento local en el interior del cluster de 4 TeraBytes.

7 INSTALACION SO LINUX EN PS3

En este apartado se describe brevemente la puesta en marcha del cluster, configuración de los distintos módulos necesarios para dar una facilidad en el manejo de todo el conjunto a un futuro usuario.

A diferencia de otros fabricantes de consolas, Sony soporta oficialmente la instalación de Linux en la Playstation. Además hay muchos tutoriales en la web sobre este tema [6]. Cabe destacar dos cosas acerca de la ejecución de Linux en la PS 3. La primera es que no está soportado el acceso directo al hardware: a fin de proteger su firmware propietario, Sony ha incluido una capa de virtualización adicional. Lo segundo es que para los programas Linux sólo se dispone de seis de los ocho procesadores SPE Cell.

En la siguiente figura se muestra el típico Proceso de instalación y arranque por red.

(25)

Figura 17. Proceso de instalación y arranque por red

7.1 INSTALACIÓN DE OTRO SISTEMA OPERATIVO

La PS3 que se ha utilizado, permite la introducción de un sistema operativo diferente al que inicialmente arranca el equipo (GameOS). En este apartado se muestra la secuencia de acciones necesarias para poder instalar desde cero el sistema operativo Linux YellowDog 6.1 (YDL 6.1) compatible con el hardware de los nodos PS3. La PS3 tiene un cargador de SO en el arranque denominado other_os.bld, a partir del cual se indica al hipervisor qué SO se desea instalar y arrancar.

(26)

El firmware de la PS3 se debe actualizar, siendo necesario un firmware de Version 2.20 o superior. El último firmware 3.0 permite instalar otro SO en la consola. Se debe ir a la opción

"System Update" del menu principal para poder instalar una versión reciente de la PS3.

A continuación se enumeran los distintos pasos a seguir para instalar YDL en PS3.

1. Tras encender la consola, pulsar el botón PS del mando. A partir de este momento se puede tener un teclado / ratón USB que será reconocido en el sistema.

2. Ajustar fecha

3. Configurar la red ethernet de forma automática a. No UPnP

4. Ir a herramientas Ajustes del sistema

a. Formateado del disco: 10 GB para GameOS de Ps3 es suficiente por si se desea recuperar GameOS, dejando el resto para otro sistema operativo

b. Instalar otro Sistema Operativo => meter DVD o llave usb con el arranque YDL 6,1 que se desea tener (kboot / petitboot).

(27)

Instituto Universitario de Investigación

lulsl

sobre Seguridad Interior

1

c. Cambiar el SO predetermina do de arranque para que arranque el linux instalado. En caso de querer rearrancar GameOS de PS3 basta con mantener 3 seg. apretado el botón de encendido y la consola automáticamente conmuta a modo juego de la PS3. También existe un comando desde linux que permite reinicia r el sistema en modo juego de PS3.

Todas estas operaciones se han rea lizado de forma sistemática en cada uno de los nodos del cluster PS3, arrancando Linux desde la PS3.

1 1 '1 '11 I ' 1 1 " 1 1 ' ' t • ' t • 1 I

• • li' 1 " ' d 1 • 1 1 1 .. .

, , "1 1 11 , , 1 , , t t .., 1 ' 1 ' I • .1 1 • • 1 1

1 1 ' 1 t1 f 1 j , 1 1 • 1 t H J J 1 .11 f • 1 1 ll .1 1 1 • 1 1 t 1 r '' " • ' t , "11

1 111 111 1 1 1 Htl • • ) ' 1 1 11 • 1 "1 f f l 11\ 1 11

7.2 RECONFIGURACIÓN DEL KERNEL

Antes de comenzar debemos tener unos paquetes que se necesitarán para compilar el kernel:

aptitude install build-essential libncursesS-dev kernel-package

Ahora debemos obtener la imagen del kernel 2.6.29, descomprimirla y crear el enlace simbólico /usr/src/linux apuntando al directorio que acabamos de descomprimir, y entrar a ese enlace /usr/src/linux, esto es:

cd /usr/src

wget http ://kernel.org/pub/linux/kernel/v2 .6/linux-2 .6.29 .tar .bz2 tar xjfv linux-2 .6.29.tar.bz2

ln -sf linux-2 .6.29 linux cd Linux

1

(28)

lulsl

Paso seguido, vamos eliminar cualquier archivo .config que existiese y limpiar los archivos objetos de otras versiones anteriores.

make mrproper

Ahora para configurar las opciones del kernel específicas del PS3 ejecutamos este comando:

make ps3 defconf ig

Esto creará un archivo .config con las opciones del soporte PS3 habilitadas, tales como el nuevo VRAM. La nueva versión del kernel de Linux 2.6.29, incluye la incorporación de un nuevo módulo o driver que da soporte de VRAM para PS3. Esto quiere decir que a partir de ahora se puede utilizar memoria RAM no usada de la tarjeta de video como un dispositivo de bloque para almacenar datos o como memoria de intercambio (swap).

Adicionalmente si se quiere habilitar otras opciones (por ejemplo módulos de sonido OSS, etc.), se ejecuta menuconfig seleccionando lo que se desee.

make menuc onfig

Llegó la hora de compila r tanto la imagen del kernel como los headers (estos últimos necesarios para compilar otros programas en nuestro Linux):

make-kpkg clean

make-kpkg --revision ccsl --initrd kernel image kernel headers

Esta compilación creará unos archivos .deb en el directorio /usr/src. Para instalarlos basta con usar dpkg como se haría con cua lquier otro paquete de Debian:

cd ..

dpkg -i linux-image-2.6.29 ccsl_powerpc.deb

Por último se debe configurar el gestor de arranque (PetitBoot), a través del archivo /etc/yaboot.conf para configurar las imágenes de linux, teniendo que agregar las siguientes

líneas:

image= /boot/vmlinux-2.6.29 label=Debian-2.6.29-ccsl initrd=/boot/initrd. img-2.6.29 initrd-size= 1607 6

append="video=ps3fb:mode:3 --"

rea d-only

7.2.1 Memoria Swap en VRAM

Para activar la swap es necesario primero habilitar el dispositivo para el área de intercambio:

mkswap /dev/ps3vram

(29)

lulsl

Es necesario editar el archivo /etc/fstab para agregar la definición de la swap recién habilitada:

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

/dev/ps3vram none swap sw,-1

o o

/dev/ps3da5 none swap sw,-2 O

o

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Hay que destacar que los parámetros -1y -2 establecen la prioridad de la swap a ser usada por el sistema. Ahora para cargar esta configuración primero apagaremos la swap que se esté usando:

swapoff -a

Esto puede tardar unos segundos mientras se vacía la swap usada y sin ninguna aplicación abierta para que no se cuelgue la máquina. Ahora se activa la configuración que crea da en el archivo /etc/fstab

swapon -a

Se puede revisar la información de la memoria swap ejecutando:

swapon -s

Otra forma es configura r udev:

# udev rules to automatically enable swap on /dev/ps3vram

# Copy this file to /etc/udev/rules.d/10-ps3vram-swap.rules

# Choose only one of the rules below

# Initialize and enable swap unconditionally

# KERNEL=="ps3vram", ACTION=="add", RUN+="/sbin/mkswap /dev/ps3vram", RUN+="/sbin/swapon -p 10 /dev/ps3vram"

# Initialize using /etc/fstab and standard init scripts

# KERNEL=="ps3vram", ACTION=="add", RUN+="/bin/bash -e '/bin/grep -q A / dev/ps3vram [[:space :]]* ^swap/etc/fstab & & / sbin/mkswap /dev/ps3vram'"

7.2.2 Driver PS3 GigaEthernet

La PS3 tiene una comunicación Gigabit Ethernet En el kernel aparece dicho dr iver, pero hay que configura rlo dado que no está activado por defecto

Una forma sencilla de incluirlo es usando el fichero de pre-configuración que algunas distribuciones de Linux como fedora core incluyen:

make ps3 defconfig

(30)

8 PUESTA EN MARCHA DEL SERVIDOR

En este apartado se muestran los pasos seguidos para realizar la puesta en marcha del servidor de gestión del cluster.

Figura 18. Servidor central basado en un Quad PowerPC con YDL 6.1 instalado.

Tras la instalación de YDL 6.1 en el servidor, se han desactivado los servicios que no son estrictamente necesarios para la gestión del cluster. Por defecto, la instalación de YDL habilita un número de servicios que no son necesarios, así pues, por un motivo de seguridad y eficiencia se han deshabilitado diferentes servicios con el comando chkconfig.

El siguiente commando muestra qué servicios se encuentran actualmente activados tras el inicio:

[root]# /sbin/chkconfig --list | grep ':on'

Con el siguiente commando se ordena al sistema deshabilitar los servicios que no son necesarios. La lista incluye los servicios no extrictamente necesarios para el funcionamiento del cluster. Esta lista debe ser modificada convenientemente.

[root]# LIST="kudzu apmd autofs iptables ipchains rawdevices lpd rhnsd"

[root]# for SERVICE in $LIST; do /sbin/chkconfig --del ${SERVICE}; done

(31)

Se recomienda desabilitar los siguientes servicios.

autofs linuxconf reconfig

isdn pppoe iptables

ipchains apmd pcmcia

rawdevices lpd kudzu

pxe rhnsd wine

httpd identd

8.1 CONFIGURACIÓN DE UN SYSLOG CENTRALIZADO

Los nodos del cluster mandarán todas las entradas de su log al nodo central, para de esta manera, habilitar el acceso remote a los logs de cada nodo del cluster. Así pues la configuración del syslog de cada nodo debe ser modificada:

[root]# vi /etc/sysconfig/syslog Cambiando la siguiente línea:

SYSLOGD_OPTIONS="-m 0"

8.2 CONFIGURACION DHCP INTERFAZ ETH0

El servidor central se ha denominado: ps3head.

Consta de 2 interfaces de red:

1. eth0, dedicado a la red privada con las PS3. IP: 10.10.0.1 subnet mask: 255.255.0.0 2. eth1, intranet del dpto. IP: 172.29.24.76 subnet mask: 255.255.252.0

Actualmente el servidor proporciona el servicio DHCP. Este servicio podrá ser migrado en un futuro a un dispositivo router con firmware Linux y capacidades usb-hdd storage.

El servidor DHCP se configura mediante el fichero nombrado: /etc/dhcpd.conf

El demonio DHCP usa el fichero /var/lib/dhcp/dhcpd.leases para almacenar la base de datos con las IP y datos de red del cliente al cual le ha otorgado una dirección IP válida

Cuando se desea eliminar el fichero de dhcp-leases anterior, se debe usar el comando ^touch

/var/lib/dhcp/dhcpd.leases para crear el fichero antes de re-arrancar el servicio.

El servicio dhcpd se controla con los siguientes comandos

/sbin/service dhcpd start /sbin/service dhcpd stop /sbin/service dhcpd restart

(32)

Como se tiene más de una interfaz de red conectada al sistema, pero sólo se desea que el servidor DHCP arranque en una de las interfaces, se ha de modificar el script init para arrancar solamente en ese dispositivo.

Para ello, se añade el nombre de la interfaz de la lista de ^DHCPDARGSen

/etc/sysconfig/dhcpd:

# Cormnand line options here DHCPDARGS=ethO

Esto es útil si tiene una máquina firewall con dos tarjetas de red. Se puede configurar una tarjeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra tarjeta de red puede utilizarse como servidor DHCP para la red interna detrás del firewall. Su sistema será más seguro si especifica la tarjeta de red conectada a la red interna ya que los usuarios no pueden conectarse al demonio vía Internet.

Si hay algún problema y el servidor da un error en lugar de indicar "done", el archivo /var/lag/messages así como la consola 10 (Ctrl + Alt + FlO) ofrecen más información.

Ejemplo de declaración subnet (subred)

subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.254;

option subnet-mask 255.255.255.0;

option domain-name "example.com";

option domain-name-servers 192.168.1.1;

option time-offset -5; # Eastern Standard Time

range 192.168.1.10 192.168.1.100;

}

8.3 ACTUALIZACION DINAMICA DE NOMBRES DE NODOS PS3

# option definitions common to all supported networks...

# option ntp-servers 192.168.1.1; # Default NTP server to be used by DHCP clients authoritative; #this is the main DHCP server in this LAN

ddns-update-style interim; #do not use ad-hoc mode ddns-updates on; #do the dynamic dns updates

deny client-updates; #specifies that clients could not modify the DNS records by themselves, En los nodos clients se supnm1ra la línea en el fichero /ps3cluster/$clusterroot/etc/sysconfig/network

lulsl

(33)

HOSTNAME= localhost.localdomain (se suprimirá esta línea, para permitir al kernel y al dhcp configurar el hostname automáyticamente)

8.4 ANULACION DHCP INTERFAZ ETH1

El fichero de configuración /etc/dhcpd.conf y el arranque del demonio, permiten habitualmente la selección del interfaz sobre el que se desea realizar una configuración de servicio dhcp

Otra opción, que es la que se ha escogido en nuestro caso particular, es eliminar el puerto de servicio dhcp estandar (67) en el interfaz que se desea (eth1), de manera que se descarten todos los paquetes que entren por dicho puerto.

iptables -t nat iptables -A input iptables --list

iptables -save > ... tail /var/log/messages

8.5 AUTENTICACIÓN SEGURA MEDIANTE SSH

El administrador del cluster necesita tener un control total sobre cada uno de los nodos que lo forman. También, los usuarios del cluster necesitarán ejecutar distintos trabajos y tareas de cálculo en los nodos del cluster de una forma sencilla y simplificada. El protocol y aplicación ssh posibilita todo lo anterior.

Existen diferentes scripts, como gensshkeys el cual crea el par de claves privada/publica con una password vacía para root. También crea una configuración SSH por defecto para que el usuario root pueda abrir conexiones seguras al shell del nodo servidor y a cualquier otro nodo del cluster. Estos ficheros de claves se encuentran en el directorio /root/.ssh.

Se comprueba que el demonio ssh está activado en el servidor, si no fuera así se debe habilitar en el arranque del sistema principal:

ssh /etc/init.d/sshd restart [root]# chkconfig --add sshd [root]# service sshd start Se debe editar

/etc/init.d/sshd.config opcion tcpkeepalive: no netstat -ln

(34)

Copia de claves entre equipos conocidos para una autenticación rápida.

Con el siguiente comando se configura todo para que el sistema no pida nombre de usuario:

ssh-keygen -t dsa -N "" > id_dsa... -- cd .ssh

cat id_dsa.pub > authorized_keys

y además se copiará esta estructura al directorio /ps3cluster/$clusterroot/root/.ssh

8.6 SISTEMA DE FICHEROS EN RED NFS: CONFIGURACIÓN.

Se ha configurado un servidor NFS en la ruta /home/cluster para que todas las PS3 tengan el mismo directorio y cambiando algo en el mismo, lo vean todas ellas a la vez.

Yellow Dog Linux (YDL) 6.1 tiene un kernel linux 2.6.27

Para recompilar, ejecutar "make menuconfig" en /usr/lib/linux/sources... o similar.

Para comprobar qué servicios están incluidos actualmente se puede hacer uso del siguiente comando:

chkconfig => runlevel chkconfig --list nfs chkconfig --list dhcp

Con todo ello, se comprueba si el servicio NFS está activado en el kernel Se rearranca el servicio

/etc/init.d/nfs restart rpcinfo -p

En la consola PS3, se ejecutan los siguientes comandos:

ps3-linux: killall pb-discover ps3-linux: mkdir /local

ps3-linux: mount /dev/ps3da1 /local ps3-linux: mkdir /remote

ps3-linux: mount -o nolock 192.168.1.2:/target /remote ps3-linux: cp -a /local /remote/ps3

ps3-linux: rm -rf /remote/ps3/lost+found

En el servidor, se deben realizar algunos pequeños cambios, importantes para que el servicio arranque y esté preparado para lanzar las peticiones a los nodos PS3.

Con los siguientes commandos se consigue habilitar y arrancar el servicio NFS.

[root]# chkconfig nfs on [root]# service nfs start

El commando exportfs puede ser utilizado para verificar que el sistema de ficheros está exportado via nfs.

[root]# exportfs /usr/local 10.0.0.0/16

(35)

/opt/xcat 10.0.0.0/16 /home 10.0.0.0/16 /install world

Así, se debe editar el fichero /target/ps3/etc/fstab para que se use el fichero raíz NFS, modificando la línea

LABEL=/ / ext3 defaults 1 1 por esta otra

/dev/nfs / rootfs defaults 0 0

Se debe eliminar el fichero de configuración del interfaz eth0, puesto que los scripts de arranque del kernel intentarán reinicializar el interfaz, lo que conllevará la desconexión del sistema de archivos por red, parando el arranque del nodo.

[@host]# rm /target/ps3/etc/sysconfig/network-scripts/ifcfg-eth0 Con la siguiente orden se crea un directorio NFS para los nodos ps3.

[@host]# mknod /ps3cluster/$rootcluster/dev/console c 5 1

Si todo ha ido bien, ahora desde un ordenador remoto se puede montar dicho directorio exportado.

mount -t nfs 172.29.25.70

Para acceder al servidor de forma remota y haciendo uso de un interfaz gráfico X:

ssh -x [email protected]:22

8.7 CONFIGURACION TFTP

En este apartado se describe la configuración del servicio TFTP en el nodo central de manera que todos los nodos tengan el mismo sistema operativo. Se necesita que los demonios tftpd y xinetd estén activos.

En el fichero de configuración xinetd.d/tftp se debe tener la siguiente entrada:

service tftp { disable=no

server_args = -v -s /target

only_from = 192.168.1.0 localhost }

(36)

En este ejemplo, se hace uso de la opción -s en la llamada del servidor tftpd

Para testear el correcto funcionaminento y arranque de los nodos PS3 a partir de la imagen almacenada en el servidor se ha copiado la imagen del kernel existente en una PS3 con el SO Linux instalado en su HDD local.

La localización del servidor tftp se indica en el servicio dhcp, configurada dentro del fichero dhcpd.conf, junto con los nombres del servidor, fichero a proporcionar para el arranque por tftp y directorio dentro del servidor.

Siguiendo el ejemplo anterior, la localización del sistema de arranque sería la siguiente:

'192.168.1.2:/target/ps3/boot/vmlinux'.

[@host]# mkdir -p /target/ps3/boot/

[@host]# scp 192.168.1.50:/boot/vmlinux-2.6.xx /target/ps3/boot/vmlinux

Para testear si este kernel can puede ser descargado, el gestor de arranque mínimo petitboot tiene un comando disponible:

ps3-linux: tftp -g -l test -r /ps3/boot/vmlinux 192.168.1.2

En el servidor se debe realizar las siguientes acciones, para instalar el servicio tftp y para habilitarlo dentro del superdemonio xinetd

yum install tftp

vi /etc/xinetd.d/tftp => opcion disable => poner no (por defecto viene deshabilitado el tftp) añadir la opción "-s /tftpboot" para indicar en la orden de comandos que directamente vaya a ese directorio en el cual tenemos la imagen comprimida de Linux.

8.8 CONFIGURACION WAKE ON LAN

Para tener un arranque rápido de todos los nodos PS3 del cluster, se recurre a configura Wake on LAN en las tarjetas Ethernet de las que dispone cada consola. En este apartado se describe la configuración y puesta en marcha del mismo.

Para ver el estado del servicio Wake-On-Lan:

[@ps3]# ethtool eth0

Para habilitar la opción de Wake-On-Lan en la tarjeta de Ethernet:

[@ps3]# ethtool -s eth0 wol g [@ps3]# ethtool eth0

(37)

Hay varias formas de determinar la dirección MAC de cada nodo PS3.

Esta dirección es necesaria, dado que cada PS3 tiene un identificador de dirección Ethernet MAC único,y debe ser utilizado cuando se envía por red el MagicPacket. Hay que haacceerr uso de dicho valor mediante el comando etherwake.

[@ps3]# ifconfig eth0 | grep HWaddr

La consola debe apagarse con cualquiera de los métodos disponibles en Linux, lo que llevará a la consola a permanecer en modo stand-by, permitiendo que se mantenga la configuración Wake On LAN. Para apaagar el sistema cualquiera de los siguientes métodos es válido.

[@ps3]# shutdown -h now [@ps3]# shutdown

[@ps3]# poweroff

Arranque por red de la consola:

From a remote host on the same subnet as the PS3:

[@host]# etherwake -i ethX aa:bb:cc:dd:ee:ff Siendo:

- ethX el interfaz de red del host que está en la misma subred que los nodos PS3 - aa:bb:cc:dd:ee:ff es la dirección Ethernet MAC del nodo PS3 que se desea activar

8.9 CONFIGURAR SERVICIO DE TIEMPO - NTP

Es importante que todos los nodos del cluster tengan un reloj sincronizado. No immpp orta si no se posee un sistema servidor de tiempo estable y fiablee, pero al menos se debe tener un servidor NTP para que los nodos tengan un tiempo local similar al del resto de nodos.

La mayoría de redes tienen servidores de tiempo disponibles que se pueden usar como fuente de tiempo de los nodos. Para usar este servicio, se puede averiguar el nombre del host o su dirección IP, añadiéndola al fichero /etc/ntp.conf.

restrict hostname mask 255.255.255.0 nomodify notrap noquery server hostname

En nuestro caso, el servidor central se ha configurado para ser el servidor NTP del cluster.

Los siguientes commandos habilitan y arrancan el servicio NTP:

[root]# chkconfig ntpd on [root]# service ntpd start

Para permitir que los nodos cliente se sincronicen con el nodo servidor NTP se debe editar el fichero /etc/ntp.conf:

(38)

restrict 10.0.0.0 mask 255.255.0.0 notrust nomodify notrap restrict 10.1.0.0 mask 255.255.0.0 notrust nomodify notrap restrict 192.168.42.0 mask 255.255.255.0 notrust nomodify notrap

(39)

9 APLICACIONES DESARROLLADAS

En apartados anteriores se han puesto de manifiesto las bondades que puede tener un cluster para abordar distintos problemas que se dan actualmente en el trabajo diario de las fuerzas de seguridad dedicadas a la informática forense.

• Prueba de velocidad y validación de arquitectura base, con la aplicación de estabilización.

• Desarrollo e instalación de las librerias de paralelización SPMD para procesadores CELL mezcla y distribución de las spu, ppu y librerias MPICH.

• Análisis y comprobación de la velocidad de transferencia de datos y de consumo y rendimiento de los procesos

• Herramientas de gestión de spu y cpu evaluación de microkernel de sony para SPU.

• OpenCv librerias de procesamiento de imagen para cell.

• Herramientas de scripting paralelo ClusterIt.

• En desarrollo: implementación paralelo de las herramientas de análisis informático forense Sleuthkit.

9.1 PROGRAMACION DEL PROCESADOR CELL

El procesador Cell está pensado para realizar un procesamiento y cálculos SIMD.

La idea es poder hacer uso de instrucciones vectoriales para realizar un algoritmo o cálculo computacional.

Cada unidad SPU tiene 3 métodos para realizar el almacenamiento de datos locales:

- El espacio de registros de la SPU (la opción más rápida) - La RAM de la SPU (512 KB, pequeña pero muy rápida) - La RAM del sistema (algo más lenta)

Las arquitecturas basadas en x86 tienen 8 registros de 32-bit de propósito general y 8 - 16 MMX/SSE registros vectoriales. Las SPU constan de 128 registros vectoriales.

La plataforma de desarrollo ideal sea un PC con Linux. La Playstation no es que vaya sobrada de RAM - sólo 256MB - escasez de memoria que se hace patente en el momento de trabajar con una interfaz X11. IBM pone a nuestra disposición un SDK (Software Development Kit) libre para la arquitectura Cell [3].

El SDK para Cell es apto para plataformas x86, x86_64 y PowerPC, así como para máquinas Linux basadas en Cell. La última versión (3.1) del SDK para Cell soporta Fedora 9 y Red Hat Enterprise Linux 5.2. El kit incluye las imágenes de CD Developer y Extras, así como un paquete RPM con el script de instalación. Hasta la versión 3.0, el SDK de Cell para Fedora incluía un simulador del sistema, que permitía al desarrollador probar y optimizar sus aplicaciones sin tener que usar hardware Cell físico. Desde la versión 3.1, el simulador se puede obtener por separado desde el sitio web de IBM [4]. La nueva versión 3.1 está aún en fase beta, pero funciona perfectamente bajo Fedora 9. Según IBM, los requisitos mínimos de hardware son un Intel Pentium 4 con una velocidad de reloj de al menos 2GHz o un Socket F AMD Opteron. Además de esto son necesarios 1 GB de RAM y 5 GB de espacio libre en disco.

(40)

Para instalar el SDK para Cell en Linux también se requieren los paquetes rsync, sed, TCL y wget. Debido a que el script de instalación descarga varios paquetes desde el Centro de Supercomputación de Barcelona [5], hace falta una conexión permanente a Internet durante la instalación. El paquete RPM cellinstall3.1.00.0.noarch.rpm crea un directorio /opt/cell para el entorno de desarrollo y su documentación. El script de instalación recibe como parámetro la ruta a las imágenes de CD:

/opt/cell/cellsdk -iso path install

Esta variante tiene la ventaja de que se puede instalar el contenido de ambas imágenes desde un solo proceso. Si las imágenes de CD del SDK para Cell están en CDs, hay que insertar el de Developer y el de Extras uno a uno e iniciar cada instalación de forma separada con /opt/cell/cellsdk install. Si ya hemos instalado el simulador del sistema, podemos inicializarlo con el script /opt/cell/cellsdk_sync_simulator, que instalará ciertos elementos necesarios del SDK. Las ISOs contienen varias librerías que no son de código abierto. Para obtener más documentación acerca de la instalación se puede consultar /opt/cell/sdk/docs/install.

Figura 19. Arquitectura hardware del procesador Cell.

Cada SPE (Synergistic Processing Element) posee una SPU (Synergistic Processing Unit), memoria local (LM) y un MFC (Memory Flow Controller). Un MIC (Memory Interface Controller) se sitúa delante de la memoria principal y un BIC (Bus Interface Controller) delante de la interfaz de Entrada/Salida.

(41)

9.2 SIMULADOR CELL

Con el sistema Cell Full System Simulator de IBM no es necesario el hardware Cell físico.

Antes de poder iniciar el simulador Cell Full System Simulator, se debe guardar la ruta completa del mismo en la variable de entorno SYSTEMSIM_TOP, que por defecto es /opt/ibm/systemsim-cell. El siguiente comando despierta al simulador: /opt/ibm/systemsim- cell/U bin/systemsim -g La opción -g inicia una interfaz gráfica Tcl/ Tk (Figura 6). Para ver los distintos modos que el simulador ofrece, pulsamos el botón Mode. Si lo que queremos es probar una función simple, lo que necesitamos es Fast Mode. Al pulsar sobre Go iniciamos el simulador. Desde este momento, la ventana de consola comienza a mostrar cómo el sistema operativo arranca en la máquina Cell simulada. Para cargar el programa que deseamos ejecutar en el simulador se usa el comando callthru. Ejecutándolo sin argumentos, sólo muestra un texto de ayuda. Para importar un archivo ejecutable desde la ruta /tmp/pi_libspe de la máquina física, usamos el comando: callthru source U /tmp/pi_libspe > pi_libspe

Figura 20. Con el sistema Cell Full System Simulator de IBM no es necesario el hardware Cell físico.

(42)

9.3 INSTALACION DE SLEUUTH KIT - APLICACIONES FORENSES

Figura 21. Sleuthkit instalado en el servidor y cluster PS3.

9.4 INTERFAZ AUTOPSY

El navegador Autopsy forense es una interfaz gráfica del set de herramientas disponibles en línea de comandos para el análisis de pericias informáticas forenses. El kit autopsy-Sleuth. Kit permiten investigar el sistema de archivos y volúmennes de datos de los que consta un ordenador incautado. Soporta sistemas de archivos NTFS, FAT, UFS1 / 2, Ext2 / 3, etc.

A continuación se enumeran las distintas Técnicas de Búsqueda de Evidencias que se pueden hacer uso con el sleuth-kit y autopsy.

LListado de archivos: Analizar los archivos y directorios, incluidos los nommbb

aarrchivos eliminados y archivos con nombres basados en Unicode. res de los Contenido de los archivos: El contenido de los archivos se puede ver en binario

directamente, hexadecimmaa ll, o en ASCII.

BBases de datos Hash: Búsqueda de archivos desconocidos en una base de datos de hash para identificar rááppidamente si son buenas o malas. Autopsy utiliza el NIST Biblioteca Nacional de Software (NSRL), creado por múltiples usuarios a partir de bases de datos de archivos bien reconocidos.

Clasificación del tipo de aarchivo: Ordena los archivos en función de su firma interna para identificar los archivos de un tipo conocido.

Cronología de la Actividaad de archivos: En algunos casos, con una línea de tiempo de la aactividad del archivo pueede ayudar a identificar las áreas de un sistema de archivos que pueden contener eleementos de prueba

Búsqueda de palabra claavve: Búsquedas por palabras clave del archivo imagen del sistema se puede realizar usando cadenas ASCII y expresiones regulares grep.

(43)

AAnálisis de MetaDatos: estructuras de meta datos que contienen los detalleess acerca de los archivos y directorios. Autopsy permite ver los detalles de cualquier estructura de datos de metadatos en el sistema de archivos.

Asimismo, con autopsy se tiene una completa herramienta con interfaz web estándar para el manejo de casos, secuenciador de eventos, introducción de notas rápidas y comenntarios por cada investigador, respetando la integridad de la imagen forense, generación de informes, etc. Autopsy está escrito en Perl y funciona en las mismas plataformas que Sleuth Kit.

9.5 UUDD P-CAST

UDPcast es una herramienta de transferencia de archivos que puede enviar datos simultáneamente a los múltiples nodos del cluster dado que estos se encuentran conectados mediante una LAN Gigabit Ethernet. La ventaja de UDPcaast con respecto a otros métodos (NFS, FTP, etc.) es que UDPcast utiliza las capacidades de multidifusión de Ethernet: por lo que el envío múltiple de información no tomará más tiempo para enviar a los N nodos toda la informacción que se desee.

UDPcast se puede iniciar en un sistema YDL 6.1 desde la línea de comandos, aunque también existe una utilidad gráfica.

En el servidor se arranca el servicio de emisión que espera para las conexiones desde los distintos receptores.

udp-sender -nokbd -f OUTFILE