Как планировать ресурсы и балансировать нагрузки в облаке? Многие привыкли думать о нем как о каком‑то бесконечном ресурсе — нажал на кнопку, и через несколько секунд виртуальная машина готова. Но это ощущение безграничности, на самом деле, результат большой работы.

Привет, Хабр! Я — Анастасия Стоянова, менеджер эксплуатации K2 Cloud. В этой статье вас ждёт:

рассказ о физической и виртуальной инфраструктуре;
пояснение, почему ВМ ≠ сервер;
описание цикла capacity management с расчетом потребности по трендам, целевым запасом под рост, закупкой и вводом новых мощностей, сверкой плана с фактическим потреблением;
механизмы помогающие пережить пики нагрузки;
и многое другое.

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

Ковальски, нам нужен план! Виртуальная машина не возникает из воздуха

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

Сначала в нее устанавливаются коммутаторы: один нужен для управления оборудованием, еще пара — для обеспечения связи со внешним миром. После этого можно разместить вычислительные серверы, которые дают vCPU и оперативную память.

Но виртуальная машина не может работать без дисков — для этого нужно собрать хотя бы один пул блочного хранилища, например для типа st3:Стандартный. А если заказчик захочет использовать более производительный тип диска или остальные облачные сервисы, то оборудования станет в разы больше.

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

С виртуальными машинами все наоборот — они постоянно меняются. Пользователь может изменить конфигурацию, удалить ВМ, создать несколько копий, а может быть вообще создать 1000 новых…Иногда кажется, что рост объема виртуальных машин вообще зависит от чего угодно — «левой пятки» или ретроградного Меркурия!

Наша основная задача — обеспечить неповоротливыми физическими ресурсами воздушные виртуальные так, что бы «бесконечность» сохранялась.

Именно поэтому управлять облаком — это не столько про эксплуатацию оборудования, сколько про постоянное прогнозирование.

Нельзя просто так взять и купить тысячу серверов

На первый взгляд решение очевидно: зачем постоянно прогнозировать, если можно просто купить огромный запас оборудования?

Увы, но так это не работает. Почему?

Во‑первых, это дорого. Причем не только для провайдера, но и для клиентов, поскольку вместе со стоимостью серверов вырастут расходы на размещение оборудования в ЦОДах, обслуживание, питание и охлаждение. В итоге увеличится себестоимость облака, а вместе с ней и стоимость каждой виртуальной машины. То есть даже самая маленькая ВМ в таком случае будет стоить уже не 1 рубль, а 10, 20, 30 — и так до бесконечности.

Во‑вторых, никто не гарантирует, что эти мощности вообще будут востребованы. Можно годами держать простаивающее оборудование, которое никогда не окупится.

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

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

Capacity Management: как понять сегодня, сколько ресурсов понадобится через четыре месяца

На всякий случай поясню: тренд — это усредненное значение роста ресурса за нужный нам промежуток времени. Для ядер мы считаем его в vCPU в день: берем данные за предыдущие 90 дней и предполагаем, что в следующие 90 дней потребление будет расти примерно с той же скоростью.

Казалось бы, все просто, но есть нюанс. В нашем облаке есть сервис выделенных серверов — весь физический сервер целиком передается одному заказчику. Он управляет размещением виртуальных машин на нем самостоятельно и в веб‑консоли видит, сколько свободных ресурсов ещё осталось.

Однако для общей облачной инфраструктуры такой сервер перестает существовать: даже если на нем работает одна виртуальная машина на два ядра, остальные ресурсы уже нельзя использовать для других клиентов. Собственно, по этой причине выделенные серверы нельзя учитывать так же, как обычные виртуальные ресурсы. Их рост мы прогнозируем не в ядрах, а в количестве физических хостов. И если с vCPU все более‑менее понятно, следующий вопрос на очереди — память.

Почему память мы не прогнозируем отдельно

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

В общих пулах доступны к размещению только ВМ. Мы работаем со стандартными соотношениями vCPU и RAM: 1:2, 1:4 и 1:8.

Первые подходят для небольших виртуальных машин (например, под Kubernetes), вторые — для более ресурсоемких систем вроде 1С. Если посмотреть на все виртуальные машины в облаке, среднее соотношение окажется примерно 1:4. Поэтому при планировании мы исходим именно из него. Таким образом, в сервере, содержащем 128 физических ядер, должно быть установлено не менее 512 ГБ оперативной памяти. Как показала практика, такой подход соответствует реальному потреблению.

А вот с дисками все немного сложнее

Блочные типы хранения требуют отдельного подхода. Во‑первых, потому что существует несколько типов хранилищ — ST3, GP2 и IO2, каждый из которых использует собственный набор дисков. Во‑вторых, каждый пул существует только внутри своей зоны доступности.

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

Прогноз превращается в серверы: закупка

После того как тренды рассчитаны, можно «приземлить» вопрос: сколько оборудования и когда необходимо купить?

Допустим, прогноз на 3 месяца показывает рост на тысячу виртуальных ядер. Мы знаем характеристики наших серверов и можем посчитать, что этот объем обеспечат, например, восемь новых хостов.

А вот у блочного хранилища есть важный нюанс: далеко не весь сырой объем реально установленных дисков доступен для заполнения данными. ⅔ объема забирает репликация, ещё 25% из оставшейся трети — порог заполнения. Но логика остается той же: сначала определяется объем ресурсов, который потребуется облаку, а затем количество оборудования.

Только после этого начинается закупка.

И здесь выясняется, что купить сервер — это отдельный проект.

Планировать новую закупку нужно минимум за 16 недель до установки. Пока средний срок поставки оборудования — 12 недель. Еще 4 недели добавим себе на подготовку — нам нужно всё посчитать, получить цену, поменять поставщика при необходимости, а потом и правильно принять их.

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

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

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

На самом деле, было весело: мы не знали китайского, они — русского. Все немного говорили по‑английски и кое‑как объяснялись жестами. В итоге задачу решили, в BMC попали, а у меня появился верифицированный аккаунт в WeChat.

Но даже после того, как оборудование заказано, возникает вопрос: куда его поставить?

Купить сервер — только половина дела

Казалось бы, ответ очевидный — в стойку. Но они тоже не появляются из воздуха, нужен ЦОД.

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

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

С питанием разобрались — можно ставить оборудование.

Но почему нельзя просто занять первое свободное место в стойке?

Есть свободный юнит — ставим туда сервер, что может пойти не так? Спойлер — все что угодно. Например, наш обычный сервер потребляет всего 800 Вт, а вот сервер с четырьмя картами Nvidia H100 потребляет уже 2,5 чайника, а при условии, что на стандартную стойку выделено всего 10 чайников….

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

У нас получилось этого добиться, потому что мы придерживаемся определенного стандарта.

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

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

Но не стоит обольщаться, что новый ЦОД можно найти за один день. Даже если новый дата‑центр понадобится только через несколько месяцев, готовиться нужно заранее. Во‑первых, площадка должна соответствовать нашим требованиям — она не может быть ниже уровня Tier III, даже если действующего сертификата у нее сейчас нет. Во‑вторых, хорошие ЦОДы — дефицитный ресурс. Во многих известных площадках стойко‑места уже зарезервированы или находятся на стадии строительства. И даже после того, как подходящий ЦОД найден, согласование договора может занять несколько месяцев.

Поэтому мы начинаем процесс сразу, как только понимаем, что такая потребность может возникнуть. Даже если в итоге этот ЦОД не понадобится, лучше иметь возможность быстро развернуть инфраструктуру, чем искать место тогда, когда свободное уже закончилось.

Казалось бы, все самое сложное уже позади: оборудование заказано, стойки подготовлены, остается только дождаться поставки. Но именно в этот момент мы снова возвращаемся к трендам — нельзя один раз сделать прогноз и забыть об этом до приезда новых серверов. Нужно поддерживать ту самую «бесконечность» облака и постоянно отодвигать потолок доступных ресурсов.

Тренд не может сохранять линейность. Что, если произошло вот так?

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

План D: что делать, если спрос растет быстрее прогноза

Чтобы понять, как он работает, нужно разобраться, как вообще виртуальные машины распределяются по физическим серверам.

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

На первый взгляд кажется, что это идеальная стратегия, но есть нюанс — планировщик не может безопасно заполнить сервер на 100% и ничего не знает о реальной нагрузке на ВМ. Если сильно упростить, его работу можно представить как тетрис, только в этой версии игры горизонтальные линии никогда не исчезают.

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

На этот случай есть второй инструмент — дефрагментатор. Он анализирует, какую нагрузку создает каждая виртуальная машина.

Например, одна ВМ может постоянно использовать все выделенные ей процессорные ядра, а другая — в среднем загружать их только на 30%.На основе этой информации дефрагментатор строит план миграции виртуальных машин между хостами. Его задача — максимально плотно заполнить часть серверов и полностью освободить другие. После этого мы проверяем предложенный план и выполняем миграции.

А еще дефрагментатор решает нашу вторую задачу, например, в пулах с не гарантированными ресурсами — чтобы хост был заполнен на 100%, но при этом не нагружен. Мы используем два понятия — заполненность и загруженность.

Заполненный сервер — это сервер, на котором размещено много виртуальных машин. При этом сами по себе они могут практически не нагружать физические процессоры.

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

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

Возникает логичный вопрос: если дефрагментатор умеет так эффективно перераспределять виртуальные машины, почему бы не использовать его постоянно? А мы используем! Но с определенной периодичностью.

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

Окей, с vCPU разобрались, переходим к дискам. В некоторых пулах хранения мы специально оставляем часть слотов под диски пустыми. Например, если в системе предусмотрено 28 дисковых слотов, часть из них может оставаться незанятой. Причина простая: если вычислительный сервер быстро не купишь, то с дисками ситуация гораздо проще — можно ножками пойти в магазин и купить. Поэтому свободные слоты позволяют быстрее увеличить доступный объем хранения, когда это действительно потребуется.

Никто не должен знать, что облако не бесконечно

Все, о чем я рассказывала, остается для пользователя «за кадром»: когда он нажимает кнопку «Создать виртуальную машину», то не думает о том, сколько месяцев назад был рассчитан прогноз, когда заказали серверы, сколько времени они ехали, хватило ли места в дата‑центре, пришлось ли перераспределять виртуальные машины между хостами или искать новую площадку для размещения оборудования. И это правильно.

Облако должно восприниматься как практически бесконечный ресурс: виртуальная машина должна запускаться тогда, когда нужна пользователю. В этом смысле capacity management перестает быть просто расчетами и графиками, а превращается в постоянную работу с прогнозами, закупками, инфраструктурой и существующими ресурсами, чтобы пользователь никогда не столкнулся с ситуацией, когда облако внезапно «закончилось».

Наверное, это и есть главный критерий того, что мы все делаем правильно: никто не должен знать, что облако на самом деле не бесконечно.