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

Предмет совместного исследования, которое ведется в двух очень известных в компьютерном мире университетах, в Стэнфорде и Беркли, составили компьютерные системы, ориентированные на восстановление после отказа (recovery oriented computing, ROC). Результаты работы, которую со стороны Стэнфорда возглавляет Армандо Фокс, а со стороны Беркли — Дэвид Паттерсон, пока еще не вышли за стены лабораторий. Однако она привлекает к себе внимание исключительной новизной, а также тем, что в ее фундамент легли удивительно простые и здравые взгляды и, прежде всего, учет человеческого фактора. Невниманием к роли человека заметно страдают технологии, называющие себя информационными. Ориентация же на человека привела к удивительному следствию. Обладая высочайшим интеллектуальным потенциалом, создатели ROC опираются на вполне естественную, если не сказать обыденную логику. Совмещение технических решений с подобной логикой позволяет представить ROC не столько как сумму технологий, но и как более органичную, нежели принято, идеологию построения систем, обладающих качеством, называемым высокой готовностью. Идеология ROC отрицает традиционное стремление во что бы то ни стало устранить причины отказов; напротив, она признает неизбежность возникновения неисправностей, но, если предпосылки к ним обнаруживаются заблаговременно, и обеспечены эффективные средства для восстановления, то негативные последствия можно минимизировать.

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

Вывод первый: как бы не были эффективны средства обеспечения безопасности, катастрофы возможны, если не неизбежны.

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

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

Помимо инженерного искусства, создатели ROC опираются еще и на житейский опыт, сформулированный, в том числе, и афористически. Практически во всех материалах, посвященных ROC, цитируется так называемое «правило Шимона Переса» (Peres?s Law): «Если проблема не имеет решения, то, возможно, это не проблема, а явление, стоит не решать ее, а признать необходимым пожизненное его преодоление». Правило Переса стало главной заповедью создателей ROC, краеугольным камнем их философии. Анализ этого высказывания дает ответ на закономерный вопрос: почему собственно понадобилось создавать ROC, если есть традиционные подходы к построению надежных вычислительных систем, чем они стали плохи?

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

Сегодня в компьютерных системах, поддерживающих Internet-приложениях, обычно используют ультратонкие серверы Intel-архитектуры, часто оснащенные очень недорогими материнскими платами, не поддерживающие память ECC, а также IDE-диски. Так поступают, например, владельцы всем хорошо известной поисковой машины Google, которая работает на 8 тыс. «самодельных» серверов. В среднем такого рода серверы имеют 1% отказов в год, что в случае Google равняется полутора отказам в неделю. И это кустарное, если смотреть с классических позиций, решение оказывается экономически целесообразным.

Таблица 1. Результаты испытаний действий операторов

Пяти операторам было предложено заменять вышедшие из строя диски в дисковых массивах. Каждый оператор выполнял от 5 до 9 замен. Фатальными считались ошибки, при которых содержимое тома терялось, нефатальными — когда его удавалось восстановить.

При проектировании большинства систем не учитывается человеческий фактор. Но именно люди выполняют все функции по ремонту и обслуживанию, т. е. физические действия с оборудованием и вмешательство в программное обеспечение. При этом они неизбежно совершают ошибки. В обычных условиях уровень ошибок не нулевой, а в стрессовой ситуации он может многократно возрастать. Реальную эффективность работы операторов иллюстрирует таблица 1. Анализ работы операторов систем управления ракетными комплексами (воздушными перевозками, отказоустойчивыми вычислительными системами Tandem и т.п.) показывает, что от 42 до 70% сбоев происходит из-за человеческого фактора. Неизбежность аппаратных сбоев и человеческих ошибок заставляет прийти к выводу, что перед нами не проблема, а явление. Поэтому, следуя закону Переса, надо принять действительность такой, какая она есть. С возникновением новых приложений возникают новые сложности, и это не те проблемы, которые можно разрешить техническими способами, это явления, существование которых следует признать, а затем научиться с ними сосуществовать.

Проектирование систем, ориентированных на восстановление

Философия Recovery-Oriented Computing предполагает наличие неизбежных неисправностей, а поэтому ориентируется на методы, позволяющие выявить скрытые угрозы, предоставляет более эффективные механизмы обнаружения и восстановления и при этом учитывает человеческий фактор, заботясь о том, чтобы облегчить оператору выполнение задач диагностики, и повышая толерантность системы по отношению к ошибкам «человеческого» происхождения. В качестве средства для повышения готовности предлагается альтернативный подход к проектированию систем, названный Repair-centric System Design.

Но прежде несколько общих слов о готовности систем. Для оценки этого показателя используется формула

A = MTTF/(MTTF+MTTR),

где A — коэффициент готовности, MTTF — время наработки на отказ, а MTTR — время восстановления. Несмотря на заверения, обещающие А = 0,99999, в самых лучших Internet-системах этот показатель находится в диапазоне от 0,99 до 0,999, что соответствует простоям суммарной длительностью от 8 до 80 часов в год. Помимо чисто технических причин ненадежности есть вирусные атаки и другие террористические действия.

Формула коэффициента готовности позволяет продемонстрировать главную идею ROC. Для того чтобы приблизить значение A к единице, традиционно старались максимально увеличить значение MTTF, т.е. шли на создание более надежного оборудования и программного обеспечения. Но арифметика подсказывает, что достижение той же цели возможно, если MTTR много меньше MTTF. Другими словами, повышение готовности может быть достигнуто за счет сокращения времени восстановления. Для совершенствования ремонтопригодности и используется методика Repair-centric System Design. Ее можно представить в виде нескольких основных положений.

  • Прогнозирование неисправностей. Один из самых очевидных способов прогнозирования заключается в постоянном тестировании и верификации оборудования и программного обеспечения. Но в отличие от «прослушивания», как это делается в отказоустойчивых системах, в ROC предлагается «инъекция» реальных тестов через действующие интерфейсы. Такой метод проверки позволяет выйти на семантический уровень оценки системы, в отличие от тривиальной проверки на коммуникационном уровне. Кроме того, предполагается, что каждый из модулей системы осуществляет входной контроль данных.
  • Необходимость демонстрации неисправностей. Это в некоторой степени смена стиля мышления. Если присмотреться, то классические отказоустойчивые системы пытаются замаскировать неисправности, «сделать вид», что ничего не произошло. На практике подобное возможно с точки зрения функциональности, но не с точки зрения производительности, поэтому обычно и говорят о плавной деградации. Для систем, обслуживающих Internet-приложения, такой подход не всегда годится. Более того, в некоторых случаях можно поступиться функциональностью, но при этом сохранить производительность. Поэтому наряду с традиционными механизмами, построенными на принципах избыточности, ROC предполагает наличие механизма активного информирования каждым модулем о «своем состоянии здоровья» других модулей, с которыми он находится во взаимодействии; существенным требованием является асинхронность этого процесса.
  • Оказание помощи в процессе диагностики. Информация об ошибках и изменении статуса должна становится доступной человеку в наиболее доступной для него форме и поддерживается механизмом анализа причин (root-cause analysis). Одной из перспективных форм подобного анализа является анализ зависимостей (dependency analysis). Он позволяет оценивать симптомы состояния системы и сосредоточивать внимание на подозреваемых модулях, исключая остальные.
  • Совершенствование механизмов обслуживания и ремонта. Анализ показывает, что создание эффективных программных кодов, поддерживающих обслуживание и ремонт, относится к числу наиболее сложных задач. Известно, что множество инцидентов со сложными техническими системами, например, с космическими аппаратами, предназначенными для работы на других планетах, было связано с ошибками в программном обеспечении, предназначенном для обслуживания и ремонта. Из более близких примеров: операционная система Solaris/x86 не справляется с двойной ошибкой в RAID-5; очень плохо работают с RAID-5 драйверы Linux — для восстановления даже небольших томов могут потребоваться многие часы. Создание системы, ориентированной на обслуживание, предполагает, прежде всего, необходимость позаботиться о свободных от ошибок и эффективных поддерживающих кодах.
  • Обслуживание, ориентированное на человека. Человеку свойственно ошибаться. Это обстоятельство учитывают создатели многих приложений. Во все текстовые редакторы, электронные таблицы и графические пакеты встроены механизмы undo/redu; удаление файлов производится почти всегда через буфер, обеспечивающий восстановление, и т.д. Так было не всегда; те, кто работал с «древними» программами, помнит, к чему обычно приводили оплошности. К сожалению, возможности мгновенно исправить допущенную ошибку лишен системный администратор, а ведь он тоже может сделать ошибку при замене диска, но в большинстве случаев RAID ему это не простит. Нарушения в работе сайтов из-за ошибок в процессе модернизации или обслуживания происходят гораздо чаще, чем по иным причинам, но о них говорят меньше, чем об угрозе вирусных атак. Есть случаи, когда выполнение отката невозможно, однако во всех остальных случаях реализация подобных процедур желательна. Еще один источник ошибок — низкая подготовленность к действиям в аварийных ситуациях. Операторы вычислительных систем должны проходить такой же тренинг, что и операторы энергетических и других промышленных объектов на специальных стендах, получая, в том числе, и необходимую психологическую подготовку.

ROC на деле

Инъекция glibc. Одним из первых экспериментов, проведенных в рамках проект ROC, стал анализ свойств широко распространенного программного обеспечения. В качестве предмета для тестирования были выбраны текстовый редактор Emacs, браузер Netscape, системы управления базами данных Berkeley DB и MySQL и HTTP-сервер HTTP. В качестве инструмента для анализа свойств в существующем программном обеспечении была разработана методика инъекции ошибок в модули glibc специального средства, названного FIG (Fault Injection in glibc). Библиотека glibc (GNU C Library), один из ключевых компонентов современных дистрибутивов Linux, служит для поддержки наиболее существенных программных интерфейсов операционной системы. По своей функциональности FIG представляет собой легкое средство, имплантированное в систему и намеренно вызывающее ошибки посредством специальных вызовов, а затем фиксирующее их проявления. Эксперимент состоял в том, что на вход исследуемой программы поступало сообщение об ошибке при выполнении системного вызова, после чего фиксировалась реакция программы на сообщение. В результате эксперимента удалось показать, что даже такое отработанное годами программное обеспечение имеет недокументированные интерфейсы и слабые механизмы восстановления после сбоев, только в 30% сбоев программы продолжали сохранять работоспособность. Во всех остальных для восстановления потребовалось вмешательство оператора. Из этого опыта можно сделать однозначный вывод о необходимости усиления механизмов восстановления после сбоев даже в наиболее популярных программных продуктах.

Автоматическая идентификация сбоев. Pinpoint — это специально разработанное в рамках исследования ROC диагностическое средство, позволяющее отследить последовательность возникновения ошибок и изменений в программных модулях. Обычно для исследования программ используются средства, которые дают возможность журналировать ошибки и изменения в программном обеспечении и таким образом сокращать MTTR. Традиционные технологии хорошо работают в стабильной программной среде, но системы, предоставляющие Internet-сервисы, имеют гораздо большую динамику, они могут изменяться каждый день, поэтому классические средства не работают. Pinpoint является альтернативным инструментом, причем благодаря тому, что в большинстве случаев Internet-приложения строятся с использованием программного обеспечения промежуточного слоя Microsoft .NET или J2EE, он является модульным. Развертывание Pinpoint совместно с приложениями, написанными на J2EE, позволило заметно сократить время восстановления после сбоев.

Кластер ROC-1. Группа исследователей из Стэнфорда и Беркли выполнила еще целый ряд интересных экспериментов с программным обеспечением и опытных разработок. Пожалуй, наиболее показательным является опыт по созданию кластера, ориентированного на восстановление. Кластер ROC-1 состоит из 64 узлов, каждый из которых представляет собственную конструкцию, названную «кирпичом» (brick). Каждый кирпич состоит из 18-гигабайтного SCSI-диска, специально спроектированной системной платы, процессора Pentium II Mobile, оперативной памяти DRAM, сетевых интерфейсов и — что, собственно, и составляет его специфику — диагностического процессора Motorola 68376, включенного в отдельную диагностическую сеть. При проектировании кластера использованы две взаимодополняющие друг друга технологии — CAN (controller area network), обычно используемая в системах промышленной автоматики, и SAN (в своем исторически первом значении system area network), наиболее известная по отказоустойчивым компьютерам Tandem.

заключение

Тем, кого заинтересует предмет данного исследования, открывается полная возможность ознакомиться с ним. Множество материалов выложено на сайте roc.cs.berkeley.edu. Особое внимание тех, кого заинтересует ROC-1, обратим на статью ROC-1: Hardware Support for Recovery-Oriented Computing, опубликованную в IEEE Transactions on Computing.

Манифест Дэвида Паттерсона

Дэвид Паттерсон — одна из самых ярких, можно сказать, харизматических личностей современного компьютерного мира. Он занимает промежуточную позицию между фундаментальными исследованиями и бизнесом, а университет, где он преподает почти три десятилетия, не утратил своего бунтарского духа с тех времен, когда Паттерсон был студентом. Чтобы стать известным, ему хватило бы дизайна придуманного им логотипа компании Sun Microsystems, составленного из восьми знаков конъюнкции и дизъюнкции. И все же специалисты знают Паттерсона, прежде всего, как автора популярных технологических решений. Он возглавлял разработку RISC I, одной из первых реализаций идеи сокращенного набора команд процессора. Этот проект лег в основу архитектуры SPARC. Он руководил и инициативой по созданию избыточных массивов недорогих дисков (redundant array of inexpensive disk, RAID). О том, что означает RAID для создания высоконадежных систем хранения данных, говорить излишне. Сейчас, как и во времена создания архитектуры RISC, новые работы ведутся совместно с коллегами из Стэнфордского университета. На этот раз целью исследований является разработка программных и аппаратных основ построения компьютерных систем, ориентированных на восстановление после отказа. Для того чтобы предложить технические принципы Recovery Oriented Computing, необходимо было сначала критически переосмыслить статус-кво в информационных технологиях в целом.

Документ, опубликованный Паттерсоном два года назад, является своего рода революционным манифестом. В нем утверждается примат человеческих ценностей над машинными, в нем звучит призыв отказаться от технократической зашоренности, которой страдает большинство инженеров. Вот, в частности, что в нем говорится: «За двадцать лет производительность компьютеров возросла в 10 тыс. раз; вычисления, занимавшие в 1982 году месяцы, сегодня укладываются в час. Это прекрасно, к примеру, астрономы могут смоделировать Вселенную внутри кластера, за 10 тыс. долл. они могут собрать в архитектуру Beowulf терабайты внешней памяти, гигабайты оперативной памяти и множество гигагерцовых процессоров. Практически все ученые стали специалистами по вычислениям, и эта тенденция будет продолжаться и углубляться. Для всех остальных пользователей, свободные поисковые системы наподобие Google обеспечили доступ к океану информационных источников, позволили нам преобразовывать неясные представления в конкретные запросы и таким образом расширять наши знания. Но, увы, наряду с этими благами увлечение производительностью привело к зависимости от технологий. Мы оказываемся зацикленными на них. Мы разработали ненадежные технологии, которые при пользовании ими бесконечно огорчают нас. Врачи и юристы переустанавливают дисковые устройства в своих компьютерах, системные администраторы проводят дни и ночи в борьбе с ошибками в дорогостоящем программном обеспечении. Недовольство пользователей уже приводит к насилию. Кроме того, поведение компьютеров, начиная с простейших устройств и вплоть до мощных серверов, поддерживающих инфраструктуру Internet, непредсказуемо. Далее, слова ?компьютер? и ?безопасность? стали выражать противоположные значения. И, наконец, достижения по части оптимизации соотношения стоимость/производительность имеют обратный эффект: компьютеры называют всепроникающими, современный мир зависит от них, но никто не доказал, что они заслуживают подобного доверия. Сохранение нынешней парадигмы еще на протяжении следующих двадцати лет, когда скорости компьютеров возрастут еще в 10 тыс. раз, но при этом раз они не перестанут огорчать нас, как делают это сейчас, и не станут безопаснее, — это мой ночной кошмар.

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

  1. Синергетика с человеческой природой. Мы должны сделать технологии человечнее и для тех, кто пользуется простыми устройствами, и для тех, кто обеспечивает обслуживание этих устройств. Мы должны научиться заботиться о человеческой цене пользования информационными технологиями не меньше, чем о стоимости их приобретения.
  2. Зависимость. Мы должны создавать информационные технологии, на которые мир действительно может положиться так, как он опирается на технологии других типов, полностью доверяя им.
  3. Безопасность и охрана прав личности. Не станем обеспечивать свои трудом Большого Брата. Мы должны создавать технологии, которые будут обеспечивать и безопасность и права личности».

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