soluții Cluster pentru r

Obiectivul principal al dezvoltării sistemelor informaționale - soluția cea mai completă a sarcinilor funcționale, asigurând o fiabilitate ridicată, scalabilitate și protecție a investițiilor. Să sperăm că, astfel cum este prevăzut în prezentul articol experiența specialiștilor SA „cosmetice Neva“, care a trebuit să aleagă sisteme de soluții de inginerie pentru 3 sistemul / R va fi util multora.

Sistemul corporativ de management al afacerilor bazate pe SAP R / 3 este proiectat pentru a efectua funcții de afaceri de bază ale SA „cosmetice Neva“: management financiar (modulul FI), logistica (modulul MM), controlul (modulul CO), managementul vânzărilor și distribuție ( SD) modul. In prima faza a proiectului trebuia să implementeze 50 de locuri de muncă, iar mai târziu pentru a crește numărul acestora la 100. Odată cu dezvoltarea în continuare a proiectului sa decis să pună în aplicare PP module (Planificare de producție), QM (Managementul Calității), PN (întreținere și reparații) și EIS (info manual de sistem). În plus, acesta a fost planificat ca IPM ar trebui să ofere o serie de funcții de sprijin - integritatea arhivarea datelor și de rezervă. Cea mai importantă cerință a fost de a asigura o fiabilitate ridicată a 3 sistem / R în ansamblu, precum și de disponibilitatea constantă a resurselor esențiale: calculator, disc, bandă de rețea. Orientări „Neva Cosmetics“ necesară scalabilitate adecvată aplicațiilor consumatoare de resurse ca tip R / 3, iar datele sunt, de obicei, în mod substanțial mai mare decât proiectat. Prin urmare, soluția integratori de sistem ar trebui să aibă un potențial ridicat de creștere a performanței de procesoare, memorie, subsistem I / O, etc., pentru a proteja sistemele de aplicare nedureroase inițiale de investiții și de adaptare în cazul creșterii bruscă a sarcinii.

În procesul de creare a unui sistem corporativ a fost propus de a utiliza un model bazat pe rețea pentru sistemul de calcul de punere în aplicare, în care funcționalitatea de bază, scalabilitate și fiabilitate a soluțiilor oferite de serverul central, iar locurile client vând acces numai la resursele informaționale. Abordarea propusă asigură o fiabilitate ridicată - prin combinarea servere în grupuri de HA; scalabilitate maximă - datorită aplicării sistemelor multiprocesare simetrice ca grupuri de componente; protecție maximă de investiții - prin utilizarea echipamentelor în grupuri neomogene.

FUNCȚIONALITATEA

Caracteristica principală a oricărui IPM - o funcționalitate care, la rândul său, asigură nivelul necesar de performanță a hardware-ului, software-ul utilizat, calitatea componentelor sistemului, precum și compoziția echipamentului suplimentar. Deja în etapa de soluții de sisteme de inginerie de pre-selecție, a devenit clar faptul că asigurarea funcționării depline a / 3 și servicii conexe R este posibilă numai atunci când se utilizează clustere de servere SMP-pe un RISC și UNIX. Soluțiile bazate pe Windows NT ca nesigure și non-scalabile au fost respinse imediat, iar soluțiile închise nu au fost luate în considerare din cauza costului ridicat al acestora. Conform datelor preliminare furnizate de client au fost utilizate cerințele pentru modelul CSEA (trei niveluri), precum si R / 3 și Oracle servere. Pentru a pune în aplicare aceste cerințe, a fost necesar pentru a crea un mediu de hardware și software care îndeplinește următoarele cerințe:

  • lucrează în on-line modul în UNIX c mediu de baze de date ORACLE și SAP R / 3;
  • realizarea unei soluții de cluster de înaltă fiabilitate oferă o repornire rapidă a aplicațiilor și serviciilor majore;
  • capacitatea de a integra componente software și hardware existente în sistem;
  • asigurând o soluție acceptabilă a costurilor și a capacității sale în viitor;
  • costuri de operare reduse și posibilitatea complexului maxim de servire autonom.

Fiabilitate și scalabilitate

Pentru companiile cu un ciclu de producție continuu pentru a asigura fiabilitatea solutiei - este cea mai importantă calitate a sistemelor de management întreprinderii corporative. Utilizarea cluster în loc de un singur server ca nucleu al unui astfel de sistem permite îmbunătățirea fiabilității sistemelor de aplicații, oferind un server de baze de date în aplicații modul de înaltă disponibilitate. Cu toate acestea, elasticitatea complexului ar trebui să fie prevăzut cu construcția corectă a clusterului: topologia optimă, o duplicare completă a tuturor componentelor, inclusiv îmbinări.

Soluția a fost propusă serverele de la Fujitsu Siemens, principiu de construcție care asigură creșterea productivității substanțial liniar prin creșterea numărului de procesoare, capacitate de memorie și subsistemul de intrare / ieșire. Un cluster este un singur sistem de cele două servere cu setul de procesoare, conexiuni de rețea, adaptoare, conexiuni dedicate și matrice de disc. Fiecare componentă creată astfel încât să se asigure o fiabilitate, scalabilitate și administrare a întregului cluster-ului ca un întreg. Toate sistemele de stocare Fujitsu Siemens livrate pot fi folosite în clustere din cauza redundanței și disponibilitatea tehnologiei „hot swap“. Serverele cluster rulează Reliant Unix 5,45, sprijinind multiprocesor și multifilament de calcul punerea în aplicare a unei rețele și servicii și interfețe la nivel de sistem. O caracteristică a sistemului de operare Unix Reliant este capacitatea sa de a menține serverele practic performanța liniară atunci când întreaga gamă de sarcină.

CALCULAREA resurselor necesare

În cadrul modelului cu trei niveluri, punerea în aplicare a soluțiilor bazate pe SAP R / 3 a fost propus pentru a utiliza un server separat care rulează baza de date Oracle și un server separat pentru a rula R / 3 aplicații. Toate calculele preliminare pentru a determina cerințele pentru server se face în conformitate cu SAP AG Lista de verificare. Aceste calcule includ determinarea sarcinii în unități numite SAPS și evaluate prin următoarea procedură:

Aici SD-dialogsteps / sec - numărul de sesiuni de dialog în secunde pentru utilizatorii modulul SD pe baza cărora calculele sunt efectuate SPUS. Sarcina pe modulele rămase sunt luate în considerare de normalizând le SD cu ajutorul coeficienților; Tthink - intervalul de timp dintre două etape ale dialogului; TRES - timpul de răspuns al sistemului; N - numărul total de utilizatori.

Valoarea SAP SPUS metoda Coglasno a crescut cu 32%, pentru a ține seama de sarcinile de fond și cu 17% pentru a ține cont de situațiile de vârf. Astfel, sarcina totală centrală SPUS este egal Dialog Workload + Actualizare Workload + DB Workload.

La rândul său Actualizare Workload și DB Workload calculat folosind formula:

Datele sunt încărcate la SAPS Tthink = 27, tres = 2 cu datele preliminare privind distribuția / 3 module R utilizatori SAP

Pe baza acestor date, putem calcula cantitatea de memorie necesară și numărul de procesoare de pe serverele din cluster, și având în vedere că baza de date server va fi pus în aplicare și să lucreze pe Actualizare.

Calculul RAM. Cel puțin 512 MB de RAM este necesar pentru a instala partea de server R / 3 și 15-20 asigure funcționarea simultană a utilizatorilor R / 3. Pentru a crește numărul acestora la 100 este suficientă pentru a crește RAM pe serverul de aplicații (RM400 E) până la 600 Mbytes. Memorie pe serverul de baze de date (minimul necesar - 256 MB) va crește ușor - 280 MB la 100 de utilizatori, dat fiind faptul că procesele de fond ale R / 3) vor fi executate pe serverul de baze de date. Deoarece în cadrul ar trebui să plaseze serverul de aplicații și serverul de baze de date pe mașini diferite în cluster, apoi pentru a efectua aceste sarcini pentru 100 de utilizatori vor necesita, respectiv, 600 și 490 MB de memorie modelul cu trei niveluri. Cu toate acestea, din moment ce, în cazul defectării unuia dintre nodurile de pe repornire presupus rămase ca R / 3 și Oracle, pe fiecare server, sa recomandat să se instaleze 1000 MB de RAM (DB server de memorie parte server de R / 3 pentru sarcinile de fundal, plus memoria serverului de aplicații care a început modulele de dialog).

calcul al performanței procesorului. Pentru baza de date server numai un singur procesor MIPS R10000 / 250 MHz pentru fiecare server de baze de date de utilizator 100, atunci când a fost încărcată pe 30-40%. server de aplicații îi lipsesc două dintre aceste procesoare pentru funcționarea normală a utilizatorilor 100 la pornire pentru 40-50% din serverul de aplicații. Toate aceste valori oferă o activitate mare de utilizatori pentru care R / 3 - instrumentul principal, și de încărcare redusă de server - un mediu confortabil pentru utilizatori și cel puțin de două ori înălțimea liberă de performanță atunci când nevoia de a crește sarcina fără a schimba configurația. Context luate în considerare la calcularea sarcinii pe serverul de baze de date (aproximativ 20%).

Calculați descărcare rețea locală și conexiuni de la distanță. Într-o rețea cu tehnologie client-server, există mai multe fluxuri de date, care afectează sarcina de rețea:

  • interacțiune conversațională;
  • Tipărirea locală (Application Server mosor);
  • reacția PC-ul client la computerul din rețea;
  • traficul de rețea suplimentară.

Medie pe un singur pas este transmis interactiv 1.5 - 2.0 Kbytes de date și o operație trecere necesită de obicei 3 - 4 ecrane, astfel încât valoarea medie de funcționare este luată egală cu 16.000 bytes. Pentru a asigura timpul de răspuns necesar, utilizarea rețelei nu poate depăși 50%. Aceasta presupune că rețeaua este încărcată numai dialoguri R / 3. Calcularea dialogurilor de trafic (SAPGUI) servește pentru a efectua următoarea formulă:

în cazul în care: C - sarcină de rețea necesare;
L - utilizarea rețelei (0 Tthink - intervalul de timp dintre două etape ale dialogului;
TRES - timpul de răspuns al sistemului;
N - numărul total de utilizatori.

Astfel, atunci când încărcarea Tthink = 27 și TRES = 2 este:

Din aceste calcule arată că, atunci când sunt utilizate în LAN Ethernet 10 Mbit / s la 50% de utilizare a traficului de rețea SAPGUI este de aproximativ 1% din capacitatea totală a rețelei locale.

RECOMANDAT PENTRU topologie de cluster