about NetApp

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения NetApp – WAFL online compression, то есть сжатия данных “на лету”, для хранения их на диске в сжатом виде. В настоящий момент блоки, которые были компрессированы таким образом, не кэшируются в Flash Cache / PAM.

Как вы знаете, у NetApp есть сейчас две основных технологии снижения storage footprint, то есть объемов хранения, занимающих физическое дисковое пространство, это давно существующая и хорошо себя зарекомендовавшая во многих случаях дедупликация, и появившаяся сравнительно недавно онлайн-компрессия. Две эти технологии существуют и работают независимо друг от друга, и даже дополняют друг друга. Каждая из них имеет свои предпочтительные области применения. Например, дедупликация хорошо работает для сред виртуализации, где ее эффективность (величина экономии после ее применения) может достигать 70-85% от первоначально занятого на дисках, но в рядя других применений, например для баз данных, ее эффективность (по разным причинам, на которых мы не будем сейчас подробно останавливаться) значительно ниже, часто не более 10-20%.

Напротив, компрессия довольно неплохо уменьшает объем хранения для пользовательских файлов и баз данных (35-50%). Она также сравнительно неплохо работает даже и на уже дедуплицированных данных, что может еще повысить результаты экономии.

Сравнительно неплохая эффективность компрессии на датасетах типа баз, например, может натолкнуть вас на мысль использовать компрессию для ваших баз данных, на системах, которые часто используют Flash Cache для повышения производительности работы. Но тут вот стоит принять во внимание момент, который я вынес в заголовок заметки: Блоки, которые располагаются на томе, с включенной компрессией, и подверглись компрессии, не кэшируются во Flash Cache.

Это диаметральным образом противоположно ситуации с дедупликацией, так как дедуплицированные блоки, напротив, попадают в dedupe-aware кэш, который знает о их дедуплицированности, и умеет ее использовать (например блок, на который на диске имеется десять ссылкок из десяти разных VMDK, будет считан и находиться в кэше не в 10, как в традиционной форме кэширования, а всего в одном экземпляре, что, очевидно, увеличивает эффективную емкость кэша).

Если у вас система с Flash Cache, и вы одновременно собираетесь использовать компрессию для данных – то будьте внимательны. Компрессированные тома в системе с Flash Cache могут иметь значительно отличающуюся от некомпрессированных производительность, за счет того, что с некомпрессированными томами работа будет идти через Flash Cache, а с компрессированными – нет. Эта разница, не слишком заметная для систем без Flash Cache, за счет такого поведения для систем с Flash Cache, может быть неприятным сюрпризом.

Эта особенность работы компрессии описана в новом TR-3958 Compression and Deduplication for DataONTAP 8.1 operating in 7-Mode на странице 22:

7.6 PAM AND FLASH CACHE CARDS

In environments with high amounts of shared blocks that are read repeatedly, the PAM or Flash Cache card can significantly reduce the number of disk reads, thus improving the read performance. The PAM or Flash Cache card does not increase performance of the compression engine or of reading compressed data. The amount of performance improvement with the PAM or Flash Cache card depends on the amount of shared blocks, the access rate, the active dataset size, and the data layout. The PAM or Flash Cache card has provided significant performance improvements in VMware® VDI environments. These advantages are further enhanced when combined with shared block technologies, such as NetApp deduplication or NetApp FlexClone® technology.

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

UPD: Попросили уточнить. По-прежнему кэшируются во Flash Cache НЕсжатые блоки на сжатом томе (например, если эти блоки были исключены из процесса сжатия в результате плохого compression rate на этапе estimate для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

Пришел черед нового опроса на блоге (надеюсь вы получаете от них то же удовольствие, что и я).
Как мы знаем, нет ничего идеального, неидеален и NetApp как компания, неидеальны и его системы хранения. Что же более всего мешает пользователю NetApp FAS и клиенту компании почувствовать себя счастливым?

[poll id="3"]

Опрос, как и всегда, анонимен.
Возможны множественные ответы.
Если у вас есть собственная annoying point - не стесняйтесь высказать ее в комментариях.

Все предшествующие опросы в блоге можно посмотреть в рубрике Опрос

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

??ногда бывает нужно создать пользователя, не имеющего на системе хранения других прав, кроме read-only, например для задач демонстрации и обучения, только для получения каких-то данных или снятия показаний, или же иных подобных применений. Сделать такого пользователя можно с помощью механизма RBAC – Role-Based Access Control (кстати по RBAC в техбиблиотеке Netwell лежит дельная переведенная документация).

Пример  создания роли read-only user при помощи DataONTAP Powershell Toolkit.


#Create read-only role:
New-NaRole ro_role -Capabilities  login-*
#Add read-only capabilities to this from attached file:
$caps = Get-Content .\RoRoles.txt
ForEach ($cap in $caps)
{
  Set-NaRole ro_role -AddCapabilities  $cap
}
#Create read-only group:
New-NaGroup ro_group ro_role
#Create read-only user:
New-NaUser ro_user rouserpassword ro_group


Файл RoRoles.txt со списком вызовов API DataONTAP можно скачать тут.

Новая заметка в блоге RecoveryMonkey, которые я всегда стараюсь переводить, так как Dimitris K. всегда пишет интересно и актуально.

Interpreting $/IOPS and IOPS/RAID correctly with SPC-1 results

Posted on October 19, 2011

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

Вот некоторые моменты, на которые стоит обратить внимание.

О соотношении price/performance:

Когда вы оцениваете приведенные $/IOP, убедитесь, что вы сравниваете цены list price (смотрите на отчет с полным описанием, который содержит все детали тестированной конфигурации).

В противном случае вы можете получить неверное представление о $/IOP, так как один вендор дает цены list prices, а другой в то же время показывает цену с большим дисконтом, "street price".

Например, система, показавшая $6.5/IOP после 50% дисконта, должна показывать $13/IOP по ценам list prices.

О RAID:

Как вы уже читали в предыдущих постах, RAID играет большую роль как в вопросе защиты, так и в вопросе производительности.

Все опубликованные результаты SPC-1 используют RAID10, с единственным исключением в виде NetApp (мы используем RAID-DP, математический аналог RAID6 с точки зрения уровня защиты данных).

Вот (очень) грубый способ конвертировать результаты RAID10 в RAID6, если вендор, которого вы рассматриваете, не приводит свои результаты для RAID6:

1. SPC-1 на 60% состоит из записей.
2. Возьмем любой результат RAID10, например пусть это будет 200 000 IOPS.
3. 60% от этого составляет 120 000, это будут операции записи. 40% это операции чтения, или 80 000 IOPS.
4. При использовании традиционного RAID6, вы получаете, грубо, четырехкратное замедление для операций записи: 120 000/4 = 30 000
5. Добавляем к этому 40% чтений, и получим результат:
6. 80 000 чтений + 30 000 записей = 110 000 SPC-1 IOPS в случае использования той же конфигурации с RAID6. Это примерно половина от результата RAID10…

Обязательно убеждайтесь, что вы "сравниваете яблоки с яблоками". Я знаю, в наше время информационной перегрузки мы всегда ленимся углубиться в детали, но все же, читая результаты SPC-1, потратьте немного времени на то, чтобы просмотреть полное описание результата, там всегда содержатся очень интересные детали…

Вышла новая версия набора утилит, для подключения и работы с системой хранения NetApp по SAN-протоколам из Windows.

Это не горящая новость, но, если вы пользуетесь WHU – рекомендую обратить внимание, все же предыдущая версия – 5.3, выходила свыше полутора лет назад и накопилось новое.

Для тех, кто не в курсе: WHU – Windows Host Utilities – это набор утилит и рекомендованных настроек, помогающий правильно подключать хосты под OS Windows к LUN-ам систем хранения NetApp. При установке WHU в реестр и настройки прописываются рекомендованные NetApp установки, величины таймаутов, и так далее, обеспечивающие более стабильную работу.

Первоочередное изменение это, конечно, поддержка 8.1 Cluster-mode SAN, которая появится в 8.1RC2, также поддерживается RHEL в качестве GuestOS в Hyper-V, изменены некоторые рекомендованные таймауты настроек, включена утилита mbralign, которая поможет настроить оптимальное смещение для дисков VHD Hyper-V, устранены некоторые несогласованности при совместной работе NetApp DSM и WHU, обновлен список поддерживаемых драйверов HBA и CNA.

WHU как продукт, как я понял, постепенно уходит из оборота, большая часть его традиционных функций нынче перенесена на NetApp DSM, набор Devise Specific Module, используемый для организации SAN MPIO. Так, например, установщик WHU опознает установленный DSM 3.5 и не переписывает сделанные им настройки, которые считаются более приоритетными.

Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.

Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.

Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.

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

Уже цитировавшийся в этом блоге специалист по Oracle и блоггер NetApp с ником Neto (ранее из Бразилии, а теперь сотрудник датацентра NetApp в Triangle Park, USA), опубликовал результаты интересного эксперимента, демонстрирующие возможности и производительность NFS на системах хранения NetApp. Ниже перевод его заметки.

Не могу поверить… Еще остались люди, которые не верят в производительность на NFS

Posted by neto on Oct 8, 2011 5:23:41 AM

Многие годы я получаю много вопросов и FUD на тему того, что, якобы, NFS не обеспечивает достаточно  хорошую производительность.

Давайте смотреть.

Linux CentOS 6 с двумя портами 10Gb Ethernet (Jumbo Frames ON)

NFS v3

NetApp Cluster – каждый с одним интерфейсом 10Gb Ethernet (Jumbo Frames ON)

Cisco Nexus Switch

Я создал  4 файла на каждой mountpoint:

Запускаем ORION…

http://www.oracle.com/technetwork/topics/index-089595.html

ORION (Oracle I/O Calibration Tool) это инструмент для тестирования и калибровки показателей производительность ввода-вывода системы хранения, намеченной для использования под базы Oracle. Результаты полезны для понимания возможностей системы хранения по производительности, а таже для поиска проблем, которые могут отражаться на производительности базы Oracle, или же для сайзинга нвой инсталляции. Так как ORION это отдельный инструмент, то для проведения измерений пользователям не требуется создавать и запускать базу Oracle.
ORION генерирует синтетичекую нагрузку ввода-вывода максмально приближенную к работе базы данных Oracle, и использует тот же I/O software stack, что и Oracle. ORION может быть сконфигурирован на генерирование широкого диапазона нагрузки ввода-вывода, включая нагрузки характерные для OLTP и data warehouse.

./orion_linux_x86-64 -run advanced -testname disk1 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk2 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk3 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk4 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

Копируем скриншоты…

Controller 1

Controller 2

Server

Я полагаю, что 2 гигабайта (БАЙТА!) в секунду, этого должно хватить! Так-то. :-)

NFS это хорошо (на NetApp, конечно же).

Всех благ!

Neto

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. ??спользуемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

??так, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. ??спользуя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

Преимущества SAN boot, кроме экономии на локальных дисках, это, безусловно, большая гибкость. Особенно это полезно в условиях тестового стенда, когда развертывание из чистого эталонного образа занимает всего несколько минут, а если вам понадобилось вернуть предшествующую конфигурацию, например для продолжения работ по предыдущей теме, вы просто маппите ранее созданный и оставшийся на сторадже LUN и загружаетесь в предыдущую установку, без необходимости восстанавливать ее из бэкапа, как в “традиционном” варианте с локальными дисками.

??спользование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

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

Данные оказались любопытными, и я упросил его разрешить мне их опубликовать.

По оси X – количество подключаемых в SAN хостов-серверов, по Y – цена оборудования без учета стоимости работы и времени, только “железо”.

Цены брались “real-life” и “street price” (не list price). Разумеется dual fabric и по два порта на хост, и так далее, как положено в реал лайфе. Выбиралось оборудование за минимальную цену, выполняющее поставленную задачу, но, естественно, из доступного данному партнеру списка вендоров (поэтому, главным образом, Cisco и IBM (Brocade)). В подсчет включались HBA и NIC, коммутаторы, SFP, кабеля, лицензии на порты, где нужны, и так далее.

Результат любопытен, и показывает неоднозначность вопроса “дороговизны”. Так, например, на 1-8 хостов стоимость решения 10G Ethernet в разы перекрывает тот же 8G FC, а вот на 16-24 хоста в SAN все уже не столь очевидно (больше 24 хостов анализ не производился, там уже начинаются “директоры” и совсем иного класса оборудование).

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

Как вы все знаете, внезапно Россия решила прекратить сезонную смену временного сдвига (так называемый “переход на зимнее/летнее время”). Оставив за рамками данной статьи все прочие аспекты этой темы, сосредоточимся на проблемах сисадминских.

Как вы знаете, все действующие в настоящее время OS умеют автоматически осуществлять переход  и производить соответствующий сдвиг времени, в какой бы стране они ни были установлены (конечно, если правильно эта страна для OS указана). Средство, которое позволяет OS правильно, и в соответствии с национальными правилами (часто разными в разных странах), провести эту корректировку времени – это составляемая  Американской Национальной Лабораторией Времени (NIST) специальная база данных в файлах, которую производители OS, будь то Linux или Windows, распространяют с регулярными апдейтами.

Но как быть с такими OS, как Data ONTAP? Ведь от правильной установки времени, например, зависит работа механизма аутентификации Kerberos, и при несовпадении локального времени сервера или NAS-стораджа и контроллера домена, пользователи не смогут получить доступ к данным (их сессионные тикеты системы аутентификации Kerberos “испортятся”, например для домена Windows допустимо временное смещение для членов домена не более 15 минут).

Если вы обновляете Data ONTAP регулярно, то новое содержимое timezone у вас придет с новой версией. Если же нет – нужно записать свежий timezone, на место старого, в вашей текущей версии.

По этому поводу в Knowledge Base у NetApp есть соответствующая статья, вот вам ее сокращенный перевод.
(Я не стал переводить части, относящиеся к NetCache, VTL, а также 8.0 Cluster-mode системам).

How to update timezone information on NetApp appliances

KB ID: 1011616 Version: 3.0 Published date: 08/02/2011

Эта статья рассматривает следующие темы:

• Обновление информации timezone на Data ONTAP 7G / 7-Mode
  • Версии Data ONTAP, на которые распространяется эта информация
  • Скачивание и обновление файлов timezone
  • Установка новых значений timezone

[опущены разделы о NetCache, 8.0 Cluster-mode и пр.]

На какие версии Data ONTAP распространяется эта информация:

Все версии Data ONTAP подвержены изменениям правил в  timezone. Эти правила определяют, когда и каким образом происходит переключение локального Daylight Savings Time, а также прекращается такое переключение и производится возврат к Standard Time.

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

Скачивание и обновление файлов timezone:
Файлы timezone, которые поставляет в составе Data ONTAP компания NetApp, берутся из репозитория NIST (ftp://elsie.nci.nih.gov/pub/) , а затем компилируются и помещаются как zip, tar или в виде обычных файлов. NetApp отслеживает изменения в репозитори и автоматически получает самую свежую версию файлов, размещаемую на сайте NOW (NetApp Support).

Процесс скачивания файла на компьютер администратора под Windows/UNIX и распаковка его на систему хранения

С компьютера под управлением UNIX, с использованием NFS для подключения к  root volume:

Complete the following steps to extract the ontap_zoneinfo.tar file from a UNIX admin host to the storage system’s /etc directory:

1. Войдите на сайт NetApp Support.
2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
   http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
   Если вы по какой-то причине не можете скачать его оттуда, то версия на момент написания этого перевода лежит тут (обратите внимание! Эта версия не обновляется, и действительна для октября 2011 года!).
3. Введите следующие команды:
   unix> mount   <filername:/vol/ROOTVOLUME>   /MOUNTPOINT
   Внимание: Если вы получили в ответ на команду сообщение RPC error, это означает, что система хранения не имеет экспорта для root voume. Если вы получаете RPC error, войдите на систему хранения как root, и выполните следующую команду:
   exportfs -i -o /
   Затем повторите команду монтирования.
4. Введите команду:
   unix> cd MOUNTPOINT/>etc
5. Введите команду:
   unix> gunzip PATHTOZONEFILE>/ontap_zoneinfo.zip
6. Введите команду:
   unix> cd /
7. Введите команду:
   unix> umount MOUNTPOINT>
8. Проведите инициализацию новых установок и правил нового timezone.

С компьютера под управлением Windows, с использованием CIFS для подключения к root volume:

Выполните следующие шаги, для того, чтобы распаковать ontap_zoneinfo.zip в сетевую папку ETC$ на системе хранения:

1. Войдите на сайт NetApp Support.
2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
   http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
3. Подключите сетевой ресурс (share) ETC$ с системы хранения как сетевой диск на букву диска T: на админском компьютере.
   Внимание: Выбор имен диска T: приведен для примера. ??спользуйте любую доступную букву.
4. Распакуйте содержимое файла ontap_zoneinfo.zip на диск T: .
5. Проведите инициализацию новых установок и правил нового timezone.

??нициализация новых установок и правил timezone

ВАЖНО: Обязательно выполните приведенные шаги для успешного обновления информации timezone!

Для загрузки новых установок timezone, исполните следующие команды:

1. Введите команду:
   filer> timezone
Current time zone is Location/YourTimezone     <— введите текст, который будет выведен на месте выделенного курсивом на следующем шаге.
2. Введите команду:
   filer> timezone Location/YourTimezone 

(например: filer> timezone Europe/Moscow)

Система хранения НЕ ТРЕБУЕТ перезагрузки для обновления и установки новых значений правил timezone.

Внимание: НЕ ПЕРЕСТАВЛЯЙТЕ ВРЕМЯ НА С??СТЕМЕ ХРАНЕН??Я ВРУЧНУЮ ВПЕРЕД ?? НАЗАД. Это не является правильным способом проверить новые изменения DST (Daylight Saving Time). Если вы так сделаете, не будут работать расписания создания снэпшотов, пока система не будет перезагружена. Такое поведение документировано в баге BUG 234237 (в настоящий момент считается fixed на всех актуальных версиях Data ONTAP. прим romx).

??нженеры NetApp проверили и подтвердили, что процедура, описанная в данной статье, успешно решает задачу изменения установок и правил DST.