Навигационная программа iGO помимо многих разных достоинств обладает и следующей: какой бы вы не выбрали масштаб просмотра карты, при подъезде к повороту масштаб увеличивается, чтобы детально Вам показать куда следует повернуть. Затем масштаб возвращается на прежнюю установку. Должен доложить, что картинка "до следующего поворота 220 км" смотрится феерично.
Простым администраторам БД (да и вообще всем нормальным людям) конечно хотелось бы подобной простой вещи - если что-то случилось с БД она должна перестартовать автоматически, а если что-то случилось с сервером, БД должна перестартовать на другом сервере.
Я попробую показать как использовать технологии Oracle Oracle VM и Clusterware для достижения этой цели. Прелесть в том, что при эти технологии бесплатны, правда при условии соблюдения
некоторых условий. Также следует помнить, что Oracle VM поддерживает только x86 и
SPARC. Конечно, для x86 мы будем использовать только паравиртуализировный режим, а значит
только ОС Linux & Windows.
Вариант 1. У нас очень маленькая компания, всего один сервер. В этом случае нам поможет осуществить перезапуск БД технология
Oracle Restart.
Нужна ли нам тут виртуализация? По большому счету, вроде бы нет. С другой стороны если у нас скажем 2-х сокетный сервер, а для нашей задачи достаточно 1 сокета, то с помощью Oracle VM можно
сэкономить на лицензии, официально привязав нашу виртуальную машину к одному сокету. Конечно, за все приходится платить, и с Oracle VM это
некоторая потеря в производительности.
Вариант 2. Наша компания хоть и небольшая, но у нас есть несколько серверов, правда до выделенного дискового массива мы еще не доросли. Конечно же, мы можем поступить как и в предыдущем случае, но как же организовать переезд БД между нашими серверами? Без виртуализации нам тут не обойтись..
Вариант 2a. Использовать Oracle VM и возможность Live Migration. Мы устанавливаем в виртуальную машину Oracle Restart, который помогает нам рестартовать экземпляр, и также имеем возможность мягкого перевода нашей задачи с узла на узел. Но вот, что делать если наш сервер отказал и диски стали недоступны?
Вариант 2b. Используем ASM. Поскольку у нас есть только внутренние диски наших серверов, прежде всего нам нужно организовать из них общее дисковое пространство, да и еще обеспечить зеркалирование между ними. В этом нам может помочь технологий iSCSI и Oracle ASM. Коротко идея заключается в следующем: На каждый из серверов мы устанавливаем виртуальный машину iSCSI target (например OpenFiler,
iSCSI Enterprise) или даже вообще
используем встроенный в RHEL 5 пакет. Замечу, что это очень разные по возможностям продукты, будьте внимательны. Теперь мы готовы к тому чтобы развернуть Oracle Clusterware + ASM поверх этой инфраструктуры. Конечно мы делаем это все в виртуальных машинах. С помощью ASM мы легко соберем нужное нам число дисковых групп, причем обеспечим зеркалирование информации между отдельными устройствами, которые есть просто встроенные диски наших серверов. Остается добиться того, чтобы наши БД переезжали -
воспользуемся Oracle Clusterware!
Вариант 2c. Это развитие предыдущей идеи. Только в дополнение, мы установим RAС! Технически это не отличается от предыдущего варианта, за там исключением, что мы просто устанавливаем RAC, а разводим нагрузку различных БД с помощью сервисов. Про сервисы вы можете прочитать в
материалах курса RAC DD4D.
Как построить RAC в окружении Oracle VM. Также не стоит забывать, что RAC бесплатно входит в редакцию Standard Edition (SE). Правда и то, что SE имеет ограничение - ее можно использовать на серверах до 4-х сокетов. Тоже самое ограничение действует для нашего кластера на виртуальных машинах. Это означает (к сожалению это сложно подтвердить ссылкой, но это так), что мы можем взять и построить кластер, скажем на 4-х 4 сокетных серверах, пока наша кластерная БД использует не более 4-х сокетов. Потом поставить еще одну кластерную БД...
Вариант 3. Небольшая компания, несколько серверов, в каждом из которых по несколько сокетов, и есть по крайне мере один дисковый массив.
Вариант 3а. Использовать Oracle VM, OCFS и возможность live migration. В принципе, поскольку тут выделенный массив, то в случае гибели сервера наша виртуализированная БД вполне сможет запуститься на другом сервере.
Вариант 3b. Все тоже самое что и в вариантах 2b & 2c но только iSCSI теперь приходит к нам централизованно.
В принципе мы уже рассмотрели возможные варианты построения системы. Стоит упомянуть, что даже при условии построения системы на основе Standard Edition у нас сохраняется возможность построить разнесенный (extended) кластер, при условии сохранения всех ограничений SE. Конечно же не забудьте в случае разнесенного кластера добавить
3-ий voting disk, например использую NFS.
Вместо заключения: Даже если Вы приобрели только редакцию Standard Edition, мы можете совершенно бесплатно построить свой Grid использую бесплатные технологии Oracle и заставить его быть Вам полезным. *испуганно* Надеюсь все знают что Observer & DataGuard (автоматическая передача логов на standby) это возможности только Enterprise Edition ?
Ссылки:
- Использованы картинки из презентации Алексея Зиновьева, Яндекс. Скачать архив с презентацией можно
здесь.
-
Data Centers with Xen
-
Oracle VM Undergroud
Читать дальше...
Сообщения
