Host Nodes și Management Cluster

Această documentație a fost mutată în arhivă și nu este acceptată.

Clusterul cache Windows Server AppFabric este un grup dinamic de servere care funcționează împreună ca un singur cache logic pentru aceste aplicații. Pentru a gestiona operațiile cluster dintre nodurile cache, sunt necesare anumite costuri suplimentare. Rolul gestionării clusterului este responsabil de gestionarea nodurilor de cache și a clusterului cache propriu-zis.







În funcție de modul în care este instalată cache-ul distribuit, rolul de gestionare a cluster-ului are două opțiuni. Dacă setările de configurare a clusterului sunt stocate în baza de date SQL Server, această instanță a SQL Server poate fi, de asemenea, utilizată pentru a efectua rolul de gestionare a clusterului.

Dacă este selectat un dosar de rețea partajat pentru stocarea setărilor de configurare a clusterului, rolul de gestionare a cluster-ului este întotdeauna realizat de noduri de cache speciale, numite noduri gazdă. Nodurile gazdă efectuează aceleași sarcini ca și alte noduri de cache care nu sunt atribuite de gazde, dar sunt, de asemenea, responsabile de rularea rolului de gestionare a clusterului împreună cu alte noduri gazdă.

Următorul tabel arată modul în care selecția este asociată cu opțiunile de gestionare a clusterului în timpul instalării. Pentru mai multe informații despre alegerea opțiunilor de configurare corespunzătoare, consultați Cum se stochează configurația clusterului (cache în Windows Server AppFabric).

Cluster configurație tip magazin

Cluster configurație locație magazin

Sarcinile rolului managementului clusterelor

Există doi parametri de configurare de bază care determină modul în care clusterul funcționează în legătură cu gestionarea clusterului.

  • leadHostManagement. Această setare a nivelului de cluster determină locul în care va fi rulat rolul de gestionare a clusterului. Dacă parametrul este setat la "true", nodurile principale acționează ca rol de gestionare a clusterului. Dacă ați selectat folderul de rețea partajat pentru a stoca setările de configurare a clusterului, valoarea true este singura valoare validă pentru acest parametru. Valoarea "false" înseamnă că rolul de gestionare a clusterului va fi rulat de către SQL Server sau de la un furnizor personalizat. Dacă utilizați SQL Server sau un furnizor personalizat pentru a stoca setările de configurare a clusterului, puteți seta acest parametru la "true" și permite nodurilor principale să îndeplinească rolul de gestionare a clusterului.
  • leadHost. Această setare a nivelului de cluster determină care noduri de cache vor fi nodurile principale atunci când execută rolul de gestionare a clusterului. Chiar dacă SQL Server este selectat pentru a rula rolul de gestionare a clusterului, Setup setează nodurile gazdă în cazul în care parametrul leadHostManagement este ulterior modificat.

    Prezența acestor două proprietăți vă permite să utilizați patru opțiuni posibile pentru determinarea comportamentului nodului cache. Aceste opțiuni sunt descrise în tabelul următor.

    Parametrul nivelului clusterului LeadHostManagement

    Parametrul nodului cache LeadHost

    Descrierea combinației de parametri







    Rezultatul responsabilității gazdă a cache-ului

    SQL Server sau un furnizor personalizat îndeplinește rolul de gestionare a clusterului. Acesta nu este nodul principal.

    Numai operațiile obișnuite ale nodului cache.

    SQL Server acționează ca un instrument de gestionare a clusterului. Acesta este nodul principal dacă valoarea parametrului leadHostManagement este setată la "true".

    Numai operațiile obișnuite ale nodului cache.

    Când nodurile gazdă funcționează ca un instrument de gestionare a clusterului

    Când parametrii pentruHostHostManagement și leadHost sunt setați la true. nodul cache se mută la nivelul responsabilității crescute în cluster și este atribuit de nodul principal. Pe lângă operațiile obișnuite ale nodului cache asociat cu cache-ul de date, nodul master funcționează și cu alte noduri principale, gestionând operațiile cluster.

    Dacă nodul principal nu reușește

    Pentru a menține disponibilitatea clusterului de cache, majoritatea gazde ar trebui să rămână accesibile. Clusterele mai mici au cel mai mare risc, deoarece un număr mai mic de erori de server sunt necesare pentru a închide clusterul în mod automat.

    Dacă gazdele de vârf execută rolul de gestionare a clusterului, atunci în cazul unui eșec al majorității gazdă, întregul cluster de cache se termină.

    De exemplu, luați în considerare un cluster de cache format din șase servere și descris în diagrama următoare. În acest exemplu, gazdele principale acționează ca un rol de gestionare a cluster-ului, cu cele două noduri cache atribuite comandantului.

    În cazul unui eșec al unuia dintre nodurile cache obișnuite din cluster, clusterul poate continua să funcționeze. Datele privind nodurile care nu conduc vor fi pierdute (cu condiția ca disponibilitatea ridicată să nu fie activată), dar clusterele rămase vor continua să emită și să stocheze date. De fapt, clusterul poate continua să funcționeze chiar dacă toate cele patru noduri de cache care nu sunt atribuite gazdei sunt pierdute.

    Cu toate acestea, în cazul unui eșec al unuia dintre nodurile de vârf, clusterul de cache se va termina, deoarece majoritatea nodurilor principale nu vor fi operaționale. Pentru a rezolva această problemă, puteți atribui noduri suplimentare de plumb.

    Comanda Stop-CacheHost nu va opri serviciul gazdă cache Windows dacă îndeplinește rolul de gestionare a clusterului. Oprirea determină închiderea întregului cluster.

    Alocarea nodurilor principale suplimentare

    În Expertul de configurare AppFabric, lista derulantă Cluster Size este utilizată pentru a determina numărul corespunzător de gazde din cluster. De asemenea, puteți atribui gazde suplimentare după instalare. Cu toate acestea, este important să considerăm că selectarea prea multor noduri principale poate provoca probleme:

    • Pentru a menține sănătatea cluster-ului cache, majoritatea gazde trebuie să fie întotdeauna disponibile. Cu cât mai multe noduri sunt identificate ca lider, cu atât mai puține eșecuri vor fi capabile să reziste cluster-ului fără a întrerupe munca.
  • În grupurile mici în care o defecțiune a unuia sau a două noduri principale poate provoca o defecțiune a clusterului, se recomandă să se atribuie noduri suplimentare de plumb.
  • În clustere mari, cinci-șapte noduri principale sunt suficiente pentru o funcționare stabilă a cluster-ului în cadrul a 50 de servere cache.

    Când SQL Server îndeplinește rolul de gestionare a clusterului

    Parametrul grupului leadHostManagement este setat la fals. indiferent de parametrul leadHost, fiecare nod de cache îndeplinește numai sarcinile obișnuite (care nu au legătură cu nodurile principale) asociate datelor cache. În acest scenariu, instanța serverului SQL care este utilizată pentru a stoca setările de configurare a clusterului este, de asemenea, utilizată pentru a îndeplini rolul de gestionare a clusterului.

    În cazul unei defecțiuni a serverului

    Pentru a menține disponibilitatea clusterului în cazul în care rulează rolul de gestionare SQL Server, cel puțin un nod de cache trebuie să aibă acces la baza de date SQL Server.

    De exemplu, luați în considerare un cluster de cache format din șase servere și descris în diagrama următoare.

    În acest exemplu, SQL Server execută rolul de gestionare a clusterului; toate cele șase noduri de memorie cache pot furniza resursele lor clienților cache pentru a accesa datele.

    Dacă cel puțin unul din nodurile cache din cluster nu reușește, datele de pe astfel de servere sunt pierdute (se presupune că disponibilitatea ridicată nu este activată), dar clusterul continuă să funcționeze. Datele din alte noduri de cache rămân accesibile clienților cache. În acest scenariu, clusterul poate continua să funcționeze chiar dacă cinci noduri de cache se pierd de la șase.

    Concepte de bază







    Articole similare

    Pagina anterioară

    Pagina următoare

    Trimiteți-le prietenilor: