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

Мне задают много вопросов о лицензировании DB2 в среде HA - конфигураций, рассчитанных на исключение внеплановых (а иногда и плановых) простоев. Обычно замешательство в первую очередь вызывает широкий разброс цен, которые производители баз данных назначают на свои продукты высокой готовности.

Другая причина путаницы заключается в терминах, используемых в дискуссиях по вопросам высокой готовности. Возьмем, например, термин кластеры. В ИТ-индустрии системы высокой готовности иногда называют кластерами. Мне не нравится этот термин, так как в последнее время он слишком часто применяется для обозначения как кластеризации с целью наращивания производительности (например, с помощью функции сегментации базы данных InfoSphere Warehouse - DPF, которая базируется на DB2), так и с целью повышения готовности (например, с применением ПО кластеризации Tivoli System Automation for Multi-platforms (SA-MP), которое впервые появилось в DB2 9 и впоследствии было глубоко интегрировано в версию DB2 9.5 на группе серверов), а также для того и другого вместе (как в случае кластера DB2 pureScale или IBM Smart Analytics System). Тем не менее, этот термин в ходу, так что в данной статье под термином кластер я буду иметь в виду кластеризацию для HA (если не указано иное). Для простоты я рекомендую вам в разговоре о кластерах с клиентами или коллегами добавлять к термину "кластер" уточнение высокой готовности или масштабируемости. Конечно, с помощью кластера иногда пытаются решать задачи как масштабируемости, так и высокой готовности - так что в разговорах со своими коллегами просто всегда уточняйте, что именно вы пытаетесь сделать.

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

В литературе IBM Software Group (IBM SWG) для описания резервных серверов чаще всего используются термины холодный, теплый и горячий. До выхода DB2 9.5 в «кругах DB2» терминология несколько отличалась, но с момента появления этой версии термины по HA и лицензированию DB2 соответствуют классификации IBM SWG и той терминологии по лицензированию, которая используется при обсуждении цен. Например, если в DB2 9.1 HA-кластер конфигурировался как кластер IBM PowerHA (прежнее название: High Availability Cluster Multiprocessing - HACMP), так что один сервер находился в режиме ожидания (и не был запущен), то нужно было приобретать частичную лицензию на этот сервер. Но начиная с версии DB2 9.5 в этом случае не надо платить ни цента! Аналогично, при установке DB2 9.1 на незадействованном сервере на этот сервер также требовалась частичная лицензия. Начиная с версии DB2 9.5, для сервера, который не включен, лицензию на DB2 приобретать не нужно. Я отредактировал эту статью для версии DB2 9.7, чтобы помочь вам разобраться в правилах лицензирования DB2 для систем высокой готовности и ввести вас в курс дела.

Примечание: Эта статья относится также к технологии DB2 pureScale, анонсированной в октябре 2009 года. Средством доставки DB2 pureSCale служит DB2 9.8; при этом единственная причина переходить на DB2 9.8 – это добавление DB2 pureScale. Иными словами, если вы работаете с сервером DB2 9.7 и не планируете использовать DB2 pureScale, вам незачем переходить на DB2 9.8.

На рисунке 1 дано подробное описание классификации НА DB2 9.7 и приведены примеры конфигураций, относящихся к каждой категории.

На рисунке 2 я привел термины, наиболее часто используемые для описания систем НА, и их связь с классификацией и правилами лицензирования DB2 9.7.

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

• Какая редакция DB2 установлена?

  А именно: DB2 Express-C, DB2 Express, DB2 Workgroup, DB2 Enterprise или редакция InfoSphere Warehouse? Например, для сервера DB2 Express с недавно введенной лицензией SERVER нет понятия горячего, теплого или холодного режимов резервирования (подробнее об этом ниже). Имейте в виду, что DB2 Express-C нельзя устанавливать в конфигурации HA.

• Как используется резервная машина, пока отказ не произошел?

  Например, используется ли она в качестве рабочего сервера для выполнения транзакций и обработки запросов к DB2? Запущен ли экземпляр DB2 на этом сервере? Возможно, экземпляр выполняет ту или иную работу, но только в целях восстановления главного сервера в случае его выхода из строя; например, по сценарию High Availability Disaster Recovery (HADR). Короче, решающее значение для выбора способа лицензирования DB2 на этом сервере имеет то, что делает резервный сервер, когда все работает нормально.

• Как вы лицензировали свой сервер DB2, высокую готовность которого вы хотите обеспечить?

  Например, если вы лицензировали сервер DB2 Express с использованием новой лицензии SERVER, введенной в DB2 9.7, вам придется купить дополнительную лицензию SERVER для резервного сервера, в каком бы режиме он ни работал: горячем, теплом или холодном. Если вы лицензировали сервер DB2 Express с использованием модели Authorized User (АС), то для теплого режима резервный сервер нужно лицензировать на 5 пользователей, а для холодного, когда машина работает в режиме ожидания, его не нужно лицензировать вовсе. Если вы лицензировали сервер DB2 Express с использованием модели Processor Value Unit (PVU), то для теплого режима резервный сервер нужно лицензировать на 100 PVU, а для холодного не нужно лицензировать вовсе.

  Обзор всех серверов распределенной DB2 9 и способы их лицензирования приведены в статье "Какую распределенную редакцию DB2 9.7 выбрать?". За сравнением возможностей, функций и преимуществ различных редакций СУБД DB2 обращайтесь к статье "Сравнение серверов данных распределенной СУБД DB2 9.7".

С момента выпуска DB2 8.2 в правилах лицензирования появилось несколько замечательных дополнений, которые заметно понизили стоимость решений НА для серверов DB2. Например, в DB2 8.2, чтобы лицензировать DB2 Workgroup с HADR, нужно было приобретать пакет High Availability Feature Pack и лицензию на него для обоих серверов. В DB2 9 его уже не нужно было лицензировать для сервера, работающего в режиме ожидания. В DB2 9.5 мы сделали High Availability Feature Pack бесплатным для серверов DB2 Workgrop. Короче, с каждой новой версией стоимость среды высокой готовности на базе DB2 фактически снижается благодаря следующим изменениям:

• Когда один сервер выступает в качестве теплого резерва для нескольких рабочих серверов, теплый резервный сервер нужно лицензировать всего один раз (начиная с DB2 8.2). Например, если горячий сервер DB2 лицензирован для неограниченного числа пользователей, то для теплого резервного сервера потребуется 100 PVU. Если на 5 разных серверах производительностью 400 PVU исполняется DB2 Workgroup, и каждый сервер сконфигурирован в HADR-кластер с подхватом одного и того же сервера, потребуются лицензии только на 2100 PVU (5 серверов х 400 PVU + 100 PVU для резервного сервера), вместо 2500 PVU (5 серверов х 400 PVU) + (500 серверов по 500 PVU)).
• На сервере, который выступает в качестве теплого или холодного резерва, больше не нужно лицензировать функциональные пакеты (начиная с DB2 9). Например, если для сервера DB2 Enterprise имеется лицензия Storage Optimization Feature Pack (которая обеспечивает сжатие данных XML, таблиц, индексов, временных таблиц и т.д.), и база данных настроена для участия в HADR-кластере, достаточно приобрести только 100 PVU для DB2 Enterprise на резервный сервер.
• HADR входит в состав DB2 Workgroup без дополнительной платы (начиная с DB2 9); если оглядеться - ни один другой поставщик не предлагает такую же функциональность (на DB2 Workgroup нет никаких ограничений на технологию HADR) ни для одного сервера, ориентированного на рынок малых и средних предприятий.
• Для создания HA-кластера серверов DB2 вы получаете программное обеспечение кластеризации - Tivoli System Automation for Multi-platforms (Tivoli SA-MP) - бесплатно (начиная с DB2 9).
• Больше не нужно лицензировать машину, находящуюся в холодном резерве (начиная с DB2 9.5). Более того, некоторые поставщики заявляют о каких-то преимуществах, предлагая возможность использовать HA-конфигурацию в течение 10 дней; для DB2 вы получаете возможность, по сути, бессрочного использования подобных кластеров. Более того, впридачу вы бесплатно получаете программное обеспечение кластеризации!
• ПО кластеризации Tivoli SA-MP тесно интегрировано с DB2 (начиная с DB2 9.5) и включает в себя богатый интерфейс управления, что понижает общую стоимость владения HA-кластера.
• Вы можете объединить два сервера DB2 Express в HADR-кластер, не покупая High Availability Feature Pack, если вы лицензировали свои серверы DB2 Express по лицензии Fixed Term License (FTL) или SERVER (начиная с DB2 9.7).

Примечание: В этой статье я пишу о лицензировании сервера; однако все редакции DB2 допускают частичное лицензирование, когда лицензируется только та производительность, которую использует сервер DB2. Например, когда я говорю: "лицензирование такого-то числа PVU сервера", то при использовании технологии виртуализации нужно брать среднее число PVU для сеанса VMWare или LPAR. При таком лицензировании существуют некоторые предварительные условия, которые нужно знать, чтобы быть в курсе всех деталей до внедрения DB2 в подобной среде.

Итак, произошло много изменений, ведущих к снижению TCO HA-кластеров, как со стороны лицензирования, так и со стороны администрирования; это очень полезно, учитывая экономическую ситуацию. Теперь самое время начать обсуждение влияния HA-кластеров на лицензирование DB2 9.7 с примерами в соответствии с классификацией HA DB2. Как уже говорилось, в DB2 9.7 определены три вида резервных серверов: горячий , теплый и холодный .

Горячий резерв

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

При отказе одного из серверов передача ресурсов может, по сути, удвоить нагрузку на сервер горячего резерва (единственную сохранившуюся машину двухузлового кластера), поскольку ему теперь приходится обрабатывать свою первоначальную нагрузку, плюс нагрузку отказавшего сервера. Это необходимо учитывать при создании любой HA-среды, в которой каждый сервер поддерживает другой, но при этом имеет свое собственное соглашение об уровне обслуживания (SLA), которое он должен соблюдать. Если администратор базы данных (DBA) подчинил все свои ресурсы жестким SLA, это может оказаться не лучшим вариантом (если только размер сервера или использование передовых технологий кластеризации типа DB2 pureScale не создают условия для этого).

Итак, в DB2 сервер горячего резерва - это любая машина, используемая для обслуживания транзакций и запросов пользователей в период нормальной эксплуатации, но действующая в качестве резервной для другого сервера, который также используется для обслуживания пользовательских транзакций в периоды нормальной эксплуатации. В случае выхода из строя одного из серверов кластера сервер горячего резерва берет на себя нагрузку отказавшего сервера в дополнение к работе, которую он выполняет в период нормальной эксплуатации. Так как активная резервная машина используется для обработки пользовательских транзакций и запросов, даже если отказов не было, ее нужно лицензировать в полном объеме. Например, предположим, что имеется две базы данных на двух отдельных машинах, одна из которых работает с системой планирования ресурсов предприятия (ERP), а другая – с системой управления цепочками поставок (SCM). В случае отказа базы данных SCM машине, решающей задачи ERP, придется обслуживать также и всех пользователей SCM. Это то же самое, как если бы у вас был кластер серверов DB2, получающий задания от балансировщика нагрузки (такого как DB2 pureScale) или какого-то другого программного обеспечения. Сценарий, иллюстрирующий HA-кластер с горячим резервированием, показан на рисунке 3.

В этом примере пара серверов, которые в период нормальной эксплуатации одновременно используются для обработки транзакций и запросов (сплошными прямоугольниками обозначена нагрузка каждой машины до отказа, а заштрихованными — после выхода из строя соответствующей машины). В этом примере сценария машина 2 выходит из строя, и нагрузка переносится на ее партнера по кластеру, машину 1. Машина 1 служит горячим резервом для машины 2 (и наоборот, если внимательно посмотреть на этот рисунок – обратите внимание на заштрихованный прямоугольник для машины 1 на машине 2). Конфигурацию этого типа часто называют парой кластеров высокой готовности, отказоустойчивой парой, парой горячий/горячий или активный/активной, и она характерна для современного ИТ-ландшафта. В DB2 существует множество способов реализации кластера высокой готовности горячий/горячий, и в зависимости от того, что нужно, можно использовать функции базы данных Database Partitioning Feature (DPF), HADR в сочетании с базой данных на каждом сервере отказоустойчивого кластера, HADR (с активированным режимом Read on Standby), Q-Replication с горячим резервом для ведения отчетности посредством технологии мгновенного копирования или копирования образов дисков, применения технологии xkoto GRIDSCALE и т.д.

Опять же, обе машины 1 и 2, изображенные на рисунке 3, постоянно используются для обработки своих собственных транзакций и запросов; а когда машина 2 выходит из строя, ее нагрузка по DB2 просто переводится на машину 1. Не забывайте, что в данном случае, если не предусмотреть на машине 1 ресурсов для обработки нагрузки машины 2 в случае ее отказа (и наоборот), в результате такой передачи нагрузки могут возникнуть проблемы с производительностью. HADR-кластер может использоваться в качестве кластера горячий/горячий разными способами. Рассмотрим, например, систему, показанную на рисунке 4.

На рисунке показано, что на сервере А размещена рабочая база данных с именем Database А, а также резервная база данных в HADR-кластере с именем Database B1. В то же время на сервере В размещена рабочая база данных с именем Database В, а также резервная база данных в кластере HADR с именем Database A1. Пока отказов нет, оба сервера А и B заняты обслуживанием баз данных Database А и Database B соответственно, так что это конфигурация горячий/горячий, и оба сервера должны лицензироваться в полном объеме.

На рисунке 5 приведен пример HADR-системы с использованием функции Read on Standby, входящей в состав DB2 9.7 Fix Pack 1 и выше.

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

Наконец, на рисунке 6 приведена трехкомпонентная система DB2 pureScale.

В этом случае лицензируются только DB2 и DB2 pureScale Feature Pack на компонентах (машинах, обрабатывающих транзакции). Серверы PureScale PowerHA (CF) (которые обычно полностью дублируются) не требуют никаких лицензий на DB2 или Feature Pack. В данном примере, поскольку нагрузка по обработке текущих транзакций прозрачно распределяется между всеми компонентами, все они являются горячими, и следовательно должны лицензироваться в полном объеме.

Замечания по лицензированию машины, работающей в горячем резерве

Общее правило, при конфигурации горячий/горячий лицензирование осуществляется так же, как если бы каждый сервер работал вообще вне всякого кластера высокой готовности.

Начиная с DB2 9.7, существуют пять различных методов лицензирования (некоторые из них доступны только в определенных редакциях DB2): SERVER, Fixed Term License (FTL), SOCKET, Authorized User (AU) и Processor Value Unit (PVU). Ниже приводятся замечания по лицензированию HA-систем, которые нужно учитывать для каждой из этих лицензий.

Лицензия SERVER: Лицензия SERVER появилась только в DB2 9.7 и доступна лишь для серверов DB2 Express. При лицензировании сервера DB2 Express с использованием лицензии SERVER вы просто покупаете лицензию на каждый сервер кластера, в каком бы режиме резервирования (горячем, теплом или холодном) он ни работал. Короче, при HA-лицензировании нет необходимости определять уровень активности сервера DB2 Express, лицензируемого по лицензии SERVER. При этом не устанавливается минимальное число пользователей, не нужно выяснять значение PVU для данного сервера или что-то еще: все очень просто! Если в конфигурации горячий/горячий это правило не влияет на лицензирование (так как обе машины работают в горячем резерве), то в конфигурации с теплым резервированием требования по лицензированию сервера отличаются от требований других лицензий DB2.

Кроме того, в версии DB2 9.5, если нужно было создать HADR-кластер с использованием сервера DB2 Express, приходилось приобретать DB2 High Availability Feature Pack, чтобы получить эту функцию наряду с другими функциями, связанными с HA. В DB2 9.7 лицензия SERVER DB2 Express фактически бесплатно включает все функции высокой готовности из High Availability Feature Pack (в том числе HADR), однако если вам нужна HADR (или другие функции) с сервером DB2 Express, лицензируемым по лицензии PVU или AU, этот комплект нужно приобретать.

Лицензия FTL: Лицензия FTL тоже появилась только в DB2 Express 9.7; у нее та же методология ценообразования, что и у старых лицензий DB2 Express-C FTL 9.5 (которых больше нет), только в DB2 9.7 вы получаете доступ ко всем функциям DB2 Express, а не только DB2 Express-C. Лицензия DB2 Express FTL предоставляет доступ к программному обеспечению DB2 Express на один год - это срочная лицензия, в отличие от бессрочной лицензии, предусмотренной в других редакциях DB2. При лицензировании сервера DB2 Express с использованием лицензии FTL вы просто покупаете лицензию FTL на каждый сервер кластера - как в случае лицензий DB2 Express SERVER — в каком бы режиме резервирования (горячем, теплом или холодном) он ни работал. Короче, при HA-лицензировании нет необходимости определять уровень активности сервера DB2 Express, лицензируемого по лицензии FTL. При этом не устанавливается минимальное число пользователей, не нужно выяснять значение PVU для данного сервера или что-то еще: все очень просто! Если в конфигурации горячий/горячий это правило не влияет на лицензирование (так как обе машины работают в горячем резерве), то в конфигурации с теплым резервированием требования по лицензированию сервера отличаются от требований других лицензий DB2.

Сервер DB2 Express, лицензированный по лицензии FTL, предоставляет доступ ко всем функциям DB2 High Availability Feature Pack, включая HADR. (Заметим, однако, что при использовании лицензий DB2 Express PVU или AU, чтобы иметь возможность использовать HADR и другие функции высокой готовности, нужно приобретать этот комплект.)

Лицензия SOCKET: Лицензия SERVER тоже появилась только в DB2 9.7 и доступна лишь для серверов DB2 Workgroup. При лицензировании сервера DB2 Workgroup по лицензии SOCKET вы просто лицензируете определенное число процессорных гнезд каждого сервера, поскольку это конфигурация горячий/горячий, и все серверы в полной мере используются для обычных операций.

Например, если у вас 4-процессорный сервер IBM POWER6 с двухъядерными процессорами, вы должны купить 4 лицензии SOCKET для DB2 Workgroup. Между прочим, производительность этого сервера оценивается в 960 PVU, тем не менее, достаточно приобрести всего 4 лицензии SOCKET для DB2 Workgroup. Да, это так: используя лицензию SOCKET, можно эксплуатировать DB2 Workgroup на машине с производительностью, превышающей установленный в DB2 9.5 предел в 480 PVU (при лицензировании сервера DB2 Workgroup по лицензиям PVU или AU в DB2 9.7 вы по-прежнему ограничены 480 PVU). При конфигурации горячий/горячий вам потребовалось бы 8 лицензий SOCKET для DB2 Workgroup: 4 гнезда для главного сервера пары и 4 гнезда для резервного сервера.

Лицензия PVU: Любой сервер DB2 можно лицензировать по модели PVU. В конфигурации активный/активный нужно дополнительно лицензировать полное количество PVU сервера горячего резерва (машина 1 в нашем рабочем примере). Конечно, тот же подход нужно использовать при лицензировании сервера DB2, даже если он не является частью HA-кластера, поскольку этот сервер в любом случае выполняет работу, так что это не должно быть неожиданностью.

Если бы сервер, изображенный на рисунке 3, был сервером с четырехъядерными процессорами POWER6, и каждая машина работала бы с DB2 Workgroup (для которой по состоянию на второй квартал 2008 года серверы ограничены максимум 480 PVU), для этого решения пришлось бы приобретать 960 PVU: 480 PVU для машины 1 и 480 PVU для машины 2.

Лицензия АU: Для любого сервера DB2, лицензируемого по модели Authorized User, нужно приобретать лицензию на общее число авторизованных пользователей (AU), которые будут обращаться к нему как к основному серверу, в дополнение к соответствующему числу пользователей, которые будут иметь доступ также и к резервному серверу горячего режима (так как оба они работают со своими собственными приложениями и служат резервными серверами друг для друга).

АU – это один человек (в некоторых случаях это может быть приложение или устройство, если оно не действует от имени других пользователей) со своей учетной записью, который может находиться внутри или вне компании. Эти лицензии могут использоваться и через Интернет (как в случае приложения онлайнового банковского обслуживания), так как конечные пользователи хорошо известны, поскольку для этой лицензии они должны быть явно идентифицируемыми. Лицензии AU дают все права; нет необходимости в отдельной лицензии для сервера, как в DB2 8, когда права пользователя нужно было приобретать вместе с базовой лицензией на сервер. При использовании программного обеспечения мультиплексирования или концентрации связи эти пользователи должны быть полностью определены и подсчитаны до применения таких технологий к учетному соединению.

Лицензия АU нужна на каждого, кто обращается к серверу. Однако сколько бы пользователей ни имели доступ к вашему серверу, существуют зависящие от редакции минимумы, которые нужно учитывать. Редакции DB2 Express или DB2 Workgroup требуют минимум пять лицензий АU. DB2 Enterprise требует минимум 25 лицензий АU при производительности сервера в 100 PVU. Иными словами, на каждые 100 PVU сервера требуется пакет лицензий на 25 пользователей. Например, на сервер с 480 PVU потребуется минимум 125 лицензий АU, поскольку для определения минимального числа пользователей значение PVU округляется. Конечно, если у вас 150 пользователей, то вам придется лицензировать сервер сверх минимального количества пользователей на их фактическое количество; в данном случае на 150 AU. Лицензии AU не переносятся через рабочие смены (хотя они могут передаваться в процессе оборота кадров) и действуют только для конкретного сервера. Конечно, так как рисунок 3 служит примером конфигурации горячий/горячий, эти правила чисто теоретические, поскольку в данном случае серверы все равно должны лицензироваться как независимые.

В примере, приведенном на рисунке 3, когда есть 100 пользователей, которым требуется доступ к горячим серверам DB2 Workgroup, для этих 100 пользователей необходимо приобрести в общей сложности 200 лицензий АU DB2 Workgroup: 2 сервера по 100 AU на каждый. Даже если к серверу за все время обратились всего 12 из этих пользователей, все 100 пользователей должны иметь лицензию для каждого сервера (так что в данном примере в любом случае нужно 200 лицензий AU). Если бы на рисунке 3 фигурировали DB2 Express или DB2 Workgroup, и в компании было всего три пользователя, потребовалось бы в общей сложности 10 лицензий для DB2 Express или DB2 Workgroup (2 сервера х минимум 5 AU), чтобы удовлетворить минимальные требования по AU, предъявляемые этими редакциями DB2.

Если бы серверы, фигурирующие на рисунке 3, были серверами DB2 Enterprise, как уже говорилось, все было бы несколько иначе: давайте вернемся к примеру, где мы предполагаем, что каждый сервер – это сервер производительностью 480 PVU с 4-ядерными процессорами POWER6. Когда есть 100 пользователей, которым требуется доступ к обоим горячим серверам DB2 Enterprise, для этих 100 пользователей необходимо приобрести в общей сложности 250 лицензий АU DB2 Enterprise: 2 сервера х 125 AU на сервер, так как минимум для каждого сервера DB2 Enterprise составляет 25 пользователей на 100 PVU. Опять же, даже если к любому из серверов DB2 за все время обратились всего 12 из этих пользователей, все 125 пользователей должны иметь лицензию для каждого сервера. Если бы у серверов DB2 Enterprise на рисунке 3 было по 2 гнезда для двухъядерных процессоров Intel x86, общее число PVU для этих серверов составило бы 200 PVU на каждый сервер. Если бы в компании было всего три пользователя, потребовалось бы в общей сложности 100 AU (2 сервера х 200/100 PVU х 25 AU), чтобы удовлетворить минимальные требования по AU, предъявляемые данной редакцией DB2.

В начало

Теплый резерв

В конфигурации с теплым резервом по крайней мере один сервер в HA-кластере не имеет базы данных DB2, которая обслуживала бы транзакции или запросы пользователей в период штатной эксплуатации. Это теплый резерв в том смысле, что сервер не выполняет "полезной" работы. К работе, которая классифицируется как "бесполезная" (хотя, как ни парадоксально, это может быть самая полезная работа, какую когда-либо выполнял ваш резервный сервер), относятся действия по администрированию в аварийной ситуации, такие как перевод базы данных в состояние отложенного повтора транзакций для поддержки передачи журнала, поддержка передачи журнала на уровне транзакций для HADR-системы и т.п. Если один из серверов в HA-кластере выходит из строя, рабочая нагрузка переводится на сервер теплого резерва.

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

Примечание: Помните, что DB2 Express-C не поддерживает HA-конфигурации и, следовательно, нельзя создать HA-кластер на базе серверов DB2 Express-C.

Сценарий теплого резервирования проиллюстрирован на рисунке 7 и представляет собой типичную HADR-конфигурацию (функция Read on Standby не используется). В данном примере в периоды нормальной работы машина 2 используется для обработки транзакций и запросов (на рисунке обозначена как "Активная работа"), в то время как машина 1 находится в теплом резерве по отношению к рабочей нагрузке машины 2. Машина 2 выходит из строя, и нагрузка DB2 передается машине теплого резерва 1. В этом сценарии может случиться, что если до отказа на машине 1 выполнялась какая-то работа (любого рода), она будет приостановлена, чтобы уступить место новой рабочей нагрузке после отказа машины 2 (или машина 1 была изначально рассчитана на поддержку собственной рабочей нагрузки и нагрузки машины 2 одновременно – иначе вы опять столкнетесь с проблемой производительности).

Поскольку в период нормальной эксплуатации только одна машина является горячим сервером DB2 (рисунок 7), в то время как другая выполняет ту или иную работу в теплом режиме, такую как подготовка партнера по HADR-кластеру, эту конфигурацию часто называют конфигурацией горячий/теплый (или иногда активный/пассивный). Здесь важно помнить, что до аварии машина 1 не выполняет никакой "значимой" работы, связанной с DB2. Конечно, в системе HADR Read on Standby, DB2 pureScale или xkoto GRIDSCALE резервной машине придется выполнять значимую работу, и ни одна из этих технологий не сочетается с режимами теплого или холодного резерва.

Клиенты применяют самые разнообразные подходы в отношении резервных машин. Я рекомендую определить приоритеты своих целей и бизнес-требований в этом плане. Например, некоторые клиенты могут создать HA-систему на резервной машине и в то же время использовать резервную базу данных актуальной версии рабочей машины, предназначенную только для чтения - тем самым распределяя затраты на все большее и большее число ресурсов; это можно делать с помощью HADR, начиная с версии DB2 9.7 Fix Pack 1. Имейте в виду, что многие производители ограничивают эту модель выбором или/или; то есть в режиме базы данных для чтения нельзя прокручивать журналы вперед, чтобы сохранить их актуальными (иногда выбор или/или заменяется компромиссом в отношении допустимой скорости прокрутки вперед: как это делается в логическом резервном сервере с помощью копии текущего состояния). Затем, оставляя базу данных открытой на длительный период времени для операций чтения, вы увеличиваете среднее время восстановления (MTTR) в случае сбоя: та самая проблема, которую призвана решить данная конфигурация. Другой пример - чтение резервных баз данных OLTP. Если подумать, база данных OLTP сконструирована так, чтобы минимизировать индексы. Если на резервном сервере решаются задачи типа составления отчетов, он, вероятно, станет заниматься сканированием таблицы ввиду отсутствия индексов, способствующих ускорению поиска. Выполнение полного сканирования таблиц на резервном сервере может поглотить так много ресурсов, что это создаст проблемы для синхронизации баз данных.

В зависимости от требований по готовности, объему нагрузки, и т.д. теплый резерв может оказаться удачным или неудачным выбором для конкретной системы, однако при планировании этой системы не забывайте об основной цели реализации HA-системы — минимизация MTTR ради сокращения времени простоев. Ведь DB2 предоставляет возможности и для режима горячий/горячий (включая технологию HADR Read On Standby, которая не входила в версию DB2 9.7, когда та только появилась, но будет доступна в ближайшее время), и для новой функции DB2 pureScale. Например, если в конфигурации HADR считывать данные с резервного сервера, то этот сервер мгновенно становится горячим резервом. Вывод: то, что теплый резерв (с точки зрения DB2) — это пустая трата ресурсов, часто — очень большое заблуждение, но DB2 оставляет выбор за вами; просто помните, что DB2 может обеспечить любую желаемую конфигурацию.

Замечания по лицензированию машины, работающей в теплом резерве

Начиная с DB2 9.7, существуют пять различных методов лицензирования (некоторые из них доступны только в определенных редакциях DB2): SERVER, Fixed Term License (FTL), SOCKET, Authorized User (AU) и Processor Value Unit (PVU). Ниже приводятся замечания по лицензированию HA-систем, которые нужно учитывать для каждой из этих лицензий.

Лицензия SERVER: Лицензия SERVER появилась только в DB2 9.7 и доступна лишь для серверов DB2 Express. При лицензировании сервера DB2 Express с использованием лицензии SERVER вы просто покупаете лицензию на каждый сервер кластера в каком бы режиме резервирования (горячем, теплом или холодном) он ни работал. Короче, при HA-лицензировании нет необходимости определять уровень активности сервера DB2 Express, лицензируемого по лицензии SERVER. При этом не устанавливается минимальное число пользователей, не нужно выяснять значение PVU для данного сервера или что-то еще: все очень просто!

В HA-кластере горячий/теплый вы фактически покупаете лицензию SERVER для каждого сервера DB2 Express. Кроме того, в версии DB2 9.5, если нужно было создать HADR-кластер с использованием сервера DB2 Express, приходилось приобретать DB2 High Availability Feature Pack, чтобы получить эту функцию наряду с другими функциями, связанными с HA. В DB2 9.7 лицензия DB2 Express SERVER на самом деле бесплатно предоставляет доступ ко всем функциям, включенным в High Availability Feature Pack (в том числе HADR). Достаточно приобрести этот набор функций, чтобы использовать HADR с сервером DB2 Express, лицензируемым по лицензиям PVU или AU.

Лицензия FTL: Лицензия FTL тоже появилась только в DB2 Express 9.7; у нее та же методология ценообразования, что и у старых лицензий DB2 Express-C FTL 9.5 (которых больше нет), только в DB2 9.7 вы получаете доступ ко всем функциям DB2 Express, а не только DB2 Express-C. Лицензия DB2 Express FTL предоставляет доступ к программному обеспечению DB2 Express на один год - это срочная лицензия, в отличие от бессрочной лицензии, предусмотренной в других редакциях DB2. При лицензировании сервера DB2 Express с использованием лицензии FTL вы просто покупаете лицензию FTL на каждый сервер кластера - как в случае лицензий DB2 Express SERVER — в каком бы режиме резервирования (горячем, теплом или холодном) он ни работал. Короче, при HA-лицензировании нет необходимости определять уровень активности сервера DB2 Express, лицензируемого по лицензии FTL. При этом не устанавливается минимальное число пользователей, не нужно выяснять значение PVU для данного сервера или что-то еще: все очень просто!

В HA-кластере горячий/теплый вы фактически покупаете лицензию FTL для каждого сервера DB2 Express. Кроме того, в версии DB2 9.5, если нужно было создать HADR-кластер с использованием сервера DB2 Express, приходилось приобретать DB2 High Availability Feature Pack, чтобы получить эту функцию наряду с другими функциями, связанными с HA. В DB2 9.7 лицензия DB2 Express FTL бесплатно предоставляет доступ ко всем компонентам High Availability Feature Pack (в том числе HADR). По сути, лицензия FTL DB2 Express дает право на все функции, имеющиеся в DB2 High Availability Feature Pack! Достаточно приобрести этот набор функций, чтобы использовать HADR с сервером DB2 Express, лицензируемым по лицензиям PVU или AU.

Лицензия SOCKET: Лицензия SOCKET тоже появилась только в DB2 9.7 и доступна лишь для серверов DB2 Workgroup. При лицензировании сервера DB2 Workgroup по лицензии SOCKET вы просто покупаете лицензию на нужное число процессорных гнезд основного сервера. Если у вас 4-процессорный сервер IBM POWER6 с двухъядерными процессорами, вы должны купить 4 лицензии SOCKET для DB2 Workgroup. Кстати, этот сервер оценивается в 960 PVU, тем не менее, достаточно приобрести всего 4 лицензии SOCKET для DB2 Workgroup. Да, это так: используя лицензию SOCKET, можно эксплуатировать DB2 Workgroup на машине с производительностью, превышающей установленный в DB2 9.5 предел в 480 PVU (при лицензировании сервера DB2 Workgroup по лицензиям PVU или AU в DB2 9.7 вы по-прежнему ограничены 480 PVU). Для сервера теплого резерва достаточно купить одну лицензию SOCKET, не важно, какую. В примере на рисунке 7 потребуется 4 гнезда (горячая машина) + 1 гнездо (теплый резерв) = 5 гнезд.

Лицензия Processor Value Unit (PVU): Для любого сервера DB2, лицензируемого по модели PVU, лицензируется теплой резервный сервер для 100 PVU независимо от того, на какой процессорной архитектуре базируется сервер. Иными словами, хотя сервер с четырьмя двухъядерными процессорами AMD приравнивается к 400 PVU, а сервер с двумя двухъядерными процессорами POWER6 – к 480 PVU, в системе с сервером теплого резерва вы просто лицензируете соответствующую редакцию DB2 на 100 PVU.

Например, если бы сервер на рисунке 7 был сервером с четырехъядерными процессорами POWER6, и каждая машина работала бы с DB2 Workgroup (во втором квартале 2008 года предел PVU для DB2 Workgroup изменился с 400 PVU на 480 PVU), для этого решения пришлось бы приобретать 580 PVU: 480 PVU для машины 2 и 100 PVU для машины теплого резерва 1.

Лицензия Authorized User (AU) Для любого сервера DB2, который лицензируется по модели АU, нужно лицензировать сервер теплого резерва, приобретая минимальное число лицензий AU для данной редакции базы данных с учетом того, что это сервер теплого резерва. Для DB2 Express и DB2 Workgroup, так как для основного сервера минимальное число АU, которое необходимо лицензировать, составляет 5, для сервера теплого резерва потребуется 5 лицензий AU. На рисунке 7, если один сервер DB2 Workgroup был бы в горячем резерве и настроен на участие в HADR-кластере горячий/теплый, то при 100 пользователях нужно было бы приобрести в общей сложности 105 лицензий AU DB2 Workgroup АС: 100 AU + 5 AU для сервера теплого резерва. (Разумеется, это требование должно соблюдаться, если число пользователей меньше минимально требуемого числа лицензий АU для сервера горячего резерва.)

Если бы на рисунке 7 использовалась редакция DB2 Enterprise, все было бы немного иначе и немного сложнее. В DB2 Enterprise минимальное количество пользователей AU составляет 25 на каждые 100 PVU (о чем подробно говорилось выше). Поскольку в модели PVU с сервером DB2 Enterprise имеется минимально лицензируемое число в 100 PVU на сервер теплого резерва, минимум в 100 PVU преобразуется в 25 AU, и это становится минимальным числом AU, которое нужно лицензировать для сервера теплого резерва DB2 Enterprise, лицензируемого по модели AU. Продемонстрируем это на примере с использованием рисунка 7. Если бы у серверов на рисунке 7 было по два гнезда для двухъядерных процессоров Intel x86, общее число PVU для горячего сервера составило бы 200 PVU. Если к горячему серверу DB2 Enterprise обращаются всего три пользователя, для этой конфигурации вам все равно в общей сложности потребуется 75 AU: (200/100 = 2 х 25 AU) для горячего сервера, плюс 25 AU для сервера DB2 Enterprise теплого резерва. Однако если серверы на рисунке 7 имели бы по два гнезда для двухъядерных процессоров POWER6 (так что всего у этих серверов было бы по 4 ядра), общее число PVU для горячего сервера составило бы 480 PVU. Если к горячему серверу DB2 Enterprise обращаются всего три пользователя, для этой конфигурации вам все равно в общей сложности потребуется 150 AU: (480/100 = 4,8, округленно 5, х 25 AU для горячего сервера) + минимум 25 AU для сервера теплого резерва DB2 Enterprise.

В начало

Холодный резерв

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

В данном примере в периоды нормальной работы машина 2 используется для обработки транзакций и запросов (на рисунке обозначена как "Активная работа"), в то время как на машине 1 база данных DB2 не запущена. Возможен даже случай, когда DB2 установлена на выключенной машине; при выходе из строя машины 2 машина 1 загружается, восстанавливает базу данных на определенный момент времени из резервной копии и открывается для транзакций пользователей. Возможно также, что машина 1 сконфигурирована как часть кластера Tivoli SA-MP, но экземпляр базы данных не запущен. Понятно, что конфигурация с холодным резервом не так много дает для повышения готовности, и MTTR, как правило, будет гораздо больше, чем при горячем или теплом резерве; тем не менее, она может удовлетворять требования некоторых приложений, и в этом случае по причинам, изложенным выше, стоимость данного решения для DB2 9.5 и более поздних версий окажется гораздо ниже.

Замечания по лицензированию машины, работающей в холодном резерве

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

Так что это идеальный пример того, как правила лицензирования последних нескольких выпусков DB2 могут сэкономить деньги, а кто не ищет способа сделать это в сегодняшних экономических условиях? Предположим, что вы лицензировали сервер DB2 9 Workgroup вместе с pureXML Feature Pack для XML-приложения, предъявляющего некоторые требования по HA. Для версии DB2 9 пришлось бы покупать полную лицензию на рабочий сервер (как и следовало ожидать) как на DB2, так и на pureXML Feature Pack; кроме того, пришлось бы лицензировать сервер холодного резерва на 100 PVU DB2 Workgroup и 100 PVU для pureXML Feature Pack. В DB2 9.7 достаточно купить лицензии на DB2 Workgroup для горячего сервера. Во всех редакциях DB2 функция PureXML предоставляется бесплатно (по состоянию на 9 февраля 2009 года), и лицензирование сервера холодного резерва не требуется. Добавьте к этому, что DB2 Workgroup можно лицензировать по лицензии SOCKET, при этом вдвое возрастает емкость вашего XML-решения высокой готовности, и его стоимость уменьшается более чем на 50%!

В начало

К вершинам высокой готовности

Как видите, DB2 предоставляет множество вариантов выбора решения высокой готовности. Я рекомендую клиентам создавать многоуровневые классификации приложений, требующих подобных решений; например, с оценками "медь", "серебро" и "золото". Может оказаться, что для всего, что удостоено меди, подойдет холодное резервирование, тогда как серебро удостоится горячего резервирования, а для золотых решений можно использовать горячий или теплый резерв. Что, последнее предложение застало вас врасплох? Да-да, с выделенным сервером часто (но не всегда) можно получить лучшее среднее время наработки на отказ (MTBF) и время MTTR, чем при загрузке резервной машины в горячей конфигурации. Конечно, горячее резервирование я отношу к категории золота, потому что для обеспечения этих преимуществ можно эффективно использовать также DB2pure Scale или другие относящиеся к DB2 технологии. Короче, не всегда требуется суперготовность; поступайте рационально и точно определяйте нужную технологию в соответствии с требованиями по HA.

Ресурсы

Научиться

• Оригинал статьи (EN).
  
  
• "Compare the distributed DB2 9.7 servers [Сравнение серверов распределенной DB2 9.7]" (DeveloperWorks, сентябрь 2009 г.): Пол Зикопулос приводит сравнительную таблицу для объяснения основных правил лицензирования, функций и особенностей разных членов семейства серверов распределенной DB2 9.7.(EN)
  
  
• "Which DB2 client connectivity option is right for you? [Какой вариант связи с клиентом DB2 вам подходит?]"(DeveloperWorks, апрель 2008 г.): подробно о разных вариантах подключения клиентских систем.(EN)
  
  
• "Which distributed edition of DB2 9.7 is right for you? [Какую распределенную редакцию DB2 9.7 выбрать?]"(DeveloperWorks, сентябрь 2009 г.): подробно о том, что делает каждую редакцию DB2 9.7 уникальной. Автор приводит спецификации каждой редакции, сведения по лицензированию, исторические изменения, начиная с версии DB2 9, и описывает несколько интересных примеров применения каждой редакции DB2.(EN)
  
  
• "DB2 and IBM's Processor Value Unit (PVU) pricing [DB2 и ценобразование IBM на базе единиц Processor Value Unit (PVU)]" (developerWorks, сентябрь 2009 г.): как лицензировать DB2 с использованием нового параметра Value Unit, а также ряд полезных в повседневной практике сценариев.
  
  
• Посетите страницу ресурсов developerWorks для DB2 на Linux, UNIX и Windows, чтобы прочесть статьи и руководства и выйти на другие ресурсы для расширения своего опыта в области DB2.(EN)
  
  
• Узнайте о DB2 Express-C, бесплатной версии DB2 Express Edition для широкого сообщества.(EN)
  
  

Получить продукты и технологии

• Загрузите бесплатную ознакомительную версию DB2 для Linux, Unix и Windows.(EN)
  
  
• Теперь DB2 можно использовать бесплатно. Загрузите DB2 Express-C, бесплатную версию DB2 Express Edition для широкого круга пользователей с теми же основными возможностями по работе с данными, что и у DB2 Express Edition, которая образует прочный фундамент для создания и развертывания приложений.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Блоги developerWorks: примите участие в деятельности сообщества developerWorks.
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Горячий резерв
• Теплый резерв
• Холодный резерв
• К вершинам высокой готовности
• Ресурсы
• Об авторе
• Комментарии