Группа обеспечения доступности баз данных: выходя за пределы "A"

Article
12/05/2011

Оригинал статьи опубликован в пятницу, 16 сентября 2011 г.

Определения

Все мы знаем, что в Microsoft Exchange "DAG" обозначает "Группа обеспечения доступности баз данных".

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

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

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

Википедия дает следующие определения "доступности":

Показатель того, насколько система, подсистема или оборудование находятся в заданном рабочем состоянии и удовлетворяют требованиям при начале эксплуатации, в случае начала эксплуатации в неизвестное, т. е. случайное время. Проще говоря, доступность — это доля времени, в течение которой система находится в рабочем состоянии. Этот показатель часто называют уровнем готовности к выполнению задачи . Математически он выражается как 1 минус недоступность.
Соотношение (a) полного времени, в течение которого функциональный модуль может использоваться во время заданного интервала времени, к (b) длительности этого интервала.

В терминах теории вероятностей оба определения означают одно и то же: вероятность того, что заданная система или компонент "работают" или "могут использоваться" (т. е. доступны ) в любой случайный момент времени (когда мы их проверяем).

Математически это можно представить с помощью вычисления времени, в течение которого система доступна ("время работы"), на некотором большом и статистически показательном периоде (обычно год), разделенном на суммарную длительность периода. Если использовать широко применяемые термины среднее время между сбоями (MTBF) и среднее время восстановления (MTTR) (первый представляет время работы между сбоями, а второй — время простоя системы во время любого из сбоев), то доступность можно выразить как их соотношение:

Противоположным математическим показателем будет вероятность сбоя ("недоступность"):

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

Уровень доступности	Значение доступности	Вероятность сбоя	Допустимое время простоя в год
Две девятки	99 %	1 %	5256 минут = 3,65 дня
Три девятки	99,9 %	0,1 %	525,6 минуты = 8,76 часа
Четыре девятки	99,99 %	0,01 %	52,56 минуты
Пять девяток	99,999 %	0,001 %	5,26 минуты

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

Влияние зависимостей службы на доступность

Доступность базы данных почтовых ящиков Exchange зависит от доступности многих других служб и компонентов. Например, от подсистемы хранения, в которой размещается база данных, от сервера, который обрабатывает базу данных, от сетевых подключений к серверу и т. п. Все это — критические компоненты, и сбой любого из них будет означать прекращение обслуживания, даже если сама база данных полностью работоспособна. Это значит, что для того, чтобы база данных была доступна как служба, все ее зависимости также должны быть доступны. Если правильно обозначить и изолировать компоненты зависимости, можно будет математически вычислить, как они влияют на конечную доступность самой базы данных почтовых ящиков Exchange.

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

Дисковая подсистема или хранилище базы данных. Назовем их доступность A₁.
Сервер почтовых ящиков (оборудование и ПО). Назовем его доступность A₂.
Сервер клиентского доступа (CAS) (оборудование и ПО). Вспомним, что в Exchange 2010 все клиенты подключаются к серверу базы данных почтовых ящиков только через сервер клиентского доступа. Также допустим, что в данном случае CAS установлен отдельно от сервера почтовых ящиков. Назовем его доступность A₃.
Сетевое подключение между клиентами и сервером клиентского доступа, а также между сервером клиентского доступа и сервером почтовых ящиков. Назовем его доступность A₄.
Система электропитания в центре обработки данных, в котором располагаются серверы и хранилище. Назовем ее доступность A₅.

Этот список можно продолжать… Например, Active Directory и DNS также представляют собой критические зависимости для Exchange. Более того, кроме чисто технологических зависимостей, на доступность влияют процессные зависимости, такие как уровень зрелости процесса эксплуатации и т. п.: человеческий фактор, неправильно заданные операции, недостаток координации — все это может вести к простою службы. Мы не будем пытаться составить исчерпывающий список зависимостей, а сосредоточимся на том, как они влияют на общую доступность службы.

Так как описанные компоненты сами по себе не зависят друг от друга, доступность каждого представляет независимое событие, а конечная доступность базы данных почтовых ящиков Exchange представляет собой сочетание всех этих событий (другими словами, чтобы база данных почтовых ящиков была доступна клиентам, все указанные компоненты должны быть доступны). Из теории вероятностей следует, что вероятность сочетания независимых событий является произведением вероятностей каждого из них:

Например, если бросить три монеты, вероятность выпадения орлов на всех трех монетах составляет (1/2)*(1/2)*(1/2) = 1/8.

Важно понять, что так как каждое отдельное значение доступности не может быть больше единицы (или 100 %), а конечная доступность службы является просто произведением доступности отдельных компонентов, то значение конечной доступности не может быть больше наименьшей доступности компонентов зависимости.

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

Компонент критической зависимости	Вероятность сбоя	Значение доступности
Сервер почтовых ящиков и система хранения	5 %	95 %
Сервер клиентского доступа	1 %	99 %
Сеть	0,5 %	99,5 %
Электропитание	0,1 %	99,9 %
Вся служба (зависит от всех перечисленных выше компонентов)	6,51383 %	95% x 99% x 99,5% x 99,9% = 93,48617 %

Из этого примера можно видеть, сколь важны зависимости службы. Доступность базы данных почтовых ящиков, которая никогда не ломается (никогда не повреждается, никогда не заражается вирусами и т. д.), уже находится на уровне, меньшем 93,5 %!

Вывод: большое число зависимостей службы снижает доступность.

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

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

Влияние избыточности на доступность

Концептуально все способы повышения уровня избыточности означают одно: имеется несколько экземпляров компонентов, которые доступны и могут использоваться либо параллельно друг с другом (как в случае балансировки нагрузки), либо в качестве замены (как в случае нескольких копий базы данных). Предположим, что у нас есть n экземпляров определенного компонента (n серверов в массиве CAS или n копий баз данных в DAG). Даже если один из них выходит из строя, другие экземпляры по-прежнему могут использоваться, поддерживая надлежащий уровень доступности. Единственная ситуация, когда возникает действительный простой, — это сбой всех экземпляров.

Как было определено ранее, вероятность сбоя любого экземпляра составляет P = 1 – A. Все экземпляры статистически независимы друг от друга. Это означает, что доступность или сбой любого из них не влияет на доступность других экземпляров. Например, сбой определенной копии базы данных не влияет на вероятность сбоя другой копии базы данных (возможное исключение здесь заключается в распространении логического повреждения базы данных с одной поврежденной копии базы данных на все другие копии, но пока исключим этот маловероятный фактор — все же, для устранения этой проблемы можно реализовать отложенное копирование базы данных или традиционное резервное копирование на определенный момент времени).

Используя снова ту же теорему из теории вероятности, вероятность сбоя набора n независимых компонентов является произведением вероятностей каждого из них. Так как все компоненты одинаковы (разные экземпляры одного объекта), результат будет степенью:

Очевидно, что так как P < 1, Pⁿ меньше P. Это значит, что вероятность сбоя уменьшается, а уровень доступности, соответственно, повышается:

Рассмотрим для ясности практический пример. Предположим, что мы развертываем несколько копий базы данных почтовых ящиков; каждая копия размещается на отдельном диске SATA. Статистически процент выходящих из строя дисков SATA составляет примерно ~5 % в год[1], что дает нам 5 % вероятность сбоя: P = 0,05 (это соответствует доступности в 95 %: A = 0,95). Как изменится доступность, если будет добавлено больше копий базы данных? Посмотрите на следующую таблицу, которая говорит сама за себя:

Число копий базы данных	Вероятность сбоя	Значение доступности
1	P₁ = P = 5 %	A₁ = 1 – P₁ = 95 %
2	P₂ = P² = 0,25 %	A₂ = 1 – P₂ = 99,75 %
3	P₃ = P³ = 0,0125 %	A₃ = 1 – P₃ = 99,9875 %
4	P₄ = P⁴ = 0,000625 %	A₄ = 1 – P₄ = 99,9994 %

Впечатляет, не правда ли? В общем случае каждая дополнительная копия на диске SATA дает множитель в 5 % или 1/20, поэтому вероятность сбоя с каждой копией становится в 20 раз меньше (и, соответственно, доступность повышается). Можно заметить, что даже с самыми ненадежными дисками SATA развертывание только четырех копий базы данных поднимает уровень доступности базы данных до пяти девяток.

Это уже очень хорошо, но можно ли еще улучшить результат? Можно ли повысить доступность, не производя архитектурных изменений (т. е. если добавление "еще одной" копии базы данных невозможно)?

Как ни удивительно, это можно сделать. Если улучшить доступность каждого из компонентов зависимости, повысится и общий уровень доступности службы. Также это приведет к более сильному эффекту от добавления компонентов избыточности. Одним из возможных способов реализации такой схемы, не грабя банк, является использование дисков Nearline SAS вместо дисков SATA. Диски Nearline SAS имеют процент годовых сбоев ~2,75 % вместо ~5 % у SATA. Это уменьшит вероятность сбоя компонента хранения в приведенных выше вычислениях и, следовательно, повысит общую доступность службы. Сравните эффект от добавления нескольких копий базы данных:

Средний процент сбоев в 5 % = множитель 1/20 = каждая новая копия уменьшает вероятность сбоя базы данных в 20 раз.
Средний процент сбоев в 2,75 % = множитель 1/36 = каждая новая копия уменьшает вероятность сбоя базы данных в 36 раз.

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

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

Компонент критической зависимости	Вероятность сбоя	Значение доступности
Сервер почтовых ящиков и система хранения (4 копии)	5% ^ 4 = 0,000625 %	99,999375 %
Сервер клиентского доступа (4 сервера, установленных раздельно)	1% ^ 4 = 0,000001 %	99,999999 %
Сеть	0,5 %	99,5 %
Электропитание	0,1 %	99,9 %
Вся служба (зависит от всех перечисленных выше компонентов)	0,6 %	99,399878 %

Можно видеть, что просто благодаря развертыванию четырех серверов клиентского доступа и четырех копий базы данных вероятность сбоя всей службы уменьшилась более чем в 10 раз (с 6,5 % до 0,6 %), и доступность службы увеличилась с 93,5 % до существенно более достойного значения в 99,4 %!

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

Синтез, промежуточный

Из предыдущих заключений возникает интересный вопрос. Мы проанализировали два разных фактора, влияющих на общую доступность службы двумя разными способами, и пришли к двум простым выводам:

Добавление зависимостей системы снижает доступность.
Добавление избыточности в компоненты зависимости системы повышает доступность.

Что произойдет, если оба фактора присутствуют в имеющемся решении? Какая тенденция сильнее?

Рассмотрим следующую ситуацию:

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

В первом случае серверы почтовых ящиков независимы и будут недоступны только если оба сервера выйдут из строя. Вероятность сбоя для набора из двух серверов почтовых ящиков будет равна P × P = P². Соответственно, их доступность будет равна A_MBX = 1 – P². Следуя той же логике, службы клиентского доступа будут недоступны только если оба сервера клиентского доступа выйдут из строя, поэтому вероятность сбоя для набора из двух серверов клиентского доступа тоже будет P × P = P². Соответственно, их доступность будет равна A_CAS = 1 – P².

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

Продолжаем рассматривать ситуацию… Чтобы вся система была доступна, оба набора серверов (набор серверов почтовых ящиков и набор серверов клиентского доступа) должны быть доступны одновременно. Не выходить из строя одновременно, а быть доступными одновременно, так как теперь они представляют системные зависимости, а не компоненты избыточности. Это значит, что общая доступность службы является произведением доступности каждого из наборов:

Конечно, второй случай существенно проще, так как в нем только один сервер, который надо учесть, и его доступность это просто A = 1 – P.

Итак, значения доступности для обоих случаев вычислены, какое же из них больше, (1–P²)² или 1–P?

Если мы нарисуем графики обеих функций, откроется следующая картина:

(Для простого и быстрого создания графика я использовал бесплатную вычислительную систему Wolfram Alpha Mathematica Online).

Можно видеть, что для небольших значений P доступность сложной четырехсерверной системы больше, чем доступность одного сервера. Здесь нет ничего удивительного; это то, что мы и ожидали, правильно? Но при значениях P ~ 0,618 (точнее говоря, ) эти два графика пересекаются, и для больших значений P система из одного сервера имеет большую доступность. Конечно, на практике хотелось бы иметь значение P близкое к нулю; но если вы планируете создавать свое решение из очень ненадежных компонентов, то, вероятно, лучше использовать один сервер.

Влияние областей сбоя

К сожалению, в реальных условиях развертывания редко бывают настолько простыми. Например, как доступность службы изменится, если развертываются серверы с несколькими ролями? Мы заметили в ситуации выше, что объединение ролей сервера сокращает число зависимостей службы, поэтому это может быть хорошим фактором? Что произойдет, если разместить две копии базы данных на одном массиве SAN или в одном модуле DAS? Что если все серверы почтовых ящиков подключены к одному сетевому коммутатору? Что если имеет место все перечисленное и еще больше?

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

Области сбоя — это не обязательно плохо. Важное различие заключается в том, из каких компонентов состоит область сбоя. Являются ли они различными зависимостями системы или это избыточные компоненты системы? Рассмотрим два вышеприведенных примера, чтобы понять различие.

Сервер с несколькими ролями

Сравним доступность двух различных систем:

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

В первом случае оборудование одного сервера является областью сбоя. Это значит, что все размещенные роли либо доступны, либо недоступны. Это просто — общая доступность такой системы A = 1 – P.

Во втором случае вся служба будет доступна только если оба сервера доступны независимо (так как каждая из ролей представляет собой критическую зависимость). Поэтому, основываясь на теории вероятностей, доступность службы будет составлять A × A = A².

Так как A < 1, это значит, что A² < A, поэтому во втором случае доступность будет меньше.

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

Вывод: совместное размещение серверных ролей Exchange на сервере с несколькими ролями повышает общий уровень доступности службы.

Общее хранилище

Теперь рассмотрим другую ситуацию области сбоя (две копии базы данных расположены в общем массиве хранения данных) и сравним доступность базы данных в следующих двух случаях:

Две копии базы данных размещены в одном общем хранилище (массиве SAN или модуле DAS), имеющем вероятность сбоя P.
Те же копии базы данных размещены в двух отдельных системах хранения, каждая из которых имеет такую же вероятность сбоя.

В первом случае общее хранилище представляет собой область сбоя. Как и в предыдущей ситуации, это значит, что обе копии базы данных доступны или недоступны одновременно, поэтому общая доступность составляет A = 1 – P.

Во втором случае вся служба будет доступна, если хотя бы одна система доступна, а недоступна только в том случае, если обе системы выйдут из строя. Рассматриваемые системы хранения данных независимы, поэтому вероятность сбоя для всей службы будет P × P = P², а соответствующая общая доступность службы вычисляется как A = 1 – P².

Так как P < 1, P² < P, и поэтому 1 – P² > 1 – P. Это значит, что доступность во втором случае больше .

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

Итак, в чем различие между двумя описанными ситуациями, почему введение области сбоя повышает доступность в первом случае и снижает ее во втором?

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

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

(Нет, мы не использовали Wolfram Alpha для построения этого графика).

Заключение

Архитектура Exchange 2010 предоставляет широкие возможности для добавления избыточности на уровне Exchange (например, развертывание нескольких копий базы данных или нескольких серверов клиентского доступа в массиве CAS), а также для сокращения числа зависимостей системы (посредством объединения серверных ролей Exchange на базе сервера с несколькими ролями или использования более простой архитектуры хранения данных без огромного числа критических компонентов). Простые правила и формулы, представленные в статье, позволят вам вычислять влияние на доступность различных факторов, таких как развертывание дополнительных копий базы данных или объединение серверных ролей Exchange. Вы также сможете вычислить влияние областей сбоя. Важно заметить, что мы попытались использовать простые математические модели для иллюстрации концепций, а не для того, чтобы получить точные значения доступности. Реальные явления редко укладываются в простые ситуации, и вам требуются существенно более сложные вычисления для получения удовлетворительных оценок доступности реальных систем. Возможно, будет иметь смысл просто измерить доступность статистически и проверить, удовлетворяет ли она требованиям соглашения об уровне обслуживания. Однако понимание влияющих на доступность факторов и их взаимодействия в сложном инженерном решении должно помочь вам должным образом разработать решение и достичь существенного повышения общей доступности службы, удовлетворяющей даже самым высоким требованиям.

Борис Лохвицкий (Boris Lokhvitsky)
Архитектор по реализации

[1] Следующие исследования Университета Карнеги — Меллон, компании Google и подразделения Microsoft Research показывают, что средняя сбойность дисков SATA составляет 5 %:

https://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf

https://labs.google.com/papers/disk_failures.pdf

https://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2005-166