Горячая замена FC свичей

Технологии постороения кластеров (вычислительных и отказоустойчивых), настройка терминал серверов,
SAN , NAS, FibreChannel, Infiniband

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
denge
Junior member
Сообщения: 10
Зарегистрирован: 24 июл 2007, 06:01
Откуда: Россия, Красноярск

Горячая замена FC свичей

Сообщение denge » 04 окт 2007, 06:26

Здравствуйте.
Возник вопрос по горячей замене свичей.

Есть 2 сконфигурированных системы.
Первая:
1) DS4500
2) 2 свича Brocade (8 портовых, 2 Gb)
3) Сервер IBM c ОС AIX, работающий с дисками через оба свича
4) Сервер IBM с ОС Linux, работающий с дисками через оба свича
5) Сервер IBM с ОС Windows 2003 Server, работающий  с дисками через оба свича
Вторая:
1) DS4700
2) 2 свича Brocade (16 портовых, 4 GB)
3) Сервер IBM с ОС Linux, работающий с дисками через оба свича

Задача:
Объединить 2 системы в одну, путем замены 8 портовых свичей, на 16 портовые.

Действия:
На сколько я понимаю, такая замена должна без проблем проходить на горячую. Собственно, отключаем первый 8 портовый свич, в Storage Managere видим, что все кто работал через него, переключились на второй (данный пошли по другому контроллеру), так и должно было быть.
Аналогично, отключаем первый 16 портовый свич, та же ситуация, всё в норме.
Далее, перетыкаем все провода из 8 портового в 16 портовый и включаем его. Через некоторое время, видим что сигнал есть, часть портов работает на 4 gb, часть на 2 gb, в зависимости от FC карт в серверах, всё в норме.

Однако, AIX сервера, не хотят работать через 16 портовый свич(тобишь другой контроллер, при переключении в SM cliente).

То же самое и с Linux сервером.

Если выполнить на Linux команду mppUtil -a можно увидить обе системы хранения.
Логический диск дан только на системе DS4500.
Выполняем комманду для неё, mppUtil -g0
----------------
Hostname    = LinuxServer
Domainname  = N/A
Time        = GMT 10/04/2007 02:16:21

MPP Information:
----------------
     ModuleName: DS4500                                   SingleController: N
VirtualTargetID: 0x000                                       ScanTriggered: N
    ObjectCount: 0x000                                          AVTEnabled: Y
            WWN: ----------------------------               RestoreCfg: N
   ModuleHandle: none                                        Page2CSubPage: Y
FirmwareVersion: 6.12.3.0
  ScanTaskState: 0x00000000


Controller 'A' Status:
-----------------------
ControllerHandle: none                                    ControllerPresent: Y
   UTMLunExists: N                                                  Failed: N
  NumberOfPaths: 1                                          FailoverInProg: N
                                                               ServiceMode: N

   Path #1
   ---------
DirectoryVertex: present                                           Present: Y
      PathState: OPTIMAL_CHECKING
hostId: 3, targetId: 3, channelId: 0


Controller 'B' Status:
-----------------------
ControllerHandle: none                                    ControllerPresent: Y
   UTMLunExists: N                                                  Failed: N
  NumberOfPaths: 1                                          FailoverInProg: N
                                                               ServiceMode: N

   Path #1
   ---------
DirectoryVertex: present                                           Present: Y
      PathState: OPTIMAL
hostId: 2, targetId: 1, channelId: 0



Lun Information
---------------
   Lun #0 - WWN: ------------------------------------
   ----------------
      LunObject: present                                 CurrentOwningPath: B
 RemoveEligible: N                                          BootOwningPath: B
  NotConfigured: N                                           PreferredPath: B
       DevState: OPTIMAL                                   ReportedPresent: Y
                                                           ReportedMissing: N
                                                     NeedsReservationCheck: N
                                                                 TASBitSet: N
                                                                  NotReady: N
                                                                      Busy: N
                                                                 Quiescent: N

   Controller 'A' Path
   --------------------
  NumLunObjects: 1                                         RoundRobinIndex: 1
        Path #1: LunPathDevice: present
                       IoCount: 0
                      DevState: OPTIMAL
                   RemoveState: 0x0  StartState: 0x1  PowerState: 0x0

   Controller 'B' Path
   --------------------
  NumLunObjects: 1                                         RoundRobinIndex: 1
        Path #1: LunPathDevice: present
                       IoCount: 0
                      DevState: OPTIMAL
                   RemoveState: 0x0  StartState: 0x1  PowerState: 0x0

----------------
Оба контроллера работают.
Делали mppBusRescan - диск видим.
Но, работать через второй контроллер(16 портовый свич) он отказывается.

Подскажите пожалуйста, что я не так делаю ?

Я начинаю грешить на взаимодействие между свичами.
Никакого зонирования на них нет.
На 8 портовом версия ОС - v5.0.1d
На 16 портовом версия ОС - v5.1.0b
Могут версии ОС как то влиять на работу ?

Svi
member
Сообщения: 30
Зарегистрирован: 19 окт 2006, 13:08
Откуда: MOSCOW

Сообщение Svi » 04 окт 2007, 12:47

firm свичей скорее всего нипричём, при послеовательном апгрейде фабрики вместе жили фёрмы от 5.0.1 и до 5.3 никаких глюков небыло.
"Делали mppBusRescan - диск видим.
Но, работать через второй контроллер(16 портовый свич) он отказывается."
что значит отказывается работать ?
ИМХо,для Линукса(и скорее всего Аикса) у дисков сменились хардверные пути, поэтому и работать нихочет.

denge
Junior member
Сообщения: 10
Зарегистрирован: 24 июл 2007, 06:01
Откуда: Россия, Красноярск

Сообщение denge » 04 окт 2007, 13:18

Svi, переключаем в SM cliente, логический диск с одного контроллера на другой. Запускаем любую задачу на диске из под Linux (либо AIX), ждем таймаут, после чего происходит автаматическое переключение на предыдущий контроллер и задача начинает выполняться. Если, во время выполнения задачи, переключить на лог. диск на другой контроллер, выполнение приостанавливается, после 20 сек. таймаута, возвращаемся на старый контроллер.

Svi
member
Сообщения: 30
Зарегистрирован: 19 окт 2006, 13:08
Откуда: MOSCOW

Сообщение Svi » 04 окт 2007, 13:49

похоже дело как раз в Storage Managere (думаю как раз он за мультипасинг отвечает), я к сожалению с IBM не общался :(

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 04 окт 2007, 18:26

denge
Есть 2 сконфигурированных системы.
Т.е. до тех пор, пока никакое переключение не делалось, Вы можете спокойно отключить любой из коммутаторов и все нормально наботает на Linux и AIX?

denge
Junior member
Сообщения: 10
Зарегистрирован: 24 июл 2007, 06:01
Откуда: Россия, Красноярск

Сообщение denge » 05 окт 2007, 05:00

Да, при отключении, автоматически переключались на доступный контроллер и продолжали работать.

ITER
Advanced member
Сообщения: 306
Зарегистрирован: 13 июл 2003, 10:01
Откуда: Хабаровский край

Re: Горячая замена FC свичей

Сообщение ITER » 05 окт 2007, 07:00

denge писал(а): Но, работать через второй контроллер(16 портовый свич) он отказывается.

Подскажите пожалуйста, что я не так делаю ?

Я начинаю грешить на взаимодействие между свичами.
Никакого зонирования на них нет.
На 8 портовом версия ОС - v5.0.1d
На 16 портовом версия ОС - v5.1.0b
Могут версии ОС как то влиять на работу ?
В каком смысле никакого зонирования нет? Свитч работает как хаб что ли? Может на 16 портовом как раз таки надо зоны настроить  :wink:

denge
Junior member
Сообщения: 10
Зарегистрирован: 24 июл 2007, 06:01
Откуда: Россия, Красноярск

Сообщение denge » 05 окт 2007, 07:53

ITER, ни на 8 портовых, ни на 16 зонирование не настраивалось ранее.

Аватара пользователя
CrazyFrog
Advanced member
Сообщения: 210
Зарегистрирован: 16 авг 2005, 23:09
Откуда: Мурманск

Сообщение CrazyFrog » 05 окт 2007, 19:15

Это кривой IBMский мультипасинг (RDAC) во всём виноват. Боролся однажды с таким, при замене коммутатора он ни за что не хочет использовать новый путь. Не смотря ни на что: fcping есть, в scli от qlogic путь есть, диски по новому пути видны в ОС (dd проходит), но RDAC не хочет.

Тогда пришлось перезагружать хосты :-/

denge
Junior member
Сообщения: 10
Зарегистрирован: 24 июл 2007, 06:01
Откуда: Россия, Красноярск

Сообщение denge » 06 окт 2007, 07:27

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

Допустим, остановлю сервера и заменю второй 8портовый свич на 16 портовый, по новым путям точно данные пойдут ?

В теории, всё должно ведь на горячую меняться, что бы исключить простои, а на практике что-то не получается ((

К тому же, страшно ещё то, как бы не произошла потеря данных на массиве, после переключения. ((

Аватара пользователя
CrazyFrog
Advanced member
Сообщения: 210
Зарегистрирован: 16 авг 2005, 23:09
Откуда: Мурманск

Сообщение CrazyFrog » 11 окт 2007, 19:57

Если я правильно думаю, то RDAC коробит от смены FCID. Можно попробовать поменять Domain ID в коммутаторах и вставить устройства в порты с такими же номерами, тогда fcid должен остаться прежним и RDAC узнает новый путь. из CLI: switchdisable, config, switchenable.

У Cisco MDS как раз для такого го-нософта есть полезная фича: задание fcid вручную, но с brocade так неполучится.

Ответить

Вернуться в «Кластеры, Аппаратная часть»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 9 гостей