Путь к полной консолидации

Консолидация актуальна для бизнеса практически всех уровней — по оценкам аналитиков Forrester Research, на 90% предприятий используется сегодня более одной базы данных. В России активно ведутся проекты по консолидации, и наиболее масштабные — на предприятиях с разветвленной филиальной сетью, характерной для таких отраслей, как финансы и телекоммуникации, а также для государственных структур, ведущих сегодня работу по созданию единых баз данных федерального уровня из множества разрозненных информационных систем.

Консолидация серверов и систем хранения

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

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

Применяются две характеристики измерения производительности системы хранения:

• максимальное количество операций ввода-вывода в секунду (IOPS) — показатель для задач, требующих большого количества операций произвольного доступа к дискам, что характерно для приложений оперативной обработки транзакций (OLTP);
• максимальный объем передаваемых данных в единицу времени — параметр оценки выполнения операций последовательного доступа, специфичных для хранилищ данных, процедур формирования отчетности и пакетных задач.

Подавляющее большинство реальных приложений OLTP во время эксплуатации являются комбинацией нагрузок разного типа. Практически в каждой транзакционной системе нельзя обойтись без отчетов и пакетных задач расчетов. Это могут быть, например, расчет остатков на конец дня, начисление процентов в конце месяца, закрытие квартала или года. Суть в том, что любой запрос, инициируемый процедурой формирования отчета, может вызвать серию «тяжелых» последовательных дисковых чтений, которые могут отрицательно повлиять на производительность выполнения более важных запросов от онлайн-пользователей. А как совместить на одной дисковой системе разные базы данных? Для успеха проекта по консолидации требуется обеспечить выполнение запросов ввода/вывода разных задач с заданными приоритетами.

Традиционный подход

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

• Планирование с запасом. Обеспечение в дисковой системе мощностей, достаточных для поддержки максимально возможной внешней нагрузки с временем ответа ниже предельно допустимого, — это самый дорогой в реализации подход.
• Физическое разделение. Выделение дисковых устройств и контроллеров для эксклюзивного использования одной базой данных. Если расчет осуществляется на основе метрик производительности, размеры созданных «островков» дискового пространства могут значительно превышать требуемые для баз данных объемы. Недостатками данного подхода являются неэффективное использование дискового пространства, неравномерное распределение нагрузки, сложность администрирования. Этот метод не может решить проблему конкуренции за ресурсы ввода-вывода в рамках одной базы.
• Планирование по времени. Вынесение некритичных задач с большой интенсивностью дисковых операций на периоды времени с меньшей активностью, что является практически единственным способом разрешения конфликтов за ресурсы ввода-вывода внутри одной базы данных. Однако способ не всегда возможен из-за ограничений по времени для решения бизнес-задач.

Часто данные методы применяются совместно, но любая их комбинация все равно будет иметь недостатки при усложнении администрирования, что существенно снижает эффект консолидации.

Как хотелось бы

На практике ни один из традиционных методов не способен обеспечить выполнение политики разграничений, диктуемых требованиями бизнеса, —например, выделить 70% производительности дискового массива хранилищу финансового департамента и 30% хранилищу департамента продаж или обеспечить приоритет операций ввода/вывода для «боевой» базы над операциями по тестированию и разработке. Воплощение таких пожеланий немыслимо без интеграции СУБД с дисковой подсистемой, что, однако, реализовать сложно — для СУБД физическая сущность дискового массива скрыта под ворохом виртуальных слоев, а для дискового массива обрабатываемая информация является лишь обезличенным набором байтов.

В отличие от традиционных дисковых массивов, в Exadata Database Machine обращение экземпляра базы данных к системе хранения происходит напрямую с помощью специально разработанного протокола iDB, реализованного на основе межсоединения Infiniband. Использование iDB позволяет расширить список команд, передаваемых от СУБД к ячейкам хранения, и улучшить взаимодействие.

Ячейки хранения Exadata — это устройства, способные понимать и выполнять расширенные команды, поступающие от СУБД. Для соблюдения приоритетов операций ввода-вывода в систему хранения передается дополнительная информация — каждая команда чтения или записи снабжается метками, идентифицирующими ее принадлежность к базе данных и группе пользователей внутри этой базы, а также указателем типа операции. Благодаря этому система хранения может обеспечивать соблюдение приоритетов и лимитов на выполнение команд ввода-вывода. Такой механизм называется I/O Resource Manager.

I/O Resource Manager ячеек хранения Exadata взаимодействует с менеджером ресурсов СУБД Oracle — план распределения приоритетов между группами внутри одной базы «спускается» именно со стороны базы данных (рис. 1). С помощью множества критериев СУБД Oracle позволяет классифицировать задачи по «группам потребителей» (Consumer Group). Приоритетность и лимиты на использование ресурсов, в том числе ресурсов ввода-вывода, между группами определяются на основе многоуровневого плана.

Рис.1. Ячейка хранения Oracle Exadata производит построение очереди запросов ввода/вывода согласно идентификаторам, присутствующим в каждой команде, и плану выполнения, определяемому на уровне БД

Количество уровней и групп варьируется в зависимости от потребностей — в одной базе данных можно определить несколько планов, которые будут активизироваться по заданному расписанию. Лимиты гарантируют минимальную пропускную способность и могут жестко вводить ограничения сверху на использование ресурсов ввода-вывода. При этом запросы от системных процессов экземпляра СУБД Oracle всегда имеют наивысший приоритет.

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

При наличии в очередях ввода-вывода запросов от нескольких баз данных на первом шаге производится выбор базы, а затем в очереди запросов базы данных выбирается наиболее приоритетная на данный момент группа «потребителей» (рис. 2). Подобный механизм управления ресурсами ввода-вывода дисковой системы при запросах от СУБД Oracle реализован только в Exadata — использование протокола iDB позволяет «метить» каждый запрос идентификаторами базы данных, группы потребителей, системного процесса и типом запроса. Кроме этого, менеджер ресурсов обеспечивает выполнение с высоким приоритетом критически важных запросов ввода-вывода, влияющих на производительность системы в целом, и, наоборот, уменьшает приоритет некритичных операций.

Рис.2. Если на Exadata работают несколько баз, то исходя из плана распределения ресурсов выбирается база, а затем группа «потребителей». Критически важные системные запросы всегда обрабатываются в первую очередь

Oracle Exadata Database Machine

Возможности эффективного управления ресурсами ввода-вывода для любых вариантов нагрузки дополняются функционалом, позволяющим экстремально увеличить производительность выполнения запросов разного типа. Ключевыми возможностями Exadata, помимо I/O Resource Manager (рис. 3), являются:

• Smart Flash Cache — кэш емкостью 5,3 Тбайт, построенный на основе технологии флэш-памяти, обеспечивает хранение часто используемых данных. Встроенный интеллект и интеграция ячеек хранения Exadata с СУБД позволяют повысить эффективность его использования, обеспечивая быструю реакцию на изменение набора активных данных.
• Smart Scans — технология увеличения скорости выполнения запросов по обработке больших массивов данных. При этом массивные операции, связанные с фильтрацией строк и проекцией столбцов, производятся внутри ячеек хранения, что освобождает ресурсы серверов СУБД для выполнения другой работы.
• Hybrid Columnar Compression — технология сжатия данных, нацеленная как на увеличение скорости обработки запросов путем сокращения требуемых дисковых операций, так и на многократное сокращение требуемых объемов дискового пространства.

Рис. 3. Ключевые возможности Exadata

***

Exadata Database Machine — оптимальное средство консолидации баз данных Oracle уровня предприятия. Машина обладает встроенными разграничениями использования системных ресурсов между базами данных и группами отдельных пользователей, как на уровне серверов СУБД, так и на уровне системы хранения. Функционал Exadata позволит обеспечить максимальную скорость выполнения практически для любых типов задач баз данных.

Владимир Демкин ( pr-team_ru@oracle.com ) — ведущий консультант по направлению Oracle Exadata, «Oracle СНГ» (Москва).