наверх

Главная, «Открытые системы», № 02, 2012 1841 прочтение

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

Функционал современных дисковых массивов не позволяет эффективно эксплуатировать несколько баз данных, однако машины баз данных от Oracle дают такую возможность.

Ключевые слова / keywords: СУБД

Владимир Демкин

РЕКЛАМА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Exadata Database Machine

 

Большие Данные — новая теория и практика

У каждой промышленной революции были свои символы: чугун и пар, сталь и поточное производство, полимеры и электроника — а очередная революция пройдет под знаком композитных материалов и данных. Big Data — ложный след или будущее индустрии?

Леонид Черняк
Сегодня бизнес уже не может жить в статичном ИТ-окружении, поэтому производители стали выпускать устройства типа Oracle Exadata Database Machine, позволяющие не переписывать имеющиеся приложения и снизить риски потери администрирования.

 

Машина баз данных Oracle Exadata Database Machine обеспечивает высокую производительность хранилищ данных и систем OLTP и позиционируется разработчиками как платформа для консолидации и частных облаков. Машина представляет собой интегрированную систему с предустановленной СУБД Oracle Database 11g R2 и аппаратной платформой, объединяющей серверные мощности архитектуры x86, системы хранения и оптимизированной для высокопроизводительной обработки данных. Машина имеет ряд технологических особенностей, определяющих ее способность работать в условиях экстремальных нагрузок: флэш-память объемом до 5 Тбайт, выполняющая роль кэша между дисками и серверами и обеспечивающая малое время отклика; средства сжатия данных, позволяющие экономить пространство систем хранения; механизм переноса части операций обработки на сторону систем хранения, благодаря чему сокращаются объемы перемещения данных и ускоряется выполнение обращений к СУБД.

 

Ячейки хранения 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 — технология сжатия данных, нацеленная как на увеличение скорости обработки запросов путем сокращения требуемых дисковых операций, так и на многократное сокращение требуемых объемов дискового пространства.
Ключевые возможности Exadata
Рис. 3. Ключевые возможности Exadata

 

Комплектация

Oracle Exadata Database Machine предлагается в двух моделях:

  • Exadata X2-2 — восемь серверов Sun Fire X4170 M2, каждый из которых оснащен двумя шестиядерными процессорами Intel Xeon X5670 и оперативной памятью 96 Гбайт;
  • Exadata X2-8 — два сервера Sun Fire X4800 M2 с восемью десятиядерными процессорами Intel Xeon E7-X8870 и оперативной памятью 2Тбайт.

Обе модели поставляются с 14 ячейками системы хранения, при этом возможны два варианта комплектации: высокопроизводительные диски (100 Тбайт общего «сырого» пространства) и диски большого объема (336 Тбайт). В обоих вариантах система оснащена флэш-памятью 5,3 Тбайт.

Модель X2-2 предлагается в трех конфигурациях — кроме полной комплектации (Full Rack) предлагаются Half Rack (четыре сервера СУБД и семь ячеек Exadata) и Quarter Rack (два сервера СУБД и три ячейки Exadata). Модернизация комплекса от конфигурации Quarter Rack до Half Rack и до Full Rack, а также добавление новых стоек возможны без остановки работы системы.

***

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

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

Купить номер с этой статьей в pdf

Комментарии


19/05/2016 №02

Купить выпуск

Анонс содержания
«Открытые системы»

Подписка:

«Открытые системы»

на месяцев

c

Средство массовой информации - www.osp.ru. Свидетельство о регистрации СМИ сетевого издания Эл.№ ФС77-62008 от 05 июня 2015 г. Выдано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзором)