Dacă mai mulți angajați din compania dvs. folosesc software 1C, atunci este suficient să cumpărați un server bun și să îl configurați corect. Cu toate acestea, dacă numărul de utilizatori a ajuns la 150-200 de persoane și aceasta nu este limita, atunci instalarea unui cluster de servere va ajuta la reducerea încărcării echipamentului. Desigur, instalarea de echipamente suplimentare și formarea specialiștilor pentru a sprijini funcționarea clusterului va necesita niște resurse financiare și de timp, dar aceasta este o investiție pe termen lung care compensează ulterior toate costurile datorate funcționării neîntrerupte a sistemului. În același timp, multe depind de configurația corectă a clusterului - productivitatea poate fi crescută de mai multe ori fără investiții costisitoare. Prin urmare, înainte de a studia funcționalitatea și de a cumpăra servere, trebuie să vă asigurați dacă aveți nevoie de un cluster de servere 1C.
Când ar trebui să instalați un cluster de server 1C?
Când se proiectează o schemă de lucru și se calculează capacitatea serverului necesară în software, apar destul de des erori. În etapa inițială, administratorii de sistem le pot nivela prin creșterea cantității de memorie RAM sau modernizarea procesorului și a altor noduri. Dar întotdeauna vine un moment în care aceste posibilități se usucă, iar instalarea unui cluster de server devine practic inevitabilă. Acesta este cel care va rezolva principalele probleme ale sistemelor foarte încărcate:
- Defecțiuni ale echipamentelor și rețelei. Pentru bazele de date deosebit de importante, se recomandă crearea unui cluster de servere care acționează ca backup;
- Securitate insuficientă a bazei de date. Un avantaj suplimentar este capacitatea de a cripta datele din software pe platforma 1C;
- Distribuția neuniformă a sarcinii pe nodurile serverului. Rezolvat prin crearea mai multor „procese de lucru” care controlează conexiunile și solicitările clientului;
- Pe lângă rezolvarea acestor probleme, un cluster de servere 1C configurat corespunzător vă permite să economisiți semnificativ la menținerea funcționării stabile a aplicațiilor 1C.
Proprietarii de companii mici, care se confruntă cu problemele de mai sus, pot fi, de asemenea, interesați să instaleze un cluster de servere. Dar totuși, dacă numărul de utilizatori nu depășește câteva zeci și performanța software-ului nu provoacă plângeri, atunci clusterul nu este justificat din punct de vedere economic. Va fi mult mai eficient să actualizați serverul sau să configurați corect parametrii cheie. Cu toate acestea, dacă o companie are ca scop dezvoltarea și creșterea locurilor de muncă, atunci merită să ne gândim la crearea unui cluster de servere 1C în viitorul apropiat.
Instalarea unui cluster de servere de failover în cazuri standard nu necesită ca administratorii să aibă cunoștințe aprofundate despre structura și logica echipamentului serverului.
Să luăm în considerare acest algoritm folosind exemplul combinării a două servere 1C 8.2 într-un cluster
Să presupunem că astăzi aveți două servere, pe unul dintre care (S1C-01) sunt instalate serverul 1C și bazele de date de informații. Pentru a configura un cluster de servere de failover, trebuie să implementați un server 1C:Enterprise pe serverul S1C-02 și să începeți fluxul de lucru. Asigurați-vă că în proprietățile sale elementul „Utilizare” este setat la „Utilizare”. Nu este necesară înregistrarea bazelor de informații.
După aceasta, în consola de administrare 1C trebuie să adăugați un cluster de rezervă cu numele celui de-al doilea server – S1C-02 – la secțiunea „Rezervare cluster”. Adăugăm un cluster de rezervă numit S1C-01 la o secțiune similară a celui de-al doilea server și îl mutăm în poziția de sus. Pentru a face acest lucru, utilizați meniul contextual și comanda „Mutare în sus”. Este necesar să se asigure aceeași ordine în aceste grupuri pe ambele servere.
După pașii de mai sus, tot ce rămâne este să faceți clic pe butonul „Acțiune” – „Actualizare”. După aceasta, bazele de informații înregistrate pe prima ar trebui să apară în arborele celui de-al doilea server. Aceasta înseamnă că acțiunile noastre au dus la succes și acum avem un cluster de failover de două servere.
Acesta este unul dintre exemplele simple de creare a unui cluster de servere, care nu se referă la optimizarea și configurarea corectă a acestora. Pentru implementarea finală a unui cluster pentru anumite sarcini, este necesar să se rezolve problema suficienței capacității și a configurației profesionale a clusterului rezultat.
Încărcarea și optimizarea clusterelor
Testare de sarcină
Cele mai comune tehnologii pentru testarea unui cluster de servere 1C sunt:
- testul Gilev;
- Centru de testare de la 1C:KIP.
În primul caz, avem de-a face cu un instrument care ne permite să evaluăm bazele de date de fișiere și client-server. Include o evaluare a vitezei sistemului, a interfețelor, a operațiunilor îndelungate și a cantității de resurse pentru operare. Marele avantaj este versatilitatea sa - nu contează configurația pe care o testați cu el. Rezultatul este o estimare în unități convenționale.
A doua funcționalitate vă permite să estimați timpul petrecut pentru o anumită operațiune în sistem pentru un număr predeterminat de utilizatori. În același timp, puteți specifica în mod independent numărul de operații, tipul și secvența acestora - testul va simula acțiuni reale.
Pe baza rezultatelor obținute, puteți judeca dacă merită să faceți upgrade sau să optimizați clusterul de servere.
Cel mai simplu mod de a accelera 1C este de a crește caracteristicile serverului. Au existat însă cazuri când, din cauza setărilor incorecte după actualizarea hardware-ului, situația s-a înrăutățit. Prin urmare, dacă vă plângeți de înghețari, este recomandat să verificați mai întâi setările clusterului în serviciul de administrare.
Este necesar să vă asumați întreaga responsabilitate pentru toate acțiunile. Setările clusterului pot avea un impact semnificativ asupra performanței și funcționalității, atât în bine, cât și în rău. Fiecare setare afectează toate serverele din cluster. Prin urmare, înainte de a schimba ceva, trebuie să înțelegeți de ce este responsabilă configurarea unui cluster 1C.
Un parametru extrem de util pentru serverele care sunt utilizate 24 de ore pe zi - „Interval de repornire”. De obicei, valoarea sa este setată la 86400 de secunde, astfel încât serverele să poată reporni automat o dată pe zi. Acest lucru este util pentru reducerea efectelor negative ale pierderilor de memorie și ale fragmentării datelor de pe discuri în timpul operațiunilor.
Este foarte important ca clusterul tolerant la erori al serverelor 1C să fie protejat de suprasolicitarea memoriei. O solicitare nereușită într-un ciclu poate elimina toată puterea serverelor multi-core. Pentru a preveni acest lucru, există două opțiuni de cluster - „Capacitate de memorie admisă” și „Interval pentru depășirea capacității admise”. Dacă configurați acești parametri corect și precis, vă veți proteja bazele de informații de multe probleme comune.
Limitarea procentului de toleranță la erori de server va ajuta la identificarea fluxurilor de lucru cu prea multe apeluri eșuate. Clusterul le va opri forțat dacă este bifată caseta de selectare corespunzătoare. Acest lucru va ajuta la protejarea proceselor „fără erori” împotriva blocării și așteptării.
Un alt parametru - „Opriți procesele care sunt oprite după” este responsabil pentru deconectarea regulată a conexiunilor la server la intervale specificate. În 1C, după finalizarea lucrărilor, procesele de lucru se blochează pentru o perioadă de timp, astfel încât datele să fie transferate corect către procese noi. Uneori apar erori și procesele rămân suspendate pe server. Ei risipesc resurse și este mult mai util să le minimizezi semnificativ cantitatea.
Pe lângă optimizarea clusterului în sine, este și necesar să configurați corect fiecare server inclus în acesta. Pentru comoditatea optimizării serverului și a verificării performanței, administratorii folosesc agentul server – ragent. Stochează informații despre ceea ce rulează pe un anumit server. Pentru a obține date despre bazele de informații utilizate, trebuie să contactați managerul serverului – rmngr.
Pentru o optimizare adecvată, utilizați consola cluster de server și configurați următorii parametri pentru fiecare server:
- Dimensiunea maximă de memorie a tuturor proceselor de lucru. Dacă acest indicator este 0, atunci sistemul alocă 80% din RAM pentru procese, dar dacă câmpul este 1, atunci 100%. Dacă 1C și un DBMS sunt instalate pe același server, atunci există posibilitatea unui conflict din cauza memoriei și trebuie să utilizați această setare. În caz contrar, standardul de 80% va fi suficient sau calculați câtă memorie OS este necesară și introduceți cantitatea rămasă în acest câmp;
- Consum de memorie sigur per apel. Valoarea implicită este „0”, ceea ce înseamnă că 1 proces de lucru va ocupa mai puțin de 5% din RAM maximă pentru toate procesele. Nu este recomandat să setați valoarea „-1”, deoarece va elimina toate restricțiile, care este plină de consecințe sub formă de înghețare;
- Numărul de baze de informații și conexiuni pe proces. Aceste setări controlează modul în care sarcinile de lucru sunt distribuite între procesele de lucru. Le puteți personaliza în funcție de cerințele dumneavoastră pentru a minimiza pierderile din cauza încărcării excesive pe server. Dacă valoarea este setată la 0, atunci restricțiile nu se aplică, ceea ce este periculos dacă există un număr mare de locuri de muncă.
În versiunea 8.3, o altă caracteristică utilă pentru distribuirea corectă a încărcăturii pe server este „Manager pentru fiecare serviciu.” Acest parametru face posibilă utilizarea nu a unui manager de server (rmngr), ci a mai multor, fiecare dintre acestea fiind responsabil pentru propria sa sarcină. Aceasta este o oportunitate excelentă de a urmări serviciul care cauzează degradarea performanței și de a măsura cantitatea de resurse alocată fiecărei sarcini.
După instalarea acestei caracteristici, agentul serverului ragent va reporni și în loc de un singur rmngr.exe în consolă veți găsi o listă întreagă. Acum puteți utiliza managerul de activități pentru a găsi procesul care încarcă sistemul și pentru a efectua niște reglaje fine. PID-ul lor vă va ajuta să distingeți aceste procese unul de celălalt. Cu toate acestea, deoarece aceasta este o inovație, experții 1C recomandă utilizarea cu atenție a acestei funcții.
Înainte de a decide să adăugați un cluster de server 1C la structura dvs., trebuie să verificați setările serverului. Poate că există o modalitate de a corecta situația fără a cumpăra echipamente scumpe și a pregăti specialiști pentru a înființa un cluster 1C. Nu este neobișnuit ca un server să fie examinat și configurat profesional de către specialiști terți pentru a funcționa la vechea capacitate încă câțiva ani. Dar în companiile mari, un cluster de servere 1C rămâne singura soluție care permite angajaților să lucreze 24 de ore pe zi.
Serverul 8.3 se caracterizează printr-un cod intern nou reproiectat, deși „din exterior” poate părea că este un 8.2 ușor modificat.
Serverul a devenit mai „auto-configurabil”; unii parametri, cum ar fi numărul de procese de lucru, nu mai sunt creați manual, ci sunt calculati pe baza descrierilor cerințelor de toleranță la erori și sarcini de fiabilitate.
A fost dezvoltat un mecanism de echilibrare a sarcinii, care poate fi utilizat fie pentru a crește performanța sistemului în ansamblu, fie pentru a utiliza un nou mod de „economisire a memoriei”, care vă permite să lucrați „cu memorie limitată” în cazurile în care configurația folosit „îi place să mănânce memoria”.
Stabilitatea funcționării atunci când se utilizează cantități mari de memorie va fi determinată de noii parametri ai serverului de producție.
Parametrul „consum de memorie sigură per apel” este deosebit de interesant. Pentru cei care nu au idee despre ce este, este mai bine să nu se antreneze pe o bază „productivă”. Parametrul „Dimensiunea maximă a memoriei proceselor de lucru” permite, în caz de „overflow”, să nu blocheze întregul proces de lucru, ci doar o singură sesiune „cu ratatul”. „Cantitatea de memorie pentru procesele de lucru până la care serverul este considerat productiv” vă permite să blocați noile conexiuni de îndată ce acest prag de memorie este depășit.
Recomand izolarea proceselor de lucru pe baza de informații, de exemplu, specificarea parametrului „Număr de securitate a informațiilor per proces = 1”. Cu mai multe baze de date foarte încărcate, acest lucru va reduce influența reciprocă atât în ceea ce privește fiabilitatea, cât și performanța.
O contribuție separată la stabilitatea sistemului o are „cheltuiala” licențelor/cheilor. În 8.3, a devenit posibilă utilizarea unui „manager de licență software”, care amintește de managerul „aladin”. Scopul este de a putea plasa cheia pe o mașină separată.
Este implementat ca un alt „serviciu” în managerul clusterului. Puteți folosi, de exemplu, un laptop „gratuit”. Adăugați-l la clusterul 1C 8.3, creați un manager separat pe el cu serviciul „serviciu de licențiere”. Puteți introduce o cheie hardware hap în laptop sau puteți activa licențe software.
De cel mai mare interes pentru programatori ar trebui să fie „Cerințe de atribuire a funcționalității”.
Deci, pe un laptop cu o cheie de securitate, pentru a nu lansa utilizatorii pe serverul cluster, trebuie să adăugați „cerințe” pentru obiectul de cerințe „Conexiune client la securitatea informațiilor” - „Nu atribuiți”, adică. împiedică procesele de lucru de pe acest server să proceseze conexiunile client.
Și mai interesantă este capacitatea de a rula „numai joburi de fundal” pe serverul de producție al clusterului fără sesiuni de utilizator. În acest fel, puteți muta sarcinile foarte încărcate (cod) pe o mașină separată. Mai mult, puteți rula o sarcină de fundal de „închidere a lunii” folosind „Valoarea unui parametru suplimentar” pe un computer și sarcina de fundal „Actualizarea indexului de text integral” pe altul. Clarificarea are loc prin indicația „Valoarea de un parametru suplimentar”. De exemplu, dacă specificați BackgroundJob.CommonModule ca valoare, puteți limita munca serverului de lucru din cluster la numai joburi de fundal cu orice conținut. Valoarea BackgroundJob.CommonModule..- va indica codul specific.
Este clar că nu are rost să repovestim documentația. Dar dacă cineva dă niște sfaturi utile, voi extinde articolul.
Mai multe procese de lucru pe un server fac posibilă utilizarea eficientă a cantității de RAM și a resurselor procesorului pentru a executa cereri, precum și conectarea unei sesiuni client la un alt proces de lucru dacă cel curent „se blochează”.
Programul Server Agent (ragent) este responsabil pentru înțelegerea a ceea ce rulează pe un anumit server. Oprirea agentului server va face ca serverul să nu fie disponibil pentru utilizare de către cluster. Agentul își stochează informațiile în fișierul srvribrg.lst.
Informațiile despre bazele de date de lucru și procesele de lucru implicate sunt deținute de „Managerul serverului” (rmngr). Stochează aceste informații în fișierul 1CV8Reg.lst. Oprirea managerului de server poate duce la repornirea aplicațiilor client dacă managerul repornește cu succes sau la oprirea completă a serverelor de lucru ale întregului cluster.
1C: Întreprinderea permite posibilitatea de a crea mai multe clustere independente pe un server. Fiecare dintre ele este identificat în rețea printr-un „port IP” unic și un număr unic în fișierele de serviciu. Primul cluster primește implicit portul 1541.
Complementul Enterprise Servers este conceput pentru a gestiona clusterul.
Vă puteți conecta la servere după numele serverului sau adresa IP.
Agent server
Agentul server „știe” despre toate clusterele care rulează pe server. Aceste informații sunt stocate în fișierul srvribrg.lst cu o listă de clustere și lista de administratori. Portul principal al agentului este 1540. Pe fiecare server de lucru, poate fi lansat un singur agent, care deservește toate clusterele posibile de pe acest server.
Să aruncăm o privire mai atentă asupra proprietăților clusterului
Intervalul de repornire
Acest parametru repornește procesele de lucru ale serverului 1C conform valorii specificate în secunde. De obicei, parametrul este utilizat pe serverele de aplicații care au un sistem pe 32 de biți, deoarece capacitatea de memorie este limitată la ~ 3,7 GB dacă sistemul de operare este pe 64 de biți și serverul de aplicații este pe 32 de biți. Dacă sistemul de operare folosește o arhitectură pe 32 de biți, atunci consumul total de memorie al procesului de lucru este de ~ 1,7 GB. Și utilizatorii pot primi adesea un mesaj de eroare precum „Memorie insuficientă pe serverul 1C Enterprise”. Cel mai simplu mod de a evita această eroare este să reporniți procesele de lucru, de exemplu 86400 de secunde (1 zi). La modificarea parametrului, numărul de timp începe de la începutul serviciului de server de aplicații 1C.
Dimensiunea memoriei permisă
Repornirea proceselor de lucru atunci când este atins un anumit prag de memorie ocupat de procesul de lucru în kilobytes.
Interval pentru depășirea cantității permise de memorie
Aceasta înseamnă că, dacă într-un număr specificat de secunde, memoria specificată în parametrul „cantitate de memorie permisă” este depășită, atunci serverul 1C va decide să repornească fluxul de lucru.
Abaterea permisă a numărului de erori de server
Se calculează după cum urmează. Avem apeluri la server care pot fi văzute în jurnalul de tehnologie prin evenimentul „CALL”, și există, de asemenea, diverse situații de excepție care pot fi văzute în jurnalul de tehnologie prin evenimentul „EXCP”. Platforma calculează raportul dintre aceste evenimente. Se presupune că aceste evenimente ar trebui să fie aproximativ aceleași. Dacă în orice proces de lucru acest raport depășește raportul dintre aceste evenimente în alte procese de lucru cu o sumă semnificativă, atunci un astfel de proces de lucru este considerat problematic. Doar această valoare este setată în acest parametru. Valoarea recomandată este 50.
Terminarea forțată a proceselor problematice
Dacă activăm acest parametru, atunci, conform parametrului „deviația permisă a numărului de erori de server”, procesele problematice vor fi încheiate. Dacă parametrul este dezactivat, platforma afișează evenimentul de jurnal de proces „ATTN”, care indică procesul problematic.
Opriți procesele dezactivate după
Dacă se declanșează unul dintre parametrii „interval de repornire” sau „dimensiunea permisă a memoriei”, atunci când procesul de lucru este repornit, acesta poate „cădea”. Dacă clientul nu accesează serverul în timpul repornirii (este inactiv), atunci data viitoare când îl accesează, va trece fără probleme la noul proces de lucru. Dacă clientul contactează serverul în momentul repornirii fluxului de lucru, atunci în acest caz va primi un mesaj de eroare și își va termina activitatea. Pentru a preveni acest lucru, trebuie să setați valoarea acestui parametru în secunde. De obicei, 120 de secunde sunt suficiente. În acest timp, fluxul de lucru va avea timp să proceseze cererile curente ale clienților și să le transfere într-un nou flux de lucru. Acei clienți activi pe care procesul nu a avut timp să îi proceseze sunt terminați și clienții pot primi o eroare.
Nivel de toleranță la erori
Această setare trăiește singură, indiferent de numărul de servere centrale. Nivelul de toleranță la erori poate lua orice valoare. De exemplu, nivelul de rezistență = 1, apoi fiecare sesiune de utilizator este dublată. Dacă nivelul de toleranță la erori = 2, atunci fiecare sesiune este înmulțită cu 3. De asemenea, sarcina de pe server crește. La schimbarea nivelului de toleranță la erori, dacă avem un server central, acesta se repetă pe fiecare server central: „registru cluster”, „serviciu blocare cluster”. Există, de asemenea, replicarea unor servicii precum „serviciu de date de sesiune”, „serviciu de marcare temporală online”, „serviciu de blocare a obiectelor”, „serviciu de licențiere”, „serviciu de numerotare” pe alte servere. Dintre acestea, cel mai greu este „serviciul de date de sesiune”.
Modul de partajare a încărcării
În ceea ce privește performanța. Când se conectează o conexiune client, se va conecta la oricare server care are un proces de lucru cu performanțe mai disponibile. Performanța disponibilă este setată în proprietățile fluxului de lucru:
Performanța disponibilă la nivelul 1C este calculată după cum urmează: se efectuează un apel server de referință către toate procesele de lucru o dată la 10 minute și se măsoară timpul acestui apel. Numărul rezultat este împărțit la 10.000 (zece mii), iar mecanismele serverului de aplicații calculează timpul de referință. În cazul în care productivitatea unui proces de lucru a devenit cu 25% mai mică decât cea a celorlalte, conexiunile din acest proces de lucru încep să meargă la alte procese de lucru până când toate conexiunile dispar.
Prioritatea memoriei. Conexiunile utilizatorului vor fi realizate la un server de producție care are mai multă memorie disponibilă.
Manager de cluster
Managerul clusterului este responsabil pentru funcționarea clusterului. Fiecare cluster are propriul manager. Managerul stochează informații despre cluster în fișierul 1CV8Reg.lst (registru cluster). Fiecare Cluster Manager are, de asemenea, propriul său port pe Work Server. Pentru primul cluster, portul implicit Manager este 1541. Acesta este portul care este afișat în snap-in-ul 1C Servers: Enterprise în ramura Clustere, identificând clusterul.
Managerul primește solicitări de la partea client a 1C: Enterprise și decide cărui flux de lucru să îi adreseze această solicitare de serviciu.
Managerul folosește portul de serviciu pentru a interacționa cu procesele de lucru.
Procesul de lucru
Procesul de lucru este responsabil pentru „lucrarea cu clienții”. Pot exista mai multe procese de lucru în clusterul 1C: Enterprise 8. Numărul de procese de lucru nu este creat manual, ci este calculat pe baza descrierilor cerințelor sarcinilor pentru toleranță și fiabilitate la erori. Managerul serverului decide ce proces de lucru va servi conexiunea client. Pentru conexiunile client, proceselor de lucru le este alocată în mod implicit o gamă de porturi IP 1560 – 1591. În plus, fiecărui proces de lucru îi este atribuit un port de serviciu pentru comunicarea cu managerul de cluster.
Setările serverului de lucru, conform documentației 1C, pot fi modificate numai în versiunea CORP a serverului de aplicații 1C. De fapt, setările funcționează atât în versiunea CORP, cât și în versiunea PROF. Dacă aceste setări sunt utilizate în versiunea PROF, aceasta va fi o încălcare a acordului de licență.
Memorie maximă pentru fluxul de lucru
Acest parametru în sine nu limitează nimic. Funcționează împreună cu parametrul „consum de memorie sigur pe apel”. Să ne imaginăm că toate procesele noastre de lucru în total au atins aproximativ consumul de memorie al valorii specificate a acestui parametru. Și acum un anumit utilizator dorește să efectueze un anumit apel de server care dorește să consume o cantitate mare de memorie. De îndată ce apelul la server depășește cantitatea de memorie specificată în acest parametru cu cantitatea de memorie din parametrul „consum de memorie sigură pentru un apel”, acest utilizator particular va primi o eroare de forma: „consum de memorie sigură pentru un client -apelul serverului a fost depășit.” Acest lucru este necesar pentru ca un utilizator să nu poată copleși serverul de lucru. Valoarea parametrului 0 este egală cu 80% din memoria instalată pe serverul 1C.
Consum de memorie sigur per apel
O valoare de 0 (implicit) este 5% din valoarea maximă a memoriei fluxului de lucru. Valoarea poate fi -1. Aceasta înseamnă că orice apel client-server care depășește valoarea specificată a parametrului „dimensiunea maximă a memoriei lucrătorului”.
Cantitatea de memorie de proces de lucru până la care serverul este considerat productiv
Înseamnă, dacă este setată la o valoare și procesele de lucru au ocupat cantitatea de memorie specificată în acest parametru, serverul va continua să ruleze, dar nu va accepta conexiuni noi până când memoria este eliberată.
Numărul de securitate a informațiilor per proces
Poate exista o scădere a performanței atunci când există multe baze de informații și un singur flux de lucru. Prin urmare, cu acest parametru este posibil să se reducă numărul de baze de date per proces. Dacă setați valoarea la 1 (în cele mai multe cazuri, aceasta funcționează destul de optim), atunci va fi creat un nou proces de lucru (rphost) pentru fiecare bază de informații.
Numărul de conexiuni per proces
Același ca parametrul de mai sus, dar depinde de numărul de conexiuni per proces. O valoare de 0 va însemna că va exista un singur proces de lucru pe fiecare server de lucru.
Manager pentru fiecare serviciu
Fiecare server central de lucru are un manager de cluster principal cu anumite servicii:
Ele sunt executate de un serviciu „rmngr”. Să ne imaginăm că acest serviciu începe să consume multă memorie sau să risipească resurse CPU. Există de obicei câțiva suspecți tipici. Dar, dintr-o dată, vă aflați într-o „funcție” și nu puteți înțelege ce anume încarcă serviciul, puteți bifa caseta de selectare „manager pentru fiecare serviciu”, serviciul va fi împărțit în 21 de procese (acesta este numărul de servicii din principal). manager de cluster). Și, în consecință, folosind PID-ul procesului, va fi posibil să se calculeze ce serviciu încarcă sistemul.
Server central
Acesta este serverul care stochează registrul clusterului în fișierul 1CV8Clst.lst. Fișierul stochează o listă de baze de date, o listă de administratori de cluster, o listă de cerințe de atribuire a funcționalităților, o listă de profiluri de securitate și, în general, toate setările clusterului. Acest fișier este prezent numai acolo unde este bifată caseta de selectare „server central”. Pot exista mai multe servere centrale. De asemenea, pe serverele centrale există servicii precum „serviciu de blocare a clusterelor”, „serviciu de configurare a clusterelor”. Atâta timp cât cel puțin un server central este operațional, clusterul funcționează. Odată ce cel mai recent server central eșuează, clusterul devine inutilizabil, indiferent de setările de toleranță la erori.
Cerința de atribuire a funcționalității
Clusterul de servere 1C Enterprise 8.3 oferă un anumit set de funcționalități (numite obiecte de cerințe), a căror distribuție între serverele de lucru din cluster poate fi controlată. De exemplu, puteți specifica că toate joburile de fundal din cluster vor rula pe un server de lucru selectat. Pentru a plasa o conexiune sau un serviciu de cluster pe orice server de producție, trebuie să creați o cerință de atribuire a funcționalității pentru serverul de producție selectat. Această cerință determină capacitatea sau imposibilitatea unui anumit server de a efectua o anumită sarcină. Să aruncăm o privire mai atentă la ce este o cerință de atribuire a funcționalității.
Migrarea conexiunilor utilizator
Să presupunem că vrem ca conexiunile utilizatorilor să funcționeze pe serverul lucrător nr. 1, dar dacă acel server se defectează, dorim ca ele să treacă la un alt server lucrător nr. 2
Pentru a face acest lucru, trebuie să creăm o cerință de atribuire a funcționalității pe serverul nr. 1:
Pe serverul nr. 2, setați aceleași setări, dar modificați prioritatea:
Importanța priorității este implementată invers. Adică, prioritatea 1 este mai mare decât prioritatea 2.
Scoateți serverul de producție din cluster
Putem elimina pur și simplu serverul de lucru din cluster ștergându-l din listă, dar în acest caz toți utilizatorii vor fi „expulși” din sistem. Pentru a face retragerea mai nedureroasă, puteți face următoarele:
Creați o cerință de atribuire a funcționalității cu următoarele setări:
Această setare înseamnă că nu vor exista conexiuni noi la acest server de producție. Acei utilizatori care lucrau vor continua să lucreze, dar se vor trece treptat pe alte servere de lucru.
Serviciu de licențiere
Mutați serviciul de licențiere pe un server separat. Acest lucru este bun deoarece licențele software pot fi legate de un anumit computer. Să creăm o cerință de atribuire a funcționalității cu următoarele setări:
Lucrări de fundal
Odată cu lansarea platformei 8.3.7, joburile de fundal au fost împărțite în 2 grupuri:
1. Lucrări de fundal apelate din codul de configurare
2. Sarcini de rutină
Prin urmare, sunt necesare mai multe setări pentru atribuirea funcționalității:
1. Pentru a face joburile de fundal să ruleze rapid, trebuie să adăugați date de sesiune pentru joburile de fundal și programate
După crearea cerințelor necesare pentru atribuirea funcționalității, trebuie să le aplicați:
Parțial – aplicație care nu va perturba experiența utilizatorului
Complet – o aplicație care poate perturba experiența utilizatorului.
În practică, nu am întâlnit niciodată o situație în care, atunci când este aplicat pe deplin, să perturbe experiența utilizatorului sau ceva similar. Dar orice este posibil, tine cont. După aplicare, repornirea serviciului de server de aplicații 1C nu este necesară.
Puteți contacta oricând specialiștii în optimizare 1C; experiența noastră practică vă va economisi timp.
În secțiunea curentă, sunt acoperite principalele extrase despre crearea unui cluster. Desigur, ele nu sunt complete, deoarece totul depinde de reglarea fină a fiecărei platforme. Dar tot vreau să nu-l caut în grabă, dar unde am căutat asta, sau cum am făcut-o odată?
- Cluster de failover
Scalabilitate cluster de server
- Cerințe de atribuire a funcționalității
Cluster de failover
2.1.7. Echilibrarea sarcinii într-un cluster
2.1.7.1. Performanță accesibilă a fluxului de lucru
Fiecare proces de lucru are proprietatea Performanță disponibilă. Acesta determină cât de repede un anumit proces de lucru este capabil să finalizeze un apel la server de referință în comparație cu alte procese de lucru. Apelul de referință include următoarele operațiuni:
● Operarea memoriei: alocarea matricei, umplerea matricei, eliberarea matricei.
● Operarea fișierului: creare, înregistrare, ștergere.
● Se determină gradul de încărcare a CPU pe computerul pe care rulează procesul de lucru și numărul de fire care așteaptă execuția. Această valoare ajustează în sus timpul de execuție a apelului de referință. Dacă utilizatorul în numele căruia rulează serverul nu este membru al grupului Jurnalul de performanță utilizatori(Performance Log Users), atunci încărcarea procesorului nu este determinată.
Valoarea proprietății Performanță disponibilă se calculează prin împărțirea numărului 10.000 la timpul mediu de execuție (peste 5 minute) al apelului de referință la procesul lucrător curent. Apelul de referință este executat la fiecare 2 secunde dacă există mai multe servere de lucru în cluster. Dacă un cluster de servere este format dintr-un server de lucru, toate procesele de lucru sunt considerate egale.
Clienții sunt distribuiți între procesele de lucru pentru a face performanța disponibilă a tuturor proceselor de lucru aproximativ egală. O diferență de performanță disponibilă de peste 25% este considerată semnificativă.
Când echilibrul dintre capacitatea fluxului de lucru disponibil se modifică, clienții sunt redistribuiți dinamic între procesele de lucru în decurs de 10 minute.
Când un proces de lucru este dezactivat, clienții săi sunt redistribuiți dinamic printre procesele de lucru rămase activate.
2.1.7.3. Cerințe de atribuire a funcționalității
2.1.7.3.1. Informații generale
Un cluster de servere oferă un set de funcționalități (numite obiectele cerinţelor), a cărui distribuție între serverele de lucru din cluster poate fi controlată. De exemplu, puteți specifica că toate joburile de fundal din cluster vor rula pe un server de lucru selectat.
Pentru a plasa o conexiune sau un serviciu de cluster pe orice server de producție, trebuie să creați o cerință de atribuire a funcționalității pentru serverul de producție selectat. Această cerință determină capacitatea sau imposibilitatea unui anumit server de a efectua o anumită sarcină. Să aruncăm o privire mai atentă la ce este o cerință de atribuire a funcționalității.
Cerința de atribuire a funcționalității definește:
● Pentru ce obiect de cerință este creată cerința. Obiectul de solicitare poate fi unele servicii cluster (vezi), conexiuni client (vezi) și un obiect de cerere arbitrar. Următoarele servicii cluster pot servi ca obiect de solicitare:
● Blocarea obiectelor.
● Timpul.
● Jurnalele de bord.
● Sarcini.
● Numerotarea.
● Căutare text integral.
● Setări personalizate.
● Datele sesiunii.
● Blocări tranzacționale.
● Lucrați cu surse de date externe prin ODBC.
● Lucrul cu surse de date externe prin XMLA.
● Serviciu de licențiere.
● Serviciu de actualizare a configurației bazei de date de fundal.
● Serviciu de testare.
● Serviciu extern de gestionare a sesiunilor.
● Definește tipul de cerință. Tipul de cerință determină modul în care va fi utilizat serverul de producție:
● Nu atribui – înseamnă că serverul de producție pentru care a fost creată această cerință nu va fi alocat să deservească un obiect de cerință care îndeplinește condițiile specificate în cerință.
● Atribuire – înseamnă că serverul de lucru pentru care a fost creată această cerință va fi unul dintre candidații pentru deservirea acestui obiect de cerințe (dacă există mai multe servere de lucru).
● Auto – înseamnă că serverul de lucru poate fi utilizat pentru a deservi obiectul de solicitare în cazul în care nu există un server de lucru cu o indicație explicită a necesității utilizării.
SFAT. Este logic să folosiți tipul de cerințe Auto atunci când lista de cerințe a serverului de producție include o cerință cu un set mai larg de condiții și este necesar să aveți o cerință pentru un set mai restrâns de condiții. De exemplu, acest server nu poate deservi conexiunile aplicației client pentru toate bazele de informații, cu excepția unei baze de informații pentru care este permisă o astfel de întreținere.
● Parametri suplimentari necesari clusterului de server pentru a lua o decizie într-un număr de cazuri:
● Numele bazei de informații. Folosit pentru a clarifica cerința de generare a cerințelor pentru conexiunile client și toate serviciile cluster care pot acționa ca obiect de cerință, cu excepția serviciului de licențiere.
● Opțiuni suplimentare. Folosit pentru a clarifica cerințele atunci când găzduiți o conexiune client sau un serviciu de date de sesiune. Parametrul suplimentar este verificat pentru a se asigura că se potrivește cu începutul parametrului obiect de cerere corespunzător. Parametrul suplimentar poate lua una dintre următoarele valori:
● Pentru a specifica un anumit job de fundal: BackgroundJob.CommonModule. <Имя модуля>.<Имя метода> ;
● Pentru a specifica toate joburile de fundal: BackgroundJob.CommonModule ;
● Pentru a specifica toate rapoartele: BackgroundJob.Report . Specificarea unui nume de raport nu este acceptată;
● Introduceți după rând sau căutați într-o listă: BackgroundJob.SystemBackgroundJob;
● Pentru a specifica restructurarea de fundal: SystemBackgroundJob ;
● Pentru aplicația client:
● 1CV8 – client gros;
● 1CV8CDirect – thin client în cazul conexiunii directe la serverul 1C:Enterprise;
● Designer – configurator;
● COMConnection – conexiune COM;
● WebServerExtension – conexiune la baza de date prin intermediul unui server web: client web, client thin în cazul conexiunii prin server web, serviciu web.
Să ne uităm la modul în care funcționează un cluster de servere atunci când procesează cereri.
Dacă este necesar să plasați un obiect de cerere, clusterul efectuează următoarele acțiuni:
● Toate serverele care fac parte din cluster procesează cerințele de atribuire a funcționalității specificate pentru aceste servere. Serverele și cerințele sunt parcurse în ordinea în care aceste obiecte apar în consola clusterului.
● În fiecare listă de cerințe se determină prima cerință care satisface obiectul plasat: pentru obiectul propriu-zis, baza de informații și un parametru suplimentar.
● Lista rezultată de servere de producție este apoi sortată după tipul de cerințe, astfel încât serverele de producție cu o indicație explicită de utilizare să apară primele. Serverele de lucru pentru care o cerință adecvată conține o interdicție explicită de utilizare sunt excluse din lista de servere de lucru disponibile. În acest caz, atribuirea se realizează după cum urmează:
● Există servere de lucru cu utilizare explicită: în acest caz, obiectul de cerere va fi servit de unul dintre aceste servere de lucru.
● Niciun server de producție cu utilizare explicită specificată: Se încearcă utilizarea serverelor de producție cu utilizare automată specificată sau acele servere de producție pentru care nu sunt specificate cerințe.
● La plasarea unei conexiuni client, cea care conține procesul de lucru cu cea mai mare performanță disponibilă va fi selectată din lista de servere disponibile (vezi ). Pentru o descriere detaliată a regulilor de selectare a unui flux de lucru într-un anumit server de producție, consultați.
Aplicația client care a inițiat plasarea obiectului de solicitare se va închide în mod anormal în unul dintre următoarele cazuri:
● Dacă lista de servere de lucru pentru un obiect de solicitare este goală, nu există un singur server de lucru care să poată deservi obiectul. În acest caz, obiectul de cerere nu va fi alocat și va fi aruncată o excepție.
● Dacă nu este posibil să găzduiți pe serverul de producție selectat, de exemplu, dacă serverul selectat nu este și nu există servere de producție alternative.
2.1.7.3.2. Scopul obiectelor cerinței
Să aruncăm o privire mai atentă la algoritmul de atribuire a unui server de lucru pentru a servi serviciul cluster.
● Serviciu de același tip, dacă serviciul nu este împărțit în baze de informații.
● Serviciu de același tip pentru o bază de informații, dacă serviciul este împărțit pe baze de informații.
● Serviciu de date sesiuni.
● Serviciu de licențiere.
Serviciile sunt distribuite între serverele de lucru adecvate, după cum urmează:
● Din lista de servere de lucru selectate pentru atribuire, sunt selectate cele care sunt operaționale în prezent. Dintre serverele de lucru rămase, sunt selectate acele servere a căror proprietate Prioritate conține valoarea maximă.
● Serviciile sunt distribuite uniform între serverele de lucru selectate.
● Serviciile care acceptă replicarea pot fi atribuite mai multor servere de producție. Numărul de servere de lucru utilizate este egal cu nivelul de toleranță la erori al clusterului plus unu (vezi). În acest caz, un serviciu va fi activ, iar cu alte servicii (backup) va fi acceptată replicarea datelor de serviciu. Replicarea se realizează asincron. Sincronizarea are loc la fiecare secundă.
● Pentru fiecare sesiune pe care o servește clusterul de server, este creată propria instanță a serviciului de date sesiuni. La selectarea serverelor de lucru care pot deservi o anumită instanță de serviciu, sunt luați în considerare parametrii de cerințe suplimentare. Din lista de servere disponibile, sunt selectate servere cu un număr minim de servicii cluster. Numărul de servere de lucru utilizate este egal cu nivelul de toleranță la erori al clusterului plus unu (vezi).
● Dacă trebuie să utilizați un serviciu de licențiere, trebuie să selectați în mod explicit serverul de producție la care va fi legată licența software și să descrieți în mod explicit în cerințe plasarea serviciului pe serverul de producție selectat.
● Alte servicii sunt alocate într-o singură copie.
Realocarea serviciilor cluster între serverele de producție poate fi efectuată în următoarele cazuri:
● La adăugarea unui server de producție, se efectuează o reatribuire parțială a serviciilor. Această reatribuire se efectuează automat.
● Când un server de lucru este eliminat din cluster sau serverul de lucru nu este disponibil, numai acele obiecte de solicitare care au fost servite de serverul de lucru eliminat sunt reatribuite. Această reatribuire se efectuează automat.
● Când ștergeți sau adăugați o bază de informații la cluster, se efectuează o reatribuire parțială. Această reatribuire se efectuează automat.
2.1.7.3.3. Atribuirea fluxurilor de lucru
Stabilirea unei conexiuni între o aplicație client și un cluster de server 1C:Enterprise se realizează în conformitate cu următoarele reguli:
● În conformitate cu cerințele destinației și restricțiile privind utilizarea RAM, este selectat serverul de lucru necesar.
Restricțiile privind utilizarea RAM sunt luate în considerare dacă se face o solicitare de stabilire a unei conexiuni la o bază de informații la care nu există conexiuni stabilite pe serverul de lucru selectat. Dacă limita de utilizare a RAM este depășită, serverul de lucru este exclus din listă dacă există un alt server care nu a depășit limita. De asemenea, exclude serverele de producție care nu pot procesa conexiunea necesară în funcție de cerințele destinației.
● Pentru serverul selectat, este determinată o listă de procese de lucru care sunt disponibile și pot deservi conexiunea solicitată. Un flux de lucru se referă la lista de fluxuri de lucru disponibile în următoarele cazuri:
● Numărul maxim de baze de informații deservite nu a fost atins pentru procesul de lucru (proprietatea serverului de lucru Numărul de securitate a informațiilor per proces).
● Numărul maxim de conexiuni deservite nu a fost atins pentru procesul de lucru (proprietatea serverului de lucru).
● Fluxul de lucru nu este într-o stare de pregătire pentru repornirea automată.
● Dintre fluxurile de lucru selectate, se acordă preferință acelor fluxuri de lucru care deservesc deja conexiuni la baza de informații a cărei conexiune trebuie deservită. Dacă nu există un astfel de proces de lucru, este selectat procesul de lucru cu numărul maxim de conexiuni deservite.
● Dacă nu poate fi selectat niciun proces de lucru, atunci un nou proces de lucru este lansat pe acest server de lucru, care va servi conexiunea solicitată.
Când se stabilește o conexiune în numele unei sesiuni existente (dacă conexiunea de la un apel anterior de server nu a putut fi reutilizată), se acordă preferință procesului de lucru care a servit conexiunea anterioară pentru acea sesiune. În acest caz, este posibil să selectați un alt flux de lucru dacă productivitatea disponibilă a celuilalt flux de lucru este cu cel puțin 25% mai mare decât productivitatea disponibilă a fluxului de lucru curent.
Dacă pe un server de lucru există 2 procese de lucru în 20 de minute, pentru care numărul total de conexiuni deservite și diverse baze de informații este mai mic decât valorile specificate în proprietățile serverului de lucru (proprietăți Numărul de conexiuni per procesȘi Numărul de securitate a informațiilor per proces), atunci procesul care deservește mai puține conexiuni va fi marcat ca învechit și va fi oprit după ce ultima conexiune este închisă. Conexiunile existente la un proces de lucru „vehicul” vor fi „solicitate să părăsească” serverul de lucru la următorul apel de server la acea conexiune. În același timp, fluxul de lucru „moștenit” nu participă la distribuirea cererilor de deservire a noilor obiecte de cerințe.
În primul rând, după instalarea clusterului 1C, a fost necesar să se creeze fluxuri de lucru. După cum sa dovedit, procesele cluster au început să fie create automat în funcție de încărcarea bazei de date.
O rulare de testare a joburilor de fundal ale bazei de date principale a făcut ca clusterul 1C să supraîncarce la nesfârșit rphost.exe și rphost.exe suplimentar nu a dorit să fie creat. După ce am săpat prin setări, totul a devenit clar.
Memorie maximă pentru fluxul de lucru este cantitatea de memorie pe care procesele de lucru o pot folosi împreună. Trebuie să fiți foarte atenți când setați parametrul, măsurat în octeți. Dacă setați o valoare greșită (insuficientă pentru funcționarea normală a utilizatorului), utilizatorii vor primi eroarea „Nu este suficientă memorie liberă pe serverul 1C”. Puteți obține această eroare și atunci când cota de memorie de pe serverul 1C s-a epuizat.
Consum de memorie sigur per apel– vă permite să controlați consumul de memorie în timpul unui apel de server, măsurat în octeți. Dacă un apel utilizează mai multă memorie decât se aștepta, acest apel va fi finalizat în clusterul 1C fără a reporni procesul de lucru (rphost.exe). În consecință, „perdantul” care a efectuat apelul pe server își va pierde sesiunea cu baza de date 1C fără a afecta munca altor utilizatori.
într-un GB – 1073741824 octeți, deci în 2 GB – 2147483648 octeți
Cantitatea de memorie pentru procesele de lucru până la care serverul este considerat productiv - dacă acest parametru este depășit, serverul din clusterul 1C nu va mai accepta conexiuni noi.
Numărul de securitate a informațiilor per proces– vă permite să izolați bazele de informații pentru procesele de lucru. În mod implicit, clusterul 1C curent a fost setat la „ 8 „, dar pe parcursul mai multor ore de funcționare, serverul s-a comportat foarte instabil, sesiunile utilizatorilor au înghețat. După izolarea fiecărei baze de informații (valoare – „1”) problemele au dispărut.
Numărul de conexiuni per proces- valoare implicită " 128 „. Deoarece baza de date actuală are o încărcătură foarte mare de sarcini de fundal (calcule logistice, analiza listei de prețuri, analiza concurenților etc.), s-a decis reducerea numărului la „25”.
Setările clusterului 1C în sine s-au schimbat ușor:
Nivel de toleranță la erori– acesta este numărul de servere care funcționează care pot eșua simultan și acest lucru nu va duce la încetarea anormală a utilizatorilor. Serviciile de backup sunt lansate automat în cantitatea necesară pentru a asigura toleranța specificată la erori. În timp real, serviciul activ este replicat celor de rezervă.
Modul de partajare a încărcării– există două opțiuni pentru parametru: „Prioritate în funcție de performanță” – este cheltuită mai multă memorie de server și performanța este mai mare, „Prioritate în funcție de memorie” – clusterul 1C salvează memoria serverului.
Serverul 8.3 se caracterizează printr-un cod intern nou reproiectat, deși „din exterior” poate părea că este un 8.2 ușor modificat.
Serverul a devenit mai „auto-configurabil”; unii parametri, cum ar fi numărul de procese de lucru, nu mai sunt creați manual, ci sunt calculati pe baza descrierilor cerințelor de toleranță la erori și sarcini de fiabilitate.
Acest lucru reduce probabilitatea unei configurări greșite a serverului și scade cerințele de calificare pentru administratori.
A fost dezvoltat un mecanism de echilibrare a sarcinii, care poate fi utilizat fie pentru a crește performanța sistemului în ansamblu, fie pentru a utiliza un nou mod de „economisire a memoriei”, care vă permite să lucrați „cu memorie limitată” în cazurile în care configurația folosit „îi place să mănânce memoria”.
Stabilitatea funcționării atunci când se utilizează cantități mari de memorie va fi determinată de noii parametri ai serverului de producție.
Parametrul „consum de memorie sigură per apel” este deosebit de interesant. Pentru cei care nu au idee despre ce este, este mai bine să nu se antreneze pe o bază „productivă”. Parametrul „Dimensiunea maximă a memoriei proceselor de lucru” permite, în caz de „depășire”, să nu blocheze întregul proces de lucru, ci doar o singură sesiune „cu ratat”. „Cantitatea de memorie de proces de lucru până la care serverul este considerat productiv” vă permite să blocați noile conexiuni de îndată ce acest prag de memorie este depășit.
Recomand izolarea proceselor de lucru pe baza de informații, de exemplu, specificarea parametrului „Număr de securitate a informațiilor per proces = 1”. Cu mai multe baze de date foarte încărcate, acest lucru va reduce influența reciprocă atât în ceea ce privește fiabilitatea, cât și performanța.
O contribuție separată la stabilitatea sistemului o are „cheltuiala” licențelor/cheilor. În 8.3, a devenit posibilă utilizarea unui „manager de licență software”, care amintește de managerul „aladin”. Scopul este de a putea plasa cheia pe o mașină separată.
Este implementat ca un alt „serviciu” în managerul clusterului. Puteți folosi, de exemplu, un laptop „gratuit”. Adăugați-l la clusterul 1C 8.3, creați un manager separat pe el cu serviciul „serviciu de licențiere”. Puteți introduce o cheie hardware hap în laptop sau puteți activa licențe software.
De cel mai mare interes pentru programatori ar trebui să fie „Cerințe de atribuire a funcționalității”.
Cerințe pentru funcționalitatea atribuită a 1c
Deci, pe un laptop cu o cheie de securitate, pentru a nu lansa utilizatorii pe serverul cluster, trebuie să adăugați „cerințe” pentru obiectul de cerințe „Conexiune client la securitatea informațiilor” – „Nu atribuiți”, adică. împiedică procesele de lucru de pe acest server să proceseze conexiunile client.
Și mai interesantă este capacitatea de a rula „numai joburi de fundal” pe serverul de producție al clusterului fără sesiuni de utilizator. În acest fel, puteți muta sarcinile foarte încărcate (cod) pe o mașină separată. Mai mult, puteți rula o sarcină de fundal de „închidere a lunii” folosind „Valoarea unui parametru suplimentar” pe un computer și sarcina de fundal „Actualizarea indexului de text integral” pe altul. Clarificarea are loc prin indicația „Valoarea de un parametru suplimentar”. De exemplu, dacă specificați BackgroundJob.CommonModule ca valoare, puteți limita munca serverului de lucru din cluster la numai joburi de fundal cu orice conținut. Valoarea BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>– va indica un cod specific.
Se încarcă...