У версіях Windows Server, що передують Windows Server 2016, створити відмовостійкий кластер з декількох серверів можна було лише між серверами одного домену Active Directory. У новій версії тепер можна створювати двох (і більше) вузлових failover кластерів між серверами в різних доменах, і навіть між серверами робочої групи (взагалі без домену Active Directory).
Природно, що на всіх вузлах кластера необхідно застаріти Windows Server 2016. Підтримуються такі сценарії кластеризації:
На всіх майбутніх вузлах кластера потрібно
- Встановити роль Failover Clustering: Install-WindowsFeature Failover-Clustering –IncludeManagementTools
- На кожній кластерній ноді потрібно створити локальний обліковий запис з правами адміністратора (або використовувати вбудований обліковий запис адміністратора) з однаковими паролями.
net user /add clustadm Pa$$word!
net localgroup administrators clustadm /add - З появою помилки Requested Registry access is not allowed, необхідно змінити в реєстрі параметр віддаленого UAC — цей ключ дозволяє віддалений доступ до адміністративних куль.
New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1 - На всіх вузлах кластера потрібно задати однаковий первинний DNS суфікс (PrimaryDNSsuffix). Це потрібно для того, щоб сервери кластера могли звертатися один до одного за іменами FQDN
- Також потрібно зняти галку Register DNS connection addresses
- У файл hosts на всіх вузлах кластера потрібно внести зміни, щоб сервери могли відрізнити імена інших членів кластера, а також ім'я кластера (у тому числі імена FQDN). Додати імена у файл c:\windows\system32\drivers\etc\hosts можна так:
Set file="%windir%\System32\drivers\etc\hosts"
echo 192.168.1.21 clust-host1 >> %file%
echo 192.168.1.21 clust-host1.mylocal.net >> %file%
echo 192.168.1.22 clust-host2 >> %file%
echo 192.168.1.22 clust-host2.mylocal.net >> %file%
echo 192.168.1.20 cluster1 >> %file%
echo 192.168.1.20 cluster1.mylocal.net>> %file%
Для попередньої валідації вузлів кластера можна скористатися командою:
test-cluster -node "clust-host1.mylocal.net", "clust-host2.mylocal.net"
Для створення кластера через PowerShell потрібно виконати таку команду:
New-Cluster -Name cluster1 -Node clust-host1.mylocal.net, clust-host2.mylocal.net -AdministrativeAccessPoint DNS -StaticAddress 192.168.1.20
Тепер можна перевірити статус кластера та його компонентів командлетами get-cluster і get-clusterresource.
Для підключення (і віддаленого керування) кластером через GUI потрібно скористатися оснащенням Failover Cluster Manager (Входить до складу) RSAT для Windows 10.
Тепер за допомогою пункту меню Connect to cluster можна підключатися до створеного кластера. У разі, якщо в кластері парна кількість серверів, доведеться налаштувати ресурс-свідок. Зазначимо, що як кворумний свідок не можна використовувати мережну папку SMB. Підтримується режим Disk Witness загальний диск (з одночасним доступом до нього з обох вузлів), або Cloud Witness – Хмарний дисковий ресурс в Azure.
За останні кілька років я дуже тісно працюю з кластерами 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 та ключ цього репозиторію:
echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list wget http://download.proxmox .com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg chmod +r /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg # optional, if you have a changed default umaskОновлюємо репозиторії та саму систему:
apt update && apt dist-upgradeПісля успішного оновлення встановимо необхідні пакети Proxmox:
apt install proxmox-ve postfix open-iscsiНотатка: під час встановлення буде налаштовуватися Postfix і grub – одна з них може завершитися помилкою. Можливо, це буде викликано тим, що хостнейм не резолвується на ім'я. Відредагуйте hosts записи та виконайте apt-get update
З цього моменту ми можемо авторизуватись у веб-інтерфейс Proxmox за адресою https://:8006 (зіштовхніться з недовіреним сертифікатом під час підключення).
Зображення 1. Веб-інтерфейс ноди Proxmox
Установка Nginx та Let's Encrypt сертифіката
Мені не дуже подобається ситуація з сертифікатом та IP-адресою, тому я пропоную встановити Nginx і налаштувати Let's Encrypt сертифікат. Установку Nginx описувати не буду, залишу лише важливі файли для роботи Let's encrypt сертифіката:
location ^~ /.well-known/acme-challenge/ < allow all; root /var/lib/letsencrypt/; default_type "text/plain"; try_files $uri = 404; >Команда для випуску SSL сертифіката:
certbot certonly --agree-tos --email [email protected] --webroot -w /var/lib/letsencrypt/ -d proxmox1.domain.name upstream proxmox1.domain.name <server 127.0.0.1:8006; >server < listen 80; server_name proxmox1.domain.name; include snippets/letsencrypt.conf; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name proxmox1.domain.name; access_log /var/log/nginx/proxmox1.domain.name.access.log; error_log /var/log/nginx/proxmox1.domain.name.error.log; include snippets/letsencrypt.conf; ssl_certificate /etc/letsencrypt/live/proxmox1.domain.name/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/proxmox1.domain.name/privkey.pem; location / < proxy_pass https://proxmox1.domain.name; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_redirect off; proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >Не забуваймо після встановлення SSL сертифіката поставити його на автооновлення через cron:
0 */12 * * * /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --renew-hook "systemctl reload nginx"Чудово! Тепер ми можемо звертатися до нашого домену HTTPS.
Нотатка: щоб вимкнути інформаційне вікно про підписку, виконайте цю команду:
sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.serviceНалаштування мережі
Перед підключенням до кластера налаштуємо мережеві інтерфейси на гіпервізорі. Варто відзначити, що налаштування інших нод нічим не відрізняється, крім 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 записах наступним чином (на кожній ноді має бути запис про інші):
172.30.0.15 proxmox1.livelinux.info proxmox1 172.30.0.16 proxmox2.livelinux.info proxmox2 172.30.0.17 proxmox3.livelinux.info proxmox3 Також потрібно додати публічні ключі кожної ноди до інших – це потрібно для створення кластера.
Створимо кластер через веб-панель:
Зображення 6. Створення кластера через веб-інтерфейс
Після створення кластера нам потрібно отримати інформацію про нього. Переходимо в ту ж вкладку кластера і натискаємо кнопку Join Information:
Зображення 7. Інформація про створений кластер
Ця інформація стане нам у нагоді під час приєднання другої та третьої ноди в кластер. Підключаємось до другої ноди та у вкладці Cluster натискаємо кнопку “Join Cluster”:
Зображення 8. Підключення до кластера ноди
Розберемо докладніше параметри для підключення:
- Peer Address: IP-адреса першого сервера (до того, до якого ми підключаємося)
- Password: пароль першого сервера
- Fingerprint: це значення ми отримуємо з інформації про кластер
Зображення 9. Стан кластера після підключення другої ноди
Друга нода успішно підключена! Проте таке буває не завжди. Якщо ви неправильно виконаєте кроки або виникнуть проблеми з мережею, то приєднання до кластера буде провалено, а сам кластер буде “розвалений”. Найкраще рішення — це від'єднати ноду від кластера, видалити на ній всю інформацію про кластер, після чого зробити перезапуск сервера і перевірити попередні кроки. Як же безпечно вимкнути ноду із кластера? Для початку видалимо її з кластера на першому сервері:
Після цього нода буде від'єднана від кластера. Тепер переходимо на зламану ноду та відключаємо на ній такі сервіси:
systemctl stop pvestatd.service systemctl stop pvedaemon.service systemctl stop pve-cluster.service systemctl stop corosync systemctl stop pve-cluster Proxmox кластер зберігає інформацію про себе в базі sqlite, її також необхідно очистити:
sqlite3 /var/lib/pve-cluster/config.db delete from tree where name = 'corosync.conf'; .quit Дані про коросинку успішно видалено. Видалимо файли, що залишилися, для цього необхідно запустити кластерну файлову систему в standalone режимі:
pmxcfs -l rm /etc/pve/corosync.conf rm /etc/corosync/* rm /var/lib/corosync/* rm -rf /etc/pve/nodes/* Перезапускаємо сервер (це необов'язково, але перестрахуємося: всі послуги за підсумком повинні бути запущені і працювати коректно. Щоб нічого не пропустити робимо перезапуск). Після включення ми отримаємо порожню ноду без будь-якої інформації про попередній кластер і можемо розпочати підключення знову.
Встановлення та налаштування ZFS
ZFS – це файлова система, яка може використовуватися разом із Proxmox. За допомогою неї можна дозволити собі реплікацію даних на інший гіпервізор, міграцію віртуальної машини/LXC контейнер, доступ до LXC контейнер з хост-системи і так далі. Установка її досить проста, приступимо до розбору. На моїх серверах є три SSD диски, які ми об'єднаємо в RAID масив.
nano /etc/apt/sources.list.d/stretch-backports.list deb http://deb.debian.org/debian stretch-backports main contrib deb-src http://deb.debian.org/debian stretch- backports main contrib nano /etc/apt/preferences.d/90_zfs Package: libnvpair1linux libuutil1linux libzfs2linux libzpool2linux spl-dkms stretch-backports Pin- Priority: 990 Оновлюємо список пакетів:
Встановлюємо необхідні залежності:
apt install --yes dpkg-dev linux-headers-$(uname -r) linux-image-amd64Встановлюємо сам ZFS:
apt-get install zfs-dkms zfsutils-linuxЯкщо ви в майбутньому отримаєте помилку fusermount: fuse device not found, try 'modprobe fuse' first, виконайте таку команду:
Тепер приступимо безпосередньо до налаштування. Для початку нам потрібно відформатувати SSD та налаштувати їх через parted:
parted /dev/sda (parted) print Model: ATA SAMSUNG MZ7LM480 (scsi) Disk /dev/sda: 480GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: 1 1049kB 4296MB 4295MB primary raid 2 4296MB 4833MB 537MB primary raid 3 4833MB 37,0GB 32,2GB primary raid (parted) mkpart Partition type? primary/extended? primary File system type? [ext2]? zfs Start? 33GB End? 480GB Warning: Ви забрали партію від 33,0GB to 480GB (sectors 64453125..937500000). closest location we can manage is 37,0GB to 480GB (sectors 72353792..937703087). Is this still aceptable to you? Yes/No? yes Аналогічні дії необхідно зробити й інших дисків. Після того, як всі диски підготовлені, приступаємо до наступного кроку:
zpool create -f -o ashift=12 rpool /dev/sda4 /dev/sdb4 /dev/sdc4
Ми вибираємо ashift=12 з міркувань продуктивності – це рекомендація самого zfsonlinux, докладніше про це можна почитати в їх вікі: github.com/zfsonlinux/zfs/wiki/faq
Застосуємо деякі налаштування для ZFS:
zfs set atime=off rpool zfs set compression=lz4 rpool zfs set dedup=off rpool zfs set snapdir=visible rpool zfs set primarycache=all rpool zfs set aclinherit=passthrough rpool zfs inherit acltype rpool zfs get -r acltype rpool zfs get all rpool | grep compressratio Тепер нам треба розрахувати деякі змінні для обчислення zfs_arc_max, я це роблю так:
mem = `free - giga | grep Mem | awk ''` partofmem=$(($mem/10)) echo $setzfscache > /sys/module/zfs/parameters/zfs_arc_max grep c_max /proc/spl/kstat/zfs/arcstats zfs create rpool/data cat > /etc /modprobe.d/zfs.conf /sys/module/zfs/parameters/zfs_arc_max grep c_max /proc/spl/kstat/zfs/arcstatsВ даний момент пул успішно створений, також ми створили сабпул 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 контейнера:
arch: amd64 cores: 3 memory: 2048 nameserver: 8.8.8.8 net0: name=eth0,bridge=vmbr1,firewall=1,gw=172.16.0.1,hwaddr=D6:60:C5:39:98:A0 172.16.0.2/24,type=veth ostype: centos rootfs: local:100/vm-100-disk-1.raw,size=10G swap: 512 unprivileged: Контейнер успішно створено. До LXC контейнерів можна підключатися через команду pct enter , я також перед встановленням додав SSH ключ гіпервізора, щоб підключатися безпосередньо через SSH (PCT має невеликі проблеми з відображенням терміналу). Я підготував сервер і встановив туди всі необхідні додатки, тепер можна перейти до створення реплікації.
Клацаємо на LXC контейнер і переходимо у вкладку "Replication", де створюємо параметр реплікації за допомогою кнопки "Add":
Зображення 12. Створення реплікації в інтерфейсі Proxmox
Зображення 13. Вікно створення Replication job
Я створив завдання реплікувати контейнер на другу ноду, як видно на наступному скріншоті реплікація пройшла успішно – звертайте увагу на поле Status, вона сповіщає про статус реплікації, також варто звертати увагу на поле Duration, щоб знати, скільки триває реплікація даних.
Зображення 14. Список синхронізацій ВМ
Тепер спробуємо змігрувати машину на другу ноду за допомогою кнопки Migrate
Почнеться міграція контейнера, лог можна переглянути у списку завдань там буде наша міграція. Після цього контейнер буде переміщено на другу ноду.
Помилка “Host Key Verification Failed”
Іноді при налаштуванні кластера може виникати подібна проблема – вона заважає мігрувати машини та створювати реплікацію, що нівелює переваги кластерних рішень.Для виправлення цієї помилки видаліть файл known_hosts і підключіться SSH до конфліктної ноди:
/usr/bin/ssh -o 'HostKeyAlias=proxmox2' [email protected] Прийміть Hostkey і спробуйте ввести цю команду, вона повинна підключити вас до сервера:
/usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=proxmox2' [email protected] Особливості мережевих налаштувань на Hetzner
Переходимо в панель Robot і натискаємо кнопку “Virtual Switches”. На наступній сторінці ви побачите панель створення та управління інтерфейсів Virtual Switch: для початку його необхідно створити, а потім підключити виділені сервера до нього. У пошуку додаємо необхідні сервери для підключення – їх не потрібно перезавантажувати, тільки доведеться почекати до 10-15 хвилин, коли підключення до Virtual Switch буде активно.
Після додавання серверів до Virtual Switch через веб-панель підключаємося до серверів та відкриваємо конфігураційні файли мережевих інтерфейсів, де створюємо новий мережевий інтерфейс:
auto enp4s0.4000 iface enp4s0.4000 inet static address 10.1.0.11/24 mtu 1400 vlan-raw-device enp4s0Давайте розберемо докладніше, що таке. За своєю суттю це VLAN, який підключається до єдиного фізичного інтерфейсу під назвою enp4s0 (він у вас може відрізнятися), із зазначенням номера VLAN це номер Virtual Switch'a, який ви створювали в веб-панелі Hetzner Robot. Адреса можете вказати будь-яке, головне, щоб він був локальний.
Зазначу, що конфігурувати enp4s0 слід як завжди, по суті він повинен містити зовнішню IP адресу, яка була видана вашому фізичному серверу. Повторіть ці кроки на інших гіпервізорах, після чого перезавантажте на них networking сервіс, зробіть пінг до сусідньої ноди за адресою Virtual Switch. Якщо пінг пройшов успішно, то ви успішно встановили з'єднання між серверами Virtual Switch.
Я також докладу конфігураційний файл sysctl.conf, він знадобиться, якщо у вас будуть проблеми з форвардингом пакетом та іншими параметрами мережі:
net.ipv6.conf.all.disable_ipv6=0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.all.forwarding=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_syncookies= 1 net.ipv4.ip_forward=1 net.ipv4.conf.all.send_redirects=0 Додавання IPv4 підмережі в Hetzner
Перед початком робіт необхідно замовити підсіти в Hetzner, зробити це можна через панель Robot.
Створимо мережевий міст з адресою, яка буде з цієї підмережі. Приклад конфігурації:
auto vmbr2 iface vmbr2 inet static address ip-address netmask 29 bridge-ports none bridge-stp off bridge-fd 0Тепер переходимо в налаштування віртуальної машини в Proxmox і створюємо новий інтерфейс, який буде прикріплений до мосту vmbr2. Я використовую контейнер LXC, його конфігурацію можна змінювати відразу ж в Proxmox. Підсумкова конфігурація для Debian:
auto eth0 iface eth0 inet static address ip-address netmask 26 gateway bridge-addressЗверніть увагу: я вказав 26 маску, а не 29 – це потрібно для того, щоб мережа на віртуальній машині працювала.
Додавання IPv4 адреси в Hetzner
Ситуація з одиночною IP-адресою відрізняється – зазвичай Hetzner дає нам додаткову адресу з підмережі сервера. Це означає, що замість vmbr2 нам потрібно використовувати vmbr0, але на даний момент його ми не маємо. Суть у тому, що vmbr0 повинен містити IP-адресу залізного сервера (тобто використовувати ту адресу, яка використовувала фізичний мережевий інтерфейс enp2s0). Адресу необхідно перемістити на vmbr0, для цього підійде наступна конфігурація (раджу замовити KVM, щоб у разі чого відновити роботу мережі):
auto enp2s0 iface enp2s0 inet manual auto vmbr0 iface vmbr0 inet static address ip-address netmask 255.255.255.192 gateway ip-gateway bridge-ports enp2s0 bridge-stp off bridge-fd 0 Перезапустіть сервер, якщо це можливо (якщо ні, перезапустіть сервіс networking), а потім перевірте мережеві інтерфейси через ip a:
2: enp2s0: mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000 link/ether 44:8a:5b:2c:30:c2 brd ff:ff:ff:ff:ff:ff Як видно, enp2s0 підключений до vmbr0 і немає IP адресу, оскільки він був перепризначений на vmbr0.
Тепер у налаштуваннях віртуальної машини додаємо мережний інтерфейс, який буде підключений до vmbr0. Як gateway вкажіть адресу, прикріплену до vmbr0.
На завершення
Сподіваюся, що ця стаття стане вам у нагоді, коли ви будете налаштовувати Proxmox кластер в Hetzner. Якщо дозволить час, то я розширю статтю і додам інструкцію для OVH – там теж не все очевидно, як здається на перший погляд. Матеріал вийшов досить об'ємним, якщо знайдете помилки, будь ласка, напишіть у коментарі, я їх виправлю. Дякую всім за приділену увагу.
Автор: Ілля Андрєєв, під редакцією Олексія Жадан та команди «Лайв Лінукс»