Техника быстрого перезапуска вместо сохранения хорошего состояния (доступность и согласованность)

Question

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

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

Я слышал, что Amazon / Google имеет кластер из множества узлов. И одним из важных свойств каждого узла является то, что он может перезапустить в считанные секунды. Таким образом, если один из них выходит из строя, то для возврата его в исходное состояние достаточно просто перезапустить его.

Существуют ли какие-либо языки / структуры / шаблоны проектирования, которые используют эту технику в качестве первоклассного гражданина?

РЕДАКТИРОВАТЬ Ссылка, которая описывает некоторые принципы Amazon, а также общие принципы доступности и согласованности: http://www.infoq.com/presentations/availability-consistency

Answer 1

Это на самом деле очень редко в мире Unix / Linux. Эти oses были разработаны (как и окна), чтобы защитить себя от плохо управляемых процессов. Я уверен, что Google не полагается на жесткий перезапуск для исправления некорректно работающего программного обеспечения. Я бы сказал, что эту технику не следует использовать, и если кто-то скажет, что самый лучший путь к восстановлению для их программного обеспечения, вы должны искать что-то еще!

Answer 2

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

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

Звучит достаточно просто, верно? Ну, большая часть исследований была направлена ​​на реализацию этой идеи. Причина именно в том, что вы и другие комментаторы указали: перезапуски ОС слишком медленные, чтобы быть жизнеспособным методом восстановления.

РПЦ опирается на три основные части:

1. Метод выявления неисправностей как можно раньше.
2. Средство изоляции неисправного компонента при сохранении остальной части системы.
3. Перезапуск на уровне компонентов.

Реальное ключевое различие между ROC и типичным подходом «ночной перезагрузки» заключается в том, что ROC - это стратегия, в которой перезагрузки являются реакцией. Я имею в виду, что большая часть программного обеспечения написана с некоторой степенью обработки ошибок и их восстановления (бросание и отлов, логирование, повторные циклы и т. Д.). Программа ROC обнаружит ошибку (исключение) и немедленно выход. Смешение двух парадигм просто оставляет вам худшее из обоих миров - низкую надежность и ошибки.

Answer 3

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

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

Answer 4

Я видел это в нескольких местах на уровне приложения (приложение перезапускается, если оно бомбит).

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

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

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

Answer 5

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

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

Answer 6

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

Я видел, как сайт на 50 пользователей наносил ущерб как SQL Server Enterprise Edition (с базой данных 750 МБ), так и серверу Novell из-за плохого управления соединениями в сочетании с чрезмерными вызовами и отсутствием кэширования. Novell была всегда виновником, по словам разработчиков, пока мы не нашли пропущенный вызов "CloseConnection" в основной библиотеке. К тому времени тысячи были потрачены, безуспешно, на обновления, чтобы устранить эту недостающую строку кода.

(Почему у них Enterprise Edition было за пределами меня, так что не спрашивайте !!)

Answer 7

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

Я собираюсь догадаться, что аналогичная техника (но более сложная) используется для Amazon / Google.