Сегодня – вольный перевод заметки про V3700 известного блоггера из IBM - Barry Whyte.
Часто можно слышать вопрос, является ли система V3700 настоящей active/active или active/passive? Подоплека вопроса в том, что в свойствах логического диска (volume, vdisk, LUN) всегда указан “preferred” контроллер:
Однако, этот параметр нужен вовсе не для того чтобы указать единственный “активный” контроллер, а для оптимизации нагрузки на систему (распределению между контроллерами). При создании нескольких томов они чередующимся образом распределяются между контроллерами, а дальше в дело вступает драйвер multipath на уровне сервера. Если драйвер на сервере поддерживает ALUA, то такое указание “активного” контроллера позволит, при наличии нескольких томов, распределить нагрузку между контроллерами. Трафик “от” и “к” каждому конкретному тому будет идти через его “preferred” контроллер, а если томов много, то оба контроллера будут загружены примерно одинаково (конечно в отдельных случаях может потребоваться ручное перераспределение). Если же драйвер не поддерживает ALUA, то будет использоваться режим round-robin (чередование путей) и все контроллеры также будут равномерно загружены. В этом случае, (с точки зрения сервера) нет разницы, какой контроллер “preferred” – оба будут получать трафик со стороны хоста.
Для всех СХД IBM, построенных на базе микрокода SVC (SVC, V7000, V3700, V3500) реализовано такое поведение при получении запроса от хоста:
- запросы на чтение обрабатываются тем контроллером, на который пришел запрос;
- успешность запроса на запись подтверждается (ACK) тем контроллером, на который пришел запрос. Разумеется, это происходит только после зеркалирования записываемого блока в кэш второго контроллера. Затем уже “preferred” контроллер осуществляет непосредственный сброс кэша на диски.
На основании вышесказанного можно с полной уверенностью утверждать, что все перечисленные СХД являются настоящими active/active СХД.
Андрей, в приведенной заметке вопрос стоял является ли V3700 системой "symmetric active active". А дальше начинаются спекуляции на эту тему, хотя отсылка на протокол ALUA (Asymmetric Logical Unit Access), однозначно, нам говорит какого типа active/active является эта система.
ОтветитьУдалитьИ без этого уточнения информация явно не полная )))
Так в том-то и дело, что сама по себе поддержка ALUA не говорит вообще ни о чем! EMC Symmetrix прекрасно поддерживает ALUA и теперь это active/passive система? На многих active/active СХД поддерживается ALUA и это позволяет _управлять_ трафиком. А вот для active/passive систем ALUA нужен уже для обеспечения производительности - в них доступ к данным через "запасной" контроллер будет значительно медленнее, чем через активный.
УдалитьТо, что Symmetrix использует протокол ALUA, для разделения ввода-вывода различных приложений, чтобы исключить их взаимное влияние, это здорово. А вот SVC-like системы используют ALUA как раз для перенаправления трафика по оптимальному пути на контроллер-владелец LUN'а, как вы и писали )))
УдалитьИли может быть еще как использует и это тема будущих постов?
Если получится найти более подробную информацию, то конечно тема для других постов! :)
УдалитьЕсли не получится, то пока отталкиваемся от того, что сейчас в связке SVC и VMware IBM рекомендует использовать RR, а он пробегает по всем путям (к обеим узлам). Маловероятно, что сознательно рекомендуют зло.
А у SVC-подобных СХД доступ через noprefered контроллер не медленее?
ОтветитьУдалитьВообще говоря, если верить тому что я до сих пор видел, запросы на _чтение_ должны обрабатываться немного медленнее (так как кэширование чтения происходит на preferred узле). Насколько велико это "немного" и насколько это актуально именно сейчас - я не могу дать 100% верную информацию. Есть подозрение, что в настоящее время концепция немного иная, поэтому продолжаем изучение вопроса...
УдалитьЭто я к тому, что СХД active-passive и есть, просто добавлена возможность доступа к луну через noprefered controller через интерконнект м-ду ними (а это сейчас могут буквально все). Это типа и есть ALUA, но к настоящему active-active (соотв. SAA) это никакого отношения не имеет.
ОтветитьУдалитьЕсли получится найти более подробную информацию, то конечно тема для других постов! :)
ОтветитьУдалитьЕсли не получится, то пока отталкиваемся от того, что сейчас в связке SVC и VMware IBM рекомендует использовать RR, а он пробегает по всем путям (к обеим узлам). Маловероятно, что сознательно рекомендуют зло.
RR пробегает не по всем путям, а по всем optimized путям в случае использования ALUA. И опять же это работает в случае любой СХД с ALUA :)
Насколько я помню, для сторвайза RR сейчас пробегает по всем путям.
УдалитьНе бегает по всем путям.
Удалитьhttp://pic.dhe.ibm.com/infocenter/storwize/ic/index.jsp?topic=%2Fcom.ibm.storwize.v7000.doc%2Fsvc_w2kmultipathovr_21osvf.html
"VMware multipathing software performs static load balancing for I/O, based upon a host setting that defines the preferred path for a given volume."
Ни под VMware, ни на Windows - "SDDDSM uses a load-balancing policy that attempts to equalize the load across all preferred paths." там же
Да, SDDD отправляет данные по активному пути, все верно.
УдалитьПо варе ссылка не та - правильная здесь: https://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sto_wp_vmware_vsphere_best_practices/lc=en_ALL_ZZ
Отчего же ссылка на информационный портал по продукту IBM Storwize V7000 не правильная, тем более дата последней редакции Nov 9 2012, на сентябрьский документ правильная? ;-))
УдалитьМожет быть вы имели ввиду ссылку на сам раздел, то я приведу его точно: http://pic.dhe.ibm.com/infocenter/storwize/ic/topic/com.ibm.storwize.v7000.doc/svc_vmwmultivmw_21swt4.html
Если говорить формально, то ссылка конечно правильная, но содержит она информацию о дефолтных настройках в VMware, а там вовсе даже не RR. Поэтому в данном конкретном случае она как раз и не совсем верна.
УдалитьЗаметка выше - это только "вольный перевод". Когда у меня будет свободное время для того чтобы проверить и выразить в цифрах, насколько один путь длиннее другого, я обязательно это сделаю.
Согласен.
УдалитьНаглядное тестирование и сравнение было бы просто замечательно. А если еще и для FC и для iSCSI протоколов....)))
Не пробегает. Ни на варе ни в какой либо другой ОС, при грамотной настройке мультипассинга. Сомневаетесь? А вы проверьте чего гадать то :)
ОтветитьУдалитьХотя вру, к варе не подключал. Но за линукс,AIX и венду ручаюсь :)
ОтветитьУдалитьУже были публикации на этот счет
Удалитьhttp://www.vm4.ru/2012/01/storwize-v7000-esx-50-iscsi-lun-alua.html
iSCSI это отдельная песня.
УдалитьА в статье то и не было разделения для iSCSI это или для FC ))
УдалитьЗа DS3500 могу сказать, что ISCSI работает точно так же, как вы пишете, префферед контроллер для каждого луна.
ОтветитьУдалить