Методы достижения высокой отказоустойчивости

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

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

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

A = (F - (D + R))/F

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

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

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

В любой дискуссии о высокой отказоустойчивости следующий набор правил можно считать не обсуждаемым:

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

Высокая отказоустойчивость SQL Server

Отказоустойчивость часто меряется в "девятках" - процентах, выражающих количество времени в году, когда система находится в рабочем состоянии. Четыре девятки (99,99 %) означают, что система находится в нерабочем режиме не больше 52 минут в году. Пять девяток означают, что режим бездействия в сумме не превышает 5,26 минут в году. А шесть девяток дают допустимое отклонение от работоспособного режима всего 32 секунды в году. В зависимости от особенностей бизнеса, это время может включать время запланированных простоев. По мере стремления достичь большего числа "девяток" отказоустойчивости, приемы управления должны совершенствоваться вместе с технологическими решениями.

Можно достичь пяти девяток отказоустойчивости, делая упор на три основные технологии SQL Server 2000 - отказоустойчивую кластеризацию, перемещение журналов и репликацию. Еще один аспект отказоустойчивости рассматривается во врезке "Восстановление после сбоя тоже означает отказоустойчивость".

Любая дискуссия о высокой отказоустойчивости должна начинаться с обсуждения версий SQL Server, которые можно использовать. Чтобы прийти к конфигурациям с высокой отказоустойчивостью, необходимо задействовать версию SQL Server 2000 Enterprise Edition. Только Enterprise Edition поддерживает отказоустойчивую кластеризацию и пересылку журналов. Хотя можно достичь высокой отказоустойчивости и в версии Standard Edition, в ней вы ограничены в использовании репликации и настраиваемой пересылке журналов. Рассмотрим эти три ключевые для отказоустойчивости технологии.

Отказоустойчивая кластеризация

Самая главная технология высокой отказоустойчивости в SQL Server 2000 - это отказоустойчивая кластеризация. В статье "Кластеризация SQL Server" Брайан Найт подробно описывает процесс настройки двухузлового кластера SQL Server 2000 в Windows 2000 Enterprise Edition. До SQL Server 2000 отказоустойчивая кластеризация была реализована плохо. Однако разработчики Microsoft полностью переписали отказоустойчивую кластеризацию в SQL Server 2000, и теперь технология стала простой для применения благодаря наличию в SQL Server 2000 многих новых возможностей. Управление кластером осуществляется точно так же, как управление SQL Server, установленным на одной машине. Пока вы не сядете за настольную систему и не запустите утилиту для настройки кластеризации Cluster Administrator, SQL Server ничем не выдаст того факта, что он работает на кластере. Такая прозрачность упрощает администрирование кластера.

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

Когда на части оборудования (узле), на котором работает SQL Server, происходит сбой, SQL Server отключается. Служба Microsoft Cluster перемещает владельца дисков на другой узел и запускает службу SQL Server. Восстановление ресурсов на кластере происходит примерно за 15 секунд при нормальных условиях. Однако не все понимают последствия отключения и перезапуска SQL Server. Когда SQL Server запускается, выполняется особый последовательный процесс, называемый возвращением к исходному режиму. Важнейшая часть возвращения к исходному режиму - фаза "отменить/повторить исправления" базы данных. Фаза "повторить исправления" всегда короткая; она контролируется настройкой интервала восстановления. В фазе "отменить исправления" все зависит от того, как было запрограммировано приложение. Существенно увеличивать время восстановления кластера могут долго исполняемые транзакции.

Пусть, к примеру, пользователь инициирует операцию в базе данных, на выполнение которой требуется 6 часов. В момент 5:59:00 от начала процесса происходит сбой на узле, где запущен SQL Server. За дело берется служба Cluster, перемещает ресурсы и перезапускает SQL Server не более чем через 15 секунд. Несмотря на то, что восстановление после сбоя на кластере произошло за 15 секунд, пользователи теперь должны ждать примерно 6 часов, прежде чем их данные снова станут доступными, что обусловлено наличием фазы "отменить исправления" в процессе возвращения к исходному режиму. Если бы разработчик написал это приложение так, чтобы оно работало восстанавливаемыми порциями с максимальной длительностью от 3 до 5 секунд, кластер восстановился бы, и данные снова были бы доступны пользователям в пределах 20 секунд после сбоя на первичном узле. Другая область, где умелая разработка может создать повышенную отказоустойчивость на уровне конечного пользователя, - управление соединениями и транзакциями внутри приложения. SQL Server всегда SQL Server независимо от того, на каком оборудовании он работает. Если пользователь подключается к кластеризованному SQL Server, на котором неожиданно происходит сбой, последует отключение сеанса пользователя. Для продолжения работы все, что нужно сделать пользователю, это восстановить подключение к SQL Server. Разработчики могут воспользоваться данной возможностью и сделать переключение кластеров прозрачным для пользователей, программируя приложение так, что оно обнаруживает отключение от SQL Server, ждет несколько секунд, затем восстанавливает подключение. Сразу после подключения приложение должно быть в состоянии повторно выполнить любые транзакции, которые не были завершены до сбоя. Такой перенос центра тяжести на приложение основан на том, что гибкая системная архитектура обеспечивает сохранность пользовательских данных даже во время системного сбоя.

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

Перемещение журналов

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

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

Можно использовать пересылку журналов для достижения многократно повышенной избыточности данных в гораздо большем числе сред, чем в средах с кластерами. Например, Windows Server 2003 Datacenter Edition поддерживает максимум восемь узлов в кластере. Но единственное, что вас ограничивает в количестве вторичных серверов, которые можно задействовать для перемещения журналов, это объем инфраструктуры, которым вы в состоянии управлять; вы можете создать столько резервных копий, сколько хотите. Перемещение журналов может выполняться на значительно больших расстояниях, чем переключение между узлами кластера. Большинство отказоустойчивых кластеров ограничены расстоянием примерно от 80 до 100 миль. В случае перемещения журналов только возможность провести кабель между первичным и вторичным серверами ограничивает географическое распределение вторичных серверов.

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

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

Репликация

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

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

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

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

Это может показаться жестким ограничением и имеет значительные последствия для механизма репликации, но не слишком сильно ухудшает отказоустойчивость. При реализации репликации для целей отказоустойчивости обычно задействуют не меньше трех серверов. Publisher - это первичный сервер, где приложения пересылают все транзакции. Subscriber - вторичный сервер, который действует как двойник первичного, доступный в случае сбоя на первичном сервере. Единственная задача третьего сервера, Distributor, - гарантировать доставку транзакций на вторичный сервер. Как только транзакции копируются с Publisher на Distributor, Distributor доставляет их на Subscriber. Такая схема позволяет приложению немедленно переключаться на вторичный сервер, даже если, возможно, не все транзакции на вторичном сервере были проведены, поскольку Distributor гарантирует их доставку. Вообще, то, насколько хорошо вы управляетесь с этой задержкой в процессе обеспечения отказоустойчивости данных, определяет то, насколько быстро вы сможете переключиться в аварийной ситуации с первичного сервера на вторичный. В идеальных условиях кластеризация позволяет достичь аварийного переключения примерно за 15 секунд, перемещение журналов позволяет достичь переключения за время примерно от 1 до 2 минут, а репликация дает немедленное переключение.

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

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

Три способа достижения высокой отказоустойчивости

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

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

Майкл Хотек - независимый консультант, специализирующийся на вопросах использования репликаций, восстановлении после сбоев и настройке производительности. Он поддерживает сайт mssqlserver.com и имеет сертификат SQL Server MVP. С ним можно связаться по адресу: mhotek@columbus.rr.com.

Восстановление после сбоя тоже означает отказоустойчивость

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

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

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