О-очень медленная архивация!!!

[Duser]

Всем доброго времени суток.

Проблема: в одной серверной стоят несколько серверов с платами видеозахвата (16 камер 6к/с на сервер) и парой дисков 400Ггб (помимо системного) в зеркале для оперативного архива, и файловый сервер с клиентской лицензией и немалым (2,5Тб) программным RAID5. Везде W2003ServerSP2+VN8.4. Система ровно пашет около двух лет, архивацию добавили недавно.
В ноль часов каждый день по расписанию запускается архивация за "Вчера" с серверов на файловый. Сначала все было вполне радужно - архив за сутки сливался часа за 3-4, потом это время стало увеличиваться...сейчас архив за сутки льется ДОЛЬШЕ суток!
Железных ресурсов серверам хватает. Сетка отдельная - патчкорды по 1,5м. и свитч D-Link. Перезагруз не спасает. Сетка занята примерно на 4-6%, причем временами взмывает процентов до 70. Просто перекид файла по сети между серверами проходит на ура.

Может кто с подобным бодался? Где рыть?

[O.W.]

А если тома убить и новые создать?
Как дела с бэдами на дисках?

[Duser]

При добавлении в систему файлового сервера система полностью переустанавливалась на каждом сервере. Конфигурация писалась практически с нуля (т.е. без импорта экспорта) на основе старой конфигурации. Диски естественно форматились. Беды есть, но их очень немного. Опять же проблем с записью не наблюдается, только с архивацией. Текущая очередь дисков нулевая с всплесками до 1 раз в 5-6 секунд (это на сервере, с которого делается архивация и на который ведется оперативная запись).

[Slav]

А свитч D-Link пробовали заменить на что-то серьезное?

[Duser]

Сегодня вместе с саппортом пробовали соединить напрямую без свитча. И много чего еще другого пробовали.
А помогло только отключение тома (программный RAID5) на файловом сервере и снова подключение. Сейчас вроде льет. Сетка 60-70%. За час слито было 20% инфы за ДВОЕ суток. Но, думаю, это еще не конец. В понедельник отпишусь. Чует мое сердце - все только начинается...

Саппорт грешит на программный RAID...

[Duser]

Сделал следующее:
Убил том размером 2,5Тб,
Создал три тома по 800ГГб (все это на том же самом софтверном райде).
В остальном изменения несущественные.
И архивация заработала. Вывод - софтверный райд ни при чем. Глючил VN.

[Kly]

Аналогичная проблема только архив аж 13 ТБ, для каждого сервера по 2.5 ТБ в среднем.
Убивать тома = самоубийство.
Ну и Рейд 5 соответственно на Адаптеке.
Винчестеры все серверные 24/7
За полгода время архивации возросло с 2 часов на сервер до 6-8 часов.

[Max]

по данной теме прошу прислать САВ файлы и ваших серверов VideoNet и "хранилищ" (куомпьютеров VideoNet, куда ведется архивация).

PS
убедительная просьба в письме так же указать ссылку на данную тему форума.

[Duser]

2Kly: Убийство архива - всегда нож по сердцу. Правда я обошелся малой кровью - оперативные архивы живы+важное слили на доп винчестер (временно). У меня на 2,5 Тб сначала тоже все было радужно, пока том не пошел на второй цикл. Поэтому и не отписывался - ждал зацикливания на новых томах.

2Max: Мои CABы давно у вас.

[Max]

2Kly: Убийство архива - всегда нож по сердцу. Правда я обошелся малой кровью - оперативные архивы живы+важное слили на доп винчестер (временно). У меня на 2,5 Тб сначала тоже все было радужно, пока том не пошел на второй цикл. Поэтому и не отписывался - ждал зацикливания на новых томах.

2Max: Мои CABы давно у вас.

я так понимаю с Владимиром, по данной проблеме Вы обсуждали возможные пути решения и, для себя нашли наиболее приемлемый путь решения.

[Duser]

Владимир предложил воткнуть райд аппаратный. Других вариантов решения не предлагалось.
Я не понимаю почему софтверный райд годится для томов ~800ГГб и не годится для томов ~2Тб. Владимир мне этого объяснить не смог.

[Stranger]

Владимир предложил воткнуть райд аппаратный. Других вариантов решения не предлагалось.
Я не понимаю почему софтверный райд годится для томов ~800ГГб и не годится для томов ~2Тб. Владимир мне этого объяснить не смог.

Константин, Вы лукавите в этих утверждениях.

Вам было предложено несколько вариантов:

1. Отказаться от использования программного рэйда в пользу аппаратного рэйд-контроллера (сохранить отказоустойчивость и повысить производительность массива).

2. Отказаться от программного рэйда и перейти на использование сингл-дисков (повысить производительность массива в ущерб отказоустойчивости).

3. Уменьшить количество фрагментов записи посредством увеличения длительности единичной записи по детекции и уменьшения количества срабатываний по детекции (либо вообще перейти на постоянную запись в моменты пиковой нагрузки).

Также Вам было предоставлено мое видение Вашей ситуации с замедлением архивации при заполнении тома большим количеством фрагментов. На всякий случай, напомню: частых, регулярно чередующихся операций чтения-записи при большом количестве фрагментов в томе требуется больше, чем при меньшем их количестве. Соответственно, в программном рэйде, на мой взгляд, данные операции приводят к существенно большему времени реакции, нежели без программного пересчета четности. О возросшем времени реакции дисковой системы говорил и счетчик текущей длины очереди диска, поднимающийся до 2-х. Также, отрисовка карты фрагментов в проигрывателе в течении десятков секунд при активной функции архивации и проблемы при собирании дополнительной информации о томе при ведении архивации в него говорили о недостаточной производительности Вашего массива.

Вопросов о том, почему программный рэйд "годится" для томов размером 800Gb и "не годится" для томов размером 2.5Gb у Вас на момент нашего длительного диалога и вовсе не возникало, поскольку результатов такового эксперимента тогда просто не было в природе.

Объяснение, как ни странно, у меня тоже самое - количество фрагментов в томе размером 800Gb в ~три раза меньше, чем в томе размером 2.5Tb (при условии одинаковых настроек записи по детекции).

[Duser]

Переход на сингл диски (потеря избыточности и потеря части архива в случае сбоя диска, как следствие) или изменение уже отлаженного режима записи в сторону ухудшения (увеличение времени записи по детекции, постоянная запись -> раздутие архива; ухудшение чувствительности детектора -> увеличение вероятности пропуска событий) вариантами решения назвать трудновато. Это подгон задачи под ответ. Действительно реальное решение из предложенных - переход на железный райд.
"..частых, регулярно чередующихся операций чтения-записи при большом количестве фрагментов в томе требуется больше, чем при меньшем их количестве..." - это справедливо для тома VN, но не для райда. Режим просмотра архива не изменился. Смотрим со всех трех томов. Так что операций стало меньше для одного тома, а для трех томов их осталось столько же. Напомню: сам райд не изменился, изменились только размеры томов VN.
Возможно VN стало легче работать с отдельным томом во время архивации? Ну так это проблема VN,а не софтверного райда.
Теперь что касается эксперимента: Software RAID5, организованный средствами операционной системы, абсолютно органично вписывается в концепцию "данное ПО работает под данной ОС", и эксперимент этот должны были поставить вы (разработчики ПО). Хотя бы для того, чтобы написать в требованиях к конфигурации ОС и железа "с софтверным райдом работает нестабильно".
Вопрос "почему годится" я действительно не задавал (не знал, что годится), но вопрос "почему НЕ годится" звучал настойчиво, внятного ответа однако я не услышал.
Насколько я понимаю - райд организованный средствами ОС для ПО, работающего под управлением ОС никак не отличается от обычного динамического сингл-диска. Так же как и райд, собранный на аппаратном контроллере. Разнице в скорости и нагрузке на процессор. Но известно, что скорость чтения с софтверного райда из пяти дисков - выше, чем с одного (можно ведь читать данные одновременно с нескольких дисков), а скорость записи не ниже, чем на один, при условии достаточной мощщи процессора. У меня процессор на сервере архивации ни разу не грузился более, чем на 30%. Сейчас во время архивации - не более 10%.
Так что проблема не в софтверном райде, а в размере тома (читай - в количестве записей в томе). История Kly тому подтверждение.

[Stranger]

Переход на сингл диски (потеря избыточности и потеря части архива в случае сбоя диска, как следствие) или изменение уже отлаженного режима записи в сторону ухудшения (увеличение времени записи по детекции, постоянная запись -> раздутие архива; ухудшение чувствительности детектора -> увеличение вероятности пропуска событий) вариантами решения назвать трудновато. Это подгон задачи под ответ. Действительно реальное решение из предложенных - переход на железный райд.

Я нигде не предлагал ухудшение чувствительности детектора. Возможно, Вы неправильно поняли. Имелась ввиду комплексная мера по уменьшению кол-ва фрагментов в томе, как то: в свойствах события от детектора по камере установить больший интервал в пункте "Срабатывать не чаще x раз в секунду" и одновременно соответствующим же образом увеличить в реакции "Регистрация видео-аудио данных" интервал длительности записи. Ни о каком увеличении вероятности пропуска событий здесь речи быть не может.

Касаемо "подгонки под ответ": а использование аппаратного рэйд-контроллера не будет таковым при условии того, что Вы неоднократно повторяли "этот вариант даже не рассматривается"?

"..частых, регулярно чередующихся операций чтения-записи при большом количестве фрагментов в томе требуется больше, чем при меньшем их количестве..." - это справедливо для тома VN, но не для райда. Режим просмотра архива не изменился. Смотрим со всех трех томов. Так что операций стало меньше для одного тома, а для трех томов их осталось столько же. Напомню: сам райд не изменился, изменились только размеры томов VN.

И, соответственно, изменилось (уменьшилось) количество фрагментов в томе, на который ведется архивация. Как следствие, уменьшилось кол-во обращений на массив при выполнении этой архивации. Напомню, в VideoNet одновременно не может выполняться более одной операции архивации.

Возможно VN стало легче работать с отдельным томом во время архивации?

А я что-то иное когда-либо утверждал? Константин, повторяю: Скорость дисковых операций при использовании VideoNet для записи (архивации) томов видеоархива является критичным параметром. Скорость дисковых операций/загрузку процессора при использовании сугубо программного рэйда 5-го уровня весьма сложно прогнозировать и, тем более, гарантировать.

Ну так это проблема VN,а не софтверного райда.

Это проблема взаимодействия VideoNet и программного рэйда 5-го уровня при определенном количестве определенных операций в единицу времени, при котором вышеуказанный программный рэйд не обеспечивает требуемого для VideoNet быстродействия.

Теперь что касается эксперимента: Software RAID5, организованный средствами операционной системы, абсолютно органично вписывается в концепцию "данное ПО работает под данной ОС", и эксперимент этот должны были поставить вы (разработчики ПО). Хотя бы для того, чтобы написать в требованиях к конфигурации ОС и железа "с софтверным райдом работает нестабильно".

Написать "работает нестабильно с такой-то аппаратной конфигурацией при использовании такого-то режима воспроизведения такого-то количества камер на таком-то количестве клиентов и архивации со стольки-то компьютеров"?
Еще раз повторюсь: в нашей компании существует отдел комплексных цифровых решений, который в том числе призван помочь пользователям в подборе гарантированно работоспособной конфигурации для решения поставленной задачи.
Если Вы подбираете оборудование и ПО самостоятельно, то Вы делаете это только на свой страх и риск.

Вопрос "почему годится" я действительно не задавал (не знал, что годится), но вопрос "почему НЕ годится" звучал настойчиво, внятного ответа однако я не услышал.

Ответ, повторенный мной в предыдущем письме, невнятен?

Насколько я понимаю - райд организованный средствами ОС для ПО, работающего под управлением ОС никак не отличается от обычного динамического сингл-диска. Так же как и райд, собранный на аппаратном контроллере. Разнице в скорости и нагрузке на процессор. Но известно, что скорость чтения с софтверного райда из пяти дисков - выше, чем с одного (можно ведь читать данные одновременно с нескольких дисков), а скорость записи не ниже, чем на один, при условии достаточной мощщи процессора. У меня процессор на сервере архивации ни разу не грузился более, чем на 30%. Сейчас во время архивации - не более 10%.
Так что проблема не в софтверном райде, а в размере тома (читай - в количестве записей в томе). История Kly тому подтверждение.

Можно узнать источник сведений о том, что скорость записи программного рэйда пятого уровня не ниже одиночного диска? Причем, в любом режиме?
Опять же, насколько я помню, Вы сообщили о том, что при увеличении времени архивации загрузка одного ядра процессора в процессе этой архивации увеличивается до 100%.

[Duser]

Я нигде не предлагал ухудшение чувствительности детектора. Возможно, Вы неправильно поняли. Имелась ввиду комплексная мера по уменьшению кол-ва фрагментов в томе, как то: в свойствах события от детектора по камере установить больший интервал в пункте "Срабатывать не чаще x раз в секунду" и одновременно соответствующим же образом увеличить в реакции "Регистрация видео-аудио данных" интервал длительности записи. Ни о каком увеличении вероятности пропуска событий здесь речи быть не может.

Это правда. Здесь речь идет о неоправданном раздутии архива.

Касаемо "подгонки под ответ": а использование аппаратного рэйд-контроллера не будет таковым при условии того, что Вы неоднократно повторяли "этот вариант даже не рассматривается"?

Железный райд - несомненно правильное решение и единственное из предложенных не ухудшающее ТТХ системы. Но он тянет за собой вопрос финансирования, а это уже не моя и не Ваша компетенция. Поэтому вариант и не рассматривается.

И, соответственно, изменилось (уменьшилось) количество фрагментов в томе, на который ведется архивация. Как следствие, уменьшилось кол-во обращений на массив при выполнении этой архивации. Напомню, в VideoNet одновременно не может выполняться более одной операции архивации.

Как количество обращений зависит от объема тома? Поток архивируемых данных тот же (в моем случае ~5МБ/сек, т.е. ~50ГГБ за ~3 часа), сервер архивации должен найти самые старые данные и на их место записать новые. Как при неизменном потоке новых данных может уменьшиться/увеличиться/измениться количество обращений? Или VN постоянно сканирует весь том в поисках самого старого фрагмента?

Константин, повторяю: Скорость дисковых операций при использовании VideoNet для записи (архивации) томов видеоархива является критичным параметром. Скорость дисковых операций/загрузку процессора при использовании сугубо программного рэйда 5-го уровня весьма сложно прогнозировать и, тем более, гарантировать.

Заявление весьма двусмысленное. Покупая VN, я вынужден покупать продукт Microsoft. И тут выясняется, что как минимум один из этих программных продуктов имеет серьезные проблемы со стабильностью ( "...сложно прогнозировать и, тем более, гарантировать..."=нестабильность).

Это проблема взаимодействия VideoNet и программного рэйда 5-го уровня при определенном количестве определенных операций в единицу времени, при котором вышеуказанный программный рэйд не обеспечивает требуемого для VideoNet быстродействия.

А разве Microsoft заявлял о совместимости своих осей с вашим ПО? Это вы выбрали данное семейство ОС.

Еще раз повторюсь: в нашей компании существует отдел комплексных цифровых решений, который в том числе призван помочь пользователям в подборе гарантированно работоспособной конфигурации для решения поставленной задачи.
Если Вы подбираете оборудование и ПО самостоятельно, то Вы делаете это только на свой страх и риск.

ПО, которое я подобрал на свой страх и риск - это Win2003Server? Софтверный рейд - встроенная функция ОС. Если VN не поддерживает эту функцию - нужно громко-громко об этом заявлять, а не отправлять меня в соответствующий отдел за санкцией на использование с вашим ПО той оси, использовать которую вы меня и вынудили.

Вопрос "почему годится" я действительно не задавал (не знал, что годится), но вопрос "почему НЕ годится" звучал настойчиво, внятного ответа однако я не услышал.

Ответ, повторенный мной в предыдущем письме, невнятен?

Он невнятен и в этом посте.

Можно узнать источник сведений о том, что скорость записи программного рэйда пятого уровня не ниже одиночного диска? Причем, в любом режиме?

А это вытекает из самого принципа построения пятого райда. Запись на райд отличается от записи на сингл-диск только вычислением XOR. А задержка на эту операцию, при наличии мощного процессора, настолько мала, что ею можно пренебречь. Про любой (читай-деградированный) режим я не говорил, не передергивайте. Речь идет о штатном режиме.
Вообще аппаратный райд - это процессор, выполняющий программу вычисления XOR (~100Мгц) + кеш (~128МБ) + контроллер диска + батарейка, засунутые в отдельную железку. Так неужели CoreQuad с 2ГГБ оперативы, который только тем и занимается, что обслуживает этот самый райд, уступит тому же Adaptec'у? Да и майкрософтовский LDM вроде не самое отстойное в мире райдов.

Опять же, насколько я помню, Вы сообщили о том, что при увеличении времени архивации загрузка одного ядра процессора в процессе этой архивации увеличивается до 100%.

Опять же ядро это отжирает VN, тогда как винда вместе с неуспевающим райдом и еще тремя ядрами простаивают. При этом чтение/запись с райда/на райд в это время абсолютно не тормозит. И текущая очередь диска всплескивается до единицы раз в 5-6 сек.(при копировании порядка 17000 файлов общим объемом в 5ГГБ с райда на тот же райд держалась где-то на 20 все время копирования)

Владимир, мне абсолютно ясно, что райд здесь ни при чем. Есть проблема у VN с томами ~2.5ТБ на софтверных и софтверно-аппаратных (Adaptec ведь такой, если не ошибаюсь?) райдах. Её надо изучать, решать и о ней нужно предупреждать.
IMHO

[Stranger]

И, соответственно, изменилось (уменьшилось) количество фрагментов в томе, на который ведется архивация. Как следствие, уменьшилось кол-во обращений на массив при выполнении этой архивации. Напомню, в VideoNet одновременно не может выполняться более одной операции архивации.

Как количество обращений зависит от объема тома? Поток архивируемых данных тот же (в моем случае ~5МБ/сек, т.е. ~50ГГБ за ~3 часа), сервер архивации должен найти самые старые данные и на их место записать новые. Как при неизменном потоке новых данных может уменьшиться/увеличиться/измениться количество обращений? Или VN постоянно сканирует весь том в поисках самого старого фрагмента?

В данном случае, описание механизмов работы не принципиально. Факт в том, что при использовании достаточных по быстродействию дисковых подсистем аналогичные конфигурации работают нормально.

Константин, повторяю: Скорость дисковых операций при использовании VideoNet для записи (архивации) томов видеоархива является критичным параметром. Скорость дисковых операций/загрузку процессора при использовании сугубо программного рэйда 5-го уровня весьма сложно прогнозировать и, тем более, гарантировать.

Заявление весьма двусмысленное. Покупая VN, я вынужден покупать продукт Microsoft. И тут выясняется, что как минимум один из этих программных продуктов имеет серьезные проблемы со стабильностью ( "...сложно прогнозировать и, тем более, гарантировать..."=нестабильность).

Поправлю: одна из надстроек продукта Microsoft может иметь проблемы прогнозирования и гарантирования пропускной способности дисковой подсистемы и загрузки процессора. Именно поэтому для достижения отказоустойчивости и при этом сохранения нужного быстродействия процессора/пропускной способности дисковой подсистемы мы и рекомендуем использование аппаратных рэйд-контроллеров.

Например то, что далеко не всякое "железо" подходит для использования с VideoNet/платами захвата - не тайна и двусмысленности, почему-то, не вызывает.

Это проблема взаимодействия VideoNet и программного рэйда 5-го уровня при определенном количестве определенных операций в единицу времени, при котором вышеуказанный программный рэйд не обеспечивает требуемого для VideoNet быстродействия.

А разве Microsoft заявлял о совместимости своих осей с вашим ПО? Это вы выбрали данное семейство ОС.

Описать все исключения для всех теоретически возможных режимов использования - невозможно.

Еще раз повторюсь: в нашей компании существует отдел комплексных цифровых решений, который в том числе призван помочь пользователям в подборе гарантированно работоспособной конфигурации для решения поставленной задачи.
Если Вы подбираете оборудование и ПО самостоятельно, то Вы делаете это только на свой страх и риск.

ПО, которое я подобрал на свой страх и риск - это Win2003Server? Софтверный рейд - встроенная функция ОС. Если VN не поддерживает эту функцию - нужно громко-громко об этом заявлять, а не отправлять меня в соответствующий отдел за санкцией на использование с вашим ПО той оси, использовать которую вы меня и вынудили.

В случае именно с Вашей конфигурацией/ситуацией быстродействия используемой дисковой подсистемы оказалось недостаточно. Наверняка, найдется конфигурация, при использовании которой будет достаточно и быстродействия дисковой подсистемы, использующей такие встроенные функции ОС, как компрессия ntfs и шифрование (efs).
Однако, утверждать, что VideoNet при использовании любой конфигурации будет достаточно такой пропускной способности - нонсенс.

Вопрос "почему годится" я действительно не задавал (не знал, что годится), но вопрос "почему НЕ годится" звучал настойчиво, внятного ответа однако я не услышал.

Ответ, повторенный мной в предыдущем письме, невнятен?

Он невнятен и в этом посте.

Тем не менее, на основе данных из него Вы смогли сделать рабочее на текущий момент решение.

Можно узнать источник сведений о том, что скорость записи программного рэйда пятого уровня не ниже одиночного диска? Причем, в любом режиме?

А это вытекает из самого принципа построения пятого райда. Запись на райд отличается от записи на сингл-диск только вычислением XOR. А задержка на эту операцию, при наличии мощного процессора, настолько мала, что ею можно пренебречь. Про любой (читай-деградированный) режим я не говорил, не передергивайте. Речь идет о штатном режиме.
Вообще аппаратный райд - это процессор, выполняющий программу вычисления XOR (~100Мгц) + кеш (~128МБ) + контроллер диска + батарейка, засунутые в отдельную железку. Так неужели CoreQuad с 2ГГБ оперативы, который только тем и занимается, что обслуживает этот самый райд, уступит тому же Adaptec'у? Да и майкрософтовский LDM вроде не самое отстойное в мире райдов.

Принцип работы raid5 Вами понимается несколько неверно.

Производительность записи программного рэйда 5-го уровня в общем случае ниже сингл-диска из-за того, что на один диск должна быть записана четность, а на другой - данные. При вычислении новой четности сначала должны быть считаны старая четность и старые данные. После этого старые данные, новые данные и старая четность объединяются операцией xor для получения новой четности. Таким образом, операция записи требует дополнительного расхода ресурсов процессора и дополнительных дисковых операций.


Про работу рэйд-массива в состоянии Degrade я ничего не говорил.
Не приписывайте мне лишнего.

Опять же, насколько я помню, Вы сообщили о том, что при увеличении времени архивации загрузка одного ядра процессора в процессе этой архивации увеличивается до 100%.

Опять же ядро это отжирает VN, тогда как винда вместе с неуспевающим райдом и еще тремя ядрами простаивают. При этом чтение/запись с райда/на райд в это время абсолютно не тормозит. И текущая очередь диска всплескивается до единицы раз в 5-6 сек.(при копировании порядка 17000 файлов общим объемом в 5ГГБ с райда на тот же райд держалась где-то на 20 все время копирования)

Владимир, мне абсолютно ясно, что райд здесь ни при чем. Есть проблема у VN с томами ~2.5ТБ на софтверных и софтверно-аппаратных (Adaptec ведь такой, если не ошибаюсь?) райдах. Её надо изучать, решать и о ней нужно предупреждать.
IMHO

У меня стойкое убеждение в том, что в Вашем случае проблема вызвана недостаточным для Вашей задачи быстродействием дисковой подсистемы при использовании VideoNet.