Модернизация инфраструктуры Rapidsoft в DAPL: анализ и предложения

1. Краткий анализ и предложения по модернизации инфраструктуры rapidsoft в DAPL

2.

Рассмотрим инфраструктуру с 5-ти позиций:
1. Серверная инфраструктура и виртуализация
2. Мониторинг
3. Безопасность
4. Резервное копирование
5. Сетевая инфраструктура

3. Серверная инфраструктура и виртуализация, анализ.

В данный момент в DAPL установлены следующие сервера:
1. HV0 (Xeon E5-2630 12/24 C/T, 256GB DDR3 (исп. 62%), Win Server 2012)
2. HV1 (Xeon E5-2640 12/24 C/T, 96GB DDR3 (88%), Win Server 2022 Datacenter)
3. HV2 (Xeon E5-2670 16/32 C/T, 192GB DDR3 (85%), Win Server 2019)
4. HV3 (Xeon E5-2670 16/32 C/T, 192GB DDR3 (84%), Win Server 2019)
5. HV4 (Xeon E5645 12/24 C/T, 48GB DDR3 (60%), Win Server 2022 Datacenter)
6. Backup0 (Athlon 4/4 C/T, 6GB DDR2 (76%), Win Server 2012 R2)
7. Backup3 (i7-3770 4/8 C/T, 8GB DDR3 (82%), Win 10 Pro)
8. Storage0 (Xeon E5-2620 6/12 C/T, 8GB DDR3 (9%), Debian 12 Bookworm)
9. pfSense (Xeon E3-1230 V2 4/8 C/T, 16GB DDR3 (5%), FreeBSD14.0)

4. Серверная инфраструктура и виртуализация, предложения.

Я считаю, что инфраструктура в том виде, в котором она есть сейчас:
1) Показывает низкую производительность.
2) Не является гибкой, т.е. не позволяет, при необходимости, оперативно
перераспределять виртуальные ресурсы между гипервизорами.
3) Не имеет централизованного управления.
4) Объединена вокруг Windows-экосистемы, но при этом почти везде
разные версии ОС.
5) Смешана в одну большую кучу. В идеальной инфраструктуре – один
сервер=одна роль. (к примеру один гипервизор=только виртуальные
машины/контейнеры для целей разработки/тестирования)

5. Серверная инфраструктура и виртуализация, предложения.

Необходимо начать с проведения поэтапной ревизии всех имеющихся ресурсов (как физических, так и
виртуальных).
Нужно выявить все неактуальные виртуальные машины и диски и принимать решение об их полном
удалении или о переносе на сервера с бэкапами.
Также, необходим детальный анализ дисковой подсистемы на каждом из серверов. Я уже могу назвать
как минимум один сервер, диски которого (Samsung SSD NVMe 6.4Tb) используются не так, как должны,
но при этом два этих диска могут дать существенный прирост в производительности всей инфраструктуры
при правильном распределении их по гипервизорам (повторюсь, необходим детальный анализ каждого
частного случая).
Как только мы поймём, что у нас не осталось ничего лишнего в инфраструктуре – считаю необходимым
поднимать вопрос о пересмотре ролей каждого из серверов и переходе от Windows Hyper-V к open-source
Proxmox Virtual Environment (Proxmox VE) в качестве гипервизора.
Это будет не быстрый и не дешёвый процесс, однако только он, как мне кажется, позволит нам построить
современную (на сколько это возможно, с учётом устаревшего «железа»), гибкую и централизованную
инфраструктуру.
Всё это необходимо дополнительно подробно рассчитывать в плане затрат времени, денег и труда.

6. Мониторинг, анализ.

Мониторинг осуществляется сервером Zabbix. На данный момент вся
физическая, виртуальная и сетевая инфраструктура покрывается
мониторингом.
Для наглядности была создана инфраструктурная карта.
https://zabbix.rapidsoft.ru/zabbix.php?action=map.view&sysmapid=4
В целом, считаю, что с таким мониторингом можно жить и работать, однако
в самом Zabbix необходимо проводить ревизию по добавленным в него
хостам, по их логическому группированию и тд.

7.

8. Безопасность, анализ.

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

9. Безопасность, предложение.

Предлагаю этот вопрос закрыть при помощи open-source решения Wazuh.
https://wazuh.com
Это клиент-серверная платформа, содержащая в себе SIEM, IDS и IPS
(Intrusion Detection/Prevention).
Даже если у нас не хватит ресурсов мониторить всю инфраструктуру, нам
необходимо как минимум мониторить критические узлы (pfSense, git, jira и
тд.)

10. Резервное копирование, анализ.

У нас есть два сервера резервного копирования. В рамках SYSOPS-1575 я
проверил процесс резервного копирования и восстановления из резервных
копий и, частично, убедился в его работоспособности.
Однако, есть замечания по процессу резервного копирования:
1) Мы используем крякнутый Veeam Backup и Replication (поправьте, если не
прав). Официально и штатно обновлять это решение не представляется
возможным
2) В процессе резервного копирования у нас ложится вся инфраструктура из-за
нагрузки на сеть и диски, такого быть не должно. Никак.
3) Мы не можем централизованно управлять процессом резервного
копирования

11. Резервное копирование, предложение.

В случае, если мы принимаем решение о переходе на Proxmox Virtual
Environment (Proxmox VE) вместо Microsoft Hyper-V в роли основного
гипервизора, мы можем перестроить все процессы, связанные с резервным
копированием и восстановлением из резервных копий, под open-source
решение Proxmox Backup Server (Proxmox BS)
Proxmox BS интегрируется в Proxmox VE и позволяет нам централизованно
управлять всеми процессами резервного копирования и восстановления,
при этом находясь в рамках единой программной экосистемы.

12. Сетевая инфраструктура, анализ.

Сетевая инфраструктура построена в рамках одного общего «сетевого
домена», без разделения на VLAN, но с разделением на разные подсети.
Пока что у меня практически нет информации о физической коммутации
сетевых устройств с серверами и серверов между собой.
Мониторинг Zabbix показывает, что в периоды пиковых нагрузок на сеть (в
моменты создания резервных копий) мы сталкиваемся с недостаточной
пропускной способностью сети. Пока что не совсем понятно, что является
узким местом в сети. Данных в сетевой документации практически нет.
Документацию необходимо создавать с 0.

13. Сетевая инфраструктура, предложение.

В первую очередь необходимо разработать документацию, которая бы
описывала всё сетевое взаимодействие каждого из узлов, находящихся в
сети (L2-карта сетевого взаимодействия, для начала. Потом можно
подумать и о создании L3-карты).
Затем, необходимо проанализировать достаточность пропускной
способности всех сетевых интерфейсов на всех устройствах.
После того, как карта будет составлена и анализ пропускной способности
будет завершён, на основе полученных данных необходимо принимать
решение о модернизации сетевых устройств там, где сеть является узким
местом.