При использовании тонкого предоставления с ZFS, как вы убедитесь, что у вас нет свободного места на физическом диске?
Простите, если это кажется фундаментальным вопросом, но я не смог найти ничего конкретного в Google, и я не системный администратор по профессии.
Мы устанавливаем SAN в нашем офисе, используя NexentaStor с конфигурацией RAID Z3 с 8 дисками (8 x 1,36 ТБ дисков), и сейчас все настраиваем.
Прямо сейчас, с точки зрения общего дискового пространства, у нас есть около 10,8 ТБ "реального" хранилища в SAN, все выделено в одном zpool/zvol. Я подумывал о том, чтобы обеспечить zvol (скажем, ради аргумента) 100 ТБ места для учета будущего роста.
Теоретически это кажется достаточно простым: когда мы почти исчерпали фактическое дисковое пространство, мы просто добавляем несколько новых дисков, и это "просто работает": без изменения размера файловой системы или простоев, о которых можно беспокоиться.
Однако как мы узнаем, когда нам нужно добавить больше емкости, если не входить в SAN каждые несколько часов и следить за тем, чтобы у нас оставалось свободное место?
Например, это обычно обрабатывается путем установки cron задание, или NexentaStor (или сама ZFS) выдает предупреждения, когда вы приближаетесь к емкости, или ожидается, что вы просто должны "знать", сколько места у вас осталось в любой момент времени, и сами должны его отслеживать?
Если это поможет, zvol 10,8 ТБ будет использоваться в качестве резервного хранилища (через iSCSI) для наших виртуальных серверов и тестовых виртуальных машин (которые также имеют минимальное количество ресурсов), поэтому часть проблемы, которую я вижу, заключается в том, что ее можно было бы легко запустить не хватает дискового пространства, если мы постоянно создаем / создаем моментальные снимки / восстанавливаем виртуальные машины (что мы часто делаем при тестировании различных конфигураций компьютеров и программных сред).
3 ответа
На стороне Nexenta есть volume-check скрипт, который по умолчанию настроен на ежечасный запуск. Будет:Check volume health and capacity, clear correctable device errors, validate mountpoints.
Он также отправляет еженедельный сводный отчет по электронной почте.
Тем не менее, есть некоторые вещи, которые вы должны учитывать при планировании решения для хранения данных Nexenta для целей, которые вы перечислили.
- Вы можете рассмотреть возможность использования нескольких пулов для гибкости. Работает один пул, но иногда необходимо перемещать данные или просто выбрать второй пул в локальном хранилище.
- ZFS zvols может быть расширен / сокращен на лету. Например, если вы выделите 20TB для zvol с тонким предоставлением, вы можете очень легко изменить его на 30TB или 100TB. Вам не нужно перерасходовать 100 ТБ на будущее, если у вас его нет в настоящее время.
- С zvols с тонким предоставлением, когда пространство используется, вы не можете вернуть его. Если вы выделите 2 ТБ zvol в пуле 10 ТБ, заполните zvol вверх, а затем удалите виртуальные машины на этом zvol, ваш пул все равно будет показывать только 8 ТБ свободной памяти. Это 2TB останется.
- Будете ли вы использовать сжатие или дедупликацию ZFS или и то, и другое? Одна из ситуаций, в которой имеет смысл переполнение, - это использование встроенного сжатия и данных с высокой степенью сжатия. То же самое для данных, которые дедуплицируются. В моем случае наборы данных, с которыми я работаю, сжимаются на 60%-80%, поэтому я представляю больше zvols, чем объем памяти, который у меня есть.
- Использование зеркал и raidz1/2/3 облегчает расширение основного хранилища. Вы можете добавить зеркальные пары дисков в zpool, но вы не сможете развернуть raidz1/2/3, если не добавите еще один vdev (группу дисков raidz(x)). Вы также хотели бы перебалансировать данные внутри, чтобы перераспределить между дисками.
- Какую технологию виртуализации вы будете использовать? Если VMWare, вы можете тонкое обеспечение. Я полагаю, вы увидите предупреждения хранилища данных почти на 80%. VMware также жалуется, если вы находитесь в опасной ситуации с увеличением размера снимка.
- Если вы много тестируете виртуальные машины или у вас есть виртуальные машины, размер которых колеблется, я бы предложил использовать iSCSI и zvols для относительно статических виртуальных машин и NFS для тестовых виртуальных машин (если это вариант для вашего предпочтительного решения для виртуализации). С NFS вы можете более эффективно использовать пространство хранения, поскольку вы видите полный доступный размер zpool и вам не о чем беспокоиться.
Короче говоря... я бы не стал сверхобеспечивать, чтобы учесть будущий рост. Это необязательно. В Nexenta проводятся ежечасные проверки для оповещения об использовании пространства. Также подумайте, будете ли вы использовать сжатие или нет (дедупликация требует немного большего планирования). Протестируйте вещи и посмотрите, как будет выглядеть виртуальная машина, прежде чем приступить к работе. После этого будет сложнее измениться.
Если у вас есть какая-то система мониторинга, такая как Nagios, вы легко можете написать проверку, оценивающую вывод zpool list и проверка его на соответствие пороговым значениям в вашей зоне комфорта.
Если у вас нет системы мониторинга, вы должны использовать эту возможность для ее установки - SAN является критически важным компонентом инфраструктурного оборудования, которое требует постоянного мониторинга, если вы не хотите в конечном итоге простоев или потери данных из-за неисправных дисков, условия вне пространства, сбои оборудования или проблемы с подключением.
Просто отметим, что если вы используете RAID-Z, вы не можете легко "добавить еще несколько дисков" для любого RAID-Z.