Наверняка вы сталкивались с ситуацией, когда операции чтения-записи забивают полностью канал виртуального адаптера и сервер находится в жутком ступоре, практически не реагируя на свое существование. Такая ситуация может возникнуть, например, при проблемах на хранилище.
"Виноват" в этой ситуации фибр-ченел адаптер и так называемый мультипассинг.
В "бест практис" IBM рекомендует настраивать использование нескольких путей на канал.
Посмотрим какие варианты настройки существуют в системе при работе с хранилищем (SAN, EVA и т.д.), а именно использование алгоритма работы.
#lsattr -El hdisk0
В моем случае, нет мультипасинга и алгоритм работы диска "fail_over". Используя этот алгоритм, все операции чтения-записи идут по одному пути ( управляется этим модулем - path control module (PCM)), и в случае сбоя операции пойдут по другому пути, который был определен в настройках канала VSCSI (virtual SCSI). Данный алгоритм в основном используется на ВИОС-сервере, как не требующий особой настройки, но может быть использован и на клиентской партиции, нет проблем.
Следующий тип, algorithm = round_robin. Перед его использованием убедитесь, что хранилище может использовать несколько путей для работы с клиентской партицией. У меня был случай, когда "старая" Ева выделяла 2 канала для использования, а с аикса все операции шли через один путь, хотя был включен алгоритм round_robin. Мучились, искали настройки, проверяли, перегружали, никак не заводилось. Оказывается ограничение Евы.
С помощью данного алгоритма все операции чтения-записи идут через все включенные пути к диску. Балансировка нагрузки на диски может быть разделена с помощью атрибута
path_priority, который задается для каждого диска в отдельности. В случае сбоя или отключения пути, происходит пересчет приоритетов и все операции делятся поровну между оставшимися каналами.
algorithm = shortest_queue
Данный алгоритм является самым новым и он очень похож на round_robin при небольшой нагрузке на каналы. Когда нагрузка возрастает алгоритм перенаправляет поток на тот канал, который менее загружен. Т.е. используется тот путь, который не испытывает серьезных затруднений в работе. Атрибут path_priority игнорируется.
С помощью команды lspath вы всегда сможете посмотреть через какие каналы у вас настроено соединение диска с хранилищем (LUN).
#lspath -l hdisk1
Комментарии приветствуются. Успехов!
"Виноват" в этой ситуации фибр-ченел адаптер и так называемый мультипассинг.
В "бест практис" IBM рекомендует настраивать использование нескольких путей на канал.
Посмотрим какие варианты настройки существуют в системе при работе с хранилищем (SAN, EVA и т.д.), а именно использование алгоритма работы.
#lsattr -El hdisk0
В моем случае, нет мультипасинга и алгоритм работы диска "fail_over". Используя этот алгоритм, все операции чтения-записи идут по одному пути ( управляется этим модулем - path control module (PCM)), и в случае сбоя операции пойдут по другому пути, который был определен в настройках канала VSCSI (virtual SCSI). Данный алгоритм в основном используется на ВИОС-сервере, как не требующий особой настройки, но может быть использован и на клиентской партиции, нет проблем.
Следующий тип, algorithm = round_robin. Перед его использованием убедитесь, что хранилище может использовать несколько путей для работы с клиентской партицией. У меня был случай, когда "старая" Ева выделяла 2 канала для использования, а с аикса все операции шли через один путь, хотя был включен алгоритм round_robin. Мучились, искали настройки, проверяли, перегружали, никак не заводилось. Оказывается ограничение Евы.
С помощью данного алгоритма все операции чтения-записи идут через все включенные пути к диску. Балансировка нагрузки на диски может быть разделена с помощью атрибута
path_priority, который задается для каждого диска в отдельности. В случае сбоя или отключения пути, происходит пересчет приоритетов и все операции делятся поровну между оставшимися каналами.
algorithm = shortest_queue
Данный алгоритм является самым новым и он очень похож на round_robin при небольшой нагрузке на каналы. Когда нагрузка возрастает алгоритм перенаправляет поток на тот канал, который менее загружен. Т.е. используется тот путь, который не испытывает серьезных затруднений в работе. Атрибут path_priority игнорируется.
С помощью команды lspath вы всегда сможете посмотреть через какие каналы у вас настроено соединение диска с хранилищем (LUN).
#lspath -l hdisk1
Комментарии приветствуются. Успехов!
ДУ! подскажите пжлст по поводу vio-сервера, как более менее правильно раздавать диски партициям?
ReplyDelete1) расшарить FC карточки партициям, потом зонингом пораздавать напрямую(на СХД создать хоста(партиция)
2) дать VIO-серверу, потом от него партициям?
1. Если вы расширите карты под партиции, то только эти партиции будут их использовать.
ReplyDelete2. Этот вариант предпочтителен, если на вашем сервере лпаров больще чем FC-карт.
в данный момент, у меня есть ВИО сервер на котором сидит 8 партиций. и каждой партиции я дал по 2 виртуальные карточки FC.
Deleteвыписка 1
Виртуальный Fibre Channel с физическими адаптерами, поддерживающими порты NPIV, дает возможность присваивать эти порты нескольким логическим разделам, благодаря чему разделы могут напрямую подключаться к запоминающим устройствам в сети хранения данных SAN. Для просмотра логических разделов, использующих указанный физический порт NIPV,
выписка 2
Показать соединения с разделами виртуального Fibre Channel: fcs0 Справка
В таблице перечислены все логические разделы, подключенные к выбранному физическому порту.
Вы можете указать, подключен ли раздел к заданному физическому порту, с помощью задачи Показать/Изменить разделы -> Свойства раздела (вкладка Память) для логического раздела.
Доступные соединения: 56
делалось так, чтобы на партициях крутить БД. сильно много производительности заберет на себя прослойка ВИО-сервера если делать 2-м вариантом? удобней ли 2 способ?
DeleteВсе верно вы делаете. Прослойка ВИО-сервера практически не создает нагрузки, у вас все равно нет других вариантов как сделать:)Поэтому выход только номер2(это Best Practice).
ReplyDeleteвы не могли ткнуть документом бест практис? а то я не знаю как его зовут
ReplyDeleteДокумент называется PowerVM best practice, давайте мыло скину pdf.
ReplyDelete