about NetApp

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

Что вы, как пользователь системы, должны знать, уметь и сделать, чтобы поддержка не огорчала.

Начнем с основ.

1. Надеюсь, вы уже скачали и прочли NetApp Support Owner’s Guide. Для него есть русский перевод, правда не самой последней версии этого документа, но если у вас сложности с английским – читайте русский перевод, он вполне годится.

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

3. Возможно вы установили и используете NetApp’s Remote Support Diagnostics Tool – компонет для RLM/SP, позволяющий поддержке удаленно коннектиться через него непосредственно в вашу систему хранения.

Что вам стоит сделать (проверить, если вы это делали раньше, и сделать, если еще не сделали)

1. Проверьте полноту и правильность информации, которую вы завели по своей системе и аккаунту в целом в support.netapp.com. Проверьте актуальность адреса (компании и, отдельно, доставки запчастей, если они отличаются), телефонных номеров, контактных данных (телефон, адреса email) ответственных за контакты с поддержкой.

Что делать, если необходимо обратиться в поддержку:

1. DON’T PANIC! :) Начните с того, что постарайтесь четко и однозначно сформулировать проблемную ситуацию. Поддержка оказывается на английском языке, но все мы понимаем, что иногда и на русском-то бывает сложно сформулировать и объяснить проблему. Начните с того, что опишите и запишите проблему на русском (на родном для вас языке), но обязательно запишите, оформите это как связный текст. Затем пройдите несколько раз, сокращая текст и уточняя, устраняя возможные неясности, неточноти и “мутные” места описания. Постарайтесь сократить его до минимально необходимого размера. Запишите максимально короткими и ясными предложениями.
Подумайте, какие дополнительные данные могут понадобиться в саппорте (логи, за какой период, данные perfstat, stats, что-то еще). Далее либо найдите того, кто вам поможет перевести данный текст на английский (не пользуйтесь автоматическими переводчиками!), либо, если это невозможно, тогда посылайте текст на русском, сделав в начале кейса приписку, что “case description language below is russian, please route it to appropriate person”. Да, это возможно. Разбор вашего текста и нахождение понимающего по-русски может занять какое-то время, но NetApp большая компания, в ней много народу работает, из очень разных стран, есть и русские, есть и разные восточноевропейцы, понимающие русский, так что практика показывает, что если вы совсем никак не можете по-английски, то это не является барьером для получения поддержки, на самом деле.

2. Подготовьте необходимые данные для идентификации вашей системы, такие как ее серийный номер (Serial ID), System ID, Purchase Order Number (это все можно найти, например, на странице вашей системы в http://mysupport.netapp.com/eservice/SupportHome.jsp. Таким вещам полезно всегда быть под руками и не только для NetApp. В моей практике я специально собрал все такие данные на все оборудование, потратив неделю времени, на отдельную страничку внутреннего портала, потратил неделю, зато теперь все под руками в самом экстренном случае.

3. Соберите и держите под руками необходимые данные о работе системы, такие как логи /etc/messages и syslog, актуальные результаты perfstat, сделанные во время набюдаемой проблемы. ??спользуемые версии, от версий Data ONTAP, до версий прошивок дисков, полок, и так далее. Если вы заводите кейс с высоким приоритетом (выше 3), подготовьтесь к тому, что позвонить с уточнениями могут в любое, в том числе нерабочее для вас время. Высокие приоритеты начинают колбасить всю группу поддержки и вовлекают в процесс много руководства. С одной стороны не стоит злоупотреблять, с другой - повышение приоритета, по моему опыту, хорошо гальванизирует саппорт, если ваша заявка зависла в Unassigned (Бывает, чо уж скрывать. У всех бывает). Помните, однако, также про разницу во временных поясах.

4. Заведите кейс (case) на странице службы поддержки в вашем аккаунте на http://mysupport.netapp.com/eservice/SupportHome.jsp
Снова: если есть проблема с английским, то не пользуйтесь автопереводчиком (а то он вам напереводит - не разгребете потом), либо найдите человека, который напишет вам перевод вашего текста, написанного на русском, либо посылайте на русском с припиской, которая поможет идентифицировать текст как русский и отправить его к понимающему этот язык. Напомню, официально поддержка на русском не оказывается, но неофициально компания часто идет навстречу.

TIPS: Если вы можете худо-бедно писать по-английски, но, например как я, часто “плаваете” в грамматической правильности выражений и сомневаетесь в ясности и понятности того, что вы пишете в ходе переписки с англоязычной поддержкой, могу порекомендовать вам полезный способ использования автопереводчика, например http://translate.google.com или http://www.bing.com/translator/ (не недооценивайте последний, MS проделала за несколько лет довольно серьезную работу) для проверки вашего текста “обратным переводом”.

Обычно я пишу на английском, а потом, чтобы убедиться, что получившееся разбирается в понятный текст и я не путаю никакие слова, я копирую предложение или его фрагмент в автопереводчик “английский -> русский”, и смотрю, получается ли хотя бы примерно то, что я хотел сказать? То есть я не использую переводчик как в чистом виде переводчик, к сожалению автоперевод все еще, для такого грамматически непростого языка, как русский, создает неприемлемого качества вывод, тем более для такого критичного содержимого, как переписка с поддержкой. Но в этом случае вы используете автопереводчик как своеобразный “валидатор”, парсер. Если то, что вы насочиняли, “распарсилось” в хотя бы приемлемый и понятный вам текст с англйийского на русский, то скорее всего его разберет и человек. Если нет – меняйте, подбирайте слова, упрощайте фразу до тех пор, пока даже тупой автопереводчин не начнет понимать то, что вы пишете. Это даст гарантию, что вас и ваш английский разберет и нормальный человек. Не стоит стесняться выражений типа Данила, ай нид хелп. Ваша задача быть абсолютно ясным, а не развлекать индийцев литературным английским.

Методы “самопомощи” (можно использовать как до обращения в поддержку, так и во время ожидания).

1. Поищите ответы по ключевым словам вашей ситуации на:

а. NetApp KnowledgeBase: https://kb.netapp.com/support/index?page=home&access=s

b. Пользовательском коммьюнити https://communities.netapp.com/welcome, а также в русскоязычной группе https://communities.netapp.com/groups/netapp-ru

c. Поищите зацепки в списке известных багов: http://mysupport.netapp.com/NOW/cgi-bin/bol/

d. Понятнее сообщения EMS (Enterprise Messaging System) в логах NetApp станут, если вы введете их в Syslog Translator: http://mysupport.netapp.com/eservice/ems. Если вы столкнулись с kernel panic в системе, то помочь разобраться в причинах может помочь Data ONTAP Panic Message Analyzer: http://mysupport.netapp.com/NOW/cgi-bin/pmsg/

d. Наконец, Google. Как ни банально бы прозвучал такой совет. В интернете есть несколько англоязычных форумов, где можно найти встретившихся со сходной с вашей проблемой, и Гугл довольно неплохо находит соответствующий тред по ключевым словам. Попробуйте вычленить для поиска в Google более-менее уникальную группу ключемых слов, например номера и коды ошибок в выводе, фрагменты сообщения об ошибке, взятые в кавычки в качестве строки поиска (точное соответствие), и так далее.

2. Проверьте вопросы совместимости с помощью NetApp Interoperability Matrix Tool: http://mysupport.netapp.com/NOW/products/interoperability/
Помните, “работает” не равно “поддерживается” или “будет работать всегда с любым релизом DOT”.

3. Вся информация по конфигурации и допустимым лимитам “железа” стораджей NetApp собирается на Hardware Universe: http://hwu.netapp.com/Home/Index

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

Продолжим наш разговор, про то, как правильно использовать вендорскую техподдержку.

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

Что-то работает не так. Пойти поискать в гугле и яндексе. Написать в форум ixbt или sysadmins.ru пост вида: “Ребята, у меня что-то не работает так, как должно. Как исправить?”. Подождать неделю. Через неделю обнаружить в треде 28 страниц флейма, кто более говно – HP или IBM (в итоге все стороны сходятся, что – Oracle), объяснений что у топикстартера кривые руки, и что под Линуксом все работает, и вообще, что автор – лох. Снова поискать в гугле. Написать пост в ЖЖ в ru_root. Почитать комменты. Попереводить найденное в гугле с помощью Google Translate. Ничего не найдя, спустя две недели, тяжело вздохнуть, и завести кейс. ?? получить через 40 минут в нем сообщение, что это была бага, поправленная пару недель назад, в патче таком-то, вот ссылка.

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

Пока же, немного о том, что нам, как кастомерам, дано в качестве интерфейса взаимодействия с поддержкой.

Continue reading ‘Как получать поддержку. Часть 1’ »

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

Начнем с основ. С того, какая поддержка у NetApp есть, и как оно все работает.

Сперва разберемся, что есть Hardware Warranty, и что в нее входит,и что такое Software Subscription, и что входит в нее, и чем одно от другого отличается. Я заметил, что для некоторых моих читателей эти понятия не вполне ясны. ??так.

Continue reading ‘Как получать поддержку: Часть 0’ »

В связи с тем, что, постепенно, Cluster-mode Data ONTAP, или как ее теперь правильно называть Clustered Data ONTAP, входит в жизнь, и все больше пользователей задумываются о ее использовании, возникает вопрос, как бы наиболее щадящим и простым способом перенести между двумя этими системами данные.
К сожалению, разница “в потрохах” между этими двумя OS, несмотря на схожесть названий, слишком велика, чтобы просто “запустить скрипт, и все сделается за час”. К сожалению пока нет реально работающего способа преобразовать уже имеющуюся 7-mode систему в C-mode. Поэтому, обычно, о Clustered ONTAP начинают думать в случае появления новой, “чистой” системы хранения, тем более, что сегодня есть возможность сделать Clustered Data ONTAP из всего пары контроллеров. Это интересно тем, что впоследствии вы уже сможете довольно свободно добавлять к этой паре контроллеров новые пары. Например старые (если они поддерживаются) контроллеры, работавшие в 7-mode, после завершения миграции данных с них, могут быть легко добавлены в такой кластер.

Довольно быстро в голову приходит идея использовать SnapMirror, штатную репликацию данных NetApp. Но поддерживает ли она репликацию между двумя “модами”? Да, поддерживает, хотя и с ограничениями. Наиболее существенным является невозможность перенести LUN-ы FCP или iSCSI. Увы, изменения в работе с метаданными LUN-ов в C-mode слишком значительны, чтобы это можно было просто реплицировать. В случае LUN-ов вы получите при попытке репликации сообщение в логах:

wafl.voltrans.lun.exists: Volume vmware_datastore1@vserver:a0cc5791-fd70-11e2-9f1f-123478563412 contains 7-Mode LUNs. It cannot be transitioned to Cluster-Mode.


В случае LUN-ов вам придется воспользоваться ручным переносом данных, либо через хост, либо через какой-то софт создания образа диска, хотя бы Norton Ghost или Acronis True Image.

Для разделов с файловыми данными, однако, можно все сделать собственными средствами SnapMirror.

Допустим, у нас есть две физических системы: 7-mode по имени NETAPP_7MODE (192.168.2.10) и Netapp Clustered ONTAP system по имени NETAPP_CMODE (192.168.1.10).

Создадим SnapMirror peer:
NETAPP_CMODE::> vserver peer transition create -local-vserver NETAPP_CMODE -src-filers-name NETAPP_7MODE

Transition peering created

Создадим том-получатель реплики данных:
NETAPP_CMODE::> volume create -volume vmware_datastore1 -aggregate aggr1 -size 100GB -type DP

[Job 16] Job succeeded: Successful

Создадим межкластерный интерфейс LIF:
NETAPP_CMODE::> network interface create -vserver NETAPP_CMODE -lif intcl_lif1 -role intercluster -home-node NETAPP_CMODE -home-port a0a-10 -address 192.168.1.10 -netmask 255.255.255.0

NETAPP_CMODE::> network routing-groups route create -vserver NETAPP_CMODE -routing-group i192.168.1.0/24 -destination 0.0.0.0/0 -gateway 192.168.1.1


Проверим, что связь есть:
NETAPP_CMODE::> network ping -lif intcl_lif1 -lif-owner NETAPP_CMODE -destination 192.168.2.10

192.168.2.10 is alive

Устанавливаем отношения репликации SnapMirror:
NETAPP_CMODE::> snapmirror create -source-path NETAPP_7MODE:vmware_datastore1 -destination-path NETAPP_CMODE:vmware_datastore1 -type TDP

Operation succeeded: snapmirror create the relationship with destination NETAPP_CMODE:vmware_datastore1

Проводим инициализацию репликации:
NETAPP_CMODE::> snapmirror initialize -destination-path NETAPP_CMODE:vmware_datastore1

Operation is queued: snapmirror initialize of destination NETAPP_CMODE:vmware_datastore1

Ждем завершения начальной полной передачи данных, проверяя статус:
NETAPP_CMODE::> snapmirror show

При необходимости обновляем данные на получателе, если они изменились на источнике:
NETAPP_CMODE::> snapmirror update -destination-path NETAPP_CMODE:vmware_datastore1

Отрезаем реплику от источника (quiesce):
NETAPP_CMODE::> snapmirror quiesce -destination-path NETAPP_CMODE:vmware_datastore1

При необходимость снова восстановить репликацию после отреза (quiesce):
NETAPP_CMODE::> snapmirror resume -destination-path NETAPP_CMODE:vmware_datastore1

Отрываем реплику (break):
NETAPP_CMODE::> snapmirror break -destination-path NETAPP_CMODE:vmware_datastore1

При необходимости повторять репликацию назначаем расписание:
NETAPP_CMODE::> job schedule cron create -name Every15mins -minute 15

NETAPP_CMODE::> snapmirror modify -destination-path NETAPP_CMODE:vmware_datastore1 -schedule Every15mins

После завершения репликации у вас на новой системе окажется копия данных системы с 7-mode, и их можно начинать использовать.

ВАЖНО: После репликации для тома-получателя будет автоматически выставлена опция fs_fixed_size, вы не сможете ее изменить командой vol options fs_fixed_size off, вместо этого воспользуйтесь командой: vol modify -vserver -volume -filesys-size-fixed false

??нтересный способ был подсмотрен в соседском блоге.

В некоторых (нечастых) случаях возникает необходимость преобразовать уже существующий виртуальный диск, например файл VMDK, лежащий на NFS-шаре, в RDM LUN (RDM – raw device mapping, подключение физического LUN в VM непосредственно, как SCSI LUN-а). Есть некоторое ограниченное число случаев, когда трудно или нельзя обойтись без RDM.

Сделать это можно без необходимости копирования данных через хост и создания второй копии данных. NetApp может создать LUN с указанием файла на диске, из которого будет взято его содержимое. При этом со стороны хоста это будет самый настоящий физический SCSI LUN, и его можно будет подключить как самостоятельное физическое устройство, например с помощью установленного внутри VM OS инициатора, допустим MS Software iSCSI Initiator, как новый диск. Но при этом на стороне стораджа такой “LUN” будет просто небольшой ссылкой на данные соотвествующего vmdk, уже хранящегося на дисках.

Опция –f может указать при создании LUN файл, хранящий содержимое сотвествующего LUN-а.

lun create -f /vol/vol1/test02/test02_1-flat.vmdk -t windows_2008 /vol/vol1/lun1
создаст физически небольшой файл LUN  /vol/vol1/lun1 (тип LUN – windows_2008), указывающий на существующий .vmdk файл test02_1-flat.vmdk. В дальнейшем вы можете работать с таким “LUN”-ссылкой как с настоящим LUN-ом.

Обратите внимание, что в качестве vmdk указан именно *-flat.vmdk, большого размера.

Помните также, что после такого “преобразования” нельзя удалить этот *–flat.vmdk, так как именно в нем будет находиться физическое содержимое LUN.

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

Как ни удивительно прозвучит, но в Data ONTAP нет средства переименовать созданную сетевую NAS-шару. Но зато есть возможность задать одному тому более одного имени шары. Таким образом можно сделать (не)хитрый финт: вместо переименования шары, задаем ей новое имя, а старое – удаляем. Это можно сделать руками, если у вас этих шар немного. Но когда их сотни и тысячи, то хочется завести уже какой-то инструмент. ?? вот недавно я в communities.netapp нашел скрипт на Perl, который делает именно это.

#!/usr/bin/perl -w
##########################################################
# cifs_share_rename
# rename a netapp cifs share
#Michael.S.Denney@gmail.com
$version=1.0;
##########################################################
#TO DO:
use strict;
use warnings;
use Getopt::Long;
use POSIX;
##################Global VARS#################################
use vars qw($version $verbose $debug $filer $share $new_share);
##################Predeclare SUBS#############################
use subs qw(run_cmd);
##############################################################
GetOptions(
          'f=s' => \$filer,
          'filer=s' => \$filer,
          's=s' => \$share,
          'share=s' => \$share,
          'n=s' => \$new_share,
          'new_share=s' => \$new_share,
          'v' => \$verbose,
          'd' => \$debug
);
my $t=' ';
print "verbose on\n" if $verbose;
print "debug on\n" if $debug;
$verbose=1 if $debug;
unless ($filer and $share and $new_share) {
   print "Usage: cifs_share_rename -f  -s  -n \n";
   print "Usage: cifs_share_rename --filer  --share  --new_share \n";
   exit 1 ;
}

my $cmd="ssh $filer cifs shares $share";
print "$cmd\n";
my ($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1;
}
my $path;my $comment;my $access;my %security;

print "search share=>$share\n";
foreach (@$stdout){
   print "$_\n" ;
   if (/^\S+\s+(\/vol\/\S+\s+|\/vol\/\S+\/\S+\s+)(.*)?/){
      $path=$1;
      $comment=$2;
   }#end if regex
   if ( /\s+(.+)\s+\/\s+Read/g){
        push @{$security{read}},$1;
   }
   if ( /\s+(.+)\s+\/\s+Change/g){
      push @{$security{change}},$1;
   }
   if ( /\s+(.+)\s+\/\s+Full\sControl/g){
      push @{$security{'full control'}},$1;
   }

}
print "path=>$path\n" if $path;
print "comment=>$comment\n" if $comment;
print "cifs read=>$_ \n" foreach (@{$security{read}});
print "cifs full control=>$_ \n" foreach (@{$security{'full control'}});
print "cifs change=>$_ \n" foreach (@{$security{change}});

$cmd="$t ssh $filer cifs shares -add $new_share $path -comment \'$comment\'" if ($comment);
$cmd="$t ssh $filer cifs shares -add $new_share $path" unless ($comment);
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    unless ((grep /MS-DOS/,@$stderr)and @$stderr == 1){
       exit 1;
    }
}
print "$_\n" foreach (@$stdout);

$cmd="$t ssh $filer cifs access -delete $new_share everyone";
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1 unless (grep /successfully modified/,@$stderr);
}
print "$_\n" foreach (@$stdout);

foreach my $type ('read','change','full control'){#type
   print "type=$type\n";
   foreach (@{$security{$type}}){
      $cmd="$t ssh $filer cifs access $new_share \'$_\' $type";
      print "$cmd\n";
      ($stdout,$stderr)=run_cmd $cmd;
      if (@$stderr){
          print "$_\n" foreach (@$stderr);
          exit 1 unless (grep /successfully modified/,@$stderr);
      }
      print "$_\n" foreach (@$stdout);
   }
}#end foreach type
$cmd="$t ssh $filer cifs shares -delete $share";
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1;
}
print "$_\n" foreach (@$stdout);
##########################################################
sub run_cmd{
##########################################################
   my $cmd=" @_";
   my $err_file="/dev/shm/err.$$";
   $cmd.=" 2>$err_file";
   my @stdout=qx($cmd);
   chomp @stdout;
   my @stderr;
   if (-s $err_file) { #if the error file has messages
      open ERR,"$err_file";
      @stderr=();
      close ERR;
      chomp @stderr;
      #print "$_\n" foreach (@stderr);
   }
   unlink ($err_file);
   return (\@stdout,\@stderr);
}

Если вы используете Data ONTAP Edge в своей инфраструктуре хранения (это, напомню, “виртуальный NetApp” в виде VSA, Virtual Storage Appliance, виртуальной машины с Data ONTAP внутри), в особенности если вы используете не один Edge, а несколько, в пределах одной инфраструктуры управления, то наверняка уже столкнулись с неприятной проблемой. Все Edge устанавливаются с одним и тем же “серийным номером” системы, а это приводит к неприятным эффектам для софта управления, например VSC. Однако есть решение.

Нужно при загрузке VSA прервать нормальную загрузку, и выйти в boot prompt (SIMLOADER), нажав Ctrl-C на сообщение “Hit [Enter] to boot immediately, or any other key for command prompt”. Далее введите следующие команды:

1. set bootarg.nvram.sysid=1111111101
2. set SYS_SERIAL_NUM=1111111101
3. boot

В этих командах 1111111101 – нужный вам серийный номер данного “контроллера” Data ONTAP Edge.

Если вы пользовались NetApp VSC, Virtual Storage Console, плагином для VMware vCenter, позволяющим управлять системой хранения NetApp непосредственно из среды vCenter, то видели в нем набор утилит MBRtools. Он предназначен для выравнивания разделов виртуальных машин, по границам блоков диска, файловой системы и VMFS, чтобы оптимизировать операции ввода-вывода.
Хотя с массовым переходом на Windows Server 2008 R2 и Windows 7, где партиции уже изначально создаются с правильным смещением, актуальность этих утилит и снизилась, тем не менее еще случаются ситуации, когда их по прежнему нужно использовать. Простейший пример - если сервер Windows (или Linux) установлен апгрейдом на партицию, созданную более старой системой, то скорее всего она будет выровненной неправильно.
Неправильное выравнивание может давать некоторые неприятные эффекты ввода-вывода и потенциально влиять на производительность.

Однако с переходом на ESXi, то есть “baremetal hypervisor”, не имеющий “сервисной консоли”, то есть вот той инсталляции Linux RedHat, из под которого стартовала “классическая” ESX, возникает проблема, как же устанавливать MBRtools в ESXi.

Вот как это можно теперь, например, сделать.

Continue reading ‘Установка MBRtools на ESXi’ »

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

Если у вас на сторадже используются SAN LUN-ы, то при замене “головы”, а если более точно, то при замене NVRAM (при замене контроллера обычно с ним также меняется и NVRAM (NVMEM), установленная внутри) у этих LUN изменится их SerialID. В ряде случаев это может озадачить использующие их хосты (например Windows Cluster изменяет при этом их signatures, и не может после поднять в онлайн). Поэтому было бы правильно, после замены контроллера, и до возвращения LUN-ов использующим их системам, вернуть им старые SerialID.

Если у вас LUN-ов всего несколько, то это можно сделать и вручную (главное не забыть). Но если их много, то встает вопрос автоматизации.

На сайте communities.netapp.com было найдено несколько вариантов такого скрипта. На Perl, на VBS, и в виде скрипта PowerShell.

Если вы, как и я ранее, мучаетесь от совершенно запредельно ннизкой скорости работы NetApp System Manager 2.x, основного ныне инструмента администрирования NetApp, то радикально ускорить его поможет вам способ, порекомендованный в нашем форуме (если вы еще не там – настоятельно приглашаю, ссылка в шапке блога):

По видимому причина тормозов – в крайне кривом разрешении хостнейма в IP в Java при работе через DNS, поэтому добавьте соответствие имен контроллеров и их IP в локальный файл hosts. Таким доисторическим приемом вы, на глаз, в десятки раз увеличите скорость работы, открытия панелей и их обновления.