Масштабирование на грани фантастики

Ведущий тренд последних лет — введение в эксплуатацию гипермасштабируемых центров обработки данных. В 2018 году их число увеличилось на 11% и достигло 430 единиц, а к 2020 году их может стать уже 500. Драйвером роста стал постепенный отказ многих компаний от содержания собственных «железных» серверов в пользу облачных сервисов и покупки виртуальных машин для своих нужд.

Выйти из полноэкранного режима

Развернуть на весь экран

Облачные операторы предоставляют потребителям услугу IaaS (Infrastructure as a Service) — инфраструктура в качестве сервиса. Это целая экосистема, позволяющая запускать виртуальные машины, объединять их и использовать дисковое пространство для хранения данных. При всей простоте идеи сервис IaaS труден в реализации. Необходимо создать «умную», самоконтролируемую систему, способную распределять нагрузку между сотнями тысяч физических машин. Она должна быть устойчивой к сбоям, но при этом гипермасштабируемой — легко и быстро расширяемой по мере увеличения клиентского спроса на ресурсы. Поэтому любому новому провайдеру облачных услуг необходимо правильно спрогнозировать и обеспечить рост аппаратных мощностей. Именно этот аспект влияет на его выживание на рынке и финансовый успех.

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

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

Выходов из этого замкнутого круга всего два. По одному идут глобальные корпорации типа Google — создание «железного» подразделения внутри себя. Другой путь — поставка rackscale-продуктов, специально адаптированных под покупателя. Именно его выбрали облачная платформа SberCloud и поставщик физической инфраструктуры компания Yadro, входящая в экосистему «ИКС Холдинга».

В рамках партнерства разработана долгосрочная стратегия: как из стартовой точки постепенно перейти к большому облаку. Ее центральный элемент — глубокая интеграция производственных процессов двух компаний и кооперация между инженерами продавца «железа» и программистами оператора.

Как итог, SberCloud покупает у Yadro не коробки с серверами, а готовые к работе модули. Они состоят из полностью собранной и многократно протестированной стойки со всеми необходимыми компонентами: серверами, системами хранения, коммутаторами и т. д. Но самое важное: оборудование полностью интегрировано с предварительно развернутым программистами SberCloud софтом, благодаря чему каждая стойка заранее оптимизирована под конкретный облачный сервис российского провайдера.

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

Алексей Шелобков, Артем Икоев