Бейнебақылау сервері (VMS): сақтау мен жүктемені есептеу

Серверді сатып алардан бұрын сақтау мен жүктемені не үшін есептеу керек

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

Басты қате — тек камералар саны мен диск сыйымдылығына ғана сүйену. VMS үшін маңыздысы — камералар әр секундта қанша дерек жазады және осы мәліметтерді қанша уақыт сақтау керек. Екі жүйе бірдей 50 камерадан тұруы мүмкін, бірақ жазу жүктемесі мүлде өзгеше: біреуі камераға 2 Мбит/с жазады, екіншісі сапа, FPS немесе күрделі сахнаға байланысты 10 Мбит/с-қа дейін береді.

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

Сатып алудан бұрын серверді үш басты көрсеткішке түсіру жеңіл:

• Мбит/с — жазу кіріс ағымы;
• ТБ — қажетті тереңдікпен архив;
• TB/day — тәуліктік жазба көлемі (дискілерге қаншалықты «ауыр» екені).

Осы көрсеткіштер 1G желісінің жететінін, қандай класс дискілер қажет екенін және нақты пайдалы сыйымдылықты ескере отырып қанша диск кадрлары керек екенін тез көрсетуге көмектеседі.

Алдын ала анықтауға болатын минимум: камералар бойынша орташа және пик битрейт, архив тереңдігі (күндер), жазу режимі (24/7 немесе оқиға бойынша), жалпы кіріс трафигі өсуге резервпен және TB/day дискілік подсистема жүктемесін бағалау үшін.

Мысал ретінде: бүгін 30 камера «орташа сапада» жоспарланып тұр, ал жарты жыл өткен соң тағы 20 қосылады және кейбір нүктелердегі FPS көтеріледі. Сервер сыйымдылықта емес, жазу жылдамдығы мен желіде «тапталуы» мүмкін. Сатып алдындағы есептеу кейінгі шұғыл диск алмастыру, желіні жаңарту және архивті көшіруге қарағанда арзанға түседі.

Камералар мен VMS бойынша қандай бастапқы деректер жинау керек

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

Әр камера үшін паспорттық деректер мен объектідегі нақты баптауды жазыңыз. «Спецификациядағы максимум» пен «жобада жұмыс істейтін мән» арасында айырмашылық болуы мүмкін.

Не жазу керек (бір кесте жеткілікті):

• Шешім (разрешение), FPS, кодек (H.264 немесе H.265) және негізгі кодтау баптаулары;
• Сахна түрі: дала ма, ішкі бөлме ме, көп қозғалыс па, шамдар, қар, жапырақтар және т.б.;
• Битрейт басқаруы: CBR немесе VBR және шектеу (бар болса);
• Жазу режимі: үнемі, қозғалыс бойынша, кесте бойынша, алдын ала және кейінгі жазу (pre/post);
• Нақты қанша ағын қолданылатындығы: жазуға негізгі ағын, «тірі» қарау үшін субпоток, мобильді клиенттер мен видеобекеттерге қосымша ағындар.

CBR желіні жоспарлауда оңай: трафик біркелкі, порттар мен коммутаторларды есептеу жеңілірек. VBR орташа битрейтте жақсы сапа береді, бірақ пиктермен тосынсыйлар әкеледі: түнгі режим, жауын, белсенді сахна немесе жарық жарқылы ағынды қатты көтеруі мүмкін.

Сондай-ақ VMS жазба жасаудан басқа не істейтіні маңызды. Камерадағы қозғалыс детекциясы мен сервердегі детекция — түрлі жүктемелер. Аналитика, тану, қашықтағы қолжетімділік үшін транскодтау, шифрлау, көптеген бір уақытта қараулар CPU/GPU және жадтан көп талап етуі мүмкін.

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

Камера битрейтін қалай есептеп, тексеру керек

Битрейт — камераның нақты секундтық жіберіп және жазып жатқан дерегі. Ол тікелей желіге, дискілерге және архивтің шығындарына әсер етеді. Бұл шешімге тең емес: екі 4 Мп камера әртүрлі ағын беруі мүмкін — кодек, FPS, қысу деңгейі және кадрдағы өзгерістер әсер етеді.

Бастапқы бағалау үшін типтік диапазондар қолданылады және резерв қойылады. Әдетте орташа битрейт алынады, бірақ сатып алу пик бойынша жоспарланады. Әйтпесе VMS желіде немесе жазуда ең қолайсыз сәттерде «тапталады».

15–25 FPS кезінде «қалыпты» суретке ориентирлер:

• 1080p: H.264 2–6 Мбит/с, H.265 1–4 Мбит/с
• 4 Мп: H.264 4–10 Мбит/с, H.265 2–7 Мбит/с
• 4K: H.264 8–20 Мбит/с, H.265 4–14 Мбит/с

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

Ең сенімді әдіс — нақты битрейтті тест арқылы өлшеу. 15–30 минут типтік шарттарда және бөлек ең нашар жағдайда жазып, файл өлшемінен нақты Мбит/с-ті есептеңіз.

Практикалық тексеру:

• Жобадағыдай кодек, шешім және FPS қойыңыз;
• 15–30 минут тесттік үзінді жазыңыз;
• Файл өлшемін жазу уақытына бөліп, Мбит/с-ке аударыңыз;
• «Күрделі» сахна үшін қайталаңыз.

Substream-ті бөлек ескеріңіз. Оны әдетте жеңіл жасайды (мысалы, күзет постындағы камералар торы үшін), сондықтан қарау арнасын және декодтауды ауыртпайды. Архив есептеуде көбінесе негізгі ағын есепке алынады, ал substream мониторинг пен қашықтан қарауда маңызды.

Архив көлемін есептеу: сақтау тереңдігі және нақты пайдалы сыйымдылық

Бейнебақылау архивінің көлемі қарапайым: орташа битрейт x жазу уақыты x камера саны. Негізгі мәселе — өлшем бірліктерін шатастырмау, әйтпесе бірнеше терабайтқа қателесу оңай.

Негізгі логика: Мбит/с-ті МБ/с-ке аударыңыз (8-ге бөліңіз), содан соң секундқа көбейтіңіз. Жаттығу үшін қолайлы ереже: 1 Мбит/с шамамен тәулігіне 10,8 ГБ береді.

Жай мысал: 20 камера, әрқайсысы 4 Мбит/с, 24/7 жазу, 30 күн сақтау.

• Бір камера: 4 x 10,8 = 43,2 ГБ/тәулік.
• 30 күн: 43,2 x 30 = 1296 ГБ ≈ 1,3 ТБ камераға.
• 20 камераға: шамамен 25,9 ТБ.

Одан кейін қағаздағы «архив тереңдігі» мен дискіңіздің нақты қанша толатыны арасында айырмашылық басталады. Әдетте ескеріңіз:

• Файл жүйесінің және VMS-тің қызметтік шығындары (көбіне 5–15%);
• Битрейт пиктеріне резерв (түн, қар, жауын, шу);
• Өсуге резерв (жаңа камералар, жоғары FPS, жоғары шешім).

Егер жазу қозғалыс бойынша болса, 24/7 формуласына көбейтпеңіз. Белсенділікті пайызбен қойыңыз. Мысалы, 25% белсенділік камераның орташа есеппен тәулігіне 6 сағат жазатынын білдіреді. Тест немесе пилотпен расталған мәнді қолданған жөн.

Практикалық минимум — есепке 20–30% қосымша сыйымдылық қою. Бұл бірнеше айдан кейін бірнеше камера қосылғанда немесе сапа өсірілгенде архив тез толып кетуінен қорғайды.

Тұрақты жазба үшін дискілер мен RAID талаптары

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

Көбінесе архив HDD-ге жасалады: олар 1 ТБ үшін арзанырақ және ұзақ уақыттық үздіксіз жазбаға жақсы келеді. SSD көбіне жүйелік диск, VMS дерекқоры, индекстер, кэш және уақытша файлдар үшін пайдалы — бұл іздеуді және таймлайнды жылжытуды жылдамдатады, бірақ тұрақты жазба үшін дұрыс таңдалған HDD-ты алмастырмайды.

Видеожазба үшін қандай RAID жиі қолайлы

RAID таңдауы — сыйымдылық, тұрақтылық және диск қалпына келтіру жылдамдығы арасындағы теңгерім.

• RAID 5 сыйымдылықты үнемдейді, бірақ бір диск қана істен шыққанда ғана сақтайды. Үлкен HDD және ұзақ rebuild кезінде тәуекел жоғары.
• RAID 6 екі диск істен шыққанда сақтайды. Көп дискілері бар архивтер үшін жиі әлдеқайда сенімді таңдау.
• RAID 10 жоғары жылдамдықты және тез қалпына келуді береді, бірақ сыйымдылықтың жартысын «жояды».

32–64 камералы және кеңею жоспары бар жүйелер үшін RAID 6 немесе RAID 10 әдетте RAID 5-пен салыстырғанда азырақ тосынсыйлар береді.

Rebuild: басты қауіп қайда жасырынады

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

Алдын ала ойластыруға пайдалы нәрселер: hot spare (жүйе дереу қалпына келтіруді бастау үшін), SMART және хабарландырулар, дискіні жоспарлы ауыстыру стратегиясы, SSD — ОС пен VMS базасы үшін, архив үшін бөлек массив.

Егер архивке серверлік платформа жинасаңыз, корзиналар санын, контроллерді және диск резервін алдын ала жоспарлау дұрыс: GSE S200 деңгейіндегі стойкалық платформаларда бұл әдетте конфигурация сатысында шешіледі, сондықтан архив кеңеюі жазбаға қауіп тудырмасын.

IP-камералар үшін желі: трафикті қалай бағалап, 1G-ге «тапталмау»

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

Практикалық ереже: кіріс ағымы = камералардың битрейттері сомасы + 10–20% запас. Пиктер жауын, қар, адам көп болуы, күннен түнге ауысуда және VMS буферден қысқаша жазу кезінде пайда болады.

1G және 10G порттар: қашан қайсысын қажет ету

1G порт шамамен 900–940 Мбит/с пайдалы өткізу қабілетін береді. Мысалы, 80 камера × 8 Мбит/с = 640 Мбит/с тек жазу үшін. Қосымша резерв, қызметтік трафик және қашықтан қарауларды қоссаңыз, шекара оңай бұзылады.

Егер есеп 1G-тің 70–80% шамасына жақындаса, 10G немесе интерфейстерді бөлу (мысалы, бір порт — камералар, екіншісі — қолданушылар мен архив экспорты) қойыңыз. Кейін «бұзылған» видеоны «емдеуден» гөрі алдын ала шешім оңайырақ.

VLAN және аплинктер: жиі қайдан жылдамдық жоғалады

Камераларға бөлек VLAN желінің кеңейтпелі сигналын оқшаулауға көмектеседі, кездейсоқ циклдер мен қол жеткізу ережелерін жеңілдетеді.

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

Мысалы, күзет бір уақытта 16 камераны 4 Мбит/с-тан қарайтын болса, бұл тағы +64 Мбит/с. Бұл көп емес көрінеді, бірақ 1G-ке «жақын» жұмыс істеген кезде осындай қосымшалар үзіліс пен кадр жоғалтуларын тудырады.

Сервер жүктемесі: CPU, RAM, GPU және VMS функцияларының рөлі

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

CPU-ды камералар өздері емес, VMS-тің видеопотоктармен не істейтіндігі жүктейді. Егер сервер тек H.265 қабылдап, дискіге жазса, CPU жүктемесі қалыпты болуы мүмкін. Бірақ өңдеу қосылса, картина өзгереді.

CPU-ды ең көп жейтіндер: көп декодтау (тірі қарау және видеобекеттер үшін), қашықтан кіру үшін транскодтау, сервердегі аналитика, шифрлау және водяные знаки, база мен индекстерді қызмет көрсету.\n GPU әрдайым қажет емес. Ол көп параллельді жоғары шешімді қарауларда, H.265-ті декодтау ауыр болғанда немесе аналитика GPU-да жұмыс істегенде пайдалы. Егер сервер тек жазумен және сирек бір-екі арнаны қараумен шектелсе, бөлек видеокарта жиі артық болады.

RAM мен жүйелік диск VMS-тің «ішкі жұмысы» үшін маңызды. Дерекқор, журналдар, индекстер, кадр кэші мен сервистерді SSD-де сақтау архивтен бөлек болғаны дұрыс. Егер жүйелік диск баяу немесе логтармен толса, тіпті дұрыс таңдалған архивтік дискілермен де VMS баяулауы мүмкін.

Тағы бір жиі ескерілмейтін нәрсе — қанша клиент бір уақытта қосылатыны. Мысалы, 4 оператор × 16 камера экранда — онда ондаған ағын декодталуы мүмкін. Субпотоктар мен операторларға арналған FPS шектеулерінің орнатылуы жиі «тағы CPU қосуға» қарағанда тиімдірек болады.

Қадам бойынша есептеу: камерадан сервер конфигурациясына дейін

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

Жұмыс тәртібі:

1. Камера параметрлерін және жазу режимін бекітіңіз: рұқсат, FPS, кодек (H.264/H.265), VBR немесе CBR, 24/7 немесе оқиға бойынша жазу, аудио, қарауға екінші ағын.

2. Жалпы битрейтті есептеңіз: барлық камералардың орташа битрейтін қосып, пиктерге 20–30% қосыңыз (VBR үшін әсіресе маңызды).

3. Битрейтті архивке аударыңыз: жалпы ағым (Мбит/с) × тәуліктік уақыт × қажетті күндер. Егер кейбір камералар 24/7 жазбаса, оларды бөлек есептеңіз.

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

5. Желіні тексеріңіз: 1G аплинктар жеткілікті ме, қанша порт қажет, PoE-коммутаторлар қайда, және камералар, сервер мен жұмыс орындар арасындағы тар орындар пайда бола ма.

6. Есептеу ресурстарын бағалаңыз: қарау, транскодтау, серверлік детекция және аналитика CPU/GPU және RAM-ды жүктейді. Егер ондаған бір уақытта қараулар немесе аналитика жоспарланып отырса, процессор мен жадыға резерв керек, ал ауыр аналитика үшін GPU-ны қарастыру орынды.

Мини-сценарий: 40 камера × 6 Мбит/с ≈ 240 Мбит/с, резервпен шамамен 300 Мбит/с. Мұндай жағдайда аплинктер мен дискілік подсистеманы тексеру маңызды — тек ТБ-ны санау жеткіліксіз. Мұндай тапсырмаларға көп диск және тұрақты жазуды қамтамасыз ететін стойкалық серверлер (мысалы, S200 класс) қарайды.

Камераларды масштабтағанда жиі қайталанатын қателіктер

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

Типтік қателіктер:

• Битрейтті спецификациядан алып, түнгі режимді тексермеу. Түнде шу өседі, күшейту қосылады — битрейт күндізгіге қарағанда 1.5–3 есе артуы мүмкін.
• Дискілер сыйымдылығын «жапсырма бойынша» есептеу. RAID, файл жүйесі және VMS қызметтік деректері қолжетімді көлемді азайтады.
• Сақтауды «қатты жететіндей» жоспарлау. Камералар біртіндеп қосылады, FPS немесе шешім арттырылады — резерв ұстамау қауіпті.
• Қашықтан қарау мен архив экспортын жұмыс уақытында есептемеу. Бұл дискілерді оқудан және желіні тұтынудан жазуды әлсіретеді.
• Үлкен дискпен RAID 5-ті артық бағалау. Қалпына келтіру ұзақ жүруі мүмкін және екінші дисктың ақауы тәуекелі өседі.
• Жазу мен ауыр аналитиканы бір серверде бөлетін жоспарлау. Ресурстар бәсекеге түсіп, әсіресе транскодтау және тануда жазба зардап шегеді.

Егер тұрақты жазба да, аналитика да қажет болса, рөлдерді алдын ала бөлу немесе мақсатты конфигурацияда жүктемені тексеру дұрыс.

Қарапайым формулаларсыз сценарийге мысал

Мектеп немесе клиника: 48 IP-камера, дәліздер мен дала нүктелері. Параметрлер: 1080p, 15 FPS, H.265, 24/7 жазу, архив 30 күн. Желіні және дискілерді бағалау керек.

Ол үшін орташа битрейтті аламыз: 1080p/15 FPS/H.265 үшін әдетте 2–4 Мбит/с есептейді. 3 Мбит/с алайық (далада жапырақ, қар және фаралар әсер етуі мүмкін).

Трафик: 48 × 3 = 144 Мбит/с. Мегабайтқа аудару: 144 / 8 = 18 МБ/с тұрақты жазба.

Архив: 18 МБ/с × 86 400 с ≈ 1,55 млн МБ/тәулік ≈ 1,5 ТБ/тәулік. 30 күн — шамамен 45 ТБ «шикі» көлем. 15–25% қызметтік шығындар мен битрейт ауытқуларын қоссаңыз, пайдалы сыйымдылық ретінде шамамен 55 ТБ мақсат еткен дұрыс.

RAID-ты таңдағанда: RAID 6 болса, N дискіден екеуі қорғанысқа кетеді. Мысалы, 10 × 10 ТБ = 100 ТБ «шикі», пайдалы шамамен 80 ТБ (форматтаудан кейін сәл аз). Бұл 30 күнге жақсы резерв береді.

Өсу кезінде не болады:

• 16 камера қосылды (жалпы 64): 64 × 3 = 192 Мбит/с (24 МБ/с), 30 күнге шамамен 60 ТБ без запаса.
• FPS 25-ке көтерілді: битрейт көбейуі 1.5–1.8 есе болуы мүмкін. Егер орташа 5 Мбит/с болса, 48 × 5 = 240 Мбит/с, 30 күнге архив шамамен 75 ТБ болуы ықтимал.

Финалдық таңдау алдында күзет пен ИТ-дан келесі сұрақтарды нақтылау пайдалы: барлық камералар үшін 30 күн ме немесе тек бір бөлігі үшін бе, жазу қатаң 24/7 ме немесе оқиға бойынша ма, аналитика және қосымша ағындар бола ма, қанша бір уақытта қарау, желі архитектурасы мен аплинктер (1G/10G) қалай орналасқан.

Сатып алмас бұрын тексеру тізімі және келесі қадамдар

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

Сатып алудан бұрын тексеру керек:

• Бірнеше камерадан күндіз және түнде нақты битрейт алыңыз (қозғалыс жағдайында міндетті). Түнгі режим, жаңбыр немесе қар битрейтті 1.5–3 есе көбейтуі мүмкін.
• Архив тереңдігін пайдалы сыйымдылық бойынша қайта есептеңіз. RAID, форматтау және резервтер қолжетімді көлемді азайтады.
• Желі мен жазу жылдамдығына пик бойынша резерв қойыңыз. Орташа жүктеме қалыпты болса да, бір уақытта барлық камералар битрейтті көтерсе 1G жетпеуі мүмкін.
• Дискілерді қызмет көрсету жоспарын ойластырыңыз: hot spare, SMART мониторингі, массив деградация сценарийі, диск ауыстыру мерзімі мен тәртібі.
• Қандай VMS функциялары қосылатындығын бекітіңіз (аналитика, сервердегі детекция, транскодтау). Бұл CPU/GPU және RAM-ға тікелей әсер етеді.

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

Одан әрі логика қарапайым: алдымен VMS пен камера талаптары, содан кейін сервер мен дискілер, және тек соңында соңғы баға. Егер 12–24 айда өсу жоспарланған болса, резервті бірден қосып қойыңыз, сонда камераларды қосу төтенше апгрейдке айналмайды.

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