Мало кто знает, что первое облако Selectel было самописным решением на Haskell… с IPv6-адресацией, тарификацией по использованному процессорному времени, современной веб-консолью и быстрыми графиками потребленных ресурсов на базе продвинутой in-memory базы данных YawnDB.

С тех пор многое изменилось: облачная платформа сменила стек, обросла функциональностью, разрослась до 8 регионов, два из которых — «Узбекистан» и «Амстердам» — доступны за рубежом.

Под катом директор по развитию ядра облачной платформы Иван Романько рассказывает, с каких клиентов начиналось облако Selectel, что не так с Haskell и почему PaaS-сервисы компании уходят «корнями» в балансировщики нагрузки.

Кому нужно было облако 10 лет назад

2014 год. На рынке «железных» серверов Selectel был уже 6 лет, но IaaS этим не ограничивался. Тогда уже были зарубежные провайдеры, которых сейчас мы называем глобальными облаками, но в России рынок только зарождался. Спрос был не столько на виртуальные мощности, сколько на ценности, которые давали облачные ресурсы, — скорость, масштабирование, отсутствие необходимости «копаться» в море мелких деталей при построении частного облака на дедиках.

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

На старте облачного Selectel к нам пришли, например, Учи.ру и CarPrice. Тогда их сервисы были далеки от того, что есть сейчас, но у них было общее: они быстро росли, требовали большей инфраструктуры, не хотели инвестировать в собственные серверы и больше думали о бизнес-логике, чем сисадминстве.

Виртуальных серверов тогда не было? Да нет, были. Но мы тогда заметили, что практически никто на российском рынке не предлагает решений, отвечающих требованиям корпоративных клиентов. Можно было запускать приложения и развертывать сайты в VDS — тут предложение подходит частным лицам и небольшим компаниям. А вот более сложные инсталляции в облаке не поддерживались: API не было, интеграция виртуальных серверов с другими приложениями осложнена, загрузка собственных образов — тот еще квест. То есть инфраструктура как будто бы была, а инфраструктуры как сервис не было.

Сначала было VPC

Появление облака в Selectel и его дальнейшее развитие — это вообще история отклика на потребности клиентов компании и рынка. Так было с самого начала — с появления виртуального приватного облака.

Выбранное название — «виртуальное приватное облако» (VPC) — сейчас, да и тогда, вызывало вопросы. Virtual Private Cloud задумывалось в противопоставление дорогим приватным облакам, а перевод был дословным: виртуальное приватное облако. Полноценно частным при этом оно, естественно, не было. Так, VPC нельзя было сравнить с приватным облаком, которое мог развернуть клиент на собственных серверах. «Соседи» на хостах были, но задача компании была как раз в том, чтобы максимально изолировать клиентов друг от друга.

Чего хотели клиенты?

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

Что предлагало облако Selectel?

Возможность строить более сложную архитектуру

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

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

Pay-as-you-go

Плюс ко всему еще на старте облачной платформы Selectel реализовал модель pay-as-you-go — для компаний это была возможность платить только за потребленные ресурсы и более гибко использовать мощности. Утром создать машину, вечером удалить, через неделю снова запустить, а платить только за время работы. В то время подобные опции если и были, то только у единиц на рынке.

Кастомные конфигурации серверов

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

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

На данный момент в Selectel можно собрать кастомный облачный сервер или выбрать из десятка фиксов, в том числе серверы с GPU.

Панель управления 2014 года.

Облако времен динозавров

Мало кто знает, что облачная платформа Selectel — это вторая попытка Selectel создать собственное облако. В то время (примерно 2013 год) у компании были три продукта про виртуализацию: Linux VDS и Windows VDS – виртуальные машины, где мы руками устанавливали нужную ОС и отдавали клиенту, а также самописное облако.

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

«Старое» облако разрабатывала небольшая команда из 5-7 инженеров — писали на Haskell с нуля. Использовали модную в то время систему управления виртуализацией XEN — конкурент KVM, которую мы используем в облаке сейчас. Почему начали разрабатывать свое? На тот момент ничего готового не было.

В итоге технологический стек подвел. XEN предоставлял хорошую производительность, но постепенно утрачивал поддержку в комьюнити. Разработка на Haskell выходила дорогой: разработчики редкие, пишут не очень быстро, а писать приходилось очень много. Для создания фичи «сетевые диски» приобрели дорогое вендорское «железо» — потратили много времени, чтобы построиться на нем. Все впустую: облако ломалось под нагрузкой, а сетевые SATA-диски тормозили.

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

Новые регионы для отказоустойчивой инфраструктуры

Чего хотели клиенты?

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

Что предлагало облако Selectel?

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

Во многом разделение на регионы началось, когда Selectel запланировал открытие первого дата-центра в Москве — «Берзарина». До этого распределение на географическом уровне реализовать было невозможно: был один дата-центр в Санкт-Петербурге — «Цветочная-1», который полностью занимали серверы известной социальной сети, и три машинных зала в «Дубровке» (Ленинградская область), два из которых тоже были забиты клиентами.

При появлении площадки в Москве мы могли пойти двумя путями: сделать отдельное облако или сделать новый регион того же облака. В последнем случае можно было бы работать с инфраструктурой в разных регионах от одного пользователя/аккаунта. Именно по этому пути пошла облачная платформа Selectel.

Почти полгода разработки

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

Тогда на программную реализацию аренды серверов в разных регионах ушло примерно полгода. Но у нас появились первые регионы — то, что долгое время называлось ru-1 и ru-2. Клиенты могли запускать виртуальные машины в «Дубровке» и на «Берзарина».

Запуск региона — это командная работа. Одни разработчики облака не справятся. Нужно, чтобы подключились системные инженеры, специалисты по закупкам, сотрудники инженерно-технического отдела, которые монтируют стойки. Чтобы регионы «заиграли», чтобы клиенты могли строить на них них что-то более сложное, требовалась экспертиза по сложным сетям. В дальнейшем это выросло в такую автоматизацию по связности сложносочиненной, гибридной инфраструктуры, как услуга L3 VPN. Там много интересного, поэтому про нее напишем отдельно — подписывайтесь, чтобы не пропустить апдейты.


Сейчас в облачной платформе 8 регионов. Два из них — «Узбекистан» и «Амстердам» — за границей. Специалисты компании уже так обкатали автоматизацию развертывания и запуска новых площадок, что вся работа в комплексе занимает меньше месяца. Если инфраструктура готова и дело остается только за OpenStack, запуск занимает несколько дней (против месяца в более «ранние» годы развития платформы).

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

Балансировщики нагрузки: начало готовых решений

Чего хотели клиенты?

Готовое решение, которое избавило бы от необходимости подбирать конфигурацию виртуального сервер под балансировщик нагрузки и настраивать его.

Что предлагало облако Selectel?

Балансировщик нагрузки в облачной платформе стал первым решением в Selectel, которое можно было бы назвать «коробочным». Клиент мог зайти в панель управления и запустить готовый к использованию отказоустойчивый балансировщик L4/7. Задать все необходимые параметры при этом можно в интерфейсе, что существенно облегчает эту стандартную задачу.

Настройка балансировщика в панели управления

Интересно, что именно балансировщики открыли для нас путь в облачные базы данных и Managed Kubernetes.

Сервисы OpenStack, которые мы использовали для облачной платформы — Nova, Neutron, Cinder, были там практически с первых релизов. В них было много легаси-кода, который было очень сложно поддерживать.

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

В итоге работать с OpenStack Octavia было одно удовольствие: понятно, что менять, чтобы ничего не сломалась, отличная поддержка со стороны комьюнити. И патчи, которыми мы кастомизировали open source-решение, ложились без проблем.

Что допиливали под себя? Например, в Octavia нельзя было сделать сетевой диск основным диском виртуальной машины. Балансировщики можно было создавать только с локальным диском, а это гораздо дольше по времени. При этом для нас было важно, чтобы балансер быстро пересоздавался в случае аварии. Нам удалось разработать патч, который позволял это сделать. Также довольно просто мы реализовали отображение статусов создания балансировщика, которое не поддерживается в OpenStack.

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

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

Вам может быть интересно:

→ Как мы создавали удаленный регион в Узбекистане
→ Кейс: развернули сотню виртуалок для проведения олимпиады
→ Бюджетные GPU в облаке