Что за зверь Oracle Exadata?

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

Архитектура

Так что же из себя представляет Oracle Exadata внутри? Это набор серверного оборудования стандартной архитектуры x86_64 для серверов хранения и серверов баз данных, коммутаторов транспортной подсистемы на основе Infiniband и инфраструктурных компонент (Ethernet коммутатор внутренней сети управления и KVM-переключатель). Все это компактно упаковано в один стандартный 19" серверный шкаф.

Транспортная подсистема Exadata включает в себя два коммутатора Oracle Data Center Infiniband Switch (leaf-switch или коммутаторы подключения серверов) для организации взаимодействия внутри комплекса между серверами баз данных и серверами хранения. На основе коммутаторов формируется единая резервированная сеть Infiniband. Каждый сервер включен двумя портами Infiniband QDR 40Gb/s: основным и резервным (в режиме failover), что гарантирует автоматическое переключение на резервный канал связи при выходе из строя одного Infiniband-кабеля или одного из коммутаторов транспортной системы.

В зависимости от типа серверов СУБД, различают две модели Exadata: Oracle Exadata X2-2 и Oracle Exadata X2-8. Oracle Exadata X2-2 может поставляться в трех конфигурациях: Quarter Rack (2 сервера баз данных и 3 сервера хранения), Half Rack (4 сервера баз данных и 7 серверов хранения) и Full Rack (8 серверов баз данных и 14 серверов хранения).(См. рис.1).

Рис. 1 – Виды Exadata.

Cерверы стандартной архитектуры

В основе Exadata используются серверы стандартной архитектуры Oracle Sun Fire X4170M2, X4270M2 и X4800.

Характеристики серверов приведены в таб.1.

Серверы хранения во всех вариантах комплекса представляют собой серверы Oracle Sun Fire X4270 M2. Каждый сервер хранения укомплектован дисковым шасси на 12 дисков. В зависимости от инсталлированных дисков весь сервер хранения будет маркирован как HP (High Performance) либо HC (High Capacity). В настоящее время смешивание серверов хранения разных типов в рамках одной Exadata не поддерживается. Необходимо отметить, что никаких избыточных структур (RAID) на уровне серверов хранения не создается, резервирование дисковых ресурсов выполняется средствами Oracle Automatic Storage Management (Oracle ASM) на уровне серверов баз данных.

Таб. 1 – Характеристики серверов.

Компоновка оборудования в шкафу

Как уже было сказано выше, для размещения компонент комплекса используется серверный шкаф Oracle Sun Rack II 1242, который представляет собой стойку шириной в 19" (600мм) с двумя распределителями питания и глубиной в 1200мм. По центру шкафа располагаются инфраструктурные компоненты: Ethernet-коммутатор, KVM-консоль и два leaf-switch Infiniband, которые занимают 5 Rack Unit (RU). По обе стороны от центральных компонент (вверх и вниз по 4 RU) выделены места под серверы баз данных. В зависимости от комплектации X2-2 (quarter, half или full) эти места заполняются снизу вверх, а в комплектации X2-8 эти места всегда заняты двумя серверами баз данных. Далее по 14 RU сверху и снизу выделено для размещения 14 серверов баз данных, каждый из которых высотой по 2 RU. Так же как и с серверами БД, серверами хранения, в зависимости от комплектации Exadata, эти места заполняются снизу вверх.

Серверный шкаф Exadata поставляется заказчику предынсталлированным, с полной внутренней коммутацией, что позволяет использовать его практически из коробки (out-of-box). (См. рис.2).

Рис. 2 – Серверный шкаф Exadata.

Встраивание Exadata в ЦОД заказчиков

Несмотря на относительную сложность внутреннего состава Exadata, она достаточно проста для интеграции в инженерную инфраструктуру ЦОД. В зависимости от принятых стандартов питания в ЦОД, Exadata может быть заказана в конфигурации с трехфазным или однофазным питанием. Продувка серверного шкафа осуществляется спереди назад, что позволяет размещать ее в стандартных рядах стоек, не нарушая концепцию «горячих» и «холодных» коридоров.

С точки зрения включения в локальный сегмент сети передачи данных, Exadata выглядит стандартным сервером, который несет на себе порты для подключения 1GbE медными кабелями или 10GbE через оптические порты. Также Exadata с применением дополнительных серверов резервного копирования может быть интегрирована в существующие СРК заказчика. Почему нужен дополнительный сервер? Потому что включения Exadata в систему хранения данных заказчика на основе FC-коммутаторов не предусматривается, и напрямую писать данные резервных копий на ленточные приводы с протоколом FC невозможно, а объемы данных, располагаемые на этом комплексе, не позволяют в короткие окна резервного копирования осуществить копирование через Ethernet. В качестве естественной альтернативы может рассматриваться подключение сертифицированных систем хранения непосредственно в коммутатор Infiniband самой Database Machine. При этом запрещается размещать какое-либо оборудование в серверном шкафу Exadata даже в свободных позициях, так как это не даст возможности в будущем осуществить upgrade до большей конфигурации, а также потенциально несет незапланированную энергетическую нагрузку на блоки распределения питания серверного шкафа.

Вопросы надежности и доступности

Является ли ПАК Exadata действительно решением Enterprise уровня? Ответить на этот вопрос нам поможет анализ средств обеспечения надежности и отказоустойчивости комплекса в целом. Мы уже отмечали, что дублирование начинается с обеспечения всего оборудования в серверном шкафу резервированным электропитанием (резервирование осуществляется средствами модулей распределения питания серверного шкафа Oracle Sun Rack II 1242). Транспортная система Exadata также имеет 100% резервирование и при выходе из строя одного кабеля или коммутатора не теряет в пропускной способности и доступности компонент между собой.

Дальше начинается самое интересное: как уже отмечалось выше – никаких RAID-структур на серверах хранения не создается. Это не ошибка – это технологическое решение, позволяющее разгрузить серверы хранения от операций вычисления контрольных сумм, поддержки целостности избыточных структур. Но тогда как обеспечивается надежность хранения данных? На серверах баз данных работает Oracle Automatic Storage Management (ASM), который в нормальном режиме осуществляет зеркалирование блоков данных на различных дисковых ресурсах. Это значит, что каждый блок данных будет гарантированно записан с дублированием на двух независимых дисках, не принадлежащих одному серверу хранения. В такой конфигурации выход из строя одного физического диска или даже целого сервера хранения не приведет к потере данных. ASM «пометит» группу дисковых ресурсов как группу с проблемами и выждет тайм-аут на восстановление работоспособности физического оборудования. Если по истечении тайм-аута сбой не устранен, ASM начнет работы по перемещению данных таким образом, чтобы опять каждый блок данных был записан в двух независимых местах.

Казалось бы, при таком подходе сервер баз данных может стать единой точкой отказа, но для резервирования экземпляров БД рекомендуется использовать Oracle Real Application Cluster (RAC). Тогда при выходе из строя одного из серверов кластера доступность БД в целом не снижается и не будет потеряно ни одной завершенной транзакции. Конфигурация Oracle RAC не является обязательной. Внутри одной Exadata высокая доступность может быть обеспечена с помощью Oracle Clusterware (failover-конфигурация) или RAC One Node. Между Exadata, расположенными на разных площадках, – с помощью создания резервной БД механизмом Oracle Data Guard. Конечное решение по схеме резервирования остается за проектировщиком на основании требований по времени восстановления предоставления сервиса.

Производительность

Но вернемся к вопросу – почему Exadata? Что даст нам этот ПАК с точки зрения производительности?

Мы уже знаем, что серверы баз данных в случае Exadata – это современные высокопроизводительные серверы стандартной архитектуры на базе Intel Xeon Processor, в комплектации X2-2 по 12 вычислительных ядер на сервер баз данных и 64 ядра для каждого узла в X2-8.

При этом практически для всех задач рекомендуемая конфигурация Oracle RAC даёт линейное масштабирование, а его коэффициент зависит от качества реализации задачи в плане минимизации конкуренции за ресурсы. Как показывает опыт, используя стандартные рекомендации Oracle, можно улучшить коэффициент масштабирования даже для тяжелых OLTP-задач с высокой конкуренцией за разделяемые ресурсы без изменения кода.

Но производительность любой БД складывается из вычислительной мощности сервера баз данных и производительности дисковой подсистемы или серверов хранения (для Exadata). Рекомендуемая и реализуемая «из коробки» конфигурация дисковых ресурсов изначально «размазывает» дисковую нагрузку равномерно по всем физическим дискам всех серверов хранения, и все серверы хранения параллельно обслуживают запросы базы данных. Таким образом, кэширование данных осуществляется на нескольких последовательных уровнях: кэш-память физических дисков, кэш-память дискового контроллера, Flash Cache. Все это позволяет достичь высоких показателей производительности ПАК Exadata в целом, даже в самой маленькой конфигурации Quarter Rack.

Расширение и масштабирование

Понятно, что даже проведя качественное планирование развития с целью выбора и приобретения оптимальной конфигурации, рано или поздно встанет вопрос расширения существующей Exadata, например, из конфигурации Quarter Rack в Half Rack или даже в Full Rack. Это не является проблемой, и существуют легальные механизмы по такому расширению. (См. рис. 3).

Рис. 3 – Модернизация Exadata.

Но что делать, если у нас уже X2-2 Full Rack или X2-8, а мощности не хватает? Нет ничего проще – ставим рядом еще одну Exadata и связываем их по Infiniband таким образом, что два шкафа становятся одной логической Exadata. Все дисковые ресурсы становятся доступными всем серверам баз данных объединенного ПАК, а соединение между шкафами не станет узким местом. Для этого используется высокоскоростное многоканальное соединение через spine-коммутаторы. Spine-коммутаторы образуют ствол дерева Infiniband, к которому подключаются leaf-коммутаторы, к которым уже подключены все серверы Exadata. Так мы можем горизонтально масштабировать ПАК до 8 стоящих рядом шкафов, получив до 1024 вычислительных ядер серверов баз данных и до 1344 физических дисков в серверах хранения. (См. рис. 4).

Рис. 4 – Горизонтальное масштабирование.

Технологии

Infiniband

В основе транспортной подсистемы Exadata применяется технология высокоскоростных коммутируемых соединений Infiniband. Сеть Infiniband – это двустороннее высокоскоростное соединение типа «точка-точка» с гарантированно низкой задержкой при передаче данных. Классическая скорость передачи данных в Infiniband, называемая единичным потоком – Single Data Rate (SDR), составляет 2,5 Гб/с. Для связи в Exadata используется увеличенная в четыре раза линейная скорость передачи данных Quad Data Rate (QDR, 10 Гб/с на канал), а каждое соединение типа сервер-коммутатор агрегирует по четыре QDR канала, что дает общую производительность канала в 40 Гб/с. Если сравнивать с традиционными схемами построения СХД на основе FC (8Гб/с) или СПД (10Гб/с), то мы увидим превосходство скорости передачи в 5 и 4 раза соответственно, при этом на каналах Infiniband гарантированно низкая задержка, что наиболее критично для кластерного взаимодействия в Oracle RAC. Наличие Infiniband в Exadata позволяет избежать узкого места в архитектуре решения.

Flash Accelerator

Известно, что традиционные жесткие диски обладают относительно невысокой производительностью (около 180 IOPS для дисков 600GB@15kRPM). Для получения необходимой производительности в классических системах используется подход распределения информации по множеству жестких дисков, пусть даже с невысокой утилизацией по объемам, либо применение дорогостоящих «твердотелых» дисков (Solid State Disks). При этом доступ к этим дискам происходит через те же каналы связи и контроллеры, что и к обычным дискам системы хранения. В Exadata применили новый подход – в каждом сервере хранения установлены по четыре Flash Accelerator FA20, которые представляют из себя контроллеры SAS-2 6Gb/s со своей кэш-памятью, обслуживающие лишь flash-диски. Это означает, что доступ к информации на этих дисках происходит практически с нулевыми задержками, операции кэшируются в защищенной суперконденсатором кэш-памяти, а скорость таких дисков может достигать десятков тысяч IOPS.

Exadata Smart Scans

Сервера хранения в некотором виде получили интеллект за счет внедрения Exadata Software. Теперь выполнение части SQL-запросов может выполняться не на серверах БД, а именно на серверах хранения. Это означает, что Exadata Software на серверах хранения не просто понимает структуру хранимых сегментов базы данных, но и имеет возможность осуществлять выборки по сегментам таблиц, хранящихся на конкретном Exadata Storage Cell. При этом сервер БД осуществляет только агрегирующую роль, а непосредственно выборки и фильтрация данных происходят на узлах хранения.

Разберем пример, характерный для классической DWH системы: требуется из миллиарда записей найти всего несколько сотен. Классические системы вынуждены выполнять последовательную фильтрацию всех записей с чтением полного объема данных из системы хранения в память сервера БД. Exadata умеет распределять задачу сканирования на серверы хранения: каждый сервер хранения выполняет сканирование только той части данных, что расположена на нем и выдает поднабор, удовлетворяющий условию из своих данных. Такой набор может быть пустым, а сервер БД занимается непосредственным приемом результатов от серверов хранения и объединения в единый пакет результата. Таким образом, в Exadata реализовано «интеллектуальное» хранилище данных, имеющее возможность выполнять часть операций, которые обычно выполняет сервер СУБД.

Exadata Hybrid Columnar Compression

В Exadata реализован новый подход к компрессии данных. Хранение таблиц организуется с использованием Compression Unit (CU) – логического раздела, который размещается в множестве дисковых блоков базы данных. Количество строк в CU определяется в момент загрузки и зависит от объема строки и требуемого уровня компрессии, данные в CU группируются по столбцам (См. рис.5).

Рис. 5 – Структура Compression Unit.

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

Дополнительно, в зависимости от характера сжимаемых данных (ARCHIVE или QUERY), можно задать различный алгоритм сжатия, который позволит либо получить высокую компрессию для статичных данных архивных систем, либо меньшее сжатие, но более высокую скорость доступа для DWH баз данных.

Storage Indexes

Еще одной отличительной особенностью Exadata является технология Storage Indexes – это псевдоиндексы на уровне серверов хранения. Для каждого региона данных размером в 1 МБ на сервере хранения формируется динамический индекс, включающий вычисленные минимальные и максимальные значения величин, хранимых в столбцах таблиц, попавших в регион. А это означает, что на задачах с большими выборками данных, прежде чем делать чтение региона данных, проверяется, входит ли искомое значение в интервалы значений данных, хранящихся в данном регионе. И если значение не входит, то строки этого региона не отвечают условиям запроса, и чтение блоков данных региона не производится.

Storage Indexes – это динамические структуры, они вычисляются при первой выборке, затрагивающей регион данных, и находятся в оперативной памяти серверов хранения до перезагрузки либо до изменения региона данных. В этом случае значения для блока Storage Index обнуляются и будут вычислены вновь при первом запросе, затрагивающем этот блок данных.

Такой подход позволяет эффективно снижать объемы обрабатываемой информации в поисках результатов запросов, а также дополняет существующие традиционные механизмы сегментирования объектов на секции по тем или иным полям (Partitioning). И на задаче поиска 100 строк из миллиарда происходит (если возможно) определение секции средствами Partitioning, дальше запрос распараллеливается на серверы хранения, и на них выбираются только те блоки, которые содержат искомые данные.

Полный комплекс – Oracle Exadata Database Machine

База данных как сервис

Актуальный лозунг компании Oracle – это комплексные решения на всех уровнях от аппаратного обеспечения до прикладного программного обеспечения. Таким образом, можно рассматривать Exadata как первое действительно комплексное решение от компании Oracle для размещения и консолидации баз данных. Не случайно полное название этого комплекса – Oracle Exadata Database Machine. Фактически вместе с покупкой Exadada заказчик получает готовую интегрированную платформу обслуживания баз данных промышленного уровня с короткими сроками развертывания и внедрения. Отличительным качеством Oracle Exadata Database Machine является практически линейная горизонтальная масштабируемость производительности. Увеличивая таким образом свою Exadata, заказчик получает одновременный прирост производительности и доступных дисковых объемов.

Exadata для пользователей и приложений

Насколько сложен переход на ПАК Exadata для приложений? Как взаимодействовать с этой умной машиной для СУБД? Оказывается, что ничего проще нет – для приложений Exadata представляет собой не что иное, как обычный высокопроизводительный сервер со стандартными протоколами доступа к СУБД. Таким образом, от приложения скрыты все сложности внутренней организации, оно не потребует модернизации для работы с Exadata в качестве хранилища данных, просто потребуется перенести БД на Exadata и перенастроить подключения приложения на новый сетевой адрес.

Миграция БД и ППО на Exadata

Миграция на Exadata мало чем отличается от миграции на другую платформу. Как правило, самым сложным при миграции между платформами является вопрос конвертирования между двумя форматами хранения данных (если таковое необходимо). В остальном миграция данных является более-менее стандартным процессом, который требует системного подхода и, в большинстве случаев, времени. Хотя существуют варианты перевода БД в online режиме. Но как уже сказано выше, для самого приложения миграция на Exadata является неявным процессом.

Что в итоге?

В итоге это мощная платформа консолидации БД, альтернатива традиционным архитектурам в части больших БД с аналитической нагрузкой (DWH) и вариант замены под OLTP базы данных.

Это действительно решение Enterprise уровня, надежное и производительное. Вспомним, какие базы данных и приложения обычно располагаются на программно-аппаратных комплексах такого уровня – часто это системы уровня Mission Critical, с жесткими требованиями по времени отклика и доступности.

Теперь архитектура Exadata стала понятна, но прежде чем внедрять, следует провести серии нагрузочных и функциональных испытаний, особенно это касается использования кластеризации на базе Oracle RAC.

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