Электрондық құжат айналымы жүйесі үшін сервер: RAM пен дискке қажетті резерв

Өтініш: СЭД өнімділігімен байланысты мәселе қайдан басталады

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

Неліктен алғашқы айларда бәрі қалыпты жұмыс істейді де, кейін жүйе «плывет» болады? Бастапқыда құжаттар аз, индекстер кішкентай, жұмыс деректері кэшке сыйып жатады. Уақыт өте архив өседі, карточкалар мен байланыстырулар көбейеді, құқықтар мен келісім маршруттары күрделенеді. Сервер «паспорттық» сипаттамаларымен емес, нақты тар жерлерімен шектеледі: диск кідірістері, кэшке арналған RAM жетіспеушілігі, индексация кезектері.

Сандық сипаттамаларға емес, нақты уақыт жоғалатын жерді көрсететін метрикаларға назар аудару керек. Ең пайдалысы:

• p95 немесе p99 жауап уақыты (орташа мән мәселені жасыруы мүмкін)
• диск latency және жазу/оқу кезектері
• RAM пайдалану және своптың бар-жоғы
• IOPS және сақтау жүйесінің өткізу қабілеті пике уақытында
• фондық тапсырмалар (индексация, бэкаптар, регламентті есептер) және олардың іске қосылу уақыты

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

Практикада жиі мынадай көрініс болады: CPU әлі «бос», бірақ дискілер бір уақытта іздеу, карточкаларды ашу және жаңа құжаттарды жазуды қамтамасыз ете алмайды. Сол себепті СЭД уақытта-уақытта күрт баяулайды.

Есептеуге дейін қандай бастапқы мәліметтер жинау керек

Дәл есептеу сервер таңдауынан емес, нақты цифрлардан басталады. «Бізде шамамен 500 пайдаланушы» дегенге сүйене отырып бағалау жасағанда жиі ауытқу болады: CPU мен RAM шамадан тыс, ал дисктер жетпейді, немесе орын көп, бірақ іздеу баяу.

Алдымен жалпы есептік жазбалар саны мен нақты бір уақытта байқалатын параллель жүктеменің арасындағы айырмашылықты анықтаңыз. СЭД үшін маңыздысы — компаниядағы адамдар саны емес, пик уақыттағы бір уақытта жүйемен жұмыс істеп тұрғандар саны (мысалы, таңертең және дедлайн алдында). Сондай-ақ «ауыр» рөлдердің үлесін түсіну пайдалы: қызметкерлер, архив, бухгалтерия, заң бөлімі — оларда көбіне операциялар мен тіркемелер көбірек.

Келесі — құжаттар туралы мәлімет жинаңыз. Маңыздысы — тек файлдар ғана емес, тіркемелер: скан, PDF, кестелер, хат-хабарлар. Жылына қанша құжат жасалатынын және тіркеме орташа өлшемін анықтаңыз. Орташа өлшем белгісіз болса, соңғы 200–500 құжат бойынша таңдап, орташа және 90-шы процентильді есептеңіз. «Ауыр хвост» көбіне диск өсімін анықтайды.

Минималды қажетті деректер:

• пиктегі бір уақытта белсенді сессиялар саны және пайдаланушылардың типтік әрекеттері
• құжаттар мен тіркемелер өсімі жылына, өлшемдердің таралуымен
• сақтау мерзімі және ережелер: не жойылады, не архивке кетеді, не 5–10 жыл сақталады
• қандай операциялар жылдам болуы тиіс: іздеу, келісім, жаппай жүктеу/экспорт
• қолжетімділік талаптары: техникалық тоқтау қабылдана ма және ең ұзақ қандай тоқтаулар бола алады

Архивтеу туралы бөлек келісіңіз. Егер құжаттар 10 жыл сақталса, дисктер бір жылға емес, толық циклге және жыл сайынғы өсімге қарай есептеледі. Сонымен қатар архивті толық индексдеу керек пе, әлде ескі деректерді толық мәтіндік іздеусіз тез ашуға жеткілікті ме — соны шешіңіз.

Ақырында, қолжетімділік туралы келісіңіз. Егер тоқтау қабылданбайтын болса (мемлекеттік орган, банк, ірі клиника), есептеу бірден өзгереді: ресурстарға қосымша резерв, бэкаптарға орын және ақау сценарийлері қажет. Бұл сервер таңдауға тікелей әсер етеді.

Жад: қанша RAM керек екенін қалай түсінуге болады және қайда запас қою керек

СЭД-та RAM тек «өз жүйеге» ғана жұмсалмайды. Жад бірнеше қабатқа кетеді: операциялық жүйе, дерекқор, қосымша (пайдаланушылар сессиялары, тапсырма кезектері, кэш), сондай-ақ іздеу мен индексация (индекс кэші, қызмет процестері). Сондықтан «алғашында бәрі ұшып тұр» деген сезім база мен индекс өсіп жатқанда тез баяулауға ауысады.

RAM жетіспеген кезде тек жылдамдық қана азаймайды. Жүйе жиі дискіге жүгінеді, кешігулер өседі, фондық тапсырмалар кезекте жиналады. Пикте таймауттар, қосымша қателері және сервис перезапустары байқалады. СЭД-та бұл жаппай құжат жүктеу, келісімдер және таңертеңгі логиндер кезінде айқын көрінеді.

СЭД үшін оперативті жадты бағалау практикалық тәсілі — тұтынуды рөлдерге бөлу және өсімді ескеру:

• ОС және қызметтік үдерістер: әдетте 4–8 ГБ (Windows Server-та жиірек көбірек)
• СУБД: негізгі тұтынушы (деректер кэші және сұраныс жоспарлары)
• СЭД қосымшасы: сессиялар, кэш, фондық өңдеулер, файл конвертациясы
• іздеу және индексатор: индекстер мен кэшке қажетті жад, ол құжат саны мен өрістер саны өскен сайын өседі

RAM-ға резерв кэштің тұрақты жұмыс істеуі үшін қажет, ол минут сайын қайта тазартылып отыруға тиіс емес. Продакшнда жиі 20–30% бос жад қалдыру пайдалы және RAM орташа жүктеме 80–90% жетпей тұрып есепті қайта қарау керек.

Мысал: қазір 200 пайдаланушы және 2 млн құжат, бір жылдан кейін 400 пайдаланушы және 4–5 млн құжат жоспарланады. Тіпті бір уақытта жұмыс істейтіндер саны тез өзгере қоймаса да, база мен индекс шамамен екі есеге өседі. Демек СУБД мен іздеуге жад та көбейеді. Құжаттар бойынша өсу адамдар бойынша өсуден бөлек есептелуі тиіс.

Вертикальды масштабтау (RAM пен CPU-ны көбейту) бір серверде кэшке қысымды азайтуға жылдам шешім. Рөлдерді бөлу пайдалы болғанда: база жадты «жеп қояды», индексатор өзіне алады, ал қосымшаға тұрақтылық жетпейді — сонда дерекқор мен іздеу үшін бөлек түйіндер қалыпты жұмыс береді.

Дискілер: СЭД-та диск үнемі неге өседі

СЭД үшін серверді таңдағанда жиі тек файлдар папкасын ғана есептейді. Бірақ СЭД-та бірнеше дерек қабаттары өседі, олар күтпеген жерден орын алады.

Біріншісі — құжаттар мен тіркемелер. Олардың саны ғана емес, орташа өлшемі де маңызды. Қызметкерлер жеңіл PDF-тен жоғары сапалы сканға немесе фото/видео қосуға өткенде орташа өлшем 2–3 есе өсуі мүмкін, тіпті құжат саны өзгермесе де.

Екінші қабат — дерекқор. Онда карточкалар, келісім маршруттары, құқықтар, статустар, метадеректер, сонымен қатар журналдар мен уақытша файлдар тұрады. Логтар мен temp файлдар секірумен өседі: жаппай құжат жүктеу, кезең жабу, есептер, жаңартулар.

Үшінші — іздеу индекстері. OCR қосылғанда және барлық мәтін индекселсе, индекс құжаттардың өз көлеміне тең болуы мүмкін, әсіресе көптеген скандар болғанда.

Төртінші — резервтік көшірмелер. Орын қажет тек «кейін» ғана емес, үнемі: толық бэкап, инкрементті тізбек, кейде тестілеу үшін қалпына келтіру. Егер бэкаптар сол сақтау жүйесінде тұрса, тағы да орынды көбірек қарастыру қажет.

Жазу/оқу қателерінен қорықпау үшін жұмыс бөлімдері 70–80%-дан асырмау керек. Тексеріңіз:

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

Егер бұл зоналарды алдын-ала әртүрлі дискіге бөлсеңіз, өсімді бақылау оңай болады және «орын бар, бірақ критикалық бөлім толып кетті» деген жағдай болмайды.

Жинағыштар түрлері және RAID: қалай қателеспеуге болады

Тіпті көлем бойынша мінсіз есептелген сервер де дискілік подсистема дұрыс таңдалмаса баяулай береді. СЭД үшін жиі маңыздысы — кішкентай операциялардың жылдамдығы: диск пулдарының секундына қанша сұранысты (IOPS) өңдейтіні және олардың кідірісі. Бұл карточкаларды ашуға, тіркемелерді сақтауға және жылдам іздеуге тікелей әсер етеді.

SSD пен HDD-ті міндеттерге қарай бөліңіз. SSD-ті көп кездейсоқ оқу/жазу қажет болатын жерге қойыңыз: дерекқор, журналдар, уақытша файлдар, іздеу индекстері. HDD архив пен сирек ашылатын тіркемелер үшін қолайлы, егер оларға жиі қатынау болмаса.

Практикалық үлгі:

• ОС пен қызметтік рөлдер — бөлек шағын SSD массив
• СЭД дерекқоры — төмен latency-ге басымдық берілген SSD
• іздеу индекстері — бөлек SSD (индексация дерекқорға кедергі жасамасын деп)
• тіркемелер мен архив — HDD массив (немесе SSD, егер ескі құжаттар жиі ашылса)
• резервтік көшірмелер — жұмыс деректерінен бөлек сақтау

RAID тек сенімділік үшін емес, диск істен шыққанда жұмыстың болжамды деңгейін сақтау үшін керек:

• RAID 1 — шағын көлемдер үшін қарапайым айна
• RAID 10 — көбіне БД мен индекстер үшін ең жақсы таңдау, бірақ көп диск талап етеді
• RAID 5/6 — көлем бойынша үнемді, файлдар мен архивтер үшін жарайды, бірақ интенсивті жазуды нашар көтереді

Индексация сценарийлерін бөлек тексеріңіз. Жаппай жүктеу немесе индекстерді қайта құру күндерінде дискіге үлкен жүктеме түседі. Егер индекстер БД немесе тіркемелермен бірге болса, бүкіл жүйеде «просадка» басталады.

Индексация мен іздеу: жүктеме мен өсімді жеке есептеңіз

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

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

Жоспарлы индексацияны түнгі немесе демалыс күндері қою ыңғайлы, бірақ сол уақытқа арнайы ресурс запасын қарастырады. Фондық индексация жүктемені уақыт бойынша таратады, бірақ тұрақты түрде диск, RAM және CPU-ден бір бөлігін «жеп» отырады және кейде пике уақытында іздеуді әлсіретуі мүмкін.

Индекстің өсуін бағалау үшін тек файл санына қарамай, мазмұнға назар аударыңыз:

• құжаттың орташа өлшемі және «ауыр» форматтардың үлесі (скан, күрделі PDF)
• OCR қосылған құжаттар пайызы
• карточкада қанша өріс индекселінеді және толық мәтіндік іздеу бар ма
• бір құжатқа қанша нұсқа мен тіркесім бар
• күн сайын қанша құжат қосылады және қанша рет өзгереді (бұлар да қайта индексация)

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

Индексация көбіне қайда «ұғырылады»: диск (көп кішкентай оқу/жазу), RAM (кэш пен буферлер), CPU (парсинг, OCR). Егер диск баяу болса, индексация созылып, барлығына кедергі келтіреді. Егер RAM аз болса, своп басталып іздеу кенет баяулайды. CPU әлсіз болса, индексация баяулайды, бірақ OCR және үлкен көлемдегі өңдеуде бұл жиірек байқалады.

RAM пен дискілерге запасты кезең-кезеңмен есептеу

СЭД-ке арналған сервер алты айдан кейін ресурстарға тіреліп қалмасын десеңіз, ағымдағы жүктеме мен өсімді есептеңіз.

1. Белсенді пайдаланушыларды анықтаңыз. Күнделікті СЭД-ті қолданатындардың орташа санын алып, келесі 2–3 жылға болжам қосыңыз (мысалы, жылына +10–20% немесе филиалдар есебінен өсу). Триггер ретінде базалық және «пиктік ай» сценарийларын есептеңіз.

2. Құжаттар мен тіркемелер өсімін есептеңіз. Құжаттар санымен қатар орташа тіркеме өлшемін ескеріңіз. Оңай формула: айдағы құжаттар саны x орташа тіркеме өлшемі x «жылдам» архив сақтау мерзімі (мысалы, 12–18 ай жылдам дискілерде).

3. Дискілерді категорияларға бөліңіз. Орындауды төртке бөлу ыңғайлы: дерекқор, файлдар, іздеу индекстері, бэкаптар. Мысалы: 200 ГБ БД, 2 ТБ файлдар, 300 ГБ индекстер, плюс 2–3 толық бэкап (саясатыңызға байланысты).

4. Әр бөлік үшін дискі түрі мен RAID таңдаңыз. БД мен индекске жоғары IOPS пен төмен latency қажет, сондықтан SSD және «жылдам» RAID сәйкес келеді. Файлдар архиві үлкен көлемді болса HDD-те болуы мүмкін, егер оларға жиі қатынау болмаса.

Осыдан соң запас қосыңыз. Практикада дискілерге 30–50% запас, ал RAM үшін кэш пен фондық тапсырмаларға 20–40% запас қалдырады.

Апгрейд қажет екенін анықтайтын триггерлер:

• БД немесе индекс томында 20%-дан аз бос орын қалғанда
• индекстер құжаттардан жылдам өсіп кетсе (жаңа файл түрлері немесе жиі переиндексация белгісі)
• жадтың тұрақты жоғары жүктемесі және жиі свопқа кету
• іздеу мен карточкаларды ашу уақыты аптадан аптаға тұрақты өсіп жатса

Сервер таңдау кезінде жиі кездесетін қателіктер

Негізгі қателік — «қай жерге запас қоюды» түсінбей тек жалпылама резерв қалдыру. Нәтижесінде жаңа сервер алынса да, пайдаланушылар іздеу мен карточкалар ашуда баяулау туралы шағымдарын жалғастыра береді.

Көп кездесетін қателік — пайдаланушылар санын компания штатымен шатастыру. Маңыздысы — бір уақытта СЭД-пен жұмыс істейтіндер саны. Жалпы штатқа сүйенсеңіз артық төленіп қалуыңыз мүмкін. Егер күндік орташа арқылы бағаласаңыз, пиковтарды ескермей қаласыз.

Дискілер мен сақтау бойынша қателіктер

Көптері тек файлдарға орын қарастырып, жанындағы өсімді — іздеу индекстері, құжат нұсқалары, журналдар, уақытша файлдар және бэкаптар — ұмытады. Тағы бір қате — БД, индекстер мен файлдарды бір баяу массивке қою: онда бәрі бірдей дискті «жеп», кез келген ауыр операция барлығын тежейді.

Дискілерді 80–85% дейін толтыру қауіпті. Сол шегінен кейін индексация, жаңартулар мен техникалық қызмет көрсету қиындатады; өнімділік пен қаталар тәуекелі өседі.

Көрінбейтін жылдамдық «жейтіндер"

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

Сатып алудан бұрын өзіңізге қысқаша тексеру:

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

Жеткізу және іске қосу алдындағы жылдам чек-лист

Сатып алудан бұрын ресурстар қазір жеткілікті ме ғана емес, өсімге, индексация мен пик уақытына қаншалықты запас бар екенін тексеріңіз.

Тапсырыс пен іске қосу жоспарына не енгізу керек:

• RAM: жұмыс сағаттарында своп тұрақты түрде қолданылмасын, пиктерде де бос жад сақталсын
• Дискілер: сақтау көлемі белгіленген шегінен төмен болсын (әдетте 70–80%), сол арқылы жылдамдық төмендеу мен бэкап уақыттары ұзармайды
• Бэкаптар: көшірмелер таңдалған сақтау схемасына сай сыяды, және бір типтік қалпына келтіру қадамы мен уақыты тексерілген
• Индексация мен іздеу: индексация бөлінген терезеге сыйсын және пайдаланушылардың карточкалар ашуы мен іздеу уақытын ұзартпағаны тексерілсін
• Мониторинг: 3–5 метрика таңдалып, жауапты тағайындалсын (диск жүктемесі, бос RAM, своп бар-жоғы, диск latency, СЭД жауап уақыты немесе индексация кезегі ұзындығы)

Іске қосар алдында қысқа тест жасаңыз: типтік күнді имитациялаңыз (пайдаланушылардың кіруі, құжат жүктеу, іздеу, келісім), параллель түрде индексацияны қосып, метрикалардың нашарламайтынын бақылаңыз.

Нағыз сценарий бойынша қарапайым есептеу мысалы

Мысалы, мемлекеттік орган немесе банк. Қазір 600 белсенді пайдаланушы, 3 жылда 900 план. Кіріс және ішкі құжат ағымы штатпен бірге өседі, сондықтан есепте запас қалдырамыз.

Шығу деректері: айына 80 000 құжат, орташа тіркеме 1,5 МБ. «Ыстық» кезеңде деректер 36 ай бойы қолжетімді болып сақталады.

Сақтау есебі: 80 000 x 1,5 МБ = 120 000 МБ ~ айына 117 ГБ. 36 айға: 117 x 36 ≈ 4,2 ТБ тек тіркемелерге.

Бірақ СЭД-та тек файл ғана өсіп жатқан жоқ. Қосыңыз:

• метадеректер, нұсқалар, қызметтік өрістер мен журналдар: +30%
• іздеу индекстері: көбіне мәтін мен метадеректер көлемінің 10–20%-ы шамасында, біз +15% аламыз
• өсім мен шиеленіске резерв: кем дегенде +30%

Нәтиже: 4,2 ТБ x (1 + 0,30 + 0,15) ≈ 6,1 ТБ. Қосымша +30% запаспен шамамен 8 ТБ пайдалы сыйымдылық қажет. Одан кейін RAID коэффициентіне қарай «шикі» сыйымдылықты көбейтіңіз (мысалы RAID6 үшін көбірек диск қажет).

SSD қайда керек: СЭД дерекқоры, транзакциялық журналдар және іздеу индексі SSD-де болғаны жақсы — жауап тұрақты әрі мерзімді тоқталулар азаяды. Архивтік тіркемелер сирек ашылатын болса, оларды үлкен HDD-да ұстауға болады.

RAM бойынша: егер қазір жүйе сенімді 64 ГБ-та жұмыс істесе, пайдаланушылар мен индексация өсуін ескеріп 128 ГБ жоспарлау және 20–30% запас ұстау ақылға қонымды. Бұл жоспардан тыс апгрейд пен тоқтаудан арзан болуы мүмкін.

Келесі қадамдар: есептеуді бекітіп, әзірлеуге көшу

RAM пен дискіге есеп шыққан соң, оны мұқият бекітіңіз, сонда жарты жылдан кейін ешкім «неден шықты?» деп сұрамайды. Енгізу деректерін қарапайым шаблонға түсіріңіз: қазір және 12–24 айда белсенді пайдаланушылар саны, күн сайын қосылатын құжаттар, орташа тіркеме өлшемі, архив сақтау мерзімі, қызметке рұқсат етілген техникалық терезелер. Өсу горизонты мен талаптарды СЭД иесі мен қауіпсіздік бөлімімен келісіңіз.

Содан кейін ақауға төзімділік талаптарын тексеріңіз. Егер тоқтау қабылданбаса, бір машина жеткіліксіз. Алдын ала шешіңіз: рөлдер бөлінетін бе (қосымша, БД, іздеу) немесе кластер, және диск/түйін/платформа ақауы болғанда не істеледі.

Іс-қимыл жоспары қысқа және тексерілетін түрде болуы тиіс:

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

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

Егер жеткізуші керек болса, «барлық жабдықты сатушы» емес, нақты пик пен өсуге қарай конфигурация жинай алатын компания қажет. Қазақстанда жиі қаралатын провайдер — GSE.kz (GSE) локалды өндірушілер мен жүйелік интеграторлар қатарында, S200 Series сервер желісі мен 24/7 қолдауды ұсынады.