about NetApp

Удивительно быстро летит время. Уже почти год прошел, с момента, когда авторитетное веб-издание Storage Magazine проводило свой предыдущий опрос пользователей Enterprise Storage Systems, о котором я писал в этом блоге, и вот подготовлены результаты нового, шестого по счету.

Напомню, что Storage Magazine ежегодно опрашивает пользователей различных систем хранения, с целью получить их оценку глазами самих пользователей. Оценка проводится по нескольким критериям, таким как: Sales Force Competence (компетентность продавцов продукта), Product Features (богатство функциональности), Initial Product Quality (базовое качество поставленного продукта), Product Reliability (эксплуатационная надежность), Technical Support (качество техподдержки), и, наконец, “Would you buy this product again?” - “Купите ли вы такую систему в дальнейшем еще?”. 
441 респондент оценил суммарно 727 системы (что почти вдвое выше, чем при опросе прошлого года).

Каждая категория вопросов оценивалась в диапазоне от 1 до 8, и в отчет вошли следующие системы:

• 3PAR InServ Storage Server T400/T800 or S400/S800 (32)
• EMC Symmetrix, DMX/DMX-3/DMX-4, V-Max (240)
• Hewlett-Packard XP Series or StorageWorks P9000 Series (126)
• Hitachi Data Systems USP/USP V/VSP Series (95)
• IBM DS8000 Series or XIV Storage System (106)
• NetApp FAS6000 Series or V6000 (123)

В скобках указано общее количество оцененных систем данного вендора. Отмечу также, что результаты опроса прошлого года критиковались за решение включить в него у NetApp и серию 3000, вместе с 6000, в этом опросе было решено оценивать midrange-серию 3000 отдельно. По сравнению с опросом прошлого года из результатов полностью выпала Sun/Oracle. Также не набрала достаточного количества отзывов для участия Fujitsu. 3Par в данном опросе пока еще участвует под своим именем.

Как вы понимаете, пишу я это в блоге конечно же потому, что NetApp опять продемонстрировал хороший результат. Появившись в этом опросе только в 2007 году, NetApp быстро пошел вверх, в 2009-м сравнялся с лидером, EMC, и вчистую победил в 2010. ?? вот новая оценка пользователей.

Я всегда отмечаю, что самая суть не в абсолютной величине, а в динамике, в тренде. Самая польза от таких результатов в их изменениях. Вот, например, сравнивая с результатами прошлого года, мы видим, как хорошо себя показала в глазах пользователей Hitachi, которой, судя по всему, уход Sun из ее OEM-клиентов придал силы к мобилизации, и как тяжело дался прошедший год EMC.

Завершается опрос, по традиции, вопросом к пользователям: “Купите ли вы еще такую систему?” Вновь, как и в прошлом году, пользователи демонстрируют доверие и удовлетворенность продуктами NetApp. В прошлом году результат NetApp в 91,4% был самым высоким из всех опросов Storage Magazine. Отрадно видеть, что в этом году он побил даже прошлогодний рекорд.

Полную версию отчета можно прочесть по ссылке (версия для печати на одной странице).

Как вы заметили, стандартными днями публикации в этом блоге являются понедельник и четверг. В эти дни выходят мои собственные заметки в блоге. Но недавно я решил “расширить предложение”, и по средам тут будут публиковаться наиболее интересные публикации переводов постов из англоязычных блогов, в частности из blogs.netapp.com – директории официальных блоггеров NetApp, где, зачастую, встречаются очень интересные посты, увы, по причине “англоязычности” часто проходящие мимо внимания русскоязычных пользователей.

Сегодня – пост Кейта Аасена, инженера службы поддержки пользователей в NetApp, где он рассказывает об основных ошибках пользователей при конфигурировании дедупликации на системах хранения NetApp.

The 4 Most Common Misconfigurations with NetApp Deduplication

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, хранящимися по отдельности друг от друга, будут заметно выше. Но, в принципе, оба варианта вполне рабочие.

Вот такие четыре основных ошибки конфигурирования дедупликации, с которыми приходится сталкиваться на практике у наших пользователей.

SnapCreator Framework это пока не такой широко известный и активно продвигаемый продукт, как, например, продукты семейства SnapManager, но тоже интересный инструмент.

Это, если в двух словах, специальный фреймворк для самостоятельного создания процессов взятия консистентных снэпшотов для любых ваших систем, в том числе и тех, для которых пока нет специализированных SnapManager-ов. Например, в комплекте с SnapCreator поставляются, как образец, плагины для IBM DB2, MySQL и Oracle DB (несмотря на то, что для Oracle и есть отдельный SnapManager for Oracle). SnapCreator это не заменяющий его, но дополняющий продукт.

Продукт выпущен под следующие платформы:

• Microsoft Windows Server 2008 (32/64bit)
• Microsoft Windows Server 2003 (32/64bit)
• Red Hat® Enterprise Linux® (32/64bit)
• SUSE® Linux Enterprise Server (32/64bit)
• Solaris® SPARC and x86
• IBM® AIX®

В состав framework входят необходимые для управления созданием снэпшотов API и средства, сервер, под различные платформы, а сами плагины под конкретные продукты пишутся на Perl.

Серверная часть SnapCreator общается, с одной стороны, с хранилищем под Data ONTAP с помошью вызовов API, с другой – с агентами под приложения, которые осуществляют операции необходимых предварительных действий при создании снэпшота данных приложенй, операцию фиксации состояния, например режим hot backup для базы, и прочие подобные действия, обеспечивающие консистентность получаемых снэпшотов. После выполнения необходимых предварительных действий на уровне приложения, сервер вызывает через API необходимую функцию в Data ONTAP и создает снэпшотданных этого приложения.

Посмотреть Administration Guide можно тут:
SnapCreator Framework 3.3.0 Installation and Administration Guide

Пользователи обсуждают продукт, задают вопросы и делятся решениями, в том числе и готовыми плагинами в форуме NetApp Communities (eng):
communities.netapp.com - snapcreator

Обратите внимание, SnapCreator это отличный способ создавать и использовать снэпшоты NetApp для, например, баз MySQL, PostgreSQL, MaxDB и некоторых других популярных баз данных, и использующих их решений, для которых нет готового SnapManager, но уже написаны плагины под SnapCreator.

Скачать – в NOW. Продукт бесплатный, но несвободно распространямый, и доступен клиентам NetApp, имеюшим доступ к скачиванию ПО для их систем. Начиная с текущей версии 3.3, SnapCreator Framework не требует специальной лицензии и approving для использования на сайте пользователя.

Не вполне про NetApp, но раз уж приходится заниматься темой, по которой находятся интересные материалы, то было бы неправильно их не публиковать, тем более, что при нынешней стратегической дружбе Cisco и NetApp в проекте FlexPod, это и к NetApp некоторым боком относится, по крайней мере мне, в ходе “разбора” с FlexPod это все было крайне интересно.

В блоге инженера Cisco Брэда Хедлунда обнаружились несколько видеопрезентаций по основам организации сети в blade-системах Cisco UCS B. У автора они выложены на Youtube, а мне показалось более удобно смотреть их в оффлайне, поэтому я скачал их и сделал в виде файлов в формате mp4, позволяющих непосредствнно копировать и просматривать на iPod/iPhone/iPad.

Оригинальная статья здесь:
http://bradhedlund.com/2011/03/08/cisco-ucs-networking-videos-in-hd-updated-improved/

690Mb HD-видео в MP4 - тут:
http://www.divshare.com/folder/845459-b15

Cisco UCS Networking - Part 01 - The Physical Architecture of UCS.mp4
Cisco UCS Networking - Part 02 - Infrasctructure Virtualization.mp4
Cisco UCS Networking - Part 03 - Switching Modes of the Fabric Interconnect.mp4
Cisco UCS Networking - Part 04 - Upstream connectivity for SAN.mp4
Cisco UCS Networking - Part 05 - Appliance Ports and NAS direct attach.mp4
Cisco UCS Networking - Part 06a - Fabric Failover with Hyper-V and bare metal OS.mp4
Cisco UCS Networking - Part 06b - Fabric Failover with VMware.mp4
Cisco UCS Networking - Part 07a - End Host mode pinning.mp4
Cisco UCS Networking - Part 07b - Upstream LAN Connectivity.mp4
Cisco UCS Networking - Part 08 - Inter-Fabric Traffic and Recommemded LAN Topologies.mp4
Cisco UCS Networking - Part 09 - Disjointed L2 Domains.mp4
Cisco UCS Networking - Part 10 - Gen2 Adapters.mp4
Cisco UCS Networking - Part 11 - Cisco VIC (Palo) QoS.mp4
Cisco UCS Networking - Part 12 - SPAN, IPv6.mp4

Но кроме “встроенных” в Data ONTAP средств, есть еще и очень полезные “внешние” утилиты сбора и анализа. Например, для пользователей NetApp на NOW есть скрипт perfstat, собирающий с контроллера разнообразную информацию по производительности в единый “лист”. В дальнейшем этот вывод perfstat можно обрабатывать и анализировать другими утилитами, а также использовать в сайзинге.

Скрипт существует как для UNIX (в виде bash-скрипта), так и для Windows, оба варианта работают через rsh/ssh.
Запущенный без параметров, он выведет подробную инструкцию по использованию. Рекомендую начать с ее изучения.

Perfstat: Version 7.32 12-2008
    - perfstat.sh is a simple Bourne Shell script that
      captures performance and configuration statistics.
    - Output from perfstat is sent to standard out and
      is typically captured in an output file for
      later analysis.
    - perfstat.sh is capable of capturing info from host(s) and
      NetApp storage controllers simultaneously.
    - Currently perfstat supports these OS platforms:
      Solaris, HP-UX, OSF1, Linux, AIX, FreeBSD, OpenBSD, ESX 3.5
    - perfstat.sh is typically run as root from the host or
      as a user with root-level permissions
    - For controller data capture, the user must have RSH or
      SSH privileges to the controller. Unless instructed otherwise,
      perfstat will use 'root' as the default username to communicate
      remotely with storage controllers and hosts.

Usage: (basic options list)
 perfstat [-f controllername] [-t time] > perfstat.out
    where:
    -f controllername - host name (or IP address) of target controller
    -t time - collect performance data for 'time' minutes

 Simple Examples:
   Capture data on local host and one controller for 5 minutes:
     perfstat -f controller1 -t 5 > perfstat.out
   Capture data on multiple hosts and controllers for 10 minutes:
     perfstat -h host1,host2 -f controller1,controller2 -t 10 > perfstat.out
   Capture data for five 1 minute iterations, with 10 minutes between
   successive iterations:
     perfstat -f controller1 -t 1 -i 5,10 > perfstat.out

Usage: (more complete options list)
 perfstat
          [-f controllername[,controllername1,controllername2,...]]
          [-h hostname[,hostname1,hostname2,...]]
          [-t time] (sample time per iteration, default 2)
          [-i n[,m]] (repeat n times with m minutes between samples,
                      defaults: n=1, m=0)
          [-I] (force perfstat to execute all iterations)

          [-r rootcmd] (e.g. sudo)
          [-l login[:password]] (RSH/SSH login and RSH password)
          [-S] (use SSH instead of RSH)
          [-s param1[,value1][:param2[,value2]]...] (optional RSH/SSH
                                                     arguments)

          [-F] (do not capture information from local host)
          [-V] (do not capture vfiler data)
          [-p] (capture performance data only, no config info)
          [-c] (capture config info only, no performance data)
          [-L] (capture logs - beware verbose output)
          [-E cmd[,cmd2,cmd3] (exclude commands)
          [-P domain1[,domain2,domain3...] (capture profiles,
              use "-P flat" to capture complete profile)

          [-a app_name -o app_param] (E.g., -a oracle)

          [-v] (print version info only)
          [-q] (quiet mode - suppress all console output)
          [-x] (print what commands will be issued without actually
                issuing them)
          [-d] (debug mode - beware verbose output)

          [-b] (begin sampling and return immediately)
          [-e] (end sampling - used in conjunction with -b)

          [-n] (RAM Service Invocation)

          [-k] (disable collection of "stutter" statit; i.e.,
                collect 1 statit report that covers the entire
                iteration)
          [-K] (collect only "stutter" statit reports over
                the entire iteration)

          [-T default | sk_mod,level[,sk_mod2,level,...]] (collect sktrace)
          [-B sk_buffer_size] (specify sktrace buffer size)

Notes:
 -h option adds hosts to be monitored.  By default, the local
    host is always monitored, unless the -F flag is specified.
    E.g., executing this command
      perfstat -h host1 > perfstat.out
    on machine host0 will result in data captured from both
    host0 and host1
    This command:
      perfstat -F -h host1 > perfstat.out
    on machine host0 will result in data captured from host1 only
 -l option is only applied to RSH/SSH commands to the controller.
    RSH/SSH commands to other hosts do not use the -l information.
    perfstat.sh does not support password authentication over SSH,
    so if '-S -l login:password' is specified, the password will
    be stripped from the subsequent SSH invocations.
 -S requires passwordless (public key) SSH authentication to be
    configured for all controllers and hosts
    An SSH username may prefix a hostname using a '@'
    E.g.,
      perfstat -S -h root@host1,user@host2
    Additionally, the -l option can be used to specify usernames for
    controller login. E.g.,
      perfstat -S -f controllername -l user
 -s arguments to this option use the syntax 'param,value', and param
    value pairs can be separated by a ':'
    E.g. the syntax '-S -s p1,22:p2:p3,v3' tells perfstat to build
    the following SSH invocation string:
     'SSH -o BatchMode=yes -2 -ax -p1 22 -p2 -p3 v3'
 -a is limited to these applications currently:
    oracle: -o specifies sub arguments.  run -o help for details
 -b|-e are provided for legacy compatibility and can be used to
    manually perform an iteration. Use -b to start the iteration
    and after perfstat returns, use -e to stop that iteration.
 -P saves profiling data in a tar.gz file in the current working
    directory and deletes any existing gmon files on the controller
 -E excludes all foreground commands that have at least the cmd as a
    substring; E.g.
      -E snap,vol       - excludes all 'snap*' and 'vol*' commands
      -E "snap list -v" - excludes only the command 'snap list -v'
 -T used to toggle sktrace collection and specify sk modules and the
    levels at which trace data should be collected for those modules.
    Some valid sk modules include SK, WAFL, DISK and SCSITARGET. For
    default values of 'SK 7 WAFL 4', specify '-T default'. sktrace data
    will be copied off of the controller(s) and into the current working
    directory from where perfstat was invoked.
 -B used to manually set the sktrace buffer size. By default, perfstat
    will use a default value of '40m' (40MB). Please note that it is
    required that the units be specified with the size in the format:
    k (KB), m (MB), or g (GB). This value should only be changed if
    specifically advised by global support.
 Early termination of execution: as of v7.00 perfstat will terminate
   iterations early if a calculated max runtime is met or exceeded.
   If it is required that perfstat must execute all iterations regardless
   of the total runtime, please use the '-I' option.

Неплохим вариантом использования будет сбор “суточной” статистики, путем регулярного запуска perfstat, и сбора данных, например, каждые полчаса.

Например, можно поместить в cron на администраторском хосте команду вида:

perfstat -f filer1 -t 30 -i 46 > perfstat.$date.out

Такая строка запуска делает 46 “снимков” с 30-минутным интервалом, что покрывает примерно 23 часа суток. ??з-за некоторых сложностей, связанных с тем, что выполнение множества команд в rsh при выполнении скрипта может подтормаживать, и за сутки может набежать довольно существенная задержка, NetApp рекомендует делать полный интервал снятия показаний не 24, а 23 часа (46 снимков каждые полчаса), оставив запас между сутками в час,  чтобы быть уверенным, что из-за таких задержек исполнения, не набежит нежелательная погрешность для времени запуска.

Так как официально perfstat раздается только с NOW, то есть действующим пользователям NetApp, наверное я вам его раздавать не буду, сами скачайте с NOW.

Для обработки вывода perfstat можо воспользоваться интересной утилитой PerfViewer.

Она представляет собой несколько java-апплетов, визуализирующих вывод perfstat, и поможет быстро проанализировать и оценить данные, собранные им.

Берут там же. :)

А вот про покупку Engenio ничего я вам писать не буду, так как своего мнения не имею, а распространять слухи не хочу. Хотя пока, на сегодня, ситуация выглядит в соответствии с известной поговоркой “Не было у бабы забот, да купила порося”:

Это с 60-то баксов за акцию…
Сейчас, правда, понемногу начало подниматься.

Так что лично я намерен ждать запрошеные Нетаппом три месяца, после чего, как обещано, все станет ясно, чем будет Engenio под крышей NetApp, и что они с ним такое задумали.

Я уже писал на тему охлаждения в датацентре ранее, в блоге коллег proitclub.ru, а вот та же статья на более популярном harahabr.ru, кстати хочу обратить ваше внимание, что статьи о технологиях NetApp теперь публикуются в блоге компании на Хабре, и я там тоже принимаю участие, причем “контент” там пишется непересекающийся с этим блогом. Если вам интересны технологии NetApp, советую также просматривать и тот блог тоже, мы будем писать туда две статьи в месяц.

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

Вообще тема затрат на охлаждения оборудования в датацентре не зря находится сейчас во главе любого списка оптимизации расходов на IT, ведь не секрет, что энергопотребление охлаждающего оборудования, то есть кондиционеров и систем приточно-вытяжной вентиляции, часто составлят примерно половину от общего энеропотребления всего оборудования датацентра, и сократить, подчас совсем несложными мероприятиями, такой жирный кусок затрат было бы довольно заманчиво.

Вот уже много лет, как в вопросах рабочих температур и охлаждения принято руководствоваться выводами весьма авторитетной работы MIL-HDBK 217F, выполненной для Минобороны США в 1991 году, и носящей название “Military Handbook. Reliability prediction of electronic equipment”. Приведенные в данной работе результаты утверждают, что величина отказов электронного оборудования удваивается, при повышении рабочей температуры каждые 10С.

Однако, за прошедшие 20 лет стало ясно, что приведенные в данной работе выводы по меньшей мере неполны, и найденная линейная корреляция между ростом отказов и повышением температуры, по меньшей мере, выполняется не всегда, или, вернее она не настолько линейна и детерминирована, как утверждается в этой работе.

Так, например, многие эксплуатанты, последовавшие рекомендациям ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) в 2009 году, пересмотревших свои ранние рекомендации об оптимальной температуре экспуатации оборудования, и повысивших рекомендации эксплуатационной температуры в датацентре до 27 градусов на входе в сервер, вовсе не наблюдали пропорциональное увеличение количества отказов. В подавлящем большинстве случаев сообщается о изменениях этого параметра “ниже измеряемого уровня”. Некоторые, повысившие температуру с 25 до 30 не получили роста отказов на 1,8%, предсказанного по результатам MIL-HDBK 217F. Таким образом привычная “линейная корреляция” между температурой и величиной отказов, как минимум, не подтверждается.

??нтересную историю рассказывает бывший VP отдела энергоэффективности в Sun, Субодх Бапат:

К нам обратились заказчики с Ближнего Востока, с просьбой проанализировать возможность эксплуатации датацентра вообще без охлаждения, то есть при температуре “забортного воздуха”, достигающего там 45 градусов Цельсия. Обычные наши результаты AFR (Annual Failure Rate – величины ежегодных отказов) для температуры эксплуатации 25C составляли 2,45%, и мы оценили его рост в 0,36% при росе температуры на каждый дополнительный градус. Таким образом, для температуры 45С величина ежегодных отказов составила 11,45%. Клиенты утверждали, что ликвидация затрат на охлаждение, от которого они планировали полностью отказаться, даже при замене 12% серверов в датацентре каждый год, в результате, позволяла сохранить это решение экономически эффективным.

Любопытно, что хотя повышение количества отказов на 9% (с 2,45 до 11,45%) при повышении температуры на 15 градусов, это и выше предсказанного по MIL-HDBK 217F, однако, тем не менее, даже эту величину затрат клиенты оценили как экономически приемлемую, за счет экономии на охлаждении.

Также любпытно посмотреть и на довольно известную реализацию проекта датацентра Microsoft в Дублине, работающего на пассивном испарительном охлаждении при средней температуре в датацентре в 35C.

Очень интересная работа проделана у Джеймса Гамильтона, VP и ведущего инженера Amazon Web Services, обнародованная в 2009 году на конференции Google, посвященной энергоэффективности датацентров. Собственно его запись в блоге и вызвала к жизни эту мою заметку.

Так или иначе, совершенно очевидно, что имеющиеся на сегодня данные исследований в этой области уже не удовлетворяют реальному положению дел, и требуют нового анализа, с учетом всех новых обстоятельств и трендов. Безоглядно доверять традиционным выводам о надежности и температурном режиме эксплуатации сегодня нельзя.

По сведениям, опубликованным блогом Geek ONTAP, Data ONTAP с версии 8.0.1 будет уметь использовать диски, сертифицированные по FIPS 140-2 level 2, с так называемым “аппаратным шифрованием”, то есть встроенной системой шифрования-дешифрования данных с помощью уникального для каждого диска ключа.

Это, так сказать, не функция Data ONTAP как такового, просто возможность использовать средства, предоставляемые оборудованием. Подобные диски вот уже несколько лет как есть на рынке, к сожалению, из-за ограничений ввоза криптографических систем, они в России почти не встречаются, по крайней мере в официально поставляемых системах.

Так как вся эта кухня с ключами и шифрованием работает, по сути “на уровне диска”, то специальных особых требований к уровню OS данная система не предъявляет, оставаясь “прозрачной” для уровня приложений, однако поддержку и валидацию работы с NSE (NetApp Storage Encryption) требуют SnapMirror и SnapVault, что и было проделано для версии 8.0.1.
Работу с ключами обеспечивает специальный сервер ключей.

Еще раз повторюсь, для России все эти возможности остаются сугубо теоретическими, вследстве жесткой политики ограничения импорта сильной криптографии в стране, не позволяющих такие устройства в страну ввозить на практике.

bitoniau: ??ногда на динамику автомобиля влияют не двигатель, трансмиссия и прочие умные штуки, а сгоревшая лампочка индикации затянутого ручника
bash.org.ru

Я уже затрагивал в этом блоге вопросы анализа производительности и используемых для этого инструментов. Первым, и самым простым инструментом для оценки того, что происходит на вашей системе хранения, являтся вывод команды sysstat.

Для вас, как для админа-“доктора”, это как градусник и стетоскоп. С помощью замера тепературы и измерения пульса сложно поставить полный диагноз, но это может быть первым признаком того, что система “хворает”, и первой “зацепкой” в том, чтобы “раскрутить” ситуацию до деталей, и поставить точный и исчерпывающий диагноз, уже с помощью более глубоких и обширных диагностических средств.

Начните со статьи в этом блоге, а также детально просмотрите описание sysstat во встроенной документации, в частности в Data ONTAP Command Reference vol1 (должна быть в комплектной документации вашей системы).

С помощью вывода sysstat вы сможете “вчерне” оценить происходящее на системе, а также понять причины какого-то странного поведения. Например, высокая загрузка дисковой подсистемы по вводу-выводу, при отсутствии входного трафика с хостов, может говорить о идущем процессе дискового “скраббинга”, высокая нагрузка на CPU при этом – о возможно идущей активной фазе процесса дедупликации данных. Маленькая величина Cache Hit – о неэффективности использования кэша системы. Короткий Cache Age – о нехватке объемов кэша, вынуждающего постоянно его опустошать для новых данных. Характер сброса Consistency Points – о характере и объемах записываемых на систему данных.

Однако это, повторюсь, только черновые, общие признаки.

К более детальным диагностическим средствам следует отнести выводы команд statit и stats. Последняя является одним из самых детальных и подробных средств, к сожалению довольно слабо документированных и с визуально очень тяжело читаемым человеком выводом, ориентированным скорее на работу собственного техсаппорта NetApp, чем анализа силами конечного юзера. Для облегчения  использования вывода stats я уже публиковал в этом блоге неплохой набор скриптов на Perl, которые осуществляют разбор и вывод данных команды stats в “человекочитаемом” виде.

Но сперва подробнее рассмотрим, что мы можем извлечь с помощью sysstats и statit.

Допустим, мы наблюдаем вот такую картину на выводе sysstat: sysstat_out1.txt (поставьте моноширинный шрифт для просмотрщика данного файла, отключите переносы строки и расширьте окно, чтобы вся длинная строка вывода влезла).

Что вас должно насторожить?

Мы видим мультипротокольную систему (FAS3140A с двумя полками дисков SATA, обслуживающая roaming profiles (от 130 до 700MB размером) примерно 3000 (до 600 одновременно работающих) пользователей под Windows XP), загруженную, главным образом, чтениями  по CIFS (до полутора тысяч операций в секунду). Обратите внимание на сравнительно невысокую загрузку CPU и сравнительно высокий уровень Cache Hit (попадания запросов не на диск, а читающихся из кэша), но при этом странное поведение CP Time/CP ty, и, что самое важное, почти полную, около 90% загрузку дисковой подсистемы. Подозрительно при этом выглядят объемы операций, как видите, в основном это чтения, и при этом не превышающие 2500-4000 килобайт в секунду. При этом на той же системе периодически проскакивающие записи могут быть и до 20 мегабайт в секунду, то есть дело явно не в слабости дисковой части. Что-то не дает дискам “разогнаться”. Ограничивает производительностьявно не процессор или память, а именно непонятная, объективно ничем не вызванная перегрузка дисковой подсистемы, ограничившая трафик на уровне 4Mb/s с всей группы дисков.

Давайте посмотрим детальнее на картину на уровне физических дисков на выводе команды statit: statit-out1.txt

Мы видим, что aggregate наш состоит из двух RAID-групп -  rg0 и rg1, в кофигурации RAID-DP 11d+2p. Диски 0c.16, 1b.17 и 0c.29, 0c.33 – диски parity. Остальные – Data.

Что тут мы видим странного. Во-первых обратите внимание на величину использования дисков 0с.25, 26 и 28, по сравнению с остальными дисками data (для дисков parity действуют другие правила, на них пока не смотрите). При средней нагрузке по дискам группы в 35%, на этих дисках загрузка почти вдвое выше, около 75%. Также высока и величина latency, она почти втрое-вчетверо выше на этих дисках, достигая 60-70 миллисекунд, против 14-17 для остальных. В нормально же работающем aggregate нагрузка должна равномерно распределяться по всем дискам aggregate.

По видимому “больное место” мы обнаружили. Проблема – в этих трех дисках, именно их аномальное поведение и перегрузка, скорее всего, и является причиной проблем. Причин возникновения такого hotspot-а может быть несколько. Например это может быть неоптимальное расширение aggregate увеличением размеров RAID-групп, о чем я как-то уже писал, при этом наиболее активные данные могут оказаться на немногих добавленных дисках, и впоследствии, при обращении к этим данным, перегрузить их, либо это признак аппаратной неисправности, как диска, так и дискового интерфейса (например большое количество ошибок на FC-интерфейсе ухудшают его показатели по latency из-за retransmission).

??так, в соответствии с Top5, мы действительно нашли наш bottleneck в перегрузке какого-то отдельного диска (в данном случае сразу трех их), тормозящего всю подсистему.

Часто самые простые и “неромантичные” причины проблем являются и самыми частыми. Прежде чем вы начнете тюнинговать двигатель, подвеску и городить систему впрыска закиси азота, проверьте, не ездите ли вы с затянутым ручником :)

UPD: Когда этот пост уже был написан, пришло письмо с ответом на мой вопрос “чем же история закончилась?” от автора и администратора рассмотренной системы. В двух словах: Да, действительно, проблема была в этих трех дисках, они подняли кейс в поддержке, диски были заменены, и все заработало так, как должно было работать.

Приходящим с opennet.ru по некорректно озаглавленной ссылке: эти статьи НЕ про оптимизацию произвдительности систем хранения в целом, а про специальные инструменты и средства оптимизации производительности конкретно систем NetApp FAS! Если у вас не NetApp FAS, то вам, кроме вот этой первой статьи, будет неинтересно!

С неделю уже закопался в материалы по оптимизации производительности систем хранения, причем не только NetApp, но, все же, главным образом. ?? решил подкинуть вам полезных сведений, тем более из опыта знаю, что множество админов систем хранения NetApp, увы, имеют, зачастую, самые базовые представления об диагностике и траблшутинге проблем производительности. ?? это при том, что, зачастую, системы хранения, даже в базовой поставке, не считая всяких мегакрутых штук типа DFM и Performance Advisor, имеют достаточно средств “загрузить” среднего админа мыслями.

Для начала несколько вполне разумных рекомендаций от Тома Гамильтона, инженера NetApp, занимающегося в компании базами данных и оптимизацией производительности систем хранения для них. Когда вы их читаете, то кажется, что все это очевидная банальщина. Что, впрочем, не мешает все новым и новым людям их нарушать на практике, и огребать проблемы, как результат такого нарушения.

1. В первую очередь проверьте все уже известные проблемы (known issues) с софтом и оборудованием, которые часто перечисляют вендоры в документации и release notes. Вполне возможно, что ваша проблема с производительностью имеет хорошо известную причину и, соответственно, решение.
2. Рассматривайте всю систему целиком. Не занимайтесь ускорением “на 5%” отдельно взятых подсистем ее, когда, возможно, куда большие “затыки” существуют на других участках. Выбирайте как цель оптимизации наиболее существеные в общей картине участки системы. Низкое быстродействие IT-системы в целом далеко не всегда вызвано только лишь невысокой производительностью хранилища базы данных.
3. ??змеряйте и переконфигурируйте систему поэтапно.  Не пытайтесь объять необъятное и поменять сразу все. Разделите рассмотренную вцелом систему на компоненты, оцените вклад в производительность на каждом этапе, и улучшайте производительность постепенно, начиная с участков, дающих наибольший вклад.
4. Делайте изменения в конфигурации по одному за раз. Если вы найдете причину и улучшите производительность системы, то, если изменений делалось много за раз, будет непросто найти что именно дало результат.
5. Продумайте и распишите по шагам все процедуры изменений, и, что не менее важно, “путей отступления”, “отката” в исходное состояние в случае неудачи. ДО того, как вы начнете что-то менять!
6. Не твикайте систему только ради того, чтобы потвикать! О-о… Даже и комментировать не стану :)
7. Помните про “Закон убывающей доходности”. Начиная с какого-то этапа, каждая следующая ступенька относительного прироста производительности будет вам стоить все дороже и дороже.

Правильная настройка системы хранения, и системы в целом, куда входят сервера и ПО, зачастую может дать весьма серьезный результат прироста производительности. Так, например, в TR-3557 приводится вот такая картинка для результатов базы Oracle 10g на HP-UX, работающей по 10G Ethernet NFS, для настроек по умолчанию OS, и для правильных настроек:

Всегда ищите главное, наиболее существенное “бутылочное горло” системы, и начинайте оптимизацию именно с него.

По опыту Тома Гамильтона, Top5 таких “узких мест” для системы хранения это:

1. “Затык” на уровне диска
2. На уровне интерфейса к дискам FC-AL или SAS
3. На уровне процессора контроллера или OS системы хранения
4. “Потолок” сетевой карты или target-адаптера
5. Проблемы настроек tread parallelism на клиенте

В следующих постах я покажу каким образом и с помощью чего можно обнаружить и проанализировать эти bottlenecks, и принять меры по их устранению.