8.3 8 սերվերի կլաստերի լռելյայն կարգավորում

Այս հոդվածը պարունակում է տեղեկատվություն 1C-ի տեղադրման ընթացակարգի մասին հաճախորդ-սերվեր տարբերակում:

1C պլատֆորմի տեղադրումը նկարագրված է մեր մյուս հոդվածում՝ «1C ադմինիստրացիա», «1C տեղադրում» բաժնում: Սերվերի վրա տեղադրումը գրեթե նույնն է, ինչ տեղային համակարգչում տեղադրելը, միայն մեկ տարբերությամբ. Սերվերի տարբերակում տեղադրման համար բաղադրիչներ ընտրելիս պետք է ընտրել «1C:Enterprise Server» և «1C:Enterprise Server Administration»:

Տեղադրեք 1C-ը հաճախորդի համակարգիչների վրա, որոնցից կապեր կկատարվեն սերվերի հետ:

Հաճախորդի համակարգիչների վրա տեղադրումը ոչնչով չի տարբերվում «1C Administration» հոդվածում ավելի վաղ նկարագրված մեթոդից:

Ստեղծեք տեղեկատվական բազա SQL-ում:

SQL-ում տեղեկատվական բազա ստեղծելը նույնպես շատ նման է ֆայլի տարբերակում տվյալների բազա ստեղծելուն: Տարբերությունն այն է, որ տեղեկատվական բազայի գտնվելու վայրի տեսակը ընտրելու փուլում պետք է ընտրել «1C:Enterprise սերվերի վրա»:

«Սերվերների կլաստեր» կետում նշեք սերվերի անունը (կամ ավելի լավ՝ IP հասցեն), որի վրա տեղադրել եք SQL:

«Infobase name» բաժնում նշեք ցանկացած անուն, որը ցանկանում եք տալ տվյալների բազային:

DBMS տեսակը – SQL:

Տվյալների բազայի օգտատերը և նրա գաղտնաբառը վերը նշված նույն գերօգտագործողն են MS SQL-ի տեղադրման ժամանակ:

Թողնել ամսաթվի շեղումը որպես լռելյայն:

Անհրաժեշտ է ստուգել «Ստեղծել տվյալների բազա, եթե այն գոյություն չունի» տարբերակը և սեղմել «Հաջորդ»:

Այժմ տվյալների բազան հաջողությամբ ստեղծվել է SQL սերվերում և ավելացվել է առկա տվյալների բազաների ցանկում: Ստորև նկարում կարող եք տեսնել կատարված աշխատանքի արդյունքը։

Հարկ է նշել, որ ստեղծված տվյալների բազան դեռ դատարկ է։ Սա շրջանակ է, տեղ հատկացված SQL-ում ձեր տեղեկատվական բազայի համար: Ձեր տվյալների բազան այս շրջանակում բեռնելու համար դուք պետք է օգտագործեք Վերբեռնում/Բեռնել տեղեկատվական բազայի գործիքները: Վերբեռնման/ներբեռնման կարգը նկարագրված է նաև մեր մյուս «1C ադմինիստրացիա» հոդվածում:

Համակարգն ապագայում իդեալական վիճակի բերելու համար անհրաժեշտ կլինի կարգավորել ստեղծված տվյալների բազայի «սպասարկման պլան»: Սպասարկման պլանը մի շարք ընթացակարգեր է, որոնք SQL-ը կանոնավոր կերպով կկատարի տվյալ ժամանակացույցի համաձայն: Օրինակ, այն պարբերաբար կրկնօրինակումներ կստեղծի և կջնջի ժամանակավոր ֆայլերը: SQL-ի հետ աշխատելը դուրս է այս հոդվածի շրջանակներից և կնկարագրվի ստորև նշվածներից մեկում:

Սերվերի կլաստեր 1C:Enterprise 8 (1C:Enterprise 8 Server Cluster)

1C:Enterprise 8 սերվերների կլաստերը հարթակի հիմնական բաղադրիչն է, որն ապահովում է տվյալների բազայի կառավարման համակարգի և օգտագործողի միջև փոխգործակցությունը հաճախորդ-սերվերի շահագործման դեպքում: Կլաստերը հնարավորություն է տալիս կազմակերպել անխափան, սխալ հանդուրժող, մրցակցային աշխատանք զգալի թվով օգտատերերի համար՝ մեծ տեղեկատվական բազաներով:

1C:Enterprise 8 սերվերների կլաստերը տրամաբանական հասկացություն է, որը ցույց է տալիս գործընթացների մի շարք, որոնք սպասարկում են տեղեկատվական տվյալների բազաների միևնույն շարքը:

Սերվերի կլաստերի հետևյալ հնարավորությունները կարելի է առանձնացնել որպես հիմնական.

• ինչպես մի քանի, այնպես էլ մեկ համակարգչի վրա (աշխատանքային սերվերներ) գործելու ունակություն.
• յուրաքանչյուր աշխատող սերվեր կարող է աջակցել մեկ կամ մի քանի աշխատանքային գործընթացների գործարկմանը, որոնք սպասարկում են հաճախորդի կապերը այս կլաստերի սահմաններում.
• նոր հաճախորդների ընդգրկումը կլաստերի աշխատանքային գործընթացներում տեղի է ունենում աշխատանքային գործընթացի ծանրաբեռնվածության վիճակագրության երկարաժամկետ վերլուծության հիման վրա.
• Բոլոր կլաստերային գործընթացների փոխազդեցությունը միմյանց հետ, հաճախորդի հավելվածների և տվյալների բազայի սերվերի հետ իրականացվում է TCP/IP արձանագրության միջոցով.
• կլաստերային գործընթացները աշխատում են, կարող են լինել կամ ծառայություն կամ հավելված

Հաճախորդ-սերվեր տարբերակ. Աշխատանքի սխեման

Այս տարբերակում հաճախորդի հավելվածը փոխազդում է սերվերի հետ: Սերվերի կլաստերն իր հերթին փոխազդում է տվյալների բազայի սերվերի հետ։

Կլաստերի կենտրոնական սերվերի դերը կատարում է սերվերային կլաստերի մաս կազմող համակարգիչներից մեկը։ Բացի հաճախորդի կապերը սպասարկելուց, կենտրոնական սերվերը կառավարում է նաև ամբողջ կլաստերի աշխատանքը և պահպանում է այս կլաստերի ռեեստրը:

Կլաստերը հասցեագրված է հաճախորդների միացումների համար կենտրոնական սերվերի անունով և, հնարավոր է, ցանցի պորտի համարով: Եթե ​​օգտագործվում է ստանդարտ ցանցային պորտ, ապա միանալու համար պարզապես անհրաժեշտ է նշել կենտրոնական սերվերի անունը:

Կապի հաստատման ընթացքում հաճախորդի հավելվածը կապվում է կլաստերի կենտրոնական սերվերի հետ: Աշխատողների գործընթացի բեռնվածության վիճակագրության վերլուծության հիման վրա կենտրոնական սերվերը հաճախորդի հայտը փոխանցում է պահանջվող աշխատանքային գործընթացին, որը պետք է սպասարկի այն: Այս գործընթացը կարող է ակտիվացվել կլաստերի ցանկացած աշխատող սերվերի վրա, մասնավորապես կենտրոնական սերվերի վրա:

Կապի պահպանումը և օգտատիրոջ իսկորոշումը աջակցվում են այս աշխատանքային հոսքի կողմից, մինչև հաճախորդը դադարի աշխատել որոշակի տեղեկատվական բազայի հետ:

Սերվերի կլաստեր

Հիմնական սերվերի կլաստերը կարող է լինել մեկ համակարգիչ և պարունակել միայն մեկ աշխատանքային գործընթաց:

Նկարում կարող եք դիտարկել բոլոր այն տարրերը, որոնք, այսպես թե այնպես, մասնակցում են սերվերի կլաստերի աշխատանքին: Սրանք հետևյալ տարրերն են.

• սերվերի կլաստերի գործընթացներ.
  o ragent.exe;
  o rmngr.exe;
  o rphost.exe;
• տվյալների պահպանում:
  o կլաստերների ցանկ;
  o կլաստերային ռեգիստր:

Ragent.exe գործընթացը, որը կոչվում է սերվերի գործակալ, ապահովում է համակարգչի աշխատանքը որպես կլաստերի մաս: Հետևաբար, համակարգիչը, որի վրա աշխատում է ragent.exe գործընթացը, պետք է անվանել արտադրական սերվեր: Մասնավորապես, ragent.exe-ի ֆունկցիոնալ պարտականություններից մեկը կլաստերների ռեեստրի պահպանումն է, որոնք տեղակայված են կոնկրետ աշխատող սերվերի վրա:

Ոչ կլաստերի ռեեստրը, ոչ էլ սերվերի գործակալը սերվերի կլաստերի անբաժանելի մասն են, այլ միայն թույլ են տալիս գործելու սերվերը և դրա վրա տեղակայված կլաստերները:

Սերվերի կլաստերն ինքնին բաղկացած է հետևյալ տարրերից.

• մեկ կամ մի քանի rmngr.exe գործընթացներ
• կլաստերային ռեգիստր
• մեկ կամ մի քանի rphost.exe գործընթացներ:

Կլաստերի կառավարիչ (գործընթացի rmngr.exe): Այն ծառայում է վերահսկելու ամբողջ կլաստերի աշխատանքը: Կլաստերը կարող է ներառել մի քանի rmngr.exe գործընթացներ, որոնցից մեկը միշտ կլինի այս կլաստերի հիմնական կառավարիչը, իսկ մնացած գործընթացները կլինեն լրացուցիչ կառավարիչներ։ Կլաստերի կենտրոնական սերվերը պետք է կոչվի աշխատանքային սերվեր, որի վրա գործում է հիմնական կլաստերի կառավարիչը և որը պարունակում է կլաստերի ցուցակը։ Կլաստերների ռեեստրի վարումը հիմնական կլաստերի կառավարչի գործառույթներից մեկն է:

Աշխատանքային գործընթաց (rphost.exe գործընթաց): Նա է, ով ուղղակիորեն սպասարկում է հաճախորդի հավելվածները՝ շփվելով տվյալների բազայի սերվերի հետ։ Այս գործընթացի ընթացքում սերվերի մոդուլի կազմաձևման որոշ ընթացակարգեր կարող են իրականացվել:

1C 8.3 տարբերակի մասշտաբայնություն

Սերվերի կլաստերի մասշտաբայնությունը ձեռք է բերվում հետևյալ եղանակներով.

• բարձրացնել կլաստերում մենեջերների թիվը և նրանց միջև ծառայությունների բաշխումը
• ավելացնել աշխատանքային գործընթացների քանակը, որոնք գործում են տվյալ աշխատող սերվերի վրա
• ավելացնել աշխատող սերվերների թիվը, որոնք կազմում են կլաստերը:

Միաժամանակ մի քանի մենեջերի օգտագործում:

Կլաստերների կառավարչի կողմից իրականացվող գործառույթները բաժանված են մի քանի ծառայությունների. Այս ծառայությունները կարող են վերագրվել տարբեր կլաստերի կառավարիչների: Սա հնարավորություն է տալիս հավասարաչափ բաշխել բեռը մի քանի գործընթացների վրա:

Այնուամենայնիվ, որոշ ծառայություններ կարող են օգտագործվել միայն հիմնական կլաստերի կառավարչի կողմից.

• կլաստերի կազմաձևման ծառայություն
• վրիպազերծման կետերի կառավարման ծառայություն
• կլաստերի կողպման ծառայություն:

Այլ ծառայությունների համար կամայական կլաստերի կառավարիչներին թույլատրվում է նշանակել.

• գրանցամատյանի ծառայություն
• օբյեկտների արգելափակման ծառայություն
• աշխատանքի սպասարկում
• ամբողջական տեքստի որոնման ծառայություն
• նստաշրջանի տվյալների ծառայություն
• համարակալման ծառայություն
• մաքսային կարգավորումների ծառայություն
• ժամանակի սպասարկում
• գործարքների արգելափակման ծառայություն.

Միաժամանակ մի քանի աշխատանքային հոսքերի օգտագործում:

Մի կողմից, մի քանի աշխատանքային գործընթացների օգտագործումը հնարավորություն է տալիս նվազեցնել յուրաքանչյուր կոնկրետ աշխատանքային գործընթացի ծանրաբեռնվածությունը: Մյուս կողմից, բազմաթիվ աշխատանքային գործընթացների օգտագործումը հանգեցնում է արտադրական սերվերի ապարատային ռեսուրսների ավելի արդյունավետ օգտագործմանը: Ավելին, մի քանի աշխատանքային գործընթացներ գործարկելու ընթացակարգը մեծացնում է սերվերի հուսալիությունը, քանի որ այն մեկուսացնում է հաճախորդների խմբերը, որոնք աշխատում են տարբեր տեղեկատվական բազաներով: Կլաստերում աշխատող պրոցեսը, որը թույլ է տալիս մի քանի աշխատանքային պրոցեսներ գործարկել, կարող է ավտոմատ կերպով վերագործարկվել կլաստերի ադմինիստրատորի կողմից սահմանված ժամանակահատվածում:

Ավելի շատ աշխատանքային գործընթացներ օգտագործելու (հաճախորդների կապերի քանակի ավելացում) առանց որոշակի աշխատանքային գործընթացի բեռը մեծացնելու կարողությունը հանգեցնում է կլաստերի մաս կազմող աշխատող սերվերների քանակի վերափոխմանը:

1C 8.3 տարբերակի սխալների հանդուրժողականություն

Կլաստերային խափանումների դիմացկունությունն ապահովվում է երեք եղանակով.

• ինքնին կլաստերի ավելորդությունը
• աշխատանքային գործընթացների վերապահում
• դիմադրություն կապի ալիքի ընդհատմանը.

1C կլաստերի 8.3 տարբերակի կրկնօրինակում

Մի քանի կլաստերներ միավորված են ավելորդության խմբի մեջ: Կլաստերները, որոնք գտնվում են նման խմբում, ավտոմատ կերպով համաժամացվում են:

Եթե ​​ակտիվ կլաստերը ձախողվի, այն փոխարինվում է խմբի հաջորդ աշխատանքային կլաստերով: Երբ ձախողված կլաստերը վերականգնվի, այն կակտիվանա տվյալների համաժամացումից հետո:

1C աշխատանքային գործընթացների 8.3 տարբերակի կրկնօրինակում

Աշխատանքային հոսքերից յուրաքանչյուրի համար հնարավոր է նշել դրա օգտագործման տարբերակները.

• օգտագործել
• չեն օգտագործում
• օգտագործել որպես կրկնօրինակ:

Եթե ​​պրոցեսը խափանվում է, ապա կլաստերը փոխարենը սկսում է օգտագործել ներկայումս ոչ ակտիվ պահուստավորման գործընթաց: Այս դեպքում դրա վրա բեռը ավտոմատ կերպով վերաբաշխվում է:

1C 8.3 տարբերակի դիմադրություն կապի ալիքի ընդհատմանը

Քանի որ յուրաքանչյուր օգտատիրոջ տրամադրվում է իր սեփական հաղորդակցման սեսիան, կլաստերը պահում է տվյալներ այն օգտատերերի մասին, ովքեր միացել են և ինչ գործողություններ են նրանք կատարել:

Եթե ​​ֆիզիկական կապը անհետանա, կլաստերը կսպասի այս օգտատիրոջ հետ կապին: Շատ դեպքերում, կապը վերականգնելուց հետո, օգտվողը կկարողանա շարունակել աշխատել հենց այն կետից, որտեղ կապը կորել է: Տեղեկատվական բազայի հետ նորից միանալու կարիք չկա:

Նիստերը 1C տարբերակով 8.3

Սեսիան հնարավորություն է տալիս որոշել կոնկրետ տեղեկատվական բազայի ակտիվ օգտագործողին և որոշել այս հաճախորդից վերահսկման հոսքը: Առանձնացվում են նիստերի հետևյալ տեսակները.

• Thin client, Web client, Thick client – ​​այս նիստերը տեղի են ունենում, երբ համապատասխան հաճախորդները մուտք են գործում տեղեկատվական բազա
• «Կազմաձևողի» տիպի միացում - դա տեղի է ունենում կոնֆիգուրատորի տեղեկատվական բազա մուտք գործելիս
• COM կապ – ձևավորվում է ինֆաբազա մուտք գործելու համար արտաքին կապ օգտագործելիս
• WS կապ – տեղի է ունենում վեբ սերվերի տեղեկատվական բազա մուտք գործելիս՝ վեբ սերվերում հրապարակված վեբ ծառայության մուտք գործելու արդյունքում։
• Ֆոնային աշխատանք – ստեղծվում է, երբ կլաստերի աշխատող պրոցեսը մուտք է գործում տեղեկատվական բազա: Այս նիստն օգտագործվում է ֆոնային աշխատանքի ընթացակարգի կոդը գործարկելու համար,
  Կլաստերային վահանակ – ստեղծվում է, երբ հաճախորդ-սերվերի ադմինիստրացիայի կոմունալ ծրագիրը մուտք է գործում աշխատանքային գործընթաց
• COM ադմինիստրատոր – տեղի է ունենում, երբ աշխատանքային գործընթացին հասանելի է դառնում արտաքին կապի միջոցով:
• Աշխատեք տարբեր օպերացիոն համակարգերի ներքո

Ցանկացած սերվերի կլաստերի գործընթաց կարող է գործել ինչպես Linux օպերացիոն համակարգի, այնպես էլ Windows օպերացիոն համակարգի ներքո: Սա ձեռք է բերվում նրանով, որ կլաստերի փոխազդեցությունը տեղի է ունենում TCP/IP արձանագրության հսկողության ներքո: Կլաստերը կարող է ներառել նաև աշխատող սերվերներ, որոնք աշխատում են այս օպերացիոն համակարգերից որևէ մեկով:

Server Cluster Administration Utility 8.3

Համակարգի փաթեթը ներառում է հաճախորդ-սերվեր տարբերակի կառավարման ծրագիր: Այս օգտակար ծրագիրը հնարավորություն է տալիս փոխել կլաստերի կազմը, կառավարել տեղեկատվական բազաները և արագ վերլուծել գործարքների կողպեքները:

Մի սերվերի վրա աշխատող մի քանի պրոցեսներ հնարավորություն են տալիս արդյունավետորեն օգտագործել RAM-ի և պրոցեսորային ռեսուրսների քանակը՝ հարցումները կատարելու համար, ինչպես նաև միացնել հաճախորդի նիստը մեկ այլ աշխատանքային գործընթացի հետ, եթե ընթացիկը «խափանվի»:
Server Agent (ragent) ծրագիրը պատասխանատու է հասկանալու համար, թե ինչ է աշխատում կոնկրետ սերվերի վրա: Սերվերի գործակալի դադարեցումը սերվերն անհասանելի կդարձնի կլաստերի օգտագործման համար: Գործակալը պահպանում է իր տեղեկատվությունը srvribrg.lst ֆայլում:

Աշխատանքային տվյալների բազաների և ներգրավված աշխատանքային գործընթացների մասին տեղեկատվությունը պատկանում է «Սերվերի մենեջերին» (rmngr): Այն պահում է այս տեղեկատվությունը 1CV8Reg.lst ֆայլում: Սերվերի կառավարչի դադարեցումը կարող է հանգեցնել հաճախորդի հավելվածների վերագործարկմանը, եթե կառավարիչը հաջողությամբ վերագործարկվի կամ ամբողջ կլաստերի աշխատող սերվերների ամբողջական դադարեցմանը:

1C: Ձեռնարկությունը թույլ է տալիս մեկ սերվերի վրա ստեղծել մի քանի անկախ կլաստերներ: Նրանցից յուրաքանչյուրը նույնացվում է ցանցում եզակի «IP պորտով» և ծառայության ֆայլերում եզակի համարով: Առաջին կլաստերը լռելյայն ստանում է պորտ 1541:

Enterprise Servers snap-in-ը նախատեսված է կլաստերի կառավարման համար:
Դուք կարող եք սերվերներին միանալ սերվերի անունով կամ IP հասցեով:

Սերվերի գործակալ

Սերվերի գործակալը «գիտի» բոլոր կլաստերների մասին, որոնք աշխատում են սերվերի վրա: Այս տեղեկատվությունը պահվում է srvribrg.lst ֆայլում՝ կլաստերների և ցուցակի ադմինիստրատորների ցանկով: Գործակալի հիմնական պորտը 1540 է: Յուրաքանչյուր աշխատանքային սերվերի վրա կարող է գործարկվել միայն մեկ գործակալ, որը սպասարկում է այս սերվերի բոլոր հնարավոր կլաստերները:

Եկեք ավելի սերտ նայենք կլաստերի հատկություններին

Վերագործարկման ընդմիջում

Այս պարամետրը վերսկսում է 1C սերվերի աշխատանքային գործընթացները՝ ըստ նշված արժեքի վայրկյանների ընթացքում: Սովորաբար, պարամետրը օգտագործվում է հավելվածի սերվերների վրա, որոնք ունեն 32-բիթանոց համակարգ, քանի որ այնտեղ հիշողության ծավալը սահմանափակվում է ~ 3,7 ԳԲ-ով, եթե օպերացիոն համակարգը 64-բիթ է, իսկ հավելվածի սերվերը 32-բիթանոց է: Եթե ​​ՕՀ-ն օգտագործում է 32-բիթանոց ճարտարապետություն, ապա աշխատանքային գործընթացի հիշողության ընդհանուր սպառումը կազմում է ~ 1,7 ԳԲ: Իսկ օգտվողները հաճախ կարող են սխալ հաղորդագրություն ստանալ, ինչպիսին է «Անբավարար հիշողություն 1C Enterprise սերվերում»: Այս սխալից խուսափելու ամենահեշտ ձևը աշխատանքային գործընթացների վերագործարկումն է, օրինակ՝ 86400 վայրկյան (1 օր): Պարամետրը փոխելիս ժամանակի հաշվարկը սկսվում է 1C հավելվածի սերվերի ծառայության մեկնարկից:

Թույլատրված հիշողության չափը

Աշխատանքային գործընթացների վերագործարկումը, երբ հասնում է աշխատանքային պրոցեսի կողմից զբաղեցրած հիշողության որոշակի շեմը կիլոբայթներով:

Հիշողության թույլատրելի քանակի գերազանցման ընդմիջում

Սա նշանակում է, որ եթե որոշակի վայրկյանների ընթացքում գերազանցվի «թույլատրելի հիշողության քանակի» պարամետրում նշված հիշողությունը, ապա 1C սերվերը կորոշի վերագործարկել աշխատանքային հոսքը:

Սերվերի սխալների քանակի թույլատրելի շեղում

Այն հաշվարկվում է հետևյալ կերպ. Մենք ունենք սերվերի զանգեր, որոնք կարելի է տեսնել տեխնոլոգիայի մատյանում «ԶԱՆԳ» իրադարձության միջոցով, և կան նաև տարբեր բացառություններ, որոնք կարելի է տեսնել տեխնոլոգիայի մատյանում՝ «EXCP» իրադարձության միջոցով: Պլատֆորմը հաշվարկում է այս իրադարձությունների հարաբերակցությունը։ Ենթադրվում է, որ այդ իրադարձությունները պետք է լինեն մոտավորապես նույնը։ Եթե ​​որևէ աշխատանքային գործընթացում այդ հարաբերակցությունը որոշակի զգալի չափով գերազանցում է այլ աշխատանքային գործընթացների այս իրադարձությունների հարաբերակցությունը, ապա նման աշխատանքային գործընթացը համարվում է խնդրահարույց: Պարզապես այս արժեքը սահմանված է այս պարամետրում: Առաջարկվող արժեքը 50 է:

Խնդրահարույց գործընթացների ստիպողական դադարեցում

Եթե ​​միացնենք այս պարամետրը, ապա «սերվերի սխալների քանակի թույլատրելի շեղում» պարամետրի համաձայն, խնդրահարույց գործընթացները կդադարեցվեն։ Եթե ​​պարամետրն անջատված է, հարթակը ցուցադրում է «ATTN» գործընթացի գրանցամատյանի իրադարձությունը, որը ցույց է տալիս խնդրահարույց գործընթացը:

Դադարեցրեք անջատված գործընթացները հետո

Եթե ​​գործարկվում է «վերագործարկման ընդմիջում» կամ «հիշողության թույլատրելի չափ» պարամետրերից մեկը, ապա երբ աշխատանքային գործընթացը վերսկսվում է, այն կարող է «ընկնել»: Եթե ​​հաճախորդը վերագործարկման ժամանակ չի մուտք գործում սերվեր (ոչ ակտիվ է), ապա հաջորդ անգամ, երբ նա մուտք գործի այն, այն սահուն կերպով կանցնի նոր աշխատանքային գործընթացին: Եթե ​​հաճախորդը կապ հաստատի սերվերի հետ աշխատանքային հոսքը վերագործարկելու պահին, ապա այս դեպքում նա կստանա սխալի հաղորդագրություն և կդադարեցնի իր աշխատանքը: Որպեսզի դա տեղի չունենա, դուք պետք է սահմանեք այս պարամետրի արժեքը վայրկյանների ընթացքում: Սովորաբար 120 վայրկյանը բավական է։ Այս ընթացքում աշխատանքային հոսքը ժամանակ կունենա մշակելու հաճախորդների ընթացիկ հարցումները և դրանք տեղափոխելու նոր աշխատանքային հոսք: Այն ակտիվ հաճախորդները, որոնց գործընթացը չի հասցրել մշակել, դադարեցվում են, և հաճախորդները կարող են սխալ ստանալ:

Սխալների հանդուրժողականության մակարդակը

Այս պարամետրը գործում է ինքնուրույն՝ անկախ կենտրոնական սերվերների քանակից։ Սխալների հանդուրժողականության մակարդակը կարող է ընդունել ցանկացած արժեք: Օրինակ, ճկունության մակարդակը = 1, ապա յուրաքանչյուր օգտագործողի նստաշրջան կրկնապատկվում է: Եթե ​​սխալների հանդուրժողականության մակարդակը = 2, ապա յուրաքանչյուր նիստ բազմապատկվում է 3-ով: Սերվերի բեռը նույնպես մեծանում է: Սխալների հանդուրժողականության մակարդակը փոխելիս, եթե մենք ունենք կենտրոնական սերվեր, այն կրկնվում է յուրաքանչյուր կենտրոնական սերվերի վրա՝ «կլաստերի ռեեստր», «կլաստերի կողպման ծառայություն»: Գոյություն ունի նաև այնպիսի ծառայությունների կրկնօրինակում, ինչպիսիք են «նստաշրջանի տվյալների ծառայությունը», «ժամանակի դրոշման առցանց ծառայությունը», «օբյեկտների արգելափակման ծառայությունը», «լիցենզավորման ծառայությունը», «համարակալման ծառայությունը» այլ սերվերների վրա: Դրանցից ամենածանրը «սեսի տվյալների ծառայությունն» է։

Բեռնել համօգտագործման ռեժիմը

Կատարման առումով. Երբ հաճախորդի կապը միանում է, այն կմիանա այն սերվերին, որն ունի աշխատանքային գործընթաց՝ ավելի մատչելի կատարողականությամբ: Հասանելի կատարումը սահմանվում է աշխատանքային հոսքի հատկություններում.

1C մակարդակում առկա կատարողականը հաշվարկվում է հետևյալ կերպ. տեղեկանք սերվերի զանգը կատարվում է աշխատանքային բոլոր գործընթացներին յուրաքանչյուր 10 րոպեն մեկ և չափվում է այս զանգի ժամանակը: Ստացված թիվը բաժանվում է 10000-ի (տասը հազարի) և հավելվածի սերվերի մեխանիզմները հաշվարկում են հղման ժամանակը: Այն դեպքում, երբ աշխատանքային գործընթացի արտադրողականությունը դարձել է 25% -ով պակաս, քան մյուսներինը, այս աշխատանքային գործընթացից կապերը սկսում են անցնել այլ աշխատանքային գործընթացների, մինչև բոլոր կապերը վերանան:

Հիշողության առաջնահերթություն. Օգտատիրոջ կապերը կկատարվեն արտադրական սերվերի հետ, որն ավելի շատ հասանելի հիշողություն ունի:

Կլաստերի կառավարիչ

Կլաստերի կառավարիչը պատասխանատու է կլաստերի գործունեության համար: Յուրաքանչյուր կլաստեր ունի իր մենեջերը: Կառավարիչը պահում է կլաստերի մասին տեղեկատվությունը 1CV8Reg.lst ֆայլում (կլաստերի ռեեստր): Յուրաքանչյուր կլաստերի կառավարիչ ունի նաև աշխատանքային սերվերի իր պորտը: Առաջին կլաստերի համար կառավարչի լռելյայն նավահանգիստը 1541 է: Հենց այս նավահանգիստն է ցուցադրվում 1C սերվերներում. Enterprise snap-in Կլաստերների ճյուղում՝ նույնականացնելով կլաստերը:
Կառավարիչը հարցումներ է ստանում 1C: Enterprise-ի հաճախորդի մասից և որոշում, թե որ Workflow-ին տրամադրի այս ծառայության հարցումը:

Կառավարիչը օգտագործում է ծառայության նավահանգիստը աշխատողների գործընթացների հետ փոխազդելու համար:

Աշխատանքային գործընթացը

Աշխատանքային գործընթացը պատասխանատու է «հաճախորդների հետ աշխատելու համար»: 1C-ում կարող են լինել մի քանի աշխատանքային գործընթացներ՝ Enterprise 8 կլաստերում: Աշխատանքային գործընթացների քանակը ձեռքով չի ստեղծվում, այլ հաշվարկվում է սխալների հանդուրժողականության և հուսալիության առաջադրանքի պահանջների նկարագրության հիման վրա: Սերվերի կառավարիչը որոշում է, թե որ աշխատանքային պրոցեսը կծառայի հաճախորդի կապին: Հաճախորդների միացումների համար Worker Processes-ին լռելյայն հատկացված է IP պորտերի մի շարք 1560 – 1591: Բացի այդ, յուրաքանչյուր Worker Process-ին հատկացվում է ծառայության միացք՝ կլաստերի կառավարչի հետ հաղորդակցվելու համար:

Աշխատանքային սերվերի կարգավորումները, ըստ 1C փաստաթղթերի, կարող են փոխվել միայն 1C հավելվածի սերվերի CORP տարբերակում: Փաստորեն, կարգավորումներն աշխատում են և՛ CORP, և՛ PROF տարբերակներում: Եթե ​​այս կարգավորումները օգտագործվում են PROF տարբերակում, դա կլինի լիցենզային պայմանագրի խախտում:

Աշխատանքային հոսքի առավելագույն հիշողություն

Այս պարամետրն ինքնին ոչինչ չի սահմանափակում։ Այն աշխատում է «անվտանգ հիշողության սպառում մեկ զանգի համար» պարամետրի հետ համատեղ: Եկեք պատկերացնենք, որ մեր բոլոր աշխատանքային գործընթացներն ընդհանուր առմամբ հասել են մոտավորապես այս պարամետրի նշված արժեքի հիշողության սպառմանը: Եվ հիմա որոշակի օգտվող ցանկանում է կատարել որոշակի սերվերի զանգ, որը ցանկանում է սպառել մեծ քանակությամբ հիշողություն: Հենց որ սերվերի զանգը գերազանցի այս պարամետրում նշված հիշողության ծավալը «անվտանգ հիշողության սպառում մեկ զանգի համար» պարամետրի հիշողության քանակով, այս կոնկրետ օգտվողը կստանա «անվտանգ հիշողության սպառում մեկ հաճախորդի համար» ձևի սխալ: - սերվերի զանգը գերազանցվել է»: Սա անհրաժեշտ է, որպեսզի մեկ օգտվող չկարողանա ծանրաբեռնել աշխատող սերվերը: 0 պարամետրի արժեքը հավասար է 1C սերվերի վրա տեղադրված հիշողության 80%-ին:

Անվտանգ հիշողության սպառում մեկ զանգի համար

0 (կանխադրված) արժեքը առավելագույն աշխատանքային հոսքի հիշողության արժեքի 5%-ն է: Արժեքը կարող է լինել -1: Սա նշանակում է, որ հաճախորդ-սերվերի ցանկացած զանգ, որը գերազանցում է «աշխատողի հիշողության առավելագույն չափը» պարամետրի նշված արժեքը:

Աշխատանքային գործընթացի հիշողության ծավալը, մինչև որ սերվերը համարվում է արդյունավետ

Նշանակում է, որ եթե սահմանվել է արժեք, և աշխատող գործընթացները զբաղեցրել են այս պարամետրում նշված հիշողության ծավալը, սերվերը կշարունակի աշխատել, բայց չի ընդունի նոր կապեր, մինչև հիշողությունը չազատվի:

Տեղեկատվական անվտանգության քանակը յուրաքանչյուր գործընթացի համար

Կարող է լինել կատարողականի նվազում, երբ կան բազմաթիվ տեղեկատվական բազաներ և մեկ աշխատանքային հոսք: Հետևաբար, այս պարամետրով հնարավոր է կրճատել տվյալների բազաների քանակը մեկ գործընթացում։ Եթե ​​արժեքը սահմանեք 1 (շատ դեպքերում սա բավականին օպտիմալ է աշխատում), ապա յուրաքանչյուր տեղեկատվական բազայի համար կստեղծվի նոր աշխատանքային պրոցես (rphost):

Մեկ գործընթացում միացումների քանակը

Նույնը, ինչ վերը նշված պարամետրը, բայց կախված է յուրաքանչյուր գործընթացի միացումների քանակից: 0-ի արժեքը կնշանակի, որ յուրաքանչյուր աշխատող սերվերի վրա կլինի միայն մեկ աշխատանքային պրոցես:

Մենեջեր յուրաքանչյուր ծառայության համար

Յուրաքանչյուր կենտրոնական աշխատող սերվեր ունի հիմնական կլաստերի կառավարիչ՝ որոշակի ծառայություններով.

Դրանք իրականացվում են մեկ ծառայության «rmngr»-ի կողմից: Եկեք պատկերացնենք, որ այս ծառայությունը սկսում է մեծ քանակությամբ հիշողություն սպառել կամ վատնել պրոցեսորի ռեսուրսները: Սովորաբար կան մի քանի բնորոշ կասկածյալներ: Բայց հանկարծ դուք հայտնվել եք «փակուղու» մեջ և չեք կարող հասկանալ, թե կոնկրետ ինչ է բեռնում ծառայությունը, կարող եք ստուգել «մենեջեր յուրաքանչյուր ծառայության համար» վանդակը, ծառայությունը կբաժանվի 21 գործընթացի (սա հիմնական ծառայությունների քանակն է. կլաստերի կառավարիչ): Եվ համապատասխանաբար, օգտագործելով գործընթացի PID-ը, հնարավոր կլինի հաշվարկել, թե որ ծառայությունն է բեռնում համակարգը։

Կենտրոնական սերվեր

Սա այն սերվերն է, որը պահում է կլաստերի ռեեստրը 1CV8Clst.lst ֆայլում: Ֆայլը պահում է տվյալների շտեմարանների ցանկը, կլաստերի ադմինիստրատորների ցանկը, ֆունկցիոնալության առաջադրանքի պահանջների ցանկը, անվտանգության պրոֆիլների ցանկը և ընդհանրապես կլաստերի բոլոր կարգավորումները: Այս ֆայլը առկա է միայն այնտեղ, որտեղ նշված է «կենտրոնական սերվերի» վանդակը: Կարող են լինել մի քանի կենտրոնական սերվերներ: Նաև կենտրոնական սերվերների վրա կան այնպիսի ծառայություններ, ինչպիսիք են «կլաստերի արգելափակման ծառայությունը», «կլաստերի կազմաձևման ծառայությունը»: Քանի դեռ առնվազն մեկ կենտրոնական սերվեր է գործում, կլաստերը գործում է: Երբ ամենավերջին կենտրոնական սերվերը ձախողվի, կլաստերը դառնում է անօգտագործելի՝ անկախ սխալների հանդուրժողականության կարգավորումներից:

Ֆունկցիոնալության առաջադրանքի պահանջ

1C Enterprise 8.3 սերվերների կլաստերը ապահովում է որոշակի գործառույթների շարք (կոչվում են պահանջի օբյեկտներ), որոնց բաշխումը կլաստերի ներսում աշխատող սերվերների միջև կարող է վերահսկվել: Օրինակ, կարող եք նշել, որ կլաստերի բոլոր ֆոնային աշխատանքները կաշխատեն ընտրված աշխատող սերվերի վրա: Ցանկացած արտադրական սերվերի վրա կապի կամ կլաստերի ծառայություն տեղադրելու համար դուք պետք է ընտրված արտադրական սերվերի համար ստեղծեք ֆունկցիոնալ նշանակման պահանջ: Այս պահանջը որոշում է որոշակի սերվերի որոշակի աշխատանք կատարելու հնարավորությունը կամ անհնարինությունը: Եկեք ավելի սերտ նայենք, թե որն է ֆունկցիոնալության առաջադրանքի պահանջը:

Օգտատիրոջ կապերի տեղափոխում

Ենթադրենք, որ մենք ցանկանում ենք, որ օգտատերերի կապերը աշխատեն աշխատող սերվերի #1-ի վրա, բայց եթե այդ սերվերը դադարի, մենք ուզում ենք, որ դրանք ձախողվեն մեկ այլ աշխատող սերվերի համար՝ #2:

Դա անելու համար մենք պետք է ստեղծենք ֆունկցիոնալության հանձնարարության պահանջ թիվ 1 սերվերի վրա.

Թիվ 2 սերվերի վրա սահմանեք նույն կարգավորումները, բայց փոխեք առաջնահերթությունը.

Առաջնահերթության կարևորությունն իրականացվում է հակառակ ուղղությամբ: Այսինքն՝ 1-ին գերակայությունը 2-ից բարձր է։

Հեռացրեք արտադրության սերվերը կլաստերից

Մենք կարող ենք պարզապես հեռացնել աշխատող սերվերը կլաստերից՝ ջնջելով այն ցուցակից, բայց այս դեպքում բոլոր օգտատերերը «կհեռացվեն» համակարգից։ Հեռացումն ավելի ցավոտ դարձնելու համար կարող եք անել հետևյալը.

Ստեղծեք ֆունկցիոնալ նշանակման պահանջ հետևյալ կարգավորումներով.

Այս կարգավորումը նշանակում է, որ այս արտադրական սերվերի հետ նոր կապեր չեն լինի: Այն օգտվողները, ովքեր աշխատում էին, կշարունակեն աշխատել, բայց աստիճանաբար կտեղափոխվեն այլ աշխատող սերվերներ։

Լիցենզավորման ծառայություն

Լիցենզավորման ծառայությունը տեղափոխեք առանձին սերվեր: Սա լավ է, քանի որ ծրագրային ապահովման լիցենզիաները կարող են կապված լինել որոշակի համակարգչի հետ: Եկեք ստեղծենք ֆունկցիոնալության հանձնարարության պահանջ հետևյալ կարգավորումներով.

Նախապատմական աշխատանքներ

8.3.7 հարթակի թողարկմամբ ֆոնային աշխատանքները բաժանվեցին 2 խմբի.

1. Ֆոնային աշխատանքներ կանչված կազմաձևման կոդից

2. Սովորական առաջադրանքներ

Հետևաբար, ֆունկցիոնալությունը նշանակելու համար պահանջվում են մի քանի պարամետրեր.

1. Որպեսզի ֆոնային աշխատանքները արագ աշխատեն, դուք պետք է ավելացնեք սեսիայի տվյալները ֆոնային և պլանավորված աշխատանքների համար

Ֆունկցիոնալությունը նշանակելու համար անհրաժեշտ պահանջները ստեղծելուց հետո դուք պետք է կիրառեք դրանք.

Մասնակի – ծրագիր, որը չի խաթարի օգտագործողի փորձը

Full – ծրագիր, որը կարող է խաթարել օգտատիրոջ փորձը:

Գործնականում ես երբեք չեմ հանդիպել այնպիսի իրավիճակի, երբ այն ամբողջությամբ կիրառվելիս խաթարեր օգտագործողի փորձը կամ նմանատիպ որևէ այլ բան: Բայց ամեն ինչ հնարավոր է, հիշեք: Դիմումից հետո 1C հավելվածի սերվերի ծառայության վերագործարկումը անհրաժեշտ չէ:

Դուք միշտ կարող եք կապվել 1C-ի օպտիմալացման մասնագետների հետ, մեր գործնական փորձը կխնայի ձեր ժամանակը:

Բացի ֆայլի տարբերակից, 1C:Enterprise համակարգը կարող է աշխատել տեղեկատվական բազաների հետ հաճախորդ-սերվեր տարբերակով: Վերջին դեպքում հասկացվում է ճարտարապետություն, որը բաղկացած է մի քանի ծրագրային շերտերից, որոնք սխեմատիկորեն պատկերված են ստորև նկարում:

• Հաճախորդների հավելվածներ, thin հաճախորդներ և վեբ հաճախորդներ- սա «1C:Enterprise» է գործարկման տարբեր ռեժիմներում, որոնց հետ աշխատում է վերջնական օգտագործողը: Հաճախորդների հավելվածների և thin-հաճախորդների համար վեբ-բրաուզերը բավարար է օգտատերերի համակարգիչների վրա (կամ միացված), վեբ հաճախորդի համար:
• Սերվերի կլաստեր «1C:Enterprise»մեկ կամ մի քանի համակարգիչների վրա աշխատող աշխատանքային գործընթացների հավաքածու է և տեղեկատվական բազաների ցանկ, որոնք տեղակայված են այս կլաստերում: Սերվերի կլաստերում կատարվում է հավելվածի օբյեկտների ամբողջ աշխատանքը, պատրաստվում են ձևերի ցուցադրման համար (տեղեկատվական բազայի օբյեկտների ընթերցում, ձևի տվյալների լրացում, տարրերի դասավորություն և այլն) և հրամանի ինտերֆեյսի, հաշվետվությունների ստեղծման և ֆոնային աշխատանքների կատարման համար: Հաճախորդները ցուցադրում են միայն սերվերի կլաստերում պատրաստված տեղեկատվությունը: Բացի այդ, ծառայության ֆայլերը պահվում են 1C:Enterprise կլաստերի սերվերում, ինչպես նաև տեղեկատվական բազայի գրանցման մատյանում:
• Տվյալների բազայի սերվեր— տվյալների բազայի սերվերի վրա տեղի է ունենում ուղղակի պահպանում և տվյալների հետ աշխատանք՝ տրամադրված 1C:Enterprise համակարգի կողմից աջակցվող տվյալների բազայի կառավարման հետևյալ համակարգերից մեկով (DBMS).
  • Microsoft SQL Server Microsoft SQL Server 2000-ից և ավելի բարձր;
  • PostgrageSQL 8.1 տարբերակից սկսած;
  • IBM DB2 9.1 տարբերակից սկսած;
  • Oracle տվյալների բազա 10g թողարկում 2-ից սկսած:
• Վեբ սերվերպահանջվում է միայն վեբ-հաճախորդների և thin client տարբերակներից մեկի համար: Ապահովում է այս տեսակի կապերի փոխազդեցությունը 1C:Enterprise սերվերների կլաստերի հետ:

Հարկ է նաև նշել, որ ծրագրային ապահովման յուրաքանչյուր շերտ պարտադիր չէ, որ տեղակայված լինի առանձին ֆիզիկական համակարգչի վրա: Սերվերի կլաստերը կարող է տեղակայվել նույն համակարգչում տվյալների բազայի սերվերի, վեբ սերվերի և այլնի հետ: Օրինակ, հետևյալ աշխատանքային կառուցվածքը հաճախ հանդիպում է փոքր կազմակերպություններում.

Այս հոդվածում ես կնկարագրեմ 1C:Enterprise սերվերի 8.3.4.389 տարբերակի տեղադրումը (1C:Enterprise պլատֆորմի 8.1, 8.2 և 8.3 այլ տարբերակների համար քայլերը նման են) մեկ համակարգչի վրա, որն աշխատում է Windows Server 2008 (R2) կամ Windows: Սերվեր 2012 (R2): Microsoft SQL Server 2008 (R2) կամ Microsoft SQL Server 2012-ը կդիտարկվեն որպես DBMS: Դրա համար մեզ անհրաժեշտ կլինի.

1. Համակարգիչ, որը համապատասխանում է 1C:Enterprise սերվերի տեղադրման համակարգի պահանջներին և այս համակարգչում տեղադրված ՕՀ-ով կամ .
2. Համակարգիչ տվյալների բազայի սերվերի համար, որը նաև աշխատում է ՕՀ կամ (կարող է լինել համակարգիչը 1-ին քայլից):
3. Տեղական ադմինիստրատորի իրավունքները երկու համակարգիչների վրա:
4. 1C:Enterprise սերվեր 8-ի տեղադրման բաշխման հավաքածու:
5. Ծրագրային ապահովման լիցենզիա կամ HASP4 Net պաշտպանության բանալի 1C:Enterprise սերվերի համար:
6. Բաշխման հավաքածու Microsoft SQL Server 2008 (R2) կամ Microsoft SQL Server 2012 տեղադրելու համար:

2. MS SQL Server DBMS-ի տեղադրում

Մենք տեղադրում ենք MS SQL Server DBMS-ը համակարգչի վրա, որը ծառայում է որպես տվյալների բազայի սերվեր: 1C:Enterprise համակարգը գործարկելու համար բավական է տեղադրել հետևյալ բաղադրիչները.

• Տվյալների բազայի շարժիչի ծառայություններ
• Կառավարման գործիքներ - Հիմնական
  • Կառավարման գործիքներ - Ամբողջական:

Ընտրեք տեսակավորման տարբերակներ» Cyrillic_General_CI_AS« Մանրամասներ համակարգերի տեղադրման մասին

3. Windows Firewall-ի կարգավորում DBMS շահագործման համար

Եթե ​​տվյալների բազայի սերվերը և 1C:Enterprise կլաստերային սերվերը տեղակայված են տարբեր ֆիզիկական համակարգիչների վրա, ապա դուք պետք է կարգավորեք Windows Firewall-ը տվյալների բազայի սերվերի վրա, որպեսզի 1C:Enterprise սերվերը կարողանա աշխատել DBMS-ի հետ, մասնավորապես՝ բացել մուտքային կապերը նավահանգստում: 1433 (կանխադրված SQL Server օրինակի համար):

• Ես մանրամասն գրեցի Microsoft SQL Server 2008 (R2) / 2012-ի համար Windows Firewall-ի տեղադրման մասին:

4. Օգտատիրոջ ավելացում MS SQL Server-ում

Հաջորդը MS SQL Server-ին կավելացնենք առանձին օգտատեր, որի տակ կմիացվեն 1C:Enterprise սերվերի տվյալների բազաները։ Այս օգտվողը կլինի նաև այս տվյալների շտեմարանների սեփականատերը: Ավելացվող օգտատերը պետք է լիազորված լինի սերվերում՝ օգտագործելով գաղտնաբառ և ունենա հետևյալ դերերի շարքը. dbcreator, գործընթացի ադմինիստրատոր, հանրային. Մանրամասներ օգտատեր ավելացնելու մասին

• Microsoft SQL Server 2008 (R2) ես գրել եմ.
• Ես գրել եմ Microsoft SQL Server 2012:

5. 1C:Enterprise սերվերի տեղադրում

Այժմ եկեք անցնենք 1C:Enterprise սերվերի ֆայլերի տեղադրմանը և համապատասխան ծառայության գործարկմանը։ Տեղադրման համար անհրաժեշտ է 1C:Enterprise տեխնոլոգիական հարթակի բաշխման հավաքածու: Մատակարարված բաշխումների ցանկից հարմար են հետևյալը.

• 1C:Enterprise տեխնոլոգիական հարթակ Windows-ի համար - թույլ է տալիս տեղադրել 32-բիթանոց 1C:Enterprise սերվեր:
• 1C:Enterprise սերվեր (64-բիթ) Windows-ի համար - թույլ է տալիս տեղադրել ինչպես 32-բիթանոց, այնպես էլ 64-բիթանոց 1C:Enterprise սերվերներ

(Կա նաև KORP սերվերի 1C:Enterprise 8.3 ընդլայնված տարբերակը, մանրամասները կարելի է գտնել 1C կայքում)

Բացեք գրացուցակը 1C:Enterprise սերվերի տեղադրման ֆայլերով և գործարկեք ֆայլը setup.exe.

1C:Enterprise համակարգի տեղադրման օգնականը կսկսվի: Առաջին էջում սեղմեք « Հետագա».

Հաջորդ էջում դուք պետք է ընտրեք այն բաղադրիչները, որոնք կտեղադրվեն, մենք պահանջում ենք հետևյալ բաղադրիչները.

• Սերվեր 1C: Ձեռնարկություն— 1C: Ձեռնարկությունների սերվերի բաղադրիչներ
• Սերվերի կառավարում 1C: Ձեռնարկություն 8— լրացուցիչ բաղադրիչներ 1C:Enterprise սերվերների կլաստերի կառավարման համար

Մնացած բաղադրիչները (բաղադրիչների ցանկը կարող է կախված լինել կոնկրետ բաշխումից), կախված կարիքից, կարող են տեղադրվել նաև այս համակարգչում: Ձեր ընտրությունը կատարելուց հետո սեղմեք « Հետագա».

Ընտրեք ինտերֆեյսի լեզուն, որը կօգտագործվի լռելյայն և սեղմեք « Հետագա».

Եթե ​​1C:Enterprise սերվերը տեղադրված է որպես Windows ծառայություն (և շատ դեպքերում այն ​​պետք է տեղադրվի որպես այդպիսին), խորհուրդ եմ տալիս անմիջապես ստեղծել առանձին օգտվող, որի տակ կգործարկվի ստեղծված ծառայությունը: Սրա համար

• Դրոշը «միացված» թողեք Տեղադրեք 1C:Enterprise սերվերը որպես Windows ծառայություն (խորհուրդ է տրվում)»;
• Համապատասխան անջատիչը տեղափոխում ենք « Ստեղծեք USR1CV8 օգտվող».
• Երկու անգամ մուտքագրեք ստեղծվող օգտվողի գաղտնաբառը: Լռելյայնորեն, գաղտնաբառը պետք է համապատասխանի Windows-ի գաղտնաբառի քաղաքականությանը: Այս մասին ավելին կարող եք կարդալ.
  • Microsoft Windows Server 2008 (R2) համար - ;
  • Microsoft Windows Server 2012-ի համար - .

Կարող եք նաև ընտրել գոյություն ունեցող օգտվող 1C:Enterprise սերվերը գործարկելու համար: Այս դեպքում ընտրված օգտվողը պետք է ունենա հետևյալ իրավունքները.

• Մուտք գործեք որպես ծառայություն
• Մուտք գործեք որպես խմբաքանակային աշխատանք
• Կատարման մատյան օգտագործողներ:

Նաև օգտագործողին պետք է տրվեն անհրաժեշտ իրավունքները սերվերի ծառայության ֆայլերի գրացուցակի նկատմամբ (լռելյայն C:\Program Files\1cv8\srvinfo 64-բիթանոցի համար և C:\Program Files (x86)\1cv8\srvinfo 32-բիթանոց սերվերի համար):

Ինքնաբերաբար ստեղծված օգտվող USR1CV8կունենա վերը նշված բոլոր իրավունքները:

Համապատասխան պարամետրերը լրացնելուց հետո սեղմեք « Հետագա».

Եվ վերջապես սեղմեք « Տեղադրեք» տեղադրումը սկսելու համար: Սա կպատճենի ընտրված բաղադրիչների ֆայլերը, կստեղծի կազմաձևման ֆայլեր, կգրանցի ծրագրի բաղադրիչները, կստեղծի դյուրանցումներ, ինչպես նաև կսկսի 1C:Enterprise սերվերի ծառայությունը:

Տեղադրումն ավարտվելուց հետո օգնականը ձեզ կհուշի տեղադրել պաշտպանական դրայվերը՝ HASP Device Driver: Եթե ​​դուք օգտագործում եք ծրագրային լիցենզիա 1C:Enterprise սերվերի համար, ապա դրայվերը տեղադրելու կարիք չկա: Թողնել կամ հեռացնել դրոշը» Տեղադրեք պաշտպանիչ վարորդը«և սեղմեք» Հետագա».

Հաճախ 1C:Enterprise սերվերի հետ միասին մեքենայի վրա աշխատում են այլ ծառայություններ՝ տերմինալային սերվեր, SQL սերվեր և այլն: Եվ ինչ-որ պահի 1C:Enterprise սերվերը, ավելի ճիշտ՝ rphost worker պրոցեսը, ավելի շատ հիշողություն է խլում, քան նախատեսված էր կամ ամբողջ հիշողությունը: Ինչը հանգեցնում է այլ ծառայությունների և սերվերի զոմբիացման դանդաղեցմանը: Նման իրավիճակներից խուսափելու համար անհրաժեշտ է կարգավորել 1C:Enterprise սերվերի աշխատանքային հոսքերի ավտոմատ վերագործարկումը:

Լուծում

1. Բացեք 1C Enterprise սերվերների կառավարման վահանակը;
2. Ընդարձակեք կենտրոնական սերվերի ծառը դեպի կլաստերներ և ընտրեք մեզ հետաքրքրող կլաստերը: Օրինակում կա միայն մեկ կլաստեր.
3. Բացեք ընտրված կլաստերի հատկությունները և տեսեք հետևյալ ձևը

1C:Enterprise 8.3 սերվերի կլաստերի հատկությունները

Դիտարկենք նկարում ներկայացված օրինակը.

Վերագործարկման ընդմիջում— ժամանակ, որից հետո rphost գործընթացը հարկադրված կլինի վերագործարկել: Մինչ գործընթացի ավարտը գործարկվում է նոր rphost պրոցես, որին փոխանցվում են բոլոր կապերը, և միայն դրանից հետո հին գործընթացը կդադարեցվի։ Սա որևէ կերպ չի ազդի օգտատիրոջ փորձի վրա: Ընդմիջումը նշված է վայրկյաններով, օրինակում՝ 24 ժամ:

Թույլատրված հիշողության չափը— հիշողության ծավալը, որի շրջանակներում աշխատանքային հոսքը կարող է աշխատել առանց խնդիրների: Ծավալը նշված է կիլոբայթներով, օրինակում արժեքը 20 գիգաբայթ է (իրականում, թիվը չափազանց մեծ է, և դուք պետք է սկսեք կոնկրետ համակարգից, բայց միջին ցուցանիշը 4 ԳԲ է): Հենց որ աշխատանքային գործընթացի զբաղեցրած հիշողությունը գերազանցի նշված արժեքը, սկսվում է հետհաշվարկը:

Հիշողության թույլատրելի քանակի գերազանցման ընդմիջում— այն բանից հետո, երբ հիշողության թույլատրելի քանակությունը գերազանցելուց հետո գործարկված ժմչփը կհաշվի նշված ժամանակը, կգործարկվի աշխատանքային նոր գործընթաց, որին փոխանցվում են բոլոր կապերը, հին գործընթացը նշվում է որպես անջատված: Ընդմիջումը նշված է վայրկյաններով, օրինակում նշված է 30 վայրկյան:

Դադարեցրեք անջատված գործընթացները հետո— այն ժամանակը, որից հետո որպես անջատված նշված աշխատանքային հոսքը կդադարեցվի, եթե արժեքը 0 է, գործընթացը չի ավարտվի: Ընդմիջումը նշված է վայրկյաններով, օրինակում նշված է 60 վայրկյան:

Պարամետրերը կիրառելուց հետո դուք ստիպված չեք լինի վերագործարկել սերվերի ծառայությունը, դրանք կիրառվում են դինամիկ:

Ընդամենը

Այսպես մենք կարգավորում ենք 1C:Enterprise սերվերի աշխատանքային պրոցեսների ավտոմատ վերագործարկումը և ստանում ավելի կայուն համակարգ, եթե հիշողության արտահոսք տեղի ունենա, կոնկրետ նիստի աշխատանքը կդադարեցվի։

Բացի այդ, որոշ իրավիճակներում դուք կարող եք խաղալ կարգավորումների հետ և կանխել սերվերի հնարավոր խափանումը, եթե սխալներ թույլ տաք: