1С сервері: CPU, жад пен дискілерді артық төлемсіз қалай таңдау керек

Қайдан бастау: сервер қандай міндеттер атқарады

Сервер сатып алу модельден немесе ядро санынан басталмайды — алдымен оның қандай рөлдерді атқаратынын анықтау керек. Бірдей сервер 1С үшін құжат енгізуге арналған «жұмысшы ат» бола алады, ал бір уақытта дерекқор, алмасулар, есептер мен интеграциялар да сол жерде жүрсе, талаптар мүлдем өзгереді. Екінші жағдайда дискілер мен жад жиі CPU-дан маңыздырақ болады.

1С-пен бірге не жиі жұмыс істейді

1С-тің өзінен бөлек әдетте СУБД (көбінесе MS SQL Server немесе PostgreSQL), фондық тапсырмалар, сайтпен немесе басқа жүйелермен алмасулар, басып шығару, пошта, банк және ЭДО интеграциялары, сондай-ақ ауыр есептер болады. Егер бәрі бір серверде тұрса, жүктемелер қосылып, тар орын күтпеген жерден пайда болуы мүмкін.

Пайдаланушылар саны бірдей болғанымен, жүктеме әртүрлі болуы мүмкін. Күн бойы құжатпен жұмыс істейтін 20 бухгалтер — бір жағдай. Ал олардың ішінде жартысы «жыл бойынша барлық қоймалар» сияқты үлкен есептерді үнемі іске қосса және екі адам әр 5 минут сайын алмасулар жүргізсе, тіпті қуатты сервер де жүктеліп қалуы мүмкін.

Қайсысы жиі бәсеңдетеді

Практикада ең жиі дискі жүйесі шектейді (көп кішкентай операциялар мен күту), одан кейін жад (кэштің ығыстырылуы және swap пайдалану), және тек содан кейін CPU. Желінің мәселелері пайда болады, егер база мен пайдаланушылар әртүрлі орналасқан жерлерде болса немесе бэкаптар мен алмасулар жұмыс уақытында жүрсе.

Темір таңдаудан бұрын қысқа деректер жинаңыз:

• бір уақытта қанша пайдаланушы және олардың рөлдері (бухгалтерия, қойма, сату, басшылық)
• базаның қазіргі көлемі және 1–2 жылға өсу болжамы
• ең ауыр операциялар қандай (есептер, ай жабу, алмасулар, жүктеулер)
• СУБД қайда орналасады (соңғы серверде ме, бөлек па)
• қолжетімділік талаптары (қажет пе резервтеу және жылдам қалпына келтіру)

Осы сұрақтарға жауаптар қай жерде үнемдеуге болатынын және қай жерлерде ядроларға артық төлем жасаудың қажеті жоқ екенін көрсетеді.

1С, ERP және дерекқорлардың типтік жүктеме профильдері

Сервер адамдар жүйеде не істейтініне байланысты әртүрлі жүріс көрсетеді. Қайсысы сізге тән екенін алдын ала түсіну пайдалы: «көп қолданушы онлайн», «ай сайынғы шың», «ауыр есептер» немесе «интеграциялар 24/7».

1) Күнделікті онлайн-жұмыс

Бұл пайдаланушылардың бір уақытта жұмысы: құжат енгізу, тіркеу, басып шығару, шағын сұраулар. Мұнда қысқа операцияларға тез жауап және шипалық жоғары жүктемеде «ұстап қалмау» маңызды. Әдетте бір ядроның өнімділігі және диск кешігуі (жазба белсенді болса) шектейді.

2) Регламентті тапсырмалар және ай жабу

Түнде немесе айдың соңында себет есептеу, айды жабу, қайта өңдеу, алмасулар іске қосылады. Жүктеме ұзақ әрі ауыр болады, кейде жақсы параллелденеді, бірақ әрдайым емес. Қате — «сақтық үшін» көп ядро алу, ал шын мәнінде шектеу бірнеше ағындарда немесе дискілердің жылдамдығында болуы мүмкін.

3) Ауыр есептер мен ерікті сұраулар

Бухгалтер немесе аналитик күрделі есеп жинағанда, база көп деректі оқып, оларды сұрыптайды. Әдетте маңыздысы:

• кэш үшін жеткілікті жад (дискіден аз оқу үшін)
• уақытша операциялар үшін жылдам SSD (NVMe жиі тиімді)
• ауыр есептерді кім және қашан іске қосатынын анық білу

4) Интеграциялар, терминалдық қолжетімділік және виртуализация

ERP/CRM, EDI, API және файл алмасулары біркелкі фондық жүктеме және тұрақты жазбалар береді. Терминалдық қатысу немесе виртуализация CPU мен жадқа «құрбы» қосады.

Типтік сценарий: күндіз 40 пайдаланушы батырмаларды басса, кешке ай жабу басталып, бір уақытта алмасулар жүреді. Мұндайда CPU-ға артық төлеуден гөрі жад пен жылдам дискілерге инвестиция жасау және ауыр тапсырмалар үшін терезе жоспарлау ақылдырақ.

Сатып алудан бұрын жинау қажет деректер

1С серверін таңдаудан бұрын жүктеме туралы нақты деректер жинаңыз. Олай істемей қосымша ядро сатып алып, баяуын дискілерге немесе жадқа тиіп кету оңай.

Пайдаланушылардан бастаңыз. Маңыздысы — штаттағы адамдар саны емес, ең жүктелген сағаттағы бір уақытта жұмыс істейтіндер саны. Бір адам ай жабуды орындап, бірнеше «тыныш» қолданушыға тең жүктеме бере алады.

Содан кейін базаны бағалаңыз: ағымдағы көлем, база мен журнал файлдары қанша алады және қалай өсуде. 1–3 жылдық перспектива жоспарлаңыз, серверді ерте ауыстырудың қажеті болмауы үшін. Егер өсу секірмелі болса (сайтпен интеграция, архив сканерлеу және т.б.), оны да белгілеңіз.

Шиықтарды тіркеңіз: айдың соңы, дүйсенбі таңертеңі, маусымдық сатылымдар, құжаттардың жаппай жүктелуі. Пикте нақты не болатынын жазыңыз: құжаттарды тіркеу, жалақы есептеу, ай жабу, регламенттік тапсырмалар, алмасулар.

Поставщикке әкелу үшін минималды пакет:

• әдеттегі күндегі және пиктегі бір уақытта жұмыс істейтіндер саны
• база көлемі және жылдық өсім
• сезім бойынша 3–5 ең баяу операция және олардың қай кезде болатыны
• қандай СУБД және ол қайда орналасатыны (сол серверде ме, бөлек сақтау немесе виртуал машинада)
• фондық тапсырмалар, алмасулар, бэкаптар жұмыс уақытында бар ма

Мысал: кеңседе 60 қызметкер бар, бірақ 1С-те бір уақытта 18–25 жұмыс істейді, ал айдың сонында тіркеу мен есептер тоқтап қалады. Мұндайда көбіне жылдам дискілер мен жеткілікті жад маңыздырақ, ал ядролардың максимумы емес.

Процессор: жиілік па, ядро саны ма

1С пен SQL тапсырмалары үшін жиі ядро саны емес, бір ядроның жылдамдығы маңызды. Көп операциялар тізбектей орындалады: құжаттарды тіркеу, кейбір сұраулар, локтар, қосымша логика. Егер ядро баяу болса, жүйе көп ядролы процессорда да «баяулайды».

Әрине, қосымша ядролар қажет: көп қолданушы бір уақытта, бірнеше адам ауыр есептерді қатар іске қосады, фондық тапсырмалар белсенді, серверде бірнеше база бар.

Қайда ядроларға артық төлеу керегі жоқтығын қарапайым түрде түсіну: жұмыс уақытындағы CPU пиктерін қараңыз. Егер ауыр сәттерде жүктеме сирек 30–40%-дан асады, ал жылдамдық жөнінде шағымдар бар болса, себеп әдетте дискілер, жад, бір ядро өнімділігі немесе баптауларда. Керісінше, егер жүктеме 80–90% ұстап тұрса және тапсырмалар кезегі өсіп жатса, ядролар шынымен жетіспейді.

Рөлдерді қайда орналастыратынын алдын ала шешу пайдалы. 1С сервері, дерекқор сервері және терминалдық сервер қажет болмаса бір жерге жинауға болмайды: әр рөл CPU-ды өзінеше «жейді» және бір-біріне кедергі келтіруі мүмкін.

CPU-ға сақтық үшін:

• типтік пикте шамамен 20–30% бос қуат қалдырыңыз
• маусымдық жүктемені ескеріңіз (айды жабу, тоқсандық есеп)
• жаңа базалар, интеграциялар немесе есептер жоспарланса, қор қалдырыңыз
• ядроларға қосардан бұрын дискілер мен жадты тексеріңіз

Жад: қанша қажет және көлемнен маңыздысы не

RAM тапшылығы жиі «дискідің баяулауына» ұқсайды. Жүйе деректерді swap-қа жиі шығарады, ал 1С пен СУБД оқу/жазбада кідірістерге тап болады. Нәтижесінде жылдам SSD сатып алып та нәтиже көрінбеуі мүмкін, себебі тар орын — жад.

Қарапайым бағдар: RAM-ға қанша дерек сыйса, сервер дискке сирек жүгінеді. 1С пен ERP жадты 1С процессі, СУБД кэші, фондық тапсырмалар (алмасулар, регламенттер), сонымен қатар ОС пен антивирустық тұтынады.

Пайдалы өлшемдер:

• 64 ГБ — кіші кеңсе үшін жиі жеткілікті: бірнеше ондық пайдаланушы және орташа база, «барлық кезең бойынша» ауыр есептер жоқ болса.
• 128 ГБ — пайдаланушылар көп, база тез өссе, регламенттік тапсырмалар мен алмасулар үзіліссіз жүрсе қажет болады.
• 256 ГБ және одан жоғары — ірі база үшін, СУБД кэшінің үлкен көлемі қажет болса, бірнеше ақпараттық база немесе аналитика мен интеграциялар параллель жұмыс істесе justified.

Маңыздысы — тек «қанша» емес, «қалай орнатылғаны». Қазіргі платформа көп арналы жадтан ұтады, сондықтан бірдей модульдерді қоя отырып арналарды симметриялы толтыру жақсы. Әр түрлі көлемдегі және жиіліктегі планкалар өнімділікті жасырып төмендетуі мүмкін.

Өсуге орын қалдырыңыз. 1С үшін жақсы ереже — типтік жұмыста RAM-тың кемінде 20–30% бос қалуы.

Мысал: қазір 40 пайдаланушы және база 150–200 ГБ болса, 64 ГБ «тар» болуы мүмкін. База өсіп, есептер күрделенсе swap пайда болады. 128 ГБ-қа өту көбіне дискілерді жылдамдатудан гөрі үлкен әсер береді.

Дискілер және сақтау: IOPS-та қалай әуестіктен босатпау

1С, ERP және дерекқорлардағы мәселелердің көпшілігі процессордан гөрі дискілік подсистемаға байланысты. Паспорттағы «7000 МБ/с дейін» есептеріне қарағанда кешігуге (latency) және аралас жүктеме кезінде тұрақты IOPS-қа назар аударыңыз. Егер кешігу секірсе, пайдаланушы ұзақ жүргізулер, формалардың тұруы және баяу есептер ретінде сезінеді, тіпті CPU бос тұрып жатса да.

Жұмыс схемасы: сақтау рөлдерін бөлу, сонда операциялар бір-біріне кедергі келтірмейді. Көп таралған бөлу:

• ОС және қызметтік файлдар бөлек томда
• дерекқор файлдары жылдам томда
• журналдар (log) жеке жылдам томда
• бэкаптар бөлек диск немесе массивте; онда IOPS емес көлем маңыздырақ

SATA SSD пен NVMe арасындағы таңдау мағынасы бойынша қарапайым: SATA SSD бағасы/гигабайт маңызды болғанда және жүктеме орташа болса жарайды; NVMe — көп бір уақытта операциялар мен минималды кешігулер маңызды болса қажет. Көбіне аралас шешім ақылды: дерекқор мен лог NVMe-де, ОС пен бэкаптар SATA SSD немесе HDD-да.

RAID тек қана төзімділік үшін емес, сонымен бірге болжамды өнімділік үшін маңызды. RAID 1 диск сәтсіздігінен қорғайды. RAID 10 жазба өнімділігі жоғары әрі сенімді болғандықтан белсенді базалар мен журналдар үшін жиі таңдалады.

Контроллерді ұмытпаңыз: кэш пен дұрыс баптау тұрақты өнімділікті ұстап тұруға көмектеседі, ал кэштің қорғанысы (battery/flash-backed) тоқтағанда деректер жоғалу тәуекелін азайтады.

Желi, резервтеу және қайта құрусыз масштабтау

Егер сервер 1С пен дерекқор деректер орталығында тұрса, ал пайдаланушылар желі арқылы қосылса, тар орын жиі кешігулер болады. 1С үшін кіші кешігулер мен тұрақтылық маңызды: тіпті аз ғана жауап уақытының секірістері «құлап қалу» сияқты сезіледі.

10GbE әрқашан қажет емес. Оны база үлкен, бір уақытта пайдаланушылар көп, басқа жүйелермен белсенді алмасу болса, бэкаптар желі арқылы кетсе немесе желілік сақтау пайдаланылса қолданған жөн. Егер сервер мен дискілер локалдық болса, офис 30–40 пайдаланушыға дейін және ауыр интеграциялар жоқ болса, көбіне 1GbE жеткілікті, бірақ порттар мен апгрейд мүмкіндігін ескеріңіз.

Резервтеуді сіз қанша рет тоқтатуға дайын екеніңіз және қаншалықты жылдам қалпына келу керек екенін анықтаудан бастаңыз. Бэкап — тек көшірме жасау емес, бірнеше қалпына келтіру нүктелері мен қалпына келтірілетініне сенімділік.

Алдын ала тексеріңіз:

• көшірмелер қайда жазылады (бөлек диск, бөлек сервер, желідегі репозиторий)
• қанша сақтау және қандай схема бойынша
• толық және инкременттік бэкаптың қанша уақыт алатынын
• қалпына келтіруді бөлек базада қаншалықты жиі тексеретініңіз

Кейде екі түйін бір үлкен серверден тиімді: SQL-ге бөлек сервер және 1С/терминалдарға бөлек сервер масштабу мен жаңартуды жеңілдетеді.

Өсу жоспарын алдын ала қойыңыз: бос RAM слоттары, диск резерві және екінші желілік интерфейс қосу мүмкіндігі.

Архитектура нұсқалары: бір сервер ме, әлде бірнеше рөл

Бірінші таңдау — барлық рөлдерді бір серверге қою немесе бөлу. Кіші офис үшін көбіне бір сервер жеткілікті: онда қосымша, база және файлдар бірге жүреді. Бұл бастапқыда қарапайым және арзан.

Алайда пайдаланушылар мен база өскен сайын рөлдердің бір-біріне кедергі арқылы жұмыс істеуі басталады: дискілер мен жад бәсекелеседі, ал кез келген қайта жүктеу барлық сервистерге әсер етеді. Егер 1С пен дерекқор критикалық болса, бөлу жиі ұтымды: дерекқорға жеке сервер және қосымша/терминалдарға жеке сервер беру оңай масштабтауға және жаңартуға мүмкіндік береді. Сонымен қатар жаңарту мен қайта жүктеу кезекпен жасала алады.

Виртуализация бар бір сервер ме, әлде бірнеше физикалық

Виртуализация бірнеше рөл керек болғанда, бірақ бөлек машиналар сатып алғыңыз келмегенде ыңғайлы. Артықшылығы — икемділік: ресурстарды қайта бөлу, snapshot және миграция жеңілірек. Кемшін тұсы — ресурстар қоры қажет және мұқият баптау керек, әйтпесе бір VM-нің «шуыл» басқа VM-ге әсер етеді.

Минималды ережелер:

• CPU мен жадта 20–30% қор сақтаңыз
• дерекқорға диск бойынша приоритет беріңіз (жақсырақ бөлек пул немесе том)
• бэкаптар қайда және қалай сақталатынын алдын ала шешіңіз
• виртуалдық ортаға арналған 1С, Windows және СУБД лицензия шектеулерін тексеріңіз

Форм-фактор, сенімділік және жасырын шектеулер

Форм-фактор «әсемдік» себептермен таңдалмауы керек. Рэк (стойка) серверлік бөлмеде және масштабтауда ыңғайлы. Башня сервер кабинет жоқ жерде және шу аз болса жарайды. Компактты шешім орын аз жерде көмектеседі, бірақ салқындатуға талаптары жоғары.

Сенімділікті басынан қалдырыңыз: екі блок питания, горячая смена дискілер, түсінікті вентилятор схемасы. Сондай-ақ тұрмыстық шектеулерді ұмытпаңыз: қуат жеткілікті ме, бөлме жылуға төзімді ме және сервер адамдарға шу жағынан кедергі келтірмейді ме.

1С және дерекқорларға арналған сервер таңдау кезіндегі жиі қателер

Ең қымбат қате — «ең қуатты» процессор сатып алу, ал жүйе дискілерден баяулайтынын түсіну. 1С пен көптеген ERP үшін I/O кешігулері жанында тұрғанда ядроларға қосымша төлеу нәтиже бермейді. Егер база баяу сақтау үстінде тұрса, CPU жиілігін арттыру едәуір әсер етпейді.

Екінші проблема — жадқа үнемдеу. RAM жетіспесе, жүйе swap-қа түседі. Бұл жауап уақытын нашарлатып, «CPU жетімсіз» деген қате әсер қалдырады, шын мәнінде себеп жад.

Тағы бір қате — бәрін бір массивке салу: ОС, база, журналдар, уақытша файлдар және резервтік көшірмелер. Нәтижесінде операциялар бір IOPS базасын бөліседі және пиковте бәрі баяулайды. Дискілерді бөлу немесе кем дегенде әртүрлі томдар — көбіне CPU-ды жаңартудан тиімдірек.

Сонымен қатар бэкаптарды тек «белгі үшін» жасау қауіпті. Қалпына келтіру тексерілмеген көшірме көмектеспейді, әсіресе көшірмелер негізгі массивке жазылса.

Қысқа өзін-өзі тексеру сатып алудан бұрын:

• дискілік жүктемені (IOPS және кешігулер) өлшедіңіз бе, тек CPU емес
• RAM-тың өсуге қорын есептедіңіз бе, swap-қа кірмеу үшін
• базаны, журналдарды және бэкаптарды бір-біріне кедергі келтірмеу үшін бөлдіңіз бе
• тесттік қалпына келтіру жасап, шынайы тоқтату уақытын тіркедіңіз бе
• 6–12 айлық өсу сценарийін ойластырдыңыз ба (не қосамыз және қалай)

Қысқа тексеру тізімі (чек-лист) тапсырыс бермес бұрын

Серверді тапсырыс бермес бұрын талаптарды қағазға түсіріп алыңыз. Бұл пайдаланылмайтын ресурстарға артық төлем төлеуден және бірнеше айдан кейін тар орынға тап болудан сақтайды.

Бес пункт бойынша спецификацияны тексеріңіз:

• CPU және нақты жүктеме. 1С және көптеген ERP үшін жоғары жиілік пен жылдам ядролар маңызды. Пик үшін қор қалдырыңыз, «екі есе көп» деп артық қоспаңыз.
• Жад және 1–3 жылдық өсім. Ағымдағы деректер көлемін және СУБД мен кэштің қанша жадты пайдаланатынын бағалаңыз. Өсуге қор қалдырыңыз.
• Дискілер және том схемасы. Дерек пен журналдарды бөлек томдарға орналастырыңыз, RAID-ты жүктемеге сәйкестендіріңіз және сақтау тұрақты IOPS пен төмен кешігу беретініне көз жеткізіңіз.
• Желі және кешігулер. Пайдаланушылар қайда орналасатынын және серверге дейінгі кешігуді анықтаңыз. Кейде желіні баптау CPU-ды жаңартудан жылдам нәтиже береді.
• Сенімділік және қалпына келтіру. Екі блок питания, мониторинг, түсінікті бэкап жоспары және қалпына келтіруді тұрақты тексеру.

Мысал: орташа офис үшін конфигурация таңдау

Сценарий: 60 пайдаланушы 1С пен ERP-де бір база арқылы жұмыс істейді. Күнделікті жағдайлар тұрақты, бірақ айдың соңында ай жабу, есептер және массалы қайта жүргізулер салдарынан шыңдар пайда болады. Мақсат — шыңдарды ұстап тұру, күнделікті жұмыстарда ядролардың бос қалуын болдырмау.

Темір таңдамас бұрын кем дегенде аптаға метрикалар жинаңыз (оның ішінде бір жүктелген күн). Орташа мәндер емес, шын мәніндегі пиктерді қараң:

• CPU жүктемесі по ядрам және жиілік (1–2 ағында шектелесіз бе)
• қолданылып жатқан RAM және swap бар ма
• диск кезегі және оқу/жазба кешігістері (latency)
• типтік 1С операцияларының орындалу уақыты
• база көлемі және өсу жылдамдығы, журналдар мен уақытша файлдар көлемі

Балансталған конфигурация жиі былай болады: жоғары жиілікке және орташа ядролар санына басымдық беретін процессор (8–12 жылдам ядро 24 «баяу» ядродан жиі пайдалы), 128 ГБ RAM және жылдам дискілер. Базаны NVMe SSD-те орналастырып, журналдарды бөлек томға шығару — жазбалардың оқуға кедергі келтірмеуі үшін маңызды. Бэкаптар мен архивтер үшін бөлек массив немесе қарапайым дискілер қолданылады.

Құрамның артық емес екенін қалай түсінуге болады: пикте CPU тұрақты «шылым шегіп» тұрмайды, диск кезегі тұрақты емес, RAM таусылмайды және swap пайда болмайды. Егер CPU төмен, бірақ жүйе баяу болса, жиі себеп — дискілер, дерекқор локтары немесе рөлдердің қақтығысы.

Өсу кезінде жетілдіру жоспары: алдымен дискілік подсистеманы реттеу, кейін RAM қосу және тек содан кейін CPU туралы ойлану. Қолданушылар саны едәуір өскенде рөлдерді бөлу (дерекқор бөлек, терминалдар бөлек) өмірді жеңілдетеді.

Келесі қадамдар: конфигурация мен бюджетті келісу

Серверді келісу көбінесе «темірде» емес, күтілетін қызмет деңгейінде үзіледі. Алдымен қысқа құжатта талаптарды бекітіңіз: серверде қандай рөлдер (1С, SQL, терминалдар, файл сервисі), 1–2 жылда база мен қолданушылар өсуі қандай, бэкаптар қашан жүргізіледі және тоқтату қаншалықты маңызды.

Шекараларды келісу пайдалы: мысалы «жылына 2 сағаттан артық тоқтату жоқ» және «түнгі бэкапқа 3 сағат терезе». Бұл екі фраза дискілерге, резервтеу және қолдауға тікелей әсер етеді.

Содан кейін 2–3 конфигурация сұраңыз және әрқайсысына не үшін төлеп жатқаныңызды түсіндіріп беруді талап етіңіз. Тек сатып алу бағасын ғана емес, иемдену құнын салыстырыңыз: өсуге қор, энергия тұтыну, қызмет көрсету, қолдау.

Талқылауды пәнді ету үшін әрқашан:

• нақты тар орынды (CPU, жад немесе дискі) анықтап, нені жақсартатыныңызды көрсетіңіз
• базалық нұсқа мен «плюс/минус» нұсқаларды таңдап, компромисстерді белгілеңіз
• мониторинг пен сапалы қолдауды қалай ұйымдастыратыныңызды алдын ала шешіңіз
• жеткізу мерзімдері, сервис және аймағыңызда запчастьтардың бар-жоғын тексеріңіз
• өсу жоспарын құжаттаңыз: бір жылдан кейін не қосасыз (RAM, дискі, екінші сервер) және оны тоқтатусыз қалай жасауға болатынын көрсетіңіз

Егер сіз Қазақстанда болсаңыз және жергілікті жеткізу мен қызмет маңызды болса, өндірушімен және интегратормен конфигурацияны талқылауға мән беріңіз. Мысалы, GSE.kz серверлер өндіреді және жүйелік интеграциямен айналысады — сол арқылы қажетті жүктеме профиліне сай шешімді құрастырып, қолдауды алдын ала жоспарлауға болады.