При использовании NFS и снапшотов на уровне системы хранения падения производительности не будет если механизм снапшотов на данных системах хорош. Точно знаю про системы NetApp, у них даже плагинчик готовый есть для клонирования такого.
Интересно будет посмотреть насколько они смогут сохранить плюсы SAS при таком «изврате».
Мне нравится элегантнейшее решение, но будущее его туманно.
Как только RPO/RTO может быть обеспечен синхронным\асинхронным SnapMirror то гораздо дешевле сделать полуручные процедуры DR (vFiler DR тот же очень элегантен).
Вы чертовски логичны, за недостатком знаний даже не знаю что возразить. Но факт есть факт — оно работает и мне как админу без разницы что лежит там на низком уровне. Меня устраивает что задержки в приемлемых пределах и задача решается.
Кстати, тот же EMC со своим SRDF/S и наверняка куча других вендоров делают то же самое.
SRM теоретически не нужен если у нас метрокластер (т.е. данные УЖЕ доступны в DR датацентре и готовы к использованию без всяких миграционных процессов).
А вот если у нас скажем простой snapmirror тогда да — SRM сильно упростит выполнения сценария DR.
Можно посмотреть в TR3742 на NOW (переведенный документ есть на Netwell.ru, пункт 5.9).
Снапшоты не создают дополнительные ссылки на физические блоки, они залочивают ссылки на физические блоки в таблицах inode. А вот этих ссылок может быть много на один и тот же блок.
Фраза «до 255» на том очень правильна, число не гарантировано, там делается ссылка на каждый блок в отдельности, а значит для каждого блока будет индивидуальное число максимально возможных ссылок 255 минус «количество уже существующих ссылок». Например если том хорошо дедуплицирован то число может значительно снизиться.
Мой пример конечно к этим тестам не относится — они NASовые для клиентского доступа по NFS и CIFS (не SAN и не vmdk на NFS например).
Что значит «иная»? Проблемы с raid penalty для RAID-6 решены, прироста IOPS это само по себе не дает.
Как говорит Recovery Monkey «There is no magic»: диски есть диски и больше чем теоретически возможно IOPS они не обслужат.
Попробую другой пример привести: если у нас было 33,6k IOPS при 100% writes (random, так конечно не бывает, просто для примера), перенесли все это с 224 FC на 93 SATA, стало 11,2k IOPS. Это не та же производительность на запись и FlashCache тут не поможет никак.
На запись то скорость теперь 93х«SATA disk IOPS» (скажем 93х80=7440, 80 IOPS это оптимистично, может и до 30 IOPS быть), а не 224x«FC IOPS» (скажем 224х150=33600).
Если у нас была OLTP база 66%/33% read/write и 11,2k (33,6k / 3) IOPS и были этими 33% writes то мы в пролете: 11200>>2480 (7440/3, если кэш не разогрет или ну вот плохое случилось идут запросы на отсутствующие в кэше данные и мы читаем все с дисков), 11200>7440 (идеальный случай когда все данные в кэше и 7440 IOPS мы 100% задействуем на write IOPS).
Поправьте если все запутал :).
Ну почему же в корне, по словам EMC первая половина верна «универсальное хранилище данных» :)
Вторая да, неверна. Во FLARE с 28 есть pools которые конечно кусочками выделяют место но файловой системой никак (или «пока» :) ) не назовешь.
А рассказывать то там нечего, DART и FLARE так же работают на отдельном железе (в VNXe некоторый изврат с гипервизороподобным решением, но по сути работает тот же основной код DART и FLARE).
EMC пришли не к техническому решению (может просто не могут пока аналогичное сделать) а к тому что тактика продвигания low- mid- решений как «универсальных систем хранения с кучей всяких плюшек» успешна и NetApp много лет отжимает доли рынка.
При текущем уровне взаимодействия ОС на хосте с системой хранения все это еще уж больно убого для SAN. Space Reclamation есть только для Windows/NTFS и проходит относительно медленно (плюс нетапп рекомендует не проводить IO intensive операций на LUN в это время).
Однако возможность весьма полезна как ни крути, бывает что нужно получить назад место когда-то съеденное и теперь свободное с т.з. ОС. В Windows 2008 c введением возможности уменьшения партиции NTFS LUN можно и уменьшать через SnapDrive без прерывания работы с данными. Для UNIX не совсем в курсе, но последний виденный SnapDrive не умел делать reclaim и уменьшение партиций вообще.
Думаю если крупные заказчики попросили бы то и для VMWare VMFS датасторов на LUN можно и reclaim и уменьшение организовать (увеличение уже работает без проблем под нагрузкой).
Для NAS все весьма замечательно, отключаем резервирование места хоть под все тома на агрегате и получаем общий пул свободного места хоть под NFS для VMWare/XEN, хоть CIFS шары, хоть одновременно.
С введение TP усложняется управление занятым\свободным местом и возрастает риск переполнения тома\агрегаты, особенно опасное для томов с LUN (которые как известно если нет места уходят в оффлайн на системах NetApp). Решается хорошими средствами мониторинга (у нас например их родной DFM/OM) и осмысленным выбором параметров томов\LUN в соответствии с задачами.
Ок, я вполне верю что это так. Мы говорили про разные extent получается. Я не в курсе был что точно так же называют некий цельный кусок данных расположенный в одном месте.
Не из пальца. Курс PAD (Performance analysis on Data ONTAP) довольно подробно разбирает падение производительности из-за большего количества CPread (Consistency Point read) при записи.
Экстенты существуют по сути только для Exchange (уточнял по документации на 7.3.1, может для более поздних что-то изменилось).
На random чтение влиять не будет, на последовательное для NAS — мало или совсем нет (спасибо NetApp за грамотные алгоритмы кеширования) разве что система и так перегружена, для SAN — вопрос неоднозначный, что там творится на LUN в 3rd party файловой системе хрен его знает, алгоритмы вполне могут не работать (особенно если это какой-нибудь LUN c VMFS нагруженный пачкой VM, а клиент(scsi initiator) по сути один — ESX) или работать частично. Тут NetApp непричем, у всех вендоров будут те же проблемы.
А если считывание LUN идет на уровне Data ONTAP snapmirror например то это уже не SAN вообще.
Про запись уже другой вопрос. На WAFL и RAID-DP фрагментация немного иного характера чем на обычном райде или вообще одном диске. Когда страйп уже записан, а потом часть данных в нем стерта и помечена как свободные блоки то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать, что в случае WAFL может происходить довольно часто даже для random данных, особенно на заполненной агрегате, особенно на «старой», т.е. тут которую уже давно и интенсивно используют random записями.
WETA ж все-таки по большей части считывали данные (аж FlexCache применили), да и NAS(NFS) у них был.
Вопрос «а почему вы не поставляете, на что надеетесь?» весьма интересен :) Может породить еще и большую кучу малу.
Резюмируя, FUD на то и FUD чтобы нечестно дискредитировать вендора. Реальные проблемы могут быть на старых сильно заполненных (точнее с малым количеством длинных непрерывных свободных мест) агрегатах, где довольно много данных было перезаписано. Либо если неграмотно расширяли (добавляли малое кол-во дисков в райд группы/ создавали новые группы с малым кол-вом) и не делали reallocate после этого.
Да не забросает меня камнями track за комментарий.
Ваш вопрос весьма в точку, проблема падения производительности со временем есть(и от других факторов, например заполненность агрегаты и количество непрерывных свободных мест, также недаром сразу 10% съедается на т.н. WAFL резерв, одна из задач которого как раз обеспечить наличие места для поддержания скорости записи), однако до сих пор NetApp как-то обходит её пристальным вниманием (никакой официальной статистики, никаких best practice или специальных мануалов).
У конкурентов и злых языков эта одна из излюбленных тем для FUD — «а зачем NetApp поставляет вместе с системой хранения программу дефрагментации???».
На самом деле т.н. reallocate это часть операционной системы предназначенный как раз чтобы выправить ситуацию (если возникла) с неоптимальным расположением данных на WAFL.
Однако как уже сказал ниже track при правильно настроенной системе такая проблема решима («правильное использование» :) ). Может появится очень не скоро (зависит от многих факторов) или не появится вообще. Самый типовый случай — расширение агрегаты новыми дисками, т.е. в одной или нескольких райд группах появляются новые диски.
Может я и буду банален, но google «netapp price» дает нам ссылку на замечательный блог Робина Харриса со страницей прайсов на самые различные СХД.
На глазок прикинуть порядок цен вполне можно.
А по мне так тоже NetApp весьма прост в первоначальной установке. Хотя согласен — было бы огромным плюсом сделать отдельный quickstart guide с абстрактным объяснением основ и куда смотреть дальше.
На первых порах можно сильно наглупить разве что с созданием агрегат (набор дисков объединенные в несколько RAID групп на которрых создаются уже все вышележащие структуры данных).
Скажу что на личном опыте курсы не так уж и нужны для того чтобы начать администрировать.
Можно найти симулятор, порыскать по интернету, сгрузить мануалы и вполне так въехать что да как. Жаль что NetApp не дает доступа всем до документации на NOW, но при желании можно найти что хочется. Плюс есть IBM Red Books где про N-Series (суть OEM NetApp) очень много и весьма добротно.
5 дневный DOTF (Data ONTAP Fundamentals) весьма хорош, подробный но по сути безбожно ужат по времени + задавать действительно грамотные вопросы про тонкие моменты можно только позанимавшись непосредственной поддержкой.
Мне нравится элегантнейшее решение, но будущее его туманно.
Как только RPO/RTO может быть обеспечен синхронным\асинхронным SnapMirror то гораздо дешевле сделать полуручные процедуры DR (vFiler DR тот же очень элегантен).
Кстати, тот же EMC со своим SRDF/S и наверняка куча других вендоров делают то же самое.
А вот если у нас скажем простой snapmirror тогда да — SRM сильно упростит выполнения сценария DR.
Снапшоты не создают дополнительные ссылки на физические блоки, они залочивают ссылки на физические блоки в таблицах inode. А вот этих ссылок может быть много на один и тот же блок.
Мой пример конечно к этим тестам не относится — они NASовые для клиентского доступа по NFS и CIFS (не SAN и не vmdk на NFS например).
Что значит «иная»? Проблемы с raid penalty для RAID-6 решены, прироста IOPS это само по себе не дает.
Как говорит Recovery Monkey «There is no magic»: диски есть диски и больше чем теоретически возможно IOPS они не обслужат.
Попробую другой пример привести: если у нас было 33,6k IOPS при 100% writes (random, так конечно не бывает, просто для примера), перенесли все это с 224 FC на 93 SATA, стало 11,2k IOPS. Это не та же производительность на запись и FlashCache тут не поможет никак.
Если у нас была OLTP база 66%/33% read/write и 11,2k (33,6k / 3) IOPS и были этими 33% writes то мы в пролете: 11200>>2480 (7440/3, если кэш не разогрет или ну вот плохое случилось идут запросы на отсутствующие в кэше данные и мы читаем все с дисков), 11200>7440 (идеальный случай когда все данные в кэше и 7440 IOPS мы 100% задействуем на write IOPS).
Поправьте если все запутал :).
Вторая да, неверна. Во FLARE с 28 есть pools которые конечно кусочками выделяют место но файловой системой никак (или «пока» :) ) не назовешь.
А рассказывать то там нечего, DART и FLARE так же работают на отдельном железе (в VNXe некоторый изврат с гипервизороподобным решением, но по сути работает тот же основной код DART и FLARE).
EMC пришли не к техническому решению (может просто не могут пока аналогичное сделать) а к тому что тактика продвигания low- mid- решений как «универсальных систем хранения с кучей всяких плюшек» успешна и NetApp много лет отжимает доли рынка.
Однако возможность весьма полезна как ни крути, бывает что нужно получить назад место когда-то съеденное и теперь свободное с т.з. ОС. В Windows 2008 c введением возможности уменьшения партиции NTFS LUN можно и уменьшать через SnapDrive без прерывания работы с данными. Для UNIX не совсем в курсе, но последний виденный SnapDrive не умел делать reclaim и уменьшение партиций вообще.
Думаю если крупные заказчики попросили бы то и для VMWare VMFS датасторов на LUN можно и reclaim и уменьшение организовать (увеличение уже работает без проблем под нагрузкой).
Для NAS все весьма замечательно, отключаем резервирование места хоть под все тома на агрегате и получаем общий пул свободного места хоть под NFS для VMWare/XEN, хоть CIFS шары, хоть одновременно.
С введение TP усложняется управление занятым\свободным местом и возрастает риск переполнения тома\агрегаты, особенно опасное для томов с LUN (которые как известно если нет места уходят в оффлайн на системах NetApp). Решается хорошими средствами мониторинга (у нас например их родной DFM/OM) и осмысленным выбором параметров томов\LUN в соответствии с задачами.
Не из пальца. Курс PAD (Performance analysis on Data ONTAP) довольно подробно разбирает падение производительности из-за большего количества CPread (Consistency Point read) при записи.
На random чтение влиять не будет, на последовательное для NAS — мало или совсем нет (спасибо NetApp за грамотные алгоритмы кеширования) разве что система и так перегружена, для SAN — вопрос неоднозначный, что там творится на LUN в 3rd party файловой системе хрен его знает, алгоритмы вполне могут не работать (особенно если это какой-нибудь LUN c VMFS нагруженный пачкой VM, а клиент(scsi initiator) по сути один — ESX) или работать частично. Тут NetApp непричем, у всех вендоров будут те же проблемы.
А если считывание LUN идет на уровне Data ONTAP snapmirror например то это уже не SAN вообще.
Про запись уже другой вопрос. На WAFL и RAID-DP фрагментация немного иного характера чем на обычном райде или вообще одном диске. Когда страйп уже записан, а потом часть данных в нем стерта и помечена как свободные блоки то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать, что в случае WAFL может происходить довольно часто даже для random данных, особенно на заполненной агрегате, особенно на «старой», т.е. тут которую уже давно и интенсивно используют random записями.
WETA ж все-таки по большей части считывали данные (аж FlexCache применили), да и NAS(NFS) у них был.
Вопрос «а почему вы не поставляете, на что надеетесь?» весьма интересен :) Может породить еще и большую кучу малу.
Резюмируя, FUD на то и FUD чтобы нечестно дискредитировать вендора. Реальные проблемы могут быть на старых сильно заполненных (точнее с малым количеством длинных непрерывных свободных мест) агрегатах, где довольно много данных было перезаписано. Либо если неграмотно расширяли (добавляли малое кол-во дисков в райд группы/ создавали новые группы с малым кол-вом) и не делали reallocate после этого.
Ваш вопрос весьма в точку, проблема падения производительности со временем есть(и от других факторов, например заполненность агрегаты и количество непрерывных свободных мест, также недаром сразу 10% съедается на т.н. WAFL резерв, одна из задач которого как раз обеспечить наличие места для поддержания скорости записи), однако до сих пор NetApp как-то обходит её пристальным вниманием (никакой официальной статистики, никаких best practice или специальных мануалов).
У конкурентов и злых языков эта одна из излюбленных тем для FUD — «а зачем NetApp поставляет вместе с системой хранения программу дефрагментации???».
На самом деле т.н. reallocate это часть операционной системы предназначенный как раз чтобы выправить ситуацию (если возникла) с неоптимальным расположением данных на WAFL.
Однако как уже сказал ниже track при правильно настроенной системе такая проблема решима («правильное использование» :) ). Может появится очень не скоро (зависит от многих факторов) или не появится вообще. Самый типовый случай — расширение агрегаты новыми дисками, т.е. в одной или нескольких райд группах появляются новые диски.
На глазок прикинуть порядок цен вполне можно.
На первых порах можно сильно наглупить разве что с созданием агрегат (набор дисков объединенные в несколько RAID групп на которрых создаются уже все вышележащие структуры данных).
Можно найти симулятор, порыскать по интернету, сгрузить мануалы и вполне так въехать что да как. Жаль что NetApp не дает доступа всем до документации на NOW, но при желании можно найти что хочется. Плюс есть IBM Red Books где про N-Series (суть OEM NetApp) очень много и весьма добротно.
5 дневный DOTF (Data ONTAP Fundamentals) весьма хорош, подробный но по сути безбожно ужат по времени + задавать действительно грамотные вопросы про тонкие моменты можно только позанимавшись непосредственной поддержкой.