Obračun poslužitelja za 1s. Cijene i postupak dostave

1C:Enterprise 8 može biti zahtjevna aplikacija čak i s malim brojem korisnika. Prilikom odabira poslužitelja za 1C, svaki vlasnik želi izbjeći "traume rođenja" - potencijalna uska grla koja su mu svojstvena. S druge strane, danas malo tko kupuje poslužitelje s viškom kapaciteta, “za rast”. Dobro je ako se profil opterećenja može unaprijed ukloniti - tada je lakše dizajnirati poslužitelj za određenu konfiguraciju aplikacija tvrtke.

Konkretno, razmotrimo platformu 1C:Enterprise 8.2 u popularnim osnovnim konfiguracijama "Računovodstvo", "Trgovina i skladište", "Upravljanje plaćama i osobljem", "Upravljanje trgovačkim poduzećem" i djelomično "Upravljanje proizvodnim poduzećem". Pretpostavljamo da se za poduzeća s 10 ili više zaposlenika koji rade u 1C koristi "1C:Enterprise 8.2". Poslužitelj aplikacija". Uzmimo u obzir mogućnost rada u Remote Desktop modu, s brojem istodobnih korisnika baze podataka do 100-150. Preporuke će se također odnositi na "teže" 1C baze podataka, ali "teški slučajevi" uvijek zahtijevaju individualni pristup.

Procesori i RAM

Ako je tvrtka vrlo mala (2-7 korisnika u sustavu), baza podataka mala (do 1GB), a "1C:Enterprise 8.2" radi u datotečnom načinu rada na računalu korisnika, tada dobivamo klasičnu implementaciju poslužitelj datoteka. Čak i Intel Core i3, posebno Intel Xeon E3-12xx. Potreban volumen RAM memorija(RAM) smatra se prilično jednostavnim: 2 GB za operativni sustav i 2 GB za predmemoriju sistemskih datoteka.

Ako tvrtka ima 5-25 1C korisnika, veličina baze podataka je do 4 GB, tada bi aplikacija 1C:Enterprise 8.2 trebala biti dovoljna za 4 Nuklearni Intel Xeon E3-12xx ili AMD Opteron 4xxx. Uz 2 GB RAM-a za OS, trebate dodijeliti 1-4 GB za 1C:Enterprise 8.2. Application Server" i isto toliko pod MS SQL Server kao cache - ukupno 8-12GB RAM-a. Za male baze podataka, preporučljivo je predmemorirati najmanje 30% baze podataka u RAM-u, ili još bolje, 100%.

Dobro je poznata (iako ne posebno reklamirana) činjenica: “1C:Enterprise 8.2. Poslužitelj aplikacija stvarno ne voli kada ga operativni sustav istovaruje u swap datoteku HDD, i ponekad gubi odgovor. Stoga na poslužitelju na kojem se izvodi “Aplikacijski poslužitelj” uvijek treba postojati rezerva slobodan prostor u RAM-u - pogotovo jer je danas jeftin.

U većim tvrtkama korisnici 1C obično rade putem daljinski pristup u aplikaciju (Remote Desktop) – odnosno u terminalskom načinu rada. U pravilu, s 10-100 1C korisnika s bazom podataka od 1 GB i više, “1C: Enterprise 8.2. Aplikacijski poslužitelj" i korisnička aplikacija "1C:Enterprise 8.2" rade na istom poslužitelju.

Da bi se odredili potrebni resursi procesora, pretpostavlja se da jedna fizička jezgra može učinkovito obraditi najviše 8 korisničkih niti - to je zbog interne arhitekture procesora. Kao što pokazuje praksa, ne biste trebali koristiti 1C + Remote Desktop za zadatke poslužiteljski procesori juniorske linije s niskim frekvencijama računalnih jezgri i ogoljelom arhitekturom. Ako ima malo korisnika (do 15-20), bit će dovoljan jedan visokofrekventni Intel Xeon E3-12xx procesor. Istovremeno, barem jedna njegova fizička jezgra (2 niti) koristit će se za potrebe SQL Servera, druga (2 niti) koristit će se za 1C:Enterprise 8.2. Application Server", a preostale 2 fizičke jezgre (4 niti) su za OS i korisnike terminala. Ako je broj korisnika 1C veći od 20 ili ako je volumen baze podataka veći od 4 GB, vrijeme je za prelazak na 2-procesorske sustave na Intel Xeon E5-26xx ili AMD Opteron 62xx.

Izračun potrebne količine RAM-a relativno je jednostavan: 2 GB treba dati OS-u, 2 GB ili više MS SQL Serveru kao predmemorija (najmanje 30% baze podataka), 1-4 GB 1C:Enterprise 8.2. Application Server", preostala memorija poslužitelja trebala bi biti dovoljna za terminalske sesije. Jedan korisnik terminala, ovisno o konfiguraciji, troši u aplikacijama „Računovodstvo“, „Trgovina i skladište“ - 100-120 MB, „Plaće i upravljanje osobljem“, „Upravljanje trgovačkim poduzećem“ - 120-160 MB, „Upravljanje proizvodnim poduzećem“ - 180-240 MB. Ukoliko korisnik dodatno pokreće MS Word, MS Excel, MS Outlook na poslužitelju, tada se za svaku aplikaciju mora izdvojiti oko 100MB. Obično je minimum za terminalski poslužitelj 12 GB RAM-a.

Na primjer, za 1C poslužitelj s cijelim programskim paketom, 50 korisnika terminala u konfiguraciji "Trading Enterprise Management" i bazom podataka od 8 GB, optimalna računalna snaga bit će dva procesora Intel Xeon E5-2650 (8 jezgri, 16 niti, 2,0 GHz). RAM će trebati najmanje 2 (OS) + 4 (SQL) + 4 (1C poslužitelj) + 8 (160 “USP” * 50 korisnika) = 18 GB, ili još bolje 24-32 GB (6-8 DIMM kanala od 4 GB).

Diskovni podsustav

Većina pritužbi na spor rad 1C:Enterprise 8 poslužitelji povezani su s nedostatkom razumijevanja koje se vrste I/O operacija izvode na njima, nad kojim podacima i kojim intenzitetom. Često je diskovni podsustav ključan za osiguravanje dostatnih performansi poslužitelja u cjelini - na kraju krajeva, za zauzete baze podataka najveći problem predstavlja zaključavanje tablica kada s njima radi više korisnika istovremeno ili tijekom masovnih preuzimanja/istovara/objavljivanja . Praćenje i optimizacija diskovnog podsustava poslužitelja.

1C ima 5 tokova podataka za diskovni podsustav s kojim radi:

  • tablice baze podataka;
  • indeksne datoteke;
  • privremene datoteke tempDB;
  • SQL log datoteka;
  • log datoteka 1C korisničkih aplikacija.

Struktura podataka u 1C je objektno orijentirana, s mnogo objekata i veza između njih. Pri radu s podatkovnim tablicama iznimno je važan broj operacija čitanja i pisanja koje diskovni podsustav može izvesti u određenom vremenskom razdoblju (Input Output Operation per Second, IOPS). U isto vrijeme, njegova sposobnost da pruži visoke brzine prijenosa podataka (u MBp/s) mnogo je manje važna. Vrlo skromna baza podataka od 200-300MB s 3-5 korisnika može generirati do 400-600 IOPS u vršnim intervalima. Baza podataka s 10-15 korisnika i volumenom od 400-800MB sposobna je proizvesti 1500-2500 IOPS, 40-50 korisnika baze podataka od 2-4GB generira 5000-7500 IOPS, a baze podataka s 80-100 korisnika lako dosegnu 12000- 18000 IOPS.

Naravno, prosječno opterećenje diskovnog podsustava može biti 10-15% od vrha. Samo što je u stvarnosti važna izvedba tijekom razdoblja najvećeg opterećenja: automatska preuzimanja podaci iz drugih sustava, razmjena podataka distribuiranog sustava ili ponovno izvođenje razdoblja.

Moderni diskovi u operacijama čitanja i pisanja s nasumičnim pristupom (Random Read/Write) sami se nose sa sljedećim opterećenjima:

Intel 910 400 GB

2400 – 8600 IOPS

Jasno se vidi da:

  • usko grlo i za HDD i za SSD je snimanje;
  • tradicionalni HDD-ovi nisu konkurenti SSD-ovima u pogledu brzine čitanja u IOPS-u, čak i teoretski, razlika prelazi dva reda veličine;
  • Čak je i ne tako moderan desktop SSD 3-40 puta (ovisno o konfiguraciji) brži od bilo kojeg HDD-a u IOPS brzini pisanja, poslužiteljski SSD je 12-40 puta brži od HDD-a;
  • Maksimalne performanse u IOPS-u osiguravaju PCIe SSD klase Intel 910 ili LSI WarpDrive.

Pojedinačni diskovi se ne koriste u poslužiteljima baza podataka, samo RAID polja. Da biste dodatno izračunali stvarne performanse diskovnog podsustava, morate uzeti u obzir troškove („kazne“) za pisanje u IOPS, koje snosi grupa diskova u RAID-u:

Ako sastavite 6 diskova u RAID 10, tada će se za svaki upis od 1 IOPS podataka potrošiti 2 IOPS fizičkih diskova, a ako u RAID 6, onda će se potrošiti 6 IOPS diskova. Dakle, kada izračunavate kapacitet opterećenja diskovne grupe, prvo morate zbrojiti IOPS svih diskova u RAID grupi, a zatim ih podijeliti s "kaznom".

Primjer 1: 2 HDD SATA 7200 u RAID 1 osigurat će kapacitet pisanja: (100 IOPS *2) / 2 = 100 IOPS.

Primjer 2: 4 SATA 7200 u RAID 5 osigurat će kapacitet pisanja: (100 IOPS *4) / 4 = 100 IOPS.

Primjer 3: 4 SATA 7200 u RAID 10 osigurat će kapacitet pisanja: (100 IOPS *4) / 2 = 200 IOPS.

Primjeri 2 i 3 jasno pokazuju zašto je RAID 10 poželjniji za pohranu baza podataka s tipičnom distribucijom čitanja/pisanja 68/32.

Iz ove tri tablice jasno je zašto je izvedba tipičnog " gospodski set» 2 HDD SATA 7200 u RAID 1 poslužitelju nije dovoljno: tijekom vršnih opterećenja red zahtjeva za diskom raste, korisnici čekaju odgovor od sustava, ponekad i više sati.

Kako povećati performanse pisanja diskovnog podsustava? Povećavaju broj diskova u RAID grupi, prelaze na diskove s većom brzinom rotacije i odabiru razinu RAID-a s nižom kaznom pisanja. Predmemoriranje pomoću RAID kontrolera s omogućenim načinom pisanja unazad puno pomaže. Podaci se ne zapisuju izravno na diskove (kao u Write Through modu), već u predmemoriju kontrolera, a tek onda, u paketnom načinu iu uređenom obliku, na diskove. Ovisno o specifičnostima zadatka, performanse snimanja mogu se povećati za 30-100%.

Za malo opterećene ili relativno male baze podataka (do 20 GB), prikladna je jeftina metoda "izvlačenja IOPS" - hibridni RAID sa SSD/HDD. Baza podataka podružnica za 3-15 korisnika u distribuiranoj strukturi poput lanca kafića ili servisa ne treba više.

Za velike (200 GB ili više) baze podataka s dugim povijesnim tragom podataka ili za servisiranje nekoliko velikih baza podataka, SSD predmemorija (tehnologije LSI CacheCade 2.0 ili Adaptec MaxCache 3.0) može biti učinkovita. Na temelju iskustva rada s takvim sustavima, upravo se u zadacima 1C mogu koristiti za ubrzanje diskovnih operacija za 20-50% relativno jeftino i bez značajnih promjena u infrastrukturi za pohranu.

Šampion u performansama u IOPS-u su očekivano RAID nizovi na SSD-ovima poslužitelja - i tradicionalni, koji koriste SAS RAID kontroler, i PCIe SSD. Dva ograničenja koče njihovu popularnost: tehnološka (izvedba RAID kontrolera ili potreba za radikalnim razbijanjem strukture pohrane) i cijena implementacije.

Posebno treba spomenuti pohranjivanje indeksnih datoteka i TempDB. Indeksne datoteke ažuriraju se vrlo rijetko (obično jednom dnevno), ali se čitaju vrlo, vrlo često (IOPS). Takve podatke jednostavno treba pohraniti na SSD, s njihovim učinkom čitanja! TempDB, koji se koristi za pohranu privremenih podataka, obično je male veličine (1-4-12GB), ali vrlo zahtjevan u pogledu brzine pisanja. Ono što je zajedničko indeksu i privremenim datotekama jest da njihov gubitak ne rezultira gubitkom stvarnih podataka. To znači da se mogu staviti na poseban (još bolje - na dva odvojena volumena) SSD. Barem na ugrađenom SATA kontroleru matične ploče. Sa stajališta pouzdanosti i performansi, preporučljivo je osigurati mirror (RAID1) sa SSD-a za TempDB, što se može učiniti na on-board kontroleru, ali uz obavezno onemogućavanje svih predmemorija pisanja. SSD-ovi za stolna računala također se mogu nositi s ovom ulogom - poput serije Intel 520, gdje će hardverska kompresija podataka prilikom pisanja u TempDB biti prikladna. Uklanjanje ovih zadataka iz zajednički sustav pohranjivanje na namjenskom podsustavu velike brzine ima pozitivan učinak na performanse sustava u cjelini, posebno tijekom vršnih opterećenja.

U slučajevima kada je moguće osigurati najbrži mogući odgovor administratora u slučaju kvarova, te kada se radi o složenim računskim zadacima (skladišna ili transportna logistika, proizvodnja u UPP-u, razmjene volumena u URDB), TempDB se prenosi u RAMDrive. Ovo rješenje ponekad vam omogućuje da dobijete do 4-12% ukupne performanse sustava. Određene neugodnosti nastaju samo ako se poslužitelj ponovno pokrene: ako se RAMDrive ne pokrene automatski, bit će potrebna intervencija administratora za ručno pokretanje - inače će cijeli sustav propasti.

Druga važna komponenta su log datoteke. Imaju neugodnu značajku za bilo koji diskovni podsustav - generiraju gotovo konstantan tok malih zahtjeva za pisanje. To je neprimjetno pod prosječnim opterećenjima, ali uvelike degradira performanse 1C poslužitelja pod vršnim opterećenjima. Logičnu datoteku (osobito SQL log datoteku) ima smisla premjestiti na zaseban fizički volumen koji nema visoke zahtjeve za IOPS i primat će gotovo linearna pisanja. Radi bezbrižnosti, možete stvoriti zrcalo od jeftinih i glomaznih SATA/NL SAS (za puni zapis) ili jeftinih SSD-ova za stolna računala iste serije Intel 520 (jednostavni zapis ili puni zapis, uz svakodnevno sigurnosno kopiranje i čišćenje).

Općenito, možemo reći da je dolazak SSD-ova u poslužitelje otvorio nove mogućnosti za povećanje performansi masovno proizvedenih poslužitelja – kroz pohranu podataka na više razina i razumnu konfiguraciju diskovnih I/O.

Podsustav diska "idealnog poslužitelja za 1C" izgleda ovako:

1. Tablice baze podataka smještene su na RAID 10 (ili RAID 1 za male baze podataka) s pouzdanih SSD-ova poslužitelja s obaveznim hardverskim RAID kontrolerom. Za visoke IOPS zahtjeve, možete razmotriti opciju PCIe SSD. Za velike baze podataka, SSD predmemoriranje HDD polja je učinkovito. Ako korištena 1C konfiguracija i struktura podataka nisu prezahtjevni za IOPS, a broj korisnika je mali, bit će dovoljan tradicionalni niz HDD SAS 15K rpm.

2. Indeksne datoteke smještene su na brzi i jeftini pojedinačni SSD, TempDB - na 1-2 (RAID 1) SSD ili RAMDrive.

3. Za SQL (i po mogućnosti 1C) log datoteke, namjenski volumen (jedan fizički disk ili RAID-1) dodjeljuje se na SATA/NL SAS HDD ili jeftinom SSD-u, ili logički pogon na RAID polju na kojem se nalazi operativni sustav poslužitelja i korisničke datoteke/mape.

4. Operativni sustav i korisnički podaci pohranjuju se na RAID 1 s HDD-a ili SSD-a.

Ako je IT infrastruktura virtualizirana, vrlo je poželjno da SQL Server nije instaliran kao virtualni stroj, već izravno na fizički poslužitelj, na goli metal. Cijena izdavanja je od 15 do 35% performansi diskovnog podsustava (ovisno o opremi, upravljačkim programima, alatima za virtualizaciju i metodama povezivanja volumena). U virtualiziranom okruženju SQL poslužitelja, povezivanje volumena s tablicama baze podataka, indeksnim datotekama i TempDB-om na VM potrebno je u ekskluzivnom načinu rada putem izravnog pristupa.

Mrežna sučelja

Prilikom izgradnje sustava 1C:Enterprise 8 za mala i srednja poduzeća (do 100-150 aktivnih korisnika istovremeno), gubitke u mrežnim operacijama putem Ethernet sučelja treba svesti na minimum. U idealnom slučaju poslužite i SQL Server, 1C:Enterprise 8 Application Server x64 i 1C korisničke sesije na udaljenoj radnoj površini s jednim fizičkim poslužiteljem. Kontroverzna sa stajališta osiguranja tolerancije na greške, takva preporuka omogućuje da izvučete maksimum iz hardvera i softvera, a korištenjem virtualizacije pruža određenu razinu sigurnosti i „ponovljivosti okruženja“ na drugoj opremi.

Zašto isključiti Ethernet iz lanca SQL poslužitelj -> Application Server 1C: Enterprise 8 -> korisnička sesija 1C: Enterprise 8? Ethernet mrežno sučelje svojim pakiranjem podataka u relativno male blokove za prijenos uvijek će stvarati dodatna kašnjenja: kako tijekom pakiranja/raspakiranja prometa, tako i tijekom samog prijenosa (visoka latencija). U 1C:Enterprise 8 prilično velike količine podataka prenose se za obradu i prikaz duž cijelog lanca, u nekim situacijama - u oba smjera. Pri izravnom prijenosu podataka iz jednog procesa u drugi unutar RAM-a poslužitelja (na jednom poslužitelju bez virtualizacije), ili putem virtualnog mrežnog sučelja (unutar istog fizičkog poslužitelja, s dobrim mrežnim adapterima poslužitelja s prijenosom RAM blokova između VM-ova) latencija je velika niži. Moderni dvoprocesorski poslužitelji s velikim RAM-om i podsustavom SSD diska omogućuju udobno posluživanje 1C baze podataka za 100-150 aktivnih korisnika.

Ako je korištenje nekoliko fizičkih hostova neizbježno za opterećene baze podataka, preporučljivo je povezati sve poslužitelje putem 10Gb Etherneta. Ili barem 2-4 agregirane 1Gb Ethernet veze s hardverskim TCP/IP ubrzanjem (TCP/IP Offloader) i hardverskom podrškom za virtualizaciju.

Najviše od svih gubitaka produktivnosti na Ethernet priključci odluke o proračunu trpe. Nije tajna da mrežni adapteri 1Gb, zalemljen na većini poslužitelja matične ploče, nisu dizajnirani za rukovanje velikim mrežnim prometom. Čak i ako ploča ima 2 ili 3 GbE priključka, oni su obično implementirani na čipovima za stolna računala. Iako su dovoljni za upravljanje, oni stvaraju dodatne troškove za servisiranje mrežnih komunikacija, posebno u virtualiziranom okruženju. Cijeli proces prijenosa podataka kroz takav čip osiguran je resursima procesora, RAM-a i opterećenja internih sabirnica. Takvi čipovi ne daju nikakvo ubrzanje u prijenosu IP prometa; svaki primljeni i odaslani Ethernet paket zahtijeva poseban prekid procesora. U virtualiziranom okruženju, gubici performansi mrežnog sučelja mogu doseći 25-30%. Najneugodnije je to što se možda neće primijetiti preopterećenje mrežnog sučelja alatima za nadzor. Preuzeti rap umjesto njega CPU, a ako ne radi, onda miruje i čeka odgovor mrežne kartice. Preporučljivo je isključiti priključke na desktop čipovima iz protoka podataka u virtualiziranim okruženjima, ostavljajući ih za zadatke upravljanja poslužiteljem. Za intenzivan mrežni promet vrijedi dodati diskretni Mrežna kartica na čipsetu poslužitelja.

Tolerancija na pogreške ili prihvatljivo vrijeme prekida rada?

Rasprave o performansama poslužitelja gotovo su uvijek popraćene raspravama o njihovoj pouzdanosti. Osiguravanje tolerancije na greške uvijek zahtijeva dodatne troškove, posebno kada podržava kontinuirane proizvodne procese. Ne umanjujući ulogu i mjesto 1C, možemo reći da većina njegovih korisnika dilemu "performanse/pouzdanost" rješava u različitim planovima: za prvo se bore optimizacijom hardverskih rješenja, za drugo - organiziranjem procesa i procedura. Kada su aplikacije umjereno kritične, glavni fokus u održavanju operativnosti nije na pojedinačnoj zaštiti poslužitelja, već na minimiziranju zastoja infrastrukture u cjelini.

Naravno, za poduzeća s relativno veliki iznos istovremeno spojenih korisnika (25-150) i smještaj svih aplikacija na jednom poslužitelju, potrebno je koristiti besprekidna napajanja, redundantna napajanja samih poslužitelja, hot-swappable disk košarice i hot-standby RAID polja. Ali nijedan hardver ne može zamijeniti planiranu sigurnosnu kopiju samih podataka. Imajući dnevnu (točnije, noćnu) sigurnosnu kopiju i radnu datoteku s punim SQL zapisnikom, možete u potpunosti vratiti 1C bazu podataka u relativno kratkom roku.

Dopušteni zastoj centralnog 1C sustava za mala i srednja poduzeća je 1-2 nesreće mjesečno, u trajanju od 1-4 sata. Zapravo, ovo je ogromna rezerva vremena - ako ste unaprijed spremni za oporavak. Neophodan uvjet za brzo ponovno pokretanje je prisutnost slika svih virtualnih i fizičkih poslužitelja u obliku VM-a na zasebnoj pohrani/volumenu – za vraćanje samog infrastrukturnog dijela na backup poslužitelju. Dnevna sigurnosna kopija je potrebna (kao i tjedno i na kraju razdoblja) za drugog fizički uređaj i Potpuni SQL zapisnik za slučajeve kada je gubitak podataka "od početka radnog dana" kritičan i teško ga je ručno vratiti. Ako imate zamjensku opremu, to možete učiniti za 1-2 sata kako biste vratili cjelokupnu funkcionalnost, iako uz manju produktivnost. Pa, tamo gdje je potreban kontinuitet rada 24×7, primarni zadaci bit će odabir odgovarajuće arhitekture, opreme s minimalnim brojem točaka kvara i potpune tehnologije klasteriranja. Ali to je sasvim druga priča.

Izvorni članak: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

Uz dopuštenje urednika časopisa "Computer Review"

Prilikom odabira poslužitelja koji je potreban za 1C, trebali biste imati na umu da će se, dok korisnici rade s njim, mnoge operacije čitanja i pisanja podataka izvoditi u sekundi.

Najvjerojatnije je odmah jasno zašto je kompetentan dizajn poslužitelja za 1C toliko važan - ako je hardver u početku pogrešno odabran i ne odgovara opterećenju sustava, tada postoji rizik da će raditi povremeno ili da će važni podaci biti biti izgubljen. S druge strane, napravite poslužitelj za 1C, kupite sav hardver i softver može koštati značajan iznos za tvrtku, stoga je preporučljivo odabrati opremu na takav način da se izbjegnu nepotrebni troškovi.

Odabir poslužitelja za 1C

Kada naši stručnjaci trebaju odabrati konfiguraciju za 1C poslužitelj, prvo što pitaju je koliko će korisnika raditi s 1C u tvrtki i koji skup usluga planiraju koristiti, što će biti, tko će administrirati 1C poslužitelji i kako. Polazimo od ovih informacija pri izradi 1C poslužitelja.

Zahtjevi za 1C poslužitelj

U hardverskoj strukturi 1C poslužitelja bit će nam važne karakteristike procesora, RAM-a, diskovnog podsustava i mrežnih sučelja.

Potrebno je osigurati stabilan i dovoljno produktivan rad sljedećih komponenti:

  • operacijski sustav;
  • poslužitelj baze podataka (najčešće ovo);
  • 1C poslužiteljski dio (ne za sve slučajeve, budući da mala tvrtka s 2-10 korisnika može raditi s 1C u načinu rada datoteke);
  • Korisnici rade u načinu udaljene radne površine;
  • rad udaljenih korisnika putem tankog klijenta ili web klijenta.

Odabir procesora za 1C poslužitelj

Optimalan broj procesorskih jezgri obično se izračunava na temelju činjenice da je potrebno 1-2 jezgre rezervirati za rad OS-a, 1-2 jezgre za rad SQL baze podataka, još 1 za pokretanje aplikacijskog poslužitelja i otprilike 1 jezgra za svakih 8-10 istovremenih korisničkih sesija (kako se korisnici kasnije ne bi žalili da je 1C poslužitelj spor).

Imajte na umu da brzina obrade zahtjeva ne ovisi toliko o broju jezgri, koliko o frekvenciji takta procesora, a broj jezgri ima veći utjecaj na stabilnost rada s velikim brojem korisnika i istovremenim zadacima od njih .

Koliko memorije treba 1C poslužitelj?

Uz gore navedeno, ako vam je potreban 1C poslužitelj za 100 ili više korisnika, preporučujemo postavljanje klastera od najmanje dva fizička 1C poslužitelja.

Predlažemo izračunati veličinu potrebnog RAM-a na temelju sljedećih pokazatelja:

  • Za operativni sustav bit će potrebno 2 GB
  • najmanje 2 GB za pokretanje predmemorije MS SQL Servera, a bolje je da ta vrijednost iznosi 20-30% stvarnog volumena baze podataka - to će korisnicima osigurati udoban rad s njom
  • 1 – 4 GB za 1C aplikacijski poslužitelj
  • Za jednu sesiju korisničkog terminala bit će potrebno 100 – 250 MB, ovisno o skupu funkcija 1C poslužitelja i korištenoj konfiguraciji

Evo naših približnih izračuna parametara 1C 8.3 poslužitelja:

Bolje je kupiti RAM s rezervom - ovo je jedan od najvažnijih čimbenika visokih performansi 1C poslužitelja, a istovremeno je sada jedna od najjeftinijih komponenti. Ako na poslužitelju 1C Enterprise nema dovoljno memorije, to će biti vrlo vidljivo tijekom rada, stoga, kada je pitanje koji 1C poslužitelj odabrati, uvijek obratite pozornost na to da ima dovoljno RAM-a.

Server 1C: oprema za diskovni podsustav

Prilikom odabira poslužitelja koji je potreban za 1C, trebali biste imati na umu da će se, dok korisnici rade s njim, mnoge operacije čitanja i pisanja podataka izvoditi u sekundi. Ovaj parametar - brzina kojom vam tvrdi disk omogućuje obradu podataka - također je jedan od ključnih parametara za performanse 1C poslužitelja.

Prilikom projektiranja 1C poslužitelja preporučujemo poštivanje sljedećih hardverskih zahtjeva za diskovni podsustav:

  • Nije važno kakvu vrstu poslužitelja kreirate za 1C, ni pod kojim uvjetima ne preporučujemo korištenje pojedinačnih diskova u poslužiteljima - preporučljivo je organizirati ih u RAID nizove (RAID 10 za velike ili RAID 1 za male baze podataka), gdje baza podataka stolovi će se nalaziti.
  • Preporučujemo premještanje indeksnih datoteka na zaseban SSD radi bržeg pristupa njima
  • TempDB - na 1-2 (RAID 1) SSD.
  • Postavite OS i korisničke podatke na RAID 1 sa SSD/HDD.
  • Za zapisničke datoteke dodijelite zaseban logički disk iz polja ili fizički SSD disk.
  • Ako je moguće, koristite hardverski kontroler - vidjeli smo situacije u kojima je moćan i skup poslužitelj usporen zbog nedovoljne izvedbe kontrolera.

Izbor poslužitelja za 1C

U ovom smo članku dali neke savjete i grube izračune o tome kako odabrati poslužitelj za 1C, nadamo se da će vam biti korisni.

Zaključno, dodajmo još jednu stvar - ne biste trebali pokušavati uštedjeti novac korištenjem korisničkog računala za 1C poslužitelj (kao što se često radi u malim tvrtkama) - korisnički hardver je mnogo manje pouzdan i tolerantan na greške od poslužiteljskog hardvera sličnu izvedbu. Ne biste trebali riskirati računovodstveni sustav svoje tvrtke. Ako kupnja odgovarajućeg hardvera nije unutar vašeg proračuna, možda biste trebali razmotriti implementaciju 1C u oblaku

Ako vam je teško shvatiti koji poslužitelj odabrati za 1C Enterprise 8.3, kako napraviti 1C poslužitelj, jer se prije niste susreli s ovim zadatkom, uvijek se možete obratiti tvrtki za integraciju sustava kako bi vam iskusni tehnički stručnjaci mogli pomoći u dizajnu , kupite, instalirajte i postavite poslužitelj koji vam odgovara za 1C.

Razmatraju se verzije 8.2 i 8.3 platforme 1C:Enterprise standardna aplikacija za računovodstvene i upravljačke poslove poduzeća. Razvijen je širok raspon aplikativnih rješenja za javna i privatna poduzeća. Prilikom implementacije vlastite informacijske infrastrukture, svaki izvršni ili IT menadžer tvrtke ima pitanje kakav je poslužitelj potreban za 1C. Problem je kompliciran činjenicom da kupnja opreme zahtijeva značajne financijske troškove, a ne može si svako poduzeće priuštiti odabir vrhunskih konfiguracija.

Prikupili smo preporuke vodećih proizvođača opreme (HP, Dell, IBM) i programera softverski proizvod"1C" 8.3 kako bi naši klijenti mogli isplativo kupovati potreban poslužitelj. Optimalna mrežna infrastruktura može se dobiti na temelju bilo kojeg operativnog sustava, ali značajniju ulogu u tome imaju hardverske mogućnosti.

Kriteriji odabira poslužitelja

1C platforma može zahtijevati značajne hardverske resurse od poslužitelja. Ako je proračun tvrtke neograničen, što je rijetkost slučaj, možete preuzeti platformu bez oklijevanja posljednje generacije, napuniti sve disk košarice, RAM utore i zahtijevati od informatičara da osigura nesmetan rad sustava. Odabir opreme s ograničenim sredstvima zahtijeva promišljeniji pristup. Da biste razumjeli koji će se 1C poslužitelj moći nositi s tim, potrebno je pažljivo analizirati strukturu računalnih opterećenja. Ako su unaprijed poznati, bit će puno lakše osmisliti gotovo rješenje.

Prilikom odabira poslužitelja za "1C" (8.2; ​​​​8.3), oni se vode sljedećim točkama:

  • broj operatera koji istovremeno obavljaju unos podataka i generiraju izvješća;
  • mogućnost dodjele zasebnih fizičkih poslužitelja za SQL i 1C aplikaciju;
  • planirane količine obrade podataka;
  • struktura raspodjele opterećenja u arhitekturi klijent-poslužitelj

Odabir procesora i RAM-a

Izračun frekvencije, potrebnog broja procesorskih jezgri i količine RAM-a prvi je i najvažniji korak. Da bismo razmotrili nekoliko opcija, odabrat ćemo poslužitelj za 1C uzimajući u obzir osoblje tvrtke.

Mala organizacija (do 15 zaposlenika). S malim brojem korisnika, volumen baze podataka u pravilu ne prelazi 2 GB, a program 1C u obliku verzije datoteke instaliran je na klijentskim računalima. Potrebe OS-a u ovom slučaju iznose 4-6 GB, a još 4 GB je dodijeljeno za predmemoriju sistemskih datoteka. Raspodjela opterećenja procesora izgleda ovako:

  • 2 jezgre – za korisnike OS-a i terminala;
  • 1 jezgra - za poslužitelj aplikacija 1C;
  • 1 jezgra – za SQL bazu podataka.

Strojevi se mogu nositi s ovim zadatkom početna razina s jednim četverojezgrenim procesorom. To mogu biti rack ili tower poslužitelji. Posljednja opcija je poželjnija jer ne zahtijeva izdvajanje zasebne sobe za serversku sobu.

Srednja organizacija (do 40 zaposlenih). S takvim brojem korisnika, programeri 1C preporučuju korištenje terminalskog načina za pristup aplikaciji. Veličina baze podataka može biti do 4 GB. Za takvo opterećenje potrebna su vam najmanje dva procesora s 4–6 jezgri. Optimalna količina RAM-a bit će 16–64 GB, budući da svakom korisniku mora biti dodijeljeno najmanje 700 MB. Vjeruje se da 1C aplikacijsko rješenje u kojem radi klijentski stroj zahtijeva od 240 do 480 MB, a još 200–220 MB dodijeljeno je za uredske aplikacije.

Uz toliki broj procesa preporuča se koristiti jedan stroj srednje razine s virtualizacijom ili dva fizička poslužitelja. Jedan od njih će se koristiti za pristup terminalu, a drugi za SQL. Najbolje je implementirati aplikacijski poslužitelj 1C na prvom stroju ili čak dodijeliti zaseban jednoprocesorski sustav za to. Potrebna konfiguracija odabire se u svakom konkretnom slučaju na temelju analize procesorskog vremena.

Velika organizacija (više od 40 zaposlenih). Osnovna konfiguracija opreme u ovom slučaju sastojat će se od tri fizička poslužitelja:

  • terminal,
  • DBMS,
  • "1C".

Volumen baze podataka s takvim brojem zaposlenika često prelazi 4 GB i manje predmemorija sustava Preporuča se dodijeliti barem toliko RAM-a. Koristit će se još 4 GB operacijski sustav, a 1C aplikacije će zahtijevati oko 8 GB. Dakle, potrebno vam je najmanje 16 GB RAM-a.

Za takve zadatke odabrani su dvoprocesorski poslužitelji s podrškom za Intel Xeon E5-2600 ili noviji. Ako broj zaposlenih nije veći od 50 ljudi, može se ostaviti samo jedno računalo za terminalski pristup i 1C aplikacije. Međutim, s obzirom na izglede za rast tvrtke, bolje je osigurati zaseban poslužitelj za svaki zadatak. Ako se broj uključenog osoblja približi 100 zaposlenika, morate postaviti klaster od dva stroja za 1C, a jedan ostaviti za druge zadatke.

Odabir diskovnog podsustava

Performanse poslužitelja izravno ovise o podsustavu diska. Prilikom pokretanja 1C aplikacija, operacije čitanja i pisanja podataka izvode se s visokim intenzitetom. Većina pritužbi na rad poslužitelja odnosi se na blokiranje tablica kada im istovremeno pristupa veliki broj korisnika.

Zadatak odabira poslužitelja za 1C uključuje nadzor diskovnog podsustava, omogućujući vam da pronađete optimalnu ravnotežu performansi i pouzdanosti. Izuzetno važan čimbenik koji utječe na performanse je njegova sposobnost da izvrši određeni broj operacija čitanja/pisanja u sekundi (IOPS). Ako je baza podataka do 300 MB, a broj korisnika 1C je do 6 ljudi, ovaj parametar je 400–600. Ako broj korisnika poslužitelja dosegne 100 ljudi, tada će IOPS biti 18 000. Brzina prijenosa strujanja igra sekundarnu ulogu.

Za svakoga upišite teško brzine čitanja/pisanja diska postavljene su na:

  • SATA – 100/80;
  • SAS – 240/220;
  • SSD – 35 000/8 600.

Ovo pokazuje da su 1C poslužitelji baze podataka najprikladniji solid state diskovi. Glavni čimbenik koji ograničava njihovu upotrebu je njihova visoka cijena. Stoga se za smanjenje proračuna koriste i SAS diskovi. Za pohranu kritičnih podataka, uključujući 1C, tvrdih diskova kombinirani u RAID nizove različite razine, a inherentnu redundanciju treba uključiti u izračune performansi poslužitelja.

Prilikom dizajniranja rješenja, otpornost na pogreške sustava igra važnu ulogu. U tu svrhu, i hardver i softver. Poslužitelji su opremljeni izvorima napajanja koji se mogu mijenjati bez prekida rada i kavezima za diskove, a za neprekidno napajanje koriste UPS. Sigurnost podataka osigurana je sigurnosnom kopijom. Datoteka dnevnika se stvara najmanje jednom dnevno kako bi se osigurao oporavak podataka u slučaju kvara sustava.

Možete pronaći traženi poslužitelj i konfigurirati ga za 1C na web mjestu. Naši stručnjaci pomoći će u rješavanju ovog problema. Za savjet kontaktirajte ih telefonom ili kontaktirajte upravitelja putem chata.

Pošaljite rješenje pitanja Odgovaramo radnim danom
Za sat vremena

Kako odabrati poslužitelj za rad s 1C

Razmotrimo nekoliko osnovnih primjera osnovnih konfiguracija poslužitelja za 1C, vođeni dvama glavnim kriterijima - brojem korisnika i načinom implementacije samog programa: 1C na temelju datoteka ili 1C: aplikacijski poslužitelj + SQL.

Rezervirajmo odmah - ova podjela je vrlo proizvoljna, jer nije veliki broj korisnici, koji imaju veliku bazu podataka, značajno će opteretiti i procesor i diskovni podsustav. Ali u isto vrijeme, relativno velik broj korisnika može koristiti prilično ograničen skup funkcionalnosti i raditi s malom bazom podataka, pa čak i ne raditi istovremeno. Oni. prilikom odabira poslužitelja trebate se posavjetovati sa stručnjakom i pokušati mu prenijeti "cijelu istinu" o svom radu.

    Mala tvrtka (2-10 korisnika), baza podataka do 1 Gb, 1C Enterprise - način rada datoteka, ovo nije ništa više od klasične implementacije poslužitelj datoteka.

    Kao osnovni procesor možete odabrati jedan od mlađih Intel Xeon modela E3-12XX serije.

    Izračun RAM-a je jednostavan: ne ulazeći u detalje o specifičnostima rada sustava i predmemorije datoteka, jednostavno ćemo ga označiti kao približno 2 Gb za OS i istu količinu za rad s datotečnim sustavom.

    Ne razmatramo slučajeve "pseudo-poslužitelja", tj. kada pokušavaju "prilagoditi" radnu stanicu pristojne konfiguracije poslužitelju za 1C, čak i za 2-3 korisnika. Unatoč činjenici da mnogi "sysadmini" imaju "bogato" iskustvo u korištenju običnih računala kao poslužitelja, ne raspravljamo o takvim opcijama i ne preporučujemo takav izbor.

    Ne mogu čak ni podići ruku da instaliram samo 4 Gb RAM-a na Intel Xeon - serversku seriju procesora. Ipak, preporučamo 8Gb (ovdje funkcionira princip više, a ne manje).

    Disk sustav. Moderni diskovi, čak i oni serverske razine koji implementiraju SATA sučelje za prijenos podataka, razlikuju se vrlo malo u cijeni ovisno o veličini diska. Stoga se “hvatanje buha” pokušajem smanjenja cijene poslužitelja zbog razlike u cijeni diskova od 500 Gb i 1 Tb ne isplati. Osim toga, linija 500 GB SATA diskova svih proizvođača već nestaje iz njihove ponude. S druge strane, nitko nije otkazao dobro poznati postulat - brzinu punjenja prostor na disku izravno proporcionalna svom volumenu. Oni. Što je disk veći, to je više informacija pohranjeno na njemu, čak i ako to u početku nije bilo potrebno. Inzistiramo na tome da moraju postojati najmanje 2 diska kako bismo mogli organizirati tzv. softversko “zrcalo” - minimalna zaštita podataka u slučaju kvara jednog od diskova.

    Dakle, dobivamo osnovnu konfiguraciju 1C poslužitelja datoteka za korištenje do 10 korisnika:

  1. Ako ima 15-20 korisnika, tada veličina baze podataka može doseći 4 GB. U pravilu, u ovom slučaju koriste verziju 1C: Enterprise 8.3 Application Server ili SQL verziju 1C.

    Stoga zahtjevi za RAM: isti 2 GB za OS, do 4 GB za 1C: aplikacijski poslužitelj i isti iznos za MS SQL Server. Najbolja opcija, kada je baza podataka potpuno predmemorirana u RAM-u. Dobivamo potrebnu minimalnu veličinu RAM-a - 10 GB. U praksi često postoje situacije kada verzija 1C: Application Server gubi odgovor. To se događa kada nema dovoljno RAM-a, kada je OS prisiljen zamijeniti 1C na disk. Kako se to ne bi dogodilo, uvijek preporučujemo zalihu RAM-a - ukupno 16 GB.

    Što se tiče procesora, opet, četverojezgreni procesor Intel Xeon E3 12XX serije će se sasvim dobro snaći, samo ćemo izabrati višu frekvenciju takta. Štoviše, ovisnost radne brzine 1C o frekvenciji takta u verziji 1C-8.3 kompenzira se određenom efektivnom frekvencijom - brojem jezgri procesora pomnoženim s frekvencijom takta jezgre.

    Podsustav diska postaje malo kompliciraniji. Opet, ne ulazeći u detalje rada diskova s ​​operacijama čitanja i pisanja (tzv. IOPS), napominjemo da će se prosječna brzina rada u istom “zrcalu” približno udvostručiti ako broj diskova u zrcalu povećamo na četiri (tzv. RAID 10).

    Ukratko, dobivamo osnovnu konfiguraciju poslužitelja za 15-20 korisnika u sustavu 1C: Application Server 8.3:

    • CPU - Intel Xeon E3 1240V3 3,4 GHz,
    • RAM - 16GB,
    • Diskovni podsustav - ogledalo od 4 diska 4x1TB.

  2. Za poboljšanje performansi i pouzdanosti sustava u cjelini, kada je broj korisnika 1C:Enterprise veći od 30, u pravilu se koristi terminalno rješenje. Suština ovog rješenja je da se korisničke aplikacije (u ovom slučaju 1C) pokreću i rade na samom terminalskom poslužitelju, a korisnik vidi samo grafičku sliku koju poslužitelj šalje na njegovo računalo (terminal). Osim visokih performansi i skalabilnosti, imamo dodatnu pouzdanost i zaštitu Vaših podataka koja je određena konfiguracijom terminalskog poslužitelja.

    Ovdje se u pravilu već koriste diskovni nizovi višeg stupnja zaštite (RAID 6, 60, kombinacije RAID nizova implementirane na hardverski, najčešće namjenski RAID kontroler).

    Izbor procesora za takve poslužitelje određuje se jednostavnim izračunima - obično se najmanje jedna fizička jezgra dodjeljuje SQL-u, barem jedna jezgra za 1C: Application Server, 2 za OS. Preostale jezgre dodjeljuju se korisnicima.

    Poznato je da jedna jezgra procesora može učinkovito nositi s više od 8 korisnika. Iz navedenih kriterija nije teško razumjeti da za učinkovit rad više od 30 korisnika, morate se odlučiti za 2-procesorske poslužitelje - barem u pogledu ukupnog broja jezgri.

    Tipična konfiguracija terminalskog poslužitelja + 1C:Aplikacijskog poslužitelja prikazana je u nastavku:

    • Procesor: 2 x 4C/4T CPU | Intel Xeon E5-2609 V2,
    • Memorijski moduli: 4 x DDR3-ER 8Gb,
    • Pohrana: 4 x HDD 1Tb, 4 x HDD 1Tb,
    • Upravljač: RAID.

  3. Za više od 50 korisnika obično su odvojene uloge terminalskog poslužitelja (aplikacijskog poslužitelja) i poslužitelja baze podataka.

Prije otprilike dvije godine objavili smo materijal o poslužitelju 1C Enterprise na Linux platformi, interes za ovu temu je još uvijek velik. U isto vrijeme, puno se toga promijenilo, 1C platforma ne stoji mirno, a implementacija najčešće nadilazi jednostavno ponavljanje uputa. To ne čudi, 1C Enterprise poslužitelj je složen proizvod, pa smo odlučili započeti ovu seriju članaka s ciljem dubljeg proučavanja teme.

Prije nego što uzmete miš i odete u sobu s poslužiteljem, trebali biste jasno razumjeti potrebno minimalno znanje, naime, imati ideju o strukturi 1C Enterprise poslužitelja i namjeni njegovih pojedinačnih komponenti. Većina problema tijekom implementacije nastaje zbog činjenice da se 1C Enterprise poslužitelj doživljava kao neka vrsta monolitne formacije u kojoj su sve komponente međusobno povezane na lukav način poznat samo jednom programeru. Međutim, to nije tako, a danas ćemo shvatiti od čega se sastoji naš server i kako to sve zajedno funkcionira.

Želio bih još jednom naglasiti iznimnu važnost onoga o čemu će biti riječi u nastavku. Bez tog znanja bit će teško postići stabilan rad, a da ne govorimo o dijagnosticiranju uskih grla i povećanju produktivnosti. Rezultat može biti klasična slika: hardver se čini moćnim, sve je napravljeno prema uputama, ali usporava. Nažalost, većina uputa za početnike (uključujući i naše) sadrži samo informacije o tome kako to učiniti, bez fokusa na to što se točno radi i zašto. Pa počnimo popravljati stvari.

Verzija klijent-poslužitelj 1C Enterprise je struktura od tri razine (tzv. "tri razine"), koja uključuje: klijenta, 1C Enterprise poslužitelja i DBMS poslužitelja. To su potpuno neovisne komponente koje se mogu kombinirati u bilo koju valjanu kombinaciju kako bi se postigle najbolji rezultat. Razmotrite sljedeći dijagram:

Krenimo od klijenata, trenutna verzija platforme (8.2) omogućuje korištenje tri vrste klijenata. Pogledajmo ih detaljnije.

Debeli klijent

Ovo je klasična 1C klijentska aplikacija; prije izlaska platforme 8.2 to je bila jedina dostupna vrsta klijenta. Shema rada debelog klijenta je sljedeća: klijentska aplikacija traži podatke od 1C poslužitelja, zatim ih zauzvrat traži od baze podataka i prosljeđuje ih nazad klijentu, gdje se obrađuju. Kao što vidite, ova shema nije optimalna: 1C poslužitelj je u biti samo sloj između klijenta i baze podataka, svi izračuni se odvijaju na klijentu. To nameće povećane zahtjeve za klijentska računala, jer Računalna snaga poslužitelja se ne koristi. Vrijedno je jasno razumjeti da u načinu rada debelog klijenta nećete dobiti povećanje performansi od prebacivanja na verziju klijent-poslužitelj, možda čak i obrnuto.

Tanak klijent

Može se nazvati glavnom vrstom klijentske aplikacije za platformu 8.2; u teoriji, u praksi, nije sve tako glatko i vratit ćemo se na to. Način rada je radikalno drugačiji: klijent traži podatke od 1C poslužitelja, koji ih prima iz baze podataka, obrađuje i vraća rezultat izračuna klijentu. Glavno računalno opterećenje pada na poslužitelj, tako da nema posebnih zahtjeva za klijentska računala i kanal od klijenta do poslužitelja.

Također, tanki klijent može raditi koristeći ili TCP/IP protokol ili lokalna mreža, i putem HTTP-a preko interneta. Za to je potreban još jedan posrednik - web poslužitelj, koji šalje klijentske zahtjeve na 1C poslužitelj; na web poslužitelju se ne vrši obrada podataka, on se koristi isključivo kao transport. Prednosti tankog klijenta su jasne; ako imate moćan poslužitelj, to vam omogućuje značajno ubrzanje rada s programom; mrežni promet također je značajno smanjen, što je vrlo važno za uredske mreže.

Web klijent

Njegovo postojanje logično proizlazi iz nekih svojstava tankog klijenta; doista, ako sve zahtjeve obrađuje poslužitelj, HTTP se koristi kao prijenos, zašto onda ne koristiti preglednik za rad? Način na koji web klijent funkcionira ne razlikuje se od tankog klijenta, međutim, danas nisu sve funkcije koje podržava tanki klijent implementirane i ne rade ispravno u web klijentu. Djelomično se to može ispraviti u konfiguraciji; dijelom mehanizam za prikaz informacija u pregledniku nameće ograničenja. Međutim, 1C ima web klijent i radi i nitko te ne smeta (opet u teoriji) da radiš u programu dok ležiš na plaži s tabletom.

Sada o muhi u masti. Za normalna operacija u načinu tankog i web klijenta, konfiguracija mora raditi u načinu upravljane aplikacije i podržavati sve funkcije u ovaj način rada. Način upravljane aplikacije glavni je za platformu 8.2 i prilično se radikalno razlikuje od onoga što je bilo prije, uključujući i izgled. Vizualno vođena aplikacija može se prepoznati po novom sučelju koje sadrži kartice i hiperveze:

U najmanju ruku, neobično je, posebno u usporedbi s klasičnim sučeljem, ali nemojte se žuriti radovati kada vidite novo sučelje, osim izgled, konfiguracija mora podržavati izvođenje svih svojih funkcija na poslužitelju; moglo bi se ispostaviti da neće sve značajke biti dostupne u tankom i web klijentskom načinu rada.

Danas samo dio tipičnih konfiguracija radi u modu upravljane aplikacije, kao što su: Small Firm Management, Trade Management 11, Retail 2 i Salary and HR Management. Ova rješenja mogu u potpunosti iskoristiti prednosti nove platforme. Enterprise Accounting 2.0 ne koristi način upravljane aplikacije i neće raditi u tankim i web klijentima, isto vrijedi i za mnoga rješenja trećih strana, kao što je “Kamin” itd.

zaključke

Ako je moguće, trebali biste koristiti tanki klijent, jer vam to omogućuje da prebacite sve izračune na stranu poslužitelja i udobno radite čak i na sporim kanalima, uklj. putem Interneta. Treba imati na umu da je rad u konfiguracijskom načinu rada moguć samo putem debelog klijenta, koji će se također morati koristiti za rad s konfiguracijama koje još nisu prebačene u upravljani aplikacijski način rada.

Web klijent treba koristiti kada nije moguće koristiti tanki, npr. s tuđeg računala na poslovnom putu, ali treba biti spreman na odsutnost ili neispravan rad neke funkcije.

1C klaster poslužitelja

Nakon što smo se pozabavili klijentima, prijeđimo na poslužitelje. Sustav omogućuje korištenje tri vrste poslužitelja: 1C poslužitelj, DBMS poslužitelj i web poslužitelj. Važno je razumjeti da su podaci poslužitelja potpuno neovisni jedni o drugima, što sustavu daje fleksibilnost i omogućuje racionalno korištenje računalnih resursa.

Također, sustav ne nameće nikakve zahtjeve platformama. Možete dijeliti i Windows i Linux poslužitelji, Apache i IIS mogu se koristiti kao web poslužitelj; PostgreSQL, MS SQL Server, IBM DB2 i Oracle podržani su iz DBMS-a. Stoga vas nitko ne sprječava da stvorite shemu u kojoj će 1C poslužitelj koji radi na Linux platformi raditi zajedno s poslužiteljem baze podataka koji radi Windows kontrola Server i IIS i obrnuto. Osim toga, možete koristiti nekoliko DBMS poslužitelja (kao i web poslužitelja) postavljanjem različitih baza podataka na različite poslužitelje.

Ovakav pristup omogućuje fleksibilno kombiniranje, proširenje i promjenu postojeće konfiguracije ovisno o trenutnim potrebama, a sve će biti maksimalno transparentno za krajnjeg korisnika. Na primjer, možete premjestiti resursno intenzivnu informacijsku sigurnost na zasebni DBMS poslužitelj promjenom samo parametara veze s bazom podataka u postavkama poslužitelja bez utjecaja na postavke klijenta.

I na kraju ono najzanimljivije: klaster 1C Enterprise poslužitelja. Da, tako je, ne jedan poslužitelj, već skupina poslužitelja. Obično tu počinje zbrka, pogotovo ako postoji samo jedan poslužitelj. Međutim, sve pada na svoje mjesto ako uzmemo u obzir da je koncept klastera poslužitelja prvenstveno logičan, ali ovaj pristup vam lako omogućuje skaliranje sheme, povećavajući njegovu izvedbu ili toleranciju na pogreške.

Bilo koji klaster sastoji se od središnjeg poslužitelja 1C Enterprise i radnih poslužitelja. U najjednostavnijoj konfiguraciji, to će biti isti fizički poslužitelj. Međutim, ako je potrebno, možemo dodati dodatne radne poslužitelje čije će opterećenje izbalansirati centralni poslužitelj. To vam omogućuje brzo i transparentno povećanje računalne snage sustava i povećanje tolerancije na pogreške. Klaster također ne nameće zahtjeve za homogenošću platforme; može uključivati ​​poslužitelje koji rade na Windowsima i Linuxu.

Koji se zaključci mogu izvući iz gore navedenog? Prvo, sustav klijent-poslužitelj 1C Enterprise vrlo je fleksibilan i omogućuje vam optimalno korištenje dostupnih računalnih resursa za postizanje optimalnog rezultata. Koju konfiguraciju odabrati ovisi o specifičnim zadacima i sredstvima dodijeljenim za njihovo rješavanje.

Na primjer, ako imate malo opterećenja i koristite debeli klijent i konfiguraciju koja ne podržava način rada upravljane aplikacije, ima smisla kombinirati klaster 1C poslužitelja i DBMS poslužitelj na jednom fizički poslužitelj, jer je vrlo rasipno dodijeliti poseban stroj za sloj između klijenta i baze podataka.

Nasuprot tome, kada koristite upravljanu aplikaciju u načinu tankog klijenta, bolje je razdvojiti DBMS poslužitelj i klaster poslužitelja u različite poslužitelje, od kojih će svaki biti optimiziran za svoj zadatak.