about NetApp

В блоге Ника Триантоса, инженера NetApp, обнаружена интересная информация. С февраля по конец апреля 2010 года NetApp объявил о промо-программе для своего обучающего ресурса NetApp University.

Вы можете зарегистрироваться там и пройти 9 бесплатных веб-курсов по ряду нужных и полезных тем. Вот список входящих в промо курсов:

• Introduction to NetApp Products 
• FAS2000 Series Hardware Maintenance
• FAS3100 Series Hardware Maintenance
• FAS6000 Series Hardware Maintenance 
• Performance Acceleration Module Hardware Maintenance 
• High Availability on Data ONTAP 7.3
• SnapMirror Disaster Recovery 
• SnapMirror Planning and Implementation
• Technical Overview of System Manager 1.0  

Для того, чтобы попасть на NeApp University надо зарегистрироваться в NOW (NetApp On Web), основном портале клиентской поддержки NetApp, с логином уровня guest, после чего пойти на NetApp University, и авторизоваться там этим логином. Далее выбрать названные курсы, добавить их в свой список курсов, и пройти.

Для подробного путевождения по NetApp University eLearning, сайту, который делался только для настоящих джедаев, а простому человеку, впервые сталкивающемуся с чудовищностью юзабельности “корпоративных порталов” я подготовил вам небольшой (5 минут) скринкаст процесса. Посмотреть его можно тут: How to enroll a web-based course in NetApp University

Небольшой FAQ:

1. Это доступно любому человку, или надо быть партнером или клиентом NetApp?
   Это доступно любому, если получить логин в NOW. Для guest этот процесс иногда может затянуться на неосмысленно продолжительное время, так что не откладывайте. Конечно действующий клиент NetApp также может эти курсы пройти, даже, наверное, должен. Однако, о диковинные извивы мысли маркетинга, под логином уровня customer вы этих курсов не увидите, только под guest, так что уже действующим клиентам, имеющим логин уровня Customer, то есть с зарегистрированной на него системой, придется сделать еще один аккаунт. Основная целевая группа промо – клиенты NetApp, которые уже купили систему хранения и ожидая ее прибытия хотели бы подготовиться.
2. Когда заканчивается promo?
   Вы должны успеть зарегистрироваться до 30 апреля. Если вы зарегистрировались и заказали курсы в NU, то вы сможете их пройти и после 30 апреля. ??мейте виду, если вы проапгрейдите ваш логин с guest до customer, заказанные курсы исчезнут. Впрочем, как я знаю, для “кастомера”  есть набор своих, как платных, так и бесплатных курсов на NU.

Примечание: После регистрации тренинга, вы получите на почту, которая соответствует вашему зарешистрированному в NOW логину, письмо о успешном заказе тренинга. Вот оттуда выдержка про аппаратные и программные требования:

This web-based course is available for access any time and can be completed over multiple sessions.

System Requirements
Please review the general system requirements below to ensure that web-based training (WBT) courses operate correctly.

Machine Specifications:

• Pentium class personal computer
• Windows 2000 or XP operating system
• Broadband internet connection
• Internet Explorer 6.x
• Audio capability
• 1024×768 or greater screen resolution
• 256 MB or greater RAM

Other configuration notes:

• Pop-up blockers can interfere with WBT course operation and should be turned off
• Sun Java Plug-In should be installed and enabled
• Adobe Flash player should be installed and enabled
• Active X should be enabled
• The following software configurations are currently being evaluated:
• Microsoft Vista operating system
• Internet Explorer 7.x
• Firefox 2.x

Тематика тестирования производительности и stress-test не отпускает, и поэтому я решил сделать небольшой обзор некоторых “подручных” (тех, которыми приходилось пользоваться) средств оценки и измерения производительности.

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

SIO

На вебсайте NOW, в разделе ToolChest найдена небольшая утилитка SIO – Simulated I/O, которая пусть  н столь совершенна и гибка как IOmeter, но тоже может использоваться с успехом. Она есть для Windows, Linux, Solaris, AIX и HP-UX, соотвтствующие версии можно скачать из ToolChest.

iozone

??сторически в Linux/UNIX средах популярна программка iozone. Она же существует и под другие платформы, в том числе и под win32. Текущая версия – 3.321 Программа имеет огромное количество ключей и настроек, в которых можно увязнуть надолго.  Описание всех их для всеобъемлющего тестирования далеко выходит за рамки этого поста, подскажу только, что с ключом –a (или –A, немного другой вариант) запускается некий дефолтный набор тестов “auto”. Также стандартный короткий тест запускается и при запуске iozone  без параметров, а ключи выводятся по –help.
В свое время в форуме sql.ru был составлен типовой паттерн тестирования, ориентированный на профиль баз данных, можно воспользоваться им.

iozone -i 0 -i 1 -i 2 -i 4 -i 5 -i 8 -e -o -c -s 4000M -r 4K -j 1 -f TEST4G4k.log -b /export/home/romx/testlog-4g4k.xls

iozone -i 0 -i 1 -i 2 -i 4 -i 5 -i 8 -e -o -c -s 4000M -r 64K -j 1 -f TEST4G64k.log -b /export/home/romx/testlog-4g64k.xls

Здесь, как видите, настроен тестовый файл размером 4000MB, и проводятся два тестирования, с блоком 4KB и 64KB, а результаты записываются в файл testlog-*.xls

SQLIO

Не отстает и Microsoft. На сайте MS можно скачать программку SQLIO, ориентированную, казалось бы, как явствует название, на симуляцию нагрузки MS SQL Server, однако в целом это утилита довольно широкого применения. Только под Win32. К программе прилагается файлик “Using SQLIO” - Using SQLIO to Stress Test an I/O Subsystem, с помощью которого можно во всем разобраться.

SQLIOSim

Однако если вас в первую очередь интересует именно MS SQL Server и его характерные нагрузки и особенности, там же, на сайте MS TechNet можно найти программу SQLIOSim

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

Однако примите во внимание, что включение Negotiation Failover может вызывать ненужные “ложные” срабатывания “на каждый чих”, со всей последующей суетой в виде кластерного файловера, и прочим, так что применяйте ее с осторожностью, и с полным пониманием того, что вы хотите достичь.

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

Примеры:

Сначала разрешим negotiated failover (nfo) на интерфйсах в файле /etc/rc file:

ifconfig e0a ???hostname’-e0a netmask 255.255.255.0 nfo partner 10.10.1.102

Далее установим опции ONTAP:

fas> options cf.takeover.on_network_interface_failure on
fas> options cf.takeover.on_network_interface_failure.policy [ any_nic | all_nics ]

Если на вашей кластерной системе невелико количество сетевых портов, или вы не имеете избыточности в вашей сетевой инфраструктуре, то использование Negotiation Failover (NFO) может повысить отказоустойчивость вашей системы.

ВН??МАН??Е: Если обе кластерные ноды включены в один сетевой коммутатор, и коммутатор отключен, то система хранения может войти в так называемый  failover loop при котором каждая из систем попытается сделать failover на своего партнера. Внимательно оцените вашу структуру сети, чтобы не допустить такого развития событий.

Подробнее смотрите в документации на соответствующие команды ONTAP:

ifconfig:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/cmdref/man1/na_ifconfig.1.htm

options:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/cmdref/man1/na_options.1.htm

Я заметил, что многие люди читают этот блог странными способами.
Хочу привлечь ваше внимание к тому, что единственно правильный способ (два;) - читать его с адреса http://blog.aboutnetapp.ru как вебстраницу, либо подписаься на RSS по адресу http://blog.aboutnetapp.ru/rss (или он же: http://feeds.feedburner.com/AboutNetapp).

Это я к тому, что я постепенно буду стараться прекращать “левые” ретрансляции блога, и первой “жертвой” будет ITblogs, который уже опустился ниже плинтуса качеством и количеством материала, и превратился во “френдленту Миши Елашкина”, вдобавок глючащую без меры. Так что если вы все еще читаете меня в потоке itblogs, то рекомендую перенастроить ридер на меня напрямую.

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

В недрах OS Data ONTAP скрывается много удивительных гитик.
Вот, например, в каждой системе хранения NetApp, вернее в ее OS, имеется встроенный сниффер, запускаемый командой pktt, и собирающий дамп с интерфейса для последующей разборки, в формате стандартного юниксного tcpdump.

??спользование:
pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …
pktt pause {if | all}
pktt dump {if | all} [-d dir]
pktt stop {if | all}
pktt status [{if | all}] [-v]
pktt delete [filename.trc]+
pktt list

Команда pktt управляет простым встроенным средством сбора ethernet-трафика. Пакеты захватываются с указаного интерфейса в специальный trace buffer, и после этого записываются в файл на диске. Данные записываются в формате “tcpdump”, который может быть прочитан разнообразными средствами, такими как tcpdump, ethereal (wireshark), и прочими программами-анализаторами и просмотрщиками. Вывод можно также конвертировать (утилитой editcap) в различные другие употребимые форматы, например для Sniffer, NetMon, и snoop.

pktt может захватывать пакеты для всех поддерживаемых типов медиа.

pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …

Команда start запускает трассировку, (или рестартует ее, если pktt находился в положении paused). Данные собираются в память, и пишутся в кольцеой буфер в памяти в формате “tcpdump”. Опции могут быть следующие:

-b размербуфера
Устанавливает размер буфера, который может быть определен в килобайтах или мегабайтах, при задании ‘k’ или ‘m’ после числа. Если не определен, то будет равен 128K, если вы не задали также опцию -d, что немного, но может быть достаточно в ряде случаев. Если задана опция -d, то значение буфера по умолчанию равно 1M. Значение может быть от 8K до 32M, то в очень редких случаях стоит устанавливать его большим 1-2M. Максимальный объем пространства, доступного pktt в памяти, равен 64M.

-d директория
Определяет путь к существующей директории, куда будет записан файл дампа. Файл будет иметь имя “if.trc” где”if” это имя интерфейса (например e0, fa3, и так далее.). Если опция не указана, то данные будут собиратся только в памяти, и после его заполнения, данные будут перезаписываться по кругу. Однак в любой момент можно сбросить содержимое буфера на диск с помощью команды pktt dump. Обратите внимание, что если система не будет успевать записывать все пакеты, то будет расти показатель счетчика “dropped” в выводе статуса pktt. Помните, что запись дампа всего трафика на диск может вызвать значительную нагрузку на запись для системы, и замедлить ее работу, поэтому, если это возможно, всегда ограничивайте область трассировки определенными IP-адресами и интерфейсами. Кроме этого, если вам не нужно сохранять содержимое всего пакета, то вы можете обрезать его командой -m.

??мейте ввиду, что любой существующий файл .trc будет молча перезаписан при выполнении этой команды.

-s размер
Эта опция позволяет вам задать максимальный размер файла дампа. Величина может быть задана с указанием “k”, “m”, или “g”. По умолчанию - 1G. Этот параметр всегда используется вместе с опцией -d. После достижения максимального лимита по размеру, пакеты продолжают собираться в буфер, но уже не пишутся на диск.

-m длинапакета
Этот параметр задает длину обрабатываемых пакетов (обрезая все что выходит за заданные пределы). По умолчанию - 1514 байт, что подходит для обычного ethernet, но может быть недостаточно для gigabit ethernet с использованием jumbo frames. ??ногда может быть использован для ситуаций, когда не обязательно сохранять полное содержимое пакета. Однако, во многих случаях полезно сохранять полное содержимое всего пакета. В этом случае, если пакеты имеют размер свыше 1514 байт, вы можете задать желаемый максимум. ??мейте виду, что некоторые декодеры (как пример - snoop) не обрабатывают пакеты более 1514 байт. Декодер ethereal/wireshark не имеет такой проблемы.

-i ipaddr [-i ipaddr] …
Эта опция включает простую возможность фильтрации. Можно задать до чтырех IP-адресов, для которых (на которые и с которых) будет записываться трафик. Это, кроме всего прочего, ограничит записываемый трафик только IP-пакетами, то есть в него не попадут пакеты, например arp/rarp, и прочие подобные.

pktt pause {if | all}
Команда “pause” приостанавливает сбор трафика с указаных интерфейсов. Незаписанные данные в буфере сбрасываются на диск. С помощью команды pktt start без других опций, можно возобновить сбор данных.

pktt dump {if | all} [-d dir]
Команда dump вызывает сброс содержимого кольцевого буфера в памяти в файл на диске. Если задана опция -d dir, то файл будет создан в указанной директории, в противном случае - в корневой директории root volume. ??мя файла всегда равно if.trc (где if это название интерфейса), и содержимое записывается в формате “tcpdump”. Если файл уже существует, то он будет молча перезаписан.

pktt stop {if | all}
Эта команда выполнит остановку сбора дампа для всех заданных (или вообще всех) интерфейсов. Если вы пишете на диск, то все незаписанные на этот момент данные в буфере будут сброшен на диск. Если вы не задали файл записи дампа, то все данные в буфере будут потеряны. Это действие не требует подтверждения, так что будьте аккуратны.

pktt status [{if | all}] [-v]
Эта команда покажет вым состояние буфера и файла дампа для действующей трассировки. ??спользуя “pktt status -v” вы получите полный статус всех интерфейсов.

pktt delete [filename.trc]+
Эта команда позволит вам удалить один или неколько файлов дампа в корневой директории. Длжен быть указан хотя бы один файл.

pktt list
Показывает список всех файлов трассировки в корневой директории.

Примеры:
pktt start e0
Эта команда начинает захват трафика с интерфейса “e0″. Весь трафик пищется в кольцевой буфер, размером 128K. ??ли же, если предыдущая команда приостановила сбор дампа, то она его возобновит.

pktt start fa3 -d / -s 100m -b 2m
Эта команда начинает захватывать дамп трафика на интерфейсе “fa3″, и писать в файл под названием “/fa3.trc” которому будеи позволено расти до максимальног размера в 100MB, с использованием буфера в 2MB.

pktt start el10 -d /home -m 10k -b 500k -i ehost1 -i ehost2
Эта команда начинает захватывать пакеты на и с определенных хостов, в данном примере “ehost1″ и “ehost2″ записывая их в файл “/home/el10.trc”. Пакеты размером до 10K записываются в буфер, размером 500K buffer. Отметьте, это будет работать только в том случае, если имена заданных хостов будут успешно резолвиться в DNS.

pktt start all -b 128k -i 172.20.4.1
Все интерфейсы начинают записыват дамп трафика на и с определенного IP-адреса. Это простой и быстрый способ посмотреть трафик, сли вы не уверены в том, какой интерфейс используется, но хотите увидеть пакеты с одного или более адресов IP.

Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
??змерялся FCoE и iSCSI по 10G Ethernet.

Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
http://www.netapp.com/us/library/research-papers/rp-unified-networking-evaluation.html

Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.

MAC Load-Balancing
Этот алгоритм используется не так часто, так как ему присущ ряд недостатков. Основанный на использовании MAC алгоритм балансировки вычисляет XOR между MAC-адресами пар источника и получателя. ??сточником будет MAC-адрес сетевой карты хосте, подключенного к контроллеру  NetApp. Получателем будет MAC-адрес VIF-интерфейса контроллера NetApp. Алгоритм работает хорошо, когда хосты и контроллер NetApp размещаются в одной подсети или VLAN. Когда хост расположен в другой подсети относительно контроллера NetApp, мы сталкиваемся с недостатками алгоритма. Для понимания того, что происходит, нам надо разобраться с тем, что происходит с фреймом Ethernet, когда он маршрутизируется по сети.

Допустим, мы хотим соединить Host1 с Controller1.

Host1 IP address - 10.10.1.10/24 (default gateway для Host1 - 10.10.1.1)
Controller1 IP address - 10.10.3.100/24 (default gateway для Controller1 - 10.10.3.1)

Выше мы задали для Host1 и Controller1 две отдельные подсети. Единственный путь передачи данных в том случае - через роутер. В рассматриваемом случае, роутер для подсетей 10.10.1.1 и 10.10.3.1 это один и тот же физический роутер, эти адреса просто два физических его интерфейса. Задача роутера - связать две подсети, и обеспечить передачу данных между ними.

Когда Host1 передает frame предназначенный для Controller1, он отправляет его на роутер по адресу default gateway, так как видит, что адрес 10.10.3.100 это IP-адрес не его локальной подсети, потому он отправляет его в адрес default gateway, по которому расположен роутер, в надежде, что роутер знает что с ним делать дальше, и найдет путь к получателю.

с Host1 на Host1Router

-IP Source: Host1 (10.10.1.10)
-MAC Source: Host1
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: Host1DefaultRouter

с Host1Router на Controller1

-IP Source: Host1 (10.10.1.10)
-MAC Source: Controller1DefaultRouter
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: VIFController1

Обратите внимание: MAC-адреса источника и получателя меняются, когда фрейм передается по сети. Так работает маршрутизация, и когда маршрутизаторы встречаются на пути несколько раз, то и MAC будет изменен несколько раз по пути от источника к получателю. Не важно сколько раз конкретно, главное что он меняется когда фрейм попадает в локальный сегмент контроллера. MAC источника будет являться MAC-ом роутера, а получателем – MAC-адрес VIF контроллера. Для полного понимания проблемы, допустим у нас есть четыре 1Gbps канала, объединенных в Etherchannel на Controller1. Допустим у нас есть 50 хостов в той же подсети, что и  Host1. Пары source и destination для соединения Host1 к Controller1 будут ровно теми же, что и любых других хостов в подсети host1, так как  MAC-адреса source и destination всегда будут равны Controller1DefaultRouter и VIFController1.

IP Load-Balancing
IP Load-Balancing это параметр по умолчанию для всех NetApp MultiMode VIF и наиболее часто используемый на практике метод построения MultiMode VIF на сегодня. Алгоритм не отличается от уже рассмотренного алгоритма с использованием MAC, который мы расмотрели выше. Разница только в том, что мы используем IP-адреса ??сточника (Source) и Получателя (Destination), которые, если вы посмотрите рассмотренный ранее вариант, никогда не менятся, в отличие от  адресов MAC. Факт того, что IP-адреса не меняются, создает сценарий, в котором у вас больше шансов получить уникальные пары, что, в результате, приводит к более равномерному распределению трафика по физическим линкам.

Для правильного понимания механизма работы следует учесть один важный момент, касающийся пар IP-адресов source и destination: при вычислении пар source-destination принимаются во внимание только последние октеты адресов. Это означает, что в адресе 10.10.1.10 будет использован для идентификации только 10 – последний октет адреса, в адресе 10.10.3.100 - только 100. Принимать во внимание этот момент следует в случае развертывания системы в сети, состоящей из нескольких подсетей, в этом случае может получиться так, что адреса из разных подсетей (но с одинаковым последним октетом) будут передаваться по одному физическому линку.

IP Aliasing
Понимание принципов алгоритмов Load-Balancing позволяет вам, как администратору, использовать их к собственной выгоде. Все NetApp VIF и физичские интерфейсы имеют возможность назначить им так называемые “алиасы”. Это просто дополнительный адрес для самого VIF. Рекомендуется назначит адреса(для VIF + определенное количество алиасов) равное числу физических линков в EtherChannel между контроллером и коммутатором, к которому подключен контроллер. Таким образом если вы используете VIF, состоящий из  4 штук 1Gbps линков в виде MultiMode VIF между контроллером и коммутатором, то назначьте один адрес для VIF и добавьте к нему три алиаса для того же VIF.

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

Oracle NFS -  хосты с Oracle должны монтировать тома NFS равномерно распределяя их по доступным  IP-адресам контроллера. Если у вас есть 4 различных NFS ресурса, то смонтируйте их используя для доступа четыре различных IP-адреса контроллера. Каждый ресурс будет иметь различную пару из источника и получателя (source and destination pair) и полоса передачи между хостом и контроллером будет использована более эффективно.

VMware NFS – хосты ESX должны монтировать каждый NFS Datastore через различные IP-адреса контроллера NetApp. Такой вариант наилучшим способом использует один интерфейс VMkernel (адрес источника (source)). Если у вас больше датасторов, чем  IP-адресов, то просто распределите датасторы по доступным IP-адресам контроллера NetApp поравномернее.

Обратите внимание: Когда вы назначаете алиас интерфейсу, и у вас установлены и включены партнерские отношения между двумя контроллерами (и, естественно, их физическими интерфейсами) кластера NetApp, то в случае кластерного файловера алиасы также перенесутся на партнерский интерфейс

Ну и, наконец, обещанные шаблоны:

Continue reading ‘Multimode VIF в NetApp (часть 2)’ »

На днях EMC выкатило на тесты SPECmark (тесты производительности NAS enterprise-уровня), впервые с 2007 года, свой “суперболид” на базе симметрикса и “всех порвала!!!11″.
Впрочем, как выяснилось довольно скоро, не то чтобы совсем порвала, а так, понадрывала по краю ;)
По этому поводу блоггеры NetApp вовсю ехидничают.
Судите сами:
EMC Symmetrix V-MAX, 4x V-engines, 264GB cache total
96 штук 400GB EFD flash drives (это EMC-шные SSD) в двух RAID-1
3 штуки (2 active + 1 passive) Celerra NS-G8 Datamovers в качестве NAS Gateway, 8GB cache в каждой.
24-портовый коммутатор FC, чтобы всю эту кухню пересоединять между собой
Наддув, впрыскивание закиси азота, ксеноновые фары и брызговики Sparco.

?? все это счастье сисадмина, стоимостью не менее чем 6 миллионов долларов в ценах американского лиспрайса набирает аж 110621 спекмарковских попугаев по SPECsfs2008 в NFS (и 118463 в CIFS, которые никто почти и не меряет из участников).

Круто типа.
Но при этом еще в прошлом году NetApp публиковал результаты FAS6080, с ценой проекта едва ли вполовину EMC-шной, на обычных дисках (не SSD), и даже без Performance Accelerator, показавшей 120011 спекмарковских попугаев.
А результат в районе 60 тысяч, то есть вполовину EMC-шного “устройства для завоевания превосходства в датацентре” показывает довольно таки средненькая midrange FAS3160, причем при использовании PAM делает она это на всего лишь 96 дисках SATA (!)

Я уж не говорю, что по абсолютной величине их обгоняет, например система производства Huawei Symantec ;)

Материалы по теме:
Все опубликованные результаты SPECsfs2008
Ник Триантос: “Как потратить побольше, а получить поменьше”
Вон Стюарт: “Бенчмаркинг-жульничество*”
* “Жульничество”(Shenanigans) - один из любимых терминов Чака Холлиса, блоггера EMC, обычно в отношении NetApp.
Комменты к обоим вышеприведенным постам не только доставляют, но и служат интересными источниками подробностей, рекомендую.

Часто приходится отвечать на вопрос: “Ну понятно, в Москве, конечно, все хорошо. А что делать остальной “заМКАДной” России? Что, вот прямо “некст бизнес дэй” и по остальной России? Да не поверю никогда!”

Найти пример, чтобы и “не в Москве”, и с вылетевшей запчастью, и со включенным autosupport,  оказалось непросто. Но нашел. Вот смотрите.

Организация в городе Сургут, Тюменской области, эксплуатирует FAS3020 (6 полок дисков, 84 штуки) c октября 2007 года.

22 января 2009 года, четверг, в 08:06 PST (Pacific Standard Time, “среднекалифорнийского”, в кейсовой системе NetApp время записывается “американское”. PST это GMT-8), то есть в 19:06 московского, или 21:06 местного, сургутского, система сообщает о выходе из строя диска. Автоматически заводится кейс.

Через минуту, 08:07 он обработан сотрудником поддержки, и заведен RMA (Return Materials Autorisation), то есть отдана команда на доставку.

В 20:54 того же дня, то есть в 23 января, 7:54 утра пятницы московского или 9:54 пятницы местного делается отметка в кейсе, что кастомер уведомлен, и контакт доставки подтвержден.

23 января 2009, в 03:56 PST или 16:56 местного делается отметка, что диск отправлен.

По UPS tracking number можно отследить подробности доставки:
Delivered on: 26.01 (понедельник), 14:26, местного времени.

Другой обнаруженный случай “немосковской” onsite dielivery. Калуга. Также FAS3020, 2 полки дисков, с июля 2008.

10/15/2009 02:05:22 PST  - отказ диска зарегистрирован в кейсе.
10/15/2009 05:33:10 PST – RMA заведен, получено потверждение об отправке из UPS.
10/17/2009 03:34:17 PST - “customer requests case be closed on NOW: Hi Disk is replaced. Ok to close”