Назад | Перейти на главную страницу

Типичная наработка на отказ SAN

Мы используем SAN в проекте на работе, и есть небольшие споры по поводу того факта, что технически это единственная точка отказа. Кажется, ни у кого нет достоверных данных.

Рассматриваемый SAN представляет собой единый физический блок, но с внутренними резервными компонентами (извините, не уверен3, какой уровень RAID у него есть, но я могу выяснить).

Какая типичная наработка на отказ для сети SAN? Премьер-министр внес это в реестр рисков проектов как «Довольно часто» - я никогда не слышал о сбоях SAN, но у меня нет статистики, чтобы показать, насколько это вероятно.

У кого-нибудь есть полезная информация?

На самом деле это вообще не распространено, на самом деле я бы сказал, что это почти так же часто, как потеря питания для всей комнаты - как если бы они были правильно настроены и обслуживались, потеря мощности - единственный реальный способ потерять весь блок SAN.

Тем не менее, вам необходимо убедиться, что они питаются от двух отдельных ИБП, имеют двойные контроллеры, двойные переключатели, разнонаправленные волокна и что вы планируете компоновку полки / массива с учетом потери всей полки. Если вы это сделаете, то вы будете защищены настолько, насколько это возможно без второго сайта.

Не зная точного рассматриваемого SAN, его настройки и управления, любой ответ на этот вопрос является предположением. Я говорю это по 2 причинам:

  1. Некоторые сети хранения данных лучше других. У нас есть старинный EMC CX500, который выпускается 7 лет без единого сбоя. У нас есть Dell MD3000i, у которого постоянные проблемы. Ты получаешь то, за что платишь.

  2. Даже самая лучшая сеть SAN при плохом управлении или настройке может иметь плохое время безотказной работы. Я видел, как глупый администратор дважды за месяц приводил к отказу EMC Symmetrix за 2 миллиона долларов. До того, как мы наняли его, он работал без проблем почти четыре года подряд.

С начала года у нас были всевозможные проблемы, вплоть до того, что «следующий доступный период обслуживания» стал эвфемизмом для отказа SAN. Если прислушаться к продажам, они все твердые. На практике у вас нет опыта, чтобы мучительно тестировать SAN перед запуском в производство, поэтому на долю стрелы судьбы приходится обнаруживать проблемы с конфигурацией в периоды высокого спроса.

Невероятно сложное программное обеспечение SAN или сбой конфигурации - неизвестная величина по сравнению с реальными дисками и другим оборудованием. В конечном итоге это означает, что вы можете добавить столько физического резервирования, сколько захотите, но поскольку все это работает с одним и тем же сломанным программным обеспечением, у вас все еще есть единственная точка отказа.

Тем не менее, похоже, что мы работаем намного более плавно, поскольку мы сняли все это для исправления прошивки. Сводный отчет о нашем ремонте SAN заставляет меня беспокоиться, что слишком много магических размышлений по-прежнему приписывают SAN.

Как отмечали другие, неправильно настроенная и специфицированная серверная часть хранилища (избыточные контроллеры, питание, переключатели и т.д.) не выходит из строя. Я серьезно попрошу премьер-министра подробно обсудить мысли, лежащие в основе оценки этого риска как общего.

Технически всегда стоит задокументировать «отказ единой точки» как часть оценки риска, но предстоит серьезное обсуждение того, представляет ли полностью избыточное хранилище в конфигурации высокой доступности «единую точку отказа». Это может или не может, в зависимости от вашей организации и приложения. Если это единая точка отказа, также стоит обсудить сценарии отказа для потери обслуживания всего центра обработки данных (поскольку вряд ли произойдет полный отказ избыточной сети хранения данных высокой доступности, которая оставила бы все остальное доступным).

Работа с такими сценариями обходится довольно дорого ... для начала, избыточные центры обработки данных и такие вещи, как географически растянутые структуры, несколько полностью избыточных SAN, «репликация в реальном времени» для части хранилища. Сценарии и приложения, требующие этих вещей, не так уж и распространены.

Только мой личный опыт: я сталкивался с ошибками прошивки и контроллера, которые вызывают отдельные проблемы. В одном редком случае я даже столкнулся с ошибкой, из-за которой один контроллер в паре активный-активный делал дамп и запускал аварийное переключение. Это не привело к простоям.

Я слышал о кошмарных сценариях, таких как разделение мозга контроллера или что-то еще, которые приводят к полному краху массива, но это редко и никогда не бывает окончательно, что это не из-за человеческой ошибки или неправильной конфигурации. (человеческий фактор и неправильная конфигурация - огромные проблемы ... Я не хочу преуменьшать их значение ... но они не являются "спофами" в том же смысле, что и отдельная SAN.)