05.04.2017 |

Clusterul 1C 8.3

Î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, actualul cluster 1C a fost setat la „8”, dar pe parcursul mai multor ore de funcționare, serverul a devenit 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- valoarea implicită este „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 de lucru care pot eșua în același timp, iar 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 a sarcinilor 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 folosit 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țele 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, iar sarcina de fundal „Actualizarea indexului textului integral” pe altul are loc prin indicația „Valoare 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.

Clusterul 1C 8.2

Sesiunile permit echilibrarea sarcinii și toleranța la erori în cadrul unei aplicații gestionate.

Managerul clusterului a devenit acum mai complex. Unele funcții pot fi acum separate într-un proces separat și chiar plasate pe un alt server de lucru din cluster. Acest lucru vă permite să echilibrați încărcarea serverului.

Toleranța la erori Server 8.2 se realizează prin:

• Stocarea informațiilor despre sesiunea utilizatorului.
• Utilizatorul nu mai este legat de fluxul de lucru.
• Rezervarea proceselor de lucru într-un cluster.
• Ar trebui să existe mai multe procese de lucru, inclusiv cele redundante
• Rezervare cluster.

Este indicat un cluster de rezervă atunci când sunt conectați, acestea sunt listate în linia de conectare

Acest lucru vă permite să asigurați continuitatea muncii!

Dacă conexiunea fizică a clientului la cluster este întreruptă (doamna de curățenie a scos cablul, alimentarea echipamentului de rețea a fost oprită, a existat o problemă cu furnizorul), nu este nevoie să vă reconectați la baza de informații și să porniți totul munca din nou. După ce conexiunea fizică este restabilită, utilizatorul poate continua să lucreze din punctul în care a fost întreruptă.

Dacă este necesară întreținerea computerelor cluster, acestea pot fi oprite în timpul funcționării fără a opri utilizatorii să lucreze cu baza de informații.

Dacă orice server din cluster eșuează, lucrul utilizatorului nu se va opri, acesta va fi transferat automat în clusterul de rezervă și/sau în procesele de lucru de rezervă. Pentru utilizatori, o astfel de tranziție va fi invizibilă.

Dacă unul dintre procesele de lucru ale clusterului eșuează, utilizatorii conectați la acesta vor fi transferați automat la alte procese de lucru sau de rezervă. O astfel de tranziție va fi, de asemenea, invizibilă pentru utilizatori.

DECI CE S-A SCHIMBAT ÎN CLUSTERUL 1C 8.3:

În primul rând, după instalarea clusterului 1C, a fost necesar să se creeze fluxuri de lucru. După cum sa dovedit,procesele clustera început să fie creat 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 o eroare va fi aruncată "Nu există suficientă memorie liberă pe serverul 1C„. Puteți obține această eroare și 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.

Cantitatea de memorie de proces de lucru până la care serverul este considerat productiv- la 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 curent 1C a fost setat la- „8”, dar pe parcursul mai multor ore de funcționare serverul a devenit 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- valoarea implicită este „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- Acest numărul de servere funcționale care pot eșua simultan fără a provoca blocarea 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.

În loc de postfață. Clusterul 1C 8.3 funcționează considerabil mai rapid și mai fiabil, crearea unei sesiuni de utilizator cu baza de informații este de multe ori mai rapidă, se poate spune că interfața în modul de compatibilitate cu 1C 8.2.16 zboară. Desigur, există nuanțe, dar unde am fi noi fără ele? Succes în configurarea noului cluster 1C 8.3.

Vă rugăm să rețineți că setările clusterului sunt responsabile pentru setările tuturor serverelor care aparțin clusterului configurat. Un cluster presupune operarea mai multor servere fizice sau virtuale care lucrează cu aceleași baze de date de informații.

Interval de repornire– este responsabil pentru frecvența repornirii proceselor de lucru în cluster. Acest parametru trebuie setat atunci când serverul rulează non-stop. Se recomandă asocierea frecvenței de repornire cu ciclul tehnologic al bazelor de info cluster. De obicei, aceasta este la fiecare 24 de ore (86400 de secunde). După cum știți, procesele de lucru ale serverelor 1C procesează și stochează datele de lucru.

Repornirea automată a fost proiectată în platformă „pentru a minimiza efectele negative ale fragmentării și scurgerilor de memorie în fluxurile de lucru”. ITS are chiar și informații despre cum să organizeze repornirea proceselor de lucru pe baza altor parametri (dimensiunea memoriei, resursele ocupate etc.).

Dimensiunea memoriei permisă– protejează serverele 1C de suprasolicitarea memoriei. Dacă procesul depășește acest volum în interval de depășire a volumului admis, procesul este repornit. Poate fi calculată ca dimensiunea maximă de memorie ocupată de procesele „rphost” în perioadele de vârf de încărcare a serverului. De asemenea, merită să setați un interval mic pentru depășirea volumului permis.

Abaterea permisă a numărului de erori de server. Platforma calculează numărul mediu de erori de server în raport cu numărul de apeluri către server în decurs de 5 minute. Dacă acest raport depășește valoarea permisă, atunci fluxul de lucru este considerat „problematic” și poate fi încheiat de sistem dacă steag-ul este setat „Începeți forțat procesele problematice.”

Opriți procesele dezactivate după. Dacă este depășită cantitatea de memorie permisă, procesul de lucru nu se încheie imediat, ci devine „dezactivat”, astfel încât să existe timp pentru a „transfera” datele de lucru fără pierderi către noul proces de lucru care rulează. Dacă acest parametru este specificat, atunci procesul „dezactivat” se va încheia în orice caz după expirarea acestui timp. Dacă observați procese de lucru „înghețate” în funcționarea serverului 1C, atunci puteți seta acest parametru la 2-5 minute.
Aceste setări sunt setate individual pentru fiecare server 1C.

Memorie maximă pentru fluxul de lucru– acesta este volumul total memorie care poate fi ocupată de procesele de lucru (rphost) pe clusterul curent. Dacă parametrul este setat la „0”, acesta ocupă 80% din memoria RAM a serverului. „-1” - fără restricții. Când un DBMS și un server 1C rulează pe același server, trebuie să partajeze RAM. Dacă în timpul funcționării se dovedește că serverul DBMS nu are suficientă memorie, atunci puteți limita memoria alocată serverului 1C folosind acest parametru. Dacă DBMS și 1C sunt separate de servere, atunci este logic să calculați acest parametru folosind formula:

„Volum maxim” = „RAM totală” – „RAM OS”;

„OS RAM” se calculează pe principiul a 1 GB pentru fiecare 16 GB de RAM de server

Consum de memorie sigur per apel. În general, apelurile individuale nu ar trebui să ocupe toată memoria RAM alocată unui proces de lucru. Dacă parametrul este setat la „0”, atunci debitul sigur va fi egal cu 5% din „ Capacitate maximă de memorie pentru procesele de lucru”. „-1” - fără limitare, ceea ce nu este foarte recomandat. În cele mai multe cazuri, este mai bine să lăsați acest parametru la „0”.

Utilizarea parametrilor „Numărul de securitate a informațiilor per proces” și „Numărul de conexiuni per proces” puteți controla distribuția muncii serverului 1C între procesele de lucru. De exemplu, rulați un „rphost” separat pentru fiecare bază de informații, astfel încât, în caz de blocare a procesului, numai utilizatorii unei baze de date să fie deconectați. Acești parametri ar trebui selectați individual pentru fiecare configurație de server.

Limitarea utilizării RAM de către serverul DBMS– Serverul MS SQL DBMS are o caracteristică remarcabilă - îi place să încarce baze de date cu care lucrează activ complet în RAM. Dacă nu îl limitați, va lua toată memoria RAM posibilă.

• Dacă serverul 1C:Enterprise este instalat împreună cu Microsoft SQL Server, atunci pragul superior de memorie trebuie redus cu o sumă suficientă pentru funcționarea serverului 1C.
• Dacă numai DBMS rulează pe server, atunci pentru DBMS conform formulei:

„Memorie DBMS” = „RAM generală” – „RAM OS”;

Memorie partajată– se știu multe despre acest parametru, dar totuși se întâmplă ca oamenii să uite de el. Îl setăm la „1” dacă serverul 1C și DBMS rulează pe același server fizic sau virtual. Apropo, funcționează începând de la platforma 8.2.17.

Gradul maxim de paralelism– determină câte procesoare sunt folosite la executarea unei cereri. SGBD paralelizează regăsirea datelor atunci când se execută interogări complexe pe mai multe fire. Pentru 1C este recomandat să-l setați la „1”, adică într-un fir.

Extensia automată a fișierelor bazei de date- determinăm pasul în MB cu care fișierul bazei de date este „extins”. Dacă pasul este mic, atunci cu creșterea activă a bazei de date, extinderile frecvente vor duce la încărcare suplimentară a sistemului de discuri. Este mai bine să-l setați la 500 – 1000 MB.

Reindexarea și defragmentarea indecșilor– se recomandă defragmentarea/reindexarea cel puțin o dată pe săptămână. Reindexarea blochează mesele, așa că cel mai bine este să rulați în timpul orelor de lucru sau în perioadele de încărcare minimă. Nu are rost să faci defragmentare după reconstruirea indexului (reindexare). Conform recomandărilor Microsoft, defragmentarea se face dacă fragmentarea indexului nu depășește 30%. Dacă este mai mare, se recomandă reindexarea.

Planul de alimentare– setați setările de putere ale sistemului de operare la performanță ridicată.

Victoria nu a fost ușoară...
Voi încerca să descriu totul în detaliu, deși a trecut destul de mult timp. Sper că informațiile pe care le-am adunat vor ajuta administratorii de sistem și să-mi dea ceva la care să mă gândesc.
Am mutat bazele de date la 1 școală și am realocat utilizatorul pentru agentul 8.3 - nu a ajutat...

Am parcurs RuNet-ul nostru și am găsit două articole interesante, pe care vă sugerez să le citiți și dumneavoastră.

Pentru prima dată, un test destul de detaliat între două platforme: versiunea PS-middle și serverul dual-core. Apar puncte destul de interesante care au fost subliniate de mine în timp ce lucram în alte companii.
efsol.ru/articles/tuning-1c.html

Al doilea se referă la testele 1c pe mașini virtuale. Aici am văzut motivul întârzierii lansării configurației:
efsol.ru/articles/performance-comparison-1c.html

După ce am săpat aproximativ o săptămână și am încercat mai multe metode, nu am putut rezolva problema cu prima lansare. Dar am observat un model interesant... Când clientul subțire rulează, a doua pornire a sistemului are loc aproape instantaneu. Am schimbat setările pentru numărul de sisteme de securitate a informațiilor pe proces: 8 (sunt 5 baze de date pe 8.3 până acum). Ca rezultat, din moment ce serverul a încetat să mai piardă timpul creând RPHOST la intrarea pe traseu. a cheltuit baza și restul doar pentru a descărca conferința din scâncete. S-a redus timpul de pornire al bazei secunde cu 10-7 secunde.

În principiu, această opțiune mi se potrivește pe deplin, având în vedere că la fiecare bază de date lucrează 7-10 utilizatori, conf-ul este menținut constant în RPHOSTe și timpul de conectare este de 4-8 secunde cu autentificare împreună.

Dacă aveți probleme că baza de date nu este deschisă des, atunci ca opțiune vă pot sugera tăierea unui mic reg. sarcină de introducere a utilizatorului la fiecare bază de date și configurați serviciul să repornească seara (fie prin servicii, fie printr-un interval de repornire). Cred că acest lucru ar trebui să ajute, deși aici suntem limitați de disponibilitatea unei licențe, așa că trebuie să ne gândim)))

Dar un alt moment neplăcut a apărut pe unul dintre forumuri am primit acest răspuns:
Offtop. Aveți licențe CORP?

Capacitățile avansate ale serverului de nivel CORP „1C:Enterprise 8.3” în comparație cu serverul de nivel PROF pe 64 de biți:
* consum de memorie sigur per apel;
* numărul de securitate a informațiilor pe proces;
* cantitatea de memorie a proceselor de lucru până la care serverul este considerat productiv;
* capacitatea maximă de memorie a proceselor de lucru;
*strategia de echilibrare (memorie, performanță);

Utilizarea funcționalității enumerate folosind produsele „1C:Enterprise 8. Server License (x86-64)” de nivel PROF, adică cele care nu au denumirea CORP în nume, este ilegală.

Am decis să verific cu băieții de la trei companii diferite dacă știau că există o platformă corporativă și prof. La care răspunsul a fost primit sub forma unui deget care se învârte la tâmplă și a unei trimiteri către forumul 1c. Și mai jos este răspunsul de la suportul 1c:

1) >>> Aș dori să clarific diferențele dintre platforma 8.3 Corp și 8.3 Prof.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

De fapt, atunci când utilizați Platforma PROF, conform licenței, puteți utiliza doar setările implicite ale clusterului.

Dacă întâmpinați probleme cu setările „implicite” ale clusterului (lipsa memoriei, incapacitatea de a actualiza configurația etc.), atunci
acest comportament este o eroare (fie al platformei, fie al acestei soluții de aplicație).
Creați cereri de corectare cu exemple specifice.
În timpul corectării erorii, se poate emite permisiunea în scris (semnată de directorul SA 1C) pentru a utiliza funcționalitatea licenței Corp.
2) >>> Vă rugăm să clarificați, i.e. există două platforme 8.3?
Nu. Platforma nu este momentan singură.
Cu toate acestea, dreptul de a utiliza funcționalitatea CORP apare numai la achiziționarea licenței corespunzătoare.
De asemenea, nu există nici un control software pentru această licență în acest moment.
Astfel, licența CORP este mai mult un concept legal.

Sincer, nu cred în diverse tipuri de conspirații, dar când o companie are un monopol aproape 100% pe piața întreprinderilor mici și mijlocii, îmi vin în minte gânduri diferite.
„Va fi o actualizare a unui fel de configurație pentru depunerea rapoartelor, care va necesita actualizarea platformei, în care controlul software-ului va fi deja implementat... Și apoi ne veți plăti integral (1c)... copii. ”
P.S. Aș dori să clarific că serverul meu se bazează pe 2008r2 și pot exista diferențe față de 2012. Totuși, kernel-ul a fost tăiat în detaliu, iar hyper-v 3.0 este, de asemenea, un bonus pentru creștere. Dar cum se spune „Este viu!!!” iar rularea 1C pe mașini virtuale nu este doar posibilă, ci și încurajată. Ca rezultat, avem 30 8.2 utilizatori și 20 8.3 utilizatori. Succes tuturor, aveți răbdare și nu renunțați niciodată)))

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 a sarcinilor de fiabilitate.

A fost dezvoltat un mecanism de echilibrare a sarcinii, care poate fi folosit 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țele 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, iar sarcina de fundal „Actualizarea indexului textului integral” pe altul are loc prin indicația „Valoare 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.