Menü
Ingyenes
bejegyzés
itthon  /  TOVÁBB/ Szükségünk van a vállalat 1c szerverére. Megoldások

Szükségünk van a vállalat 1c szerverére. Megoldások

Mára az 1C pénzügyi termék a könyvelésre szolgáló számviteli szoftverből egy széles formátumú komplexummá nőtte ki magát, amely szinte bármilyen típusú vállalkozás könyvelésére és karbantartására szolgál, és azt állítja, hogy versenyez a világ „szörnyeivel”, az SAP R / 3-val és a Microsoft Dynamics AX-vel. (Axapta).

Az orosz vállalatok egyre inkább modern konfigurációk segítségével szervezik meg üzleti folyamataikat 1C 8.3 „Kereskedelmi menedzsment”, „Termelésmenedzsment”, „ERP Vállalati menedzsment”és a hasonlók. A számviteli, marketing, termelési, értékesítési részlegek átkerülnek az 1C-be, folyamatban van az IP-telefóniával és a munkafolyamat-rendszerekkel való integráció. A „dolgozzunk 1C-ben” szándékok után azonban azonnal felmerülnek a kérdések – milyen erőforrásokon fog működni a központi 1C bázis, milyen „hardver” mutatja az optimális eredményt ésszerű költségvetés mellett? A közszféra óriásainak könnyebb dolguk ebben a helyzetben - számos főállású informatikai integrátor és építész kapott egyértelmű parancsot, elindultak a nagy költségvetésű pályázatok mechanizmusai, kötelező feltétellel a „kulcsrakész” koncepció, ill. a rendszer további támogatása minősített szakemberek által. De mi a helyzet a cégekkel, amelyek maguk akarják megvásárolni és telepíteni az 1C: Enterprise termékek valamelyikét, és okosan költik el a költségvetést?

A legalapvetőbb hiba, ha nem veszi figyelembe a kalóz vagy nem ellenőrzött szoftverek használatát, a hardver megtakarítása az 1C számára. Ezek a trendek különösen gyakoriak a startupoknál és a kisvállalatoknál. Van olyan vélemény, hogy nem kell drága szerverberendezéseket vásárolni Intel Xeon processzorokkal, nem kell előre kalkulálni a RAM mennyiségével, a CPU és a lemez alrendszer terhelésével, nem kell redundanciát létrehozni. lemeztömbök (Raid), használjon professzionális lemezvezérlőket Cache-RAM-mal stb. Az 1C informatikai architektúrájának számítási hibái szomorú következményekkel járnak, amelyekről a vállalat az üzleti folyamatok leállítása után értesül. Ezért nagyon fontos odafigyelni az 1C szerverplatformjának minden hardvercsomópontjára.

Példák az 1C informatikai architektúrájának nem megfelelő felépítéséből adódó tipikus problémákra:
  • Az alap és 1C interfészek "lassulása" a kulcsfontosságú erőforrások (általában RAM vagy lemez alrendszer) túlzott terhelése miatt.
  • Az 1C program hibái és "összeomlása" a helytelenül kiválasztott berendezés instabilitása miatt.
  • A cég leállása a központi hardver meghibásodása miatt.
  • Az 1C adatok részleges vagy teljes elvesztése a hardverkomponensek vagy szoftverek véletlenszerű meghibásodása miatt.

1C szerver hardver erőforrások

Tekintse meg az alábbiakban a legfontosabb hardver-erőforrásokat, amelyek megválasztásának hibája tönkreteheti a teljes vállalati automatizálási projektet, amikor önállóan hoz létre egy kiszolgálót az 1C számára.

Központi feldolgozó egység (CPU)

A fizikai CPU magok száma. Az örök viták témája mindenféle fórumon az 1C-n - melyik a fontosabb CPU frekvencia vagy többmagos. Ezeknek az ellentmondásoknak a gyökerei az 1C 8.0-ra vagy akár az 1C 7.7-re nyúlnak vissza. Valóban, a korábbi verziók 1C futtatható folyamatai tisztán egymagosak voltak, pl. függetlenül attól, hogy hány magot biztosít a központi processzor - az 1C 8.0 vállalati szerverszolgáltatás vagy az 1C 7.7 vastag kliens mindig csak egy „nulla” magot foglalt el az operációs rendszerben. Mára a kép megváltozott - az operációs rendszer bátran osztja el egy 1C: Enterprise process (rphost) feladatait több CPU mag között (lásd 1. ábra).




1. ábra - CPU terhelés az 1C szerver folyamatai során.


De ez egyáltalán nem jelenti azt, hogy ha maximális számú maggal rendelkező processzort vásárol, akkor egy DBMS-sel párosított 1C szerver (leggyakrabban a DBMS jelentése MS SQL) fantasztikus teljesítményt fog mutatni, és az elszámolási időszakok 1C-ben történő átírása megtörténik. néhány perc kérdése. Meg kell értenie a különbséget egy művelet végrehajtásának sebessége és a nagy mennyiségű információ egyidejű feldolgozásának folyamata között. A fizikai magok száma csak lehetővé teszi, hogy megoldja az 1C: Enterprise szerver és a DBMS sok különböző feladattal végzett egyidejű munka stabilitásának és teljesítményének kérdését. Ebből következik a következtetés: minél több az 1C felhasználó, annál nagyobb szerepet fog játszani a szükséges számú mag ezen felhasználók kényelmes egyidejű munkájában. A felhasználók számának függőségét az 1C szerver magjainak számától az 1. táblázat mutatja.


Az egyidejű felhasználók száma az 1C: Enterprise szerveren Processzor típusa és modellje A felhasznált magok száma
Akár 10 felhasználó Egyedi Intel Core 3,1 GHz-től Legfeljebb 2-4
Akár 20 felhasználó Intel Xeon szerver 2,4 Ghz-től 4-től 6-ig
Akár 30 felhasználó Intel Xeon szerver 2,6 Ghz-től 6-8 mag
Akár 50 felhasználó Intel Xeon szerver 2,4 Ghz-től - 2 darab mennyiségben 4 minden processzorhoz

1. táblázat – Az 1C szerver felhasználói számának és a CPU magok ajánlott számának aránya.


CPU frekvencia. A magok számával ellentétben a központi processzor frekvenciája pontosan befolyásolja a munka egy darabjának feldolgozási sebességét egyszerre, ami a legnépszerűbb kritérium az 1C végfelhasználói számára. A processzor frekvenciája pontosan az a paraméter, amelynek növekedésével az egyes felhasználók számára megnő az 1C szerver és a DBMS kérések feldolgozásának sebessége, és az az idő, ameddig a rendszer megadja a végeredményt a végfelhasználónak. csökken. Ennek megerősítésére a jól ismert szakember, Gilev az egyik cikkében, gyakorlati tesztek alapján, egyértelmű következtetést vont le - "az 1C sebességét sokkal jobban befolyásolja a központi processzor frekvenciája, mint a többi paramétere. , legyen szó 1C végkliensről vagy 1C: Enterprise szerverről." Ez az 1C program architektúrája.

Gyorsítótár, virtualizáció és hiperszál-fűzés. Régebben, amikor a többmagos processzorok még nem voltak elterjedve, az Intel egy speciális CPU-technológiával rukkolt elő, amely a többmagos működést utánozza, az úgynevezett "hiperszálazást". Ha engedélyezve van, az operációs rendszer egy fizikai processzort (egy fizikai magot) két külön processzorként (két logikai magként) határoz meg. Javasoljuk, hogy tiltsa le a hiperszálakat az 1C szerveren. Ez a technológia nem gyorsítja fel az 1C munkáját.

Amikor virtuális gépeket használ az 1C: Enterprise szerverhez és a DBMS-hez, figyelembe kell vennie, hogy a virtuális gépek kernelei "gyengébbek", mint a valódi fizikai kernelek, bár ugyanazon a néven - "kernelek". Pontos hivatalos együtthatók nincsenek, de a Microsoft műszaki portáljain megjelent cikkek azt javasolják, hogy fizikai magonként 4-6 processzormagot számoljanak egy virtuális gépben.

A gyorsítótár a processzor által a számítógép memóriájához való átlagos hozzáférési idő csökkentésére használt gyorsítótár. Valójában ez a processzor szerves része, mivel ugyanazon a szerszámon található, és a funkcionális blokkok része. Itt minden nagyon világos - minél nagyobb a gyorsítótár mérete, annál nagyobb "darabokat" tud feldolgozni a processzor. A gyorsítótár mérete általában a processzormodelltől függ – minél drágább a modell, annál több a gyorsítótár. Nem hisszük azonban, hogy a processzor gyorsítótárának mérete drámaian befolyásolja az 1C szerver és a DBMS teljesítményét. Inkább a "finomhangolás" területére utal.

Processzor típusa. Mindenki tudja, hogy a hardver fel van osztva szerverre és felhasználóra. Lehetséges bizonyos esetekben olcsó egyedi CPU használata a professzionális, de drága szerver CPU alternatívájaként? Kiderült – lehet. Tekintsünk egy táblázatot, amely összehasonlítja az Intel központi processzorainak két változatának fő paramétereit (lásd a 2. táblázatot).

Egyedi Intel® Core™ i7-6700T processzor (8M gyorsítótár, akár 3,60 GHz) Szerver Intel® Xeon® processzor E5-2680 v2 (25M gyorsítótár, 2,80 GHz)
Cache memória 8 MB 25 MB
Rendszerbusz-frekvencia 8 GT / s DMI3 8 GT/s QPI
Parancskészlet 64 bites SSE4.1 / 4.2, AVX 2.0 64 bites AVX 2.0
Magok száma 4 10
CPU alap órajele 2,8 GHz 2,8 GHz
Max. a RAM mennyisége és típusa 64 GB nem ECC 768 GB ECC
Becsült költség 354$ 1 280$

2. táblázat – Az otthoni és kiszolgálói CPU főbb paramétereinek összehasonlítása az Inteltől.


Amint látjuk, a szerverprocesszor sokkal magasabb értékekkel rendelkezik a magok számában, a gyorsítótár mennyiségében, támogatja a több RAM-ot és természetesen magasabb áron. A szerver CPU azonban gyakorlatilag nem különbözik a felhasználói CPU-tól bizonyos processzorparancsok (utasítások) támogatásában és az órajel frekvenciájában. Ebből arra következtethetünk, hogy kis szervezetek számára teljesen elfogadható egyéni CPU használata az 1C: Enterprise szerverhez. A kérdés csak az, hogy egyedi processzor nem telepíthető a szerver alaplapjának foglalatába, és támogatja a szerver RAM-ját paritásellenőrzéssel (ECC), és az egyedi összetevők használata a teljes rendszer egészének stabilitásának kockázatát hordozza magában.

Véletlen hozzáférésű memória (RAM)

RAM típus. A RAM (RAM) sáv rendeltetésében különbözik - többfelhasználós szerverrendszerekhez vagy személyes eszközökhöz - PC-k, laptopok, nettopok, vékony kliensek stb. Akárcsak a CPU esetében - a RAM modulok fő paraméterei nagyjából egyenértékűek - a modern PC RAM gyakorlatilag nem marad el a szerver RAM mögött sem egy bar mennyiségben, sem órajel frekvenciában, sem DDR típusban. modulok. A szerver RAM és az "otthoni" RAM közötti különbségek a hardverplatform használatában és céljában – ebből adódik a magasabb költsége:

  • A szerver RAM-ja ECC paritással (Error Correction Code) rendelkezik - egy kódolási / dekódolási technika, amely lehetővé teszi az információfeldolgozás hibáinak közvetlenül a RAM modul által történő javítását.
  • A szerver alaplapján sokkal több csatlakozó található a RAM modulok telepítéséhez, mint egy hagyományos PC-n
  • A kiszolgáló RAM-ja regisztereket (puffereket) tartalmaz, amelyek adatpufferelést biztosítanak (részlegesen regisztrált vagy teljes pufferelt), ezáltal csökkentve a memóriavezérlő terhelését sok egyidejű kéréssel. A pufferelt FB-DIMM-ek nem kompatibilisek a puffereletlenekkel.
  • A regisztermemória modulok lehetővé teszik a memória nagyobb skálázhatóságát is – a regiszterek jelenléte lehetővé teszi több modul telepítését egy csatornába.

Megállapíthatjuk, hogy a szerver RAM modulok használata lehetővé teszi nagy mennyiségű RAM telepítését egy rendszerbe, az ECC paritásvezérlési technikák és a pufferek használata pedig lehetővé teszi a szerver operációs rendszer stabil és gyors működését.

A RAM mennyisége. Az 1C szerver és a DBMS nagy teljesítményének egyik kulcstényezője a megfelelő mennyiségű RAM. Természetesen a RAM iránti tényleges igény sok tényezőtől függ - az 1C konfiguráció típusától, az 1C: Enterprise szerverfolyamatok számától, a DBMS adatbázis méretétől stb. Mindazonáltal levezethető a RAM mennyiségének hozzávetőleges függése a felhasználók számától (lásd a 3. táblázatot).


RAM szükségessége az 1c szerverhez és a DBMS-hez Akár 10 felhasználó Akár 20 felhasználó Akár 30 felhasználó Akár 50 felhasználó
1c szerver: Enterprise 4-6 GB 6-8 GB 12-14 GB 18-24 GB
MS SQL Server 4-6 GB 8-10 GB 16-18 GB 24-28 GB

3. táblázat - Az 1C szerver felhasználói számának és az 1C: Enterprise szerver és az MS SQL szerver folyamataihoz ajánlott RAM hozzávetőleges aránya.


Az 1C szerver folyamataival kapcsolatban: Enterprise (rphost.exe) - a modern 1C platformok nem teszik lehetővé az 1C szerverfolyamatok számának manuális megadását. Ehelyett a rendszer paramétereket igényel, például az infobázisok számát és az rphost.exe folyamatonkénti felhasználók számát, ami után automatikusan meghatározza az 1C: Enterprise szerverfolyamatok optimális számát. A RAM zökkenőmentes felszabadítását az rphost.exe folyamattal is beállíthatja, ha a mennyisége meghaladja az előre meghatározott küszöböt. Ezzel egyidejűleg az 1C szerver létrehoz egy új rphost.exe folyamatot, amely fokozatosan átveszi az 1C feladatokat, lehetővé téve a szükséges 1C folyamat kiürítését.

Azt is meg kell jegyezni, hogy az SQL szolgáltatáshoz lefoglalt RAM mennyisége akkor tekinthető elegendőnek, ha a gyorsítótárban elért SQL adatok legalább 90%-a. Ez a mérőszám meglehetősen kényelmes, mert nem láthatja egyszerűen az SQL szerver által fogyasztott RAM mennyiségét - az SQL legújabb kiadásai dinamikusan fogyasztottak RAM-ot - a RAM maximális lehetséges mennyiségét rögzíti és felszabadítja, amikor más folyamatok RAM-ot kérnek.

RAM frekvencia. Röviden, ez azoknak a csatornáknak a sávszélessége, amelyeken keresztül az adatok az alaplapra, majd onnan a processzorra kerülnek. Kívánatos, hogy ez a paraméter egybeessen az alaplap megengedett frekvenciájával, vagy meghaladja azt, különben a RAM átviteli csatornája "szűk keresztmetszet" lesz. Az egyik típusú DDR keretein belül a frekvencia növelése / csökkentése nem befolyásolja drasztikusan az 1C szerver teljesítményét, és inkább a "finomhangolás" területére vonatkozik.

RAM időzítése. Ez a RAM késleltetése vagy késleltetése. Ezt a paramétert az adatkésleltetési idő jellemzi a RAM mikroáramkör különböző moduljai közötti váltáskor. A kisebb értékek gyorsabb teljesítményt jelentenek. A szerverrendszer általános teljesítményére, és még inkább az 1C: Enterprise szerverre gyakorolt ​​hatás azonban nem nagy. Általában csak a játékosok és az overclockerek figyelnek ezekre a paraméterekre, akiknek minden extra teljesítménycsepp a legdrágább.

Lemez alrendszer és merevlemezek HDD

Merevlemez vezérlők. A merevlemezek hardverrendszerben történő csatlakoztatásának és rendszerezésének fő eszköze a merevlemez-vezérlő. Két típusa van:

1. Beépített - a vezérlő modul be van építve a rendszerbe, a merevlemezrekesz közvetlenül az alaplaphoz csatlakozik. Gazdaságosabb megoldásnak tartják.

2. Külső - egy külön nyomtatott áramköri kártya (eszköz), amely az alaplap csatlakozójához csatlakozik. Professzionális megoldásnak tekinthető, mivel külön chipekkel rendelkezik a merevlemezes HDD-vel végzett műveletek végrehajtásához és vezérléséhez. Fontos szerverrendszerekhez ajánlott, mint például az 1C: Enterprise szerver és DBMS.

Van egy harmadik típus is - blokkadatok fogadására / továbbítására szolgáló eszköz iSCSI, FiberChanel, InfiniBand, SAS csatornákon keresztül. Azonban ebben a kiviteli alakban a lemez alrendszert egy különálló tárolóeszközre (DSS) „kiveszi”, amely optikai vagy rézkábellel csatlakozik a szerverhez. Cikkünkben elemezzük az 1C autonóm szerverének követelményeit, ezért ezt a típust nem vesszük figyelembe.

A RAID-tömbök típusai és szintjei. Ez egy adatvirtualizációs technológia, amely több lemezt egyesít logikai egységgé a redundancia és a jobb teljesítmény érdekében. Vessünk egy pillantást a RAID specifikáció legnépszerűbb szintjeire:

  • RAID 0 ("csíkozás") nincs redundanciája, és kis blokkok ("csíkok") formájában egyszerre osztja el az információkat a tömbben lévő összes lemezen. Ez jelentősen javítja a teljesítményt, de veszélyezteti a megbízhatóságot. A teljesítménynövekedés ellenére nem javasoljuk ennek a tömbtípusnak a használatát.
  • RAID 1 ("tükrözés", "tükör"). Védelmet nyújt a rendelkezésre álló hardver felének (általában a két merevlemez egyikének) meghibásodása ellen, elfogadható írási sebességet és olvasási sebességnövekedést biztosít a kérések párhuzamosítása miatt. Ez a fajta tömb eléggé "lehúz" egy 1C + DBMS szervert 25-30 felhasználóig, különösen, ha SAS 15K meghajtókat vagy SSD-ket használnak.
  • RAID 10. A tükrözött meghajtópárok „láncba” helyezkednek el, így az így kapott kötet meghaladhatja egyetlen merevlemez kapacitását. Véleményünk szerint a legsikeresebb lemeztömb típus, hiszen ötvözi a RAID1 megbízhatóságát és a RAID 0 sebességét. 15K SAS meghajtókkal vagy SSD-vel kombinálva 40-50 felhasználó 1C szervereihez használható.
  • RAID 5. Híres gazdaságáról. Ha csak egy meghajtó kapacitását áldozzuk fel a tömbből a redundancia érdekében, védelmet kapunk a rendszerben lévő bármelyik merevlemez meghibásodása ellen. (A RAID 6-os változata két extra merevlemezt igényel az ellenőrző összegek fogadásához, de megőrzi az adatokat akkor is, ha két meghajtó meghibásodik). Az ilyen típusú tömb gazdaságos, megbízható és meglehetősen észrevehető olvasási teljesítménnyel rendelkezik. Sajnos ennek a tömbnek a szűk keresztmetszete az alacsony írási sebesség, ami kényelmessé teszi az 1C szerverkonfigurációkkal való használatát akár 15-20 felhasználó számára. Alkalmazott célokra is optimális - fájladatok tárolása, dokumentumfolyamat-archívumok stb.

Merevlemez interfész típusok. A csatlakozás típusa szerint a merevlemezek fel vannak osztva:

  • HDD Sata Home. A merevlemezek legolcsóbb változata, amelyet otthoni számítógépekben vagy hálózati médiaközpontokban való használatra terveztek. Erősen nem ajánlott ilyen eszközöket használni az 1c szerverekben az alacsony hibatűrés és a működés stabilitása miatt - ezeknek a meghajtóknak az alkatrészeit egyszerűen nem 24 órás működésre tervezték, és gyorsan meghibásodnak.
  • HDD Sata szerver. Ez a név általában a Sata interfésszel rendelkező, 7200 ford./perc orsófordulatszámú merevlemezekre utal. A "Server" előtag azt jelenti, hogy az ilyen meghajtókat tesztelték a szerverrendszerekben való működőképesség szempontjából, és úgy tervezték, hogy stabilan, a hét minden napján, 24 órában működjenek. Általában az 1C szerverekben használják nagy mennyiségű információ tárolására, amely nem igényel nagy feldolgozási sebességet. Például - 1c archív adatbázisok, cseremappák, irodai dokumentumok feltöltési fájlok stb.
  • HDD SAS szerver. Számos különbség van a SAS interfész (az SCSI modern analógja) és a Sata interfész között. Ez az átlagos lemezválaszidő, és a munka egy megosztott lemezpolcon, és a HDD-vezérlővel nagyobb adatcsere-sebességgel dolgozik - akár 6 Gb / s (a Sata 3 Gb / s-hoz képest). A fő előny azonban a 15 000 ford./perc orsófordulatszámú SAS-lemezes modellek létezése. Ez a tervezési funkció teszi lehetővé, hogy a SAS meghajtók csaknem háromszor több I/O műveletet hajtsanak végre másodpercenként, mint a HDD Sata Server. Az ilyen SAS-lemezek kis térfogatúak, és állandóan nagy munkaterhelésű alap 1c adatbázisokhoz ajánlott használni.
  • SSD meghajtók. Ezek a lemezek nem a csatlakozási felületben, hanem kialakításukban térnek el a korábbiaktól - szilárdtestek és nincsenek mozgó alkatrészeik, pl. lényegükben a "flash drive" analógjai. Az ilyen technológiák lehetővé teszik, hogy az SSD-lemezek "tiltó" számú I / O műveletet hajtsanak végre másodpercenként (a legegyszerűbb SSD-modellek 10 000 műveletétől kezdve). Ennek az előnynek azonban van egy árnyoldala is - az SSD-meghajtók magasabb ára és az "élettartam küszöbe", amely az SSD blokkokra való írási szám határától függ. Ezek a lemezek azonban évről évre egyre olcsóbbak és tartósabbak. Mivel az SSD lemezek költsége a mérettől függően sokszorosára nő, ezért a legésszerűbb kisméretű, de túlterhelt, nagy hozzáférési sebességet igénylő 1c adatbázisokhoz, valamint a TempDB DBMS ideiglenes adatbázisaihoz használni őket.

Az IOPS a bemeneti-kimeneti műveletek száma másodpercenként. Valójában az IOPS azon információblokkok száma, amelyek 1 másodperc alatt olvashatók vagy írhatók egy adathordozóra. Vagyis tiszta formájában - ez a merevlemez információfeldolgozási sebességének kulcsparamétere, amely befolyásolja az 1C szerver teljesítményét. Ha összehasonlításul egy 4 kb-os szabványos információs blokkot veszünk, akkor nagyjából a következő IOPS mutatókat tudjuk kiemelni (lásd 4. táblázat).


HDD IOPS Felület
7200 rpm SATA meghajtók ~ 75-100 IOPS SATA 3Gb/s
10 000 rpm SATA meghajtók ~ 125-150 IOPS SATA 3Gb/s
10 000 ford./perc SAS meghajtók ~ 140 IOPS SAS
15 000 ford./perc SAS meghajtók ~ 175-210 IOPS SAS
SSD meghajtók 8000 IOPS-től SAS vagy SATA

4. táblázat - Az IOPS mutatói különböző típusú merevlemezeken 4 KB-os adatblokk használatakor.


Természetesen tiszta formájában az IOPS nem túl hasznos az 1C szerver lemezalrendszerére vonatkozó végső számítások és követelmények kiszámításához. Végül is a lemezalrendszer teljes teljesítménye a RAID-tömb típusából, a lemeztípusokból és az interfész sebességének mutatóiból, a válaszidőből (latencia), a véletlen hozzáférési időből, az olvasási és írási műveletek számának százalékos arányából áll, és sok más tényező. Ez a paraméter azonban véleményünk szerint a lemezalrendszer sebességének kulcsmutatója, és a szerverarchitektúra fejlesztésének szakaszában segít meghatározni, hogy általában milyen típusú merevlemezek a legalkalmasabbak bizonyos igényekhez. (lásd RAID kalkulátor)

Gyakorlati teszt

Mi a kapcsolat az 1C felhasználók száma és az iop-ok száma között? Csapatunk gyakorlati tesztet végzett (lásd az 5. táblázatot), hogy megmérje a lemez alrendszer terhelését bizonyos számú 1C munkamenettel. Mivel az 1C rendszer programozható környezet, és minden vállalatnak saját üzleti folyamatai lehetnek az 1C-ben, a teszteléshez egy bizonyos referenciakonfigurációhoz kellett kapcsolódnunk. Ebben a minőségben az MCC 1C speciális konfigurációját választották, amelyet tesztelésre és hibakeresésre fejlesztettek ki. Ennek alapján 1C programozóink számos olyan kérést adtak hozzá, amelyek egy átlagos vállalkozás normál működését szimulálják, számviteli lekérdezések, könyvelések, jelentések elkészítése és működési dokumentumok vezetésével.


Rendszerlemez Adatbázis lemez
Ismétlés Felhasználók IOPS írás IOPS olvasott IOPS írás IOPS olvasott
Átlagos értékek
1 12 9,1 0,1 13,1 1,5
2 20 7,9 0,1 21,8 0,4
3 32 5,2 0,006 36,1 5,2
4 40 7,7 0,013 27,52 1,3
5 52 7,7 0,006 32,04 0,94

5. táblázat – A lemezalrendszer terhelésére vonatkozó gyakorlati teszt eredményei.


A teszteredmények azt mutatják, hogy a lemezalrendszer terhelésének oroszlánrésze akkor következik be, amikor az 1C-t a DBMS-kiszolgáló adatbázisába és az operációs rendszer lemezére írják (amelyen alapértelmezés szerint az 1C: Enterprise cache-kiszolgáló fájljai találhatók).

Ezzel párhuzamosan a már működő 1C UPP 8.2 bázisokon gyakorlati méréseket végeztünk a tesztidőszak alatt - 5 munkanap. Azt mutatják, hogy egy 1C + DBMS szerver átlagosan kétszer annyi iops-t fogyaszt „íráshoz”, mint „olvasáshoz”. Ez a különbség a szintetikus tesztek és a valódi 1C-szerver megfigyelésére szolgáló statisztikák között az adatbázisból származó információs adatokból a munkanap során történő időszakos mintavételéből, valamint az adatbázis rendszeres olvasásának köszönhető a DBMS biztonsági mentése vagy replikálása során.

A merevlemez egyéb részeire figyelni kell.

  • Fizikai méret (formafaktor). Ma szinte minden ismert személyi számítógéphez és szerverhez való meghajtó 3,5 vagy 2,5 hüvelykes méretű. Vegye figyelembe, hogy a 2,5 hüvelykes lemezeket nem gyártják nagy mennyiségben.
  • Véletlenszerű hozzáférési idő- az az idő, ameddig a merevlemez garantáltan olvasási-írási műveletet hajt végre a mágneslemez egy bizonyos területén. Általános szabály, hogy a szervermeghajtók jobb eredményeket adnak. Ez egy meglehetősen fontos paraméter, amikor egy 1C DBMS-kiszolgálóhoz lemeztömböt építünk.
  • Orsó fordulatszám- a merevlemez-orsó percenkénti fordulatszáma. Itt minden egyszerű és világos - a merevlemez hozzáférési ideje és átlagos adatátviteli sebessége az orsó mágneses tányérokkal történő forgási sebességétől függ.
  • Merevlemez puffer mérete- a puffer egy ideiglenes memória, amelyet a merevlemez olvasási/írási sebességében és az interfészen keresztüli adatátvitelben tapasztalható különbségek kiegyenlítésére terveztek.
  • Megbízhatóság- a meghibásodások közötti átlagos idő (MTBF). A megbízhatóság jellemzően közvetlenül függ a merevlemez gyártójától, árától és használati környezetétől. A megbízhatóságot a merevlemez fontos paraméterének tartjuk, amely befolyásolja az 1C szerver működésének minőségét.

A megfelelő választás: otthoni vagy szerver hardver

A hardverösszetevők olcsóbbá válása és az „otthoni számítógépek” potenciális kapacitásának aktív növekedése egy újabb veszedelmes téveszméhez vezet – a kisvállalkozások aktívan használják a munkaállomásokat az 1C adatbázisokkal való együttműködés platformjaként. Ugyanakkor anélkül, hogy észrevennénk, hogy a magfrekvencia, a memória mérete és a pénztárcabarát SSD-meghajtók hagyományos PC-ben való használatának lehetőségén túlmenően rendszerszintűbb, mélyebb és fontosabb követelmények is vannak a hardver működésével szemben. kereskedelmi szerkezet (lásd 6. táblázat).

Az 1C szerver megszervezésével kapcsolatos probléma megoldása érdekében 1C felhőszervereket bérelünk Tier III adatközpontokban. A szerverbérlet kiválasztásának gazdasági megvalósíthatóságáról a cikkben olvashat.


Lehetőségek szerver Személyi számítógép
A számítási teljesítmény elegendősége V V
Garantált rendszer üzemidő a hét minden napján, 24 órában V x
A kulcsfontosságú hardverelemek megbízhatósága és stabilitása V x
Távoli Power & Console Management (IPMI) képesség V x
A hardverplatform költségvetési költsége x V

6. táblázat - Az otthoni és szerver hardverek összehasonlítása a jó minőségű 1C szerver működéshez szükséges kritériumok szerint.

Az 1C hibamentes működése

Kétségtelen, hogy az 1C szerver része számára az egyik fontos követelmény a működés stabilitása és a hibákkal szembeni ellenálló képessége. A Microsoft és maga az 1C is sok erőfeszítést tett ebbe az irányba, és olyan technológiákat hoztak létre, amelyek szolgáltatásaik meglehetősen komoly szintű klaszterezésére szolgálnak (lásd a 7. táblázatot).


SQL szerverek hibatűrése Az egyetlen megosztott adattárház koncepciója alapján. A beépített SQL Server fürtözési technológia két SQL-kiszolgálót egyesít egyetlen fürtben egyetlen virtuális IP-címmel és egyetlen bázissal. Így, ha a fő SQL meghibásodik, a lekérdezések automatikusan átkerülnek a biztonsági másolatba.
A második lehetőség a nemrég bemutatott AlwaysOn, az elsődleges és a készenléti SQL-kiszolgálók közötti automatikus rendszeres adatbázis-replikáció technológia. Ugyanakkor a duplikált SQL-kiszolgáló fizikailag egy másik tárolón található, ami növeli a kockázatokkal szembeni ellenálló képességet.
Az 1C: Enterprise szerverszolgáltatás hibatűrése Az 1C Enterprise szervereket egy aktív-aktív szoftveres feladatátvételi fürtté egyesítik, automatikus feladatátvétellel és az aktuális munkamenetek mentésével.

7. táblázat – SQL és 1C szerverek hibatűrése.


Azonban minden technológiának vannak előnyei és hátrányai is. A kulcsfontosságú előnyök mellett ismernie kell az 1C és SQL () fürtözés néhány jellemzőjét, hogy a végén ne romoljon a szolgáltatás teljesítménye:

  • Az SQL-fürtözés virtuális IP-t használ. Ez azt jelenti, hogy az 1C: Enterprise szerver és az MS SQL közötti interakció mindig a hálózati interfészen keresztül történik, még akkor is, ha mindkét szolgáltatás ugyanabban az operációs rendszerben van. Ami ennek megfelelően az 1C munkájának lelassulásához vezet, összehasonlítva az architektúra klasszikus verziójával, amelyet maga az 1C ajánlott - megosztott memória megosztott memória használatával. Ez az akadály elvileg "kikerülhető" például az MS SQL Log Shipping technológia használatával. Ebben az esetben azonban a készenléti SQL szerverre való váltás már nem lesz automatikus, és ez az opció nem tekinthető teljes értékű fürtnek.
  • Az SQL Cluster nagy költségvetési befektetés. Ha az MS SQL szolgáltatás klasszikus klaszterezéséről beszélünk, akkor a fő és a tartalék SQL szerverekhez kapcsolódó egységes adatbázis-tárolás szükséges. Általában ezt a szerepet a drága tárolórendszerek töltik be, ami nagyságrenddel növeli a költségvetést. Ha az újdonsült AlwaysOn-ról beszélünk, akkor nincs szükség egységes adatbázis-tárolóra, a technológia az elsődleges és a tartalék szerverek helyi lemezeivel működik a hálózaton keresztül. Ehelyett az SQL Server vállalati verziójára van szükség, amely négyszer többe kerül, mint egy normál SQL Server StandardD licenc.
  • Az engedélyek száma. Annak ellenére, hogy a második SQL-kiszolgáló nem dolgoz fel adatokat, és tartalékban van, mindkét kiszolgálóhoz licencet kell vásárolni - mind az elsődleges, mind a tartalék kiszolgálóhoz. Különösen költségesek az SQL Server Enterprise licencek az AlwaysOn magas rendelkezésre állási csoportok elosztott fürtjének megvalósításához.
  • Nem kell olcsó egyedi hardvert használnia egy olyan fontos szolgáltatáshoz, mint egy vállalati szintű könyvelési rendszer. Ebben az esetben az ár közvetlenül meghatározza egy ilyen platform minőségét, stabilitását és tartósságát.
  • Szerverplatform kiválasztásakor javasoljuk, hogy figyeljen két tápegység, egy távoli IPMI kártya és a gyártó márkájának meglétére. Természetesen mindenki a pénztárcája alapján választ megoldást, a csúcsmárkák néha túl drágák és nem is teljesen megfelelőek, de nem nagyon érdemes spórolni a gyártón, ez irányíthatatlan vis maiorhoz vezethet az 1C-vel való munka során. Személyesen használjuk a Supermicro szerverplatformokat az Intel szerver CPU-kkal együtt.
  • A gyakorlat által megerősített vélemény szerint az 1C teljesítménye jobban függ a magasabb CPU frekvenciától, mint a biztosított magok számától.
  • Nem kell spórolni az 1C szerver és az SQL szolgáltatás számára lefoglalt RAM mennyiségén. Jelenleg a RAM meglehetősen olcsó erőforrás, és hiánya (akár 10-15 százalékkal is) az 1C rendszer teljesítményének erőteljes csökkenéséhez vezet, mert a lassabb csererendszer bekapcsol. Ráadásul a swap további terhelést jelent a lemez alrendszerére, ami tovább rontja a helyzetet.
  • Az EFSOL átfogó szolgáltatásokat kínál az 1C szerver kiválasztásához, amely magában foglalja az 1C szerver tervezését, beszerzését, konfigurálását és karbantartását.
  • Az 1C szerver saját létrehozásának alternatívája, ha bérel egy szervert az 1C számára. A felhőtechnológiák lehetővé teszik, hogy alacsony havi költségek mellett megbízható, hibatűrő szolgáltatást kapjunk a kényelmes munkavégzéshez 1C-ben.

Rendszerintegráció. Tanácsadó

Amikor kiválasztja, hogy melyik szerverre van szükség az 1C-hez, ne feledje, hogy miközben a felhasználók ezzel dolgoznak, másodpercenként sok adatolvasási és -írási műveletet hajtanak végre.

Valószínűleg azonnal világos, hogy miért olyan fontos az 1C szerver helyes tervezése - ha a hardvert kezdetben rosszul választották ki, és nem felel meg a rendszer terhelésének, akkor fennáll annak a veszélye, hogy vagy akár szakaszosan is működik, fontos adatok elvesznek. Másrészt az 1C-hez szerver létrehozása, a hozzá tartozó összes hardver és szoftver megvásárlása jelentős összegbe kerülhet a cégnek, ezért célszerű a felszerelést úgy kiválasztani, hogy elkerüljük a felesleges költségeket.

Szerver kiválasztása 1C-hez

Amikor szakembereinknek ki kell választaniuk az 1C szerver konfigurációját, először azt kérdezik, hogy hány felhasználó fog dolgozni az 1C-vel a vállalatnál, és milyen szolgáltatáskészletet terveznek használni, mik lesznek, kik és hogyan. adminisztrálja az 1C szervereket. Ezekre az információkra alapozunk az 1C szerver létrehozásakor.

Szerverkövetelmények 1C

Az 1C szerver hardverszerkezetében a processzor, a RAM, a lemez alrendszer és a hálózati interfészek jellemzői lesznek fontosak számunkra.

Szükséges, hogy a következő alkatrészek stabil és kellően produktív működését biztosítsák:

  • operációs rendszer;
  • adatbázis-kiszolgáló (leggyakrabban az);
  • az 1C szerver része (nem minden esetben, mivel egy 2-10 felhasználós kis cég képes dolgozni az 1C-vel fájlmódban);
  • felhasználói munka távoli asztal módban;
  • távoli felhasználók munkája vékony kliensen vagy webes kliensen keresztül.

Processzor kiválasztása 1C szerverhez

A processzormagok optimális számát általában az alapján számítják ki, hogy 1-2 magot le kell foglalni az operációs rendszer működéséhez, 1-2 magot az SQL adatbázis működéséhez, további 1 magot az alkalmazásszerver működéséhez és kb. 1 mag minden 8-10 egyidejű felhasználói munkamenethez (hogy a felhasználók később ne panaszkodjanak az 1C szerver lelassulására).

Felhívjuk figyelmét, hogy a kérések feldolgozási sebessége nem annyira a magok számától, mint inkább a processzor órajelétől függ, és a magok száma nagyobb hatással van a nagyszámú felhasználóval végzett munka stabilitására és a tőlük érkező egyidejű feladatokra.

Mennyi memóriára van szüksége az 1C szervernek?

A fentieken túlmenően, ha szüksége van egy 1C-kiszolgálóra 100 vagy több felhasználó számára, javasoljuk, hogy telepítsen legalább két fizikai 1C-szerverből álló fürtöt.

Javasoljuk a szükséges RAM méretének kiszámítását a következő mutatók alapján:

  • Az operációs rendszer működéséhez 2 GB szükséges
  • legalább 2 GB az MS SQL Server gyorsítótárának működéséhez, és jobb, ha ez az érték az adatbázis valós mennyiségének 20-30% -a - ez biztosítja a felhasználók kényelmes munkáját vele
  • 1-4 GB 1C alkalmazásszerverhez
  • 100-250 MB egy felhasználói terminál munkamenetet igényel, az 1C szerver funkciókészletétől és a használt konfigurációtól függően

Adjuk meg hozzávetőleges számításainkat az 1C 8.3 szerver paramétereiről:

Jobb, ha a RAM-ot árréssel vásárolja meg - ez az egyik legfontosabb tényező az 1C szerver nagy teljesítményében, és ugyanakkor most az egyik legolcsóbb összetevő. Ha nincs elég memória az 1C Enterprise szerveren, az nagyon észrevehető lesz működés közben, ezért amikor az a kérdés, hogy melyik 1C szervert válasszuk, mindig figyeljünk arra, hogy van-e elég RAM.

1C szerver: hardver a lemez alrendszerhez

Amikor kiválasztja, hogy melyik szerverre van szükség az 1C-hez, ne feledje, hogy miközben a felhasználók ezzel dolgoznak, másodpercenként sok adatolvasási és -írási műveletet hajtanak végre. Ez a paraméter – hogy milyen sebességgel tudja feldolgozni a merevlemez az adatokat – szintén az 1C szerver teljesítményének egyik kulcsparamétere.

Az 1C szerver tervezésekor a lemezalrendszer hardverére vonatkozó követelményeket javasoljuk, hogy tartsa be a következőket:

  • Nem számít, milyen szervert hoz létre az 1C-hez, semmi esetre sem javasoljuk egyedi lemezek használatát a szerverekben – célszerű ezeket RAID tömbökbe rendezni (RAID 10 nagy adatbázisokhoz vagy RAID 1 kis adatbázisokhoz), ahol az adatbázistáblák található.
  • Javasoljuk, hogy helyezze át az indexfájlokat egy külön SSD-re a gyorsabb hozzáférés érdekében.
  • TempDB - 1-2 (RAID 1) SSD.
  • Helyezze az operációs rendszert és a felhasználói adatokat a RAID 1-re SSD-ről/HDD-ről.
  • Rendeljen külön logikai meghajtót a tömbből vagy egy fizikai SSD-meghajtót a naplófájlok számára.
  • Amikor csak lehetséges, használjon hardveres vezérlőt – láttunk már olyan helyzeteket, amikor egy erős és drága szerver lelassult a vezérlő elégtelen teljesítménye miatt.

Szerver kiválasztása 1C-hez

Ebben a cikkben néhány tippet és hozzávetőleges számításokat adtunk az 1C szerver kiválasztásához, reméljük, hasznosak lesznek az Ön számára.

Végezetül hozzáteszünk még egy dolgot - ne próbáljon pénzt megtakarítani, ha az 1C szerverhez felhasználói számítógépet használ (ahogy ezt gyakran teszik a kis cégeknél) - a felhasználói hardver sokkal kevésbé megbízható és hibatűrő, mint a hasonló szerver hardver. teljesítmény. Nem érdemes kockáztatni vállalkozása számviteli rendszerét. Ha a megfelelő hardver vásárlása nem fér bele a költségvetésbe, meg kell fontolnia az 1C telepítését a felhőben.

Ha nehéznek találja eligazodni, hogy melyik szervert válassza az 1C Enterprise 8.3-hoz, hogyan készítsen 1C szervert, mert még nem szembesült ezzel a feladattal, bármikor felveheti a kapcsolatot egy rendszerintegrátor céggel, hogy tapasztalt technikusok segítsenek a tervezésben, vásárlásban , telepítse és állítsa be az Önnek megfelelő szervert az 1C-hez.

A legtöbb esetben az 1C: Enterprise 8.x "kliens-szerver" opcióban történő telepítéséhez elegendő az 1C: Enterprise 8.x telepítőprogram futtatása. Ebben az esetben az 1C: Enterprise szerver megkapja a normál működéséhez szükséges paraméterek szabványos értékeit.

Tekintsük részletesebben az 1C: Enterprise szerver telepítését. Az 1C: Enterprise 8.x szerver telepítése során az 1C: Enterprise 8.x telepítőprogram a következő műveleteket hajtja végre:

* Az 1C: Enterprise szerver betöltési moduljait az 1C: Enterprise telepítőprogram által célmappaként megadott könyvtárba másolja.
* Ha a telepítés során a "USR1CV81 felhasználó létrehozása" van kiválasztva, akkor az USR1CV81 felhasználót hozza létre. A felhasználó nevében az 1C: Enterprise 8.1 szerver akkor működik, ha szolgáltatásként indul el. Csak azokhoz az erőforrásokhoz fér hozzá, amelyekre az 1C: Enterprise szervernek szüksége van. Fontos, hogy az 1C: Enterprise szervernek két könyvtárra van szüksége a működéshez: egy közös könyvtárra a szerveradatokkal (általában "C: \ Program Files \ 1cv81 \ server") és egy ideiglenes fájlkönyvtárra (általában "C: \ Documents and Settings \". usr1cv81 \ Helyi beállítások \ Temp "vagy" C: \ WINNT \ Temp "). Az USR1CV81 felhasználó jogokat kap a szerveradatokat tartalmazó megosztott könyvtárhoz. Az ideiglenes fájlok könyvtára általában minden felhasználó számára elérhető.
* Ha a telepítési folyamat során az „1C: Enterprise 8.1 kiszolgáló telepítése Windows szolgáltatásként” engedélyezve van, akkor regisztrálja az 1C: Enterprise szerverügynök szolgáltatást a Windows rendszerben, és elindítja. Az első indításkor egy 1C: Enterprise szerverfürt jön létre alapértelmezett beállításokkal. Egy munkakiszolgálóval és egy munkafolyamattal rendelkezik. A működő kiszolgáló címe megegyezik annak a számítógépnek a nevével, amelyen a telepítést végrehajtották.

USR1CV81 vagy USR1CV82 felhasználó és jogai

Server 1C: Enterprise egy szerveralkalmazás, amelynek működése nem függhet attól, hogy melyik felhasználó lépett be interaktívan a szerver számítógépbe, ha egyáltalán belépett valaki. Ezért az 1C: Enterprise szerver telepítésekor célszerű egy speciális USR1CV81 felhasználót létrehozni, amely rendelkezik az 1C: Enterprise szerverhez szükséges minimális jogokkal, és nem interaktív bejelentkezésre szolgál. Az 1C: Enterprise szervert az USR1CV81 felhasználó mutatja be a Windows rendszernek.

Nézzük meg közelebbről az USR1CV81 felhasználóhoz rendelt jogokat. Server 1C: Enterprise a következő könyvtárakat használja:

* A betöltő modulok könyvtára az 1C: Enterprise telepítőprogram által célmappaként megadott könyvtárban található. Ez tartalmazza az 1C: Enterprise szerver betöltési moduljait. Az USR1CV81 felhasználónak jogokra van szüksége az adatok olvasásához és a programok futtatásához ebből a könyvtárból és alkönyvtáraiból. Ezeket a jogokat implicit módon megkapja, köszönhetően annak, hogy szerepel a Felhasználók csoportban.
* A szerver adatkönyvtárának neve általában "C: \ Program Files \ 1cv81 \ server". Az USR1CV81-nek teljes jogokra van szüksége ehhez a könyvtárhoz. Az 1C: Enterprise telepítőprogram az USR1CV81 felhasználó létrehozásakor megadja neki a jogokat ehhez a könyvtárhoz.
* Az ideiglenes könyvtár neve általában "C: \ Documents and Settings \ usr1cv81 \ Local Settings \ Temp" vagy "C: \ WINNT \ Temp", amelyet a felhasználó TEMP változójának vagy a rendszerkörnyezeti TEMP változónak az értéke határoz meg. Ennek a változónak az értékét a Rendszer tulajdonságai párbeszédpanelen tekintheti meg (Start -> Beállítások -> Vezérlőpult -> Rendszer -> Speciális -> Környezeti változók). Az 1C: Enterprise telepítőprogram teljes jogot biztosít az USR1CV81 felhasználónak ehhez a könyvtárhoz. A Windows telepítésekor az ideiglenes könyvtár általában minden felhasználó számára elérhető, ha az ACL-jében szerepel a CREATOR OWNER csoport. Ez a hozzáférés azonban nem teljes. A fájlok keresése ebben a könyvtárban nem minden felhasználó számára elérhető. Az USR1CV81 felhasználó teljes jogának megadása az ideiglenes fájlok könyvtárához lehetővé teszi az 1C: Enterprise szerver számára az összes szükséges művelet elvégzését. A hozzáférési listát megtekintheti a Biztonság lapon található könyvtár tulajdonságai párbeszédpanelen. A CREATOR OWNER csoport jelenléte lehetővé teszi, hogy minden olyan felhasználó hozzáférjen a könyvtárhoz, aki bármilyen fájlt hoz létre ebben a könyvtárban, vagy rendelkezik fájlokkal ebben a könyvtárban. Ebben az esetben a fájlt létrehozó felhasználó kerül be a létrehozott fájl hozzáférési listájába a CREATOR OWNER csoport helyett. A címtárhoz hozzáféréssel rendelkező felhasználók között kell lennie USR1CV81 felhasználónak is, akinek teljes joga van ehhez a címtárhoz.
Fontos szem előtt tartani, hogy egy adott felhasználó ideiglenes fájlok könyvtárát (beleértve az USR1CV81 felhasználót is) az adott felhasználó környezeti változóinak és rendszerkörnyezeti változóinak kombinációja határozza meg. Ennek a könyvtárnak a megismeréséhez az 1C: Enterprise telepítőprogram az USR1CV81 felhasználói környezetet kéri. Ehhez a Windows 2000 rendszerben annak a felhasználónak, akinek nevében az 1C: Enterprise telepítőprogram elindul, a következő jogosultságokra lehet szüksége: Az operációs rendszer részeként működjön, és kerülje meg a bejárási ellenőrzést. A felhasználói jogosultságokat a Helyi biztonsági beállítások segédprogrammal ellenőrizheti a Helyi házirendek -> Felhasználói jogok hozzárendelése ágban. Az új szoftver telepítése során a telepítő általában automatikusan megszerzi ezeket a jogosultságokat.

Az 1C: Enterprise szerver regisztrációja Windows szolgáltatásként


A Server 1C: Enterprise egy egyszerű Windows-konzolalkalmazás, amely interaktívan indítható. Állandó használat esetén azonban ez kényelmetlen, mivel ez arra készteti az 1C: Enterprise szervert, hogy egy inaktív felhasználó beviteléről induljon el a kiszolgáló számítógépen. A függőség megszüntetése érdekében az 1C: Enterprise szerver Windows szolgáltatásként futhat. Ehhez regisztrálnia kell a Windows Service Managerben.

A Windows-szolgáltatások és paramétereik listájának megtekintéséhez használja a Komponensszolgáltatások segédprogramot (Start -> Beállítások -> Vezérlőpult -> Felügyeleti eszközök -> Szolgáltatások). Az 1C: Enterprise szervert a szolgáltatások listájában az "1C: Enterprise 8.1 Server Agent" szolgáltatás képviseli. A szolgáltatás paraméterei határozzák meg az 1C: Enterprise Server Agent (ragent) folyamat elindítását, a felhasználót, akinek nevében elindul, és a vészhelyzetekben történő újraindítás módját.

Az "1C: Enterprise 8.1 Server Agent" szolgáltatás tulajdonságai párbeszédpanel Általános lapján megjelenik a ragens folyamat indításának sora, amely az 1C: Enterprise szerver ügynöke. Általában ez a sor így néz ki:


Azt írja ki, hogy:

* a Server Agent folyamat a "C: \ Program Files \ 1cv81 \ bin \ ragent.exe" betöltési modul;
* a Ragent folyamat Windows szolgáltatásként indul, és egy szolgáltatáskezelőnek (-srvc) kell felügyelnie;
* az 1C: Enterprise szerver ügynökeként használják (-agent);
* a szolgáltatás első indításakor létre kell hozni egy fürtöt az alapértelmezett paraméterekkel és a fő IP-portszámmal 1541 (-regport 1541). Az ügyfélalkalmazásoknak ezt a portot kell használniuk a fürtben regisztrált információs bázisokhoz való csatlakozáshoz;
* A kiszolgáló ügynök IP-portjának 1540-nek kell lennie (-port 1540). Ezen a porton a Cluster Console-nak csatlakoznia kell a központi szerverhez az adminisztrációs funkciók végrehajtásához;
* A fürtfolyamatok elindításakor ezen a kiszolgálón dinamikusan hozzárendelődnek az 1560-1591 (-1560: 1591) tartomány IP-portjai.
* az általános fürtadatok a "C: \ Program Files \ 1cv81 \ server" könyvtárban találhatók (-d "C: \ Program Files \ 1cv81 \ server").

Az 1C: Enterprise 8.1 Server Agent szolgáltatás nem csak az 1C: Enterprise 1C: Enterprise 8.1 telepítőprogrammal történő telepítésekor vagy eltávolításakor, hanem manuálisan is hozzáadható vagy eltávolítható. Ehhez a megfelelő paraméterek megadásával parancssorból futtathatja a ragens segédprogramot.

Szolgáltatás létrehozásához meg kell adnia az -instsrvc paramétert és a következő paramétereket: -usr az a felhasználónév, akinek nevében a szolgáltatást el kell indítani, -pwd a felhasználó jelszava. Ebben az esetben a többi paraméter az 1C: Enterprise szerver ügynökének szolgáltatásként való indításához szükséges sor paramétereivé válik. Például az 1C: Enterprise Server Agent szolgáltatás normál regisztrációjához hibakeresési módban a paraméterkészletnek a következőnek kell lennie:

"C: \ Program Files \ 1cv81 \ bin \ ragent.exe" -instsrvc -usr. \ USR1CV81 -pwd Password -regport 1541 -Port 1540 -range 1560: 1591 -d "C: \ Program Files \ 1c server" -8 hibakeresés

Egy szolgáltatás eltávolításához meg kell adnia az -rmsrvc paramétert. Például:
"C: \ Program Files \ 1cv81 \ bin \ ragent.exe" -rmsrvc

Néha túl könnyű megváltoztatni a Server Agent indítósorát vagy az Agent szolgáltatás egyéb paramétereit, például engedélyezni a hibakeresési módot, vagy több, különböző verziójú szolgáltatást létrehozni. A szolgáltatás tulajdonságai párbeszédpanel nem teszi lehetővé a szolgáltatási alkalmazás indítósorának és néhány egyéb paraméternek, például a szolgáltatásazonosítónak a szerkesztését. A szerkesztéshez szükség van a regedit segédprogramra, amelyet a Windows rendszerleíró adatbázisának megtekintéséhez és szerkesztéséhez terveztek.

Figyelem!
A Windows rendszerleíró adatbázisának szerkesztése rendkívüli körültekintést igényel, mivel a hibás módosítások használhatatlanná tehetik az operációs rendszert.

Futtassa a regedit segédprogramot (nyissa meg a Start -> Futtatás parancsot, és írja be a regedit parancsot), és válassza ki az ágat:


Paraméterei között van az ImagePath paraméter, melynek értéke az 1C: Enterprise szerver ügynökének indítására szolgáló sor. Itt új paramétereket adhat hozzá az indítósorhoz, vagy módosíthatja a meglévők értékeit. A lehetséges paraméterek teljes listája az „1C: Enterprise 8.1 Client-Server” című könyvben található.

Ha több független szolgáltatást kell regisztrálnia az Agent of the 1C: Enterprise szerverhez, meg kell adnia nekik a fürt különböző betöltési moduljait, különböző portjait és különböző adatkönyvtárait. Ezenkívül regisztrálnia kell őket különböző szolgáltatási azonosítókkal. Ezt így teheti meg:

* Első szolgáltatás létrehozása:
"C: \ Program Files \ 1cv81 \ bin \ ragent.exe" -srvc -agent -regport 1541 -Port 1540 -range 1560: 1591 -d "C: \ Program Files \ 1cv81 \ server"

* Módosítsa a regisztrált szolgáltatásazonosítót a regedit segédprogrammal. Ehhez: válasszon egy ágat
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ 1C: Enterprise 8.1 Server Agent

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ 1C: Enterprise 8.1 Server Agent First
* Hozzon létre egy második szolgáltatást:
"C: \ Program Files \ 1cv81_10 \ bin \ ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660: 1691 -d "C: \ Program Files \ 1cv81_10 \ server"

* Talán változtassa meg az azonosítóját is. Ehhez: válasszon egy ágat
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ 1C: Enterprise 8.1 Server Agent
és módosítsa a nevét, például erre:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ 1C: Enterprise 8.1 Server Agent Second

Mit nem tud az 1C: Enterprise telepítőprogram?

Mint már említettük, az 1C: Enterprise telepítőprogram átmásolja az 1C: Enterprise betöltési modulokat, és elvégzi a szükséges regisztrációt a COM-ban és a Windows szolgáltatáskezelőben. A fenti információk a regisztráció belső mechanizmusainak megértéséhez szükségesek. Ha nem csak a szerver, hanem az 1C: Enterprise kliens rész is telepítve van a kiszolgáló számítógépen, akkor a telepítés (és a védelmi kulcsok csatlakoztatása) után azonnal használatra kész.

Annak érdekében, hogy az 1C: Enterprise szerver elérhető legyen a helyi hálózat többi számítógépéről, ellenőrizni kell a kiszolgáló és az ügyfélszámítógépek hálózati beállításait, valamint a hálózat egészét. A TCP / IP-t az ügyfélalkalmazások és az 1C: Enterprise szerver, valamint a szerverfürt folyamatok közötti adatátvitelre használják. Az 1C: Enterprise működése a kliens-szerver verzióban a konfiguráció helyességétől függ.

Az 1C: Enterprise szerverfürt folyamatai a működő szerverek tulajdonságai párbeszédpanel "Számítógép" tulajdonságának értékeiként megadott címeken kapcsolódnak egymáshoz. A fürt megköveteli, hogy a "Számítógép" tulajdonság értéke vagy egy IP-cím pont jelöléssel, vagy egy szimbolikus cím, amely felhasználható az IP-cím meghatározására a TCP API-ban definiált gethostbyname függvény segítségével. Az IP-cím vagy a helyi szimbolikus címtáblázatból (C: \ WINNT \ system32 \ drivers \ etc \ hosts), vagy az elérhető DNS-kiszolgálók címtáblázataiból kerül meghatározásra. Ha a működő szerver szimbolikus címe nem határozza meg annak IP-címét, vagy helytelenül van meghatározva (például az IP-cím nem egyezik a számítógép tényleges IP-címével), akkor a fürt nem fog működni. Fontos, hogy a fürt egyes éles kiszolgálóin a Windowsban meghatározott számítógépnevek és címeik ne ütközzenek a DNS-ben szereplő nevükkel.

Minden működő szerveren a fürtfolyamatok a következő portokat használják: a működő kiszolgáló IP-portja (általában 1540); A munkafolyamat IP-portjainak IP-portjai (általában 1560-1591). Ezenkívül a fürt központi kiszolgálója használja a fürtportot (általában 1541). Ha a rendszer tűzfalat használ, akkor ezeken a portokon engedélyezni kell az adatátvitelt. A fenti listából származó portok engedélyezése helyett engedélyezheti az adatátvitelt a fürtfolyamatokhoz (ragent, rmngr, rphost).

Az 1C: Enterprise kliens alkalmazás csatlakoztatása a szerverhez 2 lépésben történik. Először kapcsolatot létesít a fürtkezelővel. Ez a központi szerver címét (szimbolikus vagy numerikus) és a fürt portját (általában 1541) használja. Ezután az ügyfélalkalmazás kapcsolatot létesít az egyik munkafolyamattal. Címként a megfelelő működő szerver "Számítógép" tulajdonságának értéke és a munkafolyamat portja, amely a működő szerver IP-portjai közül kerül kiválasztásra. Az ezekre a portokra történő adatátvitelt engedélyezni kell minden tűzfalon az ügyfélalkalmazás számítógépétől az 1C: Enterprise szerverfürt számítógépei felé vezető útvonalon. A szerverfolyamatok IP-címét a gethostbyname függvény határozza meg az ügyfélszámítógépen. Fontos, hogy az egyes fürtkiszolgálókon a központi és éles kiszolgálók neve és a Windowsban meghatározott címei ne ütközzenek az ügyfélszámítógép számára elérhető DNS-ben szereplő nevükkel.

És az utolsó dolog. Nyilvánvaló, hogy az 1C: Enterprise szerverhez más számítógépekről történő sikeres hozzáféréshez a hálózaton kell lennie, és meg kell tenni a szükséges beállításokat. A hálózati csatlakozási és beállítási módszerek a Microsoft Windows alapú hálózati adminisztrációra jellemzőek, és leírásuk a kapcsolódó utasításokban található.

Az SQL Server Tuning sajátosságai

1C: Az Enterprise a "kliens-szerver" verzióban SQL-szervert használ az adatok tárolására. Ugyanakkor csak az 1C: Enterprise Server címzi az SQL-kiszolgálót. Az 1C: Enterprise ügyfelei nem férnek hozzá közvetlenül az SQL-kiszolgálóhoz. Az SQL Server telepítését és konfigurálását részletesen a Microsoft SQL Server dokumentációja írja le. Az 1C: Enterprise Server SQL szerverrel történő sikeres működéséhez különös figyelmet kell fordítania a következő beállításokra.

* Szükséges SQL Server összetevők. Az SQL szerver 1C: Enterprise Server oldalról való eléréséhez a Microsoft Data Access 2.6 vagy újabb összetevőit telepíteni kell az 1C: Enterprise Server számítógépen.
* Felhasználó hitelesítés SQL szerverrel. Az SQL szerver adatbázisaihoz való hozzáférési jogokat az a felhasználó határozza meg, akinek nevében az adatbázishoz hozzáférnek. Arról a számítógépről, amelyre az SQL-kiszolgáló telepítve van, indítsa el az SQL Server Enterprise Manager segédprogramot, keresse meg a helyi csomópontot (Konzolgyökér -> Microsoft SQL Servers -> SQL Server Group -> (Helyi)), és nyissa meg a tulajdonságait. A Biztonság lapon láthatja, hogy az SQL Server két módot támogat a felhasználók hitelesítésére: az SQL Server és a Windows és a Windows csak. A Windows hitelesítés lehetővé teszi, hogy az 1C: Enterprise Server csak az USR1CV81 felhasználó nevében férhessen hozzá az SQL-kiszolgálóhoz, ami nem teszi lehetővé az 1C: Enterprise szerver által kiszolgált különféle információs bázisok hozzáférési jogainak megkülönböztetését. Javasolt az SQL Server és a Windows mód kiválasztása. Ebben az esetben egy adott információs bázishoz való hozzáférés annak a felhasználónak a nevében történik, akit az információs adatbázis létrehozásakor az SQL-kiszolgáló felhasználójaként határoztak meg. Fontos, hogy ennek a felhasználónak nemcsak az infobase adatbázishoz kell teljes jogával rendelkeznie, hanem az SQL szerveren adatbázisok létrehozására és a Master adatbázis tábláinak olvasására is.
* Hálózati protokollok az SQL szerver eléréséhez. Ha az 1C: Enterprise Server és az SQL szerver különböző számítógépeken található, akkor be kell állítani a hálózati protokollokat az SQL szerver eléréséhez. Ezt az SQL Server Client Network Utility segítségével teheti meg. Az Általános lapon kiválaszthatja az SQL-kiszolgáló eléréséhez használt hálózati protokollok listáját. A leggyorsabb és legsokoldalúbb a TCP / IP protokoll használata. Más protokollok használatakor ne feledje, hogy ezek közül néhány, például a Named Pipes, további Windows-hitelesítést hajt végre az SQL-kiszolgálóval való kommunikáció során. Ebben az esetben az SQL szerverrel való sikeres munka érdekében a megfelelő jogosultságokkal rendelkező USR1CV81 felhasználót regisztrálni kell a számítógépen az SQL szerverrel. Az SQL-kiszolgáló hozzáférési protokollja az Alias ​​lapon módosítható.

A cikk mellett

Kétségtelen, hogy az MS SQL Server + szerver "1C: Enterprise 8" csomag a legkeresettebb és leggyakrabban használt csomag a rést illetően. Mindkét termék megértése kívánatos a minőségi támogatás érdekében. Ugyanakkor a gyakorlatban a támogatási szakember általában vagy az MS SQL Server adminisztrálására specializálódott, és nem ismeri az 1C: Enterprise 8 szerver sajátosságait, vagy éppen ellenkezőleg, az 1C: Enterprise 8 szerver adminisztrálására specializálódott, és nem ismeri. az MS SQL Server sajátosságai.

Ezt a cikket azért írtuk, hogy segítséget nyújtson ezeknek és más szakembereknek is, és célja, hogy időt takarítson meg, és felhívja a figyelmet a szoftvertermékek együttes használata során a legfontosabb részletekre.

Az információ észlelésének megkönnyítésére gyakorlati esetek, megjegyzések és tippek (dőlt betűvel) olvashatók.

Három láncszem séma

Amint azt az olvasó már tudja, az adatbázis ebben az esetben háromszintű architektúrával rendelkezik:

1. hivatkozás: MS SQL Server DBMS. Ez "tárolja" és karbantartja az adatbázist, és végső soron mindenféle műveletet végrehajt az adatbázissal. Így az adatbázis teljesítményét, az adatok írás-olvasás sebességét és párhuzamosságát nagyban meghatározza az MS SQL Server teljesítménye.

2. hivatkozás: "1C: Enterprise 8" szerver. Közvetítőként szolgál az ügyfelek (felhasználók) és az MS SQL Server közötti interakcióban. Minden kliens kérés elküldésre kerül a kiszolgálónak, amely "lefordítja" azokat az MS SQL Server lekérdezési nyelvére, megkapja ezeknek a lekérdezéseknek az eredményeit, és elküldi az eredményeket a kliensnek.

Az 1C: Enterprise 8 szerverszinten, az MS SQL elérése nélkül végrehajtott műveleteknek csak egy kis része van - különösen az úgynevezett „menedzselt zárak” követése, a „munkamenet-paraméterek” olvasása-írása. Ilyen esetekben a DBMS hívása nem szükséges, mivel ezeket a műveleteket nem az adatbázis adataival, hanem a szerver segédinformációival hajtják végre.

3. hivatkozás: „1C: Enterprise 8” ügyfélrész. Kapcsolatba lép az 1C: Enterprise 8 szerverrel, eredményeket kap tőle (azaz például adatmintákat), és felelős a felhasználói felületért.

– A legjobbat akartam.

Az 1C: Enterprise 8 szerver újratelepítése után a felhasználók panaszkodnak a teljesítmény meredek csökkenéséről. Az újratelepítő 1C: Enterprise szoftvermegvalósítási szakember csak meglepődött - azt mondják, a legjobbat akarta, a rendszernek gyorsabban kellett működnie... A helyzet elemzése azt mutatta, hogy túl sok erőforrás jutott az 1C: Enterprise 8-hoz szerver: folyamatok (lásd 3. pont) Az rphost 15,5 GB-ot vett el a 16 GB-os szerver RAM-ból, ennek eredményeként a kompatibilis MS SQL Server számára gyakorlatilag nem áll rendelkezésre RAM.

Ennek eredményeként - állandó "csere", szükségtelen terhelés a lemezalrendszeren, és az adatbázis-műveletek rendkívül lassú végrehajtása, mivel az MS SQL Server-nek nincs ideje feldolgozni a "túlhúzott" "1C: Enterprise 8" szervertől érkező kéréseket. .

Termék kompatibilitás

Az MS SQL Server „1C: Enterprise 8-cal együtt történő használatra javasolt” verzióira vonatkozó naprakész adatokért kövesse a hivatkozást. http://v8.1c.ru/requirements/.

A cikk írásakor az 1C cég fejlesztői a következő lehetőségeket javasolják:

      1. SQL Server 2008 R2.
      2. SQL Server 2008, Service Pack 1 (SP1) szükséges.
    3. SQL Server 2005, Service Pack 3 (SP3) szükséges.



Az MS SQL Server 2000 használata technikailag lehetséges, de nem ajánlott, ehhez a Service Pack 2 (SP2) telepítése szükséges, és kívánatos a Service Pack 4 (SP4) telepítése.

Felhívjuk figyelmét, hogy ez a verzió jelenleg megszűnt, és nincs 64 bites verziója az x86-64 architektúrához.

Jegyzet:

Figyelni kell az operációs rendszer beállításaira: például ahhoz, hogy az M SQL Server 2008 hatékonyan működjön a Server 2008R2 operációs rendszer alatt, ki kell kapcsolni a kiegyensúlyozott tápegység módot, és át kell váltani a maximális teljesítményű módra.

Az "1C: Enterprise 8" kliens-szerver verziójának telepítése

"1C telepítve"

Az egyik ügyfél telepítette az „1C: Enterprise 8”-at egy olyan rendszergazda által, akinek nincs tapasztalata az „1C: Enterprise 8” szoftverrel való munkavégzésben. És bár elmondása szerint "telepítette az 1C-t" - a felhasználói számítógépeken nem volt kliens oldal, a szerveren pedig szerveroldal. A helyzet elemzése tisztázta a képet - az "1C: Enterprise 8" készletben 2 lemez volt - a platform telepítése és az adatbázissablonok telepítése. Az adminisztrátor nem mélyedt el a telepítési folyamatban - és az adatbázis-sablonokat telepítette, nem pedig a futtatható fájlokat, platform-összetevőket.

Természetesen ez a munkához való rendkívül figyelmetlen hozzáállás atipikus példája.

Az "1C: Enterprise 8" telepítésekor figyelembe kell venni, hogy a következőket külön kell telepíteni:

      Az "1C: Enterprise 8" platform egy végrehajtható alkalmazás, integrált környezet adatbázisok fejlesztéséhez és üzemeltetéséhez. Amikor elindul, a két működési mód egyike van kiválasztva – "Enterprise" (felhasználó által definiált adatbázishéj) vagy "Configurator" (integrált fejlesztői környezet). Részletesebb leírás a linken található
      Konfigurációs sablonok Az „1C: Enterprise” a platform belső formátumú fájlja, melynek segítségével a platform tiszta vagy demó adatbázist hozhat létre a sablonban szereplő struktúráról. Ezenkívül a frissítési sablon segítségével frissítheti egy már adatokkal feltöltött adatbázis szerkezetét.
      A platform telepítésekor ügyelni kell az alkatrészek kiválasztására:





Előfordulhat, hogy az 1C: Enterprise összetevő nincs telepítve a kiszolgáló(k)ra.

Ebben az esetben a szerver hozzáférést biztosít az ügyfélszámítógépekhez az 1C: Enterprise adatbázisokhoz, de nem lehet közvetlenül a szerverről felhasználói módban dolgozni az adatbázissal.

Jegyzet:

A platform 64 bites verziója nem tartalmazza a kliens részt. Ezért a telepítés során a 64 bites kiszolgálókomponensek külön, a kliens alkalmazás 32 bites összetevői pedig külön kerülnek telepítésre.

Az 1C: Enterprise Server összetevő szükséges az MS SQL Serverhez való csatlakozáshoz - ez egy olyan alkalmazásszerver, amely összeköti a platformot az ügyfél munkaállomásokon és az MS SQL Serveren.

A komponens telepítése egyszerű alkalmazás vagy rendszerszolgáltatás módban is lehetséges, és természetesen a második lehetőség javasolt.

Amikor "szolgáltatásként" telepíti, ez az összetevő a kiválasztott felhasználó nevében indul el és fut le:




Az összetevő betöltése után számos folyamatot indít el, például: "szerver ügynök", "szerverfürt-kezelő", "szerver-munkafolyamatok".

Az adatbázis-lekérdezéseket a dolgozói folyamatok hajtják végre, és a kiszolgálófürt-kezelő osztja el a terhelést közöttük.

A szerver munkafolyamatai kezelhetők (RAM hozzáadása, törlése, használatának korlátozása, elsődleges vagy biztonsági mentés deklarálása), ha telepítve van az "1C: Enterprise Server Administration" komponens.



Jegyzet:

A szerver 32 bites verziójához ajánlott olyan mennyiségben telepíteni a munkafolyamatokat, hogy ne hagyja kihasználatlanul a RAM-ot - mindegyiknek észrevehető korlátja van a RAM használatában, 2-4 GB, attól függően a rendszer konfigurációján.

A szerver 64 bites verziójához elméletileg két munkafolyamat is elegendő – egy dolgozó és egy biztonsági másolat. A gyakorlatban azonban a kapcsolatok megbízhatóságának és stabilitásának biztosításához jelentős (több száz) felhasználószámon nagyobb számra van szükség, ez sok tényezőtől függ - a felhasználók számától, az adatbázis kitöltöttségétől, ill. az elvégzett lekérdezések mennyisége, ezért a szerzők úgy vélik, hogy ebben az esetben a folyamatok számát kísérletileg kell kiválasztani.

"Ouroboros"

Az 1C: Enterprise 8 szerver beállításainak sikertelen optimalizálása után a felhasználók jelezték, hogy a rendszer rendkívül lassú, és a rendszergazda állandó 100%-os CPU-terhelést észlelt a szerveren.

A helyzet elemzése megmutatta a probléma forrását - a beállításkor túl kicsi korlátot állítottak be a dolgozói folyamatok RAM-használatára.

És a tény az, hogy ez a korlátozás a következőképpen működik:

Amikor egy kiszolgálófürt-kezelő azt látja, hogy egy munkavégző folyamat túllépte a RAM-korlátot, a folyamat leállítja a kapcsolatot, megszakítja a kapcsolatot, új munkavégző folyamat jön létre, és a kapcsolatok és a felhasználói kérések újraelosztásra kerülnek a munkavégző folyamatok között.

A beállított korlát olyan kicsi volt (300 MB), hogy a munkafolyamat még egy intenzíven dolgozó felhasználót sem tudott teljes mértékben kiszolgálni – ennek eredményeként a szerverfürt-kezelő folyamatosan újraindította a dolgozói folyamatokat és újracsatlakoztatta a felhasználókat. Amint létrejött egy új folyamat, és a felhasználók csatlakoztak hozzá, a RAM-korlát szinte azonnal elérte, és a következő újraindítást okozta. Ez a processzorterhelés 100%-át vette igénybe.

Az 1C: Enterprise Server komponensre nincs szükség a kliens munkaállomásokon, és ott sem fog tudni elindulni, mivel fizikai biztonsági kulcsot igényel.

Ha a csatlakoztatott felhasználók száma kicsi (50-nél kevesebb), akkor az alkalmazáskiszolgáló általában ugyanarra a számítógépre van telepítve, ahol az MS SQL Server fut.

Nagy számú felhasználóval és/vagy nagy mennyiségű információáramlással rendelkező rendszerek esetén külön telepítés, valamint szerverfürt használata javasolt.

Az 1C: Enterprise Server Administration összetevő az ügyfeleken is hasznos lehet - például segítségével láthatja az adott 1C: Enterprise szerverhez kapcsolódó infobázisok listáját.

Erősen ajánlott magára a szerverre telepíteni.

Hozzáférés

Jegyzet:

A hozzáférés biztosításának ellenőrzéséhez nem elég az 1C: Enterprise szerveradminisztrációs segédprogramot használni, és még inkább nem elegendő a szerver jelenléte a "Network Neighborhood"-ban!

Minden kliensnek be kell jelentkeznie a kiszolgálóra telepített adatbázisba - csak ez ad 100% -os biztonságot a hozzáférés biztosítására.

1. A biztonsági házirendektől függően az MS SQL Server esetében Windows-fiókhitelesítés vagy MS SQL Server-fiókhitelesítés használatos.




Az utóbbi esetben az 1C: Enterprise adatbázis létrehozásakor a rendszer kérni fogja az MS SQL Server fiók bejelentkezési nevét és jelszavát (például sa); az első esetben a bejelentkezési nevet és a jelszót üresen kell hagyni:



és a rendszer azon felhasználójának, akinek nevében az 1C: Enterprise szerver elindul, jogokat kell adni az MS SQL Serverben, nevezetesen:

      teljes jogok ahhoz az adatbázishoz, amelyben az információs bázis található
      hozzáférés a fő adatbázishoz (nyilvános szerepkör)
      ajánlott - az adatbázis létrehozásának joga, különben minden új adatbázist először az MS SQL Severrel kell létrehozni, és csak ezután kell csatlakozni az 1C: Enterprise szerverhez
      ajánlott - az adatbázis törlésének joga



Például hozzárendelheti a kérdéses felhasználót az előre meghatározott processadmin vagy sysadmin szerepkörhöz.

Tanács.

Ha az összes felhasználó egyszerre elvesztette a hozzáférést a működő adatbázishoz, akkor még egyszer ellenőriznie kell a felhasználó jogait és szerepköreit az MS SQL Serverben, beleértve azokat is, amelyek egy adott adatbázishoz vannak beállítva, azaz a Felhasználói leképezés:




2. Az 1C: Enterprise szerver a Microsoft Data Access mechanizmuson keresztül éri el az MS SQL Servert, ezért annak összetevőit telepíteni kell, és az 1C: Enterprise szerver felhasználójának (lásd az előző bekezdést) jogosultsággal kell rendelkeznie az indításhoz.

3. A kliensek és a szerver közötti kommunikációt TCP protokoll támogatja, ezért szükséges, hogy ezt a protokollt mindkét fél támogassa. Problémák adódhatnak a kiszolgáló nevének és IP-címének egyeztetésével, például ha peer-to-peer hálózatot használnak. Ebben az esetben a megfelelést a [C: \ WINDOWS \] system32 \ drivers \ etc \ hosts fájlba kell rögzíteni.

Tanács.

Ha a hálózat peer-to-peer – a kiszolgálóval való állandó kapcsolat biztosítása érdekében hozzon létre egy hálózati meghajtót, amely hozzáfér a kiszolgáló bármely mappájához.

4. Ha a Named Pipes protokollt használják, és ha az MS SQL Server és az 1C: Enterprise szerver különböző számítógépekre van telepítve, akkor azt a felhasználót, akinek nevében az 1C: Enterprise szerver fut, regisztrálni kell a számítógép felhasználóinak listájában. amelyen az MS SQL Server fut.

5. Bizonyos esetekben szükség lehet a Windows tűzfal további konfigurálására, azaz kivételek hozzáadására.

6. Egyes víruskeresők blokkolhatják a "nem kívánt" hálózati forgalmat, ezért előfordulhat, hogy hozzá kell adnia a kizárási listáikat.

7. Az 1C: Enterprise 8 platform kiadásának pontosan azonosnak kell lennie a kliensen és a szerveren.

"Ikrek"

"Az egyik ügyfél két adatbázis-szervert használt, amelyek mindegyikének egy működő adatbázisa volt. A felhasználók egyszerre dolgoztak mindkét adatbázissal. A támogatási szolgálatok frissítették az 1C: Enterprise 8 platformot a szervereken és a klienseken... Aztán elkezdtek özönleni a panaszok A helyzetelemzés azt mutatta, hogy a klienseken és a szervereken a frissítést többen végezték, és a telepítők nem ellenőrizték még egyszer, hogy ugyanazt a kiadást telepítik-e, ezért az egyik szervernek egy platform kiadása volt, a másodikon - a másik, a kliensek fele - az első kiadás, a másik fele - a másik. Kiderült, hogy minden felhasználó csak az egyik adatbázishoz fér hozzá.

A probléma gyors megoldásához telepítenem kellett mindkét platformkiadást minden felhasználóhoz, és külön parancsikonokat kellett létrehoznom az egyes adatbázisok belépéséhez.

Az MS SQL Server és az adatbázis kezdeti beállításai

"És így működik"

Az MS SQL Servert a kezdeti telepítés egyszerűsége különbözteti meg, így nem minden adminisztrátor ért fejtörést további konfigurációja előtt - a telepítés után alapértelmezés szerint az adatbázis működik, a felhasználók be vannak jelentkezve - a munka kész. Ez a megközelítés szinte mindig azzal jár, hogy körülbelül egy-két hónap elteltével problémák jelentkeznek - és természetesen hirtelen és a legkellemetlenebb pillanatban.

Például, ha a bázist könyvelésre szánják, az adóbevallások benyújtása előtt gyakran sürgősen újra kell számolni bizonyos adatokat, és nagy mennyiségben újra kell számolni, mondjuk "az év elejétől az összes tárgyi eszköz bevételét". Sőt - a munkanap folyamán, anélkül, hogy leállítaná az adatbázis többi felhasználójának munkáját.

És természetesen ebben a pillanatban derül ki, hogy az alap "lefagy" vagy "összeomlik" ilyen újraszámítással, vagy nem engedi más felhasználóknak a munkát.

Ez a fajta "Murphy-törvény" az alábbi pontok mindegyikére vonatkozik.

Mielőtt elkezdené az MS SQL Server DBMS-ként való használatát az 1C: Enterprise számára, javasoljuk:

1. Állítsa a párhuzamosság max. foka paraméter értékét 1-re.

Azaz:

      a szerverhez való csatlakozás után a helyi menü Properties menüpontján keresztül adja meg a szerver tulajdonságait
      majd válassza ki a Speciális oldalt, és módosítsa a párhuzamosság maximális foka paramétert






Ellenkező esetben az 1C: Enterprise szerver által generált néhány lekérdezés a következő hibát okozhatja: "A lekérdezésen belüli párhuzamosság a kiszolgálóparancsot (folyamatazonosító #XX) elakadt. Futtassa újra a lekérdezést lekérdezésen belüli párhuzamosság nélkül a query hint (maxdop 1) beállítással. ) ". E hiba után az ügyféloldal gyakran összeomlik.

A hiba nem jelenik meg stabilan, mivel a lekérdezési terv a felhalmozott statisztikáktól függően eltérően alakul ki - nagy és összetett lekérdezéseken, vagyis a legszerencsétlenebb pillanatban jelenik meg.

2. Hozzon létre egy karbantartási tervet, amely csökkenti a tempdb ideiglenes tábla adatbázisát. Az ideiglenes táblák adatbázisát az 1C: Enterprise szerver nem mindig törli automatikusan, és néha egy sikertelenül megírt lekérdezés eredményeként egy például 50 GB méretű ideiglenes tábla generálható, és nem törlődik. Emiatt elfogyhat a lemezterület, aminek következtében mind a kliens, mind a szerver rész lefagyhat, illetve kismértékben fennáll az adatintegritás megsértésének veszélye is.

Vagyis szüksége van:

      lépjen az MS SQL Management Studio-ba
      a szerverhez való csatlakozás után nyissa meg a „Karbantartási tervek” részt
      új szolgáltatási tervet készíteni (vagy kiegészíteni a meglévőt),
      add hozzá az "Execute T-SQL utasítás feladat" elemet (mivel a tempdb adatbázis nem választható ki az "Adatbázis zsugorítása" feladatban) a kóddal




1.HASZNÁLAT
2.
3.MENJ
4.
5.DBCC SHRINKFILE (N "tempdev", 0, CSAK CSONKULT)
6.
7.MENJ
8.
9.DBCC SHRINKFILE (N "templog", 0, CSAK CSONKÍTOTT)
10.
11.MENJ

Vegye figyelembe, hogy az ideiglenes táblaadatbázis fájlneve nem lehet „tempdev”. A név ellenőrzéséhez használhatja a szkriptet

1. HASZNÁLJA a tempdb-t
2.
3.MENJ
4.
5.EXEC sp_helpfile
6.
7.MENJ




"Fazék, ne forrald"

A gyakorlatban a tempdb túlcsordulásának és így a szerver összeomlásának legáltalánosabb módja az, hogy elfelejtjük megadni a feltételt a táblák összekapcsolásakor.

Nevezetesen, tegyük fel, hogy két táblánk van az adatbázisban, egyenként 20 ezer rekord méretű. Tegyük fel, hogy a rekordjaik között egy-egy megfeleltetés hozható létre, és írunk egy lekérdezést, amely egy ideiglenes táblát hoz létre, amely 20 ezer rekordot tartalmaz mindkét eredeti tábla mezőivel. De ha elfelejtjük megadni a csatlakozási feltételt, akkor az első tábla minden rekordja csatlakozik a második tábla minden rekordjához! Vagyis a kapott táblázat 20'000 * 20'000 = 400 millió rekord lesz. Stb.

3. A lemezalrendszer terhelésének csökkentése érdekében ajánlatos lehetőség szerint a működő adatbázist és a tempdb-t, a naplókat és a rendszerlapozófájlt szétszórni különböző fizikai lemezeken.

A munkabázis fájljainak tárolásához szükséges elérési utat célszerű a létrehozáskor a Path oszlop szerkesztésével beállítani:




Az ideiglenes tábla adatbázis-fájlok fizikai helyének megváltoztatásához használja az ALTER DATABASE parancsot, azaz az MS SQL Management Studio programban a következő szkriptet kell végrehajtania ("Új lekérdezés" parancs)

1.MASTER HASZNÁLATA
2.
3.MENJ
4.
5. ADATBÁZIS MÓDOSÍTÁSA tempdb
6.
7. FÁJL MÓDOSÍTÁSA (NAME = tempdev, FILENAME = "Új_meghajtó: \ Új_Könyvtár \ tempdb.mdf")
8.
9.MENJ
10.
11.ADATBÁZIS MÓDOSÍTÁSA tempdb

12.
13. FÁJL MÓDOSÍTÁSA (NAME = templog, FILENAME = "Új_meghajtó: \ Új_Könyvtár \ templog.ldf")
14.
15.MENJ

4. A működő adatbázis és naplójának "növekedését" nem szabad akadályozni - méretkorlátozás ne legyen, az "Autogrowth" tulajdonság százalékban legyen beállítva, az ajánlott érték 10%. Ellenkező esetben az adatok hozzáadása az adatbázishoz, az archívumból való visszaállítás és egyéb műveletek indokolatlanul sokáig tarthatnak.

A tulajdonság beállításához lépjen az adatbázis tulajdonságaihoz a helyi menün keresztül, válassza ki a Fájlok részt, és nyissa meg a fájl tulajdonságainak szerkesztését:



5. Javasoljuk, hogy engedélyezze a TCP / IP hálózati protokoll támogatását az MS SQL Serverben, és tiltsa le az összes többit, különben az MS SQL Server és az 1C: Enterprise szerver közös munkája kevésbé lesz stabil.




6. Ugyanott - törölje az Alias ​​részt, mivel telepítése hibákhoz vezet az MS SQL Server és az 1C: Enterprise szerver közötti interakcióban.

Az adatbázis működtetésének megkezdése előtt ajánlatos:

1. Amikor adatbázist hoz létre az "1C: Enterprise"-ból, állítsa be a "dátumeltolás" értéket 2000-re, ellenkező esetben az 1753.01.01-nél korábbi dátum rögzítésének kísérlete (ami emberi tényező miatt lehetséges) az adatbázis hibás működését okozza.

Figyelem! Meglévő adatbázis esetén a dátum eltolás nem módosítható!



2. Állítsa a helyreállítási modellt Egyszerűre, vagy hozzon létre egy karbantartási tervet, amely naponta biztonsági másolatot készít az adatbázisról, és csonkolja a tranzakciós naplót (naplófájlt). Ellenkező esetben egyes műveletek során a tranzakciós napló (naplófájl) nagyon gyorsan megnő: például az adatbázis átstrukturálásakor a naplófájl méretének növekedése többszörösen meghaladhatja magának az adatbázisnak a méretét.




3. Hozzon létre egy karbantartási tervet, amely legalább hetente egyszer elvégzi a következő ütemezett feladatokat:

      Biztonsági másolat készítése az adatbázisról.
      Az adatbázis-statisztikák frissítése és az eljárási gyorsítótár törlése (vegye figyelembe, hogy az automatikus frissítési statisztikák tulajdonság nem törli az eljárási gyorsítótárat).
      Az eljárási gyorsítótár törlése – nem szerepel a Karbantartási tervek szabványos műveleteiben, ezt a lépést a következő tartalommal rendelkező szkript (Execute T-SQL Statement) végrehajtásaként kell meghatározni:
      DBCC FREEPROCCACHE
      Adatbázistáblázatok újraindexelése.






Természetesen célszerű automatikus e-mail küldést beállítani a feladatok sikeres / sikertelen elvégzéséről.




Következtetés

Azok a problémák, amelyek leggyakrabban okoznak nehézséget az „1C: Enterprise 8” rendszergazdáinak és megvalósítóinak, az MS SQL Server és az „1C: Enterprise 8” kliens-szerver verziójának közös használatával kapcsolatban.

A szerző reméli, hogy elég következetesen és könnyen kiemelte "az érem mindkét oldalát".

P.S. Gyakrabban készítsen biztonsági másolatot!

Az 1C szerver fontos technikai elem az IT-infrastruktúra felépítésénél. Készek vagyunk kiváló konfigurációjú szerverhardvert megfelelő áron, hatalmas felárak nélkül értékesíteni. Csak az Ön igényeinek megfelelő konfigurációk. Hagyjon kérést, és olyan eszközt kap, amely megfelel a szervezet műszaki igényeinek.

Bármilyen bonyolultságú szerverberendezést készek vagyunk a követelményeknek megfelelő konfigurációval biztosítani. Van egy kényelmes szállítás. Az önátvétel Moszkvában lehetséges. Általánosságban elmondható, hogy ha vásárolni szeretne, akkor csak fel kell hívnia, ki kell töltenie a számítási űrlapot, vagy írnia kell e-mailben. Változatos alkatrészeket, összeszerelési lehetőségeket kínálunk, kereskedelmi ajánlatot teszünk. A költségvetésre építünk, és összegyűjtjük a legcélravezetőbb 1C szervereket.

Ha információért jött, akkor lent található. Igyekeztünk egy olyan teljes értékű anyagot közölni, amely képes ugyan nem kimerítő, de terjedelmes választ adni egy kérdésre. Azonnal figyelmeztetünk a hardverre vonatkozó információkra, mint a szoftverekre.

  • 1C szerver 5-10 felhasználó számára
  • 1C szerver 10-20 felhasználó számára
  • 1C szerver 20-30 felhasználó számára
  • 1C szerver 30-50 felhasználó számára
  • 1C szerver 50-100 felhasználó számára
  • 1C szerver 200+ felhasználó számára

Ebben az esetben egyedi konfigurációra van szükség. Nincs értelme véletlenszerű konfigurációnak, mivel a terhelés nagymértékben változhat a felhasználók feladataitól függően. Egyes esetekben nem működik, ha egy eszközre korlátozódik; fürt szükséges. Hagyjon kérést, hogy a szakember felvehesse Önnel a kapcsolatot és tisztázza a részleteket.

Bármely összeállítás egyedileg konfigurálható az Ön igényei szerint!

Az előzetes paramétereket egyébként az alábbi űrlapon lehet kiválasztani. Ez lehetővé teszi a szakemberek számára, hogy gyorsan kereskedelmi ajánlatot készítsenek.

Kérjen egyedi számítást az 1C szerverről:

Mi az 1C szerver?

Az "1C: Enterprise 8.3" szoftvercsomag üzleti eszközök készlete a könyveléshez, a leltárhoz és a jelentéskészítéshez automatikus üzemmódban. Számos lehetőség kínálkozik az élesítésre bármely tevékenységi szegmensben. A szoftver meglehetősen rugalmas a beállításokban, de sajnos nagyon igényes.

Valójában a komplexumot ma már mindenhol használják. Nagy szervezetek, költségvetési intézmények, kormányzat. És nem csak Oroszországban, hanem külföldön is.

A termék piaci megjelenése egy nagyon alkalmas pillanatban történt, ami jó hatással volt a termék széles körű elterjedésére. Eleinte minimális eszközkészlet állt rendelkezésre a könyveléshez, fokozatosan fejlődtek, fejlődtek a szoftverek, új funkciókkal, képességekkel bővült.

Mára a termék a vállalkozás számos aspektusának automatizálásának teljes értékű eszközévé vált, és megérdemelt népszerűségnek örvend. A szoftver a hiányosságok ellenére folyamatosan fejlődik, újításokat vezet be, és javítja a korábbi verziók hiányosságait.

Megvalósítási típusok

A legtöbb kis szervezet nem vásárol szervert 1C-hez. Nem látják értelmét az ilyen pazarlásnak. Végül is elegendő a komplexumot személyi számítógépen telepíteni, majd hozzáférést adni más számítógépekhez. Ennek az opciónak a neve "Fájl mód".

Nem tud tisztességes teljesítményt nyújtani, csak helyi hálózatban használható (természetesen van távoli elérés is, de nem hatékony). Ha az adatbázisba irányuló egyidejű hívások száma meghaladja az 5-öt, az komolyan lelassul. Időnként lefagy. Ezenkívül az adatbázisban egy tábla méretkorlátja 4 GB, a nagy cégek, mondjuk, gyakran készítenek ilyen terjedelmes táblázatokat. Természetesen a fájlmód hátránya a következő tényező: minél nagyobb az adatbázis mérete, annál komolyabb a hardver erőforrásigénye. Sajnos, ha sokan dolgoznak ebben a szoftverben, vagy ha nagy táblákat kell készíteni, akkor érdemes az informatikai struktúra más megvalósítási módját választani.

És a DB menedzsment rendszerek jönnek a segítségre, amelyek kliens-szerver típusú végrehajtásban működnek. Az 1C szerver a következő típusú DBMS-eket támogatja:

    Az MS SQL Server a Microsoft által kifejlesztett DBMS. Megbízható, működőképes, de a Windows családhoz tartozó operációs rendszert igényel. Vannak bizonyos hátrányai: szereti a RAM-ot, teljesen elfoglalja, ezért manuálisan kell beállítani a korlátokat, a RAM-szivárgások rendszeresen előfordulnak a táblatömbökkel való interakció során.

    A PostgreSQL egy ingyenes terjesztés. Helyeken lassú, ami empirikusan bizonyított. Alkalmas kis létszámú személyzet számára, előfordulhat, hogy egy nagy létszám nem működik. De a hiányosságok ellenére a támogatásra nincs korlátozás e processzorok, és nincs RAM-plató.A fő követelmény a rendszergazda közvetlen kezei. Kiváló eredményeket mutat, ha helyesen van konfigurálva.

    Az Oracle Database egy verziózott DBMS, jó funkcionalitással, ugyanakkor nagyon ügyes, egyszerre teszi lehetővé az írást és az olvasást. A gyenge pont a RAM-igény.

    IBM DB2 Universal Database. Kiválóan alkalmas nagy tömbök kezelésére. Széleskörű funkcionalitással rendelkezik. Sajnos ez a DBMS sok felesleges dolgot tartalmaz az elavult számítógépekkel való kompatibilitás fenntartásához, ami csökkenti a DBMS hatékonyságát. Nem igényel RAM-ot, de az ideiglenes táblák korlátozottak. A támogatott magok maximális száma 16, ami bizonyos korlátozásokat ír elő.

A tesztek szempontjából leghatékonyabb DBMS az MS SQL Server, Oracle. Ha a költségvetésben korlátok vannak, akkor a PostgreSQL-en le kell állítani a választást, ez egy ingyenes DBMS, de ne feledje, hogy csak a célszoftverhez készült verzió működik. Az IBM DB2 Universal Database-t ritkán használják, mert vannak termelékenyebb analógok, de az elavult hardverek és összeállítások támogatására. Az IBM a legjobb.

Arra a következtetésre jutottunk, hogy mit kell implementálni a kliens-szerverben végrehajtás sokkal hatékonyabb... Ellenkező esetben fékeket és komoly korlátozásokat kapunk. Remélem, a DBMS mellett döntöttünk, de valójában azt mondom, hogy a legkényelmesebb és legnépszerűbb az MS SQL Server.Ezt a legjobban a kérdéses szoftvercsomag támogatja.

És azonnal válaszolok még egy kérdésre. Más SQL értelmezők nem támogatottak. Legalábbis hivatalosan.

Ennek megfelelően bonyolultabb lesz. Az egyes gépek klaszterekké alakulnak, a személyzet bővül és csoportokra oszlik. De az alap úgy néz ki, mint a diagram. Az 50 év feletti felhasználók számára mindenképpen két eszközt kell használnia. Az egyik adatbázisokhoz, a másik terminálkiszolgálóhoz. Ellenkező esetben a kapacitás nem lesz elegendő.

Terminálcsomópont szükséges a vékony kliens tápellátásához. Vékony kliensként működhet egy speciális eszköz, egy számítógép, akár egy okostelefon is. Ennek megfelelően minden művelet központilag, egy gépen történik. Ez szükségtelenné teszi a TC szerepében nagy teljesítményű eszközöket. Elegendő nem produktív eszköz van, amely felelős az utasítások végrehajtásának eredményeinek képernyőn történő megjelenítéséért.

Az adatbázisokhoz olyan berendezésekre van szükség, amelyek képesek egyszerre a teljes kötetet feldolgozni, és információkat továbbítani a terminál csomóponthoz, aminek nagyon erősnek kell lennie, mivel ez felelős az alkalmazások virtualizálásáért és a technikai erőforrások biztosításáért.

Minél nagyobb a szervezet, minél szélesebb a felhasználók száma, annál termelékenyebb berendezésekre lesz szükség. Bizonyos helyzetekben klaszterre van szükség. Úgy tűnik, hogy a költségek magasak, valójában olcsóbb az 1C és az alacsony fogyasztású PC-k számára szervert vásárolni, mintha ezek nélkül próbálnánk kiépíteni egy informatikai infrastruktúrát.

Felszerelés

Tehát milyen hardvert kell megvalósítanunkszerver 1C-hez ? Jó kérdés, először el kell döntenie, hogy milyen paraméterekkel összhangban állítjuk be a követelményeket:

    felhasználók száma;

    hangerő DB;

    szükséges rugalmasság;

    megvalósítás típusa.

Helyettesítsen kérdőjellel minden elemet. Válaszolj nekik. Valójában így formálódik a feladat. Most próbáljunk meg segíteni a tájékozódásban. Kezdjük kedvenc felhasználóinkkal.

Az SQL lekérdezések száma kulcsfontosságú a műszaki probléma előkészítésében. Minden személy vagy program képes bizonyos számú kérést generálni, és lefoglalja a hardver erőforrások egy részét. Tehát egy 5 felhasználós build nem biztos, hogy 10-nél működik, 50-nél a követelmények is másképp fognak kinézni. Körülbelül 100, 200 ugyanaz. Természetesen az 1C-vel automatikusan működő szoftverek egy külön téma, amely részletesebb megfontolást igényel.

Most a második pont. Van adatbázis, ennek megfelelően azt valahol el kell helyezni, a működéshez szükséges erőforrásmennyiség mellett. A feladat csak látszólag könnyű. Ki kell választania a megfelelő meghajtókat, amelyek biztosítják a sebességet és a kívánt hangerőt. Javasoljuk, hogy előre jelezzük az adatbázis lehetséges méretét, így könnyebben megfogalmazhatóak a követelmények.

A hibatűrést úgy alakították ki, hogy biztosítsa a zavartalan működést. A biztonsági mentések futása érdekében egy az eszközről mások által sokszorosított. Minél magasabb a hibatűrés szintje, annál bonyolultabb és drágább a konfiguráció.

A megvalósítás típusa – tulajdonképpen hogyan fogjuk használni, milyen célokra. Semmi bonyolult. Ha csak a számvitel, akkor az erő kevésbé lesz alapvető, de ha minden eszközt használunk, akkor erősebb technikára van szükség.

Lássuk a kiegészítőket.

processzor

Processzor legalább 1700 MHz teljesítménnyel, bár az érték alacsonyabb a követelményekben, de kellene koncentrálj rá,és a végén vegyél egy még erősebb processzort. Ideális az Intel Cor e i3-8100, Xeon E3-1220 v6 vagy AMD Ryzen 3 1200. Természetesen a legtöbb NS a termelékenység megadja Xeon, de ő a legdrágább mind közül. Ez az 5-10 emberi ... Ha növelni tervezi"felhasználók" állatállománya, akkor mindenképpen érdemes választani Xeon.

10-20 főre már az Intel Xeon E3-1230 v6 hasznos, öccsével ellentétben magasabb órajelű és többszálú. Bár ez nem annyira alapvető, a CPU egy nagyságrenddel erősebbnek bizonyul. Az olcsóbbak a Core i5-8500 és az AMD Ryzen 5 1500X. Utóbbi azonban nem fogja tudni olyan teljesítményt felmutatni, mint a Xeon. Tehát az utóbbit válaszd.

Ha az 1C szerverét 20-50 főre tervezik. Ezután a szerelvénynek produktívra van szüksége. A felhasználói szegmensben jobb, ha elfelejtjük a processzorokat, és a szerverszegmenst nézzük. Így. Ide legalább Intel Xeon E5-1650 v4 kell, 6 maggal, 12 szálal és 3,6 GHz-es alapfrekvenciával egész jó. Az AMD-től a 8 magos, 16 szálas, 2,5 GHz-es alapfrekvenciájú EPYC 7261 CPU megfelelő. Természetesen alacsonyabb teljesítményt fog mutatni, de egy kicsit olcsóbban. De nem nagyon.

50-100 felhasználónak érdemes egy pillantást vetni az Intel Xeon E5-1680 v4-ére, érezhetően erősebb a korábbi CPU-nál. 8 magja, 16 szála és 3,4 GHz-es frekvenciája van. 16 magos, 32 szálas, 2,4 GHz-es alapfrekvenciás AMD EPYC 7351 is használható. De lényegesen rosszabb, mint az Intel. De érezhetően olcsóbb is.

Komolyabb megoldásokhoz akár kétprocesszoros rendszereket, vagy szegmenses eszközöket is használhatunk. Például egy kétprocesszoros rendszerhez a Xeon E5-2643 v4 ideális. De az eszközök szegmentálása sokkal célszerűbb. Azaz egyszerre két eszközön valósítani a megoldást.

Általában meg kell jegyezni, hogy az 1C szerverében lévő magok száma nem játszik döntő szerepet. Nagyobb hangsúlyt kell fektetni az órajelre és a szekvenciális teljesítményre. Ezért biztonságosan dobja ki a többmagos CPU-kat. A felülvizsgált szoftvercsomagban a többszálú és többfeldolgozási támogatás nagyon rosszul van megvalósítva. Számos kernel nem nyújt jelentős előnyt.

Tárolóeszközök

A rendszer szűk keresztmetszete hagyományosan a HDD. Kezdjük az interfészekkel. SATA csak egymást követő kérésekre alkalmas. Bármilyen párhuzamosítást csak be lehet végezni RAJTAÜTÉS- sor. Felület SAS jobb, akár 10 egyszeri kérés, de a merevlemezek átviteli sebessége még mindig hagy kívánnivalót maga után. A legmegfelelőbb választás - SSD. Szilárdtestalapú meghajtók SAS, a SATA-tól javasoljuk, hogy megtagadják, hanem egy lehetőség, és egy kicsit olcsóbbak. Tökéletesen - SSD NVMe. Ők a leggyorsabbak a javasolt ... De sajnos nagyon drágák. Kezdje a költségvetésből, de javasoljuk, hogy válasszon SSD, akkor egy hatékonyabb rendszer kerül megvalósításra.

RAM

Nos, mindenféle apróság, mint az alaplap (ha-ha, apróság), jobb, ha további meghajtókat választunk a többi összetevőtől függően. De a tápra külön figyelmet kell fordítani, érdemes a drága címkés változatokat venni Bronz, ezüst, arany, platina. Az utóbbi a legjobb és legmegbízhatóbb, az előbbi kevésbé jó, de jobb, mint a szokásos olcsók.

Ügyeljen arra, hogy RAID 1 vagy RAID 10 (1 + 0) legyen, a második lehetőség sokkal hatékonyabb. Duplikált memóriaírást biztosítanak. Vagyis ugyanazt a dolgot több lemezre írják egyszerre. De vegye figyelembe, hogy egy RAID 10 létrehozásához 4 meghajtó szükséges.

És az utolsó pont, feltétlenül vegyen egy szünetmentes tápegységet. Áramszünet esetén lesz idő az adatok mentésére és a szerver gondos leállítására.

Nem, talán vannak még fontos pontok, csak tanulja meg ezeket a konfigurálás során, és alaposan gondolja át. Lehet, hogy a rendszert komoly ráhagyással kell elkészíteni.

felhasználó erőforrásokat vesz fel. Az olvasás azonban sokkal kevesebb erőforrást igényel, mint az olvasás/írás. Ezért egy felhasználó nagyobb terhelést tud biztosítani, mint több másik felhasználó. Az informatikai infrastruktúra tervezésénél ezt is figyelembe kell venni a kapacitás megfelelő elosztása érdekében.

Védelem. A biztonsági mentés is erőforrásokat foglal el, hogy ne zavarja a munkát, további erőforrásokat kell hozzá rendelni. A tűzfalak, vírusirtó és egyéb biztonsági eszközök szintén bizonyos mennyiségű energiát igényelnek.

Hibatűrés. Üzem közben cserélhető meghajtók vagy tápegységek, rendszerredundancia. Az alkatrészek gyors cseréjének lehetősége. Minél nagyobb a hibatűrés, annál kisebb az esélye annak, hogy egyszerűen kezelhető lesz. A legnagyobb hibatűrés a klaszterben érhető el.Szerver 1C-hez a felhasználók száma szerint

Ez egy kulcsfontosságú paraméter a felszerelés kiválasztásakor. Javasoljuk, hogy ismerkedjen meg, hogy legalább hozzávetőleges elképzelése legyen arról, mire lehet szüksége a konfiguráció kialakítása során.

1C szerver 5 felhasználó számára

Nincs szükség nagy teljesítményre 5 fő számára, a kisvállalkozási konfigurációk megfelelőek. Ha az iroda kicsi, és kompakt helyre van szüksége, akkor használhat miniszervert . Ez az opció lehetővé teszi a berendezés kompakt elhelyezését, és kényelmes lesz a szállításhoz.

Egy ilyen eszköz költsége 30 000 rubel. A konfiguráció általában nem különbözik a finomságoktól. Az Intel Xeon E3 sorozatból vagy az AMD Opteronból származó belépő szintű processzort használnak. Számos kész összeállítás létezik erre a feladatra. Ám az olcsó készülékek esetében nincs szilárdtestalapú meghajtó és mozgástér a csúcsterheléshez.

1C szerver 10 felhasználó számára

A 10 fős konfiguráció az előző megoldáshoz hasonló, nem igényel különösebb teljesítményt, elegendő egy miniszerver használata. De figyelembe kell venni a csúcsterhelést, ha vannak olyan automatizált műveletek, mint például a riportok automatikus generálása egy webáruházból, akkor a terhelés sokkal komolyabb lehet.

Itt egy Intel Xeon E3 vonalból származó processzorral is meg lehet boldogulni, például a 1240-es modellel. A RAM 8 GB-ra elég, de a 16 is jobb, és érdemes SSD-t is használni az alkalmazás és a DB tárolására.

1C szerver 20 felhasználó számára

Itt erősebb felszerelésre van szüksége, mint az előző verzióban. Egy közepes méretű vállalkozás számára az optimális választás. Az ilyen rendszerben az SSD-nek alapértelmezés szerint jelen kell lennie, és ajánlott legalább Intel Xeon E3-1280 v6 processzort használni. Ellenkező esetben nem lesz tartalék a csúcsteljesítményre.

1C szerver 50 felhasználó számára

Ebben a konfigurációban ajánlatos figyelembe venni a feladatok összetettségét. Ha nem hoznak létre komoly terhelést, akkor nincs szükség nagy kapacitásra. Erős vagy nagy adatbázismennyiség esetén nagy erőforrás-intenzitású berendezésekre lesz szükség, bizonyos esetekben eszközcsoportra van szükség.

Általában ehhez a feladathoz egy Intel Xeon E5-2643 v4 processzorokon alapuló kétprocesszoros rendszert állítanak össze. Ezek közül 2 CPU képes kielégíteni egy alkalmazás, sőt egy adatbázis igényeit is. Ideális esetben azonban az SQL-kiszolgáló létrehozása külön költséget jelent.

Természetesen ebben az esetben a szilárdtestalapú meghajtók már nem csak ajánlottak, hanem létfontosságúak, különben a lemez alrendszer szűk keresztmetszetté válik.

1C szerver 100 felhasználó számára

Ebben az esetben egy eszköz nem elegendő. Gyakran szükség van egy 1C szervercsoportra, amely képes párhuzamosan és együttesen végrehajtani a műveleteket. Egyéni fejlesztés szükséges.

De a hozzávetőleges konfiguráció a következő lenne:

  1. Terminál alkalmazásszerver. 2 Intel Xeon Silver 4215 processzor a nagy TDW SSD alkalmazásokhoz, kettős tápegység, lemezes alrendszer a rendszerállapot-mentésekhez.

    szerver SQL. Hasonló processzorok, SSD magas DWPD-vel, két tápegység és egy lemezes alrendszer RAID 1-gyel a biztonsági mentések tárolására.

Ez feltételes, a konkrétumok a végleges műszaki infrastruktúrától függenek.

Szerver 1C-hez 200 és több felhasználó számára

Ilyen számú felhasználó esetén olyan fejlett berendezésekre van szükség, amelyek bármilyen összetett feladattal megbirkóznak. Az előző verzióhoz hasonlóan egy eszköz sem lesz elég, szükség van egy fürtre. Minél magasabb az adatbázishívások és az alkalmazottak száma, annál nagyobb teljesítményre lesz szükség, és ennek megfelelően több eszközre lesz szükség a klaszterben. Nincsenek univerzális megoldások, mindegyiket egyedileg dolgozzák ki.

Körülbelül két éve publikáltunk anyagot az 1C Enterprise szerverről Linux platformon, a téma iránt továbbra is nagy az érdeklődés. Ugyanakkor sok minden megváltozott, az 1C platform nem áll meg, és a megvalósítás leggyakrabban túlmutat az utasítások egyszerű ismétlésén. Ez nem meglepő, az 1C Enterprise szerver egy összetett termék, ezért úgy döntöttünk, hogy elindítjuk ezt a cikksorozatot, amelynek célja a téma mélyebb tanulmányozása.

Mielőtt felveszi az egeret és elindul a szerverszobába, egyértelműen el kell sajátítania a szükséges minimális ismereteket, nevezetesen, hogy elképzelése legyen az 1C Enterprise szerver felépítéséről és egyes összetevőinek céljáról. A legtöbb probléma a megvalósítás során abból adódik, hogy az 1C Enterprise szervert egyfajta monolitikus képződménynek tekintik, amelyben az összes összetevő ravasz módon kapcsolódik egymáshoz, amelyet egy fejlesztő ismer. Ez azonban nem így van, és ma kitaláljuk, miből áll a szerverünk, és hogyan működik mindez egymással.

Szeretném még egyszer hangsúlyozni az alábbiakban tárgyaltak rendkívüli fontosságát. Ezen ismeretek nélkül problémás lesz a stabil működés elérése, nem beszélve a szűk keresztmetszetek diagnosztizálásáról és a termelékenység növeléséről. Ennek eredményeként klasszikus képet kaphat: a hardver erősnek tűnik, minden az utasításoknak megfelelően történt, de lelassul. Sajnos a kezdőknek szóló utasítások többsége (beleértve a mieinket is) csak arról tartalmaz információt, hogyan kell ezt megtenni, anélkül, hogy arra összpontosítana, hogy pontosan mit és miért csinál. Ezért elkezdünk javítani.

Az 1C Enterprise kliens-szerver verziója egy háromszintű struktúra (az úgynevezett "három link"), amely a következőket tartalmazza: egy kliens, egy 1C Enterprise szerver és egy DBMS szerver. Teljesen független alkatrészek, amelyek bármilyen elfogadható kombinációban kombinálhatók a legjobb eredmény elérése érdekében. Tekintsük a következő diagramot:

Kezdjük a kliensekkel, a platform jelenlegi verziója (8.2) háromféle kliens használatát teszi lehetővé. Nézzük meg őket közelebbről.

Kövér kliens

Ez egy klasszikus 1C kliens alkalmazás, a 8.2 platform megjelenése előtt ez volt az egyetlen elérhető ügyféltípus. A vastag kliens sémája a következő: a kliens alkalmazás adatokat kér az 1C szervertől, majd lekéri azokat az adatbázisból, és visszaküldi a kliensnek, amelyen feldolgozzák azokat. Amint látható, ez a séma nem optimális: az 1C szerver lényegében csak egy interlayer a kliens és az adatbázis között, minden számítás a kliensen történik. Ez fokozott követelményeket támaszt az ügyfélszámítógépekkel szemben. a szerver számítási teljesítményét nem használják fel. Világosan meg kell érteni, hogy vastag kliens módban nem fog teljesítménynövekedést elérni a kliens-szerver verzióra való váltástól, sőt, talán fordítva sem.

Vékony kliens

A 8.2-es platform fő kliens alkalmazásának nevezhető, elméletileg, a gyakorlatban nem minden olyan zökkenőmentes, erre később még visszatérünk. Működési sémája alapvetően eltérő: a kliens adatokat kér az 1C szervertől, amely az adatbázisból kapja azokat, feldolgozza és megadja a számítások eredményét az ügyfélnek. Ebben az esetben a fő számítási terhelés a szerverre esik, így a kliens PC-vel és a klienstől a szerverig tartó csatornával szemben nincs különösebb követelmény.

Ezenkívül a vékony kliens a helyi hálózatban a TCP / IP protokollon és az interneten keresztül HTTP-n keresztül is működhet. Ehhez egy másik közvetítőre van szükség - egy webszerverre, amely az ügyfélkéréseket továbbítja az 1C szervernek, a webszerveren nem történik adatfeldolgozás, kizárólag szállításként használják. A vékony kliens előnyei egyértelműek, nagy teljesítményű szerver jelenlétében lehetővé teszi a programmal való munka jelentős felgyorsítását, a hálózati forgalom is jelentősen csökken, ami nagyon fontos az irodai hálózatok számára.

Web kliens

Létezése logikusan következik egy vékonykliens egyes tulajdonságaiból, sőt, ha minden kérést a szerver dolgoz fel, a szállítás HTTP, akkor miért nem használunk böngészőt a munkához? A webkliens működési sémája nem különbözik a vékonyklienstől, de ma már nem minden vékonykliens által támogatott funkció van implementálva és működik megfelelően a webkliensben. Ez részben a konfigurációban korrigálható, részben a böngészőnek való információmegjelenítési mechanizmus korlátozza. Viszont az 1C-nek van webkliense és működik, és senki sem zavar (elméletileg megint), hogy a tengerparton fekve tablettával dolgozzon a programban.

Most egy légyről egy hordó mézben. A vékony és webes kliens módban történő normál működéshez a konfigurációnak felügyelt alkalmazás módban kell működnie, és ebben a módban támogatnia kell az összes funkciót. A felügyelt alkalmazásmód a fő a 8.2-es platformon, és gyökeresen eltér a korábbiaktól, beleértve a külsőt is. A vizuálisan vezérelt alkalmazást az új felületről lehet megkülönböztetni, amely lapokat és hiperhivatkozásokat tartalmaz:

Legalábbis szokatlan, különösen a klasszikus felülethez képest, de ne rohanjon örülni, amikor meglátja az új felületet, a megjelenésen kívül a konfigurációnak támogatnia kell a szerveren való végrehajtását minden funkciójában, Nos kiderül, hogy a vékony és webes kliens módban nem lesz elérhető minden lehetőség.

Manapság a tipikus konfigurációknak csak egy része működik menedzselt alkalmazás módban, mint például: Kisvállalat vezetése, Kereskedelmi menedzsment 11, Kiskereskedelem 2 és Bér- és személyzetkezelés. Ezek a megoldások teljes mértékben kihasználhatják az új platform előnyeit. Az Enterprise Accounting 2.0 nem használja a felügyelt alkalmazásmódot, és nem fog működni vékony és webes klienseken, ugyanez vonatkozik sok külső féltől származó megoldásra, például a „Fireplace” stb.

következtetéseket

Lehetőség szerint használjon vékony klienst, mivel ez lehetővé teszi, hogy minden számítást a szerver oldalra toljon, és kényelmesen dolgozzon még lassú csatornákon is, pl. az interneten keresztül. Emlékeztetni kell arra, hogy a Konfigurátor módban történő munkavégzés csak vastag kliensen keresztül lehetséges, amelyet olyan konfigurációkkal is kell használni, amelyek még nem kerültek át a felügyelt alkalmazás módba.

A webklienst akkor érdemes használni, ha nem lehetséges vékonyat használni, például valaki más számítógépéről üzleti úton, és fel kell készülni egyes funkciók hiányára vagy hibás működésére.

1C szerverfürt

Miután az ügyfelekkel foglalkoztunk, térjünk át a szerverekre. A rendszer három típusú szerver használatát biztosítja: Server 1C, DBMS szerver és webszerver. Fontos megérteni, hogy ezek a szerverek teljesen függetlenek egymástól, ez rugalmasságot ad a rendszernek, és lehetővé teszi a számítási erőforrások ésszerű felhasználását.

Ezenkívül a rendszer nem ír elő platformkövetelményeket. Windows és Linux szerverek is megoszthatók, az Apache és az IIS webszerverként használható, a PostgreSQL, MS SQL Server, IBM DB2 és Oracle támogatott a DBMS-ből. Ezért senki sem zavarja, hogy olyan sémát hozzon létre, amelyben egy Linux platformon futó 1C-kiszolgáló együtt fog működni egy Windows Server-t és IIS-t futtató adatbázis-kiszolgálóval, és fordítva. Ezenkívül több DBMS-kiszolgálót (valamint webszervert is) használhat különböző adatbázisokkal a különböző szervereken.

Ez a megközelítés lehetővé teszi a meglévő konfiguráció rugalmas kombinálását, bővítését és megváltoztatását az aktuális igények függvényében, miközben a végfelhasználó számára minden a lehető legátláthatóbb lesz. Például áthelyezhet egy erőforrás-igényes IS-t egy külön DBMS-kiszolgálóra, ha csak az adatbázishoz való csatlakozás paramétereit módosítja a kiszolgáló beállításaiban, anélkül, hogy az ügyfélbeállításokat befolyásolná.

És végül a legérdekesebb dolog: az 1C Enterprise szerverek fürtje. Igen, ez így van, nem egyetlen szerver, hanem egy szervercsoport. Általában itt kezdődik a zavar, különösen, ha csak egy szerver van. Azonban minden a helyére kerül, ha figyelembe vesszük, hogy a szerverfürt koncepciója elsősorban logikus, de ez a megközelítés könnyen lehetővé teszi a séma méretezését a teljesítmény vagy a hibatűrés növelésével.

Bármely fürt az 1C Enterprise Central szerverből és működő szerverekből áll. A legegyszerűbb konfigurációban ugyanaz a fizikai szerver lesz. Szükség esetén azonban további működő szervereket is hozzáadhatunk, amelyek terhelését a központi szerver fogja kiegyenlíteni. Ez lehetővé teszi a felhasználók számára, hogy gyorsan és átláthatóan növeljék a rendszer számítási teljesítményét és növeljék a hibatűrést. A fürt nem támaszt követelményeket a platform homogenitására sem, Windows és Linux szervereket is tartalmazhat.

Milyen következtetéseket lehet levonni a fentiekből? Először is, az 1C Enterprise kliens-szerver rendszer nagyon rugalmas, és lehetővé teszi a rendelkezésre álló számítási erőforrások optimális felhasználását az optimális eredmény elérése érdekében. A kiválasztandó konfiguráció a konkrét feladatoktól és a megoldásukra elkülönített forrásoktól függ.

Például, ha csekély a terhelése, és vastag klienst használ, és olyan konfigurációt használ, amely nem támogatja a felügyelt alkalmazás módot, akkor érdemes egy 1C szerverfürtöt és egy DBMS-kiszolgálót egy fizikai szerveren kombinálni, mivel ez nagyon pazarló. hogy a kliens és az adatbázis közötti réteghez külön gépet rendeljünk.

Ezzel szemben, ha egy felügyelt alkalmazást vékony kliens módban használ, jobb, ha a DBMS-kiszolgálót és a kiszolgálófürtöt külön-külön kiszolgálókra választja, amelyek mindegyike a saját feladatára lesz optimalizálva.