Сегодня я опишу весьма интересную, на мой взгляд, новую возможность систем хранения данных HP 3PAR. Имя ей Persistent Ports (virtual ports).
Общеизвестный факт, что все производители систем хранения данных в тяжкой конкурентной борьбе вынуждены постоянно добавлять в микрокоды своих систем хранения новые функции и конечно же исправлять ошибки в микрокодах. Администраторам систем хранения данных с определенной периодичностью приходится обновлять микрокоды. Иногда проявляется баг в прошивке, иногда желают получить новый функционал или снять ограничения предыдущей версии, а зачастую просто возникает необходимость миграции, потому что прошивка СХД настолько стара, что вот-вот будет снята с поддержки.
Умеющие руки, всегда решат задачу обновления микрокода, но есть одна проблема – бизнес и его требования, чтобы сервис предоставлялся 24 часа, 7 дней в неделю и 365 дней в году. А простои – только запланированные и короткие, а лучше вообще без них. Коэффициент доступности оборудования с большим количеством девяток после запятой необходимо отрабатывать.
Итак, решая проблему ликвидации необходимости временного простоя оборудования во время сервисных работ по обслуживанию СХД инженеры 3PAR реализовали алгоритм под названием Persistent Ports. Решение подкупает своей гениальной простотой. Но прежде чем описать это решение, вспомним, что необходимо было сделать используя другие СХД для этого. Далее по тексту мы имеем ввиду системы хранения данных подключаемые по протоколу FC и обновления, которые не требуют одновременного перезапуска всех контроллеров системы хранения данных (offline upgrade), т.к. в таком случае полностью избежать даже малейшего простоя просто не возможно. Рассмотрим только случаи, при которых необходим поочередный перезапуск контроллеров СХД.
Классическое решение данной проблемы заключается в использовании программного обеспечения для переключения путей на сервере (multipath software). В этом случае каждый том с системы хранения данных должен быть виден на сервере через несколько независимых путей. Пути должны идти через разные коммутаторы сети хранения данных и разные контроллеры системы хранения.
Эта схема прекрасна и при ответственной реализации чаще всего работает. Программное обеспечение multipath-инга делает своё дело, но порой всё разбивается о суровую реальность. Реальность мне подсказывает, что:
1. Когда я вижу несколько сотен серверов, каждый из которых работает под своей операционной системой, администрируется своим системным администратором с неизвестной мне квалификацией, то желания проверять, у всех ли из них сработает переключение путей во время обновления микрокода систем хранения у меня совсем нет.
2. Мне известны случаи ошибок в работе ПО multipath-инга. Я имею ввиду не ошибки в настройке, допущенные системным администратором, а ошибки в программном обеспечении. К сожалению оба этих случая были обнаружены на продуктивных системах. Производители данного ПО в последствии выпускали патчи, но кому от этого легче. Поэтому лишний раз проверять на продуктивной системе сработает ли данный способ или нет желания мало.
С очередным обновлением 3PAR OS до версии 3.1.2 появилась очень полезная функция Persistent Ports (она же virtual ports). Смысл этой функции заключается в том, что каждому хост-порту контроллера системы хранения назначается партнерский порт на другом контроллере системы хранения. То есть при обновлении микрокода на одном контроллере системы хранения, адреса (wwn) этого контроллера переедут на работающий контроллер. При этом программное обеспечение на хосте не пометит ни один путь до системы хранения как offline, то есть для ПО multipath-инга эта операция прозрачна.
Эта возможность теперь активирована по умолчанию и проявляет себя при перезапуске контроллера системы хранения и при online-обновлении микрокода. Данная возможность реализована при помощи функционала NPIV (N_Port ID Virtualization). Напомню, что NPIV позволяет нескольким узлам сети хранения данных использовать доступ к сети через один физический порт, но при этом каждый имеет свой уникальный адрес (wwn).
Общеизвестный факт, что все производители систем хранения данных в тяжкой конкурентной борьбе вынуждены постоянно добавлять в микрокоды своих систем хранения новые функции и конечно же исправлять ошибки в микрокодах. Администраторам систем хранения данных с определенной периодичностью приходится обновлять микрокоды. Иногда проявляется баг в прошивке, иногда желают получить новый функционал или снять ограничения предыдущей версии, а зачастую просто возникает необходимость миграции, потому что прошивка СХД настолько стара, что вот-вот будет снята с поддержки.
Умеющие руки, всегда решат задачу обновления микрокода, но есть одна проблема – бизнес и его требования, чтобы сервис предоставлялся 24 часа, 7 дней в неделю и 365 дней в году. А простои – только запланированные и короткие, а лучше вообще без них. Коэффициент доступности оборудования с большим количеством девяток после запятой необходимо отрабатывать.
Итак, решая проблему ликвидации необходимости временного простоя оборудования во время сервисных работ по обслуживанию СХД инженеры 3PAR реализовали алгоритм под названием Persistent Ports. Решение подкупает своей гениальной простотой. Но прежде чем описать это решение, вспомним, что необходимо было сделать используя другие СХД для этого. Далее по тексту мы имеем ввиду системы хранения данных подключаемые по протоколу FC и обновления, которые не требуют одновременного перезапуска всех контроллеров системы хранения данных (offline upgrade), т.к. в таком случае полностью избежать даже малейшего простоя просто не возможно. Рассмотрим только случаи, при которых необходим поочередный перезапуск контроллеров СХД.
Классическое решение данной проблемы заключается в использовании программного обеспечения для переключения путей на сервере (multipath software). В этом случае каждый том с системы хранения данных должен быть виден на сервере через несколько независимых путей. Пути должны идти через разные коммутаторы сети хранения данных и разные контроллеры системы хранения.
Эта схема прекрасна и при ответственной реализации чаще всего работает. Программное обеспечение multipath-инга делает своё дело, но порой всё разбивается о суровую реальность. Реальность мне подсказывает, что:
1. Когда я вижу несколько сотен серверов, каждый из которых работает под своей операционной системой, администрируется своим системным администратором с неизвестной мне квалификацией, то желания проверять, у всех ли из них сработает переключение путей во время обновления микрокода систем хранения у меня совсем нет.
2. Мне известны случаи ошибок в работе ПО multipath-инга. Я имею ввиду не ошибки в настройке, допущенные системным администратором, а ошибки в программном обеспечении. К сожалению оба этих случая были обнаружены на продуктивных системах. Производители данного ПО в последствии выпускали патчи, но кому от этого легче. Поэтому лишний раз проверять на продуктивной системе сработает ли данный способ или нет желания мало.
С очередным обновлением 3PAR OS до версии 3.1.2 появилась очень полезная функция Persistent Ports (она же virtual ports). Смысл этой функции заключается в том, что каждому хост-порту контроллера системы хранения назначается партнерский порт на другом контроллере системы хранения. То есть при обновлении микрокода на одном контроллере системы хранения, адреса (wwn) этого контроллера переедут на работающий контроллер. При этом программное обеспечение на хосте не пометит ни один путь до системы хранения как offline, то есть для ПО multipath-инга эта операция прозрачна.
Эта возможность теперь активирована по умолчанию и проявляет себя при перезапуске контроллера системы хранения и при online-обновлении микрокода. Данная возможность реализована при помощи функционала NPIV (N_Port ID Virtualization). Напомню, что NPIV позволяет нескольким узлам сети хранения данных использовать доступ к сети через один физический порт, но при этом каждый имеет свой уникальный адрес (wwn).
