2 ответов в этой теме

[stylkovich]

Здравствуйте!

Проконсультируйте, пожалуйста, по сабжу: планируется установка Сервера для обслуживания 250 АРМ пользователей (win10) и 10 серверных виртуалок (WinSrv2019 на vmware 7). Хранить логи нужно минимум год.

Какую конфигурацию виртуалки для него создавать: ядра/оперативная память/объем раздела для хранения данных Сервера? Поиском по форуму искал подобные темы/не нашел. Инструкцию читал, считал, получил 4/8/100GB. Достаточно ли таких характеристик?

[B.Chugunov]

Никаких особых мощностей от машины для обслуживания такого числа агентов не требуется. Того, что Вы указали вполне достаточно. По сути достаточно штатных рекомендуемых сис. требований, указанных в документации. 
О каком-то особом выделении ресурсов по ядрам\ОЗУ можно начинать говорить ИМХО от ~1000 агентов, а скорее даже от 10 000. При 1000 агентов обычно просто рекомендуется пересаживаться с sqlite на внешнюю БД. Хотя много пользователей при таком порядке агентов все равно продолжают сидеть на sqlite и даже всё вполне себе работает. Но это не значит, что это хорошо и так надо делать. 

 

Хранить логи нужно минимум год.

Речь точно о логах, а не о какой-то статистике конкретной? Логи сервера, в зависимости от интенсивности обмена данными и настроек логирования могут и за день весь терабайтный диск сожрать очень легко. Если например повышенную детальность выставить и практически неограниченную ротацию. Хранить их год можно наверное только при условии околонулевой активности агентов по передаче статистики, стабильном соединении, отключении сбора ряда статистики и минимальных уровнях детализации логирования. Но в таком случае и пользы от таких логов практически не будет. Т.е. не ясно, зачем это хранить, как в частном случае, так и в общем. Не ясно и зачем Вам самому логи именно сервера. 
Если речь все таки не про логи, а про какую-то статистику, которая лежит в БД, то здесь все весьма условно. В зависимости от того, что именно требуется хранить(и сколько, но сколько мы уже знаем) - размеры могут очень сильно различаться. Никаких даже приблизительных оценок здесь быть не может, слишком много переменных. Я видел базы, которые за год при схожем порядке числа агентов "раздувало" как до 2 Гб, так и до 200 Гб. И это только база, без учета самих файлов сервера, бэкапов, репозитория и его кэша (в дефолте тоже будет не мало занимать со временем). При условии, что надо хранить много и долго, я бы закладывал минимум 50-100 Гб чисто на базу. И базу в таком случае все таки лучше сменить с sqlite на что-то внешнее, вроде PostgreSQL. С ростом размера sqlite очень плохо справляется. На 10 Гб базе уже очень тяжело будет с сервером работать, если он вообще запустится. На сам сервер, его файлы, без учета БД тех же 50-100 Гб должно хватить с запасом на годы. При необходимости конечно можно будет подрезать хранение каких-нибудь ревизий в репозитории и еще больше снизить занимаемый размер файлов самого сервера. 
Пример - если проводить на всех 250+ станциях какие-нибудь еженедельные запланированные сканирования и собирать за весь год статистику по ошибкам сканирования, то таблицу с этими ошибками в БД легко до нескольких гигабайт может "раздуть", если не до десятков. + к этому статистика самих этих сканирований, найденных угроз и прочего. 
Самые тяжелые по размеру таблицы в БД это обычно - оповещения (чаще неотправленные), статистика Контроля приложений по активности процессов, статистика сканирования, ошибки сканирования. 
Отсюда, если не хочется, чтобы база быстро и неконтролируемо разрослась, нужно:
- Внимательно относиться к настройке оповещений каждого отдельного администратора(у каждого свои настройки). Не создавать неработающих методов. Не включать отправку лишних ненужных оповещений, особенно в неработающих методах, через которые все эти оповещения не смогут быть отправлены. Периодически следить за актуальностью настроенных методов оповещений. 
- Не создавать кучи заданий на сканирования или заданий, которые выполняются очень часто везде, и в целом обдумать, нужны ли они. Если таки нужны - обдумать, требуется ли сбор ошибок сканирования (собираетесь ли Вы их зачем то обрабатывать и соответственно хранить). Если сбор не требуется, либо отключить его, либо снизить время хранения этих данных в БД. Собственно статистику по ошибкам сканирования в целом можно отдельно рассматривать, даже без учета наличия каких-либо заданий на сканирование. Их и в обычном режиме может быть много, но при постоянных плановых сканах число этих данных вырастет кратно. 
- Если будет настраиваться контроль приложений, то обратить внимание на статистику по активности процессов. Насколько она интересна в принципе для сбора, если интересна, реально ли ее требуется хранить целый год. 
Все остальное уже менее вероятно окажет ощутимое влияние на размер БД, хотя всякое бывает. При должном контроле и настройках сбора статистики\очистки базы для годового хранения всех этих данных может с лихвой хватить даже 10-20 Гб. 100 Гб с запасом на несколько лет. Если вообще не следить за всем этим, то и спрогнозировать становится невозможно. 
Ну и в любой ситуации базу можно будет конечно почистить. В таком случае тоже особо много выделять не требуется. Если есть возможность отдать 50-100 Гб, значит отдать их. 

Сообщение было изменено B.Chugunov: 24 Июль 2025 - 15:49

[stylkovich]

Спасибо Вам большое за развернутый ответ