Лицензирование распределенных серверов данных DB2 9.5 в средах высокой готовности

Вы хотите убедиться в правильности лицензирования серверов данных IBM® DB2® версии 9.5 для Linux®, UNIX® и Windows® (DB2 9.5) для сред высокой готовности? У вас нет времени на внимательное чтение рекламных листков и лицензионных соглашений? Об этом, а также о некоторых важных изменениях в DB2 9.5 простым и доступным языком рассказывает автор статьи Пол Зикопулос.

Пол Зикопулос (Paul C. Zikopoulos), лаборатория IBM в Торонто

Пол Зикопулос (Paul C. Zikopoulos), бакалавр гуманитарных наук, магистр управления бизнесом, является отмеченным наградами писателем и докладчиком Database Global Sales Support team (группы содействия продажам баз данных во всем мире). Иимеет более чем девятилетний опыт работы с DB2 и написал много статей для журналов и книг об этой СУБД. Пол был соавтором следующих книг: DB2 Version 8 (DB2 версия 8): The Official Guide (Официальное руководство), DB2 - The Complete Reference (DB2 – полное руководство), DB2 Fundamentals Certification for Dummies (DB2 - Основы сертификации DB2 для "чайников"), DB2 For Dummies (DB2 для "чайников") и A DBA's Guide to Databases on Linux (Базы данных в Linux - руководство для администраторов баз данных). Пол является сертифицированным техническим экспертом DB2 (в области DRDA (архитектура распределенной реляционной базы данных) и Cluster/EEE) и сертифицированным экспертам по решениям DB2 (средства бизнес-аналитики и администрирование баз данных). Вы можете связаться с ним по электронной почтеpaulz_ibm@msn.com.



15.07.2009

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

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

а, во-вторых, из-за различий в толковании терминов, используемых при описании сред высокой готовности. Возьмем, например, термин кластеры. Иногда специалисты в ИТ-отрасли называют среды высокой готовности кластерами. В последнее время я не люблю этот термин, поскольку он используется для обозначения и кластеризации в целях обеспечения масштабируемости (например, функции секционирования баз данных DB2 - DPF-функции), и кластеризации в целях обеспечения высокой готовности (пример: использование встроенной в DB2 9.5 кластеризующей функции Tivoli System Automation (TSA) в группе серверов). Несмотря на мое отношение к этому термину, он все же используется, поэтому в данной статье, говоря о кластерах, я имею в виду кластеризацию для обеспечения высокой готовности (если не указано иное). Чтобы избежать путаницы, я рекомендую при обсуждении кластеризации с клиентами или коллегами добавлять к слову кластеры соответствующее дополнение - "кластеры высокой готовности" или "кластеры масштабируемости".

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

Чаще всего в литературе IBM Software Group (IBM SWG) используется следующая классификация резервных серверов: холодный, теплый и горячий. До DB2 9.5 все было немного по-другому. В DB2 8 и DB2 9 для описания резервных серверов данных используются термины резервный и активный. В результате термины лицензирования и ценообразования DB2 8 и DB2 9 не соответствуют терминам IBM SWG, что может запутать клиентов, лицензирующих стек продуктов IBM для сред высокой готовности.

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

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

Рисунок 1. Полезные советы по таксономии высокой готовности DB2 9.5 (горячий, теплый и холодный резерв) .
Полезные советы по таксономии высокой готовности DB2 9.5 (горячий, теплый и холодный резерв).

На рисунке 2 я сопоставил самые распространенные термины, которые используются для описания сред высокой готовности, c таксономией DB2 9.5 и терминами лицензирования:

Рисунок 2. Сопоставление используемых в отрасли терминов высокой готовности с терминами лицензирования DB2 9.5
Сопоставление используемых в отрасли терминов высокой готовности с терминами высокой готовности в DB2 9.5

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

Условия лицензирования сервера DB2 для сред высокой готовности будут зависеть от ответов на следующие вопросы:

  • Какая версия сервера данных DB2 у вас установлена:

    DB2 Express-C, DB2 Express-C FTL, DB2 Express, DB2 Workgroup или DB2 Enterprise? Например, при лицензировании DB2 Express-C FTL не используются понятия сервера горячего, теплого или холодного резерва (об этом немного позже). Кроме того, сервер данных DB2 Express-C не может быть кластеризован для обеспечения высокой готовности.

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

    Для основных серверов данных DB2 9.5 (DB2 Express, DB2 Workgroup и DB2 Enterprise) имеются следующие варианты лицензирования: по количеству авторизованных пользователей (как ясно из ее названия, такая лицензия использует методологию идентификации каждого конечного пользователя) и по показателю вычислительной мощности IBM SWG (которая использует методологию неограниченного доступа без учета количества пользователей); этот показатель измеряется в в единицах вычислительной мощности (Processor Value Unit, PVU). Для DB2 Express-C FTL используется методология лицензирования по физически установленным серверам (описание всех распределенных серверов данных DB2 9 и способов их лицензирования можно найти в статье "Which distributed edition of DB2 9.5 is right for you?" (Какая из распределенных версий DB2 9.5 подходит именно вам?).

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

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

В версии DB2 9.5 значительно снижена стоимость среды высокой готовности благодаря ряду изменений, о которых говорится в данной статье:

  • Компьютеры холодного резерва больше не подлежат лицензированию;
  • Пакеты дополнений на серверах, которые выполняют функции теплого или холодного резерва, также не подлежат лицензированию;
  • DB2 9.5 поставляется с интегрированным кластеризующим ПО для обеспечения высокой готовности (IBM TSA for Multiplatforms), то есть, вам не нужно приобретать отдельно кластеризующее ПО, чтобы автоматизировать обработку ситуации отказа при помощи функции HADR или создать простой кластер высокой готовности;
  • Теперь функция HADR бесплатно включена в DB2 Workgroup; если вы внимательно рассмотрите предложения конкурентов, то увидите, что ни один из производителей не предлагает функциональных возможностей такого уровня (в DB2 Workgroup нет ограничений на использование технологии HADR) для любого SMB-сервера;
  • Ограничение для версии DB2 Workgroup изменилось с 400 PVU (единиц вычислительной мощности) до 480 PVU; если мы сравним эти два значения, то увидим, что транзакционная рабочая нагрузка на сервере с 480 PVU стала дешевле и обеспечивает более высокую степень готовности. (Сервер с 480 PVU может обработать очень большое количество транзакций.)

Лучше всего начать изучение влияния наличия кластеров высокой готовности на условия лицензирования DB2 с примеров, которые соотносятся с новой таксономией. Как мы уже видели, в DB2 9.5 определены три типа резервных серверов: горячий, теплыйи холодный.

Конфигурация с сервером горячего резерва

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

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

Подведем итог: в DB2 сервер горячего резерва - это любой компьютер, который используется для обслуживания транзакций и запросов пользователей в нормальном рабочем режиме. Если происходит отказ сервера в кластере, то сервер горячего резерва, помимо нагрузки, которую он выполняет в обычных условиях, принимает на себя нагрузку неисправного сервера. Поскольку компьютер горячего резерва продолжает использоваться для обработки транзакций и запросов пользователей и в отсутствие отказов, он подлежит полному лицензированию. Допустим, например, что у нас есть две базы данных на двух отдельных компьютерах, на одном из которых выполняется пакет приложений системы планирования ресурсов предприятия (enterprise resource planning, ERP), а на другом - пакет приложений управления цепочкой поставок (supply chain management, SCM). При отказе базы данных системы SCM компьютеру, выполняющему рабочую нагрузку ERP, пришлось бы обслуживать также всех пользователей системы SCM.

Схема сценария с сервером горячего резерва показана на рисунке 3. В этом примере используется пара серверов, причем оба сервера используются для обработки транзакций и запросов в обычном рабочем режиме (прямоугольники со сплошной заливкой показывают рабочую нагрузку до отказа, а заштрихованные прямоугольники показывают рабочую нагрузку, которая имела бы место при наступлении события отказа на соответствующей машине). В нашем примере сценария на компьютере 2 произошел отказ, поэтому его рабочая нагрузка передается на компьютер аварийного переключения, то есть, компьютер 1. Компьютер 1 является сервером горячего резерва для компьютера 2 (и наоборот: внимательно рассмотрите рисунок и обратите внимание на заштрихованный прямоугольник для компьютера 1 на компьютере 2). Этот вид конфигурации часто называют кластеризованной парой высокой готовности, сдвоенной парой серверов аварийного переключения или кластером типа "активный/активный"; это довольно распространенная конфигурация в современном ИТ-мире. В DB2 существует много способов реализации кластеров высокой готовности по типу "активный/активный"; в зависимости от ваших требований к решению, вы можете использовать функцию секционирования базы данных, функцию HADR в сочетании с базой данных для каждого неисправного сервера на другом сервере, функции HADR и Q-репликации с использованием активного резерва для генерации отчетов через технологию моментальных снимков или копирование образов дисков, использования технологии xKoto GRIDSCALE и т. д.

Здесь оба компьютера 1 и 2 с рисунка 3 тоже использовались для обработки собственных транзакций и запросов, а при отказе компьютера 2 его рабочая нагрузка DB2 просто была переведена на компьютер 1. Не забывайте, что в этом случае, если на компьютере 1 для выполнения рабочей нагрузки неисправного компьютера 2 будет выделено недостаточно ресурсов (и наоборот), после возникновения отказа в результате переноса рабочей нагрузки могут возникнуть проблемы с производительностью.

Рисунок 3. Компьютер 1 является горячим резервом для компьютера 2, а компьютер 2 является горячим резервом для компьютера 1. При отказе рабочая нагрузка компьютера 2 переносится на компьютер 1.
Компьютер 1 является горячим резервом для компьютера 2, который, в свою очередь, является горячим резервом для компьютера 1.

Условия лицензирования для компьютера горячего резерва

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

Лицензирование по вычислительной мощности:

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

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

Лицензирование по количеству авторизованных пользователей

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

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

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

Если бы в качестве сервера данных на рисунке 3 использовалась версия DB2 Enterprise, все было бы немного по-другому. Возвращаясь к примеру из предыдущего раздела, если бы у вас было 100 пользователей, которым необходим доступ к обоим серверам данных DB2 Enterprise, вам нужно было бы приобрести для этих 100 пользователей в общей сложности 250 лицензий на авторизованных пользователей DB2 Enterprise: 2 сервера x 125 авторизованных пользователей на каждый сервер (при условии, что сервер в нашем примере - это сервер на базе четырехъядерного процессора POWER6 с вычислительной мощностью в 480 PVU). И в этом случае, даже если в любой момент времени к любому из серверов данных одновременно подключается всего 12 пользователей, все 125 пользователей должны иметь лицензии для каждого сервера данных (поэтому в данном примере вам необходимо 250 лицензий на авторизованных пользователей DB2 Enterprise). Если бы сервер данных DB2 Enterprise на рисунке 3 был двухъядерным сервером на 2 сокета Intel x86, то общее количество единиц вычислительной мощности (PVU) для этих серверов будет 200 PVU для каждого. Если в вашей компании только 3 пользователя, то для того, чтобы выполнить требования к минимальному количеству авторизованных пользователей для этой версии DB2, вам понадобится в общей сложности 100 лицензий на авторизованных пользователей (2 сервера x 200/100 PVU x 25 авторизованных пользователей). Однако, если бы серверы на рисунке 3 были двухъядерными серверами на 2 сокета Power5+, то общее количество единиц вычислительной мощности (PVU) для каждого сервера было бы 400 PVU. Итак, для этого типа серверного аппаратного обеспечения, даже если в вашей компании всего 3 пользователя, вам понадобится в общей сложности 200 лицензий на авторизованных пользователей (2 сервера x 400/100 PVU x 25 авторизованных пользователей) для того, чтобы выполнить требования к минимальному количеству авторизованных пользователей для данной версии DB2.

Как уже говорилось ранее, версия DB2 Express-C не поддерживает конфигурации высокой готовности. Однако DB2 Express-C FTL такую конфигурацию поддерживает. При лицензировании DB2 Express-C FTL в среде высокой готовности правила, описанные в данном разделе, не соблюдаются. Поскольку DB2 Express-C - это бесплатный сервер данных, а лицензия с ограниченным сроком (Fixed Term License, FTL) представляет собой контракт на поддержку и функции, который можно приобрести отдельно, в этом случае используется другой способ лицензирования. Лицензируя DB2 Express-C FTL в среде высокой готовности, вы просто приобретаете контракт на поддержку для каждого сервера в кластере, независимо от того, какой тип резерва (горячий, теплый или холодный) он собой представляет; при этом нет необходимости идентифицировать степень активности данного сервера, минимальные количества пользователей, объем вычислительной мощности базового сервера или что-либо еще. Все просто!


Конфигурация с сервером теплого резерва

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

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

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

Поскольку в ходе работы в обычном режиме только один компьютер на рисунке 4 является горячим резервом с точки зрения DB2, тогда как другой выполняет некоторые операции теплого резерва типа инициализации партнерского сервера аварийного переключения HADR; такая конфигурация часто называется кластером типа активный/резервный. Следует обратить внимание на одну важную деталь: до простоя компьютер 1 не выполнял никакой "значимой" работы DB2.

Рисунок 4. Рабочая нагрузка компьютера 2 переводится на сервер теплого резерва, компьютер 1
Рабочая нагрузка компьютера 2 переводится на резервный сервер

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

Особенности лицензирования для компьютера теплого резерва

Лицензирование по вычислительной мощности:

Для всех серверов данных DB2, лицензируемых по модели PVU, сервер теплого резерва лицензируется на 100 PVU, независимо от того, на каком типе архитектуры вычислительного ядра построен данный сервер. Другими словами, тот факт, что сервер с четырьмя двухъядерными процессорами AMD имеет вычислительную мощность 400 PVU, а сервер с четырьмя двухъядерными процессорами POWER6 - 960 PVU (можете мне поверить, его производительность превосходит производительность первого сервера больше чем вдвое), для сервера теплого резерва вам нужно просто лицензировать его из расчета на 100 PVU для соответствующей версии DB2.

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

Авторизованный пользователь

Для любого серверного продукта DB2, который лицензируется по количеству авторизованных пользователей, вам придется лицензировать сервер теплого резерва путем приобретения лицензий для минимального количества авторизованных пользователей, предусмотренного для данной версии, с учетом того, что это сервер теплого резерва. Для версий DB2 Express и DB2 Workgroup на сервер теплого резерва потребуется 5 лицензий авторизованных пользователей,.поскольку минимальное количество лицензий авторизованных пользователей равно 5 на каждый физический сервер.. Если в приведенном выше примере один сервер DB2 Workgroup является сервером горячего резерва и сконфигурирован на участие в кластере типа активный/резервный, и при этом у нас есть 100 пользователей, то для этих 100 пользователей нам пришлось бы приобрести в общей сложности 105 лицензий на авторизованных пользователей DB2 Workgroup: 100 авторизованных пользователей + 5 авторизованных пользователей для сервера теплого резерва. (Конечно, если количество пользователей меньше, чем это число, необходимо будет оплатить минимальное количество лицензий на авторизованных пользователей.)

Если бы в качестве сервера данных на рисунке 4 использовалась версия DB2 Enterprise, то в этом случае для сервера теплого резерва вам пришлось бы приобрести 25 лицензий на авторизованных пользователей, потому что, в соответствии с моделью PVU, вы лицензируете для сервера теплого резерва DB2 Enterprise 100 единиц вычислительной мощности, а это соответствует 25 авторизованным пользователям с учетом минимального количества авторизованных пользователей DB2 Enterprise на 100 PVU.

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

Как уже говорилось ранее, версия DB2 Express-C не поддерживает конфигурации высокой готовности. Однако DB2 Express-C FTL такие конфигурации поддерживает. При лицензировании DB2 Express-C FTL в среде высокой готовности правила, описанные в данном разделе, не соблюдаются. Поскольку DB2 Express-C - это бесплатный сервер данных, а лицензия с ограниченным сроком (Fixed Term License, FTL) представляет собой контракт на поддержку и функции, который можно приобрести отдельно, в этом случае используется другой способ лицензирования. Лицензируя DB2 Express-C FTL в среде высокой готовности, вы просто приобретаете контракт на поддержку для каждого сервера в кластере, независимо от того, какой тип резерва (горячий, теплый или холодный) он собой представляет; при этом нет необходимости идентифицировать степень активности данного сервера, минимальные количества пользователей, объем вычислительной мощности базового сервера или что-либо еще. Все просто!


Конфигурация с сервером холодного резерва

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

Схема сценария с сервером холодного резерва показана на рисунке 5.

Рисунок 5. Компьютер 1 является сервером холодного резерва для компьютера 2
Компьютер 1 является сервером холодного резерва для компьютера 2

В данном примере в ходе работы в обычном режиме компьютер 2 используется для рабочей нагрузки по обработке транзакций и запросов пользователей (обозначенной на рисунке как активное задание), тогда как на компьютере 1 отсутствует запущенный экземпляр DB2. Чаще всего компьютер 2 отключен, но DB2 на нем установлена, и в случае отказа компьютер 1 загружается, восстанавливает базу данных до состояния на определенный момент времени из резервной копии и открывается для обработки транзакций пользователей. Возможна также следующая ситуация: компьютер 1 сконфигурирован как компонент кластера высокой готовности TSA, но экземпляр базы данных на нем не запущен. Нетрудно понять, что конфигурация с сервером холодного резерва не слишком оптимальное решение для обеспечения высокой готовности из-за того, что MTTR в этом случае обычно значительно больше, чем в конфигурации с сервером горячего или теплого резерва. С другой стороны, такое решение может соответствовать вашим потребностям, и если это так, его стоимость в DB2 9.5 по ряду причин будет меньше.

Как уже говорилось ранее, существуют среды, для которых сервер холодного резерва будет подходящим решением. Обычно я рекомендую клиентам придумать многоуровневую классификацию для приложений, требующих высокой готовности (например, бронзовая, серебряная и золотая категория). Возможно, решения "бронзовой" категории, будут использовать холодный резерв, "серебряной" - горячий, а "золотой" - горячий или теплый. Вам кажется неожиданной последняя фраза? Что касается меня, то, если требуется наибольшая из возможных степень высокой готовности, я буду использовать решение с сервером теплого резерва и функцией HADR. Если у вас есть выделенный сервер, то вы, вероятно (но не обязательно) получите лучшие показатели средней наработки на отказ (mean time between failure, MTBF) и MTTR, чем в случае загрузки резервной машины в конфигурации с сервером горячего резерва (кроме случаев, когда вы выделили для этого достаточно ресурсов). Конечно, конфигурацию с сервером горячего резерва я отнесу к категории "золотых" решений, потому что можно использовать такие технологии, как Xkoto GRIDSCALE.

Условия лицензирования для компьютеров холодного резерва

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

Вот превосходный пример того, как новые правила лицензирования DB2 9.5 для сред высокой готовности будут экономить ваши деньги. Предположим, вы лицензировали среду DB2 9 при помощи дополнения Feature pack. В DB2 9 вам пришлось бы полностью лицензировать сервер горячего резерва (как и следовало ожидать), кроме того, необходимо было бы лицензировать сервер холодного резерва и дополнение Feaure pack. В DB2 9.5 вам нужно лицензировать только сервер горячего резерва, поскольку плата за сервер холодного резерва не предусмотрена и, кроме того, не нужно лицензировать дополнения feature pack для целей обеспечения высокой готовности в кластерах высокой готовности типа "горячий/холодный" или "горячий/теплый".


Формирование цены для решений высокой готовности с использованием HADR

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

Начиная с версии DB2 9.5, функция HADR включена в поставку DB2 Workgroup (она всегда поставлялась с DB2 Enterprise). В DB2 9 единственным способом добавить функцию HADR к серверу данных DB2 Workgroup, была покупка дополнения High Availability Feature Pack и для основных, и для резервных серверов. Начиная с версии DB2 9.5, в этом больше нет необходимости, поэтому, чтобы сэкономить довольно большую сумму, нужно просто лицензировать резервный сервер DB2 Workgroup как сервер теплого резерва и выполнить приведенные выше рекомендации.

Кроме того, вам по-прежнему придется приобрести дополнение DB2 High Availability Feature Pack Однако если вы хотите использовать функцию HADR на сервере DB2 Express, то, начиная с версии DB2 9.5, вам больше не нужно лицензировать дополнение High Availability Feature Pack на резервном компьютере, кроме случаев, когда эта машина используется как сервер горячего резерва в кластере со спаренными серверами и HADR.

И наконец, в DB2 Express-C FTL всегда можно было настроить кластер высокой готовности при помощи HADR; для этой конфигурации нет особых условий лицензирования, поэтому достаточно приобрести контракт на техническую поддержку для каждого сервера, на котором планируется установка DB2 Express-C FTL.

Ресурсы

Научиться

  • Оригинал статьи: Licensing distributed DB2 9.5 data servers in a high availability environment (En);
  • "Compare the distributed DB2 9.5 data servers" (Сравнение распределенных серверов данных DB2 9.5) (developerWorks, март 2007 г.). Автор статьи Пол Зикопулос (Paul Zikopoulos) при помощи сравнительной таблицы объясняет различия между основными правилами лицензирования, функциями и особенностями представителей семейства распределенных серверов данных DB2 9.5 (En);
  • "Which DB2 9.5 client connectivity option is right for you?" (Какой из вариантов подключения клиентов подойдет именно вам?) (developerWorks, апрель 2008 г.): ознакомьтесь с историей разработки вариантов подключения для серверов данных DB2 между версиями DB2 8 и DB2 9.5. Кроме того, изучите спецификации для каждой опции подключения в DB2 9.5 и ознакомьтесь с полезными советами, которыми изобилует данная статья (En);
  • "Какой из вариантов распределенной СУБД DB2, версия 9.5, подходит именно вам?: в статье представлена подробная информация об уникальных особенностях различных версий DB2 9.5. Автор подробно объясняет спецификацию каждой версии, условия лицензирования, историю изменений после выхода DB2 9 и описывает некоторые интересные применения каждой версии DB2;
  • "DB2 и система ценообразования IBM на основе единиц процессора (PVU): в этой статье описывается лицензирование DB2 при помощи новой модели - по вычислительной мощности, а также ряд полезных сценариев, которые можно использовать в повседневной работе;
  • Информация о DB2 Express-C, бесплатной версии DB2 Express для сообщества разработчиков (En);
  • На Web-сайте developerWorks, в разделе Information Managementпредставлена дополнительная информация о продуктах для управления информацией (IBM Information Management). здесь вы найдете техническую документацию, справочные статьи, материалы для загрузки, информацию о продуктах и многое другое.

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

  • Загрузите бесплатную ознакомительную версию DB2 Enterprise 9 (En);
  • Теперь у вас есть возможность использовать DB2 бесплатно. Загрузите DB2 Express-C, бесплатную версию DB2 Express Edition для сообщества разработчиков, которая предлагает все основные возможности DB2 Express Edition и может служить прочным фундаментом для создания и размещения приложений (En);

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=413298
ArticleTitle=Лицензирование распределенных серверов данных DB2 9.5 в средах высокой готовности
publish-date=07152009