Использование хранилища реплицированных данных для максимальной связи между удаленными сайтами (часть 1)

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

Введение

С появлением объединенных ферм серверов Citrix возникли вполне предсказуемые проблемы. Так как Citrix теперь поощряет использование одной фермы, когда это возможно, расстояние между серверами Citrix в одной ферме является реальностью, с которой сталкиваются многие администраторы. Серверы часто организуются в зоны на основе физического местоположения, при этом сборщик данных зоны передает трафик между зонами и обратно на сервер хранилища данных. Хотя это, безусловно, приемлемый метод, он может вызвать проблемы с производительностью на некоторых фермах. Если между зонами существуют медленные сетевые условия, точное отслеживание нагрузки на сервер и мониторинг серверных событий часто не имеют качества в реальном времени. Одним из возможных решений этой проблемы является использование реплицированных хранилищ данных. В этой статье из двух частей я сосредоточусь на репликации хранилищ данных в Microsoft SQL 2000. Часть 1 посвящена основам репликации и некоторым определениям терминов, которые мы будем использовать во второй части.

Что такое репликация?

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

При работе с Citrix Data Store наша главная задача — согласованность и обратная связь в режиме реального времени. Это означает, что нам нужен метод репликации, гарантирующий постоянную синхронизацию между реплицируемыми сайтами. И к счастью для нас есть один! Что требуется для Citrix, так это распределенные транзакции. Распределенные транзакции полагаются на координатора распределенных транзакций Майкрософт (MS DTC), чтобы гарантировать, что на каждом сайте будут одни и те же данные в одно и то же время. Это делается с помощью протокола, известного как двухфазная фиксация. Это означает, что каждый сайт должен согласиться с изменениями, прежде чем они будут зафиксированы.

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

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

Вторая причина, по которой стоит подумать о реализации хранилища реплицированных данных, — это избыточность и аварийное восстановление. Если вы поддерживаете отдельный сайт, который можно использовать в случае объявленной чрезвычайной ситуации, наличие реплицированной базы данных, уже подключенной к сети и активной, может составлять разницу между часами работы по восстановлению и простой сменой DSN. Предположим, у вас есть два сайта, A и B. Сайт A — это ваш основной сайт с сотней серверов Citrix, а сайт B — гораздо меньшее место с 20 серверами Citrix. Сайт B был назначен вашей компанией сайтом аварийного переключения. Серьезный кризис происходит на сайте А и выводит из строя блок SQL, содержащий ваше хранилище данных. Если вы спланировали заранее и у вас есть доступное хранилище реплицированных данных, процесс замены любых серверов Citrix, которые все еще работают на сайте A, на SQL-сервер сайта B, будет минимальным. Очевидно, что это может привести к снижению производительности для пользователей сайта А, но это ничуть не лучше производительности!

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

Как распределенные транзакции работают с хранилищем данных

Давайте рассмотрим пример распределенных транзакций и то, как будет выглядеть хранилище данных. Мы назовем себя Alpha Company с вышеупомянутыми площадками A и B. Площадка A — это наш региональный центр обработки данных в Северной Америке, а площадка B — завод. Процесс создания реплицированного хранилища данных такой же, как и при репликации любой другой базы данных SQL. Это можно резюмировать так:

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

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

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

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

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

Вывод

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

на нашу рассылку новостей об обновлениях статей в режиме реального времени