Разработка и внедрение эффективных стратегий аварийного восстановления с помощью технологий Citrix. Часть 2. Стратегия

Опубликовано: 24 Апреля, 2023

Введение

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

Сценарий

Давайте посмотрим на это с точки зрения традиционной среды Citrix с использованием Presentation Server 4. Возьмем ферму с 5 серверами приложений PS4 и компьютером NFuse/Secure Gateway. Хранилище данных размещено в среде SQL2000 вместе с базой данных Resource Manager. Installation Manager устанавливается и используется для развертывания приложений, когда это возможно, но есть некоторые установки, которые необходимо выполнить вручную. Установленными приложениями являются SAP, Office, электронная почта и самодельное приложение базы данных. Приложения устанавливаются следующим образом:

Сервер A: офис, электронная почта
Сервер B: офис, электронная почта
СерверC: SAP
СерверD: SAP
ServerE: Приложение БД

Доступны два центра обработки данных. Серверы A, C и E размещаются в DC1 вместе с сервером SQL, сервером лицензий и блоком NFuse/Secure Gateway. Серверы B и D находятся в DC2.

Хочу ли я аварийного восстановления или отказоустойчивости?

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

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

Разбивка компонентов

Серверы приложений. Мы уже рассмотрели это немного выше. Серверы приложений были разделены между контроллерами домена для обеспечения полной отказоустойчивости и аварийного восстановления. Если один центр обработки данных выйдет из строя, ваши серверы приложений по-прежнему будут доступны в другом для пользовательских подключений с предостережениями, обсуждаемыми ниже. Если вы хотите сделать еще один шаг в обеспечении аварийного восстановления, вы также можете поддерживать набор машин в месте аварийного восстановления, которые используются ТОЛЬКО в случае реальной ситуации аварийного восстановления. В настоящее время мы делаем это для наших собственных критически важных приложений. Несколько серверов Citrix размещены на размещенном сайте аварийного восстановления. Второй набор приложений, идентичный исходным, публикуется с этого сервера в папке с пометкой DR в программном окружении пользователя. Доступ к этим полям возможен только в том случае, если объявлено истинное DR, и у пользователей есть инструкции о том, когда переключаться на набор приложений папки DR.

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

Сервер лицензирования — MPS3 и PS4 переместили лицензирование из хранилища данных в реальный процесс сервера лицензий. Он должен быть размещен на машине, на которой работает IIS, и ваши серверы приложений будут периодически запрашивать у ящика статус лицензии. Каждый раз, когда сервер приложений перезагружается, он подключается к серверу лицензий, а затем локально кэширует количество лицензий. Это позволяет отключить сервер лицензий на срок до 30 дней, прежде чем серверы приложений больше не будут разрешать подключения, что является долгожданным изменением по сравнению со старой моделью. Файлы лицензий загружаются с MyCitrix.com и импортируются в консоль сервера лицензий. К сожалению, файлы лицензий генерируются на основе имени хоста и не будут работать на других серверах лицензий без их восстановления в Mycitrix и последующего перераспределения на новый сервер.

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

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

Хранилище данных. Один из самых сложных вопросов, связанных с созданием настоящей среды аварийного восстановления, заключается в том, как вы обращаетесь со своим хранилищем данных. В наши дни большинство администраторов предпочитают размещать хранилище данных на внешнем компьютере, таком как сервер SQL 2000. До появления MPS3 потеря хранилища данных была действительно критическим событием. У вас было 96 часов, чтобы восстановить хранилище данных, в противном случае подключение невозможно. Поскольку лицензирование было отделено от хранилища данных и ему был предоставлен льготный период в 30 дней, критичность хранилища данных значительно снизилась. Если ваше хранилище данных не работает, изменения конфигурации не могут быть внесены в среду фермы. Однако ваши пользователи не окажут никакого влияния на доступ к их приложениям, и у вас, по сути, будет статическая среда, пока вы не сможете восстановить ее.

Однако в более крупных средах может возникнуть критическая потребность в доступе к хранилищу данных. Например, без возможности изменения конфигурации вы не сможете указать своим серверам новый сервер лицензий. Для подобных ситуаций есть несколько вариантов. Если требуется решение высокой доступности, то кластеризация сред ОС и SQL является очень действенной тактикой. Это еще и дорого! Для многосайтовой отказоустойчивости и аварийного восстановления может быть установлена репликация SQL. Это то, что мы решили сделать с нашей размещенной средой аварийного восстановления. Хранилище данных SQL в реальном времени реплицируется в нашу размещенную среду аварийного восстановления, в которой размещены серверы аварийного восстановления Citrix. Эти машины аварийного восстановления должны указывать на хранилище оперативных данных (репликация — это улица с односторонним движением, иначе ваши данные будут не синхронизированы) и переключаться на отказоустойчивый SQL-сервер в случае аварийного восстановления. Сервер-реплика должен быть повышен до рабочего сервера, чтобы вывести его из режима только для чтения.

Вывод

Для небольших сред, использующих локальное хранилище данных, важно регулярно создавать резервные копии хранилища данных с помощью команды резервного копирования dsmaint. Это создаст плоский файл, резервную копию которого можно будет создать и восстановить, используя любую используемую методологию резервного копирования. В заключительной части этой серии статей мы рассмотрим восстановление файлов хранилища данных и стратегии аварийного восстановления для остальной части нашей среды Citrix. Мы также рассмотрим альтернативные стратегии предоставления доступа к приложениям в периоды простоя. Так что следите за обновлениями!