Date December 30th, 2009 Author Vitaly Agapov

В этой статье я опишу процесс построения кластера DB2 с разделением нагрузки. Описывать процесс я буду для своего случая, в котором необходимо построить кластер на двух компьютерах. Один работает под управлением CentOS 5, другой – под Ubuntu 9.10. Но принципиальных отличий для других Линуксов быть не должно.
Поддержка механизма load-balancing реализована в самом ПО DB2 Enterprise или Workgroup Edition (в бесплатном Express Edition эта поддержка отсутствует). А это означает, что кроме дистрибутива DB2 никакого дополнительного софта нам не потребуется. Встроенный кластер работает по принципу shared nothing, то есть серверы в составе кластера не имеют одновременного доступа к одним и тем же данным, а каждый из серверов работает со своим отдельным разделом (partition) БД. Поэтому весь этот механизм (характерный именно для DB2) носит название partitioning. DB2 позволяет разделять базы данных на разделы (partitions или nodes), располагающиеся на разных серверах. Запросы по извлечению или изменению данных автоматически разбиваются на под-запросы и выполняются параллельно на соответствующих серверах. Для клиента эта процедура происходит прозрачно — обращение происходит к любому из серверов, который в свою очередь дальше занимается обработкой запроса и координированием под-запросов ко всем остальным узлам в кластере.

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

Стоит, наверное, сделать небольшую ремарку: partitioning в DB2 никак не влияет на общую отказоустойчивость системы и даже ы целом ухудшает её из-за увеличения точек отказа. Для повышения надёжности следует обратить внимание на такие вещи, как HADR, hearbeat, LifeKeeper, Red Hat Cluster Suite и т.д. Но сейчас не об этом…
DB2 Partitioning обладает целым рядом достоинств и недостатков. Из достоинств стоит отметить:

• масштабируемость (при необходимости в кластер легко добавляются новые серверы);
• можно легко управлять кластером, выводить из работы тот или иной сервер (просто монтируя разделы на другие серверы и меняя конфигурацию db2nodes.cfg с рестартом СУБД);
• не требуется загружать процессоры серверов кластера задачами по репликации данных между серверами (любым кластерным софтом вроде drbd).

Недостатки:

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

Установка софта

В нашем примере будет использоваться версия DB2 Enterprise 9.5. Хотя особых отличий в процедуре для версии 9.1 я не обнаружил.

Устанавливаем DB2 с помощью запуска скрипта db2_install из распакованного дистрибутива. Если есть графическая оболочка, то можно, конечно, воспользоваться графической Java-based утилитой DB2 Setup. Но это не наш случай. Производим эту процедуру на всех узлах будущего кластера. В моём случае их два, и я буду называть их host1 и host2. Также сразу устанавливаем файл лицензии.

Для кластерной архитектуры понадобится единый расшаренный дисковый раздел. Что это будет – дисковый массив или раздел на одной из нод, расшаренный по NFS, GFS, SSHFS или чем-то подобным – совершенно не важно. Мы в нашем примере будем использовать NFS. За поддержку NFS на сервере отвечает демон rpc.statd, управлять им можно с помощью скриптов в /etc/init.d (в Red Hat это nfslock, в Ubuntu это nfs-common). Итак, на хосте, откуда будем расшаривать раздел (host1), делаем следующее:

Для проверки расшаренного раздела можно использовать команду showmount -e host1.
А теперь на всех узлах монтируем эту директорию в /db2home:

Как вариант, можно использовать autofs, но это тема для отдельной статейки.

На следующем шаге (если мы не пользовались для установки DB2 графической утилитой DB2 Setup) надо создать необходимых пользователей и группы. Пользователей всего три: владелец инстанса, служебный аккаунт для выполнения хранимых процедур и администратор DAS (DB2 Administration Server):

Далее потребуется обеспечить между всеми узлами кластера Remote Shell. Можно использовать ssh с публичными ключами, можно – rsh с файлом .rhosts. В общем, по желанию и по обстановке. Останавливаться на этом не буду.

Настройка

После всех подготовительных операций можно приступать к созданию инстанса. Для этого служит утилита db2icrt:

Само собой, если у нас дистрибутив WSE, то ключом -s указываем wse.
Если все нормально, то двигаемся дальше. Надо в файле /etc/services на всех узалх прописать порты для DB2:

Затем указываем в конфигурации DBM какой порт использовать:

Указываем транспорт для Remote Shell (в зависимости от того что выбрали ранее):

Теперь самое важное: надо прописать все ноды в файле db2nodes.cfg (в /db2home/db2inst1/sqllib/):

Здесь первая колонка – номер ноды, вторая колонка – её ip-адрес или hostname (кстати, надо не забыть прописать все хостнеймы на всех нодах в /etc/hosts) и третья колонка – номер ноды на данном хосте.

Теоретически всё. Осталось сделать

Настройка tablespaces

Сразу стоит напомнить о двух полезных в распределённой базе командах: rah и db2_all. rah позволяет выполнить команду на всех физических узлах, входящих в кластер (то есть прописанных в db2nodes.cfg на том сервере, где команда непосредственно запускается). db2_all делает то же самое, но для всех логических узлов, то есть если на одном сервере располагается несколько DB2-нод, то команда будет выполнена для них всех.

Создадим теперь нашу базу данных. Назовём её test и решим, что храниться файлы базы будут в /database.

Выполнив эти команды, мы увидим стандартные тейблспейсы, созданные на обоих нодах кластера. Причём на разных нодах набор тейблспейсов будет разный – SYSCATSPACE создаётся только на главной ноде:

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

Здесь мы создали директории для табличного пространства на обеих нодах, а затем подключились к базе и создали табличное пространство MULTISPACE в стандартной группе партиций (partition group) IBMDEFAULTGROUP на обеих партициях. Переменные $DB2NODE и $N используются для автоматической подстановки номера ноды и партиции соответственно (не забываем, что на одной ноде может быть несколько партиций). сами эти значения берутся из файла db2nodes.cfg.

Теперь для полноты картины создадим табличное пространство SINGLRSPACE на одной из нод (например, host1):

Здесь мы создали директорию под табличное пространство на сервере, создали partition group, а в нём уже создали табличное пространство, располагающееся целиком на нулевой ноде.

Теперь мы сможем создавать таблицы в любом из этих тейблспейсов:

На сегодня – всё!

Tags: cluster, DB2, Linux
Category: DB2 | No comments »

Comments

Leave a comment

 Comment Form 

Name *

E-Mail *

Site

Your comment

Rich Text Editor, comment

Editor toolbarsBasic Styles Bold Italic Strikethrough Remove FormatParagraph Block Quote Align Left Center Align RightLinks Link UnlinkInsert Image Insert Special Character

Press ALT 0 for help

◢Elements path