Масштабирование мощностей в облачной среде
С развитием бизнеса увеличивается нагрузка на ИТ-инфраструктуру и необходимость в дополнительных вычислительных мощностях. Так у компаний возникает потребность в масштабировании. Особенно это актуально для сфер бизнеса с волнообразным спросом, например ретейла. В период распродаж нужно срочно наращивать ресурсы, а потом их оперативно сокращать.
Проблема в том, что покупать, настраивать и обслуживать собственное оборудование накладно: нужно заказывать дорогие серверы с запасом, долго ждать доставку, платить заработную плату специалистам с высокой квалификацией и т. д. Но есть альтернативный вариант — арендовать ресурсы в облаке. Какие бывают типы и какую стратегию лучше выбрать бизнесу?
Зачем расширяться в облаке
Масштабирование в облаке целесообразно, когда:
-
текущее оборудование устарело или ломается. Например, актуальная линейка СХД любого вендора устаревает через три-пять лет, и обновить ее достаточно сложно, а новое оборудование проблематично заказать из-за нарушения цепочек поставок. Срок жизни серверов ограничивается также тремя-пятью годами, поэтому после трех лет использования их отправляют под второстепенные проекты;
-
вычислительных мощностей становится недостаточно, потому что проекты интенсивно растут, бизнес развивается либо старое оборудование выходит из строя;
-
у текущего облачного провайдера нет ресурсов. Например, бизнес запускает новый проект, а поставщик услуг не выдает дополнительные вычислительные мощности, потому что сам ждет поставку, закончились ресурсы либо на это есть другие причины.
Почему бизнес считает, что расти в облаке сложно
У бизнеса часто есть предрассудки по поводу масштабирования в облаке, которые мешают эффективно распоряжаться облачными ресурсами. Если у компании уже имеется своя инфраструктура, развернутая с помощью определенных инструментов и средств, ИТ-специалисты могут решить, что расширить вычислительные мощности в облаке будет сложно. Но это не так.
Ситуация 1. Инфраструктура развернута на VMware локально или у другого провайдера
После ухода VMware купить лицензии стало невозможно, пользователи лишились поддержки и обновлений, но сама виртуализация работает. Облачные провайдеры продолжают предоставлять на ней облака.
Коммерческие заказчики, у которых уже была своя инфраструктура на VMware, тоже продолжают жить на этой виртуализации. Да, они лишились поддержки и обновлений — кто-то не обновляется уже почти год, другие компании находят способы получить доступ к новым версиям и использовать их. Проще всего международным организациям, у которых есть контракты с VMware в других странах. В этом случае личный кабинет работает в штатном режиме и все доступно.
Из общего ряда выбиваются компании, которые имеют отношение к госсектору или попадают под пристальное внимание регуляторов. Таких компаний в РФ много, если не большинство. Им поставлена задача импортозамещения с четко прописанными сроками по миграции на российскую виртуализацию. По данным ITGLOBAL.COM, спрос на виртуализацию, состоящую в Реестре отечественного ПО Минцифры, за 2022 год вырос в десятки раз.
Ситуация 2. Инфраструктура развернута на другой виртуализации
Многие компании ошибочно считают, что если у них или у их провайдера инфраструктура развернута на Hyper-V, KVM и других виртуализациях, то обязательно нужно найти провайдера, который тоже работает на ней. Но виртуализация — это лишь инструмент для построения сервисов компании. И если площадки взаимодействуют на уровне приложений, совершенно неважно, какая виртуализация лежит под ними.
Ситуация 3. Инфраструктура развернута на физическом оборудовании
Оборудование может быть собственное или арендованное — в любом случае вычислительные мощности могут неожиданно закончиться, а возможности оперативно расшириться не будет. Но можно построить сеть, когда разные части сервисов будут находиться на разных площадках и взаимодействовать как единое целое.
Поэтому можно сказать, что нет никаких ограничений. Вне зависимости от того, что у бизнеса есть в текущей инфраструктуре, расширяться можно несколькими способами.
Какие существуют стратегии масштабирования
Заказчики, которые не дождались поставок оборудования из-за санкций, дефицита чипов и нарушения цепочек поставок, как правило, уже имеют свою on-premise-инфраструктуру. В таких ситуациях можно масштабироваться в облаке сервис-провайдера и полностью мигрировать в клауд, чтобы не зависеть от закупок оборудования и сэкономить на инженерном персонале. Существует две стратегии масштабирования, у каждой есть как плюсы, так и минусы.
Частное облако
Плюсы
-
изолированная и защищенная инфраструктура, серверы выделены под конкретную компанию;
-
можно развернуть на собственном оборудовании или в дата-центре облачного провайдера, самостоятельно выбрать класс и производителя;
-
подходит для размещения бизнес-критичных сервисов и персональных данных;
-
возможность выполнять самые жесткие требования от отдела ИБ, регуляторов;
-
реализация индивидуальных требований по СХД и архитектуре;
-
самостоятельное управление ресурсами через единую панель;
-
если у заказчика гибридная инфраструктура, частное облако позволяет быстрее подключить инфраструктуру провайдера к инфраструктуре клиента.
Минусы
-
менее гибкая масштабируемость по сравнению с публичным, поэтому не подходит для сервисов, в которых потребляемые ресурсы регулярно меняются;
-
дороже по сравнению с публичным облаком;
-
не предусмотрен биллинг по факту существующих ВМ и их потребления. Невозможно сформулировать стоимость 1 vCPU или 1 GB RAM, так как
-
переподпиской управляет заказчик.
Кейс
В мае 2020 года один банк из-за пандемии не мог вовремя получить закупленное оборудование и решил зарезервировать 1500 VDI в частном облаке, чтобы высвободить свои мощности и дождаться поставки серверов. Через несколько месяцев специалисты банка решили разместить на облачной площадке не резерв, а сами VDI в production.
После пандемии бизнес столкнулся с контейнерным кризисом, санкциями и потерей доступа к поддержке и лицензиям. Эти факторы побудили банк разместить больше своих сервисов в облаке. Сейчас у клиента, помимо своих ресурсов, есть три облачные площадки, каждая на несколько тысяч рабочих мест, в процессе реализации — четвертая.
Публичное облако
Плюсы
-
гибкое и легко масштабируемое решение, поэтому подходит для отраслей бизнеса с пиковыми нагрузками. Например, перед распродажей можно увеличить вычислительные мощности, а после — сократить;
-
нет необходимости в капитальных затратах и инвестициях, не нужно закупать оборудование и обслуживать его;
-
облако администрирует клауд-провайдер, поэтому бизнесу не нужно нанимать инженеров и администраторов виртуализации;
-
публичное облако можно развернуть за несколько часов и сразу же начать в нем работать;
-
оплата происходит по модели pay-as-you-go: только за те ресурсы, которыми заказчик пользовался по факту.
Минусы
-
подходит не для всех бизнес-критичных сервисов с точки зрения информационной безопасности и политики по управлению рисками;
-
типизированная инфраструктура не учитывает индивидуальных особенностей конкретного бизнеса;
-
облачный провайдер самостоятельно решает, какое оборудование и программное обеспечение для виртуализации использовать;
-
инфраструктура не изолирована, поэтому ресурсы приходится делить с другими заказчиками. Это может влиять на доступность сервисов в пиковые сезоны. Например, в период сдачи отчетности или праздничные дни.
Кейс
У авиакомпании во время распродаж постоянно падал сайт, из-за этого количество продаж снижалось, финансовые показатели падали, а клиенты уходили к конкурентам. Было принято решение разместить сервис в публичном облаке. Миграция позволила масштабировать ресурсы при распродажах и акциях: впервые сайт авиакомпании перестал падать и зависать в период пиковых нагрузок, а путешественники могли приобрести билеты онлайн по специальной цене. За последние несколько лет эта группа компаний перенесла в облако еще восемь своих сервисов.
Стоит ли автоматизировать масштабирование
По данным исследования Flexera, 42% компаний используют инструменты автоматизации масштабирования ресурсов, остальные контролируют ресурсы облака вручную. Но, по нашему опыту, автоматизация не идеальна.
Автоматизация масштабирования работает на уровне виртуальных машин, но далеко не все операционные системы поддерживают изменение ресурсов «на лету». Для стабильной работы необходимо каждый раз перезагружать ВМ. Мы собрали негативный опыт и сделали автоматическое масштабирование ВМ средствами гипервизора недоступным, но клиенты могут управлять мощностями с помощью сторонних сервисов, например Terraform.
В случае частного облака мы постоянно мониторим степень загрузки частного облака клиента и оповещаем его, когда ресурсы подходят к концу, предлагая подходящее увеличение. Ресурсы публичного облака мы всегда выдаем с запасом.
Вывод: при масштабировании в облаке важно понимать задачи бизнеса
Выбор типа масштабирования и его стратегии всегда зависит от этапа развития конкретной компании, состояния ее инфраструктуры, потребностей и планов бизнеса по развитию ИТ. Понимание этих фундаментальных вещей — уже половина успеха в правильном выборе облачного решения.
Если необходима изолированная защищенная среда для размещения важных сервисов и данных, то оптимальным вариантом станет частное облако. Если нужны ресурсы для сред разработки и тестирования — подойдет публичное облако.
***
Миграция в облако — это решение, которое позволяет компаниям быстро расти, активно конкурировать на рынке и ускорять цифровую трансформацию бизнеса. Поэтому важно грамотно выбирать поставщика услуг, который сможет проконсультировать по всем вопросам, провести аудит ИТ-инфраструктуры и предложить подходящую стратегию масштабирования в облаке.
Опубликовано 30.01.2023
