расскажите про работу в схд.

Пффф. В основном читаешь в сислоге вот это и пьешь водку стаканами.

May 13 12:44:33 hodb001abt kernel: qla2xxx 0000:10:00.0: scsi(3:0:0): Abort command issued -- 1 e474e5 2002.
May 13 17:26:32 hodb001abt kernel: qla2xxx 0000:10:00.0: scsi(3:0:0): Abort command issued -- 1 e54640 2002.
May 14 19:30:31 hodb001abt kernel: qla2xxx 0000:10:00.0: scsi(3:0:0): Abort command issued -- 1 eb4f66 2002.
May 14 23:45:08 hodb001abt kernel: qla2xxx 0000:10:00.0: scsi(3:1:0): Abort command issued -- 1 ed5446 2002.
May 14 23:45:09 hodb001abt kernel: qla2xxx 0000:10:00.0: scsi(3:1:0): Abort command issued -- 1 ed5447 2002.

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

Я б пошёл. Админить СХД - вообще сказка, настраивай нетапы & нарезай луны

Все уже давно настроено и нарезано, теперь с этим как-то жить надо.

Ну увеличивать тома и луны, да диски менять )))

В основном читаешь в сислоге вот это и пьешь водку стаканами.

Это при какой нагрузке? В фабрике на портах ошибки есть?

SAN или NAS?

Первое будет как первый коммент треда, а второе как второй.

Если нет проблем с относительно нудной работой, иди.

Админство в принципе достаточно однообразное занятие

А что тебе про неё рассказать?

описание типичного рабочего дня, необходимых навыков и знаний.

необходимых навыков и знаний.

FC, iSCSI, raid, windows/linux/что у них там есть и MPIO к ним - как минимум. Всё очень зависит от того, что нужно делать. Чистых storage админов в РФ я не видел, как правило эти люди решают несколько задач сразу (общеинфраструктурные, виртуализация, бэкап и прочее). В описании вакансии разве нет требований? А то может там что-то редкое и нестандартное.

описание типичного рабочего дня

Типичный не главное, главное справишься ли ты с нетипичным.
Когда у тебя вроде 2 фабрики и все вроде красиво, но тут вдруг раз и внезапно ВСЕ встало колом, а рядом ходит управляющий директор компании и спрашивает почему наши клевые новые и дороги fc san директора не хотят работать. И вроде все нормально и первые два уровня сапорта говорят что все нормально, но ничего не работает и бизнес стоит, теряя миллионы ежечасно. А потом все оказывается из-за одного маленького и малозночительного сервачка и одного дохлого линка, и вот тебе slow drain device во все поля. Как-то так :)

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

Если там два стораджа и два свитча это одно. Когда 3 площадки, десятки таргетов и сотни и тысячи инцициаторов, десятски свитчей, директора, Backbone-фабрики и т.д. и т.п. это уже совсем другое.

Типичный не главное, главное справишься ли ты с нетипичным. ...
... Как-то так :)

мороз по коже.

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

вот и думаю, стоит ли туда погружаться с головой. действительно ли это мне будет интересно и полезно.

может кто-нибудь из знающих это дело подкинет пруфов на профессиональную литературу? поштудировать, прикинуть хрен к носу.

Доки любого вендора и его же бестпрактис.

Доки любого вендора и его же бестпрактис.

К сожалению не всегда спасают. Мы вот недавно нашли багу в mpio hp 3par для AIX из-за чего фаловые системы клинило намертво при ребуте ноды. Дело оказало в скрытом! неизменяемом!! стандартными методами параметре. Который был когда-то в древние времена был стандартом, а для современных схд сильно не рекомендован. Как я понял про него просто все забыли. Тупо перезжало из версии в версию многие годы и никто знать не знает зачем, кто и когда это так оставил, пока мы радостно не напоролись на эту пасхалку положив весь цод во время апдейта прошивки сторадажа.

может кто-нибудь из знающих это дело подкинет пруфов на профессиональную литературу?

Но вообще да, в первую очередь доки конкретных вендоров. Если fc san, то там два основных вендора cisco и brocade, они сильно разные и нынче не совместимы.
По схд там вообще каждая железка у каждого вендора вещь сама в себе. У того же ibm мидловые storwize и топовые 8к это сильно разные железки, с разной архитектурой.
А у hp на 3par вообще нет классических рейдов и пулов. Там рейды собираются не из дисков, а из маленьких кусков на которые разбиты эти диски. В итоге один, даже самый маленький лун оказывается размазан по тысяче рейдов. Все разное в общем:)

т.е. конкретно по месту работы опыт набирать? сам, если не секрет, как устраивался?

Жесть какая... Т.е в 3PAR обновление микрокода - это не онлайн-операция? Они полагаются на то, что MPIO на хостах должен быть корректно настроен? Это в какой линейке у 3PAR такое счастье - midrange/hi-end?

собеседование я вроде прошел, с начальником поговорил

Чего ты паришься тогда? Раз начальник берет человека без опыта, значит он знает, что делает. Может, там вообще весь SAN состоит из одной MSA'хи =)

Как уже сказали, это как правило работа с закрытыми вендорскими железками (что массивы, что коммутаторы). По месту и научишься.

Я считаю, админу нужно это знать, это один из необходимых кирпичиков.

Это в какой линейке у 3PAR такое счастье - midrange/hi-end?

Все известные мне массивы (IBM,HP,EMC), как мидловые так и топовые обновляют мажорные версии микрокода таким образом, ребутая по очереди ноды.

У 3par причем есть дополнительный механизм страховки- port persistence. У каждого порта есть партнерский порт на другой ноде, когда нода и ее порты тухнут, партнерский порт поднимает у себя wwn потухшего порта по npiv. Позволяет не полагаться сильно на mpio на хосте. Но происходит это разумется не мгновенно и в нашем случае хватило, чтобы огребсти проблем.

В топовых EMC микрокод загружается на все директора одновременно, MPIO на хостах не нужен. В топовых HDS апгрейды тоже non-disruptive, ничего в оффлайн не уходит.
Да даже в HDS midrange начиная с AMS2000 тоже сделали non-disruptive upgrade. Хотя по-началу не верилось, но практика показывает, что хосты при обновлении AMS2100/HUS100 ничего не чувствуют.

В топовых EMC микрокод загружается на все директора одновременно

У меня только vnx 5600, не знал. Почитал.

During this special NDU Fast IML step, all host I/O is paused as the data structures in Symmetrix Global Memory are updated. When upgrading from one Enginuity family to the next, the time required for this internal re-structuring will vary, depending on the size of the Symmetrix, the amount of physical cache, and whether there is a disk format change between the Enginuity families. This step, and the resulting pause in host I/O, is notably longer than the standard (non-NDU)


all host I/O is paused
This step, and the resulting pause in host I/O, is notably longer than the standard


Из моего опыта все это звучит как потенциальное приключение.

Из моего опыта все это звучит как потенциальное приключение.

Вот в процессе NDU (non-disruptive upgrade) ни разу проблем не было (тьфу-тьфу), все четко.

Один раз я не мог удалить тонкий пул, созданный несколько лет назад. Пришлось обращаться в саппорт, они пофиксили какие-то self-referencing tracks и в качестве возможной причины указали это:

... orphaned tracks could be there a long time, possibly since an Enginuity 5875 to 5876 NDU, where Data Movement Engine (DME) tasks were aborted during the upgrade"

Но, как же без багов =)