Cu capu' in nori

Intr-un final a fost inclusa aceasta functionalitate in openSSL si este compilata standard incepand cu versiunea 0.9.8l. Aceasta extensie permite ssl-ului ca in momentul in care se face peering-ul de sesiune HTTPS sa fie transmis si numele de domeniu pentru care se face cererea HTTP. Astfel fiecare virtualhost poate avea propriul certificat si aceasta va fi trimis corect browserului spre autentificare. Pana in acest moment nu puteau fi tinute 2 site-uri cu openSSL folosind aceeasi adresa ip pentru conectare ci doar un modul de testare ce foloseste gnuTLS.

Pentru testare am folosit openssl-0.9.8l si ultima versiune de apache-2.2.14 avand modulul ssl built-in (–enable-ssl), astfel:

1. compilare openssl:
   1. ./config –prefix=/opt/openssl.l
2. compilare apache2:
   1. ./configure –prefix=/opt/httpd –enable-ssl –with-ssl=/opt/openssl.l
3. configurare apache2:
   1. configurare 2 virtualhost-uri ssl in /opt/httpd/conf/extra/httpd-ssl.conf
      1. vhost1.doraz.local cu certificat avand CN  vhost1.doraz.local
      2. vhost2.doraz.local cu certificat avand CN  vhost2.doraz.local
   2. start apache:
      1. /opt/httpd/bin/httpd

Am testat ambele host-uri cu un browser si obtin certificatele corecte (fara eroare de certificat pentru nici unul din domenii).

Instalarea Sun Grid Engine in sine nu este un proces dificil dar necesita putina atentie.

Pentru inceput trebuie pregatit terenul si aici revin la arhitectura sistemului de planificare a executiei joburilor.

Din figura se poate deduce ca avem nevoie de o masina (fizica sau virtuala) care sa joace rol de master (pe ea va rula sge_master) si una sau mai mai multe masini (fizice sau virtuale) ce vor avea rol de execution nodes (pe ele va rula sge_execd).

SGE ofera posibilitatea de a rula sub un anumit user. Aceasta poate fi considerat un bonus la capitolul securitate: daca cineva reuseste sa compromita unul din seviciile sale ce ascultata pe retea nu va putea face prea mult rau sistemului, din lipsa de drepturi. Este recomandata rularea sub un user neprivilegiat (si SUN recomanda acest lucru). Important de retinut ca userul va trebui sa aibe acelasi uid:gid pe toate masinile din ce vor fi integrate in SGE.

Inaintea inceperii instalarii trebuie ca urmatoarele servicii sa fie functionale:

- rezolvarea de nume pentru toate hosturile din cluster, directa si inversa

- autentificare centralizata, de preferinta LDAP pentru user management

- user home directories exportate prin nfs

Instalarea propriu-siza consta din instalarea procesului master (sge_master) pe o masina separata. Aceasta se face prin invorcarea comenzii ./inst_sge -m. Nodurile worker se instaleaza cu ./inst_sge -x.

Pentru mai multe detalii accesati sectiunea de tutoriale sau link urmator: http://doraz.ro/tutorials/installing-sun-grid-engine/.

Sun Grid Engine este o solutie de planificare pe griduri oferita de Sun Microsystems.

De ce planificare pe griduri?

In primul rand este nevoie de rezervare de resurse: vrem ca programul (job) pe care il rulam sa ruleze cu performante maxime iar pentru acest lucru nu trebuie ca doi utilizatori sa foloseasca aceeasi masina pentru procesare.

Securitatea este si ea un punct de interes in aces caz: datele unui job nu trebuie sa se amestece cu datele altui job al altui utilizator.

Arhitectura

Sun Grid Engine (SGE) foloseste modelul master – worker in care exista un master (qmaster) ce gestioneaza noduri worker, noduri pe care se ruleaza efectiv joburile. Astfel se poate face si o gestionare centralizata a nodurilor folosind utilitare incluse in pachet (qlogin, qrsh).

Slot

Un slot este o unitate de executie. Poate fi un core, procesor sau masina. In functie de acest lucru este necesar sa nu folosirea de medii paralele de executie.

Queue

In queue este o coada de prioritati dinamica in care joburile asteapta sa fie rulate. Se pot creea oricate cozi in functie de necesitate. Un caz comun este creearea a cate o coada pentru fiecare tip de procesor existent in sistem si includerea acelor noduri ca si noduri worker pentru acea coada.

Queue-urile ofera facilitatea de a rula scripturi particulare inainte si dupa rularea unui job (prolog si epilog scripts). Acestea sunt utile atunci cand se doreste rulare de joburi IntelMPI. IntelMPI nu se integreaza cu SGE si astfel layerul de comunicare peste retea trebuie bootat manual (looseless integration). OpenMPI nu are aceasta problema.

Parallel environment

Am vorbit mai sus de joburi MPI. In functie de cum este alocat un Slot este nevoie de a rezerva mai mult de unul pentru a rula cu un numar de procese dorit. Astfel la rularea jobului pe langa specificarea queue-ului este necesara si specificare pe-ului parallel environement) impreuna cu numarul de sloturi de rezervat.

Instalare

Pentru instalarea SGE este necesar cel putin o masina. Aceasta va avea rol de master host si de submiter host dar poate avea si rol de execution host (in cazul in care se doreste executarea seriala a unor procese batch). Pentru performanta se recomanda ca nodurile worker sa fie diferite de master.

Atasez mai jos o prezentare pe care am realizat-o pentru un curs de la facultate.

sprc-prezentare

Recent am utilizat ceea ce se numeste, conform man ssh, reverse ssh. Este o metoda foarte utila in cazul in care vrem sa accesam calculatoare aflate in spatele NAT-ului (o masina virtuala pe o statie aflata intr-o retea privata). Pentru a realiza acest lucru aproape nu este nevoie de nici o configuratie: este nevoie doar de un server ssh cu tcpforwarding activat (AllowTcpForwarding yes).

Conectarea se face in felul urmator:

ssh -R 60000:10.0.0.1:22

acest lucru inseamna ca portul remote 60000 este forwardat local catre 10.0.0.1 pe portul 22. De asemenea se poate accesa orice statie din retea sau din afara ei atata timp cat exista conectivitate cu aceasta. Pentru conectare pe statia remote trebuie apelata comanda ssh root@localhost -p 60000 ce va realiza, in acest exemplu, o conexiune ssh cu statia 10.0.0.1 aflata in reteaua privata.