Предотвращение сбоев хранилища

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

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

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

Рисунок 1: Как управлять сбоями хранилища.

Идентифицировать

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

Кроме того, любое событие, препятствующее соблюдению условий соглашения об уровне обслуживания хранилища, также может рассматриваться как форма сбоя хранилища. Например, если ваше соглашение об уровне обслуживания для хранилища уровня 1 гарантирует максимальную задержку в 50 мс, но фактическая задержка увеличилась до 100 мс, это следует рассматривать как сбой хранилища. Или, если ваше SLA для хранилища уровня 2 гарантирует, что запросы на дополнительное хранилище будут обработаны, утверждены и предоставлены в течение семи рабочих дней, но через две недели запрошенное новое хранилище еще не предоставлено, то это также следует считать отказом хранилища..

Другими словами, идея заключается в том, что «сбой» хранилища в основном относится к несоблюдению условий SLA для системы хранения. Такие сбои могут быть вызваны рядом различных вещей, таких как:

• Отказ реального запоминающего устройства, например жесткого диска или карты RAID-контроллера.
• Отказ межсоединения, такого как кабель Fibre Channel, кабель SATA или даже сетевой кабель Ethernet.
• Сбой связанного программного обеспечения, например проблема совместимости, возникающая при обновлении программного обеспечения для управления хранилищем, проблема, связанная с обновлением программного обеспечения, примененным к операционной системе, проблема, возникающая при установке последней версии драйвера устройства, проблема, возникающая при перепрошивке BIOS системы и так далее.
• Человеческая ошибка, например, неправильная настройка функции моментального снимка массива хранения или неправильное завершение кабельного соединения.
• Экологические проблемы, такие как отказ системы кондиционирования воздуха, приводящий к перегреву и выходу из строя системы хранения.
• Проблемы проектирования, такие как невозможность установки достаточного количества кондиционера или электропитания для удовлетворения потребностей стоечного массива хранения.
• Несчастный случай, например случайное удаление файла, папки, тома, LUN, резервной копии или данных конфигурации.

Какие другие возможные типы сбоев хранилища вы можете определить в своей среде? Остановите чтение и подумайте об этом несколько минут.

Избегать

Избегание проблем — лучший способ справиться с ними. Вы избегаете аппаратных сбоев, принимая меры для минимизации их возможных последствий. Ключевыми понятиями здесь являются избыточность, отказоустойчивость, горячие резервы и т. д.

Некоторые из способов, которыми вы можете избежать проблем с вашей инфраструктурой хранения, включают:

• Внедрение отказоустойчивой кластеризации, чтобы при выходе из строя одного узла другой мог взять на себя нагрузку.
• Внедрение избыточности, чтобы в случае сбоя одной технологии или пути данные можно было направить через другую технологию или путь. Двойные контроллеры хранения здесь просто необходимы.
• Внедрение репликации, чтобы горячие данные можно было хранить более чем на одном сайте.
• Иметь под рукой запасные части, включая запасные диски, запасные контроллеры, запасные кабели и даже целые запасные системы.
• Убедитесь, что у вас под рукой есть системы бесперебойного питания, портативные кондиционеры, дизельные генераторы и баки с топливом.
• Проверяем все на работоспособность!

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

Документ

Документируйте все, что связано с вашей инфраструктурой хранения. Это включает:

• Документирование всех продуктов и технологий, которые вы используете, как аппаратного, так и программного обеспечения. Это включает в себя, где они установлены и как они настроены.
• Маркируйте все, что может потребоваться для быстрой идентификации в случае сбоя. Например, пометьте кабели и соединения на массиве хранения.
• Документирование процессов настройки, обслуживания, обновления и восстановления всего, что связано с вашим решением для хранения данных. Например, запишите шаги по замене вышедшего из строя жесткого диска в массиве хранения. Запишите эти шаги таким образом, чтобы их мог выполнить любой человек, обладающий минимальными техническими знаниями.
• Держите всю документацию и маркировку в актуальном состоянии. Если что-то изменится, пересмотрите документацию или немедленно замените маркировку. На каждом элементе документации или маркировке должно быть указано имя лица, внесшего в нее изменения в последний раз.

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

Какие еще шаги необходимо выполнить, чтобы убедиться, что ваше решение для хранения данных правильно задокументировано, чтобы вы могли быстро восстановиться после сбоя хранилища? Остановите чтение и подумайте об этом несколько минут.

Упражняться

Последним столпом управления отказом хранилища является практика. Вам нужно все практиковать, чтобы убедиться, что ваши продукты, процессы и документация работают должным образом. Некоторые из тестов, которые вы можете практиковать, могут включать:

• Замена вышедшего из строя диска в массиве хранения DAS, NAS или SAN.
• Замена платы контроллера.
• Правильный монтаж кабеля.
• Восстановление тома из моментального снимка SAN или набора резервных копий на ленте.
• Восстановление удаленных файлов.
• Восстановление конфигурации сервера хранения.
• Перевод узла кластера в автономный режим для обслуживания.
• Проверка всех путей в резервированном решении.
• Обновление узлов кластера.

Какие еще действия следует предпринять, чтобы быстро устранять сбои хранения в вашей среде? Остановите чтение и подумайте об этом несколько минут.

Вывод

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