Программное обеспечение и его разработка - [116]
Интуитивно может показаться очевидным, что многопроцессорная система имеет более высокий коэффициент готовности, но это не так, по крайней мере не всегда так. Нужно обязательно провести исследование и расчеты, очень длительные расчеты. В 1963 г. глубокое изучение этого вопроса, проведенное исследовательской группой IBM, созванной В. Пирсоном (вице-президент IBM, а затем председатель отделения) для того, чтобы ответить на запрос, поступивший из FAA, привело к созданию системы диспетчеризации авиалиний Соединенных Штатов.
Технический отдел IBM горячо доказывал, что в данном случае дублирование даст более хороший результат, система будет в более высокой степени готовности. В качестве предполагаемого руководителя выполнением заказа для FAA я спорил с ними, доказывая, что многопроцессорный вариант более надежен (исходные требования от FAA прямо приводили к многопроцессорной системе). Многие часы провели мы в исследовательском комитете. К моему удивлению, было выработано решение, в котором система с дублированием объявлялась более надежной. В тот зимний день 1963 г., проведенный в Поукипси, шт. Нью-Йорк, я просто отказывался верить своим ушам. Лирсон склонялся к тому, чтобы в IBM делали систему с дублированием. «Но ведь требования прямо ведут к многопроцессорности!» По некоторым причинам я никак не мог объяснить это Лирсону. Он спросил, все ли собравшиеся согласны с тем, что в требованиях есть предпосылки многопроцессорной системы. Все были согласны. Лирсон решил остановиться на многопроцессорном варианте. Наш проект был принят.
Многопроцессорная обработка обусловлена тремя главными причинами — две из них довольно простые, третья же очень сложна.
Прежде всего многопроцессорность увеличивает мощность (пропускную способность) на самом высоком уровне производительности, достигнутом вычислительной техникой. Если мы не способны построить более быструю вычислительную машину, мы можем объединить в одной конфигурации два ЦП.
Вторая причина состоит в возможности обеспечить безболезненный рост, не требуя дополнительного пространства, не срывая работ, мы получаем возможность увеличивать вычислительную мощность, убирая один из ЦП и заменяя его другим, более мощным и совместимым по программному обеспечению.
Третья причина заключается в необходимости обеспечить бесперебойную работу. Не просто защиту от отказов, а именно бесперебойную работу. Простая защита от отказов приводит к тому, что для каждого критичного устройства в систему включается еще одно резервное, и если происходит отказ, то к линии подключается резерв, а работа продолжается. Бесперебойная работа подразумевает наличие нескольких способов обработки кризисных ситуаций, используя в качестве резерва несколько ЦП и блоков памяти и исключая из системы после каждого очередного отказа некоторую часть выполняемых ею функций. Аппаратура для бесперебойной работы проще, а вот программное обеспечение построить для нее практически невозможно. Количество комбинаций возможных в системе отказов очень быстро становится огромным. Обработать программными средствами один отказ в памяти не очень сложно, но, если сразу же может возникнуть второй отказ, третий, мы тут же сталкиваемся с сотнями различных комбинаций, и в программах нужно отражать их все. Очень скоро программа восстановления становится бесконечно большой. Если мы остановимся только на одном уровне резервирования, как при простой защите, это еще вполне выполнимо. Если же нам требуются два уровня, на которых придется осуществлять защиту, а в нашем распоряжении десятки разных устройств, каждое из которых подвержено отказам, перед нами встает уже гораздо более сложная задача.
Если я пользуюсь своим банковским счетом один и у меня есть несколько чеков, суммы которых я должен вычесть из суммы своего вклада, вычисленной накануне, я могу сделать это последовательно на одной машине. Но, если у меня два чека, один находится у вас, а другой я должен обработать сам, нам никак нельзя делать это одновременно, находясь за разными терминалами и по отдельности вычисляя новую сумму, иначе мы получим неверные результаты.
Предположим, что на моем счете находится 575 долларов и у меня есть чек на 35 долларов, а у вас — на 100 долларов. Если баланс начну подводить я, то, увидев сумму 575 долларов, я должен буду производить вычитание из нее. Если в это же время вы тоже начнете производить вычитание из этой же суммы, мы ошибемся. Я получу результат в 500 долларов, а вы в 475 долларов. Кто бы ни написал в основной файл новое значение последним, он напишет неверное значение. В данном случае не была обеспечена целостность процесса. Мы не имеем права разрешать внесение изменений в основной файл более чем одному пользователю за раз. Значение баланса должно быть заблокировано все время, пока кто-то его изменяет. Это справедливо и для многих других типов данных — мест расположения самолетов, медицинских сведений и т. д. Это же относится и к сложным вычислительным комплексам. Мы должны следить за целостностью данных и в многопроцессорных системах, и в системах распределенной обработки данных, и в сетях.
