Неприятный инцидент в ЦОД с сервером. Монолит - это риск

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

Главный вывод: Монолит — это зло.

До этого момента ключевые сервисы (1С, MS SQL, RDP-сервер для разработчиков) жили на одной физической машине (Сервер 2). ИБ-инцидент наглядно показал: любая проблема на этом хосте — будь то зловред, неудачное обновление ОС или аппаратный сбой — парализует всю работу компании. Это недопустимый бизнес-риск.
Век виртуализации наступил давно, и наша инфраструктура очевидно от него отстала. Пора это исправлять.

Я, хоть и директор, глубоко погружен в технические процессы компании. Я убежден, что, прежде чем нанимать администратора или подрядчика для построения новой архитектуры, я должен сам хорошо понять другие варианты, риски и лучшие практики. Только так можно сформировать грамотное ТЗ и принять правильное решение.

Что мы имеем (Дано):

1. ЦОД
- 4 "белых" IP-адреса.
- Маршрутизатор Mikrotik для управления трафиком.
- Канал 200 Мбит/с.

2. Сервер 1 (Младший хост)
- 1U Supermicro, 2 x Xeon E5-2650 v3.
- 190 ГБ ОЗУ.
- SSD-накопители (2 x 480 ГБ Intel, 1 x 960 ГБ Intel).
- Ранее использовался для демо-сервера 1С, бэкапов с Сервера 2 и тестовых VM.

3. Сервер 2 (Старший хост)
- 2U HPE 10 Gen, 2 x Intel XEON 6248R.
- 512 ГБ ОЗУ.
- Высокопроизводительные накопители (SAS SSD 1.6 ТБ x2, NVMe PCI-E 3.2 ТБ x1).
- Архивные HDD (SAS 16 ТБ x2).
- Ранее нес на себе всю основную нагрузку: 1С, MS SQL, RDP, GitLab, GitLab-раннеры, тестовые Linux-машины.

Для Сервера 2 уже заказан апгрейд, который добавит еще 256 ГБ ОЗУ, пару быстрых SAS SSD PM1643a по 3.84 ТБ и дополнительный HDD Exos на 18 ТБ.
Первый сервер послабее, второй достаточно не плохой. Использовать их как два изолированных "монолита" — преступление.

Постановка задачи: Новая архитектура

Цель — построить отказоустойчивую, безопасную и масштабируемую инфраструктуру, используя имеющееся железо.
Очевидный путь — виртуализация. Но просто разнести сервисы по VM на одном хосте — это полумера, которая не решает проблему отказа самого хоста.
Поэтому я думаю о построении HA-кластера (High Availability) на базе двух этих серверов.
В идеале при падении физического Сервера 2 все его критичные виртуальные машины (1С, SQL, RDP) должны автоматически перезапуститься на Сервере №1 c минимальным простоем.

Это порождает три главных вопроса, по которым я и хочу посоветоваться с сообществом.

Вопросы к профи

1. Платформа виртуализации
Что выбрать для построения отказоустойчивого кластера на двух нодах?
- Hyper-V: Логичный выбор для Windows. Но как лучше организовать общее хранилище? Использовать Storage Spaces Direct (S2D), связывая две ноды?
- Proxmox: Выглядит очень привлекательно. Open-source, HA-кластер и бэкапы "из коробки", отлично работает с Linux VM (KVM). Насколько он стабилен для высоконагруженных Windows-машин (MS SQL, 1C, RDP)? Кто использует в проде, какие подводные камни?
- VMware vSphere: Вариант серьезно не рассматриваю. Думаю это будет слишком дорого.
2. Сетевая изоляция
Просто разнести сервисы по VM недостаточно. Если зловред попадет в одну VM, он не должен иметь доступ к другим. Я планирую использовать Mikrotik для жесткой сетевой сегментации (VLAN). Какие здесь лучшие практики?
3. Отказоустойчивые бэкапы
Инцидент показал, что бэкапы, лежащие на соседнем сервере в той же сети не панацея. Шифровальщик мог бы добраться и до них. Какой софт используете для бэкапа VM в кластере? Куда лучше всего отправлять третью копию (S3-совместимое облако, съемные диски, другой ЦОД)?

Цель — построить прочный фундамент для ИТ-инфраструктуры, который переживет и сбой железа, и атаку, не останавливая бизнес. Буду благодарен за любой конструктивный совет и обмен реальным опытом.