Собственные серверы — особенно при дефиците электронных компонентов — могут позволить себе только большие компании. Найти ресурсы сложно, а покупать и поддерживать дата-центр — дорого.

Разворачивать физические дата-центры, искать людей, которые будут их поддерживать, — или осваивать насколько профессий, чтобы делать всё самому, — отнимает время и силы.

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

Виртуальная инфраструктура для экономии ресурсов

IaaS — это набор виртуальных ресурсов: процессоров, памяти, дискового пространства. Клиент заказывает их в личном кабинете на сайте облачного провайдера и получает мощности для виртуального дата-центра. Затем девопсы — или обученные разработчики — делают на базе этих ресурсов виртуальные машины, где размещают среды разработки, тестовые среды, необходимое ПО и так далее.

Чем полезна виртуальная инфраструктура

• Не нужно самому покупать и настраивать оборудование (что особенно полезно, если у вас небольшая компания).
• Можно без проблем увеличивать и уменьшать количество ресурсов самому — через личный кабинет.
• Не обязательно самостоятельно поддерживать инфраструктуру. Некоторые провайдеры выделяют специалистов, которые работают с виртуальными машинами по заявкам клиента.
• Не нужно заботиться о надёжности, доступности и отказоустойчивости сервиса — провайдер занимается этим сам.
• Провайдер гарантирует безопасность. Например, наша платформа защищена центром безопасности (SOC) всего МТС.
• IaaS может автоматизировать масштабирование сервисов по API, например, с помощью Terraform.

Как это выглядит на примере

Один из наших заказчиков решил продублировать на разных площадках значимые ИТ-системы, повысить доступность инфраструктуры и сервисов и снизить затраты на поддержку серверов.

Мы перенесли в облако инфраструктуру бухгалтерского отдела и сопутствующие системы: серверы 1С с базами данных, сервер терминалов, файловый сервер, сервер «Консультант», Active Directory, серверы VPN и DHCP. Безопасность удалённого доступа обеспечили собственным каналом связи и VPN-подключением. А клиент/сервер IPSEC VPN, который входит в состав сервиса Virtual Infrastructure, объединил корпоративную сеть и виртуальную инфраструктуру.

Переход в облако повысил доступность и на 25% ускорил работу ИТ-систем. Теперь при запуске новых продуктов клиент может расширять мощности за 24 часа. В традиционном ЦОДе на это потребовалось бы 1-3 недели.

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

DBaaS для простой и быстрой работы с базами данных

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

Развернуть кластер БД стандартной конфигурации можно довольно быстро. Но на то чтобы настроить мониторинг, регулярное резервное копирование и отказоустойчивость, у отдельного инженера или разработчика может уйти от нескольких дней до нескольких недель — в зависимости от уровня компетенций. И всё равно останется необходимость поддерживать систему и вручную устанавливать обновления. По сути, нужно писать автоматизацию с нуля либо адаптировать существующие open-source или коммерческие решения — и тратить гораздо больше ресурсов.

Поэтому система управления базами данных в облаке может стать простой и доступной альтернативой. Она позволяет:

• Создавать базы данных. Провайдер создаёт сеть, выделяет виртуальные машины, устанавливает зависимости, необходимые для развёртывания баз данных, системы управления и компоненты для обеспечения мониторинга, резервного копирования и восстановления. Наконец, проверяет доступность данных и даёт инструкции для подключения.
• Управлять базами с помощью пары кликов. Если клиент хочет что-то изменить, например, планируется распродажа и нагрузка на его сервис сильно вырастет, провайдер меняет размер виртуальной машины, возможно, настройки в конфигурации баз данных, чтобы они лучше работали в новых условиях.
• Устанавливать обновления, как операционной системы так и СУБД.
• Снимать резервные копии, хранить их определённое количество времени и восстанавливать при необходимости. Важно делать бэкапы отдельно от виртуальных машин, где работают БД. Тогда потеря одного хранилища не помешает восстановить данные и продолжить работать.
• Не тратить время и силы на поддержку. Например, мы постоянно снимаем метрики с системы мониторинга и замечаем алерты раньше пользователя. Поэтому если что-то упадёт, быстро об этом узнаем, всё починим — и постараемся сделать так, чтобы клиент ничего не заметил.
• Не думать о безопасности данных. Провайдер ограничивает порты, по которым можно подключиться к базе данных, и регулярно сканирует пользовательские кластеры на уязвимости. В нашем облаке также есть файрвол, где можно ограничить адреса, подключающиеся к базам данных. И возможность создать кластер без публичного IP-адреса — благодаря чему базы из внешней сети недоступны.

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

Кому не подходит такое решение

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

Если приходит клиент и говорит: «Мне нужен кластер баз данных — но обязательно с установите ПО из этого списка, и шифрование только на конкретных дисках», DBaaS не для него. Тут понадобятся professional services, которые работают с нетиповыми конфигурациями.

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

Сервис управления кластерами для удобной работы с Kubernetes

Чтобы использовать микросервисную архитектуру, применяются контейнеры, в которые «упакованы» приложения и все их зависимости. Благодаря этому мы можем запускать приложения на одной виртуальной машине, экономить место и не разбираться с «конфликтами» между разными сервисами.

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

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

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

• Обеспечивает бесперебойную работу Control Plane. Если что-то пойдёт не так с мастер-нодами, кластер потеряет управляемость. Мы как провайдер делаем всё, чтобы этого не случилось: настраиваем компоненты, которые разворачиваются на мастер-нодах, подбираем оптимальный размер мастеров, а в ближайших планах — автоскейлинг мастер-нод. И даём пользователю SLA на то, что всё точно будет работать.
• Предлагает интеграцию с хранилищем «из коробки». Она нужна, чтобы создавать выделенные тома и хранить данные, которые важно не потерять, когда приложение «умирает», а виртуальная машина удаляется.
• Создаёт балансировщики нагрузки. Просто опишите параметры балансировщика и примените манифест, а провайдер создаст балансировщик и добавит его в кластер.
• Помогает настраивать плагины. Экосистема Кубера предлагает большое количество программ и расширений, делающих работу в K8s удобнее и эффективнее, но их ещё нужно установить. Мы автоматизируем этот процесс для пользователя.

Настройка плагинов на примере

Возьмём Nginx Ingress Controller. Это балансировщик L7-уровня, который в 99% случаев нужен, чтобы на приложение, которое развёрнуто в Kubernetes, пускать пользовательский трафик.

Пользователь при создании кластера отмечает, что ему нужен этот плагин. А мы под капотом поднимаем сетевой балансировщик, вешаем на него белый IP-адрес, поднимаем L7, устанавливаем Nginx, связываем всё это друг с другом. И гарантируем, что плагин будет работать корректно.

Compute Cloud для удобной работы с виртуалками

Compute Cloud — это простые и понятные виртуальные машины, которыми удобно управлять и легко масштабировать. Можно выбрать подходящую ОС или готовый шаблон приложения, чтобы сэкономить время на установку и конфигурацию. Чем хорош сервис:

• Низкий порог вхождения. Запустить сервис и создать виртуальную машину может любой человек, мало-мальски разбирающийся в теме. К тому же мы подготовили документацию и стараемся делать максимально простые и понятные интерфейсы.
• Масштабирование. Мы даём возможность менять размер диска и количество CPU и RAM на виртуальной машине. При работе с простым хостингом для масштабирования нагрузки пришлось бы брать новую виртуальную машину и переносить всё в неё.
• Большой выбор дисков и высокая частота процессора.
• Экосистема. Compute Cloud — часть экосистемы продуктов, интегрированная со всеми сервисами #CloudMTS. То есть сервис можно превратить в виртуальную инфраструктуру, которую можно будет масштабировать и которой можно будет управлять.

Как это выглядит на примере

Клиенту нужны Kubernetes и база данных, причём редкая, которой нет у облачного провайдера «as-a-Service». У него есть выбор:

• Развернуть базу в Kubernetes. Но Persistent Volumes, то есть хранилища данных, не всегда работают идеально. И считается не очень хорошей практикой хранить высоконагруженные базы данных в Кубере.
• Развернуть базу в Virtual Infrastructure, но это дольше и сложнее, так как решение больше подходит для больших комплексных проектов.
• Поднять одну простую виртуальную машину. Если клиент разворачивает не большую ко́мплексную инфраструктуру, а одну базу данных, это оптимальный вариант. И для таких кейсов прекрасно подходит Compute Cloud.

Другой кейс — поднять ВМ и на ней развернуть VPN-сервис. Зачастую это выгоднее, чем покупать подписку на какой-то VPN.

---