Управление точками отказа при проектировании облачных приложений

Четыре способа повышения надежности облачных приложений

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

Питер Бедлл, технический директор, PowWow

Питер Бедлл (Peter Bell) – фотографияПитер Белл (Peter Bell) является техническим директором бережливого стартапа PowWow, расположенного в Нью-Йорке. Представлен на международном уровне и много пишет на темы облачных вычислений, доменных языков, динамичных архитектур, NoSQL, а также требований и оценок. Участвовал в ряде конференций, включая DLD Conference, ooPSLA, Code Generation, Practical Product Lines, the British Computer Society Software Practices Advancement, UberConf, the Rich Web Experience и No Fluff Just Stuff tour. Публиковался в IEEE Software, Dr. Dobbs, IBM developerWorks, Information Week, Methods & Tools, Mashed Code, NFJS the Magazine, JSMag и GroovyMag. Является постоянным инструктором в General Assembly – кампусе технологии, дизайна и предпринимательства в Нью-Йорке.



24.09.2012

Что такое надежность

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

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

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

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

Рассмотрим четыре способа проектирования мощных и надежных Web-приложений:

  • Сокращение количества единых точек отказа.
  • Управление поведением отказов.
  • Обнаружение отказов.
  • Предотвращение отказов при помощи стратегий проектирования, разработки, тестирования и развертывания.

Сокращение количества единых точек отказа

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

Возникновение единых точек отказа зависит от приложения, но обычно они возникают в следующих областях:

  • DNS-серверы.
  • Web-серверы.
  • Серверы баз данных.
  • Файловые серверы.
  • Распределители нагрузок.
  • Другие специализированные серверы.
  • Взаимозависимости со сторонними приложениями.

На рисунке 1 показаны типичные точки отказа.

Рисунок 1. Типичные точки отказа
Рисунок 1. Типичные точки отказа

DNS-серверы

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

Web-серверы

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

Во-вторых, необходимо подумать о том, как сохранять информацию о сеансе. Для небольших объемов данных можно использовать хранилище куки, но следует проявлять осторожность, если вы хотите хранить больше чем просто идентификатор, поскольку куки не защищены от несанкционированного вмешательства пользователей и их максимальный размер равен 4 КБ. Чаще всего применяются либо локальное хранилище сеансов на каждом Web-сервере с распределителем нагрузки, использующим "привязанные" сеансы (пользователи во время сеанса постоянно возвращаются на один и тот же Web-сервер), либо хранение состояния всех сеансов на отдельном сервере сеансов, который будет использовать кэш в памяти или хранилище пар ключ-значение. Хранение состояния сеансов на каждом Web-сервере и использование привязанных сеансов является, как правило, более производительным подходом, так как при этом снижается число сетевых пакетов для выполнения запроса, но при отказе Web-сервера все его пользователи теряют свои сеансы. Если важна надежность, для хранения сеансов имеет смысл использовать отдельный сервер.

Серверы баз данных

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

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

Файловые серверы

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

Распределители нагрузок

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

Другие специализированные серверы

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

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

Взаимозависимости со сторонними приложениями

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

Например, использование стороннего сайта для предоставления аутентификации является большим риском. Однако если сторонним сайтом является Facebook, такой риск может быть оправдан, поскольку простой серверов большой организации менее вероятен, чем простой серверов поставщика с меньшими возможностями. Если риск простоя велик, гарантируйте вход в систему с использованием альтернативных учетных данных (например, адреса электронной почты и пароля), чтобы пользователи могли получить доступ к приложению даже при недоступности серверов OAuth Facebook (см. рисунок 2).

Рисунок 2. Дополнительные точки отказа
Рисунок 2. Дополнительные точки отказа

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


Управление отказами

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

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

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

Рисунок 3. Обход отказа без локального хранилища
Рисунок 3. Обход отказа без локального хранилища

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


Обнаружение отказов

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

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

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

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


Обход отказов

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

Разработка через тестирование

Одним из наиболее эффективных способов убедиться, что приложение хорошо спроектировано и обеспечивает ожидаемую функциональность, является разработка через тестирование (test-driven development – TDD). Этот процесс гарантирует корректность кода и существенно улучшает гибкость и качество дизайна.

Непрерывная интеграция

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

Непрерывное развертывание

Одной из самых значительных технических книг 2010 года является книга Джеза Хамбла (Jez Humble) и Дэйва Фарли (Dave Farley) "Непрерывное развертывание". В ней рассматривается создание устойчивого, хорошо спроектированного конвейера развертывания приложений; если вы интересуетесь повышением надежности приложений, эту книгу нужно прочесть обязательно. В перечень концепций входят сине-зеленое развертывание (когда две практически идентичные рабочие среды используются для выпуска и отката новых версий с нулевым временем простоя) и канареечное развертывание (позволяющее передать новый код на тестирование группе пользователей до развертывания для всех пользователей). При помощи переключателей функциональности можно даже программно доставлять функциональность выбранным пользователям, что позволяет определенными группами пользователей легко тестировать новые возможности.


Заключение

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=836986
ArticleTitle=Управление точками отказа при проектировании облачных приложений
publish-date=09242012