Комментарии 88
А разве нельзя уменьшить размер раздела? Linux это умеет всяким там gparted, ну и всякие Partition Magic тоже.
Как это сделать на лету?
Отчасти верно, но тут есть вот какое серьезное «но».
Во-первых, хранилище (сам SAN-массив) не знает, что у него там на разделе лежит, что за файловая система, и есть ли она там вообще. Ему приложение не сообщает. А не зная этого, изменить размеры раздела, что связано в том числе и с изменением структур файловой системы — невозможно. Можно это делать только изнутри _каждого_ раздела, и каждого приложения/OS. Кроме того, это вызывает приостановку работы с данным разделом, «наживую», на смонтированном разделе, gparted не работает.
Во-вторых, это не решает проблему, если у нас много разделов, и мы изменяем, например, размеры третьего, седьмого, и двенадцатого, чтобы за счет их уменьшения увеличить двадцатый. У нас все равно получатся либо «куски» в разных местах стораджа, которые надо как-то собрать вместе и «пристыковать» к нужному, либо же надо всю «кухню» разделов двигать, не только три уменьшенных, а все 19. И все их остановить, размонтировать, и передвигать.
Плюс же thin provisioning заключается в том, что это происходит автоматически, «на ходу».
Во-первых, хранилище (сам SAN-массив) не знает, что у него там на разделе лежит, что за файловая система, и есть ли она там вообще. Ему приложение не сообщает. А не зная этого, изменить размеры раздела, что связано в том числе и с изменением структур файловой системы — невозможно. Можно это делать только изнутри _каждого_ раздела, и каждого приложения/OS. Кроме того, это вызывает приостановку работы с данным разделом, «наживую», на смонтированном разделе, gparted не работает.
Во-вторых, это не решает проблему, если у нас много разделов, и мы изменяем, например, размеры третьего, седьмого, и двенадцатого, чтобы за счет их уменьшения увеличить двадцатый. У нас все равно получатся либо «куски» в разных местах стораджа, которые надо как-то собрать вместе и «пристыковать» к нужному, либо же надо всю «кухню» разделов двигать, не только три уменьшенных, а все 19. И все их остановить, размонтировать, и передвигать.
Плюс же thin provisioning заключается в том, что это происходит автоматически, «на ходу».
LVM, не?
или собственно за хитрой фразой «thin provisioning» он и стоит?
или собственно за хитрой фразой «thin provisioning» он и стоит?
Да, хранилище не знает, что у него твориться «на верху» на уровне файловой системы, но размер раздела можно уменьшить. NetApp SnapManager поддерживают функцию space reclamation. romx даже писал об этом blog.aboutnetapp.ru/archives/664
Боюсь, все это радужно лишь на словах. На высоконагруженых системах это «тонкое резервирование» приведет к очень сильной фрагментации между приложениями, вследствие чего производительность будет падать в разы.
Я не зря остановился на этом в тексте. :)
Падения «в разы» не наблюдается, в большинстве случаев не наблюдается даже сколь-нибудь измеяемое изменение.
Ну и, потом, никто же не заставляет обязательно использовать thin provisioning, вполне можно на одном сторадже иметь и thin и traditional разделы, они друг другу не мешают.
Падения «в разы» не наблюдается, в большинстве случаев не наблюдается даже сколь-нибудь измеяемое изменение.
Ну и, потом, никто же не заставляет обязательно использовать thin provisioning, вполне можно на одном сторадже иметь и thin и traditional разделы, они друг другу не мешают.
И все таки. Каковы накладные расходы в производительности в угоду оптимизации использования пространства?
Хотелось бы прям цифры, т.к. всеравно это надо переводить в деньги, при выборе платформы.
И… это отдельный функционал? Лицензии надо открывать? Дорого?
Хотелось бы прям цифры, т.к. всеравно это надо переводить в деньги, при выборе платформы.
И… это отдельный функционал? Лицензии надо открывать? Дорого?
Я, пока писал, к сожалению, не нашел под руками конкретно по NetApp цифр, зато есть аналогичный функционал у виртуальных дисков VMware, и выше в тексте я дал ссылку на этот документ.
Что же касается NetApp, то, например, тестирование производительности по SPC-1 NetApp проводит с включенным thin provisioning (lun reservation = off), и ничуть не боится снижения производительности.
Повторюсь, это не обязательная опция, вы вполне вольны ее использовать, или нет, по своему усмотрению. Например, на части разделов и LUN-ов, где ожидаете заметный эффект — использовать, на других, где не хотите, или не видите эффекта — не используйте. Оно независимо, и друг другу не мешает.
Нет, это «встроенный» функционал OS Data ONTAP и WAFL, на уровня опций при создании тома и LUN, денег не стоит.
Вот тут есть хороший переведенный best practices по thin provisioning:
www.netwell.ru/production/techbiblioteka.php
www.netwell.ru/docs/thin_provisioning.pdf
Что же касается NetApp, то, например, тестирование производительности по SPC-1 NetApp проводит с включенным thin provisioning (lun reservation = off), и ничуть не боится снижения производительности.
Повторюсь, это не обязательная опция, вы вполне вольны ее использовать, или нет, по своему усмотрению. Например, на части разделов и LUN-ов, где ожидаете заметный эффект — использовать, на других, где не хотите, или не видите эффекта — не используйте. Оно независимо, и друг другу не мешает.
Нет, это «встроенный» функционал OS Data ONTAP и WAFL, на уровня опций при создании тома и LUN, денег не стоит.
Вот тут есть хороший переведенный best practices по thin provisioning:
www.netwell.ru/production/techbiblioteka.php
www.netwell.ru/docs/thin_provisioning.pdf
Точно сказать сложно, но я думаю лицензия обойдеться по стоимости, как лишние 10-15 TB массива. Так что я думаю, если взять прозвучавшие здесь цифры 60-80% — я бы стал задумывать над лицензией, если есть фрагментация на массиве в 60+80/2*10TB = 70 Tb. Но это только задумываться). И естественно, это ИМХО.
А теперь вопрос: какой оверхед это даёт по скорости? Если быть точным, допустим, у нас есть iscsi target размером 1.5Тб. Как показывает эксперимент, при форматировании туда пишется около 30Гб данных, то есть примерно на 60Гб блоков. Thin Providing, всё хорошо. Образ занимает 60Гб вместо полутора терабайт, человек заходит, начинает писать… На уже выделенных блоках у него скорость записи, допустим, 300Мб/с. А теперь он доползает до «заявленных, но не выделенных» блоков.
Какая скорость будет при этом?
Какая скорость будет при этом?
Думаю, в этом месте будет небольшая заминка на выделение очередного блока, затем все вернется в исходное. Это может оказаться неприятным сюрпризом, если пишутся данные, получаемые в реалтайме с соизмеримой скоростью. Одна надежда — система начинает выделять следующий блок при заполнении предыдущего, скажем, на 90-95%
Вопрос — как это происходит в реале?
Вопрос — как это происходит в реале?
Я с такой проблемой столкнулся с thin providing с использованием VHD на NFS. Не смотря на то, что после выделения места скорость была нормальной, сам процесс был крайне неприятным и дискомфортным.
Я не стану утверждать, что thin provisioning у NetApp идеален, и на него не действуют физические законы :)
Нет, конечно, процесс space allocation обязательно вызывает задержки в операциях миллисекундного порядка (впрочем, честно попытался после вашего вопроса найти жалобы на этот счет в community, чтобы оценить порядок — не нашел).
Но, как я уже писал выше, выделение дополнительных сегментов производится все же не «побайтово», а довольно крупными «кусками» что снижает негативный эффект, в том числе фрагментации.
Опять же отмечу, если вы оцениваете, что какие-то разделы, вследствие своего характера заполнения, могут иметь проблемы с thin, просто используйте для них traditional reservation, и все. Как traditional разделы, так и thin, могут сосуществовать на одной системе неограниченно, по выбору админа.
Нет, конечно, процесс space allocation обязательно вызывает задержки в операциях миллисекундного порядка (впрочем, честно попытался после вашего вопроса найти жалобы на этот счет в community, чтобы оценить порядок — не нашел).
Но, как я уже писал выше, выделение дополнительных сегментов производится все же не «побайтово», а довольно крупными «кусками» что снижает негативный эффект, в том числе фрагментации.
Опять же отмечу, если вы оцениваете, что какие-то разделы, вследствие своего характера заполнения, могут иметь проблемы с thin, просто используйте для них traditional reservation, и все. Как traditional разделы, так и thin, могут сосуществовать на одной системе неограниченно, по выбору админа.
За информацию спасибо.
Thick не годится, у нас он есть и мне он несколько не нравится.
Итак, вопросы более конкретные:
1) при линейной записи на thin насколько снижается скорость записи на thick?
2) Есть ли апи для выяснения реального объёма занятого места конкретным lun'ом?
3) Цена вопроса для хранилища на 100-200Тб?
4) Сколько юнитов?
Thick не годится, у нас он есть и мне он несколько не нравится.
Итак, вопросы более конкретные:
1) при линейной записи на thin насколько снижается скорость записи на thick?
2) Есть ли апи для выяснения реального объёма занятого места конкретным lun'ом?
3) Цена вопроса для хранилища на 100-200Тб?
4) Сколько юнитов?
Как вы понимаете, точно на этот вопрос ответить невозможно. Наши англоязычные товарищи тут говорят «mileage may vary». Слишком много переменных должно быть учтено для точного ответа «в граммах» (а «приблизительно» вас не устроит).
Я бы на вашем месте, если вас заинтересовало, попросил бы примерно соответствующую вашим требованиям систему на тестирование. У любого приличного партнера NetApp, из числа интеграторов, есть (должен быть, по условиям партнерства) демо-пул железа как раз для таких целей, и NetApp всегда поощряет тестирование и демонстрацию непосредственно на задаче и площадке потенциального клиента.
Рекомендую только не пренебрегать консультациями специалистов в настройке, так как, уже говорил, системы внутренне необычные, и требуют некоторого углубленного понимания ряда по певости не вполне очевидных процессов конфигурирования, отличающегося от «традиционных систем».
Системные инженеры NetApp в представительстве не враги, они тоже заинтересованы, чтобы «товар показался лицом».
Я бы на вашем месте, если вас заинтересовало, попросил бы примерно соответствующую вашим требованиям систему на тестирование. У любого приличного партнера NetApp, из числа интеграторов, есть (должен быть, по условиям партнерства) демо-пул железа как раз для таких целей, и NetApp всегда поощряет тестирование и демонстрацию непосредственно на задаче и площадке потенциального клиента.
Рекомендую только не пренебрегать консультациями специалистов в настройке, так как, уже говорил, системы внутренне необычные, и требуют некоторого углубленного понимания ряда по певости не вполне очевидных процессов конфигурирования, отличающегося от «традиционных систем».
Системные инженеры NetApp в представительстве не враги, они тоже заинтересованы, чтобы «товар показался лицом».
Да, второй вопрос. Что дешевле — иметь Thick Provision на большом SATA-рейде (допустим, 2Тб винтами) или покупать лицензии NetApp? Вопрос не праздный, если меня убедите, я подниму вопрос об использовании вас вместо локального iscsi target'а.
> если меня убедите, я подниму вопрос
Это шантаж ;)
> Что дешевле
А чорт его знает, если честно, слишком расплывчата задача.
Как написал уже выше, возьмите и проверьте самостоятельно, конкретно, руками. Это будет самый лучший ответ, самим себе.
Кому-то подходит, кому-то нет, нельзя удовлетворить абсолютно всех.
Наверняка есть задачи, где самодельный RAID выигрывает просто по фактору цены. Есть другие задачи, где вес других параметров, кроме цены, в суммарной оценке выше.
Но сложно, и попахивает профанацией и дилетантизмом, если бы я стал втюхивать вам сейчас что-то, не будучи уверенным в том, что это для вас подходит.
Это шантаж ;)
> Что дешевле
А чорт его знает, если честно, слишком расплывчата задача.
Как написал уже выше, возьмите и проверьте самостоятельно, конкретно, руками. Это будет самый лучший ответ, самим себе.
Кому-то подходит, кому-то нет, нельзя удовлетворить абсолютно всех.
Наверняка есть задачи, где самодельный RAID выигрывает просто по фактору цены. Есть другие задачи, где вес других параметров, кроме цены, в суммарной оценке выше.
Но сложно, и попахивает профанацией и дилетантизмом, если бы я стал втюхивать вам сейчас что-то, не будучи уверенным в том, что это для вас подходит.
Каким образом я должен «взять и проверить»? Или вы предлагаете «купи и проверь»? М… Мне это не нравится.
Нет, у любого нормального партнера можно взять в тестирование имеющуюся у него систему из демо-пула в тестирование (например на 2 недели) под так называемое «гарантийное письмо».
Естественно, это не накладывает никаких обязательств по покупке, если «не подойдет», именно для этого и придумано тестирование.
Странно, неужели это такая редкость, и вы ни разу не сталкивались с таким, мне казалось, что все Tier-1 вендоры такое практикуют.
Естественно, это не накладывает никаких обязательств по покупке, если «не подойдет», именно для этого и придумано тестирование.
Странно, неужели это такая редкость, и вы ни разу не сталкивались с таким, мне казалось, что все Tier-1 вендоры такое практикуют.
Да, интеграторы дают покататься железо — это точно, сам пользовался :)
Другое дело, что без должной подготовки и с отсутствием знаний по СХД толку от тестов будет мало так что нужно и этот вопрос продумать перед тем как брать что-то на тесты.
Другое дело, что без должной подготовки и с отсутствием знаний по СХД толку от тестов будет мало так что нужно и этот вопрос продумать перед тем как брать что-то на тесты.
Собственно, мы особо в сторону готовых вендоров не смотрели. С учётом, что всё равно никто из них готового решения под нужды виртуализации предложить не может, то брать «якобы готовое» чтобы потом ровно так же пилить, совершенно не хочется.
Однако, вы говорите что-то, что может заинтересовать, так как решает одну из проблем.
Однако, вы говорите что-то, что может заинтересовать, так как решает одну из проблем.
Какова стоимость такого решения и соответственно — область применения? Имеется в виду стоимость подключения одного компьютера к такой SAN.
Fiber channel и iSCSI — решения не копеечные. Возможно для пула производительных серверов-молотилок это хорошее решение, но как офисное хранилище на замену 500-гиговым дискам — на мой взгляд дороговато. Да и не нужны офисным работникам такие диски, 150-200 Гиг и то много. А те задачи, где нужны — решаются обычно на серверах, где и применяются соответствующие решения.
Fiber channel и iSCSI — решения не копеечные. Возможно для пула производительных серверов-молотилок это хорошее решение, но как офисное хранилище на замену 500-гиговым дискам — на мой взгляд дороговато. Да и не нужны офисным работникам такие диски, 150-200 Гиг и то много. А те задачи, где нужны — решаются обычно на серверах, где и применяются соответствующие решения.
iscsi — решение бесплатное, вообще говоря :)
Вот я темнота! :(
Да. Это решение будет зависеть от скорости работы сети. Получается для офиса оно вполне приемлемо, но с ростом персонала вырастут и нагрузки на сеть. Получается, там, где подобное решение предпочтительней — крупные офисы больших компаний — оно менее работоспособно.
Или я опять где-то ошибаюсь?
Да. Это решение будет зависеть от скорости работы сети. Получается для офиса оно вполне приемлемо, но с ростом персонала вырастут и нагрузки на сеть. Получается, там, где подобное решение предпочтительней — крупные офисы больших компаний — оно менее работоспособно.
Или я опять где-то ошибаюсь?
При 10G порте до сервера проблемы раньше начнутся на сервере, чем в сетевом сегменте.
10G до сервера, гигабит до пользователей — вполне комфортно и дёшево.
10G до сервера, гигабит до пользователей — вполне комфортно и дёшево.
Обычно iSCSI организуют в отдельную сеть. Либо отдельную физически, либо, хотя бы, в VLAN.
Но «скорость работы» это такой гипотетический параметр. Если вашим серверам достаточно iSCSI по гигабиту, и они не прокачивают даже в пике полосу пропускания больше 1Gb/s, (видел таких задач немало, на самом деле) то любое расширение этой полосы в ее неиспользуемой части, не повышает производительность.
Если по шоссе проезжает один грузовик в минуту, и не возникают заторы, то расширение полосности шоссе в 4 раза не увеличит скорости грузовика, и скорости доставки груза.
Но «скорость работы» это такой гипотетический параметр. Если вашим серверам достаточно iSCSI по гигабиту, и они не прокачивают даже в пике полосу пропускания больше 1Gb/s, (видел таких задач немало, на самом деле) то любое расширение этой полосы в ее неиспользуемой части, не повышает производительность.
Если по шоссе проезжает один грузовик в минуту, и не возникают заторы, то расширение полосности шоссе в 4 раза не увеличит скорости грузовика, и скорости доставки груза.
Для КОГО это оно бесплатно? (:
С какой стороны выглядывает его бесплатность?
С какой стороны выглядывает его бесплатность?
Для пользователя. aptitude install iscsi-target. Аналогично initiator.
Ну разве у нас бывает что-то бесплатное?
Бывает бесплатно, бывает за деньги.
Но дешевого и бесплатного в области iSCSI действительно довольно много.
Бывает бесплатно, бывает за деньги.
Но дешевого и бесплатного в области iSCSI действительно довольно много.
ох уж эти софтварные решения…
Вот только не надо снобизма ;)
Ну… это не снобизм. Любой hba чего-то да стоит. Я конечно не стал бы использовать железное решение если бы мне нужно было организвать таргет для локалки дома. Но на работе использовать софтовые решения не всегда возможно(из-за производительности и ограничений самой ОС).
Ну так никто не говорит про «всегда», конечно, надо оценивать стоимость и эффективность решения. Нет смысла возить помидорную расаду на дачу на Ламборгини, также как нет надежды очаровать подружку новой Ладой-классикой ;)
Ага, ага. То-то у меня рядом «софтварное решение» через 10G во всю молотит.
iscsi-target?
А вы не думали, что будете делать, когда возникнет проблема с железом, на котором крутится «софтварное решение»?
Думали. Железо в хлам, дискам писец, из БП дым.
Для этого DRBD и существует.
Кстати, а «железные» решения в этом смысле, по сравнению с софтовыми, имеют какие-то особые резисты и иммуны к 380 вместо 220 и с размаху кувалдой по корпусу?
Для этого DRBD и существует.
Кстати, а «железные» решения в этом смысле, по сравнению с софтовыми, имеют какие-то особые резисты и иммуны к 380 вместо 220 и с размаху кувалдой по корпусу?
А вот честно, подскажите мне, у нетапа и прочих решений нету материнской платы или контроллера? Они что, сгореть не могут?
Конечно все есть. Но если вы покупаете систему в «кластерной», двухконтроллерной конфигурации (это, так сказать, конфигурация покупки «по умолчанию» для NetApp), то выход из строя материнской платы или контроллера не приводят к потере доступа к данным, так как оставшийся контроллер на время берет на себя диски и ресурсы отказавшего. А замена по гарантии осуществляется «на следующий рабочий день» (или даже «через 4 часа» в случае Москвы и Петербурга) с доставкой по месту установки системы.
<s>fffffff</s>
НЛО прилетело и опубликовало эту надпись здесь
+1, при этом tp очень геморрная вещь, но наиболее приятная ее реализация именно в NetApp.
Может быть SAN и дороже, зато надежность выше + куча новых возможностей.
Хорошо быть богатым, и не задумываться о этой презренной суете. ;)
Однако, на практике, «эффективность хранения», то есть «экономость» в терминах пространства и использования ресурсов, это самая «горячая» тема последних пары лет в индустрии.
Я думаю, что если бы сэкономленный объем, выраженный в тысячах долларов (а FC и SAS-диски в таких системах исторически стоят ну ооочень много), выплачивался вам в качестве премии, то и вы бы стали большим фанатом процесса повышения эффективности ;)
Не думаю, что 60-80% емкости, о которых писалось выше, это «ловля блох».
Однако, на практике, «эффективность хранения», то есть «экономость» в терминах пространства и использования ресурсов, это самая «горячая» тема последних пары лет в индустрии.
Я думаю, что если бы сэкономленный объем, выраженный в тысячах долларов (а FC и SAS-диски в таких системах исторически стоят ну ооочень много), выплачивался вам в качестве премии, то и вы бы стали большим фанатом процесса повышения эффективности ;)
Не думаю, что 60-80% емкости, о которых писалось выше, это «ловля блох».
НЛО прилетело и опубликовало эту надпись здесь
Ну, то что вы не встречали, не значит что их нет, поверьте, в России, хотя и традиционно не умеют считать затраты (ROI, TCO), уже тоже начали задумываться, топить ли печь ассигнациями, или дешевле и выгоднее будет купить простых дров для того же самого.
Кризис хоть и идет на убыль, но многих научил считать расходы, а не только «освоенное бабло».
Кризис хоть и идет на убыль, но многих научил считать расходы, а не только «освоенное бабло».
с учётом drbd, надёжность дисков теперь является фактором, который влияет только на один параметр расходов — на стоимость времени тех, кто диски меняет.
Хм… я вообще то не говорил вообще ни о какой экономии) Как раз наоборот — сан хорошо использовать с дублированием ресурсов. В этой области — излишняя экономия — это большее зло, чем недостаточная.
Все зависит от обьемов. 1Тб — да смешно. 10Тб — это уже может быть дополнительная секция, замена свича и так далее.
Вопрос не в стоимости хранилища, а в стоимости электричества для юнитов и кондиционеров. Когда мы (в селектеле) обсуждаем платформу, её потребление и количество занимаемых юнитов на первом месте.
При чем здесь NetApp? Какое отношение имеет SAN к thin provisioning?
Пользуюсь thin provisioning без каких либо FC SAN'ов даже на локал дисках используя VMware ESXi.
Все верно, VMware умеет thin provisioning своими средствами, в своей реализации. Но с NetApp thinpro можно использовать автономно и прозрачно, для любого приложения, а не только для VMware ESX.
Thin Provisioning это не конкретная «торговая марка», это скорее концепция распределения пространства, она есть у VMware, а также у множества систем хранения: 3Par, HP, EMC, HDS (если кого забыл — не со зла), есть и у NetApp, и сделана там довольно неплохо.
Thin Provisioning это не конкретная «торговая марка», это скорее концепция распределения пространства, она есть у VMware, а также у множества систем хранения: 3Par, HP, EMC, HDS (если кого забыл — не со зла), есть и у NetApp, и сделана там довольно неплохо.
Я бы, как «пользователь» NetApp и других уже блочных стораджей могу сказать, что блочные стораджы теряют в производительности при использовании TP (сам замерял ~10%), а NetApp нет т.к. TP это просто опция у LUN и запись осуществляется точно так же как если бы TP не использовался поэтому и производительность не теряется.
хорошая идея — грузить операционку полностью с SAN-стораджа. Ни тебе проблемы бакапов, ни летящих хардов…
Сплошная теория и абстракция в духе «А вы знаете?..». Я требую конкретных примеров применения на практике. С цифрами.
Желательно конкретных цифр, на интервале в месяцы или год, для Windows виртуалок. В которых есть дефрагментатор.
Конкретные цифры без подробного описания деталей условий будут в духе "- Петька — приборы? — 70!"
Но если что-то будет достойное описания под руками — конечно напишу.
Но если что-то будет достойное описания под руками — конечно напишу.
Речь о виртуальных машинах, в которых администраторы запускают дефрагментацию. Как влияет она на рост занятого места? Наверно плохо влияет, а без дефрагментации в windows частенько плохо. Получается, что thin provision может быть даже вредным инструментом, если полагаясь на thin указываем больше размер чем вроде бы нужно — типа «с запасом, всё равно скорее всего не выделится».
Тут вот какая загогулина.
Для чего вообще делается дефрагментация? Для минимизации seek-ов, расход времени на которые замедляет процесс считывания/записи данных с дисков.
С минимизацией seek-ов все очевидно в случае, если логический диск лежит поверх простого физическом диска. Считываемые и записываемые последовательно данные испытывают большой выигрыш, если и располагаются они тоже последовательно.
Отметьте, что мы сейчас совсем не затрагиваем тему выгоды (или «невыгоды»)дефрагментации для файлов, считываемых не последовательно, а рандомно. Это еще на целую статью потянет.
Но все становится сложнее, когда раздел располагается поверх непростой RAID-структуры, где последовательно раполоденные блоки файловой системы совсем необязательно последовательно лежат на дисках. Еще неоднозначнее все становится в случае, когда поверх RAID, как в случае NetApp, лежит какая-то структура размещения блоков данных, которая сама по себе использует те или иные методы оптимизации расположения.
При этом дефрагментация ничего не знает о том, как и каким образом работает оптимизация на уровне стораджа, возможно данные, с точки зрения стораджа, размещены оптимально, с максимальным возможным быстродействием доступа, но «фрагментрованно» с точки зрения тупенького «дефрага». Напротив, «дефрагментация» может даже ухудшить структуру расположения, и оптимальность размещения.
Именно по этой причине NetApp, в общем случае, не рекомендует, без специальных консультаций с саппортом, использовать «дефрагментацию» для разделов виртуальных машин, так как это может ухудшить производительность.
И, да, вы правильно заметили, так как сторадж ничего не знает о том, что происходит на уровне FS приложения, это ведет и к ухудшению результатов thin provisioning.
Борьбе с этой ситуацией посвящен метод под названием space reclamation, при котором специальный клиентский софт на уровне OS сообщает стораджу, что «блоки данных номертакой-то и такой-то были стерты (или перенесены), и больше не используются для хранения актуальных данных, можно их освободить на уровне стораджа». Но это еще одна статья, спасибо за то, что подсказали тему. :)
Для чего вообще делается дефрагментация? Для минимизации seek-ов, расход времени на которые замедляет процесс считывания/записи данных с дисков.
С минимизацией seek-ов все очевидно в случае, если логический диск лежит поверх простого физическом диска. Считываемые и записываемые последовательно данные испытывают большой выигрыш, если и располагаются они тоже последовательно.
Отметьте, что мы сейчас совсем не затрагиваем тему выгоды (или «невыгоды»)дефрагментации для файлов, считываемых не последовательно, а рандомно. Это еще на целую статью потянет.
Но все становится сложнее, когда раздел располагается поверх непростой RAID-структуры, где последовательно раполоденные блоки файловой системы совсем необязательно последовательно лежат на дисках. Еще неоднозначнее все становится в случае, когда поверх RAID, как в случае NetApp, лежит какая-то структура размещения блоков данных, которая сама по себе использует те или иные методы оптимизации расположения.
При этом дефрагментация ничего не знает о том, как и каким образом работает оптимизация на уровне стораджа, возможно данные, с точки зрения стораджа, размещены оптимально, с максимальным возможным быстродействием доступа, но «фрагментрованно» с точки зрения тупенького «дефрага». Напротив, «дефрагментация» может даже ухудшить структуру расположения, и оптимальность размещения.
Именно по этой причине NetApp, в общем случае, не рекомендует, без специальных консультаций с саппортом, использовать «дефрагментацию» для разделов виртуальных машин, так как это может ухудшить производительность.
И, да, вы правильно заметили, так как сторадж ничего не знает о том, что происходит на уровне FS приложения, это ведет и к ухудшению результатов thin provisioning.
Борьбе с этой ситуацией посвящен метод под названием space reclamation, при котором специальный клиентский софт на уровне OS сообщает стораджу, что «блоки данных номертакой-то и такой-то были стерты (или перенесены), и больше не используются для хранения актуальных данных, можно их освободить на уровне стораджа». Но это еще одна статья, спасибо за то, что подсказали тему. :)
Статья про «space reclamation» — здорово актуально, я думаю. А насчёт неважности фрагментации — давно ходят слухи, что на сервере фрагментация не важна. Но практика-то показывает, что если можно файл считать последовательно — он считывается гораздо быстрее, ОС ведь тоже не дураки делают.
Все верно, но вопрос, насколько действительно часто встречается в реальной жизни sequental read/write на современных задачах, в многозадачных системах, да еще и в виртуальных машинах?
Я сходу могу назвать только одну такую задачу — создание резервной копии. Отчасти, быть может, еще работа с transaction logs SQL-баз данных, с которыми работают последовательно. Остальные же более или менее random. А случайное чтение случайно расположенных блоков с точки зрения seek ничем не отличается от случайного чтения последовательно расположенных блоков, «случайно» «в квадрат» не возводится :)
Что же касается фрагментации, то бесспорно излишняя фрагментация вредна. Но, с другой стороны, как мне кажется, опасность фрагментации часто очень сильно переоценивается. На дисках у всех давно уже не FAT16.
Вот тут довольно любопытные результаты о влиянии фрагментации «сегодня» приведены
blog.aboutnetapp.ru/archives/466
Я сходу могу назвать только одну такую задачу — создание резервной копии. Отчасти, быть может, еще работа с transaction logs SQL-баз данных, с которыми работают последовательно. Остальные же более или менее random. А случайное чтение случайно расположенных блоков с точки зрения seek ничем не отличается от случайного чтения последовательно расположенных блоков, «случайно» «в квадрат» не возводится :)
Что же касается фрагментации, то бесспорно излишняя фрагментация вредна. Но, с другой стороны, как мне кажется, опасность фрагментации часто очень сильно переоценивается. На дисках у всех давно уже не FAT16.
Вот тут довольно любопытные результаты о влиянии фрагментации «сегодня» приведены
blog.aboutnetapp.ru/archives/466
При текущем уровне взаимодействия ОС на хосте с системой хранения все это еще уж больно убого для 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 в соответствии с задачами.
Однако возможность весьма полезна как ни крути, бывает что нужно получить назад место когда-то съеденное и теперь свободное с т.з. ОС. В Windows 2008 c введением возможности уменьшения партиции NTFS LUN можно и уменьшать через SnapDrive без прерывания работы с данными. Для UNIX не совсем в курсе, но последний виденный SnapDrive не умел делать reclaim и уменьшение партиций вообще.
Думаю если крупные заказчики попросили бы то и для VMWare VMFS датасторов на LUN можно и reclaim и уменьшение организовать (увеличение уже работает без проблем под нагрузкой).
Для NAS все весьма замечательно, отключаем резервирование места хоть под все тома на агрегате и получаем общий пул свободного места хоть под NFS для VMWare/XEN, хоть CIFS шары, хоть одновременно.
С введение TP усложняется управление занятым\свободным местом и возрастает риск переполнения тома\агрегаты, особенно опасное для томов с LUN (которые как известно если нет места уходят в оффлайн на системах NetApp). Решается хорошими средствами мониторинга (у нас например их родной DFM/OM) и осмысленным выбором параметров томов\LUN в соответствии с задачами.
> При текущем уровне взаимодействия ОС на хосте с системой хранения все это еще уж больно убого для SAN.
Тем не менее, это лучше, чем ничего. Большинство SAN-систем других производителей вообще этим «не заморачиваются».
> Space Reclamation есть только для Windows/NTFS
Не только. Для VxFS, по меньшей мере, еще. (см. новости про поддержку Symantec Thin Reclamation API) А системы, использующие VxFS/VxVM это довольно значительный кусок «энтерпрайза».
> С введение TP усложняется управление занятым\свободным местом и возрастает риск переполнения тома\агрегаты
Естественно, ничто в нашем мире не дается даром :).
Но я уже, кажется, говорил это, лучше иметь возможность, даже сейчас не используя ее, если она не нужна, чем не иметь такую возможность вообще, в принципе.
Тем более, что вы и сами согласны, что все это решается. :)
Тем не менее, это лучше, чем ничего. Большинство SAN-систем других производителей вообще этим «не заморачиваются».
> Space Reclamation есть только для Windows/NTFS
Не только. Для VxFS, по меньшей мере, еще. (см. новости про поддержку Symantec Thin Reclamation API) А системы, использующие VxFS/VxVM это довольно значительный кусок «энтерпрайза».
> С введение TP усложняется управление занятым\свободным местом и возрастает риск переполнения тома\агрегаты
Естественно, ничто в нашем мире не дается даром :).
Но я уже, кажется, говорил это, лучше иметь возможность, даже сейчас не используя ее, если она не нужна, чем не иметь такую возможность вообще, в принципе.
Тем более, что вы и сами согласны, что все это решается. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Thin Provisioning — «кредитная карта» для хранилища