Обновление приложения со 100% временем безотказной работы

В прошлом интервью меня спросили, как мне написать критически важную службу Windows, которая должна поддерживать 100% -ное время безотказной работы, быть очень отзывчивым, а также быть обновляемым. Служба была описана как удаленное приложение, которое принимает запросы, выполняет вычисления и отправляет ответ.

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

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

Кто-нибудь строит что-либо с аналогичными требованиями? Какие решения вы использовали? Что не работает? Является ли отражение полезным вариантом?

Ответ 1

.Net имеет встроенную поддержку обновления сборок во время использования. Он называется Shadow Copy и эффективно копирует сборки в отдельный каталог перед их загрузкой. Вам все равно нужно выгрузить приложение, прежде чем вы сможете загружать новые версии, но другие приложения могут по-прежнему использовать старые версии сборки. Таким образом, один appdomain может обслуживать запросы во время загрузки нового приложения. Это также то, как IIS и ASP.Net обрабатывают вещи.

Ответ 2

Нет такой вещи, как 100% времени. Даже самые лучшие системы измеряют простои как "5 девяток", что означает 99,999% времени.

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

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

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

Ответ 3

100% времени безотказной работы? "Пять девяток" означает 315 секунд простоя в год. Если бы вы могли это сделать, вы бы очень хорошо себя чувствовали.

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

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

Ответ 4

Хорошо, немного фона, я работаю в Wireless Telecom, где наши платформы требуют абсолютного времени безотказной работы, и, увидев все различные стратегии, вы абсолютно не должны использовать программный подход, это добавляет сложность программного обеспечения, где все, что вам нужно do - добавить некоторое оборудование.

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

Итак, что вам нужно, это два балансировщика нагрузки Cisco, настройте HSRP между ними для перехода на другой ресурс между балансировщиками нагрузки. Вы можете быть очень агрессивны с настройками восстановления после сбоя, но, по нашему опыту, слишком агрессивно с ними могут возникнуть ненужные отказы. Кроме того, убедитесь, что вы отключили proxy-arp (это сэкономит вам страдание, поскольку cisco по умолчанию работает).

Теперь у вас есть кластер серверов приложений? Таким образом, у вас есть ping-балансировщики нагрузки, ping портов и время отклика приложений для приложения. Все, что вам нужно, это, по крайней мере, два сервера, но вы можете добавить более позднее (где план емкости?). Итак, теперь наступает бесконтактное обновление, во время окна обслуживания, из балансировки нагрузки вы можете управлять одним из вас сервером. Но балансировщик нагрузки может делать действительно вики-админы, где текущие соединения остаются, пока они не закончатся естественным образом.

В этом состоянии любые запросы переходят на второй сервер, и вы все время в мире делаете все, что хотите, на сервере, который вы обновляете. Как и в самом деле, зачем писать приложение, в котором есть оживленная вещь для перезагрузки домена, когда вам понадобится перезагружать сервер каждые 3 месяца, чтобы использовать критический патч для Windows? Просто выложите наличные деньги для аппаратного обеспечения и получите что-то, что будет работать в 100% случаев, и вы можете попасть в диапазон этих 5x 9 даже с незапланированными проблемами.

Теперь вот следующий шаг, географическая избыточность. У Cisco есть продукт балансировки нагрузки, который может выполнять географическую балансировку нагрузки, но я никогда не видел его. Лучшая геограхическая модель, которую я видел, фактически основана на запрашивающем приложении. Это не бесконтактное обновление, но абсолютно надежное. Что вы делаете, в запрашивающем приложении настраивается первичный IP-адрес сервера и сервера отказоустойчивости. Заявка в нем запрашивает, будет ли сервер недоступен, инициирует тот же запрос в режиме ожидания, который в этом случае может находиться в одной и той же серверной комнате или в месте резервного копирования. Идеал был бы комбинацией, где приложение может ориентироваться на виртуальный IP-адрес балансировки нагрузки в одном месте или в месте резервного копирования, и вы можете использовать балансировщик нагрузки для поддержания 100% в каждом местоположении.

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

Удачи.

Ответ 5

Spring dm Server утверждает, что может выполнять горячее развертывание/развертывание пакетов OSGi. Если аппаратное обеспечение может оставаться достаточно длинным, вы сможете обновить приложение, не доведя сервер до отказа. Если это произойдет, это станет стандартной функцией для всех серверов приложений Java EE.