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

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

Введение

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

Восстановление хранилища данных

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

Что ж, давайте начнем с рассмотрения сценария, как он был представлен в прошлой статье. Хранилище данных размещено в среде SQL2000 вместе с базой данных Resource Manager. Очевидно, что это более сложная ситуация, чем простое хранилище данных Access. Я не могу сказать вам, как важно для вас ваше хранилище данных. Честно говоря, это индивидуальный выбор, который каждой организации придется сделать для достижения своих целей. Давайте рассмотрим два общих требования, которые менеджеры любят предъявлять своим бедным переутомленным администраторам:

Хранилище данных должно быть ВСЕГДА доступно

Честно говоря, вы не можете гарантировать это. Вы можете подойти чертовски близко, хотя! Для начала вы, вероятно, захотите кластеризовать свою среду SQL. В Windows 2003 Enterprise установка SQL2000 с пакетом обновления 3 (SP3) в кластерной среде на самом деле является довольно безболезненным процессом. Однако ограничения кластеризации Microsoft остаются в силе. Поскольку кластер будет активным/пассивным, один сервер останется неиспользованным, пока основной не будет переведен в автономный режим. Кроме того, отработка отказа будет происходить только в условиях, которые служба кластера распознает как сбой. А из-за требований к общему пространству кворума и данных становится очень сложно найти кластерные серверы на любом реальном расстоянии друг от друга для реальной ситуации аварийного восстановления.

Кластерная среда обеспечивает отказоустойчивость на локальном уровне. Однако для настоящей защиты от аварий необходимо иметь план удаленного восстановления. Это может означать горячее оборудование на резервной площадке и репликацию SQL для баз данных хранилища данных. Доставка журналов также возможна с SQL, но с некоторыми важными оговорками. Если вас беспокоит постоянное время безотказной работы, доставка журналов может привести к значительному времени восстановления в зависимости от количества транзакций в вашей базе данных. Когда вы используете доставку журналов как средство резервного копирования и восстановления, база данных должна обработать эти журналы в режиме восстановления, прежде чем она сможет стать работоспособной. Если вы не обновляли свою базу данных в течение года и только что отправляли эти журналы на свой сайт аварийного восстановления, то будьте готовы к ОЧЕНЬ больным, когда вы запускаете этот режим восстановления.

Итак, у вас есть кластер, репликация или доставка журналов… вы в безопасности, верно? Ну, наверное. Но что, если (и я знаю, что схожу с ума здесь) ваш сервер аварийного восстановления выйдет из строя? Никогда не бывает, верно? Это то, о чем я думал. Но забавная вещь случается, когда вы оставляете серверы аварийного восстановления бездействующими в течение года, толком не наблюдая за ними. Они, как правило, терпят неудачу, и вы часто не осознаете этого, пока не придет время, когда они вам понадобятся. Так что ты можешь сделать? Конечно, вы кластеризуете свою среду аварийного восстановления! Итак, теперь у вас есть свой работающий кластер, ваш кластер аварийного восстановления и, возможно, SQL-репликация между рабочим сервером и сервером базы данных аварийного восстановления. Я признаю, что это сумасшедшая ситуация. У вас есть 2 активных сервера, 2 резервных сервера и много резервирования. Все для вашего хранилища данных Citrix!

Я не могу сказать, что искренне рекомендую эту ситуацию. В моем случае на сервере базы данных размещалось несколько других важных баз данных, и мое небольшое хранилище данных было захвачено в процессе. Однако я признаю, что теперь я абсолютно не опасаюсь какого-либо отказа хранилища данных! Однако важно понимать, что эта среда ПО-ПРЕЖНЕМУ не соответствует требованиям управления, заключающимся в том, что хранилище данных должно быть всегда доступно. В реплицированной среде вам все равно придется заставить реплицированный SQL-сервер работать в качестве живой среды. Вам также придется изменить DSN на каждом сервере, чтобы он указывал на новый SQL-сервер, если вы не используете какую-либо форму псевдонимов DNS. Настройка репликации SQL — чрезвычайно сложная задача, если вы не являетесь опытным администратором SQL. Citrix предоставила ОЧЕНЬ подробную документацию на своем веб-сайте для настройки этой репликации, но для ее выполнения все еще требуется хорошее понимание SQL Server. Я не рекомендую настраивать репликацию без помощи ваших администраторов баз данных, если вы сами не разбираетесь в SQL.

Хранилище данных не так важно, как возможность подключения пользователя!

Это еще одно распространенное отношение менеджеров, и оно часто является правильным. В конце концов, вы можете довольно долго бегать без него. Конечно, ваши возможности сильно ограничены в отношении управления вашей средой Citrix. Но пока ваши пользователи могут продолжать, с миром все в порядке! Ну, может быть, нет. Возможность подключения пользователей может и должна быть наивысшим приоритетом для любой фермы Citrix, но это не должно отменять вашу способность управлять собственной фермой. Однако этому отношению может быть трудно противостоять. Как правило, это тип среды, в которой вы просто собираетесь запускать плоские резервные копии базы данных и использовать их для восстановления, когда у вас будет время. Это может быть одно и то же оборудование, сайт аварийного восстановления и т. д.; Плоские резервные копии базы данных можно планировать и управлять ими с помощью администратора SQL Server. Вы хотите убедиться, что вы создали резервные копии всех соответствующих баз данных, таких как Master, а также самого хранилища данных. В противном случае вы не сможете успешно восстановить базу данных.

После того, как вы восстановили базу данных из плоских файлов, вы по-прежнему сталкиваетесь с теми же требованиями, что и выше. Вам может потребоваться внести те же самые изменения DSN или псевдонимы DNS, чтобы соединение работало. Вам также, вероятно, потребуется запустить службу IMA на всех ваших устройствах, чтобы убедиться, что они могут подключиться к новой копии хранилища данных. Хотя серверы могут работать в течение некоторого времени без хранилища данных, это действительно не лучший способ покинуть вашу среду. Мониторинг становится логистическим кошмаром. Выполнение обычных задач, таких как манипулирование сеансом пользователя, почти невозможно. И если что-то еще пойдет не так, это может занять очень много времени, чтобы диагностировать. Хотя понятно, что руководство заботится о пользовательской базе, вы должны заботиться о своей собственной способности работать.

Вывод

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

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