Как вы заметили, стандартными днями публикации в этом блоге являются понедельник и четверг. В эти дни выходят мои собственные заметки в блоге. Но недавно я решил “расширить предложение”, и по средам тут будут публиковаться наиболее интересные публикации переводов постов из англоязычных блогов, в частности из blogs.netapp.com – директории официальных блоггеров NetApp, где, зачастую, встречаются очень интересные посты, увы, по причине “англоязычности” часто проходящие мимо внимания русскоязычных пользователей.
Сегодня – пост Кейта Аасена, инженера службы поддержки пользователей в NetApp, где он рассказывает об основных ошибках пользователей при конфигурировании дедупликации на системах хранения NetApp.
Posted by Keith Aasen - CSE Virtualization
Работая сервисным инженером мне приходится встречаться с пользователями из самых разных отраслей. Когда я рассказываю пользователям про наши типичные показатели экономии пространства при дедупликации данных на “боевых” системах VMware, которые составляют 60-70% изначального объема, я часто встречаюсь со скептическим отношением: “Ну, мол, это у них, у нас-то данные особенные”, часто отвечают мне, “Поверю, только когда сам увижу”. Мы демонстрируем результат, и мне нравится слышать в ответ: “О, это совсем не то, что про вас рассказывали нам ваши конкуренты!”
Совсем недавно один из наших клиентов перенес более 600 виртуальных машин, занимавших на его действующей системе хранения 11,9TB, на новый дисковый массив NetApp, причем это были 600 виртуальных машин разного содержимого, с различными OS, с различными в них приложениями и их конфигурациями, и после дедупликации это заняло всего 3,2TB – 73% экономии!
Но иногда встречаются пользователи, которые звонят с вопросами: “Эй, а у нас тут дедупликация дала всего 5%, в чем дело?” Такие невысокие показатели дедупликации, по моему опыту, являются следствием какой-нибудь из перечисленных ниже типичных ошибок.
Ошибка №1 – Неправильно изначально включенная дедупликация (или забытая опция –s для scan)
Как уже указывал в своем блоге Dr.Dedupe, NetApp рекомендует использовать дедупликацию для всех данных VMware. Вы можете заметить, что если вы используете наш продукт Virtual Storage Console (VSC), плагин к vCenter, то созданные в нем датасторы VMware автоматически идут с включенной опцией дедупликации для них. Мы советуем оставлять включенной эту опцию, и вот почему.
Когда для тома включена дедупликация (ASIS), то контроллер отслеживает все записываемые на этот том блоки данных. Когда наступает время запуска процесса дедупликации, то контроллер просматривает все отслеженные ранее блоки, и устраняет дубликаты среди них. Но только среди тех, которые он перед этим уже отследил при записи! Что же делать, если у вас уже на диске было несколько виртуальных машин, для которых опция дедупликации не была включена изначально при их создании? Если вы не указали контроллеру NetApp специально просканировать блоки уже лежащих на его дисках данных, то эти виртуальные машины и их данные не будут обработаны дедупликацией! Это приведет к снижению результатов, показываемых дедупликацией. Но хорошая новость состоит в том, что это легко поправить. Запустите дедупликацию с опцией scan в VSC, или же вручную, из консоли управления укажите у команды sis ключ –s.
Выше – рассматриваемое действие в VSC, ниже – в System Manager, другом нашем инструменте управления контроллером системы хранения.
Для предпочитающих командную строку это будет sis start -s /vol/myvol, удивительно как много могут сделать всего два дополнительных символа.
Это, по моим наблюдениям, самая популярная ошибка, но благодаря все большему количеству наших пользователей, которые создают разделы для VMware с помощью VSC, она становится все менее распространенной.
Ошибка №2 – Включенное резервирование пространства под LUN
На контроллере NetApp у нас есть несколько различных уровней включения резервирования пространства, в зависимости от ваших потребностей. Но для VMware используются главным образом два. Первый – это резервирование на уровне тома (volume reservation). Оно резервирует пространство в объеме пула aggregate, и обеспечивает вам уверенность в том, что объект, который вы помещаете на том, на него поместится, и для него найдется достаточно места. Внутри такого тома вы можете создавать LUN-ы для VMware. Тут вы тоже можете выбрать вариант резервирования пространства под LUN, которое займет сразу все необходимое пространство на томе под создаваемый LUN. ?? с этим есть две проблемы. Первая – что вам так делать, на самом деле, не нужно. Вы уже зарезервировали место на уровне тома на aggregate, с помощью volume space reservation, вам не нужно резервировать его еще раз, с помощью LUN space reservation. Вторая – LUN reservation означает, что LUN всегда будет занимать зарезервированное пространство. То есть LUN , созданный с заданным размером 600GB, всегда займет на дисках эти 600GB, даже если он пустой, даже если на нем успешно поработала дедупликация.
Простое отключение резервирование пространства для LUN даст вам эффект от дедупликации данных на нем (да, кстати вы можете сделать это прямо на ходу, не останавливая VM, использующую этот LUN).
Ошибка №3 – Неверно выравненная VM
Проблема с неверным выравниванием партиций для некоторых гостевых операционных систем с нижележащей структурой блоков системы хранения хорошо документирована. Во многих случаях проблема неправильного выравнивания вызывает уменьшение результатов экономии пространства при дедупликации, ниже ожидаемых величин. Наши клиенты часто бывают поражены тем, как много блоков мы можем дедуплицировать даже между неодинаковыми OS, например между Windows 2003 и Windows 2008, или между Windows XP и Windows 2003. Но если начальное смещение партиции одной OS отличается от такого же смещения другой, то результат дедупликации будет почти нулевой.
Кроме снижения результатов экономии при дедупликации и большего занятого на дисках объема, неверное выравнивание партиции оказывает довольно значительную дополнительную нагрузку на контроллер системы хранения (любой системы хранения, не только NetApp). Поэтому было бы очень неплохо исправить эту ситуацию. На рынке существует множество программных инструментов для выполнения этого действия, включая утилиту MBRalign, которую получают клиенты NetApp в составе нашего пакета VSC (Virtual Storage Console). Когда вы поправите неправильное выравнивание ваших VM, вы увидите не только улучшение показателей экономии пространства в результате дедупликации, но и снижение уровня загрузки процессоров на контроллерах системы хранения.
Ошибка №4 – Большой объем данных в VM
Это, правда, не ошибка конфигурации, а, скорее, особенность дизайна системы. Большинство наших пользователей не отделяют данные VM от системного VMDK с OS. Возможность держать все содержимое VM в одной директории выглядит слишком заманчиво, чтобы ей пренебречь. Пользователь обычно все равно получает довольно неплохие результаты дедупликации, даже если данные приложения смешаны с блоками данных самой OS. Часто пользователи держат по настоящему большие разделы виртуальных дисков, где блоки данных OS лежат вместе с большими базами данных, репозиториями образов, или базами электронной почты, все внутри одного диска VM. Такие большие разделы смешанных данных скорее всего не будут дедуплицироваться с высокими показателями экономии. В общем-то нет ничего страшного в такой схеме, но если вы переместите VMDK с такими данными на отдельные разделы с аналогичными данными, то показатели дедупликации для таких VMDK, и для VMDK с файлами OS, хранящимися по отдельности друг от друга, будут заметно выше. Но, в принципе, оба варианта вполне рабочие.
Вот такие четыре основных ошибки конфигурирования дедупликации, с которыми приходится сталкиваться на практике у наших пользователей.