Базы данных Oracle - статьи

         

Развитие СУБД Oracle как платформы для GRID вычислений


Начиная с версии 10g компания Oracle позиционирует свою СУБД как платформу для GRID вычислений. Концепция GRID вычислений достаточно проста, понятна, гибка и позволяет экономить средства предприятия []. Поэтому в последнее время наблюдается постепенное внедрение этой архитектуры в IT инфраструктуру.

Вскоре ожидается появление первых GRID с более чем тысячью процессоров. Сегодня многие крупные информационные системы используют от 100 до 300 процессоров. Реализуются как малые кластеры, состоящие из нескольких больших SMP машин (например, 2 узла по 64 процессора или 4 узла по 32 процессора), так и большие кластеры, состоящие из множества мелких элементов (например, 32 узла по 4 процессора). Для российских заказчиков тестируются конфигурации с 1,5 сотней процессоров.

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

Уже сегодня Oracle 10g позволяет объединить в кластер до 64 узлов. В Oracle 11g эта цифра удвоится. И каждый узел может иметь множество процессоров и ядер. Таким образом суммарная вычислительная мощность такой GRID может превысить вычислительную мощность серьезных mainframe машин. Кстати, уже сегодня Oracle использует для TPC тестов двухтеррабайтный буферный кэш, так что растет не только процессорная мощность GRID, но и ее суммарная память.

Одним из примеров удачного внедрения GRID технологии является хорошо известный многим Интернет магазин . Изначально хранилище данных было реализовано на основе нескольких SMP машин, но затем, с целью повышения мощности и снижения стоимости системы, ее решили перевести на платформу GRID. В качестве элементов GRID использовались четырехпроцессорные компьютеры с OC Linux, на которых был установлен Oracle 10g RAC и Oracle ASM. Архитектура системы представлена на рисунке 1.




Рис.1.Хранилище данных

Система состоит из нескольких блоков:

  • извлечение данных из исходных систем


  • интеграция, преобразование и денормализация данных


  • блок обработки запросов и анализа данных


  • блок доступа к данным и публикации.


  • Извлечением данных занимаются так называемые extract серверы. Далее они передают данные в блок интеграции и преобразований. SMP машины блока интеграции и преобразований были заменены GRID из 8 узлов. Объем данных, хранимых на этом этапе – 12 терабайт. SMP машины блока обработки запросов и анализа были заменены на GRID из 16 узлов. Объем данных хранилища – 66 терабайт. Данные extract серверов поступают в первый GRID (это Stage область), после чего загружаются в хранилище на второй DRID.

    После реализации такой линейки из 8+16=24 узлов выяснилось, что стоимость такой инфраструктуры, благодаря использованию дешевых элементов, более чем в 2 раза ниже стоимости предыдущей системы. Поэтому было принято решение реализовать вторую такую же линейку из 8+16 узлов, которая будет дублировать работу первой линейки. Теперь данные extract серверов поступают как на первую, так и на вторую линейку серверов и в компании всегда существует 2 одинаковые версии хранилища. Одна из них является основной, а на вторую можно переключиться в случае сбоя. Такая архитектура позволила отказаться от частого копирования активных оперативных данных. Причем суммарная стоимость такой продублированной архитектуры оказалась ниже стоимости старой системы.

    Этот пример еще раз подчеркивает преимущества GRID вычислений, поэтому в версии Oracle 11g был реализован ряд изменений, улучшающих использование СУБД Oracle в GRID. Особое внимание было обращено на снижение времени простоя элементов GRID. Если раньше большинство производителей СУБД прилагало усилия к снижению времени простоя систем, возникающего из-за внезапных, незапланированных причин (поломка компьютера, сбой операционной системы или приложения, человеческие ошибки, катастрофы, потери файлов и т д.), то теперь Oracle сосредоточился на снижении времени плановых простоев.

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

    Список новых возможностей Oracle 11g для сохранения работоспособности приложений при внесении изменений изображен на рисунке 2.



    Рис. 2. Новые возможности Oracle 11g для сохранения работоспособности приложений

    Коротко рассмотрим эти возможности.


    Содержание раздела