Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Практические руководства
    • Все руководства
    • Настройка сетевого взаимодействия ресурсов из разных каталогов
    • Создание бастионного хоста
    • Создание туннеля между двумя подсетями при помощи OpenVPN Access Server
    • Защищенный доступ пользователей к облачным ресурсам на основе WireGuard VPN
    • Создание и настройка шлюза UserGate в режиме межсетевого экрана
    • Реализация отказоустойчивых сценариев для сетевых ВМ
    • Реализация защищенной высокодоступной сетевой инфраструктуры с выделением DMZ на основе Check Point NGFW
    • Сегментация облачной инфраструктуры с помощью решения Check Point Next-Generation Firewall
    • Реализация защищенной высокодоступной сетевой инфраструктуры с выделением DMZ на основе UserGate NGFW
    • Организация доступа через Cloud Interconnect к облачным сетям, размещенным за NGFW
    • Настройка защищенного туннеля GRE поверх IPsec
    • Настройка сети для Yandex Data Processing
    • Переключение сетевого соединения при пересоздании кластера Yandex Data Processing
    • Подключение к Object Storage из VPC
    • Подключение к Container Registry из VPC
    • Создание прямого транкового подключения и приватного соединения в нем
    • Создание прямого транкового подключения и публичного соединения в нем
    • Создание нового партнерского транкового подключения и приватного соединения в нем
    • Создание нового партнерского транкового подключения и публичного соединения в нем
    • Добавление приватного соединения в прямое или партнерское транковое подключение
    • Добавление публичного соединения в прямое или партнерское транковое подключение
    • Изменить емкость транкового подключения
    • Изменить набор IP-префиксов в приватном соединении
    • Удалить приватное соединение
    • Удалить публичное соединение
    • Удалить транковое подключение
    • Настройка VRRP для кластера серверов BareMetal
    • Настройка сетевой связности в подсети BareMetal
    • Настройка сетевой связности между подсетями BareMetal и Virtual Private Cloud
    • Доставка USB-устройств на сервер BareMetal или виртуальную машину

В этой статье:

  • Схема решения
  • Перед началом работы
  • Необходимые платные ресурсы
  • Создайте виртуальный сетевой сегмент
  • Создайте приватные подсети
  • Арендуйте серверы BareMetal
  • Настройте Keepalived на серверах пула ru-central1-m3
  • Убедитесь в работоспособности решения
  • Как отказаться от аренды серверов
  1. Архитектура, сетевое взаимодействие
  2. Настройка VRRP для кластера серверов BareMetal

Настройка VRRP для кластера серверов BareMetal с использованием Keepalived

Статья создана
Tania Lushnikova
Обновлена 28 апреля 2025 г.
  • Схема решения
  • Перед началом работы
    • Необходимые платные ресурсы
  • Создайте виртуальный сетевой сегмент
  • Создайте приватные подсети
  • Арендуйте серверы BareMetal
  • Настройте Keepalived на серверах пула ru-central1-m3
  • Убедитесь в работоспособности решения
  • Как отказаться от аренды серверов

Примечание

Сервис Yandex BareMetal находится на стадии Preview.

VRRP (Virtual Router Redundancy Protocol) — это сетевой протокол, предназначенный для повышения отказоустойчивости маршрутизаторов, выполняющих роль шлюза по умолчанию.

Отказоустойчивость достигается за счет объединения в группу двух и более маршрутизаторов в один виртуальный маршрутизатор, который выступает шлюзом по умолчанию для обслуживаемых сегментов сети. Протокол VRRP позволяет создать виртуальный IP-адрес и передавать его между участниками группы, за счет чего повышается доступность шлюза.

В данном руководстве приводится пример организации на серверах BareMetal высокодоступной конфигурации прокси-сервера, в которой функции проксирования симметрично настроены на двух и более узлах HAProxy, а за формирование и передачу виртуального IP-адреса между этими узлами отвечает сервис Keepalived.

Схема решенияСхема решения

В зоне доступности ru-central1-m вы настроите окружение из двух приватных подсетей subnet-m3 и subnet-m4, созданных соответственно в пулах серверов ru-central1-m3 и ru-central1-m4. Эти подсети вы объедините в виртуальный фрагмент сети (VRF) vrrp-vrf.

В подсети subnet-m3 вы создадите два сервера BareMetal — master-server-m3 и backup-server-m3, которые соответственно будут выполнять роли MASTER и BACKUP в VRRP-группе. На двух этих серверах вы запустите сервис Keepalived и настроите с его помощью виртуальный IP-адрес для группы серверов в пуле ru-central1-m3.

В подсети subnet-m4 в пуле серверов ru-central1-m4 вы создадите сервер BareMetal client-server-m4, который будет выступать в качестве клиента при использовании виртуального IP-адреса, созданного в пуле ru-central1-m3.

Данное решение позволяет продемонстрировать комплексную работу клиентского изолированного VRF с маршрутизацией уровня L3 сетевой модели OSI между пулами серверов ru-central1-m3 и ru-central1-m4, а также работу широковещательного протокола VRRP на уровне L2 в пуле серверов ru-central1-m3.

Примечание

Распространение широковещательного трафика (на уровне L2 сетевой модели OSI) происходит только в пределах одного пула серверов и только для группы серверов, находящихся в одной и той же сети.

Чтобы настроить отказоустойчивый кластер серверов BareMetal с использованием VRRP:

  1. Подготовьте облако к работе.
  2. Создайте виртуальный сетевой сегмент.
  3. Создайте приватные подсети.
  4. Арендуйте серверы BareMetal.
  5. Настройте Keepalived на серверах пула ru-central1-m3.
  6. Убедитесь в работоспособности решения.

См. также Как отказаться от аренды серверов.

Перед началом работыПеред началом работы

Зарегистрируйтесь в Yandex Cloud и создайте платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Yandex Cloud или зарегистрируйтесь.
  2. На странице Yandex Cloud Billing убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его и привяжите к нему облако.

Если у вас есть активный платежный аккаунт, вы можете создать или выбрать каталог, в котором будет работать ваша инфраструктура, на странице облака.

Подробнее об облаках и каталогах.

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость предлагаемого решения входит плата за аренду серверов BareMetal (см. тарифы Yandex BareMetal).

Создайте виртуальный сетевой сегментСоздайте виртуальный сетевой сегмент

Чтобы связать несколько приватных подсетей на уровне L3 сетевой модели OSI, их необходимо объединить в виртуальный фрагмент сети (VRF).

Создайте новый VRF:

Консоль управления
  1. В консоли управления выберите каталог, в котором вы будете создавать инфраструктуру.
  2. В списке сервисов выберите BareMetal.
  3. На панели слева выберите VRF и нажмите кнопку Создать VRF.
  4. В поле Имя задайте имя VRF: vrrp-vrf.
  5. Нажмите кнопку Создать VRF.

Создайте приватные подсетиСоздайте приватные подсети

Создайте две приватные подсети в разных пулах серверов и добавьте их в созданный ранее виртуальный фрагмент сети:

Консоль управления
  1. В консоли управления выберите каталог, в котором вы создаете инфраструктуру.
  2. В списке сервисов выберите BareMetal.
  3. На панели слева выберите Приватные подсети и нажмите кнопку Создать подсеть.
  4. В поле Пул выберите пул серверов ru-central1-m3.
  5. В поле Имя задайте имя подсети: subnet-m3.
  6. Включите опцию IP-адресация и маршрутизация.
  7. В поле Виртуальный сетевой сегмент (VRF) выберите созданный ранее сегмент vrrp-vrf.
  8. В поле CIDR укажите 172.28.1.0/24.
  9. Нажмите кнопку Создать подсеть.
  10. Аналогичным образом создайте приватную подсеть subnet-m4 в пуле серверов ru-central1-m4 c CIDR 172.28.2.0/24.

Арендуйте серверы BareMetalАрендуйте серверы BareMetal

Консоль управления
  1. В консоли управления выберите каталог, в котором вы создаете инфраструктуру.

  2. В списке сервисов выберите BareMetal и нажмите кнопку Заказать сервер.

  3. В поле Пул выберите пул серверов ru-central1-m3.

  4. В блоке Конфигурация выберите подходящую конфигурацию сервера.

  5. (Опционально) В блоке Диск настройте разметку дисков:

    1. Нажмите кнопку Настроить разделы диска.

    2. Укажите параметры разделов. Чтобы создать новый раздел, нажмите кнопку Добавить раздел.

      Примечание

      Чтобы самостоятельно собрать RAID-массивы и настроить разделы дисков, нажмите кнопку Разобрать RAID.

    3. Нажмите кнопку Сохранить.

  6. В блоке Образ выберите образ Ubuntu 24.04.

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

  8. В блоке Сетевые настройки:

    1. В поле Приватная подсеть выберите созданную ранее подсеть subnet-m3.
    2. В поле Публичный адрес выберите Автоматически.
  9. В блоке Доступ:

    1. В поле Пароль воспользуйтесь одним из вариантов создания пароля для root-пользователя:

      • Чтобы сгенерировать пароль для root-пользователя, выберите опцию Новый пароль и нажмите кнопку Сгенерировать.

        Важно

        Этот вариант предусматривает ответственность пользователя за безопасность пароля. Сохраните сгенерированный пароль в надежном месте: он не сохраняется в Yandex Cloud, и после заказа сервера вы не сможете посмотреть его.

      • Чтобы использовать пароль root-пользователя, сохраненный в секрете Yandex Lockbox, выберите опцию Секрет Lockbox:

        В полях Имя, Версия и Ключ выберите соответственно секрет, его версию и ключ, в которых сохранен ваш пароль.

        Если у вас еще нет секрета Yandex Lockbox, нажмите кнопку Создать, чтобы создать его.

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

    2. В поле Открытый SSH-ключ выберите SSH-ключ, сохраненный в вашем профиле пользователя организации.

      Если в вашем профиле нет сохраненных SSH-ключей или вы хотите добавить новый ключ:

      • Нажмите кнопку Добавить ключ.
      • Задайте имя SSH-ключа.
      • Загрузите или вставьте содержимое открытого SSH-ключа. Пару SSH-ключей для подключения к серверу по SSH необходимо создать самостоятельно.
      • Нажмите кнопку Добавить.

      SSH-ключ будет добавлен в ваш профиль пользователя организации.

      Если в организации отключена возможность добавления пользователями SSH-ключей в свои профили, добавленный открытый SSH-ключ будет сохранен только в профиле пользователя создаваемого сервера BareMetal.

  10. В блоке Информация о сервере в поле Имя задайте имя сервера: master-server-m3.

  11. Нажмите кнопку Заказать сервер.

  12. Аналогичным способом арендуйте еще два сервера: с именем backup-server-m3 в пуле серверов ru-central1-m3 и с именем client-server-m4 и подсетью subnet-m4 в пуле серверов ru-central1-m4.

На открывшейся странице со списком серверов BareMetal отобразится информация обо всех созданных серверах. В поле Публичный адрес таблицы скопируйте публичные IP-адреса серверов — они понадобятся для подключения к серверам по SSH.

Примечание

Подготовка серверов и установка на них операционных систем может занять до 45 минут — в это время серверы будут находиться в статусе Provisioning. После завершения установки ОС серверы перейдут в статус Ready.

Настройте Keepalived на серверах пула ru-central1-m3Настройте Keepalived на серверах пула ru-central1-m3

На этом этапе вы установите, настроите и запустите сервис Keepalived на серверах, созданных в пуле ru-central1-m3.

Используйте приведенную ниже инструкцию, чтобы настроить оба сервера — master-server-m3 и backup-server-m3.

  1. Подключитесь к серверу по SSH, использовав сохраненный на предыдущем шаге публичный IP-адрес этого сервера.

  2. Установите сервис Keepalived, выполнив команду:

    sudo apt update && sudo apt install keepalived -y
    
  3. Посмотрите список сетевых интерфейсов сервера:

    ip a
    

    Результат:

    ...
    5: etx2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 00:02:c9:35:fd:31 brd ff:ff:ff:ff:ff:ff
        altname enp6s0d1
        inet 172.28.1.2/24 metric 100 brd 172.28.1.255 scope global dynamic etx2
           valid_lft 3512sec preferred_lft 3512sec
        inet6 fe80::202:c9ff:fe35:fd31/64 scope link
           valid_lft forever preferred_lft forever
    

    В выводе команды найдите интерфейс с IP-адресом, относящимся к диапазону 172.28.1.0/24, назначенному приватной подсети subnet-m3. В примере выше это интерфейс с идентификатором etx2. Идентификатор интерфейса понадобится далее, при настройке Keepalived.

  4. Создайте файл конфигурации Keepalived:

    sudo nano /etc/keepalived/keepalived.conf
    
  5. Добавьте в созданный файл следующую конфигурацию:

    Master
    Backup
    vrrp_instance M3_1 {
        state MASTER
        interface etx2
        virtual_router_id 51
        priority 100
        advert_int 1
    
        authentication {
            auth_type PASS
            auth_pass hGoVjTjSYQq3Epm
        }
    
        virtual_ipaddress {
            172.28.1.254
        }
    
        preempt
    }
    
    vrrp_instance M3_2 {
        state BACKUP
        interface etx2
        virtual_router_id 51
        priority 90
        advert_int 1
    
        authentication {
            auth_type PASS
            auth_pass hGoVjTjSYQq3Epm
        }
    
        virtual_ipaddress {
            172.28.1.254
        }
    
        preempt
    }
    

    Где:

    • vrrp_instance — имя виртуального маршрутизатора:

      • для сервера с ролью MASTER — M3_1
      • для сервера с ролью BACKUP — M3_2
    • state — состояние сервера: MASTER или BACKUP.

    • interface — идентификатор сетевого интерфейса, на котором будет работать виртуальный IP-адрес. В примере выше — etx2.

    • virtual_router_id — уникальный идентификатор VRRP для группы виртуальных маршрутизаторов. Значение должно совпадать для всех серверов в группе.

    • priority — приоритет, позволяющий определить основной и резервный узлы. Установка приоритета на уровне 100 делает сервер основным узлом, на 90 — резервным.

    • advert_int — интервал объявления состояния в секундах.

    • authentication — секция с настройками аутентификации для обеспечения безопасности. Содержимое секции должно совпадать для всех серверов в группе.

    • virtual_ipaddress — виртуальный IP-адрес, который будет управляться этим узлом. Виртуальный IP-адрес:

      • должен относиться к диапазону CIDR, заданному для виртуальной подсети, в которой создана группа северов;
      • должен быть не занят;
      • должен совпадать для всех серверов в группе.
    • preempt — позволяет серверу перейти в состояние MASTER, если его приоритет оказывается выше чем у текущего мастера в группе.

  6. Перезапустите сервис Keepalived:

    systemctl restart keepalived.service
    
  7. Посмотрите журнал логов сервиса Keepalived, чтобы убедиться, что сервис запущен:

    sudo journalctl -u keepalived.service
    

    Результат:

    Master
    Backup
    systemd[1]: keepalived.service - Keepalive Daemon (LVS and VRRP) was skipped because of an unmet condition check (ConditionFileNotEmpty=/etc/keepalived/keepalived.conf).
    systemd[1]: Starting keepalived.service - Keepalive Daemon (LVS and VRRP)...
    Keepalived[4045]: Starting Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+
    Keepalived[4045]: Running on Linux 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 (built for Linux 6.8.0)
    Keepalived[4045]: Command line: '/usr/sbin/keepalived' '--dont-fork'
    Keepalived[4045]: Configuration file /etc/keepalived/keepalived.conf
    Keepalived[4045]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
    Keepalived[4045]: Starting VRRP child process, pid=4046
    Keepalived_vrrp[4046]: (/etc/keepalived/keepalived.conf: Line 10) Truncating auth_pass to 8 characters
    Keepalived[4045]: Startup complete
    systemd[1]: Started keepalived.service - Keepalive Daemon (LVS and VRRP).
    Keepalived_vrrp[4046]: (M3_1) Entering BACKUP STATE (init)
    Keepalived_vrrp[4046]: (M3_1) Entering MASTER STATE
    
    systemd[1]: keepalived.service - Keepalive Daemon (LVS and VRRP) was skipped because of an unmet condition check (ConditionFileNotEmpty=/etc/keepalived/keepalived.conf).
    systemd[1]: Starting keepalived.service - Keepalive Daemon (LVS and VRRP)...
    Keepalived[2751]: Starting Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+
    Keepalived[2751]: Running on Linux 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 (built for Linux 6.8.0)
    Keepalived[2751]: Command line: '/usr/sbin/keepalived' '--dont-fork'
    Keepalived[2751]: Configuration file /etc/keepalived/keepalived.conf
    Keepalived[2751]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
    Keepalived[2751]: Starting VRRP child process, pid=2752
    Keepalived_vrrp[2752]: (/etc/keepalived/keepalived.conf: Line 10) Truncating auth_pass to 8 characters
    Keepalived[2751]: Startup complete
    Keepalived_vrrp[2752]: (M3_2) Entering BACKUP STATE (init)
    

Убедитесь в работоспособности решенияУбедитесь в работоспособности решения

  1. Убедитесь, что виртуальный IP-адрес был добавлен к сетевому интерфейсу сервера с ролью Master:

    1. Подключитесь по SSH к серверу master-server-m3.

    2. Посмотрите конфигурацию сетевого интерфейса, назначенного приватной подсети subnet-m3.

      ip a
      

      Результат:

      ...
      5: etx2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
          link/ether 00:02:c9:35:fd:31 brd ff:ff:ff:ff:ff:ff
          altname enp6s0d1
          inet 172.28.1.2/24 metric 100 brd 172.28.1.255 scope global dynamic etx2
          valid_lft 3575sec preferred_lft 3575sec
          inet 172.28.1.254/32 scope global etx2
          valid_lft forever preferred_lft forever
          inet6 fe80::202:c9ff:fe35:fd31/64 scope link
          valid_lft forever preferred_lft forever
      

      Сетевой интерфейс получил дополнительный виртуальный IP-адрес, который был задан в настройках Keepalived — 172.28.1.254/32.

  2. С помощью ICMP-запросов из приватной подсети subnet-m4 убедитесь в доступности виртуального IP-адреса, расположенного в приватной подсети subnet-m3:

    1. Подключитесь по SSH к серверу client-server-m4.

    2. Выполните команду:

      ping 172.28.1.254 -s 1024 -c 5
      

      Результат:

      PING 172.28.1.254 (172.28.1.254) 1024(1052) bytes of data.
      1032 bytes from 172.28.1.254: icmp_seq=1 ttl=62 time=0.211 ms
      1032 bytes from 172.28.1.254: icmp_seq=2 ttl=62 time=0.242 ms
      1032 bytes from 172.28.1.254: icmp_seq=3 ttl=62 time=0.264 ms
      1032 bytes from 172.28.1.254: icmp_seq=4 ttl=62 time=0.312 ms
      1032 bytes from 172.28.1.254: icmp_seq=5 ttl=62 time=0.273 ms
      
      --- 172.28.1.254 ping statistics ---
      5 packets transmitted, 5 received, 0% packet loss, time 4117ms
      rtt min/avg/max/mdev = 0.211/0.260/0.312/0.033 ms
      

      Использованная команда отправляет и получает пакеты увеличенного размера: все пакеты были доставлены без потерь.

  3. Убедитесь в корректной работе балансировщика Keepalived:

    1. Подключитесь по SSH к серверу client-server-m4.

    2. В отдельном окне терминала подключитесь по SSH к серверу master-server-m3.

      Расположите окна терминала так, чтобы одновременно видеть содержимое обоих окон.

    3. В окне терминала с сессией подключения к серверу client-server-m4 повторно запустите утилиту ping без ограничения на количество повторений:

      ping 172.28.1.254 -s 1024
      

      В процессе выполнения этого опроса в окне терминала с открытой сессией подключения к серверу master-server-m3 остановите сервис Keepalived, выполнив команду:

      sudo systemctl stop keepalived
      

      В момент остановки сервиса наблюдайте за окном терминала с сессией подключения к client-server-m4. Результатом корректной работы процесса по передаче виртуального IP-адреса должно быть практически бесшовное переключение ICMP-запросов на резервный хост, при этом выполнение команды ping не должно прерваться.

      Примечание

      Допускается минимальная потеря пакетов (1-3), что обусловлено срабатыванием таймера выбора нового MASTER в группе и передаче ему виртуального адреса.

      Результат:

      PING 172.28.1.254 (172.28.1.254) 1024(1052) bytes of data.
      1032 bytes from 172.28.1.254: icmp_seq=1 ttl=62 time=0.249 ms
      ...
      1032 bytes from 172.28.1.254: icmp_seq=56 ttl=62 time=0.224 ms
      1032 bytes from 172.28.1.254: icmp_seq=57 ttl=62 time=0.314 ms
      1032 bytes from 172.28.1.254: icmp_seq=58 ttl=62 time=0.278 ms
      ^C
      --- 172.28.1.254 ping statistics ---
      58 packets transmitted, 55 received, 5.17241% packet loss, time 58368ms
      rtt min/avg/max/mdev = 0.185/0.271/0.326/0.035 ms
      
    4. В окне терминала с открытой сессией подключения к серверу master-server-m3 запустите сервис Keepalived, выполнив команду:

      sudo systemctl start keepalived
      
  4. Проверьте журнал логов сервиса Keepalived на сервере с ролью BACKUP:

    1. Подключитесь по SSH к серверу backup-server-m3.

    2. Посмотрите журнал логов сервиса Keepalived:

      sudo journalctl -u keepalived.service
      

      Результат:

      ...
      # регистрация события о переключении на MASTER в момент остановки сервиса на исходном основном узле
      Feb 19 07:08:07 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Entering MASTER STATE
      
      # регистрация события о переключении на BACKUP при восстановлении работы сервиса на исходном основном узле
      Feb 19 07:08:31 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Master received advert from 172.28.1.2 with higher priority 100, ours 90
      Feb 19 07:08:31 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Entering BACKUP STATE
      ...
      

      Как видно из журнала работы сервиса и добавленных в него комментариев, после остановки сервиса Keepalived на сервере master-server-m3, роль основного узла перешла к серверу backup-server-m3. После восстановления работоспособности сервиса на сервере master-server-m3 роль основного узла была ему возвращена, а сервер backup-server-m3 вновь стал резервным.

Как отказаться от аренды серверовКак отказаться от аренды серверов

Удалить серверы BareMetal нельзя. Вместо этого можно отказаться от продления их аренды.

Чтобы перестать платить за созданные ресурсы, откажитесь от продления аренды созданных ранее серверов BareMetal.

Была ли статья полезна?

Предыдущая
Удалить транковое подключение
Следующая
Настройка сетевой связности в подсети BareMetal
Проект Яндекса
© 2025 ООО «Яндекс.Облако»