От виртуалки на ноутбуке к облакам / Георгий Меликов

Продолжается обсуждение темы виртуализации и контейнеров, целью которого является переход от использования виртуальной машины на локальном ноутбуке непосредственно к облачным решениям. Спикер имеет многолетний опыт работы в облачной сфере и в настоящее время занимается развитием собственного стартапа, фокусирующегося на инфраструктурных решениях, включая программируемые хранилища и сети, с акцентом на разработку в среде открытого исходного кода (open source).

Большинство стартапов, включая упомянутый проект, начинаются с разработки на личном оборудовании, например, на ноутбуке. Однако для достижения масштабов крупного конгломерата такое решение становится недостаточным. Отличительной особенностью деятельности стартапа является реализация всех решений в формате open source, что обеспечивает прозрачность и возможность использования сообществом.

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

Для обхода ограничений одного потока длительные операции выносятся в отдельные фоновые потоки, такие как генерация кэша или выполнение джабов воркерами. При получении запроса к API система быстро отдает готовый результат или предлагает клиенту прийти позже. Тем не менее, физические и экономические факторы накладывают жесткие ограничения на размер любого отдельного сервера.

Как бы вы его ни растили, и физика, и экономика она всё-таки даёт нам по рукам, что он конечен.

Облако представляет собой набор физических серверов. Среднестатистический сервер в облаке может иметь до 200 ядер (до 400 потоков), особенно при использовании современных процессоров AMD EPYC, которые могут поддерживать несколько сокетов. Оперативная память может достигать 6 ТБ на процессор, а количество локальных дисков (NVME или HDD) ограничено примерно тридцатью, хотя физически можно подключить больше дисковых полок.

Даже если растянуть виртуальную машину на один гипервизор, используя все его ресурсы (до 300 ядер и 12 ТБ ОЗУ), сохраняется проблема конечных ресурсов (сети, диски) и отсутствие отказоустойчивости. Отказ одного сервера приводит к простою. Более того, крупные провайдеры регулярно сталкиваются с авариями на уровне целых дата-центров, что является нормой, к которой необходимо готовиться.

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

Существует несколько типов дисков. Локальные диски обеспечивают высокую скорость, но при отказе сервера данные теряются. Сетевые хранилища делятся на нереплицируемые (доступные по сети, но также с единой точкой отказа) и реплицируемые (имеющие копии данных для повышения надежности).

Целевое хранилище может быть построено на основе HTTP-протокола, фокусируясь на создании, удалении и получении файлов. Это приводит к созданию абстракции, где метаданные хранятся в кластеризованной базе данных, а сами данные — на дисках. Такая модель, известная как Simple Storage Service (S3), является объектным, а не файловым хранилищем, и, что критично, она распределена.

Критически важным параметром является задержка (latency). Пирамида задержек показывает, что доступ к L1 кэшу занимает около полунаносекунды (2 млрд операций в секунду). Попадание в L2 кэш или блокировки увеличивают задержку в десятки раз. Оперативная память в 200 раз медленнее L1 кэша. Самое медленное — это сетевое взаимодействие: по одному проводку между серверами задержка составляет 10 000 наносекунд, что в 20 000 раз медленнее L1 кэша.

Сетевые задержки сильно влияют на разработку: поштучная обработка данных из сетевой базы данных приводит к многократному начислению задержки. Основная оптимизация заключается в пакетной обработке данных. Многие библиотеки, например, `pyco pg2` на Python, уже реализуют эту оптимизацию под капотом, выбирая тысячи записей сразу, а не по одной.

Хранилища делятся на классы по степени «горячести». Самые быстрые — это in-memory данные. Более теплые — базы данных с персистентностью на диске. S3, будучи распределенным, является самым холодным и медленным, иногда его скорость сравнима со скоростью работы жестких дисков, что ограничивает его до 500 операций в секунду.

К сожалению, S3 из-за того, что он должен быть распределённый, разнесённый, будет сильно медленнее и иногда будет аналогичен жёстким диском.

На практике нагрузка и базы данных разделяются. Базы данных собираются в кластеры для отказоустойчивости. Выделение ВМ отдельно позволяет мыслить о базе данных как о сервисе (DBaaS или PaaS). Управление базами данных как услугой снимает с разработчика необходимость решать проблемы обновления и обслуживания, позволяя использовать те же данные для новых бизнес-сервисов.

После решения вопросов хранения необходимо обеспечить связанность для клиентов. Наивный подход с выдачей публичных IP всем ВМ нежелателен, так как это открывает доступ к приватным компонентам, например, базам данных. В результате появляется концепция приватной сети с приватными адресами (10.0.0.x) для каждой ВМ.

Ключевым понятием становится мультиарендность — одновременное сосуществование множества клиентов, которые не должны видеть друг друга. Этим управляет оркестратор SDN (Software Defined Network). Он предоставляет базовые строительные блоки, такие как коммутаторы (свитчи), DHCP-серверы, базовые файрволы для ограничения портов и DNS-серверы (публичные и приватные).

При масштабировании на несколько дата-центров (ЦОД) возникает проблема консистентности данных: в случае отказа одного ЦОД необходимо точно знать, какая информация была актуальной. При наличии одной или двух нод отказ приводит к невозможности работы или ситуации «разделенного мозга» (split brain), когда ноды не могут договориться о состоянии.

Самый надежный вариант — это три и более ноды. Мастер-нода не должна отвечать клиенту, пока не реплицирует запрос хотя бы на одну ноду. В идеале для большинства систем требуется кворум, то есть не менее 2/3 от общего числа нод, чтобы принять решение о консистентности. Отказавший элемент, вернувшись, легко догоняет актуальное состояние.

Сложность развертывания тысяч виртуальных машин, дисков, балансировщиков и платформенных сервисов (S3, БД) требует автоматизации. Ручное управление тысячами компонентов невозможно. Возникает необходимость в подходе, который абстрагирует разработчика от конкретных деталей инсталляции.

Существуют две парадигмы управления: «питомцы» (Pets) и «скот» (Cattle). «Питомец» — это конкретный сервер, который знают поименно, лелеют и чинят вручную при аварии (например, чистят логи). «Скот» — это безымянные сущности с UUID, управляемые автоматизированно. В случае отказа «скота» система должна автоматически заменять неисправный элемент.

В случае аварии вы должны достичь ситуации, что и аварии переживаются автоматически, что не вы руками идете, что-то опять чините.

Управление через API является ключевым для автоматизации. Инструменты типа Ansible или Puppet работают императивно, описывая желаемое состояние через инвентарь, который часто статичен. Terraform и аналоги позволяют декларативно задать требования, но они хранят инвентарь централизованно, что создает новую точку отказа. Главный недостаток этих инструментов — отсутствие свойства самолечения (self-healing) и привязка к конкретной инсталляции.

В идеале развертывание должно быть как сервис. Разработчик должен декларативно указывать, какие сервисы ему нужны (например, одна база данных), не заботясь о версии, IP-адресах или паролях. Это должно покрывать полный жизненный цикл: развертывание, обновление и переезд. Также критически важна полная обсервабилити (мониторинг) из коробки, не привязанная к конкретному облаку.

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