Комментарии 4
Интересный опыт. Но не совсем понятно как именно peer zoning повлиял на выравнивание нагрузки на директора VPLEX. Не пробовали с этим разобраться? В плане найти логическое объяснение. Просто по описанию из статьи формально для серверов и HBA в них ничего не изменилось.
Хороший вопрос, спасибо. По сути, да, все верно, Peer zoning как таковой тут не причем.
Когда у заказчика еще был подход зонирования «Single initiator — Single target», FE-порты отдавались серверам в разнобой. Кроме того, engines изначально было по два в каждом сайте. Позже добавили еще по два. Новые сервера подключали к новым engines. Получается, что уже и VPLEX best practices не соблюдался, при котором, каждый порт сервера должен приходить на один из директоров каждого engine. Проще говоря, был бардак.
С внедрением Peer zoning мы применили более системный подход, что и позволило сбалансировать нагрузку и соответствовать VPLEX best practices.
Когда у заказчика еще был подход зонирования «Single initiator — Single target», FE-порты отдавались серверам в разнобой. Кроме того, engines изначально было по два в каждом сайте. Позже добавили еще по два. Новые сервера подключали к новым engines. Получается, что уже и VPLEX best practices не соблюдался, при котором, каждый порт сервера должен приходить на один из директоров каждого engine. Проще говоря, был бардак.
С внедрением Peer zoning мы применили более системный подход, что и позволило сбалансировать нагрузку и соответствовать VPLEX best practices.
Вот так уже понятнее. А то из самой статьи создается впечатление некой магии при применении Peer Zoning :).
Кстати, а на backend-е VPLEX до СХД какой тип зонинга используется?
На back-end используется традиционный «Single initiator — Single target» зонинг.
Он настраивался изначально правильно при подключении engines и затем при добавлении новых engines в каждом сайте. Peer zoning решили там не делать, так как зонинг на back-end менять не приходится: настроили правильно один раз с соблюдением лучших практик и больше он не меняется.
Вывод команды проверки back-end подключения на обоих кластерах VPLEX (при правильной настройке все должно быть по нулям):
Он настраивался изначально правильно при подключении engines и затем при добавлении новых engines в каждом сайте. Peer zoning решили там не делать, так как зонинг на back-end менять не приходится: настроили правильно один раз с соблюдением лучших практик и больше он не меняется.
Вывод команды проверки back-end подключения на обоих кластерах VPLEX (при правильной настройке все должно быть по нулям):
VPlexcli:/> connectivity validate-be
Cluster cluster-1
0 storage-volumes which are dead or unreachable.
0 storage-volumes which do not meet the high availability requirement for storage volume paths.
0 storage-volumes which are not visible from all directors.
0 storage-volumes which have more than supported (4) active paths from same director.
Cluster cluster-2
0 storage-volumes which are dead or unreachable.
0 storage-volumes which do not meet the high availability requirement for storage volume paths.
0 storage-volumes which are not visible from all directors.
0 storage-volumes which have more than supported (4) active paths from same director.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как Peer Zoning упростил нам жизнь и помог сбалансировать нагрузку EMC VPLEX