Mára az 1C pénzügyi termék egy könyvelési alkalmazásból egy széles formátumú komplexummá nőtte ki magát, amely szinte bármilyen típusú vállalkozást támogat, é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 osztályok átkerülnek az 1C-be, folyamatban van az IP-telefónia és a dokumentumkezelő rendszerekkel való integráció. Közvetlenül a „dolgozzunk 1C-ben” szándék után azonban kérdések merülnek fel - milyen erőforrásokon fog működni az 1C központi bázisa, milyen hardver fogja a legjobb eredményt mutatni ésszerű költségvetés mellett? A közszféra óriásvállalatainak könnyebb dolguk van ebben a helyzetben - számos főállású informatikai integrátor, építész kapott egyértelmű parancsot, nagy költségvetésű pályázatok indultak a kulcsrakész koncepció biztosításának kötelező feltételével és az minősített szakemberek által. De mi a helyzet azokkal a cégekkel, amelyek saját maguk szeretnék megvásárolni és telepíteni az 1C: Enterprise termékek valamelyikét, és okosan költik el költségvetésüket?

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 szükséges drága szerverberendezéseket vásárolni Intel Xeon processzorokkal, nem szükséges előre kiszámítani a RAM mennyiségét, a CPU és a lemez alrendszer terhelését, hogy nem kell redundánsokat 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 már az üzleti folyamatok leállításakor tudomást szerez. Ezért nagyon fontos odafigyelni az 1C szerverplatformjának minden hardvercsomópontjára.

Példák az 1C IT architektúrájának helytelen felépítéséből adódó tipikus problémákra:

• Az alap és 1C interfészek "fékezése" a kulcsfontosságú erőforrások (általában RAM vagy lemez alrendszer) túlterhelé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 meghibásodása miatt hardver.
• Az 1C adatok részleges vagy teljes elvesztése véletlenszerű hardver- vagy szoftverhibák miatt.

Az 1C szerver hardver erőforrásai

Tekintsük 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 1C alatt.

Központi feldolgozó egység (CPU)

A fizikai CPU magok száma. Az örök viták témája a különböző 1C fórumokon, hogy mi a fontosabb, mint a CPU frekvencia vagy a többmagos. Ezeknek az ellentmondásoknak a gyökerei a múltba nyúlnak vissza, az 1C 8.0-ig vagy akár az 1C 7.7-ig. Valójában az 1C végrehajtható folyamatok többek korai változatai tisztán egymagosak voltak, i.e. nem számít, hány magot biztosít a központi processzor - az 1C 8.0 vállalati szerverszolgáltatás vagy a "vastag kliens 1C 7.7" mindig csak egy "nulla" magot foglalt el. operációs rendszer. Mára megváltozott a kép – az operációs rendszer bátran elosztja egy 1C: Enterprise (rphost) folyamat feladatait több CPU mag között (lásd 1. ábra).

1. ábra - CPU terhelés az 1C szerverfolyamatok működése közben.

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 átírása az 1C programban néhány perc kérdése. Meg kell érteni az egyetlen művelet végrehajtásának sebessége és a nagy mennyiségű információ egyidejű feldolgozásának folyamata közötti különbséget. A fizikai magok száma csak lehetővé teszi, hogy megoldja az 1C: Enterprise szerver és 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 játszik a megfelelő számú mag ezen felhasználók kényelmes egyidejű működésében. 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.

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 db mennyiségben	Processzoronként 4-től

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 feladat egy darabjának feldolgozásának sebességét egy időben, ami a legnépszerűbb kritérium az 1C végfelhasználók számára. A processzor frekvenciája pontosan az a paraméter, amelynek növekedésével egyetlen felhasználó esetén 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ökkenni fog. Ennek alátámasztására a jól ismert szakember, Gilev az egyik gyakorlati teszteken alapuló cikkében 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éterét, akár egy 1C végkliens vagy 1C: Enterprise szerver. Ez az 1C program architektúrája.

Gyorsítótár, virtualizáció és hiperszál-fűzés. A múltban, amikor a többmagos processzorok még nem voltak annyira elterjedtek, az Intel feltalálta speciális technológia a központi processzor, amely többmagos szimulációt, az úgynevezett "hiperszálas feldolgozást" szimulálja. 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 kapcsolja ki a „hiperszálat” az 1C szerveren. Ez a technológia nem hoz 1C-os gyorsulást.

Használata virtuális gépek az 1C:Enterprise szerver és a DBMS esetében figyelembe kell venni, hogy a virtuális gépek magjai "gyengébbek", mint a valódi fizikai magok, bár ugyanazt nevezik - "magoknak". 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 egy scratchpad memória, amelyet a processzor használ a számítógép memóriájához való átlagos hozzáférési idő csökkentésére. Valójában a processzor szerves része, mivel ugyanazon a chipen található, és a funkcionális blokkok része. Itt minden nagyon világos - minél nagyobb a gyorsítótár, annál nagyobb "darabokat" tud feldolgozni a processzor. A gyorsítótár mérete jellemzően a processzormodellektő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 drasztikusan befolyásolná az 1C szerver és a DBMS teljesítményét. Inkább a "finomhangolás" területéhez tartozik.

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ül – lehetséges. Vegyünk egy táblázatot, amely összehasonlítja a központi két lehetőség fő paramétereit Intel processzorok(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)
Gyorsítótár	8 MB	25 MB
Frekvencia rendszerbusz	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. hangerőt és típust véletlen hozzáférésű memória	64 GB nem ECC	768 GB ECC
Becsült költség	354$	1 280$

2. táblázat – Az Intel otthoni és szerver CPU főbb paramétereinek összehasonlítása.

Amint látjuk, a szerverprocesszor sokkal magasabb értékekkel rendelkezik a magok számában, a gyorsítótár méretében, a több RAM támogatásában és természetesen magasabb áron. A szerver CPU azonban gyakorlatilag nem különbözik a felhasználói CPU-tól bizonyos processzorutasítások (utasítások) támogatása és órajel-frekvencia tekintetében. Ebből arra következtethetünk, hogy kis szervezetek számára teljesen elfogadható egyéni központi processzor használata az 1C: Enterprise szerverhez. Az egyetlen probléma az, hogy felhasználói processzort nem lehet telepíteni a szerver foglalatba. alaplapés támogatja a szerver RAM-ot paritásellenőrzéssel (ECC), és az egyedi komponensek használata a rendszer egészének stabilitását veszélyezteti.

Random Access Memory (RAM)

RAM típus. A RAM (RAM) sávja eltér a rendeltetésétől - többfelhasználós szerverrendszerekhez vagy személyes eszközökhöz - PC-k, laptopok, nettopok, vékony kliensek stb. A CPU-hoz hasonlóan - a RAM modulok fő paraméterei megközelítőleg egyenértékűek - a modern PC RAM gyakorlatilag nem marad el a szervertől egy bar térfogatban, sem órajelben, sem a DDR modulok típusában. . A szerver RAM és az "otthoni" RAM közötti különbségek a hardverplatform használati eseteiben és rendeltetésében – itt alakul ki a magasabb költsége is:

• A szerver RAM-ja ECC (Error Correction Code) paritással 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 nyílás 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 nem puffereltekkel.
• Modulok regiszter memória lehetővé teszi a memória skálázhatóságának növelésé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 egyik kulcstényező a nagy teljesítményű Az 1C szerver és a DBMS elegendő mennyiségű RAM-ot biztosít. Természetesen a tényleges RAM-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 és így tovább. 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-igény 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ó
Szerver 1c: Vállalati	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 MS SQL szerver folyamataihoz javasolt RAM hozzávetőleges aránya.

Az 1C: Enterprise (rphost.exe) szerverfolyamatokkal kapcsolatban - a modern 1C platformok ezt nem teszik lehetővé kézi üzemmód adja meg a szerverfolyamatok számát 1C. Ehelyett a rendszer megköveteli olyan paraméterek beállítását, mint a szám információs bázisokés a felhasználók száma rphost.exe folyamatonként, 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 eltávolí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 lévő SQL adatok találata legalább 90%. Ez a mérőszám nagyon hasznos, mert nem lehet csak nézni az SQL szerver által fogyasztott RAM mennyiségét - az SQL legújabb kiadásai dinamikusan fogyasztottak RAM-ot - a RAM maximális mennyiségét rögzíti és szabadítja fel, amikor más folyamatok RAM-ot igényelnek.

RAM frekvencia. Röviden, ez az áteresztőképesség csatornák, amelyeken keresztül az adatok az alaplapra, majd onnan a processzorba kerülnek. Kívánatos, hogy ez a paraméter egybeessen az alaplap megengedett frekvenciájával, vagy meghaladja azt, ellenkező esetben a RAM átviteli csatorna szűk keresztmetszetgé válhat. Az egyik típusú DDR-en 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éhez kapcsolódik.

RAM időzítése. Ez a RAM késleltetése vagy késleltetése (Latency). Ezt a paramétert az adatkésleltetési idő jellemzi a RAM chip különböző moduljai közötti átmenet során. 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álló nyomtatott áramkör(eszköz), amely az alaplap csatlakozójába csatlakozik. Professzionálisabb megoldásnak tekinthető, mivel külön chipekkel rendelkezik a kemény műveletek végrehajtásához és vezérléséhez HDD-k. Fontos szerverrendszerekhez, például 1C:Enterprise szerverhez és DBMS-hez ajánlott.

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 verzióban a lemez alrendszer "eltávolítva" a külön készülék adattároló (SHD), optikai vagy rézkábellel csatlakozik a szerverhez. Cikkünkben elemezzük az 1C önálló 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 meghajtót egyesít logikai egységgé a redundancia és a teljesítmény érdekében. Fontolja meg a legnépszerűbb RAID specifikációs szinteket:

• 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 nagymértékben javítja a teljesítményt, de rontja 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 lekérdezés 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 vagy SSD lemezeket használnak.
• RAID 10. A tükrözött lemezpárok „láncban” sorakoznak fel, így a kapott kötet térfogata meghaladhatja egy merevlemez. Véleményünk szerint a legsikeresebb lemeztömb típus, mert ötvözi a RAID1 megbízhatóságát és a RAID 0 sebességét. SAS 15K vagy SSD meghajtókkal kombinálva 40-50 felhasználó 1C szervereihez használható.
• RAID 5. Gazdaságáról ismert. Feláldozva a redundancia érdekében a tömbből csak egy lemez kapacitását, védelmet kapunk a rendszerben lévő bármelyik merevlemez meghibásodása ellen. (a RAID 6 változata további kettőt igényel merevlemezek ellenőrző összegek fogadásához, de megőrzi az adatokat akkor is, ha két lemez meghibásodik). Ez a fajta tömb gazdaságos, megbízható és meglehetősen kézzelfogható "olvasási" sebességgel rendelkezik. Sajnos ennek a tömbnek a szűk keresztmetszete az alacsony írási sebesség, ami lehetővé teszi, hogy akár 15-20 felhasználós 1C szerverkonfigurációkkal is kényelmesen használható legyen. Alkalmazott célokra is optimális - fájladatok tárolása, dokumentumkezelési archívum stb.

A merevlemez interfészek típusai. A csatlakozás típusa szerint a merevlemezek fel vannak osztva:

• HDD Sata Home. A legolcsóbb megoldás a merevlemezekhez, 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 lemezeknek az összetevőit egyszerűen nem úgy tervezték, hogy éjjel-nappal működjenek, és gyorsan meghibásodjanak.
• 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 szerverrendszerekben tesztelték teljesítményük szempontjából, és arra tervezték stabil munkavégzés 24/7 módban. Általában 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, mappák cseréje, fájlok feltöltése irodai dokumentumok stb.
• HDD SAS szerver. A SAS interfész (az SCSI modern analógja) és a Sata interfész számos. Itt az átlagos válaszidő a lemez, és a munka egy közös lemezes polcon, és a munka a HDD vezérlővel magasabb információcsere sebességgel - 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 lemezmodellek létezése. Ez az tervezési jellemző lehetővé teszi, hogy a SAS lemezek csaknem háromszor több IOPS-t hajtsanak végre a Sata Server HDD-hez képest. Az ilyen SAS lemezek kis méretűek, és 1c fő adatbázisokhoz ajánlott, állandóan nagy munkaterhelés mellett.
• SSD meghajtók. Ezek a meghajtók nem a csatlakozási felületben, hanem a kialakításukban különböznek a korábbiaktól - szilárdtestek és nincs mozgó alkatrészük, pl. lényegében a "flash drive" analógjai. Az ilyen technológiák lehetővé teszik az SSD-k számára, hogy másodpercenként „felháborító” számú I / O műveletet hajtsanak végre (a legegyszerűbb SSD-modellek 10 000 műveletéből). Ennek az előnynek azonban van egy hátránya is - az SSD-k magasabb ára és „életküszöbük”, amely az SSD-blokkok írási számának korlátjától függ. Ezek a lemezek azonban évről évre egyre olcsóbbak és tartósabbak. Mivel az SSD lemezek költsége sokszorosára nő a kötettől függően, ezért a legésszerűbb kisméretű, de túlterhelt, nagy hozzáférési sebességet igénylő 1c adatbázisokhoz, valamint TempDB ideiglenes adatbázisokhoz használni.

Az IOPS a másodpercenkénti I/O műveletek száma. Valójában az IOPS azon információblokkok száma, amelyek 1 másodperc alatt olvashatók vagy írhatók a médiára. Vagyis a legtisztább formá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 szabványos 4kb információs blokkot veszünk, akkor nagyjából a következő IOPS-mutatókat különböztethetjük meg (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 – IOPS-jelzők különféle típusú merevlemezeken, ha 4 kb-os adatblokkkal dolgozik.

Természetesen tiszta formájában az IOPS kevéssé használható 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 lemez alrendszer teljes teljesítménye a RAID tömb típusától, a lemez típusátó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ások és írások százalékos arányából és sok másból áll. tényezőket. 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 lesznek a legalkalmasabbak bizonyos igényekhez. (lásd RAID kalkulátor)

gyakorló teszt

Mi a kapcsolat az 1C felhasználók száma és az iop-ok száma között? Csapatunk gyakorlati tesztet (lásd 5. táblázat) végzett a lemez alrendszer terhelésének mérésére egy bizonyos összeget foglalkozások 1C. 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 kötnünk. Ebben a minőségben a TsUP 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 lekérdezést adtak hozzá, amelyek szimulálják egy hagyományos vállalkozás normál működését, számviteli lekérdezések, könyvelések, jelentéstétel é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
Átlagok
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 rendszerlemezére írják (amely alapértelmezés szerint az 1C:Enterprise fájljait tartalmazza. cache szerver).

Ezzel párhuzamosan a már működő 1C UPP 8.2 adatbázisok gyakorlati méréseit is elvégeztük a tesztidőszakban - 5 munkanap. Azt mutatják, hogy egy 1C + DBMS szerver átlagosan kétszer annyi iop-ot fogyaszt „íráshoz”, mint „olvasáshoz”. A szintetikus tesztek és a valódi 1C szerver megfigyelési statisztikái közötti ilyen különbség annak köszönhető, hogy a munkanap során rendszeresen mintavételezzük az adatbázisból származó információs adatokat, és rendszeresen olvassuk az adatbázist biztonsági mentés vagy DBMS replikáció.

A merevlemez további alkatrészei, amelyekre érdemes odafigyelni.

• Fizikai méret (formafaktor). A mai napig szinte az összes ismert meghajtó a személyi számítógépekés a szerverek mérete 3,5 vagy 2,5 hüvelyk. Vegye figyelembe, hogy a 2,5 hüvelykes meghajtókat nem gyártják nagy mennyiségben.
• Véletlenszerű hozzáférési idő- mire HDD garantáltan olvasási-írási műveletet hajt végre a mágneslemez egy meghatározott területén. Általános szabály, hogy több magas eredményeket szerver lemezei vannak. Ez elég fontos paraméter amikor lemeztömböt építünk az 1C DBMS szerverhez.
• 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 a mágneses lemezekkel ellátott orsó forgási sebességétől függ.
• Merevlemez puffer mérete- A puffer egy ideiglenes memória, amelyet arra terveztek, hogy kiegyenlítse a merevlemez olvasási/írási sebessége és az interfészen keresztüli adatátvitel közötti különbségeket.
• Megbízhatóság- a meghibásodások közötti átlagos idő (MTBF). Általános szabály, hogy a megbízhatóság 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 fontos merevlemez-paraméternek tartjuk, amely befolyásolja az 1C szerver minőségét.

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

A hardverelemek olcsóbbá válása és az "otthoni számítógépek" potenciális kapacitásának aktív növekedése egy másik végzetes tévhithez 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 paraméterein, a memória mennyiségén és a pénztárcabarát SSD-meghajtók normál 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 szerkezetben (lásd 6. táblázat).

Az 1C szerver megszervezésének problémájának megoldására Tier III osztályú adatközpontokban 1C felhőszerverek bérlését kínáljuk. A szerverbérlés 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
A rendszer garantált működőképessége 24/7 üzemmódban	V	x
A kulcsfontosságú hardverelemek megbízhatósága és stabilitása	V	x
Lehetőség távirányító táp és konzol (IPMI)	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 az 1C szerver minőségi működéséhez szükséges kritériumok szerint.

Hibatűrő munka 1C

Természetesen az 1C szerver része számára az egyik fontos követelmény a működés stabilitása és a meghibásodásokkal szembeni ellenállás. 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 meglehetősen komoly szinten fürtözik szolgáltatásaikat (lásd 7. táblázat).

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 adatbá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 megjelent AlwaysOn, a DBMS-adatbázisok automatikus rendszeres replikációja az elsődleges és a tartalék SQL-kiszolgálók között. Ugyanakkor a duplikált SQL szerver fizikailag egy másik tárolón található, ami növeli a kockázatokkal szembeni ellenállást

Feladatátvételi szolgáltatás szerver 1C:Enterprise

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 legfontosabb előnyök mellett ismernie kell az 1C klaszterezés és az SQL () néhány funkcióját, hogy ne romoljon a szolgáltatás teljesítménye:

• Az SQL-fürtözés virtuális IP-t használ. Ez pedig azt jelenti, hogy az 1C: Enterprise szerver és az MS SQL interakciója mindig ennek megfelelően történik hálózati felület, még akkor is, ha mindkét szolgáltatás ugyanazon az operációs rendszeren van. Ami ennek megfelelően lelassítja az 1C munkáját maga az 1C által ajánlott architektúra klasszikus verziójához - a megosztott memória használatához - képest. Ez az akadály elvileg "kikerülhető" például az MS SQL Log Shipping technológia segítségével. Ebben az esetben azonban a készenléti SQL szerverre való váltás már nem lesz automatikus, és ez a lehetőség nem tekinthető teljes értékű fürtnek.
• Az SQL-fürt nagy költségvetést igényel. Ha az MS SQL szolgáltatás klasszikus klaszterezéséről beszélünk, akkor egyetlen adatbázis tárolóra van szükség, amely a fő és a tartalék SQL szerverhez kapcsolódik. Jellemzően 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 egyetlen adatbázis tárolóra, a technológia működik vele helyi meghajtók elsődleges és tartalék szerverek a hálózaton keresztül. De szüksége van az SQL Server Enterprise egy verziójára, amelynek licence négyszer többe kerül, mint egy normál SQL Server Standardé.
• 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 a fő, mind a tartalék kiszolgálóhoz. A költségvetés szempontjából különösen fájdalmasak az SQL Server Enterprise licencei az AlwaysOn magas rendelkezésre állási csoportok elosztott fürtjének megvalósítására.

• Nem kell olcsó egyedi hardvert használnia olyan fontos dolgokhoz, mint egy vállalati szintű számviteli rendszer. Ár be ez az eset közvetlenül meghatározza egy ilyen platform minőségét, stabilitását és tartósságát.
• A szerverplatform kiválasztásakor javasoljuk, hogy ügyeljen a 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 teljesen megfelelőek, de a gyártón semmiképpen nem szabad spórolni, ez ellenőrizhetetlen vis maiorhoz vezethet az 1C-vel való munka során. Személyesen használjuk a Supermicro szerverplatformokat Intel szerver CPU-kkal kombinálva.
• A gyakorlat által megerősített vélemény szerint az 1C teljesítménye jobban függ a CPU magasabb frekvenciájától, mint a biztosított magok számától.
• Nem kell spórolnia az 1C szerverhez és az SQL szolgáltatáshoz kiosztott RAM mennyiségén. RAM bekapcsolva Ebben a pillanatban meglehetősen olcsó erőforrás, és hiánya (akár 10-15 százalékos is) az 1C rendszer teljesítményének erőteljes csökkenéséhez vezet, mert egy lassabb csererendszer engedélyezve lesz. Ráadásul a swap további terhelést ad a lemezalrendszernek, ami még tovább rontja a helyzetet.
• Az EFSOL cég átfogó szolgáltatásokat kínál az 1C szerver kiválasztásához, amely magában foglalja: 1C szerver tervezést, beszerzést, konfigurációt és karbantartást.
• A saját 1C szerver 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 dolgoznak vele, 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 a kompetens szervertervezés az 1C számára - ha a „hardvert” kezdetben rosszul választották meg, és nem felel meg a rendszer terhelésének, akkor fennáll annak a veszélye, hogy a fontos adatok megszakítás nélkül működnek. el fog veszni. Másrészt hozz létre egy szervert 1C alatt, vegyél meg minden hardvert és szoftver 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, ki fogja felügyelni az 1C-t. szerverek és hogyan. Ebből az információból indulunk ki az 1C szerver létrehozásakor.

A szerver követelményei 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 biztosítsák a következő alkatrészek stabil és kellően produktív működését:

• operációs rendszer;
• adatbázis-kiszolgáló (leggyakrabban az);
• 1C szerver rész (nem minden esetre, mivel egy kis cég 2-10 felhasználóval tud dolgozni az 1C-vel fájl módban);
• felhasználói munka távoli asztal módban;
• távoli felhasználók munkája révén vékony kliens vagy webes kliens.

Processzor kiválasztása 1C szerverhez

A processzormagok optimális számát általában az alapján számítják ki, hogy az operációs rendszer működéséhez 1-2 magot, az SQL adatbázis működéséhez 1-2 magot, az alkalmazásszerver működéséhez további 1 magot kell lefoglalni. , és körülbelül 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).

Kérjük, vegye figyelembe, hogy a kérések feldolgozási sebessége nem annyira a magok számától, hanem a processzor órajelétől függ, és a magok száma jobban befolyásolja a munka stabilitását nagyszámú felhasználó és egyidejűleg végzett feladatok esetén.

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

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

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

• 2 GB-ra lesz szükség az operációs rendszer működéséhez
• legalább 2 GB az MS SQL Server gyorsítótár számára, és jobb, ha ez az érték az adatbázis tényleges mennyiségének 20-30%-a - ez biztosítja a kényelmes felhasználói élményt 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

Íme az 1C 8.3 szerver paramétereinek hozzávetőleges számítása:

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, ez nagyon észrevehető lesz működés közben, ezért amikor arról van szó, hogy melyik 1C szervert válasszuk, mindig ügyeljünk arra, hogy elegendő RAM-mal rendelkezik.

1C szerver: berendezés 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 dolgoznak vele, másodpercenként sok adatolvasási és -írási műveletet hajtanak végre. Ez a paraméter - a merevlemez milyen sebességgel teszi lehetővé az adatok feldolgozását - szintén az 1C szerver sebességének egyik kulcsa.

Az 1C szerver tervezésekor azt javasoljuk, hogy tartsa be a következő követelményeket a lemez alrendszer berendezésére vonatkozóan:

• Nem számít, melyik szervert hozzuk 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 lesz elhelyezve.
• Javasoljuk, hogy az indexfájlokat külön SSD-re helyezze át a gyorsabb eléréshez
• TempDB - 1-2 (RAID 1) SSD-n.
• Helyezze el az operációs rendszert és a felhasználói adatokat az SSD/HDD RAID 1-jén.
• A naplófájlokhoz külön logikai lemezt foglaljon le a tömbből vagy egy fizikai SSD-lemezt.
• Ha lehetséges, használja hardveres vezérlő- Láttunk 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 tegyünk még hozzá egy dolgot - ne próbáljon pénzt spórolni azzal, hogy felhasználói számítógépet használ az 1C szerverhez (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 meghaladja a költségvetést, érdemes megfontolni az 1C telepítését a felhőben.

Ha nehéz kitalálnia, hogy melyik szervert válassza az 1C Enterprise 8.3-hoz, hogyan készítsen 1C szervert, mert még nem találkozott ezzel a feladattal, mindig felveheti a kapcsolatot egy rendszerintegrátor céggel, hogy tapasztalt műszaki szakemberek segítsenek. megfelelő szerver tervezése, vásárlása, telepítése és beállítása az 1C számára.

Kezdetben azt javaslom, hogy kiemeljek néhány munkaforgatókönyvet:

1.) A fájlbázis kezelése megosztott erőforráson (webszerveren) keresztül

2.) Munkavégzés a terminálban lévő fájlbázissal

3.) Szerver (MSSQL) adatbázissal való munkavégzés

A fájlbázis kezelése megosztott erőforráson (webszerveren) keresztül

Itt minden nagyon egyszerű. Ha ez szabályos formákés 1-3 felhasználó. Ezután a "szerveren" (a gépen, amelyen az alap fog feküdni, válassza ki:

• gyors csavarok- ügyeljen az orsó fordulatszámára (7200 ford./perc-et veszünk). Például nem a zöld sorozatot vesszük a WD-ből, hanem feketét vagy pirosat. Lásd a Seagate Constellation sorozatát.
• processzor- a magok nem olyan fontosak, mint a gyakoriságuk. Az 1C elég gyengén használja a többmagos processzort (egyáltalán nem), így a 8 magos processzorból nem lesz semmi előnye, egy 2 magos magasabb frekvenciájú processzor megteszi. Például a core i3 4360 - jelenleg ez a maximális frekvencia az Intel számára (4 GHz turbó módban).
• RAM - nem fog szerepet játszani. Figyelembe véve, hogy a modern alkalmazások hogyan fogyasztják a memóriát, tegyen 8 GB-ot
• háló- Nos, tulajdonképpen nem igazán lesz haszna az 1Gb-os hálózatnak, de ennek ellenére, ha egy 8 vezetékes csavart érpár meg van húzva (a csatlakozókba lehet nézni), akkor van értelme egy gigabites kapcsolót rakni, ugyanakkor gyorsabb lesz az időbeli fájlmegosztás.
  Az utolsó simítás ebben a forgatókönyvben pedig az, hogy nem kell az adatbázist valahol egy külön gépen elhelyezni – a régóta futó műveletek sokkal gyorsabban hajthatók végre helyben, mint a hálózaton keresztül. Tedd fel ezt az autót munkahely, ahonnan például a hónap lezárását vagy az információbiztonság frissítését tervezik.

Egy másik pont, ha az alap be van kapcsolva kezelt űrlapok. Itt, ha minden a fent leírtak szerint történik, fékeket kap. Van azonban egy kiút:

• SSD* a szokásos csavar helyett megment minket. Vegyünk egy 120 GB-os meghajtót, hiszen az árfolyam növekedését figyelembe véve is elfogadhatóak. Javaslom figyelni az intel 520/530 sorozatra, kingston v300-ra. Még jobb, ha csak olvassa el a legújabb modellekről szóló véleményeket, mert. ez a piac meglehetősen gyorsan fejlődik, és új termékek kerülnek a piacra
  *Megjegyzés: Ha a lemezeket tükrözéssel kombinálja egy RAID-ben, például RAID1. Ebben az esetben van egy olyan pillanat: a legtöbb SSD meghajtók trim szükséges a szemét eltakarításához (főleg meglehetősen régi modelleknél), raid módban előfordulhat, hogy a parancs nem támogatott, és a meghajtó működése közben csökken a sebesség. A probléma elkerülése érdekében legalább két módszert használhat: ideális esetben vásároljon vállalati szintű SSD-t, például intel DC3500-at. Ha drágának tűnik, használhat egy csomagot: alaplap chipkészlettel
• processzor- hasonlóan az előző bekezdéshez. Minél magasabb a frekvencia, annál jobb.
• RAM - nagy nem fog szerepet játszani. Figyelembe véve, hogy a modern alkalmazások hogyan fogyasztják a memóriát, tegyen 8 GB-ot

Ha 1 felhasználó helyileg dolgozik az adatbázissal, akkor ez elegendő a kényelmes munkájához, de a hálózati munka sebessége egy megosztott erőforráson keresztül továbbra is lassú lesz. De van egy kiút - dolgozzon webszerveren keresztül. Az interneten számos olyan cikket találhat, amelyek leírják, hogyan kell hasonló módon megszervezni a munkát az 1C-vel, ebben a cikkben nem foglalkozom ezzel. Az egyetlen dolog, amit megosztok veled a megfigyeléseim: jobb, ha nem webböngészőn, hanem vékony kliensen keresztül állítjuk be a munkát a felhasználók számára (amikor új adatbázist adunk az IS-listához, megjelenik egy elem webszerver" az IS elhelyezési oldalon). Ez megfigyeléseim szerint gyorsabb, mint a böngészőn keresztül. Ezenkívül a böngészőn keresztül végzett munka során hibák vannak a felületen (eltolódott PM stb.), amelyek nem jelennek meg vékony kliensen keresztül.

Valójában ezzel a recepttel (ssd, processzor magas frekvenciával, webszerver, vékony kliens). Eloszlathatja azt a mítoszt, hogy "ha a felhasználók száma több mint 1 (egyes verziók szerint több mint 0 :)) - szükség van egy szerverbázisra *.

*Bár persze azzal a feltétellel, hogy ez nem egy SCP vagy egy > ~ 4GB méretű adatbázis, de a felhasználók száma nem haladja meg a 4-et (ezek a maximális adatbázisméretek és a felhasználók száma, amit láttam, talán valaki találkozott olyan esetekkel, amikor webszerveren keresztül többen dolgoztak a fájlbázissal? Írja meg kommentben)

Munkavégzés a terminál fájlbázisával

Térjünk át a következő lehetőségre. Van terminálszerverünk és fájlbázisunk. Itt minden hasonló az 1. forgatókönyvhöz, kivéve a processzort:

• SSD meghajtó rendes csavar helyett.*
  *Jegyzet:Ügyeljen arra, hogy a lemezeket tükrözéssel rendelkező RAID-be szerelje össze, például RAID1. Ebben az esetben van egy ilyen pont: a legtöbb SSD-meghajtó vágást igényel a szemét eltávolításához (főleg meglehetősen régi modelleknél), raid módban előfordulhat, hogy a parancs nem támogatott, és a meghajtó sebessége csökkenni fog, ahogy működik. A probléma elkerülése érdekében legalább két módszert használhat: ideális esetben vásároljon vállalati szintű SSD-t, például intel DC3500-at. Ha ez drágának tűnik, használhat egyéni osztályú SSD-t, de ezután győződjön meg arról, hogy az újraírási kapacitása elegendő a forgatókönyvhöz.
• processzor- Itt van értelme i3 helyett corei5-öt venni, mert Az 1C fog működni a terminálon, további 2 mag nem zavarja, de ne felejtse el a frekvenciát.
• RAM van egy ilyen stabil kifejezés az adminok között: soha nincs sok memória). Az én gyakorlatom szerint 7 ember BP3-ban dolgozva 8-12GB-ot foglal el a terminálon (attól függ, hogy hány dokumentum van nyitva egy-egy felhasználó számára). A hagyományos űrlapoknál a memória mennyisége osztható 2-vel :). Egy hozzávetőleges számítást a következőképpen lehet elvégezni: 256 MB magának a terminál munkamenetnek + 1,5 GB 1C-nek

Szerver (MSSQL) adatbázissal való munkavégzés

Ez a forgatókönyv a legösszetettebb, és talán külön cikket igényel. Ebben a cikkben azt javaslom, hogy csak a teljesítményt befolyásoló alapelveket vegyük figyelembe

• SQL szerver és szerver elhelyezése 1C. Különböző gépeken vagy egyen. Van egy ilyen momentum: ha ugyanazon a gépen vannak, akkor a kommunikáció a megosztott memória protokollon keresztül történik közöttük, és ebben az esetben teljesítménybónuszt kapunk, ami nincs meg, ha különböző gépeken vannak.
• PROCESSZOR.És itt már hasznos és nagy órajel és többmagos. Mert van egy SQL szerver folyamatunk, ha ugyanazon a gépen van, és több 1C rphost szerver folyamat, ami betölti a processzormagokat. Külön szeretném kiemelni a kétprocesszoros rendszereket (azaz amikor az alaplapon két socket van a ill. több mint egy aljzat). Még akkor is, ha egy üres foglalattal veszel "tartalékban, vegyél később processzort, ha hirtelen szüksége lesz rá." Nagyon sok kétfoglalatos szervert láttam, amelyek életük végéig üres második foglalattal álltak. Bár ha a cég fizet... miért tagadná meg magától az örömöt :)
• RAM. Az SQL Server * munkája során aktívan használja a RAM-ot, ha nem elég, akkor felmászik a lemezekre, amelyek még ssd esetén is lassabbak, mint a RAM. Ezért itt nem érdemes a memóriával spórolni. Költségvetés a lehető legnagyobb mértékben (természetesen a józan észről se feledkezz meg :)), és hagyj szabad helyeket az alaplapon, hogy mindig szállíthass egy további rudat.
  *Megjegyzés: ne felejtse el korlátozni az SQL szerver által használt maximális RAM-ot, hogy az elegendő legyen az operációs rendszer és a terminál munkamenetekhez, valamint növelje a tmp és az SQL alap növelésének lépéseit (az alapértelmezett lépés 1 mb, ami nagyon kicsi, készlet 200 MB alap és 50 MB napló)
• lemez alrendszer. Feltűnhet az a gondolat, hogy ha a RAM mennyisége nagyobb, mint az alap mérete, akkor mindez a memóriában hever, és minden repülni fog. Lehet, hogy ... az első írási művelet előtt :), amely lemezekre fog írni. És itt a merevlemezek letörnek :) Használj SSD meghajtókat. És itt már ne spóroljon a nem asztali SSD-kkel, vegyen normál vállalati szintű SSD-ket. Intel DC3700 -200 GB erőforrás 3,7 petabájt (10 felülírás a meghajtó teljes mennyiségéből naponta 5 éven keresztül), megtalálható 24000r/db + másodperc RAID1=48000 esetén. Az engedély sokkal többet fog igénybe venni.

Úgy néz ki, ez az. Kérdés/panasz/javaslat esetén üdvözöljük kommentben;)

Az 1C:Enterprise 8 még kis számú felhasználó esetén is erőforrás-igényes alkalmazás lehet. Ha szervert választ az 1C-hez, minden tulajdonos szeretné elkerülni a "születési sérüléseket" - az esetleges szűk keresztmetszeteket. Másrészt ma már kevesen vesznek többletkapacitású szervereket, „növekedésért”. Jó, ha a terhelési profil előre eltávolítható – akkor könnyebben lehet szervert tervezni a céges alkalmazások meghatározott konfigurációjához.

A pontosság kedvéért vegyük figyelembe az „1C:Enterprise 8.2” platformot népszerű alapkonfigurációiban: „Számvitel”, „Kereskedelem és Raktár”, „Bérszámfejtés és humánerőforrás-menedzsment”, „Kereskedelmi vállalatirányítás” és részben „Gyártó vállalatirányítás” ". Abból a tényből indulunk ki, hogy az 1C-ben dolgozó 10 vagy több alkalmazottat foglalkoztató vállalkozások esetében „1C: Vállalat 8.2. Alkalmazásszerver". Vegyük figyelembe a Remote Desktop módban való munkavégzés lehetőségét, az egyidejű adatbázis-felhasználók számával 100-150-ig. Az ajánlások a „nehézebb” DB 1C-re is vonatkoznak, de a „súlyos esetek” mindig egyéni megközelítést igényelnek.

Processzorok és RAM

Ha nagyon kicsi a cég (2-7 felhasználó a rendszerben), kicsi az adatbázis (max. 1GB), és az 1C:Enterprise 8.2 fájl módban működik a felhasználó gépén, akkor a fájlszerver klasszikus megvalósítását kapjuk . Még az Intel Core i3, különösen az Intel Xeon E3-12xx is képes megbirkózni egy ilyen feladattal a CPU terhelés szempontjából. A szükséges RAM mennyisége meglehetősen egyszerű: 2 GB az operációs rendszerhez és 2 GB a rendszerfájl gyorsítótárhoz.

Ha a cégnek 5-25 1C felhasználója van, az adatbázis mérete legfeljebb 4 GB, akkor az 1C:Enterprise 8.2 alkalmazásban elegendő 4 magos Intel Xeon E3-12xx vagy AMD Opteron 4xxx. Az operációs rendszer 2 GB RAM-ja mellett 1-4 GB-ot kell lefoglalni az 1C:Enterprise 8.2 számára. Application Server" és ugyanennyi az MS SQL Server számára gyorsítótárként - összesen 8-12 GB RAM. Kisméretű adatbázisok esetén kívánatos, hogy az adatbázis legalább 30%-át a RAM-ban tárolják, és lehetőleg az összes 100%-át.

Ismert (bár nem reklámozott) tény: „1C: Enterprise 8.2. Az Application Server nem nagyon szereti, ha az operációs rendszer kirakja a merevlemezen lévő swap fájlba, és néha hajlamos a válaszadás elvesztésére. Ezért azon a kiszolgálón, ahol az "Application Server" fut, mindig legyen szabad RAM-beli tárhely - különösen, mivel ez ma olcsó.

Nagyobb cégeknél az 1C felhasználók általában távoli hozzáféréssel dolgoznak az alkalmazáshoz (Remote Desktop) - vagyis terminál módban. Általános szabály, hogy 10-100 1C-felhasználóval, 1 GB vagy nagyobb adatbázissal, az „1C:Enterprise 8.2. Application Server" és az „1C:Enterprise 8.2" felhasználói alkalmazás ugyanazon a szerveren fut.

A szükséges processzorerőforrások meghatározásához feltételezzük, hogy egy fizikai mag legfeljebb 8 felhasználói szálat képes hatékonyan feldolgozni - ez a processzorok belső architektúrájának köszönhető. Amint a gyakorlat azt mutatja, az 1C + Remote Desktop feladatokhoz ne vegyen be alacsonyabb vonalú szerverprocesszorokat alacsony frekvenciájú számítási magokkal és csonka architektúrával. Ha kevés a felhasználó (legfeljebb 15-20), akkor egy nagyfrekvenciás Intel Xeon E3-12xx processzor is elegendő. Ugyanakkor legalább egy fizikai magja (2 szál) az SQL Server igényeihez fog menni, még egy (2 szál) - az 1C:Enterprise 8.2-hez. Application Server", és a fennmaradó 2 fizikai mag (4 szál) - az operációs rendszer és a terminál felhasználók számára. Több mint 20 1C felhasználóval vagy 4 GB-nál több adatbázis-kötettel itt az ideje, hogy 2 processzoros rendszerre váltsunk Intel Xeon E5-26xx vagy AMD Opteron 62xx rendszeren.

A szükséges RAM mennyiségének kiszámítása viszonylag egyszerű: 2 GB-ot kell adni az operációs rendszernek, 2 GB vagy több - MS SQL Server gyorsítótárként (az adatbázis legalább 30%-a), 1-4 GB - az "1C: Enterprise 8.2" alatt . Application Server", a kiszolgáló többi memóriájának elegendőnek kell lennie a terminál munkamenetekhez. Egy terminál felhasználó a konfigurációtól függően a "Számvitel", "Kereskedelem és Raktár" - 100-120 MB, "Bérezés és személyi menedzsment", "Kereskedelmi vállalat vezetése" - 120-160 MB, "Kereskedelem és raktár" alkalmazásokban fogyaszt el 120-160 MB-ot. Manufacturing Enterprise" - 180-240 MB. Ha a felhasználó emellett elindítja az MS Word, MS Excel, MS Outlook alkalmazásokat a szerveren, akkor minden alkalmazáshoz további 100 MB-ot kell lefoglalni. Általános szabály, hogy a terminálszerver minimuma 12 GB RAM.

Például egy 1C szervernél a teljes szoftvercsomaggal, a Trading Enterprise Management konfigurációban 50 terminálfelhasználóval és egy 8 GB-os adatbázissal két Intel Xeon E5-2650 processzor (8 mag, 16 szál, 2,0 GHz) számítási teljesítménye optimális legyen. A RAM-hoz legalább 2 (OS) + 4 (SQL) + 4 (1C-szerver) + 8 (160 "UTP" * 50 felhasználó) = 18 GB, és lehetőleg 24-32 GB (6-8, egyenként 4 GB-os DIMM csatorna) szükséges. .

Lemez alrendszer

Az 1C:Enterprise 8 szerverek lassú működésével kapcsolatos legtöbb panasz abból adódik, hogy félreértik, milyen típusú I / O műveleteket hajtanak végre rajtuk, milyen adatokon és milyen intenzitással. Gyakran a lemez alrendszer a kulcsa a megfelelő szerverteljesítmény biztosításának – elvégre a betöltött adatbázisok esetében a legnagyobb probléma a táblák zárolása, amikor sok felhasználó dolgozik velük egyszerre vagy tömeges letöltések/feltöltések során. hozzászólások. A szerver lemez alrendszerének figyelése és optimalizálása.

Az 1C 5 adatfolyammal rendelkezik ahhoz a lemezalrendszerhez, amellyel működik:

• adatbázis táblák;
• index fájlok;
• ideiglenes fájlok tempDB;
• SQL naplófájl;
• 1C felhasználói alkalmazások naplófájlja.

Az 1C adatszerkezete objektumorientált, sok objektummal és közöttük kapcsolattal. Az adattáblázatokkal való munkavégzéshez rendkívül fontos azoknak az olvasási és írási műveleteknek a száma, amelyeket a lemezalrendszer egy adott időn belül el tud végezni (Input Output Operation per Second, IOPS). Ugyanakkor az a képessége, hogy nagy streaming adatsebességet biztosítson (MBp / s-ban), sokkal kevésbé fontos. Egy nagyon szerény, 200-300 MB-os bázis 3-5 felhasználóval akár 400-600 IOPS-t is képes előállítani csúcsidőben. Egy 10-15 felhasználós adatbázis 400-800 MB méretű 1500-2500 IOPS szállítására képes, 2-4 GB-os adatbázisból 40-50 felhasználó 5000-7500 IOPS-t generál, a 80-100 felhasználós adatbázisok pedig könnyen elérik az 12000-et. 18000 IOPS.

Természetesen a lemez alrendszer átlagos terhelése a csúcs 10-15%-a is lehet. Csak a valóságban a csúcsterhelési időszakban a teljesítmény a fontos: adatok automatikus letöltése más rendszerekről, elosztott rendszer adatcseréje vagy időszak újrafutása.

A véletlen hozzáférésű (véletlenszerű olvasási / írási) olvasási és írási műveletekben a modern meghajtók egyedül megbirkóznak az ilyen terhelésekkel:

					Intel 910 400 GB
				2400-8600 IOPS

Jól látható, hogy:

• a szűk keresztmetszet mind a HDD, mind az SSD esetében az írás;
• A hagyományos HDD-k nem vetélytársai az SSD-knek az IOPS olvasási sebességét tekintve, a különbség még elméletileg is meghaladja a két nagyságrendet;
• még a legmodernebb asztali SSD sem 3-40-szer gyorsabb (konfigurációtól függően) bármelyik HDD-nél az IOPS írási sebességét tekintve, a szerver SSD 12-40-szer gyorsabb, mint a HDD;
• A maximális teljesítményt az IOPS-ben a PCIe SSD osztályú Intel 910 vagy LSI WarpDrive biztosítja.

Az adatbázis-kiszolgálók nem használnak egyedi lemezeket, csak RAID-tömböket. A lemezalrendszer valós teljesítményének további kiszámításához figyelembe kell vennie az IOPS-be való írás költségeit („büntetését”), amelyek a RAID lemezcsoportjában merülnek fel:

Ha 6 lemezt gyűjt össze RAID 10-ben, akkor minden 1 IOPS adatnyi rekord után 2 IOPS fizikai lemezt költenek el, ha pedig RAID 6-ban, akkor 6 IOPS lemezt. Így egy lemezcsoport írási terhelhetőségének kiszámításakor először össze kell adni a RAID-csoportban lévő összes lemez IOPS-értékét, majd el kell osztani a „büntetéssel”.

1. példa: 2 SATA 7200 HDD a RAID 1-ben a következő írási lehetőséget biztosít: (100 IOPS *2) / 2 = 100 IOPS.

2. példa: 4 SATA 7200 a RAID 5-ben a következőket biztosítja: (100 IOPS *4) / 4 = 100 IOPS írásonként.

3. példa: 4 SATA 7200 a RAID 10-ben a következőket biztosítja: (100 IOPS *4) / 2 = 200 IOPS írásonként.

A 2. és 3. példa bemutatja, hogy miért részesítik előnyben a RAID 10-et olyan adatbázisok tárolására, amelyek tipikus 68/32 olvasási/írási eloszlásúak.

Ebből a három táblázatból jól látható, hogy egy tipikus "úri készlet" 2 HDD SATA 7200 teljesítménye RAID 1-ben miért nem elég egy szerver számára: csúcsterheléskor a lemezelérések sora nő, a felhasználók válaszra várnak a rendszer, néha több órán keresztül.

Hogyan lehet növelni a lemez alrendszer írási teljesítményét? Növelje a lemezek számát egy RAID-csoportban, lépjen a nagyobb forgási sebességű lemezekre, válasszon egy RAID-szintet alacsonyabb írási büntetéssel. Sokat segít a gyorsítótárazás egy RAID-vezérlővel, ha a visszaírási mód engedélyezett. Az adatok nem közvetlenül a lemezekre íródnak (mint a Write Through módban), hanem a vezérlő gyorsítótárába, és csak ezután kötegelt módban és rendezett formában lemezekre. A feladat sajátosságaitól függően az írási teljesítmény 30-100%-kal növelhető.

Enyhén terhelt vagy viszonylag kicsi (20 GB-ig) adatbázisok esetén az IOPS „kibontásának” olcsó módja a megfelelő - hibrid RAID az SSD-ről / HDD-ről. Több és nincs szükség fiókadatbázisra 3-15 felhasználó számára elosztott struktúrában, például kávézók vagy töltőállomások hálózatában.

Nagy (200 GB vagy több) hosszú adatbázisok esetén, vagy több nagy adatbázis kiszolgálása esetén az SSD-gyorsítótár (LSI CacheCade 2.0 vagy Adaptec MaxCache 3.0 technológia) hatékony lehet. Az ilyen rendszerek üzemeltetésének tapasztalatai szerint az 1C feladatokban viszonylag olcsón és a tárolási infrastruktúra jelentős változtatása nélkül használhatók a lemezműveletek 20-50%-os felgyorsítására.

Az IOPS teljesítményének bajnoka előreláthatóan a kiszolgálói SSD-k RAID-tömbjei – mind a hagyományos, SAS RAID-vezérlőt használó, mind a PCIe SSD-k esetében. Népszerűségüket két korlát akadályozza: technológiai (a RAID vezérlők teljesítménye vagy a tárolóstruktúra radikális megbontásának szükségessége) és az eladási ár.

Külön meg kell említeni az indexfájlok és a TempDB tárolását. Az indexfájlokat nagyon ritkán frissítik (általában naponta egyszer), de nagyon-nagyon gyakran olvassák (IOPS). Az ilyen adatokat egyszerűen SSD-n kell tárolni, az olvasási sebességükkel együtt! Az ideiglenes adatok tárolására használt TempDB általában kis méretű (1-4-12 GB), de nagyon igényes az írási sebességre. Az index- és az ideiglenes fájlok közös jellemzője, hogy elvesztésük nem vezet valódi adatok elvesztéséhez. Ez azt jelenti, hogy külön (még jobb - két külön kötetre) SSD-re helyezhetők. Legalábbis az alaplap beépített SATA vezérlőjén. Megbízhatóság és teljesítmény szempontjából TempDB alatt kívánatos az SSD-ről tükröt (RAID1) adni, az alaplapi vezérlőn lehetséges, de minden írási gyorsítótár kötelező leállításával. Az asztali SSD-k is megbirkóznak ezzel a szereppel – például az Intel 520-as sorozatnál, ahol a hardveres adattömörítés a TempDB-be írva megfelelő lesz. Ezeknek a feladatoknak a megosztott tárolórendszerről egy dedikált nagy sebességű alrendszerre történő eltávolítása pozitív hatással van a rendszer egészének teljesítményére, különösen csúcsterhelések idején.

Azokban az esetekben, amikor a rendszergazdák lehető leggyorsabb reakciója biztosítható meghibásodás esetén, valamint összetett számítási feladatok (raktári vagy szállítási logisztika, termelés SCP-ben, kötetcserék URDB-ben) esetén a TempDB átkerül a RAMDrive-ba. Ezzel a megoldással a rendszer teljes teljesítményének néha akár 4-12%-át is megnyerheti. Némi kellemetlenség csak a szerver újraindítása esetén merül fel: ha a RAMDrive nem indul el automatikusan, akkor a manuális indításhoz rendszergazdai beavatkozásra lesz szükség - különben az egész rendszer azzá válik.

Egy másik fontos összetevő a naplófájlok. Van egy kellemetlen tulajdonságuk bármely lemezalrendszer számára - szinte állandó kis írási hozzáférési folyamot generálnak. Ez közepes terhelésnél észrevehetetlen, de nagymértékben rontja az 1C szerver teljesítményét csúcsterhelésnél. Célszerű a naplófájlt (különösen az SQL-naplófájlt) egy különálló fizikai kötetre helyezni, amely nem rendelkezik magas IOPS-követelményekkel, és amelyre szinte lineárisan kell írni. A nyugalom érdekében tükröt készíthet olcsó és terjedelmes SATA / NL SAS-ból (teljes naplózáshoz), vagy ugyanabban az Intel 520-as sorozathoz tartozó olcsó asztali SSD-kből (egyszerű napló vagy teljes napló, napi biztonsági mentéssel és tisztítással).

Általánosságban elmondható, hogy az SSD-k megjelenése a szerverekben új lehetőségeket nyitott meg a tömegszerverek teljesítményének növelésére – a többszintű adattárolásnak és az ésszerű lemez I/O konfigurációnak köszönhetően.

Az "ideális szerver 1C alatt" lemezalrendszere így néz ki:

1. Az adatbázistáblák RAID 10 (vagy kis adatbázisok esetén RAID 1) megbízható kiszolgálói SSD-n találhatók, kötelező hardveres RAID-vezérlővel. Magas IOPS-követelmények esetén fontolja meg a PCIe SSD opciót. Nagy adatbázisok esetén hatékony a HDD-tömbök SSD-gyorsítótárazása. Ha a használt 1C konfiguráció és adatstruktúra nem túlságosan megterhelő az IOPS-sel szemben, és a felhasználók száma kicsi, akkor elegendő egy hagyományos HDD SAS 15K rpm tömb.

2. Az indexfájlokat a rendszer egy gyors és olcsó egyetlen SSD-re, a TempDB-t pedig 1-2 (RAID 1) SSD-re vagy RAMDrive-ra helyezi át.

3. Dedikált kötet (egyetlen fizikai lemez vagy RAID-1) SATA/NL SAS HDD-n vagy olcsó SSD-n, vagy logikai lemez egy RAID tömbön, amelyen a szerver operációs rendszer és a felhasználói fájlok/mappák találhatók.

4. Az operációs rendszer és a felhasználói adatok a HDD vagy SSD RAID 1-jén vannak tárolva.

Ha az informatikai infrastruktúra virtualizált, akkor nagyon kívánatos, hogy az SQL Servert ne virtuális gépként telepítsék, hanem közvetlenül egy fizikai szerverre, csupasz fémre. A kiadás ára a lemezalrendszer teljesítményének 15-35%-a (a hardvertől, illesztőprogramoktól, virtualizációs eszközöktől és kötetcsatlakozási módoktól függően). Virtualizált SQL-kiszolgálókörnyezetben az adatbázistáblákkal, indexfájlokkal és TempDB-vel rendelkező kötetek virtuális géphez való csatlakoztatása kötelező kizárólagos módban, közvetlen eléréssel.

Hálózati interfészek

A kis- és középvállalkozások (akár 100-150 aktív felhasználó egyidejűleg) 1C:Enterprise 8 rendszereinek építésekor minimálisra kell csökkenteni az Ethernet interfészen keresztüli hálózati műveletek veszteségét. Ideális esetben az SQL Server és az „1C: Enterprise 8 Application Server x64” és az 1C felhasználói munkameneteket is kiszolgálja a távoli asztalon egyetlen fizikai szerverrel. A hibatűrés szempontjából ellentmondásos ajánlás lehetővé teszi, hogy a legtöbbet hozza ki a hardverből és a szoftverből, és a virtualizáció használatával bizonyos szintű biztonságot és „környezeti megismételhetőséget” biztosít más berendezéseken.

Miért zárja ki az Ethernetet a lánc SQL szerverből -> 1C:Enterprise 8 alkalmazásszerver -> 1C:Enterprise 8 felhasználói munkamenet? Az Ethernet hálózati interfész, az adatok viszonylag kis blokkokra történő csomagolásával az átvitelhez, mindig további késéseket okoz: mind a forgalom be-/kicsomagolásakor, mind maga az átvitel során (magas késleltetés). Az 1C:Enterprise 8-ban meglehetősen nagy adattömbök kerülnek átvitelre feldolgozásra és megjelenítésre a teljes lánc mentén, bizonyos helyzetekben - mindkét irányban. Amikor adatot viszünk át közvetlenül egyik folyamatból a másikba a szerver RAM-ján belül (ugyanazon a szerveren virtualizáció nélkül), vagy virtuális hálózati interfészen keresztül (ugyanazon a fizikai szerveren, jó szerver hálózati adapterekkel a RAM blokkok átvitelével a virtuális gépek között) késések sokkal alacsonyabbak. A modern kétprocesszoros szerverek nagy RAM-mal és az SSD lemezes alrendszerével lehetővé teszik az 1C adatbázis kényelmes kiszolgálását 100-150 aktív felhasználó számára.

Ha több fizikai hoszt használata elkerülhetetlen a betöltött adatbázisoknál, akkor célszerű az összes szervert 10Gb Etherneten keresztül csatlakoztatni. Vagy legalább 2-4 összesített 1 Gb Ethernet kapcsolat TCP/IP hardveres gyorsítással (TCP/IP Offloader) és hardveres virtualizáció támogatással.

Leginkább a költségvetési megoldások szenvednek teljesítményveszteségtől az Ethernet portokon. Nem titok, hogy a legtöbb szerveralaplapra forrasztott 1 Gb-os hálózati adaptereket nem úgy tervezték, hogy nagy hálózati forgalmat kezeljenek. Még akkor is, ha az alaplapnak 2 vagy 3 GbE portja van, ezek általában asztali chipeken vannak megvalósítva. A felügyelethez elegendőek, és további általános költségeket generálnak a hálózati központok kiszolgálásához, különösen virtualizált környezetben. Az ilyen chipen keresztüli adatátvitel teljes folyamatát a processzor erőforrásai, a RAM és a belső buszok terhelése biztosítják. Az ilyen chipek semmilyen gyorsítást nem biztosítanak az IP forgalom átvitelében, minden fogadott és továbbított Ethernet csomag külön megszakítást igényel a processzor számára. Virtualizált környezetben a hálózati interfész teljesítményvesztesége elérheti a 25-30%-ot. A legkellemetlenebb az, hogy a hálózati interfész túlterhelt a felügyeleti eszközök által, és előfordulhat, hogy nem veszik észre. A központi processzort lefújják érte, és ha nem megy, akkor tétlenül várja a hálókártya válaszát. A virtualizált környezetekben az asztali chipeken lévő portokat célszerű kizárni az adatáramlásból, meghagyva azokat a szerverfelügyeleti feladatoknak. Intenzív hálózati forgalom esetén érdemes egy diszkrét hálózati kártyát feltenni a szerver chipkészletére.

Hibatűrés vagy elfogadható állásidő?

A szerver teljesítményével kapcsolatos vitákat szinte mindig a szerver megbízhatóságával kapcsolatos érvek kísérik. A hibatűrés mindig többletköltséggel jár, különösen a folyamatos gyártási folyamatok támogatása esetén. Anélkül, hogy lekicsinyelnénk az 1C szerepét és helyét, elmondhatjuk, hogy legtöbb felhasználója különböző síkon oldja meg a „teljesítmény/megbízhatóság” dilemmáját: az elsőért hardveres megoldások optimalizálásával, a másodikért a folyamatok szervezésével, ill. eljárások. Amikor az alkalmazások mérsékelten kritikusak, az egészség megőrzése során nem az egyes szerverek védelmére kell összpontosítani, hanem az infrastruktúra egészének leállásának minimalizálására.

Természetesen azoknak a vállalkozásoknak, ahol viszonylag sok egyidejűleg csatlakoztatott felhasználó (25-150) van, és minden alkalmazást egyetlen szerveren tárolnak, elengedhetetlen a szünetmentes tápegységek, maguknak a szervereknek redundáns tápegységei, a hot-swap lemezkosarak használata. és hot-standby RAID tömbök. De magát az adatok tervezett biztonsági mentését semmilyen hardver nem tudja helyettesíteni. Napi (pontosabban éjszakai) biztonsági mentés és teljes SQL naplóval rendelkező online fájl birtokában viszonylag rövid időn belül teljesen visszaállíthatja az 1C adatbázist.

A központi 1C rendszer megengedhető állásideje kis- és középvállalkozások számára havi 1-2 baleset, 1-4 óráig tart. Valójában ez egy hatalmas időhatár – ha előre készen áll a gyógyulásra. A gyors újraindítás szükséges feltétele az összes virtuális és fizikai kiszolgáló képeinek elérhetősége virtuális gép formájában egy külön tárolón / köteten - magának az infrastruktúra-résznek a visszaállításához egy tartalék szerveren. Kötelező napi (valamint hetente és időszak végén) biztonsági mentés másik fizikai eszközre és Full SQL napló olyan esetekben, amikor az adatvesztés "a munkanap elejétől" kritikus és nehezen manuálisan helyreállítható. Ha van csereberendezése, akkor általában 1-2 órán belül visszaállíthatja a munkaképességet, bár alacsonyabb termelékenység mellett. Nos, ahol 24×7 folyamatosságra van szükség, ott a megfelelő architektúra, a minimális hibapontszámmal rendelkező berendezések és a teljes körű klaszterezési technológiák kiválasztása lesz a prioritás. De ez egy teljesen más történet.

Eredeti cikk: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

A "Computer Review" folyóirat szerkesztőjének engedélyével

Az Enterprise 8 platformon futó programok hatékonyságának biztosításához nem csak vegyél 1C-t, hanem a megfelelő szervermegoldás kiválasztásához is.

Jelenleg az 1C 8 végrehajtása több változatban is megtörtént. A legnépszerűbb megoldás a dedikált fájlszerver. Ez az opció magában foglal egy dedikált számítógépet vagy egy kis szervert, egy telepített szerver operációs rendszert, valamint egy mappához való megosztott hozzáférést az 1C: Enterprise segítségével. Ez az opció meglehetősen egyszerű és megfizethető, de nem képes nagy teljesítményt és megbízhatóságot biztosítani.

Ha egy szervezetnek biztosítania kell a megbízhatóságot és a magas teljesítményt, akkor általában ezt választja az 1C 8 végrehajtása ipari DBMS - Microsoft SQL Server használatával. Ebben az esetben a Windows Server 2003 operációs rendszert használjuk, és a hardvernek magas követelményeknek kell megfelelnie.

Ez a megoldás drágább, de megvannak a maga előnyei, mint például a nagy teljesítmény és a hibatűrés. A rendszer emellett hatékony biztonsági mentést tesz lehetővé, magas szintű adatvédelmet biztosít, és meghibásodás esetén kiküszöböli a kötelező indexelést.

A rendszer megfelelő működéséhez szakképzett szakemberrel kell megvalósítani 1C programozó. Mert a tapasztalatlanok 1C programozó tagadhatja az összes előnyt - a nagy adatbázis-kötet alacsony minőségű szerverkonfigurációval jelentősen csökkenti az 1C termék teljesítményét.

Azt is érdemes megjegyezni, hogy ehhez az asztali telepítési lehetőséghez klienslicencekre van szükség a Windows Server 2003/2008 rendszerhez való csatlakozáshoz. Az 1C infobázis nagy terhelése esetén előfordulhat, hogy a Windows SBS 2003/2008 teljesítménye nem lesz elegendő. Ebben az esetben lehetőség van egy további szerver, a Microsoft SQL Server 2005/2007 kiosztására.

Egy másik módszer, amelyet gyakran használnak az 1C megvalósítása során, a terminálkiszolgáló. A Windows Server 2003 rendszerbe beépített terminálkapcsolati szolgáltatás lehetővé teszi a nagy teljesítménytartalék elérését, a biztonságos és teljes körű munkavégzés lehetőségét, valamint a magas szintű védelmet.

Az 1C: Enterprise programok végrehajtásához szükséges szoftverek listája.

Általában a következő szoftvereket használják a programok megvalósításához az 1C-n: Vállalati platform: Windows 7, Vista, XP Professional, Windows Server 2003-2008, Windows Small Business szerver.

A Windows XP Professional régóta az operációs rendszer alapverziója, és számos szervezetben telepítve van. A Windows 7 egy meglehetősen új operációs rendszer a személyi számítógépekhez, amely nagy teljesítményt nyújt a hálózatok, technológiák és rendszerek integrációja révén. A Windows Vista, XP Professional és 7 operációs rendszerrel felszerelt számítógépek belépő szintű szerverként használhatók. Ezek az operációs rendszerek akár 10 kapcsolatot is támogatnak, de a sebesség és a biztonság sok kívánnivalót hagy maga után.

A Windows Server 2003 vagy 2008 a legnépszerűbb szerver operációs rendszerek, amelyek lehetővé teszik az 1C:Enterprise megoldások megvalósítását , biztosítja a megbízhatóságot és az egyszerű karbantartást.

A Windows Small Business Server 2008 egy szoftvertermék, amely kiszolgálótermékek és további összetevők teljes csomagjából áll. Ez az opció olyan kisvállalatok számára alkalmas, amelyek nem terveznek komoly terhelést az 1C Enterprise információs bázisán. A Windows SBS 2008 fő előnye az alacsony ára.

Tehát korábban vegyél 1C-t, mérlegelni kell, hogy milyen terhelésnek lesz kitéve az adatbázis, és ennek megfelelően ki kell választani a szerver típusát.

A kiadást az 1cmarket.ru licencelt szoftverbolt készítette

Megjegyzések és vélemények

Hálózati források felfedték a Black Shark 2 Pro okostelefon részletes jellemzőit, amely hivatalosan is...

A HTC a Wildfire E modellel bővítette költségvetési okostelefonjainak kínálatát, melynek ára 9000 rubel...

Az LG bejelentette, hogy tévéik támogatni fogják az Apple AirPlay 2 és a HomeKit technológiákat. s...

A Phanteks cég egy egyedi megoldást mutatott be egy egyedi CBO összeállítására előző nap. Új Glacier D140...