понедельник, 25 ноября 2019 г.

Руководство администратора Proxmox VE R 6.0 Глава 6.

Proxmox VE Administration Guide

Менеджер кластера

  1. Требования
  2. Подготовка Узлов
  3. Создание кластера
  4. Добавление узлов в кластер
  5. Удаление узла кластера
  6. Кворум
  7. Сеть кластера
  8. Избыточность corosync
  9. Поддержка внешнего голосования corosync
  10. Конфигурация Corosync
  11. Холодный пуск кластера
  12. Миграция гостей

Proxmox VE cluster manager pvecm - это инструмент для создания группы физических серверов. Такая группа называется кластером. Мы используем кластерный движок Corosync для надежной групповой связи, и такие кластеры могут состоять из 32 физических узлов (возможно, больше, в зависимости от задержек сети).
pvecm можно использовать для создания нового кластера, присоединения узлов к кластеру, выхода из кластера, получения информации о состоянии и выполнения различных других задач, связанных с кластером. Файловая система кластера Proxmox ("pmxcfs") используется для прозрачного распространения конфигурации кластера на все узлы кластера.
Группировка узлов в кластер имеет следующие преимущества:
  • Централизованное управление с использованием Web интерфейса
  • Мульти - мастер кластер: каждый узел может выполнять все задачи управления
  • pmxcfs: управляемая базой данных файловая система для хранения конфигурационных файлов, реплицируемых в режиме реального времени на всех узлах с помощью corosync.
  • Простая миграция виртуальных машин и контейнеров между физическими узлами
  • Быстрое развертывание
  • Кластерные сервисы, такие как брандмауэр и HA(Высокая Доступность)

  1. Требования

    • Для работы corosync все узлы должны иметь возможность подключаться друг к другу через UDP-порты 5404 и 5405.
    • Дата и время должны быть синхронизированы.
    • Используется SSH-туннель на TCP-порту 22 между узлами.
    • Если вы заинтересованы в высокой доступности, вам необходимо иметь по крайней мере три узла для надежного кворума. Все узлы должны иметь одинаковую версию.
    • Мы рекомендуем выделенную сетевую карту для трафика кластера, особенно если используется общее хранилище.
    • Для добавления узлов требуется пароль Root узла кластера.
    Примечание
    Невозможно смешать узлы Proxmox VE 3.x и более ранними версиями с узлами Proxmox VE 4.x в кластере.
    Примечание
    Хотя это возможно для Proxmox VE 4.4 и Proxmox VE 5.0, это не рекомендуется как производственная конфигурация и должно использоваться только временно во время обновления всего кластера от одной до другой основной версии.
    Примечание
    Запуск кластера Proxmox VE 6.x с узлами более ранних версий невозможен. Кластерный протокол (corosync) Proxmox VE 6.x по сравнению с более ранними версиями принципиально изменился. Пакеты corosync 3 для Proxmox VE 5.4 предназначены только для процедуры обновления до Proxmox VE 6.0.

  2. Подготовка Узлов

    Во-первых, установите Proxmox VE на всех узлах. Убедитесь, что каждый узел установлен с окончательным именем хоста и IP-конфигурацией. Изменение имени хоста и IP-адреса невозможно после создания кластера.
    В настоящее время создание кластера может быть выполнено либо на консоли (вход через ssh), либо через API, для которого у нас есть реализация GUI (Datacenter → Cluster).
    Хотя обычно ссылаются на все имена узлов и их IP-адреса в /etc/hosts (или делают их имена разрешимыми с помощью других средств), это не обязательно для работы кластера. Это может быть полезно, однако, поскольку вы можете затем подключиться с одного узла к другому с помощью SSH используя легко запоминаемое имя узла (см. также раздел 6.7.3 типы адресов соединений). Обратите внимание, что мы всегда рекомендуем ссылаться на узлы по их IP-адресам в конфигурации кластера.

  3. Создание кластера

    Войдите по ssh на первый узел Proxmox VE. Используйте уникальное имя для вашего кластера. Это имя не может быть изменено позже. Имя кластера следует тем же правилам, что и имена узлов. 
    pvecm create CLUSTERNAME
    Примечание
    Можно создать несколько кластеров в одной физической или логической сети. При этом используйте уникальные имена кластеров. Чтобы избежать путаницы, также рекомендуется выбирать разные имена, даже если кластеры не используют общую сеть кластеров.
    Чтобы проверить состояние вашего кластера используйте: 
    pvecm status

    1. Несколько кластеров в одной сети

      Можно создать несколько кластеров в одной физической или логической сети. Каждый такой кластер должен иметь уникальное имя, это не только помогает администраторам различать, на каком кластере они в настоящее время работают, это также необходимо, чтобы избежать возможных конфликтов в стеке связи кластера.
      В то время как требования к пропускной способности кластера corosync относительно низки, задержка пакетов и скорость передачи пакетов в секунду (PPS) являются ограничивающим фактором. Различные кластеры в одной и той же сети могут конкурировать друг с другом за эти ресурсы, поэтому все же имеет смысл использовать отдельную физическую сетевую инфраструктуру для больших кластеров.

  4. Добавление узлов в кластер

    Войдите с помощью ssh в узел, который вы хотите добавить. 
    pvecm add IP-ADDRESS-CLUSTER
    Для IP-адреса кластера используйте IP-адрес или имя хоста существующего узла кластера. Рекомендуется использовать IP-адрес (см. раздел типы адресов соединений 6.7.3).
    Осторожно!
    Новый узел не может содержать никаких виртуальных машин, поскольку вы могли бы получить конфликты идентичных идентификаторов виртуальных машин. Кроме того, все существующие конфигурации в /etc/pve перезаписываются при присоединении нового узла к кластеру. Чтобы обойти эту проблему, используйте vzdump для резервного копирования и восстановления другого VMID после добавления узла в кластер.
    Для проверки состояния кластера используйте: 
    pvecm status
    Состояние кластера после добавления 4 узлов:
    Если вы хотите только список всех узлов: 
    pvecm nodes
    Список узлов в кластере:

    1. Добавление узлов с разделенной кластерной сетью

      При добавлении узла в кластер с разделенной кластерной сетью необходимо использовать параметр link0 для установки адреса узлов в этой сети: 
      pvecm add IP-ADDRESS-CLUSTER -link0 LOCAL-IP-ADDRESS-LINK0
      Если вы хотите использовать встроенную избыточность транспортного уровня kronosnet (раздел 6.8), также используйте параметр link1.

  5. Удаление узла кластера

    Осторожно!
    Внимательно прочитайте процедуру, прежде чем приступить, так как это может быть не то, что вы хотите или что вам нужно.
    Переместите все виртуальные машины с узла. Убедитесь, что у вас нет локальных данных или резервных копий, которые вы хотите сохранить, или сохраните их соответствующим образом. В следующем примере мы удалим узел hp4 из кластера. Войдите в другой узел кластера (не hp4) и выполните команду pvecm nodes, чтобы определить идентификатор узла для удаления:
    На этом этапе вы должны выключить hp4 и убедиться, что он не будет снова включен (не появится в сети), в текущем виде.
    Важно
    Как было сказано выше, очень важно выключить узел перед удалением и убедиться, что он никогда не включится снова (в существующей сети кластера), в нынешнем виде. Если вы включите узел, как есть, ваш кластер будет испорчен, и может быть трудно восстановить чистое состояние кластера.
    После отключения питания узла hp4 мы можем безопасно удалить его из кластера. 
    pvecm delnode
    Если операция завершилась успешно, сообщение не выдается, просто еще раз проверьте список узлов с помощью pvecm nodes или pvecm status. Вы должны увидеть что-то вроде:
    Если по какой-либо причине вы хотите, чтобы этот сервер снова присоединился к тому же кластеру, вы должны
    • переустановить Proxmox VE на нем с нуля
    • затем присоединитесь к нему, как описано в предыдущем разделе.
    Примечание
    После удаления узла его SSH сертификат по-прежнему будет находиться в known_hosts других узлов. Если вы получили ошибку SSH после повторного подключения к узлу с тем же IP-адресом или именем хоста, один раз запустите pvecm updatecerts на повторно добавленном узле, чтобы обновить его сертификат в кластере.

    1. Вывести узел без переустановки

      Осторожно!
      Это не рекомендуемый метод, действуйте с осторожностью. Используйте вышеупомянутый метод, если вы не уверены.
      Можно также отделить узел от кластера, не устанавливая его заново с нуля. Но после удаления узла из кластера он все равно будет иметь доступ к общим хранилищам! Это необходимо решить до начала удаления узла из кластера. Кластер Proxmox VE не может совместно использовать одно и то же хранилище с другим кластером, так как блокировка хранилища не работает за пределами кластера. Кроме того, это может также привести к конфликтам VMID.

      Предполагается, что вы создадите новое хранилище, с доступом только для узла, который вы хотите отделить. Это может быть новый экспорт на вашем NFS или новый пул Ceph, в качестве примеров. Важно, чтобы одно и то же хранилище не было доступно нескольким кластерам. После настройки этого хранилища переместите все данные с узла и его виртуальных машин на него. После этого вы готовы отделить узел от кластера.
      Внимание!
      Убедитесь, что все общие ресурсы четко разделены! В противном случае вы столкнетесь с конфликтами и проблемами.
      Сначала остановите службы corosync и PvE-кластера на узле: 
      systemctl stop pve-cluster
systemctl stop corosync
      Снова запустите файловую систему кластера в локальном режиме: 
      pmxcfs -l
      Удалите файлы конфигурации corosync: 
      rm /etc/pve/corosync.conf
rm /etc/corosync/*
      Теперь вы можете снова запустить файловую систему как обычную службу: 
      killall pmxcfs
systemctl start pve-cluster
      Теперь узел отделен от кластера. Вы можете удалить его с одного из оставшихся узлов кластера с помощью: 
      pvecm delnode oldnode
      Если команда завершилась неудачно, так как оставшийся в кластере узел потерял кворум при выходе узла из кластера, в качестве обходного пути можно задать ожидаемое число голосов (quorum) равным 1: 
      pvecm expected 1
      А затем повторите команду pvecm delnode. Теперь переключитесь обратно на отделенный узел и удалите все файлы, оставшиеся от старого кластера. Это гарантирует, что узел снова может быть добавлен в другой кластер без проблем. 
      rm /var/lib/corosync/*
      Поскольку файлы конфигурации с других узлов все еще находятся в файловой системе кластера, вы можете также очистить их. Удалите просто весь каталог рекурсивно из /etc/pve/nodes/NODENAME, но проверьте три раза, что вы использовали правильный, прежде чем удалить его.
      Осторожно!
      Ключи SSH узлов все еще находятся в файле authorized_key, это означает, что узлы все еще могут подключаться друг к другу с помощью аутентификации с открытым ключом. Это должно быть исправлено путем удаления соответствующих ключей из файла /etc/pve/priv/authorized_keys.

  6. Кворум

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

  7. Сеть кластера

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

    1. Требования к сети

      Для правильной работы требуется надежная сеть с задержками менее 2 миллисекунд (производительность локальной сети). Сеть не должна активно использоваться другими участниками, в идеале corosync должен работать в своей собственной сети. Не используйте общую сеть для corosync и хранения (кроме как потенциальный резервный вариант с низким приоритетом в конфигурации избыточного раздела 6.8).

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

      Если брандмауэр Proxmox VE включен, правила ACCEPT для corosync будут созданы автоматически - никаких действий вручную не требуется.
      Примечание
      Corosync использовал Multicast до версии 3.0 (представлен в Proxmox VE 6.0). Современные версии полагаются на Kronosnet для кластерной связи, которая на данный момент поддерживает только обычную одноадресную передачу UDP.
      Осторожно!
      Вы все еще можете включить Многоадресную или устаревшую одноадресную передачу, настроив транспорт на udp или udpu в corosync.conf (раздел 6.10.1), но имейте в виду, что это отключит поддержку криптографии и избыточности. Поэтому так поступать не рекомендуется.

    2. Отдельная кластерная сеть

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

      Настройка новой сети
      Сначала вы должны настроить новый сетевой интерфейс. Он должен находиться в физически отдельной сети. Убедитесь,что ваша сеть соответствует требованиям раздела 6.7.1 кластерной сети.

      Отделение сети при создании кластера
      Это возможно с помощью параметров linkX команды pvecm create, используемой для создания нового кластера.

      Если вы настроили дополнительную сетевую карту со статическим адресом на 10.10.10.1 / 25 и хотите отправлять и получать все сообщения кластера через этот интерфейс, вы должны выполнить: 
      pvecm create test --link0 10.10.10.1
      Чтобы проверить, все ли работает правильно выполнить: 
      systemctl status corosync
      Затем выполните описанные выше действия для добавления узлов с разделенной кластерной сетью (см.раздел 6.4.1).

      Отделить сеть после создания кластера
      Это можно сделать, если вы уже создали кластер и хотите переключить его связь на другую сеть, не перестраивая весь кластер. Это изменение может привести к кратковременной потере кворума в кластере, так как узлы должны перезапустить corosync и появляться один за другим в новой сети.
      Просмотрите сначала, как изменить файл corosync.conf (раздел 6.10.1). Затем откройте его, и вы увидите файл, аналогичный:
      Примечание
      ringX_addr фактически ссылается на адрес corosync, имя "ring" является остатком старых версий corosync, которые хранятся для обратной совместимости.
      Первое, что вы должны сделать, это добавить свойство "имя" в записи узлов, если вы их еще не видите.
      Они должны соответствовать имени узла.

      Затем замените все адреса из свойств ring0_addr всех узлов на новые адреса. Вы можете здесь использовать просто IP-адреса или имена хостов. Если вы используете имена узлов, убедитесь, что они разрешимы со всех узлов. (см. также раздел 6.7.3 типы адресов соединений)

      В этом примере мы хотим переключить связь кластера на сеть 10.10.10.1/25. Поэтому мы заменяем все ring0_addr соответственно.
      Примечание
      Точно такая же процедура может быть использована для изменения других значений ringX_addr, хотя мы рекомендуем не изменять несколько адресов сразу, чтобы облегчить восстановление, если что-то пойдет не так.
      После увеличения свойства config_version новый файл конфигурации должен выглядеть следующим образом:
      Затем, после окончательной проверки правильности всей измененной информации, мы сохраняем ее и снова следуем разделу редактирование файла corosync.conf (раздел 6.10.1) для приведения изменений в действие.

      Изменения будут применены в реальном времени, поэтому перезапуск corosync не является строго необходимым. Если вы также изменили другие настройки или заметили, что corosync на что то жалуется, вы можете дополнительно осуществить его перезапуск.

      На одном узле выполнить: 
      systemctl restart corosync
      Теперь проверьте, все ли в порядке: 
      systemctl status corosync
      Если corosync запускается корректно, перезапустите corosync на всех остальных узлах. После перезапуска они присоединятся к членству в кластере один за другим в новой сети.

    3. Адресация в Corosync

      Адрес соединения corosync (для обратной совместимости обозначается ringX_addr в corosync.conf ) можно указать двумя способами:
      • IPv4/v6 адреса будут использоваться напрямую. Они рекомендуются, так как они статичны и обычно не изменяются случайно.
      • Имена хостов будут разрешены с помощью getaddrinfo, что означает, что по умолчанию сначала будут использоваться IPv6-адреса, если они доступны (см. Также man gai.conf). Имейте это в виду, особенно при
      обновлении существующего кластера до IPv6.
      Осторожно!
      Имена хостов следует использовать с осторожностью, так как адрес, в который они разрешаются, может быть изменен без взаимодействия с corosync или узлом, на котором он работает , что может привести к ситуации, когда адрес изменяется, без учета последствий для corosync.
      Рекомендуется использовать отдельное статическое имя хоста специально для corosync, если предпочтительны имена хостов. Кроме того, убедитесь, что каждый узел в кластере может правильно разрешить все имена узлов.

      Поскольку Proxmox VE 5.1, хотя и поддерживается, имена хостов будут разрешены во время входа. Только разрешенный IP-адрес затем сохраняется в конфигурации.

      Узлы, которые присоединились к кластеру в более ранних версиях, все еще могут использовать свое неразрешенное имя хоста в corosync.conf.

      Возможно, было бы неплохо заменить их IP-адресами или отдельным именем хоста, как упоминалось выше.

  8. Избыточность corosync

    Corosync поддерживает избыточную сеть через свой интегрированный слой kronosnet по умолчанию (он не поддерживается на устаревших udp/udpu транспортах). Corosync по умолчанию поддерживает избыточность сети через встроенный уровень kronosnet (не поддерживается на устаревших транспортах udp/udpu). Его можно включить, указав более одного адреса соединения, либо с помощью параметров --linkX в pvecm (при создании кластера или добавлении нового узла), либо указав более одного ringX_addr в corosync.conf.
    Примечание
    Чтобы обеспечить полезную отработку отказа, каждое соединение должно быть на своем собственном физическом сетевом соединении.
    Соединения используются в соответствии с настройкой приоритета. Вы можете настроить этот приоритет, установив knet_link_priority в соответствующем разделе интерфейса в corosync.conf, или, предпочтительно, использование параметра priority при создании кластера с pvecm: 
    pvecm create CLUSTERNAME --link0 10.10.10.1,priority=20 --link1 10.20.20.1,priority=15
    Это приведет к тому, что link1 будет использоваться первым, так как он имеет более низкий приоритет.

    Если приоритеты не настроены вручную (или два соединения имеют одинаковый приоритет), соединения будут использоваться в порядке их очередности, причем меньший номер будет иметь более высокий приоритет.

    Даже если все соединения работают, только один с самым высоким приоритетом будет видеть трафик corosync. Приоритеты соединений не могут быть смешанными, т. е. соединения с разными приоритетами не смогут взаимодействовать друг с другом.

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

    1. Добавление избыточных соединений в существующий кластер

      Чтобы добавить новое соединение в текущую конфигурацию, сначала ознакомьтесь с разделом "как изменить файл corosync.conf" (раздел 6.10.1).

      Затем добавьте новый ringX_addr к каждому узлу в разделе nodelist. Убедитесь, что ваш X одинаков для каждого узла, к которому вы его добавляете, и что он уникален для каждого узла.

      Наконец, добавьте новый интерфейс, как показано ниже, в ваш раздел totem, заменив X вашим номером соединения, выбранным выше.

      Предполагая, что вы добавили соединение с номером 1, новый файл конфигурации может выглядеть следующим образом:
      Новое соединение будет включено, как только вы выполните последние шаги для редактирования файла corosync.conf (раздел 6.10.1). Перезапуск не обязателен. Вы можете проверить, что corosync загрузил новое соединение с помощью: 
      journalctl -b -u corosync
      Было бы неплохо протестировать новое соединение, временно отключив старое на одном узле и убедившись, что статус узла остается "в сети" во время отключения: 
      pvecm status
      Если вы видите работоспособное состояние кластера, это означает, что используется новое соединение.

  9. Поддержка внешнего голосования corosync

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

    Для его работы задействованы две службы:
    • так называемый демон qdevice, который работает на каждом узле Proxmox VE
    • внешний демон голосования, который работает на независимом сервере.
    В результате вы можете добиться более высокой доступности даже в небольших установках (например, 2+1 узел).

    1. Технический Обзор QDevice

      Устройство Corosync Quroum (QDevice) - это демон, который работает на каждом узле кластера. Он предоставляет настроенное количество голосов подсистеме кворума кластеров на основе решения внешнего управляющего арбитра третьей стороны. Его основное назначение-разрешить кластеру поддерживать большее количество отказов узлов, чем это позволяют стандартные правила кворума. Это можно сделать безопасно, так как внешнее устройство может видеть все узлы и, таким образом, выбрать только один набор узлов, чтобы дать свой голос. Это будет сделано только в том случае, если указанный набор узлов может иметь кворум (снова) при получении стороннего голосования.

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

      У внешнего хоста есть единственное требование, что ему нужен сетевой доступ к кластеру и доступный пакет corosync-qnetd. Мы предоставляем такой пакет для хостов на основе Debian, другие дистрибутивы Linux также должны иметь пакет, доступный через их соответствующий менеджер пакетов.
      Примечание
      В отличие от самой corosync, QDevice подключается к кластеру по протоколу TCP/IP. Демон может даже работать за пределами локальной сети кластера и иметь более длительные задержки, чем 2 мс.

    2. Поддерживаемые настройки

      Мы поддерживаем QDevices для кластеров с четным числом узлов и рекомендуем его для 2-х узловых кластеров, если они должны обеспечивать более высокую доступность. Для кластеров с нечетным числом узлов мы не рекомендуем использовать Qdevices в настоящее время. Причина этого заключается в разнице голосов, которые QDevice предоставляет для каждого типа кластера. Кластеры с четным количеством узлов получают один дополнительный голос, с ним мы можем только увеличить доступность, т. е. если сам Qdevice терпит аварию, мы находимся в той же ситуации, что и без QDevice вообще.

      Теперь, с нечетным размером кластера QDevice предоставляет (N-1) голосов — где N соответствует количеству узлов кластера. Это различие имеет смысл, если бы у нас был только один дополнительный голос, кластер может оказаться в неопределенном состоянии. Этот алгоритм позволил бы, чтобы все узлы, кроме одного (и, естественно, самого QDevice), могли потерпеть крах. В этом есть два недостатка:
      • Если сам демон QNet выходит из строя, ни один другой узел не может выйти из строя или кластер немедленно теряет кворум. Например, в кластере из 15 узлов с 7 может произойти сбой до того, как кластер потеряет кворум. Но, если QDevice сконфигурирован и сообщил, что QDevice сам терпит аварию, ни один узел из 15 не может потерпеть крах. В этом случае QDevice выступает почти как единственная точка отказа.
      • Тот факт, что все узлы, кроме одного плюс QDevice, могут одновременно потерпеть аварию, звучит многообещающе, но это может привести к массовому восстановлению служб высокой доступности, что приведет к перегрузке единственного оставшегося узла. Кроме того, сервер ceph перестанет предоставлять услуги после того, как только ((N-1)/2) узлы будут доступны.

      Если вы понимаете недостатки и последствия, вы можете сами решить, следует ли использовать эту технологию при настройке кластера с нечетным количеством узлов.

    3. Настройка QDevice-net

      Мы рекомендуем запускать любой демон, который предоставляет голоса corosync-qdevice, от лица непривилегированного пользователя. Proxmox VE и Debian предоставляют пакет, который уже настроен для этого. Трафик между демоном и кластером должен быть зашифрован для обеспечения безопасной и надежной интеграции QDevice в Proxmox VE.

      Сначала установите пакет corosync-qnetd на внешний сервер, а пакет corosync-qdevice - на все узлы кластера. После этого убедитесь, что все узлы кластера доступны.

      Теперь вы можете легко настроить QDevice, выполнив следующую команду на одном из узлов Proxmox VE: 
      pvecm qdevice setup
      Ключ SSH из кластера будет автоматически скопирован в QDevice. На этом шаге может потребоваться ввести пароль SSH.

      После того, как вы введете пароль и все шаги будут успешно завершены, вы увидите сообщение "готово". Вы можете проверить статус прямо сейчас:
      это означает, что QDevice настроен.

    4. Часто задаваемые вопросы

      Разрыв связи
      В случае обрыва связи, когда два кластерных раздела одинакового размера не видят друг друга, но видят QDevice, QDevice случайным образом выбирает один из этих разделов и предоставляет ему право голоса.

      Возможные негативные последствия
      Для кластеров с четным числом узлов нет никаких негативных последствий при настройке QDevice. Если он не работает, кластер так же работоспособен, как и без QDevice вообще.

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

      Удаление QDevice
      Если вы использовали официальный инструмент pvecm для добавления QDevice, вы можете удалить его, просто запустив: 
      pve# pvecm qdevice remove

  10. Конфигурация Corosync

    Файл /etc/pve/corosync.conf играет центральную роль в кластере Proxmox VE. Он управляет участниками кластера и его сетью. Для получения дополнительной информации об этом, обратитесь к страницам corosync.conf man:
    man corosync.conf
    Для добавления узла в члены кластера вы всегда должны использовать инструмент pvecm, предоставляемый Proxmox VE. Возможно, вам придется вручную отредактировать файл конфигурации для других изменений. Вот несколько практических советов как лучше сделать это.

    1. Редактирование corosync.conf

      Редактирование файла corosync.conf иногда не очень простое. Их два на каждом узле кластера, один в /etc/pve/corosync.conf и другой в /etc/corosync /corosync.conf . Редактирование одного из них в нашей кластерной файловой системе распространит изменения на локальный, но не наоборот.

      Конфигурация обновиться автоматически, как только файл изменится. Это означает, что изменения, которые могут быть внесены в запущенный corosync, вступят в силу немедленно. Поэтому вы всегда должны делать копию и редактировать ее, чтобы избежать запуска некоторых нежелательных изменений с помощью промежуточного сохранения файла. 
      cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new
      Затем откройте файл конфигурации в вашем любимом редакторе, nano или vim.tiny например, предустановлены на любом узле Proxmox VE.
      Примечание
      Всегда увеличивайте число config_version при изменении файла конфигурации, не делая этого, Вы можете столкнуться с проблемами.
      После внесения необходимых изменений создайте еще одну копию текущего рабочего конфигурационного файла. Это служит в качестве резервной копии, если новая конфигурация не применяется или возникают другие проблемы. 
      cp /etc/pve/corosync.conf /etc/pve/corosync.conf.bak
      Затем переместите новый файл конфигурации поверх старого: 
      mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf
      Вы можете проверить результат с помощью команд 
      systemctl status corosync
journalctl -b -u corosync
      Если изменение может быть применено автоматически. Если нет, возможно, вам придется перезапустить службу corosync с помощью: 
      systemctl restart corosync
      Об ошибках см. следующий раздел устранение неполадок.

    2. Устранение неполадок

      Проблема: quorum.expected_votes должен быть настроен

      Когда corosync начинает отказывать и вы получаете следующее сообщение в системном журнале:
      Это означает, что имя хоста, заданное для corosync ringX_addr в конфигурации, не может быть разрешено.

      Записать конфигурацию, когда нет кворума
      Если вам нужно изменить /etc/pve/corosync.conf на узле без кворума, и вы знаете, что делаете, используйте: 
      pvecm expected 1
      Это устанавливает ожидаемое число голосов в 1 и делает кворум кластера. Теперь вы можете исправить свою конфигурацию или вернуть ее к последней рабочей резервной копии.

      Этого недостаточно, если corosync больше не может запускаться. В этом случае лучше всего отредактировать локальную копию конфигурации corosync в файле /etc/corosync/corosync.conf, чтобы corosync можно было запустить снова. Убедитесь, что на всех узлах эта конфигурация имеет одинаковое содержимое, чтобы избежать неопределенного состояния. Если вы не уверены в причине неисправности, лучше всего обратиться к сообществу Proxmox за помощью.

    3. Глоссарий конфигурации corosync

      ringX_addr
      Это имена различных адресов линков(интерфейсов) для соединений kronosnet между узлами.

  11. Холодный пуск кластера

    Очевидно, что кластер не имеет кворума, когда все узлы выключены/не в сети. Это обычный случай после сбоя питания.
    Примечание
    Использовать источник бесперебойного питания (”ИБП“, также называемый” резервная батарея") - всегда хорошая идея, чтобы избежать этого состояния, особенно если вы хотите HA.
    При запуске узла служба pve-guests запускается и ожидает кворума. При появлении кворума, она запускает всех гостей, у которых установлен флаг "запуск при старте".

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

  12. Миграция гостей

    Перенос виртуальных гостей на другие узлы является полезной функцией кластера. Существуют настройки для управления поведением таких миграций. Это можно сделать с помощью конфигурационного файла datacenter.cfg или для конкретной миграции через API или параметры командной строки.

    Это имеет значение, если гость находится в сети или в автономном режиме, или если он имеет локальные ресурсы (например, локальный диск).

    Дополнительные сведения о миграции виртуальных машин см. В разделе 10.3 главы миграция QEMU/KVM.

    Дополнительные сведения о миграции контейнеров см. В разделе 11.9 главы о миграции контейнеров.

    1. Тип миграции

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

      Поэтому мы настоятельно рекомендуем использовать защищенный канал, если вы не имеете полного контроля над сетью и не можете гарантировать, что никто не подслушивает его.
      Примечание
      Миграция хранилища не соответствует этому параметру. В настоящее время он всегда отправляет содержимое хранилища по защищенному каналу.
      Шифрование требует большой вычислительной мощности, поэтому этот параметр часто изменяется на "небезопасный" для достижения лучшей производительности. Влияние на современные системы ниже, потому что они реализуют аппаратное шифрование AES. Влияние производительности особенно заметно в быстрых сетях, где вы можете передавать 10 Гбит/с или более.

    2. Сеть миграции

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

      Установка параметра миграционная сеть позволяет использовать выделенную сеть для всего миграционного трафика. Помимо памяти, это также влияет на трафик хранилища для offline миграций.

      Сеть Миграции определяется как сеть в нотации CIDR(бесклассовая адрессация). Это имеет то преимущество, что вам не нужно устанавливать отдельные IP-адреса для каждого узла. Proxmox VE может определить реальный адрес на узле назначения из сети, указанной в форме CIDR. Чтобы включить это, сеть должна быть указана так, чтобы каждый узел имел один, но только один IP-адрес в соответствующей сети.

      Пример:
      Мы предполагаем, что у нас есть трехузловая установка с тремя отдельными сетями. Один для публичной связи с Интернетом, один для кластерной связи и очень быстрый, который мы хотим использовать в качестве выделенной сети для миграции.

      Сетевая конфигурация для такой установки может выглядеть следующим образом:
      Здесь мы будем использовать сеть 10.1.2.0/24 в качестве миграционной сети. Для одной миграции это можно сделать с помощью параметра migration_network средства командной строки: 
      qm migrate 106 tre --online --migration_network 10.1.2.0/24
      Чтобы настроить эту сеть в качестве сети по умолчанию для всех миграций в кластере, задайте свойство миграции в файле /etc/pve/datacenter.cfg: 
      # use dedicated migration network
migration: secure,network=10.1.2.0/24
      Примечание
      Тип миграции всегда должен быть установлен, когда сеть миграции установлена в /etc/pve/datacenter.cfg.



Автор: на
Ярлыки: , ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)