- Service Balancing Load Network (NLB). În principiu, este destinat pentru echilibrarea traficului TCP / IP de intrare. NLB este de obicei folosit pentru servere web.
- Server clusters. Implementat pentru a oferi failover failover între calculatoarele grupate. Serviciul Cluster este utilizat, de obicei, pentru aplicații care funcționează cu baze de date.
Nu puteți aplica ambele tehnologii pe același server, dar puteți utiliza împreună aceste două soluții de cluster pentru a implementa funcții complementare, de exemplu, pentru a face baza de date accesibilă vizitatorilor pe site.
Clustere de echilibrare a încărcării rețelei
Repartizarea încărcării în rețea (NLB) este o dezvoltare software utilizată în clustering-ul Microsoft Windows pentru a scala performanța programelor IP prin distribuirea cererilor clientului între mai multe servere dintr-un cluster. NLB este cel mai frecvent utilizat pentru a îmbunătăți performanța și disponibilitatea aplicațiilor Web, dar poate fi, de asemenea, utilizat pentru a îmbunătăți performanța mai multor aplicații IP din cadrul companiei dvs.
Notă. Service Network Load Balancing în forma sa actuală a apărut ca un serviciu de înlocuire reproiectat pentru Windows Load Balancing de service (WLBS), utilizat în Windows NT 4. Cu toate acestea, veți găsi că există încă componente ale sursei WLBS, cum ar fi un software de management al liniei de comandă, wlbs .exe, este încă folosit pentru compatibilitate înapoi.
- Ediție standard;
- Enterprise Edition;
- Datacenter Edition;
- Ediția Web.
Beneficiile de echilibrare a sarcinii în rețea
promptitudine
Unul dintre principalele avantaje ale serviciului NLB este disponibilitatea ridicată pe care acest serviciu o oferă pentru aplicațiile pentru întreprinderi. Software-ul cluster poate schimba automat distribuția solicitărilor clientului în cazul unei defecțiuni a serverului. Pentru a face acest lucru, clusterul și serverele individuale se monitorizează reciproc. Între servere, precum și între fiecare server și cluster există schimb de mesaje de grup sau de difuzare.
În cazul în care starea serverului (sau mai multe servere) în cadrul modificărilor de cluster, serverele active, rula un proces care se numește „fuziune“ (convergență), pentru a determina care servere ca stânga activă și să redistribuie sarcina între ele. În mod implicit, membru cluster NLB determină pierderea timp de cinci secunde, și efectuează procesul de fuziune în următoarele cinci secunde. Odată cu îmbinarea, fiecare nod de cluster continuă să proceseze pachetele de aplicații în conformitate cu regulile anterioare fuziunii.
În cazul în care fuziunea este inițiată prin pierderea unuia dintre serverele, cererile de aplicare care au fost procesate de către server a eșuat returnat neîndeplinite până când solicitările vor fi îndeplinite reafectarea (la finalul fuziunii). Această condiție de eroare trebuie să fie luate în considerare în starea de tranziție a utilizatorului sau aplicația, dar nu cel mai serviciu NLB.
Dacă un alt server gazdă este adăugat în cluster, același proces de îmbinare permite noii gazde să primească cota de trafic. Ca rezultat, clusterul este extins într-o manieră complet transparentă atât pentru clienți, cât și pentru aplicații.
scalabilitate
NLB oferă două niveluri de scalabilitate.
- Scalabilitatea acțiunilor Creșterea numărului de utilizatori și creșterea traficului este neîngrădită datorită distribuției constante a cererilor, permițând accesul egal la toți clienții la aplicație sau la serviciu.
- Scalabilitatea sistemului Puteți include componente suplimentare (servere sau procesoare) în cluster.
controlabilitatea
Repartizarea încărcării rețelei este eficientă deoarece clusterul este gestionat ca o singură entitate dintr-un singur punct de gestionare (care poate fi la distanță). Administratorii gestionează clusterul utilizând comenzi și script-uri pentru a porni, opri și gestiona clusterul. În plus, capacitatea de a transfera serverele individuale în modul offline, fără a reduce performanțele clusterului, face mai ușoară întreținerea și actualizarea sistemelor de operare.
NLB arhitectura
Algoritmul definit în timpul procesului de îmbinare a cluster-ului permite fiecărui nod din cluster să decidă dacă va procesa sau nu următorul client. Nodul de procesare trimite pachetul către protocolul IP și toate celelalte noduri ar elimina acest pachet. Pentru fiecare gazdă, puteți seta procentajul încărcării sau puteți distribui sarcina în mod egal între toate gazdele.
NLB interceptează numai pachetele TCP și UDP. Pachetele altor protocoale IP sunt transferate în stiva protocolului și procesate de toate nodurile clusterului NLB.
Echipamente și protocoale
Cererile clienților primite sunt mapate la gazdele de cluster printr-un algoritm de distribuție. Când un pachet sosește, toți gazdele efectuează o cartografiere simultan. Aceasta vă permite să determinați rapid ce gazdă ar trebui să gestioneze acest pachet. Acest algoritm de filtrare simultană este mai eficient pentru procesarea pachetelor decât programele care utilizează algoritmi centralizați de echilibrare a încărcării. Filtrarea centralizată asigură modificarea și retransmiterea pachetelor, ceea ce poate crește timpul de întârziere. Pe de altă parte, filtrarea simultană asigură o viteză globală ridicată.
NLB gestionează conexiunile TCP și datagramele pentru UDP prin aplicarea filtrării de intrare a traficului înainte de a accesa programele protocolului TCP / IP. Procesele TCP / IP procesează numai protocoalele TCP și UDP și toate gestionările sunt aplicate la nivelul portului.
NLB poate fi configurat pentru a gestiona traficul cluster în detaliu folosind instrumente cum ar fi reguli de port sau afinitate. Pentru mai multe informații, consultați secțiunea "Instalarea și configurarea încărcării în rețea".
Clustere virtuale
Serverele virtuale au următoarele proprietăți.
Configurarea aplicațiilor
Există mai multe moduri de a configura aplicațiile într-un cluster NLB. Clusterul poate fi configurat astfel încât o copie a programului server să fie executată pe fiecare gazdă; sau aplicația poate rula pe aceeași gazdă, atunci când toate cererile sunt trimise la această gazdă, în loc să distribuie uniform sarcina pe întregul grup. Decizia depinde de tipul de aplicație. De exemplu, aplicațiile care necesită centralizare, cum ar fi Microsoft Exchange Server, aparțin unei singure gazde. În plus, cererile de scriere către baza de date pot fi trimise la serverul bază de date dedicat din sistem. Dacă încărcarea bazei de date este echilibrată într-un cluster, fiecare nod de cluster poate avea o copie proprie a acestor date. Actualizările la conținutul tabelei bazei de date trebuie să fie sincronizate prin fuzionarea obișnuită în modul offline. Cu toate acestea, în majoritatea cazurilor, bazele de date critice sunt implementate într-un mediu de cluster server care permite failover, nu NLB (a se vedea "Server Clusters" de mai jos).
NLB în forma sa pură este cel mai potrivit pentru stocarea de date descentralizate sau pentru aplicații care nu acceptă date de la clienții care accesează serverul (adică, disponibil pentru aplicații numai de citire bazate pe TCP sau UDP). Site-uri web sunt ideale „candidați“ pentru a fi utilizate cu NLB, deoarece face ușor de a oferi fiecare gazdă pagini de copiere curente (care sunt de obicei statice), oferind simplitatea și viteza de prelucrare a unor volume mari de trafic. Pentru clienții Web care au nevoie de acces la baza de date, serverele Web pot trimite cereri către serverul de baze de date. Există, de asemenea, următorii candidați pentru care NLB este potrivit:
- HTTP, HTTPS, FTP, TFTP și SMTP prin TCP / IP
- HTTP prin portul SSL 443
- Portul FTP 21, portul 20, porturile 1024.65 și portul 535
- Portul SMTP 25
- Serviciile Terminal - port 3389
- Servere Web (cum ar fi Microsoft Internet Information Services) - port 80
- Servere Web care utilizează un DNS circular
- Servere de rețele private virtuale (VPN)
- Streaming media servere.
O aplicație poate fi implementată într-un cluster NLB dacă mai multe instanțe ale acestei aplicații pot fi executate simultan fără erori sau daune.
Servere de aplicații și conexiuni cu starea modificată
Există două tipuri de conexiuni între clienți și gazde pentru serverele de aplicații și sunt descrise, de obicei, prin termenul state-connection (conexiune cu o stare variabilă).
- Interclient-state (stat cu toți clienții). Actualizările sunt sincronizate cu tranzacțiile efectuate pentru alți clienți. Un exemplu este actualizarea bazei de date a stocului pe site-ul de comerț electronic după vânzarea de bunuri prin intermediul conexiunii cu clientul.
- Intraclient-state (de stat la nivelul unui client). O stare menținută pentru un anumit client pe parcursul unei singure sesiuni, incluzând, de exemplu, vânzarea de produse (de obicei folosind procesul de procesare a "coșului de cumpărături") pe site-ul de comerț electronic. De fapt, pentru majoritatea site-urilor de comerț electronic, procesul de procesare a coșului de cumpărături poate cuprinde mai multe conexiuni separate cu un singur client.
Serviciul NLB funcționează cel mai bine în cazul în care este folosit pentru a furniza o interfață scalabilă pentru servicii care nu se schimba starea lor (de exemplu, pentru o serie de aplicații standard HTTP bazate pe Web), chiar dacă serviciul accesează baza de date a serverului de aplicații partajate.
NLB nu ar trebui să fie utilizat niciodată cu conexiuni interclient. Aplicațiile care utilizează acest tip de conexiune statală nu permit mai multe instanțe de conexiuni care permit accesul la baza de date partajată și sincronizarea actualizărilor în același timp.
NLB poate fi folosit pentru a scala aplicații cu state intraclient, chiar și în cadrul unei sesiuni care acoperă mai multe conexiuni. Când activați una dintre opțiunile de afinitate pentru clienți, NLB transmite toate conexiunile TCP la aceeași gazdă de cluster, ceea ce vă permite să mențineți starea sesiunii în memoria acelei gazde. (Pentru aplicațiile client / server care încorporează starea în cookie-uri sau le trimit într-o bază de date a aplicațiilor, nu este necesară o rudenie pentru clienți.)
Articole similare
Trimiteți-le prietenilor: