Network Load Balancing cu TS Session Broker între două Terminal Server 2008
De ce TS Session Broker? Prin TS Session Broker ne putem asigura că un user este tot timpul redirecționat către acel server pe care are o sesiune deconectată, putem configura anumite servere să preia un volum mai mare de conexiuni decât celelalte din grup (de exemplu atunci când resursele hardware disponibile sunt diferite) sau putem restricționa complet accesul unor noi conexiuni către un server (de exemplu dacă planificăm să oprim serverul respectiv). Andrei Ionut Pop arata pas cu pas cum se realizeaza acest scenariu.
De ce Terminal Server 2008? Pentru că Terminal Server este o alternativă excelentă la clasicele aplicații instalate direct pe calculatoarele utilizatorilor. Reducem utilizarea de bandă între birourile din teritoriu și datacenter, eliminăm necesitatea unor servere în aceste locații, precum și a administratorilor de sistem care oferă suport.
De ce Network Load Balancing (NLB? Pentru că este o metodă ușor de configurat și extrem de scalabilă prin care obținem atât redundanță cât și o distributie egală a încărcării pe servere ce îndeplinesc funcții identice. Deși, în mod obișnuit, NLB este asociat cu serverele WEB, puțini țtiu că se preteaza la fel de bine pentru scenarii cu Terminal Server.
De ce TS Session Broker? Prin TS Session Broker ne putem asigura că un user este tot timpul redirecționat către acel server pe care are o sesiune deconectată, putem configura anumite servere să preia un volum mai mare de conexiuni decât celelalte din grup (de exemplu atunci când resursele hardware disponibile sunt diferite) sau putem restricționa complet accesul unor noi conexiuni către un server (de exemplu dacă planificăm să oprim serverul respectiv).
Iată așadar o demonstratie pas cu pas pentru realizarea scenariului de mai sus. Am folosit trei mașini virtuale, un server Windows 2003 R2 cu rol de Domain Controller și două mașini virtuale SRV1 și SRV2, cu Windows Server 2008 cu rolul de Terminal Server, membre în domeniu source.int.
Pasul 1. Instalăm rolul de Terminal Server pentru SRV2, folosind Server Manager.
1. | Selectăm Add Roles, iar din lista selectăm Terminal Services.
|
2. | Selectăm opțiunea de Terminal Server și pe cea de TS Session Broker. Se recomandă ca rolul de TS Sesssion Broker să ruleze pe un alt server, independent. Am fi putut folosi serverul Windows 2003 R2, deoarece acest serviciu a fost introdus începând cu această versiune de Windows Server.
|
3. | Nu vom selecta Network Level Authentication deoarece asta presupune să folosim clienti cu RDP v6.1, prezenți nativ numai în Windows Vista SP1, Windows Server 2008 și Windows XP SP3. RDP v6.1 aduce, printre altele, un nivel suplimentar de securitate, întrucât autentificarea conexiunii se face înaintea conectării propriu zise la serverul remote.
|
4. | La sfârșit ni se cere restart. |
5. | Procedăm identic pentru configurarea Terminal Server pe SRV1, cu unica diferența că nu mai este necesar să instalam și serviciul de TS Session Broker. |
Pasul 2. Instalam Network Load Balancing, care în Windows Server 2008 este un Feature, așadar extinde funcționalitatea unui rol de bază.
1. | Pe serverul SRV2, tot din Service Manager, de la Features, adaugăm un nou Feature, Network Load Balancing.
|
2. | Se instalează similar și pe SRV1. |
3. | După instalare, accesăm Network Load Balacing în Administrative Tools. |
4. | Selectăm New Cluster, ne conectăm la serverul de pe care rulam , SRV2, apoi selectăm adresa IP a plăcii de rețea conectată la subnetul cu celelalte servere din cluster, în cazul nostru 192.168.1.3. (domain controller-ul are adresa 192.168.1.1).
|
5. | La cluster IP completăm 192.168.1.10, care va fi adresa generică a clusterului nostru. |
6. | La Full Internet Name scriem ts.source.int, acesta va fi numele clusterului. Clienții se vor conecta remote către serverul ts (la adresa 192.168.1.10), iar serviciul NLB va distribui în mod egal conexiunile către toți membri clusterului, în cazul nostru SRV1 și SRV2, proces total transparent utilizatorilor. |
7. | La Cluster Operation Mode alegem modul Unicast, configurație recomandată de altfel de Microsoft.
|
8. | La New Cluster: Port Rules modificăm regula existentă, selectând numai portul TCP 3389, pentru Remote Connection, iar la Affinity selectăm None.
|
9. | În acest moment am adaugat SRV2 în clusterul nostru.
|
10. | Procedam identic pentru adaugarea lui SRV1 în cluster.
|
11. | Așa trebuie să arate fereastra noastră NLB Manager, cu două servere active.
|
12. | Adaugăm în serverul DNS o înregistrare de tip A pentru adresa numele ts.source.int, rezolvată prin adresa 192.168.1.10, adresa generică a clusterului. După cum spuneam, toți clienții nostri se vor conecta remote la serverul ts.
|
Pasul 3. Configurăm TS Session Broker. Acest serviciu (care porneste automat) l-am instalat la început pe SRV2. TS Session Broker crează automat pe calculatorul instalat un grup local, numit Session Directory Computers, și se aplică pentru toate calculatoarele aflate în acest grup.
1. | Așadar, adaugăm în acest grup cele două servere SRV1 și SRV2.
|
2. | Pe SRV2, în Service Manager, la rolul Terminal Server, la Terminal Server Configuration, selectăm Member of farm în TS Session Broker și completăm precum în poza de mai jos. Am selectat srv2, serverul pe care rulează serviciul, și am denumit ts ferma de Terminal Servere. Atenție, această valoare nu are nici o legatură cu numele clusterului ales în NLB, dar pentru usurință am folosit același nume. Prin modificarea parametrului Relative weight of this server în the farm putem configura nivelul de încărcare pe server, de exemplu, prin selectarea valorii 50, jumatate dintre conexiunile directate initial către acest server vor fi redirectate către celelalte servere din ferma. Selectând valoarea 0, nici o conexiune nu va fi directată spre acest server. |
3. | Configurăm identic pe SRV1: srv2, serverul pe care rulează serviciul, și ts ferma de Terminal Servere.
|
4. | Pentru a putea testa modul în care sunt distribuite mai multe conexiuni inițiate de pe același server (de exemplu de pe Domain Controller), pe fiecare dintre cele două Terminal Servere trebuie să modificam parametrul Restrict each user to a single session din Yes în No.
|
Mecanismul de functionare este foarte simplu:
1. | Clienții se conectează remote la ts. Serverul DNS rezolvă acest nume prin IP-ul 192.168.1.10, adresa clusterului NLB, și trimite cererea la cluster. |
2. | Clusterul NLB ascultă pe portul 3389, deci va prelua conexiunile și le va trimite alternativ unuia din cele două servere disponibile și active. Acesta realizează funcția simplă de balansare, dar cel mai important, realizează și funcția de redundanta, în caz că unul din servere este oprit, el detectează acest lucru și trimite toate cererile spre celălalt server. |
3. | Cele două Terminal Servere primesc conexiunile de la NLB și le trimit mai departe către serverul care rulează serviciul TS Session Broker. |
4. | TS Session Broker decide spre ce Terminal Server trebuie făcută conexiunea, în funcție de modul în care este configurat. |
Pe parcursul descrierii configurării nu am precizat unele explicații suplimentare, dorind ca acest articol sa fie unul inițial. În articolele viitoare voi intra in detalii.
