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

Когда я возглавлял общее руководство группой программистов фирмы IBM, я узнал от руководителя группы внутренней обработки данных (мы работали над составлением платежной ведомости для 15 тысяч человек, разбросанных по всей стране), что нам нужно «купить» удаленную вычислительную машину, которая будет использоваться для разгрузки центральной машины, выполняя «удаленные вычисления». Я ответил: «Прекрасно, а теперь покажите мне, сколько мы на этом сэкономим». Мы провели три совещания общей продолжительностью в четыре с половиной часа и пришли к выводу, что денег нам на этом сэкономить не удастся, более того, возникнут дополнительные затраты, но зато «может» появиться некоторая «эффективность». Эффективность эта была несущественна (мое мнение). Предложение поэтому было отвергнуто. Этот случай показал мне, что мой руководитель внутренней обработки не может четко мыслить.

Многопроцессорная обработка и мультипрограммирование

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

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

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

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

Если в состав многопроцессорного комплекса входят машины в 1 МКС — каждая из них выполняет миллион команд в секунду — и у нас их четыре, мы, конечно же, получим систему в 4 МКС, не так ли? Нет, не так. Когда сразу несколько ЦП пытаются обратиться к одному блоку памяти, возникает эффект блокирования. В некоторых приложениях специально формулируются требования по синхронизации, позволяющие достичь целостности данных, когда несколько ЦП пытаются обратиться к одному файлу данных или к одной физической ячейке памяти. При этом может возникать некоторое снижение производительности, измерить которое и понять очень сложно. (См. рис. 7.1.)

Если кто-то говорит, что такая-то и такая-то системы имеют по 16 ЦП, можно побиться об заклад, что либо 1) они работают с очень специальной задачей в крайне жестких граничных условиях, либо 2) такие системы не более чем любопытная лабораторная диковина, которая вряд ли может быть применена в настоящих приложениях. На путях внедрения 16-процессорных систем в практику универсальной обработки данных еще остается много препятствий.

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

Готовность

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

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

Для того чтобы определить, что надежнее — дублирование или многопроцессорность, разберем простой пример. Для простоты рассмотрим случай многопроцессорной системы всего с двумя блоками памяти и двумя ЦП, не обращая внимания на каналы ввода/вывода и другие детали. (См. рис. 7.2.) Единственная разница между системами состоит в том, что устройства памяти разделяются обоими процессорами (доступны им обоим). Следовательно, потеря одного ЦП в системе 1 и одного блока памяти в системе 2 не должна приводить к прекращению функционирования. Теперь нам надо представить себе, что мы хотим определить вероятность готовности системы к продолжению работы.

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

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

Технический отдел IBM горячо доказывал, что в данном случае дублирование даст более хороший результат, система будет в более высокой степени готовности. В качестве предполагаемого руководителя выполнением заказа для FAA я спорил с ними, доказывая, что многопроцессорный вариант более надежен (исходные требования от FAA прямо приводили к многопроцессорной системе). Многие часы провели мы в исследовательском комитете. К моему удивлению, было выработано решение, в котором система с дублированием объявлялась более надежной. В тот зимний день 1963 г., проведенный в Поукипси, шт. Нью-Йорк, я просто отказывался верить своим ушам. Лирсон склонялся к тому, чтобы в IBM делали систему с дублированием. «Но ведь требования прямо ведут к многопроцессорности!» По некоторым причинам я никак не мог объяснить это Лирсону. Он спросил, все ли собравшиеся согласны с тем, что в требованиях есть предпосылки многопроцессорной системы. Все были согласны. Лирсон решил остановиться на многопроцессорном варианте. Наш проект был принят.

Причины многопроцессорной обработки

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

Прежде всего многопроцессорность увеличивает мощность (пропускную способность) на самом высоком уровне производительности, достигнутом вычислительной техникой. Если мы не способны построить более быструю вычислительную машину, мы можем объединить в одной конфигурации два ЦП.

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

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

Целостность данных

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

Предположим, что на моем счете находится 575 долларов и у меня есть чек на 35 долларов, а у вас — на 100 долларов. Если баланс начну подводить я, то, увидев сумму 575 долларов, я должен буду производить вычитание из нее. Если в это же время вы тоже начнете производить вычитание из этой же суммы, мы ошибемся. Я получу результат в 500 долларов, а вы в 475 долларов. Кто бы ни написал в основной файл новое значение последним, он напишет неверное значение. В данном случае не была обеспечена целостность процесса. Мы не имеем права разрешать внесение изменений в основной файл более чем одному пользователю за раз. Значение баланса должно быть заблокировано все время, пока кто-то его изменяет. Это справедливо и для многих других типов данных — мест расположения самолетов, медицинских сведений и т. д. Это же относится и к сложным вычислительным комплексам. Мы должны следить за целостностью данных и в многопроцессорных системах, и в системах распределенной обработки данных, и в сетях.

Как мы это делаем? С помощью системных программ.

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

Аппаратные решения этих сложных конфигураций известны уже не один десяток лет. С аппаратурой у нас проблем нет.

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

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

Сети

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

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

2. Желание создать сеть машин. Такая сеть нужна для вычисления, и линии связи обеспечивают возможность этих вычислений.

Очевидно, что между этими двумя типами существует некоторое перекрытие. И с ним уже десяток лет борется FCC (Федеральная комиссия по связи — Federal Communications Commission).

Стоимость сетей первого типа — сетей связи — должна определяться их задачами. Либо они себя оправдывают, либо нет. И если существует более дешевый способ управления системой, то вычислительные машины использовать нет необходимости. Экономическую целесообразность использования вычислительных сетей показать не так просто. Сеть Агентства министерства обороны США по передовым исследовательским проектам (Advanced Research Projects Agency — ARPA) можно считать великолепным техническим достижением, доказавшим, что можно объединять в одной сети множество разнотипных вычислительных машин, причем все протоколы, написанные для этого, будут верно работать. Вычислительных же сетей, действующих в частном секторе и дающих реальный доход, очень мало, если они вообще существуют. Некоторые крупные компании, занимающиеся работой в режиме разделения времени, считают экономически более выгодным использовать центральный вычислительный комплекс, состоящий из расположенных в одном месте нескольких вычислительных машин, и коммуникационную сеть, собирающую информацию для централизованной обработки. При этом можно обойтись единым руководством, одной бригадой операторов, единой охраной и т. д. Кроме экономических могут, однако, существовать и другие причины, приводящие к распределению вычислительных машин. Надежность, защита от стихийных бедствий и забастовок, исключение необходимости создания огромных сложнейших систем программного обеспечения могут оказаться вполне достаточными предпосылками.

Заказ на создание сети для фирмы General Motors

В середине 1974 г. я получил приглашение от отделения обработки данных фирмы IBM (ООД): не смогу ли я совместно со своими лучшими специалистами затратить один день на рассмотрение состояния дел в работе над предложениями, которые ООД собиралось передать в General Motors? Я согласился.

Просить помощи не в правилах ООД. Но о предложениях, готовящихся для General Motors, уже складывались легенды — их масштаб и сложность, как говорили, не имели прецедентов.

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

Запрос был весьма объемистым — пачка бумаги около 15 см толщиной, — и ответ на него был весьма объемистым и сложным. Несколько часов мы провели, пытаясь пробиться сквозь дебри звезд, колец, пакетов, — и несколько часов, пытаясь заставить работать это огромное сборище машин стоимостью в несколько десятков миллионов долларов.

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

Зачем огромной вычислительной машине, выполняющей инвентаризацию, составление платежных ведомостей и планирующей производство в городе 1, взаимодействовать с большой системой разделения времени, расположенной в городе 2? И зачем этим двум машинам еще взаимодействовать с мощной машиной для научных расчетов, которая стоит в городе 3?

Потому что так требуется в запросе на систему! Может быть, для выравнивания загрузки, может быть, для разделения данных, может быть, для…?

Ясного ответа на эти вопросы не было! Способ взаимодействия и используемые при этом соглашения зависят от того, зачем вы объединяете все эти вычислительные машины. «Как» идет следом за «почему».

Известно, что фирма General Motors так и не подписала контракт! Несмотря даже на то, что IBM и некоторые фирмы потратили по миллиону долларов, чтобы ответить на все запросы.

Фирма General Motors не новичок в деле использования вычислительной техники. И даже этот весьма квалифицированный пользователь не избежал соблазна, исходящего от «новых» методов, «новых» использований.

Распределенная обработка?

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

Выводы

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

Если мы не будем достаточно осторожны, оценивая размеры программ, организующих взаимодействие, то мы вскоре обнаружим, что получившаяся система 80 или 90 % времени тратит не на работу, а на это взаимодействие. Каждое подключение к сети независимого вычислителя (вычислительной машины или одиночного центрального процессора) усложняет связь между всеми остальными частями сети. Надо следить, чтобы эта сложность не затрудняла выполнение основной задачи системы — обработки данных.

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

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