athacker

Валентин выше правильно пишет -- самая простая схема -- это делать ещё и SNAT для трафика, прошедшего через 1-ый микротик к серверу. Но учтите, что при этоё схеме вы потеряете информацию о SRC IP клиента, т. к. с точки зрения сервера, запросы будут приходить от микротика.

И знания микротика здесь ни при чём, разберитесь с тем, как работает маршрутизация.

Дело в том, что на сервере, подключенном к микротику2, этот микротик является шлюзом по умолчанию. Когда вы делаете DNAT на микротике1, то получается следующее:

• Некий клиент из интернета, с белым адресом, скажем 1.2.3.4, шлёт пакет на белый адрес микротика1
  
• Микротик1 получает пакет и делает DNAT -- заменяет свой IP-адрес в поле "DST IP" на серый адрес вашего сервера (192.168.3.10 и отправляет пакет по EoIP в сторону микротика2
  
• Микротик2 получает пакет, видит, что это пакет в его внутреннюю сеть и перенаправляет пакет к серверу 192.168.3.10
  
• Сервер получает пакет от клиента с IP 1.2.3.4, обрабатывает запрос и отправляет ответ. Но этот ответ пойдёт через микротик2, т. к. именно микротик2 является шлюзом по умолчанию для сервера, а про существование микротик1 и то, что запрос от клиента 1.2.3.4 прошёл через микротик1, сервер вообще не в курсе
  

Если же вы сделаете ещё и SRC NAT клиентского пакета, т. е. поменяете адрес клиента (1.2.3.4) на адрес микротик1 (192.168.3.1), то сервер будет отвечать на этот адрес, и ответ сервера достинет микротик1, а он, в свою очередь, сделав обратную трансляцию по таблице NAT, вернёт ответ клиенту. Но, повторюсь, по этой схеме в логах сервера вы не увидите реальных IP клиентов, для запросов, пришедших через микротик1 IP клиента будет 192.168.3.1

P/S/: Напрасно вы сделали EoIP и одну плоскую клиентскую сеть за микротиками. Это только к путанице будет приводить.

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

https://habr.com/post/108690/

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

IT Ops, на мой взгляд, поинтереснее (сам такой потому что), так как задачи разнообразнее. Но в DevOps, например, денег больше платят. Хотя в IT Ops сейчас тоже много из DevOps наприлетало -- Infrastructure as a Code, ansible/chef/puppet, хранение конфигов/плейбуков в VCS, вот это вот всё. И это действительно приводит к тому, что нужно меньше людей, чтобы управлять существенно бОльшими по размеру инфраструктурами. Но и квалификация этих людей тоже должна быть выше, и программерский бэкграунд какой-то тоже нужен. Потому что даже в IT Ops очень много автоматизации, которую нужно писать руками на Shell, Powershell, Python, смотря где как принято.

Отдельный денежный сегмент -- это DBA. Oracle, PostgreSQL, MariaDB -- прокачанных DBA мало, и стоят они дорого. С другой стороны, рынок, где требуются DBA -- довольно узок. И чтобы не было проблем с поиском работы -- квалификация должна быть высокой.

Есть ещё NetOps, т. е. сетевые инженеры. Но там сейчас грустно -- несмотря на то, что для работ в операторских сетях, например, нужна нефиговая такая квалификация и знание особенностей кучи вендорского железа (редко кто строит гомогенные в смысла вендора сетевого железа сети, в основном сборная солянка - -Cisco/Juniper/Mikrotik/Dlink/Huawei), но зарплаты там (по Москве) -- 90-100 тысяч. При этом практикуются ночные/выходные дежурства и всё такое. Можно найти прекрасные места, где сетевой инженер будет зарабатывать бОльшую сумму, но в целом -- как-то так.

Если резюмировать -- в IT Ops ниже порог вхождения в целом. Т. е. можно найти работу, где не требуется серьёзная квалификация, но и денег будет соответственно.

DevOps -- порог вхождения выше, т. к. DevOps подразумевает выполнение вполне конкретного набора задач, и для их выполнения уже вряд ли возьмут человека с улицы, надеясь, что он "по ходу разберётся" (а вот в IT Ops или даже NetOps в мелких и средних конторах ещё может прокатывать). Квалификация требуется выше, но и денег больше.

DBA -- всё ещё сложнее, чем с DevOps. Рынок узкий, квалификация нужна высокая, но зарплаты тоже высоки, повыше DevOps, по моим наблюдениям.

В чистый NetOps сейчас уходить... Ну такоэ... Есть крупные конторы, где этим можно нормально зарабатывать, но всё равно, квалификация требуется высокая, а денег относительно требуемого объёма знаний платят не так уж много. Вот IT Ops + NetOps -- это да, тут можно найти хорошую работу. Но для этого книжек придётся прочитать в полтора раза больше, чем отдельно IT Ops и в два раза больше -- чем отдельно NetOps :-)

FYI: Инсталлятор фряхи работает на уже загруженной и рабочей системе. Там есть консоль и всё такое. Зайдя в консоль, можете делать с дисками что угодно. Например, собрать ZFS пул нужной вам конфигурации.

С другой стороны, инсталлятор уже умеет ставить фрю на ZFS, поэтому в общем случае, даже в консоль лазать не нужно. Возможно, там нельзя будет подключить SSD под L2ARC, но сконфигурить RAIDZ и установить туда систему -- точно можно. А L2ARC можно сконфигурировать позже, загрузившись со свежеустановленной системы.

Ну на ходу Вы вряд ли сможете заменить процессор, а выключенным виртуалкам будет пофиг. После включения оно просто станут жить в новой реальности с новым процом. А вот если у вас в кластере хосты с разными процессорами (особенно разных поколений), тогда да, там могут быть приключения.