Бейнебақылау қоймасын 60 тәулікке қалай есептейді

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

Бұл есепте әдетте екі рет қателеседі. Алдымен камера санын «Full HD үшін» алынған шартты көлемге көбейтеді, бірақ кіреберіс, автотұрақ және бос дәліз әртүрлі сығылады. Содан кейін RAID, қызметтік кеңістік, бос орын қоры және түнгі битрейт өсімі ескерілмей, шыққан сан массив сыйымдылығы деп аталады. Қағазда дәл 60 тәулік шығады, ал тіркеуіш мұрағатты 43 немесе 51 күннен кейін өшіре бастайды.

Дұрыс есеп үш бөлек нәтиже береді: 60 тәулікте қанша терабайт бейне жиналады, жазу сервері қандай жиынтық және шекті өткізу жолағын қабылдауы керек, барлық шығын мен қордан кейін қанша физикалық сыйымдылық орнату қажет. Бұл сандар өзара байланысты, бірақ бірін-бірі алмастырмайды. Диск мұрағатты сыйғызғанымен, көптеген параллель жазу ағынына шыдамауы мүмкін. Ал желі камераларды күндіз қабылдап, түнгі шу немесе жаппай қозғалыс кезінде пакеттерді жоғалтуы мүмкін.

Мегапиксельден емес, өлшенген битрейттен есептеңіз

Битрейт камераның бір секундта іс жүзінде қанша дерек шығаратынын көрсетеді, сондықтан көлем мен өткізу жолағының есебіне дәл осы көрсеткіш кіреді. 25 кадр/с жиілігі бірдей екі 1920x1080 камерасының орташа ағыны бірнеше есе өзгеше болуы мүмкін: біреуі жарығы тұрақты тыныш қойманы, екіншісі жапырақ, жаңбыр, көлік шамы және адам легін түсіреді.

Битрейтке ажыратымдылық, кадр жиілігі, ысырма жылдамдығы, шу деңгейі, көрініс күрделілігі, кең динамикалық ауқым, кодек, сығу профилі, GOP ұзындығы және ағынды басқару режимі қатар әсер етеді. «2 Мп 2 Мбит/с-қа тең» деген кесте бастапқы бағалауға жарайды, бірақ диск сатып алуға негіз бола алмайды. Ол қорды жеп қоятын ауытқуларды жасырады.

Жобалық тізімде әр камера үшін кемінде екі сан керек: өкілдік кезеңдегі орташа битрейт және байқалған шекті мән. Орташа көрсеткіш сыйымдылыққа, ал шекті мән желіге, контроллерге, диск интерфейстеріне және жазу серверіне қажет. VMS тек ағымдағы жылдамдықты көрсетсе, мәнді кемінде минутына бір рет автоматты түрде алып, тәуліктік қатарды сақтаңыз. Максимуммен бірге 95 немесе 99-процентильді алған дұрыс. Кездейсоқ бір секундтық секіріс бүкіл жүйені анықтамауы керек, бірақ ұзаққа созылған кешкі шекті жүктемені елемеуге болмайды.

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

Өлшем бірлігін тексеретін қарапайым тәсіл бар. Интерфейс 4 Мбит/с көрсетсе, бұл мегабит, ал диск сыйымдылығы байтпен берілген. Сегізге бөлу битті байтқа айналдырады. Осы жердегі қате нәтижені сегіз есе бұрмалайды, мұндайды мұқият рәсімделген спецификациялардан да көрдім.

Бір формула битрейтті, мерзімді және көлемді байланыстырады

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

ГБ/сутки = битрейт_Мбит_с × 86 400 / 8 / 1 000
ТБ/60_суток = битрейт_Мбит_с × 86 400 × 60 / 8 / 1 000 000
ТБ/60_суток = битрейт_Мбит_с × 0,648

Орташа ағыны 4 Мбит/с камера 60 тәулікте шамамен 2,592 ТБ жазады. Осындай он камера 25,92 ТБ бастапқы бейне береді. Бұл әлі массив көлемі емес: мұнда дыбыс, метадерек, файлдық үстеме шығын, RAID және бос орын жоқ.

Камералар әртүрлі болса, алдымен әр топты есептеп, содан кейін нәтижелерді қосады:

V60 = Σ(число_камер_i × средний_битрейт_i × доля_записи_i × 0,648)

Тәулік бойы жазу үшін доля_записи 1-ге тең. Тәулігіне 12 сағаттық кестеде ол 0,5 болады. Оқиға бойынша жазуда бұл VMS негізгі ағынды шынымен жазған уақыттың үлесі, оған оқиға алдындағы және оқиғадан кейінгі жазу да кіреді. 0,2 мәні әр сағаттың тура 20 пайызында қозғалыс болды дегенді білдірмейді, ол орташа тәулікте шамамен 4,8 сағат бейне жазылғанын көрсетеді.

Бастапқы бейнеге басқа дерек ағындарын қосыңыз. 64 Кбит/с дыбыс бір камераның 8 Мбит/с бейнесінің жанында болмашы көрінеді, бірақ жүздеген арна мен ұзақ мерзімде ол бірнеше терабайт алады. Талдау метадерегі, іздеу индексі, оқиға базасы және шағын кескіндер VMS-ке байланысты. Жеткізуші құжатталған норманы бермесе, пилоттан кейін өлшенген пайызды немесе бөлек тұрақты томды қарастырыңыз. Оларды түсініксіз «сенімділік коэффициентінің» ішіне жасырмаңыз.

Мен есепті тексеруге оңай тізбекпен жазамын: бастапқы бейне көлемі, қосымша дерек, сыйымдылық қоры, RAID-тің пайдалы сыйымдылығы, физикалық сыйымдылық. Барлық түзету бір 1,4 коэффициентіне жиналса, жарты жылдан кейін оның құрамын ешкім есіне түсірмейді. Бөлек жолдар бүкіл жобаны қайта болжаусыз, бір ғана болжамды ауыстыруға мүмкіндік береді.

Ажыратымдылық пен кодек тек бастапқы болжам береді

Ажыратымдылық битрейтті тікелей белгілемейді, ал кодек кез келген көріністе бірдей үнем бермейді. H.265 әдетте салыстырмалы кескінді H.264-ке қарағанда төменірек ағынмен жеткізеді, бірақ нәтиже кодердің іске асуына, баптауларға және кадр мазмұнына байланысты. Ескі декодер, мобильді клиент немесе талдау модулі H.265 қолдауын шектеуі мүмкін, сондықтан бүкіл ойнату және экспорт жолын тексермей тұрып үнемді есепке алуға болмайды.

Axis компаниясының AV1 кодегі туралы құжаты пайдалы, бірақ әмбебап емес көріністер жиынын келтіреді. Бір камерадағы қатар сынақтарда AV1 ағыны H.265-ке жақын, ал H.264 жоғары болған. Қаланың күндізгі, түнгі және көлік көріністері арасында айырма да анық байқалған. Бұдан шығатын қорытынды: кодектерді бір құрылғыда, бір көріністе және талап етілетін детализациясы бірдей жағдайда салыстыру керек. Өзгенің ролигіндегі жарнамалық пайызды өз сметаңызға көшіруге болмайды.

Алғашқы тізімде диапазон қолдануға болады, бірақ оның болжам екенін анық белгілеңіз. Мысалы, H.265 қолданатын тыныш 1080p камерасын 15 кадр/с кезінде 1,5-3 Мбит/с, қозғалысы көп 4 Мп камераны 20 кадр/с кезінде 3-6 Мбит/с, ал деталі көп 4K көріністі 12-16 Мбит/с деп бастап бағалауға болады. Бұлар норматив емес. Олар пилотқа дейінгі шаманы ғана көрсетіп, жобаның қай бөлігін мұқият өлшеу керегін түсіндіреді.

Кадр жиілігі де бақылау міндетіне сай болуы керек. Тыныш дәлізге 12-15 кадр/с жиі жеткілікті, ал касса аймағына, жылдам көлікке немесе технологиялық операцияға 25 кадр қажет болуы мүмкін. Диск үнемдеу үшін барлық жерде жиілікті азайту қауіпті: керек әрекет кадрлардың арасында жоғалады. Оператор нені ажыратуы тиіс екенін анықтап, содан кейін сол әрекетті сақтайтын ең төмен жиілікті таңдаңыз.

GOP ұзындығы тиімділікке, іздеуге, пакет жоғалған кездегі әрекетке және экспортқа әсер етеді. Ұзын GOP толық I-кадр үлесін азайтады, бірақ кейінгі кадрлар тірек кадрға ұзағырақ тәуелді болады. Axis нұсқаулығы ағынды төмендету тәсілдерінің бірі ретінде GOP ұзартуды атайды, сонымен бірге өзгерістен кейін бейненің бақылау міндетіне жарамдылығын тексеруді талап етеді. Орташа битрейт әдемі шықты деп ұзын GOP-ты бірден қабылдамас едім. Жазбаны жылжытып көріңіз, үзінді экспорттаңыз және желі қысқа үзілгеннен кейінгі қалпына келуді тексеріңіз.

Түнгі шу күндізгі бағалауды жиі бұзады. Автоматты күшейту қараңғы аймақтарды үнемі өзгеретін түйіршіктерге айналдырады, кодек соны сипаттауға мәжбүр. Дұрыс жарық, ысырма, шуды азайту және маңызы жоқ аймақтарға маска көмектеседі, бірақ әр өзгерісті бет, көлік нөмірі және басқа қажетті деталь бойынша тексеріңіз. 60 тәулік тұрғанымен, тергеу сұрағына жауап бермейтін мұрағат орынды босқа алады.

Үздіксіз және қозғалыс бойынша жазу бөлек есептеледі

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

Оқиға бойынша жазуда адамның кадрда болған уақытын емес, сақталған клиптердің нақты ұзақтығын өлшеңіз. Оқиға алдындағы жазу әр оқиғаның алдына бірнеше секунд қосады, оқиғадан кейінгі жазу әр үзіндіні ұзартады, ал жақын оқиғалар бір үздіксіз файлға бірігуі мүмкін. Оқиғадан кейін 20 секунд жазылатын жағдайда бір минуттағы бес қысқа өту сол минутты тұтас дерлік жазбаға айналдыра алады. Детектордың іске қосылу саны мұны көрсетпейді.

VMS есебін әдеттегі екі аптаға және жүктемесі өзгеше кезеңдерге бөлек алыңыз: оқу жылының басталуы, тауар қабылдау, қар жауу, жарықтың өзгеруі, жөндеу немесе көпшілік іс-шара. Әр камера үшін сақталған үзінділердің жалпы ұзақтығын күнтізбелік уақытқа бөліңіз. Мұрағат бұрыннан жұмыс істесе, бос емес көлемнің тәуліктік өсімін салыстыруға болады, бірақ алдымен томдағы экспортты, қолмен бұғатталған жазбаны және өзге деректерді алып тастаңыз.

Аралас режим көбіне тек қозғалыс бойынша жазудан жақсы. Негізгі ағын оқиға кезінде сақталады, ал битрейті немесе кадр жиілігі төмен ағын үнемі жазылады. Детектор оқиғаның басын өткізіп алса да контекст қалады, әрі орын үнемделеді. Формулада екі бөлікті бөлек есептеңіз:

V = V_фоновый_поток × 100% времени + V_основной_поток × доля событий

Метриканың мағынасын тексермей, көрініске қарай битрейті өзгеретін ағынға белсенділік коэффициентін қолданбаңыз. VBR бос кадрда орташа ағынды өзі төмендетіп, қозғалыс кезінде көтереді. Орташа битрейт толық тәуліктен алынса, онда нақты белсенділік бар. 0,3-ке тағы көбейту камера бұл ағынды VMS-ке үздіксіз жіберіп, ал VMS оны уақыттың 30 пайызында ғана жазған жағдайда дұрыс. Әйтпесе үнем екі рет есептеледі.

Міндетті сақтау мен даулы оқиғалар үшін сыйымдылықты тыныш аптаның ортасымен емес, байқалған ең жоғары жазу үлесімен есептеген дұрыс. Нысан 60 тәулікке кепілдік беруге тиіс болса, сирек кездесетін қарбалас ай мұрағатты қысқартпауы керек. Өшіру саясатын да тексеріңіз: кей VMS бос орын белгілі шекке жеткенде ең ескі бейнені өшіреді, кейбірі камераларға көлем бөледі, ал басқалары белгіленген жазбаны қалыпты циклден тыс ұстайды.

Орташа көлемнен гөрі шекті өткізу жолағы маңызды

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

Жазу серверінің кіріс өткізу жолағы қабылдайтын ағындардың қосындысына тең. Оған қызметтік трафик пен қор қосылады:

B_ingest = Σ(пиковый_битрейт_камеры × число_камер) × 1,2

Мұндағы 1,2 заң емес, ашық көрсетілген 20 пайыздық жобалық қор. Желі бөліктерге бөлінсе, есепті әр uplink, коммутатор және сервердің желілік интерфейсі үшін қайталаңыз. Нысанның жалпы қосындысын алып, әр арна оны автоматты түрде көтереді деп ойлауға болмайды. Қашықтағы ғимараттан келетін бір гигабиттік uplink жиі тар орынға айналады.

Шығыс жолағын бөлек есептеңіз. Бір мезгілде тікелей көру, мұрағатты ойнату, экспорт, репликация және резервтік көшіру серверден дерек оқиды. 16 камералық торды қарап отырған төрт оператор үнемі 64 жаңа ағын жасамайды: VMS қосалқы ағын немесе multicast таратуы мүмкін, ал кейде әр клиентке бөлек unicast ашады. Мұны нақты архитектурадан тексеру керек.

Мегабитпен берілген ағынды сегізге бөліп, дискіге тізбекті жазу жылдамдығына айналдыру ыңғайлы. 600 Мбит/с жиынтық ағын үстеме шығынға дейін шамамен 75 МБ/с болады. Қазіргі массив үшін бұл аз көрінеді, бірақ бейнежазба көптеген бір мезгілдегі ағыннан тұрады, оған қоса оқу, RAID қайта құру, массивті тексеру және экспорт жүреді. Бір бос дискінің паспорттағы ең жоғары жылдамдығы мұндай күйді сипаттамайды.

Axis битрейтті басқару құжатында VBR мен MBR-ді бөледі. VBR күрделі көріністе ағынның өсуіне мүмкіндік беріп, сапаны сақтайды. MBR жоғарғы жылдамдықты шектейді, бірақ қатаң лимит белсенді оқиға кезінде сапаны түсіруі мүмкін. Сондықтан лимитті тек қолжетімді өткізу жолағына қарап таңдамаңыз. Қозғалыс, жаңбыр немесе жасанды шу бар сынақ көрінісін жазып, шектелген ағынның деталін тексеріңіз.

Қабылдаудың пайдалы шарты мынадай: келісілген шекті көрініс бір сағат жүргенде ешбір желі интерфейсі, контроллер немесе диск томы ұзақ уақыт шегінде тұрмауы керек, ал VMS жоғалған кадрлар мен жазу кезегін көрсетпеуі тиіс. Орташа жүктеменің 30 пайыз болуы қажетті оқиға дәл сол минутта орын алса, бір минуттық үзілісті ақтамайды.

RAID пайдалы сыйымдылық есебін алмастырмайды

RAID диск істен шыққанда қолжетімділікті арттырады, бірақ резервтік көшірме болмайды және номиналды көлемнің бәрін сақтамайды. Пайдалы сыйымдылық RAID деңгейіне, диск саны мен көлеміне, файлдық жүйеге, контроллер қорына және VMS ережесіне байланысты.

Бірдей дискілер үшін жуық есеп мынадай:

RAID 5: полезно ≈ (N - 1) × размер диска
RAID 6: полезно ≈ (N - 2) × размер диска
RAID 10: полезно ≈ N × размер диска / 2

Бұл формулалар пішімдеу мен қызметтік шығынға дейінгі жоғарғы шекті береді. Әрқайсысы 12 ТБ болатын сегіз диск RAID 6-да шамамен 72 ТБ, RAID 10-да 48 ТБ қалдырады. Операциялық жүйе ТиБ өлшемінде бұдан кіші сан көрсетуі мүмкін, өйткені бір ТиБ 2^40 байтқа тең, ал диск өндірушісі бір ТБ-ны 10^12 байт деп есептейді. Бұл жоғалған дерек емес, өлшем бірлігінің айырмасы.

Томды 100 пайыз толатын етіп жобаламаңыз. VMS-ке, файлдық жүйеге және қызмет көрсету операцияларына бос орын қажет, ал нақты битрейт есеппен ешқашан дәл келмейді. Пайдалы сыйымдылықтың 80-85 пайыздық жұмыс шегі жиі орынды, бірақ нақты мәнді VMS пен қойма құжатынан алыңыз. Жүйе ескі бейнені 90 пайызда өшіре бастаса, сақтау мерзімін толық том емес, сол 90 пайыз анықтайды.

Физикалық сыйымдылық формуласын оңнан солға қарай оқу ыңғайлы:

требуемая_полезная_емкость = (видео + аудио + метаданные) × резерв_роста / допустимое_заполнение

60 тәуліктің дерегі 70 ТБ алды, өсу мен дәлсіздікке 20 пайыз қалдырылды, ал томды 85 пайызға дейін толтыруға болады делік. 70 × 1,2 / 0,85 = 98,82 ТБ пайдалы сыйымдылық қажет. Содан кейін ғана осы көлемге RAID конфигурациясы таңдалады. 16 ТБ-лық сегіз диск RAID 6-да пішімдеуге дейін шамамен 96 ТБ береді, яғни қораптардағы жалпы 128 ТБ жазуына қарамастан, талаптан өтпейді.

Істен шығу кезінде не болатынын бөлек шешіңіз. Қайта құру кезінде массив қалған дискілердің бәрін оқып, бейнені қабылдауды жалғастырады. Деградация режиміндегі жазу жылдамдығы мен мұрағат мерзімін тексеру керек. Ыстық резерв қалпына келуді ертерек бастайды, бірақ пайдалы сыйымдылық қоспайды. Басқа бөлмедегі екінші сервер немесе реплика корпус пен контроллер ақауынан, әкімші қатесінен және физикалық оқиғадан қорғайды. Мұны бір RAID істей алмайды.

Диск жылдық жүктеме, бөлік саны және қалпына келу бойынша таңдалады

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

Western Digital жылдық жүктемені дискіге немесе дискіден берілген пайдаланушы дерегін 8760 жұмыс сағатына келтірілген көлем деп анықтайды. Қазіргі қалыпты WD Purple паспортында жылына 180 ТБ-ға дейін көрсетілген, ал кейбір сыйымдылығы жоғары модельдер мен Pro желісінде мән үлкенірек. Seagate те SkyHawk үшін жылына 180 ТБ, SkyHawk AI үшін 550 ТБ көрсетеді. Бұл сандар нақты сериялар мен модельдерге қатысты, сондықтан оларды сол брендтің кез келген дискіне қолдануға болмайды.

Лимитті нақты жазу және оқумен салыстырыңыз. Массив жылына 500 ТБ бейне қабылдап, жазуды сегіз дискіге біркелкі бөлсе, бір дискінің жуық жазу үлесі 62,5 ТБ болады. Бірақ қайта құру, ойнату, тексеру, экспорт және RAID ерекшелігі қосымша оқу мен жазу жасайды. Өндіруші workload көрсеткішіне тек пайдалы мұрағатты емес, екі бағыттағы деректі де қосады. Әсіресе жүйе талдауды бірге орындаса, қор қалдыру керек.

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

Паспорттағы қолдайтын ағын саны да өнімділік есебін алмастырмайды. «64 камераға дейін» деген мәлімдеме белгілі бір жағдайды болжайды және 20 Мбит/с жылдамдықтағы 64 ағынның қатар экспортпен сіздің массивіңізге жарайтынын білдірмейді. Жиынтық ағынды, операция сипатын және жүктеме сынағын қараңыз. Үлкен жүйеде істен шығуы немесе қайта құрылуы бүкіл нысанға әсер ететін бір алып томнан гөрі, бірнеше болжамды сақтау тобы дұрыс.

Температура мен қуат та қойма жобасына кіреді. Дискілер тығыз орнатылғанда және RAID қалпына келгенде қатты қызады, ал контроллер жұмыс ауқымынан шыққан дискінің жылдамдығын шектеуі немесе оны ажыратуы мүмкін. Басқарылатын ауа ағыны, SMART мониторингі, ескерту, үздіксіз қуат көзі және жұмысты дұрыс тоқтату қажет. Үздіксіз қуат көзі нысанды бірнеше сағат ұстамауы мүмкін, бірақ қуат ауысуын жабуы немесе серверге жазуды қалыпты тоқтатуға уақыт беруі тиіс.

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

Нақты көріністегі сынақ сметаны өзгертеді

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

Әр камера бойынша ажыратымдылықты, кадр/с мәнін, кодекті, битрейтті басқаруды, мақсатты сапаны, ағын шегін, GOP-ты, күн-түн режимін, дыбысты, жазу режимін, оқиға алдындағы және кейінгі жазуды бекітіңіз. Жанына орташа, 95-процентиль және ең жоғары битрейтті, сондай-ақ жазылған уақыттың нақты үлесін жазыңыз. Өлшенген нәтижесі жоқ баптау скриншоты есепке жарамайды.

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

Пилоттан кейін төрт салыстыру жасаңыз:

1. Мұрағаттың есептелген тәуліктік өсімі өлшенген мәнге түсіндірілетін үстеме шығын шегінде сәйкес келеді.
2. Шекті ағындар әр желі бөлігін жоғалтусыз және кезексіз өтеді.
3. Барлық камера жазып жатқанда мұрағат ойнатылады және экспортталады.
4. Таңдалған RAID талабына сай массив тексерілгенде немесе бір диск істен шыққанда жүйе жазуды сақтайды.

Содан кейін екі ай күтпей сақтау мерзімін бақылаңыз. Жеті тәуліктегі өсімді өлшеп, 60/7-ге көбейтіңіз де, VMS шынымен толтыруға рұқсат беретін сыйымдылықпен салыстырыңыз. Жоғары белсенділікті бөлек модельдеңіз. Бұл болжам 60-күнгі соңғы тексеруді алмастырмайды, бірақ өлшем бірлігі, ағын профилі немесе сақтау саясатындағы қатені тез табады.

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

48 камераға арналған толық есеп

Міндетті мұрағат мерзімі 60 тәулік болатын 48 камералы нысанды қарастырайық. Жобада орташа ағыны 2 Мбит/с болатын 24 ішкі 1080p камера, 5 Мбит/с болатын 16 сыртқы 4 Мп камера және 12 Мбит/с болатын сегіз 4K камера бар. Барлығы үздіксіз жазылады, ал мәндер күндіз бен түнді қамтыған пилоттан алынған.

Жиынтық орташа ағын:

24 × 2 + 16 × 5 + 8 × 12 = 224 Мбит/с

60 тәуліктегі бастапқы көлем:

224 × 0,648 = 145,152 ТБ

Пилоттық VMS өлшемінен алынған дыбысқа, индекске, шағын кескінге және қызметтік дерекке 3 ТБ қосамыз. Есеп негізі 148,152 ТБ болады. Көрініс өзгерісіне, бірнеше камера ауысуына және ұзақ кезеңнің пилоттан өзгешелігіне 20 пайыз қалдырамыз:

148,152 × 1,2 = 177,7824 ТБ

Томды 85 пайызға дейін толтыруға болса, массивтің қажет пайдалы сыйымдылығы:

177,7824 / 0,85 = 209,16 ТБ

16 ТБ-лық 16 диск RAID 6-да пішімдеуге дейін жуықтап 224 ТБ береді: (16 - 2) × 16. Ол сыйымдылықтан шағын қалдықпен өтеді, бірақ шешімді әлі бекітуге болмайды. Нақты массивтің қызметтік шығынын шегеру, 16 дискілік топтың үйлесімділігін, қайта құру жылдамдығын, диск моделінің жылдық жүктемесін және қатар оқу кезіндегі жазу өнімділігін тексеру қажет.

Енді өткізу жолағын есептейік. Өлшенген шектер ішкі камераға 3,5 Мбит/с, сыртқы камераға 9 Мбит/с және 4K камераға 20 Мбит/с болсын. Қолайсыз оқиға барлық камераға бір мезгілде әсер етсе, жоғарғы қосынды:

24 × 3,5 + 16 × 9 + 8 × 20 = 388 Мбит/с
388 × 1,2 = 465,6 Мбит/с с сетевым запасом

Бір гигабиттік интерфейс қабылдауды атаулы мән бойынша көтереді, бірақ оған жазуды, клиенттік көруді, резервтік көшіруді және басқаруды ойланбай араластыруға болмайды. Практикалық жоба архитектура қолдаған жерде трафикті VLAN мен интерфейстерге бөледі, әр uplink-ті тексереді және шығыс оқуға орын қалдырады. Екі қашық алаң 200 Мбит/с арна арқылы қосылса, сервердің гигабиттік картасы бұл мәселені шешпейді.

Қозғалыс бойынша жазу есебі өзгеше болады. Ішкі камералар негізгі ағынды уақыттың 35 пайызында жазып, 0,3 Мбит/с фондық ағынды үнемі сақтасын, ал басқа камералар үздіксіз жазылсын. Онда ішкі топ 24 × (2 × 0,35 + 0,3) болып есептеледі, 24 × 2 × 0,35 емес, өйткені фондық жазба тоқтамайды. 35 пайыздық үлесті оқиға алдындағы және кейінгі бөлігі бар сақталған клиптермен растау керек.

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

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