Proxmox mail gateway что это такое

Proxmox Mail Gateway кто юзал?

расскажите как оно?

Приветствую Вас! Как Ваши успехи? Все наставляете молодежь?:)

Нужно больше букав о целях и задачах. Например что планируется прикрыть? Эксчендж, сэндмыл или и то и другое?

Тоже интересует как оно в работе.

Примерно как и мэл клинер. 🙂

Сколько ящиков, сколько доменов, сколько писем/час?

я бы тоже послушал отзывы, лень самому тестировать. Но мне кажется, что в данный момент лучшая модульная спаморезка (+ dkim etc) это rspamd

Они ошиблись в том, что изначально хотели за Proxmox mail gate много денег, а теперь уже поздно. Никто не обращает внимание на этот продукт.

Во истину так. Из открытых решений это бест. Но тс хочет иметь гуятину и рулить «из коробки», типа как пфсенс. Я не сторонник этого дерьма, но если возюкать мышой совсем невтерпёж, посмотрите в сторону mail cleaner, если доменов/ящиков не много.

Источник

Proxmox Mail Gateway

Comprehensive Open-Source Email Security Platform

Proxmox Mail Gateway is the leading open-source email security solution helping you to protect your mail server against all email threats from the moment they emerge. The flexible architecture combined with the userfriendly, web-based management interface, allows IT professionals and businesses to control all incoming and outgoing emails with ease, and to protect their users from spam, viruses, phishing and trojans.

Organizations of any size can easily deploy and implement the anti-spam and anti-virus platform in just a few minutes. The full featured mail proxy is deployed between the firewall and the internal mail server, and allows to control all email traffic from a single platform. Proxmox helps you to easily maintain a secure and professional email communication, ensure business continuity, and gain high business reputation as well as customer satisfaction.

Ready to start Proxmox Mail Gateway?

Features

Proxmox Mail Gateway integrates the ClamAV anti virus engine, various filtering methods, the innovative Proxmox Message Tracking Center, HA clustering and more to detect Trojans, viruses, malware and other malicious threats.

Easy Integration into IT

Designed as software appliance, the strength of Proxmox Mail Gateway is its flexibility. It can be easily integrated into your existing email architecture and is compatible to every type of mail transfer agent like MS Exchange, Lotus Domino, or Postfix. Or you can run it as virtual appliance.

Affordable and scalable

A single Proxmox Mail Gateway server can handle unlimited email domains with multiple internal mail servers and millions of emails per day. The flexible subscription model makes it very affordable to scale capacity as your demand grows.

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.

Источник

Proxmox Mail Gateway установка с Microsoft Exchange

Выставлять в интернет корпоративный почтовый сервер плохая идея с точки зрения безопасности. Оптимальным вариантом является использование почтового шлюза, который будет проверять почту на спам и вирусы и уже пересылать ее внутреннему почтовому серверу. В Microsoft Exchange есть собственный вариант установки такого пограничного сервера, но из коробки, как правило, он не умеет ни проверять вирусы, ни фильтровать нормально спам. Приходится докупать решения сторонних разработчиков (например Касперского), чтобы закрыть почтовый траффик от интернет-угроз. Я же обычно использовал собранный вручную почтовый шлюз на Linux с использованием открытых технологий для фильтрации спама и вирусов. Но вот появилось красивое и бесплатное решение — Proxmox Mail Gateway установка которого с Microsoft Exchange не занимает и получаса.

Установка Proxmox Mail Gateway

Что из себя представляет сам продукт. Это сервер под управлением Debian с установленными и настроенными компонентами, а так же функциональным и удобным web-интерфейсом для настройки всего. До 2018 года продукт был закрытым, но с недавних пор разработчики открыли все компоненты под свободной лицензией и продают только поддержку продукта куда входят подписка на платные репозитории для обновления компонент. Но без подписки он тоже прекрасно работает, только для обновлений следует использовать бесплатные репозитории.

Для установки предварительно скачиваем образ установщика на сайте:

А вот здесь вы можете скачать документацию на PMG.

Открытая версия начинается с 5-го выпуска дистрибутива. Перед установкой убедитесь, что сервер соответствует минимальным системным требованиям. У меня установка завершалась ошибкой при нехватки оперативной памяти. Добавил до 4 Гб, пару ядер процессора и все прошло гладко.

В остальном установка весьма тривиальна:

После ввода этих данных начнется установка операционной системы. По окончании вы должны получить возможность войти внутренний ip-адрес сервера по SSH и через веб-браузер по адресу https://ipadres:8006. В качестве логина используется root с паролем, который вы задали во время установки.

Настройка Proxmox Mail Gateway

Сразу после установки мне понадобилось настроить внешний интерфейс для приема почты из интернет. Настроить ip-адрес можно через веб-интерфейс, однако настраивать маршрутизацию все-равно придется редактируя файл описания интерфейсов /etc/network/interfces

Пример отредактированного файла интерфейсов. После внесения всех правок рекомендуется перезагрузить сервер.

Целью всех манипуляций должна стать работающая сеть, работающий резолвинг, доступ в интернет с сервера и на сервер. Если в вашей сети используется какой-то межсетевой экран, то учтите его при настройке.

Следующим шагом необходимо прописать бесплатный репозиторий для обновления компонентов PMG, а так же отключить платный репозиторий, который не будет работать без ключа платной подписки. Для этого необходимо отредактировать файл /etc/apt/sources.list.d/pmg-enterprise.list. Необходимо привести его к следующему виду:

Теперь можно обновить систему:

При необходимости перезагрузить сервер.

Установка дополнительных компонент в Proxmox Mail Gateway

Из дополнительного программного обеспечения я установил лишь несколько утилит, к которым я привык и постоянно использую их в своей работе с Linux системами (в основном Ubuntu). Это Midnight Commander (mc), htop и ufw. Все это делается одной командой:

После установки я включил ufw предварительно добавив в него примерно такие правила:

Все! Снаружи на почтовом шлюзе будет открыт только 25 порт, а из локальной сети вы сможете подключится к серверу по любому порту.

Настройка почтового шлюза Proxmox Mail Gateway

Все остальные настройки делаются через веб интерфейс. Консоль вам понадобится только в случае если нужно будет что-то отладить и оперативно посмотреть логи. Смотреть их можно и в веб-админке, но мне в консоли привычнее.

Первым делом идем в раздел Configuration\Mail proxy. На вкладке Relay domains вбиваем домены на которые мы принимаем почту нашим почтовым шлюзом, т.е. например тот почтовый домен, который прописан у вас в Exchange.

Следующая интересующая нас вкладка Transport. Здесь мы прописываем соответствие домена и внутреннего адреса почтового сервера, например Exchange, куда почтовый шлюз будет пересылать всю чистую корреспонденцию.

И последняя вкладка — это Networks, здесь необходимо прописать внутренние адреса серверов, клиентов, сегментов сети с которых почтовый шлюз будет принимать письма к пересылке. Обратите внимание, что пересылка с этих сетей разрешена только на внутреннем (internal) порту указанному на вкладке Ports. По умолчанию это 26 порт. Иными словами чтобы почта с вашего exchange уходила в интернет через шлюз вы должны прописать его адрес в Networks, а в Exchange указать адрес шлюза и задать ему 26 порт для работы (как это сделать написано ниже).

После этого рекомендую зайти в раздел Spam Detector и Virus Detector и обновить их вручную. Остальные настройки в целом разумны по умолчанию, но вы вольны настраивать их как вам заблагорассудится. Для этого используйте документацию (ссылку я давал вверху).

Настройка коннектора Exchange на работу по нестандартному порту

Ну и напоследок необходимо настроить Send connector в MS Exchange на работу по нестандартному 26-му порту. Создайте коннектор для отправки как обычно, задайте ему осмысленное имя, например по имени хоста почтового шлюза. Затем запустите PowerShell консоль Exchange С помощью команды Get-SendConnector вы можете посмотреть в консоли коннекторы. Скопируйте имя вновь созданного коннектора. После чего введите команду:

Посмотреть, что порт изменился можно командой:

В обеих командах ConnectorName — заменить на имя вашего коннектора! Если все в порядке включайте коннектор и трафик пойдет через новый почтовый шлюз. Не забудьте настроить в DNS mx запись на новый почтовый шлюз, а так же соответствующий ей A и PTR записи.

Замечания, критика, дополнения, опечатки? Прошу в комментарии!

Источник

interface31

Записки IT-специалиста

Анонсы

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

Исходящая почта как передавалась вашим основным сервером, так и будет передаваться. Технически, конечно, возможно и ее пропустить через шлюз, но на практике такое решение вызывает больше проблем, чем предоставляет преимуществ. Такая схема потребует внесения существенных изменений в почтовую инфраструктуру: изменение DNS-записей, правильная настройка заголовков и т.д. В случае неверных настроек вреда будет больше, чем пользы, ваша почта начнет выглядеть подозрительно и будет иметь гораздо более высокие шансы попасть в спам у получателя.

Тем более, что отправку с собственного сервера администратор вполне может контролировать, а если спам вдруг начнет отправлять вредоносное ПО, то оно вряд ли будет это делать через шлюз.

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

Установка системы производится в графическом режиме и не должна вызвать сложностей, если у вас есть опыт установки Linux. Первым шагом нам предлагают настроить конфигурацию дисков, в качестве целей вам будут доступны одиночные диски, для того чтобы получить больше возможностей нажмите Options и появившееся окно даст вам настроить требуемую конфигурацию, например, создать RAID-массив.

Затем потребуется указать регион и часовой пояс, задать пароль суперпользователя и сетевые настройки, после чего будет проведена установка системы.

После установки нас встретит консоль с предложением подключиться к системе через браузер, но не будем спешить. Войдем в систему под суперпользователем root.

Сразу напомним, внутри обычный Debian, поэтому можем делать все, что сочтем нужным, например, доустановить для удобства администрирования Midnight Commander и любые иные утилиты. Но прежде всего следует отключить корпоративный репозиторий Proxmox, который доступен только по подписке:

А затем создадим собственный лист:

И внесем в него следующее содержимое:

Теперь можно перейти в веб-интерфейс, в котором и будет происходить вся работа с почтовым шлюзом. Наберем в браузере указанный адрес, обязательно с указанием защищенного протокола HTTPS, для аутентификации используем пользователя root и указанный при установке пароль. Первоначально админка способна сбить с толку обилием разнообразных пунктов и опций, но сейчас нас интересует окончательная настройка шлюза.

В следующем пункте Relay Domain следует указать все обслуживаемые вашим почтовым сервером домены, в противном случае почта будет отклонена как как нежелательная.

Теперь можно вводить наш шлюз в эксплуатацию, для этого достаточно перенаправить поток почты с порта 25 основного сервера на порт 25 шлюза, обычно для этого достаточно изменить настройку проброса портов на роутере. Точно также все можно быстро вернуть обратно, если вдруг что-то пойдет не так.

А мы пока перейдем в раздел Spam Detector, в этом качестве используется SpamAssassin, из настроек следует также обратить внимание на размер письма и время нахождения спама в карантине, на закладке Update можно вручную обновить набор правил, хотя эта задача выполняется автоматически, по расписанию.

В разделе Virus Detector находятся настройки антивируса ClamAV, здесь также можно запустить его обновление вручную. Однако в этом процессе вы можете получить похожую «ошибку»:

Но повода для беспокойства здесь нет, система обновляет пакеты ClamAV из репозиториев Debian, где последняя версия на момент написания статьи была 0.100.0, а с серверов ClamAV антивирус получил данные о наличии более новой версии 0.101.1. Однако на безопасность это влияет слабо, гораздо более важно своевременное обновление баз, а с этим у нас все в порядке.

Раздел User Management ожидаемо содержит настройки пользователей. Здесь же можно добавить дополнительных пользователей, например, менеджера карантина, которому будет доступно только просмотр и управление письмами в карантине, без возможности изменять настройки сервера. Это позволяет дать определенным пользователям возможность самим проверять попадание нужных писем в карантин, не тревожа лишний раз администраторов, но и не боясь, что они что нибудь сломают по неосторожности.

Также ненадолго заглянем в раздел Administration, на верхнем уровне которого собраны инструменты управления сервером, их немного, но для повседневной работы вполне достаточно. На первом экране собраны графики загрузки сервера, а также кнопки вызова консоли, перезагрузки и выключения.

На других вкладках можно посмотреть состояние служб сервера и статус задач, вывод сообщений syslog в режиме реального времени и проверить наличие обновлений. Там же можно их установить. При этом в отдельном окне открывается консоль и дальнейшее управление процессом обновления производится в нем.

Теперь покинем этот раздел и перейдем на самый верх, в Mail Filter, который содержит настройки фильтрации почты. На верхнем уровне расположены правила, указан их приоритет и направление действия, если выделить любое из них, то справа можно увидеть логику его действия.

Для построения правил используются несколько типов объектов:

Чтобы не быть голословными, составим собственное правило. В качестве вводной примем следующие условия: есть некоторые контрагенты, и их весьма много, которые посылают нам в рабочее время документы в формате PDF или XSL/XSLX с пустым телом письма и возможно даже без темы, документы могут быть в архиве.

Прежде всего перейдем в раздел What Objects и создадим новый объект, назовем его PDF & Excel, в который добавим четыре типа Content Type Filter, в которых укажем документы PDF, ХLS, XLSX и ODS (так как документ Excel давно стал понятием собирательным и нам вполне могут прислать таблицу в формате Open/LibreOffice). Затем добавим четыре типа Archive Filter с тем же самым содержимым, если документ придет запакованным в архив.

Следующим условием задачи у нас стоит время отправки подобной документации, условно примем его с 8:00 до 20:00, перейдем в раздел When Objects и создадим временной промежуток Work Time.

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

И снова перейдем в раздел Administration, теперь нас будет интересовать управление карантином, для начала перейдем в Spam Quarantine. Здесь можно просмотреть письма, попавшие в карантин для каждого почтового ящика. Выбираем период времени и почтовый ящик, и получаем полный список попавших в карантин сообщений.

Для каждого сообщения доступен ряд действий, во первых добавление в персональный черный/белый список, но это действие не изменяет состояние письма, оно остается в карантине, при необходимости мы можем доставить его получателю (Deliver) или удалить (Delete), если не предпринять никаких действий, то такое письмо будет удалено по истечению срока хранения (по умолчанию 7 дней). Аналогичным образом работает и антивирусный карантин.

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

Раздела Statistics мы подробно касаться не будем, там и так все понятно, статистика в различных ее видах.

В заключение хочется сказать, что Proxmox Mail Gateway показал себя как гибкое и эффективное средство борьбы со спамом, поэтому мы можем смело рекомендовать его к внедрению и надеемся, что данная статья окажется вам полезной.

Источник

Работа с кластером Proxmox: установка, настройка сети, ZFS, решение распространенных проблем

За последние несколько лет я очень тесно работаю с кластерами Proxmox: многим клиентам требуется своя собственная инфраструктура, где они могут развивать свой проект. Именно поэтому я могу рассказать про самые распространенные ошибки и проблемы, с которыми также можете столкнуться и вы. Помимо этого мы конечно же настроим кластер из трех нод с нуля.

Proxmox кластер может состоять из двух и более серверов. Максимальное количество нод в кластере равняется 32 штукам. Наш собственный кластер будет состоять из трех нод на мультикасте (в статье я также опишу, как поднять кластер на уникасте — это важно, если вы базируете свою кластерную инфраструктуру на Hetzner или OVH, например). Коротко говоря, мультикаст позволяет осуществлять передачу данных одновременно на несколько нод. При мультикасте мы можем не задумываться о количестве нод в кластере (ориентируясь на ограничения выше).

Сам кластер строится на внутренней сети (важно, чтобы IP адреса были в одной подсети), у тех же Hetzner и OVH есть возможность объединять в кластер ноды в разных датацентрах с помощью технологии Virtual Switch (Hetzner) и vRack (OVH) — о Virtual Switch мы также поговорим в статье. Если ваш хостинг-провайдер не имеет похожие технологии в работе, то вы можете использовать OVS (Open Virtual Switch), которая нативно поддерживается Proxmox, или использовать VPN. Однако, я рекомендую в данном случае использовать именно юникаст с небольшим количеством нод — часто возникают ситуации, где кластер просто “разваливается” на основе такой сетевой инфраструктуры и его приходится восстанавливать. Поэтому я стараюсь использовать именно OVH и Hetzner в работе — подобных инцидентов наблюдал в меньшем количестве, но в первую очередь изучайте хостинг-провайдера, у которого будете размещаться: есть ли у него альтернативная технология, какие решения он предлагает, поддерживает ли мультикаст и так далее.

Установка Proxmox

Proxmox может быть установлен двумя способами: ISO-инсталлятор и установка через shell. Мы выбираем второй способ, поэтому установите Debian на сервер.

Перейдем непосредственно к установке Proxmox на каждый сервер. Установка предельно простая и описана в официальной документации здесь.

Добавим репозиторий Proxmox и ключ этого репозитория:

Обновляем репозитории и саму систему:

После успешного обновления установим необходимые пакеты Proxmox:

Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update

С этого момента мы можем авторизоваться в веб-интерфейс Proxmox по адресу https:// :8006 (столкнетесь с недоверенным сертификатом во время подключения).

Изображение 1. Веб-интерфейс ноды Proxmox

Установка Nginx и Let’s Encrypt сертификата

Мне не очень нравится ситуация с сертификатом и IP адресом, поэтому я предлагаю установить Nginx и настроить Let’s Encrypt сертификат. Установку Nginx описывать не буду, оставлю лишь важные файлы для работы Let’s encrypt сертификата:

Команда для выпуска SSL сертификата:

Не забываем после установки SSL сертификата поставить его на автообновление через cron:

Отлично! Теперь мы можем обращаться к нашему домену по HTTPS.

Заметка: чтобы отключить информационное окно о подписке, выполните данную команду:

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

Создадим сетевой мост для внутренней сети, чтобы наши виртуальные машины (в моем варианте будет LXC контейнер для удобства) во-первых, были подключены к внутренней сети гипервизора и могли взаимодействовать друг с другом. Во-вторых, чуть позже мы добавим мост для внешней сети, чтобы виртуальные машины имели свой внешний IP адрес. Соответственно, контейнеры будут на данный момент за NAT’ом у нас.

Работать с сетевой конфигурацией Proxmox можно двумя способами: через веб-интерфейс или через конфигурационный файл /etc/network/interfaces. В первом варианте вам потребуется перезагрузка сервера (или можно просто переименовать файл interfaces.new в interfaces и сделать перезапуск networking сервиса через systemd). Если вы только начинаете настройку и еще нет виртуальных машин или LXC контейнеров, то желательно перезапускать гипервизор после изменений.

Теперь создадим сетевой мост под названием vmbr1 во вкладке network в веб-панели Proxmox.

Изображение 2. Сетевые интерфейсы ноды proxmox1

Изображение 3. Создание сетевого моста

Изображение 4. Настройка сетевой конфигурации vmbr1

Настройка предельно простая — vmbr1 нам нужен для того, чтобы инстансы получали доступ в Интернет.

Теперь перезапускаем наш гипервизор и проверяем, создался ли интерфейс:

Изображение 5. Сетевой интерфейс vmbr1 в выводе команды ip a

Заметьте: у меня уже есть интерфейс ens19 — это интерфейс с внутренней сетью, на основе ее будет создан кластер.

Повторите данные этапы на остальных двух гипервизорах, после чего приступите к следующему шагу — подготовке кластера.

Также важный этап сейчас заключается во включении форвардинга пакетов — без нее инстансы не будут получать доступ к внешней сети. Открываем файл sysctl.conf и изменяем значение параметра net.ipv4.ip_forward на 1, после чего вводим следующую команду:

В выводе вы должны увидеть директиву net.ipv4.ip_forward (если не меняли ее до этого)

Настройка Proxmox кластера

Теперь перейдем непосредственно к кластеру. Каждая нода должна резолвить себя и другие ноды по внутренней сети, для этого требуется изменить значения в hosts записях следующих образом (на каждой ноде должна быть запись о других):

Также требуется добавить публичные ключи каждой ноды к остальным — это требуется для создания кластера.

Создадим кластер через веб-панель:

Изображение 6. Создание кластера через веб-интерфейс

После создания кластера нам необходимо получить информацию о нем. Переходим в ту же вкладку кластера и нажимаем кнопку “Join Information”:

Изображение 7. Информация о созданном кластере

Данная информация пригодится нам во время присоединения второй и третьей ноды в кластер. Подключаемся к второй ноде и во вкладке Cluster нажимаем кнопку “Join Cluster”:

Изображение 8. Подключение к кластеру ноды

Разберем подробнее параметры для подключения:

Вторая нода успешно подключена! Однако, такое бывает не всегда. Если вы неправильно выполните шаги или возникнут сетевые проблемы, то присоединение в кластер будет провалено, а сам кластер будет “развален”. Лучшее решение — это отсоединить ноду от кластера, удалить на ней всю информацию о самом кластере, после чего сделать перезапуск сервера и проверить предыдущие шаги. Как же безопасно отключить ноду из кластера? Для начала удалим ее из кластера на первом сервере:

После чего нода будет отсоединена от кластера. Теперь переходим на сломанную ноду и отключаем на ней следующие сервисы:

Proxmox кластер хранит информацию о себе в sqlite базе, ее также необходимо очистить:

Данные о коросинке успешно удалены. Удалим оставшиеся файлы, для этого необходимо запустить кластерную файловую систему в standalone режиме:

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

Установка и настройка ZFS

ZFS — это файловая система, которая может использоваться совместно с Proxmox. С помощью нее можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. Установка ее достаточно простая, приступим к разбору. На моих серверах доступно три SSD диска, которые мы объединим в RAID массив.

Обновляем список пакетов:

Устанавливаем требуемые зависимости:

Устанавливаем сам ZFS:

Если вы в будущем получите ошибку fusermount: fuse device not found, try ‘modprobe fuse’ first, то выполните следующую команду:

Теперь приступим непосредственно к настройке. Для начала нам требуется отформатировать SSD и настроить их через parted:

Аналогичные действия необходимо произвести и для других дисков. После того, как все диски подготовлены, приступаем к следующему шагу:

Мы выбираем ashift=12 из соображений производительности — это рекомендация самого zfsonlinux, подробнее про это можно почитать в их вики: github.com/zfsonlinux/zfs/wiki/faq#performance-considerations

Применим некоторые настройки для ZFS:

Теперь нам надо рассчитать некоторые переменные для вычисления zfs_arc_max, я это делаю следующим образом:

В данный момент пул успешно создан, также мы создали сабпул data. Проверить состояние вашего пула можно командой zpool status. Данное действие необходимо провести на всех гипервизорах, после чего приступить к следующему шагу.

Теперь добавим ZFS в Proxmox. Переходим в настройки датацентра (именно его, а не отдельной ноды) в раздел «Storage», кликаем на кнопку «Add» и выбираем опцию «ZFS», после чего мы увидим следующие параметры:

ID: Название стораджа. Я дал ему название local-zfs
ZFS Pool: Мы создали rpool/data, его и добавляем сюда.
Nodes: указываем все доступные ноды

Данная команда создает новый пул с выбранными нами дисками. На каждом гипервизоре должен появится новый storage под названием local-zfs, после чего вы сможете смигрировать свои виртуальные машины с локального storage на ZFS.

Репликация инстансов на соседний гипервизор

В кластере Proxmox есть возможность репликации данных с одного гипервизора на другой: данный вариант позволяет осуществлять переключение инстанса с одного сервера на другой. Данные будут актуальны на момент последней синхронизации — ее время можно выставить при создании репликации (стандартно ставится 15 минут). Существует два способа миграции инстанса на другую ноду Proxmox: ручной и автоматический. Давайте рассмотрим в первую очередь ручной вариант, а в конце я предоставлю вам Python скрипт, который позволит создавать виртуальную машину на доступном гипервизоре при недоступности одного из гипервизоров.

Для создания репликации необходимо перейти в веб-панель Proxmox и создать виртуальную машину или LXC контейнер. В предыдущих пунктах мы с вами настроили vmbr1 мост с NAT, что позволит нам выходить во внешнюю сеть. Я создам LXC контейнер с MySQL, Nginx и PHP-FPM с тестовым сайтом, чтобы проверить работу репликации. Ниже будет пошаговая инструкция.

Загружаем подходящий темплейт (переходим в storage —> Content —> Templates), пример на скриншоте:

Изображение 10. Local storage с шаблонами и образами ВМ

Нажимаем кнопку “Templates” и загружаем необходимый нам шаблон LXC контейнера:

Изображение 11. Выбор и загрузка шаблона

Теперь мы можем использовать его при создании новых LXC контейнеров. Выбираем первый гипервизор и нажимаем кнопку “Create CT” в правом верхнем углу: мы увидим панель создания нового инстанса. Этапы установки достаточно просты и я приведу лишь конфигурационный файл данного LXC контейнера:

Кликаем на LXC контейнер и переходим во вкладку “Replication”, где создаем параметр репликации с помощью кнопки “Add”:

Изображение 12. Создание репликации в интерфейсе Proxmox

Изображение 13. Окно создания Replication job

Я создал задачу реплицировать контейнер на вторую ноду, как видно на следующем скриншоте репликация прошла успешно — обращайте внимание на поле “Status”, она оповещает о статусе репликации, также стоит обращать внимание на поле “Duration”, чтобы знать, сколько длится репликация данных.

Изображение 14. Список синхронизаций ВМ

Теперь попробуем смигрировать машину на вторую ноду с помощью кнопки “Migrate”

Начнется миграция контейнера, лог можно просмотреть в списке задач — там будет наша миграция. После этого контейнер будет перемещен на вторую ноду.

Ошибка “Host Key Verification Failed”

Иногда при настройке кластера может возникать подобная проблема — она мешает мигрировать машины и создавать репликацию, что нивелирует преимущества кластерных решений. Для исправления этой ошибки удалите файл known_hosts и подключитесь по SSH к конфликтной ноде:

Примите Hostkey и попробуйте ввести эту команду, она должна подключить вас к серверу:

Особенности сетевых настроек на Hetzner

Переходим в панель Robot и нажимаем на кнопку “Virtual Switches”. На следующей странице вы увидите панель создания и управления интерфейсов Virtual Switch: для начала его необходимо создать, а после “подключить” выделенные сервера к нему. В поиске добавляем необходимые сервера для подключения — их не не нужно перезагружать, только придется подождать до 10-15 минут, когда подключение к Virtual Switch будет активно.

После добавления серверов в Virtual Switch через веб-панель подключаемся к серверам и открываем конфигурационные файлы сетевых интерфейсов, где создаем новый сетевой интерфейс:

Давайте разберем подробнее, что это такое. По своей сути — это VLAN, который подключается к единственному физическому интерфейсу под названием enp4s0 (он у вас может отличаться), с указанием номера VLAN — это номер Virtual Switch’a, который вы создавали в веб-панели Hetzner Robot. Адрес можете указать любой, главное, чтобы он был локальный.

Отмечу, что конфигурировать enp4s0 следует как обычно, по сути он должен содержать внешний IP адрес, который был выдан вашему физическому серверу. Повторите данные шаги на других гипервизорах, после чего перезагрузите на них networking сервис, сделайте пинг до соседней ноды по IP адресу Virtual Switch. Если пинг прошел успешно, то вы успешно установили соединение между серверами по Virtual Switch.

Я также приложу конфигурационный файл sysctl.conf, он понадобится, если у вас будут проблемы с форвардингом пакетом и прочими сетевыми параметрами:

Добавление IPv4 подсети в Hetzner

Перед началом работ вам необходимо заказать подсеть в Hetzner, сделать это можно через панель Robot.

Создадим сетевой мост с адресом, который будет из этой подсети. Пример конфигурации:

Теперь переходим в настройки виртуальной машины в Proxmox и создаем новый сетевой интерфейс, который будет прикреплен к мосту vmbr2. Я использую LXC контейнер, его конфигурацию можно изменять сразу же в Proxmox. Итоговая конфигурация для Debian:

Обратите внимание: я указал 26 маску, а не 29 — это требуется для того, чтобы сеть на виртуальной машине работала.

Добавление IPv4 адреса в Hetzner

Ситуация с одиночным IP адресом отличается — обычно Hetzner дает нам дополнительный адрес из подсети сервера. Это означает, что вместо vmbr2 нам требуется использоваться vmbr0, но на данный момент его у нас нет. Суть в том, что vmbr0 должен содержать IP адрес железного сервера (то есть использовать тот адрес, который использовал физический сетевой интерфейс enp2s0). Адрес необходимо переместить на vmbr0, для этого подойдет следующая конфигурация (советую заказать KVM, чтобы в случае чего возобновить работу сети):

Перезапустите сервер, если это возможно (если нет, перезапустите сервис networking), после чего проверьте сетевые интерфейсы через ip a:

Как здесь видно, enp2s0 подключен к vmbr0 и не имеет IP адрес, так как он был переназначен на vmbr0.

Теперь в настройках виртуальной машины добавляем сетевой интерфейс, который будет подключен к vmbr0. В качестве gateway укажите адрес, прикрепленный к vmbr0.

В завершении

Надеюсь, что данная статья пригодится вам, когда вы будете настраивать Proxmox кластер в Hetzner. Если позволит время, то я расширю статью и добавлю инструкцию для OVH — там тоже не все очевидно, как кажется на первый взгляд. Материал получился достаточно объемным, если найдете ошибки, то, пожалуйста, напишите в комментарии, я их исправлю. Всем спасибо за уделенное внимание.

Автор: Илья Андреев, под редакцией Алексея Жадан и команды «Лайв Линукс»

Источник