Как не нужно работать с выделенными серверами

Аренда

Ошибка: сразу брать сервер на длительный срок

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

Отказ от аренды — это отмена дальнейшего продления, но сервер продолжит работать до конца текущего периода аренды, и только потом будет удалён.

Одна из ошибок — заказ сервера на большой срок, без его проверки и тестирования под свои задачи.

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

Настройка и управление выделенными серверами

Ошибка: устанавливать пароль BIOS

Пароль BIOS часто воспринимают как дополнительную меру безопасности. На практике для Bare Metal это избыточный инструмент контроля доступа.

Доступ к KVM и операциям управления сервером нужно ограничивать через ролевую модель Yandex Cloud. Например, роль baremetal.operator даёт право использовать KVM-консоль и управление питанием. Роли baremetal.editor и baremetal.admin дают более широкие права, включая переустановку ОС. А физическая безопасность обеспечивается на уровне дата-центра.

При этом пароль на BIOS осложняет диагностику и обслуживание: если сервер уйдёт в нештатное состояние, специалистам дата-центра может потребоваться больше времени на восстановление или замену оборудования, потому что часть штатных процедур будет заблокирована пользовательским паролем.

Правильный подход: не использовать BIOS-пароль как основной механизм безопасности.

Ошибка: менять пароль или настройки BMC

BMC — сервисный контроллер, через который платформа управляет сервером на аппаратном уровне по IPMI. Через него работают KVM-консоль, управление питанием, переустановка ОС и получение аппаратных метрик.

Если поменять любые настройки BMC, это может привести к критичным последствиям: KVM-консоль станет недоступной, перестанут работать остановка, запуск и перезапуск сервера через консоль, станет невозможна переустановка ОС, а также перестанут собираться аппаратные метрики сервера: температура процессоров, скорость вращения вентиляторов и другие. При этом с точки зрения производительности или безопасности пользы от изменения параметров BMC нет.

Правильный подход: не менять настройки BMC.

Ошибка: не учитывать BIOS-настройки для высокопроизводительных задач

Сервис Yandex BareMetal даёт доступ к настройкам, которые обычно скрыты за слоем виртуализации. Это позволяет тонко настроить CPU, память, энергопотребление и ввод-вывод под конкретную нагрузку.

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

Что обычно проверяют:

• Power Profile / System Profile / Operating Mode

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

• C-States, C1E, Package C State Limit

  C-States — это состояния энергосбережения, в которые CPU уходит при простое. Отключение глубоких C-States может снизить задержку ввода/вывода, особенно для высоконагруженных баз данных и других задач, чувствительных к задержкам.

• Intel SpeedStep / EIST, AMD P-States, CPU Frequency Scaling

  Эти механизмы динамически меняют частоту CPU в зависимости от нагрузки. Для резких нагрузок и некоторых баз данных это может быть проблемой: процессору нужно время, чтобы поднять частоту.

• Turbo Boost / Core Performance Boost

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

• Hyper-Threading / SMT

  Hyper-Threading или SMT позволяет одному физическому ядру выполнять два аппаратных потока. Для виртуализации и обычных нагрузок это обычно плюс: больше исполняемых потоков и выше общая утилизация CPU. Отключение Hyper-Threading или SMT может быть полезно в специальных случаях: при low-latency-нагрузках, лицензировании по ядрам, специфичных вычислительных задачах.

• VT-x, VT-d, AMD-V, SVM, IOMMU
  Эти настройки нужны прежде всего для виртуализации и изоляции устройств. Если сервер используется как гипервизор, например Proxmox, эти функции лучше включить.

• PCIe ASPM / Link Power Management
  Эти настройки отвечают за энергосбережение PCIe-устройств. Настройка этих опций может понизить задержки при работе с дисками или сетевыми картами.

Ошибка: не учитывать поколение процессора при выборе ОС

Современные дистрибутивы начинают повышать минимальные требования к процессору. Хороший пример — Rocky Linux 10: на x86_64 он больше не поддерживает x86-64-v2 и более старые уровни микроархитектуры — базовым требованием стал x86-64-v3. Поэтому данный дистрибутив не получится установить на ряд серверных конфигураций. Если необходимо работать с оборудованием предыдущих поколений, придётся выбрать Rocky 8/9, Debian^™, Ubuntu^® или другой дистрибутив.

Правильный подход: перед заказом сервера сопоставить:

• поколение CPU
• флаги процессора
• требования ОС
• требования гипервизора или прикладного ПО

Сделать это можно, сверившись с HCL вендора ОС или ПО.

Диски

Ошибка: не использовать RAID

Диски на сервере — это физические устройства. Если установить ОС или разместить данные на один диск без RAID, отказ этого диска может привести к простою, переустановке ОС и потере данных.

Правильный подход: почти всегда нужен RAID. Для системного раздела обычно уместен RAID 1, для данных — RAID 1, RAID 5, RAID 10.

Но следует помнить, что RAID — это не бэкап. RAID помогает пережить отказ диска, но не защищает от удаления файлов или ошибочного форматирования. Одна из опций для решения таких проблем — подключение сервера к Yandex Cloud Backup.

Ошибка: заказать RAID-контроллер и оставить его в HBA/pass-through

При заказе конфигурации по запросу можно взять в аренду сервер с аппаратным RAID-контроллером. Но само наличие контроллера ещё не означает, что данные защищены отказоустойчивым RAID-массивом.

После получения сервера контроллер нужно настроить в подходящий режим и создать на нём RAID-массив. Если оставить контроллер в режиме HBA, диски будут пробрасываться в операционную систему как отдельные физические устройства. В этом случае отказоустойчивость не будет достигнута.

Кроме того, нужно обязательно проверить, совместима ли технология обеспечения отказоустойчивости с вашим ПО и ОС.

Правильный подход: Перед установкой ОС переключить режим RAID-контроллера и настроить параметры массивов.

Ошибка: размещать ОС на дисках, предназначенных для данных

На личном ПК логика простая: быстрый SSD/NVMe — под систему, медленный HDD — под файлы. А вот на сервере эта логика не всегда правильная. В гибридной конфигурации (HDD+SSD/NVMe) быстрый диск — это часто самый ценный ресурс, который нужен приложению: базе данных, виртуальным машинам, индексам. Установка системы на SSD — это не всегда правильное решение.

Правильный подход: разделять системные диски и диски для данных. Типовая схема:

• ОС — на отдельном зеркале, например RAID 1;
• данные — на отдельном массиве, подобранном под нагрузку;
• логи — отдельно, если они интенсивные;
• промежуточное хранение резервных копий / холодные данные — на HDD.

Настройку разделов системы можно задать заранее при установке ОС из Yandex Cloud Marketplace.

Настройка сети

Ошибка: заказать выделенную публичную подсеть и ожидать DНСP на интерфейсе

В выделенных публичных сетях Bare Metal отсутствует DHCP-сервер. Можно либо воспользоваться инструкцией для ручной настройки, либо поднять на одном из серверов собственный DHCP-сервер.

Правильный подход: если нужен публичный доступ сразу после установки, использовать эфемерную публичную подсеть.

Ошибка: не учитывать особенности подсети /31

Эфемерная публичная подсеть — имеет длину префикса /31. Один адрес — шлюз, второй — адрес сервера. Для Linux это нормально, но некоторые ОС и сетевые стеки хуже работают с /31.

Если планируется не Linux-based ОС, лучше заранее рассмотреть выделенную публичную подсеть подходящего размера. Для выделенных публичных подсетей доступны размеры /29, /28, /27, /26, /25, /24, при этом /28 даёт 13 доступных IP-адресов.

Правильный подход: использовать эфемерные публичные подсети только для Linux-based ОС.

Ошибка: не закладывать рост по сети

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

Правильный подход: заранее оценивать не только текущую нагрузку, но и возможный рост. Если есть вероятность, что серверу понадобится расширенный пакет публичного трафика, лучше сразу выбирать конфигурацию с сетевыми интерфейсами 10G/25G.

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

Ошибка: планировать виртуализацию и не учитывать MAC-лимит

При запуске гипервизора на выделенных серверах каждая виртуальная машина будет иметь собственный MAC-адрес. В сетях Yandex BareMetal действует ограничение: по умолчанию пять MAC-адресов на один порт сервера. Увеличить количество MAC-адресов сверх установленного лимита можно только для серверов с сетевыми картами 10 или 25 Гбит/с.

Правильный подход: если планируются Proxmox или другие гипервизоры, заранее выбирайте конфигурацию с сетевыми интерфейсами 10G/25G.

Ошибка: пытаться объединить в bond две разные сети

При проектировании сетевой схемы может потребоваться объединить несколько сетевых интерфейсов в bond, чтобы увеличить пропускную способность или повысить отказоустойчивость подключения.

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

Правильный подход: если требуется отказоустойчивость сетевого подключения, лучше выбирать конфигурации с MC-LAG. В такой схеме сервер подключается к сети через несколько физических интерфейсов, и это обеспечивает отказоустойчивость и повышенную скорость. При установке ОС из образа Marketplace группы агрегирования настраиваются автоматически, а при самостоятельной установке ОС их нужно настроить вручную.

Ошибка: подключить дополнительную приватную подсеть и не настроить VLAN в ОС

В Yandex BareMetal основная приватная подсеть — это native VLAN. Но на том же интерфейсе могут быть дополнительные приватные подсети с помощью tagged VLAN. После привязки дополнительной приватной подсети к серверу нужно вручную настроить VLAN на сетевом интерфейсе в ОС. Кроме того, дополнительная приватная подсеть может быть только с выключенным DHCP.

Ошибка: связывать Yandex BareMetal и VPC через публичный интернет

При построении гибридной инфраструктуры может потребоваться связать по сети серверы Yandex BareMetal с виртуальными машинами в облаке или инфраструктурой on-premises.

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

Правильный подход: использовать приватную связность через Yandex Cloud Interconnect и VRF. Такая схема позволяет соединить приватные подсети Yandex BareMetal с подсетями VPC и, при необходимости, с инфраструктурой on-premises. При проектировании важно заранее проверить адресный план: CIDR-диапазоны Yandex BareMetal, VPC и сетей on-premises не должны пересекаться.

Ошибка: забывать про сетевые ограничения

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

Например, на один сетевой порт по умолчанию доступно пять MAC-адресов. Для обычного Linux-сервера этого достаточно, но для гипервизора это ограничение может стать критичным: каждая виртуальная машина, bridge-схема может использовать отдельный MAC-адрес. Если заранее не учесть этот лимит, часть виртуальных машин может не получить нормальную сетевую связность. При этом на портах 1 Гбит/с увеличить MAC-лимит сверх установленного значения невозможно.

Другой пример — MTU. В публичной сети используется MTU 1500, а в приватной — 8910. Это важно для сценариев хранения, репликации, бэкапов, кластеров и сервисов, которые рассчитывают на джамбо-фреймы. Если одна часть пути настроена на большой MTU, а другая остаётся на стандартном 1500, можно получить неочевидные проблемы: фрагментацию, падение производительности или сетевые ошибки.

Отдельный пункт — доступность портов из интернета. На стороне публичной сети часть входящих и исходящих TCP/UDP-портов ограничена.

Правильный подход: заранее описать сетевой профиль приложения и ответить на вопросы:

• Сколько потребуется MAC-адресов?
• Будет ли на сервере гипервизор?
• Нужны ли джамбо-фреймы?
• Используются ли мульти- и широковещание, VRRP, CARP или discovery-протоколы?
• Какие порты должны быть доступны из интернета?
• Нужны ли дополнительные VLAN?
• Как сервер будет связан с VPC или инфраструктурой on-premises?