Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    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 Виртуальная Среда
    Какую сеть следует использовать для Corosync?

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Какую сеть следует использовать для Corosync?, Proxmox Виртуальная Среда
     
    adrian.jiang
    Guest
    #1
    0
    25.03.2020 13:35:00
    Привет, сейчас наш Proxmox corosync находится на публичном IP. Это правильная практика? В нескольких статьях упоминается 'RING' в контексте corosync. # corosync-cfgtool -s Печать статуса соединения. Локальный ID узла 5 LINK ID 0 addr = 117.xxx.x.x статус: nodeid 1: link включен:1 link подключен:1 nodeid 2: link включен:1 link подключен:1 nodeid 3: link включен:1 link подключен:1 nodeid 4: link включен:1 link подключен:1 nodeid 5: link включен:1 link подключен:1 nodeid 6: link включен:1 link подключен:1 Ниже результат, который я получил из онлайн-статьи (упоминающей RING) [root@pcmk-1 ~]# corosync-cfgtool -s Печать статуса кольца. Локальный ID узла 1 RING ID 0 id = 192.168.122.101 статус = кольцо 0 активно без ошибок. Наша конфигурация выглядит рискованной? Почему команда, запущенная на нашей установке proxmox, не показывает RING ID? Что на самом деле означает термин RING в данном контексте? Заранее спасибо.
     
     
     
    mscd
    Guest
    #2
    0
    08.01.2022 01:18:00
    Уважаемый господин Лампрехт, я нашел этот тред в ходе своих исследований по следующей проблеме/вопросу: я хотел бы построить кластер Proxmox на базе выделенных серверов от Hetzner. Узлы могут быть соединены с помощью технологии vSwitch от Hetzner (полные виртуальные подключения уровня 2). Учитывая, что трафик vSwitch по умолчанию не шифруется, я хотел бы узнать, защищен ли весь кластерный трафик уже шифрованием самого Proxmox? Как вы упомянули выше, трафик corosync по умолчанию защищен шифрованием. Так безопасно ли запускать кластерную сеть Proxmox без дополнительного шифрования (по незащищенной сети)? К сожалению, я не могу найти дополнительной информации по этой теме (шифрование кластерной сети). С наилучшими пожеланиями, mscd
     
     
     
    Tmanok
    Guest
    #3
    0
    12.02.2023 06:23:00
    Привет, Томас. У меня похожий вопрос по поводу MSCD: мы рассматриваем будущее использование DarkFibre для подключения 8-узлового кластера между двумя городами (~378 км). Мы рассчитали, что задержка должна быть достаточно низкой, и у нас будет контроль над волоконно-оптической связью, за исключением тех точек, которые будут переключаться и ретранслироваться провайдером. Мы хотим узнать, есть ли письменная документация о том, что трафик Corosync шифруется — в документации Corosync ничего не указывает на то, что трафик шифруется или как он шифруется: https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_cluster_network Спасибо, дай знать, если я что-то упустил, если нет, не мог бы кто-то из команды обновить документацию? Tmanok
     
     
     
    spirit
    Guest
    #4
    0
    12.02.2023 09:04:00
    Вам стоит быть осторожным, если хотите растянуть один кластер между двумя городами. Если у вас произойдет обрыв волокна между этими двумя городами, вы потеряете кворум в одном из них. Вам нужны кворумные ноды где-то в третьем городе с другим сетевым соединением между каждым городом. Не уверен, будет ли латентность в 380 км хорошей. (Думаю, она должна быть около 5-6 мс?). Кажется, это немного много. На мой взгляд, вам стоит построить два отдельных кластера в каждом городе.
     
     
     
    Tmanok
    Guest
    #5
    0
    14.02.2023 05:43:00
    Привет, Spirit. Наличие узла-свидетеля в другом дата-центре — хорошая идея. Тем не менее, задержка на оптике составит 3.8 мс (1 мс на каждые 100 км), если она будет свободна от всего остального трафика. Рекомендация в вики — около 5 мс и ниже 10 мс, так что если нам удастся это реализовать, я буду рад. Мы рассматриваем 2 оптических маршрута, чтобы в случае разрыва одного, другой находился в совершенно другом месте. Задержка может варьироваться от 3 мс до 5 мс в зависимости от маршрута. Мы хотим мгновенный переход, поэтому тщательно изучаем опции связи. Сейчас ключевым моментом является безопасность. Спасибо, наш текущий план — 4 кластера с по четыре узла в каждом, два кластера на каждом сайте, но межкластерная репликация пока не реализована как функция, и мы хотим соответствовать SLA. Tmanok
     
     
     
    spirit
    Guest
    #6
    0
    14.02.2023 07:47:00
    У меня есть клиент, который управляет кластером из 3 узлов, расположенных в 2 разных дата-центрах с задержкой 1 мс, и с дополнительным 7-ым узлом для кворума с задержкой 10 мс. Это работает. Не уверен насчет большего кластера. Имейте в виду, что для репликации данных, если вы хотите действительно мгновенное переключение при сбое, вам потребуется синхронная репликация, так что не ожидайте много iops при 4 мс, если ваше приложение не производит слишком много параллельных операций или последовательных записей (журнал базы данных и т.д.) (1 мс = 1000 iops, 4 мс = 250 iops).
     
     
     
    Tmanok
    Guest
    #7
    0
    14.02.2023 09:18:00
    Репликация (асинхронная на основе PVE) будет происходить по VPLS-ссылкам отдельно от арендованных волоконно-оптических каналов, но это действительно хорошие оценки IOPS для хранения в зависимости от задержки. К сожалению, наши VPLS-ссылки сейчас имеют задержку 8-13 мс (62.5 IOPS по вашей оценке), мы планируем уменьшить задержку в основной сети, чтобы улучшить эту ситуацию, но вы правильно отметили, насколько осторожными мы должны быть с репликацией. Спасибо за ваши мысли, я действительно упустил из виду IOPS на мс пинга. При наличии, скажем, 20-40 основных ВМ, нам потребуется частая репликация — у меня сейчас нет точной оценки, сколько IOPS это может потребовать. Учтите, что базы данных будут реплицироваться отдельно на уровне приложения. Мне было бы интересно узнать, что вы используете для синхронной репликации (PVE, CEPH или SAN репликация). Возвращаясь к основной мысли, Томас, пожалуйста, пусть кто-то обновит эти документы или дайте знать, прописана ли в техническом документе зашифровка corosync. Спасибо, Tmanok.
     
     
     
    t.lamprecht
    Guest
    #8
    0
    14.02.2023 09:44:00
    К вашему сведению, для четного количества узлов можно добавить QDevice, который не участвует в работе кластера как полноценный узел, а лишь выступает в качестве арбитра голосования, и поэтому у него нет таких же требований по латенции. https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_corosync_external_vote_support Что именно вам нужно знать? В основном, мы установили опцию secauth в corosync.conf в положение "включено", что подразумевает шифрование AES 256: https://manpages.debian.org/bullseye/corosync/corosync.conf.5.en.html#secauth
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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