Разработчики сегодня создают новые классы приложений. Эти приложения разрабатываются уже не под отдельный сервер, а запускаются с нескольких серверов в дата-центре. Примеры включают фреймворки, реализующие аналитические вычисления, такие как Apache Hadoop и Apache Spark, брокеров сообщений, вроде Apache Kafka, key-value хранилища, например Apache Cassandra, а также приложения, с которыми работают непосредственно конечные пользователи, вроде тех, которые используются компаниями Twitter и Netflix.
Эти новые приложения – больше, чем просто приложения, это – распределенные системы. Точно так же, как когда-то для разработчиков стало привычным создавать многопоточные приложения для отдельных машин, становится общепринятым проектировать распределенные системы для дата-центров.
Но разработчикам довольно сложно создавать такие системы, а администраторам тяжело их поддерживать. Почему? Потому что мы используем неверный уровень абстракции, как в отношении разработчиков, так и в отношении администраторов – уровень машин.
Машины – неподходящий уровень абстракции
Машины не подходят в качестве уровня абстракции для создания распределенных приложений и работы с ними. Использование подобной абстракции разработчиками усложняет процесс создания ПО без явной на то необходимости, привязывая разработчиков к характеристикам конкретных компьютеров, таким как IP-адреса и объем памяти локальной машины. Это затрудняет, а порой и не позволяет провести миграцию и изменение размеров приложений, приводя к тому, что поддержка работы дата-центра становится трудоемкой и болезненной процедурой.
Машины, взятые как уровень абстракции, вынуждают администраторов развертывать приложения с расчетом на возможность выхода отдельных единиц оборудования из строя, что приводит к использованию самого простого и наиболее консервативного подхода, заключающегося в установке одного приложения на одну машину. Это почти всегда означает, что оборудование не используется на полную мощность, поскольку в большинстве случаев мы не покупаем машины (как физические, так и виртуальные) специально под какие-либо приложения и не выверяем размер приложений под возможности той или иной машины.
Запуская только одно приложение на одной машине, мы приходим к тому, что наш дата-центр становится крайне статичной, негибкой конструкцией из групп машин. В итоге на одной группе машин запускаются приложения, обрабатывающие аналитику, на другой идет работа с базами данных, третья поддерживает работу веб-серверов, еще одна работает с очередями сообщений и так далее. И число таких групп только возрастает в процессе замены компаниями монолитной архитектуры архитектурой сервис-ориентированной и микросервисной.
Что происходит, когда машина в одной из этих статичных групп выходит из строя? Остается надеяться, что мы можем ее эффективно заменить новой (а это трата денег) или можем выделить под эти задачи какую-то из имеющихся машин (а это трата времени и усилий). А что делать, если в рамках дня веб-траффик снижается до минимального уровня? Мы готовим статичные группы под пиковые нагрузки, а это означает, что когда траффик снижается до минимального уровня, дополнительные мощности расходуются зря. Вот почему стандартный дата-центр загружен обычно на 8–15% своей мощности.
И наконец, используя машины, как абстракцию, организации вынуждены нанимать огромный штат людей, которые будут вручную настраивать и ремонтировать каждое индивидуальное приложение на каждой отдельной машине. Люди – «узкое место» подобной системы, запускать новые приложения из-за человеческого фактора не удается, даже если компания уже закупила достаточно ресурсов, которые в настоящий момент не используются.
Если бы мой ноутбук был дата-центром
Представьте, что было бы, если бы мы запускали приложения на ноутбуках так же, как мы делаем это в дата-центрах. Каждый раз, когда мы запускали бы веб-браузер или текстовый редактор, нам приходилось бы уточнять, с помощью каких аппаратных мощностей необходимо обработать данный процесс. Хорошо, что наши ноутбуки обладают операционными системами, благодаря которым мы можем абстрагироваться от сложностей управления ресурсами нашего ПК вручную.
В сущности, у нас есть операционные системы для наших рабочих станций, серверов, мейнфреймов, суперкомпьютеров и мобильных устройств, каждая из которых оптимизирована под уникальные характеристики этих устройств и форм-факторов.
Мы уже начали воспринимать дата-центр сам по себе как один гигантский компьютер размером с огромное хранилище данных. Но у нас все еще нет операционных систем, которые могли бы оперировать таким уровнем абстракции и управляли бы аппаратным обеспечением в дата-центре так же, как ОС делает это на наших компьютерах.
Пришло время создать ОС для дата-центров
На что могла бы походить ОС для управления дата-центром?
С точки зрения администратора, она бы работала со всеми машинами из дата-центра (или облака) и агрегировала их в один гигантский пул ресурсов, в рамках которого могли бы запускаться приложения. Вам больше не пришлось бы заниматься конфигурированием отдельных машин под отдельные приложения, все приложения могли бы запускаться на любом из доступных ресурсов, на любой машине, даже если бы с нее уже были запущены другие приложения.
С точки зрения разработчика операционная система дата-центра должна была бы действовать, как посредник между приложениями и машинами, обеспечивая реализацию общих примитивов и упрощая разработку распределенных приложений.
Операционная система дата-центра не должна была бы заменить Linux или любую другую ОС, которые мы используем в дата-центрах сегодня. ОС для дата-центра должна была бы представлять собой стек ПО, установленный поверх основной операционной системы. Продолжать использовать основную ОС для обеспечения выполнения стандартных операций было бы критически важным для оперативной поддержки существующих приложений.
ОС дата-центра должна была бы обеспечивать функциональность подобную задачам ОС отдельной машины, а именно: управление ресурсами и изоляцию процессов. Точно так же, как и традиционная ОС, операционная система дата-центра должна была бы обеспечить возможность многим пользователям одновременно запускать множество приложений (поддерживать многопоточность) в условиях наличия общей группы ресурсов и явной изоляции запускаемых приложений друг от друга.
API для дата-центра
Возможно, определяющей характеристикой ОС для дата-центра было бы то, что она обеспечивала бы интерфейс для разработки распределенных приложений. По аналогии с системным вызовом для традиционных ОС, API операционной системы дата-центра мог бы позволить распределенным приложениям резервировать и высвобождать ресурсы, запускать, отслеживать и завершать процессы и многое другое. API обеспечивал бы реализацию примитивов, обладающих общей функциональностью, необходимой всем распределенным системам. А разработчикам, таким образом, не нужно было бы независимо друг от друга раз за разом вводить в использование фундаментальные примитивы распределенных систем (и неизбежно страдать от одних и тех же багов и проблем производительности).
Централизация общей функциональности в рамках API-примитивов позволила бы разработчикам создавать новые распределенные приложения проще, безопаснее и быстрее. Это напоминает ситуацию, когда к стандартным ОС была добавлена виртуальная память. По сути, один из пионеров в направлении развития виртуальной памяти писал, что «Разработчикам операционных систем в начале 1960-х было предельно ясно, что автоматическое выделение памяти может значительно упростить процесс программирования».
Примеры примитивов
Два примитива, характерные для ОС дата-центров, которые могли бы сразу же упростить создание распределенных приложений – это обнаружение и координация сервисов. В отличие от ОС на отдельном устройстве, где обнаружение требуется очень немногим приложениям, запускающимся в рамках одной и той же системы, для распределенных приложений функция обнаружения вполне естественна. Более того, доступность и отказоустойчивость большинства распределенных приложений достигается через эффективное и адекватное обеспечение координации и/или консенсуса, достичь которых крайне тяжело.
Благодаря ОС дата-центра, интерфейс ПО мог бы заменить человека. Сегодня разработчики вынуждены выбирать между существующими средствами обнаружения сервисов и их координации, такими как Apache ZooKeeper и etcd для CoreOS. Это принуждает организации к развертыванию множества инструментов для различных приложений, что существенно увеличивает операционную сложность и потребность в дальнейшей поддержке.
Если примитивы по обнаружению и координации будут обеспечиваться за счет ОС дата-центра, это не только упростит разработку, но и обеспечит «портативность» приложений. Организации смогут изменять лежащую в основе всей системы реализацию, без необходимости внесения изменений в приложения – примерно так же, как вы сейчас выбираете реализацию файловой системы на локальной ОС.
Новый способ развертывания приложений
ОС дата-центров позволит интерфейсам ПО заменить людей, с которыми разработчики обычно взаимодействуют сейчас, пытаясь обеспечить развертывание своих приложений. Вместо того, чтобы просить кого-то выделить машины и обеспечить их настройку для запуска приложений, разработчик сможет запустить свои приложения, используя ОС дата-центра (с помощью CLI или GUI), и приложение будет исполняться с использованием API ОС дата-центра.
Этот подход обеспечит явное разграничение интересов администраторов и пользователей: администраторы будут определять количество ресурсов, выделяемое под каждого пользователя, а пользователи будут запускать любые приложения, которые захотят, используя любые доступные ресурсы. Поскольку администратор будет определять, какой тип ресурса (но не сам ресурс) доступен и в каком количестве, ОС дата-центра и запускаемые распределенные приложения будут знать больше о ресурсах, которые можно использовать, чтобы работать более эффективно и быть более отказоустойчивыми. Поскольку большинство распределенных приложений имеют повышенные требования к планированию процессов (например, Apache Hadoop) и специфические потребности в отношении восстановления (что характерно для БД), предоставление ПО возможности принимать решения вместо людей будет критически важным для обеспечения эффективности работы на уровне дата-центра.
Облако – это не ОС
Но зачем нам новая ОС? Не являются ли IaaS (подход «инфраструктура как услуга») и PaaS (подход «платформа как услуга») решениями этих проблем?
IaaS не решает наших проблем, поскольку такой подход все еще фокусируется на машинах. В рамках этого подхода приложения не обращаются к интерфейсу ПО для последующего исполнения. IaaS ориентируется на людей, обеспечивающих систему виртуальными машинами, которые другие люди в свою очередь будут использовать для развертывания приложений. IaaS превращает машины в более виртуальные сущности, но не содержит каких-либо примитивов, которые могли бы упростить разработчику процесс создания распределенных приложений, работающих с ресурсами сразу нескольких виртуальных машин.
PaaS, с другой стороны, абстрагируется от машин, но создается в первую очередь для взаимодействия с человеком. Множество PaaS-решений включают в себя различные сторонние (по отношению к непосредственным задачам платформы) сервисы и интеграционные механизмы, которые упрощают создание распределенных приложений, однако подобные механизмы нельзя использовать в рамках сразу нескольких PaaS-решений.
Распределенные вычисления стали уже правилом, а не исключением, и теперь нам нужны ОС для дата-центров, которые обеспечили бы необходимый уровень абстракции и портативные API для распределенных приложений. Их отсутствие препятствует развитию нашей отрасли. Разработчики должны иметь возможность создавать распределенные приложения без необходимости в многократной повторной реализации основной функциональности. Распределенные приложения, созданные в рамках одной организации, должны легко запускаться и в других компаниях.
Автор: 1cloud
