Google:
Помощь

OpenTS. Руководство системного программиста

Содержание

1. Назначение программы
2. Структура программы
2.1. Микроядро и его расширения
2.2. Модульная структура расширений
3. Настройка программы
3.1. Установка и конфигурирование Т-системы
3.2. Проверка программы. Запуск тестовых примеров
4. Дополнительные возможности
4.1. Использование расширений для трассировки и поддержки контрольных точек
4.2. Дополнительные возможности отладки системы программирования OpenTS
4.2.1. Общее описание возможностей по отладке Т-приложений
4.2.1.1. Специальные возможности режима отладки
4.2.1.2. Дополнительные возможности для отладки Т-приложений
4.2.1.3. Опции запуска
4.2.2. TDB — открытая распределенная программная система интерактивной отладки MPI-программ: архитектурные решения и общие принципы реализации
4.2.2.1. Введение
4.2.2.2. Основные архитектурные принципы
4.2.2.3. Компоненты TDB и их назначение
4.2.3. Средства визуализации процесса параллельного исполнения Т++ программ
4.2.3.1. Алгоритм трассировки
4.2.3.2. Трасса выполнения Т-приложения
4.2.3.3. Формат представления трассы
4.2.3.4. Т-визуализатор — графический пользовательский интерфейс системы визуализации трассы
4.2.3.5. Режимы работы Т-визуализатора. Механизмы обработки исходных данных
4.2.3.6. Компоненты Т-визуализатора
4.2.3.6.1. Компонент отображения статистических данных о состояниях Т-приложения.
4.2.3.6.2. Компонент схематического отображения статуса процессов Т-приложения.
4.2.3.6.3. Компонент управления просмотром трассы Т-приложения.
4.2.3.7. Опции Т-визуализатора
4.2.3.8. Цветовая схема
4.2.3.9. Сообщения о фатальных ошибках
4.2.3.10. Информационные сообщения
4.3. Поддержка отказоустойчивости исполнения Т-приложений в версии системы OpenTS для платформы Windows Compute Cluster Server
4.3.1. Краткая характеристика DMPI и OpenTS
4.3.2. Методы обеспечения отказоустойчивости
4.3.3. Архитектура ПО отказоустойчивого DMPI
4.3.3.1. Краткое описание реализации DMPI над протоколом TCP/IP
4.3.3.2. Программный интерфейс отказоустойчивого DMPI
4.3.3.3. Общее описание программного интерфейса отказоустойчивого DMPI
4.3.3.4. Доработка архитектуры DMPI
4.3.4. Архитектура отказоустойчивой версии OpenTS
4.3.4.1. Программный интерфейс отказоустойчивой Т-системы
4.3.4.2. Ограничения на стиль программирования
4.3.4.3. Неготовые значения и незавершенные по причине сбоя вычисления
4.3.4.4. Связь с транзакциями и субтранзакциями
4.3.4.5. Характер обрабатываемых сбоев
4.3.4.6. Откат незаконченных вычислений
4.3.5. Вектор перерождений
4.3.5.1. Определение и свойства вектора перерождений
4.3.5.2. Кодирование и передача вектора перерождений
4.3.6. Вектор посещений
4.3.6.1. Отказ от повторной миграции
4.3.7. Классы повреждений Т-функции в случае сбоя
4.3.7.1. Неповрежденные вычисления
4.3.7.2. Поврежденные вычисления
4.3.7.3. Полуповрежденные вычисления
4.3.8. Освобождение ресурсов в случае сбоя
4.3.8.1. Освобождение автоматических переменных и зависящих от них ресурсов
4.3.8.2. Освобождение весов распределенного сборщика мусора
4.3.9. Новые классы и сущности OpenTS
4.3.9.1. Класс Portal
4.3.9.2. Структуры NodeId/NodeConf/GblConf
4.3.9.3. Класс Visits (вектор посещений)
4.4. Виртуальная машина OpenTS_VM
4.4.1. Назначение OpenTS_VM
4.4.2. Установка и настройка VMware Player на ОС Windows
4.4.2.1. Установка VMware Player
4.4.2.2. Сетевые настройки VMware Player
4.4.2.3. Работа с VMware Player
4.4.3. Установка и настройка QEMU на ОС Windows
4.4.3.1. Установка QEMU
4.4.3.2. Сетевые настройки QEMU
4.4.3.3. Передача файлов на виртуальную машину QEMU
4.4.3.4. Работа с QEMU
4.4.4. Установка и настройка VMware Player на ОС Linux
4.4.4.1. Установка VMware Player
4.4.4.2. Сетевые настройки VMware Player
4.4.4.3. Работа с VMware Player
4.4.5. Установка и настройка QEMU на ОС Linux
4.4.5.1. Установка QEMU
4.4.5.2. Сетевые настройки QEMU
4.4.5.3. Передача файлов на виртуальную машину QEMU
4.4.5.4. Работа с QEMU
4.4.6. Использование OpenTS_VM
4.5. Поддержка работы Т-приложений в GRID-сетях
4.5.1. Поддержка подключаемых модулей планировщика
5. Сообщения системному программисту

1. Назначение программы

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

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

В то же время тела функций могут быть описаны в императивном стиле (на языках типа FORTRAN, C и т. п.). Важно только, чтобы:

  • всю информацию извне функция получала только через свои аргументы;

  • вся информация из функции передавалась только через явно описанные результаты.

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

2. Структура программы

2.1. Микроядро и его расширения

Т-система с открытой архитектурой конструктивно состоит из микроядра (Т- суперструктуры) и расширений. Расширения бывают внутрнние и внешние. Подключением внутренних расширений управляет файл tssconfig.h (входит в архив с исходными текстами Т-системы; исходные тексты микроядра располагаются в каталоге opentss).

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

В момент компиляции программы используются заголовочные файлы микроядра (txx и trt). В момент компоновки исполняемых модулей может происходит связывание с объектными модулями внешних расширений.

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

Установочный пакет представляет собой один файл OpenTS-*.rpm, который включает в микроядро, внешние расширения и конвертор t++.

При необходимости можно установить Т-систему с открытой архитектурой локально (в пользовательском каталоге). Для этого нужно раскрыть архив с исходными текстами, сконфигурировать их командой ./configure и выполнить сборку командой make.

2.2. Модульная структура расширений

На верхнем уровне все внешние расширения делятся на группы и подгруппы. В соответствии с каталогами (директориями в исходных текстах) имеются следующие внешние расширения:

  • grid — расширения для поддержки метакомпьютерных вычислений в GRID-сетях;

  • dmpi — динамическая реализация подмножества MPI. Позволяет запускать Т- приложения без их перекомпоновки с разными реализациями MPI-библиотеки и просто на SMP-компьютере;

  • debug/prof — расширения для поддержки профилирования Т-программ;

  • debug/ltdb — расширения для поддержки режима удаленной отладки Т-приложений с помощью gdb;

  • debug/trace — расширения для поддержки трассировки Т-программ (режимов записи и воспроизведения трассы);

  • debug/viz — расширения для поддержки визуализации процесса исполнения Т- программы;

  • debug/Wad — расширение для обработки исключительных ситуаций (печати стека фреймов вызванных функций и соответствующих номеров строк исходного кода);

  • extras/ckpt — расширение для поддержки контрольных точек;

Состав расширений может изменяться от версии к версии.

3. Настройка программы

3.1. Установка и конфигурирование Т-системы

Для использования ПО Т-система в принципе подходит любая программно-аппаратная платформа, удовлетворяющая следующим требованиям:

  1. SMP-компьютер, кластер или мета-кластер с процессорами одной из следующих архитектур:

    • Intel или AMD IA-32;

    • Intel или AMD x86-64;

    • PowerPC или PowerPC-64;

  2. ОС Linux, ядро не ниже 2.4.20 (лучше 2.6). Коммуникационная среда MPI одного из следующих видов:

    • LAM;

    • MPICH;

    • MP-MPICH;

    • SCALI;

    • MPICH-G2;

    • MPICH-GM;

    • PACX (MetaMPICH);

    • PVM;

    • MVAPICH.

К настоящему моменту система оттестирована на суперкомпьютерах семейства «СКИФ» со стандартным для этой платформы программным обеспечением. По вопросу эксплуатации на другом оборудовании следует обратиться к разработчикам по адресу opents@botik.ru

Для системной установки достаточно установить пакет openTS-*.rpm на фронтальной машине и всех узлах кластера.

3.2. Проверка программы. Запуск тестовых примеров

В состав исходных текстов Т-системы входит каталог testing/tests.

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

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

4. Дополнительные возможности

4.1. Использование расширений для трассировки и поддержки контрольных точек

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

Для поддержки режима контрольных точек необходимо использовать коммуникационную библиотеку LAM, собранную с поддержкой контрольных точек. Ниже описан порядок установки дополнительного пакета lam-ckpt.

Порядок установки пакетов:

  1. Собираются из blcr-0.2.3-1.src.rpm бинарные пакеты и инсталлируются их на фронтальную машину

    rpm -ihv blcr-0.2.3-1.i686.rpm blcr-libs-0.2.3-1.i686.rpm
    blcr-modules_2.4.20-0.2.3-1.i686.rpm

    и на узлы кластера

    all rpm -ihv blcr-0.2.3-1.i686.rpm blcr-libs-0.2.3-1.i686.rpm
    blcr-modules_2.4.20-0.2.3-1.i686.rpm
  2. Проверяется, что blcr модули загружены

    /etc/init.d/blcr status

    если получается сообщение "BLCR subsytem is not active", то загружаются модули

    /etc/init.d/blcr start
    all /etc/init.d/blcr start
  3. Собирается из lam-ckpt-7.0.6-1.src.rpm бинарный пакет и инсталлируется

    rpm -ihv lam-ckpt-7.0.6-1.i386.rpm
    all rpm -ihv lam-ckpt-7.0.6-1.i386.rpm

При компиляции программ с включенным механизмом контрольных точек используется опция -ckpt, например,

t++ -o fib fib.tcc -ckpt

Для включения механизма контрольных точек используется опция -tct ckpt=checkpoint:filename:intervalsec, например,

mpirun C -ssi rpi crtcp -ssi cr blcr ./ep -size 15 -depth 15 -tct ckpt=checkpoint:aaa:100

При правильной установке это должно вызывать сохранение контрольной точки каждые 100 с в файл с именем aaa.

Для повторного старта используется команда cr_restart filename, например,

cr_restart aaa

Пример использования режима трассировки:

/opt/scali/bin/mpirun -np 4 ./ep -size 10 -depth 10 -tct trace=record:aaa

Эта команда инициирует режим записи трассы в файл с именем aaa

/opt/scali/bin/mpirun -np 4 ./ep -size 10 -depth 10 -tct trace=play:aaa

Эта команда влечет за собой использование трассы с именем aaa.

4.2. Дополнительные возможности отладки системы программирования OpenTS

4.2.1. Общее описание возможностей по отладке Т-приложений

4.2.1.1. Специальные возможности режима отладки

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

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

4.2.1.2. Дополнительные возможности для отладки Т-приложений

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

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

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

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

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

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

4.2.1.3. Опции запуска

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

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

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

  • -tct 'DP(<regular-expression>)' — Указывает регулярное выражение-фильтр для режима отладки (опция компилятора -dbg);

  • -tct callGraph — заказ на визуализацию графа вызовов Т-функций;

  • -tct showMsgs — этот ключ включает вывод на экран информации обо всех пересылаемых по сети сообщениях;

  • -tct showFeatures — заказывает вывод на экран списка подключенных расширений микроядра;

  • -tct enableAsync — разрешает асинхронный режим работы суперпамяти;

  • -tct disableAsync — запрещает асинхронный режим работы суперпамяти;

  • -tct enableSMP — разрешает использование режима SMP;

  • -tct enableTrace — разрешает трассировку исполнения Т-приложения;

  • -tct ncpu=<N> — заказывает N системных потоков при SMP-режиме.

4.2.2. TDB — открытая распределенная программная система интерактивной отладки MPI-программ: архитектурные решения и общие принципы реализации

4.2.2.1. Введение

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

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

4.2.2.2. Основные архитектурные принципы

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

  • крайне важно было поддержать собственные — созданные в ИПС РАН — инструментальные средства разработки параллельных программ [1,2];

  • требовалось обеспечить совместимость TDB как с открытыми версиями MPI, свободно распространяемыми в виде исходных текстов, так и с коммерческими (например, SCALI MPI), тексты и детали реализации которых недоступны;

  • наличие на базовой аппаратно-программной платформе (GNU/Linux) широкого выбора свободного программного обеспечения с открытыми текстами позволяет использовать в TDB значительное число готовых компонент из состава свободного ПО;

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

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

  • распределенность и многокомпонентность. TDB состоит из набора компонентов, функционирующих на различных частях ПВС (как на фронтальной ЭВМ, так и на вычислительных узлах). Схема взаимодействия между компонентами соответствует расширенной модели «клиент-сервер».

  • открытость и переносимость. Одним из важнейших элементов архитектуры системы является «TDB-протокол» — набор соглашений, декларирующий интерфейс взаимодействия между собой различных компонентов TDB. Благодаря этому, существует возможность использовать разнообразные варианты реализации компонентов системы, при условии, что они поддерживают данный набор соглашений. Например, можно реализовать несколько различных клиентских компонентов (текстовых, графических и др.), набор серверов отладки, поддерживающих различные базовые отладчики (GDB, IDB, PGDBG и другие) или обеспечить поддержку нескольких систем распараллеливания программ. Как следствие, можно добиться переносимости системы даже в том случае, когда невозможно или нежелательно использование стандартных реализаций одного или нескольких компонентов. В этом случае их можно заменить специализированными реализациями, способными функционировать в специфических условиях (нестандартные аппаратные платформы, программные среды и т.д.).

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

  • многопользовательность, что обеспечивает бесконфликтность и безопасность процесса отладки при одновременном осуществлении отладки несколькими пользователями.

4.2.2.3. Компоненты 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), удовлетворяющий всем этим требованиям и имеющий набор базовых компонентов, каждый из которых ответственен за выполнение отдельной группы функций:

  • настройки свойств TDB, в том числе и поддерживаемых MPI реализаций;

  • выбора вычислительных узлов для запуска приложения;

  • отображения состояния MPI-узлов/процессов отлаживаемого приложения, с возможностью выбора любого из них для индивидуальной работы по интерактивной отладке;

  • интерактивной работы с процессом отлаживаемого приложения;

  • отображения сообщений TDB;

  • работы с точками останова;

  • ввода команд TDB.

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 на различных этапах сеанса отладки и соответствующие возможности, предоставляемые пользователю.

  1. Подготовка среды выполнения отлаживаемой задачи происходит с использованием графических компонентов: настройки свойств (см. рис. 4) и выбора узлов (см. рис. 5). Альтернативный способ подготовки среды выполнения — использование следующих CLI-команд: "shownodes", "getnodes", "addnode", "delnode", "printnodes", "set npn", "set args", "set mpi", "set mpiargs", "set runmode".

    Рис. 4. Компонент настройки свойств TDB

     

    Рис. 5. Компонент выбора вычислительных узлов

  2. Запуск задачи осуществляется коммандой "run".

  3. Управление процессом интерактивной отладки происходит либо с использованием компонентов и элементов графического пользовательского интерфейса (кнопки, всплывающие меню), либо при помощи CLI-комманд.

    В процессе интерактивной отладки действия можно выполнять как над отдельными процессами, так и над множеством групп процессов. Для формирования различных типов групп: статических (состав которых определен в момент создания) и динамических (состав которых пересчитывается в момент выполнения команды над группой) используются команды "sgroup" и "dgroup" соответственно.

    Наряду с ординарными командами, которые могут выполняться на группе процессов (next, print и др.), в TDB реализованы специальные групповые команды, аналоги "break", "watch", "display", позволяющие оперировать объектами, заданными на каждом из процессов группы (например, breakpoint) как с единым объектом (см. рис. 6).

    Клиент GTDB позволяет производить отладку MPI-приложений в двух режимах: основном и "по процессам". В первом (основном) режиме пользователю дается возможность работать с активным (выбранным) процессом или группой, во втором — работать с процессами приложения индивидуально (см. рис. 6).

    Рис. 6. Иллюстрация работы GTDB в режиме "Procs"

  4. Завершение процесса отладки осуществляется коммандой "quit".

4.2.3. Средства визуализации процесса параллельного исполнения Т++ программ

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

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

  1. Средство съема трассы и ее подготовки для последующего отображения в графическом визуализаторе.

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

4.2.3.1. Алгоритм трассировки

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

4.2.3.2. Трасса выполнения Т-приложения

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

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

 

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

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

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

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

  • количество свободной памяти, измеряемое в мегабайтах;

  • производительность вычислительного узла, измеренная в миллионах операций в секунду (MFLOPS).

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

  • суммарное время счета задачи;

  • суммарное время простоя задачи;

  • суммарное время работы планировщика;

  • суммарное время работы MPI-транспорта.

4.2.3.3. Формат представления трассы

Для хранения и передачи трассы выполнения Т-программы графическому визуализатору, разработан формат представления трассы в виде 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>
4.2.3.4. Т-визуализатор — графический пользовательский интерфейс системы визуализации трассы

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

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

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

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

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

4.2.3.5. Режимы работы Т-визуализатора. Механизмы обработки исходных данных

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

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

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

4.2.3.6. Компоненты Т-визуализатора
4.2.3.6.1. Компонент отображения статистических данных о состояниях Т-приложения.

Компонент предназначен для отображения различного рода информации о

состояниях Т-приложения в процессе выполнения, (см. рис. 8, нижняя часть).

Информация, отображаемая в статистическом компоненте, разделена на три группы:

  • группа «А» — информация по отдельному выбранному процессу.

  • группа «Б» — та же информация, что и в группе «А», но суммарная по всем процессам Т-приложения;

  • группа «В» — содержит неизменную информацию, информацию общего характера и информацию о состоянии Т-визуализатора.

Группы «А» и «Б» содержат следующую информацию о состояниях Т-приложения:

  • информацию о состоянии Т-функций:

    • o количество запущенных Т-функций;

    • o количество пренатальных Т-функций;

    • o количество экспортированных Т-функций;

    • o количество импортированных Т-функций;

    • o количество активных (выполняющихся в данный момент) Т-функций;

    • o количество приостановленных Т-функций;

    • o количество завершившихся Т-функций.

  • информацию о количестве переданных и полученных сообщений;

  • информацию о времени работы задачи в той или иной подсистеме OpenTS:

    • времени затраченном на выполнение непосредственно Т-функций;

    • o времени проведенном в планировщике;

    • o времени потраченном на передачу MPI-сообщений;

    • o прочее, отображается как время простоя.

Группа «В» содержит информацию:

  • об исследуемом Т-приложении, а именно:

    • названии Т-приложения и параметрах запуска;

    • времени старта Т-приложения;

    • количестве процессов;

    • объеме доступной памяти на момент старта Т-приложения;

    • приблизительной оценки вычислительной мощности используемой установки.

  • о трассе выполнения Т-приложения:

    • количестве срезов состояния исполнения;

    • текущем срезе;

    • времени, прошедшем с момента старта Т-приложения.

  • о типе стрелок компонента схематического отображения статуса процессов Т-приложения.

Рис. 8. Графический интерфейс системы визуализации

4.2.3.6.2. Компонент схематического отображения статуса процессов Т-приложения.

Компонент реализован с использованием векторной графической библиотеки «Cairo» из инструментария «GTK+».

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

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

Реализована возможность выбора одного из процессов, при этом в статистическом компоненте в подкомпоненте подробной информации по процессу (информация группы «А») будут отображаться данные именно по выбранному процессу.

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

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

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

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

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

Рис. 9. Иллюстрация миграции Т-задач. Пример информационной подсказки

4.2.3.6.3. Компонент управления просмотром трассы Т-приложения.

Компонент управления просмотром позволяет пользователю выбирать интересующий срез трассы для исследования.

Компонент реализован в интуитивно понятном, простом и привычном виде и

представляет собой набор графических примитивов — кнопок.

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

В наборе присутствуют:

  • кнопка «перемотка на начало» — переход на начальный срез трассы;

  • кнопка «предыдущий кадр» — переход на предыдущий срез;

  • кнопка «проиграть» — запустить режим проигрывания (автоматический переход от среза к срезу через заданный промежуток времени);

  • кнопка «пауза» — прервать процесс проигрывания;

  • кнопка «следующий кадр» — переход на следующий срез;

  • кнопка «перемотка на конец» — переход на последний срез.

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

4.2.3.7. Опции Т-визуализатора

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

  • -s, --play_speed=SEC — установить скорость проигрывания в сек/кадр. Например:

    • -s 0.5 — 2 кадра в секунду;

    • -s 0.04 — 25 кадров в секунду.

  • -f, --file=FILE — указать файл с XML-данными трассы.

  • -b, --sbars_style=ID — указать стиль элементов отображения статуса.

    • Возможные варианты: 0 или 1.

  • -a, --arcs_type=ARCTYPE — указать тип направленных дуг между процессами Т-приложения.

    • Возможные варианты: ('e', 'i', 'a', 'c', 'r', 'd', 'm' и 's').

  • --stream — использовать потоковый режим обработки данных трассы.

4.2.3.8. Цветовая схема

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

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

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

4.2.3.9. Сообщения о фатальных ошибках
  • “Regexp `%s' compilation failed!” — не удалось откомпилировать указанное регулярное выражение-фильтр для визуализации системных событий (в режиме отладки);

  • “Unknown TCT option %s !” — неизвестная опция командной строки (следует за ключом -tct), определяющей начальный Т-контекст времени исполнения;

  • “Internal feature failed” — одно из встроенных расширений ядра OpenTS не удалось инициализировать;

  • “Stack overflow” — недостаточно памяти для требуемого программой количества суперпотоков;

  • “Threads initialization failed” — ошибка на стадии инициализации подсистемы поддержки суперпотоков;

  • “Out of memory” — недостаточно памяти для программы;

  • “MPI_Error[%d != %d]: %.*s” — сбой подсистемы обмены сообщений MPI;

  • “No free MPI_Request (%d tries)” — недопустимая задержка в подсистеме коммуникаций;

  • ”Out of supermemory” — исчерпан лимит ячеек суперпамяти. Необходимо увеличить размер суперматрицы;

  • “Deadlock detected” — внутренняя ошибка синхронизации;

  • “Drop or freeze on uninitialized T-value.” — Т-функция не инициализировала один из своих выходных аргументов.

4.2.3.10. Информационные сообщения

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

  • “MemoryLeak: ...” — в программе осталась неосвобожденная память в момент завершения;

  • “main result is ready and %d TFuns are still working. Memory leaks are possible” — в момент завершения головной функции tfun main остались работающие Т-функции;

  • “Leaked cell %x,%lld with data %s (%d bytes)” — в программе осталась неосвобожденная суперпамять в момент завершения;

  • “local memo works” — началось повторное использование результатов мемо-функций на одном узле;

  • “global memo works” — началось повторное использование результатов мемо-функций, вычисляющихся на других узлах.

4.3. Поддержка отказоустойчивости исполнения Т-приложений в версии системы OpenTS для платформы Windows Compute Cluster Server

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

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

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

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

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

  • доработанная в части отказоустойчивости реализация наиболее употребимого подмножества функций MPI — DMPI — пополненная функциями автоматического мониторинга исправной вычислительной конфигурации сильно- либо слабосвязанного множества вычислительных узлов. Такая реализация позволяет в каждом конкретном случае наиболее эффективно реализовать восстановление нормального счета прикладной программы в случае аппаратного сбоя (путем переповтора пострадавшего фрагмента вычислений) на новой исправной конфигурации.

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

4.3.1. Краткая характеристика DMPI и OpenTS

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

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

T++ — синтаксически и семантически гладкое расширение языка C++; основной входной язык, распознаваемый синтаксическим анализатором OpenTS.

DMPI — Dynamic MPI. Инфраструктура, реализующая идею динамической загрузки коммуникационной библиотеки MPI по используемой разновидности сценария запуска mpirun.

Базовыми системными компонентами, решающими вопросы отказоустойчивости, являются компоненты DMPI и OpenTS.

4.3.2. Методы обеспечения отказоустойчивости

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

  2. На практике следует по возможности стремится к автоматической отказоустойчивости на системном уровне, но это не всегда разумно в силу того, что зачастую при небольших затратах на прикладном уровне можно получить на порядок более эффективное решение. Лучше всего иметь автоматическую отказоустойчивость с возможностью ручного управления для оптимизации в каждом конкретном случае.

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

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

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

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

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

4.3.3. Архитектура ПО отказоустойчивого DMPI

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

Краткое описание реализации 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() — закрытие всех сокетов.

4.3.3.2. Программный интерфейс отказоустойчивого DMPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.3.4. Доработка архитектуры DMPI

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

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

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

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

4.3.4. Архитектура отказоустойчивой версии OpenTS

4.3.4.1. Программный интерфейс отказоустойчивой Т-системы

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

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

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

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

4.3.4.2. Ограничения на стиль программирования

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

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

4.3.4.3. Неготовые значения и незавершенные по причине сбоя вычисления

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

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

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

  • Неготовое значение становится незавершенным, если его вычисление было остановлено вследствие сбоя.

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

  • В случае, когда прикладная программа использует примитив языка T++ twait(), она получает событие, означающее что величина готова, но вычисление не было завершено. В этом случае она может продолжать счет, предприняв то или иное действие в соответствии с выбранной «заказной» моделью обработки сбоя.

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

4.3.4.4. Связь с транзакциями и субтранзакциями

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

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

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

4.3.4.5. Характер обрабатываемых сбоев

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

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

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

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

4.3.4.6. Откат незаконченных вычислений

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

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

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

4.3.5. Вектор перерождений

4.3.5.1. Определение и свойства вектора перерождений

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

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

4.3.5.2. Кодирование и передача вектора перерождений

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

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

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

4.3.6. Вектор посещений

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

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

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

4.3.6.1. Отказ от повторной миграции

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

4.3.7. Классы повреждений Т-функции в случае сбоя

4.3.7.1. Неповрежденные вычисления

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

4.3.7.2. Поврежденные вычисления

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

4.3.7.3. Полуповрежденные вычисления

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

4.3.8. Освобождение ресурсов в случае сбоя

4.3.8.1. Освобождение автоматических переменных и зависящих от них ресурсов

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

4.3.8.2. Освобождение весов распределенного сборщика мусора

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

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

4.3.9. Новые классы и сущности OpenTS

4.3.9.1. Класс Portal

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

4.3.9.2. Структуры NodeId/NodeConf/GblConf

Определение статуса узла (работает/не работает, время когда загрузился, счетчик реинкарнаций и т. д.). Вектор перерождений представлен в виде массива структур 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;
};
4.3.9.3. Класс Visits (вектор посещений)

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

4.4. Виртуальная машина OpenTS_VM

4.4.1. Назначение OpenTS_VM

За последнее десятилетие технологии виртуальных машин (ВМ) сделали стремительный рывок в развитии от экспериментального программного обеспечения до полноценных инструментов для создания виртуальных сред. Современные технологии ВМ обладают целым рядом возможностей, которые трудно или невозможно реализовать на «обычных» компьютерах. В частности, например, виртуальную машину VMware можно:

  • приостановить и сохранить ее состояние в памяти, понизив нагрузку на процессор для последующего запуска других приложений;

  • остановить и сохранить ее состояние на диск, предоставляя, таким образом, возможность использовать ресурсы другими, более приоритетным с точки зрения пользователя, виртуальными машинами;

  • переместить с одного физического компьютера на другой (т.н. «живая» миграция);

  • запустить с некоторым числом процессоров, а затем добавлять или убирать процессоры во время работы ВМ с учетом потребностей и приоритетов других ВМ;

  • запустить с некоторой долей процессора и затем увеличивать или уменьшать ее, исходя из потребностей приложений, работающих внутри ВМ;

  • запустить с некоторым объемом оперативной памяти и затем, по мере необходимости изменять его;

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

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

Другое важное применение ВМ связано с разработкой и настройкой программного обеспечения. В последнее время все большую популярность получают так называемые «виртуальные приложения» (virtual appliance). Виртуальные приложения – это ВМ с предустановленной операционной системой и полностью сконфигурированными программами, нацеленные на предоставление конкретной функциональности. Виртуальным приложением может быть, например, почтовый сервер. Для запуска такого почтового сервера системному администратору необходимо всего лишь запустить соответствующую виртуальную машину. Причем производительность виртуального почтового сервера будет незначительно уступать «обычному» серверу.

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

В этом документе рассматривается виртуальное приложение OpenTS_VM. OpenTS_VM — это виртуальное приложение с предустановленной средой автоматического динамического распараллеливания OpenTS (http://opents.net/). В комплект входят также несколько модулей расширений OpenTS (отладка, визуализация счета, различные планировщики) и встроенная документация с примерами.

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

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

С точки зрения пользователя, виртуальная машина представляет собой один или несколько файлов с образами файловой системы. Но для того, чтобы создать виртуальную машину из этого образа, необходимо воспользоваться одним из многочисленных доступных сегодня мониторов виртуальных машин (гипервизоров). При создании виртуальной машины образы файловой системы монтируются в качестве жестких дисков ВМ. В этом документе описывается использование OpenTS_VM для разработчиков на операционных системах Windows и Linux с использованием гипервизоров VMware и QEMU.

4.4.2. Установка и настройка VMware Player на ОС Windows

4.4.2.1. Установка VMware Player

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

Внимание! Далее описывается процесс установки на ОС Windows XP. Установки VMware Player на другие дистрибутивы ОС Windows может отличаться.

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

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

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

4.4.2.2. Сетевые настройки VMware Player

Виртуальное приложение 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

4.4.2.3. Работа с VMware Player

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

  • f9.vmdk — образ ВМ в формате VMware;

  • vm.nvram — файл для хранения состояния BIOS ВМ;

  • f9.vmx — основной конфигурационный файл ВМ;

  • f9.vmxf — дополнительный конфигурационный файл.

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

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

Внимание! Загрузка виртуальной машины может занять значительное время. Дождитесь окончания загрузки.

Внимание! При загрузке виртуальной машины может возникнуть аварийное сообщение о нехватке памяти (рис. 1)

Рисунок 5: аварийное сообщение о нехватке памяти

 

В этом случае необходимо уменьшить значение memsize в конфигурационном файле f9.vmx.

4.4.3. Установка и настройка QEMU на ОС Windows

4.4.3.1. Установка QEMU

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 и сконфигурирует ее для автоматического запуска.

4.4.3.2. Сетевые настройки QEMU

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

Внимание! При использовании user mode network трафик из виртуальной машины перенаправляется только по протоколам TCP и UDP. ICMP (ping) протокол не перенаправляется. Для проверки соединения используйте, например, wget.

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

-redir tcp:50022:10.0.2.15:22

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

4.4.3.3. Передача файлов на виртуальную машину QEMU

В 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. Нельзя передавать файлы с виртуальной машины на физический компьютер.

4.4.3.4. Работа с QEMU

Перед запуском виртуального приложения 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.

4.4.4. Установка и настройка VMware Player на ОС Linux

4.4.4.1. Установка VMware Player

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

  1. Убедитесь, что у вас есть права суперпользователя, на том компьютере, где вы планируете выполнить установку VMware Player. Перейдите в режим суперпользователя (например, с помощью команды su).

  2. Если для установки вы используете tar-архив, перейдите к шагу 3. В случае, если для установки используется rpm-пакет, выполните следующие команды:

    1. #> rpm -Uhv Vmware-player-<XXXX> где XXXX – это номер версии и сборки Vmware Player
    2. запустите конфигурационную программу из командной строки:

      #> vmware-config.pl

      Перейдите к пункту 4.

  3. Для установки VMware Player из tar-архива выполните следующие команды

    1. Разархивируйте загруженный архив

      tar -zxf VMware-player-<XXXX>.tar.gz
    2. Перейдите в каталог дистрибутива;

      cd vmware-player-distrib
    3. Запустите установочную программу.

      ./vmware-install.pl
    4. Отвечайте на вопросы, задаваемые установочной программой. В большинстве случае можно использовать значения по умолчанию (Enter).

    5. Обязательно согласитесь выполнить программу конфигурации VMware Player (vmware-config.pl).

  4. Следуйте инструкциям на экране. В большинстве случаев можно использовать значения по умолчанию (Enter).

  5. В случае успешного завершения процесса конфигурации на экране появится сообщения вида:

    The configuration of VMware Player 2.0.4 build-93057 for Linux for this running
    kernel completed successfully.
    
    You can now run VMware Player by invoking the following command:
    "/usr/bin/vmplayer".
    
    Enjoy,
    
    --the VMware team

    В противном случае повторно выполните процедуру конфигурации (vmware-config.pl) внимательно следуя инструкциям на экране.

  6. По завершению установки завершите сеанс суперпользователя:

    #> exit

    Для удаления vmware-player используйте:

    1. В случае установки из tar-архива:

      #> vmware-uninstall.pl
    2. В случае установки из rpm-пакета:

      #> rpm –e VMwarePlayer

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

4.4.4.2. Сетевые настройки 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

4.4.4.3. Работа с VMware Player

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

$> vmplayer

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

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

4.4.5. Установка и настройка QEMU на ОС Linux

4.4.5.1. Установка QEMU

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

  1. Загрузите исходные файлы гипервизора QEMU с сайта http://bellard.org/qemu/download.html в разделе QEMU с пометкой Source code. На момент подготовки документа, последняя версия QEMU: 0.9.1.

  2. Разархивируйте архив с исходным кодом QEMU:

    $> tar xzf qemu-0.9.1.tar.gz
  3. Перейдите в каталог с исходным кодом QEMU:

    $> cd qemu-0.9.1
  4. Выполните конфигурационный скрипт сборки:

    $> ./configure
  5. Выполните сборку QEMU:

    $> make

    Внимание! Процесс сборки может занять значительное время! Дождитесь завершения сборки.

  6. Скопируйте исполняемые файлы в каталог /usr/local (необходимо наличие прав суперпользователя):

    $> su 
    #> make install
    или
    $> sudo make install

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

  1. Загрузите исходный код акселератор с сайта http://bellard.org/qemu/download.html в разделе QEMU Accelerator Mode. Не рекомендуется использовать версию для разработчиков (development version). На момент подготовки этого документа последняя стабильная версия акселератора — 1.3.0pre11;

  2. Разархивируйте архив с исходным кодом акселератора:

    $> tar xzf kqemu-1.3.0pre11.tar.gz
  3. Перейдите в каталог с исходным кодом:

    $> cd kqemu-1.3.0pre11
  4. Выполните конфигурационный скрипт сборки:

    $> ./configure
  5. Выполните сборку акселератора:

    $> make
  6. Выполните установку акселератора. Модуль будет скопирован в /lib/modules/$kernel_version/misc. Также будет произведена загрузка модуля ядра (необходима наличие прав суперпользователя).

    $> su 
    #> make install
  7. Создайте файл устройства kqemu и установите соответствующие права на него:

    #> mknod /dev/kqemu c 250 0
    #> chmod 666 /dev/kqemu
  8. Убедитесь, что модуль загружен:

    $> /sbin/lsmod | grep kqemu
  9. Для автоматической загрузки акселератора во время запуска компьютера добавьте строку /sbin/modprobe kqemu в /etc/rc.d/rc.local

  10. По завершении установки завершите сеанс суперпользователя.

4.4.5.2. Сетевые настройки QEMU

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

4.4.5.3. Передача файлов на виртуальную машину QEMU

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

4.4.5.4. Работа с QEMU

Перед запуском виртуального приложения 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.

4.4.6. Использование OpenTS_VM

После запуска OpenTS_VM виртуальная машина полностью готова для компиляции т­программ. Для проверки работы конвертера можно использовать программу fib (вычисление заданного числа Фиббоначчи), входящую в состав OpenTS_VM. Для этого перейдите в каталог с текстом программы:

[opents@OpenTS_VM ~]$ cd opents-cross/testing/tests

Убедитесь, что файл с программой присутствует в текущем каталоге:

[opents@OpenTS_VM tests]$ ls fib.tcc
fib.tcc

Скомпилируйте программу:

[opents@OpenTS_VM tests]$ t++ fib.tcc –o fib

Запустите программу:

[opents@OpenTS_VM tests]$ ./fib 5

При корректной работе системы, программа выдаст примерно такой результат:

Open T-System Runtime v3.0, 2003-2004, PSI RAS, Russia.
Running under unicomputer MPI on 1-rank cluster:
  [3.1Gf,3080BM,0.86GiB]
Starting tfun main, good luck!

fib(5) = 5
Tasks activated:     16
Tasks exported:      0
Msgs sent:           0
Async Msgs:          0
Msgs size:           0
Taskboard visits:    16
Scheduler time:      0.000
MPI time:            0.000
Idle time:           0.000
Tasks time:          0.000
Total time:          0.118

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

[opents@OpenTS_VM tests]$ mpirun –np 2 ./fib 5

4.5. Поддержка работы Т-приложений в GRID-сетях

Работа Т-приложений в GRID-сетях в настоящее время возможна при использовании отказоустойчивого режима вычислений по схеме «master—slaves». Согласно этой схеме, должен быть создан выделенный сервер, который способен принимать запросы на подключение от клиентов и распределять задачи между ними. Для этого на выделенном головном узле вызывается Т-приложение, для которого задана переменная окружения «DMPI=chrys N». Приложение создаёт TCP-сервер, который ожидает ровно N соединений от клиентов. Как только нужное число клиентов подключится, начнётся распределённое вычисление задачи.

Для запуска клиента указывается переменная окружения DMPI со значением «chrys M», и вызывается желаемое количество рабочих процессов. При вызове клиентских рабочих процессов следует указать адрес сервера в переменной окружения DMPI_MASTER. Если сервер не указан, то им по умолчанию является www.opents.net

Проведён эксперимент, демонстрирующий работоспособность данного подхода к организации распределённых отказоустойчивых вычислений. В ходе эксперимента три удалённые машины с ОС Windows и ОС Linux, используя один и тот же исполняемый exe-файл Т-приложения, работали совместно в отказоустойчивом GRID-режиме над решением одной задачи (fib(25)). При этом сервер был запущен на Linux-машине, для чего использовался эмулятор Wine.

4.5.1. Поддержка подключаемых модулей планировщика

В системе OpenTS в качестве механизма планирования используется т.н. макро-планировщик, который оптимально распределяет задачи в сильносвязанной вычислительной среде (кластер, SMP-установка). Но этот планировщик не подходит для эффективной работы в распределенной вычислительной среде. Для этих целей на предыдущих этапах развития OpenTS был разработан другой планировщик — GRID-планировщик, который гораздо эффективнее распределяет задачи в слабосвязанной вычислительной среде.

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

Проведение данной работы обусловлено следующими причинами:

  1. Обеспечение модульности ядра OpenTS.

  2. Обеспечение задела для проведения дальнейших работ над OpenTS в рамках GRID-проекта.

Данная работа преследует следующие цели:

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

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

  3. Защита кода T-системы. Разделение кода на 2 части: интерфейс и реализацию. Реализация помещается в статическую и динамическую программную библиотеки, таким образом обеспечивается защита исходных программных текстов OpenTS.

  4. Упрощение процесса создания новых планировщиков для OpenTS. Вынесенную в динамическую библиотеку функциональную часть OpenTS можно рассматривать как подключаемый модуль (plug-in). Поэтому появляется возможность разработки новых подобных модулей без необходимости внесения изменений в оставшуюся часть ядра OpenTS и без предоставления программистам исходных текстов всего ядра T-системы.

  5. Удобство распространения T-системы. Появляется возможность предоставить конечному пользователю (потребителю) возможность выбрать для себя необходимую ему функциональность T-системы и таким образом минимизировать свои расходы.

5. Сообщения системному программисту

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

Их можно просмотреть стандартными командами dmesg и tail /var/log/messages, выполненными с правами суперпользователя