Комментарии 5
Вы видимо все же спец по SAN'ам, а не Oracle? Не скажу за СХДшную часть статьи, но по части баз есть много жесточайших ошибок, и надеюсь это ошибки перевода, а не Вы сами это придумали (кстати, не смог сходу найти места, откуда это все взялось – так бы просто сразу же написал вам правильные переводы).
Даже комментировать нечего — перечитайте свой оригинал и перевидите заново
Нет в Oracle «сonfig files» — есть Control File и есть Initialization Parameter File (которые в свою очередь бывают PFILE и SPFILE)
Единственное что мне приходит на ум — возможно вы про OCR/VD (Oracle Cluster Registry / Voting Disks) тут говорите.
(эти «Undo Logs» встречается в тексте в нескольких местах)
Тут опять — нет никаких Undo Logs в Oracle. И по смыслу тут пожалуй подошли бы Flashback Logs, но где-то по смыслу подходит и Undo Tablespace. Хотя опять же, где-то вы пишете «их можно не бекапить» — значит это все же не про Undo, бо бекап базы без Undo — не бекап…
Из своей практики — похожую функциональность доводилось использовать лет 5 назад на HP EVA 9000 — называлась кнопка вроде SnapClone — 2 ТБ база клонировалась за 3-5 сек, причем, думаю, половину времени из них тормозил web-интерфейс этой Эвы, да и размер наверно тоже особо там не играл роли. В общем, тогда это производило неизгладимое впечатление. Правда, выяснилось, что «snapclone от snapclon'а» уже не мгновенный — похоже на второй снимок у Эвы заканчивалась магия и она начинала по-настоящему копировать данные. Но вот первый снимок — да, мгновенно.
Если, к примеру DB состоит из двух файлов Archive Logs и каждый из них лежит ...
Даже комментировать нечего — перечитайте свой оригинал и перевидите заново
Копию Config Files от каждой DB желательно хранить ...
Нет в Oracle «сonfig files» — есть Control File и есть Initialization Parameter File (которые в свою очередь бывают PFILE и SPFILE)
Файлы для кластеризации от всех инстансов ...
Единственное что мне приходит на ум — возможно вы про OCR/VD (Oracle Cluster Registry / Voting Disks) тут говорите.
Undo Logs можно хранить ...
(эти «Undo Logs» встречается в тексте в нескольких местах)
Тут опять — нет никаких Undo Logs в Oracle. И по смыслу тут пожалуй подошли бы Flashback Logs, но где-то по смыслу подходит и Undo Tablespace. Хотя опять же, где-то вы пишете «их можно не бекапить» — значит это все же не про Undo, бо бекап базы без Undo — не бекап…
Из своей практики — похожую функциональность доводилось использовать лет 5 назад на HP EVA 9000 — называлась кнопка вроде SnapClone — 2 ТБ база клонировалась за 3-5 сек, причем, думаю, половину времени из них тормозил web-интерфейс этой Эвы, да и размер наверно тоже особо там не играл роли. В общем, тогда это производило неизгладимое впечатление. Правда, выяснилось, что «snapclone от snapclon'а» уже не мгновенный — похоже на второй снимок у Эвы заканчивалась магия и она начинала по-настоящему копировать данные. Но вот первый снимок — да, мгновенно.
Спасибо за ваш комментарий. Конструктивная критика — велкам. Я спец по СХД.
По поводу работы СХД и снимков могу вам достоварно заявить, что скорость не упадёт на любом доступном количестве клонов, тут у нетапа магических костылей никаких нет. Так устроен внутренний механизм файловой системы WAFL. Если хотите могу поверхностно объяснить.
Если хотите могу поверхностно объяснить.
Ну конечно хотим! Никто и не отвечает на такие вопросы, т.к. очевидно же, что Хабр для того и сделан, чтобы можно было прочесть про внутренности файловой системы WAFL (я даже такого названия не знал до этой статьи) от человека, который ее расковырял полностью и может популярно про все это рассказать!
Кстати, на Педивикии достаточно неплохая статья — понятно описан принцип работы, плюсы и минусы подхода.
Когда говорят про «запись повсюду» в WAFL имеют ввиду, что метаданные (иноды) файловой системы хранятся в буквальном смысле повсюду на дисках, а не в выделенном специальном месте, как это часто устроено в традиционных Файловых Системах (ФС).
В виду того, что запись всегда происходит в новое место, функция снапшотов (и соответственно клонов) очень легко реализуется в такой ФС. Когда новые данные перезаписываются при помощи «записи в новое место», старые данные по сути не затираются, при этом указатели инодов переставляются в «новое место» указывая на перезаписанные данные, таким образом происходит высвобождение нового места. Другими словами эта особенность работы WAFL (перезапись при помощи записи в новое место) является базой для работы нетаповских снапшотов по соответствующему принципу «Redirect On Write». В связи с чем на любом доступном количестве снапшотов (максимум 255 на том для DataOntap) или клонов, нет необходимости выделять специальный резерв пространства под снапшоты, а также нет падения производительности. Такая возможность WAFL должна быть очень востребована тестерами.
Т.е. выделение пространства под LUN о котором я говорю в статье не связанна с особенностью работы нетаповских снапшотов, а скорее с устаревшим принципом работы SAN, который не так давно, к счастью был доработан новыми, весьма не плохими костылями (SCSI SBC-3). Другими словами WAFL не знает о содержимом LUN'а и какие блоки там актуальные, а какие уже не нужны, а новые «костыли» позволяют ей это узнать, не захватывая мусор в снапшот и высвобождая пространство по мере удаления дынных на LUN'е. В то время как NAS имеет намного менее выраженные «проблемы поедания пространства» в сочетании со снапшотами, так как ФС WAFL взаимодействуя с хостом по SMB или NFS прекрасно знает о том, какие блоки данных более не нужны, этот функционал был заложен так сказать «By Design».
Как известно слова WAFL и Snapshot являются торговыми марками патентованными технологиями нетапа. В связи с чем слово снапшот не применяется в официальных названиях других продуктов и применяется в «не официальной терминологии». Но оно уже как-бы адаптировалось, и теперь оно как правило применяется в более «широком смысле».
Относительно снапшотов хочется отметить то, что «традиционные снапшоты» устроены по принципу COW (Copy On Write), где название отражает принцип работы: так как традиционные исполнения ФС «перезаписывают» изменённые данные на «прежнее» место, такому спаншоту необходимо выделять специальное место в ФС. Следующей особенностью работы COW является то, что для перезаписи новых данных (изменения данных) в захваченном снапшоте, такие данные для сохранности содержимого снапшота, должны быть сначала скопированные в выделенное для этого место, собственно от сюда и название Copy On Write. Таким образом самым главным недостатком такой технологии является падение производительности с ростом числа снапшотов, генерируя всё больше и больше накладных операций копирования при (пере)записи.
В виду того, что запись всегда происходит в новое место, функция снапшотов (и соответственно клонов) очень легко реализуется в такой ФС. Когда новые данные перезаписываются при помощи «записи в новое место», старые данные по сути не затираются, при этом указатели инодов переставляются в «новое место» указывая на перезаписанные данные, таким образом происходит высвобождение нового места. Другими словами эта особенность работы WAFL (перезапись при помощи записи в новое место) является базой для работы нетаповских снапшотов по соответствующему принципу «Redirect On Write». В связи с чем на любом доступном количестве снапшотов (максимум 255 на том для DataOntap) или клонов, нет необходимости выделять специальный резерв пространства под снапшоты, а также нет падения производительности. Такая возможность WAFL должна быть очень востребована тестерами.
Т.е. выделение пространства под LUN о котором я говорю в статье не связанна с особенностью работы нетаповских снапшотов, а скорее с устаревшим принципом работы SAN, который не так давно, к счастью был доработан новыми, весьма не плохими костылями (SCSI SBC-3). Другими словами WAFL не знает о содержимом LUN'а и какие блоки там актуальные, а какие уже не нужны, а новые «костыли» позволяют ей это узнать, не захватывая мусор в снапшот и высвобождая пространство по мере удаления дынных на LUN'е. В то время как NAS имеет намного менее выраженные «проблемы поедания пространства» в сочетании со снапшотами, так как ФС WAFL взаимодействуя с хостом по SMB или NFS прекрасно знает о том, какие блоки данных более не нужны, этот функционал был заложен так сказать «By Design».
Как известно слова WAFL и Snapshot являются торговыми марками патентованными технологиями нетапа. В связи с чем слово снапшот не применяется в официальных названиях других продуктов и применяется в «не официальной терминологии». Но оно уже как-бы адаптировалось, и теперь оно как правило применяется в более «широком смысле».
Относительно снапшотов хочется отметить то, что «традиционные снапшоты» устроены по принципу COW (Copy On Write), где название отражает принцип работы: так как традиционные исполнения ФС «перезаписывают» изменённые данные на «прежнее» место, такому спаншоту необходимо выделять специальное место в ФС. Следующей особенностью работы COW является то, что для перезаписи новых данных (изменения данных) в захваченном снапшоте, такие данные для сохранности содержимого снапшота, должны быть сначала скопированные в выделенное для этого место, собственно от сюда и название Copy On Write. Таким образом самым главным недостатком такой технологии является падение производительности с ростом числа снапшотов, генерируя всё больше и больше накладных операций копирования при (пере)записи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NetApp SnapManager for Oracle & SAN сеть