Мы заметили проблему с одним из наших томов в netapp filer. Похоже, что том заполнен, сообщает NetApp, что том использует или резервирует 100% пространства (0% inodes) - это отображается как предупреждение. Проблема в том, что это не так. Размер тома 190 ГБ. Том имеет гибкий тип, гарантированное файловое пространство, без зеркалирования. У нас есть ровно два LUN на сопоставленном томе. 95 ГБ и 50 ГБ. Оба они настроены на резервирование 0% для снимков. У обоих есть резервирование места. На томе еще много места (теоретически). df -r показывает:
Filesystem kbytes used avail reserved Mounted on
/vol/BACKUP/ 199229440 199229440 0 142799672 /vol/BACKUP/
Также осталось немного свободного места на агрегате. У нас на одном агрегате одинаковые тома с LUN (та же конфигурация), и с ними все в порядке. У нас есть новая полка, и мы хотим перенести туда некоторые данные, прежде чем устанавливать новую полку, мы хотим убедиться, что у нас есть резервные копии всех данных. Однако из-за этого, конкретного тома, резервное копирование не выполняется (нет свободного места для моментального снимка).
добавлено: если я проверю место, занятое в производственной системе, где отображаются оба LUN, это всего 94 ГБ.
Взгляни на man vol и прочитайте немного о fractional reserve - это корень вашей проблемы.
В частности, когда LUN'ам не хватает места, они ужасно ломаются и могут вызвать хаос на хосте. NetApp позволяет вам делать снимки томов - снимок использует пространство пропорционально измененным блокам на томе. Если ваш объем заполняется, и вы не можете выделить новый блоки, потому что есть моментальный снимок ... все ваши LUN сломаются.
Таким образом, появляется частичный резерв, который гласит: «Каждый раз, когда я делаю снимок, резервируйте место на томе, чтобы я не рисковал исчерпать». Если установлено значение 100, каждый том (при наличии привязки) пытается зарезервировать пространство, равное общей сумме выделенного пространства LUN - это означает, что том должен составлять 200% от размера, чтобы быть уверенным, что вы не закончите.
Снижение частичного резерва - это риск, но не большой, если вы регулярно не циклически циклически повторяете все данные в своих LUN. Просто имейте в виду, что нехватка данных будет означать сбои записи в LUN, а это, как правило, плохие новости. Вы также можете настроить параметры гарантии громкости - file гарантия в сочетании с fractional reserve 100 означает, что ваш том должен быть на 200% от размера LUN внутри (+ некоторые, если у вас несколько привязок, хотя это не будет + 100% на привязку).
Я видел эту проблему. Как работают LUN, при записи в секторы исходное содержимое этих секторов не распределяется, но не очищается с тома до тех пор, пока не будут удалены любые снимки, использующие их. В моем случае я не подключал LUN, но у нас был сбой питания, и наш ИБП перекрыл только одну из двух цепей питания. В этой ситуации NAS отдает приоритет очистке неиспользуемых блоков ниже.
Лучше всего разместить один LUN в каждом томе. Утончите LUN, а затем настройте автоматический рост содержащего тома. Я обильно резервирую тома. Это будет означать, что пока LUN в основном не используется, у вас никогда не будет проблем. Когда была произведена запись в каждый сектор, и они начинают сильно перезаписываться, вместо того, чтобы отключаться, объем немного вырастет, чтобы приспособиться к увеличенной занимаемой площади LUN. Конечно, сервер по-прежнему видит LUN того же размера, поэтому, как только это условие закончится, использование пространства вернется к норме.
Команда для тонкого предоставления LUN: lun set reservation lunpath disable. Команда для настройки автоматического увеличения тома: vol autosize volname -m 100g -i 5g on (который установил бы максимум на 100 ГБ и увеличил бы 5 ГБ за раз).