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

Question

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

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

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

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

Редактировать Ссылка, описывающая некоторые принципы, лежащие в основе Amazon, а также общие принципы доступности и согласованности:http://www.infoq.com/presentations/availability-consistency

Answer 1

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

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

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

ROC опирается на три основные части:

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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