Planificarea clusterelor de reluare în caz de nereușită Windows Server
Clusterele de reluare în caz de nereușită Windows Server au cerințe hardware și software mai stricte decât serverele independente. Prin urmare, implementarea necesită activități de planificare suplimentare. Examinarea cerințelor pentru implementare și planificarea atentă va fluidiza procesul de asigurare a accesului clusterului.
Considerații de planificare a clusterelor în caz de nereușită
Atunci când planificați implementarea clusterelor de reluare în caz de nereușită Windows Server, începeți cu identificarea sarcinilor de lucru potrivite, apoi luați în considerare resursele necesare volumului de lucru.
Fluxuri de lucru de grupare în caz de nereușită
Deoarece clusterarea în caz de nereușită nu este întotdeauna potrivită, înainte de a implementa tehnologia de grupare în caz de nereușită, ar trebui să identificați serviciile și aplicațiile care pot rula și ar trebui să ruleze ca resurse grupate.
Gruparea în caz de nereușită acceptă:
- O serie de aplicații statale care acceptă stocarea datelor în spațiul de stocare partajat.
- Găzduirea aplicațiilor statale care utilizează propriile mecanisme native de replicare a datelor, cu o singură copie care se poate scrie a acestor date.
Ambele scenarii sunt comune între sistemele de gestionare a bazelor de date, cum ar fi Microsoft SQL Server. Gruparea în caz de nereușită este, de asemenea, potrivită pentru Hyper-V mașini virtuale și aplicații funcționale care rulează în sistemele lor de operare.
Capacitatea de grupare în caz de nereușită
Utilizați următoarele instrucțiuni atunci când planificați capacitatea într-un cluster de reluare în caz de nereușită:
- Distribuiți sarcinile de lucru foarte disponibile de la un nod nereușit într-o manieră bine echilibrată. Dacă toate nodurile dintr-un cluster de reluare în caz de nereușită sunt active, serviciile sau aplicațiile extrem de disponibile dintr-un nod nereușit ar trebui să nu reușească în fața unor noduri supraviețuitoare diferite, pentru a împiedica supraîncărcarea unui singur nod.
- Asigurați-vă că fiecare nod are suficientă capacitate pentru a beneficia de servicii sau aplicații foarte disponibile pe care le alocați atunci când un alt nod nu reușește. Această capacitate ar trebui să fie suficientă pentru a se potrivi cerințelor suplimentare de resurse.
- Utilizați hardware cu capacitate similară pe toate nodurile clusterului. Acest lucru simplifică procesul de planificare în caz de nereușită, permițând chiar și distribuirea nodurilor supraviețuitoare.
- Luați în considerare utilizarea unui server standby pentru a simplifica planificarea capacității. Un nod pasiv dintr-un cluster reduce la minimum nevoia de planificare complexă a capacității.
Reziliență grupare în caz de nereușită
Examinați toate componentele de configurare a clusterului pentru a identifica punctele unice de eroare. Remediați punctele de eroare unice cu astfel de configurații, cum ar fi controlere de stocare redundante, configurații multi-disc, cum ar fi reproducerea în oglindă sau paritatea, adaptoarele de rețea cu echipă și software-ul multipath. Aceste soluții reduc probabilitatea ca o singură eroare de dispozitiv să aibă un impact negativ asupra stabilității unui cluster de reluare în caz de nereușită.
Notă
De obicei, hardware-ul de server include mai multe surse de alimentare pentru a oferi redundanță de alimentare și Matrice redundantă de discuri independente (RAID).
Recomandări și cerințe generale pentru hardware
Clusterele de reluare în caz de nereușită ar trebui să se conformeze următoarelor instrucțiuni de hardware:
- Hardware-ul ar trebui să fie certificat pentru Windows Server.
- Același hardware sau similar trebuie instalat pe fiecare nod de cluster de reluare în caz de nereușită.
- Fiecare nod trebuie să ruleze aceeași arhitectură de procesor și aceeași familie de procesoare.
- Dacă utilizați conexiuni de stocare scSI (SAS) sau de stocare a canalului cu fibră, controlerele de dispozitiv de stocare în masă dedicate stocării clusterului trebuie să fie identice în toate serverele grupate și să utilizeze aceeași versiune de firmware.
- Dacă utilizați conexiuni de stocare INTERNET SCSI (iSCSI), fiecare server grupat trebuie să aibă unul sau mai multe adaptoare de rețea sau adaptoare de magistrală gazdă care sunt dedicate stocării clusterului. În toate serverele grupate, adaptoarele de rețea pe care le utilizați pentru a vă conecta la ținta de stocare iSCSI ar trebui să fie identice.
Important
Nu ar trebui să utilizați rețeaua utilizată pentru conexiunile de stocare iSCSI pentru comunicațiile de rețea care nu sunt de stocare.
Cerințe de rețea
În plus față de cerințele generale de hardware, cerințele specifice rețelei includ:
- Adaptoarele de rețea din fiecare nod trebuie să fie identice și să aibă aceleași capacități de control al vitezei, duplex și fluxului.
- Adaptoarele de rețea dintr-o rețea de clustere ar trebui să aibă aceeași metodă de atribuire a adresei IP, fie statică, fie dinamică, utilizând DHCP.
- Dacă aveți rețele private care nu sunt direcționate către restul infrastructurii de rețea, asigurați-vă că fiecare dintre aceste rețele private utilizează o subrețea unică. Acest lucru este necesar chiar dacă oferiți fiecărui adaptor de rețea o adresă IP unică.
Cerințe de infrastructură
Clusterele de reluare în caz de nereușită pot depinde de serviciile de infrastructură. Windows Server acceptă clustere de mai multe domenii și clustere de grup de lucru.
Notă
Deși puteți implementa mai multe clustere de domeniu și clustere de grup de lucru, nu ar trebui să utilizați această configurație pentru clustere de servere de fișiere Hyper-V sau de fișiere.
Ar trebui să instalați aceleași caracteristici și roluri Windows Server pe fiecare nod. Configurațiile inconsistente din nodurile cluster pot provoca instabilitate și probleme de performanță. În plus, nu ar trebui să instalați rolul Active Directory Domain Services (AD DS) pe niciunul dintre nodurile cluster, deoarece AD DS are propriul mecanism de toleranță la eroare.
Trebuie să aveți elementele de infrastructură de rețea pentru un cluster de reluare în caz de nereușită descris în tabelul următor.
| Element | Descriere |
|---|---|
| DNS | Serverele din cluster utilizează Domain Name System (DNS) pentru rezolvarea numelui. |
| O apartenență la domeniu | În clusterele de reluare în caz de nereușită Windows Server, nodurile cluster nu trebuie să fie membre ale aceluiași domeniu. |
| Un cont administrativ | Atunci când creați pentru prima dată un cluster sau adăugați servere la acesta, trebuie să vă conectați la domeniu cu un cont care are privilegii administrative pentru toate serverele din acel cluster. |
Important
Contul administrativ nu trebuie să fie membru al grupului Administratori de domeniu dacă este membru al grupului administratori locali pe fiecare nod de cluster. Totuși, dacă acel cont nu este membru al grupului Administratori de domeniu, trebuie să aibă permisiunea Creare obiecte computer în domeniul care găzduiește nodurile clusterului.
Notă
Începând cu Windows Server 2016, puteți crea așa-numitele clustere detașate, care nu necesită această atribuire de permisiune.
În Windows Server, nu trebuie să aveți un cont de serviciu cluster. În schimb, serviciul cluster rulează automat într-un context special care furnizează permisiunile și acreditările specifice necesare pentru serviciu. Atunci când este creat un cluster de reluare în caz de nereușită și se creează un obiect computer corespunzător în AD DS, acel obiect este configurat pentru a preveni ștergerea accidentală. În plus, resursa Nume rețea cluster are logică de verificare a validității suplimentare, care verifică periodic starea și proprietățile obiectului computer care reprezintă resursa Nume rețea.
Cerințe de software pentru implementarea clusterului de reluare în caz de nereușită
Ca exemplu de bună practică, fiecare nod de cluster ar trebui să ruleze aceeași ediție de Windows Server, fie Windows Server 2025 Standard, fie Windows Server 2025 Datacenter. Nodurile ar trebui să aibă instalate aceleași actualizări de software. Aveți opțiunea de a utiliza instalarea Server Core a Windows Server 2025 ca noduri de cluster, deși acest lucru depinde de sarcinile de lucru și rolurile de server pe care intenționați să le implementați.