На время работы можно не обращать внимания если речь про работу от powerbank. А в остальном вариантов паяльников не так много на самом деле. TS101, Fnirsi, еще там 2-3 производителя и у каждого по 2-3 модели. На вкус и цвет.
Целевая это "куда бэкапим". В данном случае это источник.
Выделить под бэкапы отдельную подсеть и отдельную сеть. Если речь про сервера.
Но вообще, если сеть просто под нагрузкой дохнет, это не проблема виама, это проблема ОС/драйверов/железа.
Можно для проверки попробовать отбекапить на медленную цель, на флешку usb2, тогда сеть будет явно недозагружена.
У рейда есть производитель (если аппаратный). У этого производителя есть мануалка с возможностями рейда. Если в мануалке указано что он умеет расширять и написано как это делать, значит расширяем. Если не описано, значит он так делать не умеет.
Если не умеет - втыкаем рядом с 4 дисками новые 4, создаем там рейд и перетаскиваем данные с одного рейда на другой.
По дискам всегда есть баланс между параметрами. Емкость, скорость (важна и пропускная способность в целом и время отклика), стоимость. В вашем случае, скорее всего, виртуалкам не хватает времени отклика. Кстати, в стандартном мониторе производительности видно время отклика и какие файлы в данный момент загружают диски больше всего. IOPS - наше все.
Тест на aida ничего не говорит вообще, можно на него не обращать внимания. Смотрите diskspeed, например. Блоками по 4к.
По форматированию не уверен что имеет смысл 64к. 64к используют там где нужно большие тома иметь (16 тб) или если мы архивные данные храним с линейным чтением записью. А виртуалки как раз нормально живут в 4к блоках.
Если данные вам не важны (а есть подозрение что не важны), можно попробовать включить кеширование на всех уровнях. В рейде это будет write back и disk cache. В общем случае это отвратительный совет и применим только на тестовой среде.
В гипервизорах часто можно ограничить iops для каждой конкретной виртуалки. Быть может одна из них выедает все ресурсы не оставляя другим. Скажем 300-500 для DC, 1500 для файловой помойки.
Ваши 4 диска в R10 могут давать примерно 200 IOPS. Исходя из того что 1 диск выдает примерно 100 iops при 70R/30W и приемлемой задержке, имеем две группы, получаем 200. Если включить все кеши, будет примерно 300. То есть все равно маловато для перечисленных ВМ. Все это цифры от потолка, смотрите сколько у вас в реальности получается и где тормозит.
"Возможно, более реалистично окажется сразу писать записи в два места." - поддержу.
Штатных решений по бэкапу данных с NVR бытовых dahua скорее всего не существует.
Тут либо ставить на сервер свой NVR и подключаться к dahua и тянуть видео потоки с него, либо подключаться к камерам напрямую и тянуть видео поток с них. Второе более решение кажется более отказоустойчивым, т.к. даже при выходе из строя dahua мы продолжим получать и сохранять картинку.
Еще можно использовать VMS - по которое обычно используют для объединения нескольких nvr|dvr в единую систему видеонаблюдения. Технически там есть возможность указать камеру, дату и время, экспортировать интересующие записи куда-то на комп в формате avi или подобном. Почему бы не быть такому функционалу как полное копирование всех записей если ресурсы позволяют.
У veeam, если я правильно помню, есть всякие фишки по очень оперативному восстановлению. instant recovery или что-то в этом духе. Опять же, если я правильно помню, гипервизор запускает восстанавливаемую машину еще до восстановления всех ее данных, прямо на хранилке где лежит та самая резервная копия. Возможно в данном случае именно такое восстановление он и пытается сделать, но где-то что-то не настроено и примонтирование не удается.
В принципе уже сказали выше. Проведите тесты. Не Гилева в 1с, а тесты отдельно каждой из подсистем.
На уровне хоста и отдельно на уровне ВМ:
- дисковая подсистема. Под виндой diskspd, например. И с включеным кешированием и с выключеным. Каждого из массивов и из типов дисков.
- сеть (маловероятно, но вдруг тоже не очень) iperf3
- цпу. чем угодно.
- память (вдруг все к одному ЦПУ воткнуто.
Про проксмокс не скажу, я не уверен что он вам нужен, т.к. ВМ у вас виндовые. Но по дефрагментации что-то странное. Зачем дефрагментацию запускать на рейд массиве hdd sas r5 мне непонятно. Какой цели мы тем самым хотим добиться?
Программный рейд для nvme это норм.
После теста железок можно уже смотреть настройки гипервизоров, ВМ, самих приложений.
У этих дисков nvme вроде есть Power Loss Imminent Capacitor, так что можно им разрешить всевозможные кеширования на их уровне.
Тупо считаем ресурсы:
1. ОС Windows Server 2019 Standard. Хостовые ресурсы 4 цпу, 6 озу, 100 пзу ссд (200 мбит/сек).
2. контроллер домена Active Directory + DNS. 4 цпу, 6 озу, 100 пзу ссд (100 мбит/сек)
3. samba на 20 пользователей (реально не более 10 одновременно). 4 цпу, 6 озу, 100 пзу ссд (100 мбит/сек), 1 тб пзу hdd.
4. Сервер терминалов (не более 7 пользователей одновременно). Не указано для каких приложений. Пусть будет 1С и серфинг. 12 цпу, 32 гб озу, 500 гб ПЗУ (500 мбит/сек и больше)
5. "Стахановец" (программа для защиты коммерческих данных, собирает статистику и снимки с камер с компьютеров в домене). Смотрим сколько сейчас и закладываем Х2. Либо ищем у вендора.
6. Apache (необходим для работы фронтенда "Стахановца" см п.5.
7. PostgreSQL (для хранения данных "Стахановца") см п.5.
8. MySQL (для хранения данных самописной программы) 2 цпу, 2 гб озу, 60 гб пзу (100 мбит/сек (наверное))
9. Самописная программа 2 цпу, 2 гб озу, 60 гб пзу (100 мбит/сек (наверное))
10. OpenVPN 6 цпу, 2 гб озу, 60 гб пзу
Почти все ВМ на SSD, скорее всего на разных raid массивах, но можно и HDD воткнуть чисто для холодных данных (резервные копии которые снимаются локально, мусор который жалко выкинуть, те же видеопотоки от стахановца (они же не в бд хранятся?). Например, под хостовую ОС + VM DC + VM SMB (OS) можно raid 1 sata ssd. Под остальное быстрое R1 nvme, под медленное R1 sata hdd.
Важная, но сложная тема IOPS, т.к. там зависимость от размера блока. Грубо, если производитель SATA SSD говорит о 30k iops, на них можно комфортно разместить 4-5 виртуалок без нагрузок, получается по 7k iops на Win VM. Это субъективная оценка. В плане указал именно мбит/сек, а не iops, потому что попугаев сложно считать.
Собирать ли на базе ПК, искать бу сервер или собирать на новой серверной платформе - это считать надо каждый из вариантов и понимать как это все админится будет и насколько дорогой простой.
Crazy_Cooler, не надо standalone хост в режиме ядра. Просто ОС с графикой и роль hyper-v.
решение самостоятельное и рабочее. Как раз Core или proxmox это для извращенцев в данном случае. Хотя кому как )
Искатель, чем больше виртуалок, тем меньше проблем с их обслуживанием. Проще бэкапить, обновлять, менять настройки каждого из сервисов. Но в качестве расплаты увеличение используемых ОЗУ, ПЗУ, ЦПУ.
Crazy_Cooler, hyper-v можно использовать без доменной структуры. И отдельный КД ему не нужен совсем, он в workgroup умеет. И будучи в домене без доступа к КД тоже умеет работать.
Мы же не про SCVMM говорим, а про отдельно стоящий hyper-v
Есть вероятность что к коммутатору провайдера так же приходит 100 мбит, и тогда хоть 20 отдельных линков объединяй, не получится превысить этот порог.
Так же есть вероятность что провайдер может включить агрегацию портов на своем оборудовании.
Все в руках провайдера, задавайте ему как можно больше вопросов.
НР ЕlitеDеsk 800 G3 DМ
И подобные ему бывают по 8-10 т.р. Будет шуршать на полочке. Провайдер может осадить, а может забить на ваши коннекты. Как повезет.
Но брать нужно сразу парочку, как ниже заметил alexalexes в случае поломки у вас не будет шансов быстро восстановить работоспособность, в отличие от ПК на ширпотребе.
"Защищенность" по требованию ФСТЭК бывает очень разной. И перс данные бывают очень разными. Могут быть данные с ФИО и телефоном, а могут быть данные о ВИЧ инфекции. Требования к защите этих данных разные. Начинается все не с сетевого пограничного оборудования, хотя это тоже неплохо. Начинается все с бумажек и проверять прежде всего будут бумажки.
На бумаге нужно изложить классификацию обрабатываемых данных, очертить модели угроз, на основании предыдущих пунктов составляются механизмы защиты. Исходя из классификации данных берется уже оборудование или ПО закрывающее соответсвующие угрозы.
И для бумажных работ вам либо в штат нужно взять человека умеющего в бумажки, либо обратиться в соответствующую контору которая за количество денег значительно большее чем стоят все железки сделает за вас работу по оформлению бумажек и скажет что купить.
Периодически задаюсь тем же вопросом.
Вероятно лучшего решения здесь нет. Просто берем калькулятор и считаем расходы на емкость.
В разных системах копирования, с разными механизмами дедупа сталкивался с невозможностью восстановления. Где-то не во время отключилось питание, где-то странное поведение дисков. Хорошо что это было не критично. Понятно что это частный случай, но вероятность потерять данные в любом случае возрастает. С одной стороны это не основные данные, а лишь бэкапы. С другой стороны - когда бекапы нужны, они являются единственным источником и ценность их резко возрастает.
При большом желании можно размещать тома V B&R на отдельной машинке умеющей в снепшоты. Хранилка как раз может быть под линуксом, с отдельными учетными данными и вообще живущая почти отдельно. Но это усложнение.
Обратите внимание на сеть. Задержки и потери пакетов могут быть причиной тормозов. Важна даже не столько пропускная способность, сколько своевременность доставки и стабильность. Хотя и пропускная способность влияет. Были случаи когда весь канал в интернет у клиентских ПК был забит торрентами и для связи с сервером оставалось всего ничего. Если все в одной локальной сети, то тоже было - трафик бэкапов забивал сеть, снижалась производительность остальных сервисов.
В стандартном клиенте есть даже минимальная диагностика, которая говорит о состоянии канала связи. Иногда на сеть можно повлиять:
антивирусом
сменой сетевого адаптера
сменой драйверов сетевого адаптера
включением UDP
настройкой коммутатора ядра (маршрутизации, если есть)
Power off recovery count мог быть связан просто с плохим контактом диска в салазках. Плохо прикручен, не до конца вставлен, пыль на контактах, проблемный backplane.
Проверить это можно просто подключив диск к тестовому ПК и прогоняя какие-нибудь тесты наблюдая за показателями. Если счетчик перестанет расти, значит с диском все ок.
Soft read errors - не уверен, но это могут быть проблемы совместимости raid контроллера и дисков. То есть это не похоже на износ накопителя, даже на ошибки ПО в накопителе. Хотя на всякий случай я бы поискал прошивку от intel новую.
По поводу скорости в Crystal mark, диски на тестовом стенде точно подключены по SATA 6G? Может случайно по 3G поднялось?
