Сайзинг по ролям серверов

Минимальное требование по сетевым интерфейсам для ролей Controlplane, Compute и Ceph — 4 порта 10 Gb Ethernet (две двухпортовые карты или одна четырехпортовая). Для остальных ролей достаточно одной пары сетевых интерфейсов.

Рекомендуется использование 25 Gb Ethernet и более быстрых стандартов. Обратите внимание, что на первой паре интерфейсов агрегируется трафик всех необходимых сетей, на вторую пару выносится трафик СХД (для роли Ceph — отделяется внешний и внутрикластерный трафик). Пары объединяются в bond с использованием протокола LACP. В дальнейшем интерфейсы VLAN создаются на основе созданных bond-интерфейсов.

В базовом варианте используется 3 сервера. Их производительность должна быть сравнима с нодами гипервизоров (compute) и несколько уступать им. Отталкиваться стоит от следующей конфигурации:

• 2x Intel Xeon Gold 5218
• 512 Гбайт ОЗУ
• 4x 480 Гбайт NVMe
• 4х25Gb или 4x10Gb (2x LACP)

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

Минимальные требования:

• 2x Intel Xeon Silver 4210
• 128 Гбайт ОЗУ
• 4x 480 Гбайт SSD
• 4х25Gb или 4x10Gb (2x LACP)

Для установки ОС и служб контроллера достаточно двух SSD накопителей емкостью от 480 Гбайт, рекомендовано использовать накопители емкостью от 960 Гбайт. Вторая пара дисков используется для размещения базы данных. Рекомендуется использовать NVMe устройства.

Накопители настраиваются для обеспечения отказоустойчивости средствами LVM Mirror.

Использование аппаратного RAID-контроллера не рекомендуется.

При необходимости хранить локально большой объем логов может потребоваться увеличение емкости накопителей.

При росте нагрузки произведите масштабирование и выделите серверы для следующих субролей:

• Network: сетевые узлы — контроллеры SDN.

  Минимальное количество узлов Network — 2 штуки, далее возможно добавлять по одному узлу. В зависимости от планируемой нагрузки конфигурация может варьироваться от минимально рекомендованной до соответствующей основным узлам Controlplane. Рекомендуемое количество — по одному узлу на каждые 150 виртуальных маршрутизаторов и 300 DHCP-агентов (соответствует удвоенному количеству виртуальных сетей с включенным DHCP).

• K8s: рабочие ноды (worker nodes) служебного кластера Kubernetes.

  Минимальное количество рабочих нод k8s — 3 штуки, далее можно добавлять по одному узлу. Рекомендуемая конфигурация соответствует основным узлам Controlplane.

• DB: узлы служебного кластера СУБД Galera.

  Минимальное количество узлов DB — 3 штуки, далее можно добавлять по одному узлу. Рекомендуемая конфигурация соответствует основным узлам Controlplane. При этом им требуется по 2 основных сетевых интерфейса вместо 4, поскольку не требуется подключение к СХД. Настоятельно рекомендуется использовать NVMe накопители. В зависимости от объема БД может потребоваться увеличение емкости накопителей.

VK Private Cloud поддерживает возможность переподписки по CPU и RAM.

Коэффициенты должны быть согласованы с заказчиком, до него должен быть донесен их смысл и возникающие ограничения.

Требования к суммарным ресурсам Compute-узлов определяются как отношение требований для пула ресурсов к коэффициенту переподписки по данному ресурсу.

Рекомендации по выбору платформ:

• Используйте двухсокетные платформы.

• Используйте процессоры с наибольшим количеством ядер из доступных для выбранных платформ.

  Например, одним из оптимальных вариантов является Intel Xeon Gold 6238R (28 ядер).

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

• Не используйте процессоры с количеством ядер менее 12-14.

Количество узлов определяется отношением суммарного количества требуемых процессорных ядер к количеству ядер процессоров одной платформы (количество ядер одного процессора х2 — для двухсокетных) умноженному на коэффициент переподписки по vCPU.

$$Q_{hv} = \frac {Q_{req}}{Q_c \ast K_{oc}}$$

• $Q_{hv}$ — количество гипервизоров.
• $Q_{req}$ — требуемое количество vCPU.
• $Q_{c}$ — количество физических ядер в одном гипервизоре.
• $K_{oc}$ — коэффициент переподписки по vCPU.

Необходимый объем памяти определяется исходя из полученного на предыдущем шаге количества узлов: требуемый объем памяти разделенный на коэффициент переподписки и умноженный на количество узлов. К полученному числу добавить 16 Гбайт для сервисов гипервизора и округлить вверх до ближайшего объема памяти, валидированного к установке в сервер.

$$V_{mem} = \frac {V_{req}}{Q_{hv} \ast K_{om}} + 16$$

• $V_{mem}$ — объем памяти в одном сервере.
• $V_{req}$ — требуемый объем памяти для ВМ.
• $K_{om}$ — коэффициент переподписки по памяти.

Для установки ОС и служб гипервизора достаточно двух SSD накопителей емкостью от 480 Гбайт. Подойдут как SAS/SATA, так и NVMe устройства.

Накопители настраиваются для обеспечения отказоустойчивости средствами LVM Mirror.

Использование аппаратного RAID-контроллера не рекомендуется.

При необходимости хранить локально большой объем логов может потребоваться увеличение емкости накопителей.

Пример расчета:

• Требуется получить 750 vCPU и 2 Тбайт ОЗУ для ВМ.
• Коэффициенты переподписки — 4 по vCPU и 1,5 по памяти.
• Используются серверы с 2х Intel Xeon Gold 6238R.
• Итого: 48 ядер на платформу.
• Кол-во серверов = 750/4/48 = 3.9 ~ 4 сервера.
• Объем памяти = (2048/1,5/4)+16 = 357,3 ~ 384 Гбайт.
• Так как особых требований не заявлено, подойдут диски на 480 Гбайт.

Результат: потребуется 4 сервера с 2х6238R, 384 Гбайт ОЗУ и 480 Гбайт SSD каждый.

Ключевые подходы к сайзингу этой роли:

• Разбиение большой СХД на группу небольших кластеров Ceph — 3, 6 или 9 узлов в каждом.
• Определение требования к ёмкости и производительности СХД.

Допустимо, но не рекомендуется создание кластеров из 12 узлов Ceph. Общее требование для любого количество узлов в кластере — общее число OSD не более 150. Для устройств типа HDD и SAS/SATA SSD используется по 1 OSD на каждый накопитель, для устройств NVMe — по 2 OSD на каждый накопитель.

Также важно учитывать пропускную способность сети. Например, 10 Гбит/с сети (20 Гбит/с агрегированный линк) хватит для работы 12 узлов с 12 HDD каждый (144 OSD), но лишь для 6 узлов c 4 NVMe дисками (24 OSD).

Настоятельно рекомендуется в расчетах емкости использовать следующие параметры:

• Коэффициент репликации = 3
• Коэффициент заполнения = 70%

Таким образом, если необходимо получить целевую емкость СХД 100 Тбайт, то суммарная емкость дисков каждого сервера должны быть равна:

$$V_{srv} = \frac {V_{ceph} \ast K_{repl}} {Q_{srv} \ast K_{fill}}$$

• $V_{ceph}$ — полезный объем кластера СХД.
• $V_{srv}$ — общий объем накопителей в одном сервере.
• $Q_{srv}$ — количество серверов в кластере.
• $K_{repl}$ — коэффициент репликации.
• $K_{fill}$ — коэффициент заполнения.

Пример:

Для кластера из 9 узлов:

$$\frac {100 \text{Тбайт} \ast 3} {9 \text{узлов} \ast 70\%} = 47,6 \text{Тбайт}$$

Что соответствует 13 дискам 3,84 Тбайт или 7 дискам по 7.68 Тбайт.

При проектировании необходимо также учитывать следующие моменты:

1. Не допускать статусов undersized, degraded, nearfull (70-75%).

   • Если занято более 70-75% диска, то:

     • при выполнении backfill — тормозят операции на нодах с HDD.
     • при выполнении recover — тормозят и HDD, и NVMe.

   • Если занято 80% — Ceph практически перестает работать.

2. При объединении разных типов дисков в одном кластере необходимо разносить разные типы дисков по разным root в CRUSH-карте на одном узле.

3. Не использовать балансер.

4. Рекомендуемое количество PGs — 100-130 для одного OSD.

Базовая конфигурация:

• 2x Intel Xeon Silver 4210R
• 128 Гбайт ОЗУ
• 2x480 Гбайт SSD, 6x7.68 Тбайт SSD
• 4х25Gb или 4x10Gb (2x LACP)

Для инсталляций с малым объемом СХД и тестовых стендов допустимо:

• Уменьшать объем памяти до 64 Гбайт для рабочих инсталляций и 32 Гбайт для тестовых.
• Заменять процессоры на младшие Xeon Bronze или использовать старшие однопроцессорные платформы (10+ ядер).

При больших емкостях СХД (100+ Тбайт на кластер) может потребоваться удвоение объема памяти. Увеличение мощности процессоров как правило не требуется.

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

В качестве меры защиты данных используется механизм LVM Mirror.

При необходимости наращивания емкости СХД можно использовать несколько таких серверов с качестве единого бэкенда хранения данных.

Отличия от Ceph:

• Для достижения требуемых показателей производительности использовать NVMe диски.
• Базовая конфигурация оптимальна для всего спектра нагрузок и емкостей.

В расчетах емкости накопителей используйте следующие параметры:

• Коэффициент репликации = 2.
• Коэффициент заполнения = 70%.

Для расчета емкости накопителей пригодны те же формулы, что и для Ceph.

Базовая конфигурация:

• 2x Intel Xeon Silver 4210R
• 128 Гбайт ОЗУ
• 2x480 Гбайт SSD, 6x7.68 Тбайт NVMe
• 2х25Gb или 2x10Gb (LACP)

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

Для инсталляций с количеством гипервизоров до 100 штук достаточно одного сервера для обеих функций. При дальнейшем росте инсталляции или требований к объему хранимых данных возможно усиление конфигурации сервера и разделение обработки логирования и мониторинга по двум серверам.

Требования к накопителям могут меняться в зависимости от требований к длительности хранения информации и детальности логирования.

Базовая конфигурация:

• 2x Intel Xeon Silver 4210R
• 128 Гбайт ОЗУ
• 2x3.84 Тбайт SSD
• 2x10Gb (LACP)

или

• 24 vCPU
• 128 Гбайт ОЗУ
• 4 Тбайт vSSD
• 10Gb

При интеграции объектного хранилища S3 от VK необходимо выделить отдельный сервер или группу серверов для обеспечения логирования хранилища.

Для мониторинга можно использовать общий сервер.

Серверы RS не используются в случае использования сетевого оборудования для реализации работы протокола BGP. Выбор схемы реализации осуществляется совместно с клиентом.

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

• Для production-инсталляций всегда требуется два сервера.
• Для тестовых контуров допустимо использовать один сервер или виртуальную машину.

Базовая конфигурация:

• Intel Xeon E3-1230v6
• 8 (16) Гбайт ОЗУ
• 2x240 Гбайт SSD
• 2x10Gb (LACP)

или

• 4 vCPU
• 8 (16) Гбайт ОЗУ
• 100 Гбайт vSSD
• 10Gb

Допустимо использовать 1 Гбит/с интерфейсы вместо 10 Гбит/с при их отсутствии в доступном оборудовании.

Допустимо использовать как физический сервер, так и ВМ в унаследованной инфраструктуре виртуализации.

Как и остальные серверы платформы, Deploy-сервер должен быть постоянно доступен на протяжении жизненного цикла инсталляции для осуществления административных задач. При временном выходе из строя не влияет на доступность облачных сервисов.

Резервирование данного сервера не требуется. Допустимо использование HDD вместо SSD.

Базовая конфигурация:

• Intel Xeon E3-1230v6
• 8 (16) Гбайт ОЗУ
• 2x960 Гбайт SSD
• 1x10Gb

или

• 4 vCPU
• 8 (16) Гбайт ОЗУ
• 1 Тбайт vSSD
• 10Gb