Oracle mechanics

Проект Oracle 9i RAC Linux x86 FC SAN SATA

English version

Миграция БД высокой готовности [prepaid GSM биллинговая система Беркут In@Voice] на доступную кластерную конфигурацию (Oracle 9i RAC / Linux x86 / FC SAN / SATA HDD)

Игорь Усольцев, отдел ИТ Калининградского филиала ОАО «Вымпелком», 2006

Отдельное спасибо Игорю Шульцу (руководителю отдела ИТ); Сергею Голикову и его коллегам из подразделений поддержки и администрирования БД компании «Беркут» (г.Санкт-Петербург)- за поддержку проекта со стороны производителей ПО; Oracle Enterprise Linux support team, Е.Горбоконенко и А.Криушину («РДТех», г. Москва) — за консультационную помощь.

Информация о системе

Критичная для бизнеса 24×7 OLTP БД, prepaid GSM биллинговая система Беркут In@Voice 4.3.

Характеристики production БД: более 6000 000 транзакций в день, около 300000 активных GSM абонентов (звонковая активность), более 500 000 счетов в месяц, размер БД — более 600 ГБ, ежедневный объём архивных лог-файлов — более 30 ГБ.

Основной функционал:

  • online предварительный анализ вызовов (голос, SMS), включая обработку вызовов CAMEL роумеров — предтарификация;

  • посттарификация вызовов (голос, SMS, GPRS), VAS и абонентских услуг;

  • online управление статусами коммутаторных и логических услуг абонентов («subscriber provisioning»);

  • система online «самообслуживания» абонентов (управления услугами через каналы ussd, sms и http — на основе «Беркут CAREM»);

  • online клиентские платёжные системы;

  • биллинг;

  • тарификация периодических услуг;

  • система обработки TAP роуминга;

  • пользовательские приложения и отчётность;

  • online БД Call Centre (отдельная схема, порождающая незначительную нагрузку).

ПО Беркут In@Voice 4.3 было разработано для функционирования в single instance конфигурации. Но модульная система приложения позволяет разделить нагрузку на БД на почти независимые группы процессов, которые, в свою очередь, могут быть запущены на различных кластерных нодах (экземплярах Oracle RAC) с целью балансировки нагрузки и увеличения ресурсов CPU и RAM. Этот подход был предложен и успешно протестирован подразделением ДБА Беркут на платформе Oracle 9i / Sun.

Конфигурация ПО и оборудования до миграции

ПО:

  • Oracle EE 9.2.0.6

  • Red Hat Advanced Linux 2.1 (2.4.9-e.62enterprise kernel)

Оборудование:

  • Серверная платформа Intel SPSH4: 4 x 2.7 GHz Intel Xeon, 16 GB ram, 10 x 15000 rpm internal SCSI disks;

  • Встроенная система ввода-вывода: два адаптера Adaptec 29320A-R (raid-0) + software raid-1 (Linux raidtab).

Начальная конфигурация

Начальная конфигурация

Определение и цели проекта

Основной целью проекта было увеличение резерва производительности системы БД «реального времени» с постоянно увеличивающейся нагрузкой, вызванной ростом абонентской базы, звонковой нагрузкой и расширением функционала. В системе наблюдались очевидные признаки дефицита ресурсов (в последние месяцы перед миграцией “average process run queue” поднималась выше 10 в часы наибольшей нагрузки), что было недопустимо для обеспечения жёстких временных требований процессов пред- и посттарификации вызовов. Высокая загрузка сервера БД вызывала таймауты, периодически возникали отказы в обслуживании абонентов, либо звонки «пропускались» IN платформой без предтарификации (проверки статуса услуг и баланса абонента) и тарифицировались с задержкой, что недопустимо для препэйд системы по определению. Основной идеей предложения (проекта) было распределение нагрузки на систему БД между двумя (или более) экземплярами БД с использованием технологии Oracle 9i RAC. Распределение нагрузки между нодами (экземплярами) предполагалось сделать, разделив текущую активность на слабозависимые группы связанных процессов (на основе выполняемых бизнес-функций и анализа схем данных). Приоритетной целью было исключение влияния ресурсоёмких операций на критичную по времени подсистему обработки абонентских вызовов и балансов.

Планировалось изменить управление разделяемой памятью Oracle и тип хранения файлов данных. В некластерной конфигурации мы успешно использовали ограниченную 32-битной процессорной архитектурой SGA (около 2.7 GB) совместно с быстрым и надёжным файловым кэшем Linux (ext fs). Для кластерной БД использование кэша файловой системы недопустимо, необходимо использовать direct I/O. Планировалось использовать OCFS для файлов данных, технологии “Huge pages” и “Very Large Memory” для увеличения скорости работы с памятью и размера SGA.

В качестве оборудования для кластера планировалось использовать имеющиеся серверы (Intel chassis), недорогие внешние FC SATA RAID массивы (Infortrend A16F-R2221) с дублированными RAID контроллерами, полностью дублированную оптическую сеть на основе Qlogic SAN Kit и отдельную дублированную (по технологии NIC bonding с двумя неуправляемыми свичами) Gigabit Ethernet сеть в качестве интерконнекта. Выбор массивов был обусловлен нашим собственным опытом эксплуатации и данными тестов (например, проведённых в CERN, CASPUR Storage Lab. ). Т.о. конфигурацию подсистемы ввода/вывода планировалось изменить с внутреннего SCSI (soft(mirror)+hard(stripe)~RAID10 из 10 дисков) на внешний FC SATA (RAID5) с использованием mdadm multipathing software raid (для резервирования) — после тщательных предварительных тестов производительности.

Особенности реализации проекта, проблемы и решения

Для надёжного функционирования mdadm multipathing при подключении более, чем одного нода к внешнему массиву, необходимо было использовать «свежий» Linux kernel для RHEL 3.0, версия >= 2.4.21-40 (RHEL 3 update 7 или выше).

Для систем БД с высокой нагрузкой обязательным является использование Hugemem kernel во избежание проблем «low memory» starvation, в результате которых сервер БД «зависает» (hanging/freezing) без видимых ошибок. Эта проблема проявилась на нашем проекте и была успешно диагностирована с использованием netdump и разрешена (заменой ядра с 2.4.21-40smp на 2.4.21-40hugemem) с помощью высококвалифицированных специалистов Oracle Enterprise Linux support team. Стоит отметить, что в дистрибутиве Oracle Enterprise Linux, ядро hugemem установливается уже по умолчанию — во избежание подобных проблем проблем.

После обновления версии Oracle на 9.2.0.8 пришлось изменить значение параметра “filesystemio_options” с “setall” на “async” по причине ошибок процесса ARCHIVER — невозможности писать архивные лог файлы на файловую систему ext3. Данное изменение никак не повлияло на производительность скорость операций ввода-вывода, т.к. на файловой системе OCFS процессы RDBMS используют “direct I/O” по умолчанию — просто недокументированная неожиданность.

Для реализации надёжного дублирования cluster interconnect был выбран NIC bonding mode=3 (broadcast) с использованием 1GB NIC и двух неуправляемых HP 2708 свичей — предварительные тесты показали избыточность, но надёжность такого решения — линк оставался доступным при различных комбинациях сетевых сбоев, вплоть до физического обрыва. Другие конфигурации NIC bonding не показали такой же надёжности, возможно, по причине использования неподходящего сетевого оборудования. При тестировании БД проблем выявлено не было, однако после миграции рабочей БД на кластерную конфигурацию в работе Oracle проявились серьёзные проблемы (ora-600 с аргументами [2032]; [kjmsm_epc]; [4193]; [kclwcrs_4] вплоть до аварийного завершения работы инстансов), вероятно, связанные с использованием NIC bonding mode = 3. Проблема была разрешена отключением NIC bonding на всех кластерных нодах по рекомендации специалистов РДТех.

Для минимизации времени простоя процедура миграции проводилась с использованием метода активации standby БД. «Миграционная» standby БД создавалась методом копирования файлов данных актуальной standby БД на OCFS (RMAN) без остановки процесса наката последней — во избежание влияния на производительность рабочей БД.

Некоторые настройки, имеющие отношение к производительности системы:

Инициализационные параметры Oracle

  • use_indirect_data_buffers = TRUE
  • filesystemio_options = asynch
  • disk_asynch_io = TRUE
  • db_block_buffers = 1000000 / 400000 (первый /второй инстансы)
  • db_block_size = 8192
  • db_writer_processes = 4
  • db_file_multiblock_read_count = 32

OCFS block size 1 MB

VM (настройки ядра Linux) (/etc/sysctl.conf) – http://ahorvath.web.cern.ch/ahorvath/fc-sata/perf-infortrend.html:

  • vm.max-readahead = 256
  • vm.min-readahead = 127

QLA2300, настройки драйвера /etc/modules.conf – http://ahorvath.web.cern.ch/ahorvath/fc-sata/perf-infortrend.html:

options qla2300 ql2xmaxqdepth=64

QLA FAST!Util (adapter bios) параметры:

Используемые

Default

Execution Throttle

256

16

Fibre Channel Tape Support.

Disabled

Enabled

Speed

2GB

Auto

Topology

Loop only

Auto

Конфигурация массивов Infortrend RAID storage A16F-R2221 ():

RAID5 из 14 SATA disks, 256 kb blocksize

2 “global spare” диска

параметры логических дисков:

Optimization

Random I/O (not Default)

Rebuild priority

Low or Normal

Write verify

Disabled

Cach-sync on write-through

Disabled

LogicalDrive Write Policy

Write-Back (not Default)

С приведёнными выше настройками (возможно, не лучшими в части конфигурации дисковых массивов) удалось получить для одного серверного процесса Oracle (непараллельное выполнение) около 50 MB/sec при чтении и 40 MB/sec при операции записи на OCFS. Результат можно считать вполне удовлетворительным, однако при конфигурации дисковой подсистемы следует, конечно же, использовать хорошо известные рекомендации Oracle — RAID10 и SCSI диски.

В нижеприведённом запросе (v$system_event) видно относительно незначительное влияние «кластерных» ожиданий на общем фоне, что подтверждает разумность применённой стратегии разделения процессорных групп приложения между инстансами:

Node#

EVENT

TOTAL_WAITS

TIME_WAITED

1

log file sync

247,258,778

233,611,559

1

log file parallel write

488,789,406

107,718,015

1

db file sequential read

77,676,592

99,268,390

1

db file parallel write

234,524,275

74,096,542

1

global cache cr request

246,277,674

27,851,564

1

enqueue

7,692,340

18,881,059

1

SQL*Net more data from dblink

651,907

9,897,190

1

global cache null to x

26,596,349

7,259,776

1

SQL*Net message from dblink

6151768

5039957

1

db file scattered read

4303841

3837648

2

db file sequential read

139020051

168416889

2

SQL*Net message from dblink

17574681

84142288

2

log file parallel write

136337603

43194946

2

log file sync

32910771

29053196

2

db file parallel write

87785085

27940157

2

db file scattered read

22314715

20993582

2

SQL*Net more data from dblink

2012029

16166518

2

global cache cr request

224910653

12175013

2

global cache null to x

14263586

7020135

2

global cache open x

50830468

2116074

Результаты проекта

После миграции был успешно достигнут запас производительности системы БД посредством распределения нагрузки между инстансами (нодами) Oracle RAC. Появился запас процессорных ресурсов — на ноде №1 (критичном для online обработки звонков) значение “average process run queue” не превышает 4.8 независимо от времени суток, были полностью исключены таймауты не только для звонковых сессий, но и для других критических процессов (online обработка платежей, система абонентского самообслуживания, управление услугами и т.д.). Длительность ежемесячного расчёта биллинговых счетов сократилась более, чем в 2 раза.

Очень важным результатом является появившаяся возможность перераспределять процессы приложения между нодами кластера «на лету» с целью балансировки нагрузки, а также добавлять дополнительные ресурсы процессоров и оперативной памяти (добавляя новые ноды в кластер) при необходимости без прерывания функционирования «боевой» кластерной БД (Metalink Note: 270901.1). В ходе реализации проекта эта технология была успешно протестирована и реализована при добавлении к функционирующему в рабочем режиме кластеру нода №3.

Технология Oracle 9i RAC является оправданным решением для масштабирования (методом распределения нагрузки между нодами кластера) критических приложений при условии хорошо спланированной и проведённой процедуры тестов. Использование доступного оборудования (удовлетворяющего требованиям Oracle, но вовсе не обязательно входящего в «список сертифицированных конфигураций») — серверов на платформах Intel и FC SATA дисковых массивов Infortrend является доступным и достаточно производительным решением для построения кластерной решений. Технология увеличения ресурсов кластера хорошо отработана Oracle и достаточно проста: добавление новых серверов при необходимости увеличить вычислительные мощности; добавление дополнительных массивов (с последующим перераспределением нагрузки), либо увеличение ёмкости и производительности существующих массивов (добавление JBOD) — для увеличения производительности подсистемы ввода/вывода. При этом желательно для кластерных нодов выбирать серверы с идентичной конфигурацией (процессоры, память) в соответствии с рекомендациями Oracle.

Целевая конфигурация

Целевая конфигурация

Добавить комментарий »

Комментариев нет.

RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: