Машина транзакций

Если определить, что такое Sun Oracle Database Machine одной фразой, то она может звучать так: "Оптимизированный под СУБД Oracle 11g Release 2 массивно-параллельный комплекс на основе стандартных аппаратных компонентов и специализированного программного обеспечения хранения данных". Тем, кому в настоящее время не требуется высокопроизводительное решение для Oracle, причем именно последней версии — 11g Release 2, возможно, этой информации будет достаточно. Однако Sun Oracle Database Machine интересен и входящими в него техническими решениями.

История развития

Первая версия Sun Oracle Database Machine была выпущена совместно с компанией Hewlett-Packard в 2008 году. После объединения Sun Microsystems и Oracle вторая версия, о которой пойдет речь ниже, разрабатывалась, разумеется, на основе аппаратных компонентов Sun. Появление первой версии Sun Oracle Database Machine прошло незаметно, чего нельзя сказать о второй, объявленной примерно годом позже. Возможно, Oracle просто затратил больше усилий на ее продвижение, но, с другой стороны, технологии, подобные используемым в Sun Oracle Database Machine, занимают все больше места на рынке, делая решение более понятным и востребованным.

Впрочем, если брать совсем давнюю историю, то можно предположить, что компания Oracle давно вынашивала планы по более полному контролю аппаратной части, на которой используется ее флагманский продукт. В этой связи стоит вспомнить проект десятилетней давности, который Oracle реализовала совместно с Sun Microsystems, а именно Oracle Raw Iron. Цель подобного «слияния» очевидна — только системные процессы СУБД Oracle наилучшим образом могут предсказать, какие ресурсы или данные потребуются и когда это произойдет. Такая возможность позволяет улучшить общую производительность базы данных за счет оптимизации использования имеющихся вычислительных ресурсов.

Из чего состоит и как работает Sun Oracle Database Machine?

Sun Oracle Database Machine представляет собой набор серверов стандартной архитектуры x64 под управлением операционной системы (конечно же, это Oracle Enterprise Linux), а также стандартного (Oracle Database) и специализированного (Oracle Exadata) программного обеспечения. Серверы разделены в соответствии с двумя ролями:

• сервер баз данных (Database server);
• сервер хранения (Storage server).

Серверы баз данных (на данный момент Sun X4170) работают под управлением стандартного Oracle Database 11gR2 и исполняют роль традиционных серверов баз данных. Существенные отличия мы рассмотрим ниже.

Серверы баз данных не используются для хранения записей — эта роль возложена на серверы хранения. На уровне серверов хранения применен не вполне стандартный подход — данные размещаются на внутренних дисках этих серверов, а управление процессом реализовано в ПО Oracle Exadata, установленном на серверах хранения Exadata Cell.

Ниже приведена общая структура Sun Oracle Database Machine.

"Железная" часть

В качестве технологии взаимодействия между серверами баз данных и уровнем хранения данных используется Infiniband. Традиционному Gigabit Ethernet в рамках Sun Oracle Database Machine отведена роль выделенной сети управления и мониторинга. Впрочем, для внешнего взаимодействия сохранены и обычные порты Gigabit Ethernet 1000Base-T — для обеспечения взаимной связи с пользователями СУБД их вполне достаточно.

Второе существенное отличие Sun Oracle Database Machine заключается в том, что в качестве дисковых массивов используются серверы со специализированным программным обеспечением (Exadata) — главной «изюминкой» решения, выделяющим его среди решений других производителей. Но об этом чуть ниже.

Еще один отличительный признак внесен Sun Microsystems — каждый Storage Server имеет «на борту» флэш-память, позволяющую резко ускорить ввод-вывод. Если учесть, что для современного диска типичным является значение 300 IOPS (операций ввода-вывода в секунду), то в данном случае речь идет о величине 75 000 IOPS. Согласитесь, весомое преимущество. Столь внушительные цифры обеспечиваются не только за счет особенностей самой технологии флэш-памяти, но и благодаря еще одному специальному решению: эта флэш-память не эмулирует диски, как мы уже успели привыкнуть за время распространения данной технологии, что позволило избежать унаследованного узкого места — контроллеров дисков и стандартных дисковых интерфейсов. Здесь память реализована в виде специализированных PCIe-плат. Впрочем, поддержка плат должна быть обеспечена программно, что снова подчеркивает программный уклон решения.

Программные компоненты

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

Storage Server, если провести аналогию, является дисковым массивом. Тогда Exadata выступает в роли управляющего программного обеспечения контроллеров дискового массива. И если традиционным дисковым массивам приходится буквально угадывать при помощи различных адаптивных механизмов, какого рода будет следующий запрос и как оптимально разместить данные на имеющемся наборе дисков, то в случае с Exadata все намного проще — это на самом деле та же СУБД Oracle, которая знает, что и как используется.

За счет полного контроля над размещением данных и распространением их между уровнями в Sun Oracle Database Machine заметно оптимизирована процедура чтения (как если бы контроллер дискового массива уже «знал», что нужно читать с диска в зависимости от конкретного SQL-запроса). При этом, поскольку известно, какая часть данных из таблицы понадобится, даже не все прочитанные данные передаются со Storage Server на Database Server.

Компания Oracle всегда сетовала на то, что существующие оптимизаторы ввода-вывода являются черными ящиками, и она не может повлиять на их поведение. Традиционным решением проблемы было включение Direct I/O, но трафик между сервером и системой хранения по-прежнему оставался чрезмерно большим. Кроме того, управлять поведением программного обеспечения дискового массива очень сложно, а порой и невозможно в достаточной мере.

И ведь речь идет об оптимальных настройках, то есть анализ проведен, и каждый компонент цепочки ввода-вывода настроен оптимальным образом. К сожалению, на практике такое бывает далеко не всегда. Это могут быть как неотключаемые ограничения в управлении ОС, файловых систем, логических томов, так и просто некорректно выполненные, без учета оптимизации производительности, настройки комплекса. При идеальной настройке можно приблизиться к Exadata — создать подходящую инфраструктуру ввода-вывода с интерфейсами Infiniband и полностью оптимизированными под задачу настройками.

Но это будет всего лишь приближение — в Sun Oracle Database Machine эффективно реализовано минимальное перемещение данных между компонентами с использованием интерконнекта. Качество обслуживания с учетом приоритетов уже задано внутри планировщика ввода/вывода в Exadata Cell. С другой стороны, проблему оптимизации размещения данных на дисках пытались решить производители дисковых массивов — HP AutoRAID, HP Enterprise Virtual Array (EVA), а с некоторых пор массовые решения LSI взяли на вооружение Sun и IBM. Параллельным путем в том же направлении идет NetApp.

Варианты конфигураций Sun Oracle Database Machine

Основные варианты поставки просты — четверть, половина и целая стойка. Четверть рекомендуется как начало, подразумевающее обязательное последующее развитие и расширение. Дополнительно возможно как расширение путем установки нескольких дополнительных стоек (стандартно до восьми), так и покупки только часть решения — Exadata Server.

Варианты подробно описаны на http://oracle.com, и останавливаться на них большого смысла нет. Ключевой особенностью вариантов поставки Exadata является предопределенность конфигурации. Серверы имеют вполне определенные процессоры и объемы памяти, набор интерфейсов и ПО, что несколько непривычно для серверов стандартной архитектуры, но в этом есть вполне определенный смысл.

Во-первых, унификация поддержки — этим Oracle застраховался от непредсказуемости поведения различных конфигураций в различных условиях. Ситуации, когда служба поддержки не может воспроизвести проблему, возникшую у пользователя, поверьте, ей нравятся еще меньше, чем вам. А для серьезных баз данных, на которые позиционируется Sun Oracle Database Machine, и вовсе мало приемлемы.

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

Что получает пользователь Sun Oracle Database Machine?

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

Не существует, безусловно, лучших решений. За полученные уникальные результаты приходится чем-то расплачиваться. У Sun Oracle Database Machine есть и негативные стороны:

• Закрытость решения. Нельзя оспорить, что способов повлиять на работу традиционных сборных решений больше, чем на «коробочное» решение, пусть и созданное из известных кубиков. К тому же некоторые из этих кубиков больше похожи на «черные ящики». По крайней мере, так обстоят дела сейчас.

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

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

• Резервное копирование. Пофайловое копирование после приостановки базы, разумеется, осталось в прошлом, точнее, в традиционных реализациях Oracle Database. Речь идет о «продвинутых» техниках резервного копирования — создании и монтировании «снимков» состояния файловых систем. Отпадает и копирование по SAN без участия серверов, что весьма досадно — в этом смысле мы отступаем на шаг назад. Проблемы миграции на Sun Oracle Database Machine тоже существуют — не так-то легко единовременно «перелить» в систему тот объем данных, который подразумевает ее эффективное использование.

• Применение Dataguard ограничено. Когда используется Hybrid Columnar Compression, о структурах хранения данных «знает» только Exadata, приемником на stand by стороне может быть только вторая Exadata, иначе никто не сможет прочитать эти данные. В данном случае поддерживается лишь физический standby, и только если на другой стороне тоже находится Exadata. Поддержка логического standby и streams обещана в следующей версии.

• Не все приложения подходят для переноса на Sun Oracle Database Machine. Если ваши приложения пока «плохо дружат» с RAC, вам придется забыть о миграции до наступления лучших времен. Ведь использовать Sun Oracle Database Machine, основываясь на мощности всего лишь одного из входящих в ее состав серверов, — непозволительное расточительство.

А теперь хорошие новости

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

• Производительность. Мы получили максимум производительности для СУБД Oracle — причем как для OLTP, так и для решений Data Warehouse. Правильно написанное приложение, эффективно использующее параллелизм, будет работать отлично.

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

• Поддержка из одних рук. Тем, кто сталкивался с неоднозначными ситуациями в разрешении проблем, сложно преуменьшить значение этого фактора. Теперь ответственность одного производителя начинается на уровне сетевого подключения к серверу базы данных. И чем бы ни была вызвана проблемная ситуация, вы больше не услышите слов «по нашим данным, все работает нормально».

С чем надо сравнивать Sun Oracle Database Machine?

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

Идеальная среда для внедрения — трудно приживающийся у нас ASP и родственные ему «облачные» вычисления. Чему стоит поучиться у создателей Sun Oracle Database Machine?

Применение создателями Sun Oracle Database Machine стандартных компонентов дает нам, пользователям и интеграторам, прямо скажем, очень редкую возможность использовать отдельные решения из готового продукта в своей повседневной практике. Перечислю то, что мне кажется пригодным для этого:

• Оптимизация конфигурации серверов под задачу. В искусственных ограничениях, которые наложил Oracle на «железо» Sun Oracle Database Machine, есть свой смысл. Часто ли вы видите обычный сервер на двух процессорах Xeon, который имеет 72 Гбайт оперативной памяти? А сколько тот же Oracle прилагает усилий, чтобы минимизировать количество physical read за счет оптимизации? Взять хотя бы рекомендации в отношении размера SGA и его влияния на производительность. Но внимательнее всего читают эти рекомендации сотрудники компании Oracle. Обычно не придается должного значения огромной разнице в производительности оперативной памяти и дисков, число обращений к которым возрастает, если размер буферного кэша СУБД невелик. Разумеется, существуют пределы его увеличения, когда слишком большой размер становится нецелесообразным или, наоборот, может привести к падению производительности. Тем не менее, указанную цифру — 72 Гбайт — можно иметь в виду как ориентир.

• Минимизация объема передаваемых между серверами данных. Очевидно, что любая пересылка данных ведет к снижению производительности. Взаимодействие внутри сервера будет всегда более эффективным, чем между серверами при помощи любого интерфейса, будь то Ethernet, Fibre Channel, SCSI или даже Infiniband. Чем меньше пересылается данных — тем быстрее получаем конечный результат.

  «Умное» ПО Exadata, используемое на серверах хранения Sun Oracle Database Machine, пригодно не для всех задач, а зачастую всё взаимодействие уже предопределено разработчиками используемого ПО. Тем не менее, если узкое место — большой сетевой трафик, то от него надо избавиться в первую очередь. Можно повлиять на программистов (если, конечно, это возможно) или просто исключить пересылку данных, установив приложения, интенсивно взаимодействующие по сети, на один общий сервер более высокой производительности. Классический пример — значительное возрастание производительности одного известного приложения бухгалтерского учета при отказе от клиент-серверной модели и переносе клиентского ПО на сервер с последующим использованием терминального доступа к нему.

• Если пересылка по сети неизбежна — повышаем скорость сети и/или снижаем латентность, в зависимости от того, что более критично. При невозможности локализовать критичное к скорости взаимодействие внутри одного сервера стоит подумать об оптимизации внешнего взаимодействия. В такой ситуации придется ориентироваться или на передовые технологии — как относительно редкие Infiniband, Datacenter Ethernet, так и более «традиционный» 10 G Ethernet, — или же просто оптимизировать использование традиционных интерфейсов и сетевой инфраструктуры путем агрегации нескольких однотипных физических интерфейсов в один логический, а также посредством разрешения jumbo-фреймов, оптимизации стандартных настроек TCP/IP под конкретную задачу и т. п.

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

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

  Деление дискового пространства на разные уровни производительности и использование «правильного» в зависимости от требований применяется давно. Деление на пулы FC/SAS/SATA — это текущее наиболее стандартное и простое воплощение идеи в жизнь. Различие же в производительности флэш-накопителей и жестких дисков намного больше, чем между дисками разных типов, а значит, и намного больше эффект, получаемый за счет введения в иерархию хранения дополнительного уровня флэш-накопителей. Накопитель Sun Flash Accelerator F20 PCIe Card, используемый в Sun Oracle Database Machine, даже лучше чем диск — в нем нет ограничений, присущих дисковым интерфейсам, но за это приходится платить отсутствием «прозрачности» доступа, свойственной «обычным» флэш-дискам. Если использовать его невозможно или нецелесообразно, придется озаботиться поддержанием иерархии данных собственными силами, создав пул высокоскоростных SSD-дисков, или переложить эту задачу на появившиеся в последнее время дисковые массивы с промежуточной флэш-памятью, например Sun Storage 7х10 System, которые предлагает Oracle/Sun.

  Для некоторых операций, прежде всего произвольного доступа (random read/write), результат будет впечатляющим.

• Улучшение распараллеливания исполнения задач. Последнее по порядку, но, пожалуй, первое по значимости условие. В настоящее время развитие идет, скорее, по пути наращивания количества ресурсов, а не роста производительности отдельного элемента. Когда приложение не поддерживает RAC, преимущества Sun Oracle Database Machine оказываются невостребованными. Если раньше стоял вопрос о том, что приложение должно эффективно работать на одном многопроцессорном сервере, то сейчас требования растут — приложение должно эффективно использовать ресурсы нескольких серверов. В качестве примера такого решения можно привести Oracle RAC.

Эти решения не новые, они уже неоднократно применялись. Тем не менее, Oracle помог нам еще раз обратить внимание на достижение достойных результатов посредством относительно небольших усилий. Возможное будущее Sun Oracle Database Machine, Exadata и других решений.

Нет сомнений, Oracle и далее будет развивать Sun Oracle Database Machine — текущее поколение фактически уже третье, несмотря на официальное именование «V2». Вряд ли последующие изменения будут значительно менять вид продукта. Можно ожидать в первую очередь дальнейшего усовершенствования как Exadata, так и «обычного» Oracle Database. Можно предположить, что эти изменения будут направлены не только и не столько на улучшение Sun Oracle Database Machine, а на дальнейшее развитие возможностей Grid-вычислений, которые окажутся полезными и в реализации последующих поколений Sun Oracle Database Machine.

Что касается «железной» части, то здесь радикальных изменений ждать не стоит — все последует за развитием стандартных серверов; возможно, Oracle/Sun решится на замену database серверов на блейд-шасси. В любом случае нас ждет дальнейшее совершенствование, снятие некоторых имеющихся ограничений и, безусловно, дальнейшее повышение производительности.

Что же касается других вендоров, то на альтернативу Sun Oracle Database Machine особо рассчитывать не стоит — пока только IBM обладает собственной СУБД и необходимым для этого «железом».

Возможно, характеристики Sun Flash Accelerator F20 PCIe Card подтолкнут других производителей на создание флэш-накопителей, не связанных ограничениями SAS-интерфейса. Такие попытки уже были и большого успеха не имели, ведь нужно иметь не только быструю память, но и программную возможность эффективно ее использовать — здесь у альянса Oracle/Sun есть преимущество.

Интересным направлением развития могла бы стать интеграция интеллектуальных функций по хранению данных в обычные дисковые массивы. Больших технических сложностей на этом пути нет, но заинтересованность производителей ПО и производителей дисковых массивов под большим вопросом. Ближе всего к успеху находится альянс EMC и VMWare с потенциальной «Virtualization Machine», но ПО VMware не имеет такого контроля над гостевыми средами, как Oracle над своими структурами данных, поэтому выдающихся результатов ждать не приходится.

Подводя итог, хотелось бы подчеркнуть, что Sun Oracle Database Machine представляет собой значительное достижение. Нам продемонстрировали: высокая производительность — это не обязательно серверы и системы хранения старшего класса.

Предыдущая новость:
В ожидании синергии Следующая новость:
Новые возможности применения технологий анализа трафика