Что это: миграция на уровне файловой системы.
Как работает: в одну единственную опцию: zfs create -o shadow=nfs://system/export/home/ufsdata users/home/shadow2.
Читаем здесь!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

При восстановлении снимка на другой машине через ssh (rsh аналогично) нарвались на проблему с низкой пропускной способностью всего комплекта (zfs send, ssh, zfs receive). Быстрый анализ привел к этой дискуссии.

Проблема хорошо описана здесь – zfs receive имеет характер “пульсирующей” нагрузки (bursty) – приняли блок, чего-то делаем и перевариваем, zfs send в это время фактически простаивает (хотя – оба процесса могут давать пропускную способность много больше – просто у одного не забирают, а другой не принимает данные потоком, “забивая” сеть – получается ситуация, когда все компоненты могут существенно больше, чем есть на деле).

Решение – в том же блоге – описано довольно неплохо – надо буферировать приемо-передачу. Для этих целей создана утилита mbuffer. Небольшое клиент-серверное приложение, создающее буфер заданного объема с заданным размером блока внутри.

Успешно собирается (товарищ подтвердит) на Solaris 10, можно и пакеты поставить готовые.

Использование:

# принимаем поток
[root@server2]# mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs1
# отправляем поток
[root@server1]# zfs send datapool/fs1@pipesnap | mbuffer -s 128k -m 1G -O 10.0.0.1:9090

На мой вкус – чистый профит – выигрываем почти 10х приростом производительности!

К сожалению, эти механизмы как-то странно обходят собственно в Solaris 10/11 (по крайней мере – очевидного решения я не нашел).

PS: http://truewaytags.blogspot.com/2011/05/zfs.html – а вот и товарищ по несчастью

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Дано: файловая система ZFS, около 1 Тб в объеме, около 2-х миллионов файлов на ней, небольшого размера – 200-400 Кб. каждый. Для понимания – сделаем ls -la внутри этой директории, подождем. Много – и долго.

Надо: изготовить резервную копию этой ФС. Обычный бэкап работает очень медленно (tar, bpbackup) – около 12-18 часов на одну ФС, поток в 4-8 Мб/c – неприменимо, лента занята слишком долго одним заданием. Скорость модификации составляет около 800 Мб-1Гб/сутки по предварительной оценке (добавляются новые файлы). Что делает применение обычного файлового бэкапа вообще малореальным. Задачи восстановления единичного файла с ленты – не стоит. Предполагаем, что политики у нас уже настроены…

Делаем:
- создаем снимок ФС (по хорошему – надо перестраховаться и “притормозить” приложение, но – нам известен регламент записи заранее – и потому этого мы делать не будем, занимаясь изготовлением снимка в подходящий момент)
- создаем пайп
- запускаем процесс отправления снимка
- запускаем процесс бэкапа (в нашем случае NB bpbackup)
- ждем окончания процесса
- удаляем пайп
- удаляем снимок

zfs snapshot datapool/fs1@pipesnap
mkfifo /tmp/pipesnapGate
zfs send datapool/fs1@pipesnap > /tmp/pipesnapGate &
bpbackup <ключи NB> -w /tmp/pipesnapGate &
wait
rm /tmp/pipesnapGate
zfs destroy datapool/fs1@pipesnap

Скорость – 50-80 Мб/c – на порядок лучше, чем стандартными средствами. Очевидный минус – из архива проблематично достать единичный файл.

Как всегда – бэкап без восстановления – пустое место. Если надо – нарисую последовательность команд для восстановления. Она такая же простая. Вдумчивое “курение” документов позволит отказаться от запуска скрипта на стороне сервера.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Кхм – по-русски не звучит, потому плюнул – написал in english. Вот возникла задачка, вот и сделал для себя шпаргалку, чтобы кругами не “нарезать” по сайтам – я все-таки далек изрядно от Oracle DBA’s – специфика у меня другая, но вот приходиться и подумать иногда на отстраненные темы…

Рекомендовано к прочтению: Backup and Recovery@orafaq.com, масса полезной документации лежит здесь. Ну и Google никто не отменял.

Итак: есть Oracle 10gR2 + Solaris 10 x86_64. Есть БД. Некая. Которая лежит на ZFS – плюсы и минусы такого размещения я не обсуждаю, по крайней мере – здесь. Есть метод фактически прошлого века – Oracle User-Managed Hot Backups. Настоящие джежаи меня заклюют, но я не вижу способа использования RMAN в сочетании с ZFS Snapshot в рамках одной машины (вижу, но об этом – другой раз ). Надо: сделать копию БД, которая была бы пригодна к однозначному восстановлению.
Далее – много букофф…
Приступим.
- любым доступным образом проверяем: наличие в памяти Oracle (я обычно смотрю ps -ef | grep pmon), статус БД (открыта/закрыта/etc. – через sqlplus), статус архивации (база ДОЛЖНА быть в состояние ARCHIVELOG – без этого не будет горячего бэкапа), уточняем, куда пишуться наши архивные логи – не буду описывать, как это сделать. Все узнали? Приступаем.
- открываем 2 терминала: 1-й для входа пользователя oracle (наш sqlplus будет работать здесь), 2-й – для root.
- запускаем sqlplus, даем команду – переключаем группу логов – важность сего мероприятия заключена в том, чтобы нам не попасть на “лишнее” переключение в момент создания снимка – эта команда также изменит последовательность:

ALTER system switch logfile;

- даем команду, которая и начнет наше горячее резвное копирование:

ALTER DATABASE BEGIN backup;

- делаем снимок (от id=0/root):

/usr/sbin/zfs snapshot

- прекращаем процедуру горячего бэкапа:

ALTER DATABASE END backup;

- архивируем текущий журнал – КРАЙНЕ важно получить этот файл вместе с бэкапом – он будет лежать в нашем ранее определенном месте:

ALTER system archive log CURRENT;

- делаем бэкап нашего Самого Важного Файла внутри БД – он нам нужен при восстановлении:

ALTER DATABASE backup controlfile TO '/tmp/control-<inst_name>.ctl.bpck';

- на всякий случай можно изготовить копию SPFILE to PFILE и тоже положить ее к нашей резервной копии.
- для упрощения жизни – также полезно изготовить копию control file в читаемом виде, забрав ее в процессе из трейсов:

Все, что нам нужно для получения копии БД – у нас есть. Можем приступить к:
- заливанию всего полчученного счастья на ленты средствами, например NetBackup – делаем клона (zfs clone) в удобном нам месте, “льем” на ленты, не забывая при этом о том, что CoW-snapshot по своей природе создаст нагрузку на дисковую подсистему, которая будет весьма активно конкурировать с нашей продуктивной частью БД.
- созданию клона БД на новой системе – здесь фантазия должна подсказать, что использовать – можно использовать механизмы zfs send/zfs receive (все равно перекидывать файлы руками прийдется), либо использовать NFS-share – либо придумайте сами.
- какие еще варианты – например, такие – быстрое клонирование БД с нашими поправками

При восстановлении есть ряд правил:
- полностью повторяем структуры – где лежат наши файлы с пространствами, где лежат контролы, каталоги для редо-логов
- перед любой манипуляцией дважды проверяем (double-check – как мне нравиться эта фразочка ) наличие всего и вся – каталогов, прав доступа, что вводим и как вводим – порядок команд имеет значение!
- не забываем заменить наши control-фалы на заранее сохраненный нами.
- не забываем восстановить наш ранее сохраненный наш файл архивного лога – он нам необходим при восстановлении.

Последовательность восстановления довольно простая. Для начала – монтируем БД (по вкусу используя заранее заготовленный pfile):

startup mount

- выполняем процедуру восстановления:

recover DATABASE until cancel USING backup controlfile;

Собственно, ньюанс простой – после использования первого же архивного файла мы должны набрать команду CANCEL и прекратить восстановление. Так нам нужно состояние на момент выполнения процедуры горячего бэкапа (фактически его окончание – это переключение лога). Если мы были настолько хитры (и продуманны), что у нас есть набор ВСЕХ архивных логов, изготовленных БД до момента останова (наступления часа Икс – развала нашей инстанции) – восстанавливаем наши логи в нужный каталог, даем команду:

recover automatic DATABASE until cancel USING backup controlfile;

… и нервно курим “бамбук” в сторонке, до окончания восстановления – последний архив (на котором мы, естественно, “споткнемся” и процедура потребует ручного вмешательства), которого нам так будет не хватать – это и будет повод набрать CANCEL, завершив тем самым процедуру восстановления…

Короче, шансы правильно использовать механизмы, предоставляемые СУБД у нас есть – и они неплохие, если внимательно изучать документацию, делать все последовательно – имея при это вменяемый recovery plan, в котором будет написано множество “а что, если”.

Что можно легко доделать: для начала, избавиться от root везде, где только можно – для этого у нас есть мехнизмы делегирования внутри ZFS. Данная заметка элементарно переноситься на систымы Sun Unified Storage. Короче – был бы интерес, а я бы написал

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Посмотрел, отметил “зачетность” сей возможности, порадовался. Вспомнил про Oracle 10 + Solaris 10 с далеко не самым последним релизом, стоящий на V40z и контроллерах Adaptec – в продуктивной среде. Полезность этого нововведения резко сократилась до домашнего и внутриоффисного применения. Забыл до поры, до времени.

А вот сегодня – натолкнулся на крайне полезную заметочку. Смысл прост – качаем LiveCD Opensolaris latest bits (build 128+), загружаемся с него, делаем дальше все по инструкции от Виктора – она предельно проста и перевода не требует. Сам бы не додумался – особенно когда мне это надо было бы делать в “запарке” по факту наличия разваленного пула на площадке – времени бы на “подумать” не оставили бы ;(

Мораль – даже для настоящих джедаев с тяжеленным приложением Opensolaris может оказаться достаточно интересным и полезным.

PS: резонно подметили – “настоящие джедаи не используют ZFS” – это точно подмечено, они используют чОрную коробочку под название Veritas Volume Manager, они консервативны и предпочитают оплачивать свои проблемы заранее, а не по мере их возникновения. Проблемы имеют обыкновения проявляться, как показала практика, даже в самых стабильных и простых конфигурациях. Да, конфигурабельно, да, отлажено, да – много лет на рынке. Но и проблемы – тоже, кхм, оттачивались много-много лет И не все так гладко – в том числе и из-за немаленькой стоимости этого решения.

PPS: все-таки хотелось увидеть эту “фишку” в обычном, привычном для заказчиков и поддерживаемом, Solaris 10 – хотя пора думать о выходе Solaris 11 – в котором будет ВСЕ

Related posts:

1. Sun StorageTek 2510 Array iSCSI Тихо и незаметно (для меня) вышел iSCSI массив от Sun...
2. Полезно чтиво. Слайды с Oracle Solaris Summit at LISA. Собственно, слайды довольно интересны. А вот сюда ходить за презентациями....
3. Solaris 10 10/08 Выходит в октября , появится расширенная поддержка : xVM (драйвера...

Related posts brought to you by Yet Another Related Posts Plugin.

Небольшая вводная – здесь.

ЗЫ: а я сегодня так насмотрелся на Волшебную зиму в ноябре, что, пожалуй, пойду поспать +1 на градуснике и метель – очень вдохновляют

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Начиная с 15-й версии дискового формата ZFS появилась возможность устанавливать дисковые квоты для пользователей и для груп. А-ля windows/linux quota style. Что радует, потому как это закрывает еще один существенный вопрос.

Доступно с билда 114 Solaris (Nevada) 11. OpenSolaris 2009.06 по умолчанию этой возможности не имеет (версия дискового формата 14), Fishworks/Amber Road – тоже (ждем обновления, в интерфейсе должна появится одна замечательная возможность ).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

• http://ua.sun.com/win/news/events/2009/april/SS7000.pdf

Или только я ее не видел?

И еще – наткнулся на забавный девайс, а точнее – целый ряд устройств – Fusion-io ioXtreme, например – устройство для домашнего ZFS-сервера в форм-факторе PCIE. Список поддерживаемых ОС выглядит как-то кисло без (Open)Solaris. И подождем какое-то время – и потом еще напишем.

PS: вот кое-какое обсуждение на форумах opensolaris.org: https://opensolaris.org/jive/thread.jspa?messageID=297283. Дабы впустую не гонять – предварительно – этот вид устройств не поддерживается (Open)Solaris…

Related posts:

1. SAS Multipathing Хм , спросите Вы , и зачем это надо ?!...
2. OSol 2009.6 and pkg install problem After installation of OSol 2009.6 (build 111) i’v got some...
3. В догонку – про ленты В OpenSolaris build 93 представлена одна забавная (?) вещь ,...

Related posts brought to you by Yet Another Related Posts Plugin.

PS: детально просмотрел статейку, источники другие посмотрел – все-таки полного отказа от ZFS не предвидится? Цель выпуска Snow Leopard – максимальные облегчения, оптимизация и минимизация вкупе с новым фишками. ZFS – это все-таки файловая система для больших (ок, и не только) объемов данных – а целевая аудитория Apple не заинтерисованна в таких (ZFS) нововведениях? Посмотрим, как оно будет.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Что есть :

• три продукта – 7110 , 7210 , 7410
• входная цена – от ~$10 000
• внутри OpenSolaris = ZFS + OpenStorage Initiative
• базируется на AMD Opteron
• доступ iSCSI (блочный) / NFS/WebDAV/FTP
• поддержка авторизации NIS , LDAP , AD
• поддержка аггрегации линков , VLAN , 10GiB ethernet
• СКВОЗНОЕ управление через web-интерфейс
• кластеризация Active-Active / Active-Standby , поддержка удаленной репликации !
• поддержка SSD-накопителей !!! Это не просто ТУПО набор дисков SSD , это умные диски (хинт - Logzilla/Readzilla)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.