Аспро: ЛайтШоп [тема: CEPH по проблеме обновления узла]

CEPH по проблеме обновления узла

Thu, 28 Jan 2021 12:34:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Используйте NAT или (если у вас есть подсеть) маршрутизируйте публичные IP-адреса. Это похоже на маршрутизацию частных IP-сетей. Я не совсем понимаю, что вы имеете в виду под 'умирает', но dd-wrt будет шлюзом для этих гостей. У вас есть больше одного интернет-соединения? В основном, когда модем выходит из строя, резервация не будет иметь большого смысла (если это единственная цель). Менее сложным решением было бы иметь резервный сервер, который легко заменить.
28.01.2021 12:34:00, Alwin Antreich.

CEPH по проблеме обновления узла

Wed, 27 Jan 2021 22:11:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Моя цель — избавиться от DD-WRT и заменить его на какую-то конфигурацию с двумя маршрутизаторами для резервирования. У меня есть все эти сервера Dell R210II с 6 NIC-картами, и я надеялся на использование bare metal pf/opnsense или какого-то варианта фаервола с лучшим резервированием и обнаружением угроз, например, ClearOS... кто знает... в любом случае, идеи приветствуются. У меня есть единая точка отказа — это DD-WRT между узлами Proxmox и uplink WAN к провайдеру, нужно решить эту проблему. Я считаю, что маршрутизатор DD-WRT настроен просто на переадресацию и трансляцию всего, что хорошо работает до и после входящего и исходящего трафика... это может быть отдельная тема для обсуждения. Я был бы рад просто оставить его вне картинки и использовать исключительно для Wi-Fi для домашних устройств, а узлы отделить под другой вариант. У меня есть 5 публичных IP-адресов, которые я должен назначить определённым виртуальным машинам и настроить доменные сертификаты для субдоменов, которые я буду размещать локально, в то время как остальные сервисы (почта, MySQL, веб-хостинг и другие доменные услуги) находятся на удалённом сервере в центре обработки данных. Вопрос в том, как сделать так, чтобы виртуальная машина получила публичный IP напрямую... когда маршрутизируешь трафик из интернета на эти IP-адреса, он останавливается на DD-WRT и не может продвинуться дальше. У меня на DD-WRT установлен один из этих адресов, и это работает нормально, и я, конечно, могу перенаправить любой порт, который мне нужен, но это не решает мою более серьезную проблему — передачи IP-трафика для публичного IP с учетом каждого IP на конкретную виртуальную машину.
27.01.2021 22:11:00, GoZippy.

CEPH по проблеме обновления узла

Mon, 25 Jan 2021 21:55:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Судя по строкам iptables, это NAT. Все публичные IP-адреса завершаются на маршрутизаторе. Гости за маршрутизатором будут видеть только внутренний IP. Маршрутизатор переписывает его в соответствии с правилами iptables. Лучше перенаправлять только те порты, которые действительно нужны. Маршрутизация сети будет означать использование IP из публичной подсети на маршрутизаторе в качестве шлюза. И предоставление вышестоящему маршрутизатору информации о маршрутизации (если это еще не сделано провайдером). Это также должно быть отделено в отдельную зону безопасности.
25.01.2021 21:55:00, Alwin Antreich.

CEPH по проблеме обновления узла

Mon, 25 Jan 2021 19:45:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Да, я могу настроить мост для диапазонов частных IP-адресов... но пока не понял, как отправить публичный IP-адрес в виртуальную машину... У меня оптоволоконный модем от провайдера - коммутатор - DDWRT - КОММУТАТОР - узлы кластера, модем провайдера в режиме passthru (но также обслуживает своих клиентов с прямыми подключениями 192.168.1.x). WAN DDWRT назначен на публичный IP, я настроил маршрутизацию через DDWRT для публичных IP (по-моему). StartupWANIF=`nvram get wan_iface` WANMASK=`nvram get wan_netmask` ifconfig $WANIF:1 104.8.233.106 netmask $WANMASK broadcast 104.8.233.111 ifconfig $WANIF:2 104.8.233.107 netmask $WANMASK broadcast 104.8.233.111 ifconfig $WANIF:3 104.8.233.108 netmask $WANMASK broadcast 104.8.233.111 ifconfig $WANIF:4 104.8.233.109 netmask $WANMASK broadcast 104.8.233.111 Firewall# WAN .106 -> LAN .6 iptables -t nat -I PREROUTING -d 104.8.233.106 -j DNAT --to 10.0.1.6 iptables -t nat -I POSTROUTING -s 10.0.1.6 -j SNAT --to 104.8.233.106 iptables -I FORWARD -d 10.0.1.6 -j ACCEPT # WAN .107 -> LAN .7 iptables -t nat -I PREROUTING -d 104.8.233.107 -j DNAT --to 10.0.1.7 iptables -t nat -I POSTROUTING -s 10.0.1.7 -j SNAT --to 104.8.233.107 iptables -I FORWARD -d 10.0.1.7 -j ACCEPT # WAN .108 -> LAN .8 iptables -t nat -I PREROUTING -d 104.8.233.108 -j DNAT --to 10.0.1.8 iptables -t nat -I POSTROUTING -s 10.0.1.8 -j SNAT --to 104.8.233.108 iptables -I FORWARD -d 10.0.1.8 -j ACCEPT # WAN .109 -> LAN .9 iptables -t nat -I PREROUTING -d 104.8.233.109 -j DNAT --to 10.0.1.9 iptables -t nat -I POSTROUTING -s 10.0.1.9 -j SNAT --to 104.8.233.109 iptables -I FORWARD -d 10.0.1.9 -j ACCEPT ------------------ ------------------ У меня сторона LAN DDWRT подключена к коммутатору, который идет к серверам на порту eno1 (хотя некоторые из них показывают, как будто физически подключены к диапазону enpsof... странно). В любом случае, я назначаю eno1 и vmbridge vmbr0 на eno1 с диапазоном 10.0.1.x. У меня vmbr0 как основной сетевой интерфейс для каждой виртуальной машины на этом сервере на данный момент. Я прошу виртуальную машину с Ubuntu получить публичный IP, например 104.8.233.109, и это, похоже, не срабатывает. Если я попрошу ее получить IP из диапазона 10.0.x.x (/16), который у меня настроен на DDWRT и в другой сети, все работает нормально... но мне нужно использовать эти IP и все диапазоны портов, чтобы не путать переадресацию портов только с одним IP, который забирает DDWRT... Жду идей... Читал много форумов по настройке сети, но ни один из них не показывает, как подключить публичный IP к частному маршрутизатору с частной локальной сетью, смешанной с переадресацией публичного IP через сервер к виртуальной машине, которая получает этот публичный IP за частной сетью... Я надеялся, что режим passthru на маршрутизаторе/модеме провайдера с маршрутизацией на DDWRT сделает это напрямую для этих серверов, чтобы виртуальная машина могла просто подключиться и получить его... Проблема, которую я вижу, заключается в проблемах с шлюзом и маскарадином... Если vmbr0 находится на 10.0.1.100 с шлюзом, установленным на 10.0.0.1 (DDWRT), я нахожусь в этом подсети и не могу получить публичные IP-адреса 104.8.233.x... Я добавил vmbr1, связанный с другим портом (каждый сервер имеет 2 встроенных и 4 на сетевой карте 1Gb). Все еще пытаюсь разобраться, какое лучшее настройки для сети на каждом сервере Proxmox, чтобы гарантировать, что я смогу назначать публичные IP конкретным экземплярам и иметь возможность поддерживать их по всему кластеру без вмешательства для HA-фейлового переключения по мере необходимости. Мои виртуальные машины работают на Ceph OSD. С 1 Гбит-соединением между серверами я получаю 22 секунды на восстановление после отключения, чтобы перейти к живой миграции на доступный узел. Неплохо. Я хочу объединить 2 из 4 линий к каждому серверу через двойные порты на 2 разных коммутаторах GB для настоящей 2 Гбит объединенной линии... Думаю... чтобы восстановление при сбоях могло быть быстрее с миграциями, а канал передачи данных мог быть приоритизирован на этих соединениях. Каждый сервер имеет 2 встроенных 1Gb и 4 1Gb на карте вставки. Так что портов достаточно, чтобы это реализовать, даже если придется соединить порты для простой маршрутизации... Идеи очень приветствуются.
25.01.2021 19:45:00, GoZippy.

CEPH по проблеме обновления узла

Mon, 25 Jan 2021 18:45:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
IP-адреса для виртуальных машин настраиваются внутри самой виртуальной машины. И интерфейс имеет IP (без моста) или мост.
25.01.2021 18:45:00, Alwin Antreich.

CEPH по проблеме обновления узла

Mon, 25 Jan 2021 02:39:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я так понимаю, мой вопрос в том, нужно ли мне настраивать eno1 как IP узла, а vmbr как запрашиваемый IP виртуальной машины? Я хочу, чтобы каждый узел имел IP от 10.0.1.1 до 10.0.1.8, а каждая ВМ — от 10.0.1.101 до XXX. Я теряю соединение с узлом, если устанавливаю eno1 на конкретный IP, например 10.0.1.5 для узла 5, но когда я перезагружаю и вхожу в консоль с физической машины, восстанавливаю конфигурацию, и тогда могу снова получить доступ к интерфейсу Proxmox — и кажется, это единственное решение, которое работает... установка vmbr1 на конкретный статический IP. Затем в ВМ я добавляю VMBR1 и настраиваю ВМ на статическую с запрашиваемым конкретным IP, например 10.0.1.103. Это работает — вроде как... но я не вижу этого извне своей сети (наверное, проблема с маршрутизацией DDWRT). Но я могу получить доступ к ней за DDWRT в сети LAN 10.0.x.x. Просто не могу понять, где мне установить IP узла и настроить IP ВМ с 6 сетевыми картами... все физические соединения отключены, кроме eno1. Странно, что некоторые узлы сообщают, что enpsof1 — это работающая связь, хотя физическое соединение идет через встроенную сетевую карту, а не через карту с 4 портами. Действительно странные вещи...
25.01.2021 02:39:00, GoZippy.

CEPH по проблеме обновления узла

Wed, 06 Jan 2021 16:14:00 +0300

CEPH по проблеме обновления узла Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
После обновления одного из моих узлов он стал немного нестабильным... ну, три моих узла — но у них разные проблемы. Некоторые сталкиваются с сетевыми проблемами... Что касается узла 5 — у меня есть ceph monitor, который отображается как "неопределенный" в списке мониторов на любом узле, к которому я подключаюсь через интерфейс. root@node5:~# ceph mon stats
не найдено действительной команды; 10 ближайших совпадений:
mon ok-to-stop ...
mon ok-to-add-offline
mon ok-to-rm
mon scrub
mon metadata []
mon count-metadata
mon versions
mon dump []
mon stat
mon getmap []
Ошибка EINVAL: недопустимая команда
root@node5:~# ceph osd status
ID HOST USED AVAIL WR OPS WR DATA RD OPS RD DATA STATE
0 stack1 4505M 927G 0 0 0 0 существует, работает
1 node2 81.9G 849G 0 0 0 0 существует, работает
2 node3 83.6G 847G 0 2457 0 0 существует, работает
3 node4 85.4G 846G 0 0 0 0 существует, работает
4 0 0 0 0 0 0 автоматический вывод, существует
5 0 0 0 0 0 0 существует
6 0 0 0 0 0 0 существует
root@node5:~# ceph osd crush tree --show-shadow
ID CLASS WEIGHT TYPE NAME
-2 hdd 6.36789 root default~hdd
-6 hdd 0.90970 host node2~hdd
1 hdd 0.90970 osd.1
-8 hdd 0.90970 host node3~hdd
2 hdd 0.90970 osd.2
-10 hdd 0.90970 host node4~hdd
3 hdd 0.90970 osd.3
-12 hdd 0.90970 host node5~hdd
4 hdd 0.90970 osd.4
-16 hdd 0.90970 host node6~hdd
6 hdd 0.90970 osd.6
-14 hdd 0.90970 host node8~hdd
5 hdd 0.90970 osd.5
-4 hdd 0.90970 host stack1~hdd
0 hdd 0.90970 osd.0
-1 6.36789 root default
-5 0.90970 host node2
1 hdd 0.90970 osd.1
-7 0.90970 host node3
2 hdd 0.90970 osd.2
-9 0.90970 host node4
3 hdd 0.90970 osd.3
-11 0.90970 host node5
4 hdd 0.90970 osd.4
-15 0.90970 host node6
6 hdd 0.90970 osd.6
-13 0.90970 host node8
5 hdd 0.90970 osd.5
-3 0.90970 host stack1
0 hdd 0.90970 osd.0
root@node5:~# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0f0: mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 00:0e:b6:5c:a3:e8 brd ff:ff:ff:ff:ff:ff
3: enp2s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0e:b6:5c:a3:e9 brd ff:ff:ff:ff:ff:ff
4: eno1: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0e:b6:a8:54:b3 brd ff:ff:ff:ff:ff:ff
5: eno2: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0e:b6:a8:54:b4 brd ff:ff:ff:ff:ff:ff
6: enp1s0f2: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0e:b6:a8:54:b5 brd ff:ff:ff:ff:ff:ff
7: enp1s0f3: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0e:b6:a8:54:b6 brd ff:ff:ff:ff:ff:ff
8: vmbr0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0e:b6:5c:a3:e8 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.5/16 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::20e:b6ff:fe5c:a3e8/64 scope link
valid_lft forever preferred_lft forever
root@node5:~# Есть идеи, с чего начать? Я перезагрузил каждый узел... перезагрузил... но он все еще ведет себя как старая версия. Есть ли команды в интерфейсе командной строки, которые я могу запустить, чтобы получить больше информации о том, что происходит?
06.01.2021 16:14:00, GoZippy.