Режим отладки имеет место при компиляции Т-программ с опцией t++ -dbg. При этом исполняемый модуль компонуется с объектным модулем trtdbg.o, включающем в себя информацию о символах приложения, дополнительный анализ состояния и условный код визуализации событий.

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

Визуализация транспортных сообщений. При запуске Т-программы с опцией -tct showMsgs происходит распечатка активных сообщений, пересылаемых по системной сети.

Визуализация исполнения Т++ приложений. Одним из дополнительных модулей OpenTS является модуль сбора трассы исполнения Т-приложений. Он активизируется при запуске Т-приложения с опцией –tct enableTrace и позволяет собрать различные количественные характеристики исполнения этого приложения. Разработан графический интерфейс для пошаговой визуализации этой трассы, который, помимо наглядного представления работы программы, помогает разработчику при отладке как Т-программ, так и всей системы в целом.

Использование специальных отладчиков для MPI-программ. Разработана программная система отладки MPI-программ TDB, которая обладает широкими возможностями для управления процессом отладки и всестороннего анализа состояния программы во время исполнения.

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

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

При исключительной ситуации, возникающей в Т-программе, происходит запуск встроенного crash dump analizer'а. При этом распечатывается стек вызовов и параметры вызванных функций.

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

Опции (ключи командной строки), воспринимаемые ядром Т-системы, начинаются со строки '-tct' и должны следовать непосредственно за именем исполняемого файла задачи.

В настоящий момент поддерживаются следующие опции:

Существенной частью системы OpenTS является ее развитое окружение — набор различных программных средств (расширений и полезных дополнений), позволяющих облегчить путь от начала написания программы до получения высококачественного программного продукта. В частности, система интерактивной отладки MPI-программ TDB (T++ Debugger) обеспечила возможность снизить трудозатраты на одном из важнейших и наиболее трудоемких этапов реализации параллельных приложений — этапе отладки. При этом следует отметить тот факт, что, хотя TDB и создавалась специально с целью отладки Т++ приложений, она все же является универсальной, и ничто не препятствует ее использованию при создании самых различных MPI-программ.

Заметим, что на этапе проектирования системы учитывался опыт других подобных разработок [3-5]. Важной особенностью, отличающей TDB от других интерактивных параллельных отладчиков [4,5], является ее открытость. Это свойство системы, помимо многих других преимуществ, которые будут рассмотрены далее, позволяет обеспечить существенную экономию финансовых средств по сравнению с коммерческими аналогами.

При проектировании TDB на выбор архитектурных принципов, использованных для построения всего программного комплекса, оказывали влияние следующие основные факторы:

С учетом приведенных факторов и опыта других исследований [3] были сформулированы основные архитектурные принципы, легшие в основу реализации TDB. В соответствии с ними, архитектура TDB обладает следующими особенностями:

Компоненты TDB (см. рис.1) делятся на две группы: компоненты, функционирующие на фронтальной ЭВМ и компоненты, функционирующие на вычислительных узлах. К первой группе относятся первичный демон, центральный сервер и клиентский компонент, ко второй — вторичный демон, сервер отладки и библиотечный компонент.

Рис. 1. Архитектура TDB

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

Все остальные компоненты TDB не являются постоянно функционирующими процессами и запускаются клиентским компонентом системы или непосредственно пользователем в процессе проведения сеанса отладки конкретного MPI-приложения.

Центральный сервер TDB обеспечивает взаимодействие клиентского компонента с остальными компонентами TDB — исполняя, в частности, роль программного мультиплексора пакетов TDB-протокола. Использование центрального сервера в качестве отдельного компонента системы позволило в значительной степени повысить степень открытости всей системы, облегчить создание различных реализаций клиента.

В контексте расширенной модели «клиент-сервер», реализуемой в TDB, центральный сервер выступает в роли сервера для клиентского компонента, и в роли клиента для других компонентов (первичного демона и серверов отладки).

Библиотечный компонент предназначен для инициализации подключения процессов отлаживаемого MPI-приложения (в т.ч. Т++ приложения) к TDB на начальной стадии сессии отладки. С этой целью библиотечный компонент подменяет ряд функций, стандартных для параллельных приложений такого типа, на специальные, которые:

TDB поддерживает различные реализации MPI и имеет в своем составе набор соответствующих библиотек. Подходящий экземпляр библиотечного компонента вклю­ча­ется в состав исполняемого файла MPI-приложения на этапе редактирования связей.

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

Запуск сервера отладки производится из пользовательского MPI-приложения в процессе выполнении им специальных функций библиотечного компонента.

Рис. 2. Подробная иллюстрация архитектуры компонентов сервера отладки и механизма присоединения процесса к серверу отладки

Для управления отлаживаемыми процессами сервер отладки (см. рис. 2) имеет набор специальных программных объектов — экземпляров отладчиков, управляющих работой базовых системных отладчиков (например, GNU GDB). Таким образом, процессу отлаживаемого приложения в сервере отладки соответствует пара «экземпляр отладчика сервера отладки — системный отладчик», которая занимается непосредственным управлением отладкой данного процесса, интерпретируя и выполняя команды, поступающие от клиента через центральный сервер.

Набор процессов MPI-приложения, присоединенных к одному серверу отладки, образует MPI-узел. Наряду с персональными командами над конкретными процессами сервер отладки способен производить и групповые операции над предопределенными группами процессов MPI-узла, поддерживая, таким образом, парадигму групп и групповых команд TDB.

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

На основных этапах сеанса отладки клиент выполняет следующие функции: подготавливает среду выполнения отлаживаемого MPI-приложения, запускает задачу на исполнение в режиме отладки; управляет процессом интерактивной отладки MPI-приложения в целом и, наконец, производит завершение процесса отладки.

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

Очевидно, что клиентский компонент, способный обеспечить эффективность процесса интерактивной отладки параллельного приложения, должен:

Рис. 3. Интерфейс GTDB. Иллюстрация сеанса отладки.

Текущая реализация TDB включает в себя полноценный графический клиентский компонент — GTDB (см. рис. 3), удовлетворяющий всем этим требованиям и имеющий набор базовых компонентов, каждый из которых ответственен за выполнение отдельной группы функций:

GTDB разработан таким образом, чтобы быть наиболее приближенным к набору команд системного отладчика GDB. Семантика, набор параметров и формат ответных сообщений стандартных команд отладчика, как правило, идентичны семантике, параметрам и сообщениям аналогичных команд отладчика GDB.

Клиент TDB имеет также ряд характерных отличий, обусловленных спецификой TDB как распределенного отладчика. Среди особенностей можно выделить: групповые команды, команды для настройки среды MPI, команды формирования, редактирования и просмотра списка вычислительных узлов, пригодных для запуска отлаживаемой задачи, а также команды, использующиеся при отладке специальных параллельных приложений, например, Т++ приложений [1,2].

TDB поддерживает различные реализации MPI. Для сборки приложения в список использумых библиотек необходимо включить версию библиотеки libtdb_mpi, соответствующую используемой реализации MPI.

Пример сборки MPI-приложения (MPI-реализация — SCALI MPI):

# gcc -g -O0 hello-world.c -o hello-world -ltdb_mpi_scali -L/opt/scali/lib –lmpi

Ниже описываются основные функции GTDB на различных этапах сеанса отладки и соответствующие возможности, предоставляемые пользователю.

Съем характеристик выполнения приложения в среде OpenTS осуществляется запуском Т-приложения с опцией “-tct enableTrace”. Трасса сохраняется в файл, у которого имя совпадает с именем файла Т-приложения. Характеристики снимаются каждую 1/25 секунды на каждом вычислительном узле, но формирование трассы производится на одном из них, а именно на том, на котором программа была запущена на выполнение — на корневом вычислительном узле. Для передачи характеристик со всех узлов на корневой узел используются MPI-сообщения. На корневом узле сообщение принимается и передается функции фиксации трассы.

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

При выполнении параллельной программы в среде OpenTS Т-задача меняет свое состояние от «пренатального» до «завершенного». Возможные состояния Т-задачи и возможный порядок их изменения приведен на рис. 7.

Рис. 7. Состояния Т-задач

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

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

В процессе выполнения параллельной программы определяются и вычисляются следующие характеристики вычислительного узла:

При выполнении программы в среде OpenTS вычисляются следующие временные характеристики:

Для хранения и передачи трассы выполнения Т-программы графическому визуализатору, разработан формат представления трассы в виде XML.

Заголовок XML-представления трассы содержит информацию о количестве вычислительных узлов, командной строке запуска программы и времени запуска. Например:

<trace ranks="4" cmd="fib 10" time="27.04.2006 15:58">

Каждую 1/25 секунды формируется временной срез трассы — кадр состояния, который содержит номер и время среза, а также детальную информацию по каждому вычислительному узлу. Например:

<slice num="3" time="0.143853">
<rank num="0">
<resource mbytes="0" mflops="0" tasks="0.003538" idle="0.006406" sched="0.003083" mpi="0.002429" />
<task type="X" count="16" />
<detail count="1" to="1" />
</task>
<message sbytes="2536" scount="27" rbytes="1352" rcount="21">
<extra type="ctrl" sbytes="2536" scount="27" rbytes="1352" rcount="21" />
</message>
</rank>
</slice>

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

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

Т-визуализатор реализован с использованием «GTK+» — мультиплатформенного инструментария для создания графических приложений, и является полностью переносимым продуктом, работающим как под управлением как ОС Linux, так и ОС Windows, как на платформах i386 (x86, ia32), так и на платформах x86_64 (AMD64, EM64T).

Исходными данными для работы Т-визуализатора являются данные трассы выполнения Т-приложения. Сбор трассы осуществляется непосредственно в процессе выполнения Т-приложения и производится с использованием специальных механизмов OpenTS — расширения сбора трассы и визуализации.

Данные трассы оформляются в виде XML-документа определенной структуры, которая была описана выше.

Реализованы различные режимы работы Т-визуализатора с данными трассы выполнения Т-приложения:

Реализован следующий набор опций запуска Т-визуализатора из командной строки:

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

Ярко-красным цветом выделяются сообщения о фатальных ошибках, таких как сбой подсистемы коммуникаций, исчерпание лимита памяти или суперпамяти, перекрытие допустимых границ стека суперпотока и т. д.

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

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

Краткое описание реализации DMPIнад протоколом TCP/IP

DMPI TCP/IP реализует функциональность подмножества стандарта MPI 2.0 над протоколом TCP/IP.

Реализованы функции MPI_Init, MPI_Error_string, MPI_Barrier, MPI_Comm_rank, MPI_Comm_size, MPI_Finalize, MPI_Get_count, MPI_Iprobe, MPI_Recv, MPI_Send, MPI_Isend, MPI_Test, MPI_Wait, MPI_Wtime.

Рассмотрим TCP/IP реализации некоторых из них.

MPI_ISend() — асинхронная посылка сообщений — создает заголовок сообщения и затем инициирует постановку сообщения либо в очередь своих личных сообщений, если получатель есть этот же узел, либо в очередь отправляемых сообщений и вызов функции do_send(), если сокет свободен. Функция do_send() циклически вызывает библиотечную функцию write() для записи в сокет сообщения из очереди отправляемых сообщений.

MPI_IRecv() — асинхронный прием сообщений — создает заголовок сообщения и затем инициирует вызов функции получение сообщения из очереди своих личных сообщений, если получатель есть этот же узел, либо из очереди получаемых сообщений посредством вызова функции do_recv(), если сокет свободен. Функция do_recv() вызывает библиотечную функцию read() для чтения из сокета сообщения в очередь принимаемых сообщений.

MPI_Send() — работа этой функции аналогична последовательности вызовов MPI_ISend() и MPI_Wait().

MPI_Recv() — работа этой функции аналогична последовательности вызовов MPI_IRecv() и MPI_Wait().

MPI_Wait() — контроль отправки или приема сообщения из очереди отправляемых в очередь принимаемых сообщений.

MPI_Finalize() — закрытие всех сокетов.

Ключевой вопрос для каждой системной компоненты — как она будет выглядеть со стороны его использования.

Отказоустойчивый DMPI, как и обычный DMPI, в основном используется другим, более высокоуровневым системным ПО, таким как ядро Т-системы, поэтому от него не обязательно требовать каких-то особенных свойств, характерных для компонент, видимых прикладному программисту. Тем не менее, чем ближе он будет по способу использования к привычным MPI/DMPI, тем менее обременительным будет его использование.

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

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

В первой версии DMPI имеет смысл ограничиться каким-нибудь наиболее простым и безусловно отказоустойчивым транспортным уровнем. Примером такого транспорта является TCP/IP, изначально созданный для работы в условиях сбоев коммуникационного оборудования, и обладающий логикой надежной доставки сообщений.

Безусловно, использование TCP/IP в качестве базового уровня для реализации MPI-взаимодействия может внести некоторые накладные расходы при использовании внутри тесносвязанных кластеров. Однако для нас сейчас важнее уверенность в безукоризненной отказоустойчивости базового уровня коммуникаций; кроме того, уже начиная с небольших метакластерных установок, накладные расходы, вносимые уровнем TCP/IP, не будут такими уж существенными хотя бы потому, что сами кластерные установки обычно связаны именно по этому протоколу.

Изучение открытых ресурсов показало, что существует простая, но достаточно эффективная надстройка над протоколом TCP/IP, реализующая наиболее часто употребимые функции библиотеки MPI — MP_Lite. Была проведена рефакторизация исходного кода, выделен ряд процедур, на базе которых реализован драйвер DMPI_TCP.

Общее описание программного интерфейса отказоустойчивого DMPI

В виду вышеизложенных причин, API отказоустойчивого DMPI отличается наличием функции установки обработчика обнаруженных сбоев — dmpiSetConfHandler().

Единственный аргумент, который принимает данная функция — адрес процедуры-обработчика изменения «состояния» вычислительного узла (под состоянием понимается, прежде всего, общий статус работоспособности узла; предполагается, что узлы могут не только выходить из работоспособного состояния, но и возвращаться в него).

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

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

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

Доработка DMPI состоит в том, что попытка запуска приложения на каждом узле производится не однократно, а многократно, то есть в случае сбоя/перезапуска узла возникает новая «реинкарнация» вычислительного процесса, который готов продолжить работу.

Доработка кода функций DMPI состоит в корректной обработке возможных ошибок уровня сокетов TCP/IP и передаче статуса этих ошибок в функцию-обработчик сбоев.

В том случае, если функция-обработчик не установлена, предполагается, что следует вызывать функцию-обработчик, существующую в системе по умолчанию. В случае вызова при возобновлении работоспособности узла данная функция печатает соответствующее сообщение на консоль оператора; в случае сбоя любого узла производится печать его номера и аварийное завершение вычислительного процесса.

Коллективные коммуникации доработаны до корректного функционирования при условии возникновения сбоев.

Как и в случае с DMPI, сначала рассмотрим желаемый интерфейс отказоустойчивой Т-системы с точки зрения использования. Таковой является точка зрения прикладного программиста, который реализует логику параллельной программы.

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

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

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

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

Мы будем предполагать, что прикладная программа написана в функциональном стиле, и в случае его расширения прикладной программист так же точно отвечает за отказоустойчивость своей программы при использовании отказоустойчивой OpenTS, как и за простые корректность и детерминированность результатов счета в случае обычной Т-системы.

С точки зрения прикладного программиста наиболее существенное новшество Т-системы (языка T++) по сравнению с базовым языком (C++) состоит в поддержке Т-функций и неготовых значений.

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

Для того чтобы у прикладного программиста появилась возможность самостоятельно принимать решение об обработке сбоев, диаграмма состояний неготового значения была дополнена еще одним состоянием — «незавершенное». Это состояние является альтернативой готовому состоянию и отличается от него следующими ключевыми свойствами:

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

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

В Т-системе вычисление каждого неготового значения может быть соотнесено с транзакцией. Иерархии вызовов Т-функций соответствует иерархия транзакций (в модели с субтранзакциями).

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

В виду того, что высокопроизводительные комплексы представляют собой топологически сложные образования, уточним, что мы относим сбой коммуникаций к сбою тех узлов, которые оказываются изолированы друг от друга этим сбоем. Иными словами, при выпадении ребра из графа связности мы выкидываем и вершину (в случае транспорта TCP/IP и сети Ethernet это одно и то же).

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

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

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

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

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

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

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

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

Если ограничить значение счетчика перерождений некой разумной величиной (например, типом данных int), то можно хранить вектор перерождений в массиве байт (каждый элемент содержит 31 бит на порядковый номер и 1 бит на текущий статус работоспособности).

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

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

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

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

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

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

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

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

К счастью, это усложнение во многих случаях может не потребоваться по очевидным причинам.

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

Определение статуса узла (работает/не работает, время когда загрузился, счетчик реинкарнаций и т. д.). Вектор перерождений представлен в виде массива структур NodeConf.

struct NodeId {
  int  ipAddr;
  struct timeval tv;
  int  pid;
};

struct NodeConf {
  struct NodeId id;
  int reinc;
};

struct GblConf {
  int alive; 
  int minAlive;
  int maxRank;
  int generation;
};

Атрибут Т-функции, содержащий номера узлов, которые посетила Т-функция, и от непрерываемой работоспособности которых напрямую зависит востребованность ее результата.

VMware Player — это свободно распространяемый программный продукт компании VMware для развертывания виртуальных машин. Рассмотрим процесс установки программного обеспечения VMware Player на ОС Windows.

Для установки VMware Player с официального сайта VMware можно воспользоваться страницей http://www.vmware.com/download/player/. Прежде чем удастся начать установку потребуется заполнить регистрационную форму.

Процесс установки VMware Player традиционен для программ семейства Windows и не требует дополнительных пояснений. По окончании установки VMware Player может потребоваться перезагрузка компьютера.

В процессе установки VMware Player будет также установлен виртуальный сетевой адаптер VMware Network Adapter VMnet1. Его настройка производится автоматически.

Виртуальное приложение OpenTS_VM сконфигурировано таким образом, чтобы иметь возможность обращения к удаленным компьютерам из ВМ (DHCP). Для этого убедитесь, что в сетевых настройках ВМ выбран режим NAT (рис. 1)

Рисунок 1: консоль OpenTS_VM

Это оптимальный режим сетевого взаимодействия. В этом случае ВМ выходит во внешнюю сеть под IP-адресом физического компьютера.

При необходимости обеспечения доступа к виртуальной машине из внешнего мира, можно воспользоваться механизмом Port Forwarding. Настройка Port Forwarding не является обязательным условием для работы с OpenTS_VM, однако, в некоторых случаях эта функциональность может быть полезна. Для этого необходимо воспользоваться утилитой vmnetcfg.exe, входящей в состав VMware Player.

В программе vmnetcfg.exe во вкладке Summary убедитесь, какая виртуальная сеть используется для организации NAT соединения с ВМ (рис. 2). В этом примере для этих используется виртуальная сеть VMnet8.

Перейдите во вкладку NAT, выберите соответствующую виртуальную сеть в выпадающем списке VMnet host и нажмите Edit (рис. 3)

Рисунок 2: виртуальные сетевые интерфейсы

Рисунок 3: настройки виртуальной сети

В появившемся диалоговом окне нажмите кнопку «Port Forwarding…». В диалоговом окне Port Forwarding добавьте нужное правило маршрутизации (рис. 4)

Рисунок 4: правила маршрутизации

Так, например, с помощью изображенного на рисунке 4 правила, организуется передача входящего TCP-трафика с порта 50022 хост-компьютера на порт 22 ВМ. IP-адрес виртуальной машины, на который будет передаваться трафик, может отличаться от приведенного в примере. Для того, чтобы выяснить IP-адрес виртуальной машины, запустите виртуальную машину и выполните команду /sbin/ifconfig. IP-адрес виртуальной машины будет указан в поле inet addr напротив поля eth0. Например:

$> /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:48:88:A3:15
 inet addr:192.168.10.100  Bcast:192.168.10.255  Mask:255.255.255.0
 inet6 addr: fe80::230:48ff:fe88:a315/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:11617836 errors:0 dropped:0 overruns:0 frame:0
 TX packets:2450389 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:5895059859 (5.4 GiB)  TX bytes:2188753634 (2.0 GiB)
 Base address:0x2020 Memory:c8220000-c8240000

В этом примере IP-адрес виртуальной машины – 192.168.10.100

Для работы с OpenTS_VM на VMware Player необходимо загрузить образ ВМ с сайта: http://www.opents.net/download/OpenTS_VM_20100603.tar.bz2. Архив содержит следующие файлы:

Для запуска виртуальной машины запустите VMware Player в главном меню выберите пункт Open. В диалоговом окне укажите путь к f9.vmx, после чего начнется загрузка виртуального компьютера.

Для ввода команд в консоль ВМ можно нажать Ctrl+G или кликнуть мышью в любой части консоли. Чтобы вернуться к обычному управлению окнами, нажмите Ctrl+Alt.

QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ.

В состав QEMU входят эмуляторы Intel x86, устройства ввода-вывода. Может также эмулировать 386, 486, Pentium, Pentium Pro, AMD64 и другие x86-совместимые процессоры.

Для установки QEMU, используйте инсталлятор с сайта http://www.h7.dion.ne.jp/~qemu-win/ (в разделе Accelerators. На момент составления документа последняя версия инсталлятора — 0.9.0). Процесс установки типичен для ОС Windows и не нуждается в пояснениях.

Для улучшения производительности ВМ QEMU рекомендуется использоваться акселератор KQEMU. Для установки KQEMU используйте инсталлятор с сайта http://www.h7.dion.ne.jp/~qemu-win/ (в разделе Accelerators. На момент составления документа последняя версия акселератора — 1.3.0pre11). В процессе установки программа зарегистрирует службу kqemu driver и сконфигурирует ее для автоматического запуска.

Настройка сетевого интерфейса ВМ не требуется. Виртуальная машина QEMU может быть запущена в специальном пользовательском сетевом режиме (user mode network) с поддержкой NAT.

В QEMU присутствует возможность аналогичная Port Forwarding в VMware Player. Для этого используется опция -redir. Так, например, если вам необходимо организовать передачу трафика с 50022 порта хост-компьютера на 22 порт виртуальной машины используйте следующее значение для опции -redir:

-redir tcp:50022:10.0.2.15:22

В случае если вам необходимо перенаправлять значительное число портов, удобнее настроить QEMU на использование виртуального сетевого адаптера TAP-Win32.

В QEMU имеется возможность передачи файлов с физического компьютера на виртуальную машину с использованием механизма tftp (однако, для этого tftp должен быть установлен в виртуальной машине). Для этого к строке запуска QEMU следует добавить опцию -tftp и указать путь к каталогу, содержащему файлы, которые нужно передать на виртуальную машину. Например, для того, чтобы передать файл C:\test\test.txt, запустите qemu с параметром -tftp /test. Затем в ВМ выполните следующие команды:

$ tftp 10.0.2.2
$ tftp>binary
$ tftp>get /test /test.txt

У этого способа передачи файлов есть ряд ограничений. Так, передаваемый файл не должен превышать по размеру 32 мегабайта. Нет возможности передавать файлы с дисков, кроме C. Нельзя передавать файлы с виртуальной машины на физический компьютер.

Перед запуском виртуального приложения OpenTS_VM загрузите образ,  как описано в пункте 2.1.3. Для запуска виртуальной машины переместите файл с образом OpenTS_VM f9.vmdk в каталог установки qemu и выполните команду:

qemu.exe -m 512 -kernel-kqemu -L pc-bios -net nic -net user -hda f9.vmdk

Эта команда предписывает QEMU использовать 512 мегабайт оперативной памяти физического компьютера для нужд виртуальной машины, использовать акселератор kqemu и организовать сеть в пользовательском режиме.

Для ввода команд в консоль ВМ можно нажать Ctrl+G или кликнуть мышью в любой части консоли. Чтобы вернуться к обычному управлению окнами, нажмите Ctrl+Alt.

Для работы с виртуальными машинами на ОС Linux можно использовать бесплатную версию VMware Player для Linux. Для этого загрузите соответствующий дистрибутив с сайта http://www.vmware.com/download/player/. Вам необходимо будет заполнить регистрационную форму и выбрать дистрибутив в соответствии с используемой аппаратной платформой (32 или 64 разрядной). VMware Player для Linux распространяется в виде tar-архива или в виде rpm-пакета. Оба дистрибутива предоставляют эквивалентную функциональность. Для установки VMware Player выполните следующую последовательность действий:

Для удаления vmware-player вам также понадобятся права суперпользователя.

Конфигурационный файл NAT сервера для VMware Player находится в /etc/vmware/vmnet8/nat/nat.conf. Конфигурационный файл состоит из секций, таких, как, например [host], которые отвечают за различные сетевые настройки. Аналогично Windows версии VMware Player, в Linux версии можно настроить передачу сетевого трафика с некоторого порта хост-компьютера на порт виртуальной машины. Для этого необходимо внести изменения в секциях [incomingtcp] или [incomingudp]. Например, для передачи данных с порта 50022 хост-компьютера по протоколу TCP на порт 22 виртуальной машины добавьте в секции [incomingtcp] следующую строку:

50022 = <IP-адрес виртуальной машины>:22

IP-адрес ВМ назначается динамически, с помощью встроенного в VMware Player DHCP сервера. Текущий IP-адрес ВМ можно выяснить с помощью команды /sbin/ifconfig, как описано в пункте 2.1.2

Перед запуском виртуального приложения OpenTS_VM загрузите архив с образом файловой системы по приведенной в пункте 2.1.3 ссылке и разархивируйте его в нужную папку. Для работы с VMware Player на Linux используется графический интерфейс, аналогичный версии для Windows. Для запуска VMware Player выполните команду:

$> vmplayer

В появившемся окне нажмите кнопку Open и укажите путь к конфигурационному файлу OpenTS_VM, после чего начнется загрузка виртуального приложения.

Для ввода команд в консоль ВМ можно нажать Ctrl+G или кликнуть мышью в любой части консоли. Чтобы вернуться к обычному управлению окнами, нажмите Ctrl+Alt.

Гипервизор QEMU также доступен для свободного использования на ОС Linux. Для работы с QEMU потребуется предварительная сборка гипервизора из исходных файлов. Выполните следующую последовательность действий:

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

Для организации доступа виртуальной машины QEMU к внешним сетевым ресурсам целесообразно использовать пользовательский сетевой режим (user network mode, опции -net nic и -net user). Настройка переадресации портов хост-компьютера на порты виртуальной машины производится аналогично версии QEMU для Windows через опцию -redir (см. пукнт 2.2.2).

В Linux версии QEMU можно также использовать встроенный в QEMU ftp сервер для передачи файлов с хост-компьютера на виртуальную машину. Для этого используйте механизм, изложенный в пункте 2.2.3. При этом в версии QEMU для Linux не действует ограничение на диск-источник, с которого производится передача файлов. Однако остальные ограничения остаются в силе.

Перед запуском виртуального приложения OpenTS_VM загрузите образ, как описано в пункте 2.1.3. Для запуска виртуального приложения OpenTS_VM используйте команду:

qemu.exe -m 512 -kernel-kqemu -net nic -net user -hda f9.vmdk

Эта команда предписывает QEMU использовать 512 мегабайт оперативной памяти физического компьютера для нужд виртуальной машины, использовать акселератор kqemu, и организовать сеть в пользовательском режиме.

Для ввода команд в консоль ВМ можно нажать Ctrl+G или кликнуть мышью в любой части консоли. Чтобы вернуться к обычному управлению окнами, нажмите Ctrl+Alt.