Análisis de performance y optimización en Clusters Beowulf

Universidad de Buenos Aires
Facultad de Ciencias Exactas y Naturales
Departamento de Computación
Análisis de performance y
optimización en Clusters Beowulf
por
Marı́a Carolina León Carri
{[email protected]}
Director: Dr. Ing. Guillermo Marshall
{[email protected]}
Codirector: Dr. Ing. Carlos Garcı́a Garino
{[email protected]}
Tesis para optar al grado de
Licenciada en Ciencias de la Computación
Agosto 2004
Índice general
1. Introducción
8
2. Conceptos Básicos
2.1. Tecnologı́a de redes . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Tecnologı́a Ethernet . . . . . . . . . . . . . . . . .
2.1.2. Protocolo IP, Internet Protocol (MTU) . . . . . . .
2.1.3. Protocolo TCP, Transmission Control Protocol . . .
2.1.4. Ancho de Banda, Latencia y RTT . . . . . . . . . .
2.1.5. Bonding . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Arquitectura del nodo . . . . . . . . . . . . . . . . . . . .
2.3. Implementación de Gigabit Ethernet en clusters de PC . .
2.4. Sistema de archivos . . . . . . . . . . . . . . . . . . . . . .
2.4.1. Sistema de archivo local - ext3 . . . . . . . . . . . .
2.4.2. Network File System - NFS . . . . . . . . . . . . .
2.4.3. Parallel Virtual File System - PVFS . . . . . . . .
2.4.4. Mosix File System con Direct File System Access
MFS con DFSA . . . . . . . . . . . . . . . . . . . .
2.4.5. Global File System - GFS . . . . . . . . . . . . . .
2.5. Administración de Procesos . . . . . . . . . . . . . . . . .
2.5.1. Portable Batch System - PBS . . . . . . . . . . . .
2.5.2. MAUI Scheduler . . . . . . . . . . . . . . . . . . .
2.5.3. Interacción entre PBS y MAUI . . . . . . . . . . .
2.6. Herramientas de programación . . . . . . . . . . . . . . . .
2.6.1. MPICH . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2. ROMIO . . . . . . . . . . . . . . . . . . . . . . . .
3. Experimentos y optimización
3.1. Performance de Red . . . . . . . . . . . . . . . . . .
3.1.1. Mediciones de Throughput de TCP . . . . . .
3.1.2. Mediciones de Throughput de MPICH . . . .
3.1.3. Influencia del tamaño de las ventanas de TCP
3.1.4. Comparación entre diferentes clusters . . . . .
3.2. Performance de Sistemas de Archivos . . . . . . . . .
3.2.1. Benchmark Bonnie . . . . . . . . . . . . . . .
3.2.2. Benchmark Babieca . . . . . . . . . . . . . . .
3.2.3. MPI I/O: perf y coll perf de ROMIO . . . . .
3.3. Throughput de Procesos . . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
11
11
12
12
13
14
15
16
16
18
.
.
.
.
.
.
.
.
.
22
22
22
23
24
24
25
25
26
.
.
.
.
.
.
.
.
.
.
28
28
28
32
33
33
35
36
38
41
46
4. Conclusiones y lı́neas futuras
49
4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2. Lı́neas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A. Clusters Utilizados
A.1. Cluster Speedy González
A.1.1. Hardware . . . .
A.1.2. Software . . . . .
A.2. Cluster Meteoro . . . . .
A.2.1. Hardware . . . .
A.2.2. Software . . . . .
A.3. Cluster Mercurio . . . .
A.3.1. Hardware . . . .
A.3.2. Software . . . . .
.
.
.
.
.
.
.
.
.
B. Descripción de Benchmarks
B.1. Red . . . . . . . . . . . .
B.1.1. NetPIPE . . . . . .
B.2. Sistema de archivos . . . .
B.2.1. Babieca . . . . . .
B.2.2. Bonnie . . . . . . .
B.2.3. perf y coll perf . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
52
52
55
55
56
56
56
56
.
.
.
.
.
.
57
57
57
57
57
58
59
C. Configuración TCP en Linux
60
Bibliografı́a
62
2
Índice de figuras
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
Envı́o de mensajes [21] . . . . . . . . . . . . . . . . . . . . . .
Recepción de mensajes [21] . . . . . . . . . . . . . . . . . . . .
Estructura de capas de NFS [14] . . . . . . . . . . . . . . . . .
Diagrama del sistema PVFS [17]. . . . . . . . . . . . . . . . .
Flujo de metadata y datos en PVFS [17]. . . . . . . . . . . . .
Flujo de datos a través del kernel [17]. . . . . . . . . . . . . .
Ejemplo de distribución de un archivo en una partición PVFS [16]
Ejemplos de particiones Lógicas PVFS [16] . . . . . . . . . . .
Interacción entre PBS y MAUI . . . . . . . . . . . . . . . . .
13
14
17
19
20
20
21
22
25
3.1. Throughput de Speedy para tamaño de buffers default de sockets TCP. Referencias: (F)ast, (E)thernet, (B)onding, M(PICH),
(G)igabit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Gráfico de Saturación Ethernet del cluster Speedy. . . . . . . . . 31
3.3. Gráfico de Firma Ethernet del cluster Speedy. . . . . . . . . . . . 31
3.4. Throughput de red para distintos tamaños de ventanas de congestión TCP (A) MTU=1500, (B) MTU=3000 y (C) MTU=9000.
34
3.5. Comparación del throughput entre los clusters Meteoro, Mercurio
y Speedy. Referencias: (F)ast, (E)thernet, (B)onding, M(PICH),
(G)igabit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6. Throughput de accesos al sistema de archivos. Benchmark Bonnie. 37
3.7. Cantidad de búsquedas por segundo. Benchmark Bonnie. . . . . . 38
3.8. Performance de sistemas de archivos ext3, NFS, PVFS. Comandos
de lectura Unix. Benchmark Babieca. . . . . . . . . . . . . . . . 39
3.9. Performance de sistemas de archivos ext3, NFS, PVFS. Comandos
de lectura/escritura Unix. Benchmark Babieca. . . . . . . . . . . 40
3.10. Distribución fı́sica del archivo generado por perf para la ejecución
con 4 nodos de tamaño 4 MB por nodo, en la partición PVFS
(base=1, pcount=15 y ssize=64 KB). Programa perf de ROMIO. . 41
3.11. Throughput de escrituras/lecturas. (A) sin la función MPI File sync(),
(B) con dicha función. Programa perf de ROMIO. . . . . . . . . 42
3.12. Throughput de (A) escrituras y (B) lecturas SIN la función MPI File sync().
Programa perf de ROMIO. . . . . . . . . . . . . . . . . . . . . 43
3.13. Throughput de (A) escrituras y (B) lecturas CON la función MPI File sync().
Programa perf de ROMIO. . . . . . . . . . . . . . . . . . . . . 44
3.14. Throughput de Funciones Colectivas de lectura/escritura. Programa coll perf de ROMIO para cubos de 2563 . . . . . . . . . . . . . 45
3.15. Porcentaje de cantidad de trabajos por tiempo de duración. . . . . 46
3.16. Corridas homogéneas vs. heterogéneas. . . . . . . . . . . . . . . . 47
3
A.1. Topologı́a del Cluster Speedy. . . . . . . . . . . . . . . . . . . . 54
4
Índice de cuadros
2.1. Caracterı́sticas del throughput nominal del Bus PCI/PCI-X [41]. . 15
3.1. Throughput de accesos al sistema de archivos. Las búsquedas aleatorias están dadas en cantidad de búsquedas por segundo. Benchmark
Bonnie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.
A.2.
A.3.
A.4.
A.5.
Caracterı́sticas
Caracterı́sticas
Caracterı́sticas
Caracterı́sticas
Caracterı́sticas
del hardware de Speedy. . . . .
de los discos de Speedy. . . . .
de las placas de red 3c2000 [43].
del hardware de Meteoro. . . .
del hardware Cluster Mercurio.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
53
55
56
C.1. Configuración TCP en linux. . . . . . . . . . . . . . . . . . . . 61
5
Resumen
En la última década la computación paralela tuvo un gran resurgimiento
gracias a los sistemas tipo Beowulf, cluster de PCs conectadas entre sı́ para
formar una supercomputadora.
El objetivo de este trabajo es presentar un estudio de la performance y
optimización de clusters Beowulf a través del análisis de la compleja relación
existente entre la tecnologı́a de red, la arquitectura del nodo, los sistemas de
archivos, las herramientas de programación y la administración de procesos.
En relación a la tecnologı́a de red y a la arquitectura del nodo, se muestra
que para obtener la máxima performance de Gigabit Ethernet es fundamental
analizar cuidadosamente los elementos subyacentes. El máximo ’throughput’
alcanzable depende fuertemente del bus PCI (Peripheral Component Interconnect) del nodo, de la velocidad del procesador, sus técnicas de ’caching’,
de las caracterı́sticas de la placa de red (capacidad de realizar ’checksums’
y segmentación de paquetes TCP, disponibilidad de un bus PCI dedicado) y
del ’tuning’ de los parámetros TCP.
En relación al sistema de archivos, se muestra que PVFS (Parallel Virtual
File System) resulta la opción más apropiada para utilizar el espacio en disco
distribuido entre los nodos del cluster y para optimizar el uso del mismo en
programas paralelos.
En relación a las herramientas de programación, se prueba que las funciones de operaciones de entrada/salida, MPI I/O (ROMIO), son las que
acceden en forma más eficiente a las áreas de disco global.
Finalmente, con respecto a la administración de procesos se sugiere, entre otras polı́ticas, la implementación de ’checkpointing’ para aumentar el
’throughput’ total de procesos.
En sı́ntesis, éste trabajo pretende mostrar la importancia que tiene para
el logro de una performance óptima de un cluster Beowulf, la elección de
la tecnologı́a de red, la arquitectura del nodo, el sistema de archivos, el administrador de procesos y las herramientas de programación. Un correcto
balance de estos ingredientes permite obtener una notable mejora en el uso
de los recursos facilitando el objetivo fundamental de la computación paralela
que es permitir resolver problemas más grandes en menor tiempo.
6
Agradecimientos
Quisiera dedicar este trabajo especialmente a mis padres Graciela y Juan,
a mis abuelos La Baby y Marcelo, a mi hermana Marı́a y a Rodo. Ellos fueron
las principales personas que me impulsaron y apoyaron cuando decidı́ seguir
esta carrera y siempre estuvieron presentes durante el transcurso de ella.
En los años de estudiante fueron muchos los que participaron de la ’lucha’
por el tı́tulo. Ellos recordarán bien las horas sin dormir que compartimos en
tiempos de entregas de trabajos prácticos, parciales y finales. Podrı́a nombrarlos a todos aquı́ pero no quisiera arriesgarme a olvidar a uno sólo de
ellos.
Y fuera del ambiente universitario los amigos y compañeros de trabajo
fueron la compañı́a ideal para los tiempos de ocio y lamentos.
Y ahora sı́ voy a nombrar a los responsables más directos sobre la realización de este trabajo. A los que lo leyeron una y otra vez para sacarle el
jugo, a los que me explicaron pequeñas pero muy valiosas dudas que me iban
surgiendo, a los que soportaron la desesperación por terminar... Ellos son
especialmente dos grupos, la gente del laboratorio de Sistemas Complejos:
Silvina, Esteban, Graciela, Pablo(s), Ernesto, Diego, Guillermo y Carlos. Y
los del trabajo: Isa, Diego, Jorge y Luis.
7
Capı́tulo 1
Introducción
Los clusters de computadoras se crearon con el objetivo de resolver problemas complejos en forma más económica que los supercomputadores. Están
compuestos por un conjunto de PCs interconectados por una red local. Poseen
software funcional y hardware que permiten que el cluster sea visto y administrado como un sistema único. Los clusters pueden ser agrupados según su
funcionalidad en tres grupos [12]:
servidor aplicaciones administrador central de recursos dedicados a iniciar tareas
alta disponibilidad conjunto de máquinas que garantizan redundancia y
tolerancia a fallas
alta performance sistemas que trabajan en conjunto para solucionar un
problema
Los clusters Beowulf pertenecen al último grupo. Su denominación surgió en la NASA por el investigador Donald Becker quien buscó desarrollar un
recurso de supercómputo sin tener que utilizar una supercomputadora. Interconectó un conjunto de máquinas mediante un switch y logró su objetivo,
un recurso para implementar la computación paralela de alta performance
(High Performance Computing - HPC). Es importante que las computadoras
paralelas de alta performance cumplan esta caracterı́stica, sin embargo no se
espera de ellas que sean confiables. Esto significa que debe realizar los cálculos en forma eficiente y rápida pero que una falla ocasional se tolera y puede
ser superada con solo reinicializar la corrida del problema. Además deben
cumplir con la relación costo/beneficio, se desea obtener alta performance a
bajo costo.
En este trabajo, se analizarán los puntos a tener en cuenta si se quiere
poner en funcionamiento un cluster de alta performance. Las pruebas se
realizarán en el cluster Beowulf Speedy Gonzalez del Laboratorio de Sistemas
Complejos del Departamento de Computación, UBA. Se utilizará software
libre y gratuito. Los recursos a utilizar son:
sistema operativo Linux, Mandrake 9.2 [19]
benchmark de red NetPIPE descripto en el Apéndice B.1.1 que permite el análisis de la capacidad de la red interna que interconecta las
máquinas del cluster
8
sistema de archivos, organización de los discos distribuidos en todas
las máquinas que componen el cluster, NFS y PVFS descriptos en el
Capı́tulo 2.4
sistema de administración de procesos, PBS y MAUI descriptos en el
Capı́tulo 2.5
monitoreo del sistema (uso de memoria, CPU, discos, etc.)
herramientas de programación paralela basadas en pasaje de mensajes,
MPICH (Message Passing Interface) y ROMIO descriptas en el Capı́tulo 2.6.
Además, se llevaran a cabo pruebas en dos clusters externos al laboratorio
descriptos en el Apéndice A que permitirán comparar a Speedy con tecnologı́as más modernas.
9
Capı́tulo 2
Conceptos Básicos
2.1.
Tecnologı́a de redes
La eficiencia de un cluster de alta performance depende en gran parte
de la tecnologı́a utilizada para interconectar sus nodos. Esto se debe a que
los programas paralelos utilizan intercambio de mensajes entre los nodos
involucrados en la resolución de un problema. En esta sección se describirán
algunos aspectos teóricos necesarios a tener en cuenta durante el desarrollo
del trabajo.
2.1.1.
Tecnologı́a Ethernet
Redes Compartidas En un principio bastó con poder conectar los nodos
del cluster mediante una red compartida. Cada nodo con su placa de
red ethernet de 10 Mbps, se conectaba con los demás mediante un hub
a través de cables de cobre de par trenzado según norma de transmisión
10BaseT (10 Mbps). La tecnologı́a Ethernet es un bus broadcast que
transmite paquetes a 10 Mbps. Es un bus porque todas las máquinas
comparten el mismo canal de comunicación, y es broadcast porque todas
las máquinas reciben todas las transmisiones [14]. El modo de transmisión es half duplex.
El mecanismo de acceso al medio en Ethernet es CSMA/CD (Carrier
Sense Multiple Access/Collision Detection). Consiste en que cada nodo
se fija si el bus está libre, si es ası́ envı́a su paquete. Puede ocurrir que
otro nodo haya visto el bus libre al mismo tiempo y haya enviado un
paquete, esto generará una colisión de paquetes que podrá ser detectada
por el transmisor teniendo que reenviar el mensaje luego de un intervalo
de tiempo.
Esta opción presenta la desventaja de que el medio de transmisión de
mensajes es muy lento y con posibles colisiones. Además a medida que
se agregan nodos al cluster estos problemas se producen con mayor
frecuencia y es posible que la red se sature.
Redes Conmutadas Actualmente las computadoras son más potentes y
necesitan un medio de conexión más veloz para alcanzar los niveles de
alta performance deseados. En las redes conmutadas se reemplazó el
10
hub por el switch. En un principio, los conmutadores tenı́an una velocidad de transferencia de 100 Mbps, actualmente han evolucionado
hasta alcanzar 1000 Mbps y más. Esta opción requiere que cada nodo
posea una placa de red fast ethernet (100 Mbps, norma 100BaseT) o
gigabit ethernet (1000 Mbps), dependiendo de la capacidad del switch,
conectadas por un cable de par trenzado. Dicho cable posee 4 pares
de hilos, en Ethernet y Fast Ethernet sólo se empleaban 2 pares, en el
caso de Gigabit se utilizan los 4 pares. Para Gigabit se necesita como
mı́nimo cables de categorı́a 5e y preferentemente categorı́a 6.
En las redes conmutadas cuando un nodo transmite un mensaje a través
del switch hacia otro nodo, es el switch quien se encarga de enviar el
mensaje a la placa del nodo destino. Utiliza el protocolo Ethernet en
modalidad full duplex, con envı́o y recepción de paquetes en forma
simultánea. La transmisión entre la estación y el switch es punto a
punto, el mecanismo CSMA/CD ya no tiene sentido, se emplea un
par de hilos para transmisión de datos y otro para recepción en forma
simultánea. No requiere estar escuchando permanentemente en el bus
como en el primer caso.
2.1.2.
Protocolo IP, Internet Protocol (MTU)
El protocolo estándar TCP/IP define al datagrama IP como la unidad de
información enviada a través de la red y provee las bases para la distribución
de paquetes. El MTU, Maximum Transfer Unit, es el tamaño de paquete más
grande que puede ser transferido a través de una red fı́sica. En teorı́a, puede
ser de hasta 64 Kbytes, pero en la práctica está determinado por el hardware
de red. Actualmente el estándar de los dispositivos para interconectar redes
(switches, routers, etc.) es de 1500 bytes, pero algunas placas de red gigabit
permiten configurar el MTU de hasta 9000 bytes logrando ası́ incrementar
el throughput. Se debe tener en cuenta que si el MTU es muy pequeño, la
máquina estará respondiendo seguido mientras que si es muy grande puede
haber errores y los paquetes tendrı́an que ser retransmitidos.
2.1.3.
Protocolo TCP, Transmission Control Protocol
TCP es un protocolo confiable pues garantiza que los datos llegarán a
destino y orientado a conexión pues simula un túnel entre el emisor y el
receptor. Básicamente una conexión TCP consta de las siguientes partes:
emisor con un buffer para el envı́o de mensajes cuyo tamaño está dado en
bytes
receptor con un buffer para la recepción de mensajes cuyo tamaño está dado
en bytes y puede ser diferente al anterior
Dichos buffers, también llamados ventana de congestión, cambian de tamaño
dinámicamente en el transcurso de una conexión TCP controlando ası́ el flujo
de datos.
El protocolo TCP provee confiabilidad debido al uso de paquetes de acknowledge (ACK), estos paquetes son enviados por el receptor para confirmar
11
que se ha recibido un paquete determinado. Si el emisor no recibe el ACK
en un determinado transcurso de tiempo, reenvı́a el paquete. Si recibe el
ACK continúa enviando paquetes. El tamaño de la ventana de congestión
del emisor indicará cuantos paquetes puede enviar el mismo mientras que
espera el ACK de cada uno de ellos. El tamaño de la ventana del receptor
estará condicionado por la rapidez que el mismo tenga para enviar el ACK
del paquete recibido y liberar espacio en el buffer.
La performance depende del tamaño de las ventana y de la velocidad en
que la red transmita los paquetes. Incrementando el tamaño de la ventana
es posible reducir por completo los momentos ociosos de la red. Una buena
configuración del tamaño de la ventana deslizante, mantiene a la red completamente saturada de paquetes, obteniendo un mejor throughput. Luego, el
máximo throughput está condicionado por el tamaño de ambos buffers. La
siguiente fórmula permite calcular el máximo ancho de banda dado el tamaño
del buffer emisor y el tiempo de respuesta del enlace:
buffer de envı́o
ancho de banda = tamaño delRTT
El ancho de banda, la latencia y el RTT serán explicados en la próxima
sección. Por la misma fórmula, sabiendo el ancho de banda teórico de la red
y el RTT podemos calcular el tamaño óptimo de la ventana de congestión
para lograr un buen throughput.
2.1.4.
Ancho de Banda, Latencia y RTT
La performance de la red se mide preferentemente en bits por segundo
’bps’. Sus caracterı́sticas están dadas por el ancho de banda y la latencia.
El ancho de banda indica la cantidad de datos que pueden ser transferidos a
través de un enlace por unidad de tiempo. La latencia es el tiempo necesario
para transferir un dato desde un origen al destino, generalmente se refiere a
las demoras debidas al procesamiento del dato de red. El tiempo de ida y
vuelta se denomina Round Trip Time (RTT).
El ancho de banda y la latencia están relacionados. Mientras que el máximo ancho de banda teórico es fijo (dado por el hardware de red utilizado), el
ancho de banda real se ve afectado por la latencia de la red, es decir por el
tiempo mı́nimo necesario para transferir un paquete de dato desde un punto
a otro. Mucha latencia en un corto perı́odo de tiempo puede causar cuellos
de botella que no permiten llenar el enlace, por lo tanto decrece el ancho de
banda. También se ve afectado por el overhead del hardware y del sistema
operativo. El ancho de banda práctico lo llamamos throughput. La percepción
de la velocidad de la red es una sı́ntesis de estas dos unidades de medida.
2.1.5.
Bonding
Linux permite instalar dos o más placas de red por nodo con el fin de
obtener un mayor throughput balanceando la carga entre ellas. Esta configuración se denomina bonding, es totalmente transparente para el usuario y
los procesos. Por ejemplo, si se instalan dos placas de red Fast Ethernet por
nodo y se conectan ambas placas al switch se podrı́a obtener un throughput
12
aproximado del 85 % de la suma de la capacidad de ambas placas. Se debe
tener en cuenta que se requiere un switch con el doble de cantidad de bocas
que el número de máquinas a conectar.
El bonding es un driver que es parte del sistema operativo linux. Permite
definir una polı́tica para el balance de carga entre las dos placas, por ejemplo
Round-Robin (envı́a en forma circular un paquete a cada placa disponible).
Es una buena opción para lograr mayor performance de red a bajo costo.
2.2.
Arquitectura del nodo
A grandes rasgos, el camino seguido en una transferencia de datos a través
de una red implica tres cargas en memoria. Del lado del receptor, el adaptador
de red accede directamente a memoria (DMA, Direct Memory Access) para
cargar los datos en el buffer receptor, el CPU lee los datos de dicho buffer y
los escribe al de la aplicación. En una transmisión se realiza el paso inverso.
Las cargas en memoria dependerán de la aplicación que esté siendo utilizada,
tamaños de buffers y el comportamiento de la cache.
El tráfico total de memoria, lecturas/escrituras, es a través del Front
Side Bus - FSB. La Figura 2.1 muestra el tráfico de memoria durante la
transmisión de un mensaje. La Figura 2.2 muestra el tráfico de memoria
durante la recepción de un mensaje.
Envı́o de mensajes. 1. El CPU lee el buffer de la aplicación
2. El CPU escribe los datos al buffer del socket
3. La placa de red (NIC) accede directamente a memoria y lee el
buffer del socket
Figura 2.1: Envı́o de mensajes [21]
Recepción de mensajes. 1. La placa de red (NIC) accede directamente
a memoria y escribe el buffer del socket
2. El CPU lee el buffer del socket
3. El CPU escribe los datos al buffer de la aplicación
13
Figura 2.2: Recepción de mensajes [21]
2.3.
Implementación de Gigabit Ethernet en
clusters de PC
Dado un cluster de PCs interconectado mediante placas de red y switch
Fast Ethernet que presenta buena performance de comunicación, no es trivial
migrar su medio de conexión a Gigabit Ethernet. No se obtiene con facilidad
un aumento de rendimiento utilizando placas de red y switch Gigabit Ethernet. Esto se debe en gran parte a la arquitectura del bus PCI (Peripheral
Component Interconnect) que poseen los motherboards que en general se encuentran en uso y que poseen placas de red fast ethernet. Otra posible fuente
de dificultad son los potenciales cuellos de botella asociados a la gestión del
FSB [31] como ası́ también la configuración de los parámetros TCP/IP.
El bus PCI es compartido entre varios dispositivos, por su naturaleza paralela. Aquellos dispositivos que se encuentren conectados al bus harán uso
del mismo rotando cı́clicamente. No solo comparten el bus sino que la frecuencia quedará definida en base al dispositivo de menor frecuencia, disminuyendo
ası́ la performance de los dispositivos más rápidos [41]. Por ejemplo, el bus
PCI está compartido por el CPU, la memoria, la placa de video, las placas
de red, etc.
En particular, las placas de red negocian la velocidad con el bus PCI. Para
una placa con un bus PCI 32 bits/33 Mhz, ver Cuadro 2.1, se observa que
nominalmente soporta 1 Gbps, pero no es recomendable. En el caso del cluster
Speedy, éste posee motherboards PC-Chip M810 con PCI 2.2 y placas de red
3Com 3c2000 que negocian a 32-bit/66 MHz, alcanzando un ancho de banda
teórico de 2 Gbps. Existe una arquitectura más moderna para bus PCI [41]
que consiste en no compartir el bus con muchos dispositivos a través de un
bridge PCI, sino que se conectan directamente con el Memory I/O Control,
MIOC alcanzando ası́ mayor throughput para las placas Gigabit. Este es el
caso del Cluster Mercurio, ver Apéndice A.3.
No solo el bus PCI puede ser responsable de los inconvenientes para alcanzar el throughput que ofrece gigabit ethernet, las ineficiencias del sistema
pueden ocurrir en varios niveles entre la capa de aplicación y el hardware.
14
Cuadro 2.1: Caracterı́sticas del throughput nominal del Bus PCI/PCI-X [41].
Se puede perder hasta el 50 % en la capa de pasaje de mensajes. El sistema operativo y los drivers usualmente aumentan la latencia y disminuyen
el ancho de banda debido a que realizan muchas copias de dato memoria a
memoria al empaquetar los datos para su transmisión. Estos movimientos
extras de datos saturan el bus de memoria, tı́picamente antes de saturar el
bus PCI [31]. Por otro lado, también se debe tener en cuenta que los sistemas
operativos actualmente calculan los parámetros TCP/IP suponiendo el uso
de placas fast ethernet. Con lo cual, se deben configurar los parámetros por
defecto de las ventanas TCP/IP como ası́ también los buffers para pasaje de
mensajes de MPICH.
2.4.
Sistema de archivos
Dada la arquitectura, diseño y composición del hardware de Speedy se
tiene la necesidad de utilizar la capacidad de disco de cada uno de los nodos en
forma global. Se quiere aplicar un sistema de archivos que soporte el acceso
a los mismos en forma paralela. Cada sistema de archivos será evaluado
con respecto a su velocidad de acceso de entrada/salida y su escalabilidad.
También se tendrá en cuenta el tipo de aplicaciones que se quiere ejecutar en
el cluster Speedy, aquellas con gran cantidad de operaciones de entrada/salida
y las que tienen poca cantidad de operaciones de entrada/salida
Se evaluarán los siguientes sistemas de archivos:
local (ext3) tipo de fichero utilizado en Linux
NFS - Network File System
PVFS - Parallel Virtual File System
MFS - Mosisx File System
GFS - Global File System
La Figura 2.3 ilustra cómo están embebidos los distintos sistemas de
archivos con el sistema operativo (SO). Cuando se ejecuta una operación
ésta llama al SO para abrir, cargar o tomar los datos de un archivo. El
mecanismo de acceso a un archivo acepta el pedido automáticamente lo pasa
al software de su sistema de archivos local, al cliente NFS, al cliente PVFS
15
o al que corresponda dependiendo si el archivo está en el disco local, en una
máquina remota o en varias.
Cuando recibe un pedido, el software del cliente utiliza el protocolo correspondiente para conectarse al/los servidor/es remotos apropiados y lleva a
cabo la operación requerida. Cuando el servidor remoto contesta, el software
del cliente devuelve los resultados a la aplicación que inicio el pedido.
2.4.1.
Sistema de archivo local - ext3
El tipo de fichero local ext3 [24], utilizado actualmente en Linux, posee la
ventaja de tener journaling (registros de eventos periódicos), esto garantiza
disponibilidad e integridad de los datos y velocidad de acceso.
disponibilidad pues luego de una caı́da del sistema inesperada ext3 no
requiere un chequeo total del sistema de archivos gracias al journal.
integridad garantiza integridad de los datos luego de una caı́da abrupta del
sistema.
velocidad a pesar de escribir los datos mas de una vez, es más rápido que
ext2, su predecesor, pues el journaling optimiza el movimiento de las
cabezas del disco.
Posee distintas opciones de journal : registrar periódicamente todos los
archivos y los metadata, o bien, registrar sólo los metadata. En el último
caso se puede optar por escribir los datos en el sistema de archivos antes que
el metadata lo que garantiza que todos los metadata apunten a datos válidos
o escribir el metadata antes que el dato en este caso el sistema de archivos
será consistente pero luego de una caı́da del sistema podrı́an aparecer datos
viejos. Esto permite al administrador decidir si se quiere mayor rapidez o
mayor consistencia de datos.
2.4.2.
Network File System - NFS
NFS es un protocolo desarrollado por Sun Microsystems, Incorporated.
Permite que un conjunto de máquinas accedan a sistemas de archivos remotos
en forma transparente.
Cuando un cliente monta un sistema de archivos, el servidor de NFS le
devuelve un file handle (FH) que contiene el tipo de archivo, el disco, el
i-nodo e información de seguridad. La implementación de NFS, ver Figura
2.3 [14], independiente del protocolo, consiste en tres capas. La primer capa de
llamadas al SO (OPEN, READ, CLOSE) luego de examinar el pedido invoca
a la segunda capa, el sistema de archivos virtual (VFS). Ésta se encarga de
mantener una tabla con una entrada por archivo abierto llamado v-nodo. Si
el archivo es local, la entrada contendrá un i-nodo y la tercer capa será la que
manipula archivos locales y si el archivo es remoto, la tercer capa estará a
cargo del cliente NFS. Analizaremos las llamadas al sistema: MOUNT, OPEN
y READ.
16
Figura 2.3: Estructura de capas de NFS [14]
MOUNT Para montar un fichero remoto se utiliza el comando mount, se
especifica el directorio remoto y el directorio local donde será montado, entre otra información. El programa mount analiza el nombre del
directorio remoto, descubre la máquina a la cual pertenece, la contacta
y le pide el FH. Si el directorio existe y está disponible para su acceso
remoto, el servidor le da el FH. Finalmente, el programa realiza una llamada al sistema MOUNT y le pasa el FH al kernel. El kernel construye
el v-nodo y le pide al cliente NFS que cree el r-nodo (i-nodo remoto) en
su tabla interna para guardar el FH. Luego el v-nodo apunta al r-nodo.
Cada v-nodo de la capa VFS contendrá un puntero o un r-nodo en el
código del cliente NFS o bien, un puntero a un i-nodo del SO local.
Luego desde la capa VFS se puede saber si el directorio o archivo es
remoto o local y si es remoto, se puede encontrar el FH.
OPEN Durante la examinación del ’path’ del archivo, el kernel descubre
que el directorio en el cual está montado el fichero es remoto. Busca en
la tabla de v-nodos el puntero al r-nodo. Luego pide al cliente NFS que
abra el archivo. El cliente NFS busca el resto del ’path’ en el servidor
remoto asociado con el directorio montado y devuelve el FH. Crea un
r-nodo para el archivo remoto en sus tablas y reporta a la capa VFS,
la cual pone en sus tablas el v-nodo que tendrá un puntero al r-nodo.
Entonces vemos que todo archivo o directorio abierto tiene un v-nodo
que apunta a un r-nodo o i-nodo.
Notemos que el que guarda la información del FH es el cliente, el servidor no guarda ningún tipo de información sobre el archivo. El servidor
provee los FH ante un pedido, pero no lleva ningún registro de los
FH entregados. Cuando un cliente le envı́a un FH para acceder a un
archivo, el servidor verifica que el mismo exista y lo usa.
READ Cuando el FH es utilizado en llamadas posteriores al sistema, por
ejemplo para una lectura, la capa VFS localiza el v-nodo correspondiente y a partir de el determinara si es local o remoto y también que
i-nodo o r-nodo lo describe.
17
Se utilizan distintas técnicas para mejorar la eficiencia del protocolo. Las
transferencias entre el cliente y el servidor se realizan en bloques de 4096
bytes, incluso en el caso en que se pidan menos bytes. Una vez que el cliente
recibe el bloque de 4 KB, pide el siguiente, este procedimiento se llama look
ahead e incrementa la performance de NFS. Para las escrituras se procede
del mismo modo, sólo se envı́a la escritura al servidor cuando el cliente junta
un bloque de 4 KB. Se recomienda elevar el tamaño del bloque a 8192 bytes
para lograr mayor performance.
Otra técnica utilizada para mejorar la performance es el uso de cache, los
servidores guardan datos en cache para evitar accesos al disco. Los clientes,
mantienen dos caches, una para los atributos del archivo (i-nodos) y otra para
los datos. Cuando se necesita un i-nodo o un bloque de archivo, se verifica
primero si está en cache, si es ası́ se evita el tráfico de red.
Mientras que la cache en el cliente ayuda a mejorar la performance, introduce problemas de consistencia. Si dos clientes tienen en cache la misma
porción de un mismo archivo, y uno de ellos la modifica, cuando el otro lea
el bloque leerá información vieja. La cache no es coherente. NFS trata de
evitar este problema del siguiente modo:
asocia a cada bloque en cache un contador de tiempo, cuando el mismo
expira (normalmente 3 segundos para bloques de datos y 30 segundos
para directorios) se descarta la entrada;
cuando se abre un archivo que esta en cache envı́a un mensaje al servidor para averiguar cuándo fue modificado el archivo por última vez, si
la misma ocurrió luego de la copia en cache la misma se descarta y se
trae la nueva información;
cada 30 segundos expiran los datos de la cache y todos los bloques que
han sido modificados se envı́an al servidor.
En resumen, NFS ha sido muy criticado pues mientras que un cliente
escribe un archivo puede o no ser visto por otro que lo está leyendo, dependiendo del tiempo. Cuando se crea un archivo puede no ser visto por el resto
de los clientes hasta pasados 30 segundos. La semántica del acceso a archivos
no está bien definida, si un conjunto de programas cooperativos se ejecutan
varias veces podrı́an dar distintos resultados dependiendo del tiempo.
2.4.3.
Parallel Virtual File System - PVFS
PVFS es un sistema de archivos paralelo cliente/servidor en el cual los
archivos se distribuyen en forma transparente en discos de múltiples servidores. Su caracterı́stica principal es que a través de él las aplicaciones paralelas pueden acceder velozmente a los datos. Provee tres servicios básicos
a los usuarios:
un espacio de nombres consistente entre los nodos del cluster que permite a los programadores acceder a los archivos desde múltiples nodos;
distribución fı́sica de los datos entre los discos de los nodos que permite
evitar cuellos de botella tanto en la interface del disco como ası́ también en la red proveyendo mayor ancho de banda a los recursos de
entrada/salida (E/S);
18
interface de E/S que permite que los usuarios controlen cómo serán
distribuidos los datos y habilitar modos de acceso.
Figura 2.4: Diagrama del sistema PVFS [17].
Como se observa en la Figura 2.4 las máquinas que integran el sistema PVFS
pueden tomar uno o más de los siguientes roles:
Servidor Metadata. Existe un único servidor metadata por sistema de
archivos PVFS en el cual corre el demonio MGR. Contiene información correspondiente a los archivos y directorios que posee como ser
permisos, dueño, ubicación de los datos distribuidos en los servidores
de E/S. Es contactado por los clientes cuando necesitan leer un directorio o bien crear, eliminar, abrir o cerrar un archivo.
Servidor de E/S. Puede haber uno o más. Cada servidor de E/S (IOD)
aporta una porción de su disco local para integrar la partición PVFS.
Lleva a cabo las operaciones de acceso a los archivos sin intervención
del servidor metadata.
Cliente. Puede haber uno o más clientes. En ellos se corren las aplicaciones
que acceden a los archivos y directorios de la partición PVFS. Cuando
una aplicación desea abrir, cerrar, crear o eliminar un archivo se comunica directamente con el MGR a través de la biblioteca libpvfs. Una vez
que el servidor metadata localiza el archivo, le devuelve la ubicación a
la aplicación. Luego ésta puede utilizar la biblioteca para acceder directamente al servidor de E/S correspondiente para leer o escribir sin
necesidad de comunicarse con el MGR (ver Figura 2.5).
PVFS utiliza el protocolo TCP/IP para transmitir los datos. Las particiones PVFS pueden ser directamente accedidas por las aplicaciones a través
de la bibliotecas libpvfs.a, archivos de include y el archivo de configuración
pvfstab que indica cómo acceder a los ficheros PVFS. También se pueden utilizar las funciones ROMIO [36] como interface de E/S de MPICH las cuales
19
Figura 2.5: Flujo de metadata y datos en PVFS [17].
utilizan las bibliotecas mencionadas. Por otro lado, se puede acceder indirectamente a través del kernel, ver Figura 2.6. En este caso los clientes deben
utilizar:
el demonio pvfsd que se encarga de las transferencias a través de la red,
comunicación entre clientes;
el módulo del kernel pvfs.o registra en el kernel este tipo de fichero
PVFS permitiendo que los archivos PVFS sean accedidos a través de
las clásicas llamadas al SO. Este módulo es el que permite que los
programas comunes accedan a particiones PVFS que estén previamente
montadas;
el dispositivo /dev/pvfsd es utilizado como punto de comunicación entre
el módulo pvfs.o y el demonio pvfsd;
el ejecutable mount.pvfs es utilizado por el comando mount para llevar
a cabo el proceso especı́fico de montar un fichero PVFS.
Figura 2.6: Flujo de datos a través del kernel [17].
Los clientes hacen uso transparente de la partición PVFS a cambio de
pérdida de performance debido al movimiento de datos entre el kernel y el
demonio pvfsd. Por eso existe la opción de utilizar directamente las bibliotecas PVFS, o a través de las funciones ROMIO, para que el programador
pueda especificar la distribución fı́sica del archivo y configurar particiones
20
lógicas, logrando ası́ mayor performance sobre todo en aplicaciones paralelas
que posean operaciones colectivas.
Los programas que estén desarrollados para utilizar funciones de entrada
y salida propias de UNIX (read, write), correrán también sobre una partición
PVFS sin necesidad de hacerles ningún cambio. Si se crea un archivo de este
modo será distribuido entre todos los servidores de E/S con las variables
default, porciones de 64 KB. Notar que en este caso, cada escritura o lectura
que se quiera realizar sobre dicho archivo involucrará a todos los servidores de
E/S. Con muchos accesos a pequeñas porciones no dará un buen resultado.
Por eso es conveniente utilizar las funciones de la biblioteca estándar (fread,
fwrite) que permiten definir el tamaño del buffer a utilizar. Generalmente el
PVFS tendrá mayor performance con tamaños de buffers grandes.
En la Figura 2.7 se presenta un ejemplo de cómo se distribuye un archivo
en una partición PVFS. Se puede definir en qué nodo se comienza a guardar el
archivo (base=1), cuántos servidores de E/S utilizará (pcount=4) y cuantos
chunks (grupos de igual cantidad de bytes) habrá contiguos en cada servidor
de E/S, strip size (ssize).
Figura 2.7: Ejemplo de distribución de un archivo en una partición PVFS [16]
Si el programador define particiones lógicas en un archivo, los accesos
subsiguientes a dichas regiones se harán en forma más eficiente. Dichas particiones, son útiles para programación paralela pues simplifican el acceso a
datos compartidos por un conjunto de tareas de una aplicación. Cada proceso
puede definir su propia partición lógica y una vez definida todas las operaciones de E/S verán únicamente los datos correspondientes a dicha tarea. Las
particiones se definen con tres parámetros: offset, distancia en bytes desde
el inicio del archivo hasta el primer byte de la partición; group size (gsize)
número de bytes continuos de una partición y stride distancia desde el inicio
de un grupo de bytes al siguiente. En la Figura 2.8 se muestran dos ejemplos
de particiones lógicas, en el caso (A) se desea que 4 procesos paralelos procesen un archivo de 40.000.000 registros de 1.000 bytes cada uno, entonces
cada proceso (0..3) configurará su offset de modo tal de particionar al archivo
en regiones disjuntas, 10.000.000 registros para cada uno, (B) otra opción de
particionamiento del archivo es repartir en forma cı́clica los registros (roundrobin), en este caso el group size será 1.000 bytes y la cantidad de registros
a saltear hasta el próximo perteneciente a la misma tareas es de 4.000 bytes
(stride size). También se pueden definir particiones lógicas para acceder a un
21
archivo en forma matricial.
Figura 2.8: Ejemplos de particiones Lógicas PVFS [16]
2.4.4.
Mosix File System con Direct File System Access - MFS con DFSA
MFS es un sistema de archivos para clusters que optimiza el uso de la
red migrando los procesos hacia el lugar donde se encuentran los datos en
vez de buscar los datos y traerlos hacia el proceso. Esto permite mejorar la
performance de entrada/salida y reduce la congestión de la red evitando el
uso de protocolos como ser NFS y PVFS entre otros. DFSA permite operaciones paralelas consistentes en diferentes sistemas de archivos. Este tipo de
sistema de archivos no se probará en este trabajo, solo se menciona a modo
informativo.
2.4.5.
Global File System - GFS
GFS [23] es un sistema de archivos compartido apropiado para clusters
con share storage (almacenamiento compartido de datos) que permite a los
clientes acceder a los mismos mientras que mantiene la consistencia de los
datos. Los nodos comparten espacio de almacenamiento, cache de datos y
control. El problema de este tipo de sistema de archivo es el alto costo del
hardware por lo tanto en este trabajo tampoco será probado. Su escalabilidad
aún no se conoce.
2.5.
Administración de Procesos
El cluster es utilizado por un grupo de usuarios heterogéneo, alumnos y
profesores de diversas áreas. Esto implica que el tipo de problemas que se
ejecutan en el cluster es variado y por lo tanto se necesita un método que
permita balancear la carga de procesos que se genera a partir de un conjunto
de usuarios con distintos requerimientos:
mucha memoria
22
poca memoria
mucho uso de CPU
poco uso de CPU
muchas horas de procesamiento
pocas horas de procesamiento
gran cantidad de pasaje de mensajes
poca cantidad de pasaje de mensajes
Es necesario aplicar polı́ticas de administración de procesos para optimizar el ’throughput’ de procesos y ası́ utilizar el cluster en forma óptima aumentando la disponibilidad de una máquina de alta performance para
un mayor número de investigadores. Para esto se utilizaron las aplicaciones
’Portable Batch System’ (PBS) como administrador de procesos y ’MAUI
Scheduler’ que permite definir polı́ticas para decidir qué proceso de la cola
se ejecutará y en qué momento.
2.5.1.
Portable Batch System - PBS
PBS [10] es un sistema de control de ejecución de procesos y de asignación
de recursos a los mismos (cpu, memoria, cantidad de procesadores, tiempo
de ejecución de CPU, tiempo total de ejecución de un proceso ’walltime’).
Como tal, aceptará procesos ’batch’, un script escrito en shell, atributos de
control y se encargará de preservar y proteger el proceso hasta que el mismo
comience su ejecución, se ejecute y devuelva la salida a quien le solicitó la
ejecución del proceso. PBS consiste básicamente en cuatro componentes:
1. Comandos de:
usuario permiten enviar a ejecutar procesos, monitorearlos, modificarlos y borrarlos (qsub, qstat, qalter y qdel)
operador este tipo de usuario tiene más privilegios que los usuarios
comunes, puede encender y apagar colas, bajar y levantar el servidor, modificar o borrar procesos de usuarios (qdisable, qenable,
qrun, qstart, qstop, qterm, pbs_mom, pbs_server y pbsnodes)
administrador posee el máximo nivel de privilegios, puede realizar
todas las operaciones anteriores y además puede modificar la configuración de las colas y del servidor (qmgr, qenable, qrun)
2. ’Job Server’ (demonio pbs server) corre en el nodo ’master’, su función
principal es proveer los servicios básicos como ser recibir/crear un proceso ’batch’, modificarlo, protegerlo de ’system crashes’ y ejecutar el
proceso.
3. ’Job Executor’ (demonio pbs mom) este demonio es quien realmente se
encarga de poner el proceso en ejecución cuando recibe una copia del
mismo enviada por el pbs server. También tiene la responsabilidad de
devolver la salida del proceso al usuario cuando el servidor se lo indica.
23
4. ’Job Scheduler’ (MAUI scheduler) Es quien controla, según las polı́ticas
definidas, qué proceso corre, cuándo y dónde. PBS tiene tres posibles ’schedulers’ para habilitar pero son básicos y no permiten definir
polı́ticas precisas como el MAUI.
2.5.2.
MAUI Scheduler
El encolador MAUI [11] es un sistema avanzado de encolamiento de procesos por lotes, adecuado para la computación cientı́fica en gran escala o,
en su versión actual, computación de alta performance (High Performance
Computing - HPC). Fue diseñado para correr sobre plataformas Alpha e Intel, con sistemas operativos IBM SP y Unix/Linux y puede utilizar distintos
administradores de recursos entre ellos PBS (Portable Batch System).
’MAUI Scheduler’ provee un mecanismo para enviar a ejecutar procesos,
ejecutarlos y hacer un seguimiento del estado del mismo en un sistema con
recursos compartidos. Esta tarea es muy importante en un ’batch system’
que provee acceso centralizado a recursos distribuidos. Además de proveer
una visión global de los recursos del cluster, MAUI puede administrar dichos
recursos de manera justa y efectiva. Permite definir polı́ticas de asignación
de los recursos, qué proceso corre, dónde y cuándo maximizando el ’throughput’ del sistema. MAUI soporta un sistema de reserva de recursos avanzada,
niveles de calidad de servicio (QOS), métodos para optimizar la distribución
de procesos en la arquitectura del sistema (’backfill’) y administración de
asignación de los recursos en general (’allocation management’). Su esquema
de ’scheduling’ está basado en un concepto avanzado de reserva de tiempo
(’walltime’) combinada con ’backfill’. La principal diferencia con respecto a
otros encoladores (e.g. NQS, DQS) es que MAUI permite que algunos procesos de menor prioridad se ejecuten antes que otros de mayor prioridad si y
solo si no se produce un retraso la ejecución de mayor prioridad.
Los comandos disponibles para todos los usuarios son:
showq muestra información sobre procesos: en ejecución, ociosos, no encolados (son aquellos enviados al sistema pero que están considerados no
elegibles, no pueden ganar prioridad)
showbf muestra los recursos disponibles
showstart jobid muestra el tiempo aproximado de iniciación del proceso
checkjob jobid muestra detalles sobre los procesos encolados. Los usuarios
pueden ver solamente el estado de sus propios procesos.
2.5.3.
Interacción entre PBS y MAUI
MAUI Scheduler es un conjunto de funciones que permiten un ’schedule’
racional y capacidades de ’backfill’ utilizando un administrador de recursos
del sistema, PBS. PBS es un sistema de administración de procesos que
provee información de los recursos de la máquina al MAUI y se encarga de
ejecutar los procesos según las indicaciones del mismo. La Figura 2.9 muestra
un esquema que explica en forma sintética la interacción entre PBS y MAUI.
24
Figura 2.9: Interacción entre PBS y MAUI
En sı́ntesis:
el usuario envı́a a encolar un proceso con el comando qsub al PBS server
MAUI consulta al PBS server en forma periódica acerca de los procesos
encolados
MAUI consulta a los PBS moms para saber el estado de los recursos
del sistema
MAUI en base a los requerimientos de los usuarios y a sus reglas predefinidas, asigna prioridades y ordena la ejecución de los procesos.
2.6.
Herramientas de programación
2.6.1.
MPICH
El paradigma de pasaje de mensajes Message Passing Interface - MPI [26],
es utilizado usualmente en distintas clases de computadoras paralelas, especialmente en aquellas que poseen memoria distribuida. Es un estándar de
funciones para llevar a cabo el pasaje de mensajes en la programación paralela. Puede invocarse desde C y Fortran. Una función de pasaje de mensajes
se encarga simplemente de transmitir datos de un proceso a otro a través de
la red. MPICH [26] es una de las tantas implementaciones de MPI que actualmente se encuentran disponibles y la que está instalada en el cluster Speedy.
Provee los siguientes tipos de operaciones descriptas en detalle en [25]:
Combinación de contexto y grupos de mensajes a través de un comunicador
Comunicación punto a punto
• estructuras de buffers y tipos de datos
• modos de comunicación: normal (bloqueante y no bloqueante),
sincrónica, buffered
25
Comunicación Colectiva
• gran variedad de rutinas para pasar datos entre procesos
• definición de grupos
Control de errores
En los sistemas UNIX, MPICH utiliza la biblioteca llamada p4 [27, 28]
como interface sobre la capa TCP. Las transferencias de datos sólo se llevan a cabo durante las llamadas a las funciones de la biblioteca MPICH.
Se puede optimizar el uso de la biblioteca p4 mediante la configuración
de diversas variables en el entorno del usuario. Por ejemplo, la variable
P4 SOCKBUFSIZE se utiliza para definir el tamaño del buffer para el socket,
se define en bytes. Se recomienda actualizar el valor por defecto que tiene la
variable P4 SOCKBUFSIZE de 32 KB por 128 KB, esto permite aumentar
el throughput de MPI [30].
Por otro lado, se puede optimizar el uso del protocolo TCP utilizando
la opción -p4sctrl al ejecutar un trabajo por lı́nea de comandos. Dicha opción permite definir distintas caracterı́sticas del socket TCP, pero sólo se
recomienda modificar el bufsize, en este caso se define en KB [30, 31]. Por
ejemplo, si se quiere definir el buffer del socket en 64 KB (por defecto es de
16 KB), se debe ejecutar:
# mpirun -np 2 mpptest -p4sctrl bufsize=64
Es importante mencionar que la biblioteca p4 utiliza tres protocolos de
pasaje de mensaje dependiendo del tamaño del paquete a transmitir [29].
Ellos son: Short los datos son enviados junto con la información de control
(menor o igual a 16 KB), Eager los datos son enviados sin esperar que el
receptor los pida (entre 16 y 128 KB) y Rendezvous los datos no serán
enviados hasta que el receptor los pida (mayor a 128 KB). Esta estrategia en
el tratamiento de los paquetes se realiza con el fin de optimizar la latencia en
el envı́o de mensajes cortos y alcanzar mayor ancho de banda para los largos.
2.6.2.
ROMIO
ROMIO [36] es una implementación de funciones para manejo de E/S de
alta performance portable a MPI-IO. Estas funciones pueden ser utilizadas
sobre distintos tipos de sistemas de archivos (NFS, PVFS, ufs - Unix file
system, linux ext3, etc.) Se caracteriza por la utilización de dos técnicas
novedosas para el manejo de datos:
data sieving Técnica para acceder eficientemente a bloques de datos no
contiguos cuando las funciones primitivas del fichero utilizado no pueden
hacerlo. Consiste en acceder a las regiones de datos no contiguas leyendo
un bloque de datos que contiene todas las regiones deseadas incluyendo
los datos que están superfluos y que no se necesitan. Las regiones de
interés serán extraı́das en el cliente. Esta técnica tiene la ventaja de
realizar una única transferencia de datos pero lee más datos de disco
que los requeridos y transfiere más datos por la red.
two phase I/O También llamada collective buffering, es una optimización
para operaciones colectivas de E/S. El conjunto de E/S independientes
26
que componen la operación colectiva, es analizado para determinar
que regiones deben ser transferidas (leı́das o escritas). Dichas regiones
serán distribuidas entre los procesos que finalmente interactuarán con
el fichero. Por ejemplo, en el caso de una lectura, los procesos encargados de recolectar los datos leerán sus regiones de disco y redistribuirán
los datos a sus ubicaciones finales. Mientras que en el caso de una escritura, los datos son recolectados primero por el proceso que pide la
escritura y luego son tomados por los procesos encargados de realizar
efectivamente la escritura a disco.
27
Capı́tulo 3
Experimentos y optimización
3.1.
Performance de Red
El diseño, construcción y utilización de un sistema de alta performance
requiere de la medición y optimización de la configuración de la red. En esta
sección se evaluará y optimizará la performance de red de Speedy mediante
la ejecución del benchmark de red NetPIPE descripto en el Apéndice B.1.
Además se compararán algunos de los resultados obtenidos en Speedy con los
clusters externos Meteoro y Mercurio descriptos en el Apéndice A.2 y A.3
respectivamente.
En el punto 3.1.1 se discute el throughput de TCP y en el 3.1.2 se plantea
el mismo análisis para el caso de MPICH. La influencia del tamaño de las
ventanas de congestión de TCP y el rendimiento de Speedy se analizan en el
punto 3.1.3. Finalmente, en el apartado 3.1.4 se compara la performance de
los diferentes clusters utilizados en este trabajo.
Para llevar a cabo estos experimentos se realizaron las pruebas con las
siguientes configuraciones:
una placa de 100 Mbps Fast Ethernet por nodo conectadas mediante
un switch Fast Ethernet
dos placas de 100 Mbps Fast Ethernet por nodo configuradas en bonding
interconectadas mediante un switch Fast Ethernet
una placa de 1000 Mbps Gigabit Ethernet por nodo conectadas con un
switch Gigabit Ethernet
una placa de 1000 Mbps Gigabit Ethernet por nodo conectados espalda
contra espalda.
Para materializar los cuatro escenarios en el cluster Speedy cuyo hardware
es heterogéneo, se tomaron los nodos 12 y 13 de iguales caracterı́sticas, ver
Apéndice A.1, Cuadro A.1. En los clusters externos Meteoro y Mercurio sólo
se probó Bonding y Gigabit respectivamente y se tomaron un par de nodos
al azar debido a que son clusters homogéneos a nivel de hardware.
3.1.1.
Mediciones de Throughput de TCP
Se desea evaluar el throughput de la red del cluster Speedy a nivel de
protocolo TCP. Para esto se utilizó el módulo tcp del benchmark NetPIPE.
28
Con los resultados obtenidos se realizaron los gráficos de throughput según
el tamaño de bloque transferido, de saturación de la red y de firma ethernet
(definidos más adelante). Éstos últimos permiten analizar el máximo tamaño
de paquete para el cual se logra un incremento en el throughput y la latencia
de la red respectivamente.
Se tomó la siguiente configuración para las ventanas de congestión de
TCP:
Fast Ethernet (FE) y Bonding (FEB) buffer de envı́o 16 KB,
Gigabit Ethernet (GE) buffer de envı́o 64 KB,
en ambos casos el buffer de recepción es de 85 KB. El buffer de envı́o para GE
se configuró modificando las variables de configuración del socket TCP del
sistema operativo Linux, descriptas en el Apéndice C, según el Cuadro C.1.
Por otro lado, en el caso en que se conectan las máquinas espalda contra
espalda, se realizaron mediciones para MTU de 3000 y 9000 bytes. Esto
pudo llevarse a cabo pues las placas de red permitı́an el uso de jumbo frames,
tamaño de datagramas mayores a 1500 bytes. Se tomó un cable cruzado y
se conectaron las dos máquinas espalda contra espalda. Con el comando de
linux ifconfig se configuraron los distintos tamaños de MTU, por ejemplo
para 3000 bytes se ejecutó:
# ifconfig eth0 mtu 3000
La Figura 3.1 muestra el throughput en función del tamaño de
bloque transferido. A simple vista, se pueden observar las mejoras resultantes al incrementar la capacidad del medio de comunicación entre los
nodos. Sin embargo, pese a utilizar placas y switch GE el mejor resultado no
alcanza los 350 Mbps.
Con respecto a GE y a la variación en el tamaño del MTU, si se aumenta a 3000 bytes se logra una mejora pareja de 20 Mbps comparada con
1500 bytes. También se logra una mejora similar con 9000 bytes, pero su
comportamiento es un poco inestable y por debajo del caso de 3000 bytes.
Es posible que el procesador no sea lo suficientemente rápido para realizar
los cálculos que requiere TCP/IP para poder utilizar la capacidad de ancho
de banda que provee GE. Al utilizar jumbo frames, se realiza menor cantidad
de cálculo TCP/IP para enviar o recibir la misma cantidad de datos. Esto
permite que el procesador pueda enviar más datos con la misma cantidad de
cálculo obteniendo un throughput mayor al utilizar jumbo frames. Por otro
lado, también se probó el MTU por defecto, 1500 bytes, con las máquinas
conectadas espalda contra espalda obteniendo el mismo resultado que cuando
se utiliza el switch Gigabit Ethernet. De aquı́ se concluye que la limitación
en el throughput no depende de él.
Todos los casos están prácticamente superpuestos para paquetes de tamaño
menor o igual a 8 bytes, esto se debe a que para paquetes tan pequeños el
benchmark envı́a un sólo paquete TCP muchas veces y devuelve el promedio
de la latencia obtenida. Estos casos no son útiles para analizar el throughput. También se observa que para cada caso la función crece abruptamente
en cierto intervalo de tiempo, es allı́ donde se obtiene un throughput sustancialmente mayor al incrementar el tamaño del bloque. Luego de dichos
29
intervalos, no se logra mayor beneficio al incrementar el tamaño del paquete.
Esta última observación se puede ver gráficamente realizando un gráfico de
saturación de la red.
El gráfico de saturación de la red [32], Figura 3.2, se obtiene de graficar
el tamaño de bloque versus el tiempo ambos en escala logarı́tmica. Se define
como punto de saturación aquel a partir del cual al incrementar el tamaño del
bloque el tiempo crece linealmente. El punto de saturación para FEB y GE,
en todos los tamaños de MTU presentados, es cuando el paquete es de 4 KB
mientras que para FE es de 2 KB. El intervalo de tiempo luego del punto de
saturación se determina intervalo de saturación. En este intervalo el gráfico
crece a velocidad constante, por lo tanto a partir de allı́, el throughput de la
red no puede mejorarse incrementando el tamaño del bloque.
Finalmente, se observa la latencia de la red mediante el gráfico de
firma ethernet [32], Figura 3.3. Se grafica el throughput versus el tiempo de
transferencia en escala logarı́tmica obteniendo ası́ un gráfico de aceleración
de la red. La latencia de la red coincide con el primer punto de tiempo. Se
observa mayor latencia para el caso de FE y FEB con 47 µs, luego sigue el
caso de GE con MTU igual a 1500 bytes con 30 µs siendo el mejor caso para
GE con MTU de 3000 y 9000 bytes con 26 µs cada uno.
Figura 3.1: Throughput de Speedy para tamaño de buffers default de sockets
TCP. Referencias: (F)ast, (E)thernet, (B)onding, M(PICH), (G)igabit.
30
Figura 3.2: Gráfico de Saturación Ethernet del cluster Speedy.
Figura 3.3: Gráfico de Firma Ethernet del cluster Speedy.
31
3.1.2.
Mediciones de Throughput de MPICH
En esta sección se desea evaluar el throughput de red de las funciones de
envı́o y recepción de mensajes de MPICH en el cluster Speedy. Para esto se
utilizó el módulo mpi del benchmark NetPIPE. Los resultados obtenidos se
analizan a partir de los gráficos de throughput según el tamaño de bloque
transferido, de saturación de la red y de firma ethernet presentados en la
sección anterior.
La Figura 3.1 muestra el throughput versus el tamaño de bloque
transferido. Se graficaron los resultados para MPICH en Fast Ethernet
(FE), Bonding (FEB) y Gigabit (GE) con MTU=1500 bytes. En el último
caso, se modificó la variable P4 SOCKBUFSIZE, explicada en el Capı́tulo 2.6.1 y se ejecutó el benchmark para buffers de 32 KB y 128 KB. Para las
pruebas de las funciones de MPICH a primera vista se observa que la performance se degrada en comparación con los resultados obtenidos para TCP.
Esto se debe al overhead que se agrega sobre el protocolo TCP al implementar
funciones de pasajes de mensajes más simples para uso del programador.
En las pruebas de MPICH con su configuración de buffers de envı́o y
recepción de mensajes por defecto (32 KB), el throughput disminuye en
promedio: 18 % para GE, 13 % para FEB y 11 % para FE. Para GE también se evaluó la performance de MPICH incrementando el buffer mediante
la variable P4 SOCKBUFSIZE a 128 KB. Se logró en promedio una mejora
del 10 % sobre el caso por defecto para paquetes mayores o iguales a 16 KB.
Notar que el pico más alto se alcanza para paquetes mayores o iguales a
128 KB. Esto se debe al protocolo que utiliza la interface P4 para envı́o de
mensajes descripto en el Capı́tulo 2.6.1. Es en ese punto donde comienza a
utilizar el protocolo Rendezvous. A pesar que el que envı́a el paquete tiene que
esperar a que el receptor los pida, se logra un incremento en el throughput
gracias al gran tamaño de los mensajes transmitidos. Para paquetes menores
a 16 KB utiliza el protocolo Short, entre 16 y 128 KB el Eager. Finalmente,
se decide dejar configurada la variable P4 SOCKBUFSIZE en 128 KB para
todos los usuarios del sistema.
En el gráfico de saturación de la red [32], Figura 3.2, se observa que los
puntos de saturación de MPICH coinciden con los de TCP. Siendo de 4 KB
para FEB y GE, mientras que para FE es de 2 KB. Aquı́ nuevamente en el
intervalo de saturación el gráfico crece a velocidad constante, por lo tanto
a partir de allı́, el throughput de MPICH no puede mejorarse considerablemente incrementando el tamaño del bloque.
Finalmente, se observa la latencia de MPICH mediante el gráfico de
firma ethernet [32], Figura 3.3. Se observa mayor latencia para el caso de FE
y FEB con 70 µs, luego sigue el caso de GE con MTU igual a 1500 bytes con
47 µs. Notar que la latencia de un mensaje de MPICH en GE es tan grande
como la latencia TCP en FE y FEB y la latencia para FE y FEB de MPICH
siguen siendo iguales entre si.
32
3.1.3.
Influencia del tamaño de las ventanas de TCP
Se realizaron mediciones variando el tamaño de las ventanas TCP. No
se obtuvieron grandes diferencias para FE y FEB pero sı́ para GE. En la
Figura 3.4 se muestran los datos obtenidos para GE para cada uno de los
tamaños de MTU evaluados (1500, 3000 y 9000 bytes). La configuración por
defecto corresponde a tamaños de 16 KB y 85 Kb para los buffers de envı́o
y recepción respectivamente y def2 cambia el tamaño del buffer de envı́o por
64KB, el resto tienen el mismo tamaño para ambos buffers. El throughput
de MPICH se muestra para buffers de 32 KB y se evaluaron las operaciones
de envı́o y recepción de mensajes sincrónicas. En los tres gráficos podemos
agrupar las pruebas en casos según su comportamiento:
1. buffers de 256, 512 y 1024 KB
2. buffers default y 128 KB
3. buffers de 64 KB
4. buffers def2
5. MPICH
Si se compara el gráfico de MTU igual a 1500 bytes con el de 3000, se
observa que cada uno de los casos se comportan proporcionalmente igual,
ganando entre 20 y 25 Mbps para MTU de 3000 bytes. Sin embargo para
MTU igual a 9000, MPICH se comporta muy irregular y los casos 2, 3 y 4
se unen sin alcanzar la performance del caso def2 de la Figura 3.4 (b). Sólo
para el caso 1, MTU igual a 9000 muestra mayor performance para tamaños
de paquetes mayores a 128 KB pero a pesar de ello, en el recorrido hasta
allı́ presenta escalones irregulares.
Del análisis de estos tres gráficos surge que la configuración con MTU=3000
bytes es óptima y estable, sin embargo no es posible llevarla a la práctica debido a que la norma IEEE 802.3 impone una MTU máxima de 1500 bytes
de carga útil que respetan los switches comerciales. Solo unos muy pocos
equipos permiten el empleo de MTU mayores. Una última observación respecto a esta figura es que al ampliar la ventana de escritura por defecto de
16 KB a 64 KB, según las recomendaciones del documento [35], se obtuvo
una mejora de un 5 % para paquetes mayores a 128 KB. El cluster Speedy
quedó con esta última configuración.
3.1.4.
Comparación entre diferentes clusters
Por último, se comparan los resultados obtenidos en el cluster Speedy con
los extraı́dos de los clusters Meteoro y Mercurio de tecnologı́as más modernas, ver Apéndice A. El cluster Meteoro, está configurado en bonding y no
presentó diferencias para TCP, sin embargo mostró mejor performance que
Speedy en MPICH. Esto puede ocurrir debido a que el sistema necesita mayor
poder de procesamiento y memoria para manejar el bonding y ejecutar un
programa paralelo, caracterı́sticas que posee el cluster Meteoro. El cluster
Mercurio posee una red gigabit ethernet y máquinas aún más potentes que
los dos clusters anteriores, procesador de 2.8 GHz, memoria cache de nivel
33
Figura 3.4: Throughput de red para distintos tamaños de ventanas de congestión
TCP (A) MTU=1500, (B) MTU=3000 y (C) MTU=9000.
34
3 de 2 MB, FSB de 800 MHz, 4 GB de RAM y un bus PCI (sin bridge
PCI) de 64 bits/100 MHz, la placa de red negocia a 66 MHz. Se observa una
performance de un 64 % superior al cluster Speedy. Puede observarse que el
throughput alcanzado en el cluster Mercurio es del orden de 900 Mbps. Según
el bus PCI que posee, resulta en un máximo ancho de banda teórico de:
PCIb = 64 bits × 66 MHz = 4224 Mbps
En este caso, la placa de red sólo utiliza el 21 % del ancho de banda
disponible. En el caso de Speedy, se utiliza un 16 % del mismo. Comparando
el máximo throughput del cluster Speedy con Mercurio, este último es 2,5
veces mayor, se debe tener en cuenta que no solo el bus PCI tiene el doble de
capacidad sino también posee un FSB 3 veces mayor, tres niveles de cache
en vez de dos y 8 veces el tamaño de la cache.
Figura 3.5: Comparación del throughput entre los clusters Meteoro, Mercurio y
Speedy. Referencias: (F)ast, (E)thernet, (B)onding, M(PICH), (G)igabit.
3.2.
Performance de Sistemas de Archivos
Se quiere probar la performance de los distintos tipos de sistemas de
archivos configurados en el cluster Speedy Gonzalez. El análisis de los mismos servirá para que los usuarios puedan mejorar la performance de sus
procesos utilizando eficientemente las funciones de E/S disponibles. Se utilizarán los benchmarks: Bonnie [39], Babieca [40], perf y coll perf [36] para
evaluar distintos aspectos, ver Apéndice B.2.
En las pruebas básicamente se compara la velocidad de acceso (MBps)
a los distintos sistemas de archivos local de Unix ext3, NFS (versión 3) y
PVFS (versión 1.6.2). Los sistemas Mosix y GFS no se implementaron en
35
el cluster Speedy González, el primero debido a que para implementarlo se
debe recompilar el kernel para que éste aplique balance de carga en forma
automática y transparente para el usuario y ese no era el objetivo de nuestro
trabajo, el segundo por ser un tipo de sistema de archivo implementado en
mainframes.
Para poder utilizar ROMIO sobre NFS, la función fcntl debe funcionar
correctamente sobre NFS. En algunas instalaciones, dicha función no funciona. Para asegurase que no exista este problema, se debe utilizar la versión
3 de NFS y montar el sistema de archivos con la opción noac (no attribute
caching). La misma quita la opción de ’caching’ del NFS lo cual puede reducir la performance, pero es necesario para un comportamiento adecuado
[37]. Todas las pruebas de acceso a archivos se realizaron con el switch de
gigabit ethernet y con la configuración TCP actualizada según el Cuadro C.1.
3.2.1.
Benchmark Bonnie
El benchmark Bonnie, descripto en el Apéndice B.2.2, se utiliza para
medir la performance de operaciones de acceso a los sistema de archivos Unix.
Fue diseñado para hallar cuellos de botella en los servidores de aplicaciones.
Aquı́ se ejecutó en todas las máquinas del cluster, para cada tipo de fichero
disponible y con distintos tamaños de archivo en MB: 32, 64, 128, 256, 512
y 1024. Sin embargo, de todos los resultados obtenidos, se seleccionó como
tamaño de archivo 1 GB para el mejor caso correspondiente a speedy12,
Athlon 1200 MHz con 512 MB de RAM. El resto de las máquinas en los
distintos tamaños de archivo se comportaba igual que ésta para cada tipo
de fichero, pero su performance se mantenı́a o disminuı́a en proporción a los
Hzs del CPU.
Cuadro 3.1: Throughput de accesos al sistema de archivos. Las búsquedas aleatorias están dadas en cantidad de búsquedas por segundo. Benchmark Bonnie.
En la Figura 3.6 se pueden observar los resultados obtenidos en un gráfico
de barras. En todos los casos, la mejora alcanzada por PVFS se debe a la
metodologı́a que utiliza para realizar el acceso a los datos explicada en la
Figura 2.5. El archivo será distribuido en la partición PVFS como se muestra
en la Figura 2.7 con base aleatoria entre 1 y 15, pcount=15 y ssize=64 KB.
Las escrituras y lecturas a caracter realizadas en el fichero NFS con
bloques de 4 KB son 1,9 % y 3,3 % respectivamente más veloces que las
realizadas con bloques de 8 KB. Sin embargo, para la re-escritura, escritura
y lectura por bloques, esta relación se invierte. En el caso de la escritura
a caracter, Bonnie escribe el archivo invocando 1024 millones de veces a
36
la macro putc(). En NFS con bloques de 4 KB alcanza una velocidad de
5799 KBps, con lo cual, se escribirá el primer bloque NFS aproximadamente a
los 0,71 segundos después de realizada la primer llamada a la macro. Además,
mientras se realiza la escritura a través de NFS, paralelamente el benchmark
sigue escribiendo caracteres en cache. En cambio, cuando el bloque NFS
está configurado en 8 KB, la función putc() se invoca a una velocidad menor
de 5686 KBps realizando la primer escritura del primer bloque 1,44 segundos
después de realizada la primer llamada a la macro. Esta diferencia de tiempos
sumado al paralelismo entre operaciones NFS y el loop del benchmark Bonnie
para realizar las escrituras en cache, es la que hace la diferencia final. En el
caso de PVFS, por cada loop en cache se escribirá un bloque de 64 KB
en el nodo de E/S que corresponda siguiendo la estructura definida. Al ser
distintos nodos los que se encargan de la escritura se logra una mejora del
35 % sobre NFS. Se debe resaltar que las operaciones por caracter consumen
mucho trabajo de CPU lo cual no es bueno, ver Cuadro 3.1. Esto puede
ocurrir debido a que el procesador es lento o bien por una implementación
ineficiente de la interface stdio. Para la lectura a caracter el análisis es
análogo al anterior.
Con respecto a las escrituras por bloques, se debe recordar que el
benchmark Bonnie las realiza en bloques de 16 KB, con lo cual para escribir
un archivo de 1024 KB escribirá 64 bloques. A nivel de NFS, para la configuración de 4 KB se transmitirán 256 bloques al servidor y para la de 8 KB
128 bloques. Como el protocolo no envı́a el siguiente bloque si no recibió el
ACK del anterior, es más eficiente enviar menor cantidad de bloques de mayor tamaño. Por otro lado, PVFS es un 55 % mejor que NFS, esto se debe a
que realiza las escrituras en bloques de 64 KB rotando cı́clicamente entre
los 15 servidores de E/S que tiene configurados la partición, escribirá dos
bloques de 16 KB por servidor. El fichero local es sólo un 12 % mejor que
PVFS.
En las operaciones de re-escritura y lectura por bloque PVFS alcanzó el máximo throughput, incluso supera al fichero local. En el caso de
Figura 3.6: Throughput de accesos al sistema de archivos. Benchmark Bonnie.
37
re-escritura el benchmark lee, modifica y re-escribe bloques de 16 KB, tareas que serán llevadas a cabo por el nodo de E/S que contenga el bloque.
Ocurre lo mismo para las lecturas. La menor carga de CPU, ver Cuadro 3.1,
corresponde a PVFS pues el servidor solamente busca el archivo en su metadata, pero los que realmente leen son los nodos de E/S, cada uno el sector
de archivo que contiene.
Para la prueba de búsquedas aleatorias, como se observa en la Figura 3.7, sin duda el mejor caso es PVFS. Realiza una cantidad de búsquedas
72 % mayor a los otros tres casos. Esto se debe a que la partición PVFS
está compuesta por una porción de disco de cada nodo, y aquı́ también como
vimos en la Figura 2.5, una vez que se localiza la distribución del archivo en
cuestión, es cada demonio de E/S quien se encarga de realizar la búsqueda
en su sector del archivo. Al ser éstas porciones más pequeñas que el archivo
completo, el resultado final es óptimo.
Figura 3.7: Cantidad de búsquedas por segundo. Benchmark Bonnie.
En base a éstas pruebas y a no haber observado grandes diferencias con
respecto a NFS con bloques de 4 KB y de 8 KB se siguieron las recomendaciones del documento NFS Linux Howto [9] para optimizar la configuración
de NFS, dejándolo configurado en el cluster Speedy con bloques de 8 KB.
3.2.2.
Benchmark Babieca
Se creo el benchmark llamado Babieca [40], descripto en el Apéndice B.2.1,
para tomar los tiempos de acceso de los distintos comandos UNIX. Se miden
los tiempos en los siguientes casos:
lectura local (ext3)
lectura remota (NFS/PVFS)
lectura local escritura local
lectura local escritura remota
lectura remota escritura local
lectura y escritura remotas
Se utilizó como archivo base el .tar.gz de los fuentes del kernel linux-2.4.26,
comprimido tiene un tamaño de 36,7 MB, descomprimido 164 MB y desagrupado 191,5 MB. Se seleccionaron para realizar las pruebas los nodos speedy12
38
y 13, Athlon 1200 MHz, ver Cuadro A.1. Para analizar los gráficos se debe
tener en cuenta la influencia del tamaño de bloque de cada comando y del
fichero en cuestión, 8 KB para NFS y para PVFS bloques de 64 KB por
nodo repartidos en round-robin entre los 15 servidores de E/S. El archivo
será distribuido en la partición PVFS como se muestra en la Figura 2.7, con
base aleatoria entre 1 y 15, pcount=15 y ssize=64 KB.
En la Figura 3.8, se muestra el tiempo de ejecución de los comandos de
lectura rm -f, du -sk, ls -R, grep -r y find -name. Se ve claramente que en
casi todos los casos, salvo rm, PVFS es el que tarda más tiempo en llevar a
cabo las distintas tareas. Esto se debe a que para que sea transparente el uso
de aplicaciones UNIX sobre un fichero de este tipo, se deben mover muchos
datos entre el demonio pvfsd y el kernel como se explicó en el Capı́tulo 2.4.3,
Figura 2.6. El primer comando es muy rápido en los tres casos pues consiste
solamente en borrar la entrada correspondiente a dicho archivo en la tabla
de i-nodos para archivo el local, en la tabla VFS para NFS y en el metadata
server para PVFS. Los comandos du -sk y ls -R acceden solamente a los
meta-data, lo que implica que se pasen pocos datos entre el servidor y el
cliente, sin embargo PVFS da un tiempo muy grande. El comando grep -r
utiliza bloques de 32 KB y lee los archivos uno a uno buscando lo que se le pida. PVFS guarda los archivos repartidos en bloques de 64 KB entre todos los
servidores de E/S. Luego, si el total de los fuentes del kernel pesa 196096 KB
y el comando accede de a 32 KB tendrá que hacer aproximadamente 6128
conexiones a través del kernel y el demonio pvfsd para leer todos los archivo
siendo un 99,5 % peor que el caso del local. El find -name es relativamente
mejor, porque sólo busca en la lista de nombres de los archivos de la estructura. Aparentemente es comparable con el du -sk que recorrerá todos los
archivos para calcular el espacio que ocupan.
Figura 3.8: Performance de sistemas de archivos ext3, NFS, PVFS. Comandos de
lectura Unix. Benchmark Babieca.
39
La Figura 3.9 muestra los resultados obtenidos en la ejecución de comandos de lectura/escritura en las distintas combinaciones posibles según la
ubicación de los archivos. El comando cp copia el archivo del kernel comprimido, utiliza bloques de 4 KB. El caso más ineficiente es la copia desde el
fichero PVFS al local debido a que tiene que realizar 9395 conexiones a través
del kernel y el demonio pvfsd para leer los 36,7 MB del kernel comprimido.
El mejor caso para PVFS es cuando se realiza una copia en su misma partición, esto se debe a que en realidad no sigue el procedimiento habitual de
copiado sino que replica el archivo en su servidor metadata y en cada uno de
los servidores de E/S en forma paralela.
El comando gunzip implica más escrituras que lecturas en bloques de
32 KB (4,47 escrituras cada 1 lectura). Leerá 36,7 MB y escribirá 164 MB.
Otra vez se puede observar que PVFS tarda prácticamente lo mismo que en
la operación de cp desde el fichero PVFS al local. PVFS es un 30 % más
lento que NFS. El comando gzip implica más lecturas que escrituras (4,47
a 1) en bloques de 32 KB. Es interesante notar que el comando gunzip tiene
mejor performance que le gzip, esto se debe a que el comando gzip realiza
más cálculos y luego escribe su salida más lento.
Figura 3.9: Performance de sistemas de archivos ext3, NFS, PVFS. Comandos de
lectura/escritura Unix. Benchmark Babieca.
El comando tar -xf desagrupa el archivo linux-2.4.26.tar de 167936 KB,
este comando escribe un 16 % más de lo que lee. Por defecto lee y escribe de
a bloques de 10 KB. Al leer de la partición PVFS, más allá de donde vaya a
escribir, tendrá que hacer 16793 accesos a través del kernel y el demonio pvfsd.
Comparando con el comando grep -r que sólo lee los archivos, se puede inferir
que de los 900 segundos que utiliza para resolver el comando completo, 753
corresponden solamente a lecturas y el resto a escrituras. Como lee y escribe
paralelamente, se completa en un total de 900 segundos.
Un caso interesante es el comando tar ch -b X que permite definir el
tamaño del bloque de escritura, X × 512 bytes, aquı́ se ejecutó para 8, 16,
40
32 y 64 KB. Este comando realiza más lecturas que escritura, la tasa de
lectura/escritura es de 1.7. El mejor caso es cuando el origen y el destino se
encuentran en un fichero local sin importar el tamaño del bloque de escritura.
Le sigue el caso en que el origen es local y el destino es un fichero NFS.
Para bloques de 8 KB tarda 23 seg, mientras que para los otros 3 casos
(16, 32 y 64 KB) tarda 19 seg. NFS escribe de a bloques de 8 KB no se
nota prácticamente diferencias con los distintos tamaños. Sin embargo, PVFS
muestra una leve mejora al ir aumentando el tamaño del bloque de escritura,
pero su performance dista mucho de NFS y del fichero local.
Las deficiencias en tiempo obtenidas al ejecutar comandos del sistema sobre el fichero PVFS no desalientan su uso. Sirven para verificar que realmente
es transparente el acceso a los datos de dichas particiones. En la siguiente
sección probaremos si realmente cumple las caracterı́sticas de eficiencia para
aplicaciones paralelas.
3.2.3.
MPI I/O: perf y coll perf de ROMIO
Se utilizaron los programas perf y coll perf, descriptos en el Apéndice
2.6.2, para evaluar la performance de algunas de las operaciones de lectura
y escritura de archivos provistas por MPI-IO (ROMIO). Las pruebas se realizaron sobre el cluster Speedy ejecutando corridas paralelas con 1, 2, 4, 8,
12 y 14 procesadores, en el caso de coll perf se excluye la ejecución con un
único procesador debido a que evalúa funciones colectivas. Dichas pruebas
fueron realizadas sobre los sistemas de archivos NFS y PVFS.
El programa perf, como se explica en el Apéndice B.2.3 mide el throughput alcanzado en operaciones de escritura MPI File write() y lectura
MPI File read() con y sin sincronización de escritura MPI File sync() previa a la lectura. Se ejecutó para distintos tamaños de acceso por nodo: 4, 8,
32 y 64 MB. La Figura 3.10 muestra la distribución fı́sica del archivo en la
partición PVFS para la ejecución con 4 procesos y 4 MB por nodo, para los
otros tamaños es análoga.
Figura 3.10: Distribución fı́sica del archivo generado por perf para la ejecución
con 4 nodos de tamaño 4 MB por nodo, en la partición PVFS (base=1, pcount=15
y ssize=64 KB). Programa perf de ROMIO.
41
Al comparar en la Figura 3.11 el comportamiento de las lecturas y escrituras entre NFS y PVFS para 4 MB de acceso por nodo se observa que
PVFS presenta mayor throughput que NFS en todos los casos. En la operación de escritura con sincronización para PVFS, Figura 3.11(B), se
observa un decrecimiento del 50 % en el throughput con respecto al caso sin sincronización. Esto se debe al tiempo que requiere la función
MPI File sync() para realizar efectivamente las escrituras al fichero. Sin
embargo, la lectura luego de dicha sincronización, no muestra una diferencia tan marcada como cuando no se sincroniza. Es interesante observar que
aquı́ PVFS, en general, aumenta su throughput al a incrementar la cantidad
de nodos por corrida.
Figura
3.11:
Throughput de escrituras/lecturas. (A) sin la
MPI File sync(), (B) con dicha función. Programa perf de ROMIO.
42
función
En el caso de NFS, no presenta prácticamente diferencias en las escrituras
y lecturas con o sin sincronización. Esto se debe a que el protocolo NFS
posee su propia forma de escribir/leer a disco y lo hace de a bloques de 8 KB
independientemente de la cantidad de nodos en la corrida o de si se invoca o
no a una función de sincronización.
Figura 3.12: Throughput de (A) escrituras y (B) lecturas SIN la función
MPI File sync(). Programa perf de ROMIO.
En la Figura 3.12 se muestran las escrituras/lecturas sin sincronización
para tamaños de bloque por nodo de 4, 8, 32 y 64 MB. En el caso de PVFS
y escritura para 8 MB se observa un comportamiento interesante, alcanza
un pico en el throughput con 8 nodos de cómputo (124 MBps). Teniendo en
43
cuenta que hay 15 servidores de E/S en la partición PVFS se deduce que al
haber más de 8 nodos de cómputo se satura la capacidad de escritura de los
15 servidores para ese tamaño. Sin embargo para bloques de 4 y 64 MB por
nodo, tener 8 nodos de cómputo no es una buena opción. Con respecto a las
operaciones de lectura se mantienen dentro de un rango de 75 y 100 MBps
para 4, 8, 12 y 14 procesos de cómputo.
NFS en general no presenta buena performance. Acentuándose la ineficiencia en las escrituras y lecturas de bloques de 32 y 64 MB por nodo.
Evidentemente el servidor NFS no puede llevar a cabo eficientemente las lecturas concurrentes de 8, 12 y 14 nodos de cómputo para dichos tamaños.
Para 4 y 8 MB la performance es pareja pero considerablemente más pobre
que el throughput alcanzado por PVFS.
Figura 3.13: Throughput de (A) escrituras y (B) lecturas CON la función
MPI File sync(). Programa perf de ROMIO.
44
En la Figura 3.13 se muestran las escrituras/lecturas con sincronización
para tamaños de bloque por nodo de 4, 8, 32 y 64 MB. En general, para las
escrituras se degrada la performance aproximadamente 1/3 del throughput.
Sin embargo, en el caso de PVFS las lecturas mantienen su throughput y en
algunos casos lo superan.
El programa coll perf se ejecutó para un vector 3D de dimensión 2563 .
coll perf evalúa el throughput de las operaciones de lectura y escritura colectivas MPI File read all() y MPI File write all(). PVFS nuevamente presenta resultados más satisfactorios que NFS. Como se observa en la Figura 3.14 PVFS logró una mejora del throughput de 63,5 % sobre NFS para las
operaciones de escritura colectiva y una mejora de 43 % para las lecturas. Si
se analizan los ficheros en forma independiente, NFS muestra constantemente
mayor performance para las operaciones de lectura mientras que en el caso
de PVFS esta relación varı́a al utilizar distinta cantidad de procesadores.
Figura 3.14: Throughput de Funciones Colectivas de lectura/escritura. Programa
coll perf de ROMIO para cubos de 2563 .
En base a los resultados obtenidos de la ejecución de perf y coll perf
se puede concluir que utilizar la partición PVFS para el almacenamiento de
datos en corridas paralelas puede incrementar el throughput total del programa. Además, PVFS es útil para aprovechar los recursos de disco distribuidos
en los nodos del cluster y efectivamente es transparente para el usuario. Con
sólo utilizar las funciones de acceso a archivos provistas por MPI I/O, el
programa hace uso de los beneficios de PVFS, y ese mismo programa corre
sobre distintos tipos de fichero sin necesidad de modificar el código.
45
3.3.
Throughput de Procesos
En esta sección se analizará el throughput de procesos del cluster Speedy,
esto es la cantidad de procesos por unidad de tiempo que es capaz de resolver.
Además se evaluarán los tipos de procesos que se ejecutan en el cluster para
recomendar una mejora para el sistema que controla los procesos ’batch’.
Eventualmente, se presentará un esquema a seguir en el momento de decidir
actualizar el hardware de Speedy.
La configuración del PBS y MAUI definida es básica, una única cola FIFO
(First In First Out), sin lı́mites en tiempo de uso de procesador, cantidad de
nodos y cantidad de memoria. En un principio fue suficiente para la cantidad
y tipo de usuarios del cluster. A medida que se incrementó el número de
alumnos y docentes, comenzaron a desarrollar problemas más complejos en
forma paralela haciendo uso exhaustivo del cluster. Sobre una muestra de
2054 trabajos ejecutados en el cluster, se pudieron diferenciar los siguientes
grupos de procesos (Figura 3.15):
cortos, menores de 15 minutos
medios, hasta dos horas
largos, entre dos y doce horas
muy largos, más de doce horas
con intenso uso de pasaje de mensajes (por ejemplo, resolución de ecuaciones de derivadas parciales por diferencias o elementos finitos)
con uso intensivo de procesador (por ejemplo, método Monte Carlo)
Figura 3.15: Porcentaje de cantidad de trabajos por tiempo de duración.
En base a los casos diferenciados se detectaron dos problemas recurrentes:
Trabajos encolados con recursos disponibles. Debido a que sólo se ha
definido una cola de trabajo FIFO ocurre que si dados tres usuarios
que solicitan los nodos n1..n4 en el siguiente orden:
usuario1
usuario2
usuario3
n1 n2
n2
n3
n3
n4
A pesar que el trabajo del tercer usuario podrı́a comenzar mientras
se ejecuta el trabajo del primero, no lo hace debido a que el segundo
46
usuario ya tiene reservado el recurso n3. Este problema se soluciona
habilitando la polı́tica backfill de MAUI, la cual permite que el tercer
usuario comience su ejecución siempre y cuando los usuarios especifiquen entre los requerimientos del trabajo el tiempo estimado de uso
de CPU. En el caso en que haya tiempo suficiente para ejecutar el trabajo del usuario3 mientras que el 1 finaliza, se habilitará su ejecución
antes que el proceso 2. Obteniendo como resultado la resolución de
los tres trabajos en menor cantidad de tiempo. Vale resaltar que este
beneficio podrá ser utilizado si y solo si los usuarios puedan estimar el
tiempo de sus corridas.
Trabajos largos que disminuyen el throughput total de procesos. Si
un trabajo largo (duración más de 12 horas) toma los 15 nodos ningún
otro trabajo puede comenzar hasta que el mismo termine. Para solucionar esto se debe configurar algún sistema de checkpointing. Básicamente se puede implementar dentro del código del programa, guardando a intervalos regulares el estado del trabajo teniendo ası́ la posibilidad de interrumpir la corrida del mismo por cierto intervalo de tiempo
para luego continuar desde el punto de ejecución alcanzado. O bien, a
nivel del kernel, es el sistema el que se encarga de guardar el estado de los procesos, re-encolarlo quitándolo del estado de ejecución
para dar curso a otro trabajo encolado. El checkpointing, incrementa
la tolerancia a fallas del sistema global. Este tema es muy amplio y
existen diversas formas para llevarlo a cabo que no serán cubiertas en
este trabajo.
Figura 3.16: Corridas homogéneas vs. heterogéneas.
De la Figura 3.16, se pueden analizar las procesos ejecutados en el cluster
con respecto a la cantidad de nodos involucrados y al tipo de nodos seleccionados por el usuario. Las corridas de un nodo, en general, corresponden
47
a la evaluación de un programa serial que posteriormente será paralelizado, el
usuario querrá conocer la mejora alcanzada al paralelizar su problema. Luego,
se puede observar que en un 55 % de los casos el usuario prefiere llevar a cabo
sus corridas en un conjunto de nodos homogéneo, igual hardware. Esto
se debe a que pueden evaluar sus resultados sin tener que concentrarse en
un balance de carga óptimo, repartiendo el mayor cálculo en los nodos más
potentes para lograr que los más débiles no degraden la performance global.
El cluster posee como máximo 5 nodos de igual hardware. Otro caso de uso
común son las corridas con 3 procesadores, esto se debe a que un usuario
que se inicia en la programación paralela en general comienza con programas
de una dimensión. Los casos a cubrir son el pasaje de mensajes entre los
vecinos y el caso particular de los nodos de los extremos derecho e izquierdo.
Como última observación, se encuentran picos en las corridas que utilizan
2n número de procesadores, esto se debe a que para problemas cuyo dominio de datos es un cubo la forma óptima de paralelizarlo es en potencias
de dos [25].
Esta distribución particular de tipos de procesos que se corren en Speedy
está relacionada con el hardware del cluster. Se debe tener en cuenta que
Speedy se armó en tres etapas. Debido a esto y a la pronta evolución del hardware posee tres grupos de procesadores según su capacidad de procesamiento.
Además, no todos los nodos poseen la misma cantidad de memoria RAM.
Éstas caracterı́sticas obligan que los usuarios optimicen sus implementaciones
teniendo presente el hardware y utilicen las herramientas disponibles. Idealmente los programas deben poseer un balance de carga dinámico. Esto hace
que el código sea un tanto más complejo pero a la vez se generarán programas que alcanzarán un rendimiento óptimo en cualquier cluster en el que
se ejecuten. En base al análisis anterior se puede definir una polı́tica adecuada al momento de actualizar el hardware de Speedy y para optimizar su
configuración. Por ejemplo:
Que todos los nodos posean una cantidad de memoria RAM proporcional a la velocidad del CPU, ya que como se mencionó, una forma de
hacer balance dinámico es distribuir el dominio del problema según la
velocidad del CPU.
Si se desea incrementar la cantidad de nodos hasta ocupar todas las
bocas del switch, hacerlo en pasos de modo tal que siempre se pueda
particionar el conjunto de nodos en potencias de dos. Por ejemplo,
serı́a bueno agregar por lo menos un nodo, para tener 16 (24 ) nodos
de ejecución en vez de 15 y ası́ poder particionar un cubo en mayor
cantidad de procesos, actualmente la mejor distribución para un cubo
es 23 . Además, en caso de tener 16 nodos se podrı́an tener dos corridas
activas con dicha cantidad de nodos o una con una matriz del doble de
tamaño.
Por último, se recomienda definir más colas de procesos. Por ejemplo:
una cola que agrupe los nodos más lentos para uso exclusivo de principiantes que corren trabajos cortos con poca cantidad de procesadores,
otra cola con mayor prioridad para los grupos de investigación, etc.
48
Capı́tulo 4
Conclusiones y lı́neas futuras
4.1.
Conclusiones
Se realizaron experiencias de benchmarking para el estudio de la performance y escalabilidad del sistema y se han establecido recomendaciones y
especificaciones acerca de la instalación, configuración y operación de estos
equipos, con énfasis en el hardware de los nodos y la tecnologı́a de red utilizada. Este trabajo constituye un primer esfuerzo hacia el desarrollo de un
entorno de aprendizaje de gerenciamiento de sistemas paralelos y del uso del
software paralelo.
Como se ha podido comprobar en el transcurso del trabajo, no es trivial alcanzar niveles de performance óptimos en un cluster Beowulf dedicado
a resolver problemas de alta complejidad. Los rápidos avances tecnológicos
hacen que tampoco sea trivial incrementar gradualmente la capacidad de los
componentes de hardware existentes logrando una armonı́a entre el hardware
del nodo y el de comunicación.
No es directo obtener mayor rendimiento con Gigabit Ethernet que frente
a Fast Ethernet. Como se desprende de los experimentos de red realizados
en el Capı́tulo 3.1, se demuestra que para obtener un mayor rendimiento en
gigabit ethernet es necesario tener en cuenta la arquitectura del nodo antes
de migrar de la tecnologı́a Fast Ethernet. El máximo throughput alcanzable
depende fuertemente del bus PCI del nodo como ası́ también la velocidad
del procesador y sus técnicas de ’caching’. También depende de la capacidad
que posean las placas de red para aliviar al resto de los componentes con
sus caracterı́sticas de poder acceder directo a memoria, realizar ’checksums’
de paquetes y poseer su propia cache para el manejo de los sockets TCP
siendo necesario un bus PCI dedicado que le garantice la tasa de transferencia
adecuada. Esto se observó al comparar en la Figura 3.5 al cluster Speedy con
tecnologı́as más modernas.
No solo depende del hardware la performance del sistema sino también del
’tuning’ de parámetros del protocolo de red TCP/IP. De las Figuras 3.1 y 3.4
se desprendió la necesidad de actualizar los parámetros de la configuración
por defecto de los sockets TCP utilizando 64 KB para la ventana de envı́o de
mensajes, 85 KB para la de recepción y dando la posibilidad al usuario de
poder configurar tamaños de buffers de hasta 4 MB para ası́ poder alcanzar
350 Mbps trabajando con paquetes de más de 128 KB. A partir de dichas
49
figuras, también se decidió aumentar el tamaño del buffer de MPICH configurando la variable P4 SOCKBUFSIZE igual a 128 KB para todos los usuarios
del sistema. Por otro lado, a nivel IP, es útil tener en cuenta que agrandar
el MTU permite mejorar el throughput alcanzando un máximo de 400 Mbps
aunque aún no sea posible implementarlo debido a las caracterı́sticas del
switch Gigabit utilizado.
Se debe tener en cuenta que todas las pruebas realizadas con NetPIPE
dan una cota máxima del throughput de Speedy. Y que con el hardware actual
es prácticamente imposible llegar a lograr el 50 % de la capacidad Gigabit.
Con respecto a los sistemas de archivos disponibles en Speedy, se ha podido
comprobar que tener configurados estos tres tipos de ficheros: local (ext3),
NFS y PVFS, en el cluster brinda un abanico de posibilidades al momento
de implementar una solución a un problema dado.
A grandes rasgos, PVFS tiene la ventaja de poder utilizar los recursos
de disco distribuidos entre los nodos del cluster en un espacio de nombres
consistente y en forma transparente para el usuario. Como ası́ también, se
desprende de la Figura 3.6, que PVFS es una buena opción para obtener
mejores tiempos de ejecución en corridas que realicen lecturas y escrituras
por bloques y a caracter. De las Figuras 3.11, 3.13 y 3.14, se desprende que
PVFS es bueno para el uso de funciones colectivas y no colectivas de MPI
I/O.
Por otro lado, PVFS posee la desventaja que si uno de los servidores de
E/S se cae, toda la partición PVFS queda deshabilitada. Y el servidor de
metadata es un único punto de falla pues contiene la información de toda la
partición. Tiene baja tolerancia a fallas. Por esto, se recomienda el uso de
dicha partición sólo para almacenamiento de datos transitorios. Otra observación, es que PVFS se ve limitado por el protocolo TCP pues es utilizado
en todas sus comunicaciones. Luego, como se vio en la Figura 3.1(A), el
throughput se encuentra limitado en un máximo de 350 Mbps. El grupo de
investigación del proyecto PVFS de la Universidad de Clemson [18] está investigando otros métodos de comunicación para este tipo de fichero.
El benchmark Babieca, demostró que las particiones PVFS pueden ser
accedidas mediante los comandos UNIX con la desventaja de sufrir un incremento en el tiempo de ejecución de los mismos. Pero cualquier usuario
puede acceder a este tipo de ficheros en forma transparente. También se pudo comprobar con el comando tar que efectivamente el tamaño del buffer es
importante para incrementar el tiempo de acceso a los archivos de un fichero
PVFS. Esta última observación, se debe tener en cuenta prácticamente en
todos los usos de la partición PVFS, tanto para programación mediante las
funciones de E/S de MPICH como ası́ también cuando se utiliza la API
(Application Programming Interface) propia de PVFS.
NFS no es adecuado para procesamiento paralelo pues no tiene consistencia en cache. Por último, las particiones ext3 locales en cada uno de los
nodos son buenas para corridas seriales en nodos internos del cluster pues
ası́ se evita el uso de la red innecesariamente.
Con respecto al uso del cluster se observó que por lo general los usuarios
ejecutan procesos cortos y seleccionan un grupo homogéneo de nodos. Puede
ocurrir que se encole algún proceso de más de 12 horas y este podrı́a disminuir
50
el throughput total de procesos. Por esto se recomienda implementar algún
método de ’checkpointing’ y definir nuevas colas de procesos para distribuir
en forma óptima el uso de los nodos.
4.2.
Lı́neas Futuras
Con respecto a la relación entre la arquitectura del nodo y el hardware de
comunicación, serı́a bueno la evaluación de benchmarks que permitan medir
el throughput de cada una de las secciones del camino que debe seguir un
dato para llegar a destino. Como ası́ también, analizar en profundidad el
overhead del protocolo TCP/IP y de las funciones de pasaje de mensajes.
Con respecto a los sistemas de archivos, serı́a interesante ahondar en el
tema de acceso a archivos en forma paralela utilizando las funciones de MPI
I/O y ası́ poder optimizar el uso del área de datos global y lograr mayor
performance en los programas con un alto grado de accesos de E/S.
Finalmente, con respecto a la configuración del scheduling de procesos
se podrı́an implementar nuevas colas, habilitar el checkpointing y educar a
los usuarios para que especifiquen lo más detalladamente posible los recursos
requeridos por sus procesos para obtener ası́ mayor throughput global.
51
Apéndice A
Clusters Utilizados
A.1.
Cluster Speedy González
A.1.1.
Hardware
El cluster Speedy pertenece al Laboratorio de Sistemas Complejos del
Departamento de Computación de la Universidad de Buenos Aires. Consta de
16 nodos, cuyo hardware se detalla en el Cuadro A.1. Inicialmente cada nodo
poseı́a una placa de red Fast Ethernet (3Com, 3c905cx PCI) y se conectaban
entre si mediante un switch Fast Ethernet, 100 Mbps (3Com, Office Connect,
dual speed switch, 16 bocas). Luego se migró a un switch Gigabit Ethernet,
1000 Mbps (TRENDnet, TEG-S240TX, 24 bocas) con una placa Gigabit
Ethernet (3Com, 3c2000 PCI, ver detalles Cuadro A.3) por nodo. Todas las
máquinas poseen motherboards PCchip M810, FSB de 200/266 Mhz y bus
PCI 2.2 de 32-bit/66Mhz (264 MBps) además poseen 256 KB de memoria
cache de nivel 2.
El nodo speedy1 se denomina master, cumple la función de consola de
administración y no participa de los cálculos paralelos. Maneja la cola de
procesos, atiende las conexiones externas de los usuarios y posee herramientas de monitoreo del sistema. Los otros 15 nodos son exclusivamente para
cálculo. Todos los nodos poseen floppies como dispositivos de entrada/salida
y discos IDE, ver Cuadro A.2, que contienen una partición para el sistema
operativo, una para datos locales y otra para almacenamiento de datos en
forma paralela [16].
Sólo el nodo master se conecta con el exterior, posee dos placas de red,
una conectada a la red de alumnos del departamento (Fast Ethernet), la otra
hacia el switch interno (Gigabit Ethernet). Posee instalado un firewall que
filtra los paquetes que provienen desde el exterior hacia el interior de cluster.
La Figura A.1 muestra la topologı́a de Speedy.
A.1.2.
Software
Cada uno de los nodos del cluster Speedy posee instalado el sistema operativo Linux Mandrake 9.2 [19], kernel 2.4.22-21mdk [20]. La instalación y
administración del cluster se realiza con el paquete OSCAR 3.0 [3]. Este
paquete contiene las aplicaciones necesarias para instalar, configurar, administrar y utilizar clusters Beowulf. Está compuesto por un conjunto de
52
Hostname
CPU
speedy1
Pentium III
speedy2
Pentium III
speedy3
Pentium III
speedy4
Pentium III
speedy5
AMD Athlon
speedy6 AMD Athlon XP 2000
speedy7
AMD Athlon
speedy8
AMD Athlon
speedy9
AMD Athlon
speedy10
AMD Athlon
speedy11
AMD Athlon
speedy12
AMD Athlon
speedy13
AMD Athlon
speedy14
AMD Athlon
speedy15
AMD Athlon
speedy16
AMD Athlon
Mhz
Disco
RAM (MB)
733 ST3120022A
384
733
ST320423A
192
733
ST320423A
192
733
ST320423A
192
946
SV2042H
192
1666 ST320410A
256
946
SV2042H
192
946
SV2042H
192
946 FIREBALLlct20
192
946 FIREBALLlct20
192
1200 ST320410A
512
1200 ST320423A
512
1200 ST320410A
512
900
ST320410A
192
1200 ST320410A
512
900
ST320410A
192
Cuadro A.1: Caracterı́sticas del hardware de Speedy.
Marca
Modelo
Capacidad Velocidad Seek time
Segate
ST3120022A
120 Gb 7200 RPM 8.9 ms
Segate
ST320423A
20.49 Gb 5400 RPM 8.9 ms
Segate
ST320410A
20 Gb 5400 RPM 8.9 ms
Samsung
SV2042H
20.4 Gb 5400 RPM 9 ms
Quantum FIREBALLlct20 20 Gb 5400 RPM 9 ms
Interface
Ultra ATA/66
Ultra ATA/66
Ultra ATA/100
Ultra ATA/100
Ultra ATA/100
Cuadro A.2: Caracterı́sticas de los discos de Speedy.
Función
Especificaciones
Reloj PCI
Máximo 66 Mhz
Datos/Dirección PCI
32 bit
Índice de transferencia de
132 Mbps 32-bit/33 Mhz
descargas de datos PCI
264 Mbps 32-bit/66 Mhz
Modos PCI
Maestro/esclavo
10/100/1000BASE-T 10/100/1000 Mbps (full-duplex)
Cuadro A.3: Caracterı́sticas de las placas de red 3c2000 [43].
53
Figura A.1: Topologı́a del Cluster Speedy.
aplicaciones de código abierto.
SIS - System Installation Suite [4] Permite instalar clusters Linux a través
de una red. Se basa en la creación de una o más imágenes a partir de
las cuales serán instalados los nodos.
PBS - Portable Batch System [10] Controla la cola de procesos y los
recursos del sistema.
MAUI [11] Permite definir polı́ticas de asignación de recursos, qué proceso
corre, dónde y cuándo.
C3 - Cluster Command Control Permite llevar a cabo las siguientes acciones en los nodos definidos en su configuración:
ejecutar comandos del sistema en forma distribuida
distribuir y buscar archivos
eliminar procesos activos
reiniciar y apagar el cluster en forma remota
generar imágenes para actualizar el cluster
OPIUM - OSCAR Password Installer and User Management Para
sincronizar los usuarios del cluster y configurar el ssh de los mismos.
Pfilter - Packet Filtering Permite configurar las reglas del firewall (iptables) en forma más sensilla.
Switcher Permite que los usuarios modifiquen las variables de su entorno
sin tener que editar sus archivos de configuración evitando ası́ que perjudiquen al sistema.
HDF5 - Hierarchical Data Format [5] Especificación de formatos de datos
y bibliotecas para programación paralela.
54
Programación Bibliotecas que permiten que un conjunto de máquinas heterogéneo (Windows/Unix) colaboren entre si a través de una red para
ser usadas como una única máquina paralela. De este modo se pueden
resolver problemas costosos en menor tiempo. La herramientas que se
pueden instalar con Oscar son:
MPI
LAM MPI
PVM
Por otro lado, se instaló el PVFS [16] versión 1.6.2 para manejo de ficheros
distribuidos. También se instalaron herramientas de compilación como ser:
Fortran 77 (gcc-g77-3.3.1)
C (gcc-3.3.1)
C++ (gcc-c++-3.3.1)
A.2.
Cluster Meteoro
A.2.1.
Hardware
El cluster Meteoro pertenece al Grupo de Modelado de Mesoescala, Dpto. de Ciencias de la Atmósfera y los Océanos, Facultad de Ciencias Exactas y Naturales. Consta de 8 nodos iguales, cuyo hardware se detalla en
el Cuadro A.4. Cada nodo posee dos placas de red Fast Ethernet (3Com,
3c905cx PCI) configuradas en bonding y se conectan entre si mediante un
switch Fast Ethernet, 100 Mbps (3Com, Office Connect, dual speed switch,
16 bocas).
El nodo master participa de los cálculos paralelos y cumple las mismas
funciones que en el cluster anterior. Todos los nodos poseen floppies como
dispositivos de entrada/salida, el master tiene una grabadora de CD. Cada
nodo posee un disco IDE Western Digital de 120 Gb 7200 RPM, que contienen
una partición para el sistema operativo y otra para almacenamiento de datos
en red (NFS).
CPU
GHz FSB
Cache
Pentium 4 2.4 400 Mhz 512 KB
RAM
Motherboard Bus PCI
1.5 GB
Intel
32-bit/66Mhz
DDR 333Mhz D865PERL
PCI 2.2
264 MBps
Cuadro A.4: Caracterı́sticas del hardware de Meteoro.
Sólo el nodo master se conecta con el exterior, posee tres placas de red,
una conectada a la red externa, las otras dos hacia el switch interno. Posee
instalado un firewall que filtra los paquetes que provienen desde el exterior
hacia el interior de cluster. La topologı́a es igual a la de Speedy.
55
A.2.2.
Software
Cada uno de los nodos del cluster Meteoro posee instalado el sistema
operativo Linux RedHat 8 [22], kernel 2.4.22 [20]. Y se instaló utilizando
Oscar 3.0 [3].
A.3.
Cluster Mercurio
A.3.1.
Hardware
El cluster Mercurio consta de 4 nodos Dell PowerEdge 6650, cuyas caracterı́sticas se detalla en el Cuadro A.5. Cada nodo posee una placa de red
Gigabit Ethernet de fibra óptica y se conectan entre si mediante un switch
Gigabit Ethernet Avaya P880, 1000 Mbps.
El nodo master participa de los cálculos paralelos y cumple las mismas
funciones que en el cluster anterior. Todos los nodos poseen CD como dispositivo de entrada/salida y discos SCSI Maxtor, que contienen una partición
para el sistema operativo. Los datos se ubican en un servidor de archivos
Network Appliance 880. La topologı́a es igual a la de Speedy.
CPU
Ghz FSB Cache
Xeon(MP) 2.8 800Mhz 2MB
RAM Motherboard
Bus PCI
4GB
Intel
64-bit/66Mhz
DDR
PCI-X non-bridge
SDRAM
533 MBps
Cuadro A.5: Caracterı́sticas del hardware Cluster Mercurio.
A.3.2.
Software
Cada uno de los nodos del cluster Mercurio posee instalado el sistema
operativo Linux RedHat 7.3 [22], kernel 2.4.26 [20]. Se instaló utilizando
Oscar 2.2.1 [3].
56
Apéndice B
Descripción de Benchmarks
B.1.
Red
B.1.1.
NetPIPE
NetPIPE, Network Protocol Independent Performance Evaluator [31][33] es una herramienta desarrollada para medir la performance tanto a nivel
TCP como MPICH. Se envı́a un mensaje que rebota repetidas veces entre dos
nodos del cluster y ası́ se obtiene el tiempo de transmisión para cada tamaño
de mensaje. El tamaño de los mensajes se elige a intervalos regulares y se
aplican pequeñas perturbaciones para una evaluación completa el hardware
y software de comunicación. Ası́ se obtiene la latencia de pequeños mensajes,
tomada como la mitad del RTT para mensajes de 8 bytes y un gráfico del
throughput de un amplio rango de tamaño de mensajes. El módulo MPICH
permite evaluar el throughput utilizando pasaje de mensajes sincrónico y
asincrónico.
B.2.
Sistema de archivos
B.2.1.
Babieca
Se creo el benchmark llamado Babieca [40], en honor al caballo del Cid
Campeador. Toma los tiempos de acceso a un sistema de archivos para un
conjunto de comandos UNIX. En el mismo se tuvieron en cuenta los distintos
tipos de accesos: lectura (du -sk, grep -r, ls -R, find), lectura/escritura (cp,
gunzip, gzip, tar -xf, tar -ch -b X -f, rm -fr). Se describen brevemente:
du -sk Devuelve el tamaño total en KB del conjunto de datos.
grep -r Busca recursivamente una palabra dentro de todos los archivos del
conjunto de datos.
ls -lR Obtiene el estado de todos los archivos del conjunto de datos (tamaño,
dueño, etc.)
find Busca lo que se pida dentro del conjunto de datos.
cp Copia los datos.
gunzip Descomprime los datos.
57
gzip Comprime los datos.
tar -xf Desagrupa el conjunto de datos.
tar -ch -b X -f Agrupa el conjunto de datos.
El benchmark es un script en shell (bash) que se ejecuta pasándole como
parámetros:
el path completo del archivo .tar.gz sobre el cual se realizarán operaciones seleccionadas,
el path completo directorio destino,
archivo que contendrá los tiempos de acceso obtenidos.
Según el fichero al que pertenezca el archivo tar.gz y el directorio destino
seleccionado, las lecturas/escrituras serán locales, remotas, remota/remota,
local/remota o remota/local.
B.2.2.
Bonnie
El benchmark Bonnie [39] es utilizado para medir la performance de acceso a los discos locales de una máquina. Lleva a cabo una serie de pruebas
sobre un archivo de tamaño conocido, se recomienda que el mismo sea mı́nimamente el doble de tamaño de la memoria RAM disponible. Para cada
prueba informa la cantidad de bytes procesados por unidad de tiempo total,
por segundo de CPU y el porcentaje de CPU utilizado por el usuario y por
el sistema. Mide:
escrituras secuenciales Utiliza la macro putc de la biblioteca stdio. El
loop que realiza las escrituras es lo suficientemente pequeño para asegurarse que entre en cualquier cache razonable. El overhead del CPU
corresponde a la carga del código stdio y al espacio que tiene el sistema
operativo para asignar archivos.
escritura por bloques Utiliza la función write(2) con bloques de tamaño
16384 bytes. Aquı́ la carga de CPU corresponde solamente al espacio
que tiene el sistema operativo para asignar archivos.
reescritura Cada porción del archivo (16 KB) es leı́da con la función read(2),
ensuciada, y reescrita con la función write(2) requiriendo la función
lseek(2). Como no se realizan asignaciones de espacio, y la E/S está bien localizada, esta operación evalúa especı́ficamente la capacidad de
’caching’del fichero y la velocidad de transferencia de datos.
lectura secuencial Utiliza la macro getc de la biblioteca stdio. El loop de
escritura es suficientemente pequeño como en el caso de las escrituras.
La carga del CPU corresponde al código stdio y a la entrada secuencial.
lectura por bloques Utiliza la función read(2). Evalúa la performance de
entradas secuenciales.
búsqueda aleatoria Lanza 4 procesos en paralelo, entre todos realizarán
4000 búsquedas a posiciones aleatorias del archivo. En cada caso el
bloque es leı́do read(2). En el 10 % de dichas búsquedas, los procesos
ensuciarán los datos y re-escribirán el bloque con la función write(2).
Verifica que haya siempre una cola de procesos activa.
58
B.2.3.
perf y coll perf
perf Programa de prueba que es parte del código fuente de ROMIO. Realiza
operaciones de lectura y escritura concurrentes a un mismo archivo.
Para cada proceso MPI, perf asigna un arreglo de datos de tamaño
fijo (4, 8 32 64 MB). El arreglo es escrito a una región disjunta y fija
en el archivo compartido utilizando la función MPI File write() y
luego es leı́da de la misma región MPI File read(). Todos los procesos
MPI utilizan la función MPI Barrier() para sincronismo antes de cada
operación de E/S. perf mide dos tipos de operaciones:
escrituras y posterior lectura del archivo
escrituras con sincronismo con la función MPI File sync() y posterior lectura del archivo
La función MPI File sync() provoca que todas las escrituras realizadas
hasta el momento de su invocación sean transferidas de memoria al
fichero en cuestión. Este programa provee una cota máxima de la performance de operaciones de E/S de MPI según la cantidad nodos por
corrida y del tipo de sistema de archivos utilizado.
coll perf Programa escrito en C, está incluido en la distribución de ROMIO.
Mide el ancho de banda de lecturas y escrituras de un arreglo 3D
distribuido por bloques, a un archivo correspondiente a un arreglo
global en orden según C row-major. La forma de acceder al archivo es no continua. El tamaño del arreglo esté definido en 1283 pero
puede cambiarse su tamaño editando el fuente. Utiliza las funciones
MPI File read all() y MPI File write all().
59
Apéndice C
Configuración TCP en Linux
Linux permite configurar las variables que describen las caracterı́sticas
default de los sockets TCP. Se deben definir los valores deseados dentro
del archivo /etc/sysctl.conf. Para el caso en que se utilizan placas y switch
Gigabit se recomienda configurar las siguientes variables según el Cuadro C.1:
net.core.rmem default Tamaño de ventana receptora default.
net.core.rmem max Tamaño máximo de ventana receptora.
net.core.wmem default Tamaño de ventana de envı́o default.
net.core.wmem max Tamaño máximo de ventana de envı́o.
net.ipv4.tcp wmem Vector de tres enteros: min, default, max. Indica la
cantidad de memoria reservada para el buffer de un socket TCP de
envı́o de paquetes. Los valores default son min: 4K, def: 16K y max:
128K. El valor default sobrescribe al net.core.wmem default utilizado por otros protocolos, usualmente es más pequeño que este último,
el máximo no se sobrescribe.
net.ipv4.tcp rmem Vector de tres enteros: min, default, max. Indica la
cantidad de memoria reservada para el buffer de un socket TCP de
recepción de paquetes. Los valores default son min: 8K, def: 87380
bytes y max: 87380 * 2 bytes. El valor default sobrescribe al net.core.
rmem default utilizado por otros protocolos, usualmente es más pequeño que este último.
net.ipv4.tcp mem Vector de tres enteros: min, presión, max. min: debajo
de esta cantidad de páginas, TCP no se preocupa por su consumo de
memoria. presión: cuando la cantidad de memoria utilizada por TCP
excede esta cantidad de páginas, TCP modera el consumo de memoria
hasta alcanzar nuevamente el mı́nimo. max: cantidad de páginas habilitadas para encolar paquetes utilizada por todos los sockets TCP. Los
valores default de estos tres parámetros son calculados al momento de
boot en función de la cantidad de memoria disponible.
60
A continuación se presenta un cuadro con la configuración utilizada para
dichas variables para Fast Ethernet y Gigabit:
Variable
Fast Ethernet
Gigabit Ethernet
net.core.rmem default
65535
65535
net.core.rmem max
65535
8388608
net.core.wmem default
65535
65535
net.core.wmem max
65535
8388608
net.ipv4.tcp rmem 4096 87380 174760 4096 87380 4194304
net.ipv4.tcp wmem 4096 16384 131072 4096 65536 4194304
Cuadro C.1: Configuración TCP en linux.
61
Bibliografı́a
[1] D. Ridge, D. Becker, P. Merkey and T. Sterling. Beowulf:Harnessing
the power of parallelism in a pile-of-pcs. Proceedings, IEEE Aerospace,
(1997).
[2] Beowulf http://www.beowulf.org
[3] The Open Cluster Group. OSCAR (Open Source Cluster Application
Resource): A packaged Cluster software stack for High Performance computing. (2002). http://oscar.sourceforge.net.
[4] System Installation Suite (SIS). http://sisuite.org/
[5] HDF Group. http://hdf.ncsa.uiuc.edu/HDF5/
[6] A. Barak, O. La’adan y A. Shiloh. Scalable Cluster Computing with
MOSIX (Multi-computer Operating System for UNIX) for Linux. Institute of Computer Science, The Hebrew University of Jerusalem, 1999.
[7] L. Amar, A. Barak y A. Shiloh. The MOSIX Direct File System Access Method for Supporting Scalable Cluster File System. Institute of
Computer Science, The Hebrew University of Jerusalem, (2003).
[8] NFS v3 protocol specification. http://www.faqs.org/rfcs/rfc1813.html
[9] Linux NFS Howto. http://nfs.sf.net/nfs-howto.
[10] Veridian Information Solutions. Portable Batch System Administrator
Guide. (2000).
[11] Supercluster Research and Development Group. MAUI Scheduler Administrator’s Guide. May 2002. http://mauischeduler.sourceforge.net
[12] N. Snyder. IBM @Server - IBM Linux Clusters. November 2003.
[13] A. S. Tanenbaum. Modern operating System. Prentice Hall (1992).
[14] D. E. Comer. Internetworking with TCP/IP. Volume I, Principles, protocols and architecture. Prentice Hall. (1995).
[15] A. S. Tanenbaum. Computer Networks. Prentice Hall. (1996).
[16] R. B. Ross, P. H. Carns, W. B. Ligon III y R. Latham. Using the Parallel Virtual File System (PVFS). Julio 2002.
ftp://ftp.parl.clemson.edu:/pub/pvfs/.
62
[17] M. Kashyap, J. Hsieh, C. Stanton y R. Ali. The Parallel Virtual File
System for High Performance Computing Clusters. 2002.
[18] The
Parallel
Virtual
File
http://parlweb.parl.clemson.edu/pvfs.
System
Project.
[19] Mandrake Linux http://www.mandrakelinux.com
[20] The Linux Kernel Archives http://www.kernel.org
[21] A. P. Foong , T. R. Huff , H. H. Hum , J. P. Patwardhan TCP Performance Re-Visited Department of Computer Science Duke University
Durham, NC 27708
[22] Linux Red Hat http://www.redhat.com
[23] Global File System. http://www.sistina.com
[24] M. Johnson Whitepaper: Red Hat’s New Journaling File System: ext3.
2001.
[25] P. Pacheco Parallel Programming with MPI. Universidad de San Francisco. 1997.
[26] MPI Standard http://www.mcs.anl.gov/mpi/index.html
[27] P4 http://www.mcs.anl.gov/ lusk/p4/
[28] J. Boyle, R. Butler, T. Disz, B. Glickfeld, E. Lusk, R. Overbeek, J.
Patterson, and R. Stevens. Portable Programs for Parallel Processors.
Publicado por Holt, Rinehart y Winston. 1987.
[29] O. Aumage, G. Mercier, R. Namyst. MPICH/Madeleine: a True MultiProtocol MPI for High Performance Networks. LIP, ENS-LYON 46,
All’ee d’Italie 69364 Lyon Cedex 07, France.
[30] W. Gropp y E. Lusk. Installation and User’s Guide to MPICH, a
Portable Implementation of MPI Version 1.2.5. The ch p4 device for
Workstation Networks.
[31] D. Turner y X. Chen. Protocol dependent message passing performance
on linux Clusters. Ames Laboratory - Iowa State University. Septiembre
2002.
[32] Snell, Mikler y Gustafson. NetPIPE: A Network Protocol Independent
Performance Evaluator. Ames Laboratory.
[33] D. Turner, A. Oline, X. Chen y T. Benjegerdes Integrating New Capabilities into NetPIPE. Ames Laboratory - Iowa State University.
[34] B. L. Tierney TCP Tuning Techniques for High-speed Wide Area Networks. Data Intensive Distributed Computing Group. Laurence Berkeley
National Laboratory.
63
[35] B. L. Tierney TCP tuning guide for distributed application on wide
area networks. Data Intensive Distributed Computing Group. Laurence
Berkeley National Laboratory. Febrero 2001.
[36] ROMIO, MPI IO interface http://www.mcs.anl.gov/romio
[37] R. Thakur, R. Ross, E. Lusk, W. Gropp User Guide for ROMIO: A
high-performance portable MPI-IO implementation. Argonne National
Laboratory. Mayo 2002.
[38] N. Srivastava. Parallel I/O. Parallel File System. HPC Expertise Center,
Hewlett-Packard Company.
[39] The Bonnie benchmark http://www.textuality.com/bonnie/
[40] C. León Carri, D. Vadell. Benchmark Babieca. Dpto. de Computación,
Facultad de Ciencias Exactas y Naturales, UBA. 2003. (Informe interno.)
[41] Intel. PCI Express Ethernet Networking. Smoothly Migrate Networking
to the Next-generation, Industry-standard Serial I/O Architecture. 2003.
[42] M. Kashyap, J. Hsieh, C. Stanton y R. Ali. The Parallel Virtual File
System for High-Performance Computing Clusters. Dell Power Solutions
http://www.dell.com/powersolutions. Noviembre 2002.
[43] Manual de usuario. Tarjeta de interfaz de red Gigabit de 3Com 3C2000.
http://www.3com.com/. Abril 2003.
64