ОС для данных

Сегодня принято считать, что оборудование перестало быть основным активом, технологии не самоцель, а главное — это данные, однако в словосочетании «информационные технологии» акцент по-прежнему ставится на «технологии», а сам предмет, цель существования ИТ — данные — лишь подразумевается. Несмотря на декларацию «данные — основа цифровой экономики», большинство современных автоматизированных систем ориентируются на прикладное и системное ПО с жестко зашитой в нем логикой обработки данных, почти не зависящей ни от их семантики, ни от источника. Отсутствие внимания к данным отразилось и на архитектуре популярных сегодня операционных систем, созданных еще до эпохи облачных, параллельных и распределенных конфигураций. Как следствие, при работе таких ОС в цифровых средах возникают проблемы масштабируемости, неоднородности, доступности и безопасности.

Архитектуре наиболее распространенных сегодня ОС уже более 40 лет, а на момент их создания экземпляру системы нужно было работать с одним процессором, ограниченным объемом оперативной памяти, и решать четко определенный круг задач. Сегодня облачные платформы — это сотни тысяч процессоров десятков архитектур, разнородные вычислительные ресурсы (GPU, FPGA, тензорные процессоры, умные сетевые карты и пр.) и разнообразные структуры организации памяти. Сорок лет назад программисты создавали монолитные программы, работающие в пакетном режиме: запуск, выполнение, завершение. Мало того что современные программы могут быть написаны на нескольких языках, использовать разнообразные сервисные библиотеки (поисковые движки, коммуникации, базы данных, машинное обучение и пр.), так они еще должны работать непрерывно с различными нагрузками, и к тому же в распределенном режиме. Задача отладки и масштабирования систем, поддерживающих работу миллионов пользователей и обращающихся к тысячам сервисов, усложнилась многократно, а управление ОС выливается сегодня в серьезную проблему регулирования тысяч процессов и миллионов параллельных потоков.

Одна из основных проблем масштабирования и обеспечения безопасности нынешних ОС — отсутствие единой централизованной модели данных для описания состояния операционной системы. Например, ядро Linux содержит десятки различных структур данных для управления различными частями состояния ОС: таблица процессов, планировщик, кэш страниц, очереди сетевых пакетов, пространство имен, файловые системы и пр. Каждый из компонентов ядра предлагает разные интерфейсы для управления, десятки API для мониторинга состояния ОС, что усложняет любые усилия по добавлению в систему новых возможностей. Например, потребовались годы, чтобы добавить единообразные интерфейсы управления безопасностью в Linux, которые необходимо синхронизировать с изменениями в других компонентах ядра. Ушло полтора десятилетия на то, чтобы в Linux появилось разработанное для ОС Solaris средство динамической отладки DTrace. Сообщество ОС постоянно предлагает множество расширений для добавления новых возможностей (средства отслеживания, инструменты для отмены изменений, внесенных злоумышленниками, новые модели безопасности и др.), но, столкнувшись со стеной затрат на их интеграцию в полноценную промышленную ОС, вынуждено оставлять их на уровне академических пилотов.

Цифровая эпоха, в основе которой лежат данные, требует пересмотра архитектуры ОС: она должна освободиться от существующих проблем с масштабированием, ведущих к снижению производительности, и от сложностей с управлением и обеспечением безопасности выполнения приложений. Архитектура должна ориентироваться на данные и строиться на четком разделении своих состояний.

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

Сегодня имеется ряд разработок архитектуры ОС, ориентированной на данные, среди них — DBOS, Solros, ExtOS и Twizzler. В каждом из подобных проектов предлагается свой взгляд на решение многогранной задачи создания архитектуры операционной системы для современного цифрового пространства.

DBOS: от файлов к таблице

Архитектуру «ОС как база данных» (DBOS) предложила группа исследователей во главе с Майклом Стоунбрейкером [1], считающая, что все состояния операционной системы, ориентированной на данные, должны быть единообразно представлены в виде таблиц реляционной СУБД. Такой подход, как считают авторы, позволит масштабировать и развивать ОС без переработки ее кода, проверки и отладки ее состояния. Кроме того, появляется возможность без простоев обновлять компоненты ОС, управлять ее ресурсами с привлечением средств машинного обучения. Работа по масштабированию или изменению поведения ОС может быть разделена между компонентами: если компоненты ОС получают доступ к своему состоянию через таблицу запросов, то, вместо того чтобы повторно плодить десятки структур данных для масштабирования их на многоядерные конфигурации, достаточно лишь масштабировать реализации общих табличных операций. Точно так же новые функции отладки или безопасности при этом подходе могут быть один раз реализованы в табличной модели данных, вместо того чтобы требовать отдельной интеграции и отдельной работы с каждым компонентом ОС.

Данные в DBOS отделяются от вычислений, а для централизованного управления состоянием ОС используется простая и близкая авторам этого проекта реляционная структура, апробированная на протяжении десятилетий. Таблица процессов, состояние планировщика, таблицы потоков, таблицы разрешений — всё это таблицы под управлением СУБД, которая по сути и составляет ядро ОС, что позволяет через единый интерфейс запрашивать сведения о состоянии системы.

Таким образом, авторы проекта DBOS предлагают заменить мантру Unix «Все является файлом» на «Все является записями в таблицах». В результате все операции над файлами суть запросы к СУБД: выбор следующей задачи для запуска; обнаружение процессов, отставших при параллельном вычислении; поиск перегруженных или недогруженных потоков; обнаружение новых ресурсов или выведенных из использования; прогнозирование возникновения узких мест в системах реального времени и пр.

Что дает DBOS?

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

Безопасность. Инструменты управления доступом к СУБД, такие как списки ACL (Access Control List) на основе представлений, атрибутов и ролей, позволяют элегантно обеспечивать многие политики безопасности в реализациях SELinux (Security-Enhanced Linux). Кроме того, код проверки безопасности может быть представлен в виде регулярных запросов к СУБД, а не через функции ОС, выполняемые в отдельном модуле.

Виртуализация и контейнеризация. За последнее десятилетие огромные силы были вложены в поддержку средств виртуализации и контейнеризации — запуск экземпляра ОС или группы процессов для изолированного выполнения нескольких приложений. Это обычно требует изменения всех структур данных и логики в ядре ОС для поддержки различных «пространств имен» объектов для каждого контейнера и наложения ресурсных ограничений на соответствующие группы процессов. С помощью DBOS виртуализация и контейнеризация могут быть реализованы с помощью функций СУБД: запросы СУБД каждого контейнера имеют доступ только к описанию с конкретным идентификатором, тогда как пользователь с правами root может иметь доступ ко всем объектам. Многие запросы и логику в компонентах ОС в этом случае вообще не нужно изменять при добавлении виртуализации.

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

Управление файлами. Файлы DBOS хранятся в СУБД в виде больших двоичных объектов и таблиц, структура каталогов — это набор таблиц, а средства контроля доступа SQL используются для обеспечения защиты. По существу, исчезает необходимость в большом объеме кода реализации файловых систем. Например, поиск всех файлов в определенном каталоге доступа за последние сутки — это простой SQL-запрос.

В DBOS SQL становится центральным API, но дело даже не в выборе языка запроса как такового (принципиально он мог бы быть и иным), а в том, что в основании системы лежит база данных. В этом состоит кардинальное отличие, например, от проекта osquery (osquery.io), где через SQL можно выполнять почти все операции в среде обычной ОС Linux.Однако в этом проекте не используется какая-либо СУБД, а кроме обычной файловой системы, используется специализированная ProcFS, имеющая доступ к информации из ядра системы.

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

Параметры ОС должны самонастраиваться независимо от первоначальных предположений. В DBOS предлагается использовать методы, применяемые в языке программирования типа SmartChoices (arxiv.org/abs/1810.00619), в котором все эвристики заменяются моделью машинного обучения, что позволяет автоматически настраивать параметры и корректировать константы. Хранение в СУБД сведений о состояниях системы позволяет непрерывно анализировать ход работы ОС, обеспечивать мониторинг ее параметров и существенно упрощать процесс управления, сделав реальностью самонастройку ее компонентов для повышения производительности приложений при работе с широким спектром рабочих нагрузок и одновременно упростив администрирование.

Однако для DBOS по-прежнему нужны традиционные операционные системы. Скорее всего, на каждом из узлов, обслуживаемых этой ОС, нужно будет запустить экземпляр Linux, задача которого фактически сведется к уровню микропрограммного обеспечения — запустить базовые сервисы DBOS и «отдать» ей доступное оборудование. В качестве реляционных СУБД — кандидатов для несения всех данных предложены MemSQL и близкая к Стоунбрейкеру VoltDB, способные на многоузловых конфигурациях обрабатывать десятки миллионов простых транзакций в секунду (для запуска их экземпляров на узлах тоже нужен Linux).

Таким образом, проект, с одной стороны, похож на продвинутый менеджер кластерных ресурсов (такой как Yarn или Mesos, недаром два ключевых разработчика обоих — Майкл Кафарелла и Матей Захария — входят в состав рабочей группы DBOS). С другой стороны, у DBOS гораздо больше черт полноценной операционной системы, чем, например, у проекта OpenStack, который в свое время тоже называли «кластерной операционной системой». Однако в OpenStack основной класс объектов управления — виртуальные машины, то есть фактически экземпляры других ОС, тогда как DBOS непосредственно управляет процессами, заданиями, файлами и другими примитивами уровня операционной системы. Тем не менее на DBOS можно смотреть как на проект слияния СУБД и ОС в единое целое на новом технологическом витке, в ходе которого возродятся идеи ОС Pick и Mumps (www.osp.ru/os/2013/09/13038286), предложенные еще в 1960-х годах.

Ведущий архитектор баз данных

Майкл Стоунбрейкер (род. в 1943 году) — один из самых именитых из ныне живущих ученых, работающих над теоретическими основами баз данных; лауреат практически всех престижных наград в области информатики: обладатель премии Тьюринга от ACM, медали фон Неймана от IEEE, премии Flame от USENIX; почетный член множества научных сообществ, в том числе иностранный член РАН. Глубокие теоретические результаты его научно-исследовательской деятельности неотделимы от его практических инициатив, воплотившихся в коммерчески успешные проекты СУБД:

1972: Стоунбрейкер и Юджин Вон создают реляционную СУБД Ingres, распространяемую в открытых исходных кодах. В системе раньше, чем в System R и Oracle DB, были реализованы триггеры, представления, ссылочная целостность, вскоре ставшие стандартом в мире СУБД.

1984: один из разработчиков Ingres переходит в корпорацию Sybase, и на основе кодовой базы этой СУБД появляется Sybase SQL Server (ныне — SAP Adaptive Server Enterprise).

1986: Стоунбрейкер сосредотачивается на проекте Postgres.

1987: на основе кодов Ingres корпорация Tandem создает NonStop SQL — первую отказоустойчивую реляционную СУБД, ставшую вскоре стандартом для сверхинтенсивных и сверхкритичных OLTP-нагрузок.

1994: Эндрю Ю и Джолли Чэнь берут «брошенные» открытые коды Postgres, заменяют язык запросов PostQUEL на стандартный SQL — стартует проект PostgreSQL.

1996: Microsoft и Sybase, совместно выпускавшие версии Sybase SQL Server для OS/2 и Windows, разделяют кодовые базы — появляется MS SQL Server, еще один коммерчески успешный потомок СУБД Ingres.

2000: Стоунбрейкер уходит на профессорскую должность в Массачуссетский технологический институт и начинает новый проект — федеративную СУБД Mariposa, права на которую приобретает Peoplesoft.

2003: Стоунбрейкер становится сооснователем компании StreamBase, коммерциализирующей его проект поточно-ориентированной СУБД Aurora, которую в 2013 году приобретет корпорация Tibco.

2005: для развития своего проекта поколоночной СУБД без разделяемых ресурсов C-Store Стоунбрейкер основывает компанию Vertica; с 2011 года СУБД Vertica — одна из наиболее популярных коммерческих аналитических СУБД.

2006: Стоунбрейкер инициирует проект Morpheus — интеграционную СУБД, оптимизировавшую загрузку и трансформацию данных из разнородных источников.

2007: Стоунбрейкер запускает проект HStore — резидентную распределенную СУБД, ориентированную на OLTP-нагрузки.

2008: Стоунбрейкер основывает стартап Paradigm4, выпускающий поколоночную СУБД SciDB.

2009: Стоунбрейкер и его коллеги переименовывают систему HStore в VoltDB и основывают одноименныйстартап.

2014: Стоунбрейкер запускает проект BigDAWG создания эталонной реализации базы данных с открытым исходным кодом, поддерживающей гетерогенные движки баз данных, несколько языков программирования и сложную аналитику для различных рабочих нагрузок. На данный момент BigDAWG поддерживает PostgreSQL, SciDB и Apache Accumulo.

2020: DBOS — концепция операционной системы над СУБД для работы с данными в масштабе тысяч вычислительных узлов.

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

ExtOS: расширение ядра кодом приложения

Существенная проблема современных ОС — необходимость работы с разнообразным оборудованием: конец масштабирования по закону Деннарда («уменьшая размеры транзистора и повышая тактовую частоту процессора, можно повышать его производительность») привел к поиску альтернатив обработке на процессорах общего назначения [2], в связи с чем в приложениях машинного обучения применяются специализированные ускорители (FPGA, графические, тензорные процессоры), каждый со своими примитивами для выполнения массово-параллельных вычислений и обеспечения высокой пропускной способности памяти. Вкупе с появлением многоуровневой основной системы памяти и сетевых интерфейсов, обеспечивающих прямой доступ к удаленной памяти (RDMA) со скоростью выше, чем у локального хранилища, это буквально поставило в тупик существующие операционные системы, не рассчитанные на такие масштабы или неоднородности.

Несмотря на радикальные изменения в оборудовании ввода-вывода, системное ПО по-прежнему построено на концепции почти полувековой давности: медленные накопители, еще более медленные сети и быстрый процессор с прямым доступом к оперативной памяти. Все устройство POSIX API нацелено на буферизацию медленного ввода-вывода с синхронизацией по требованию через системные вызовы, выполняемые ядром ОС. Как следствие, для полноценного использования современного оборудования, от флеш-накопителей до высокопроизводительных сетей, программисты стараются обойти ядро ОС, размещая драйверы устройств и сопутствующие сервисы системы в пользовательском пространстве. Это хорошо работает в случае специализированных решений, но не имеет ничего общего с совместимостью, переносимостью и повторным использованием ПО. Таким образом, корпоративные серверные, научные, офисные и мобильные приложения, основанные на классических ОС и унаследованных программах, теряют шансы воспользоваться всеми возможностями современного оборудования.

Авторы проекта ExtOS (Extensible OS) [3] предлагают ориентированную на данные расширяемую ОС, позволяющую эффективнее использовать новейшее высокопроизводительное оборудование ввода-вывода. Основная идея — минимизация перемещений данных и акцент на архитектуре, разрешающей приложениям настраивать подсистемы ввода-вывода ядра ОС. Такой подход обеспечивает совместное использование несколькими приложениями высокопроизводительного ввода-вывода. Как утверждается, прототипы этой ОС, построенные на базе Linux, позволили почти в пять раз ускорить выполнение базовых команд Unix и вдвое — примитивов баз данных.

В предложенную архитектуру заложена давняя идея перемещения обработки ближе к данным (near data processing, NDP) и проброса вычислений в СУБД (operator pushdown in databases). Эти принципы распространяются на универсальное ПО в предположении, что данные следует перемещать только в том случае, если они будут использоваться для общих вычислений, а если обработка тривиальна или данные используются непосредственно, то все вычисления должны выполняться на месте. Общие системные операции ввода-вывода (чтение и запись, отправка и получение) и специфические для приложения действия (удаление или копирование данных) выполняются в ОС при минимальном участии приложения.

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

Рис. 1. ExtOSВ и альтернативные архитектуры

ExtOS (рис. 1) позволяет приложениям без монополизации совместно использовать один и тот же ресурс ввода-вывода. Такая демократизация путем расширения Unix-подобных монолитных ОС вполне может быть выполнена на клонах Linux путем относительно небольших модификаций за счет использования модуля фильтрации пакетов (Berkeley Packet Filter и eBPF), захватывающего и перенаправляющего необходимые команды, проходящие через любой интерфейс системы. Фактически вычислительная модель может быть применена к любому устройству ввода-вывода, в частности к устройствам хранения. Однако возможности BPF/eBPF слишком ограниченны, поэтому в ExtOS они были расширены для подсистемы хранения ОС.

Вместе с тем расширение ядра ОС во время выполнения кодом приложения, который в общем случае не является надежным, может повлиять на безопасность. Авторы проекта ExtOS стремятся создать промышленную ОС, но для этого надо решить задачу обеспечения безопасности при загрузке ненадежного кода приложения в ядро. В частности, следует обеспечить безопасность памяти.

Solros: делегирование полномочий

Группа исследователей из Политехнического университета Вирджинии, Технологического института Джорджии и компании eBay [4] предложила открытую архитектуру операционной системы Solros для работы с гетерогенными системами, включающими быстрые хост-процессоры, медленные параллельные сопроцессоры и быстрые устройства ввода-вывода. Для полноценного управления такой аппаратной системой требуется тесная интеграция процессоров и устройств ввода-вывода.

Сегодня имеется несколько моделей программирования для обеспечения вычислений в неоднородных средах: OpenCL, OpenMP, MPI, CUDA. А совсем недавно в Popcorn Linux была продемонстрирована бесшовная (seamless) миграция вычислений между хост-процессорами и сопроцессорами в рамках единого образа ОС. Для достижения высокой производительности без усложнения программирования требуется централизованная координация операций ввода-вывода, однако пока для гетерогенных систем модель эффективного ввода-вывода не предложена.

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

Для полноценного использования оборудования в Solros, операционные системы хоста и сопроцессора играют разные роли. ОС сопроцессора — это ОС плоскости данных (data-plane), которая делегирует ОС хоста (ОС уровня управления) сервисы работы с файлами и сетевые стеки. ОС плоскости данных — это минимальная RPC-заглушка, которая вызывает несколько сервисов ОС плоскости управления и при необходимости обеспечивает изоляцию между приложениями сопроцессора. ОС уровня управления работает на хосте, отвечая за координацию и оптимизацию взаимодействия сопроцессоров и устройств ввода-вывода, и обладает всей необходимой информацией о системе: о топологии сети PCIe, нагрузке на каждый сопроцессор, доступе к файлам сопроцессоров.

Рис. 2. Делегирование выполнения сервисов ввода-вывода: а — хост-центричная архитектура; б — сопроцессор-центричная; в — архитектура Solros

Идея делегировать выполнение части сервисов, особенно сервисов ввода-вывода, другим ОС не является новостью — такой подход широко применяется в виртуализации, высокопроизводительных и гетерогенных вычислениях с сопроцессорами. Делегирование выполнения сервисов ввода-вывода от быстрых, но плохо распараллеливаемых хост-процессоров высокопараллельным сопроцессорам повышает производительность ввода-вывода (рис. 2).

В ОС Solros имеется три основных сервиса: высокооптимизированный транспортный сервис для массово-параллельных процессоров и шины PCIe, сервис файловой системы и сетевой сервис. Файловая система самостоятельно выбирает, по какому пути направить потоки ввода-вывода: по одноранговой сети (P2P) или опосредованно через хост. Сетевой сервис поддерживает TCP-интерфейс сокета и выполняет балансировку нагрузки для серверного сокета так, чтобы несколько сопроцессоров прослушивали один и тот же адрес в соответствии с заданными политиками балансировки нагрузки.

Прототип Solros был реализован на сопроцессорах Xeon Phi и твердотельных NVMe-накопителях. Было обеспечено значительное улучшение производительности по сравнению с традиционной архитектурой; в 19 раз выросла скорость операций случайного чтения, и в 7 раз уменьшилась задержка при выполнении TCP-операций. Исходный код Solros доступен на Github.

Twizzler: работа в одноуровневой памяти

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

Традиционное разделение означает, что ОС управляет эфемерными копиями данных, присваивая им виртуальные адреса и контролируя операции сохранения состояния. По сути, операционные системы предоставляют абстракции для доступа к данным, физически размещаемым на конкретном оборудовании, отражая через интерфейсы ввода-вывода структуру носителей данных и учитывая их особенности, распределение потоков, деление на домены и пр. Всё это — функции ядра ОС, а значит, и накладные расходы на каналы и управление совместно используемыми виртуальными пулами памяти. Данные в памяти переформатируются, копируются в буферы, а затем отправляются блоками либо на постоянное хранение, либо на сетевое устройство. Затем на принимающей стороне блоки снова считываются в буферы и десериализуются, и в конечном счете воссоздается оптимизированное представление структуры данных в памяти. При каждом таком копировании теряются время и энергия, а данные подвергаются потенциальной опасности порчи и компрометации. Традиционные ОС рассчитаны на то, чтобы выполняться неопределенно долго и при каждом запуске заново формировать свое состояние в памяти.

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

Проект ОС Twizzler для работы с энергонезависимой памятью предложила группа авторов из Калифорнийского университета в Санта-Крус и компании Pure Storage [5], считающая, что для работы с энергонезависимой памятью требуется ОС, ориентированная на данные, а не на процессы.

В Twizzler память делится на объекты данных и указатели на них, интерпретируемые в контексте объекта, что отделяет указатели от адресного пространства конкретного потока выполнения и поддерживает модель программирования, ориентированную именно на данные. Результат — более простая среда, в которой основная функция ОС — поддержка управления, обменов и защита постоянных данных. Ядро не принимает участия в поддержке ввода-вывода, а предоставляет приложениям прямой доступ к объектам данных в постоянной памяти через 64-разрядные указатели. Прототип Twizzler работает до 13 раз быстрее, чем Unix.

По сути, в Twizzler реализованы два главных принципа ОС, ориентированной на данные: ядро исключено из конвейера поддержки ввода-вывода — обеспечен прямой доступ к данным; реализован механизм прямых ссылок на данные. В отличие от виртуальной памяти с ее виртуальными ссылками на данные, исчезающими после завершения работы виртуальной машины, данные в энергонезависимой памяти вместе со ссылками на них сохраняются после завершения работы контейнера. Постоянные данные по определению могут быть одновременно доступны нескольким субъектам, следовательно, они хранятся в форме, допускающей их совместное использование без необходимости привлечения эфемерного контекста в виде метаданных, связанных с конкретным носителем.

Поскольку состояние хранится всегда, то отпадает необходимость периодической проверки контрольных точек. В такой системе состояние автоматически сохраняется при отключении питания: приложения и ОС могут мгновенно переходить в режим выключения и столь же быстро возвращаться к работе, не «заботясь» о копировании состояния.

Рис. 3. Архитектура Twizzler

ОС Twizzler предоставляет автономную среду выполнения ядра и поддержку пользовательского пространства для исполнения приложений. Ядро обеспечивает примитивы планирования, синхронизации и управления. На рис. 3 приведена архитектура системы и представлен порядок работы различных частей системы с объектами данных.

Система Twizzler спроектирована для работы с энергонезависимой памятью, предоставляющей эффективные и простые способы прямого доступа к памяти. Перекрестные указатели объектов в Twizzler позволяют программистам создавать приложения с низкими накладными расходами на системные вызовы за счет удаления из ядра функций поддержки многоуровнего доступа. Простая модель программирования позволяет работать и с унаследованными конфигурациями без энергонезависимой памяти, но с большой RAM. Авторы проекта заявляют о возможности перенести в эту ОС уже существующее программное обеспечение (например, SQLite). Есть, правда, одна серьезная проблема — нехватка разрядов для адресации, обусловленная тем, что производители микропроцессоров не рассчитывали на прямой доступ к гигантским объемам памяти.

Twizzler — не первая ОС с «персистентной памятью»: достаточно упомянуть IBM OS/400 (впоследствии System i) и российский проект ОС «Фантом» [6], приложения в которых не теряют данные после перезагрузки. Но, в отличие от предшественников, спроектированных для работы с медленными и «неотзывчивами» дисковыми накопителями, которые на «физическом» уровне обеспечивали хранение, Twizzler работает непосредственно с энергонезависимой памятью с байтовой адресацией, что позволяет рассчитывать на большой прогресс. Особенно это важно для СУБД нового поколения: наличие энергонезависимой памяти позволяет кардинально сменить архитектуру обработки транзакций. Однако с традиционными ОС для этого приходится преодолевать множественные идеологические ограничения [7].

Совместное будущее

Перечисленные проекты ОС, хотя и направлены на общую цель — работать с данными, содержательно различаются, и в этом смысле они не конкурируют друг с другом и даже могли бы стать взаимодополняющими. Например, ExtOS могла бы ускорить операции для «несущей» СУБД DBOS, которую впоследствии можно было бы перенести на Twizzler, а Solros могла бы задействовать сопроцессорные ресурсы, освобождая основные вычислительные мощности от необходимости решать задачи ввода-вывода.

Но индустрия не спешит переходить на новые системы и часто довольствуется паллиативными решениями. Ведь остается все еще много вопросов: насколько эффективно будут работать новые ОС; насколько глубокие модификации потребуются в действующем ПО для переноса на новые системы; насколько надежны алгоритмы структуры и СУБД, которые закладываются в основу новых ОС; каковы пределы масштабируемости и не потребуется ли уже через несколько лет искать альтернативные подходы для освоения возможностей нового оборудования и решения задач обработки возрастающих объемов данных.

***

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

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

Литература

1. Michael Cafarella, David DeWitt, Vijay Gadepally, Jeremy Kepner, Christos Kozyrakis, Tim Kraska, Michael Stonebraker, Matei Zaharia. DBOS: A Proposal for a Data-Centric Operating System. URL: arxiv.org/abs/2007.11112 (дата обращения: 20.03.2021).

2. Кирк Бресникер, Шарад Сингхал, Стэнли Вильямс. Как преуспеть в условиях экономики изобилия памяти? // Открытые системы. СУБД. — 2016.— № 2. — С. 10–15. URL: https://www.osp.ru/os/2016/02/13049318 (дата обращения: 20.03.2021).

3. Antonio Barbalace, Javier Picorel, Pramod Bhatotia. ExtOS: Data-centric Extensible OS. doi.org/10.1145/3343737.3343742.

4. Changwoo Min, Woonhak Kang, Mohan Kumar, Sanidhya Kashyap, Steffen Maass, Heeseung Jo, Taesoo Kim. Solros: A Data-Centric Operating System Architecture for Heterogeneous Computing. EuroSys '18: Proceedings of the Thirteenth EuroSys Conference, April 2018, Article No. 36. P. 1–15. Doi: 10.1145/3190508.3190523.

5. Daniel Bittman, Peter Alvaro, Pankaj Mehra, Darrell D. E. Long, Ethan L. Miller. Twizzler: a Data-Centric OS for Non-Volatile Memory USENIX Annual Technical Conference, July 15–17, 2020. ISBN 978-1-939133-14-4.

6. Дмитрий Завалишин. Операционная система «Фантом» // Открытые системы. СУБД. — 2011. — № 3. — С. 20–23. URL: https://www.osp.ru/os/2011/03/13008200 (дата обращения: 20.03.2021).

7. Дмитрий Волков, Адрей Николаенко. На пути к «железным» СУБД // Открытые системы. СУБД. — 2019. — № 2. — C. 8–13. URL: www.osp.ru/os/2019/02/13054946 (дата обращения: 20.03.2021).

Андрей Николаенко (ANikolaenko@rubytech.ru) — архитектор, компания «Рубитех»; Дмитрий Волков (vlk@keldysh.ru) — старший научный сотрудник ИПМ им. М.В. Келдыша РАН (Москва).

DOI: 10.51793/OS.2021.48.96.002