В нашей storage-инфраструктуре было две проблемы. Во-первых, это 960 «Single initiator — Single target» зон на SAN, что усложняло администрирование SAN-сети. А во-вторых, несбалансированная нагрузка на директорах EMC VPLEX. Благодаря внедрению Peer zoning мы уменьшили количество зон в 120 раз, вдвое сэкономили время инженеров и получили более-менее равномерную загрузку директоров EMC VPLEX. Далее расскажу, как мы это сделали.

В инфраструктуре заказчика:

  • по одному EMC VPLEX в каждом дата-центре в конфигурации Metro;
  • суммарно 120 серверов, подключенных к ним;
  • две SAN-фабрики, в каждой из которых по два SAN-свитча Brocade.

На схеме это выглядит так:



Схема упрощенная — на ней показан только один сервер и его подключение к фабрикам (остальные сервера подключены аналогично), указаны только front-end (FE) порты от EMC VPLEX, не показан back-end storage и не показаны engines и directors EMC VPLEX.

В текущей конфигурации:

  • каждый EMC VPLEX имеет 4 engines
  • каждый engine имеет по два директора
  • каждый директор по 4 FE-порта.

Итого 4*2*4 = 32 FE порта, 16 из которых для отказоустойчивости подключены к Fabric1 и другие 16 портов — к Fabric2.

Каждый сервер имеет по два HBA: HBA0 и HBA1. Подключение к фабрикам аналогичное — для отказоустойчивости HBA0 подключен к Fabric1, HBA1 — к Fabric2.

По best practices EMC VPLEX каждая HBA сервера имеет зону на один FE-порт каждого из четырех engines. Когда мы использовали Single initiator zoning, то это было 4 зоны на одну фабрику, всего 8 путей через две фабрики для одного сервера.

На рисунке это выглядит так:



Еще год назад мы использовали Single initiator zoning и делали зонинг по принципу «Single initiator — Single target» в каждой зоне. И так, если посчитать, на одну фабрику приходилось 4 зоны*120 серверов = 480 зон, а на две фабрики, соответственно, 8 зон*120 серверов = 960 зон. Внедрение Peer Zoning помогло сократить количество зон в 120(!) раз, уменьшив их до 8 — по 4 peer-зоны в каждой фабрике.

В отличие от Single initiator zoning, Peer-зона состоит из principal (target) и members (initiators). Members внутри одной Peer-зоны взаимодействуют только с principal. При этом каждый member не видит другого member. Так же и principal: один principal не взаимодействует с другим principal.

Мы объединили FE-порты VPLEX по группам и создали по 4 Peer-зоны в каждой фабрике.

Как мы это реализовали

Чтобы соблюсти все EMC best practices, сделали это следующим образом.
В зону PEER_VPLEX_Fabric1_Group1 в качестве principal вошли порты VPLEX:

Engine1_directorB_FC01
Engine2_directorA_FC01
Engine3_directorB_FC01
Engine4_directorA_FC01

В зону PEER_VPLEX_Fabric1_Group2 в качестве principal вошли порты VPLEX:

Engine1_directorA_FC01
Engine2_directorB_FC01
Engine3_directorA_FC01
Engine4_directorB_FC01

В зону PEER_VPLEX_Fabric2_Group1 в качестве principal вошли порты VPLEX:

Engine1_directorA_FC00
Engine2_directorB_FC00
Engine3_directorA_FC00
Engine4_directorB_FC00

И так далее.

Схематично:



Сейчас при добавлении новых серверов в SAN достаточно добавить WWN новых серверов в существующие Peer-зоны.

В результате внедрения Peer zoning значительно упростилось администрирование зон SAN-сети, что, как минимум, вдвое сэкономило время инженеров.

И, кроме того, удалось добиться выравнивания нагрузки directors.
Ниже графики по Current Utilization, взятые с EMC ViPR SRM каждого из directors обоих EMC VPLEX cluster-1 и cluster-2.

Желтым отмечена дата начала поэтапного внедрения PeerZoning на front-end.



Комментарии (0)