корректный Zoning для IBM DS Storage


Главная Форумы Storage SAN, Disk & Tape корректный Zoning для IBM DS Storage

В этой теме 40 ответов, 13 участников, последнее обновление  Eldar Zhensykbaev 5 года/лет, 1 месяц назад.

  • Автор
    Сообщения
  • #15772

    Andriy
    Участник

    Добрый день

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

    два HBA на сервере, два коммутатора, используем два host порта на СХД DS4800

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

    HBA1 -> Switch A -> Controller A, Port 1
    HBA2 -> Switch B -> Controller B, Port 1

    Я утверждаю, что это наследие прошивок, которые работали с RDAC, а при наличии MPIO — можно конфигурировать таким образом, чтобы HBA видел оба контроллера, что позволит нам избежать всяческих Logical Drive not on preferred path и уменшить время файловера.

    Кто прав?

  • #15773

    uxTuaHgp
    Участник

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

  • #15774

    Andrey
    Участник

    это не зонинг, это скорее физическое подключение.
    с таким (минимальным) подключением «всяческих Logical Drive not on preferred path» и файловеров не избежать.

    как минимум подключить контроллеры вторыми портами во вторые свичи:

    HBA1 -> Switch A -> Controller A, Port 1
    HBA2 -> Switch B -> Controller B, Port 1
    Switch A -> Controller A, Port 2
    Switch B -> Controller B, Port 2

    + соответствующий зонинг и мультипасинг на хостах.

  • #15775

    uxTuaHgp
    Участник

    Речь шла о том, должны ли оба контроллера DS быть видны через каждый порт HBA.

    Раньше азбуки по AIX предписывали строго
    HBA Port1 — FAB A — X ports Controller A
    HBA Port2 — FAB B — X ports Controller B

    Само собой порты контроллеров и HBA могут быть избыточными.

  • #15776

    Сергей
    Участник

    все просто.
    для RDAC есть ограничение — два пути на лун. соответственно, Ваш товарищ прав, а Ваш вариант является неподдерживаемым.
    Каждый HBA должен видеть только один dac.
    Ошибки с путями в этом случае возможны только при восстановлении неисправностей — для типа аикс в прошивке отключен failback, т.е. лун не вернется на преферед путь без запуска соответсвующей команды на СХД.

    для MPIO жесткого ограничения на количество путей нет. т.е. допустим и Ваш вариант. Поменяли ли доку чтобы это отразить — не знаю, давно не читал. 🙂

  • #15777

    Andriy
    Участник

    ну, в общем, все, о чем я ему и рассказывал.
    кстати, нашел, уже как спросил, про зонинг для MPIO. в редбуке по 3500

    спасибо за участие

  • #15813

    boombox
    Участник

    если используется mpio, то ваш вариант будет работать,
    только «Logical Drive not on preferred path » — это категория из области DS, а как там AIX будет перебирать пути ему побоку.
    Единственное, что время failover увеличится однозначно, а при хорошо нагруженной базе это очень чувствительно.

  • #15820

    uxTuaHgp
    Участник

    Кстати да, для MPIO все пути одинаковые, и не исключено, что при выходе из строя, например контроллера СХД и наличии нескольких путей до каждого из контроллеров, нужно будет перебрать несколько «нерабочих» путей, что может привести к таймауту.
    Нет?

  • #15821

    andrewk
    Участник

    да, эту проблему в свое время освящал Валерий Груздев на одном из техклубов.

  • #15834

    Andriy
    Участник

    Кстати да, для MPIO все пути одинаковые, и не исключено, что при выходе из строя, например контроллера СХД и наличии нескольких путей до каждого из контроллеров, нужно будет перебрать несколько «нерабочих» путей, что может привести к таймауту.
    Нет?

    надо проверить, но насколько я помню — SDDPCM драйвер, к примеру, отличает пути к preferred контроллеру и ввод вывод направляет на non-preffered только в случае недоступности основных путей. подозреваю, что и native MPIO делает также.

  • #15837

    Oleg
    Участник

    надо проверить, но насколько я помню — SDDPCM драйвер, к примеру, отличает пути к preferred контроллеру и ввод вывод направляет на non-preffered только в случае недоступности основных путей. подозреваю, что и native MPIO делает также.

    это если на самом hdiskX политика failover или load balance
    если — round robin, драйвер будет пытаться работать через все пути

    кстати, даже в случае с DS5K, round robin позволяет читать данные одного и того же LUN-а через оба контроллера DS5K (запись только через preffered)
    правда при этом всегда горит logical drive not on preffered path 🙂
    так что применимость такой связки чисто академическая 🙂

  • #15841

    Сергей
    Участник

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

    этот случай, кстати, самая беда. если лун просто перескочил и висит на втором контроллере, проблем кроме «не аккуратненько» нет никаких. а если скачет туда-сюда — то получается полный превед с производительностью.

  • #15847

    Andriy
    Участник

    [quote quote="japh" post=15095]
    надо проверить, но насколько я помню — SDDPCM драйвер, к примеру, отличает пути к preferred контроллеру и ввод вывод направляет на non-preffered только в случае недоступности основных путей. подозреваю, что и native MPIO делает также.

    это если на самом hdiskX политика failover или load balance
    если — round robin, драйвер будет пытаться работать через все пути
    [/quote]
    хм. что-то мне сомнительно 🙁 проведу эксперимент — результаты доложу

  • #15848

    Pavel Alexei
    Участник

    В «IBM System Storage DS Storage Manager Version 10 Installation and Host Support Guide» есть таблица по кол-ву поддерживаемых путей. RDAC поддерживает только 2 и раньше support IBM и LSI всегда пытались поддерживаться конфигурации от HBA_A — Controller_A, HBA_B — Contoller_B. В более сложных конфигурациях что я видел были подключения крест-накрест, но все равно для каждого конкретного LUN пути ограничивались цифрой 2. Помню в developerworks Storage forum писал один человек из сапорта, что большое кол-во проблем с LSI серией сториждей решалось переконфигурированием подключения с крест-на-крест на один-на-один.
    Впервые я увидел явную рекомендацию перехода на более чем 2 пути в best practice для Vmware, где для LSI-серии обязательно надо подключить сервера и сторидж только через свич и только крест-накрест. Потом это и для MPIO стало рисоваться как best practice. Видимо уже MPIO добили на поддержку без проблем более чем 2-х путей.
    Честно говоря, у меня большое подозрение что архитектура подключения крест-накрест связана с проблемами большого timeout переключения с одного HBA на другой. Т.е. если HBA_A работает с Controller_A по пути A1, и вдруг надо будет переключится на другой путь к тому же контроллеру или к Controller_B, все это будет доли секунд. А вот если HBA_A, вообще перестанет «видеть» что-либо, и надо будет переключится на HBA_B, вот тут время пойдет на десятки секунд. HBA не сразу информирует драйвер, что вдруг «ослепла». Так что такие варианты пытаются избежать и строят конфигурации когда оба HBA видят оба контроллера.

  • #16052

    Pavel Alexei
    Участник

    Интересный документ в тему
    http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101914

  • #16928

    Andriy
    Участник

    ну, собственно, дошли руки до эксперимента:

    DS3950, 7.83.xx.xx, AIX 7100-01, MPIO.

    задействовано два порта FC адаптера и по одному порту на контроллер СХД. LUN нагружен при помощи ndisk из пакета nstress

    при включении round_robin драйвер распределяет трафик между путями, которые ведут на preferred controller. никаких скачков между контроллерами LUN’а не происходит.

    При «падении» одного из портов это выглядит так: по nmon загрузка каждого fcs — по 50%, после падения — один загружается, как следовало ожидать на 100%, но переключения LUN на другой контроллер, конечно, не происходит.

  • #16943

    Alex
    Участник

    Хороший тест, спасибо.

    Правда, подозреваю, обязательно рано или поздно найдётся тот, кто после прочтения этого сообщения решит врубить round_robin не вникнув в ситуацию (не подключив крест-накрест, в смысле) .-)

  • #16944

    Sever
    Участник

    У меня сервер подключен к стораджам через 32 порта. Нагрузка размазывается по ним абсолютно равномерно. Идея была почерпнута из IBM-овского типисишного теста.

  • #16945

    Alex
    Участник

    требую подробностей.

    если понимать буквально, выходит, что data flow идёт одновременно с двух контроллеров, что раньше не работало (обращение к луну не через preffered контроллер вызывает LUN tresspassing).

  • #16946

    andrewk
    Участник

    sever, что-то мне подсказывает, что у тебя не DS3/4/5K 😉

  • #16947

    Sever
    Участник

    По две Ds8k на сервер
    Внутри каждой 8 групп лунов
    К каждой группе организовано 2 пути
    Каждый путь это прямой оптический кабель поддерживающий соединение FC-AL на 8 гигабит.
    Получается топология звезды — сервер и 16 виртуальных дисковых систем.
    Свичи тут не нужны, что повышает общую пропускную способность и надежность.

  • #16948

    Alex
    Участник

    Ааа, восьмитысячник. С ним то тривиально всё.
    Речь то шла о младших DS-ках, я и подумал, что на них уберфичу какую-то придумали.

  • #16949

    Andriy
    Участник

    на младших DS-ках придумали ALUA. аккурат после попадания Engenio в теплые лапки NetApp, первая же прошивка в которой moduleList предательски выдает «NetApp», получила поддержку ALUA. на DS3500, DCS3700 и DS5k+DS3950… так что теперь можно и на non-preferred контроллер запись фигачить 🙂 правда эту уберфичу пока еще не тестировал толком.

    и сразу же попугайничать начали все, кто пилит стораджи по классической схеме контроллеров «Active/Standby» — но премер Fujitsu заявило о том что «можно будет писать на оба контроллера, но не скажем как»…

  • #16950

    Sever
    Участник

    С младшими моделями мы работать не умеем
    Ds8k — единственная умеет подать лун для IBM i в правильном формате для нативного подключения без VIOS

  • #16951

    Andriy
    Участник

    С младшими моделями мы работать не умеем
    Ds8k — единственная умеет подать лун для IBM i в правильном формате для нативного подключения без VIOS

    IBM i 6.1.1 научилась нативно работать с DS5k с версии прошивки 7.60, надо заметить 😉

  • #16952

    Sever
    Участник

    Может быть…
    В любом случае мы не будем их использовать.
    Для не хайэнд серверов нам дешевле, проще и надежнее использовать родные диски и контроллеры, которые выпускаются для IBM i. Из них мы можем собирать любые объемы и конфигурации и совершенно свободно переподключать их к любому серверу исходя из потребностей в любой момент времени.

  • #16953

    Oldnick
    Участник

    i может работать с Ext. Storage без SAN. Собственно такой вариант мы и используем.
    для AIX SAN и зонинг необходимы. здесь вариантов нету.

  • #16955

    andrewk
    Участник

    нет, AIX тоже может работать без SAN.

  • #16959

    Andriy
    Участник

    для AIX SAN и зонинг необходимы. здесь вариантов нету.

    это чего вдруг? никаких проблем включить сторадж напрямую в адаптер — нету. куча народу так и делают. другое дело, что есть СХД, который direct-attach не умеют, наподобие storwize v7000 — ну так это второй вопрос 🙂

  • #16961

    Alex
    Участник

    для AIX SAN и зонинг необходимы. здесь вариантов нету.

    я в этом месте ажно курицей поперхнулся. ну ладно бы «неэнтерпрайзненько» было.

  • #16963

    Eldar Zhensykbaev
    Участник

    В SAN (чтобы быть точным, FC SAN) можно жить и с default zone = permit. Вот только очень недолго. Как только число устройств увеличивается, возникают проблемы с производительностью.
    Про безопасность молчу — одно неправильное движение и все пропало.

  • #16965

    Sever
    Участник

    А какова пропускная способность у SAN?
    К примеру — у меня в самый пиковый режим нагрузки на дисковую систему через все FCкарты идет суммарный поток в 9гигабайт в секунду, по 4.5 гигабайта в оба направления. Как изменится скорость такого решения, если вместо прямого соединения дополнительно задействовать пару «умных железок»?
    Хотя бы приблизительно это можно оценить?

  • #16966

    Eldar Zhensykbaev
    Участник

    А какова пропускная способность у SAN?

    Все зависит от коммутаторов, выбранных модулей у топологии (переподписки). На сегодня используемые скорости 4/8/16Gbps

    К примеру — у меня в самый пиковый режим нагрузки на дисковую систему через все FCкарты идет суммарный поток в 9гигабайт в секунду, по 4.5 гигабайта в оба направления. Как изменится скорость такого решения, если вместо прямого соединения дополнительно задействовать пару «умных железок»?
    Хотя бы приблизительно это можно оценить?

    Если правильно построена сеть, то скорость не уменьшится.
    Появится возможность мониторить подключение к дискам, растягивать территориально, управлять трафиком, шарить систему хранения (одну или несколько) между разными системами (если необходимо), lan-free backup, репликация (точнее мониторинг, управление трафиком), оптимизация протокола (для больших расстояний), внедрение севисов непосредственно в сеть хранения.
    При необходимости шифрование трафика, что важно, если оптика выходит за пределы здания/комнаты.

    Для указаного примера получаем 90 гигабит трафика — это 12 адаптеров 8Gbps. На массивах такого уровня обычно ставят большее число адаптеров, и использование SAN позволит распределить нагрузку между ними. Такое подключение позволит проводить сервисные работы на адаптерах/контроллерах без ущерба производительности, а также легко наращивать скорость подключения. Кроме того, можно выделить часть ресурсов и для других систем (естественно, отталкиваяь от производительности и объема)

  • #16967

    andrewk
    Участник

    sever, а я бы в вашем конкретном случае и не советовал SAN. Зачем? У тебя же, если я правильно понимаю, одна core banking-система использует сторедж. И ей нужна максимальная производительность, а не кучка каких-то фич, непонятно к чему. Репликация делается MIMIX’ом, для которого сторедж совершенно индиффирентен. Вот для всевозможных тестовых сред — там бы еще можно было подумать, прикупить отдельный сторедж и построить SAN.

  • #16968

    Sever
    Участник

    Вопрос задавал только с целью оценить перспективы возможного разнесения сервера и хранилищ на расстояние большее длины пачкорда.
    Все таки для меня подобная перспектива сомнительна в плане потенциальных результатов. Быстрее не будет точно… Концентрация траффикса на коммутаторе к хорошему не приведет.

  • #16969

    andrewk
    Участник

    тебе придется очень долго выбирать свитч, а в итоге — купить директор 😉 кроме скорости портов есть еще пропускная способность шины коммутатора и если в нем воткнуто 32 8 Гбит/с порта, это еще не значит, что все они одновременно смогут работать с такой скоростью.

  • #16970

    Sever
    Участник

    О том и речь. Еще немного и получится гипертрофированный пурефлекс 😉
    Тут пришла мысль — как еще можно повысить пропускную способность текущей схемы.
    — надо просто удвоить текущее число карт на хосте и «нарисовать» по два дополнительных пути. Дешево и сердито.

    У отсутствующего коммутатора пропускная способность шины неограниченна. Возьмем это за аксиому.

  • #16971

    yota
    Участник

    А какова пропускная способность у SAN?
    К примеру — у меня в самый пиковый режим нагрузки на дисковую систему через все FCкарты идет суммарный поток в 9гигабайт в секунду, по 4.5 гигабайта в оба направления. Как изменится скорость такого решения, если вместо прямого соединения дополнительно задействовать пару «умных железок»?
    Хотя бы приблизительно это можно оценить?

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

  • #16972

    Eldar Zhensykbaev
    Участник

    Как раз для разнесения SAN может помочь. Особенно, если в регионе зверствуют экскаваторщики 😉
    Естественно, волшебства не будет и внезапно скорость не вырастет в разы. Потребуется адекватное количество оптики (или лямбд), чтобы прогнать требуемые 90Gbps на заданное расстояние. Преимущество будет в том, что волокна можно положить с избытком и по разным путям. При обрыве одного направления полоса пропускания не пострадает.

    Концентрация трафика не смертельна. Просто надо использовать адекватные решения — директора, задублированные по всем параметрам. Естественно, не один, а минимум пару. При правильной эксплуатации все работает без проблем.
    Например, вот данные с директора (на апрель этого года)
    System start time: Fri Apr 2 01:11:54 2004
    System uptime: 2945 days, 12 hours, 55 minutes, 27 seconds
    Kernel uptime: 172 days, 16 hours, 56 minutes, 18 seconds
    Active supervisor uptime: 172 days, 16 hours, 54 minutes, 32 seconds

    Софт на нем обновляется регулярно.

  • #16991

    Oleg
    Участник

    тебе придется очень долго выбирать свитч, а в итоге — купить директор 😉 кроме скорости портов есть еще пропускная способность шины коммутатора и если в нем воткнуто 32 8 Гбит/с порта, это еще не значит, что все они одновременно смогут работать с такой скоростью.

    мифы нашего городка (с)
    коммутаторам нет дела до человеческих заблуждений — они все давно строятся на неблокиремой архитектуре, так что хоть все порты одновременно в обе стороны
    а вот директоры как раз предусматривают oversubscription 🙂

  • #16993

    Eldar Zhensykbaev
    Участник

    а вот директоры как раз предусматривают oversubscription 🙂

    Лучше так: директоры позволяют oversubscription 😉
    В основном, на реальных задачах (не берем такие экстремальные случаи, их мало и с ними разбираться надо индивидуально) обычно нагрузки гораздо ниже. Снимали данные о производительности в двух банках и мизерный процент линков был загружен на 2Gbps, в основном нагрузка была <1Gbps.
    И вот тут переподписка делает свое грязное дело 🙂

Для ответа в этой теме необходимо авторизоваться.