Миграция с Sun SVM в Oracle ASM

[McZim]

Обсуждение статьи: «Миграция с Sun SVM в Oracle ASM»

[RXL]

Такой вопрос: ASM только для БД годится и к файловым системам отношения не имеет?

[McZim]

Да. ASM Это отдельный инстанс Оракла! Он работает с "сырыми" устройствами. На этих устройствах можно распологать все файлы БД, кроме бинарей, трэйсов и файла паролей. ASM подходит и для кластеров. Для расположения бинарей СУБД с поддержкой кластера Oracle предлагает, OCFS (Oracle Cluster File System).

[RXL]

Т.е. дисковое пространство, используемые ASM, доступно только одной базе и второй инстанс на него не посадишь?

Добавлено через 6 минут и 36 секунд:
И какие преимущества дает ASM над классической файловой системой? Насчет прослойки ФС - это мелочь по сравнению с задержками I/O.

[McZim]

RXL, легко Я же и говорю что ASM подходит для кластера. То есть каждый инстанс может получить доступ к данным на ASM. Только для каждого инстанса RDBMS, нужно поставить свой ASM и указать где собственно сами данные.

Посмотри бегло, там есть картинки на которых все понятно.

http://download.oracle.com/docs/cd/B28359_01/server.111/b31107/asmcon.htm

Добавлено через 7 минут и 46 секунд:
Приемущества примерно следующие:

1. Избавляемся от прослойки ФС. При различных БД на разных ФС (ufs,ext3,ntfs), мы не заморачиваемся как управлять файлами данных. Например HP-UX не умеет direct I/O.
2. Автоматическая балансировка нагрузки между дисками группы.
3. Автоматическая ребалансировка данных при добавлении или удалении диска в группу.
4. Возможность настроить группы отказа. Например у нас есть два контроллера, на каждом контроллере по 10 дисков. При выходе из строя одного из контроллера работа сервера не перкращается, ASM будет использовать другую группу!
5. Скорость доступа к данным быстрее, особенно если ФС не умеет direct I/O.
6. Это конечно же возможность использования в кластере. Например ext3 или ufs это не кластераные ФС!

[RXL]

За ссылку спасибо - обязательно ознакомлюсь. Только чуть позже.

По пунктам. Я пойду с другого конца - буду умалять достоинства. Цель - найти наибольшие достоинства.

1.
Насчет ФС я уже писал. HP-UX - экзотика. Родной ОС для Oracle, наверно, стоит считать Solaris, а после 10.2.0.5 он также стабильно работает и под Linux. У этих ОС нет проблем direct I/O.
Управление файлами имеет как плюсы, так и минусы. Я не считаю это обузой, а достоинства простоты холодного и горячего копирования на лицо. Также есть прозрачная поддержка со стороны драйверов блочных устройств: RAID, LVM (для Linux - для прочих ОС есть свои решения), Multipath и пр.
Не спорю, что в случае ASM мы имеет приблизительно похожий сервис с централизованным управлением, но, к примеру, функции RAID я не отдавал бы на откуп прикладного ПО. Масло в огонь подлило еще упоминание в статье перезапуска синхронизации дисков при ряде операций. Подозреваю, что и перезапуск служб Oracle или всего сервера тоже приведут к аналогичной ситуации. RAID, как софтовых вариантах в Linux, так и в аппаратных, не подвержен такой проблеме.

2.
Альтернатива - RAID 0 или n0. Причем, софтовый, аппаратный, на удаленном массиве, multipath или еще какое решение - есть выбор. Также stripe можно организовать через LVM. Впрочем, поверх все этого добра можно и ASM использовать. Т.е. я хочу сказать, что встроенный stripe в прикладном - не достоинство. Оверхед будет существенно больше, чем от LVM или софтового RAID (не говоря уже об аппаратных и вынесенных решениях).

3.
Об этом я уже говорил в п.1 и п.2.
Хотя, да - RAID n0 на ходу не перестроишь. Но в LVM освободить физический диск можно, как и занять новый.

4.
Если не трудно, расскажи подробнее.

5.
Сомнительно. Обоснуй, пожалуйста.
Про direct I/O не надо - говорили у же в п.1. То, что это ускоряет работу с диском, я проверял на практике и совершенно с этим согласен. Но, производительность повышается только для операций чтения или записи, но не для частой модификации, где файловый кеш оказывается весьма полезен.

6.
Существуют и другие ФС, поддерживающие совместный доступ. Правда, как к этому отнесется оракловый кластер - не знаю.


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

[McZim]

1.
Насчет ФС я уже писал. HP-UX - экзотика.

Нет, вполне нормальная ситуация, очень много кто любит HP и использует эту ОС!

Я не считаю это обузой, а достоинства простоты холодного и горячего копирования на лицо.

Тут ты о чем? Если о бэкапах путем копирования файлов, то я за это отрываю руки! Так что не довод! При этом ASM в 11g умеет копировать файлы из своего окружения в ФС!

Также есть прозрачная поддержка со стороны драйверов блочных устройств: RAID, LVM (для Linux - для прочих ОС есть свои решения), Multipath и пр.

Здесь я тоже не понял о чем ты?

Не спорю, что в случае ASM мы имеет приблизительно похожий сервис с централизованным управлением, но, к примеру, функции RAID я не отдавал бы на откуп прикладного ПО.

Если что случиться есть тех поддержка! Поверь коммерчесвое ПО в этом плане намного стабильнее свободного ПО! И потом если тебя это смущает никто не застравляет, используй внешную избыточность!

Масло в огонь подлило еще упоминание в статье перезапуска синхронизации дисков при ряде операций. Подозреваю, что и перезапуск служб Oracle или всего сервера тоже приведут к аналогичной ситуации. RAID, как софтовых вариантах в Linux, так и в аппаратных, не подвержен такой проблеме.

Видимо ты не понял. Ничго перезапускать не нужно, ASM все делает автоматически и не останавливая экземпляра, пользователи как работали так и работают!

Оверхед будет существенно больше, чем от LVM или софтового RAID (не говоря уже об аппаратных и вынесенных решениях).

Про софтверный RAID я уже говорил, это коммерческая реализация со всеми вытекающими. Про аппаратные рэйды я тоже говорил. Про оверхэд не понял!

4.
Если не трудно, расскажи подробнее.

Сомнительно. Обоснуй, пожалуйста.

Oracle сам кэширует данные и поэтому ему повторный кэш на уровне ФС не нужен! Это все общий случай, с каждой БД нужно разбираться отдельно!!!

Существуют и другие ФС, поддерживающие совместный доступ. Правда, как к этому отнесется оракловый кластер - не знаю.

Вот то то и оно! Зачем изучать, заведомо подписываться, на новые ФС, инструменты управления, баги? Если все это можно поиметь в одном месте

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

Да это так, нет ничего идеального! В Oracle багов придостаточно!

[RXL]

Тут ты о чем? Если о бэкапах путем копирования файлов, то я за это отрываю руки! Так что не довод! При этом ASM в 11g умеет копировать файлы из своего окружения в ФС!

Опыт малобюджетной эксплуатации показал, что "в случае чего", когда сервер полностью отказал и на руках только одни диски, то файлы БД можно достать из ФС, а вот что делать в такой ситуации с ASM - затруднюсь. Не буду расписывать детально, но этой зимой меня не спас даже Data Guard: сперва сгорел основной сервер, а пока его ремонтировали - сгорел резервный. С порчей ОС и отдельных файлов табличных пространств. Пришлось собирать новый сервер, ставить ОС, Оракл и переносить файлы данных от горячего бекапа и логи с диска сгоревшего сервера. (Добавлю еще, что это было в выходной день, восстанавливал ночью и на голодный желудок.) Думаю, было бы нормальное железо и ЗИП, я бы по прежнему считал такую ситуацию маловероятной. Я к ней даже не готовился, полагая, что имею три резервных решения: Data Guard, горячий бекап + архивлоги и ежедневный экспорт. Файлы автоматически копировались в три места - на активный сервер и на два других. Всего то неделю без резерва...
По той же причине, в отсутствии фирменного сервиса, Жигуль надежнее иномарки: пусть сыплется, но легче починить своими силами. Повторяю: малобюджетные решения. Если есть бабло, переложить ответственность на саппорт - милое дело.

Также есть прозрачная поддержка со стороны драйверов блочных устройств: RAID, LVM (для Linux - для прочих ОС есть свои решения), Multipath и пр.

Здесь я тоже не понял о чем ты?

ФС пофиг, как организовано блочное устройство, какую производительность и надежность оно имеет. Надо улучшить - улучшай. На ФС и выше нижестоящие решения не повлияют.

Видимо ты не понял. Ничго перезапускать не нужно, ASM все делает автоматически и не останавливая экземпляра, пользователи как работали так и работают!

Что автоматически - я понял. Но из текста я понял, что процесс синхронизации могут прервать некоторые операции, после чего он начинается с начала. Это затягивает синхронизацию. Согласись, что синхронизация - это большая нагрузка на I/O.

Про оверхэд не понял!

Как могут RAID-функции (избыточность, чередование), реализованные в ПО прикладного уровня быть быстрее, чем аналогичные функции в ядре ОС или в аппаратном обеспечении? Никак. Нагрузка на CPU (возможно и на память) будет однозначно больше. Оптимальность работы с дисками - сомневаюсь, что выше. Задержки выполнения I/O операций - больше.

Добавлено через 43 секунды:
4. Макс, это объяснение для маркетинговых презенташек. По твоей ссылке есть более техническое объяснение реализации?

Сомнительно. Обоснуй, пожалуйста.

Oracle сам кэширует данные и поэтому ему повторный кэш на уровне ФС не нужен! Это все общий случай, с каждой БД нужно разбираться отдельно!!!

Соглашусь.


Добавлено через 1 минуту и 24 секунды:

Существуют и другие ФС, поддерживающие совместный доступ. Правда, как к этому отнесется оракловый кластер - не знаю.

Вот то то и оно! Зачем изучать, заведомо подписываться, на новые ФС, инструменты управления, баги? Если все это можно поиметь в одном месте

Тоже соглашусь. Я лишь указал, что есть альтернатива.

[McZim]

Согласись, что синхронизация - это большая нагрузка на I/O.

RAID синхронизация тоже нагружает I/O дай боже!

Как могут RAID-функции (избыточность, чередование), реализованные в ПО прикладного уровня быть быстрее, чем аналогичные функции в ядре ОС или в аппаратном обеспечении? Никак. Нагрузка на CPU (возможно и на память) будет однозначно больше. Оптимальность работы с дисками - сомневаюсь, что выше. Задержки выполнения I/O операций - больше.

При нынешних CPU не критично. Например в SPARC архитектуре, можно сказать что определенные ядра должны обрабатывать только lwps и не отвлекаться на I/O. Сомневаюсь что задержки I/O будут сильно заметно различаться.

Макс, это объяснение для маркетинговых презенташек. По твоей ссылке есть более техническое объяснение реализации?

Ничего маркетингово не вижу, как раз показан принцып. Да по ссылке есть, еще можно пройти по ссылкам в разделах See Also:

У каждой реализации есть плюсы и минусы. Но ИМХО для раоты с СУБД Oracle, ASM вкупе с дисковыми массивами, это очень хорошее решение!

[RXL]

Согласись, что синхронизация - это большая нагрузка на I/O.

RAID синхронизация тоже нагружает I/O дай боже!

... Это затягивает синхронизацию. ...

При нынешних CPU не критично. Например в SPARC архитектуре, можно сказать что определенные ядра должны обрабатывать только lwps и не отвлекаться на I/O. Сомневаюсь что задержки I/O будут сильно заметно различаться.

Количество CPU на задержку мало влияет. Как я говорил, I/O дает много больше задержку, чем весь обвес. Но в посте №7 я хотел показать, что ASM не имеет в плане задержек преимуществ перед другими решениями.


После того, как отделяются все малосущественные и мнимые преимущества, остается собственно сама соль продукта. Я вижу тут только удобство централизованного управления и саппорт.

[McZim]

После того, как отделяются все малосущественные и мнимые преимущества, остается собственно сама соль продукта. Я вижу тут только удобство централизованного управления и саппорт.

Как ты заметил я не писал статью о том что ASM круче самого брюса ли Да, главное достоинство это удобство в управлении, например миграция с одной полки на другую делается парами кликов через EM или парой команд через sqlplus. Плюс достоинство появляется в том что если у тебя работа с разными вендорами ОС, тебе не нужно винить их в проблеме если что то произошло, а только Oracle, и не нужно изучать инструменты работы с ФС.

Все же исключение ФС из уровня хранения данных, я считаю это тоже достоинством, хоть ты так и не считаешь.

Да и кстате, с версии 11g, ASM входит в комплект Oracle Clusterware, так что при инсталяции RAC окружения, ASM, это обязательное требование.

В сингл инстанс версиях по прежнему есть выбор что конфигурировать, и это замечательно!

[RXL]

Макс, ну, я тоже как бы не меряюсь. С самого начала честно написал:

По пунктам. Я пойду с другого конца - буду умалять достоинства. Цель - найти наибольшие достоинства.

[McZim]

Ну собственно, здесь важно что считать достоинствами, а достоинства образуются из целей

[Алексей++]

очепятка

Два SCSI диска по 36Гб,  собранными в зеркало,