В нашей 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.
Автор: BullatN
