Proxmox protection что это

Firewall

Proxmox VE Firewall provides an easy way to protect your IT infrastructure. You can setup firewall rules for all hosts inside a cluster, or define rules for virtual machines and containers. Features like firewall macros, security groups, IP sets and aliases help to make that task easier.

The firewall has full support for IPv4 and IPv6. IPv6 support is fully transparent, and we filter traffic for both protocols by default. So there is no need to maintain a different set of rules for IPv6.

Zones

The Proxmox VE firewall groups the network into the following logical zones:

Traffic from/to a cluster node

Traffic from/to a specific VM

For each zone, you can define firewall rules for incoming and/or outgoing traffic.

Configuration Files

All firewall related configuration is stored on the proxmox cluster file system. So those files are automatically distributed to all cluster nodes, and the pve-firewall service updates the underlying iptables rules automatically on changes.

You can configure anything using the GUI (i.e. Datacenter → Firewall, or on a Node → Firewall), or you can edit the configuration files directly using your preferred editor.

Cluster Wide Setup

The cluster-wide firewall configuration is stored at:

The configuration can contain the following sections:

This is used to set cluster-wide firewall options.

Enable ebtables rules cluster wide.

Enable or disable the firewall cluster wide.

log_ratelimit : [enable=] [,burst= ] [,rate= ]

Log ratelimiting settings

Initial burst of packages which will always get logged before the rate is applied

Enable or disable log rate limiting

Frequency with which the burst bucket gets refilled

This sections contains cluster-wide firewall rules for all nodes.

Cluster wide IP set definitions.

Cluster wide security group definitions.

Cluster wide Alias definitions.

Enabling the Firewall

The firewall is completely disabled by default, so you need to set the enable option here:

If you want to administrate your Proxmox VE hosts from remote, you need to create rules to allow traffic from those remote IPs to the web GUI (port 8006). You may also want to allow ssh (port 22), and maybe SPICE (port 3128).

To simplify that task, you can instead create an IPSet called “management”, and add all remote IPs there. This creates all required firewall rules to access the GUI from remote.

Host Specific Configuration

Host related configuration is read from:

This is useful if you want to overwrite rules from cluster.fw config. You can also increase log verbosity, and set netfilter related options. The configuration can contain the following sections:

This is used to set host related firewall options.

Enable host firewall rules.

Log level for incoming traffic.

Log level for outgoing traffic.

Enable logging of conntrack information.

Enable NDP (Neighbor Discovery Protocol).

nf_conntrack_allow_invalid : (default = 0 )

Allow invalid packets on connection tracking.

Maximum number of tracked connections.

Conntrack established timeout.

Conntrack syn recv timeout.

Enable SMURFS filter.

Enable synflood protection

protection_synflood_burst : (default = 1000 )

Synflood protection rate burst by ip src.

protection_synflood_rate : (default = 200 )

Synflood protection rate syn/sec by ip src.

Log level for SMURFS filter.

Log level for illegal tcp flags filter.

Filter illegal combinations of TCP flags.

This sections contains host specific firewall rules.

VM/Container Configuration

VM firewall configuration is read from:

and contains the following data:

This is used to set VM/Container related firewall options.

Enable/disable firewall rules.

Enable default IP filters. This is equivalent to adding an empty ipfilter-net ipset for every interface. Such ipsets implicitly contain sane default restrictions such as restricting IPv6 link local addresses to the one derived from the interface’s MAC address. For containers the configured IP addresses will be implicitly added.

Log level for incoming traffic.

Log level for outgoing traffic.

Enable/disable MAC address filter.

Enable NDP (Neighbor Discovery Protocol).

Allow sending Router Advertisement.

This sections contains VM/Container firewall rules.

IP set definitions.

IP Alias definitions.

Enabling the Firewall for VMs and Containers

Each virtual network device has its own firewall enable flag. So you can selectively enable the firewall for each interface. This is required in addition to the general firewall enable option.

Firewall Rules

The following options can be used to refine rule matches.

Restrict packet destination address. This can refer to a single IP address, an IP set (+ipsetname) or an IP alias definition. You can also specify an address range like 20.34.101.207-201.3.9.99, or a list of IP addresses and networks (entries are separated by comma). Please do not mix IPv4 and IPv6 addresses inside such lists.

Restrict TCP/UDP destination port. You can use service names or simple numbers (0-65535), as defined in /etc/services. Port ranges can be specified with \d+:\d+, for example 80:85, and you can use comma separated list to match several ports or ranges.

Specify icmp-type. Only valid if proto equals icmp.

Network interface name. You have to use network configuration key names for VMs and containers (net\d+). Host related rules can use arbitrary strings.

Log level for firewall rule.

IP protocol. You can use protocol names (tcp/udp) or simple numbers, as defined in /etc/protocols.

Restrict packet source address. This can refer to a single IP address, an IP set (+ipsetname) or an IP alias definition. You can also specify an address range like 20.34.101.207-201.3.9.99, or a list of IP addresses and networks (entries are separated by comma). Please do not mix IPv4 and IPv6 addresses inside such lists.

Restrict TCP/UDP source port. You can use service names or simple numbers (0-65535), as defined in /etc/services. Port ranges can be specified with \d+:\d+, for example 80:85, and you can use comma separated list to match several ports or ranges.

Here are some examples:

Security Groups

A security group is a collection of rules, defined at cluster level, which can be used in all VMs’ rules. For example you can define a group named “webserver” with rules to open the http and https ports.

Then, you can add this group to a VM’s firewall

IP Aliases

IP Aliases allow you to associate IP addresses of networks with a name. You can then refer to those names:

inside IP set definitions

in source and dest properties of firewall rules

Standard IP Alias local_network

This alias is automatically defined. Please use the following command to see assigned values:

The firewall automatically sets up rules to allow everything needed for cluster communication (corosync, API, SSH) using this alias.

The user can overwrite these values in the cluster.fw alias section. If you use a single host on a public network, it is better to explicitly assign the local IP address

IP Sets

IP sets can be used to define groups of networks and hosts. You can refer to them with ‘+name` in the firewall rules’ source and dest properties.

The following example allows HTTP traffic from the management IP set.

Standard IP set management

This IP set applies only to host firewalls (not VM firewalls). Those IPs are allowed to do normal management tasks (PVE GUI, VNC, SPICE, SSH).

The local cluster network is automatically added to this IP set (alias cluster_network ), to enable inter-host cluster communication. (multicast,ssh,…)

Standard IP set blacklist

Traffic from these IPs is dropped by every host’s and VM’s firewall.

Standard IP set ipfilter-net*

These filters belong to a VM’s network interface and are mainly used to prevent IP spoofing. If such a set exists for an interface then any outgoing traffic with a source IP not matching its interface’s corresponding ipfilter set will be dropped.

For containers with configured IP addresses these sets, if they exist (or are activated via the general IP Filter option in the VM’s firewall’s options tab), implicitly contain the associated IP addresses.

For both virtual machines and containers they also implicitly contain the standard MAC-derived IPv6 link-local address in order to allow the neighbor discovery protocol to work.

Источник

Магия виртуализации: вводный курс в Proxmox VE

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

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

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

Как это устроено

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

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

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

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

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

KVM же напротив, полностью бесплатен и достаточно прост в работе, особенно в составе готового решения на базе Debian Linux под названием Proxmox Virtual Environment. Именно эту систему мы можем порекомендовать для первоначального знакомства с миром виртуальной инфраструктуры.

Как быстро развернуть гипервизор Proxmox VE

Установка чаще всего не вызывает никаких вопросов. Скачиваем актуальную версию образа с официального сайта и записываем его на любой внешний носитель с помощью утилиты Win32DiskImager (в Linux используется команда dd), после чего загружаем сервер непосредственно с этого носителя. Наши клиенты, арендующие у нас выделенные серверы, могут воспользоваться двумя еще более простыми путями – просто смонтировав нужный образ непосредственно из KVM-консоли, либо используя наш PXE-сервер.

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

Веб-интерфейс управления станет доступен по адресу

Что нужно сделать после установки

Есть несколько важных вещей, которые следует выполнить после установки Proxmox. Расскажем о каждой из них подробнее.

Обновить систему до актуальной версии

Для этого зайдем в консоль нашего сервера и отключим платный репозиторий (доступен только тем, кто купил платную поддержку). Если этого не сделать — apt сообщит об ошибке при обновлении источников пакетов.

Позаботиться о безопасности

Исходя из практического опыта, за неделю работы сервера с открытым ssh-портом 22 и внешним статическим IPv4-адресом, было более 5000 попыток подобрать пароль. И около 1500 адресов утилита успешно заблокировала.

Для выполнения установки приводим небольшую инструкцию:

Проверить статус работы утилиты, например, снять статистику блокировок заблокированных IP-адресов с которых были попытки перебора паролей SSH, можно одной простой командой:

Ответ утилиты будет выглядеть примерно так:

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

Начало работы

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

Настроить дисковые накопители

ВНИМАНИЕ! Приведенный ниже пример дисковой разметки можно использовать только для тестовых целей. Для эксплуатации в реальных условиях мы настоятельно рекомендуем использовать программный или аппаратный RAID-массив, чтобы исключить потерю данных при выходе дисков из строя. О том, как правильно приготовить дисковый массив к работе и как действовать в случае аварийной ситуации мы расскажем в одной из следующих статей

Предположим, что физический сервер имеет два диска — /dev/sda, на который установлен гипервизор и пустой диск /dev/sdb, который планируется использовать для хранения данных виртуальных машин. Чтобы система смогла увидеть новое хранилище, можно воспользоваться самым простым и эффективным методом — подключить его как обычную директорию. Но перед этим следует выполнить некоторые подготовительные действия. В качестве примера посмотрим, как подключить новый диск /dev/sdb, любого размера, отформатировав его в файловую систему ext4.

Вывод команды должен показать, что /dev/sdb1 смонтирован в директорию /mnt/storage. Это значит, что наш накопитель готов к работе.

Добавить новое хранилище в Proxmox

Авторизуемся в панели управления и заходим в разделы Датацентр ➝ Хранилище ➝ Добавить ➝ Директория.

В открывшемся окне заполняем следующие поля:

После этого нажимаем кнопку Добавить. На этом настройка завершена.

Создать виртуальную машину

Для создания виртуальной машины выполняем следующую последовательность действий:

Создаем нашу первую виртуальную машину:

Настроить автозапуск

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

Для продвинутых администраторов имеется еще и возможность указать дополнительные параметры запуска в разделе Start/Shutdown order. Можно явным образом указать в каком порядке следует запускать машины. Также можно указать время, которое должно пройти до старта следующей VM и время задержки выключения (если операционная система не успеет завершить работу, гипервизор принудительно ее выключит через определенное количество секунд).

Заключение

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

Proxmox VE — это действительно очень мощный и удобный инструмент для любого системного администратора; главное не бояться экспериментировать и понять, как это действительно работает.

Если у вас появились вопросы, добро пожаловать в комментарии.

Источник

Работа с кластером 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 — там тоже не все очевидно, как кажется на первый взгляд. Материал получился достаточно объемным, если найдете ошибки, то, пожалуйста, напишите в комментарии, я их исправлю. Всем спасибо за уделенное внимание.

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

Источник