Назад | Перейти на главную страницу

При использовании тонкого предоставления с ZFS, как убедиться, что у вас не закончилось место на физическом диске?

Простите меня, если это кажется фундаментальным вопросом, но я не смог найти ничего конкретного в Google, и я не системный администратор по профессии.

Мы настраиваем SAN в нашем офисе с помощью NexentaStor с 8-дисковой конфигурацией RAID Z3 (8 дисков по 1,36 ТБ) и находимся в процессе настройки всего.

На данный момент, с точки зрения общего дискового пространства, у нас есть около 10,8 ТБ «реального» хранилища в SAN, все они выделены в одном zpool / zvol. Я рассматривал возможность тонкого предоставления zvol (скажем, для аргументации) 100 ТБ пространства для учета будущего роста.

Теоретически это кажется достаточно простым: когда фактическое дисковое пространство почти исчерпывается, мы просто добавляем несколько новых дисков, и он «просто работает»: не нужно беспокоиться об изменении размера файловой системы или простоях.

Однако как нам знать когда нам нужно увеличить емкость, если не входить в сеть SAN каждые несколько часов и убедиться, что у нас еще осталось свободное место?

Например, обычно ли это выполняется путем настройки cron job, или NexentaStor (или сама ZFS) выдает предупреждения, когда вы приближаетесь к емкости, или ожидается, что вы просто должны «знать», сколько места у вас осталось в любой момент времени, и отслеживать это самостоятельно?

Если это поможет, zvol 10,8 ТБ будет использоваться в качестве резервного хранилища (через iSCSI) для наших виртуальных серверов и тестовых виртуальных машин (которые также имеют тонкое предоставление), поэтому я вижу часть проблемы в том, что его можно легко запустить не хватает места на диске, если мы постоянно создаем / делаем снимки / восстанавливаем виртуальные машины (что мы часто делаем при тестировании различных конфигураций машин и программных сред).

На стороне Nexenta есть volume-check скрипт, который по умолчанию настроен на ежечасный запуск. Так и будет:
Check volume health and capacity, clear correctable device errors, validate mountpoints.
Он также отправляет еженедельный сводный отчет по электронной почте.

Однако есть некоторые вещи, которые следует учитывать при планировании решения для хранения данных Nexenta для целей, которые вы указали.

  • Вы можете рассмотреть возможность использования нескольких пулов для обеспечения гибкости. Один пул работает, но иногда необходимо перемещать данные или просто использовать второй пул в локальном хранилище.
  • ZFS zvols можно расширять / сокращать на лету. Например, если вы выделяете 20 ТБ для zvol с тонким предоставлением, вы можете очень легко изменить его на 30 или 100 ТБ. Вам не нужно выделять 100 ТБ на будущее, если у вас их нет сейчас.
  • При использовании zvols с тонким предоставлением, как только пространство будет использовано, вы не сможете его вернуть. Если вы тонко выделите 2 ТБ zvol в пуле 10 ТБ, заполните zvol вверх, а затем удалите виртуальные машины на этом zvol, ваш пул по-прежнему будет показывать только 8 ТБ свободных. Эти 2 ТБ останутся.
  • Будете ли вы использовать сжатие 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.