Устойчивость приложений: поддерживайте доступность приложений Windows

Введение

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

Что такое устойчивость приложений?

Устойчивость приложения — это способность приложения и окружающей его инфраструктуры продолжать предоставлять жизненно важные функции во время сбоя и предсказуемо восстанавливаться после неудачи.

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

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

Устойчивость приложений — это не только время безотказной работы сервера

Распространенная ошибка заключается в том, что доступность сервера используется как прокси для доступности приложения, которое работает на сервере.

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

Инфраструктура → Операционная система → Приложение → Зависимости → Путь доступа → Пользовательская сессия → Бизнес-процесс

Проблема с любым элементом в этой цепочке может привести к тому, что приложение станет фактически недоступным.

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

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

Почему устойчивость приложений отличается для приложений Windows?

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

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

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

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

В каком случае может произойти сбой доступности приложения Windows?

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

Хосты приложений

Приложение, работающее на одном сервере Windows, имеет явную единую точку отказа.

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

Базы данных, хранилище и другие зависимости

Многие приложения Windows зависят от услуг, внешних для хоста приложения. Эти услуги могут включать:

• SQL базы данных
• файловые ресурсы
• лицензионные серверы
• Active Directory
• Система доменных имен (DNS)
• сертификаты
• APIs
• промежуточное программное обеспечение
• сетевое хранилище
• инфраструктура печати

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

Аутентификация и идентификация

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

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

Сети и пути удаленного доступа

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

Давайте представим полную цепочку:

Устройство пользователя → Интернет или LAN → шлюз → хост приложения → серверные услуги

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

Конечные точки

Устойчивость приложений не обязательно требует, чтобы обычная рабочая станция пользователя была доступна.

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

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

Каков процесс создания устойчивости приложений для Windows?

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

1. Определите критически важные приложения и бизнес-процессы

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

Две цели восстановления переводят бизнес-требования в технические спецификации. Руководство NIST по планированию на случай непредвиденных обстоятельств определяет Цель Времени Восстановления (RTO) и Цель Точки Восстановления (RPO) как ключевые параметры для определения требований к восстановлению:

• Целевое время восстановления (RTO): продолжительность допустимого времени простоя до восстановления услуги.
• Целевой уровень восстановления (RPO): интервал допустимой потери данных, измеряемый во времени.

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

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

2. Отобразите всю цепочку зависимостей приложения

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

Не останавливайтесь на исполняемом файле или сервере Windows. Не забывайте о базах данных, хранилищах, аутентификации, DNS, сетях, сертификатах, системах лицензирования, шлюзах и внешних сервисах.

Для каждого, спросите:

Что произойдет с приложением, если это исчезнет?

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

3. Устраните критические единичные точки отказа

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

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

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

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

4. Отделите приложения от отдельных конечных устройств

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

Централизация приложений на управляемых Windows-хостах и представление интерфейса приложения пользователям устраняет этот риск. Данные и состояние приложения хранятся на управляемом Windows-хосте и доступны авторизованным конечным устройствам.

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

5. Предоставьте более одного практического метода доступа

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

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

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

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

6. Мониторинг до того, как деградация станет сбоем

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

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

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

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

7. Планирование пиков нагрузки и резервирования

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

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

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

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

8. Защита данных и конфигурации

Замена сервера Windows мало полезна, если ИТ не может восстановить компоненты, необходимые для работы приложения.

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

Стратегия будет варьироваться в зависимости от Цели Восстановления Времени (RTO) и Цели Восстановления Данных (RPO) приложения.

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

9. Уменьшите радиус воздействия изменений

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

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

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

10. Дизайн для плавного ухудшения

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

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

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

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

Как IT-команды должны контролировать устойчивость приложений?

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

Реалистичная модель состоит из нескольких слоев:

Слой	Что мониторить	Пример сбоя
Хост	ЦП, ОЗУ, диск, доступность ОС	Сервер перегружен или недоступен
Приложение	Статус процесса и услуги	Сбой приложения
Зависимость	База данных, DNS, идентичность, хранилище	Приложение запускается, но не может работать.
Доступ	Шлюз, портал, сетевой путь	Пользователи не могут подключиться
Сессия	Активные пользователи, сбои, задержка	Приложение в сети, но неработоспособно
Бизнес-функция	Успешное завершение рабочего процесса	Пользователь не может выполнить требуемую задачу

Слой бизнес-функций является одним из самых простых для упущения.

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

Как следует тестировать устойчивость приложения?

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

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

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

Операционные процедуры являются неотъемлемой частью устойчивой системы. Процедуры эскалации оповещений: кто получает оповещение? Кто имеет полномочия для инициирования переключения на резервный режим? Где хранятся документы по восстановлению и учетные данные? Какая зависимость должна быть активирована первой?

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

Что может быть в контрольном списке устойчивости приложений?

Перед тем как приступить к созданию устойчивого критического приложения для Windows, ИТ-команды должны быть в состоянии ответить на следующие вопросы:

• Какие бизнес-процессы зависят от приложения?
• Каковы его RTO и RPO?
• Какие серверы, базы данных и внешние сервисы требуются?
• Где находятся его критические единичные точки отказа?
• Может ли другой хост принимать пользователей, если один хост выходит из строя?
• Могут ли пользователи подключаться, если их обычный конечный пункт или местоположение недоступны?
• Достаточно ли резервной мощности для работы в условиях деградации?
• Инфраструктура, зависимости и проблемы сессий активно мониторятся?
• Администраторы получают уведомления перед тем, как важные пороги станут сбоями?
• Защищены ли данные приложений и конфигурация?
• На самом деле была ли протестирована восстановление?
• Можно ли откатить проблемные изменения?
• Восстановительная последовательность задокументирована?
• Могут ли пользователи завершить необходимый бизнес-процесс после восстановления?

Не все ответы требуют дорогостоящей инфраструктуры высокой доступности. Правильный уровень защиты зависит от стоимости и операционного влияния простоя.

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

Как TSplus может помочь сохранить доступность приложений Windows?

Для организаций, которые полагаются на существующие приложения Windows, мы можем помочь улучшить доступность, централизуя приложения на управляемых серверах Windows и предоставляя их пользователям через совместимые с RDP клиенты, доступ в стиле RemoteApp или веб-портал на основе HTML5. Это снижает зависимость от отдельных конечных устройств пользователей и дает ИТ-командам больше гибкости, когда пользователям необходимо подключиться с другого устройства или местоположения.

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

Заключение

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

Для существующих приложений Windows устойчивость часто достигается за счет укрепления окружения вокруг программного обеспечения, а не за счет перестройки самого приложения. Ключевое испытание остается простым: когда происходит сбой, могут ли пользователи продолжать работать или может ли ИТ восстановить необходимую бизнес-функцию в пределах согласованного окна восстановления?