Когда имеет смысл не устанавливать квоту на объемах NetApp?
Когда я получил NetApp, который был настроен кем-то еще, кого я заметил, что все объемы действительно имеют квоты на них и из-за этого, кажется, что очень часто мы заканчиваем с проблемами, потому что кто-то забывает обновлять квоту, когда это действительно изменяет размер объема.
Чтобы быть более явными, эти объемы используются тем же пользователем, таким образом, я не вижу много логики на наличии квоты вообще.
Я действительно понимаю потребность в квоте, когда Вы хотите ограничить, сколько каждый пользователь смог бы сохранить, но когда у меня есть отдельный пользователь, который получает доступ к каждому объему, они, кажется, больше издержек мне.
Советуйте когда это хороший/плохой использовать квоты вместо размера тома.
Примечание: все они являются долями NFS, и тонкая резервация памяти не включена.
При отсутствии заданной квоты вы можете заполнить все хранилище за несколько минут.
Следствием этого будет то, что вам придется быстро сделать какой-нибудь чистый или купить другой шкаф для увеличения объема доступного хранилища.
С включенной квотой вы получите больше возможностей планирования емкости/более удобный вид на ваше хранилище и его использование.
Кстати, для одного пользователя, если вы не предоставите ему полную емкость хранилища, но шаг за шагом увеличиваете объем в соответствии с потребностями этого пользователя, я не вижу причин, по которым следует включать квоту, так как увеличение объема шаг за шагом приведет к такому же обзору планирования емкости и контроля над вашим хранилищем.
Другими словами :
Для одного пользователя увеличение громкости, когда оно необходимо, все равно что предоставление большего количества квот для данного пользователя, когда их несколько.
В этом конкретном случае я бы сказал, что включение квоты мне кажется бесполезным.
.Если все это для одного пользователя, то вместо квоты qtree можно использовать квоту пользователя. Но да, квоты часто не нужны.
Все, что вам всегда нужно делать, это делать qtrees в качестве первичных точек хранения. Таким образом, вы можете принять решение о квотировании - или нет. Но вы не можете, если это уже не qtrees.
В моем окружении мы, как правило, квотируем все, с ограниченным количеством примеров, потому что мы разрежем резервирование и дедуплируем.
Нашими ключевыми сценариями являются:
- Домашние драйвы - мы значительно перестаем подписываться, но даем каждому пользователю небольшую квоту. Поэтому вероятность того, что пользователи заполнят пространство достаточно быстро, чтобы выбить из строя целые системы, очень мала.
- положения, основанные на проектах/сервисах - мы представляем небольшие (1-3 или около того) qtree, каждый из которых помещается в отдельную квоту. Мы размещаем их в пределах объема, который мы затем разрежем, вычтем и применим резерв оснастки. Размер тома устанавливается, что может тонкое резервирование до суммы размера квоты + размер резерва оснастки.
- Интенсивно дедуцируемые тома, такие как образы дисков VMWare - эти тома мы не квотируем, потому что многие из их случаев использования - это коэффициент дедуплирования. Мы часто получаем 70%+ дедупе, что хорошо для пространства и кэширования.
Мы также обычно делаем снимки всего - в некоторых случаях мы делаем снимки, а в большинстве случаев мы автоудаляем на первичном.
Я бы предположил, что квотирование - это хорошо. Доступное пространство (сообщаемое) на томе всегда самое низкое из:
- Free quota
- free volume space
- free aggregate space
And note - встроенное в него - это снэпшоты и де дублирование.
Так что мы квотируем, потому что это минимизирует путаницу - в противном случае вы можете довольно легко получить сценарий, в котором вы получите путаницу между тем, как "если я удаляю 1G, то почему мой свободный объем не меняется". Это также значительно уменьшает эффект от запуска процессов/пользователей/лог-файлов.
Место, где мы этого не делаем - где мы предоставляем объем и высокий дедуп - "вид" этих томов ограничивается администраторским персоналом, который лучше понимает, как это работает.