M’agradaria presentar públicament la documentació del Projecte de Final de Carrera de l’Enginyeria Tècnica en Informàtica de Sistemes anomenat “Disseny i construcció d’un clúster de supercomputació sobre GNU/Linux” (Llicència GNU FDL).

El projecte es basa en la integració de la tecnologia openMosix dintre un clúster Rocks.

Moltes coses han quedat pendents: la traducció al castellà e anglès, introduir-lo a la documentació d’openMosix, ampliació… Les 3 primeres tinc una forta convicció d’acabar-les (sense restriccions temporals però), mentre que l’última… potser el dia de demà. De moment encara col·laboro amb el tècnic que s’encarrega de la implementació del clúster, però molt esporàdicament. Penso que m’hagués agradat no separar-me mai d’aquest camí, però si el destí així ho ha decidit serà per bé, n’estic segur.

Sempre quedaran els records… Un lloc de treball… un company d’aventures… i un final de projecte (a aquesta foto no se me veuen les ojeres, però no us les podeu imaginar…)

També vull animar a tots els que us queda realitzar el projecte a buscar un projecte ambiciós, amb molta feina pel mig i moltes recompenses a la fi. Si estem fent una carrera tècnica aprofitem-ho. Sempre ens queixem que les pràctiques són un conyaç, i aquí tenim l’oportunitat de fer la nostra propia. No us arrepentireu.

Fa poc Pere Millan va treure un projecte molt semblant al que he fet a la tècnica però per a la superior… Molt interessant

Fins d’aquí un parell d’anys no tocarà més posts sobre la categoria Projecte… descansi en pau.

Portava tot l’agost pensant en les ganes que tenia que arribés el setembre. I quan vaig veure les cares de tota la gent que va tornar a la uni al setembre vaig pensar que era l’única que en tenia ganes xDD Però ha valgut la pena. Perifèrics entregat i evaluat (el driver de Linux al final ha valgut un 10! ) i el projecte entregat i pendent de fer la presentació.

(… Respir …)

Prou estress, prou presses… fins al dilluns que començen les classes de la superior.

Jo també espero poder fer l’assignatura de Seguretat Informàtica, encara que hi ha una hora que se solapa en IA

Encara que sembli una titular apocalíptic, res, és del projecte xD

Ahir a la llista d’openMosix van enviar un mail informant d’un nou projecte, CosMos.

CosMos és un node virtual per a clústers openMosix per a win32! Pel que veig està basat sobre coLinux i és compatible (openMosixment parlant) amb la distribució CHAOS, una distribució en cd amb openMosix.

Encara està en fase experimental i té alguns/bastants problemes, però senzillament és una aplicació q s’instala a windows.

L’evolució d’aquest projecte ha de ser molt interessant, ja que pot donar pas a una aproximació de tecnologia grid per a openMosix, permetent aprofitar tots els cicles de cpu perduts amb els parcs d’estacions d’empleats (diguem profes del departament).

Emocionant Quan toqui setmana openMosix ho he de mirar, que ara toca setmana DriverpaLinux xD

La ip del frontend és 10.30.120.2 (resem per a que no es penje i el servidor DHCP no s’enfadi amb mi…)

xDDDDD

Després d’investigar i recompilar alguns kernels jugant amb parches he trobat la solució al problema.

Un resum del problema podria ser:

[root@compute-0-0 root]# /etc/init.d/gmond status
gmond dead but subsys locked

Tenia 2 possibles aproximacions, investigar sobre els pegats del nucli per donar-li suport nptl o investigar l’ús de les llibreries estandards que feia Ganglia. Per Murphy, primer vaig anar a la del nucli, gastant 3 dies sense resultats. I avui, per desesperació he anat cap a la de les llibreries.

Observant les llibreries compartides que utilitza gmond (amb greceptor és el mateix cas) podem veure:

[root@compute-0-0 root]# ldd /usr/sbin/gmond
libdl.so.2 => /lib/libdl.so.2 (0×40020000)
libresolv.so.2 => /lib/libresolv.so.2 (0×40023000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40035000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4004a000)
libc.so.6 => /lib/tls/libc.so.6 (0x4005a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Aquí veiem que utilitza les llibreries situades a /lib/tls, que són les llibreries compilades amb suport per NPTL, pro com el nucli no disposa d’aquest suport es penja a l’hora de crear els threads (LinuxThreads del vanilla versus NPTL threads de la llibreria TLS).

Primera solució a lo cutre:

# mv /lib/tls /lib/tls-mala

Doncs sorprenentment ha funcionat. Després de realitzar aquest canvi tornem a fer ldd a veure que trobem:

[root@compute-0-0 root]# ldd /usr/sbin/gmond
libdl.so.2 => /lib/libdl.so.2 (0×40020000)
libresolv.so.2 => /lib/libresolv.so.2 (0×40023000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40035000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4004a000)
libc.so.6 => /lib/i686/libc.so.6 (0x4009b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Voilà! Ara, automàticament agafa unes noves llibreries (les estandard) sense suport per NPTL, i inmediatament podem comprobar que ja funciona bé:

[root@compute-0-0 root]# /etc/init.d/gmond restart
Shutting down GANGLIA gmond: [FAILED]
Starting GANGLIA gmond: [ OK ]
[root@compute-0-0 root]# /etc/init.d/gmond status
gmond (pid 2803 2802 2801) is running…

Des del monitor web del Ganglia igualment podem veure que el sistema ha detectat que el compute-0-0 està actiu. Visca!

Només quedaran 2 passos:

1. Comunicar-ho a la llista de Rocks

2. Introduir-ho dintre el procediment general d’instalació del clúster.

Avui, buscant al llibre “Linux 6a Edicion” he trobat un subcapitul anomenat “Uso de ldd para localizar las bibliotecas compartidas necesarias”, que estava dintre el capitul “Compatibilidad entre bibliotecas”, que es un dels problemes que tinc. Aqui reproduire algunes de les parts mes importants.

Per examinar les biblioteques compartides que necessita un programa ho podem fer de la seguent forma:

# ldd /usr/bin/vi
libncurses.so.5 => /lib/libncurses.so.5 (0×40022000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0×40063000)
libperl.so.1 => /usr/lib/libperl.so.1 (0×40069000)
libutil.so.1 => /lib/libutil.so.1 (0×40168000)
libc.so.6 => /lib/libc.so.6 (0x4016b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4029a000)
libm.so.6 => /lib/libm.so.6 (0x402ec000)
libdl.so.2 => /lib/libdl.so.2 (0x4030e000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40311000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0×40326000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Aqui tenim una mostra de totes les llibreries que usa el vi.

“Si la biblioteca que falta tiene un numero de version principal diferente, simplemente encuentre el paquete que ofrece la version de biblioteca que necesita, e instalelo. Si los numeros de la version principal son diferentes, el restante software de su sistema no resultara afectado por la adicion de otra biblioteca, aunque se llame igual.”

Aixo es el que em passa amb la llibreria libc, que tinc instalades 2 versions amb diferent implementacio.

“Otra solucion es crear un enlace simbolico para el nombre de la biblioteca compartida que necesita. Enlacelo a una biblioteca ya existente en su sistema y confie en que la biblioteca sea compatible. Esto es posible que funcione en algunas circunstancias, dependiendo de cuanto se usa esa biblioteca y a que subrutinas hace referencia el programa. Sin embargo, esta es una medida para salir del paso, y deberia usarse solo cuando se sabe con seguridad que las versiones en cuestion son compatibles para los propositos del programa.”

Seguint a la pagina 422 explica el mecanisme que utilitza Linux per carregar els programes.

Mes endavant, i canviant de tema, hi ha un capitol anomenat “Consultas avanzadas sobre paquetes RPM” amb un subcapitol que diu “Extraccion de los contenidos de un paquete rpm (rpm2cpio)”, que explica com treure els fitxers d’un paquet RPM.

# rpm2cpio kernel-2.4.22-1.2174.nptl.src.rpm | cpio -ivd
Llistat dels fitxers extrets

Pozi, realment funciona be, fa exactament el que buscava fer. UOLE! Dintre contenia un tots els arxius .patch i el codi font del kernel 2.4.22, a part d’alguns scripts en awk que suposo que son per instalar tots els parches.

He d’acabar de llegir aquest capitol, ja que explica moltes coses que no sabia i necessito.

Be, tornant a la feina, novetats. He obert el kernel RHEL de la Rocks, el kernel-2.4.21-15.0.3.EL.src.rpm, i es mes intuitiu del que em pensava. Dintre hi ha el fitxer kernel-2.3.spec, que es l’encarregat de construir tot el paquet, agafant com a base el vanilla kernel que porta (un linux-2.4.21.tar.bz2) i despres li aplica tots els parches que troba oportuns (clarament especificats al .spec). Molt ben pensat, si senyor.

Despres de l’analisi del .spec he trobat el que buscava. Per a l’arquitectura x86 hi ha 2 pegats de l’NPTL:

1. linux-2.4.20-o1-nptl.patch

2. linux-2.4.21-nptl-network.patch
3. I por si las moscas tb apunto el linux-2.4.21-tux.patch

Probare d’aplicar-los al kernel 2.4.22, a veure que passa. A la 2.4.22 directament no l’he pogut aplicar, pq em donava un munt d’errors, ja que els parches no estaven preparats per a aplicar-se directament.

Seguint el .spec original he vist que el parche de l’nptl (el o1) era el 4t en aplicar-se sobre un kernel 2.4.21, de forma que he reproduit el procediment i sembla que ha funcionat. Ara ja l’estic compilant com si fos un kernel Rocks (vigilar pq fa preguntes sobre opcions noves del kernel). D’aqui 30 minuts sabrem mes (aixo es com preparar un pastis xD).

De moment poso els pegats i l’ordre en que els he posat:

1. linux-2.4.21-dailybk.patch

2. linux-2.4.21-select-upstream-bits.patch
3. linux-2.4.21-selected-ac-bits.patch

Aquesta setmana, a part de fer la previa de Periferics i reinstalar GNU/Linux tambe he tornat amb el projecte, tal i com tenia previst. Aquesta setmana i despres d’acabar tota la feina que tenia que fer per fi he pogut quedar amb la gran ajuda per al projecte, el David.

Doncs aixo, vaig quedar amb el tecnic del departament que m’ajuda amb el projecte (acabo de veure que ha fet traduccions de KDE), i li vaig explicar els dos problemes que tenia:

1. Els processos de prova del Linpack no migraven cap a un dels 2 ordenadors del cluster.

2. Ganglia no funciona, quan faig un /etc/init.d/gmond status em diu “gmond dead but subsys locked”.

Doncs be, nem per parts:

1. Per aquesta part va passar algo molt extrany, pero alhora molt normal. Quan va venir i li vaig explicar lo que tenia al seguir el procediment d’aqui. Un fitxer machines amb el nom dels 2 nodes que fa servir el linpack per computar:

   # vi machines
   compute-0-0
   compute-0-1

   A part, el fitxer de configuracio de l’HPL baixat de aqui.
   Lo altre ja es magia. Despres d’haver-ho intentat durant un munt de temps, ahir, i sense rao aparent, tot va funcionar. Murphy, oh, Murphy.

   Com a possible solucio a coses magiques he fet un test de memoria a la RAM de l’ordinador en questio, pero no ha donat cap error.

   Conclusio: A tornar a fer proves, o sigui que estare molt solet per aqui.

2. Be, el segon problema ja es mes peliagut. El David va estar-ho mirant, amb un munt d’eines, algunes conegudes pero que el seu nom me provoca panic (lease gdm) i altres que ni recordo el nom que no coneixia.

   Finalment vam arribar a 2 conclusions:

   • Per algun lloc, al fer el /etc/init.d/gmond start peta al crear els threads.

   • Utilitza unes llibreries situades a /lib/tls/lib enlloc de les de /lib, un comportament extrany.

   Per veure si era culpa del parche d’openMosix vaig dir que provaria d’instalar un kernel vanilla oficial, i aixi ho he fet. He reinstalat el kernel, i res de res, continua petant igualment.

   Conclusio: Aqui hi ha 2 conclusions xD

La desesperacio m’ha portat a un lloc que creia que mai acabaria anant (molt mal fet per part meva), anar a escriure a la llista de la NPACI Rocks. I nomes ha passat un dia i ja m’han contestat 4 persones. Coses d’aquestes son les que fan creure a la gent amb aixo del soft lliure…
Pos aixo, que m’han contestat, donant-me 2 possibles solucions:

1. Greg Bruno em contesta dient que potser es per culpa de que Ganglia utilitza comunicacio multicast. Aquesta es una de les opcions que ja havia pensat, pero he comprovat el kernel, “Networking Options”, i totes les opcions de TCP/IP multicasting estan marcades. Thanks.

2. Joe Landman, Federico Sacerdoti i David van der Spoel van pel mateix cami, que crec que es l’encertat.
   

   “If I’m not totally wrong, the RHEL kernels are patched for Posix
   threads. This breaks applications which still uses linux threads. In
   your case it could be the other way around. Vanilla kernel with Linux
   threads, application with Posix threads.

   If this is correct it could be resolved by patching your vanilla kernel
   with the posix threads.

   David”

   Doncs, si, els kernels RHEL (RedHat Enterprise Linux) estant parchejats per utilitzar els threads NPTL (Native Posix Threads Library) enlloc dels LinuxThreads, els que van inclosos al nucli per defecte fins a la 2.6. A partir del nucli 2.6 els threads seran d’aquest tipus NPTL, molt mes eficients i lleugers, pro aixo si, tocara migrar les aplicacions per adaptar-les a aquestos nous threads. Per altra banda, a part del kernel els NPTL tambe estan integrats a la libc a partir de la 2.3 em sembla, i es pot descarregar aqui.

   “The problem could be NPTL. RHEL 3 (ROCKS basis) uses it in a back
   ported manner from 2.6 kernels. If you do not use NPTL, some things
   which have been compiled against it will hang, fail, or dump core when
   they try to set up a thread. I saw this a bit with older
   linuxthread-ABI compiled binaries around the RH9 time frame.

   Unfortunately there is no way to make this work short of getting an RH
   kernel compiled and patched the way you need (unless you want to
   integrate their patches into your kernel).

   You might look at starting from
   ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/3WS/en/os/SRPMS/kernel-2.4.21-15.0.3.EL.src.rpm
   and seeing if you can patch from there.

   Joe”

   Aquesta es la resposta mes realista crec. L’unica solucio que tinc es introduir els parches dintre al meu nucli (cosa que aniria malament per a openMosix segurament…). A part, hi ha el problema de trobar els parches que exactament necessito. Pel que fa a investigar aquest kernel he de trobar alguna forma d’”obrir-lo” i veure que te per dins, a part que tb he de buscar els Changelog, ja que alli segur q ho diu.

   “As Joe says, I suspect the problem is in the threading libraries.
   Ganglia is multi-threaded (via pthreads) and we have seen segfaults
   with incompatible kernels. Greceptor uses python threading.

   Do other multi-threaded programs run? (mysql, etc). Also, if you could
   collect a core file from ganglia when it crashes that would be helpful.

   It sounds like you rebuilt and installed your new kernel fine using the
   Rocks infrastructure, which is good news to us

   I am sorry you are having problems with the new beast.

   Federico”

   Haure de parlar amb el David per a que m’ajudi a treure el fitxer core, ja que no en se i crec que es una cosa bastant dificil. Com a minim el Federico es veu afectat xD Pero dona la sensacio com si no haguessin provat mai aquesta funcionalitat, pq el Federico es un dels masters de Rocks.

   Be, amb aixo d’informacio he comencat a indagar… Pro fins i tot amb el google se’m resistia, pro poc a poc he anat trobant coses:

   • El que s’ha encarregat de posar els NPTL al nucli de Linux es diu Ingo Molnar. Dintre de la seva web personal de RedHat he trobat un parche anomenat nptl-2.4.22-ac1-A2, pero no he trobat la versio del kernel correcta per aplicar-lo. Com a curiositat, ja que despres segurament ho haure de mirar, tb te una altra carpeta anomenada tls-patches, que deu estar relacionada amb les llibreries que utilitza el Ganglia. Finalment tambe en te una altra anomenada TUX-patches, que m’acabo de donar compte que surten al menu de Networking del kernel de la Rocks. O sea que tb me l’haure de mirar.

   • Despres he trobat algo que pensava que seria molt sucos, pero al final no ha estat aixi. A aquestaweb he trobat un fitxer anomenat patch-2.4.22-nptl1.patch.bz2, un parche per al kernel 2.4.22, el que necessito.
     

     NPTL1 This is a patchset ripped from RedHat’s 2.4.22-1.2088.nptl kernel. It includes
     2.4.22-ac1 with some fixes as well as the linux-2.4.22-ac1-nptl-A1.patch which enables
     you to compile a NPTL glibc on a 2.4.22
     Linux system.

     L’ultim link no funciona, tota una pena.

     Doncs be, amb aquest parche i el nucli vanilla corresponent he compilat el kernel seguint el procediment establert. La compilacio no m’ha donat cap problema, pero a l’hora de reinstalar ha continuat petant, mira que realment creia que funcionaria…

     Conclusio: A lo millor instalant un altre parche (TUX) funcionara.

   • Un altre filo que he intentat explotar ha estat el de Fedora. Els kernels de Fedora curiosament tenen noms tipo kernel-2.4.22-1.2163.nptl.src.rpm. I si, despres d’estar mirant uns quants Changelogs he vist que els kernels porten el parche per d’NPTL. Intentare instalar un kernel d’aquestos per a la rocks, a veure que me diu. De moment no em deixa, ni per a athlon (que esta mal fet, pq l’hauria de compilar per a Rocks), ni el source, ja que no acabo de dominar el rpm.

     Conclusio: Aquest filo encara es pot investigar.
     Alguns links mes sobre Fedora:

     • Un .spec de la distro.

     • Parche nptl-2.4.22-ac1-A2.
     • Servidor per a la descarga de les actualitzacions de Fedora.
   • Una de les ultimes coses que he trobat ha estat la phil-list — A new thread library for GNU systems, la llista on es discuteixen els canvis dintre el threading de linux.

     Conclusio: He de mirar-la d’aprop, ja que aqui segur que sortiran direccions cap a webs amb els parches.

   • Tambe he buscat informacio sobre que era el TLS. Al final he trobat que son els “Thread Local Storage”, una part q tambe s’ha de modificar per tenir els NPTL. Un document que explica tot sobre el TLS es pot trobar aqui. Suposo que per aixo la rocks te 2 llibreries, les normals de /lib i les TLS a /lib/tls/lib.

     Conclusio: Tambe s’ha d’investigar mes per aqui, pero no se quins fruits donara.

   • Per ultim (que ja es molt tard), fa una estona he trobat que el kernel de la Rocks dintre del menu de Networking Options i dintre de “TCP/IP Networking” te una opcio anomenada “Threaded linUX application protocol accelerator layer (TUX)”, que ve a ser un altre parche que porta incorporat el RHEL. El que no se es que fa aquest parche ni si pot arribar a afectar la fallada del Ganglia. Suposo que no, pero aqui queda.

Algú havia sentit parlar mai d’una cosa anomenada “audit subsystem”??? Es veu que és un pedaç per al nucli, però encara no he acabat d’aclarir que fa. A més, pel google no té cap pàgina oficial. Màxim que he trobat:

   - http://people.redhat.com/faith/audit/
   - A la carpeta drivers del nucli hi ha una carpeta “audit” amb el codi font del pedaç.

De moment recompilaré el kernel introduint aquest pedaç, a veure que passa. Utilitzaré la 2.4.24 del CVS.

Me sembla que acabo d’observar un parell de coses curioses…:
- La primera vegada que instal lo un nucli només em crea una entrada al grub, en canvi, les successives reinstal lacions me’n crea 2.
- La primera arrencada m’instal la els paquets pvfs que feien falta.

Bé, després de molta investigació per fi he trobat que dimonis era això del audit. Audit només una de les eines d’un paquet, el Linux Audit Subsystem (LAuS). Info i paquets aquí i aquí. A la distribució Rocks es pot localitzar al lloc on es posen tooooooootes les coses:
   /home/install/rocks-dist/enterprise/3/en/os/i386/RedHat/RPMS/laus-0.1-56RHEL3.i386.rpm
   /home/install/rocks-dist/enterprise/3/en/os/i386/RedHat/RPMS/laus-libs-0.1-56RHEL3.i386.rpm

El problema que hi ha és amb el nucli, com sempre. “Your kernel has to support system call auditing to make these tools work” ve a dir que si fas servir un vanilla, patapam!! Pos que això no funciona. Aquí sorgeix una decisió:

      a) Buscar com intentar dotar d’aquest suport al kernel.
      b) Passar d’això, ja que no és gens necessàri, és només per paranoics de la seguretat.

Segons aquesta web l’audit system el que fa és “monitoritzar” tot el que els usuaris fan, però també indica que el “Kernel System Call Auditing” afecta el rendiment i usa un tall d’espai al disc.

Donat que l’ús del Ganglia és més important, millor abans em dedico al Ganglia.

Remirant per la web d’openMosix-Contributors he trobat un pedaç per fer que l’MPICH llençi els processos a través d’openMosix enlloc de llençar-los a través d’rsh.

 Avui he trobat perquè no funcionava la rutina d’mpirun. Llegint la secció corresponent del manual de Rocks 3.2.0 diu:

Finalment m’ho he repensat i no entrego el projecte per al juny. Motius:

- Inicialment em vaig proposar realitzar tot el disseny i modificació del kernel per incoporar a la distribució Rocks el pedaç d’openMosix. Quan em vaig proposar això ja sabia que ni en somnis podia comptar en tenir la solució implantada en 1 setmana. L’important és que he arribat on en vaig proposar, fins i tot tinc feta tota la documentació del projecte fins al punt que estic.

- Crec profundament que em sentiré molt millor personalment amb tot dintre el meu projecte i sabent que he fet una bona feina. Aquest haria de ser l’ulterior intenció de qualsevol projecte.

- Tenia un compromís moral, encara que entregués el projecte ara al juny em quedaria fins que no s’acabés la implantació.

- No tinc una urgencia incontenible per entregar al juny (però si que la tindré per al setembre xDDD).

Doncs això, ShinjixX 2 – openMosix+Rocks 1, però s’ha aplaçat el desenllaç del partit fins al setembre. Bé, el blog tornarà a tenir moviment!