Koti / Turvallisuus / Mikä palvelin 1:lle 83. C: Kirjanpito erillisellä palvelimella

Mikä palvelin 1:lle 83. C: Kirjanpito erillisellä palvelimella

Tähän mennessä 1C-rahoitustuote on kasvanut kirjanpitosovelluksesta kirjanpitosovelluksesta laajamuotoiseksi kokonaisuudeksi kirjanpitoon ja lähes kaikentyyppisten yritysten tukemiseen, väittäen kilpailevansa maailman "hirviöiden" SAP R / 3:n ja Microsoft Dynamics AX:n (Axapta) kanssa. ).

Venäläiset yritykset järjestävät liiketoimintaprosessinsa yhä useammin nykyaikaisilla kokoonpanoilla 1C 8.3 "Kaupan hallinta", "Tuottamisen hallinta", "ERP Enterprise Management" ja vastaavat. Kirjanpito-, markkinointi-, tuotanto-, myyntiosastot siirretään 1C:hen, integraatio IP-puhelimen ja dokumenttien hallintajärjestelmiin suoritetaan. Kuitenkin heti "töitä tehdään 1C:ssä" -aikeiden jälkeen herää kysymyksiä - millä resursseilla 1C:n keskuskanta toimii, mikä laitteisto näyttää parhaan tuloksen kohtuullisella budjetilla? Julkisen sektorin jättiläisille on tässä tilanteessa helpompaa - lukuisille päätoimisille IT-integraattoreille ja -arkkitehdeille annettiin selkeä käsky, käynnistettiin ison budjetin tarjouskilpailut pakollisella ehdolla avaimet käteen -konseptin toimittamisesta ja alan jatkotuesta. sertifioitujen asiantuntijoiden toimesta. Mutta entä yritykset, jotka haluavat ostaa ja asentaa jonkin 1C: Enterprise -tuotteista itse ja käyttävät budjettinsa viisaasti?

Perusvirhe, jos et ota huomioon piraattisten tai vahvistamattomien ohjelmistojen käyttöä, on laitteiston säästäminen 1C:lle. Nämä trendit ovat erityisen yleisiä startupeissa ja pienissä yrityksissä. On olemassa mielipide, että ei ole tarpeen ostaa kalliita palvelinlaitteita Intel Xeon -prosessoreilla, ei ole tarpeen laskea etukäteen RAM-muistin määrää, prosessorin ja levyalijärjestelmän kuormitusta, jotta ei tarvitse luoda redundantteja levytaulukot (Raid), käytä ammattimaisia ​​levyohjaimia välimuistilla ja niin edelleen. Virheet 1C:n IT-arkkitehtuurin laskelmissa johtavat surullisiin seurauksiin, joista yritys oppii jo liiketoimintaprosessien pysäyttämisen yhteydessä. Siksi on erittäin tärkeää kiinnittää huomiota jokaiseen palvelinalustan laitteistosolmuun 1C:lle.

Esimerkkejä tyypillisistä ongelmista, jotka johtuvat 1C:n IT-arkkitehtuurin virheellisestä rakentamisesta:
  • Perus- ja 1C-liitäntöjen "jarrutus" avainresurssien (yleensä RAM- tai levyalijärjestelmän) ylikuormituksen vuoksi.
  • 1C-ohjelman virheet ja "kaatumiset", jotka johtuvat väärin valitun laitteiston epävakaudesta.
  • Yrityksen seisokki keskuksen viasta johtuen laitteisto.
  • 1C-tietojen osittainen tai täydellinen menetys satunnaisten laitteisto- tai ohjelmistovikojen vuoksi.

Palvelimen laitteistoresurssit 1C

Tarkastellaanpa alla tärkeimpiä laitteistoresursseja, joiden valinnassa tehty virhe voi pilata koko yrityksen automaatioprojektin, kun luot palvelimen 1C:n alle itse.

Keskusyksikkö (CPU)

Fyysisten prosessoriytimien määrä. Ikuisten kiistojen aihe 1C-foorumeilla on tärkeämpää kuin suorittimen taajuus tai moniytiminen. Näiden ristiriitojen juuret ulottuvat menneisyyteen, 1C 8.0:aan tai jopa 1C 7.7:ään. Itse asiassa 1C:n suoritettavat prosessit ovat enemmän varhaiset versiot olivat puhtaasti yksiytimiä, ts. riippumatta siitä kuinka monta ydintä keskusprosessori tarjoaa - yrityspalvelinpalvelu 1C 8.0 tai "paksu asiakas 1C 7.7" käytti aina vain yhden "nolla" ytimen käyttöjärjestelmä. Nykyään kuva on muuttunut - käyttöjärjestelmä jakaa rohkeasti yhden 1C: Enterprise (rphost) -prosessin tehtävät useiden CPU-ytimien kesken (katso kuva 1).




Kuva 1 - CPU-kuormitus 1C-palvelinprosessien toiminnan aikana.


Mutta tämä ei tarkoita ollenkaan sitä, että jos ostat prosessorin, jossa on enimmäismäärä ytimiä, 1C-palvelin, joka on yhdistetty DBMS:ään (useimmiten DBMS tarkoittaa MS SQL:ää), näyttää fantastisen suorituskyvyn ja tilikausien uudelleenkirjoittaminen 1C-ohjelmassa muutaman minuutin kysymys. On tarpeen ymmärtää ero yksittäisen toiminnon suorittamisen nopeuden ja suuren tietomäärän samanaikaisen käsittelyn välillä. Fyysisten ytimien lukumäärä antaa sinun vain ratkaista 1C:n yrityspalvelimen ja DBMS:n monien eri tehtävien samanaikaisen työn vakauden ja suorituskyvyn. Tästä päätelmä - mitä enemmän 1C-käyttäjiä on, sitä enemmän oikea määrä ytimiä vaikuttaa näiden samojen käyttäjien mukavaan samanaikaiseen käyttöön. Käyttäjien lukumäärän riippuvuus 1C-palvelimen ytimien lukumäärästä on esitetty taulukossa 1.


Samanaikaisten käyttäjien määrä 1C:Enterprise-palvelimella Prosessorin tyyppi ja malli Käytettyjen ytimien lukumäärä
Jopa 10 käyttäjää Mukautettu Intel Core alkaen 3,1 GHz Enintään 2-4
Jopa 20 käyttäjää Palvelin Intel Xeon alkaen 2,4 GHz 4-6
Jopa 30 käyttäjää Palvelin Intel Xeon alkaen 2,6 GHz 6-8 ydintä
Jopa 50 käyttäjää Palvelin Intel Xeon alkaen 2,4 Ghz - 2 kpl Alkaen 4 prosessoria kohden

Taulukko 1 - 1C-palvelimen käyttäjien määrän suhde ja suositeltu prosessoriytimien lukumäärä.


CPU-taajuus. Toisin kuin ytimien lukumäärä - keskusprosessorin taajuus vaikuttaa juuri yhden tehtävän käsittelyn nopeuteen kerralla, mikä on suosituin kriteeri 1C-loppukäyttäjille. Prosessorin taajuus on täsmälleen se parametri, jonka kasvaessa yksittäiselle käyttäjälle 1C-palvelimen ja DBMS:n pyyntöjen käsittelynopeus kasvaa ja aika, jonka aikana järjestelmä toimittaa lopullisen tuloksen loppukäyttäjälle vähenee. Tämän tueksi tunnettu asiantuntija Gilev teki yhdessä käytännön testeihin perustuvassa artikkelissaan yksiselitteisen johtopäätöksen - "1C:n nopeuteen vaikuttaa paljon enemmän keskusprosessorin taajuus kuin sen muihin parametreihin, olipa se sitten on 1C end -asiakas tai 1C: Enterprise -palvelin". Tämä on 1C-ohjelman arkkitehtuuri.

Välimuisti, virtualisointi ja hyperketjutus. Aiemmin, kun moniytimiset prosessorit eivät vielä olleet niin yleisiä, Intel keksi erikoistekniikka keskusprosessori, joka simuloi moniytimistä, ns. "hyper-threading". Kun se on otettu käyttöön, käyttöjärjestelmä määrittelee yhden fyysisen prosessorin (yksi fyysinen ydin) kahdeksi erilliseksi prosessoriksi (kaksi loogista ydintä). Suosittelemme 1C-palvelimen "hyperthreading" -toiminnon poistamista käytöstä. Tämä tekniikka ei tuota 1C:n kiihtyvyyttä.

Käyttämällä virtuaalikoneita 1C:Enterprise-palvelimen ja DBMS:n osalta on otettava huomioon, että virtuaalikoneiden ytimet ovat "heikompia" kuin todelliset fyysiset ytimet, vaikka niitä kutsutaan samoin - "ytimeksi". Tarkkoja virallisia kertoimia ei ole, mutta Microsoftin teknisten portaalien artikkelit suosittelevat laskemaan 4-6 prosessoriydintä virtuaalikoneen fyysistä ydintä kohden.

Välimuisti on muistilappu, jota prosessori käyttää lyhentääkseen tietokoneen muistiin kuluvaa keskimääräistä käyttöaikaa. Itse asiassa se on olennainen osa prosessoria, koska se sijaitsee samassa sirussa sen kanssa ja on osa toiminnallisia lohkoja. Kaikki on hyvin selvää täällä - mitä suurempi välimuisti, sitä suurempia "tietoja" prosessori voi käsitellä. Tyypillisesti välimuistin koko riippuu prosessorimalleista - mitä kalliimpi malli, sitä enemmän siinä on yleensä välimuistia. Emme kuitenkaan usko, että prosessorin välimuistin koko vaikuttaa merkittävästi 1C-palvelimen ja DBMS:n suorituskykyyn. Pikemminkin se kuuluu "hienosäädön" alaan.

Prosessorin tyyppi. Kaikki tietävät, että laitteisto on jaettu palvelimeen ja käyttäjään. Onko joissain tapauksissa mahdollista käyttää edullista mukautettua CPU:ta vaihtoehtona ammattimaiselle mutta kalliille palvelinprosessorille? Osoittautuu - se on mahdollista. Harkitse taulukkoa, jossa verrataan kahden vaihtoehdon pääparametreja Intelin prosessorit(katso taulukko 2).

Mukautettu Intel® Core™ i7-6700T -suoritin (8M välimuisti, jopa 3,60 GHz) Palvelin Intel® Xeon® Prosessori E5-2680 v2 (25 M välimuisti, 2,80 GHz)
Kätkö 8 Mt 25 Mt
Taajuus järjestelmäväylä 8 GT/s DMI3 8 GT/s QPI
Komentosarja 64-bittinen SSE4.1/4.2, AVX 2.0 64-bittinen AVX 2.0
Ydinten lukumäärä 4 10
CPU:n peruskello 2,8 GHz 2,8 GHz
Max. äänenvoimakkuus ja tyyppi RAM-muisti 64 Gt ei-ECC 768GB ECC
Kustannusarvio 354$ 1 280$

Taulukko 2 - Intelin koti- ja palvelinsuorittimen pääparametrien vertailu.


Kuten näemme, palvelinprosessorilla on paljon korkeammat arvot ytimien lukumäärässä, välimuistin koossa, tuessa enemmän RAM-muistia ja tietysti korkeammalla hinnalla. Palvelimen CPU ei kuitenkaan käytännössä eroa käyttäjän CPU:sta tiettyjen prosessoriohjeiden (käskyjen) tuen ja kellotaajuuden suhteen. Tästä voimme päätellä, että pienille organisaatioille on melko hyväksyttävää käyttää mukautettua keskusprosessoria 1C: Enterprise -palvelimelle. Ainoa ongelma on, että käyttäjäprosessoria ei voi asentaa palvelinpistorasiaan. emolevy ja tuetaan palvelimen RAM-muistia pariteettitarkistuksella (ECC), ja mukautettujen komponenttien käyttöön liittyy riskejä koko järjestelmän vakaudelle.

Random Access Memory (RAM)

RAM tyyppi. RAM-palkki (RAM) eroaa tarkoitukseltaan - monen käyttäjän palvelinjärjestelmille tai henkilökohtaisille laitteille - PC:ille, kannettaville tietokoneille, nettopeille, ohuille asiakkaille jne. Kuten CPU:n tapauksessa - RAM-moduulien pääparametrit ovat suunnilleen vastaavat - nykyaikainen PC-RAM ei käytännössä jää palvelimen jälkeen yhden palkin tilavuudessa, kellotaajuudessa eikä DDR-moduulien tyypissä. . Palvelimen RAM:n ja "koti" RAM:n väliset erot laitteistoalustan käyttötapauksissa ja tarkoituksessa – tästä myös muodostuu sen korkeampi hinta:

  • Palvelimen RAM-muistissa on ECC (Error Correction Code) -pariteetti - koodaus/dekoodaustekniikka, jonka avulla voit korjata tiedonkäsittelyn virheet suoraan RAM-moduulin avulla.
  • Palvelimen emolevyssä on paljon enemmän paikkoja RAM-moduulien asentamiseen kuin tavallisessa tietokoneessa
  • Palvelimen RAM sisältää rekistereitä (puskureita), jotka puskuroivat tietoja (osittain rekisteröity tai täysin puskuroitu), mikä vähentää muistiohjaimen kuormitusta monilla samanaikaisilla pyynnöillä. Puskuroidut "FB-DIMM-moduulit" eivät ole yhteensopivia puskuroimattomien kanssa.
  • Moduulit rekisterimuisti Voit myös lisätä muistin skaalautuvuutta - rekisterien läsnäolo mahdollistaa useamman moduulin asentamisen yhteen kanavaan.

Voidaan päätellä, että palvelimen RAM-moduulien käyttö mahdollistaa suurten RAM-määrien asentamisen yhteen järjestelmään ja ECC-pariteettihallintatekniikat ja puskurien käyttö mahdollistavat palvelimen käyttöjärjestelmän vakaan ja nopean toiminnan.

RAM-muistin määrä. Yksi avaintekijöistä korkea suorituskyky palvelin 1C ja DBMS ovat riittävä määrä RAM-muistia. Tietenkin todelliset RAM-vaatimukset riippuvat monista tekijöistä - 1C-kokoonpanon tyypistä, 1C: Enterprise -palvelinprosessien määrästä, DBMS-tietokannan koosta ja niin edelleen. On kuitenkin mahdollista johtaa likimääräinen RAM-määrän riippuvuus käyttäjien määrästä (katso taulukko 3).


RAM-muistin tarve palvelimelle 1c ja DBMS Jopa 10 käyttäjää Jopa 20 käyttäjää Jopa 30 käyttäjää Jopa 50 käyttäjää
Palvelin 1c: Yritys 4-6 Gt 6-8 Gt 12-14 Gt 18-24 Gt
MS SQL -palvelin 4-6 Gt 8-10 Gt 16-18GB 24-28 Gt

Taulukko 3 - 1C-palvelimen käyttäjien lukumäärän ja suositellun RAM-muistin arvioitu suhde 1C: Enterprise -palvelimen ja MS SQL -palvelimen prosesseille.


Mitä tulee palvelinprosesseihin 1C: Enterprise (rphost.exe) - nykyaikaiset 1C-alustat eivät salli Manuaalitila ilmoittaa palvelinprosessien lukumäärä 1C. Sen sijaan järjestelmä edellyttää parametrien, kuten numeron, asettamista tietopohjat ja käyttäjien määrä rphost.exe-prosessia kohden, minkä jälkeen se määrittää automaattisesti optimaalisen määrän 1C:Enterprise-palvelinprosesseja. Voit myös määrittää RAM-muistin sujuvan vapauttamisen rphost.exe-prosessilla, jos sen määrä ylittää ennalta määritetyn kynnyksen. Samaan aikaan 1C-palvelin luo uuden rphost.exe-prosessin, joka ottaa vähitellen haltuunsa 1C-tehtävät, jolloin voit purkaa vaaditun 1C-prosessin.

Huomaa myös, että SQL-palvelulle varatun RAM-muistin määrä katsotaan riittäväksi, jos välimuistissa olevien SQL-tietojen osuma on vähintään 90%. Tämä mittari on varsin kätevä, koska Et voi vain katsoa SQL-palvelimen kuluttaman RAM-muistin määrää - SQL:n uusimmat julkaisut ovat kuluttaneet dynaamisesti RAM-muistia - suurin mahdollinen määrä RAM-muistia kaapataan ja vapautetaan, kun muut prosessit pyytävät RAM-muistia.

RAM-taajuus. Lyhyesti sanottuna tämä on läpijuoksu kanavat, joiden kautta tiedot siirretään emolevylle ja sieltä prosessorille. On toivottavaa, että tämä parametri osuu yhteen emolevyn sallitun taajuuden kanssa tai ylittää sen, muuten RAM-siirtokanava on vaarassa tulla pullonkaulaksi. Yhdessä DDR-tyypissä taajuuden lisääminen / vähentäminen ei vaikuta dramaattisesti 1C-palvelimen suorituskykyyn ja liittyy enemmän "hienosäätö" -alueeseen.

RAM-ajoitukset. Tämä on RAM-muistin viive tai latenssi (Latency). Tälle parametrille on tunnusomaista datan viiveaika siirtymisen aikana RAM-sirun eri moduulien välillä. Pienemmät arvot tarkoittavat nopeampaa suorituskykyä. Vaikutus palvelinjärjestelmän yleiseen suorituskykyyn ja varsinkin 1C:Enterprise-palvelimeen ei kuitenkaan ole suuri. Yleensä näihin parametreihin kiinnittävät huomiota vain pelaajat ja ylikellottajat, joille jokainen ylimääräinen suorituspisara on kallein asia.

Levyalijärjestelmä ja kiintolevyt HDD

kiintolevyohjaimet. Päälaite kiintolevyjen liittämiseen ja järjestämiseen laitteistojärjestelmässä on kiintolevyohjain. Sitä on kahta tyyppiä:

1. Sisäänrakennettu - ohjainmoduuli on sisäänrakennettu järjestelmään, kiintolevykehikko on kytketty suoraan emolevyyn. Sitä pidetään edullisempana ratkaisuna.

2. Ulkoinen - on erillinen painettu piirilevy(laite), joka liitetään emolevyn liittimeen. Sitä pidetään ammattimaisempana ratkaisuna, koska siinä on erilliset sirut kovalla toimintojen suorittamiseen ja ohjaamiseen kiintolevyt. Suositellaan tärkeille palvelinjärjestelmille, kuten 1C:Enterprise-palvelin ja DBMS.

On myös kolmas tyyppi - laite lohkodatan vastaanottamiseen / lähettämiseen iSCSI-, FiberChanel-, InfiniBand-, SAS-kanavien kautta. Tässä versiossa levyalijärjestelmä on kuitenkin "poistettu". erillinen laite datamuisti (SHD), yhdistetty palvelimeen optisella tai kuparikaapelilla. Artikkelissamme analysoimme 1C:n erillisen palvelimen vaatimuksia, joten emme harkitse tätä tyyppiä.

RAID-taulukoiden tyypit ja tasot. Se on tiedon virtualisointitekniikka, joka yhdistää useita asemia loogiseksi yksiköksi redundanssia ja suorituskykyä varten. Harkitse suosituimpia RAID-määritystasoja:

  • RAID 0 ("Striping") Sillä ei ole redundanssia, ja se jakaa tiedot kerralla kaikille taulukkoon kuuluville levyille pienten lohkojen ("raitojen") muodossa. Tämä parantaa huomattavasti suorituskykyä, mutta kärsii luotettavuudesta. Emme suosittele tämän taulukon käyttöä suorituskyvyn paranemisesta huolimatta.
  • RAID 1 ("peilaus", "peili"). Sillä on suojaus puolet käytettävissä olevista laitteistoista (yleensä toinen kahdesta kiintolevystä) vikoja vastaan, se tarjoaa hyväksyttävän kirjoitusnopeuden ja lukunopeuden lisäyksen kyselyn rinnakkaistamisen ansiosta. Tämän tyyppinen taulukko "vetää" melkoisesti 1C + DBMS -palvelimen jopa 25-30 käyttäjälle, varsinkin jos käytetään SAS 15K- tai SSD-levyjä.
  • RAID 10. Peilatut levyparit asettuvat "ketjuun", joten tuloksena olevan taltion tilavuus voi ylittää yhden levyn kapasiteetin. kovalevy. Mielestämme menestynein levyryhmän tyyppi, koska Siinä yhdistyvät RAID1:n luotettavuus ja RAID 0:n nopeus. Yhdessä SAS 15K- tai SSD-asemien kanssa sitä voidaan käyttää 40-50 käyttäjän 1C-palvelimille.
  • RAID 5. Tunnettu taloudestaan. Uhraamalla redundanssin vuoksi vain yhden levyn kapasiteetista ryhmästä, saamme suojan minkä tahansa järjestelmän kiintolevyn vikoja vastaan. (sen muunnelma RAID 6 vaatii kaksi ylimääräistä Kovalevyt tarkistussummien huomioon ottamiseksi, mutta säilyttää tiedot, vaikka kaksi levyä epäonnistuisi). Tämäntyyppinen taulukko on taloudellinen, luotettava ja sillä on melko konkreettinen "luku" nopeus. Valitettavasti tämän ryhmän pullonkaula on alhainen kirjoitusnopeus, jonka ansiosta sitä voidaan käyttää mukavasti jopa 15-20 käyttäjän 1C-palvelinkokoonpanoissa. Se on myös optimaalinen soveltuviin tarkoituksiin - tiedostotietojen tallentamiseen, dokumenttien hallinta-arkistoihin jne.

Kiintolevyliitäntöjen tyypit. Kiintolevyt jaetaan yhteystyypin mukaan:

  • HDD Sata Home. Halvin vaihtoehto kiintolevyille, suunniteltu käytettäväksi kotitietokoneissa tai verkkomediakeskuksissa. Tällaisten laitteiden käyttöä 1c-palvelimissa ei suositella käytettäväksi alhaisen vikasietokyvyn ja toiminnan vakauden vuoksi - näiden levyjen komponentteja ei yksinkertaisesti ole suunniteltu toimimaan 24/7 ja epäonnistuvat nopeasti.
  • HDD Sata-palvelin. Tämä nimi viittaa yleensä kiintolevyihin, joissa on Sata-liitäntä ja karan nopeus 7 200 rpm. Etuliite "Palvelin" tarkoittaa, että tällaisten asemien suorituskyky on testattu palvelinjärjestelmissä ja ne on suunniteltu vakaa työ 24/7-tilassa. Yleensä käytetään 1C-palvelimissa suurten tietomäärien tallentamiseen, mikä ei vaadi suurta käsittelynopeutta. Esimerkiksi - 1c arkistotietokannat, kansioiden vaihto, tiedostojen lataaminen toimistoasiakirjat jne.
  • HDD SAS -palvelin. Erot SAS-liitännän (SCSI:n nykyaikainen analogi) ja Sata käyttöliittymä useita. Täällä keskimääräinen vasteaika levyn, ja työskennellä yhteisessä levyhyllyssä, ja työskennellä HDD-ohjaimen korkeammilla tiedonvaihtonopeuksilla - jopa 6 Gb / s (verrattuna Sata 3 Gb / s). Mutta tärkein etu on SAS-levymallien olemassaolo, jonka karan nopeus on 15 000 rpm. Se on tämä suunnitteluominaisuus mahdollistaa SAS-levyjen suorittavan lähes 3 kertaa enemmän IOPS:ää Sata Server HDD:hen verrattuna. Tällaiset SAS-levyt ovat kooltaan pieniä, ja niitä suositellaan käytettäväksi 1c-päätietokantojen kanssa, joissa työtaakka on jatkuvasti korkea.
  • SSD-asemat. Nämä asemat eroavat aikaisemmista ei liitäntärajapinnan, vaan rakenteensa suhteen - ne ovat puolijohdekäyttöisiä eikä niissä ole liikkuvia osia, ts. pohjimmiltaan ne ovat "flash-asemien" analogeja. Tällaisten tekniikoiden avulla SSD-levyt voivat tuottaa "järjettömän" määrän I / O-toimintoja sekunnissa (10 000 operaatiosta yksinkertaisimmissa SSD-malleissa). Tällä edulla on kuitenkin myös haittapuoli - SSD-levyjen korkeampi hinta ja niiden "elinkynnys", joka riippuu SSD-lohkoihin kirjoitusmäärän rajoituksesta. Kuitenkin joka vuosi näistä levyistä tulee edullisempia ja kestävämpiä. Koska SSD-levyjen hinta nousee moninkertaisesti volyymista riippuen, olisi järkevintä käyttää niitä pienissä, mutta superkuormitetuissa 1c-tietokantoissa, jotka vaativat suurta pääsynopeutta, sekä TempDB väliaikaisiin tietokantoihin.

IOPS on I/O-toimintojen määrä sekunnissa. Itse asiassa IOPS on niiden tietolohkojen määrä, jotka voidaan lukea tai kirjoittaa medialle 1 sekunnissa. Eli puhtaimmassa muodossaan - tämä on kiintolevyn tietojenkäsittelyn nopeuden avainparametri, joka vaikuttaa 1C-palvelimen suorituskykyyn. Jos otamme vertailuksi standarditietolohkon 4 kb, voimme karkeasti erottaa seuraavat IOPS-indikaattorit (katso taulukko 4).


HDD IOPS Käyttöliittymä
7200 rpm SATA-asemat ~75-100 IOPS SATA 3Gb/s
10 000 rpm SATA-asemat ~125-150 IOPS SATA 3Gb/s
10 000 rpm SAS-asemat ~140 IOPS SAS
15 000 rpm SAS-asemat ~175-210 IOPS SAS
SSD-asemat Alkaen 8000 IOPS SAS tai SATA

Taulukko 4 - IOPS-ilmaisimet erityyppisissä kiintolevyissä käytettäessä 4 kb:n tietolohkoa.


Tietenkin puhtaassa muodossaan IOPS:stä on vähän hyötyä laskettaessa lopullisia laskelmia ja vaatimuksia 1C-palvelimen levyalijärjestelmälle. Loppujen lopuksi levyalijärjestelmän kokonaissuorituskyky koostuu RAID-ryhmän tyypistä, levytyypeistä ja sen käyttöliittymän nopeuden indikaattoreista, vasteajasta (latenssista), hajasaantiajasta, lukujen ja kirjoitusten prosenttiosuudesta ja monista muista tekijät. Tämä parametri on kuitenkin mielestämme avainindikaattori levyalijärjestelmän nopeudesta, ja palvelinarkkitehtuurin kehittämisvaiheissa se auttaa määrittämään, minkä tyyppiset kiintolevyt yleensä sopivat parhaiten tiettyihin tarpeisiin. (katso RAID-laskin)

harjoitustesti

Mikä on suhde 1C-käyttäjien määrän ja iops-määrän välillä? Tiimimme suoritti käytännön testin (katso taulukko 5) mitatakseen levyalijärjestelmän kuormitusta tietty määrä istunnot 1C. Koska 1C-järjestelmä on ohjelmoitava ympäristö ja jokaisella yrityksellä voi olla omat liiketoimintaprosessinsa 1C:ssä, meidän piti olla sidottu tiettyyn vertailukonfiguraatioon testausta varten. Tässä ominaisuudessa valittiin TsUP 1C:n erikoiskokoonpano, joka on kehitetty testausta ja virheenkorjausta varten. Sen perusteella 1C-ohjelmoijamme lisäsivät joukon kyselyitä, jotka simuloivat tavanomaisen yrityksen normaalia toimintaa kirjanpitokyselyjen, kirjausten, raportoinnin ja operatiivisten asiakirjojen suorittamisen kanssa.


Järjestelmälevy Tietokantalevy
Iterointi Käyttäjät IOPS kirjoittaa IOPS lukenut IOPS kirjoittaa IOPS lukenut
Keskiarvot
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

Taulukko 5 - Levyalijärjestelmän kuormituksen käytännön testin tulokset.


Testitulokset osoittavat, että leijonanosa levyalijärjestelmän kuormituksesta tapahtuu, kun 1C kirjoitetaan DBMS-palvelimen tietokantaan ja käyttöjärjestelmän järjestelmälevylle (joka oletuksena sisältää 1C:Enterprise-tiedostot välimuistipalvelin).

Samalla teimme käytännön mittauksia jo toimiville 1C UPP 8.2 -tietokannoille testijakson aikana - 5 työpäivää. Ne osoittavat, että 1C + DBMS-palvelin kuluttaa keskimäärin kaksi kertaa enemmän ioppeja "kirjoittamiseen" kuin "lukemiseen". Tällainen ero synteettisten testien ja todellisen 1C-palvelimen valvontatilastojen välillä johtuu sekä säännöllisestä tietodatan näytteenotosta tietokannasta työpäivän aikana että tietokannan säännöllisestä lukemisesta varmuuskopioida tai DBMS-kopiointi.

Muut kiintolevyn komponentit, joihin kannattaa kiinnittää huomiota.

  • Fyysinen koko (muototekijä). Tähän mennessä lähes kaikki tunnetut asemat henkilökohtaiset tietokoneet ja palvelimien koko on 3,5 tai 2,5 tuumaa. Huomaa, että 2,5 tuuman asemia ei valmisteta suuria määriä.
  • Random access -aika- aikaa jolle HDD taatusti suorittaa luku-kirjoitustoiminnon tietyllä magneettilevyn alueella. Pääsääntöisesti enemmän korkeita tuloksia on palvelinlevyjä. Tämä riittää tärkeä parametri kun rakennat levyjoukon 1C DBMS -palvelimelle.
  • Karan nopeus- kiintolevyn karan kierrosten määrä minuutissa. Kaikki on yksinkertaista ja selvää täällä - pääsyaika ja kiintolevyn keskimääräinen tiedonsiirtonopeus riippuvat magneettilevyillä varustetun karan pyörimisnopeudesta.
  • Kiintolevyn puskurin koko- Puskuri on väliaikainen muisti, joka on suunniteltu tasoittamaan eroja kiintolevyn luku-/kirjoitusnopeudessa ja tiedonsiirrossa rajapinnan kautta.
  • Luotettavuus- määritellään keskimääräiseksi vikojen väliseksi ajaksi (MTBF). Luotettavuus riippuu pääsääntöisesti suoraan kiintolevyn valmistajasta, hinnasta ja käyttöympäristöstä. Pidämme luotettavuutta tärkeänä kiintolevyparametrina, joka vaikuttaa 1C-palvelimen laatuun.

Oikea valinta: koti- tai palvelinlaitteisto

Laitteistokomponenttien halpeneminen ja "kotitietokoneiden" mahdollisten kapasiteetin aktiivinen kasvu johtavat toiseen kohtalokkaaseen väärinkäsitykseen - pienyritykset käyttävät aktiivisesti työasemia alustana yhteistyölle 1C-tietokantojen kanssa. Samaan aikaan ymmärtämättä, että ydintaajuuden parametrien, muistin määrän ja budjetti-SSD-levyjen käyttömahdollisuuden lisäksi tavallisessa PC:ssä on laitteiston toiminnalle järjestelmällisempiä, syvempiä ja tärkeämpiä vaatimuksia. kaupallinen rakenne (katso taulukko 6).

1C-palvelimen organisointiongelman ratkaisemiseksi tarjoamme 1C-pilvipalvelimien vuokrausta Tier III -luokan palvelinkeskuksissa. Palvelimen vuokrauksen valinnan taloudellinen kannattavuus löytyy artikkelista.


Vaihtoehdot Palvelin Henkilökohtainen tietokone
Riittävä laskentateho V V
Taattu järjestelmän toiminta 24/7-tilassa V X
Keskeisten laitteistokomponenttien luotettavuus ja vakaus V X
Mahdollisuus kaukosäädin virta ja konsoli (IPMI) V X
Laitteistoalustan budjettikustannukset X V

Taulukko 6 - Koti- ja palvelinlaitteistojen vertailu 1C-palvelimen laadukkaan toiminnan edellyttämien kriteerien mukaan.

Vikasietotyö 1C

Tietysti yksi tärkeimmistä vaatimuksista 1C:n palvelinosalle on sen toiminnan vakaus ja kestävyys vikoja vastaan. Microsoft ja 1C itse ovat tehneet paljon ponnisteluja tähän suuntaan luoden teknologioita palveluidensa klusteroimiseksi melko vakavalla tasolla (katso taulukko 7).


SQL-palvelimien vikasietoisuus Perustuu yhden jaetun tietovaraston konseptiin. Sisäänrakennettu SQL Server -klusterointitekniikka yhdistää kaksi SQL-palvelinta yhdeksi klusteriksi yhdellä virtuaalisella IP-osoitteella ja yhdellä tietokannalla. Siten, kun pää-SQL epäonnistuu, kyselyt siirretään automaattisesti varmuuskopioon.
Toinen vaihtoehto on äskettäin ilmestynyt AlwaysOn, tekniikka DBMS-tietokantojen automaattiseen säännölliseen replikointiin ensisijaisen ja vara-SQL-palvelimen välillä. Samanaikaisesti SQL-palvelimen kaksoiskappale sijaitsee fyysisesti eri tallennustilassa, mikä lisää vastustuskykyä riskeille
Vikapalvelupalvelin 1C:Enterprise 1C Enterprise -palvelimet yhdistetään aktiiviseksi-aktiiviseksi ohjelmiston vikasietoklusteriksi, jossa on automaattinen vikasieto ja nykyisten istuntojen tallentaminen.

Taulukko 7 - SQL- ja 1C-palvelimien vikasietoisuus.


Jokaisella tekniikalla on kuitenkin hyvät ja huonot puolensa. Tärkeimpien etujen lisäksi sinun on tiedettävä jotkin 1C- ja SQL-klusteroinnin () ominaisuudet, jotta et päädy palvelun suorituskyvyn heikkenemiseen:

  • SQL-klusterointi käyttää virtuaalista IP-osoitetta. Ja tämä tarkoittaa, että 1C: Enterprise-palvelimen ja MS SQL:n vuorovaikutus tapahtuu aina sen mukaan verkkoliitäntä, vaikka molemmat palvelut olisivat samassa käyttöjärjestelmässä. Mikä vastaavasti hidastaa 1C:n työtä verrattuna 1C:n itsensä suosittelemaan arkkitehtuurin klassiseen versioon - jaetun muistin käyttöön. Periaatteessa tämä este voidaan "ohittaa" esimerkiksi MS SQL Log Shipping -teknologialla. Tässä tapauksessa vaihto SQL-varapalvelimeen ei kuitenkaan ole enää automaattista, eikä tätä vaihtoehtoa voida pitää täysimittaisena klusterina.
  • SQL-klusteri vaatii suuren budjetin. Jos puhumme MS SQL -palvelun klassisesta klusteroinnista, tarvitaan yksi tietokantavarasto, joka on kytketty pää- ja vara-SQL-palvelimiin. Tyypillisesti tämä rooli on kalliilla säilytysjärjestelmillä, mikä lisää budjettia suuruusluokkaa. Jos puhumme uudesta AlwaysOnista, yhtä tietokantatallennustilaa ei tarvita, tekniikka toimii paikalliset asemat ensisijaiset ja varapalvelimet verkon kautta. Mutta tarvitset version SQL Server Enterprisesta, jonka lisenssi maksaa 4 kertaa enemmän kuin tavallisen SQL Server Standardin.
  • Lisenssien määrä. Huolimatta siitä, että toinen SQL-palvelin ei käsittele tietoja ja on varattuna, molemmille palvelimille on ostettava lisenssit - sekä pää- että varapalvelimelle. Erityisen tuskallista budjetin kannalta ovat SQL Server Enterprise -lisenssit hajautetun AlwaysOn High Availability Groups -klusterin toteuttamiseksi.
  • Sinun ei tarvitse käyttää halpoja mukautettuja laitteistoja niin tärkeässä asiassa kuin yrityksen laajuinen kirjanpitojärjestelmä. Hinta sisään Tämä tapaus Se määrää suoraan tällaisen alustan laadun, vakauden ja kestävyyden.
  • Palvelinalustaa valittaessa suosittelemme kiinnittämään huomiota kahden virtalähteen, IPMI-etäkortin ja valmistajan merkkiin. Tietysti jokainen valitsee ratkaisun budjettinsa perusteella, huippumerkit ovat joskus liian kalliita eivätkä täysin sopivia, mutta valmistajasta ei kannata säästää ollenkaan, tämä voi johtaa hallitsemattomaan ylivoimaiseen esteeseen 1C:n kanssa työskennellessä. Käytämme henkilökohtaisesti Supermicro-palvelinalustoja yhdessä Intel-palvelinsuorittimien kanssa.
  • Käytännön vahvistama mielipide on, että 1C:n suorituskyky riippuu enemmän suorittimen korkeammasta taajuudesta kuin tarjottujen ytimien lukumäärästä.
  • Ei tarvitse säästää 1C-palvelimelle ja SQL-palvelulle varatusta RAM-muistista. RAM päällä Tämä hetki on melko halpa resurssi, ja sen puute (jopa 10-15 prosenttia) johtaa 1C-järjestelmän suorituskyvyn voimakkaaseen laskuun, koska hitaampi vaihtojärjestelmä otetaan käyttöön. Lisäksi swap antaa lisäkuormituksen levyalijärjestelmään, mikä pahentaa tilannetta entisestään.
  • EFSOL-yritys tarjoaa kattavat palvelut 1C-palvelimen valintaan, joka sisältää: 1C-palvelimen suunnittelun, hankinnan, konfiguroinnin ja ylläpidon.
  • Vaihtoehto oman 1C-palvelimen luomiselle on vuokrata palvelin 1C:lle. Pilviteknologiat mahdollistavat alhaisilla kuukausikustannuksilla luotettavan, vikasietoisen palvelun mukavaan työskentelyyn 1C:ssä.

Järjestelmän integrointi. Konsultointi

Kun valitset, mitä palvelinta 1C:lle tarvitaan, on muistettava, että kun käyttäjät työskentelevät sen kanssa, suoritetaan monia tietojen luku- ja kirjoitustoimintoja sekunnissa.

Todennäköisesti on heti selvää, miksi pätevä palvelinsuunnittelu 1C:lle on niin tärkeää - jos "laitteisto" valittiin alun perin väärin eikä se vastaa järjestelmän kuormitusta, on olemassa vaara, että tärkeät tiedot toimivat tai jopa toimivat ajoittain. menetetään. Toisaalta luo palvelin alle 1C, osta kaikki laitteistot ja ohjelmisto voi maksaa yritykselle huomattavan summan, joten on suositeltavaa valita laitteet siten, että vältytään tarpeettomilta kustannuksilta.

Palvelimen valinta 1C:lle

Kun asiantuntijoidemme on tehtävä 1C-palvelimen kokoonpanovalinta, he kysyvät ensimmäisenä, kuinka monta käyttäjää työskentelee 1C:n kanssa yrityksessä ja mitä palveluita he aikovat käyttää, mitä he ovat, kuka hallinnoi 1C:tä. palvelimet ja miten. Aloitamme näistä tiedoista luodessasi 1C-palvelinta.

Palvelimen vaatimukset 1C

1C-palvelimen laitteistorakenteessa prosessorin, RAM-muistin, levyalijärjestelmän ja verkkoliitäntöjen ominaisuudet ovat meille tärkeitä.

Niiden on varmistettava seuraavien komponenttien vakaa ja riittävän tuottava toiminta:

  • käyttöjärjestelmä;
  • tietokantapalvelin (useimmiten se on);
  • 1C-palvelinosa (ei kaikissa tapauksissa, koska pieni yritys, jossa on 2-10 käyttäjää, voi työskennellä 1C:n kanssa tiedostotilassa);
  • käyttäjä työskentelee etätyöpöytätilassa;
  • etäkäyttäjien työn kautta laiha asiakas tai verkkoasiakasohjelma.

Prosessorin valinta 1C-palvelimelle

Optimaalinen prosessoriytimien määrä lasketaan yleensä sen perusteella, että sinun on varattava 1-2 ydintä käyttöjärjestelmän toimintaa varten, 1-2 ydintä SQL-tietokannan toimintaa varten, 1 enemmän sovelluspalvelimen toimintaa varten. , ja noin 1 ydin jokaista 8-10 samanaikaista käyttäjäistuntoa kohden (jotta käyttäjät eivät myöhemmin valittaisi 1C-palvelimen hidastumisesta).

Huomaa, että pyyntöjen käsittelyn nopeus ei riipu niinkään ytimien lukumäärästä, vaan prosessorin kellotaajuudesta, ja ytimien määrä vaikuttaa enemmän työn vakauteen suurella käyttäjämäärällä ja samanaikaisilla tehtävillä.

Kuinka paljon muistia 1C-palvelin tarvitsee

Edellä mainittujen lisäksi, jos tarvitset 1C-palvelimen 100 tai useammalle käyttäjälle, suosittelemme vähintään kahden fyysisen 1C-palvelimen klusterin käyttöönottoa.

Ehdotamme tarvittavan RAM-muistin määrän laskemista seuraavien indikaattoreiden perusteella:

  • Käyttöjärjestelmän toimintaan tarvitaan 2 Gt
  • vähintään 2 Gt MS SQL Server -välimuistille, ja on parempi, että tämä arvo on 20-30% tietokannan todellisesta määrästä - tämä varmistaa mukavan käyttökokemuksen.
  • 1 - 4 Gt 1C-sovelluspalvelimelle
  • 100 - 250 Mt vaatii yhden käyttäjäpääteistunnon riippuen 1C-palvelimen toimintojoukosta ja käytetystä kokoonpanosta

Tässä ovat likimääräiset laskelmamme palvelimen 1C 8.3 parametreista:

On parempi ostaa RAM marginaalilla - tämä on yksi tärkeimmistä tekijöistä 1C-palvelimen korkeassa suorituskyvyssä ja samalla se on nyt yksi halvimmista komponenteista. Jos 1C Enterprise -palvelimella ei ole tarpeeksi muistia, tämä on erittäin havaittavissa käytön aikana, joten kun on kysymys siitä, mikä 1C-palvelin valita, kiinnitä aina huomiota varmistamaan, että siinä on tarpeeksi RAM-muistia.

Palvelin 1C: levyalijärjestelmän laitteet

Kun valitset, mitä palvelinta 1C:lle tarvitaan, on muistettava, että kun käyttäjät työskentelevät sen kanssa, suoritetaan monia tietojen luku- ja kirjoitustoimintoja sekunnissa. Tämä parametri - millä nopeudella kiintolevy sallii tietojen käsittelyn - on myös yksi avaimista 1C-palvelimen nopeuteen.

Kun suunnittelet 1C-palvelinta, suosittelemme, että noudatat seuraavia levyalijärjestelmän laitteita koskevia vaatimuksia:

  • Ei ole väliä minkä palvelimen luot 1C:lle, emme missään tapauksessa suosittele yksittäisten levyjen käyttöä palvelimissa - on suositeltavaa järjestää ne RAID-taulukoihin (RAID 10 suurille tai RAID 1 pienille tietokannoille), joissa tietokantataulukot sijoitetaan.
  • Suosittelemme siirtämään hakemistotiedostot erilliselle SSD-levylle, jotta niihin pääsee nopeammin käsiksi
  • TempDB - 1-2 (RAID 1) SSD-levyllä.
  • Aseta käyttöjärjestelmä ja käyttäjätiedot SSD/HDD:n RAID 1:een.
  • Varaa lokitiedostoille erillinen looginen levy ryhmästä tai fyysinen SSD-levy.
  • Jos mahdollista, käytä laitteisto-ohjain- Olemme nähneet tilanteita, joissa tehokas ja kallis palvelin hidastui ohjaimen riittämättömän suorituskyvyn vuoksi.

Palvelimen valinta 1C:lle

Tässä artikkelissa olemme antaneet joitain vinkkejä ja likimääräisiä laskelmia palvelimen valitsemisesta 1C:lle, toivottavasti niistä on sinulle hyötyä.

Lopuksi lisätään vielä yksi asia - sinun ei pitäisi yrittää säästää rahaa käyttämällä käyttäjätietokonetta 1C-palvelimelle (kuten pienissä yrityksissä usein tehdään) - käyttäjälaitteisto on paljon vähemmän luotettava ja vikasietoinen kuin vastaavanlainen palvelinlaitteisto. esitys. Yrityksesi kirjanpitojärjestelmää ei kannata vaarantaa. Jos oikean laitteiston ostaminen ei ylitä budjettiasi, sinun kannattaa harkita 1C:n käyttöönottoa pilvessä.

Jos sinun on vaikea selvittää, mikä palvelin valita 1C Enterprise 8.3:lle, kuinka tehdä 1C-palvelin, koska et ole ennen törmännyt tähän tehtävään, voit aina ottaa yhteyttä järjestelmäintegraattoriyritykseen, jotta kokeneet tekniset asiantuntijat auttavat sinua suunnittele, osta, asenna ja asenna sopiva palvelin 1C:lle.

Aluksi ehdotan, että korostetaan useita työskenaarioita:

1.) Työskentely tiedostokannan kanssa jaetun resurssin (verkkopalvelimen) kautta

2.) Työskentely terminaalin tiedostokannan kanssa

3.) Työskentely palvelin (MSSQL) tietokannan kanssa

Työskentely tiedostokannan kanssa jaetun resurssin (verkkopalvelimen) kautta


Täällä kaikki on melko yksinkertaista. Jos tämä säännölliset lomakkeet ja 1-3 käyttäjää. Valitse sitten "palvelimelta" (kone, jolla tukiasema sijaitsee:

  • nopeat ruuvit- kiinnitä huomiota karan nopeuteen (otamme 7200 rpm). Emme esimerkiksi ota vihreää sarjaa WD:ltä, otamme mustan tai punaisen. Katso Seagaten Constellation-sarja.
  • prosessori- ytimet eivät ole yhtä tärkeitä kuin niiden taajuus. 1C käyttää moniytimistä melko huonosti (ei ollenkaan), joten 8-ytimisestä prosessorista ei saa mitään hyötyä, 2-ytiminen korkeammalla taajuudella tekee sen. Esimerkiksi core i3 4360 - tämä on tällä hetkellä Intelin maksimitaajuus (4GHz turbotilassa).
  • RAM - hän ei näytä roolia. Kun otetaan huomioon, kuinka nykyaikaiset sovellukset kuluttavat muistia, laita 8 Gt
  • netto- No, itse asiassa et todellakaan hyödy 1Gb verkosta, mutta kuitenkin, jos 8-johtiminen kierretty pari on venytetty (voit katsoa liittimistä), niin on järkevää laittaa gigabitin kytkin, samalla tiedostojen jakaminen on nopeampaa.
    Ja viimeinen silaus tässä skenaariossa on, että sinun ei tarvitse sijoittaa tietokantaa jonnekin erilliseen koneeseen - pitkäkestoiset toiminnot suoritetaan paljon nopeammin paikallisesti kuin verkon kautta. Laita tämä auto päälle työpaikka, josta on tarkoitus esimerkiksi sulkea kuukausi tai päivittää tietoturvaa.

Toinen kohta, jos alusta on päällä hallinnoidut lomakkeet. Täällä, jos kaikki tehdään yllä kuvatulla tavalla, saat jarrut. Tästä on kuitenkin ulospääsy:

  • SSD* tavallisen ruuvin sijaan pelastaa meidät. Ota 120 Gt:n kiintolevy, sillä vaikka valuuttakurssin kasvu huomioon otettaisiin, ne ovat hyväksyttäviä. Suosittelen kiinnittämään huomiota Intel 520/530 -sarjaan, kingston v300:aan. Vielä parempi, lue vain uusimpien mallien arvostelut, koska. nämä markkinat kehittyvät melko nopeasti ja uusia tuotteita tulee markkinoille
    *Huomaa: Jos yhdistät levyt RAID:iin peilauksella, esimerkiksi RAID1. Tässä tapauksessa on sellainen hetki: useimmat SSD-asemat trimmi tarvitaan roskien siivoamiseen (pääasiassa melko vanhoissa malleissa), komentoa ei ehkä tueta raid-tilassa ja aseman nopeus heikkenee toimiessaan. Tämän ongelman välttämiseksi voit käyttää ainakin kahta tapaa: ihannetapauksessa ostaa yritystason SSD, esimerkiksi intel DC3500. Jos se näyttää kalliilta, voit käyttää nippua: emolevy piirisarjalla
  • prosessori- samanlainen kuin edellinen kappale. Mitä korkeampi taajuus, sitä parempi.
  • RAM - iso hän ei näytä roolia. Kun otetaan huomioon, kuinka nykyaikaiset sovellukset kuluttavat muistia, laita 8 Gt

Jos 1 käyttäjä työskentelee paikallisesti tietokannan kanssa, tämä riittää hänen mukavaan työhönsä, mutta verkkotyön nopeus jaetun resurssin kautta on silti hidasta. Mutta tässä on ulospääsy - työskentele verkkopalvelimen kautta. Internetistä löydät suuren määrän artikkeleita, jotka kuvaavat työn järjestämistä 1C:n kanssa samalla tavalla, en käsittele tätä tässä artikkelissa. Ainoa asia, jonka jaan kanssasi havaintojeni: on parempi määrittää työskentely käyttäjille ei verkkoselaimen kautta, vaan ohuen asiakkaan kautta (kun lisäämme uuden tietokannan IS-luetteloon, siellä on kohta " verkkopalvelin" IS-sijoittelusivulla). Tämä on havaintojeni mukaan nopeampaa kuin selaimen kautta. Lisäksi selaimen kautta työskennellessä käyttöliittymässä on virheitä (siirtynyt PM jne.), joita ei esiinny käytettäessä ohuen asiakkaan kautta.

Itse asiassa käyttämällä tätä reseptiä (ssd, korkeataajuinen prosessori, verkkopalvelin, ohut asiakas). Voit kumota myytin "jos käyttäjien määrä on enemmän kuin 1 (jonkin version mukaan enemmän kuin 0 :)) - tarvitset palvelinkannan *.

*Vaikka tietysti sillä ehdolla, että kyseessä ei ole SCP tai > ~ 4GB kokoinen tietokanta, mutta käyttäjien määrä ei ylitä 4 (nämä ovat tietokannan enimmäiskoot ja näkemäni käyttäjien määrä, ehkä joku tapasi tapauksia, joissa web-palvelimen kautta enemmän ihmisiä työskenteli tiedostokannan kanssa? Kirjoita kommentteihin)

Työskentely terminaalin tiedostokannan kanssa

Siirrytään seuraavaan vaihtoehtoon. Meillä on päätepalvelin ja tiedostokanta. Tässä kaikki on samanlaista kuin skenaariossa 1, paitsi prosessori:

  • SSD-asema tavallisen ruuvin sijaan.*
    *Merkintä: muista koota levyt peilauksella varustettuun RAIDiin, esimerkiksi RAID1. Tässä tapauksessa on sellainen kohta: useimmat SSD-asemat vaativat trimmaa roskien siivoamiseen (pääasiassa melko vanhoille malleille), raid-tilassa komentoa ei ehkä tueta ja aseman nopeus heikkenee toimiessaan. Tämän ongelman välttämiseksi voit käyttää ainakin kahta tapaa: ihannetapauksessa ostaa yritystason SSD, esimerkiksi intel DC3500. Jos tämä vaikuttaa kalliilta, voit käyttää mukautetun luokan SSD-levyä, mutta varmista sitten, että sen uudelleenkirjoituskapasiteetti riittää skenaarioosi.
  • prosessori- Tässä on järkevää ottaa corei5 i3:n sijaan, koska 1C toimii terminaalissa, 2 lisäydintä ei häiritse, mutta älä unohda taajuutta.
  • RAM ylläpitäjien keskuudessa on niin vakaa ilmaus: muistia ei ole koskaan paljon). Käytännössäni 7 henkilöä, jotka työskentelevät BP3:ssa, vievät terminaalissa 8-12 Gt (se riippuu siitä, kuinka monta asiakirjaa on avoinna kullekin käyttäjälle). Tavallisissa muodoissa muistin määrä voidaan jakaa kahdella :). Arvioitu laskelma voidaan tehdä seuraavasti: 256 MB itse pääte-istuntoon + 1,5 Gt 1C: lle

Työskentely palvelin (MSSQL) tietokannan kanssa


Tämä skenaario on monimutkaisin ja vaatii ehkä erillisen artikkelin. Ehdotan tässä artikkelissa tarkastelemaan vain suorituskykyyn vaikuttavia perusperiaatteita

  • SQL-palvelimen ja palvelimen 1C sijoitus. Eri koneilla tai yhdellä. On olemassa sellainen hetki: jos ne ovat samassa koneessa, viestintä niiden välillä tapahtuu jaetun muistiprotokollan kautta, ja tässä tapauksessa saamme suorituskyvyn bonuksen, jota ei ole, kun ne ovat eri koneissa.
  • PROSESSORI. Ja tässä on jo hyödyllinen ja korkea kellotaajuus ja moniytiminen. Koska meillä on SQL-palvelinprosessi, jos se on samassa koneessa, ja useita 1C rphost -palvelinprosesseja, jotka lataavat prosessoriytimet. Haluan erikseen korostaa kahden prosessorin järjestelmiä (eli kun emolevyssä on kaksi liitäntää ja enemmän kuin pistorasia). Vaikka ottaisit yhden tyhjän pistorasian "varaan, osta prosessori myöhemmin, jos sitä yhtäkkiä tarvitset". Olen nähnyt suuren määrän kaksikantisia palvelimia, jotka seisoivat käyttöiän loppuun asti tyhjällä toisella pistokkeella. Tosin jos yritys maksaa... miksi kieltää itseltäsi nautinto :)
  • RAM. SQL Server * käyttää työssään aktiivisesti RAM-muistia, jos se ei riitä, se kiipeää levyille, jotka jopa ssd:n tapauksessa ovat hitaampia kuin RAM. Siksi tässä ei kannata säästää muistia. Budjetoi mahdollisimman paljon (älä unohda tietysti maalaisjärkeä :)) ja jätä vapaita paikkoja emolevylle, jotta voit aina toimittaa lisätangon.
    *Huomaa: älä unohda rajoittaa SQL-palvelimen käyttämää RAM-muistin enimmäismäärää niin, että se riittää käyttöjärjestelmä- ja pääte-istuntoihin, ja lisää myös tmp:n ja SQL-kannan lisäämisen vaiheita (oletusaskel on 1 mb, mikä on erittäin pieni, setti 200 Mt pohjalle ja 50 MB lokille)
  • levyn alijärjestelmä. Ajatus saattaa näyttää siltä, ​​että jos RAM-muistin määrä on suurempi kuin tukikohdan koko, niin se kaikki makaa muistissa ja kaikki lentää. Se saattoi hyvinkin olla ... ennen ensimmäistä kirjoitusoperaatiota :), joka kirjoittaa levyille. Ja tässä kovalevyt rikkovat sinut :) Käytä SSD-asemia. Ja tässä, älä enää säästä muista kuin pöytätietokoneiden SSD-levyistä, vaan hanki normaalit yritystason SSD-levyt. Intel DC3700 -200GB resurssi 3,7 petabyyttiä (10 päällekirjoitusta aseman kokonaismäärästä päivässä 5 vuoden ajan), löytyy hintaan 24000r/kpl + sekunti RAID1=48000:lle. Lisenssi vie paljon enemmän.

Näyttää siltä, ​​että se on siinä. Jos kysymyksiä/valituksia/ehdotuksia - tervetuloa kommentteihin;)

1C:Enterprise 8 voi olla resursseja vaativa sovellus jopa pienellä käyttäjämäärällä. Kun valitset palvelimen 1C:lle, jokainen omistaja haluaa välttää "syntymävammat" - siihen upotetut mahdolliset pullonkaulat. Toisaalta nykyään harvat ostavat palvelimia, joissa on ylikapasiteettia, "kasvua varten". On hyvä, jos kuormitusprofiili voidaan poistaa etukäteen - silloin on helpompi suunnitella palvelin tietylle yrityksen sovellusten kokoonpanolle.

Tarkastellaan varmuuden vuoksi "1C:Enterprise 8.2" -alustaa sen suosituissa peruskokoonpanoissa "Accounting", "Trade and Warehouse", "Payroll and Human Resources Management", "Commercial Enterprise Management" ja osittain "Manufacturing Enterprise Management" ". Lähdemme siitä tosiasiasta, että 1C:ssä työskenteleville yrityksille, joissa on vähintään 10 työntekijää, "1C: Yritys 8.2. Sovelluspalvelin". Otetaan huomioon mahdollisuus työskennellä etätyöpöytätilassa, jolloin tietokannan samanaikaisten käyttäjien määrä on jopa 100-150. Suositukset koskevat myös "raskaampaa" DB 1C:tä, mutta "vakavat tapaukset" edellyttävät aina yksilöllistä lähestymistapaa.

Prosessorit ja RAM

Jos yritys on hyvin pieni (2-7 käyttäjää järjestelmässä), tietokanta on pieni (jopa 1 Gt) ja 1C:Enterprise 8.2 toimii tiedostotilassa käyttäjän tietokoneella, niin saadaan klassinen tiedostopalvelimen toteutus. . Jopa Intel Core i3, erityisesti Intel Xeon E3-12xx, pystyy selviytymään tällaisesta tehtävästä suorittimen kuormituksen suhteen. Tarvittava RAM-muistin määrä on melko yksinkertainen: 2 Gt käyttöjärjestelmälle ja 2 Gt järjestelmätiedostovälimuistille.

Jos yrityksellä on 5-25 1C käyttäjää, tietokannan koko on jopa 4 Gt, niin 1C:Enterprise 8.2 -sovelluksessa pitäisi olla riittävästi 4-ytimistä Intel Xeon E3-12xx tai AMD Opteron 4xxx. Käyttöjärjestelmän 2 Gt RAM-muistin lisäksi 1C:Enterprise 8.2:lle on varattava 1–4 Gt. Application Server" ja MS SQL Serverille saman verran välimuistia - yhteensä 8-12 Gt RAM-muistia. Pienille tietokannoille on toivottavaa tallentaa välimuistiin vähintään 30 % tietokannasta RAM-muistiin ja mieluiten kaikki 100 %.

Tunnettu (vaikkakaan ei erityisen mainostettu) tosiasia: “1C: Enterprise 8.2. Sovelluspalvelin ei pidä siitä kovinkaan paljon, kun käyttöjärjestelmä purkaa sen kiintolevyllä olevaan swap-tiedostoon, ja sillä on joskus taipumus menettää vastaus. Siksi palvelimella, jossa "sovelluspalvelin" on käynnissä, RAM-muistissa pitäisi aina olla vapaata tilaa - varsinkin kun se on nykyään halpaa.

Suuremmissa yrityksissä 1C-käyttäjät työskentelevät yleensä etäkäytön kautta sovellukseen (Remote Desktop) - eli päätetilassa. Yleensä 10-100 1C-käyttäjää, joiden tietokanta on vähintään 1 Gt, "1C:Enterprise 8.2. Sovelluspalvelin" ja käyttäjäsovellus "1C:Enterprise 8.2" toimivat samalla palvelimella.

Tarvittavien prosessoriresurssien määrittämiseksi oletetaan, että yksi fyysinen ydin voi tehokkaasti käsitellä enintään 8 käyttäjäsäiettä - tämä johtuu prosessorien sisäisestä arkkitehtuurista. Kuten käytäntö osoittaa, 1C + Remote Desktop -tehtäviin sinun ei pitäisi ottaa alempien rivien palvelinprosessoreja, joissa on alhainen laskentataajuus ja katkaistu arkkitehtuuri. Jos käyttäjiä on vähän (15-20 asti), yksi korkeataajuinen Intel Xeon E3-12xx -prosessori riittää. Samanaikaisesti ainakin yksi sen fyysisestä ytimestä (2 säiettä) menee SQL Serverin tarpeisiin, yksi lisää (2 säiettä) - 1C:Enterprise 8.2:een. Sovelluspalvelin" ja loput 2 fyysistä ydintä (4 säiettä) - käyttöjärjestelmän ja päätelaitteiden käyttäjille. Yli 20 1C-käyttäjää tai yli 4 Gt:n tietokantavolyymeilla on aika vaihtaa kahteen prosessorijärjestelmään Intel Xeon E5-26xx:ssä tai AMD Opteron 62xx:ssä.

Tarvittavan RAM-määrän laskeminen on suhteellisen yksinkertaista: 2 Gt on annettava käyttöjärjestelmälle, 2 Gt tai enemmän - MS SQL Server välimuistina (vähintään 30% tietokannasta), 1-4 Gt - kohdassa "1C: Enterprise 8.2 . Sovelluspalvelin", palvelimen muun muistin pitäisi riittää pääteistuntoja varten. Yksi päätteen käyttäjä, kokoonpanosta riippuen, kuluttaa sovelluksissa "Kirjanpito", "Kauppa ja varasto" - 100-120MB, "Palkka- ja henkilöstöhallinta", "Kauppayrityksen hallinta" - 120-160 Mt, "Tiedon hallinta" Manufacturing Enterprise" - 180-240 Mt. Jos käyttäjä käynnistää palvelimella lisäksi MS Wordin, MS Excelin, MS Outlookin, kullekin sovellukselle tulee varata vielä 100 Mt. Pääsääntöisesti päätepalvelimen vähimmäismäärä on 12 Gt RAM-muistia.

Esimerkiksi 1C-palvelimelle, jossa on koko ohjelmistopaketti, 50 päätekäyttäjää Trading Enterprise Management -kokoonpanossa ja 8 Gt:n tietokanta, kahden Intel Xeon E5-2650 -prosessorin (8 ydintä, 16 säiettä, 2,0 GHz) laskentateho olla optimaalinen. RAM-muistia tarvitaan vähintään 2 (OS) + 4 (SQL) + 4 (1C-palvelin) + 8 (160 "UTP" * 50 käyttäjää) = 18 Gt ja mieluiten 24-32 Gt (6-8 DIMM-kanavaa, kukin 4 Gt) .

Levyn alijärjestelmä

Useimmat valitukset 1C:Enterprise 8 -palvelimien hitaasta toiminnasta johtuvat väärinymmärryksestä siitä, minkä tyyppisiä I / O-toimintoja niille suoritetaan, millä tiedoilla ja millä intensiteetillä. Usein levyalijärjestelmä on avain riittävän palvelimen suorituskyvyn varmistamiseen kokonaisuutena - loppujen lopuksi ladattujen tietokantojen suurin ongelma on taulukoiden lukitseminen, kun monet käyttäjät työskentelevät niiden kanssa samanaikaisesti tai joukkolatausten / -latausten / aikana. julkaisuja. Palvelimen levyalijärjestelmän valvonta ja optimointi.

1C:llä on 5 tietovirtaa levyalijärjestelmälle, jonka kanssa se toimii:

  • tietokantataulukot;
  • hakemistotiedostot;
  • väliaikaiset tiedostot tempDB;
  • SQL-lokitiedosto;
  • 1C-käyttäjäsovellusten lokitiedosto.

1C:n tietorakenne on oliosuuntautunut, ja siinä on monia objekteja ja niiden välisiä suhteita. Tietotaulukoiden käsittelyssä luku- ja kirjoitustoimintojen määrä, jotka levyalijärjestelmä voi suorittaa tietyn ajanjakson aikana (Input Output Operation per Second, IOPS), on erittäin tärkeä. Samanaikaisesti sen kyky tarjota suuri suoratoistonopeus (MBp / s) on paljon vähemmän tärkeä. Hyvin vaatimaton 200–300 Mt:n kanta, jossa on 3–5 käyttäjää, voi tuottaa huipuissa jopa 400–600 IOPS:ää. Tietokanta 10-15 käyttäjälle ja 400-800 Mt:n volyymi pystyy toimittamaan 1500-2500 IOPS:n, 40-50 käyttäjää 2-4 Gt:n tietokannasta tuottaa 5000-7500 IOPS:n ja 80-100 käyttäjän tietokannat saavuttavat helposti 12 000- 18000 IOPS.

Tietenkin levyalijärjestelmän keskimääräinen kuormitus voi olla 10-15% huipusta. Vain todellisuudessa suorituskyky huippukuormituksen aikana on tärkeää: tietojen automaattiset lataukset muista järjestelmistä, hajautetun järjestelmän tiedonvaihto tai jakson uusinta.

Nykyaikaiset asemat luku- ja kirjoitustoiminnoissa, joissa on satunnaiskäyttö (Random Read / Write) yksin selviävät tällaisista kuormista:

Intel 910 400GB

2400-8600 IOPS

On selvästi nähtävissä, että:

  • sekä HDD:n että SSD:n pullonkaula on kirjoitus;
  • perinteiset kiintolevyt eivät ole SSD-levyjen kilpailijoita lukunopeuden suhteen IOPS:ssä, ero ylittää jopa teoriassa kaksi suuruusluokkaa;
  • edes nykyaikaisin pöytäkoneen SSD ei ole 3–40 kertaa nopeampi kuin mikään kiintolevy IOPS:n kirjoitusnopeuden suhteen, palvelimen SSD on 12–40 kertaa nopeampi kuin HDD;
  • IOPS:n maksimaalisen suorituskyvyn tarjoaa PCIe SSD -luokan Intel 910 tai LSI WarpDrive.

Yksittäisiä levyjä ei käytetä tietokantapalvelimissa, vain RAID-taulukoita. Levyalijärjestelmän todellisen suorituskyvyn laskemiseksi edelleen sinun on otettava huomioon kustannukset (”sakko”) IOPS:ään kirjoittamisesta, jotka aiheutuvat levyryhmälle RAIDissa:

Jos keräät 6 levyä RAID 10:een, kutakin 1 IOPS:n dataa kohden kuluu 2 IOPS fyysistä levyä ja jos RAID 6:ssa, niin 6 IOPS levyä. Siksi, kun lasket levyryhmän kirjoituskapasiteettia, sinun on ensin laskettava yhteen kaikkien RAID-ryhmän levyjen IOPS-arvot ja jaettava ne sitten "rangaistuksella".

Esimerkki 1: 2 SATA 7200 -kiintolevyä RAID 1:ssä tarjoaa kirjoitustoiminnon: (100 IOPS *2) / 2 = 100 IOPS.

Esimerkki 2: 4 SATA 7200:aa RAID 5:ssä tarjoaa: (100 IOPS *4) / 4 = 100 IOPS kirjoitusta kohti.

Esimerkki 3: 4 SATA 7200:aa RAID 10:ssä tarjoaa: (100 IOPS *4) / 2 = 200 IOPS per kirjoitus.

Esimerkit 2 ja 3 osoittavat, miksi RAID 10:tä suositellaan sellaisten tietokantojen tallentamiseen, joilla on tyypillinen 68/32 luku/kirjoitus-jakauma.

Näistä kolmesta taulukosta käy selväksi, miksi tyypillisen "herrasmiessarjan" 2 HDD SATA 7200:n suorituskyky RAID 1:ssä ei riitä palvelimelle: huippukuormituksen aikana levykäyttöjen jono kasvaa, käyttäjät odottavat vastausta palvelimelta. järjestelmässä, joskus useita tunteja.

Kuinka lisätä levyalijärjestelmän kirjoitussuorituskykyä? Lisää RAID-ryhmän levyjen määrää, siirry levyille, joiden pyörimisnopeus on suurempi, valitse RAID-taso, jolla on pienempi kirjoitusvirhe. Välimuistin tallentaminen RAID-ohjaimella takaisinkirjoitustilan ollessa käytössä auttaa paljon. Tietoja ei kirjoiteta suoraan levyille (kuten Write Through -tilassa), vaan ohjaimen välimuistiin, ja vasta sitten erätilassa ja järjestetyssä muodossa levyille. Tehtävän erityispiirteistä riippuen kirjoitussuorituskykyä voidaan lisätä 30-100%.

Kevyesti ladattuihin tai suhteellisen pieniin tietokantoihin (jopa 20 Gt) edullinen tapa "purkaa IOPS" on sopiva - hybridi RAID SSD / HDD:ltä. Enemmän ja ei tarvitse 3-15 käyttäjän haaratietokantaa hajautetussa rakenteessa, kuten kahvila- tai huoltoasemaverkostossa.

SSD-välimuisti (LSI CacheCade 2.0- tai Adaptec MaxCache 3.0 -tekniikat) voi olla tehokas suurille (200 Gt tai enemmän) tietokantoille, joissa on pitkä historiallinen tietopolku, tai useiden suurten tietokantojen huoltoon. Tällaisten järjestelmien käyttökokemuksen mukaan 1C-tehtävissä niitä voidaan käyttää suhteellisen edullisesti ja ilman merkittäviä muutoksia tallennusinfrastruktuurissa levytoimintojen nopeuttamiseksi 20-50%.

IOPS-suorituskyvyn mestari on ennustettavasti RAID-ryhmät palvelimen SSD-levyillä - sekä perinteiset, joissa käytetään SAS RAID -ohjainta, että PCIe SSD -levyjä. Niiden suosiota haittaa kaksi rajoitusta: tekninen (RAID-ohjainten suorituskyky tai tarve murtaa radikaalisti tallennusrakenne) ja myyntihinta.

Erikseen on sanottava indeksitiedostojen ja TempDB:n tallentamisesta. Indeksitiedostoja päivitetään hyvin harvoin (yleensä kerran päivässä), mutta niitä luetaan hyvin, hyvin usein (IOPS). Tällaiset tiedot on yksinkertaisesti tallennettava SSD-levylle ja niiden lukunopeudet! Väliaikaisten tietojen tallentamiseen käytetty TempDB on yleensä pienikokoinen (1-4-12 Gt), mutta erittäin vaativa kirjoitusnopeuden suhteen. Hakemisto- ja väliaikaistiedostoille on yhteistä, että niiden katoaminen ei johda todellisen tiedon menettämiseen. Tämä tarkoittaa, että ne voidaan sijoittaa erilliselle (jopa parempi - kahdelle erilliselle levylle) SSD-levylle. Ainakin emolevyn sisäisessä SATA-ohjaimessa. Luotettavuuden ja suorituskyvyn kannalta TempDB:n alla on toivottavaa antaa peili (RAID1) SSD:ltä, se on mahdollista sisäisessä ohjaimessa, mutta kaikkien kirjoitusvälimuistien pakollisella sammutuksella. Pöytätietokoneiden SSD-levyt voivat myös selviytyä tästä roolista - kuten Intel 520 -sarja, jossa laitteiston tietojen pakkaus TempDB:hen kirjoitettaessa on juuri oikea. Näiden tehtävien poistaminen jaetusta tallennusjärjestelmästä erityiseen nopeaan alijärjestelmään vaikuttaa positiivisesti koko järjestelmän suorituskykyyn, erityisesti huippukuormituksen aikoina.

Tapauksissa, joissa on mahdollista varmistaa järjestelmänvalvojien nopein mahdollinen reagointi vikatilanteissa ja kun on monimutkaisia ​​laskentatehtäviä (varasto- tai kuljetuslogistiikka, tuotanto SCP:ssä, volyymien vaihdot URDB:ssä), TempDB siirretään RAMDriveen. Tämän ratkaisun avulla voit voittaa joskus jopa 4-12 % järjestelmän kokonaissuorituskyvystä. Joitakin haittoja syntyy vain, jos palvelin käynnistetään uudelleen: jos RAMDrive ei käynnisty automaattisesti, manuaalinen käynnistys edellyttää järjestelmänvalvojan toimia - muuten koko järjestelmä muuttuu.

Toinen tärkeä osa on lokitiedostot. Niillä on epämiellyttävä ominaisuus mille tahansa levyalijärjestelmälle - ne luovat lähes jatkuvan virran pieniä kirjoitusoikeuksia. Tämä on huomaamaton keskisuurilla kuormituksilla, mutta heikentää suuresti 1C-palvelimen suorituskykyä huippukuormituksessa. On järkevää siirtää lokitiedosto (erityisesti SQL-lokitiedosto) erilliseen fyysiseen taltioon, jolla ei ole korkeita IOPS-vaatimuksia ja joka kirjoitetaan lähes lineaarisesti. Mielenrauhan vuoksi voit luoda peilin halvoista ja suurista SATA / NL SAS:ista (täydelle lokille) tai edullisista pöytätietokoneiden saman Intel 520 -sarjan SSD-levyistä (Simple log tai Full log, jossa on päivittäinen varmuuskopiointi ja puhdistus).

Yleisesti voidaan sanoa, että SSD-levyjen saapuminen palvelimille on avannut uusia mahdollisuuksia lisätä massapalvelimien suorituskykyä - porrastetun tiedontallennustilan ja kohtuullisen levy-I/O-konfiguroinnin ansiosta.

"Ideaalipalvelimen alle 1C" levyalijärjestelmä näyttää tältä:

1. Tietokantataulukoita isännöidään luotettavien palvelin-SSD-levyjen RAID 10:ssä (tai RAID 1:ssä pienille tietokannoille), joissa on pakollinen laitteisto-RAID-ohjain. Jos IOPS-vaatimukset ovat korkeat, harkitse PCIe SSD -vaihtoehtoa. Suurille tietokannoille kiintolevyryhmien SSD-välimuisti on tehokasta. Jos käytetty 1C-kokoonpano ja tietorakenne eivät ole liian vaativia IOPS:lle ja käyttäjien määrä on pieni, riittää perinteinen HDD SAS 15K rpm -sarja.

2. Indeksitiedostot siirretään nopealle ja edulliselle yhdelle SSD-levylle, TempDB - 1-2 (RAID 1) SSD- tai RAMDrivelle.

3. Erillinen taltio (yksi fyysinen levy tai RAID-1) SATA/NL SAS -kiintolevyllä tai edullisella SSD-levyllä tai RAID-ryhmässä oleva looginen levy, jolla palvelimen käyttöjärjestelmä ja käyttäjän tiedostot/kansiot sijaitsevat.

4. Käyttöjärjestelmä- ja käyttäjätiedot tallennetaan kiintolevyn tai SSD-levyn RAID 1:een.

Jos IT-infrastruktuuri on virtualisoitu, on erittäin toivottavaa, että SQL Server asennetaan ei virtuaalikoneena, vaan suoraan fyysiselle palvelimelle, paljaalle metallille. Numeron hinta on 15–35 % levyalijärjestelmän suorituskyvystä (riippuen laitteistosta, ohjaimista, virtualisointityökaluista ja taltioiden liitäntätavoista). Virtualisoidussa SQL-palvelinympäristössä taltioiden yhdistäminen tietokantataulukoilla, hakemistotiedostoilla ja TempDB:llä virtuaalikoneeseen on pakollista yksinoikeustilassa suoran käytön kautta.

Verkkoliitännät

Rakennettaessa 1C:Enterprise 8 -järjestelmiä pienille ja keskisuurille yrityksille (jopa 100-150 aktiivista käyttäjää samanaikaisesti), verkkotoimintojen häviöt Ethernet-liitännän kautta tulisi minimoida. Ihannetapauksessa palvelee sekä SQL Serveriä että "1C: Enterprise 8 Application Server x64" ja 1C-käyttäjäistuntoja etätyöpöydässä yhdellä fyysisellä palvelimella. Vikasietokyvyn suhteen kiistanalainen suositus antaa sinun saada kaiken irti laitteistosta ja ohjelmistosta, ja virtualisoinnin avulla se antaa tietyn tason tietoturvan ja "ympäristön toistettavuuden" muille laitteille.

Miksi Ethernet jätetään pois ketjun SQL-palvelimesta -> 1C:Enterprise 8 -sovelluspalvelin -> 1C:Enterprise 8 -käyttäjäistunnosta? Ethernet-verkkorajapinta, jossa data on pakattu suhteellisen pieniin lohkoihin lähetystä varten, aiheuttaa aina lisäviiveitä: sekä liikennettä pakatessa/purkattaessa että itse lähetyksen aikana (korkea latenssi). 1C:Enterprise 8:ssa melko suuria tietoryhmiä siirretään prosessoitavaksi ja näytettäväksi koko ketjussa, joissain tilanteissa - molempiin suuntiin. Siirrettäessä tietoja suoraan prosessista toiseen palvelimen RAM-muistissa (samalla palvelimella ilman virtualisointia) tai virtuaalisen verkkoliitännän kautta (saman fyysisen palvelimen sisällä, hyvillä palvelinverkkosovittimilla RAM-lohkojen siirrolla virtuaalikoneiden välillä) ovat paljon alhaisemmat. Nykyaikaiset kaksiprosessoripalvelimet, joissa on suuri RAM-muisti ja levyalijärjestelmä SSD:llä, mahdollistavat 1C-tietokannan mukavan palvelemisen 100-150 aktiiviselle käyttäjälle.

Jos useiden fyysisten isäntien käyttö on väistämätöntä ladatuille tietokannoille, on toivottavaa yhdistää kaikki palvelimet 10 Gb Ethernetin kautta. Tai vähintään 2-4 yhdistettyä 1 Gt Ethernet-yhteyttä TCP/IP-laitteistokiihdytyksellä (TCP/IP Offloader) ja laitteiston virtualisointituella.

Ennen kaikkea budjettiratkaisut kärsivät Ethernet-porttien suorituskyvyn heikkenemisestä. Ei ole mikään salaisuus, että useimpiin palvelimien emolevyihin juotettuja 1 Gt:n verkkosovittimia ei ole suunniteltu kestämään raskasta verkkoliikennettä. Vaikka levyllä on 2 tai 3 GbE-porttia, ne on yleensä toteutettu työpöytäsiruilla. Ne ovat riittäviä hallintaan ja aiheuttavat ylimääräisiä yleiskustannuksia verkkokeskusten ylläpitoon, erityisesti virtualisoidussa ympäristössä. Koko tiedonsiirtoprosessi tällaisen sirun kautta saadaan suorittimen resursseista, RAM-muistista ja sisäisten väylien kuormituksesta. Tällaiset sirut eivät kiihdytä IP-liikenteen siirtoa, jokainen vastaanotettu ja lähetetty Ethernet-paketti vaatii erillisen keskeytyksen prosessorille. Virtualisoidussa ympäristössä verkkoliitännän suorituskykyhäviöt voivat olla 25-30 %. Epämiellyttävintä on, että verkkoliitäntä on ylikuormitettu valvontatyökaluilla, eikä sitä välttämättä huomaa. Keskusprosessori on räjähtänyt sen takia, ja jos se ei toimi, se on tyhjäkäynnillä odottamassa vastausta verkkokortilta. On toivottavaa sulkea pois työpöytäsirujen portit virtualisoitujen ympäristöjen tietovirrasta, jolloin ne jätetään palvelimen hallintatehtäviin. Kovan verkkoliikenteen aikana palvelimen piirisarjaan kannattaa lisätä erillinen verkkokortti.

Vikasieto vai hyväksyttävä seisokit?

Palvelimen suorituskykyä koskeviin keskusteluihin liittyy lähes aina väitteitä palvelimen luotettavuudesta. Vikasietokyvyn varmistaminen maksaa aina lisäkustannuksia, varsinkin jatkuvien tuotantoprosessien tukemisessa. 1C:n roolia ja paikkaa vähättelemättä voidaan sanoa, että suurin osa sen käyttäjistä ratkaisee "suorituskyky / luotettavuus" -dilemman eri tasoilla: he taistelevat ensimmäisestä laitteistoratkaisujen optimoinnilla, toisesta - prosessien organisoinnilla ja menettelyt. Kun sovellukset ovat kohtalaisen kriittisiä, terveyden ylläpitämisen painopiste ei ole yksittäisten palvelinten suojauksessa, vaan infrastruktuurin käyttökatkon minimoimisessa kokonaisuutena.

Tietenkin yrityksissä, joissa on suhteellisen suuri määrä samanaikaisesti kytkettyjä käyttäjiä (25-150) ja jotka isännöivät kaikkia sovelluksia yhdellä palvelimella, on välttämätöntä käyttää keskeytymättömiä virtalähteitä, itse palvelimien redundantteja virtalähteitä, hot-swap-levykoreja. ja hot-standby RAID-ryhmät. Mutta mikään laitteisto ei voi korvata itse suunniteltua tietojen varmuuskopiointia. Päivittäisellä (tarkemmin öisellä) varmuuskopiolla ja online-tiedostolla, jossa on täydellinen SQL-loki, voit palauttaa 1C-tietokannan kokonaan suhteellisen lyhyessä ajassa.

Pienten ja keskisuurten yritysten keskusjärjestelmän 1C-järjestelmän sallittu seisokkiaika on 1-2 tapaturmaa kuukaudessa, kesto 1-4 tuntia. Itse asiassa tämä on valtava aikamarginaali - jos olet valmis toipumaan etukäteen. Nopean uudelleenkäynnistyksen välttämätön edellytys on kaikkien virtuaalisten ja fyysisten palvelimien kuvien saatavuus virtuaalisen koneen muodossa erillisellä tallennustilalla / taltiolla - itse infrastruktuurin osan palauttamiseksi varmuuskopiopalvelimelle. Pakollinen päivittäinen varmuuskopiointi (sekä viikoittain ja jakson lopussa) toiseen fyysiseen laitteeseen ja Täysi SQL-loki tapauksissa, joissa tietojen menetys "työpäivän alusta" on kriittinen ja vaikea palauttaa manuaalisesti. Jos sinulla on vaihtolaitteita, voit säilyttää 1-2 tunnin sisällä työkyvyn palauttamiseksi yleensä, vaikkakin alhaisemmalla tuottavuudella. No, jos 24 × 7 -jatkuvuutta vaaditaan, etusijalla on sopivan arkkitehtuurin valinta, laitteet, joissa on pieni määrä vikakohtia, ja täysimittaiset klusterointitekniikat. Mutta se on täysin eri tarina.

Alkuperäinen artikkeli: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

"Computer Review" -lehden toimittajan luvalla

Enterprise 8 -alustalla suoritettavien ohjelmien tehokkuuden varmistamiseksi tarvitaan paitsi osta 1C, vaan myös oikean palvelinratkaisun valitsemiseen.

Tällä hetkellä kohdan 1C 8 toteutus toteutettu useissa versioissa. Suosituin ratkaisu on oma tiedostopalvelin. Tämä vaihtoehto sisältää erillisen tietokoneen tai pienen palvelimen, asennetun palvelimen käyttöjärjestelmän sekä jaetun käyttöoikeuden määrittämisen kansioon 1C: Enterprisen kanssa. Tämä vaihtoehto on melko yksinkertainen ja edullinen, mutta se ei pysty tarjoamaan korkeaa suorituskykyä ja luotettavuutta.

Jos organisaation on varmistettava luotettavuus ja korkea suorituskyky, he pääsääntöisesti valitsevat kohdan 1C 8 toteutus käyttäen teollista DBMS-järjestelmää - Microsoft SQL Server. Tässä tapauksessa käyttöjärjestelmänä on Windows Server 2003, ja laitteiston on täytettävä korkeat vaatimukset.

Tämä ratkaisu on kalliimpi, mutta sillä on omat etunsa, kuten korkea suorituskyky ja vikasietoisuus. Järjestelmä mahdollistaa myös tehokkaan varmuuskopioinnin, tarjoaa korkeatasoisen tietosuojan ja eliminoi pakollisen indeksoinnin vikatilanteissa.

Jotta järjestelmä toimisi kunnolla, se on otettava käyttöön pätevän henkilön toimesta 1C ohjelmoija. Koska kokemattomat 1C ohjelmoija voi mitätöidä kaikki edut - suuri tietokantavolyymi heikkolaatuisella palvelinkokoonpanolla vähentää merkittävästi 1C-tuotteen suorituskykyä.

On myös syytä huomata, että tämä työpöydän käyttöönottovaihtoehto edellyttää asiakaslisenssit muodostaakseen yhteyden Windows Server 2003/2008:aan. Jos 1C-tietokannassa on suuria kuormituksia, Windows SBS 2003/2008:n suorituskyky saattaa olla riittämätön. Tässä tapauksessa on mahdollista varata lisäpalvelin, Microsoft SQL Server 2005/2007.

Toinen menetelmä, jota käytetään usein 1C:tä toteutettaessa, on päätepalvelin. Windows Server 2003:n sisäänrakennettu Terminal Connection Service mahdollistaa suuren suorituskykyreservin, kyvyn työskennellä turvallisesti ja täysin sekä korkean suojan tason.

Luettelo ohjelmistoista ohjelmien toteuttamiseen 1C: Enterprise.

Pääsääntöisesti seuraavia ohjelmistoja käytetään ohjelmien toteuttamiseen 1C:llä: Enterprise-alustalla: Windows 7, Vista, XP Professional, Windows Server 2003-2008, Windows Small Business -palvelin.

Windows XP Professional on pitkään ollut käyttöjärjestelmän perusversio, ja se on asennettu moniin organisaatioihin. Windows 7 on melko uusi käyttöjärjestelmä henkilökohtaisille tietokoneille, joka tarjoaa korkean suorituskyvyn verkkojen, tekniikoiden ja järjestelmien integroinnin ansiosta. Aloitustason palvelimina voidaan käyttää Windows Vista-, XP Professional- ja 7-käyttöjärjestelmillä varustettuja tietokoneita. Nämä käyttöjärjestelmät tukevat jopa 10 yhteyttä, mutta nopeus ja turvallisuus jättävät paljon toivomisen varaa.

Windows Server 2003 tai 2008 ovat suosituimpia palvelinkäyttöjärjestelmiä, joiden avulla voit toteuttaa 1C:Enterprise-ratkaisuja , varmistaa luotettavuuden ja huollon helppouden.

Windows Small Business Server 2008 on ohjelmistotuote, joka koostuu kokonaisesta paketista palvelintuotteita ja lisäkomponentteja. Tämä vaihtoehto sopii pienille yrityksille, jotka eivät suunnittele vakavia kuormituksia 1C Enterprise -tietokantaan. Windows SBS 2008:n tärkein etu on sen alhainen hinta.

Siis ennen osta 1C, sinun on harkittava tietokannan kuormitusta ja tämän mukaisesti valittava palvelimen tyyppi.

Julkaisun valmisteli lisensoitu ohjelmistokauppa 1cmarket.ru


Kommentit ja arvostelut

Verkkolähteet ovat paljastaneet Black Shark 2 Pro -älypuhelimen yksityiskohtaiset ominaisuudet, joka tulee virallisesti...

HTC on laajentanut budjettiälypuhelinvalikoimaansa Wildfire E -mallilla, jonka hinta on 9 000 ruplaa...

LG on ilmoittanut, että heidän televisionsa tukevat Apple AirPlay 2- ja HomeKit-tekniikoita. Tekijänä s...

Phanteks-yhtiö esitteli edellisenä päivänä ainutlaatuisen ratkaisun mukautetun CBO:n kokoamiseen. Uusi Glacier D140...