8.3 8 serverklynge standardinnstilling

Denne artikkelen inneholder informasjon om 1C-installasjonsprosedyren i klient-serverversjonen.

Installasjon av 1C-plattformen er beskrevet i vår andre artikkel - "1C-administrasjon", i delen "1C-installasjon". Å installere på en server er nesten nøyaktig det samme som å installere på en lokal datamaskin, med bare én forskjell. I serverversjonen, når du velger komponenter som skal installeres, må du velge "1C:Enterprise Server" og "1C:Enterprise Server Administration".

Installer 1C på klientdatamaskiner som tilkoblinger til serveren skal gjøres fra.

Installasjon på klientdatamaskiner er ikke forskjellig fra metoden beskrevet tidligere i artikkelen "1C Administration".

Lag en infobase i SQL.

Å lage en informasjonsbase i SQL er også veldig likt å lage en database i filversjonen. Forskjellen er at du må velge "På 1C:Enterprise-serveren" når du velger informasjonsbaseplasseringstype.

I "Server cluster"-elementet, spesifiser navnet (eller enda bedre, IP-adressen) til serveren du installerte SQL på.

I "Infobasenavn"-delen angir du et hvilket som helst navn du vil gi til databasen.

DBMS-type – SQL.

Databasebrukeren og passordet hans er den samme superbrukeren nevnt ovenfor under installasjonen av MS SQL.

La datoforskyvningen være standard.

Det er nødvendig å merke av for "Opprett en database hvis den ikke eksisterer" og klikk "Neste".

Nå har databasen blitt opprettet på SQL-serveren og lagt til listen over tilgjengelige databaser. Under på bildet kan du se resultatet av arbeidet som er utført.

Det er verdt å merke seg at den opprettede databasen fortsatt er tom. Dette er et rammeverk, en plass tildelt i SQL for informasjonsbasen din. For å laste inn databasen din i dette rammeverket, må du bruke verktøyene Last opp/last informasjonsgrunnlag. Opplastings-/nedlastingsprosedyren er også beskrevet i vår andre artikkel "1C-administrasjon".

For å bringe systemet til en ideell tilstand i fremtiden, vil det være nødvendig å konfigurere en "vedlikeholdsplan" for den opprettede databasen. En vedlikeholdsplan er et sett med prosedyrer som SQL vil utføre regelmessig på en gitt tidsplan. For eksempel vil den regelmessig ta sikkerhetskopier og slette midlertidige filer. Arbeid med SQL er utenfor rammen av denne artikkelen og vil bli beskrevet i en av de følgende.

Serverklynge 1C:Enterprise 8 (1C:Enterprise 8 Server Cluster)

1C:Enterprise 8-serverklyngen er hovedkomponenten i plattformen, som sikrer interaksjon mellom databasestyringssystemet og brukeren i tilfelle klient-server-drift. Klyngen gjør det mulig å organisere uavbrutt, feiltolerant, konkurransedyktig arbeid for et betydelig antall brukere med store informasjonsdatabaser.

En 1C:Enterprise 8 serverklynge er et logisk konsept som betegner et sett med prosesser som betjener det samme settet med informasjonsdatabaser.

Følgende funksjoner til en serverklynge kan identifiseres som de viktigste:

  • muligheten til å fungere både på flere og på en datamaskin (fungerende servere);
  • hver arbeidsserver kan støtte funksjonen til én eller flere arbeidsprosesser som betjener klientforbindelser innenfor grensene til denne klyngen;
  • inkludering av nye kunder i klyngens arbeidsprosesser skjer basert på en langsiktig analyse av belastningsstatistikk for arbeidsprosesser;
  • interaksjon av alle klyngeprosesser med hverandre, med klientapplikasjoner og databaseserveren utføres via TCP/IP-protokollen;
  • klyngeprosesser kjører, kan enten være en tjeneste eller en applikasjon

Klient-server-alternativ. Arbeidsordning

I dette alternativet samhandler en klientapplikasjon med serveren. Serverklyngen samhandler på sin side med databaseserveren.

Rollen som den sentrale serveren til klyngen spilles av en av datamaskinene som er en del av serverklyngen. I tillegg til å betjene klientforbindelser, administrerer den sentrale serveren også driften av hele klyngen og lagrer registret til denne klyngen.

Klyngen adresseres for klientforbindelser med navnet på den sentrale serveren og eventuelt nettverksportnummeret. Hvis en standard nettverksport brukes, trenger du bare å angi navnet på den sentrale serveren for å koble til.

Under etablering av tilkobling kontakter klientapplikasjonen den sentrale serveren til klyngen. Basert på analysen av belastningsstatistikk for arbeidsprosesser, videresender den sentrale serveren klientapplikasjonen til den nødvendige arbeidsprosessen, som skal betjene den. Denne prosessen kan aktiveres på hvilken som helst fungerende server i klyngen, spesielt på den sentrale serveren.

Tilkoblingsvedlikehold og brukerautentisering støttes av denne arbeidsflyten til klienten slutter å jobbe med en spesifikk infobase.

Serverklynge

En grunnleggende serverklynge kan være en enkelt datamaskin og inneholde bare én arbeidsprosess.

I figuren kan du observere alle elementene som på en eller annen måte deltar i driften av serverklyngen. Dette er følgende elementer:

  • serverklyngeprosesser:
    o ragent.exe;
    o rmngr.exe;
    o rphost.exe;
  • datalagring:
    o liste over klynger;
    o klyngeregister.

Ragent.exe-prosessen, kalt serveragenten, sikrer at datamaskinen fungerer som en del av en klynge. Derfor bør datamaskinen som ragent.exe-prosessen kjører på, kalles en produksjonsserver. Spesielt er en av de funksjonelle forpliktelsene til ragent.exe å opprettholde et register over klynger som er plassert på en bestemt fungerende server.

Verken klyngeregisteret eller serveragenten er en integrert del av serverklyngen, men gjør det bare mulig for serveren og klyngene på den å fungere.

Selve serverklyngen består av følgende elementer:

  • en eller flere rmngr.exe-prosesser
  • klyngeregister
  • en eller flere rphost.exe-prosesser.

Cluster manager (prosess rmngr.exe). Det tjener til å kontrollere funksjonen til hele klyngen. En klynge kan inneholde flere rmngr.exe-prosesser, hvorav en alltid vil være hovedansvarlig for denne klyngen, og de gjenværende prosessene vil være ytterligere ledere. Den sentrale serveren til klyngen skal kalles arbeidsserveren som hovedklyngeadministratoren opererer på og som inneholder klyngelisten. Vedlikehold av klyngeregisteret er en av funksjonene til hovedklyngelederen.

Arbeidsprosess (rphost.exe-prosess). Det er han som direkte betjener klientapplikasjoner og samhandler med databaseserveren. Under denne prosessen kan noen konfigurasjonsprosedyrer for servermoduler bli utført.

Skalerbarhet av 1C versjon 8.3

Skalerbarheten til en serverklynge oppnås på følgende måter:

  • øke antall ledere i klyngen og fordelingen av tjenester mellom dem
  • øke antall arbeidsprosesser som opererer på en gitt arbeiderserver
  • øke antallet fungerende servere som utgjør klyngen.

Bruker flere ledere samtidig.

Funksjonene som utføres av klyngelederen er delt inn i flere tjenester. Disse tjenestene kan tilordnes ulike klyngeledere. Dette gjør det mulig å fordele belastningen jevnt over flere prosesser.

Noen tjenester kan imidlertid bare brukes av hovedklyngelederen:

  • klyngekonfigurasjonstjeneste
  • feilsøke vareadministrasjonstjeneste
  • klyngelåstjeneste.

For andre tjenester kan vilkårlige klyngeledere tildeles:

  • loggtjeneste
  • objektblokkeringstjeneste
  • jobbtjeneste
  • fulltekst søketjeneste
  • øktdatatjeneste
  • nummereringstjeneste
  • tjeneste for egendefinerte innstillinger
  • tidstjeneste
  • transaksjonsblokkeringstjeneste.

Bruk av flere arbeidsflyter samtidig.

På den ene siden gjør bruk av flere arbeidsprosesser det mulig å redusere belastningen på hver enkelt arbeidsprosess. På den annen side fører bruken av flere arbeidsprosesser til mer effektiv bruk av maskinvareressursene til produksjonsserveren. Dessuten øker prosedyren for å starte flere arbeidsprosesser påliteligheten til serveren, da den isolerer grupper av klienter som jobber med forskjellige informasjonsbaser. En arbeidsprosess i en klynge som lar flere arbeidsprosesser kjøre, kan startes på nytt automatisk innen et tidsintervall spesifisert av klyngeadministratoren.

Muligheten til å bruke flere arbeidsprosesser (øke antall klientforbindelser) uten å øke belastningen på en spesifikk arbeidsprosess resulterer i en oppover endring i antall arbeiderservere som er en del av klyngen.

Feiltoleranse for 1C versjon 8.3

Motstandsdyktighet mot klyngefeil sikres på tre måter:

  • redundans av selve klyngen
  • reservasjon av arbeidsprosesser
  • motstand mot avbrudd i kommunikasjonskanalen.

Sikkerhetskopiere en 1C-klynge versjon 8.3

Flere klynger er slått sammen til en redundansgruppe. Klynger som er i en slik gruppe synkroniseres automatisk.

Hvis den aktive klyngen mislykkes, erstattes den av den neste arbeidsklyngen i gruppen. Når den mislykkede klyngen er gjenopprettet, blir den aktiv etter datasynkronisering.

Sikkerhetskopiering av 1C arbeidsprosesser versjon 8.3

For hver av arbeidsflytene er det mulig å spesifisere alternativer for bruken:

  • bruk
  • ikke bruk
  • bruke som backup.

Hvis en prosess krasjer, begynner klyngen å bruke en for øyeblikket inaktiv sikkerhetskopieringsprosess i stedet. I dette tilfellet blir belastningen på den automatisk omfordelt.

Motstand av 1C versjon 8.3 mot avbrudd i kommunikasjonskanalen

Siden hver bruker får sin egen kommunikasjonsøkt, lagrer klyngen data om brukerne som koblet til og hvilke handlinger de utførte.

Hvis den fysiske tilkoblingen forsvinner, vil klyngen være i en tilstand av å vente på en tilkobling med denne brukeren. I de fleste tilfeller, etter at tilkoblingen er gjenopprettet, vil brukeren kunne fortsette å jobbe nøyaktig fra punktet der tilkoblingen ble brutt. Det er ikke nødvendig å koble til infobasen på nytt.

Økter i 1C versjon 8.3

En økt gjør det mulig å bestemme den aktive brukeren av en spesifikk infobase og bestemme kontrollflyten fra denne klienten. Følgende typer økter skilles ut:

  • Tynn klient, nettklient, tykk klient - disse øktene skjer når de tilsvarende klientene får tilgang til infobasen
  • Tilkobling av typen "Konfigurator" - det skjer når du får tilgang til konfiguratorinfobasen
  • COM-tilkobling – dannet når du bruker en ekstern tilkobling for å få tilgang til en infobase
  • WS-tilkobling – oppstår ved tilgang til webserverens infobase som et resultat av tilgang til en webtjeneste publisert på webserveren
  • Bakgrunnsjobb – opprettet når en klyngearbeiderprosess får tilgang til infobasen. Denne økten brukes til å utføre bakgrunnsjobbprosedyrekoden,
    Klyngekonsoll – opprettet når klient-serveradministrasjonsverktøyet får tilgang til en arbeidsprosess
  • COM-administrator – oppstår når en arbeidsprosess åpnes ved hjelp av en ekstern tilkobling.
  • Arbeid under forskjellige operativsystemer

Alle serverklyngeprosesser kan fungere under både Linux-operativsystemet og Windows-operativsystemet. Dette oppnås ved at klyngeinteraksjon skjer under kontroll av TCP/IP-protokollen. Klyngen kan også inkludere fungerende servere som kjører noen av disse operativsystemene.

Server Cluster Administration Utility 8.3

Systempakken inkluderer et verktøy for å administrere klient-server-alternativet. Dette verktøyet gjør det mulig å endre sammensetningen av klyngen, administrere informasjonsbaser og raskt analysere transaksjonslåser.

Flere arbeidsprosesser på én server gjør det mulig å effektivt bruke mengden RAM og prosessorressurser til å utføre forespørsler, samt koble en klientøkt til en annen arbeidsprosess hvis den nåværende "krasjer".
Server Agent (ragent) programmet er ansvarlig for å forstå hva som kjører på en bestemt server. Å stoppe serveragenten vil gjøre serveren utilgjengelig for bruk av klyngen. Agenten lagrer informasjonen sin i filen srvribrg.lst.

Informasjon om arbeidsdatabaser og involverte arbeidsprosesser eies av "Server Manager" (rmngr). Den lagrer denne informasjonen i filen 1CV8Reg.lst. Å stoppe serveradministratoren kan føre til omstart av klientapplikasjoner hvis manageren starter på nytt, eller til fullstendig stopp av fungerende servere til hele klyngen.

1C: Bedriften tillater muligheten for å lage flere uavhengige klynger på én server. Hver av dem identifiseres på nettverket av en unik "IP-port" og et unikt nummer i tjenestefiler. Den første klyngen mottar port 1541 som standard.

Enterprise Servers snap-in er laget for å administrere klyngen.
Du kan koble til servere med servernavn eller IP-adresse.

Serveragent

Serveragenten "vet" om alle klyngene som kjører på serveren. Denne informasjonen er lagret i filen srvribrg.lst med en liste over klynger og listeadministratorer. Hovedporten til agenten er 1540. På hver fungerende server kan bare én agent startes, som betjener alle mulige klynger på denne serveren.

La oss se nærmere på klyngeegenskapene

Restartintervall

Denne parameteren starter 1C-serverarbeidsprosessene på nytt i henhold til den angitte verdien i sekunder. Vanligvis brukes parameteren på applikasjonsservere som har et 32-bitssystem, siden minnekapasiteten der er begrenset til ~ 3,7 GB hvis operativsystemet er 64-bit og applikasjonsserveren er 32-bit. Hvis operativsystemet bruker en 32-bits arkitektur, er det totale minneforbruket til arbeidsprosessen ~ 1,7 GB. Og brukere kan ofte motta en feilmelding som "Utilstrekkelig minne på 1C Enterprise-serveren." Den enkleste måten å unngå denne feilen på er å starte arbeidsprosessene på nytt, for eksempel 86400 sekunder (1 dag). Når du endrer parameteren, starter tidstellingen fra starten av 1C-applikasjonsservertjenesten.

Tillatt minnestørrelse

Starter arbeidsprosesser på nytt når en viss terskel for minne som er okkupert av arbeidsprosessen i kilobyte er nådd.

Intervall for overskridelse av den tillatte mengden minne

Dette betyr at hvis minnet spesifisert i parameteren "tillatt minnemengde" overskrides innen et spesifisert antall sekunder, vil 1C-serveren bestemme seg for å starte arbeidsflyten på nytt.

Tillatt avvik i antall serverfeil

Det beregnes som følger. Vi har serveranrop som kan sees i teknologiloggen ved «CALL»-hendelsen, og det er også ulike unntakssituasjoner som kan sees i teknologiloggen ved «EXCP»-hendelsen. Plattformen beregner forholdet mellom disse hendelsene. Det antas at disse hendelsene skal være omtrent like. Hvis dette forholdet i en arbeidsprosess overstiger forholdet mellom disse hendelsene i andre arbeidsprosesser med et betydelig beløp, anses en slik arbeidsprosess som problematisk. Bare denne verdien er satt i denne parameteren. Anbefalt verdi er 50.

Tvinge avslutning av problematiske prosesser

Hvis vi aktiverer denne parameteren, vil problematiske prosesser bli avsluttet i henhold til parameteren "tillatt avvik i antall serverfeil". Hvis parameteren er deaktivert, viser plattformen prosesslogghendelsen "ATTN", som indikerer den problematiske prosessen.

Stopp deaktiverte prosesser etter

Hvis en av parameterne "omstartintervall" eller "tillatt minnestørrelse" utløses, kan den "falle av" når arbeidsprosessen startes på nytt. Hvis klienten ikke får tilgang til serveren under omstarten (er inaktiv), vil den bytte til den nye arbeidsprosessen neste gang den får tilgang til den. Hvis klienten kontakter serveren på tidspunktet for omstart av arbeidsflyten, vil den i dette tilfellet motta en feilmelding og avslutte arbeidet. For å forhindre at dette skjer, må du angi verdien for denne parameteren i sekunder. Vanligvis er 120 sekunder nok. I løpet av denne tiden vil arbeidsflyten ha tid til å behandle gjeldende kundeforespørsler og overføre dem til en ny arbeidsflyt. De aktive klientene som prosessen ikke rakk å behandle blir avsluttet og klientene kan få en feilmelding.

Feiltoleransenivå

Denne innstillingen lever av seg selv, uavhengig av antall sentrale servere. Feiltoleransenivået kan ha hvilken som helst verdi. For eksempel, elastisitetsnivå = 1, deretter dobles hver brukerøkt. Hvis feiltoleransenivået = 2, multipliseres hver økt med 3. Belastningen på serveren øker også. Når du endrer feiltoleransenivået, hvis vi har en sentral server, replikeres den til hver sentral server: "klyngeregister", "klyngelåsetjeneste". Det er også replikering av tjenester som "øktdatatjeneste", "online tidsstempeltjeneste", "objektblokkeringstjeneste", "lisensieringstjeneste", "nummertjeneste" til andre servere. Blant dem er den tyngste "øktdatatjenesten".

Last delingsmodus

Når det gjelder ytelse. Når en klienttilkobling kobles til, kobles den til den serveren som har en arbeidsprosess med mer tilgjengelig ytelse. Den tilgjengelige ytelsen angis i arbeidsflytegenskapene:


Den tilgjengelige ytelsen på 1C-nivået beregnes som følger: et referanseserveranrop foretas til alle arbeidsprosesser en gang hvert 10. minutt og tidspunktet for dette anropet måles. Det resulterende tallet deles på 10 000 (ti tusen) og applikasjonsservermekanismene beregner referansetiden. I tilfelle at produktiviteten til en arbeidsprosess har blitt 25 % mindre enn de andres, begynner koblinger fra denne arbeidsprosessen å gå til andre arbeidsprosesser inntil alle koblinger er borte.

Minneprioritet. Brukertilkoblinger vil bli gjort til en produksjonsserver som har mer tilgjengelig minne.

Cluster Manager

Klyngeleder er ansvarlig for driften av klyngen. Hver klynge har sin egen Manager. Lederen lagrer informasjon om klyngen i filen 1CV8Reg.lst (klyngeregister). Hver Cluster Manager har også sin egen port på Work Server. For den første klyngen er standard Manager-port 1541. Det er denne porten som vises i snapin-modulen 1C Servers: Enterprise i Clusters-grenen, som identifiserer klyngen.
Lederen mottar forespørsler fra klientdelen av 1C: Enterprise og bestemmer hvilken arbeidsflyt denne tjenesteforespørselen skal gis til.

Lederen bruker tjenesteporten til å samhandle med arbeidsprosesser.

Arbeidsprosessen

Arbeidsprosessen er ansvarlig for å "arbeide med kunder." Det kan være flere arbeidsprosesser i 1C: Enterprise 8-klyngen. Antall arbeidsprosesser opprettes ikke manuelt, men beregnes ut fra beskrivelser av oppgavekrav for feiltoleranse og pålitelighet. Serveradministratoren bestemmer hvilken arbeidsprosess som skal betjene klientforbindelsen. For klientforbindelser er arbeidsprosesser som standard tildelt en rekke IP-porter 1560 – 1591. I tillegg er hver arbeidsprosess tildelt en tjenesteport for kommunikasjon med klyngelederen.

De fungerende serverinnstillingene, i henhold til 1C-dokumentasjonen, kan bare endres i CORP-versjonen av 1C-applikasjonsserveren. Faktisk fungerer innstillingene i både CORP- og PROF-versjonene. Hvis disse innstillingene brukes i PROF-versjonen, vil dette være et brudd på lisensavtalen.

Maksimalt arbeidsflytminne

Denne parameteren i seg selv begrenser ikke noe. Den fungerer sammen med parameteren "sikkert minneforbruk per samtale". La oss forestille oss at alle arbeidsprosessene våre totalt har nådd omtrentlig minneforbruk for den angitte verdien av denne parameteren. Og nå ønsker en viss bruker å foreta et bestemt serveranrop som ønsker å forbruke en stor mengde minne. Så snart serveranropet overskrider mengden minne som er spesifisert i denne parameteren med mengden minne i parameteren "sikkert minneforbruk for ett anrop", vil denne spesielle brukeren motta en feilmelding av formen: "sikkert minneforbruk for én klient -serveranrop er overskredet." Dette er nødvendig slik at én bruker ikke kan overvelde den fungerende serveren. Verdien av parameter 0 er lik 80 % av minnet installert på 1C-serveren.

Sikkert minneforbruk per samtale

En verdi på 0 (standard) er 5 % av verdien for maksimal arbeidsflytminne. Verdien kan være -1. Dette betyr at ethvert klient-tjenerkall som overskrider den angitte verdien av parameteren "maksimal arbeiderminnestørrelse".

Mengden arbeidsprosessminne opp til som serveren anses som produktiv

Betyr at hvis satt til en verdi og arbeidsprosesser har tatt opp mengden minne spesifisert i denne parameteren, vil serveren fortsette å kjøre, men vil ikke godta nye tilkoblinger før minnet er frigjort.

Antall informasjonssikkerhet per prosess

Det kan være en nedgang i ytelsen når det er mange infobaser og én arbeidsflyt. Derfor er det med denne parameteren mulig å redusere antall databaser per prosess. Hvis du setter verdien til 1 (i de fleste tilfeller fungerer dette ganske optimalt), vil det opprettes en ny arbeidsprosess (rphost) for hver infobase.

Antall tilkoblinger per prosess

Samme som parameteren ovenfor, men avhenger av antall tilkoblinger per prosess. En verdi på 0 vil bety at det kun vil være én arbeidsprosess på hver arbeiderserver.

Leder for hver tjeneste

Hver sentral arbeiderserver har en hovedklyngeleder med visse tjenester:


De utføres av én tjeneste "rmngr". La oss forestille oss at denne tjenesten begynner å bruke mye minne eller kaste bort CPU-ressurser. Det er vanligvis noen typiske mistenkte. Men plutselig er du i en "blindvei" og kan ikke forstå nøyaktig hva som laster tjenesten, du kan krysse av for "administrator for hver tjeneste", tjenesten vil bli delt inn i 21 prosesser (dette er antallet tjenester i hovedsak klyngeleder). Og følgelig, ved å bruke PID-en til prosessen, vil det være mulig å beregne hvilken tjeneste som laster systemet.

Sentral server

Dette er serveren som lagrer klyngeregisteret i filen 1CV8Clst.lst. Filen lagrer en liste over databaser, en liste over klyngeadministratorer, en liste over krav til funksjonalitetstildeling, en liste over sikkerhetsprofiler og generelt alle klyngeinnstillinger. Denne filen er kun til stede der det er merket av for "sentral server". Det kan være flere sentrale servere. Også på de sentrale serverne er det tjenester som "cluster blocking service", "cluster configuration service". Så lenge minst én sentral server er operativ, fungerer klyngen. Når den siste sentrale serveren svikter, blir klyngen ubrukelig uavhengig av feiltoleranseinnstillinger.

Krav til funksjonalitetsoppdrag

1C Enterprise 8.3-serverklyngen gir et visst sett med funksjonalitet (kalt kravobjekter), fordelingen av disse mellom fungerende servere i klyngen kan kontrolleres. Du kan for eksempel angi at alle bakgrunnsjobber i klyngen skal kjøres på en valgt arbeiderserver. For å plassere en tilkobling eller klyngetjeneste på en produksjonsserver, må du opprette et krav til funksjonalitetstildeling for den valgte produksjonsserveren. Dette kravet bestemmer evnen eller umuligheten til en bestemt server til å utføre en bestemt jobb. La oss se nærmere på hva et krav til funksjonalitetstildeling er.

Migrere brukertilkoblinger

La oss si at vi vil at brukertilkoblinger skal fungere på arbeiderserver #1, men hvis den serveren går ned, vil vi at de skal mislykkes til en annen arbeiderserver #2

For å gjøre dette må vi opprette et funksjonalitetstildelingskrav på server nr. 1:


På server nr. 2, sett de samme innstillingene, men endre prioritet:


Viktigheten av prioritering implementeres omvendt. Det vil si at prioritet 1 er høyere enn prioritet 2.

Fjern produksjonsserveren fra klyngen

Vi kan ganske enkelt fjerne den fungerende serveren fra klyngen ved å slette den fra listen, men i dette tilfellet vil alle brukere bli "kastet ut" fra systemet. For å gjøre uttaket mer smertefritt kan du gjøre følgende:

Opprett et krav til funksjonalitetstildeling med følgende innstillinger:


Denne innstillingen betyr at det ikke blir noen nye tilkoblinger til denne produksjonsserveren. De brukerne som jobbet vil fortsette å jobbe, men vil gradvis flytte til andre fungerende servere.

Lisenstjeneste

Flytt lisensieringstjenesten til en separat server. Dette er bra fordi programvarelisenser kan knyttes til en bestemt datamaskin. La oss lage et krav til funksjonalitetstildeling med følgende innstillinger:


Bakgrunnsjobber

Med utgivelsen av plattform 8.3.7 ble bakgrunnsjobber delt inn i 2 grupper:

1. Bakgrunnsjobber kalt fra konfigurasjonskode

2. Rutinemessige oppgaver

Derfor kreves det flere innstillinger for å tildele funksjonalitet:



1. For å få bakgrunnsjobber til å kjøre raskt, må du legge til øktdata for bakgrunnsjobber og planlagte jobber



Etter å ha opprettet de nødvendige kravene for å tildele funksjonalitet, må du bruke dem:


Delvis – applikasjon som ikke vil forstyrre brukeropplevelsen

Full – en applikasjon som kan forstyrre brukeropplevelsen.

I praksis har jeg aldri vært borti en situasjon der det, når det ble brukt fullt ut, forstyrret brukeropplevelsen eller noe sånt. Men alt er mulig, husk. Etter påføring er det ikke nødvendig å starte 1C-applikasjonsservertjenesten på nytt.

Du kan alltid kontakte 1C-optimaliseringsspesialister; vår praktiske erfaring vil spare deg for tid.

I tillegg til filversjonen kan 1C:Enterprise-systemet fungere med informasjonsbaser i en klient-serverversjon. I sistnevnte tilfelle forstås en arkitektur som består av flere programvarelag, skjematisk avbildet i figuren nedenfor.

  • Klientapplikasjoner, tynnklienter og webklienter- dette er "1C:Enterprise" i forskjellige lanseringsmoduser som sluttbrukeren jobber med. For klientapplikasjoner og tynne klienter er en nettleser tilstrekkelig på brukernes datamaskiner (eller på), for en nettklient.
  • Serverklynge "1C:Enterprise" er en samling arbeidsprosesser som kjører på en eller flere datamaskiner og en liste over informasjonsbaser som er plassert i denne klyngen. I serverklyngen utføres alt arbeidet med applikasjonsobjekter, forberedelser for visning av skjemaer (lese infobaseobjekter, fylle ut skjemadata, ordne elementer osv.) og kommandogrensesnittet, generere rapporter og kjøre bakgrunnsjobber. Klienter viser kun informasjon utarbeidet i serverklyngen. I tillegg lagres tjenestefiler på 1C:Enterprise cluster server, samt en infobase registreringslogg.
  • Database server— på databaseserveren foregår direkte lagring og arbeid med data, levert av ett av følgende databasestyringssystemer (DBMS) støttet av 1C:Enterprise-systemet:
    • Microsoft SQL Server fra Microsoft SQL Server 2000 og høyere;
    • PostgrageSQL siden versjon 8.1;
    • IBM DB2 siden versjon 9.1;
    • Oracle Database siden versjon 10g utgivelse 2.
  • Internett server kreves bare for nettklienter og et av tynnklientalternativene. Gir interaksjon av disse typene tilkoblinger med en klynge med 1C:Enterprise-servere.

Det er også verdt å merke seg at hvert programvarelag ikke nødvendigvis trenger å være plassert på en egen fysisk datamaskin. En serverklynge kan være plassert på samme datamaskin med en databaseserver, webserver osv. Følgende arbeidsstruktur finnes for eksempel ofte i små organisasjoner:

I denne artikkelen vil jeg beskrive installasjonen av 1C:Enterprise-serverversjon 8.3.4.389 (for andre versjoner av 1C:Enterprise-plattformen 8.1, 8.2 og 8.3 er trinnene like) på én datamaskin som kjører Windows Server 2008 (R2) eller Windows Server 2012 (R2). Microsoft SQL Server 2008 (R2) eller Microsoft SQL Server 2012 vil bli betraktet som en DBMS. For dette trenger vi:

  1. En datamaskin som oppfyller systemkravene for å installere 1C:Enterprise-serveren og med OS installert på denne datamaskinen eller .
  2. En datamaskin for en databaseserver, som også kjører et OS eller (kan være datamaskinen fra trinn 1).
  3. Lokale administratorrettigheter på begge datamaskiner.
  4. Distribusjonssett for installasjon av 1C:Enterprise-serveren 8.
  5. Programvarelisens eller HASP4 Net-beskyttelsesnøkkel for 1C:Enterprise-serveren.
  6. Distribusjonssett for installasjon av Microsoft SQL Server 2008 (R2) eller Microsoft SQL Server 2012.

2. Installasjon av MS SQL Server DBMS

Vi installerer MS SQL Server DBMS på datamaskinen som fungerer som databaseserver. For å betjene 1C:Enterprise-systemet er det nok å installere følgende komponenter:

  • Databasemotortjenester
  • Administrasjonsverktøy – grunnleggende
    • Administrasjonsverktøy – komplett.

Velg sorteringsalternativer " Kyrillisk_General_CI_AS" Detaljer om installasjon av systemer

3. Konfigurere Windows-brannmuren for DBMS-drift

Hvis databaseserveren og 1C:Enterprise-klyngeserveren er plassert på forskjellige fysiske datamaskiner, må du konfigurere Windows-brannmuren på databaseserveren slik at 1C:Enterprise-serveren kan fungere med DBMS, nemlig åpne innkommende tilkoblinger på porten 1433 (for standard SQL Server-forekomst).

  • Jeg skrev i detalj om å sette opp Windows-brannmur for Microsoft SQL Server 2008 (R2) / 2012.

4. Legge til en bruker til MS SQL Server

Deretter vil vi legge til en egen bruker til MS SQL Server, som 1C:Enterprise-serverdatabasene kobles til. Denne brukeren vil også være eieren av disse databasene. Brukeren som skal legges til må være autorisert på serveren med et passord og ha følgende sett med roller: dbcreator, prosessadministrator, offentlig. Detaljer om å legge til en bruker i

  • Microsoft SQL Server 2008 (R2) skrev jeg.
  • Jeg skrev Microsoft SQL Server 2012.

5. Installasjon av 1C:Enterprise-serveren

La oss nå gå videre til å installere 1C:Enterprise-serverfilene og starte den tilsvarende tjenesten. Installasjon krever et distribusjonssett av teknologiplattformen 1C:Enterprise. Fra listen over leverte distribusjoner er følgende egnet:

  • 1C:Enterprise teknologiplattform for Windows - tillater installasjon av en 32-bit 1C:Enterprise server
  • 1C:Enterprise-server (64-bit) for Windows - tillater installasjon av både 32-bit og 64-bit 1C:Enterprise-servere

(Det finnes også en utvidet versjon av KORP-serveren 1C:Enterprise 8.3, detaljer finnes på 1C-nettstedet)

Åpne katalogen med 1C:Enterprise-serverinstallasjonsfilene og kjør filen setup.exe.

Installasjonsassistenten for 1C:Enterprise-systemet starter. På den første siden klikker du " Lengre».

På neste side må du velge komponentene som skal installeres; vi trenger følgende komponenter:

  • Server 1C: Enterprise— 1C:Enterprise serverkomponenter
  • Serveradministrasjon 1C:Enterprise 8— tilleggskomponenter for å administrere en klynge med 1C:Enterprise-servere

De resterende komponentene (listen over komponenter kan avhenge av den spesifikke distribusjonen), avhengig av behovet, kan også installeres på denne datamaskinen. Etter å ha gjort ditt valg, klikk " Lengre».

Velg grensesnittspråket som skal brukes som standard og klikk " Lengre».

Hvis 1C:Enterprise-serveren er installert som en Windows-tjeneste (og i de fleste tilfeller bør den installeres som sådan), anbefaler jeg umiddelbart å opprette en egen bruker som den opprettede tjenesten vil bli lansert under. For dette

  • La flagget stå "på" Installer 1C:Enterprise-server som en Windows-tjeneste (anbefalt)»;
  • Vi flytter den tilsvarende bryteren til " Opprett bruker USR1CV8».
  • Skriv inn passordet for brukeren som opprettes to ganger. Som standard må passordet være i samsvar med Windows-passordpolicyen. Du kan lese mer om dette:
    • For Microsoft Windows Server 2008 (R2) - ;
    • For Microsoft Windows Server 2012 - .

Du kan også velge en eksisterende bruker for å kjøre 1C:Enterprise-serveren. I dette tilfellet må den valgte brukeren ha følgende rettigheter:

  • Logg på som en tjeneste
  • Logg på som en batchjobb
  • Ytelsesloggbrukere.

Brukeren må også gis de nødvendige rettighetene til katalogen med servertjenestefiler (som standard C:\Program Files\1cv8\srvinfo for 64-bit og C:\Program Files (x86)\1cv8\srvinfo for en 32-bits server).

Automatisk opprettet bruker USR1CV8 vil ha alle de ovennevnte rettighetene.

Etter å ha fylt inn de riktige parametrene, klikk " Lengre».

Og til slutt, klikk " Installere» for å starte installasjonen. Dette vil kopiere filene til de valgte komponentene, opprette konfigurasjonsfiler, registrere programkomponenter, lage snarveier og også starte 1C:Enterprise-servertjenesten.

Når installasjonen er fullført, vil assistenten be deg installere beskyttelsesdriveren - HASP Device Driver. Hvis du bruker en programvarelisens for 1C:Enterprise-serveren, er det ikke nødvendig å installere driveren. La eller fjern flagget " Installer beskyttelsesdriver" og klikk " Lengre».

Ofte kjører andre tjenester på maskinen sammen med 1C:Enterprise-serveren - en terminalserver, SQL-server, etc. Og på et tidspunkt spiser 1C:Enterprise-serveren, eller rettere sagt rphost-arbeiderprosessen, opp mer minne enn planlagt eller alt minnet. Noe som fører til en nedgang i andre tjenester og zombier på serveren. For å unngå slike situasjoner må du konfigurere automatisk omstart av 1C:Enterprise-serverarbeidsflyter

Løsning

1. Åpne administrasjonskonsollen til 1C Enterprise-servere;
2. Utvid det sentrale servertreet til klynger og velg klyngen som interesserer oss. I eksemplet er det bare én klynge;
3. Åpne egenskapene til den valgte klyngen og se følgende skjema

Egenskaper til 1C:Enterprise 8.3-serverklyngen

La oss se på eksemplet vist på bildet:

Restartintervall— tid som rphost-prosessen vil bli tvunget til å starte på nytt. Før prosessen avsluttes, startes en ny rphost-prosess, som alle tilkoblinger overføres til, og først da vil den gamle prosessen avsluttes. Dette vil ikke påvirke brukerens opplevelse på noen måte. Intervallet er angitt i sekunder, i eksemplet er 24 timer angitt.

Tillatt minnestørrelse— hvor mye minne arbeidsflyten kan fungere i uten problemer. Volumet er angitt i kilobyte, i eksemplet er verdien 20 gigabyte (faktisk er tallet for stort, og du må starte fra det spesifikke systemet, men gjennomsnittstallet er 4 GB). Så snart minnet som er opptatt av arbeidsprosessen overskrider den angitte verdien, begynner nedtellingen.

Intervall for overskridelse av den tillatte mengden minne— etter at tidtakeren som ble startet etter å ha overskredet den tillatte mengden minne, teller ned den angitte tiden, vil en ny arbeidsprosess bli lansert, som alle tilkoblinger overføres til, den gamle prosessen er merket som deaktivert. Intervallet er spesifisert i sekunder, i eksemplet er 30 sekunder angitt.

Stopp deaktiverte prosesser etter— tiden etter at arbeidsflyten merket som deaktivert vil bli stoppet; hvis verdien er 0, vil ikke prosessen fullføres. Intervallet er spesifisert i sekunder, i eksemplet er 60 sekunder angitt.

Etter å ha brukt innstillingene, trenger du ikke å starte servertjenesten på nytt, de brukes dynamisk.

Total

Slik setter vi opp automatisk omstart av 1C:Enterprise-serverarbeidsprosesser og får et mer stabilt system; hvis det oppstår en minnelekkasje, vil arbeidet til en spesifikk sesjon bli avsluttet.

I noen situasjoner kan du også leke med innstillingene og forhindre en mulig serverkrasj hvis du gjør feil.