Oracle Exadata X2-8

Немного (вышло много, вот так странно получилось) о непонятном.

Все ниже – глубокое ИМХО и попытки разобраться с весьма занятной “железкой”, а точнее – целой большой горой “железа”, удачно скомпонованной в стойку, которую Oracle именует Exadata 😉

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

С удовольствием почитаю комментарии, если таковые будут – и внесу поправки (в свою точку зрения в том числе). Если нет желания писать в комментариях – можно отписать и в почту – spam (at) nest.org.ru – зачтем, учтем.

Попытки разобраться и сложить некую общую картинку про новую систему поначалу привела меня в полный тупик – я совсем слаб в продуктовой линейке Oracle, имею только базовые представления о Oracle RAC… Тем не менее, даже мне было очевидно, что (старая) Exadata X2-2 не решала проблемы довольно большой части клиентов с классической СУБД – к сожалению, Oracle RAC подходит не всем. Если посмотреть на Exadata X2-2 – это кластер из восьми нод, связанных исключительно быстрым и низколатентным Infiniband-интерконнектом, с Oracle Linux на “борту” нод. Кто уже имел готовые решения, нормально работающие с Oracle 11g, Linux и RAC, имел внедренный ASM – собственно, могли бы безболезненно перейти на новую машину (да и технологию). За рядом маленьких “но” – некоторое количество инсталляций Oracle (RAC) наверняка работают на платформе Solaris/SPARC – в голове довольно большого количества людей (клиентов) прочно закрепилось мнение, что High-End линейка серверов Sun (M8000/M9000, ранее – SunFire 25K и т.д.) – это как раз то самое, на чем и должен работать Oracle – и, видимо, неспроста… Сами по себе файлы данных (datafile) платформенно-зависимые и требуется специальная операция по конвертации их в нужный формат платформы. Миграция на совсем другую архитектуру – процесс не простой и требующей основательной подготовки, как от собственно клиента, так и от поставщика решения, требующий массу времени и ресурсов с предварительным тестированием и длительной подготовкой собственно к миграции. Идем дальше – задержки внутри RAC через Infiniband хоть и малы (микросекунда(ы)?), но ни коим разом не сравняться с задержками внутри большой SMP-машины – и эти машины (M9000, X4800) имеют свой стабильный, хоть и небольшой “кусок” рынка.

Так или иначе – хотим мы этого или нет – Oracle, удачно прикупив Sun, представил новую Exadata X8-2. Что имеем теперь? Две ноды, каждая из них – просто невероятная восьмисокетная числодробилка с максимальным объемом памяти в один терабайт. Это несколько улучшает ситуацию с Oracle RAC – но не более того – по крайней мере, вопрос с производительностью одной ноды решен действительно кардинально. Внутри – Oracle Enterprise Linux + Oracle 11g. Сервер хранения – тоже хорош, показывает просто фантастические цифры – до 300 терабайт на стойку, до 50 гигабайт/с с дисков. Масштабирование – на высоте – до четырех стоек, далее – специальные кабеля, и растем дальше до восьми стоек. Ого-го как много – 16 нод СУБД…

Возвращаясь к нашим “баранам” – процесс миграции во всей красе. Где SPARC внутри Exadata? Где Solaris? Потеряли? Или я чего-то глобально не понял, или – что-то упустил – неужто этот рынок очень мал и не интересен? Вопрос номер два – как это будет выглядеть с точки зрения High Availability? Я все понимаю – внутри все компоненты продублированы, остановка из-за “железа” – маловероятна в силу правильного подбора компонентов. Остановка из-за ПО – аналогично, все тщательно продумано. Продумать плиту, упавшую с потолка, или проблемы с питанием на узле целиком – увы, намного сложнее – даже самые отлаженные инженерные решения дают сбои, в том числе – и из-за человеческого фактора. Задача – банальна – два сайта, один работает – второй ждет. RTO – сайт на “подхвате” должен быть поднят через максимум несколько минут, RPO – по требованию заказчика – минимален, стремиться к нулю секунд – соответственно, синхронная репликация, соответственно, правильное железо (специфичные системы хранения) – все присутствует. Exadata – решение не для таких сайтов? Или опять упустил ниточку и Oracle умеет это делать все сам?

Короче, пока видится так – если уже есть Oracle RAC на Oracle Linux (или RedHat), все файлы – в ASM, приложение хорошо масштабируется внутри RAC – Exadata просто шикарный выбор – более того – очевидный выбор. А вот со всем остальным – ряд вопросов, причем кое-какие видятся мне весьма и весьма непростыми. Скажем, если сам по себе переход к ASM – видимо, попросту неизбежен для большинства клиентов Oracle, то вот переход к Oracle RAC, увы, не столь очевиден… Получается, Exadata – это High-End по производительности (и даже существенно выше!), но далеко не High-End – по целому ряду функционала.

Все выше – лишь мысли вслух! Решение крайне любопытное, пока – исключительно нишевое. Хочется верить, что в ближайшее время еще будут “горячие” анонсы про Exadata 🙂

UPDATE1: погорячился насчет “только linux и ничего более” – смотрим здесь и читаем, черным по белому:

Solaris 11 will be powering the newly announced Oracle Exadata X2-2 and X2-8 Database Machines, as well as the Oracle Exalogic Elastic Cloud machine. Customers invested in Oracle Solaris will find these new offerings very attractive to standardize their operating system and simplify their IT operations.

Выбору – быть 😉

2 thoughts on “Oracle Exadata X2-8”

  1. Где SPARC? Не ясно, но ясно, что платформа Nehalem уделывает одночастотный SPARC с таким же кол-вом ядер раза в 2-3 по SPECint_rate.

    При этом стоит в 5 раз дешевле.

Leave a Reply