Unul nu este un războinic în domeniu: cum se creează un cluster de eroare
Se întâmplă adesea că, după lansarea unui proiect ambițios pe Internet și a PR-ului său de succes în mass-media, compania se așteaptă la un mare aflux de vizitatori. Din păcate, lumea noastră nu este perfectă și se întâmplă astfel încât site-ul să nu facă față unui astfel de flux de vizitatori, numit "habraeffect" în cercurile noastre, și începe să încetinească. În consecință, compania își pierde atât banii, cât și reputația. În astfel de cazuri, programatorii îi dau vina pe administratori pentru vină și pe administratorii programatorilor. Se pare un cerc vicios.
Pregătirea
Pentru a crea un cluster de eroare, avem nevoie de două mașini n1 și n2 pentru serverele GlassFish (una dintre ele va avea DAS și două servere GF); mașină lb1 pentru echilibrarea încărcăturii; db1 pentru DBMS. Asigurați-vă că toate mașinile se "văd" reciproc (ping).
Cluster Configuration
Configurația cluster-ului va fi efectuată în principal din linia de comandă care utilizează utilitarul de la livrarea GlassFish asadmin
- Descărcați distribuția GlassFish
wget download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip
și despachetați-o. - Pornim o instanță a unui domeniu administrativ (domain1):
./ asadmin domeniu-domeniu1
GlassFish în mod implicit dezactivează conexiunile la distanță către domeniul administrativ. Și toate nodurile clusterului (Nod Agenți), pe lângă nodul pe care se află DAS, nu pot interacționa cu acesta.
O eroare tipică:
Nu a reușit să se întâlnească cu DAS pe n1: 4848. Verificați dacă acest server se execută, că serverul este configurat corect și că acest server este configurat să permită accesul la distanță.
Pentru a rezolva aceasta:
./ asadmin enable-secure-admin
și reporniți domeniul administrativ.
Creați clusterul în sine:
./ asadmin crea-cluster c1.
Creați două instanțe ale serverului de aplicații care se află pe aceeași mașină fizică:
./ asadmin create-local-instanță -cluster c1 i1
./ asadmin create-local-instanță -cluster c1 i2 - Porniți cluster-ul:
./ asadmin start-cluster c1 - Adăugați instanțe noi pe mașina n2 (comenzile sunt executate fizic pe n2):
. / asadmin -host n1 -port 4848 crea-local-instanță -cluster c1 i3
./ asadmin -host n1 -port 4848 crea-local-instanță -cluster c1 i4 - În administratorul consolei, găsim instanța nou creată, modificăm tipul acesteia la SSH, modificăm valoarea câmpului Nod gazdă la n2. În acest caz, trebuie să specificăm numele de utilizator și parola pentru accesul SSH la mașina n2. Porniți clusterul. Vedem că toate copiile funcționează.
Echilibrarea încărcăturii și HA
Acum, de fapt, totul este gata pentru a consolida aplicația în cluster, dar pentru noi acest lucru nu este suficient, pentru că Echilibrarea încărcăturii și HA nu sunt furnizate.
Trebuie să instalăm și să configuram balancerul de sarcină pentru a facilita utilizarea de către utilizatori a aplicației:
- A fost adresată o singură url;
- solicitările lor au fost distribuite uniform în toate instanțele serverelor de cluster;
- în caz de eșec al unui anumit număr de copii, utilizatorii pot continua lucrul cu aplicația în modul normal;
- și nici nu știau despre "bucătăria" internă a clusterului.
În general, GlassFish "conține" un plug-in de echilibrare pentru serverele http populare. Cuvintele "conține" și "populare" nu sunt introduse în zadar în citate, tk. acest plugin nu este conținut în versiunea Open Source a GF, pe lângă acesta este suportat de serverul Web Oracle iPlanet, serverul Oracle HTTP, serverul HTTP Apache, Microsoft IIS. Știm cu toții că Apache a fost odată bun, dar acum există soluții mai eficiente.
Printre candidați: NGINX, HAProxy, lighthttpd.
Vom sprijini producătorul intern și vom alege NGINX. care, în plus, captează din ce în ce mai mult piața.
- Instalați NGINX:
#yum instala nginx
#nano /etc/nginx/nginx.conf - Configuram NGINX pentru a echilibra cererile rotunde pentru 4 servere de aceeași scară, cu suport pentru sesiuni lipicioase (următorul lucru face parte din config și serverul este pornit).
upstream backend ip_hash;
server 192.168.0.1:28080 max_fails = 5 fail_timeout = 15s;
server 192.168.0.1:28081 max_fails = 5 fail_timeout = 5s;
server 192.168.0.2:28082 max_fails = 5 fail_timeout = 5s;
server 192.168.0.2:28083 max_fails = 5 fail_timeout = 5s;
>
Trebuie remarcat faptul că aceasta este cea mai simplă configurație care stabilește sesiunile de utilizator pentru un anumit server folosind metoda ip_hash - Pentru ca HA să funcționeze, este necesar ca gazdele n1 și n2 să aibă un domeniu parental comun. De exemplu, cluster.com. Pentru a face acest lucru, trebuie să modificați fișierele / etc / hosts pe ambele mașini după cum urmează:
n1:
127.0.0.1 localhost
127.0.1.1 n1.cluster.com
127.0.0.1 n1.cluster.com
192.168.0.2 n2.cluster.com
n2:
127.0.0.1 localhost
127.0.1.1 n2.cluster.com
127.0.0.1 n2.cluster.com
192.168.0.1 n1.cluster.com - Pentru a verifica funcționarea multicast pe fiecare mașină fizică a clusterului, efectuați:
./ asadmin validate-multicast - În consola administrativă DAS GlassFish, trebuie să modificați mențiunea n2 la n2.cluster.com
- Pentru ca GlassFish să replice sesiunile Http între instanțele clusterului, este necesar ca descriptorul web al aplicației să conțină instrucțiunile corespunzătoare (etichetă
) și când aplicația este instalată, setați steagul Avalabilitate.
Instalarea și configurarea bazei de date
În acest exemplu, vom folosi PostgreSQL.
Instalăm DBMS și creăm un nou utilizator și o bază de date.
# instalați yum postgresql-8.4
# service postgresql initdb
# serviciu postgresql începe
În PostgreSQL, numai conexiunile locale sunt acceptate implicit. Pentru a remedia acest lucru aveți nevoie pentru a corecta /var/lib/pgsql/data/pg_hba.conf fișier de configurare, în care trebuie să specificați subrețele permise: gazdă toate toate 192.168.0.0/24 MD5
Asta-i tot! Acum putem decomprima în sfârșit aplicația (de exemplu, vom folosi jforum).
La mine, să spun adevărul, după toate aceste ajustări "creierul" aproape "a fiert". Am avut o "sudoare" bună pentru a automatiza întregul proces descris mai sus în Jelastic și transforma-l în câteva clicuri de mouse.
Puteți încerca ce a venit din ea, pe jelastic.com
Să vedem cum serverele consumă mai multe resurse în configurația clusterului tolerant la erori (cu replicarea sesiunii) pe exemplele de servere disponibile în prezent în Jelastic.
Să începem cu GlassFish. Acest server are multe avantaje: suport complet pentru gruparea industrială, o gamă largă de funcții, multe module, fiabilitate ridicată, panou administrativ etc. Dacă ne uităm la tabelul următor, s-ar părea că GlassFish este suficient de "lăcomie", dar acest lucru este pe deplin justificat prin funcționalitatea sa.
Notă: în toate tabelele, specificăm nu numai consumul de memorie în MB, ci și numărul de claudlet consumat. Scurgerile sunt modul nostru de a număra resursele consumate. O placă este de 128 MB de memorie RAM și aproximativ 200 Mhz core CPU.
Tomcat 6 este cel mai popular server printre dezvoltatorii noștri, datorită simplității și stabilității sale. Alegerea optimă pentru majoritatea aplicațiilor web. Câte resurse îi "mănâncă" cu toate opțiunile de configurare posibile, puteți vedea în următorul tabel:
Tomcat 7 are de asemenea ceva de spus: este și mai productiv și mai eficient decât predecesorul său. În consecință, necesită costuri puțin mai ridicate:
Cât despre Jetty. atunci acest server de aplicații devine din ce în ce mai popular printre dezvoltatori (după cum arată statisticile noastre). De asemenea, este cea mai "ușoară", vedeți-vă:
După cum știți deja, GlassFish este un server de aplicații Java EE extrem de fiabil, cu suport complet pentru gruparea industrială și o gamă largă de funcții.
Până recent, Glassfish a fost folosit în Jelastic Java PaaS pur și simplu ca un server separat, acum suportăm toate funcțiile acestui server, inclusiv disponibilitatea ridicată (HA).
Am salvat arhitectura cluster "nativă" GlassFish, care se bazează pe conceptul de domeniu administrativ. Domeniile administrative constau din clustere și instanțe, controlate de DAS (Server Administration Server).
Puteți gestiona depozitul central folosind consola de administrare. Acesta este un ușor de utilizat GUI care acceptă toate caracteristicile disponibile în Glassfish. DAS gestionează instanțele de domeniu Java, iar GMS (Service Management Group) este responsabil pentru furnizarea de informații despre cluster și instanțele sale.
Sesiuni de replicare în GlassFish
Exemplele din grupuri sunt împărțite în perechi. Dacă un exemplu nu reușește, utilizatorii ale căror cereri au fost procesate pe acesta sunt transferate automat într-o altă instanță a clusterului. "Instanța-partener" are deja toate sesiunile celor căzuți, astfel încât utilizatorul final nu va observa nicio schimbare. Dacă ambele instanțe nu reușesc, solicitările utilizatorului sunt redirecționate către un alt cluster. Pentru a redirecționa cererile, Jelastic folosește balancerul NGINX (ca în cazul altor servere de aplicații).
scalare
Desigur, nu am uitat de scalare. Oferă scalarea orizontală și verticală pentru cazurile de creștere sau scădere a încărcării de pe server. Aceasta înseamnă că atât mărimea cât și numărul de clustere pot varia. Jelastic este primul PaaS care oferă un sistem perfect de scalare.
Arhitectura clusterului GlassFish din Jelastic este foarte aproape de standard, astfel încât să puteți utiliza toate caracteristicile sale și chiar mai mult.
Articole similare
Trimiteți-le prietenilor: