Александр Гладченко Организация репликации Microsoft SQL Server 2000 с учётом внешних и внутренних ограничений системы

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

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

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

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

Ограничения репликации Аппаратные ограничения сервера. Наиболее существенное влияние на производительность сервера оказывает дисковая подсистема. Количество дисков, их конфигурация и производительность естественным путём определяют производительность системы в целом, т.к. диски являются наиболее медленными устройствами доступа к данным. Для балансирования загрузки центрального процессора, который обрабатывает данные считываемые с дисков, используется промежуточный, оперативный буфер, которым является память сервера. Недостаток памяти может привести к увеличению дисковых операций, что неизбежно приведёт к падению производительности. Количество центральных процессоров также влияет на общую производительность сервера, т.к. определяет возможность параллельной обработки операций. При наличии мощной системы ввода – вывода использование всего одного процессора может стать узким местом всей системы. PCI шина также имеет ограниченную пропускную способность. Если она обслуживает большое количество устройств, она может не успеть их обслужить с приемлемой для системы скоростью. Сетевой интерфейс в многопользовательской среде также может ограничить производительность системы, если сетевая плата будет наводнена пакетами клиентских компьютеров.

Ограничения репликации Ограничения локальной сети. Наиболее распространённой сетевой средой локальных, вычислительных сетей сегодня является Ethernet. Практически повсеместно используются сети пропускной способностью 100 Мб/сек. Необходимо помнить и об ограничениях, которые накладывает такая сеть. Сети Ethernet являются коллизионными, т.е. возникающие одновременно в сети два пакета отклоняются оборудованием сети и повторяются через случайный промежуток времени, разный для каждого из пакетов. Наличие большого числа коллизий может привести к снижению производительности операций, которые сервер баз данных осуществляет через сеть. Сети Ethernet имеют ограничение на протяжённость сегмента. Превышение длинны сегмента может привести к тому, что ответ о получении пакета не буде вовремя получен узлом его ожидающим. Такая ситуация приводит к потерям пакетов, что тоже негативно отражается на производительности. Сети Ethernet имеют ограничение на число соединений между парой устройств активного сетевого оборудования. Превышение установленного стандартом числа розеток, пачкордов и пачпанелей может увеличить время отклика и породить неоднородности или аномалии в сети, снижающие её производительность. Протяжённость сети, наличие между серверами большого количества активного и пассивного сетевого оборудования имеющего собственную задержку обработки запроса, также может снижать производительность, хотя будут соблюдены требования стандарта и каждый участок в отдельности будет работать с высокой производительностью.

Ограничения репликации Ограничения глобальной сети и «тонких» коммуникаций. Сегодня многие локальные сети связаны между собой протяжёнными коммуникационными линиями, имеющими меньшую пропускную способность, чем ЛВС. Для этого применяются модемные соединения через обычные телефонные линии или выделенные линии, каналы Т1 и Е1, фрейм-релейные сети, радио Ethernet и т.д. По существу, все такие соединения накладывают ограничения на пропускную способность коммуникаций между серверами и имеют высокие значения задержки передачи запросов. Используемое на коммуникационном канале оборудование, контролирующее заявленную полосу пропускания, при превышении трафика может «резать» превышающие трафик пакеты. Провайдеры глобальных сетей не всегда могут гарантировать заявленную полосу пропускания, возможна перегрузка канала на отдельных участках глобальной сети, что может отразиться на вашем трафике.

Ограничения репликации Ограничения, накладываемые выбором операционной системы. Версия Win 95, 98, ME Win NT4 WS Win NT4 Win NT4 EE Win 2K Prof. XP Win 2K Serv. Win 2K AS Win 2K Data center Win.NET Persona и Desktop Да SP5 и выше Да N/A Evalua- tion и Develop Нет SP5 и выше Да N/A StandartНет SP5 и вы ше Нет Да 4 узлаN/A Enterpr.Нет SP5 и выше Нет Да N/A (64-bit)Нет Да

Ограничения репликации Ограничения, накладываемые выбором операционной системы. Функции издателя EnterpriseStandardPersonalDeveloperDesktopCEEvaluation Snapshot Replication Есть НетЕсть Transactiona l Replication Есть Только подписчик Есть Только подписчик НетЕсть Merge Replication Есть Только анонимный подписчик Есть Immediate Updating Subscriptions Есть НетЕсть Queued Updating Subscribers Есть НетЕсть

Ограничения репликации Ограничения, влияющие на репликацию. Зависимость работы компонент MS SQL Server 2000 от производительности репликации В представленном ниже списке перечислены основные мероприятие, реализация которых поможет снять наиболее типичные ограничения репликации: Установка фиксированного или минимального (не меньше 16MB) объема ОЗУ для SQL Server. Использование отдельных дисков для transaction log (RAID1) и для всех баз данных, включенных в репликацию (RAID 0+1 или 5). Увеличение памяти для серверов, используемых в репликации. Использование мультипроцессорных компьютеров. Установка фиксированного размера для базы Distribution. Публикация только необходимого количества данных. Запуск Snapshot Agent только когда это необходимый и не во время пиковой нагрузки, что бы избежать блокировки. Размещение папки моментальных снимков на диске, не используемом для хранения базы данных или журналов. Использование по одной папке для моментальных снимков каждой публикации, что бы сократить количество операций для поддержки снимков в других папках. Использование сжатых файлов моментальных снимков.

Ограничения репликации Ограничения, влияющие на репликацию. Зависимость работы компонент MS SQL Server 2000 от производительности репликации Сокращение частоты копирования изменений на дистрибутор при большом количестве подписчиков. Запуск Distribution и Merge агентов как можно реже (в пределах, допустимых бизнес-правилами) позволяет сократить количество операций. Использование pull или анонимных подписок позволяет разгрузить издателя/дистрибутора. Аналогично, действует использование Remote Agent Activation. Анонимные подписки не хранят информацию о подписке в БД Distribution. Установить уровень подробности хронологии работы агентов репликации в '0' кроме периода тестирования, контроля или отладки. Можно получить экономию %. Запуск агентов в непрерывном режиме вместо очень частого их запуска в виде задания по расписанию. Использование параметра -UseInprocLoader в свойствах запуска агента позволяет поднять эффективность за счёт разрешения использования команды BULK INSERT (кроме OLE DB или ODBC подписчиков). Старайтесь создавать дополнительные триггеры, индексы и представления на издателе, а не на подписчиках. Старайтесь избегать использование горизонтальных фильтров, поскольку log reader агент будет применять фильтр к каждой строке. Вместо этого можно использовать DTS.

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

Учёт ограничений при развёртывании системы с репликацией Учёт аппаратных ограничений. Размещение файлов, отличающихся по типу доступа (последовательный или случайный), на разных дисках позволит существенно сократить потери времени на перемещения головок жёстких дисков. Размещение баз данных издателя и дистрибутора на разных дисках. Размещение журналов транзакций на отдельных дисках. Размещение моментальных снимков на отдельном диске. Размещение операционной системы на отдельном диске. Размещайте массивные реплицируемые таблицы или индексы на отдельных дисках. Оптимизация работы SQL Server за счёт грамотного использования файлов и filegroupsОптимизация работы SQL Server за счёт грамотного использования файлов и filegroups

Учёт ограничений при развёртывании системы с репликацией Учёт аппаратных ограничений. Использование высокопроизводительных массивов жёстких дисков RAID. RAID 1 или 0+1 для журналов. RAID 1 или 0+1 или RAID 5 (когда операции записи не превышают 10%) для баз данных. Количество RAID контроллеров должно соответствовать загрузке PCI шины дисковой подсистемой. При конфигурировании RAID массива, продумайте оптимальный размер блока. Используйте RAID контроллеры с собственным источником резервного питания. Используйте сервера с дублированными PCI и SCSI шинами. Использование достаточного размера оперативной памяти. В идеале размер ОЗУ должен быть одного порядка с размером базы данных. Используйте мультипроцессорные системы. Дублируйте сетевые адаптеры. Дополнительный сетевой адаптер желательно включать в другой сегмент сети.

Учёт ограничений при развёртывании системы с репликацией Учёт аппаратных ограничений. Используйте высокопроизводительные сетевые адаптеры. Ниже представлен пример репликации БД размером 5Гб в разных сетях Ethernet: 10Мб – 1,4 часа. 100Мб – 8,3 минуты. 1Гб – 51 секунда. Используйте скоростные каналы для репликации через интернет. Разносите сеансы репликации разных подписчиков по времени.

Учёт ограничений при развёртывании системы с репликацией Учёт системных ограничений. Плохо установленная или плохо работающая операционная система – это плохо работающая репликация. Используйте только тома NTFS. Установите для временных папок короткие пути, например, C:\TEMP. Не располагайте файлы баз данных в каталогах с длинными или русскими именами. Лучше так: D:\MSSQL\DATA\mydb.mdf Для больших баз данных (от 1Гб) применяйте ОС и СУБД корпоративного масштаба. Не используйте на сервере СУБД другие серверные и прикладные системы. Это уменьшит число переключений между задачами. Отключите все неиспользуемые ОС сервисы. Оставьте операционной системе необходимый минимум оперативной памяти, а остальное отдайте СУБД. Правильный выбор операционной системы и издания сервера баз данных также позволит Вам избежать лишних потерь производительности.

Учёт ограничений при развёртывании системы с репликацией Учёт системных ограничений. Задействуйте для СУБД максимально возможное число доступных системе процессоров. Оптимизируйте работу операционной системы для обслуживания большого количества клиентских подключений и внутренних процессов. Обеспечьте минимальную фрагментацию файлов баз данных и журналов. Помните, что встроенный в W2K дефрагментатор поддерживает только диски со стандартным размером блока - 4Кб. Используйте последние версии Internet Explorer 6.0SP1. Его компоненты используются при получении снапшота через FTP. Оперативно обновляйте систему и СУБД при выходе новых сервисных пакетов и заплаток. Предварительно проверив работоспособность системы на полигоне. Используйте последние версии драйверов. Используйте последние версии MDAC 2.7

Учёт ограничений при развёртывании системы с репликацией Учёт сетевых ограничений. Для локализации коллизий используйте сегментацию сети. При планировании сети соблюдайте стандарты. Контролируйте утилизацию сети. Имейте возможность диагностировать всю топологию вашего внешнего и внутреннего коммуникационного канала для репликации. Размещайте сервера в центральных сегментах. Обеспечьте высокую производительность центральных сегментов. Обеспечьте максимально возможную пропускную способность для внешнего коммуникационного канала, используемого для репликации. Лучше иметь для этого отдельный канал, не используемый для других целей. Будьте осторожны в применении диагностических и журналирующих сетевой трафик систем. Плохо спланированная локальная сеть или недостаточная пропускная способность интернет – канала также могут создать проблемы при организации репликации.

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

Рекомендации по развёртыванию систем с репликацией через Internet Производительность репликации можно регулировать параметрами запуска агента синхронизации. Существует несколько стандартных профилей запуска агентов репликации, настроить которые для всех подписчиков можно в окне Agent Profiles, которое доступно по правой кнопке мыши на папке Replication, пункт меню: Configure Publishing, Subscribers, and Distribution, кнопка Agent Profiles.

Рекомендации по развёртыванию систем с репликацией через Internet Сценарий организации репликации через ограниченные коммуникационные каналы Предопределённые профили для Distribution агента: ПараметрЗначение По умолчанию Continue on data consistency errors Verbose history agent profile. Windows Synchronization Manager profile -BcpBatchSize CommitBatchSize 100 -CommitBatchThreshold HistoryVerboseLevel KeepAliveMessageInterval 300 -LoginTimeOut 15 -MaxBcpThreads MaxDeliveredTransactions PollingInterval 10 -QueryTimeOut 300 -SkipErrors 2601:2627: TransactionsPerHistory 100

Рекомендации по развёртыванию систем с репликацией через Internet Предопределённые профили для Marge агента:

Рекомендации по развёртыванию систем с репликацией через Internet Сценарий организации репликации через ограниченные коммуникационные каналы Предопределённые профили для Snapshot агента: ПараметрЗначение По умолчанию -BcpBatchSize HistoryVerboseLevel2 -LoginTimeOut15 -MaxBcpThreads1 - QueryTimeOut300

Рекомендации по развёртыванию систем с репликацией через Internet Сценарий организации репликации через ограниченные коммуникационные каналы

Рекомендации по развёртыванию систем с репликацией через Internet Рекомендации по конфигурированию компонент репликации. Для гарантированного соединения подписчика с издателем/дистрибутором, необходимо увеличить время, отводимое для подключения и запроса в Enterprise Manager, пункт меню: Tools/Options/Advanced. Например, Login time-out (seconds) = 60, Query time-out (seconds) = 60. Псевдоним, под которым работает издатель/дистрибутор, должен совпадать с именем сервера издателя/дистрибутора. Если система разрешения имён не может идентифицировать сервер подписчика по имени, необходимо средствами утилиты Client Network Utility создать псевдоним этого сервера, привязав имя сервера к IP адресу и транспортному протоколу. Логин, под которым подписчик работает с издателем во время сеанса синхронизации (для каждого подписчика он должен быть заведён на издателе/дистрибуторе), должен иметь право на SELECT в таблице systypes реплицируемой базы данных.

Рекомендации по развёртыванию систем с репликацией через Internet Рекомендации по конфигурированию компонент репликации. В конфигурации смешанного подключения серверов через Proxy Server и без него, когда часть серверов – подписчиков находится внутри корпоративной сети, а часть серверов находится за пределами файервола и подключаются к порту через WinSock, необходимо использовать разные сетевые протоколы для обмена издателя с подписчиками внутри и вне сети. Для подписчиков, которые подключаются через прослушиваемый издателем порт на Proxy Server, необходимо использовать библиотеку TCP/IP, а для подписчиков, которые находятся внутри корпоративной сети, можно использовать другой протокол, например, библиотеку для именованных каналов. Рассмотрите возможность выполнения рекомендаций BOL в статье Enhancing Replication Performance.

Рекомендации по развёртыванию систем с репликацией через Internet Рекомендации по конфигурированию компонент репликации. Установка Merge репликации: Пошаговое руководство Репликация транзакций, выполняющаяся в Non-Continous режиме Настройка TCP/IP для издателя (publisher) и дистрибутора (distributor) при публикации через FTP Настройка Proxy Server для поддержки репликации SQL Server через Internet Фильтрация реплицируемых данных Как автоматизировать репликацию с подключением через модем

Рекомендации по развёртыванию систем с репликацией через Internet Настройка компонент системы, влияющих на утилизацию коммуникационных каналов. В статье Утилиты репликации MS SQL Server представлен полный список и описание параметров запуска агентов репликации, задаваемых через командную строку запуска исполняемых файлов агентов.Утилиты репликации MS SQL Server Многие из этих параметров предназначены для регулирования производительности работы агента репликации и могут быть использованы для тонкой настройки порождаемого агентом трафика или для снижения/повышения утилизации системных ресурсов.

Рекомендации по развёртыванию систем с репликацией через Internet Настройка компонент системы, влияющих на утилизацию коммуникационных каналов. Управление трафиком: -MaxDeliveredTransactions -MaxDownloadChanges -MaxUploadChanges -PacketSize -StartQueueTimeout Управление нагрузкой: -CommitBatchSize -CommitBatchThreshold -MaxBcpThreads -BcpBatchSize -Buffers -UseInprocLoader -PollingInterval -SrcThreads -DestThreads -UploadReadChangesPerBatch -DownloadGenerationsPerBatch -UploadReadChangesPerBatch -DownloadReadChangesPerBatch -UploadWriteChangesPerBatch -DownloadWriteChangesPerBatch -ReadBatchSize -ReadBatchThreshold -MaxCmdsInTran Не документированный параметр: ForceConvergenceLevel для Merge Agent Новый Trace Flag, разрешающий модификацию Singleton для репликации транзакций Краткие рекомендации по настройке и оптимизации репликации транзакций

Рекомендации по мониторингу репликации через Internet Стандартные средства мониторинга. Для административного мониторинга работы репликации удобно использовать Replication Monitor входящий в состав SQL Server Enterprise Manager. Кроме самого факта работоспособности агентов, наиболее удобным параметром для оценки эффективности работы в рамках одного сеанса репликации является продолжительность сеансов – Duration. Окно Refresh Rate and Settings, закладка General, опция Inactivity threshold позволяет установить такое значение периода опроса агентов репликации на подписчике, что бы агент не переводился преждевременно в неактивное состояние, из-за допустимых перерывов в связи или аппаратных отключений.

Рекомендации по мониторингу репликации через Internet Стандартные средства мониторинга. Для оперативного мониторинга работы агентов репликации удобно использовать уведомления SQL Mail, настроенные на критические события, регистрируемые как на издателе, так и не подписчиках. Настройка SQL Mail для Microsoft SQL сервера.Настройка SQL Mail для Microsoft SQL сервера Подробную информацию о работе агентов репликации можно посмотреть в истории исполнения заданий агента и в истории работы агента. Эта информация наиболее полезна для локализации проблем в работе агентов репликации.

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

Рекомендации по мониторингу репликации через Internet Стандартные средства мониторинга. Вывод расширенной информации о работе агентов репликации SQL Server в текстовый файл Важным моментом диагностики и мониторинга работы системы с репликацией является контроль трафика локальной сети, а ещё в большей степени, контроль трафика через внешние коммуникации. Современное коммуникационное оборудование позволяет удобным образом визуализировать информацию о трафике, например, вот такую статистику способны выдавать маршрутизаторы Cisco:

Рекомендации по мониторингу репликации через Internet Рекомендуемые для контроля события. Replication Monitor предлагает использовать ряд предопределённых событий, большинство из которых полезно использовать в процессе промышленной эксплуатации. Некоторые события, такие как Agent success и Agent retry полезны на этапе отладки репликации. Для оперативного контроля безопасности серверов, участвующих в репликации через интернет, можно добавить несколько оповещений по следующим стандартным событиям: Permission Denied Access is denied due to a password failure, Login fails, Access denied, Denied login access.

Рекомендации по мониторингу репликации через Internet Организация оперативных оповещений. В случае длительного прерывания сеансов репликации, может наступить момент, когда выгодней не дожидаться синхронизации всех накопленных изменений, а применить свежий снапшот. При большом размере публикации это может оказаться весьма продолжительной и дорогостоящей операцией. Что бы избежать такой ситуации, желательно настроить рассылку оповещений обо всех критичных событиях в системе репликации на Ваш пейджер или в виде SMS сообщений на мобильный телефон. Желательно завести также оператора последней надежды, что бы гарантировать доставку таких уведомлений.

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

Устранение неполадок Реакция на системны сбои. Сверка данных при Merge репликации Тюнинг подсистем I/O для SQL Server Семь наиболее полезных счётчиков эффективности Реакция на коммуникационные проблемы. Появление коммуникационных проблем, особенно при репликации через интернет, чревато лавинообразным ростом трафика репликации. Например, значительный посторонний трафик может привести к существенному увеличению сеансов репликации. Задания на запуск агентов будут отрабатывать долго, и практически сразу запускаться снова. Возрастёт количество сбоев в передаче данных и повторов попыток агента провести сеанс синхронизации данных. Увеличится доля служебного трафика, и так далее, подобно эффекту снежного кома… В таких случаях, самым простым и действенным средством на время локализации коммуникационных проблем, является изменение расписания запуска сеансов репликации. Разнесение по времени сеансов разных подписчиков также позволит сократить взаимное влияния из трафика друг на друга.

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

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

Устранение неполадок Реакция на коммуникационные проблемы. Вашему вниманию прелагается алгоритм и необходимые для его реализации хранимые процедуры и функции, который позволяет отслеживать продолжительность сеанса репликации и динамически менять интервал между сеансами в зависимости от загрузки канала. Суть алгоритма в том, что мы задаём минимально возможный интервал между сеансами и максимально возможную продолжительность сеанса, по достижении которой сеанс должен быть остановлен. В нашем случае, считается, что периодичность не должна быть меньше заданного минимального значения и не должна превышать максимальное время, заданное для ограничения продолжительности сеанса. Кроме того, для задания периодичности, с которой будут запускаться последующие сеансы, вычисляется продолжительность последнего сеанса и если она больше минимального значения и меньше максимального значения, а также отличается более чем на 10% от текущей периодичности, это значение принимается для параметра Occurs every задания на запуск агента репликации.

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

Вопросы? Александр Гладченко