Ожидая вскоре очередной релиз ОС Windows, мы думаем об операционной системе для десктопов и мобильных устройств. Но десктопы сегодня — лишь макушка компьютерного айсберга, поскольку все больше задач, ранее выполнявшихся на ПК, теперь переносится в облако, где сосредоточены постоянно растущие ресурсы: вычислительные системы, память, системы хранения и сетевые устройства.
Два прошедших в середине марта мероприятия внесли свой вклад в формирование перспективы появления ОС облачного масштаба со всеми необходимыми для такой системы возможностями и API.
Первое мероприятие — прошедший
В основанном в 2011 г. компанией Facebook проекте Open Compute Project (OCP) по выработке оптимальной архитектуры ЦОДов сотрудничают сегодня крупнейшие производители аппаратных средств, а также открытых и проприетарных виртуальных программных сред. В этом проекте поистине восхитительным образом соединяются идеи и технологии людей и компаний, забывших о конкуренции ради решения проблем, которые волнуют всех.
Эта открытость напоминает конференции USENIX и подобные ей мероприятия в конце
Эффективная архитектура ЦОДов — это ключ к эффективному развитию облаков. Крупные аппаратные вендоры типа HP уже строят свои новые решения с использованием референсного дизайна, который вносят в проект Open Compute поставщики ПО вроде Microsoft. Эти аппаратные предложения для облачных ЦОДов строятся по несколько иным принципам, нежели для обычных ЦОДов. Например, облачный сервер HP Cloudline нельзя просто поставить в традиционную стойку как обычный сервер — хотя бы потому, что в нем нет резервных компонентов для обеспечения необходимой надежности системы.
Эксплуатируя правильный облачный ЦОД из десятков тысяч одинаковых серверов, вам придется забыть о привычных схемах резервирования блоков питания и сетевых элементов. На первый план выходят программные модули, которые исполняются на ваших серверах. Современная облачная платформа типа OpenStack или Windows Server Azure Pack сама обнаружит сбои в аппаратуре и перенесет программные модули на резервный вычислительный узел, данные на резервный узел хранения, а сетевые функции — на резервный коммутатор. Но облачные платформы — это только часть решения задачи, поскольку они сфокусированы на исполнении приложений и управлении виртуальными машинами, будучи абстрагированы от аппаратного слоя, поддерживающего их функционирование.
Здесь на первый план выходят решения вроде того, что предлагает Canonical в своем ПО управления аппаратурой по принципу «Metal-as a-Service» («оборудование как сервис», MaaS). За счет использования программных интерфейсов (API), встроенных в OPC-совместимое «железо», программное решение от Canonical получает полную картину доступности аппаратных ресурсов, на основе которых может быть развернута облачная платформа.
Например, установив инструменты MaaS для получения карты ЦОДа, состоящего из СХД на 6 Пб, 50 серверов и 5 сетевых коммутаторов, вы предоставите эту карту платформе OpenStack, и замена «сгоревшего» сервера станет тривиальной задачей. Механизмы MaaS точно укажут на отказавшую аппаратуру, а после ее замены вновь включат в карту элементов, доступных для размещения облачных задач. Подобная автоматизация работы с аппаратным обеспечением ЦОДов очень важна для получения операционной системы облачного масштаба, которая будет всё знать о своем аппаратном слое и сможет эффективно размещать приложения в доступных вычислительных, сетевых и дисковых ресурсах.
Пока у нас нет ОС облачного масштаба. Решения типа Juju от Canonical, Mesos от Apache (основы Mesosphere) и Kubernetes от Google — это хорошее начало; они предлагают ключевые элементы управления распределением приложений между виртуальными машинами и контейнерами. Но этого мало. Необходимо работать непосредственно с аппаратным уровнем, чтобы получить полностью программно-управляемый ЦОД.
Эта концепция лежала в основе второго мероприятия, прошедшего на той же неделе и организованного Juniper для прессы и аналитиков. Juniper четко объяснила, что сетевая виртуализация есть основа ее бизнес-модели. В своих новейших устройствах Juniper применяет комбинацию специализированных микросхем и стандартных контролеров на основе x86-архитектуры.
Одно из наиболее интересных ее решений — использование в маршрутизаторах так называемой 3D-памяти. Использование памяти высокой плотности на одной шине с процессором позволяет держать всю таблицу BGP-маршрутизации целиком в памяти, что делает возможным быструю перестройку маршрутов в зависимости от изменений производительности сети. Этот подход может также существенным образом расширить само понятие программно-конфигурируемой сети. Имея всю таблицу маршрутизации в памяти, можно, например, применить скоростную NoSQL базу данных для анализа производительности сети, что позволит сетевым провайдерам оптимизировать маршруты и минимизировать задержки, которые ощущают пользователи.
Похожим образом новые производительные коммутаторы обеспечивают высокие скорости сетевого обмена для облачных ЦОДов. Необходимость масштабирования публичных и частных облаков диктуется, в том числе, грядущим Интернетом вещей, и в этих условиях критичной становится сетевая производительность — от нее зависит возможность обеспечения данными облачных решений, ориентированных на большие данные.
Возможность программного управления сетевым стеком сейчас очень важна, особенно в свете постепенного перехода от традиционных ЦОД к частным и гибридным облакам с их массивами вычислительных, сетевых и дисковых ресурсов и новыми методами оркестровки и контейнеризации приложений. Открытая архитектура Juniper отвечает этим требованиям и должна помочь новому поколению операционных систем для ЦОДов управлять самыми сложными сетевыми архитектурами.
