3.5.1. Вопросы к разделу 3.5
1. В чем сущность расчетного диапазона кратности отказов?
Дайте определение понятия – d-ограниченные компоненты связности.
3. В чем заключается синтез отказоустоячивой ВС при определенной кратности отказов?
4. Какая основная цель надежностного подхода при создании ВС?
3.6. Реализация модели отказоустойчивых систем
3.6.1. Горячий резерв
Один сервер выполняет приложения, другой находится в горячем резерве. Дисковые массивы подключены к обоим серверам. Специальные программы, используя выделенную сеть, следят за состоянием друг друга. При обнаружении сбоя или отказа по истечении определенного интервала приложения перезапускаются на том же сервере, если он признан исправным, либо на резервном сервере с использованием состояния, сохраненного в дисковом массиве. Резервный сервер может быть менее мощным и исполнять только критичные приложения. Структура системы показана на рисунке 3.6.1.
Рисунок 3.6.1. Отказоустойчивая система по схеме «Горячий резерв»
3.6.2. Репликация
Структура системы с копированием (репликацией) данных показана на рисунке 3.6.2
Рисунок 3.6.2. Отказоустойчивая система по схеме «Репликация»
В нормальном режиме основной сервер выполняет приложения и копирует состояние основной базы данных в резервную базу данных либо по завершении каждой транзакции, либо по истечении заданного интервала времени. В случае отказа, например, по истечении определенного интервала недоступности после очередной репликации данных приложения запускаются на резервном сервере.
3.6.3. Кластеры высокой готовности
Эти кластеры применяются там, где стоимость возможного простоя из-за неполадок значительно превышают стоимость создания отказоустойчивой системы. В таких областях, как биллинговые и банковские системы, электронная коммерция, управление предприятием и т.д.
Структура кластера с высокой готовностью показана на рисунке 3.6.3.
Рисунок 3.6.3. Отказоустойчивая система по схеме «Кластер высокой готовности»
Рисунок 3.6.4. Отказоутойчивая система смешанного типа
Особенность таких кластеров – они спроектированы таким образом, что система в целом не имеет точек отказа. Иначе говоря, отсутствуют компоненты, неполадки которых могут повлиять на работоспособность системы в целом. Для достижения этой цели не придумано ничего лучше полного дублирования всех ключевых компонентов кластера (от систем хранения данных до отдельных коммутаторов и хост – адаптеров). Кроме того, при проектировании учитывается возможность быстрой замены вышедших из строя элементов без остановки системы.
В определенных случаях используют комбинирование схем, структура таких систем приведена на рисунке 3.6.4.
3.6.4. Вопросы к разделу 3.6
1. Зачем используется горячий резерв в отказоустойчивых системах?
2. С какой целью используется репликация в ВС?
3. Где используются кластеры высокой готовности?
4. Опишите структурную схему отказоустойчивой системы смешанного типа.
ГЛАВА 4. БИБЛИОТЕКА ПАРАЛЛЕЛЬНЫХ ПРОГРАММ
4.1 Характеристика параллельных языков программирования
В данной главе рассмотрены две наиболее часто используемые библиотеки параллельных программ OpenMP и MPI. В случае необходимости достаточно полный перечень библиотек параллельных программ можно найти в интернете [23]
11.1.Характеристика спецификаций OpenMP
Библиотека OpenMP [24] – это набор спецификаций по созданию параллельных программ в среде с общей памятью. Эта система предоставляет набор прагм, процедур и переменных среды. Когда эти прагмы используются в программе, они дают указание компилятору, поддерживающему OpenMP, создать исполнимый модуль, который будет выполняться параллельно с использованием нескольких потоков. При этом в исходный код необходимо внести небольшие изменения (отличные от доводки для достижения максимальной производительности).
Прагмы этой библиотеки позволяют использовать единообразный и переносимый интерфейс для создания параллельных программ на различных архитектурах и системах. Модель библиотеки позволяет параллельному программированию подняться на следующий уровень, создавая для программиста потоки и управляя ими. Все, что необходимо, это вставить соответствующие прагмы в исходный код программы и затем скомпилировать программу компилятором, поддерживающим OpenMP, с соответствующим ключевым словом. Компилятор интерпретирует прагмы и создаёт параллельный код. При использовании компиляторов, не поддерживающих OpenMP, его прагмы игнорируются без дополнительных сообщений.
Стандарты OpenMP разрабатывались в течение последних 15 лет применительно к архитектурам с общей памятью для языков Fortran, C, C++. В конце 2005 года компания Intel предложила систему программирования Cluster OpenMP, реализующий расширение OpenMP для вычислительных систем с распределенной памятью. Этот система позволяет объявлять области данных, доступные всем узлам кластера, и осуществлять передачу данных между узлами кластера неявно с помощью протокола Lazy Release Consistency. Система позволяет легко и быстро создавать многопоточные приложения на алгоритмических языках Fortran, C и C++. При этом директивы OpenMP аналогичны директивам препроцессора для языков C, C++ и являются аналогом комментариев в алгоритмическом языке Fortran. Это позволяет в любой момент разработки параллельной реализации программного продукта при необходимости вернуться к последовательному варианту программы. В настоящее время OpenMP поддерживается большинством разработчиков параллельных вычислительных систем: компаниями Intel, Hewlett-Packard, Silicon Graphics, Sun, IBM, Fujitsu, Hitachi, Siemens, Bull и другими. Многие известные компании в области разработки системного программного обеспечения также уделяют значительное внимание разработке системного программного обеспечения с OpenMP. Среди этих компаний отметим Intel, KAI, PGI, PSR, APR, Absoft и некоторые другие. Значительное число компаний и научно-исследовательских организаций, разрабатывающих прикладное программное обеспечение, в настоящее время использует OpenMP при разработке своих программных продуктов. Среди этих компаний и организаций отметим ANSYS, Fluent, Oxford Molecular, NAG, DOE ASCI, Dash, Livermore Software. Среди российских компаний следует отметить ТЕСИС, Центральную геофизическую экспедицию и российские научно-исследовательские организации. К ним относятся – Институт математического моделирования РАН, Институт прикладной математики имени Келдыша РАН, Вычислительный центр РАН, Научно-исследовательский вычислительный центр МГУ, Институт химической физики РАН и другие.
Разработкой стандарта занимается организация OpenMP ARB (ARchitecture Board), в которую вошли представители крупнейших компаний – разработчиков SMP-архитектур и программного обеспечения. Спецификации для языков Fortran, C и C++ появились соответственно в октябре 1997 года и октябре 1998 года.
Согласно терминологии POSIX threads, любой UNIX-процесс содержит несколько нитей управления (потоков, легковесных процессов), имеющих общее адресное пространство, но разные потоки команд и раздельные стэки. Самый простой процесс состоит из одной нити. POSIX-интерфейс для организации нитей (Pthreads) поддерживается широко (практически на всех UNIX-системах), однако по многим причинам не подходит для практического параллельного программирования: нет поддержки языком Fortran, слишком низкий уровень, нет поддержки параллелизма по данным, механизм нитей изначально разрабатывался не для целей организации параллелизма.
OpenMP можно рассматривать как высокоуровневую надстройку над Pthreads (динамически порождаемые нити, общие и разделяемые данные, механизм «замков» для синхронизации).
Многие поставщики SMP-архитектур (Sun, HP, SGI) в своих компиляторах поддерживают специальные директивы для распараллеливания циклов. Однако эти наборы директив, как правило: 1) весьма ограничены; 2) несовместимы между собой, в результате чего разработчикам приходится распараллеливать приложение отдельно для каждой платформы. OpenMP является во многом обобщением и расширением упомянутых наборов директив.
При использовании OpenMP разработчик получает некоторые преимущества:
1. За счет идеи независимого распараллеливания отдельных участков программ эта библиотека идеально подходит для разработчиков, желающих быстро распараллелить свои вычислительные программы с большими параллельными циклами. Разработчик не создает новую параллельную программу, а просто последовательно добавляет в текст последовательной программы соответствующие директивы.
2. Разработчику предоставляются большие возможности контроля над поведением параллельного приложения.
3. Предполагается, что OpenMP-программа на однопроцессорной платформе может быть использована в качестве последовательной программы, т.е. нет необходимости поддерживать последовательную и параллельную версии. Директивы распараллеливания просто игнорируются последовательным компилятором, а для вызова процедур библиотеки могут быть подставлены заглушки (stubs), текст которых приведен в спецификациях.
4. Одним из достоинств рассматриваемой системы её разработчики считают наличие директив синхронизации и распределения работы, которые дают возможность не входить непосредственно в лексический контекст параллельной области.