Итак, у вас есть свой бизнес и IT-инфраструктура. А еще есть несколько проблем: сервис зависает под наплывом пользователей, соседи по облаку «крадут» ресурсы, виртуальная машина ждет, когда освободятся ресурсы процессора. Наверняка вы уже пробовали добавлять ядер и оперативной памяти: в итоге только получили счет побольше, а проблемы остались, да еще и утилизация ресурсов упала. Давайте разберемся, что могло пойти не так, почему увеличение ресурсов не всегда гарантирует лучшую производительность сервера и что сделать с облаком, чтобы повысить его эффективность и не выкидывать деньги на ветер.
Эта статья — не ультимативный гайд на все случаи жизни. Это обзор фич облака Selectel, которые помогут решить специализированные задачи, когда речь идет о высоких нагрузках.
Линейка HighFreq
HighFreq — это линейка конфигураций облачных серверов с высокопроизводительными процессорами: Intel® Xeon™ Gold 6354, AMD EPYC™ 9474F или AMD EPYC™ 9554. Лучше всего они покажут себя в:
- обработке транзакций в СУБД,
- игровых серверах,
- 1С, ERP, Битрикс 24 и сложной бизнес-логике,
- финансовых и других системах, требовательных ко времени отклика.
Для таких задач характерна общая особенность — процессы в них не распараллеливаются между несколькими ядрами процессора. То есть здесь 2–3 ядра по 3 ГГц покажут себя лучше, чем 4–6 по 2,4 ГГц. А еще они обойдутся дешевле. К примеру, небольшому бизнесу финансово будет выгоднее развернуть Битрикс 24 на HighFreq с двумя vCPU, чем арендовать выделенный сервер целиком. Его лучше оставить под задачи, в которых важна физическая изоляция «железа».
Но вернемся к линейке HighFreq. Процессоры под нагрузкой разгоняются до частоты 3,6 ГГц. К тому же, серверы комплектуются оперативной памятью DDR5 с тактовой частотой до 4,8 ГГц. Добавьте к этому возможность подключить быстрые диски и гарантированный SLA 99,98% — и вот в распоряжении вашего бизнеса мощный облачный сервер, который позволяет быстро обрабатывать запросы и поддерживать стабильность и отзывчивость вашего сервиса.
Серверы линейки HighFreq доступны в фиксированных и произвольных конфигурациях. В обоих случаях вам доступно до 32 vCPU и до 190 ГБ RAM.
Облачные серверы с выделенными ядрами
В обычном облачном сервере никакие физические ресурсы за вами не закреплены. Конечно, в панели управления можно накликать побольше vCPU, но важно понимать, что эти ядра будут виртуальными. Они не закреплены за физическими, а постоянно переключаются между ними. В небольшой IT-инфраструктуре это некритично и вы, скорее всего, даже никогда не столкнетесь со Steal Time (это время, в течение которого виртуальная машина не получает ресурсы процессора).
Другое дело, если у вас в облаке что-то серьезное: высоконагруженные базы данных, финансовые системы, e-com, игровые серверы, микросервисные приложения и API с высокой частотой запросов и тому подобное. В этих сценариях вы точно захотите, чтобы процессор ВМ работал максимально эффективно.
Вот тут-то и пригодятся выделенные ядра. Они закреплены за потоками конкретных физических ядер процессора — получается аппаратная изоляция нагрузки, которая исключает задержки и обеспечивает стабильную производительность.
Настройка выделенных ядер доступна при создании или изменении конфигурации облачного сервера в панели управления.
Hyper-Threading
Для облачного сервера с выделенными ядрами по умолчанию включена опция Hyper-Threading (SMT, или гиперпоточность). Это технология, которая позволяет одному физическому ядру процессора обрабатывать два потока одновременно. В таком случае каждая пара vCPU облачного сервера соответствует двум потокам одного физического ядра процессора.
Эта технология повышает производительность на многопоточных задачах, например при работе веб-серверов и корпоративных приложений или рендеринге и обработке видео.
Здесь нужно сделать оговорку. Hyper-Threading — классная штука, которая действительно может повысить производительность сервисов в облаке. Главным образом — за счет адаптации процессора под профиль нагрузки приложения или сервиса. И тут вторая важная оговорка: избегайте принципа «Больше — значит лучше».
Если нужна гиперпоточность — включайте, если не нужна — не включайте, все просто. Если не знаете, нужна она или нет, лучше сначала протестируйте разные конфигурации. Отключение функции подойдет для HPC-вычислений, работы аналитических баз данных (OLAP) и ПО с лицензированием по физическим ядрам. Гиперпоточность можно выключить в настройках в панели управления на странице конфигурирования облачного сервера.
При отключении Hyper-Threading отключаются потоки, а количество vCPU на облачном сервере уменьшается вдвое. Например, вы создаете облачный сервер с включенной гиперпоточностью и 8 vCPU. Облачный сервер будет использовать четыре физических ядра, каждое из которых работает в режиме Hyper-Threading, то есть обрабатывает по два потока. Таким образом у облачного сервера и получается 8 vCPU.
Если вы отключите опцию Hyper-Threading, количество vCPU сократится до четырех и будет соответствовать количеству физических ядер, а не количеству потоков. Количество занятых физических ядер не изменится, поэтому стоимость облачного сервера останется такой же.
| Hyper-Threading включен | Hyper-Threading выключен | |
| Количество vCPU на облачном сервере | 8 | 4 |
| Физические ядра | 4 | 4 |
| Стоимость облачного сервера | 100% | 100% |
Перед отключением Hyper-Threading обязательно протестируйте производительность приложений под нагрузкой — некоторые приложения без Hyper-Threading могут работать медленнее.
Размещение ресурсов на одной NUMA-ноде
NUMA (Non-Uniform Memory Access) — это архитектура многопроцессорных систем. NUMA-ноды — это архитектурные блоки в многопроцессорных системах, где нода включает один процессор и локальную оперативную память. Смысл в том, что в таком случае доступ к локальной RAM у процессора внутри ноды будет с очень низкой задержкой — на 20–50% ниже обычной. Здесь важно учесть ограничение — при размещении ресурсов на одной NUMA-ноде облачный сервер будет работать только внутри нее. Но чего ни сделаешь ради производительности.
Такой подход, как и гиперпоточность, опционален. Вы можете управлять им как при создании облачного сервера, так и при изменении его конфигурации. Но помните, что он доступен только в конфигурациях с выделенными ядрами и от 4 vCPU. Включить обязательное размещение ресурсов на одной NUMA-ноде для облачных серверов без выделенных ядер нельзя.
Ограничения
Облачные серверы с выделенными ядрами доступны только в сегментах пула ru-3b, ru-7a и ru-7b. Настройка выделенных ядер доступна только для облачных серверов линеек Standard и HighFreq. Список флейворов фиксированных конфигураций линеек, которые поддерживают работу с выделенными ядрами, можно посмотреть в документации.
| Фиксированные конфигурации | Произвольные конфигурации | |
| vCPU | от 2 до 32 (Standard) или до 64 (HighFreq) | до 232 |
| RAM | от 4 ГБ до 256 ГБ | до 900 ГБ |
| Локальный диск | от 32 ГБ до 1 ТБ | до 2 ТБ |
Сверхбыстрая сеть 10Гбит/c
Для решения стандартных задач подходят стандартные инструменты. Это справедливо и для сети. Например, когда вы создаете облачный сервер в панели управления, по умолчанию вам предлагается сеть с пропускной способностью 3 Гбит/с. И в большинстве случаев этого достаточно.
Но давайте представим, что у вас есть нагруженный финтех-сервис и большая база данных. Скажем, на 20+ ТБ. Вы подошли к вопросу серьезно, поэтому на одной виртуальной машине разместили мастер, на двух других — реплики. При этом реплицирование должно происходить в реальном времени, потому что иначе, если что-то случится с мастером, замедлится работа всего сервиса. А это уже не очень хорошо хотя бы потому, что за стабильностью работы финтеха пристально следят регуляторы. Значит, задача — сделать так, чтобы реплики минимально отставали от мастера.
Вот тут-то сеть и может превратиться в «бутылочное горлышко», когда даже 3 Гбит/с будет недостаточно. Выход в данном случае — более высокая пропускная способность.
10 Гбит/с позволяет сократить время передачи больших объемов данных — будь то описанная выше репликация БД, миграция систем, обработка больших данных, работа с распределенными кластерами и так далее. Допустим, вам нужно сделать бэкап базы данных, которая занимает 1 ТБ. Через стандартную сеть на это уйдет примерно 57 минут, а через 10-гигабитную — всего около 17. К слову, сеть можно использовать для связи IT-инфраструктуры и в пределах одного дата-центра.
10-гигабитная сеть в облаке Selectel доступна в сегментах пула ru-3b (Санкт-Петербург), ru-7a и ru-7b (Москва) в конфигурациях с выделенными ядрами на процессорах Intel линейки HighFreq.
Фиксированные конфигурации включают:
- 16 vCPU,
- от 32 до 128 ГБ RAM,
- от 256 ГБ до 2 ТБ на локальном SSD.
В произвольных конфигурациях доступны:
- от 12 до 16 vCPU,
- от 512 МБ до 128 ГБ RAM,
- от 8 ГБ до 2 ТБ на локальном SSD.
Эти статьи будут полезны, если вам нужна облачная IT-инфраструктура
Виртуальная машина размером с хост
Бывает и так, что экономически вас полностью устраивает классическое облако. Вы платите только за фактически потребленные ресурсы по модели «pay-as-you-go», добавляете или убираете ресурсы в пару кликов без длительного ожидания, не озадачиваете себя вопросами подбора, настройки, обслуживания и содержания железа, при необходимости подключаете и используете облачные сервисы вроде DBaaS или Managed Kubernetes без большой команды собственных специалистов.
Но как быть, если вы работаете с софтом, для которого критична привязка к физическому оборудованию, или запускаете сервис с высокими требованиями к изоляции вычислительной нагрузки?
Если переезжать на выделенные серверы вы не готовы, то оптимальное решение — облачный сервер на выделенном хосте (Dedicated Cloud Servers, DCS). Вы получаете удобство облака и размещение без «соседей» по инфраструктуре, а следовательно — повышенную безопасность и отсутствие конкуренции за вычислительную мощность. Такие виртуальные машины, как и обычное облако, тарифицируются по модели «pay-as-you-go», то есть оплата происходит по фактическому потреблению ресурсов. А еще их можно использовать как прерываемые.
Впрочем, тут тоже есть несколько ограничений, которые стоит учесть:
- доступны только фиксированные конфигурации, собрать в панели управления кастомный облачный сервер на выделенном хосте не получится (зато получится по индивидуальному запросу, даже с GPU);
- размещение сервера возможно только в сегменте пула ru-3b;
- конфигурации линейки доступны только с поддержкой работы облачных серверов с выделенными ядрами;
- в каждом сервере доступно 14 vCPU, 64 ГБ или 86 ГБ RAM (но это пока; в будущем мы увеличим лимит до 232 vCPU и добавим конфигурации с GPU).
Если нужно «обычное» облако, но помощнее
Безусловно, высокопроизводительные и выделенные ядра, 10-гигабитная сеть и целый хост под одну виртуальную машину могут быть и не нужны. А нужна самая классическая виртуальная машина, но с максимумом вычислительных возможностей. Скажем, чтобы перенести на нее увесистый монолит Enterprise-уровня — сложную корпоративную систему или что-то подобное.
На такой случай в произвольных конфигурациях облачных серверов мы увеличили максимальные лимиты ресурсов на одну виртуальную машину. Вот что теперь можно собрать, если разместить сервер в сегментах пула ru-7a и ru-7b.
В линейке Standard:
- до 232 vCPU,
- до 900 ГБ RAM,
- до 2ТБ на локальном диске.
В линейке HighFreq:
- до 176 vCPU,
- до 900 ГБ RAM,
- до 2ТБ на локальном диске.
Вскоре в нашем блоге выйдет еще несколько статей с более подробным разбором каждой фичи, сценариями их применения и результатами тестов. Не отключайтесь.
