Собственная облачная платформа помогает контролировать технологические процессы, обеспечивает безопасность и повышает эффективность продуктовых команд. Но спроектировать её — задача со звёздочкой.
Привет, Хабр! Меня зовут Алексей Чуркин, я работаю в компании Wildberries, где строю приватное облако. В этой статье по мотивам моего доклада для Highload++ расскажу о том, как мы внутри компании построили облачную платформу, с какими сложностями столкнулись и как собираемся её развивать.
Немного контекста: Wildberries — место, где можно заказать практически любой товар и на следующий день получить его в пункте выдачи рядом с домом. Чтобы система работала без сбоев, нужна большая и надёжная инфраструктура. В департаменте инфраструктуры Wildberries работает более 500 сотрудников. У нас тысячи геораспределённых железных серверов и несколько ЦОД — часть коммерческих и часть собственных,. А количество виртуальных серверов исчисляется десятками тысяч.
Зачем нашей компании облако?
Контролировать технологические риски. Оборот нашей компании за 2023 год составил 2,5 триллиона рублей. Если эту цифру разделить на количество минут в году, то окажется, что минута простоя нашей инфраструктуры стоит компании 5 миллионов рублей. Как департамент инфраструктуры, конечно же, мы хотим контролировать все слои, которые могут повлиять на доступность бизнеса. А ещё иметь возможность достаточно быстро реагировать на вызовы. Когда нашу компанию атаковали DDoS с суммарным объёмом трафика в 450 Гб/с, мы своими силами отбились от этой атаки.
Контролировать информационную безопасность и снижать риски. Намного проще построить одну платформу и правильно её настроить с точки зрения ИБ, чем иметь дело с множеством технологий, каждая из которых требует внимания.
Конечно, начиная разработку такого большого продукта, мы всегда считаем экономику. Перед тем, как запустить разработку облака, мы столкнулись с вызовами, которые решались при помощи микросегментации корпоративной сети. Оказалось, что разработка своего облака с приватными оверлейными сетями сопоставима по стоимости с внедрением железных файерволов на большую корпоративную сеть.
Повысить эффективность продуктовых команд. Мы хотели дать им возможность создавать виртуальные машины и кластера баз данных за минуты вместо заявок в сервис-деск, исполняемых инженерами.
Почему решили разработать собственное решение
Сначала провели конкурентный анализ существующих облачных платформ. И выделили три группы альтернатив:
Open-source-решения с открытым исходным кодом, например, OpenStack, KubeVirt.
Вендорские решения с платной поддержкой, например, VMware.
Публичные облака.
Изучив эти варианты, обнаружили два факта в пользу разработки собственного решения.
Стоимость
Для публичных облаков и вендорских решений стоимость линейно растёт с ростом инфраструктуры. Мы искали решение, при котором наша инфраструктура была бы не только надёжной, но и дешёвой. Вендорские решения используют лицензионную модель, в которой стоимость отчислений за сервис линейно растёт вместе с ростом инфраструктуры. При этом стоимость разработки облака зависит не от того, сколько виртуальных машин обслуживает ваша инсталляция, а от количества фич в облаке.
Типовой сервер окупается за 1.5 месяца по ценам публичных облаков. Мы взяли стоимость одного железного сервера в закупке и посчитали, за сколько времени он окупится, если бы мы продавали его по тарифам публичных облаков в России. Оказалось, что сервер окупается за полтора-два месяца. Понятно, что реальная экономика сложнее, этот расчёт не учитывает капитальных затрат. Но всё равно собственная инфраструктура с определённого объёма становится экономически эффективной.
Зависимость от чужих технологий
Для нас принципиально контролировать решения, влияющие на прод, и иметь возможность редактировать и адаптировать их под наши требования:
OpenStack — 8.5kk LOC
Закрытые исходники vendor solutions
Исходники OpenStack — это почти 9 миллионов строк кода. Разбираться, как он работает, знать, как редактировать, обходится дорого. Также это требует найма редких специалистов или поиска экспертизы внутри компании. По нашим расчётам, разработка собственного решения гораздо выгоднее, чем взращивание этих компетенций в OpenStack.
Преимущества собственного решения
Разработка собственного решения намного проще.
Контроль всех слоёв инфраструктуры == эффективные решения
При разработке приватного облака мы должны решать только проблемы внутри компании. И не должны делать решения, которые подойдут для условных Пети или Васи с рынка.
Обычно к продуктовому приложению в нашей компании выставляются требования к архитектуре, чтобы падение одного дата-центра в «чёрную пятницу» не повлияло на продажи. Если приложения наших пользователей удовлетворяют этому требованию, значит, они уже умеют деплоиться в несколько дата-центров, а их базы данных успешно реплицируются между ЦОДами. Следовательно, у нас внутри нет проблем, которые можно было бы решить при помощи сетевых дисков. Поэтому можно не влезать в дорогостоящую разработку собственного SDS или не менее дорогостоящее построение отказоустойчивых кластеров ceph, из-за которых увеличится стоимость корпоративной сети.
Понятные варианты отказа. Требование бизнеса с точки зрения обеспечения доступности звучало так: гарантировать работу двух виртуальных машин из трёх, запущенных в разных зонах доступности.
Два вывода из этого требования:
Закладываем возможность отказа одного сервера. Мы можем не бороться до последней капли крови за доступность конкретной виртуалки, что недопустимо для публичных облаков.
Минимизируем влияния отказа сервера на другие. Мы должны обеспечить такое внутреннее решение, чтобы падение любого сервера приводило максимум к отказу виртуальных машин, запущенных на этом сервере.
Гибкость с точки зрения изменений. Мы адаптируемся под компанию, а не диктуем ей, как надо развивать инфраструктуру.
Больше пространство для манёвра при найме. Можем набирать команду из хороших людей, а не из тех, кто знает определённые технологии. Для меня важно, чтобы при разработке собственного решения нам не нужно было искать редкие и дорогие компетенции на рынке. Мы можем позволить себе нанимать людей, которые знают предметную область и которым интересно работать над таким проектом.
Живые миграции VM без сетевых дисков
Живые миграции — необходимый инструмент для обслуживания облака.
Локальные диски не являются препятствием для миграции.
Диск размером 1 ТБ можно перенести за 5 минут по сети 25 Гбит/с.
Предпочтительнее использовать много маленьких VM, чем одну большую.
В любом облаке есть краеугольный камень — живые миграции виртуальных машин. Это технология, позволяющая переносить виртуальные машины между железными серверами, и именно она обеспечивает поддерживаемость вашего облака. Помните, несколько лет назад из-за Meltdown и Spectre всем облакам пришлось обновлять ОС на гипервизорах и при этом делать всё с перезапуском железного сервера. Именно в этих случаях все провайдеры виртуализации были вынуждены организовать живые миграции всех виртуальных машин, которые они обслуживают.
Если у вас в инфраструктуре есть сетевые диски, то живые миграции происходят так:
Система переносит оперативную память виртуальной машины с одного сервера на другой.
Система переподключает сетевые диски с одного физического сервера к другому.
В случае использования локальных дисков, живые миграции работают ничуть не хуже, просто к этому этапу добавляется ещё один процесс по переносу данных локальных дисков. Этот процесс просто замедляется. Например, у нас на сети 25 Гбит/с — миграция диска в 1 ТБ происходит за пять минут. Локальные диски — не препятствие, но требуют немного модифицировать процесс.
Интересно, что на сходимость миграции влияет то, сколько данных пишется в оперативную память. Если в виртуальной машине изменений происходит больше, чем сетевой интерфейс может пропустить, то ваша миграция никогда не сойдётся — выполнится либо с паузой, либо с замедлением.
Мой совет всем пользователям виртуалок в любых облаках — если у вас есть выбор создать одну большую виртуальную машину либо несколько маленьких, то всегда выбирайте второй путь. В этом случае живые миграции, скорее всего, никогда не замедлят и не остановят вашу виртуальную машину.
Оптимизации по сравнению с OpenStack
Ещё один плюс разработки собственного облака — возможность учесть опыт индустрии и модифицировать решения.
Например, в OpenStack есть отдельный тип нод — Network Node. Это сервера, через которые проходит трафик из виртуальных сетей в Интернет или вашу корпоративную сеть. Именно там происходит NAT, работают другие сетевые службы вроде DHCP-агента.
Мы не сразу поняли, зачем это выносить в отдельную сущность в нашем решении. Тем более, каждый из таких серверов может влиять на несколько гипервизоров. В целом отказ Network Node может приводить к тому, что значительная часть виртуальных машин становится кратковременно недоступна. Все обязанности, которые в OpenStack приходятся на Network Node, мы выполняем на наших гипервизорах.
Также за счёт разработки собственного решения мы можем что-то оптимизировать. Например, у нас нет аналога службы DHCP-агент из OpenStack. Зато DHCP-трафик обрабатывается внутри OVN, нашей виртуальной сети по заданному правилу: для DHCP-пакета с MAC-адресом X из виртуальной сети выдать IP-адрес Z. В итоге у нас нет компонента-аналога из OpenStack, который мог бы влиять на виртуальные машины всего кластера.
Как мы спроектировали наше решение
Для каждого в команде это был первый опыт построения облака. Поэтому у нас используются те же абстракции, которые можно встретить в любом другом.
Одна из ключевых абстракций — зона доступности. В нашем случае, — дата-центр. В рамках одной зоны доступности у нас есть два типа серверов:
Data Plane — сервера, на которых запущен написанный нами агент. При помощи него создаются виртуальные машины на этом сервере. Мы их называем гипервизорами.
Control Plane — набор серверов, обеспечивающих контроль за жизненным циклом железок и виртуальных машин в зоне доступности, а также мониторинг и остальные служебные функции.
Именно на этом слое происходит основная работа с виртуальными сетями. Мы берём несколько таких зон доступности, объединяем их и строим сверху слой под названием Control Plane. Он предоставляет API и web-интерфейс пользователям.
Наш отдел пишет код трёх слоев — Config Plane, Control Plane и VM-Agent, — и занимается их эксплуатацией. Естественно, как и в случае с любым другим продуктом, мы используем внутри достаточно много open-source. За виртуализацию отвечает KVM через библиотеку libvirt, виртуализацию сети делаем при помощи OVN. В общем, используем примерно те же технологии, что можно увидеть в OpenStack. Вокруг этого есть огромное количество другого софта, начиная от популярных баз данных и заканчивая достаточно специфичными штуками вроде FRR — BGP-демона, который отвечает за анонсы IP-адресов наших виртуалок в корпоративную сеть.
Расскажу про варианты отказов, которые мы заранее заложили в систему.
Отказ гипервизора
Когда что-то случается с гипервизором, в худшем случае мы теряем все виртуальные машины, которые находятся на нём. Но с точки зрения исполнения требований от бизнеса это для нас допустимо. Гипервизор мы починим, виртуальные машины — вернём в строй. Ожидаем, что инфраструктура наших пользователей отлично переживёт такие инциденты.
Отказ Control Plane
Может упасть приложение или контроллер SDN. В этом случае пользователи теряют возможность редактировать или создавать виртуальные машины. Но при этом уже созданные продолжают работать за счёт того, что вся необходимая VM информация находится на гипервизоре, в том числе, необходимые данные от SDN. Благодаря этому виртуальные машины не ощущают падения Control Plane.
Важный продуктовый момент — пользователи в облаке достаточно редко что-то модифицируют или создают новое. Обычно, они создают виртуалку или кластер базы данных единожды и используют годами, изредка редактируя. Поэтому варианты падения, когда мы не можем дать пользователям что-то отредактировать либо создать новое, вполне допустимы.
Отказ Config Plane
При отказе Config Plane происходит примерно то же самое, что при отказе Control Plane. Только в придачу нельзя создавать виртуальные машины во всём облаке, а не только в конкретной зоне доступности. Это тоже вполне допустимо и решаемо.
Разработка и эксплуатация облака
Когда мы начинали этот проект, я думал, что облако — это чрезвычайно сложно. Знал только несколько компаний в России, которые делали облако похожим образом. На рынке было много популярных public cloud-платформ с OpenStack или VMware под капотом.
Вот какие выводы я сделал:
Облако — это выполнимый проект. Прототип мы сделали командой из менее десяти человек. А сейчас у нас в отделе чуть больше 50 сотрудников обеспечивают полный цикл разработки, обслуживания и эксплуатации облака.
Облако — это инфраструктурный продукт. С точки зрения программирования, приватное облако — такой же инфраструктурный проект, как и многие другие. Надо приучиться в три раза чаще, чем в продуктовых проектах, спрашивать себя о последствиях отказа какой-то службы или сервера.
Необходимость CI/CD. Отдельно упомяну, что при разработке любого решения, хоть инфраструктурного, хоть нет, хочется в процессе внутри отдела иметь механизмы, позволяющие командам разработки не бояться вносить изменения. А командам эксплуатации — не бояться деплоить что-то на прод. Облако достаточно специфичный продукт для этого. Его невозможно поднять на рабочем ноутбуке или компьютере, и дефолтные GitLab’овские пайплайны в Docker тоже никак не помогут.
У нас есть отдельная мини-команда, которая отстраивает собственный CI/CD, в рамках которого мы создаём мини-облака под каждую фича-ветку. На этом CI/CD мы прогоняем большое количество тестов, проверяющих всё — от цвета кнопок до корректности бэкапа VM.
Сага об open-source
Как и в любом продукте, мы используем множество различных библиотек:
Виртуализация: KVM с libvirt.
Сетевая виртуализация: OVN.
Базы данных: PostgreSQL, Clickhouse.
Мониторинг: Prometheus, Loki, Grafana.
Minio, FRR, Nftables, Vault, ...
Но не все библиотеки одинаково полезны. Расскажу подробней про OVN, которую используем для построения оверлейных виртуальных сетей. В сердце OVN — компонент OVSDB — это база данных на C, которая хранит информацию о топологии виртуальных сетей.
Обычно, когда слышат фразу: «база данных на C», думают, что она способна обрабатывать тысячи запросов в секунду с миллисекундными задержками, как, например, RocksDB или Redis. Оказывается, на C бывают БД, которые возвращают ответ на запрос данных из таблицы размером в несколько сот мегабайт 30−40 секунд. При этом за время выполнения этого запроса сбросятся все сетевые подключения к ней, потому что БД — однопоточная и, пока выполняет запрос, не может делать любую другую работу. А потом окажется, что интервал keep alive зашит в исходном коде OVSDB, и вы никак не можете его отредактировать.
Поэтому важно помнить, что open-source — не только о том, чтобы брать бесплатно, но и о том, чтобы возвращать. Мы попытаемся вместить в OVSDB патч, который решит часть проблем с производительностью. А ещё нужно не забывать применять инженерную смекалку. Мы пытаемся идти двумя путями и оптимизировать схему SDN, чтобы количество данных в базе данных было как можно меньше. Есть даже пиратские разработки. Пробуем написать реализацию протокола OVSDB, но с другим бэкендом.
Реальный мир не идеален: новые проблемы
Чтобы наши пользователи верили, что виртуальные машины легко создаются по щелчку мышки и вызову API, кто-то вместо них должен столкнуться с неидеальностью и проблемами этого мира.
Железо ненадёжно
Может произойти множество вещей, которые сделают сервер нерабочим: например, выбить плашку оперативной памяти в сервере. Если на этой плашке хранились данные ядра, сервер зависнет.
Мы проектируем облако с учетом того что сервер может сломаться. Например, отказывают жёсткие диски. Мы закупили большую партию дисков одного вендора и начали строить на них хранилки. Оказалось, что диски из одной партии могут выходить из строя чуть ли не одновременно, а RAID массивы — плохо спасают.
Ещё у нас была история с серверами одного производителя, на которых процессоры не могли работать на частоте больше, чем 1 ГГц. Все наши попытки как-то повлиять на это не привели ни к чему. Позже инженеры в ЦОДе сказали, что проблемы были на материнской плате серверов. Зона VRM не могла обеспечить процессоры нужным количеством энергии. Сами понимаете, что ни одна материнская плата не напишет вам сообщение в лог ядра о том, что у неё взбухли конденсаторы.
Второй нюанс — на большой инфраструктуре мы хотим работать с железом так же, как даём работать пользователям с виртуалками, то есть, вводить его в строй за минуты. Когда в инфраструктуре тысячи серверов, причём от разных вендоров, сделать это непросто. Для этого нужны специальные отделы в компании.
Люди ненадёжны
Все мы — живые люди, у каждого бывает плохое настроение или личные проблемы. Всё, о чём вы могли читать в анекдотах на bash.org, действительно происходит в дата-центрах: могут случайно нажать кнопку выключения сервера, перепутать сервер с другим, задеть кабель питания в стойке, даже может вылететь в зеркальном рейде один диск, а техник в ЦОДе перепутает и поменяет на новый чистый диск тот, на котором у вас осталась единственная копия данных. С этими проблемами ничего поделать нельзя, можно снизить их вероятность, но не исключить полностью. Надо принять меры и строить такую архитектуру, чтобы человеческая ошибка не привела к тому, что вся система или всё облако утратят работоспособность.
Поставщики тоже ненадёжны
Чтобы наши пользователи могли быстро создавать десятки и сотни виртуальных машин, мы должны обеспечить достаточно свободных мощностей, на которые это всё можно задеплоить в наших кластерах. Эти процессы называются Capacity Planning и Capacity Management. В последние годы в нашей стране их решают весьма экзотично.
Много вендоров ушло с рынка. А те, что остались, не всегда могут выдерживать сроки поставок. Всё чаще происходит ситуация, когда покупаешь железо, которое могут продать, а не то, к которому привык. Иногда в дата-центре мы ощущаем себя, как на дороге в большом городе — вокруг куча китайских марок, а мы даже не можем произнести их названия.
Но вся эта ненадёжность — не повод опускать руки
Сейчас в компании развёрнуто две инсталляции нашего облака. Мы суммарно обслуживаем более 20 тысяч виртуальных машин. Кажется, справились достаточно неплохо с реализацией базового слоя — это виртуальные машины и виртуальные сети. Перешли к более «богатым вещам» — «что-то как сервис» (*aaS). Уже запустили PostgreSQL как сервис и позволяем продуктовым командам внутри Wildberries создавать отказоустойчивые кластеры PostgreSQL, растянутые сразу на несколько ЦОДов.
В планах у нас расширение портфеля *aaS. За три года эксплуатации мы успешно пережили большое количество отказов, как мелких проблем с жёсткими дисками, так и больших, включая уход со связи целого ЦОД.
За последние несколько лет мы доказали себе, что разработка собственных решений — хороший способ контролировать технологические риски. Уход различных вендоров и поставщиков услуг с нашего рынка никак не повлиял на нашу компанию. Мы скорее выступали в роли зрителей с попкорном — радовались, что заранее выбрали такую стратегию.