Fluxul de lucru nu poate fi pornit din cauza unui conflict de port IP. Utilitar de administrare a clusterelor de servere

Cluster de servere 1C:Enterprise 8 (1C:Enterprise 8 Server Cluster)

Clusterul de servere 1C:Enterprise 8 este componenta principală a platformei, care asigură interacțiunea între sistemul de management al bazei de date și utilizator în cazul funcționării client-server. Clusterul face posibilă organizarea muncii neîntrerupte, tolerante la erori și competitive pentru un număr semnificativ de utilizatori cu baze de date mari de informații.

Un cluster de servere 1C:Enterprise 8 este un concept logic care denotă un set de procese care servesc același set de baze de date de informații.

Următoarele capabilități ale unui cluster de servere pot fi identificate ca fiind principale:

• capacitatea de a funcționa atât pe mai multe computere, cât și pe un singur computer (servere de lucru);
• fiecare server de lucru poate sprijini funcționarea unuia sau mai multor procese de lucru care deservesc conexiunile client în limitele acestui cluster;
• includerea de noi clienți în procesele de lucru ale clusterului are loc pe baza unei analize pe termen lung a statisticilor privind încărcarea procesului de lucru;
• interacțiunea tuturor proceselor cluster între ele, cu aplicațiile client și serverul de baze de date se realizează prin protocolul TCP/IP;
• procesele cluster rulează, pot fi fie un serviciu, fie o aplicație

Opțiune client-server. Schema de lucru

În această opțiune, o aplicație client interacționează cu serverul. Clusterul de servere, la rândul său, interacționează cu serverul bazei de date.

Rolul serverului central al clusterului este jucat de unul dintre computerele care fac parte din clusterul de servere. Pe lângă deservirea conexiunilor client, serverul central gestionează și funcționarea întregului cluster și stochează registrul acestui cluster.

Clusterul este adresat pentru conexiunile client prin numele serverului central și, eventual, numărul portului de rețea. Dacă se folosește un port de rețea standard, atunci pentru a vă conecta trebuie doar să specificați numele serverului central.

În timpul stabilirii conexiunii, aplicația client contactează serverul central al cluster-ului. Pe baza analizei statisticilor de încărcare a procesului de lucru, serverul central transmite aplicația client către procesul de lucru necesar, care ar trebui să o servească. Acest proces poate fi activat pe orice server de lucru din cluster, în special pe serverul central.

Întreținerea conexiunii și autentificarea utilizatorului sunt suportate de acest flux de lucru până când clientul încetează să mai lucreze cu o anumită bază de informații.

Cluster de servere

Un cluster de server de bază poate fi un singur computer și poate conține un singur proces de lucru.

În figură puteți observa toate elementele care, într-un fel sau altul, participă la funcționarea clusterului de servere. Acestea sunt următoarele elemente:

• procesele cluster de servere:
  o ragent.exe;
  o rmngr.exe;
  sau rphost.exe;
• stocare a datelor:
  o lista de clustere;
  o registru cluster.

Procesul ragent.exe, numit agent server, asigură funcționarea computerului ca parte a unui cluster. Prin urmare, computerul pe care rulează procesul ragent.exe ar trebui să fie numit server de producție. În special, una dintre responsabilitățile funcționale ale ragent.exe este de a menține un registru de clustere care se află pe un anumit server de lucru.

Nici registrul clusterului, nici agentul server nu sunt parte integrantă a clusterului de servere, ci doar permit funcționarea serverului și a clusterelor aflate pe acesta.

Clusterul de server în sine este format din următoarele elemente:

• unul sau mai multe procese rmngr.exe
• registrul clusterului
• unul sau mai multe procese rphost.exe.

Manager de cluster (procesul rmngr.exe). Acesta servește la controlul funcționării întregului cluster. Un cluster poate include mai multe procese rmngr.exe, dintre care unul va fi întotdeauna managerul principal al acestui cluster, iar procesele rămase vor fi manageri suplimentari. Serverul central al cluster-ului ar trebui să fie numit server de lucru pe care operează managerul principal de cluster și care conține lista cluster-ului. Menținerea registrului de cluster este una dintre funcțiile managerului principal de cluster.

Proces de lucru (proces rphost.exe). El este cel care servește direct aplicațiile client, interacționând cu serverul bazei de date. În timpul acestui proces, unele proceduri de configurare a modulelor serverului pot fi executate.

Scalabilitate a versiunii 1C 8.3

Scalabilitatea unui cluster de servere se realizează în următoarele moduri:

• cresterea numarului de manageri din cluster si distributia serviciilor intre acestia
• crește numărul de procese de lucru care operează pe un anumit server de lucru
• măriți numărul de servere de lucru care alcătuiesc clusterul.

Utilizarea mai multor manageri simultan.

Funcțiile îndeplinite de managerul clusterului sunt împărțite în mai multe servicii. Aceste servicii pot fi alocate diferiților manageri de cluster. Acest lucru face posibilă distribuirea uniformă a încărcăturii în mai multe procese.

Cu toate acestea, unele servicii pot fi utilizate numai de către managerul principal de cluster:

• serviciul de configurare a clusterului
• serviciul de gestionare a elementelor de depanare
• serviciu de blocare cluster.

Pentru alte servicii, administratorii de cluster arbitrari pot fi alocați:

• serviciul de jurnal
• serviciu de blocare a obiectelor
• serviciul de locuri de muncă
• serviciu de căutare text integral
• serviciu de date de sesiune
• serviciu de numerotare
• serviciu de setări personalizate
• serviciu de timp
• serviciu de blocare a tranzacțiilor.

Utilizarea mai multor fluxuri de lucru simultan.

Pe de o parte, utilizarea mai multor procese de lucru face posibilă reducerea sarcinii fiecărui proces de lucru specific. Pe de altă parte, utilizarea mai multor procese de lucru duce la o utilizare mai eficientă a resurselor hardware ale serverului de producție. Mai mult, procedura de lansare a mai multor procese de lucru crește fiabilitatea serverului, deoarece izolează grupuri de clienți care lucrează cu baze de informații diferite. Un proces de lucru dintr-un cluster care permite rularea mai multor procese de lucru poate fi repornit automat într-un interval de timp specificat de administratorul clusterului.

Capacitatea de a utiliza mai multe procese de lucru (creșterea numărului de conexiuni client) fără a crește sarcina unui anumit proces de lucru are ca rezultat o schimbare în creștere a numărului de servere de lucru care fac parte din cluster.

Toleranța la erori a 1C versiunea 8.3

Reziliența la eșecurile clusterului este asigurată în trei moduri:

• redundanța clusterului în sine
• rezervarea proceselor de lucru
• rezistență la întreruperea canalului de comunicare.

Copiere de rezervă a unui cluster 1C versiunea 8.3

Mai multe grupuri sunt combinate într-un grup de redundanță. Clusterele care se află într-un astfel de grup sunt sincronizate automat.

Dacă clusterul activ eșuează, acesta este înlocuit cu următorul cluster de lucru din grup. Odată ce clusterul eșuat este restaurat, acesta va deveni activ după sincronizarea datelor.

Backup pentru procesele de lucru 1C versiunea 8.3

Pentru fiecare dintre fluxurile de lucru, este posibil să specificați opțiuni pentru utilizarea acestuia:

• utilizare
• nu folosi
• utilizați ca rezervă.

Dacă un proces se prăbușește, clusterul începe să utilizeze un proces de rezervă momentan inactiv. În acest caz, sarcina de pe acesta este redistribuită automat.

Rezistența 1C versiunea 8.3 la întreruperea canalului de comunicație

Deoarece fiecărui utilizator i se oferă propria sa sesiune de comunicare, clusterul stochează date despre utilizatorii care s-au conectat și ce acțiuni au efectuat.

Dacă conexiunea fizică dispare, clusterul va fi într-o stare de așteptare pentru o conexiune cu acest utilizator. În cele mai multe cazuri, după ce conexiunea este restabilită, utilizatorul va putea continua să lucreze exact din punctul în care conexiunea a fost pierdută. Nu este nevoie să vă reconectați la baza de informații.

Sesiuni în versiunea 1C 8.3

O sesiune face posibilă determinarea utilizatorului activ al unei anumite baze de informații și determinarea fluxului de control de la acest client. Se disting următoarele tipuri de sesiuni:

• Thin client, Web client, Thick client - aceste sesiuni apar atunci când clienții corespunzători accesează infobaza
• Conexiune de tip „Configurator” - apare la accesarea bazei de informații configurator
• Conexiune COM – formată atunci când utilizați o conexiune externă pentru a accesa o bază de informații
• Conexiune WS – apare la accesarea bazei de informații a serverului web ca urmare a accesării unui serviciu web publicat pe serverul web
• Lucrare de fundal – creată atunci când un proces de lucru în cluster accesează baza de informații. O astfel de sesiune este folosită pentru a executa codul procedurii jobului de fundal,
  Consola cluster – creată atunci când utilitarul de administrare client-server accesează un proces de lucru
• Administrator COM – apare atunci când un proces de lucru este accesat folosind o conexiune externă.
• Lucrați sub diferite sisteme de operare

Orice proces de cluster de server poate funcționa atât sub sistemul de operare Linux, cât și sub sistemul de operare Windows. Acest lucru se realizează prin faptul că interacțiunea cluster are loc sub controlul protocolului TCP/IP. Clusterul poate include, de asemenea, servere de lucru care rulează oricare dintre aceste sisteme de operare.

Utilitar de administrare a clusterului de servere 8.3

Pachetul de sistem include un utilitar pentru administrarea opțiunii client-server. Acest utilitar face posibilă modificarea compoziției clusterului, gestionarea bazelor de informații și analizarea rapidă a blocărilor tranzacțiilor.

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:

1. testul Gilev;
2. 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.

La instalarea următoarei actualizări de contabilitate am primit eroarea „Lucrez doar pe 8.3.4”, ei bine... este timpul să instalez 8.3.4. Asa de:

Nu voi descrie procesul de descărcare și instalare a noii platforme, totul este simplu.

Serviciul Server Agent 1C
Implicit este instalat pe portul 1540, iar acolo am 8.2 care rulează, așa că îl schimbăm în ramura de registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Parametrul ImagePath Agent Server Enterprise 8.3
modificați numerele de porturi adăugând un offset: „C:\Program Files\1cv8\8.3.4.365\bin\ragent.exe” -srvc -agent -regport 1741 -port 1740 -range 1660:1691 -d "C:\Program Fișiere\ 1cv8\srvinfo"

Lansați Agentul și deschideți consola de administrare a serverelor 1C și creați un cluster 8.3
A specificat numele serverului și l-am configurat pe portul 1740 (8.2 rulează pe 1540)

Creăm un cluster + l-am optimizat puțin (am un singur server mic, așa că indic intervalul de repornire pentru procesele de lucru și cantitatea de memorie. Pentru că am un server - nivelul de toleranță la erori este 0)


Acum mai detaliat:
1. Interval de repornire: 86400 sec (24 ore). Momentul repornirii nu este reglementat, aparent din momentul in care parametrii sunt setati sau este pornit serverul de aplicatii.
2. De asemenea, puteți specifica cantitatea de memorie permisă: 3.000.000 KB (3 GB) - Pentru un server cu 4 GB RAM, Dacă este mai puțin, atunci nu completați varianta asta!.
3. Intervalul de depășire a memoriei este o perioadă continuă de timp în care este depășită cantitatea permisă de memorie, după care serverul va reporni procesul. Dacă este specificat 0 secunde, va aștepta pentru totdeauna.
4. Numărul de procese de lucru este calculat automat pe baza setărilor dvs
5. Nivel de toleranță la erori Puteți seta nivelul de toleranță la erori de cluster ca număr de servere funcționale care pot eșua simultan și acest lucru nu va duce la terminarea anormală a utilizatorilor. Serviciile de backup sunt lansate automat în cantitatea necesară pentru a asigura toleranța la erori specificată; În timp real, serviciul activ este replicat celor de rezervă.
6. Modul de distribuție a încărcăturii, care poate fi folosit fie pentru a crește performanța sistemului în ansamblu, fie pentru a utiliza noul mod „economisire memorie”, care vă permite să lucrați „cu memorie limitată” în cazurile în care configurația utilizată „place” să mănânce memoria.”

Server de lucru
Serverul meu este simplu, 2 Gb de RAM în total și vor fi doar 2 baze de date pe el, așa că îl voi configura astfel:

Am setat parametrul Număr de securitate a informațiilor per proces la 1, adică. Vreau ca fiecare securitate a informațiilor să ruleze propriul proces - acest lucru va reduce influența reciprocă atât în ​​ceea ce privește fiabilitatea, cât și performanța. Îl configurați după caracteristicile serverului dvs.!

Baza de informatii
adaug IB:

În starter urina baza de date:

Cerințe de atribuire a funcționalității
Nu am stabilit asta eu, dar cred că ar trebui să spun despre asta:
Managementul clusterelor înseamnă că administratorul stabilește compoziția computerelor (servere de lucru) pe care se află clusterul. În plus (dacă este necesar), el poate determina „cerințele” pentru acestea: ce servicii și conexiuni la bazele de informații ar trebui să ruleze pe fiecare dintre serverele de lucru. Managerii de cluster și procesele de lucru sunt lansate automat pe baza „cerințelor” atribuite. „Cerințele” pentru serverele de producție pot fi specificate interactiv, din consola de administrare a clusterului, sau programatic, din limbajul încorporat.
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 „închiderea lunii” prin „Valoare suplimentară a parametrului” pe un computer și sarcina de fundal „Actualizarea indexului textului integral” pe altul. Clarificarea are loc prin indicația „Valoarea parametrului 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.

Profiluri de securitate
Profilurile de securitate servesc pentru a interzice unei soluții de aplicație să efectueze acțiuni care ar putea fi potențial periculoase pentru funcționarea unui cluster de servere.
Administratorul clusterului poate atribui oricărei baze de informații unul dintre profilurile de securitate existente în cluster. Și apoi funcționalitatea potențial periculoasă a soluției aplicației va fi limitată în limitele descrise în acest profil.

În mod implicit, odată creat, un profil de securitate interzice toate acțiunile potențial periculoase:
- acces la sistemul de fișiere server;
-lansarea obiectelor COM;
-utilizarea componentelor externe 1C:Enterprise;
- lansarea de procesari si rapoarte externe;
-lansarea aplicatiilor instalate pe server;
- acces la resursele de internet.
Astfel, a vă proteja de acțiunile nedorite ale unei soluții de aplicație necunoscute este foarte simplu: trebuie să creați un profil de securitate gol și să-l atribuiți bazei de informații. În plus, dacă este necesar, puteți extinde acest profil, descriind în el acțiunile pe care soluția aplicației are voie să le efectueze.

Locația fișierelor de serviciu de manager de cluster în 1C Enterprise 8.3
Dacă la instalarea sistemului! „1C:Enterprise” a ales opțiunea de lansare a serverului „1C:Enterprise” ca serviciu, apoi prima lansare a agentului server va fi efectuată în timpul procesului de instalare a sistemului. În acest caz, serviciul va fi lansat în numele utilizatorului selectat în dialogul de instalare a sistemului, dar fișierele de serviciu cluster server vor fi localizate în director<каталог установки системы 1С:Предприятие>\srvinfo (cheia de lansare -d va fi specificată explicit în parametrii serviciului).

Dacă, la instalarea sistemului 1C:Enterprise, ați selectat opțiunea de a lansa serverul ca aplicație, atunci serverul nu este lansat în timpul procesului de instalare a sistemului; Agentul server trebuie pornit independent după finalizarea instalării sistemului. Mai mult, dacă comutatorul de pornire -d nu este specificat, fișierele de serviciu cluster server vor fi localizate în directorul implicit: %USERPROFILE%\LocalSettings\ApplicationData\lC\lCv8 (%LOCALAPPDATA%\lC\lCv8 pentru Windows Vista și mai vechi) .

ATENŢIE! Dacă pe acest server central a fost deja creat un cluster, atunci când schimbați opțiunea de lansare a agentului server (serviciu, aplicație) sau când schimbați utilizatorul în numele căruia rulează agentul server, trebuie să aveți întotdeauna grijă să specificați corect calea în directorul de fișiere de serviciu al clusterului de servere. Dacă agentul server nu găsește o listă de clustere în timpul pornirii, va crea un nou cluster pe acest server.
În sistemul de operare Linux, fișierele de serviciu cluster server vor fi localizate în folderul /home/usrlcv8/.lcv8/lC/lcv8 (sau versiunea scurtată este ~/.1cv8/1C/1cv8).

Acum aproximativ doi ani am publicat material despre serverul 1C Enterprise pe platforma Linux; interesul pentru acest subiect este încă mare. În același timp, s-au schimbat multe, platforma 1C nu stă pe loc și, cel mai adesea, implementarea depășește simpla repetare a instrucțiunilor. Acest lucru nu este surprinzător, serverul 1C Enterprise este un produs complex, așa că am decis să începem această serie de articole care vizează un studiu mai profund al subiectului.

Înainte de a ridica mouse-ul și de a alerga în camera serverului, ar trebui să înțelegeți clar cunoștințele minime necesare, și anume, să aveți o idee despre structura serverului 1C Enterprise și scopul componentelor sale individuale. Majoritatea problemelor din timpul implementării se datorează faptului că serverul 1C Enterprise este perceput ca un fel de formațiune monolitică în care toate componentele sunt interconectate într-un mod viclean cunoscut de un singur dezvoltator. Cu toate acestea, nu este așa, iar astăzi ne vom da seama în ce constă serverul nostru și cum funcționează totul împreună.

Aș dori să subliniez încă o dată importanța extremă a ceea ce va fi discutat mai jos. Fără aceste cunoștințe, va fi dificil să se obțină o funcționare stabilă, ca să nu mai vorbim de diagnosticarea blocajelor și creșterea productivității. Rezultatul poate fi o imagine clasică: hardware-ul pare a fi puternic, totul a fost făcut conform instrucțiunilor, dar încetinește. Din păcate, majoritatea instrucțiunilor pentru începători (inclusiv ale noastre) conțin doar informații despre cum să o faci, fără a se concentra pe ce se face exact și de ce. Deci, să începem să reparăm lucrurile.

Versiunea client-server a 1C Enterprise este o structură pe trei niveluri (așa-numita „trei niveluri”), care include: un client, un server 1C Enterprise și un server DBMS. Acestea sunt componente complet independente care pot fi combinate în orice combinație acceptabilă pentru a obține cel mai bun rezultat. Luați în considerare următoarea diagramă:

Să începem cu clienții; versiunea actuală a platformei (8.2) prevede utilizarea a trei tipuri de clienți. Să le privim mai detaliat.

Client gras

Aceasta este o aplicație client clasică 1C; înainte de lansarea platformei 8.2, era singurul tip de client disponibil. Schema de operare a clientului gros este următoarea: aplicația client solicită date de la serverul 1C, apoi le solicită la rândul său din baza de date și le transmite înapoi clientului, unde sunt procesate. După cum puteți vedea, această schemă nu este optimă: serverul 1C este în esență doar un strat între client și baza de date, toate calculele au loc pe client. Acest lucru impune cerințe sporite PC-urilor client, deoarece Puterea de calcul a serverului nu este utilizată. Merită să înțelegeți clar că în modul client gros nu veți obține o creștere a performanței de la trecerea la versiunea client-server, poate chiar invers.

Client slab

Poate fi numit principalul tip de aplicație client pentru platforma 8.2; în teorie, în practică, nu totul este atât de ușor și vom reveni la asta. Modul de funcționare este radical diferit: clientul solicită date de la serverul 1C, care le primește din baza de date, le prelucrează și returnează clientului rezultatul calculului. Sarcina principală de calcul cade pe server, deci nu există cerințe speciale pentru PC-urile client și canalul de la client la server.

De asemenea, clientul subțire poate funcționa atât folosind protocolul TCP/IP într-o rețea locală, cât și prin HTTP prin Internet. Acest lucru necesită un alt intermediar - un server web, care transmite cererile clientului către serverul 1C; pe serverul web nu se efectuează nicio prelucrare a datelor, este folosit exclusiv ca transport. Avantajele unui client subțire sunt clare; dacă aveți un server puternic, vă permite să accelerați semnificativ lucrul cu programul; traficul de rețea este, de asemenea, redus semnificativ, ceea ce este foarte important pentru rețelele de birouri.

Client web

Existența sa rezultă în mod logic din unele proprietăți ale unui client subțire; într-adevăr, dacă toate cererile sunt procesate de server, HTTP este folosit ca transport, atunci de ce să nu folosiți un browser pentru lucru? Modul în care funcționează clientul web nu este diferit de clientul subțire, cu toate acestea, astăzi nu toate funcțiile suportate de clientul subțire sunt implementate și funcționează corect în clientul web. În parte, acest lucru poate fi corectat în configurație; în parte, mecanismul de afișare a informațiilor în browser impune restricții. Totuși, 1C are un client web și funcționează și nu te deranjează nimeni (din nou teoretic) să lucrezi în program în timp ce stai întins pe plajă cu o tabletă.

Acum despre musca în unguent. Pentru a funcționa corect în modurile client subțire și web, configurația trebuie să ruleze în modul aplicație gestionată și să accepte toate funcțiile din acest mod. Modul de aplicație gestionat este cel principal pentru platforma 8.2 și este destul de diferit de ceea ce era înainte, inclusiv în aparență. Aplicația condusă vizual poate fi identificată prin noua sa interfață, care include file și hyperlink-uri:

Cel puțin, este neobișnuit, mai ales în comparație cu interfața clasică, dar nu vă grăbiți să vă bucurați când vedeți noua interfață; pe lângă aspect, configurația trebuie să susțină execuția tuturor funcționalităților sale pe server; s-ar putea dovedi că în modurile client subțire și web nu sunt disponibile toate posibilitățile.

Astăzi, doar o parte din configurațiile tipice funcționează în modul de aplicație gestionată, cum ar fi: managementul firmelor mici, managementul comerțului 11, retail 2 și managementul salariilor și resurselor umane. Aceste soluții pot profita din plin de noua platformă. Enterprise Accounting 2.0 nu utilizează un mod de aplicație gestionat și nu va funcționa în clienții subțiri și web, același lucru este valabil și pentru multe soluții terțe, cum ar fi „Kamin”, etc.

concluzii

Dacă este posibil, ar trebui să utilizați un client subțire, deoarece acest lucru vă permite să mutați toate calculele pe partea serverului și să lucrați confortabil chiar și pe canale lente, inclusiv. prin intermediul internetului. Trebuie amintit că lucrul în modul Configurator este posibil doar printr-un client gros, care va trebui să fie folosit și pentru a lucra cu configurații care nu au fost încă transferate în modul de aplicație gestionată.

Clientul web ar trebui folosit atunci când nu este posibil să utilizați unul subțire, de exemplu de pe computerul altcuiva într-o călătorie de afaceri, dar ar trebui să fiți pregătit pentru absența sau funcționarea incorectă a unor funcții.

cluster de servere 1C

După ce am avut de-a face cu clienții, să trecem la servere. Sistemul prevede utilizarea a trei tipuri de servere: 1C Server, server DBMS și server web. Este important să înțelegem că datele serverului sunt complet independente unele de altele; acest lucru oferă flexibilitate sistemului și permite utilizarea rațională a resurselor de calcul.

De asemenea, sistemul nu impune nicio cerință pe platforme. Puteți partaja atât servere Windows, cât și Linux, Apache și IIS pot fi folosite ca server web, PostgreSQL, MS SQL Server, IBM DB2 și Oracle sunt acceptate de DBMS. Prin urmare, nimeni nu vă împiedică să creați o schemă în care un server 1C care rulează pe platforma Linux va funcționa împreună cu un server de baze de date care rulează Windows Server și IIS și invers. În plus, puteți utiliza mai multe servere DBMS (precum și servere web) prin plasarea diferitelor baze de date pe servere diferite.

Această abordare vă permite să combinați, să extindeți și să modificați în mod flexibil configurația existentă în funcție de nevoile actuale, în timp ce totul va fi cât mai transparent posibil pentru utilizatorul final. De exemplu, puteți muta securitatea informațiilor care necesită mult resurse pe un server DBMS separat modificând numai parametrii de conexiune la baza de date din setările serverului, fără a afecta setările clientului.

Și, în sfârșit, cel mai interesant lucru: un cluster de servere 1C Enterprise. Da, așa este, nu un singur server, ci un grup de servere. De obicei, aici începe confuzia, mai ales dacă există un singur server. Totuși, totul se încadrează dacă ținem cont de faptul că conceptul de cluster de servere este în primul rând logic, dar această abordare vă permite cu ușurință să scalați schema, crescând performanța sau toleranța la erori.

Orice cluster constă dintr-un server central 1C Enterprise și servere de lucru. În cea mai simplă configurație, acesta va fi același server fizic. Cu toate acestea, dacă este necesar, putem adăuga servere de lucru suplimentare, a căror încărcare va fi echilibrată de serverul central. Acest lucru vă permite să creșteți rapid și transparent puterea de calcul a sistemului și să creșteți toleranța la erori. De asemenea, clusterul nu impune cerințe pentru omogenitatea platformei; poate include servere care rulează atât Windows, cât și Linux.

Ce concluzii se pot trage din cele de mai sus? În primul rând, sistemul client-server 1C Enterprise este foarte flexibil și vă permite să utilizați în mod optim resursele de calcul disponibile pentru a obține rezultatul optim. Ce configurație să alegeți depinde de sarcinile specifice și de fondurile alocate pentru a le rezolva.

De exemplu, dacă aveți o sarcină ușoară și utilizați un client gros și o configurație care nu acceptă modul de aplicație gestionată, este logic să combinați un cluster de servere 1C și un server DBMS pe un server fizic, deoarece este foarte irositor să alocați o mașină separată pentru stratul dintre client și baza de date.

În schimb, atunci când utilizați o aplicație gestionată în modul client subțire, este mai bine să separați serverul DBMS și clusterul de servere în servere diferite, fiecare dintre acestea fiind optimizat pentru propria sa sarcină.