DOCUMENTO TECNICO SOBRE SGI ALTIX 3000 PARA

DOCUMENTO TECNICO SOBRE
SGI ALTIX 3000 PARA
UNIVERSIDAD POLITECNICA DE
VALENCIA
Mayo 2003
SGI
Pza. Descubridor Diego de Ordás 3
Edificio Santa Engracia 120
28003 MADRID
1 de 83
INDICE
Capítulo/Sección
Página
1
ANEXO TÉCNICO A: DESCRIPCIÓN DE LA ARQUITECTURA
EMPLEADA EN LA FAMILIA SGI ALTIX 3000 ....................................................4
1.1 ARQUITECTURA SGI ALTIX 3000...............................................................5
1.1.1
DISTRIBUCIÓN DE MEMORIA.............................................................5
1.1.2
LATENCIA DE ACCESO A MEMORIA..................................................5
1.1.3
COHERENCIA DE CACHÉ....................................................................5
1.1.4
TIPO DE PARALELISMO.......................................................................5
1.1.5
TOPOLOGIA...........................................................................................5
1.1.5.1
2
RED DE INTERCONEXIÓN ........................................................................ 5
ANEXO TÉCNICO B: EL SUPERCLUSTER SGI ALTIX 3000 ....................5
2.1 INTRODUCCIÓN ............................................................................................5
2.2 MÓDULOS O BRICKS.....................................................................................5
2.2.1
CPU BRICK ITANIUM 2 (C-BRICK) .....................................................5
2.2.1.1
2.2.1.2
2.2.2
ROUTER BRICK (R-BRICK) ..................................................................5
2.2.2.1
2.2.2.2
2.2.3
2.2.4
2.2.5
3
PROTECCIÓN FÍSICA DE LOS DISCOS.................................................... 5
TP900 ......................................................................................................5
POWER BAY ...........................................................................................5
MODELOS ALTIX 3300 Y 3700: RACKS Y SISTEMA DE CONTROL ..5
2.2.8.1
2.2.8.2
2.2.9
DISPOSICIÓN DE LOS NODOS, ROUTERS Y NUMALINKS ................. 5
SUPERCLUSTER.......................................................................................... 5
INPUT/OUTPUT BRICK (IX-BRICK) ...................................................5
PCI-X BRICK (PX-BRICK) ....................................................................5
DISK BRICK2 (D-BRICK2) ....................................................................5
2.2.5.1
2.2.6
2.2.7
2.2.8
PROCESADOR INTEL® ITANIUM® 2 MCKINLEY.................................. 5
PROCESADOR INTEL® ITANIUM® 2 MADISON. .................................... 5
SISTEMA DE CONTROL ............................................................................. 5
MONITORIZACIÓN DE SISTEMA............................................................. 5
PARTICIÓN DEL SISTEMA ...................................................................5
ANEXO TÉCNICO C: SOFTWARE PARA LA FAMILIA SGI ALTIX 3000
5
3.1 SISTEMA OPERATIVO LINUX .....................................................................5
3.1.1
HISTORIA ...............................................................................................5
3.1.2
LINUX Y SGI ...........................................................................................5
3.1.3
ENTORNO DE DESARROLLO AVANZADO: SGI PROPACK ..............5
3.1.4
PARTICIONES ........................................................................................5
3.2 PRODUCTOS DE SOFTWARE ASOCIADOS ................................................5
3.2.1
COMPILADORES ...................................................................................5
3.2.2
LIBRERIAS, TOOLKITS, Y APIS ............................................................5
3.2.2.1
3.2.2.2
3.2.3
MESSAGE-PASSING TOOLKIT Y OpenMP .............................................. 5
SCSL (SILICON COMPUTING SCIENTIFIC LIBRARIES) ....................... 5
HERRAMIENTAS DE DESARROLLO ....................................................5
3.2.3.1
VTUNE Y PFMOM ....................................................................................... 5
3.2.4
HERRAMIENTAS DE ANÁLISIS DE PRESTACIONES Y MANEJO DE
RECURSOS............................................................................................................5
3.2.4.1
3.2.4.2
PERFORMANCE CoPILOT (PCP) ............................................................... 5
SGI CONSOLE .............................................................................................. 5
2 de 83
3.2.4.3 CSA: Comprehensive System Accounting ..................................................... 5
3.2.4.4 GESTOR DE COLAS DE BATCH. MANEJADOR DE RECURSOS DEL
SISTEMA....................................................................................................................... 5
3.2.5
SISTEMA DE FICHEROS Y SUBSISTEMA DE E/S ...............................5
3.2.5.1
3.2.5.2
3.2.5.3
3.2.6
XFS. SISTEMA DE FICHEROS. .................................................................. 5
XLV / XVM PLEXING ................................................................................. 5
SUBSISTEMA DE E/S .................................................................................. 5
COMO UTILIZAR EL SOFWARE...........................................................5
3 de 83
1
ANEXO TÉCNICO A: DESCRIPCIÓN DE
LA ARQUITECTURA EMPLEADA EN LA
FAMILIA SGI ALTIX 3000
El componente hardware constituye una parte fundamental de un computador
puesto que de alguna forma indica el máximo rendimiento que un equipo será
capaz de ofrecer. Complementariamente será preciso disponer de un sistema
operativo eficaz y versátil que permita manejarlo de manera cómoda y simple y,
por otra parte, que los compiladores y utilidades de desarrollo permitan acercar
al máximo el rendimiento real a los límites que el hardware impone
(prestaciones ideales o “peak performance”).
Probablemente este componente hardware de la familia Altix 3000 constituya la
parte más diferencial y novedosa respecto a la oferta existente en el mercado
informático actual. La tecnología cc-NUMA (cache coherent Non Uniform
Memory Access) evolucionada en su ya tercera generación, constituye un
elemento diferencial e innovador que permite una escalabilidad hasta un
elevadísimo número de procesadores manteniendo altísimos niveles de
eficiencia y siempre gobernados por una única copia de sistema operativo
(Single System Image o SSI).
La primera generación cc-NUMA fue desarrollada en el ámbito experimental en
un proyecto conjunto de SGI con la Universidad de Stanford denominado DASH
y que fue dirigido por Daniel E. Lenoski, director de ingeniería de la división de
sistemas de supercomputación de Silicon Graphics.
En esta primera aproximación fueron estudiadas todas las topologías de
interconexión, los sistemas más adecuados de medición de las características
críticas: ancho de banda y latencia, y las necesidades operativas para conseguir
sistemas que permitiesen llegar hasta un número muy elevado de procesadores
ejecutando aplicaciones paralelas eficientemente y sin renunciar al paradigma
de memoria compartida que proporciona una sencillez de programación
comparativamente muy superior a la proporcionada por las librerías de paso de
mensajes.
La segunda generación de sistemas escalables cc-NUMA fue la versión
comercial y optimizada de la anterior y fue el origen de una nueva familia y
generación de sistemas denominada Origin 2000.
Estos sistemas, de los cuales SGI ha instalado más de 50.000 en el mundo
desde su introducción en 1.996, constituyen una palpable demostración de las
capacidades de procesamiento paralelo y de la fiabilidad, madurez y robustez
de este tipo de arquitectura.
4 de 83
A mediados del año 2.000 SGI introduce su tercera generación de sistemas
escalables cc-NUMA, cuyas características técnicas se detallan a continuación,
y que constituye el núcleo de la oferta presentada.
1.1
ARQUITECTURA SGI ALTIX 3000
Existen numerosas clasificaciones de los distintos tipos de arquitecturas de
computadores multiprocesador o paralelos. Según el criterio de clasificación que
se utilice se pueden aplicar diferentes calificativos a la arquitectura del SGI Altix
3000
1.1.1
DISTRIBUCIÓN DE MEMORIA
Atendiendo al criterio de ubicación de la memoria, se pueden clasificar los
computadores en sistemas de memoria compartida (o “Shared Memory”) y
sistemas de memoria distribuida (o “Distributed Memory”).
Los sistemas de memoria distribuida conllevan que los datos del usuario
estén repartidos a través de las distintas “porciones” de la memoria del sistema
y que este hecho no sea “transparente” al usuario. Esto significa que es preciso
que el programa (o aplicación) distribuya convenientemente los datos y
comunique los cambios en los mismos explícitamente mediante la utilización de
librerías de paso de mensajes (PVM, MPI o SHMEM p.e.), y en definitiva,
implica un sobrecoste importante en cuanto al desarrollo, facilidad de uso y
patología de problemas que conlleva. Como contrapartida, estos sistemas
permiten utilizar un número muy elevado de procesadores, puesto que al
tratarse de arquitecturas distribuidas la ampliación consiste simplemente en
añadir más procesadores y memoria e interconectarlos al sistema.
Por otra parte, los sistemas de memoria compartida permiten un esquema de
programación muchísimo más simple. La generación de códigos para que se
ejecuten en paralelo no implica una recodificación de los mismos en alguna de
las librerías mencionadas sino que especificando unas pocas directivas o
simplemente con la utilización de compiladores con opción de autoparalelización
es suficiente. En su aspecto negativo, este tipo de sistemas no suelen permitir
aplicar esta facilidad de uso más que a unos pocos procesadores (pocas
decenas como mucho).
La familia SGI Altix 3000 es estrictamente un sistema de memoria físicamente
distribuida y lógicamente compartida. Esta dualidad en cuanto a la distribución
de la memoria ha pasado a ser denominada como DSM (“Distributed Shared
Memory”).
5 de 83
En definitiva los sistemas tipo DSM pretenden aunar las mejores características
de los sistemas de memoria compartida (facilidad de uso) y de los de memoria
distribuida (escalabilidad) obviando los inconvenientes que presentan ambos.
1.1.2
LATENCIA DE ACCESO A MEMORIA
Atendiendo al criterio del tiempo de acceso a la memoria desde los
procesadores, existen dos posibles tipos de sistemas: aquellos en que el acceso
a la memoria se produce en un tiempo (latencia) fijo, denominados sistemas
UMA (o Uniform Memory Access), y aquellos en que estos tiempos no son
homogéneos sino que varían en función de qué procesador y qué porción de
memoria consideramos y que se denominan sistemas NUMA (Non Uniform
Memory Access).
En principio el hecho de que se pueda fijar el tiempo de acceso en un único
valor parecería que simplifica el mecanismo y, por tanto, minimiza los posibles
problemas que se puedan generar. Sin embargo, es precisamente este hecho el
que limita el número de procesadores que podemos incorporar. Relajando la
restricción de que los tiempos sean uniformes, es posible conseguir sistemas de
un orden de magnitud superior en cuanto al número de procesadores.
Lógicamente gran parte del éxito se basa en que este tiempo no uniforme de
acceso no empeore significativamente respecto al más pequeño que
corresponde a los accesos más locales en el sistema. Si el acceso a las partes
más lejanas de la memoria conllevase tiempos de acceso muy superiores,
entonces se estaría limitando la eficiencia que pudiera obtenerse en la ejecución
de aplicaciones paralelas. Este tipo de aplicaciones precisan acceder a la
memoria de los distintos procesos (o threads) que la componen y necesitan
periódicamente sincronizar los procesos paralelos antes de iniciar nuevas
secciones de la aplicación. Si los tiempos de acceso empeoran
significativamente, el acceso a los datos y las sincronizaciones limitan
enormemente la eficiencia y por tanto la escalabilidad del sistema.
Entre las máquinas tipo NUMA, existe una característica muy importante
derivada del hecho de que existen distintos procesadores con sus respectivas
memorias cache. Esto propicia la posibilidad de que exista más de una copia de
una misma variable en distintas memorias cache de distintos procesadores que
estén trabajando en paralelo sobre datos compartidos. Cuando existen diversas
copias hay que garantizar que si cualquiera de ellas es modificada por uno de
los procesadores las demás copias serán actualizadas convenientemente para
evitar que trabajen con copias obsoletas de los datos. Esta característica se
denomina coherencia de caché.
6 de 83
1.1.3
COHERENCIA DE CACHÉ
Los sistemas multiprocesador pueden incluir la lógica necesaria y los protocolos
adecuados para garantizar la coherencia de las distintas copias del mismo dato
que puedan existir simultáneamente en el sistema. Por este motivo, los
sistemas NUMA que presentan esta característica son denominados cc-NUMA
(caché-coherent Non Uniform Memory Access).
Una forma sencilla de implementar la coherencia de caché consiste en
monitorizar el tráfico de las conexiones de acceso a memoria y establecer para
cada línea de la caché una señal de estado que indica en qué situación se
encuentra. Suele utilizarse un protocolo de implementación tipo snoopy. Esto
implica un cierto hardware específico que mantenga los estados de las líneas de
caché según las modificaciones que sufran los datos almacenados en ellas y
que se encargue de actualizar las copias de datos que hayan sido modificados
por otros procesadores.
Unos mensajes internos son generados automáticamente para restituir las
líneas de caché cuando los datos que contienen son modificados y enviados a
los nodos del sistema.
Según el esquema que se emplee para estos mensajes es posible que la
escalabilidad del sistema para un número elevado de CPUs sea pobre debido a
que un gran número de mensajes pueden consumir un gran ancho de banda y a
que,además, son muy sensibles a la latencia del sistema.
Es por este motivo que la arquitectura SGI Altix 3000 emplea un esquema
sofisticado de coherencia de caché basado en un directorio. En este directorio –
existe uno en cada nodo - se guarda una lista, para cada línea de caché, de los
otros nodos que comparten la misma línea. En caso de que sea necesario
enviar mensajes de invalidación, éstos sólo son enviados a los nodos que
comparten la línea (o sea, que figuran en la lista) y no a todos los nodos del
sistema, con lo que el coste (en tiempo) de la coherencia de caché no crece con
el tamaño del sistema sino con el grado de compartición de las líneas, que es
una característica del paralelismo de la aplicación, permitiendo al sistema
escalar convenientemente sin que la coherencia de caché constituya un
obstáculo insalvable.
1.1.4
TIPO DE PARALELISMO
Otro tipo de clasificación es el criterio del tipo de paralelismo del sistema. En
este sentido existen sistemas en que las instrucciones paralelas que se ejecutan
son exactamente las mismas sobre conjuntos de datos distintos, y son
conocidos como SIMD (Single Instruction, Multiple Data). Estos sistemas,
también conocidos como sistemas vectoriales, pueden por ejemplo aplicar la
misma operación de suma sobre varios sumandos (32, 64 o 128 es lo habitual)
7 de 83
simultáneamente en el tiempo (en el mismo ciclo de reloj). Otro tipo de sistemas
son aquellos en los que se efectuan operaciones distintas sobre datos distintos
simultáneamente en el tiempo
Estos son denominados MIMD (Multiple Instruction Multiple Data). Por ejemplo,
un sistema de multiprocesadores escalares realiza operaciones distintas sobre
datos distintos en cada procesador y proceso.
En general puede afirmarse que existen ciertos tipos de códigos en que la
aplicación de técnicas de vectorización es muy adecuada y eficiente. Este tipo
de códigos han sido denominados “vectorizables”. Sin embargo, la proporción
de códigos de este estilo es bastante reducida, y además, con la creciente y
constante evolución de los procesadores superescalares, más acelerada que la
evolución de los vectoriales, su utilización va siendo progresivamente más y
más restringida.
En definitiva y según los criterios analizados, podemos tipificar a los SGI Altix
3000 como sistemas de tipo DSM (Distributed Shared Memory), y basados en
una arquitectura cc-NUMA.
1.1.5
TOPOLOGIA
Las arquitecturas de la mayoría de computadores clásicos siguen el esquema
de Von Neuman, es decir: tres subsistemas: de procesamiento o CPU, de
Memoria y de Entrada/Salida conectados a través de una conexión tipo bus.
Este esquema ha sido mantenido hasta muy recientemente, y los sistemas de
Multiprocesadores Simétricos Paralelos (SMP) no son más que una
generalización de este concepto de sistemas basados en bus.
En general el bus tiene una limitación importante en cuanto a su posible
evolución que consiste en que cuanto más se intenta aumentar el ancho de
banda, peores resultan las latencias de acceso a memoria por parte de las
CPUs y a la inversa, cuanto más se intenta reducir la latencia de acceso peor
resulta el ancho de banda resultante.
Las nuevas necesidades en cuanto a cálculo paralelo y las nuevas tecnologías
han permitido substituir una topología de tipo bus por otras de mejores
características.
La primera de las opciones consiste en substituir el bus por un crossbar o
switch. Ello permite que las distintas CPUs accedan simultáneamente a
memoria a través de diversos canales separados.
8 de 83
C
C
C ...
C
switch
Memoria
Figura 1-1: Esquema de topología en switch
Este tipo de solución resuelve perfectamente el problema del ancho de banda
porque el ancho de banda total es el resultado de sumar los de los distintos
canales de acceso a memoria, mientras que la latencia se mantiene constante.
Sin embargo, este tipo de solución tiene un claro inconveniente en cuanto a la
escalabilidad de los sistemas. Si se desea poder escalar hasta un sistema con
N (cientos e incluso miles) de CPUs, entonces se debe dimensionar el crossbar
o switch de N x N. Ello implica que los sistemas con pocas CPUs resultan
costosos puesto que emplean una infraestructura dimensionada para muchos
más procesadores.
Muchos fabricantes que optan por esta solución han detectado este problema y
han limitado la dimensión del crossbar puesto que la mayoría de equipos se
suministran con relativamente pocos procesadores. Por tanto limitando la
escalabilidad de los sistemas a p.ej. 8, 16 o 32 CPUs se cubre una gran parte
del mercado y se conservan las características de coste/prestaciones. Los
sistemas SMP modernos emplean tecnología crossbar o switch para substituir al
bus.
Sin embargo, para sistemas de computación de altas prestaciones que
pretenden ser escalables no sólo en prestaciones sino también en precio, es
necesario adoptar algún otro tipo de solución. Existen básicamente dos tipos de
aproximaciones:
La primera aproximación consiste en introducir dos niveles de crossbar o
switch. A un primer nivel (p.ej. hasta 16 CPUs) el sistema emplea un crossbar o
switch para acceder a memoria. Para configurar sistemas mayores se sitúa un
segundo nivel de switch que enlaza módulos del primer nivel.
9 de 83
C
C ...
C
C
C
C ...
C
C
...
switch
switch
Memoria
Memoria
switch L2
Figura 1-2: Esquema de topología con dos niveles de switch
Este tipo de solución permite alcanzar un mayor nivel de crecimiento pero, sin
embargo, a veces la diferencia de latencias entre ambos niveles de switch hace
que la eficiencia que se obtiene ejecutando aplicaciones entre las CPUs del
primer nivel (hasta 16) cae ostensiblemente cuando se quiere operar con mayor
número de procesadores y hay que acceder a través de este segundo nivel.
La segunda aproximación, adoptada por SGI en su arquitectura Altix, consiste
en utilizar crossbar o switches modulares. Básicamente la idea es substituir el
concepto monolítico de switch N x N por otro de tamaño menor (8x8 en el caso
del Altix, 5x5 para el Origin 3000 y 4x4 para el Origin 2000) formando lo que se
denominan nodos, los cuales se van enlazando a través de una red de
interconexión.
salidas
X
entradas
X
R
X
X
X
Crossbar monolítico
Crossbar modular
10 de 83
En los siguientes apartados se presentará con detalle la estructura de esta red
de interconexión modular y la de los nodos a interconectar.
1.1.5.1
RED DE INTERCONEXIÓN
Esta red de interconexión tiene como objetivo servir de enlace entre todos los
nodos de forma que la memoria dispersa a través de ellos sea compartida por
las CPUs de todos los nodos, al igual que los periféricos asociados a los
distintos subsistemas de entrada/salida conectados a los nodos.
nodo
nodo
Sistema de
Interconexió
n
nodo
nodo
Figura 1-3: Esquema del sistema de interconexión de nodos
La red de interconexión se ha elegido con una topología de hipercubos. De
hecho, para ser más precisos, de hipercubos planos (flat hypercubes). Este tipo
de interconexión tiene una serie de propiedades que son fundamentales para
que la arquitectura SGI Altix 3000 pueda alcanzar su potencial:
•
El ancho de banda total es proporcional al número de nodos. De esta forma,
desde el punto de vista de esta característica, se consigue un
comportamiento lineal en función del tamaño del sistema
11 de 83
•
La latencia sólo crece logarítmicamente con el número de nodos. Así al
aumentar el tamaño del sistema la latencia máxima (la peor posible) crece
en función del log2(N).
•
El “bisectional bandwidth” (flujo máximo de información que atraviesa un
plano imaginario que corta la estructura) es constante por CPU. Dicho de
otra forma: cada CPU tiene asegurado un flujo o caudal de datos constante
independientemente del tamaño del sistema (del número de CPUs).
•
La implementación es en principio más costosa puesto que el número de
interconexiones a realizar es mucho mayor que en otros casos. Por tanto
será crítico que la implementación física de este modelo sea tal que las
interconexiones sean realizadas con el mínimo número de componentes.
Esquemáticamente, los diagramas correspondientes a estructuras de
hipercubos N-dimensionales son como siguen:
0D
1D
2D
3D
=
4D
Figura 1-4: Diagramas de hipercubos N-dimensionales
Con la versiónes de procesadores, nodos y routers actuales se asegura la
interconexión cc-NUMA de hasta 1024 procesadores.
Silicon Graphics está desarrollando los componentes de la próxima generación
de la arquitectura apuntando hacia conjuntos cc-NUMA de más de 30000
procesadores.
12 de 83
2
ANEXO
TÉCNICO
B:
SUPERCLUSTER SGI ALTIX 3000
2.1
INTRODUCCIÓN
EL
La evolución de las diversas tecnologías que componen un sistema sigue unos
ciclos de evolución de períodos radicalmente distintos. Mientras aparecen
variantes del mismo procesador cada 6 o 9 meses (básicamente el mismo pero
a mayor frecuencia), el desarrollo de una nueva familia de procesadores, con
variaciones en la arquitectura del mismo, suele tener una periodicidad de un par
de años. La infraestructura de los equipos, como por ejemplo la del Origin 3000,
suele tener un periodo que ronda los 3 o 4 años. En cambio, las interfaces de
conexión tipo ESA, PCI, etc… suelen tener unos periodos totalmente variables,
muy cortos para algún tipo de tecnología de poco éxito y muy largos para las
que realmente triunfan.
Industry-driven timing
E/S Interfaces
?
Entorno de
sistema
Familia CPU
Velocidad CPU
?
30-42 meses
18-24
meses
6-9
6-9
mes
Months
Figura 2-1: Ciclos de evolución de los componentes de un sistema.
El servidor ALTIX 3000 es un sistema constituido por módulos independientes
cada uno de los cuales desempeña una función básica.
13 de 83
Para evitar la obsolescencia tecnológica de los componentes, SGI ha
desarrollado el ALTIX 3000 con grandes capacidades modulares que permiten
actualizaciones de componentes sin tener que hacer lo mismo con todo el
sistema, protegiendo así considerablemente la inversión y permitiendo que
sistemas "maduros" en el mercado puedan adoptar tecnologías más modernas
aparecidas con posterioridad a su introducción.
2.2
MÓDULOS O BRICKS
La forma de implementar la modularidad es que cada componente del sistema
consista en un módulo aislado o “brick” independiente de los demás y que se
interconecte externamente. Estos “bricks” pueden reemplazarse
independientemente, contienen redundancia interna de ventiladores, control de
errores, etc. y son alimentados eléctricamente por otros bricks que proporcionan
esta funcionalidad.
Los módulos o bricks disponibles son
C-Brick Itanium 2 (Módulo de
computación)
IX-Brick (E/S)
TP900
R-Brick (Router)
PX-Brick (PCI-X)
D-Brick2 (Disco)
14 de 83
Figura 4-2: Fotografías de los diversos módulos
En la siguiente tabla se describen cada uno de los módulos en cuestión:
C-Brick Itanium 2 (CPU Brick)
El C-Brick contiene:
• un nodo con 4 procesadores a las frecuencias de
reloj disponibles
• 3 niveles de caché dentro del chip por procesador
• L1 de datos 16 KB y de instrucciones 16 KB
• L2 de datos de 256 KB
• L3 de datos de
• 1.5 MB para 900 Mhz
• 3 MB para 1000 y 1300 MHZ
• 6 MB para 1500 MHZ
• 8 bancos de memoria. De 4 a 32 GB.
• Controlador de memoria SHUB con ancho de banda
a memoria 8.51-10.2 GB/s
• Ancho de banda agregado de la interconexión de
6.4GB/s
•
•
•
•
PX-Brick (PCI Brick)
Ancho de banda agregado de E/S de 4.8GB/
1 controlador de nivel L1 (system controller)
Ventiladores hot-swap redundantes
Tamaño de 3U
El PX-Brick soporta un máximo de 12 tarjetas PCI-X que se
distribuyen a través de 6 buses PCI. Contiene:
•
•
•
•
•
•
•
•
Basado en el nuevo PIC ASIC (Reemplaza el
Xbridge)de familias precedentes) que suministra la
capacidad PCI-X
12 slots PCI configurables
2 slots por bus
6 buses; cada bus de
• 133Mhz para un PCI simple
• 100 Mhz con 2 slots ocupados
Soporta PCI y PCI-X pero no mezclados sobre el
mismo bus
1 controlador L1 (system controller) con
ventiladores redundantes hot-swap
2 puertos al host para conexión dual
Tamaño de 4 U
15 de 83
R-Brick (Router Brick)
El R-Brick contiene un Router ASIC montado en un PCB con
su circuitería asociada, el controlador L1 (system controller) y
un hub USB. El hub se emplea para enviar las señales USB
del controlador L2 al L1 del interior del brick R y de los 4
nodos (C-bricks) que puede tener conectado el router. Tiene
un total de 8 conectores NUMAlink, 4 para ser conectados a
C-bricks y enviar las señales USB y NUMAlink, y 4 para
conectarse a otros routers y no transmiten señales USB.
También tiene ventiladores redundantes hot-swap.
Tamaño de 2 U
TP900
Almacenamiento de discos en Ultra 160 SCSI
• Hasta 8 discos Ultra 160 SCSI
• Discos de 18 y 73 GB
• Unido a slot SCSI PCI de un IX o PX brick
• Opción de 1-bus o 2-bus
• no L1
• Tamaño de 2 U
• El D-Brick2 tiene 16 ranuras para discos con
redundancia de fuentes de alimentación y
ventiladores. Soporta diferentes tipos de expansión
como los siguientes:
• Tecnología Fibre Channel de 2 Gbit
• High-Density: 16 discos en 3 U
• Capacidad de 18, 36, 73 y 146 GB
• Escalabilidad:
• Configuración RAID desde 4 a 64 discos,
ofreciendo hasta 4.6 TBs de capacidad;
• Configuración JBOD desde 4 a 96 discos,
ofreciendo 7 TB de capacidad.
• Flexibilidad: Configuraciones JBOD pueden ser
reconfiguradas para suministrar 2 veces los accesos
al host(4) y 2 veces el ancho de banda (800 MB/sg)
para vídeo bajo demanda y para aplicaciones de
cálculo intensivo.
• Protección de la inversión: Soportado en un entorno
SAN de 1Gb, suministrando a los usuarios las
características y beneficios de la última tecnología
mientras perdura la transición desde infraestructura
de 1 Gb a 2 Gb
• Alto Rendimiento: 400MB-por-segundo de ancho de
banda para RAID reduce el número de
controladores y ranuras para aplicaciones HDTV
• Alta Disponibilidad: Ventiladores redundantes y hotswap, fuentes redundantes y hot-swap aseguran el
acceso ininterrumpido a los datos
• Tamaño 3U
D-Brick2 (Device Expansion Brick)
16 de 83
Power brick
•
•
2.2.1
Contiene múltiples fuentes de alimentación de 48
VDC. Suministra alimentación AC a 6 fuentes hotswap y proporciona control y monitorización de las
mismas. Más fuentes son añadidas a medida que la
configuración lo requiere.
Montados verticalmente para ahorrar espacio
CPU BRICK ITANIUM 2 (C-BRICK)
Es el módulo en el que se encuentran las CPUs y la memoria del sistema. Su
disposición, formando una red interna con un gran ancho de banda, le confiere
la flexibilidad necesaria para incorporar nuevos elementos y escalar el sistema
de forma independiente, ya sea en capacidad de procesamiento, en opciones
adicionales de Entrada/Salida, de control, de conexión, etc.
Cada módulo C-Brick contiene 4 procesadores, 2 SHUB ASIC y su propia
memoria, que suele denominarse “memoria local”. Cada C-Brick está
configurado en 2 bloques idénticos. Cada bloque tiene 2 procesadores y 1
SHUB. En cada bloque la memoria local consta de 16 DIMMs que están
físicamente repartidos en cuatro grupos. Cada DIMM consta de chips de
memoria DDR SDRAM a 133 MHz o 166MHz, de 256MB o 512MB. Cada SHUB
soporta hasta un ancho de banda de pico con la memoria de 8.5 GB/s. Estos 2
SHUB son el corazón del C-Brick y suministran la inteligencia necesaria entre
procesadores, memoria, conexiones y entrada/salida. Los SHUBs se conectan
entonces a routers de ocho puertos que pueden llegar a interconectar hasta
cientos de procesadores de forma que el ancho de banda crezca al aumentar el
número de procesadores interconectados.
El C-brick permite intercambiar procesadores sin tener que modificar el resto de
la infraestructura del sistema. Así cuando vayan apareciendo las sucesivas
familias de procesadores INTEL ITANIUM 2 (Madison, Montecito) se podrán
realizar mejoras significativas de potencia de cálculo sólo reemplazando estos
elementos y conservando los restantes.
Cada nodo de los módulos C-Brick contiene una electrónica de control que
permite controlar y monitorizar su funcionamiento y que se conoce como L1. Los
diferentes controladores L1 de los módulos de un rack pueden conectarse a
través de canales USB a un controlador de segundo nivel, el controlador L2, que
permite controlar y monitorizar de forma conjunta ese conjunto de módulos. Más
adelante se volverá a tratar el sistema de control y monitorización L1 y L2 del
SN2-Itanium2.
El C-Brick tiene las siguientes características:
•
•
•
un nodo con 4 procesadores a 900 o 1000 MHZ (1300 y 1500 MHZ en
la siguiente generación).
3 niveles de caché dentro del chip por procesador
L1 de datos 16 KB y de instrucciones 16 KB
17 de 83
•
•
•
•
•
•
•
•
•
L2 de datos de 256 KB
L3 de datos de
• 1.5 MB para 900 MHZ
• 3 MB para 1000 y 1300 MHZ
• 6 MB para 1500 MHZ
32 DIMMS de memoria. De 4 a 32 GB.
Controlador de memoria SHUB con ancho de banda a memoria 8.5110.2 GB/s
Ancho de banda agregado de la interconexión de 6.4 GB/s
Ancho de banda agregado de E/S de 4.8GB/s
1 controlador de nivel L1 (system controller)
Ventiladores hot-swap redundantes
Tamaño 3 U.
Cada módulo de CPU soporta hasta 32 GB de DDR-SDRAM. Hasta 8 módulos
C-brick pueden disponerse por cada rack, totalizando 32 CPUs por rack.
Figura 4-3: C-brick, vista anterior
18 de 83
Figura 2-4: C-brick vista posterior
Cada módulo de CPU soporta hasta 32 GB de DDR-SDRAM. Hasta 8 módulos
C-brick pueden disponerse por cada rack, totalizando 32 CPUs por rack.
En la siguiente figura se puede ver un esquema de un nodo y de la
interconexión de los módulos base en la configuración mínima de servidor Altix
3000:
Fig. 2-1 Diagrama de la arquitectura de un nodo de Altix 3000
Todas las conexiones son de tipo full-duplex de forma que es posible efectuar
operaciones simultáneas en ambos sentidos. De esta forma, mientras una CPU
está por ejemplo accediendo a memoria, otra puede estar simultáneamente
haciendo Entrada/Salida y otra cpu de otro nodo remoto puede estar
accediendo a la memoria local de este nodo a través de la red de interconexión.
El nodo es la pieza básica de todo el sistema ALTIX. Su disposición mediante
una red de interconexión formada por routers, permite escalar el sistema hasta
64 cpus con una sola imagen de sistema operativo LINUX y a cientos de CPUs
mediante el uso de memoria globalmente compartida de una forma altamente
eficiente gracias a su enorme ancho de banda y a su reducida latencia.
19 de 83
En las figuras, los canales NX y II representan 2 canales NUMAlink (6.4 GB fullduplex) y dos canales Xtown2 (2.4 GB full-duplex) respectivamente. Los canales
NUMAlink configuran la red de interconexión entre SHUBs y routers. Los
canales Xtown2 se conectan con los módulos de E/S.
Además, por cada nodo hay un controlador L1 para el control y monitorización
del nodo, así como un regulador de potencia.
Cada C-Brick contiene un puerto USB para conectarse al controlador L2, para el
control y monitorización del C-Brick, y un puerto de consola DB9
Figura 2-2: Servidor de 16 CPUs
2.2.1.1
PROCESADOR INTEL® ITANIUM® 2 MCKINLEY
El servidor Altix 3000 funciona con la segunda implementación de Intel de
Itanium Instruction Architecture (ISA) denominado Itanium® 2. Este procesador
inicia la segunda generación de procesadores diseñados específicamente para
la arquitectura de 64 bits de Intel®.
El procesador Intel® Itanium® 2 ha sido diseñado para satisfacer las
necesidades de alta computación sobre servidores y estaciones de trabajo. La
20 de 83
arquitectura Itanium va más allá de las tradicionales arquitecturas RISC y CISC
empleando la nueva arquitectura EPIC(Explicitly Parallel Instruction Computing),
que permite la ejecución explícita en paralelo de un conjunto de instrucciones
mediante el uso inteligente del compilador
Los conceptos de diseño EPIC se basan en un fuerte acoplamiento entre el
software y el hardware, utilizando toda la información disponible en tiempo de
compilación y así darle el trabajo resuelto al procesador para que lo procese
eficientemente. Con ello, se eliminan muchos de los actuales cuellos de botella
que existen como pueden ser la latencia a memoria, ambigüedades en el
direccionamiento a memoria y dependencias en el flujo de control. La
construcción EPIC configura una arquitectura tan potente que posibilita al
compilador realizar optimizaciones globales a través de todo el flujo de
ejecución permitiendo Paralelismo al nivel de Instrucciones (ILP). El procesador
aprovecha la ventaja de este avanzado ILP permitiendo la ejecución en paralelo
de numerosas instrucciones. Adicionalmente, se realizan optimizaciones al nivel
de ejecución que permiten al código compilado ejecutarse con altísimas
prestaciones. Esta estrategia de diseño propicia la completa sinergia entre
hardware y software y la obtención de unos resultados de computación
extraordinarios.
El procesador Itanium® 2 suministra un pipeline de 6 vías y 8 etapas a la
velocidad de 1 GHZ y 900 MHZ (1300 y 1500 MHZ en la próxima generación).
Los recursos disponibles consisten en 6 unidades de enteros, 6 unidades
multimedia, 2 unidades de Load y Store, 3 unidades de bifurcación (branch), 2
unidades de coma flotante de precisión extendida y 2 unidades de coma flotante
de simple precisión. Emplea prefetch dinámico, predicción de bifurcación,
marcador de registro y caché no bloqueantes. El empleo de 3 niveles de caché
en el propio chip permite reducir la latencia a memoria. Con los 3 MB o 1.5 MB
(hasta 6 MB en la próxima generación) de caché de nivel 3 el acceso a memoria
se realiza a gran velocidad proporcionando un ancho de banda a los datos de
más de 32 GB/ciclo. El sistema de bus ha sido diseñado para soportar hasta 4
procesadores y es empleado para construir grandes sistemas en bloques como
es el caso del ALTIX 3000. El Itanium® 2 ha sido diseñado para soportar
arquitecturas escalables, por lo que la arquitectura del Altix 3000 es la mejor
para proporcionar la potencia y el rendimiento necesarios para las aplicaciones
de alta computación demandadas por usuarios técnicos y creativos.
Las características RAS del procesador (reliability, availability and serviceability)
permiten mantener un flujo de procesamiento continúo en todo momento.
2.2.1.1.1
6-WIDE EPIC
El diseño del procesador Itanium® 2 incluye un pipeline de 6 vías y 8 etapas,
basado en la tecnología EPIC. El pipeline utiliza las siguientes unidades de
ejecución: 6 unidades multimedia, 2 unidades de Load y Store, 3 unidades de
bifurcación (branch), 2 unidades de coma flotante de precisión extendida y 2
unidades de coma flotante de simple precisión. El procesador es así capaz de
21 de 83
cargar, manejar, ejecutar y postprocesar 6 instrucciones por ciclo de reloj
mediante la carga de 2 bloques de instrucciones
Un bloque de instrucciones contiene 3 instrucciones y un indicador asignado por
el compilador. Cada instrucción en el bloque está de hecho asignada a uno de
los pipeline de ejecución siguiendo la siguiente nomenclatura: ALU de enteros
(A), NON-ALU de enteros (I), Memoria (M),
ALU de flotantes (F), bifurcación (B) o Extendida (L). El Itanium 2 triplica a su
predecesor en unidades de ejecución.
Los siguientes ejemplos dan idea del nivel de operaciones paralelas soportadas
por varias cargas de trabajo.
•
Para códigos de base de datos, la plantilla MII/MBB suministra 6
instrucciones u 8 operaciones paralelas por ciclo de reloj (2 load/store, 2
operaciones generales de ALU, 2 operaciones ALU pos-incremento y 2
bifurcaciones) Alternativamente, la plantilla MIB/MIB permite las mismas
6 operaciones pero con una indicación de bifurcación y una operación
de bifurcación en vez de dos operaciones de bifurcación.
•
Para códigos científicos, el uso de la plantilla MFI en cada bucle
posibilita 12 operaciones paralelas por ciclo de reloj, esto es 4 cargas
de operandos a los registros, 4 operaciones de flotantes en doble
precisión, 2 operaciones de enteros y 2 operaciones postincrementales.
Para códigos de creación de contenidos digitales que son operaciones de coma
flotante en simple precisión, las características SIMD en los procesadores
permiten ejecutar hasta 20 operaciones paralelas por ciclo de reloj: 8 cargas de
operandos a los registros, 8 operaciones de coma flotante en precisión simple, 2
operaciones de enteros y 8 operaciones post-incrementales
2.2.1.1.2
Pipeline
El procesador está organizado en 8 etapas de pipeline, que pueden ejecutar
hasta 6 instrucciones en paralelo por ciclo de reloj.
En la próxima figura se puede apreciar la organización del pipeline.
22 de 83
2.2.1.1.3
Diagrama de bloques
Las funciones del procesador pueden clasificarse en los siguientes 5 grupos:
•
Procesado de instrucciones: contiene la lógica necesaria para realizar el
prefetch, la carga de instrucción, el “cacheado” de instrucciones en el
nivel L1, los saltos con predicción, la generación de la dirección de la
instrucción, el buffer de la instrucción, etc.
•
Ejecución: está constituido por la unidad lógica multimedia, la unidad de
ejecución de enteros, la unidad de ejecución de coma flotante, el fichero
23 de 83
de registros de enteros, la caché de datos L1 y el fichero de registros de
coma flotante.
•
Control: está constituido por el manipulador de excepciones y el pipeline
de control, así como la pila de registros. (RSE)
•
Subsistema de memoria: contiene la caché L2, la caché L3 (ambas
internas), controlador de interrupciones programables (PIC), la TLB, la
ALAT y la interfaz con el bus externo de sistema
•
El motor de ejecución de compatibilidad con IA-32: las instrucciones IA32 son cargadas, decodificadas y ejecutadas por este módulo..
24 de 83
2.2.1.1.4
Subsistema de memoria
Al sistema de memoria principal se accede a través del bus de sistema de 128
bits. Soporta todos los accesos a memoria no-alineados de IA32, lo cual es muy
importante para recompilar códigos de IA32 de 32 bits.
Las caches L1, L2 y L3 son no bloqueantes
L1 Instrucciones
L1 Datos
L2
L3
Como se puede ver en el esquema a nivel L1 tenemos 2 cachés para datos e
instrucciones.
La caché L1 de instrucciones tiene un tamaño de 16 KB, se accede a ella en 1
ciclo, no es bloqueante, es dual port 4-way set-associative y tiene un tamaño de
línea de 64 bytes. Uno de los puertos se utiliza para la carga de las
instrucciones mientras que el otro se utiliza para almacenar prefetch, snoops e
invalidaciones de filas y columnas. Soporta lecturas y escrituras simultáneas.
Con todo ello puede ofrecer 2 bloques de instrucciones por ciclo de reloj
La caché L1 de datos es de 4 puertos y tiene también un tamaño 16 KB. Está
organizada como 4-way set-associative con un tamaño de línea de 64 bytes.
Soporta 2 cargas y almacenamientos (load-store) concurrentes. Cachea
solamente datos enteros (no flotantes)
La caché L2 sirve tanto para datos como para instrucciones. Tiene 256 KB de
tamaño, 4 puertos y soporta hasta 4 accesos concurrentes. Es 8-way setassociative con un tamaño de línea de 128 bytes, constituida por bancos de 16
bytes, no bloqueantes y out-of-order. Tiene un ancho de banda de lectura de 64
GB por segundo manejando todos los accesos de coma flotante a memoria.
25 de 83
La cache L3 está incluida dentro del chip y su tamaño varia en las diversas
implementaciones del procesador. Es de puerto simple, no bloqueante, 12 way
set-associative con un tamaño de línea de 128 bytes. Puede soportar 8
peticiones, 7 de ellas para load/store y 1 para rellenar. El caudal máximo de
transferencia desde la caché L3 a L1 o L2 es de 32 GB/ciclo. Protege los datos
mediante corrección de errores (ECC)
2.2.1.1.5
Itanium 2 sobre la arquitectura cc-NUMA
Dado que la arquitectura cc-NUMA del Altix presenta la propiedad de latencias
variables en el acceso a memoria, el procesador Itanium 2 está diseñado para
tolerar al máximo estas latencias de acceso. Para ello está dotado de ejecución
fuera de orden (out of order execution), acceso a la memoria caché no
bloqueante, especulación dinámica y otras características que hemos detallado
anteriormente
El diseño del Altix 3000 permite substituir los procesadores Itanium 2 por
procesadores INTEL de las siguientes generaciones asegurando totalmente la
compatibilidad.
26 de 83
2.2.1.2
PROCESADOR INTEL® ITANIUM® 2 MADISON.
El procesador Itanium® 2 Madison es el nombre (interno de desarrollo) que
recibirá la siguiente generación de procesadores de 64 bits de Intel®. Las
prestaciones presentes en el procesador se pueden comprender mejor desde la
descripción del procesador Itanium® 2 realizada en el anterior apartado y
enunciando las mejoras en prestaciones que presenta frente a su predecesor:
•
•
•
•
•
•
2.2.1.2.1
Aumento de un 50% en la frecuencia de reloj [1.5 GHz]
Tecnología de fabricación de 0.13 µ
Duplicación de la capacidad de la caché L3
Incremento de un 50% del ancho de banda total de acceso a memoria
caché.
Reducción en el consumo eléctrico.
Mejora en el control de temperatura
Comparación de memorias caché
Caché L3 de Itanium® Caché L3 de Itanium® 2
2
Madison
1.5-3MB en chip
6MB en chip
12-way
24-way
12-15 ciclos de reloj 14-17 ciclos de reloj de
de latencia
latencia
Ancho de banda 32 Ancho de banda de 48 GB/s
GB/s
2.2.1.2.2
Bus de datos
El bus de datos ha sido mejorado para proporcionar una incremento del 100%
en prestaciones comparado con el anterior procesador Itanium 2. Dispone de
128 bits de anchura y la frecuencia del reloj es de 200 MHZ 400MT/s, siendo
capaz de lograr un ancho de banda de 6,4 GB/s.
2.2.1.2.3
Compatibilidad con Itanium 2
Los códigos binarios generados para el procesador Itanium 2 son compatibles
con Madison y hacen uso de sus mejoras en cuanto a prestaciones (de un 50%
a un 100%) sin necesidad de recompilación. Debido a la recompilación de la
microarquitectura del Itanium 2 se espera una mejora de un 10% adicional,
dependiendo de la aplicación.
27 de 83
(Estos datos corresponden a la comparación del Itanium 2 a 1.0, GHZ y con 3
MB de caché con un Madison a 1.5 GHZ y con 6 MB de caché).
2.2.2
ROUTER BRICK (R-BRICK)
El router permite interconectar C-Bricks a partir de 16 procesadores.
El R-brick contiene un chip (ASIC) con el router montado en un PCB, el sistema
de alimentación de potencia, un controlador L1 (system controler) y un hub
USB. El Hub se emplea para enviar las señales USB del controlador L2 al
controlador L1 del R-brick y a los cuatro nodos (C-bricks) que como máximo,
puede tener directamente conectados cada router.
La mitad de las conexiones NUMAlink al R-brick están destinadas para conectar
los C-bricks. Estas cuatro conexiones soportan las señales USB y las señales
NUMAlink simultáneamente. Las otras cuatro conexiones para interconectarse a
otros routers transmiten señales NUMAlink únicamente.
El R-Brick tiene las siguientes características:
•
•
•
•
2U de alto por 25-pulgadas de profundidad
3.2 GB/s por cada puerto
48V DC de entrada
ventiladores redundantes N+1 y hot-plug
Figura 2-3: R-brick
Figura 2-4: Conexión interna del router
28 de 83
Como se está indicando, la red de interconexión está basada en una estructura
cuyo elemento básico de conexión es conocido con el nombre de Router, por
su similitud funcional con los routers de redes convencionales que deciden y
ponderan las rutas, posibilitando encauzar los datos por el camino más
adecuado. Sin embargo se trata de un diseño mucho más rápido y compacto
implementado mediante un único chip o ASIC. Estructuralmente los routers son
otro crossbar de 8 x 8. Las conexiones son de 3.2 GB/s y por tanto su ancho de
banda total asciende a 25.6 GB/s. Al tratarse de un crossbar se permiten
conexiones simultáneas entre pares de nodos de forma concurrente.
Los enlaces físicos entre routers son denominados NUMAlinks; pueden
transmitir información a 3.2 GB/s con capacidad de conexión full-duplex.
Como se ha visto anteriormente, el C-brick es capaz de ofrecer 6.4 GB/s de
ancho de banda. Debido a que actualmente la tecnología NUMAlink maneja 3.2
GB/s se ha optado por incorporar doble router a la arquitectura del Altix 3000
(Dual Plane). Con ello se consiguen unos anchos de banda de acceso a
memoria sin parangón en el mercado
6.4
GB/s
29 de 83
2.2.2.1
DISPOSICIÓN DE LOS NODOS, ROUTERS Y NUMALINKS
Hasta el momento se ha descrito una arquitectura formada por nodos
conectados a través de una red de interconexión cuya topología de hipercubos
se implementa mediante conexiones NUMAlink y routers para enlazarlos. Ahora
se tratará de como se disponen todos estos elementos para formar sistemas
completos.
Tal como se ha detallado en la descripción de los nodos, se puede llegar a
disponer de hasta 4 procesadores por nodo; por tanto, para configuraciones de
hasta 4 CPUs, sólo se utiliza un nodo sin precisar de ninguna red de
interconexión.
^Por encima de 4 procesadores, para 8 y 12 procesadores se emplean 2 y 3
nodos respectivamente. Como la conexión es única no precisan de Router y se
conectan directamente entre ellos, conformando lo que sería un hipercubo de
una dimensión, es decir, un segmento o un triángulo.
Figura 2-5:Esquema Altix 3000 hasta 8 CPUs
30 de 83
Figura 2-8 :Esquema Altix 3000 hasta 12 CPUs
Para el caso de 16 procesadores se requiere la intervención de la figura del
router
31 de 83
ROUTER
Plane 1
Plane 2
ROUTER
Fig. 2-9: Esquema Altix 3000 hasta 16 CPUs
Por encima de los 16 procesadores se debe recurrir a la red de interconexión
mediante routers dispuestos en configuración hipercúbica. Para el caso de un
sistema de hasta 32 procesadores tendremos la configuración que sigue
32 de 83
Fig. 2-10 Esquema Altix 3000 hasta 32 CPUs
Entre 32 y 64 Cpus la configuración corresponde a la de un hipercubo de 2
dimensiones como el de la siguiente figura:
Figura 2-11: Esquema Altix 3000 hasta 64 CPUs
Actualmente SGI emplea un kernel de Linux que escala hasta 64 cpus. A partir
de dicho número de CPUs se debe utilizar una arquitectura complementaria: el
supercluster.
2.2.2.2
SUPERCLUSTER
Para los usuarios que precisan de gran capacidad de computación, acceso a
memoria y gestión de grandes volúmenes de datos, como en los sectores de
gobierno y defensa, ciencias e investigación, industria, energía y media, los
superclusters SGI Altix 3000 ofrecen espectaculares incrementos en
escalabilidad y prestaciones sobre los clusters tradicionales de Linux y sobre los
servidores basados en el sistema operativo UNIX. Cada nodo tiene una sola
33 de 83
imagen del sistema operativo Linux con hasta 64 procesadores Itanium 2 y 512
GB de memoria. Utilizando múltiples nodos junto con la interconexión
propietaria de SGI NUMAlink, la transmisión de datos es hasta 200 veces más
rápida que con los métodos convencionales de “clustering”, lo que permite que
SGI Altix 3000 escale hasta cientos – y en el futuro hasta miles – de
procesadores.
Los superclusters SGI Altix 3000 funcionan como supercomputadores porque
son los primeros clusters de Linux del mundo que proporcionan memoria global
compartida a través de nodos y sistemas operativos. Normalmente los
supercomputadores requieren cantidades masivas de memoria para afrontar
complicados modelos como pronóstico climatológico o simulación de túneles de
viento para el diseño de aeronaves, que no pueden ser resueltos fácilmente en
sistemas más pequeños. La comunión de memoria global compartida y
sistema operativo Linux abre nuevas posibilidades de trabajar a los usuarios
técnicos y creativos sobre una plataforma estándar, fabricada como un cluster
pero que funciona como un supercomputador, consiguiendo que las
prestaciones de la memoria de un cluster igualen las de la memoria principal de
un equipo SSI, Además se opera con un conjunto estándar de interfaces de
programación como puede ser MPI
Figura 2-6: Cluster tradicionales
Figura 2-7: Supercluster SGI Altix 3000
34 de 83
La memoria compartida se traduce en que todos los nodos operan en un único
gran espacio de memoria, en lugar de tener cada uno su propio espacio de
memoria de reducido tamaño. Con ello todos los nodos pueden acceder a un
gran espacio de memoria eficientemente, de forma que no es necesario el paso
de datos entre nodos ni establecer complejas comunicaciones. Así grandes
conjuntos de datos caben completamente en memoria, por lo que son
necesarios menos accesos a disco La memoria compartida es eficiente,
rentable y fácil de implementar, requiriendo menos memoria por nodo, ya que
los grandes problemas pueden resolverse en la memoria compartida
Interconexión NUMAlink ® NUMAflex™
Memoria global compartida
Sistema de ficheros compartido CXFS™
Almacenamiento de alta velocidad en SAN
35 de 83
Para el sistema de 128 CPUs hay que formar un hipercubo de 3 dimensiones:
Fig. 2-2 Esquema de Altix 3000 hasta 128 CPUs
Las 256 CPUs se consiguen completando un hipercubo plano de 4
dimensiones. El hipercubo plano de cuatro dimensiones se puede entender
como dos cubos de tres dimensiones entre los que se interconectan los vértices
de forma simétrica.
Y las 512 CPUs se configuran con un hipercubo de 5 dimensiones:
36 de 83
Fig. 2-3 Esquema de un Altix 3000 de 512 CPUs
Fig. 2-4 Racks necesarios en un Altix 3000 de 512 CPUs
37 de 83
Obsérvese que para formar un hipercubo de cinco dimensiones se utiliza la
figura del metarouter, que no deja de ser un “router de routers”. En un futuro se
podrán interconectar de esta esta forma miles de procesadores.
2.2.3
INPUT/OUTPUT BRICK (IX-BRICK)
El IX-Brick atiende a las necesidades básicas de Entrada/Salida del Altix 3000, y
además proporciona la infraestructura necesaria para arrancar un sistema
multirack. Utiliza el protocolo PCI o el PCI-X. El protocolo PCI-X posibilita
conectar dispositivos de E/S para operar a una velocidad de reloj de hasta 133
MHz, o 1 GB/s. Este protocolo permite también operar a los dispositivos de E/S
más eficientemente proporcionando un ancho de banda sostenido muy alto.
El IX-Brick tiene las siguientes características técnicas:
•
•
•
•
•
•
•
•
2 Discos Ultra 160 SCSI de 36 GB, en configuración mirroring si se
desea, para alojar el sistema operativo
Hasta 12 tarjetas PCI-X montadas en carriles en 6 buses PCI-X que
soportan 32 bit y 64 bit en modo PCI y PCI-X
E/S básica en la placa madre (IO9). Ocupa de 1 a 3 slots PCI-X con:
• 10/100/1Gbit Ethernet
• 1 puerto externo Ultra 160 SCSI
• 2 puertos serie y 2 opcionales
• Interrupciones en tiempo real
IDE removible media controller
1 ATA DVD-ROM (16X DVD / 48X CD)
Un controlador L1 (system controller)
3 ventiladores redundantes y hot-swap
Tamaño de 4 U
Figura 2-8: IX-Brick
3 PIC (PCI Interface Chip) ASICs son el componente clave del IX-brick. Estos
ASICs soportan 2 puertos 1200 o 800-MB/s Crosstown2 XIO autosensible y 6
38 de 83
buses PCI-X. Cada bus tiene 2 slots en los cuales se pueden instalar tarjetas
PCI. (Slot 1 del bus 1 contiene la tarjeta IO9)
Figura 2-9: Conexiones del IX-Brick
Al disponer de 2 slots XIO se consigue aumentar al doble el ancho de banda del
sistema de E/S. Como las conexiones son full duplex de 2.4 GB/s el ancho de
banda agregado que se consigue es de 4.8 GB/s.
Otro de los aspectos fundamentales es el hecho de poner conectar el IX-Brick a
2 C-Bricks diferentes de tal forma que si uno de los C-Bricks falla, el sistema
puede seguir arrancando a través del otro C-Brick.
Una característica muy importante además de la propia arquitectura del IX-brick
es la tarjeta PCI IO9. Esta tarjeta contiene la lógica que controla el DVD-ROM y
el SCSI interno además de contener las siguientes conexiones:
•
Puerto externo SCSI VHDCI.
39 de 83
•
•
•
•
•
Puerto interno SCSI para conectar los 2 discos SCSI.
Gigabit Ethernet RJ45.
2 interrupciones Tiempo Real
2 puertos serie RS-232 DB-9
Adicionalmente es posible añadir 2 puertos serie RS-232 DB-9.
Figura 2-10: Tarjeta PCI IO9
Esta independencia de la tecnología de conexión de periféricos se traduce en la
protección de la inversión durante un periodo prolongado de tiempo.
De esta forma los dispositivos de entrada/salida son compartidos por todos los
procesos independientemente de su ubicación física en cualquiera de los nodos
del sistema. Además, el hecho de que estén conectados de forma repartida
permite el acceso en paralelo a los dispositivos y así disponer del ancho de
banda acumulado de todos ellos.
Se puede ver cómo las conexiones XIO convierten la señal a bus PCI, pudiendo
entonces conectarse a él tarjetas de entrada/salida.
Con todo ello se consigue que distintas CPUs de estos nodos o de otros nodos
remotos que accedan a través de la red de interconexión, puedan estar
trabajando de forma simultánea con los periféricos de entrada/salida conectados
en cualquiera de los canales XIO o a los de los PCI, mientras se producen otros
accesos a memoria locales o remotos
40 de 83
Figura 2-11: Pista posterior del IX-Brick
Para optimizar la eficiencia de las tarjetas PCI, hay que considerar los
siguientes aspectos de configuración antes de instalar las tarjetas:
•
•
•
•
•
•
•
Se pueden insertar 1 o 2 tarjetas PCI cards en cada bus, o 1 o 2 tarjetas
PCI-X en cada bus.
Se debe evitar mezclar tarjetas que operen a diferentes frecuencias o
en diferentes modos. Si se tienen 2 tarjetas de diferentes velocidades
sobre el mismo bus, dicho bus operará a la velocidad más baja. Si una
tarjeta PCI y una PCI-X están sobre el mismo bus, entonces ambas
funcionarán en modo PCI. Como ejemplo tenemos los siguientes:
Cuando 1 tarjeta PCI-X 133 MHz reside sobre un bus, la tarjeta opera a
133 MHz en modo PCI-X.
Cuando 2 tarjetas PCI-X 133 MHz residen sobre un mismo bus, las
tarjetas operan a 100 MHz en modo PCI-X.
Cuando 2 tarjetas PCI-X 66 MHz residen sobre un mismo bus, las
tarjetas operan a 66 MHz en modo PCI-X.
Cuando 2 tarjetas PCI 66 MHz residen sobre un mismo bus, las tarjetas
operan a 66 MHz en modo PCI.
Cuando 1 tarjeta PCI 66 MHz y una PCI-X 66 MHz residen sobre un
mismo bus, las tarjetas operan a 66 MHz en modo PCI.
41 de 83
•
•
2.2.4
Cuando 2 tarjetas PCI 33 MHz residen sobre un mismo bus, las tarjetas
operan a 33 MHz en modo PCI.
Cuando 1 tarjeta PCI 66 MHz y una PCI 33 MHz residen sobre un
mismo bus, las tarjetas operan a 33 MHz en modo PCI.
PCI-X BRICK (PX-BRICK)
El PX-Brick es un sistema de expansión PCI-X que permite albergar hasta 12
ranuras PCI o PCI-X, implementadas como 6 buses PCI-X de alta velocidad
(133 MHz) con dos slots cada uno.
Tiene 2 puertos Xtown2 (XIO) a 1.2 GB/s en cada dirección con lo que se
pueden tener hasta 4.8 GB/s de ancho de banda.
Los 12 slots PCI-X soportan:
• 1 tarjeta PCI-X a 133-MHz en un slot del bus y el otro vacío..
• 2 tarjetas PCI-X a 100-MHz o 2 PCI-X a 66-MHz sobre un bus.
• 2 tarjetas PCI a 66-MHz o 2 PCI a 33-MHz sobre un único bus.
El PX-Brick tiene las siguientes características técnicas:
•
•
•
•
•
•
•
•
Basado en el nuevo PIC ASIC (Reemplaza el Xbridge) que suministra la
capacidad PCI-X
12 slots PCI slots configurables
2 slots por bus
6 buses; cada bus de 133Mhz para un PCI simple, 100 Mhz con 2 slots
ocupados
Soporta PCI y PCI-X pero no mezclados sobre el mismo bus
1 controlador L1 (system controller) con ventiladores redundantes hotswap
2 puertos al host para dual attachment
Tamaño de 4 U
42 de 83
Figura 2-12: PX-brick
Figura 2-13: Diagrama de Bloques del PX-brick
2.2.5
DISK BRICK2 (D-BRICK2)
El D-brick2 es el módulo de mayor rendimiento para soluciones escalables noRAID para cualquier servidor SGI.
Cada bandeja contiene de 2 a 16 discos y los componentes para realizar las
operaciones de E/S, encendido y refrigeración.
El DBRICK puede instalarse en racks estándar de 19”, en los racks del Altix
3000, o bien en un rack específico. El módulo es exactamente el mismo que el
producto TP-9100, pero sin los plásticos de soporte.
Los discos se configuran como JBOD. Cada módulo dispone de dos entradas
eléctricas redundantes y los discos se pueden conectar en doble canal (dual
loop). También dispone de ventiladores redundantes N+1 y hot-swap.
Actualmente los discos disponibles son de 18, 36, 73 y 146 GB
43 de 83
Figura 2-14: D-BRICK2
El D-Brick2 tiene las siguientes características técnicas:
•
•
•
•
•
•
•
16 ranuras para discos con redundancia de fuentes de alimentación y
ventiladores.
Tecnología Fibre Channel de 2 Gbit
Alta densidad: 16 discos en 3 U
Capacidad de 18, 36, 73 y 146 GB
Escalabilidad:
• Configuración RAID desde 4 a 64 discos, ofreciendo hasta 4.6 TB
de capacidad (en montaje TP9100)
• Configuracion JBOD desde 4 a 96 discos, ofreciendo 7 TB de
capacidad.
Flexibilidad: las configuraciones JBOD pueden ser reconfiguradas para
suministrar 2 veces los accesos al host(4) y 2 veces el ancho de banda
(800 MB/s) para vídeo bajo demanda y para aplicaciones de cálculo
intensivo.
Protección de la inversión: soportado en un entorno SAN de 2Gb,
suministrando a los usuarios las características y beneficios de la última
tecnología mientras perdura la transición desde infraestructura de 1 Gb
a 2 Gb
44 de 83
•
•
•
Alto Rendimiento: 400MB-por-segundo de ancho de banda para RAID
reduce el número de controladores y espacio para aplicaciones HDTV.
Alta Disponibilidad: tanto los ventiladores como las fuentes de
alimentación son redundantes y hot-swap, lo que asegura el acceso
ininterrumpido a los datos
Tamaño 3U
Figura 2-15: Rack de discos
2.2.5.1
PROTECCIÓN FÍSICA DE LOS DISCOS
Cada disco duro está montado sobre una cubierta de aluminio. Esta montura
protege al disco de frecuencias de radio, electromagnéticas y daños físicos.
45 de 83
Figura 2-16: D-BRICK2: Módulo Drive Carrier Modules y módulo “Dummy”
2.2.6
TP900
El módulo de almacenamiento SGI TP900 está basado en Ultra 160 SCSI. Es
montable en rack, tiene un tamaño de 2U por módulo y permite alojar hasta 8
discos JBOD (“just a bunch of disks”).
El backplane del TP900 conecta hasta 8 discos en un bus SCSI. Como una
opción, el sistema de almacenamiento puede ser configurado sobre 2 buses
SCSI (2 canales de 4 discos) permitiendo doble ancho de banda de acceso a
los discos y mirroring.
El módulo TP900 tiene las siguientes características:
•
•
•
•
•
•
•
8 discos SCSI de 3.5 pulgadas.
Discos de 18 y 73 GB.
Conexión Ultra 160 SCSI.
Opción de 1 o 2 canales.
Fuentes de alimentación y ventiladores redundantes.
Cobertura de protección sobre cada disco para prevenir accidentes.
El mejor precio/rendimiento
46 de 83
•
Tamaño de 2 U
Figura 2-17: TP900. Vista frontal
Figura 2-18: TP900. Vista posterior
2.2.7
POWER BAY
La “Power Bay” es un dispositivo de 3U que aloja hasta un máximo de 6 fuentes
de alimentación hot-swap distribuidas(DPSs).
La “power bay” monitoriza, controla y suministra fuente continua a las fuentes de
alimientación de los BRICK.
Aunque la “power bay” puede llevar hasta 6 fuentes, en este sistema contiene
de 3 a 5, dependiendo si son racks de computación o de E/S
Cada entrada de la fuente es monofásica AC con un voltaje de 950 Wat 48 VDC
y 42 Wat 12 VDC. Las salidas de las fuentes son medidas conjuntamente. Por
ejemplo, cuando la power bay contiene 3 fuentes, estas son unidas para
47 de 83
suministrar aproximadamente 2,760 W de potencia 48 VDC y 135 W de 12
potencia VDC
48 de 83
Figura 2-19: Power Bay
Figura 2-20: DPS
2.2.8
MODELOS ALTIX 3300 Y 3700: RACKS Y SISTEMA DE
CONTROL
Los módulos se alojan en racks estándar de 19 pulgadas de ancho y 40 U de
altura para la versión Altix 3700 y de 17 U para el modelo Altix 3300.
En la siguiente figura podemos ver dichos racks:
49 de 83
Figura 2-21: Racks de Altix 3000
Un servidor Altix 3700 puede crecer hasta albergar 512 procesadores Intel
Itanium 2 con un mínimo de 1 IX-brick por cada 64 procesadores, y un mínimo
de 4 routers de 8-puertos por cada 32 procesadores. El sistema mínimo se
ubica en 1 tall rack de 40U con al menos una fuente de alimentación y una PDU
monofásica. (La PDU monofásica tiene 2 aberturas con 3 cables que se
extienden desde cada abertura hasta la fuente de alimentación). Las PDUs
trífásicas tienen 2 aberturas con 6 cables que se extienden desde cada abertura
hasta 2 fuentes de alimentación.
50 de 83
Cada tall rack contiene C-bricks con un controlador L2. Este controlador L2 es
un display que se puede utilizar para operar y está incorporado en el primer rack
del sistema (001)
Se pueden añadir al sistema todos los módulos que se han descrito
anteriormente
Figura 2-22: Ejemplo de configuración de Altix 3700
Un servidor Altix 3300 contiene hasta 12 procesadores Intel Itanium 2, con un
IX-brick y ningún router. El sistema emplea el armario de 17U mencionado antes
con una fuente de alimentación y una PDU monofásica..
51 de 83
Este armario puede también incorporar opcionalmente el mismo controlador L2
descrito para el Altix 3700. Este controlador L2 es un display que se puede
utilizar para operar
Figura 2-23: Ejemplo de configuración de Altix 3300
2.2.8.1
SISTEMA DE CONTROL
Los diferentes controladores del Altix 3000 tienen múltiples funciones.
Todos los controladores operan a través de una red de comunicaciones. Esta
red tiene múltiples niveles y emplea distintas interfaces de comunicaciones en
los distintos niveles para optimizar el coste y las prestaciones y minimizar la
complejidad del software.
Los controladores de sistema proporcionan los siguientes servicios:
•
•
•
•
•
Gestionar el control de potencia y la secuenciación.
Control ambiental y monitorización.
Iniciar los resets de sistema.
Almacenar la información de identificación y configuración del sistema.
Diagnósticos y consola.
El sistema de control del Altix 3000 tiene tres niveles o jerarquías:
•
•
L1 system controller - controlador al nivel de brick.
L2 system controller - controlador al nivel de armario
52 de 83
•
•
SGI Console - servidor Linux.
Figura 2-24: Sistema de control del Altix 3000
El L1 es el controlador al nivel de brick. Es el responsable del control de
potencia eléctrica y secuenciación, del control de ambiente y proporciona
información de la configuración del brick. También proporciona consola de
diagnósticos e interfaz al usuario. Establece una comunicación directa de bajo
nivel y control de todas las funciones del brick. En muchos sistemas actúa como
esclavo de un controlador de nivel L2 que lo gobierna. Sin embargo, en los
sistemas Altix 3300, que están limitados a un máximo de 3 C-bricks y 2 I/Obricks, el controlador L1 actúa como maestro del sistema completo si no existe
un controlador L2.
53 de 83
Figura 2-25: Sistema de control L1 del Altix 3000
El controlador L2 gestiona al nivel de armario entero. Actúa como central de
comunicaciones y controla todos los bricks del armario (y los armarios de E/S
asociados en sistemas Altix 3700). Hay un controlador L2 en cada armario que
contenga C-bricks, a excepción de los sistemas Altix 3300 en los que el
controlador L2 es opcional.
Cada controlador L2 está equipado con una pantalla tipo “touch-screen”.
También tiene puertos ethernet y de módem que pueden ser usados para
gobernar el sistema. Se requiere un controlador L2 si se desea la funcionalidad
de mantenimiento remoto en el modelo Altix 3300,
54 de 83
Figura 2-29: Ubicación de los controladores en un armario de 40U
55 de 83
Figura 2-30: Sistema de control L2 del Altix 3000
El SGI Console es un servidor bajo Linux. Hay como máximo uno por sistema y
es obligatorio en ciertas configuraciones de alta complejidad.
SGIconsole es una combinación de hardware y software que permite manejar
múltiples servidores SGI corriendo el sistema operativo IRIX o Linux, bien sean
particionados, en cluster o en SSI.
SGIconsole consiste de un servidor SGI 1100, en formato enrracable, un
multiplexor o Ethernet hub, y un conjunto de software incluyendo Console
Manager y Performance Co-Pilot (PCP), el cual suministra la herramienta de
manejo de acceso remoto para facilitar la administración de todo el sistema.
SGIConsole incluye el siguiente software:
− Console Manager for SGIConsole
− Performance Co-Pilot (PCP)
− System Controller Software
Console Manager es una interfaz de usuario gráfico para el manejo y
monitorización de SGIConsole usado para controlar múltiples nodos.
Console Manager realiza las siguientes funciones:
− Ventana de Consola
− Power down, power up, y system reset
− Get, steal y spy console
56 de 83
−
−
−
−
Continua la conexión al sistema sin la ventana activa
Numerosas conexiones a cualquier sistema
Acceso remoto
Consola segura
Figura 2-26: SGIConsole
2.2.8.2
MONITORIZACIÓN DE SISTEMA
El Altix 3000 tiene avanzados sistemas de monitorización y comunicación del
estado ambiental del sistema. Una parte del sistema de monitorización, el
controlador L1, incluye muchas de las funcionalidades de monitorización. Las
más importantes son:
•
•
•
•
•
•
•
Lanzar las señales de reset al conectar.
Botón de reset en el panel frontal
Botón de NMI (Non-Maskable Interrupt) en el panel de control frontal.
Monitorizar la temperatura del aire ambiente y en función de ello ajustar
la velocidad de los ventiladores
Mostrar en la pantalla LCD las alarmas de temperatura anómala.
Contiene la NVRAM (Non Volatile RAM) de la información de la
configuración
Monitoriza la rotación de los ventiladores y automáticamente los ajusta
a la máxima velocidad si uno de ellos falla. También manda una señal
de parada forzosa cuando un ventilador crítico falla o cuando fallan dos
o más ventiladores no críticos.
57 de 83
•
•
•
•
•
2.2.9
Muestra en la pantalla LCD ventiladores a máxima velocidad y posibles
fallos de ventiladores.
Muestra en la pantalla LCD las condiciones de operación de las fuentes
de alimentación. La señal “AC OK” indica que el voltaje AC de entrada
al sistema es correcto y “DC OK” indica que todas las fuentes de DC y
señales DC remotas están presentes y sin error.
Proporciona comunicaciones serie de alta velocidad y señal de control
entre bricks y el controlador L2, permitiendo el control remoto y
monitorización de todas las funciones.
Indicadores de fallo (LEDs) para cada brick para poder identificar
físicamente bricks defectuosos. Todos los LEDs pueden accederse
desde la red de control del sistema.
Facilita el número de serie del sistema y la información de configuración
si se desea.
PARTICIÓN DEL SISTEMA
Dada la especial arquitectura del Altix 3000, y tratándose de un sistema
altamente distribuido, es posible crear particiones del sistema de varias formas:
Físicamente: Lo único necesario es disponer de varios discos de sistema para
poder arrancar cada una de las particiones. En este tipo de partición podemos
emplear los NUMAlinks (que ahora comunican “máquinas distintas”) para
comunicaciones de red a través de ellos. Como se trata de enlaces de muy alta
velocidad (3.2 GB/s) y muy baja latencia, las prestaciones son mucho mejores
que las que pueden obtenerse en un cluster convencional a través de
interconexiones a medida como se ha visto anteriormente. Además tenemos la
ventaja de poder tener la memoria globalmente distribuida, cualidad única en el
mercado.
Lógicamente: las particiones físicas tienen varios inconvenientes que es
necesario puntualizar:
•
Por una parte, al generar N particiones se están generando N "rincones"
que quedan desaprovechados si el reparto no ha sido preciso o si la carga
de cada una de ellas no es constante y equilibrada. Mediante un gestor de
colas de batch como puede ser LSF o PBSPro se minimiza en gran medida
este impacto.
•
Los periféricos asociados a las particiones no son compartidos. Discos y
cintas pueden tener que reubicarse si usuarios de otras particiones
necesitan acceder a ellos.
•
Las particiones son fijas en el tiempo y precisan intervención manual del
administrador para modificarse. Así por ejemplo, si una partición queda libre
durante el fin de semana y otra tiene una carga de trabajo importante, el
sistema no es capaz de redistribuir recursos para optimizar el resultado
58 de 83
final. Igualmente a través de un gestor de colas de batch como puede ser
LSF o PBSPro se resuelve este problema.
Las particiones lógicas de Linux implementadas con cpuset permiten asignar
recursos de CPUs y memoria de forma dinámica, garantizando unos mínimos a
grupos de procesos durante espacios de tiempo determinados o
permanentemente. Y, por supuesto, asignar a estos grupos colas de batch. Por
este motivo las particiones lógicas pueden resultar muy interesantes,
especialmente en entornos de computación intensiva permitiendo un uso muy
eficiente del sistema.
59 de 83
3
ANEXO TÉCNICO C: SOFTWARE PARA
LA FAMILIA SGI ALTIX 3000
3.1
SISTEMA OPERATIVO LINUX
El servidor SGI Altix 3000 funciona bajo el sistema operativo Linux de 64 bits
Red Hat 7.2, con el kernel de Linux 2.4.19.
Para mejorar las prestaciones, SGI incluye un entorno de desarrollo optimizado
para la arquitectura Altix 3000 denominado SGI ProPack que permite obtener el
máximo rendimiento del sistema.
3.1.1
HISTORIA
Linux es un sistema operativo que fue desarrollado en un principio para la
arquitectura de procesadores 386 de Intel. Actualmente se puede considerar
como el sistema operativo que más plataformas soporta incluyendo
procesadores de diversos proveedores y arquitecturas como Itanium 2, Pentium,
Alpha, PowerPC, Power 4, UltraSparc, MIPS, StrongArm y otros. Sin embargo,
la versión más utilizada es y seguirá siendo sobre la arquitectura Intel.
El concepto de open source ha sido desarrollado desde hace ya muchos años.
Su comienzo data de las universidades que necesitaban poder compartir
información así como estudiantes y desarrolladores que adaptaban programas a
sus necesidades. En 1984 Richard Stallman, un investigador de MIT AI Lab,
arrancó un proyecto denominado GNU para tratar de expandir este movimiento.
Stallman pensó que haciendo los códigos disponibles para cualquier persona en
entornos científicos llevaría a esta comunidad a una mejor comunicación y
desarrollo.
Este concepto fue recogido por Linus Torvalds. Cuando empezó a desarrollar
Linux era un estudiante universitario que hizo una primera versión del sistema
operativo para de esta forma poder conocer mejor su nuevo ordenador 386.
Linus hizo público el código fuente de Linux en Septiembre de 1991 y poco a
poco fue ganando voluntarios a su proyecto que fueron añadiendo mejoras y
complementando el kernel y las aplicaciones hasta alcanzar la envergadura que
conocemos hoy.
60 de 83
Podríamos definir Linux como un sistema operativo basado en la filosofía de
Unix, y que por lo tanto es multiusuario y multitarea y que cumple todas las
especificaciones estándar requeridas.
En sí, Linux es sólo el núcleo del sistema operativo, pero necesita de
aplicaciones y programas para hacer algo. Muchos han sido portados a Linux,
otros han sido creados específicamente para Linux.
Como esto es una ardua tarea no tardaron en surgir compañías dedicadas a
reunir todos esos programas facilitando la tarea de crear un sistema Linux
funcional. En la actualidad existe un buen número de estas compañías.
SGI decidió que el sistema operativo con el cual iba a lanzar Altix 3000 fuera
Red Hat 7.2 (http://www.redhat.com).
Red Hat es la distribución más popular del mercado hoy en día, siendo emulada
por muchas otras. Es muy sencilla de instalar e incluye una excelente autodetección de dispositivos, un instalador gráfico y un excelente conjunto de
aplicaciones comerciales en su distribución oficial.
Linux es un sistema operativo especialmente diseñado para usuarios técnicos y
creativos. Linux es actualmente el sistema operativo de mayor crecimiento en el
mercado y a diferencia de los sistemas operativos propietarios, Linux puede ser
instalado y actualizado libremente. Esto le convierte en un sistema operativo
muy atractivo para aquellas empresas y usuarios que quieran amortizar sus
inversiones en software Pero el coste no es el principal factor. Muchas
compañías, grandes y pequeñas, prefieren Linux simplemente por su seguridad
y estabilidad: Linux puede correr durante meses e incluso años, sin tener que
rearrancar el sistema. Como el código es open source, en caso de existir algún
bug puede ser fácilmente solucionado. SGI proporciona soporte total de LINUX
solucionando problemas y asesorando a los usuarios quienes no tienen que
tratar de buscar la solución por diferentes fuentes. SGI centraliza todas esas
fuentes al estar plenamente en contacto con la comunidad,.
El valor de open source permite a los usuarios y a grupos de usuarios a
compartir y colaborar en cualquier problema. Los programas Linux pueden ser
instalados sobre prácticamente cualquier máquina lo que aporta a los usuarios
una gran flexibilidad.
3.1.2
LINUX Y SGI
Junto con la comunidad open-source, SGI está comprometida a tomar el
liderazgo en el desarrollo y mejora del rendimiento y fiabilidad del sistema
operativo Linux. Con su foco sobre entorno de producción de alto rendimiento,
61 de 83
SGI ha contribuido a la escalabilidad de Linux, su scheduling, el uso de la
memoria, la E/S y otros esfuerzos críticos para optimizar el sistema operativo
Linux, que se está convirtiendo actualmente en uno de los sistemas operativos
más robustos del mercado.
SGI lleva colaborando con open source desde hace muchos años y ha aportado
a la comunidad muchas de las mejores soluciones que han salido para Linux y
que le han convertido en uno de los sistemas operativos más robustos y
seguros del mercado. Para más información http://oss.sgi.com/
Con la familia de servidores y supercluster SGI Altix 3000, se incluye el primer
sistema operativo Linux del mundo que soporta memoria global compartida a
través de nodos de hasta 64 procesadores en una sola imagen de sistema
operativo por nodo y un avanzado entorno de desarrollo especialmente
optimizado para aplicaciones técnicas
SGI ha combinado la velocidad de su arquitectura de memoria compartida
NUMAflex con el poderoso procesador Intel® Itanium® 2 para crear un entorno
de Linux open-source que bate récords de rendimiento.
Figura 3-1: http://oss.sgi.com/projects/numa/
La plataforma Altix 3000 ha sido diseñada para ayudar a los usuarios más
exigentes a resolver los problemas más complejos mediante una arquitectura de
64-bit que es escalable totalmente en todas las direcciones hasta incluso
cientos de procesadores.
Nuestras soluciones Linux permiten ayudar a nuestros usuarios en todas sus
tareas diarias:
•
•
•
•
•
•
•
•
Migración
Implementación y configuración
Optimización de los recursos del sistema
Infraestructura
Interoperatibilidad
Almacenamiento y backup
Clustering
Administración On-site
62 de 83
Con más de 20 años de experiencia en entornos de alta computación, SGI tiene
la ventaja de la experiencia en sistema complejos. Nuestras soluciones Linux
están diseñadas para proporcionar la mayor fiabilidad y rendimiento y adaptarse
a las necesidades y los requisitos que los usuarios demandan
3.1.3
ENTORNO
PROPACK
DE
DESARROLLO
AVANZADO:
SGI
El entorno de desarrollo y colaboración con la comunidad de Linux ha permitido
suministrar un nuevo y diferente modelo de trabajo a los fabricantes de
computadores, ofreciendo un sistema operativo perfecto para servidores
escalables. Usar Linux como sistema operativo para grandes computadores
tiene el beneficio de suministrar la mejor protección software y la mejor
integración entre
el sistema operativo y las aplicaciones HPC
independientemente del fabricante.
SGI ProPack para Linux incluye cualidades y mejoras de rendimiento ideales
para posibilitar a usuarios técnicos y creativo resolver sus problemas de
cómputo con datos enormes usando el sistema operativo Linux con
procesadores Itanium 2 Este software añade y mejora las características base
de la distribución Linux basada en Red Hat, versión 7.2.
SGI ProPack para Linux está diseñada para ser ejecutado sobre cualquier
servidor SGI Altix 3000.
El Entorno de Desarrollo SGI contiene los siguientes CD:
•
•
•
•
•
•
SGI Linux Environment 7.2 Installation CD set (2 CDs)
SGI Linux Environment 7.2 Updates CD
SGI Linux Environment 7.2 Source Code CD set (3 CDs)
SGI ProPack v2.1.1 for Linux Boot CD
SGI ProPack v2.1.1 for Linux Open/Free Source Software CD
SGI ProPack v2.1.1 for Linux Proprietary Software CD
SGI Linux Environment incluye la distribución Red Hat 7.2.
SGI Propack incluye las siguientes aplicaciones:
•
•
Herramientas de medida de rendimiento de aplicaciones:
•
Vtune: Desarrollada y soportada por Intel.
•
Pfmon
Array Services: Conjunto de herramientas con soporte kernel que
simplifica el manejo de sistema y de aplicaciones paralelas para
clusters de sistemas SGI.
63 de 83
•
CpuMemSets: Optimización de la ubicación de procesos en memoria y
en procesadores.
•
Cpuset: Selección de un conjunto de procesadores exclusivos para
ejecutar más eficientemente las aplicaciones.
•
CSA: Accounting de jobs por utilización de recursos.
•
FLEXlm: Gestor de licencias flotantes.
•
Driver IOC4 : Driver para el IDE CD-ROM, NVRAM y reloj Real-Time.
•
KDB: Debugger para el kernel de Linux
•
Particionamiento del Kernel: soporte para particionar el sistema,
incluyendo la comunicación entre particiones.
•
Mejoras de rendimiento del Kernel: Incluye la mayoría de las mejoras
portadas e incluidas en el kernel 2.5 tales como Big Kernel Lock (BKL),
Frlocks (Fast-Reader Locks)
•
Controlador del firmaware L1 y L2..
•
LKCD: Herramienta de análisis de crash de sistema.
•
MPT: Librerías de pasos de mensajes especialmente optimizadas para
la arquitectura de SGI que incluyen MPI y SHMEM.
•
NUMA tools: Conjunto de herramientas NUMA que permiten aumentar
el rendimiento en la ejecución de aplicaciones. Soporte de arquitectura
NUMA. Altix implementa arquitectura de Non Uniform Memory Access
time (NUMA) incorporando varias nuevas utilidades en el sistema
operativo y en los compiladores. Incorpora extensiones en la directiva
“c$doacross'' para afinidad simple, afinidad de datos y de threads, así
como directivas de distribución de datos permitiendo el control a nivel
de usuario de la distribución de páginas y coordinando la planificación
de "loops''. También permite la reorganización de la estructura de datos
mejorando la localidad y reduciendo las falsas comparticiones.
Performance Co-Pilot: Herramienta gráfica para monitorización del
sistema.
•
•
PROM: Permite a las CPU arrancar y realizar tareas de administración
e instalación de software.
•
Runon: Permite ejecutar un job en particular en un procesador en
concreto o en un conjunto de procesadores.
•
SGI Linux Environment 7.2 updates. Conjunto de RPMs actualizadas
para el SGI Linux Environment 7.2 base con SGI Propack
•
XFS: Sistema de ficheros de alto rendimiento.
•
Infraestructura XSCSI: Soporte para aumentar espectacularmente las
prestaciones SCSI de Linux
64 de 83
•
XVM: Manejador de volúmenes y otras funcionalidades como striping y
mirroring.
Documentación adicional sobre está información está disponible en la página
web http://techpubs.sgi.com.
3.1.4
PARTICIONES
Con el sistema SGI Altix 3000, SGI suministra la posibilidad de dividir el sistema
en particiones más pequeñas, también conocidas como cluster, donde cada una
de ellas puede ejecutar su propia copia de sistema operativo.
Mediante particiones es posible escalar más allá de 64 procesadores. El límite
actual está en 8 particiones (512 procesadores).
SGI soporta global shared memory. Esto significa que una aplicación corriendo
sobre una partición puede crear un segmento de memoria global compartida en
otra partición, la cual puede ser compartida por aplicaciones ejecutándose en
otra partición
Como la conexión se realiza a través de la tecnología de interconexión de baja
latencia NUMAlink, el rendimiento obtenido para aplicaciones que requieren MPI
u otras técnicas de paso de mensajes es el mejor en el mercado.
64P
hasta 512GB
512 processors
64P
64P
shared memory
64P
Hasta 4TB of memoria direccionable directamente con coherencia de
caché
64P
64P
64P
64P
Figura 3-2:Supercluster de 512 procesadores con 8 particiones de 64 CPUs
65 de 83
3.2
PRODUCTOS DE SOFTWARE ASOCIADOS
3.2.1
COMPILADORES
El sistema de compiladores de Intel 7.0 ha sido diseñado para sacar el máximo
partido posible de las prestaciones teóricas máximas del hardware (tanto del
procesador como del resto de la arquitectura) de los servidores Altix 3000.
Los compiladores de Intel 7.0 soportan C, C++ y Fortran 77, 90 y 95.
Permiten ejecutar los códigos a un nivel de prestaciones cerca del pico teórico
tanto para el procesador de Intel® Itanium 2 de 64-bit como para 32-bit. Como
principales características se podrían reseñar las siguientes:
− Incluyen soporte para Streaming SIMD Extensions 2 (SSE2) para el
procesador Pentium® 4 así como software de pipelining en el procesador
Intel® Itanium® e Itanium 2.
− Optimizaciones Inter-procedurales (IPO) y optimización profile-guided
(PGO) que suministran el mayor rendimiento a los códigos.
− Loop unrolling y mejoras del prefetching
− Soportan desarrollo de código multi-thread, auto-paralelizadores y OpenMP
2.0. Ambas opciones soportan Hyper-Threading lo cual permite compartir
los recursos entre diferentes operaciones lógicas. Esto permite aumentar el
rendimiento de las aplicaciones cuando se ejcutan en multithread o en
multitarea.
− Optimizaciones para coma flotante
− Optimización a escala global del programa.
El compilador de C y C++ cumple las siguientes características
− Cumple Standard Ansi C y C++.
− Compatible binario con GNU gcc.
− Soporta la mayoría de las extensiones de lenguaje GNU C y C++.
− Compatibilidad con C99 (subconjunto).
− Se pueden mezclar binarios de código C con gcc 3.x y Intel 7.0.
− Ficheros objetos C pueden ser linkados con el compilador de Intel o con
gcc.
Fortran 77, 90 y 95
− Se puede mezclar C / C++ y Fortran. Si es sólo C y Fortran, es posible
linkar también con gcc
66 de 83
Los compiladores realizan toda una serie de transformaciones para optimizar el
código a varios niveles. En cada nivel el tipo de optimizaciones a realizar es
distinto y se aplica a diferentes partes de la arquitectura.
Todas estas técnicas hacen que el código generado esté altamente optimizado.
En general, los benchmarks publicados muestran unas prestaciones muy
próximas al pico del procesador. Comparativamente, utilizando el código
generado por los compiladores de GNU como unidad de prestaciones en
cualquier plataforma, los compiladores de Intel dan con diferencia los
porcentajes más elevados, siendo el código generado, en muchas ocasiones,
varias veces más rápido que el de GNU.
El sistema está integrado y permite por tanto integrar el paralelizador con el
optimizador escalar, y así evitar aspectos negativos como por ejemplo
optimizaciones escalares que luego impiden la paralelización, o
transformaciones de código que mejoran un aspecto y empeoran otros.
Así pues, el autoparalelizador de código es capaz de generar versiones
paralelas del código también optimizado escalarmente.
Documentación adicional sobre está información está disponible en la página
web http://techpubs.sgi.com.
3.2.2
LIBRERIAS, TOOLKITS, Y APIS
SGI ayuda al proceso de desarrollo de software a través del soporte y creación
de muchas librerías, toolkits y Application Program Interfaces (APIs). A
continuación se describen algunas de las mismas
3.2.2.1
MESSAGE-PASSING TOOLKIT Y OpenMP
El paso de mensajes se ha convertido en uno de los mecanismos más
populares para lograr escalabilidad y computación de altas prestaciones. Las
aplicaciones utilizando paso de mensajes han demostrado una escalabilidad de
miles de procesadores. Estas liberías permiten a los desarrolladores de
aplicaciones utilizar una interfaz estándar y portable al tiempo que consiguen el
mejor rendimiento en comunicación sobre los sistemas SGI.
Message Passing Toolkit (MPT) es la implementación optimizada de una
excelente colección de librerías de paralelización y pasos de mensajes en un
único producto. Incluye
•
Message Passing Interface (MPI)
•
SHMEM
MPI fue desarrollado para servir como un estándar común SGI ha sido un
miembro clave del Forum de MPI. La implementación de MPI de SGI cumple
67 de 83
todas las especificaciones de MPI. Como características más importantes se
pueden indicar las siguientes:
•
•
•
•
•
•
Paso de argumentos NULL a MPI_Init.
MPI I/O. MPT contiene la implementación ROMIO de MPI I/O, es la cual se
define una potente API para realizar E/S en una aplicación de paso de
mensajes.
MPI_Win_create, MPI_Put, MPI_Get, MPI_Win_fence, y MPI_Win_free
rutinas son suministradas para jobs MPI single-host.
C++ bindings.
Soporte Fortran 90 para USE MPI statement. Usando USE MPI statement
en vez de INCLUDE mpif.h suministra a los programadores de Fortran 90
con definiciones de parámetros un interfaz de llamadas a subrutinas MPI en
tiempo de compilación.
MPI bindings para multi-threading interno a procesos MPI.
Las directivas OpenMP son parte intrínseca del compilador de Intel 7.0
cumpliendo todas las directivas OpenMP 2.0
Documentación adicional sobre está información está disponible en la página
web http://techpubs.sgi.com.
3.2.2.2
SCSL (SILICON COMPUTING SCIENTIFIC LIBRARIES)
SCSL (Silicon Computing Scientific Libraries) consiste en una gran variedad de
funciones científicas y matemáticas incluyendo rutinas que realizan
manipulación de matrices, resolución de ecuaciones lineales, ecuaciones,
transformadas de Fast Fourier y filtros lineales como convoluciones y
correlaciones. Estas librerías de cálculo científico están totalmente optimizadas
y paralelizadas para la arquitectura de SGI. Incluyen:
Librería BLAS: (Basic Linear Algebra Subprograms), que proporciona la
mayoría de las funciones de algebra lineal. Contienen varias rutinas BLAS,
incluyendo:
•
•
•
BLAS1 - operaciones vector-vector
BLAS2 - operaciones matriz-vector
BLAS3 - operaciones matriz-matriz
Fueron desarrolladas en la Universidad de Tennessee y son un estándar de la
industria. Información detallada sobre la librería BLAS puede encontrarse en la
página web: http://www.netlib.org/blas/index.html
Librería FFT: Conjunto de rutinas que realizan transformadas Fast Fourier
mixed-radix así como rutinas lineales como convolución y correlación Incluyen:
•
•
Raices mezcladas de 1, 2 y 3 dimensiones
Raices mezcladas multiples unidimensionales
68 de 83
•
•
•
•
•
Convoluciones de 1 y 2 dimensiones
Convoluciones múltiples de 1 dimensión
Correlaciones de 1 y 2 dimensiones
Correlaciones de 1 dimensión
Precisión simple y doble, para números reales y complejos
•
Soluciones directas para sistemas de ecuaciones lineales dispesas con
estructura simétrica no-cero
•
Soluciones interactivas para ecuaciones lineales disperas
Librería LAPACK: Es una librería de subrutinas para resolver la mayoría de
los problemas comunes de álgebra lineal: sistema de ecuaciones lineales,
problemas eigenvalue, y problemas de valor simple. Incluyen
•
•
•
•
Sistema de ecuaciones simétricos y asimétricos.
Eigenvector/value simétricos y asimétricos
Singular Value Decomposition (SVD)
Linear Least Squares
La librería LAPACK fue desarrollada en la Universidad de Tennessee y es
también un estándar de la industria. Información más detallada puede
encontrarse en la página web: http://www.netlib.org/lapack/index.html
Documentación adicional:
Documentation de las rutinas está disponible de forma individual en la página
web http://techpubs.sgi.com.
3.2.3
HERRAMIENTAS DE DESARROLLO
3.2.3.1
VTUNE Y PFMOM
Vtune y Pfmon son herramientas especialmente diseñadas para medir el
rendimiento de aplicaciones y encontrar posibles zonas de optimización
Vtune ha sido creada y está soportada por Intel. Sus principales características
son las siguientes:
•
Almacena, analiza y visualiza datos para Windows y Linux.
•
Recoge más de 1000 muestras/segundo
•
Multithread.
•
Simplemente con opción -g al compilar.
•
Funciona con MPI, OpenMP y SHMEM
69 de 83
Figura 3-3: Ejemplo de Vtune para análisis de prestaciones
Pfmon es de Open Source. Sus principales características son las siguientes:
− Almacena, analiza y visualiza datos.
− 1000 muestra/segundo
− Muy bajo overhead
3.2.4
HERRAMIENTAS DE ANÁLISIS DE PRESTACIONES Y
MANEJO DE RECURSOS
3.2.4.1
PERFORMANCE CoPILOT (PCP)
Es un software de análisis y monitorización del sistema. Permite operar en
tiempo real o a posteriori con datos almacenados. Asimismo es posible
programar alarmas sobre eventos.
70 de 83
Figura 3-4: Ejemplo de ventana de PCP con análisis de discos
71 de 83
Figura 3-5: Ejemplo de PCP para análisis de prestaciones
3.2.4.2
SGI CONSOLE
El SGI Console es un servidor bajo Linux. Hay uno por sistema y es obligatorio
en ciertas configuraciones de alta complejidad.
SGIconsole es una combinación de hardware y software que permite manejar
múltiples servidores SGI corriendo sistemas operativos IRIX o Linux, bien sean
particionados, en cluster o en SSI.
SGIconsole consiste en un servidor SGI 1100, en formato enrracable, un
multiplexor o Ethernet hub, y un conjunto de software incluyendo el Console
Manager y Performance Co-Pilot (PCP), el cual suministra la herramienta de
manejo de acceso remoto para facilitar la administración de todo el sistema.
SGIConsole incluye el siguiente software:
− Console Manager for SGIConsole
− Performance Co-Pilot (PCP)
− System Controller Software
72 de 83
Console Manager es una interfaz de usuario gráfico para el manejo y
monitorización de SGIConsole usado para controlar múltiples nodos.
Console Manager aporta las siguientes funcionalidades:
−
−
−
−
−
−
−
Ventana de Consola
Power down, power up, y system reset
Get, steal y spy console
Continuación de la conexión al sistema sin la ventana activa
Numerosas conexiones a cualquier sistema
Acceso remoto
Consola segura
Figura 3-6: SGIConsole
3.2.4.3
CSA: Comprehensive System Accounting
CSA permite disponer de un sistema de accounting de altas prestaciones.
Es un conjunto de programas de usuario y de administración en C con scripts
que proporcionan métodos efectivos para almacenar todos los usos de recursos
de los jobs por precesos, monitorizar el uso de disco y asignar costes
específicos a cuentas. CSA utiliza este método por proceso para recoger
información y combinarla por job, grupos, proyecto, etc.
Tiene los siguientes beneficios:
Accountig por job.
Demonio de accounting
Periodos de accountig flexibles.
Accounting de datos almacenados offline
73 de 83
Reportes a medida
3.2.4.4
GESTOR DE COLAS DE BATCH. MANEJADOR DE RECURSOS
DEL SISTEMA
En todo sistema de cálculo se recomienda utilizar un buen gestor de colas de
batch que sea capaz de asignar y manejar de forma eficiente todos los recursos
del sistema.
SGI trabaja actualmente con la mayoría de los desarrolladores de aplicaciones
para tal propósito, siendo actualmente las más utilizadas LSF de Platform
Computing (www.platform.com) y PBSPro de Veridian ( www.pbspro.com).
Con estas herramientas se optimiza la utilización de los procesadores del
servidor: es posible organizar colas de acceso a un determinado número de
procesadores dinámicamente, asignar las colas a usuarios, grupos de usuarios,
proyectos, etc.
Estas aplicaciones están totalmente integradas con el servidor Altix y el sistema
operativo Linux y son actualmente los mejores gestores de colas de batch sobre
Linux; y, a su vez, la plataforma que mejor aprovecha las cualidades de estos
gestores es nuestra arquitectura NUMAFlex, puesto que utiliza totalmente las
herramientas inherentes a la arquitectura de SGI como pueden ser:
− CPUSET: Elección de Grupos de CPU para ejecución de jobs
− CSA (Comprehensive System Accounting): Accountig por jobs, usuario,
grupos, proyectos...
− Arquitectura NUMA
Como cualidades más importantes se pueden destacar las siguientes:
− Equilibrado de la Carga en forma Dinámica.
− Monitorizar continuamente recursos del servidor (uso CPU, memoria,
swap, disponibilidad de licencias software,etc)
− Seleccionar automáticamente el mejor recurso para cada trabajo.
− Asignar trabajos en interactivo y background.
− Interfaz Visual
− Estupendo Interfaz Visual basado en X.
− Programación y ejecución de trabajos en espera de recursos.
− Ejecución de trabajos cuando los recursos estén disponibles.
− Manejo dinámico de recursos basado en reglas.
− Soporta dependencia de trabajos, triggers, condiciones de "scheduling"
a medida, "chunk jobs" y "Frame Arrays".
74 de 83
− Modelo centralizado
− Recepción y monitorización de toda la información acerca de la carga
del sistema
− Monitoriza y mide el rendimiento sobre cualquier directorio.
− Compartición óptima de Recursos
− Rearranca automáticamente trabajos que han fallado
− Soporta ventanas temporales durante las cuales los trabajos pueden
ser arrancados o retrasados.
− Políticas y Control Administrativo
− Suministra opciones variadas para configurar políticas de carga de
trabajo
− Permite reconfigurar colas de ejecución
− Compartición de recursos por usuarios, grupos y proyectos.
− Permite al administrador suspender, parar y ejecutar trabajos
basándose en prioridades.
− Rearranca trabajos automáticamente si cualquier evento sobre un
servidor falla.
− Permite a los usuarios modificar su propio trabajo después de enviarlo a
la cola de ejecución
− API de Desarrollo
− Interfaz de programación C
− Disponibilidad de interfaz Perl Open Source y TCL
− Llamadas de API para trabajos, colas y operaciones sobre el host.
− Tolerancia a fallo
− Manejo de los recursos de forma continua aunque se produzca un error
en un host.
75 de 83
Figura 3-7: Gestor de colas LSF
3.2.5
SISTEMA DE FICHEROS Y SUBSISTEMA DE E/S
3.2.5.1
XFS. SISTEMA DE FICHEROS.
El sistema de ficheros XFS es el sistema de ficheros desarrollado por SGI a
principio de los años 90 para satisfacer la demanda creciente, expresada por
sus clientes, de un sistema de ficheros de alto rendimiento y gran capacidad de
crecimiento.
Gracias al uso de nuevos algoritmos basados en árboles binarios para la
organización de los directorios, el sistema de ficheros XFS es capaz de
proporcionar un ancho de banda cercano al que proporciona el hardware sobre
el que se apoya.
Al mismo tiempo, XFS utiliza la tecnología de “logging”, presente en las bases
de datos, para gestionar los cambios producidos en el sistema de ficheros, por
lo que en caso de caída de la máquina, la recuperación del sistema no supone
la comprobación de la integridad completa del sistema repasando todos los Inodos y los mapas de bits.
76 de 83
Característica
Max FS Size
Max File Size
File Space
Allocation
Max. Extent
Size
Free Space
Mgmt
Variable Block
Size
Sparse File
Support?
Directory
Organization
Inode
Allocation
Crash
Recovery
Maximum
Performance
XFS
18 million TB
9 million TB
Extents
UFS
1TB
1TB
Blocks
VxFS
1TB
1TB
Extents
NTFS
2TB
2TB
Extents
4GB
NA
64MB
Undoc’d
Free extents
organized by
B+ trees
512 bytes to
64KB (4KB w/
compression)
Yes
Bitmap per
cylinder grp
Bitmap per
allocation unit
Single bitmap
4KB or 8KB
Undoc’d
512 bytes to
64KB
Yes
No
NT 5.0
B+ Tree
Linear
Hashed
B+ tree
Dynamic
Static
Dynamic
Dynamic
Asynch.
Journal
7GB/sec,
4GB/sec
(single file)
Fsck* Synch
Journal Synch. Journal
Not Available
1GB/sec
Not Available
En la tabla de arriba se comparan las prestaciones de varios sistemas de
ficheros.
Documentación adicional sobre está información está disponible en la página
web http://techpubs.sgi.com.
3.2.5.2
XLV / XVM PLEXING
El gestor de volúmenes lógicos XLM /XVM soporta el concepto de “plexing”,
también llamado “mirroring”. Plexing es aplicado al nivel de subvolúmenes y
utilizado para proporcionar redundancia de datos cuando la integridad de los
mismos es vital. Un subvolumen al que se le haya aplicado “plexing” tendrá una
o más (máximo 4) imágenes de si mismo.
77 de 83
Figura 3-8 : Plexing
En la imagen superior el subvolumen de la derecha es una copia exacta del
subvolumen de la izquierda. XLV asegura que todas las escrituras realizadas al
plex original (plex 0) serán repetidas en el plex 1 de la derecha.
El propósito del “plexing” es proporcionar copias duplicadas de los datos para
asegurar la disponibilidad de los datos.
Documentación adicional sobre está información está disponible en la página
web http://techpubs.sgi.com.
Aunque algunas aplicaciones demandan únicamente grandes recursos de CPU,
otras muchas necesitan de unos requisitos de E/S poderosos. El subsistema
XSCSI, sistema de ficheros XFS, manejador de volúmenes XVM y migración de
datos (DMF) han sido portados desde IRIX al subsistema de E/S de Linux.
3.2.5.3
SUBSISTEMA DE E/S
El subsistema SGI XSCSI permite obtener una calidad comercial para E/S.
XSCSI aprovecha las bondades de la especial arquitectura de SGI para
conseguir unos resultados asombrosos.
78 de 83
1200
XSCS
I
1000
80
0
MB/sec
60
0
40
0
20
0
0
scsi-fixed
scs
i
0
200
600
800
40
100
Número
0 de bloques (512 bytes) 0
120
0
Figura 3-9: Comparativa de XSCSI con SCSI
Como se puede ver en la gráfica el rendimiento anterior de Linux no estaba muy
optimizado. Actualmente el rendimiento que se obtiene con XSCSI está por
encima de muchos de los UNIX estándar.
3.2.6
COMO UTILIZAR EL SOFWARE
Todo el software de Intel ha sido instalado sobre /opt/intel. A continuación
mostramos los directorios.
|-- compiler70
| |-- docs
| | |-- asm_ug
| | |-- c_ug
| | |-- f_ug
| | |-- notes
| | `-- ref
| |-- ia64
| | |-- bin
79 de 83
| | |-- include
| | | `-- sys
| | |-- lib
| | |-- libio-src
| | `-- substitute_headers
| |
|-- asm
| |
|-- bits
| |
|-- linux
| |
| `-- byteorder
| |
`-- sys
| |-- man
| | `-- man1
| `-- training
|
|-- scripts
|
|-- templ
|
| `-- nav
|
|-- templ_im
|
| |-- buttons
|
| `-- icons
|
`-- tutorial
|
|-- ch0
|
|-- ch1
|
| |-- vc6
|
| `-- vsnet
|
|-- ch2
|
|-- ch3
|
|-- ch4
|
|-- ch5
|
|-- ch6
|
|-- final
|
|-- images
|
`-- legal
|-- ipp
| |-- doc
| |-- include
| |-- lib
| |-- sharedlib
| |-- tools
| | |-- mergedlib
| | |-- perfsys
| | | `-- data
| | |-- runtime
| | |-- staticlib
| | `-- support
| `-- training
|
|-- ipp_wbt
80 de 83
|
| |-- ch0
|
| |-- ch1
|
| |-- ch2
|
| |-- ch3
|
| |-- ch4
|
| |-- ch5
|
| |-- ch6
|
| `-- images
|
|-- templ
|
| `-- nav
|
`-- templ_im
|
|-- buttons
|
`-- icons
|-- licenses
`-- mkl
|-- doc
| |-- functions
| |-- icons
| |-- images
| `-- mklqref
|-- examples
| |-- blas
| | |-- data
| | `-- source
| |-- cblas
| | |-- data
| | `-- source
| |-- fftc
| | |-- data
| | `-- source
| |-- fftf
| | |-- data
| | `-- source
| |-- lapack
| | |-- data
| | |-- lib
| | `-- source
| |-- versionquery
| | `-- source
| |-- vmlc
| | `-- source
| `-- vmlf
|
`-- source
|-- include
|-- lib
| |-- 32
81 de 83
| `-- 64
`-- tests
|-- blas
| |-- in
| `-- source
|
|-- level1
|
|-- level2
|
`-- level3
|-- cblas
| |-- in
| `-- source
|-- fftc
| |-- in
| `-- source
`-- fftf
|-- in
`-- source
-
Para compilar en FORTRAN se utiliza el comando efc situado en:
/opt/intel/compiler70/ia64/bin/efc.
También se puede compilar con g77 pero es menos óptimo.
-
Para compilar en C y C++ se utiliza el comando efc situado en:
/opt/intel/compiler70/ia64/bin/ecc
También se puede compilar con gcc pero es menos óptimo.
-
Para ambos casos es muy recomendable leer la documentación
situada en /opt/intel/compiler70/docs
-
Para utilizar la librería de paso de mensajes MPT:
- MPI:
- Compilación:
- ecc prog.c –lmpi
- gcc prog.c –lmpi
- efc prog.c –lmpi
- g77 –i/usr/include prog.c –lmpi
- Ejecución: mpirun –np numero_procesadores a.out
- Documentación: rpm –ql sgi-mpt | grep \ MPT_MPI_PM.pdf
rpm –ql sgi-mpt | grep relnotes
man mpirun
- SHMEM
- Compilación:
- ecc prog.c –lsma
- gcc prog.c –lsma
- efc prog.c –lsma
- g77 –i/usr/include prog.c –lsma
82 de 83
-
-
Ejecución: mpirun –np numero_procesadores a.out
Documentación: rpm –ql sgi-mpt | grep \ MPT_MPI_PM.pdf
rpm –ql sgi-mpt | grep relnotes
man shmem
OpenMP
- Compilación:
- ecc prog.c –openmp
- gcc prog.c –openmp
- efc prog.c –openmp
- g77 –i/usr/include prog.c –openmp
Ejecución: directa (recordar OMP_NUM_THREADS)
Librerías matemáticas:
- SCSL:
Linkar
utilizando
–lscs.
Se
debe
especificar
LD_LIBRARY_PATH y MANPATH mediante la utilización del paquete
module o bien a través de las opciones –L y –I al compilar
- Documentación man pages: intro_scsl, intro_blas, intro_lapack,
intro_fft, intro_solvers
- MKL 5.2
- BLAS: Linkar utilizando –lmkl_itp
- LAPACK: Linkar utilizando –lmkl_lapack32 y
–lmkl_lapack64
- FFT: Linkar utilizando –lmkl_itp
- Vector: Linkar utilizando –lmkl_vml_itp –ldl
- Documentación sobre /opt/intel/mkl/doc
- IPP: Intel Peformance Primitives. Mirar /opt/intel/ipp/doc para diferentes
opciones de linkaje.
- Librerías estandar matemáticas (sin, exp, etc)
- Librería matemática de Intel: libimf.a. Automática cuando compilas con
el compilador de Intel.
- Glibc’s : Linkar utilizando –lm
- NUMATOOLS
- runon
- dplace
- dlook
- cpuset
- Uitilizar páginas man para su uso.
-
Por último destacar que es muy aconsajable el uso del paquete module para
cargar diferentes versiones de compiladores, herramientas, etc.
83 de 83