Операционная система Clouds

История и обзор архитектуры

Clouds [Dasgupta et al. 1991] представляет собой операционную систему для поддержки распределенных объектов, разработана в Технологическом институте Джорджии, США. Первая версия Clouds была реализована в 1986 году. Мы описываем версию 2, которая разрабатывалась с 1987 года. Эта версия основана на микроядре Ra, которое было разработано для поддержки различных моделей программирования распределенных объектов. Clouds включает в себя полный набор средств системного уровня, включая хранилище и ввод-вывод. Она основана на объектно-поточной парадигме, которая представляет собой версию распределенной операционной системы для парадигмы объектно-ориентированного программирования. Объекты являются тяжеловесными пассивными сущностями, каждая из которых имеет собственное адресное пространство, инкапсулирующее код и данные. Потоки (activity) — выполняют методы внутри объектов, вызывая операции над другими объектами по мере их выполнения.

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

В распределенных операционных системах Mach, Chorus и Amoeba общие ресурсы управляются серверами. Эти системы основаны на объектах в том смысле, что клиенты могут обращаться ко всем ресурсам единообразным образом.

Clouds отличаются от Amoeba, Mach и Chorus объектно-ориентированным стилем вызовов и типом потоков, которые они поддерживают.

Как мы увидим, Clouds не обеспечивают передачу сообщений; и хотя объектам близка среда выполнения, такая же как в операционных системах на основе процессов, но объекты не связаны со своими потоками. Потоки в Clouds могут перемещаться от объекта к объекту и, следовательно, от компьютера к компьютеру.

Clouds предназначена для поддержки ряда языков, основанных на парадигме объектно-потоковой обработки. В настоящее время расширение языка для C++ [Stroustrup 1986] называется DC++, и расширение для языка Eiffel [Meyer 1988] называется Distributed Eiffel. Программисты могут создавать и компилировать классы, используя эти языки, и создавать экземпляры — то есть объекты с закрытым состоянием — на основе этих классов. Интерактивные пользователи могут создавать потоки неявно, указывая вызов объектов из командной строки. Clouds выполняет потоки и вызовы в сети прозрачным образом.

Архитектура системы Clouds (рис. 1.) состоит из трех классов компьютеров: рабочих станций, серверов данных и вычислительных серверов.

Рабочие станции (User workstations) используются для взаимодействия пользователей, и они работают под управление ОС UNIX. Она предоставляет файловые службы и службы для взаимодействия пользователя с остальной частью Clouds

Серверы данных (Data servers) управляют дополнительным хранилищем для кода и данных, принадлежащих объектам. Серверы данных управляются ядром Ra. Файловые службы в Clouds не доступны программистам т.к. в Clouds нет специальной концепции файла. Вместо этого все объекты в облаке сами по себе являются постоянными. Объекты, такие как файлы, переживают любые потоки, выполняющие вызовы на них, до тех пор, пока они не будут явно удалены. Мы рассмотрим эту нотацию далее, ниже.

Вычислительные серверы (Compute servers), взятые вместе, функционально похожи на пул процессоров Amoeba, хотя они не обязательно могут быть основанными на стойке, а могут быть обычными компьютерами. Потоки в Clouds выполняют операции над объектами на вычислительных серверах, которые динамически выбираются на основе иерархии вызовов. Компьютеры вычислительного сервера являются однородными и не нуждаются в каком-либо дополнительном хранилище. Они также управляются ядром Ra.

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

Цели разработки и главные конструктивные особенности

Clouds обладает следующими основными задачами и возможностями:

• Поддержка объектно-потоковой вычислительной модели: объекты Clouds (object) — это абстракции защищенного, пассивного хранения, а потоки (activity) — абстракции действий, которые существуют независимо от объектов. Поскольку объекты Clouds являются тяжеловесными (они включают виртуальное адресное пространство), предполагается, что программное обеспечение языка во время выполнения (run-time) может реализовывать множество мелких объектов (размером порядка десятков или сотен байт) внутри одного объекта Clouds. Эти небольшие объекты имеют специфическую для языка семантику, которая может отличаться от базовой объектной модели Clouds. Кластеризация объектов внутри объектов Clouds-хоста сокращает средние затраты на создание и удаление объектов. Поскольку некоторые вызовы в основном будут между объектами в пределах одного и того же объекта Clouds, кластеризация также может уменьшить количество переключений контекста, возникающих во время вызовов.

• Вызов прозрачного объекта в сети: прямой доступ к коду или данным внутри объекта предотвращается аппаратным обеспечением управления памятью. Единственным механизмом доступа к состоянию объекта является вызов. Вызов указывает целевой объект, метод, который вызывается внутри него, и входные и выходные параметры. Поток, выполняющий вызов, блокируется до тех пор, пока не будет выполнен соответствующий метод и не будут возвращены никакие параметры результата. Все передачи данных между объектами происходят, с точки зрения программиста, путем передачи параметров вызова, а не путем передачи сообщений, таких, как, скажем, в Amoeba и Mach. Вызов является прозрачным для сети, и поток может выполнить вызов объекта на любом вычислительном сервере, независимо от того, где сохранен объект.

• Постоянная одноуровневая система хранения данных: для программиста существует только один уровень хранения вместо обычной первичной/вторичной иерархии хранения. Изменения, внесенные в данные объекта, с некоторыми исключениями автоматически отражаются в версии, находящейся во вторичном хранилище на сервере данных. Этот механизм является близким сопоставленным файлам. Объекты не должны быть явно сохранены, или размещены в любой специальной форме для хранения. Конечно, для выполнения операции объекта Clouds необходимо передать код и данные объекта в основную память вычислительного сервера (Compute server).

• Общий доступ через объекты: все совместное использование в Clouds происходит путем выполнения вызовов на общих объектах — так же, как обмен происходит через файлы в других системах. Потоки, выполняющие методы внутри одного объекта, совместно используют код и данные объекта. Таким образом, Clouds обеспечивают низкоуровневые механизмы управления параллелизмом, такие как семафоры. Однако, чтобы усложнить вопросы с точки зрения реализации, потоки, выполняющиеся на отдельных компьютерах, могут выполняться параллельно в пределах одного объекта (это прозрачно для программиста). Потоки имеют доступ к одному и тому же коду и данным с одинаковыми виртуальными адресами, даже если компьютеры, на которых они выполняются, не используют физическую память. Память действительно может быть логически общей между потоками, которые выполняются на разных компьютерах без физически общей памяти, через абстракцию распределенной общей памяти (distributed shared memory).

• Автоматическая балансировка нагрузки: облака позволяют использовать поддерживаемую системой политику балансировки нагрузки при каждом выполнении вызова, чтобы выбрать вычислительный сервер для выполнения метода целевого объекта. Кроме того, программист может указать местоположения для выполнения вызова.

Объекты, потоки и вызовы

Виртуальное адресное пространство объекта состоит из областей, которые сопоставляются с ресурсами памяти, называемыми сегментами. Объект содержит постоянные: сегмент кода, сегмент данных и кучи (heap). Фактически объект обычно содержит две кучи. Постоянная куча используется для динамически выделяемой памяти, которая сохраняется с объектом. Объект также может содержать сегмент volatile (замечание переводчика: разделяют volatile и non-volatile память, в рус.яз. для второй дается определение как энерго-независимая память") для временных данных кучи. Содержимое изменяемого сегмента может быть отброшено системой до тех пор, пока в объекте, содержащем их, не будет выполняться поток. Доступ ко всем сегментам осуществляется с помощью прямых ссылок на память: за реализацию виртуальной памяти отвечает чтение или запись соответствующих данных из или в дополнительное хранилище.

Доступ к объектам происходит по ссылки на объекты, которые являются глобальными и доступны независисмо от места нахождения объекта. Каждая ссылка имеет уникальное имя — sysname. Поток, выполняющий вызов, должен предоставить sysname целевого объекта. Он получает ссылки (sysname) общих объектов через сервер имен, который хранит сопоставление текстового имен переменной. Вызов указывает идентификатор метода, который используется для поиска точки входа в целевом объекте — адрес, из которого система продолжает выполнение вызывающего потока при входе в вызываемый объект. Clouds предполагают статическую проверку типа во время компиляции (этап compile-time) используемого для обеспечения соответствия доступа потоков к только допустимым точкам входа объектов.

Рассмотрим пример (адаптировано на основе Dasgupta et al. [1991]), который показывает пример кода DC++ для работы с объектом rectangle, который является экземпляром класса rectangle. После поиска именованного экземпляра RectA с сервера имен, код делает еще два вызова на этот прямоугольник, чтобы установить его размер и определить его площадь. Обратите внимание, что в соответствии с классом rectangle язык автоматически предоставляет класс rectangle_ref ссылок на экземпляры rectangle. Это обеспечивает bind метод, который делает вызов сервера имен для поиска sysname из текстового имени, а также наследование методов базового класса rectangle.

Пример 1 Вызовы объект rectangle
clouds_class rectangle;
int x,y; // persistent data for rect.
entry rectangle; // constructor
entry size (int x,y); // set size of rect.
entry int area(); // return area of rect.
end_class
rectangle_ref rect; // ‘rect’ is a variable that holds
// an instance of a class that refers
// to an object of type rectangle
rect.bind("RectA"); // call to name server, which returns
// sysname for existing object "RectA"
rect.size(5,10); // invocation of RectA
printf("%d\n", rect.area()); // will print 50


На рис.2. показана операция вызова потоком при наследовании объектов, и возврат после выполнения каждого вызова в конечном итоге к исходному вызывавшему объекту. Вызов является синхронным. Если поток требуется для продолжения выполнения в объекте, в то время как другой вызов выполняется, он может создать второй поток для выполнения вызова в то время как исходный поток продолжается.



Рисунок 2 — Один поток выполняет вызовы трех объектов


Движение одного потока между объектами в отдельных адресных пространствах называется диффузией потоков (thread diffusion). Конечно, это представление является абстракцией: диффузия потоков реализуется с помощью известных абстракций активности (activity) и связью абстракций, предоставляемых базовыми ядрами Ra. Однако то, что принципиально отличается от предыдущих вычислительных моделей, заключается в том, что программисты Clouds не контролируют количество потоков внутри объекта. В то время как, например, программист Mach явно создает потоки, назначенные для получения входящих RPC, поступающих в задачу, потоки в Clouds входят в объект извне". Потенциально в объекте выполняется столько потоков, сколько необходимо для выполнения вызовов. Конечно, существует ограничение физических ресурсов на количество потоков, которые могут выполняться на одном и том же вычислительном сервере, наложенное ядром Ra.

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

Реализация модели вычислений

Микроядро Ra предоставляет три простых абстракции:

isibas — абстракция activity, которая выполняется как в пользовательском режим (user mode) так и в режиме супервизора (supervisor mode), которая, в отличие от потоков более высокого уровня, ограничена одним компьютером;

segments — ресурсы сопоставленной памяти (mapped memory resources);

virtual spaces — состоит из коллекции регионов сопоставленных сегментам.

Виртуальные пространства (virtual spaces) сами по себе не являются целыми адресными пространствами. Каждый isiba может быть связан с тремя различными виртуальными пространствами: пространства O Space содержит объектный код и данные для текущего вызова на уровне пользователя; пространство P Space содержит специфичные для потока личные данные, такие как стек и область передачи параметров; и пространство K Space содержит образ самого ядра и является общим для всех isibas.

В дополнение, кроме ядра, пространство K Space также содержит системные объекты. Это объекты, выполняющие некоторые функции более высокого уровня, чем стандартное ядро. Системные объекты — это серверы системы Clouds. Системные объекты выполняются в адресном пространстве ядра ради эффективности. Они отдельно компилируются и загружаются в ядро во время конфигурирования. Они, как и само ядро, написаны на языке С++. Они наследуют операции от классов ядра и таким образом могут вызывать свои сервисы напрямую (в то время как isibas уровня пользователя должны делать ловушки системного вызова). В отличие от серверов Chorus, не существует объекта для загрузки системных объектов динамически.

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

Выполнение вызова: во-первых, если программист не определил целевой узел, то для выполнения вызова на заданном объекте выбирается вычислительный сервер. Если выбранный сервер отличается от того, где находится поток в настоящее время, то производится RPC (прим. пер. — удаленный вызов процедур") к месту назначения, запрашивая его для выполнения вызова. Менеджер объектов пользователя на вычислительном сервере создает виртуальное пространство объекта — O Space", если он еще не существует. Это может быть сделано с помощью сегмента дескриптора виртуального пространства объекта, хранящегося на сервере данных. Он добавляет пространство P Space", содержащее стек вызова потока, скопированный с вызывающего компьютера, и область передачи параметров. Менеджер потоков — системный объект, который записывает сведения о потоках по мере их выполнения в распределенной системе, уведомляется о новом местоположении потока. Менеджер потоков также хранит информацию о рабочей станции, с которой был запущен поток, и об окнах на этой рабочей станции, на которые должен быть направлен вывод потока.

После того как установлено адресное пространство объекта на вычислительном сервере (compute server), диспетчер объектов пользователя ищет соответствующую точку входа в объекте и создает isiba для выполнения из этого адреса. По мере выполнения isiba метода, отсутствующие страницы памяти уже не являются внешними — они уже принесены от сервера данных (data server).

Резюме и обсуждения

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

Архитектура системы Clouds состоит из: рабочих станций для пользователей (user workstation); серверов данных (data server) для хранения кода и сегментов данных, из которых состоят объекты, и вычислительных серверов (compute server), выполняющих методы объектов. Балансировка нагрузки выполняется автоматически на вычислительных серверах по мере выполнения вызовов. Поскольку потоки могут выполняться в пределах одного объекта на вычислительных серверах, не имеющих общего доступа к физической памяти, требуется абстрактная распределенной общей память (distributed shared memory — DSM), и поддержка этого допускается в виде объектов клиента и сервера DSM, которые можно настроить для исполнения в адресном пространстве микроядра Ra. Все службы высокого уровня в Clouds (включая сетевое взаимодействие) предоставляются рабочими станциями UNIX и объектами системы Ra.

Все функции Clouds, которые мы упомянули были реализованы на компьютерах Sun 3/50 и Sun 3/60. Нулевые значения времени вызова были измерены от 8 миллисекунд до 103 миллисекунд, в зависимости от того, находились ли данные вызванного объекта в памяти или требовали транспортировки с сервера данных [Dasgupta et al. 1991].

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

Механизм вызова Clouds на основе DSM принадлежит одной из трех основных моделей, два из которых являются вызовами на основе RPC и прокси-серверами. В вызове на основе RPC объекты реализуются в средах выполнения, таких как задачи Mach. Инициатор выполняет удаленный вызов процедуры к порту, представляющему целевой объект. Поток в среде выполнения узла целевого объекта выполняет метод и возвращает все результаты. Путем переноса порта объекта, сам объект может быть прозрачно перенесен между средами выполнения. Система COOL, построенная на базе ядра Chorus, иногда использует этот стиль вызова и иногда использует методы распределенной общей памяти, аналогичные Clouds. COOL выбирает механизм в соответствии соображениям эффективности.

В третьем стиле реализации вызовов, основанном на так называемых прокси, объекты снова реализуются за портами в средах выполнения. Однако, когда вызов выполнен на удаленном объекте, вызов выполнен прозрачно сначала к локальному объекту, названному прокси [Shapiro 1986]. Прокси-сервер может пересылать идентификатор вызова и параметры в сообщении на порт удаленного объекта. Но, так как прокси является объектом, он может также использовать специализированные методы для реализации вызова. Например, это могло удовлетворить вызову с данными, кэшированными локально. Или, в качестве другого примера, это может быть многоадресная рассылка сообщения вызова коллекции удаленных объектов в схеме, которая использует репликацию объектов для достижения высокой доступности. Сравнение этих трех методов дается Blair и Lea [1992].

В приведенном нами кратком описании Clouds отсутствуют некоторые примечательные особенности, необходимые для построения полной поддержки распределенных объектов в целом. Некоторые из этих особенностей изучаются проектом Clouds. К ним относятся: алгоритмы расположения объектов; сборка мусора; динамическая загрузка постоянных объектов в существующие среды выполнения; политики миграции объектов для балансировки нагрузки и сокращения сетевого трафика; а также подробные сведения о DSM реализации и ее взаимодействие с механизмами управления параллелизмом, такими как блокировки. Для получения дополнительной информации о системной поддержке распределенных объектов читатель может обратиться к COOL [Lea et al. 1993], SOR [Shapiro 1989], Emerald [Jul et al. 1988] и Amber [Chase et al. 1989].

References

1. [Blair and Lea 1992] Blair, G.S. and Lea, R. (1992). The Impact of Distribution on the Object-Oriented Approach to Software Development, IEE/BCS Software Engineering Journal, vol. 7, no. 2.
2. [Chaseet al. 1989] Chase, J.S., Amador, F.G., Lazowska, E.D., Levy, H.M. and Littlefield, R.J. (1989). The Amber System: Parallel Programming on a Network of Multiprocessors. Proc. 12th. ACM Sym. on Operating System Principles, pp. 147-58, December.
3. [Meyer 1988] Meyer, B. (1988). Object-Oriented Software Construction. Englewood Cliffs NJ: Prentice-Hall.
4. [Shapiro 1986] Shapiro, M. (1986). Structure and encapsulation in distributed systems: the proxy principle. Proc. 6th IEEE Int. Conf. on Distributed Computing Systems, Cambridge MA, pp.198–204.
5. [Shapiro 1989] Shapiro, M. and Gautron, P. (1989). Persistence and migration for C++ Objects. Proc. Third European Conference on Object-Oriented Programming, Nottingham, pp. 191–203.
6. [Stroustrup 1986] Stroustrup, B. (1986). The C++ Programming Language. Reading MA: Addison-Wesley.