Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    CEPH по проблеме обновления узла

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    CEPH по проблеме обновления узла, Proxmox Виртуальная Среда
     
    GoZippy
    Guest
    #1
    0
    06.01.2021 16:14:00
    После обновления одного из моих узлов он стал немного нестабильным... ну, три моих узла — но у них разные проблемы. Некоторые сталкиваются с сетевыми проблемами... Что касается узла 5 — у меня есть ceph monitor, который отображается как "неопределенный" в списке мониторов на любом узле, к которому я подключаюсь через интерфейс. root@node5:~# ceph mon stats
    не найдено действительной команды; 10 ближайших совпадений:
    mon ok-to-stop <ids>...
    mon ok-to-add-offline
    mon ok-to-rm <id>
    mon scrub
    mon metadata [<id>]
    mon count-metadata <property>
    mon versions
    mon dump [<epoch:int>]
    mon stat
    mon getmap [<epoch:int>]
    Ошибка 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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST> 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: <BROADCAST,MULTICAST> 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: <BROADCAST,MULTICAST> 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: <BROADCAST,MULTICAST> 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: <BROADCAST,MULTICAST> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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:~# Есть идеи, с чего начать? Я перезагрузил каждый узел... перезагрузил... но он все еще ведет себя как старая версия. Есть ли команды в интерфейсе командной строки, которые я могу запустить, чтобы получить больше информации о том, что происходит?
     
     
     
    GoZippy
    Guest
    #2
    0
    25.01.2021 02:39:00
    Я так понимаю, мой вопрос в том, нужно ли мне настраивать 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 портами. Действительно странные вещи...
     
     
     
    Alwin Antreich
    Guest
    #3
    0
    25.01.2021 18:45:00
    IP-адреса для виртуальных машин настраиваются внутри самой виртуальной машины. И интерфейс имеет IP (без моста) или мост.
     
     
     
    GoZippy
    Guest
    #4
    0
    25.01.2021 19:45:00
    Да, я могу настроить мост для диапазонов частных 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 на карте вставки. Так что портов достаточно, чтобы это реализовать, даже если придется соединить порты для простой маршрутизации... Идеи очень приветствуются.
     
     
     
    Alwin Antreich
    Guest
    #5
    0
    25.01.2021 21:55:00
    Судя по строкам iptables, это NAT. Все публичные IP-адреса завершаются на маршрутизаторе. Гости за маршрутизатором будут видеть только внутренний IP. Маршрутизатор переписывает его в соответствии с правилами iptables. Лучше перенаправлять только те порты, которые действительно нужны. Маршрутизация сети будет означать использование IP из публичной подсети на маршрутизаторе в качестве шлюза. И предоставление вышестоящему маршрутизатору информации о маршрутизации (если это еще не сделано провайдером). Это также должно быть отделено в отдельную зону безопасности.
     
     
     
    GoZippy
    Guest
    #6
    0
    27.01.2021 22:11:00
    Моя цель — избавиться от 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 на конкретную виртуальную машину.
     
     
     
    Alwin Antreich
    Guest
    #7
    0
    28.01.2021 12:34:00
    Используйте NAT или (если у вас есть подсеть) маршрутизируйте публичные IP-адреса. Это похоже на маршрутизацию частных IP-сетей. Я не совсем понимаю, что вы имеете в виду под 'умирает', но dd-wrt будет шлюзом для этих гостей. У вас есть больше одного интернет-соединения? В основном, когда модем выходит из строя, резервация не будет иметь большого смысла (если это единственная цель). Менее сложным решением было бы иметь резервный сервер, который легко заменить.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры