антимультипассинг?


Главная Форумы Storage SAN, Disk & Tape антимультипассинг?

В этой теме 32 ответа, 10 участников, последнее обновление  MAXiK 8 года/лет назад.

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

    Sever
    Участник

    Нужна ясность по следующему вопросу.

    Есть хайенд сервер и хайенд DS. На сервере набор FC адаптеров с прямым подключением к DS. На DS имеем группу LUNов. Возможно ли организовать для сервера раздельный доступ к данным — так, чтоб каждый LUN был бы доступен для сервера только через определенный адаптер?

    Сколько раз задавал подобный вопрос — всегда получал абсолютно противоположные ответы 😉

  • #5002

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

    хайэнд ДС — это восьмитонник? думаю что на ds4k/5k это можно сделать через сторож партишнинг. но не пробовал.
    а еще можно воткнуть между железками свич и нарезать зон..

  • #5003

    Aleksandr
    Участник

    А сами LUN разве нельзя презентовать wwn адаптерам?. Просто StorageWorks EVA и CommandView именно так и презентуется LUN

  • #5004

    Sever
    Участник

    smk писал(а):

    хайэнд ДС — это восьмитонник? думаю что на ds4k/5k это можно сделать через сторож партишнинг. но не пробовал.
    а еще можно воткнуть между железками свич и нарезать зон..

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

    bagger писал(а):

    А сами LUN разве нельзя презентовать wwn адаптерам?. Просто StorageWorks EVA и CommandView именно так и презентуется LUN

    именно это и надо — однозначная связка LUN WWN адаптера на сервере. Или это и так является стандартом?

  • #5005

    uxTuaHgp
    Участник

    smk писал(а):

    хайэнд ДС — это восьмитонник? думаю что на ds4k/5k это можно сделать через сторож партишнинг. но не пробовал.
    а еще можно воткнуть между железками свич и нарезать зон..

    На 4К точно можно. В чем сомнения?
    На 8000 не в курсе, но наверное можно сделать так через SVC?

  • #5008

    Sergey
    Участник

    Если разговор про восьмитонник, то на нем при конфигурации хостконнекта явно задается через какие порты ходит данный pwwn.

  • #5231

    Владимир
    Участник

    sever писал(а):

    [b]smk писал(а):[/b]
    [quote]хайэнд ДС — это восьмитонник? думаю что на ds4k/5k это можно сделать через сторож партишнинг. но не пробовал.
    а еще можно воткнуть между железками свич и нарезать зон..

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

    bagger писал(а):

    А сами LUN разве нельзя презентовать wwn адаптерам?. Просто StorageWorks EVA и CommandView именно так и презентуется LUN

    именно это и надо — однозначная связка LUN WWN адаптера на сервере. Или это и так является стандартом?[/quote]
    Свичи конешно добавляют некоторую задержку, но если у вас маршрут до массива не проходит через десяток свичей и сотни километров линков эту разницу вы даже с микроскопом не уведите. В вашем случае самым простым решением, без покупки дополнительного оборудования, будет создать на массиве для каждого луна свою волюм группу, и к этой волюмгруппе создать хост коннекцию с нужным pwwn, вот только практика показывает что использование sddpcm есть самое лучшее решение, потому как даёт отказоустойчивость и балансировку нагрузки

  • #5255

    kir
    Хранитель

    sever писал(а):

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

    А не могли бы вы рассказать, какой процент «пропускной способности прямого соединения» теряется на «свиче, который не годится»?

    Заранее спасибо.

  • #5259

    Sever
    Участник

    порты на сервере могут работать в трех режимах — 1, 2 и 4Гбит
    HBA на DS — 2 и 4Гб
    Только при прямом соединении порт-порт линк может держаться на 4х Гбитах. Длина кабеля в этом случае не должна превышать 30 метров. Во всех других случаях скорость будет ниже в разы.

    Если я не прав, то поправьте меня…

  • #5267

    Aleksandr
    Участник

    sever писал(а):

    [b]smk писал(а):[/b]
    [quote]хайэнд ДС — это восьмитонник? думаю что на ds4k/5k это можно сделать через сторож партишнинг. но не пробовал.
    а еще можно воткнуть между железками свич и нарезать зон..

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

    bagger писал(а):

    А сами LUN разве нельзя презентовать wwn адаптерам?. Просто StorageWorks EVA и CommandView именно так и презентуется LUN

    именно это и надо — однозначная связка LUN WWN адаптера на сервере. Или это и так является стандартом?[/quote]

    Для меня да. Я если честно и не понимаю, как можно работать по другому. Сервера и Массив подключены к коммутаторам, которые составляют весь SAN. Он имеет два плеча (для отказоустойчивости). На коммутаторах нарезаны зоны адаптер-массив. В самом массиве создаются Vdisk и хосты. Хостам присваиваю WWN адаптеров. диски потом назначаю хостам. У меня в массиве нет создания рейда. HP StorageWorks EVA маскирует это своей виртуализацией.

  • #5268

    kir
    Хранитель

    sever писал(а):

    порты на сервере могут работать в трех режимах — 1, 2 и 4Гбит
    HBA на DS — 2 и 4Гб
    Только при прямом соединении порт-порт линк может держаться на 4х Гбитах. Длина кабеля в этом случае не должна превышать 30 метров. Во всех других случаях скорость будет ниже в разы.

    Ух ты.

    Теперь становится все понятно.

    А власти, тьфу, то есть редиски из IBM скрывают тайные знания.

    Но вам спасибо за срыв покровов. Жалко конечно, что без ссылок на документацию, но и так ничего.

  • #5289

    Владимир
    Участник

    sever писал(а):

    порты на сервере могут работать в трех режимах — 1, 2 и 4Гбит
    HBA на DS — 2 и 4Гб
    Только при прямом соединении порт-порт линк может держаться на 4х Гбитах. Длина кабеля в этом случае не должна превышать 30 метров. Во всех других случаях скорость будет ниже в разы.

    Если я не прав, то поправьте меня…

    Полный бред! 4 гигабита преспокойно держатся через свич, если конечно порты FRM, а использование sddpcm ещё больше увеличивает полосу пропускания. Проверено на связке DS8300+mds9000+p570

  • #5290

    _KIRill
    Хранитель

    Ёлки-иголки!!! Ну что вы как дети малые… «Бред»… Ну почему нельзя сказать «Вы не правы»?
    К вопросу о SAN: http://www.aixportal.ru/content/view/256/1/

    ---As If, But Not---

  • #5294

    Sever
    Участник

    Есть официальная конфигурация комплекса FHA в максимальной набивке для TPCишного теста.
    http://www.tpc.org/results/individual_results/IBM/IBM_595_20080610_ES.pdf
    Машина обвешена 68ю DS4800 c кучей EX810 на каждой. Используется прямое соединение FCадаптеров хоста с DSками 25метровыми кабелями. Никаких свичей нет, — они в данном случае просто не нужны. FC порты равномерно распределены по восьми дроверам. Собственно, мне нужен аналог комплекса отличающийся тем, что куча мелких DS меняется на несколько ds8k. Отсюда и родилась тема. Нужно равномерно распределить дисковые группы в 8k по соотвествующему количеству портов и, как следствие, равномерно распределить нагрузку по всему количеству линков и добиться устойчивой работы при пиковых нагрузках на ввод/вывод

    Соответствующего опыта по стороджам пока нет, но есть четкое представление того, как должна «работать» такая схема.

  • #5295

    _KIRill
    Хранитель

    Класс! Весьма познавательно! Спасибо Sever.

    ---As If, But Not---

  • #5298

    Sever
    Участник

    Может пригодиться — бенчмарки стораджей

  • #5300

    kir
    Хранитель

    sever писал(а):

    Есть официальная конфигурация комплекса FHA в максимальной набивке для TPCишного теста.
    http://www.tpc.org/results/individual_results/IBM/IBM_595_20080610_ES.pdf
    Машина обвешена 68ю DS4800 c кучей EX810 на каждой. Используется прямое соединение FCадаптеров хоста с DSками 25метровыми кабелями. Никаких свичей нет, — они в данном случае просто не нужны.

    Скажите, вы на полном серьезе не делаете разницы между «рекордной» конфигурацией и той, которую имеет смысл внедрять в эксплуатацию?

    FC порты равномерно распределены по восьми дроверам. Собственно, мне нужен аналог комплекса отличающийся тем, что куча мелких DS меняется на несколько ds8k. Отсюда и родилась тема. Нужно равномерно распределить дисковые группы в 8k по соотвествующему количеству портов и, как следствие, равномерно распределить нагрузку по всему количеству линков и добиться устойчивой работы при пиковых нагрузках на ввод

    Во-первых необходимо забыть про DS8K как про страшный сон. Дорого и тормознуто.
    Во-вторых для реальной эксплуатации естественно предусмотреть коммутаторы.
    В-третьих на всю катушку использовать принцип SAME.

    Соответствующего опыта по стороджам пока нет, но есть четкое представление того, как должна «работать» такая схема.

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

  • #5303

    Eldar Zhensykbaev
    Участник

    Машина обвешена 68ю DS4800 c кучей EX810 на каждой. Используется прямое соединение FCадаптеров хоста с DSками 25метровыми кабелями. Никаких свичей нет, — они в данном случае просто не нужны.

    Отсутствие SAN коммутаторов и использование DS4800 служит исключительно удешевлению комплекса и снижению значения в колонке Price/Performance. Добавление пары директоров повлияет на это значение, но позволит значительно сократить расходы на управление и troubleshooting всего комплекса. Повышается capex, но значительно снижается opex. Вопрос TCO должен решаться вне контекста синтетических тестов, и TCA это лишь малая часть затрат.
    Увеличение задержки на 10–20 микросекунд не даст заметного падения производительности. Зато позволит видеть состояние интефейсов, мониторить загрузку каналов и быстро изолировать неисправные HBA.

    Do not forget to leave a saucer of milk out for the storage pixie

  • #5307

    Sever
    Участник

    Stranger писал(а):

    Отсутствие SAN коммутаторов и использование DS4800 служит исключительно удешевлению комплекса и снижению значения в колонке Price/Performance. Добавление пары директоров повлияет на это значение, но позволит значительно сократить расходы на управление и troubleshooting всего комплекса.

    Разрешите с вами не согласится. Если бы IBM для TPCишного теста, основной целью которого является получение красивых цифр цена/производительность, сконцентрировала бы 68 прямых линков на две группы по 34 сходящихся на двух концентраторах/директорах, то тест бы был провален. Прямые point-to-point соединения одного сервера со многими устройствами хранения по любому будут работать быстрей и не будут создавать проблем в части пропускной способности сервера. Задача такого числа линков – ни при каких условиях не допустить возникновения узких мест при транспортировке пакетов данных на участке от CEC до DSок. Польза концентраторов/директоров при такой схеме аналогична пользе от наличия постов ГИБДД на выездах из Москвы в часы пик.

  • #5311

    kir
    Хранитель

    sever писал(а):

    Разрешите с вами не согласится. Если бы IBM для TPCишного теста, основной целью которого является получение красивых цифр цена/производительность, сконцентрировала бы 68 прямых линков на две группы по 34 сходящихся на двух концентраторах/директорах, то тест бы был провален. Прямые point-to-point соединения одного сервера со многими устройствами хранения по любому будут работать быстрей и не будут создавать проблем в части пропускной способности сервера. Задача такого числа линков – ни при каких условиях не допустить возникновения узких мест при транспортировке пакетов данных на участке от CEC до DSок. Польза концентраторов/директоров при такой схеме аналогична пользе от наличия постов ГИБДД на выездах из Москвы в часы пик.

    Господин sever.

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

    Можно даже сказать чуть жестче. Допускать до оборудования стоимостью больше пятиста долларов человека с таким сумбуром в голове как у вас — напрямую заниматься вредительством и саботажем.

    Хотя конечно если вы приблатненный сынок на синекуре у толстого папашки, то дело другое. Но если синекура — зачем вы в предмет-то лезете? Чтобы подставить кого-то ни за что ни про что?

  • #5312

    Eldar Zhensykbaev
    Участник

    Польза концентраторов/директоров при такой схеме аналогична пользе от наличия постов ГИБДД на выездах из Москвы в часы пик.

    В первую очередь, это вопрос дизайна. Если все 68 линков свести на 2 HBA, то да, толку никакого не будет. Но использовать 1 линк из 4–х имеющихся на каждом контроллере это нормально? Никто в реальной жизни не использует по 1 линку до контроллера.
    Наличие такого количества систем хранения (и, естественно, линков) обусловлено требованиями к количеству IOPS (что ограничено физическими параметрами дисков).
    Проблема для этих тестов в стоимости. Стоимость директоров для таких конфигураций существенна и дешевле поставить кучу HBA.
    В качестве коммутаторов LAN использовались 3Com Baseline Switch 2824 (24-port unmanaged switch) по цене $290 за штуку. Покажите мне хоть одну организацию, использующую такие «супер–надежные» устройства с high-end серверами.

    Задержки в коммутаторах SAN порядка 10–20 микросекунд, в то время как задержки записи на диски уже миллисекунды (прямая запись на диски важна для redo log)

    Использование SAN коммутаторов (или директоров) становится оправданным на реальных задачах. (Где 100% загрузка линка исключительное событие, но и в этом случае используют SAN сеть)

    Do not forget to leave a saucer of milk out for the storage pixie

  • #5314

    Sever
    Участник

    В первую очередь, это вопрос дизайна. Если все 68 линков свести на 2 HBA, то да, толку никакого не будет. Но использовать 1 линк из 4–х имеющихся на каждом контроллере это нормально?

    Согласен, это вопрос дизайна.

    Никто в реальной жизни не использует по 1 линку до контроллера.

    Значит я буду первым, после IBM 😉

    Наличие такого количества систем хранения (и, естественно, линков) обусловлено требованиями к количеству IOPS (что ограничено физическими параметрами дисков).

    Наличие такого числа систем хранения обусловлено целями теста TPC. Главное правило теста – тестируемый сервер должен быть в максимальной конфигурации – максимальное число процессоров и максимальный объем оперативной памяти. Время отклика транзакции не должно превышать 2х секунд. Если не обеспечить адекватную пропускную способность каналов до систем хранения, то невозможно было бы выжать из FHA требуемый результат.

    Проблема для этих тестов в стоимости. Стоимость директоров для таких конфигураций существенна и дешевле поставить кучу HBA.

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

    В качестве коммутаторов LAN использовались 3Com Baseline Switch 2824 (24-port unmanaged switch) по цене $290 за штуку. Покажите мне хоть одну организацию, использующую такие «супер–надежные» устройства с high-end серверами.

    Надежность не является критерием данного теста. Очевидно, что этого числа LAN свичей было вполне достаточно, для организации входного потока для теста со стороны 128 виндовых серверов через десять гигабитных адаптеров.

    Задержки в коммутаторах SAN порядка 10–20 микросекунд, в то время как задержки записи на диски уже миллисекунды (прямая запись на диски важна для redo log)

    Абсолютно согласен, что время задержки в SAN обычно на порядки меньше задержек возникающих на конечных дисковых устройствах, но при отсутствии любых промежуточных устройств межту FC портом на сервере и портом на DS мы не имеем вопросов по производительности этих промежуточных устройств. Этих проблем просто нет. Мы не имеем проблем надежности этих устройств и не имеем риска неадекватного вмешательства SAN-администраторов. Все вопросы по производительности комплекса направляются напрямую в IBM, как единственному вендору сервера и систем хранения. Проблему нельзя будет забулшитить в стиле “это не к нам, это вам к производителю этой железки”

    Использование SAN коммутаторов (или директоров) становится оправданным на реальных задачах. (Где 100% загрузка линка исключительное событие, но и в этом случае используют SAN сеть)

    Я так и не услышал аргументов в пользу необходимости наличия коммутаторов для очень большого сервера и нескольких DSок, которые установлены локально и используются только этим сервером. Тезис, что “так принято” для меня не является аргументом.

    С Уважением,
    Sever

  • #5315

    Eldar Zhensykbaev
    Участник

    Значит я буду первым, после IBM

    Рекомендую почитать redbook этого направления, а не следовать синтетическим тестам. Ну, разве что стоит задача получить сферического коня в вакууме (т.е. повторить тест)

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

    Управление комплексом входит в задачи тестирование производительности?
    А управление и мониторинг имеет отношение к Вашим задачам? Или только запуск и пусть все работает как захочет?

    Проблему нельзя будет забулшитить в стиле “это не к нам, это вам к производителю этой железки”

    При покупке тех же директоров через IBM (будет это Cisco MDS или Brocade), поддержкой первого и второго уровней занимается IBM Support. Вся эскалация к вендору производится IBM.

    Я так и не услышал аргументов в пользу необходимости наличия коммутаторов для очень большого сервера и нескольких DSок, которые установлены локально и используются только этим сервером. Тезис, что “так принято” для меня не является аргументом.

    «Так принято» вроде я нигде не говорил. В первую очередь дизайн диктуется задачей. И исходя из этого, есть best practices (да, «так принято в мире, поддерживается всеми производителями и настоятельно рекомендуется к использованию»).
    Учитываются соображения то поддержке работоспособности всего комплекса, масштабируемости, возможности расширения, стоимости поддержки (включая расходы на администраторов всех видов), время troubleshooting, стоимость простоя (особенно из–за долгого поиска неисправности).
    Я не рекомендую ставить директора просто из–за того, что мне так хочется. Уже не один раз наличие SAN спасало работу всей системы.

    Так что to be or not to be решать должен архитектор.

  • #5316

    kir
    Хранитель

    Stranger писал(а):

    Так что to be or not to be решать должен архитектор.

    Stranger, а что может решить архитектор, который ни бельмеса не петрит в вопросе?

  • #5319

    Eldar Zhensykbaev
    Участник

    Stranger, а что может решить архитектор, который ни бельмеса не петрит в вопросе?

    Тогда возникает вопрос «А вообще, это архитектор???» 😉

  • #5321

    kir
    Хранитель

    Stranger писал(а):

    [quote] Stranger, а что может решить архитектор, который ни бельмеса не петрит в вопросе?

    Тогда возникает вопрос «А вообще, это архитектор???» ;)[/quote]
    Ну.

    Вот такие вот архитекторы.

    «Антимультипассинговые».

  • #5325

    kir
    Хранитель

    Пользователь pisch заблокирован на 1 месяц. Основание — нарушение правил форума (раздел II пункт 2).
    http://www.aixportal.ru/component/option,com_fireboard/Itemid,164/func,rules/
    Решение окончательное и обжалованию не подлежит.

  • #5326

    Sever
    Участник

    Stranger писал(а):

    [quote] Значит я буду первым, после IBM

    Рекомендую почитать redbook этого направления, а не следовать синтетическим тестам. Ну, разве что стоит задача получить сферического коня в вакууме (т.е. повторить тест)

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

    Управление комплексом входит в задачи тестирование производительности?
    А управление и мониторинг имеет отношение к Вашим задачам? Или только запуск и пусть все работает как захочет?

    Проблему нельзя будет забулшитить в стиле “это не к нам, это вам к производителю этой железки”

    При покупке тех же директоров через IBM (будет это Cisco MDS или Brocade), поддержкой первого и второго уровней занимается IBM Support. Вся эскалация к вендору производится IBM.

    Я так и не услышал аргументов в пользу необходимости наличия коммутаторов для очень большого сервера и нескольких DSок, которые установлены локально и используются только этим сервером. Тезис, что “так принято” для меня не является аргументом.

    «Так принято» вроде я нигде не говорил. В первую очередь дизайн диктуется задачей. И исходя из этого, есть best practices (да, «так принято в мире, поддерживается всеми производителями и настоятельно рекомендуется к использованию»).
    Учитываются соображения то поддержке работоспособности всего комплекса, масштабируемости, возможности расширения, стоимости поддержки (включая расходы на администраторов всех видов), время troubleshooting, стоимость простоя (особенно из–за долгого поиска неисправности).
    Я не рекомендую ставить директора просто из–за того, что мне так хочется. Уже не один раз наличие SAN спасало работу всей системы.

    Так что to be or not to be решать должен архитектор.[/quote]

    Уважаемый Stranger
    Я несколько раз перечитал ваши фразы и совершенно не понял, что вы хотите ими сказать.

  • #5327

    Eldar Zhensykbaev
    Участник

    Я несколько раз перечитал ваши фразы и совершенно не понял, что вы хотите ими сказать.

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

    Раз уж используете IBM, то прямая дорога сюда: http://www.redbooks.ibm.com/abstracts/sg245758.html?Open
    Ну и сюда заодно: http://www.redbooks.ibm.com/abstracts/sg246419.html?Open

    DAS имеет смысл для System Z. И то, очень часто строят SAN и для таких подключений.

    Ну и можно заглянуть сюда напоследок: http://www.cisco.com/en/US/netsol/ns747/networking_solutions_sub_program_home.html
    (не считайте это рекламой)

  • #5328

    Sever
    Участник

    Спасибо.

  • #5345

    MAXiK
    Участник

    Stranger писал(а):DAS имеет смысл для System Z. И то, очень часто строят SAN и для таких подключений.[/quote]
    И для i 🙂
    Насколько я понимаю именно i-ичную архитектуру Sever и пытается натянуть на DS-ки.

  • #5346

    Eldar Zhensykbaev
    Участник

    Насколько я понимаю именно i-ичную архитектуру Sever и пытается натянуть на DS-ки

    iSeries не подразумевает использование одного линка на контроллер. Все–таки отказоустойчивость свойственна всем дизайнам, особенно на high-end оборудовании

  • #5347

    MAXiK
    Участник

    Stranger писал(а):

    [quote] Насколько я понимаю именно i-ичную архитектуру Sever и пытается натянуть на DS-ки

    iSeries не подразумевает использование одного линка на контроллер. Все–таки отказоустойчивость свойственна всем дизайнам, особенно на high-end оборудовании[/quote]Вплоть до версии ОС 5.2 она не умела параллелить на несколько линков. Вот тебе и хай-энд 🙂 Она вообще вся заточена на использование внутренних ресурсов.

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