Dual Controller, кэш и BBU в СХД: зачем они нужны и как влияют на отказоустойчивость

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

Корпоративная СХД редко выходит из строя «одной кнопкой». Чаще проблема начинается с отдельного компонента: контроллера, порта, кабеля, батареи кэша, блока питания, прошивки или дисковой группы. Хорошая архитектура нужна для того, чтобы один такой отказ не вызывал остановку бизнес-системы.

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

Что делает контроллер СХД

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

Упрощенно, в полноценной СХД сервер не «разговаривает» с каждым диском напрямую. Он обращается непосредственно к контроллеру СХД, а он уже решает, как этот запрос обработать внутри массива.

Контроллер отвечает за несколько важных задач:

• принимает команды чтения и записи от серверов;
• распределяет операции по дискам, SSD, RAID-группам или пулам;
• управляет томами, снапшотами, репликацией и другими функциями СХД;
• обслуживает кэш чтения и записи;
• работает с портами доступа (Fibre Channel, iSCSI, SAS или другие);
• передает данные в интерфейс управления;
• фиксирует ошибки в журналах событий;
• участвует в обновлении прошивки и переключении нагрузки при отказах.

Из-за этого контроллер нельзя воспринимать как обычную RAID-карту. В корпоративной СХД он выполняет больше функций и сильнее влияет на доступность данных.

Если контроллер один, он становится потенциальной единой точкой отказа. Диски могут быть исправны, блоки питания могут работать, но при отказе единственного контроллера серверы потеряют доступ к томам.

Один контроллер или два: в чем реальная разница

СХД с одним контроллером может быть нормальным вариантом для некритичных задач. Например, для тестовой среды, лаборатории, временного архива или дополнительного уровня хранения, где допустим простой.

Плюсы такой схемы понятны:

• ниже стоимость;
• проще комплектация;
• меньше компонентов для обслуживания;
• проще первичная настройка.

Но ограничения тоже серьезные:

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

СХД с двумя контроллерами устроена иначе. В ней есть два управляющих модуля, и при корректной настройке второй контроллер может принять часть нагрузки или продолжить работу при отказе первого.

Два контроллера дают несколько преимуществ:

• можно подключить серверы к СХД через разные физические пути;
• отказ одного контроллера не будет приводить к потере доступа к данным;
• часть обслуживания можно выполнять без полного выключения массива;
• повышается устойчивость к отказу порта, кабеля, адаптера или коммутатора;
• кэш записи может дублироваться между контроллерами.

Например, у многих СХД Dell EMC отказоустойчивость строится именно вокруг двух контроллеров, нескольких портов и корректной схемы подключения к серверам. Но сама по себе надпись dual controller еще не гарантирует непрерывную работу. Если сервер подключен одним кабелем только к одному контроллеру, второй контроллер физически есть, но путь до него не используется.

Dual controller не защищает от всего. Он не отменяет резервное копирование и не спасает от:

• удаления данных пользователем;
• повреждения файловой системы;
• вируса-шифровальщика;
• ошибки администратора;
• некорректного обновления прошивки;
• отказа дисковой группы сверх допустимого уровня RAID;
• неправильной настройки путей на сервере.

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

Что происходит при отказе контроллера

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

В корректно настроенной схеме процесс выглядит так:

1. Один контроллер перестает обслуживать операции.
2. СХД переводит его ресурсы на оставшийся контроллер.
3. Серверы продолжают видеть тома через другие доступные пути.
4. Multipathing на стороне сервера выбирает рабочий путь.
5. Приложения могут заметить паузу или рост задержки, но не должны полностью потерять доступ к данным.

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

То же относится к обслуживанию. В двухконтроллерных массивах часто возможна поочередная замена или перезагрузка контроллеров. Например, в документации Dell PowerVault ME5 процедура замены контроллерного модуля предусматривает проверку состояния контроллера, индикацию готовности к извлечению и маркировку кабелей перед отключением. Это хороший пример того, почему даже «горячее» обслуживание требует дисциплины и не должно выполняться наугад: Dell PowerVault ME5: замена контроллера.

Перед заменой или обновлением контроллера стоит проверить:

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

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

Потеря пути: кабель, порт, адаптер, коммутатор

В реальной инфраструктуре чаще отказывает не весь контроллер, а отдельный путь. Например:

• вышел из строя SFP-модуль;
• поврежден кабель;
• отказал порт на контроллере;
• завис SAN-коммутатор;
• возникла проблема с сетевым адаптером сервера;
• изменилась конфигурация VLAN или iSCSI-сети.

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

Для Fibre Channel типовая схема выглядит так:

• на сервере установлены два HBA-адаптера;
• есть два независимых SAN-коммутатора;
• каждый сервер подключен к обеим фабрикам;
• СХД имеет порты на контроллере A и контроллере B;
• том доступен через несколько путей.

Для iSCSI логика похожая, но вместо FC-фабрик используются классические сетевые интерфейсы и изолированные сети:

• минимум два сетевых порта на сервере;
• две отдельные iSCSI-сети или VLAN;
• разные коммутаторы;
• разные порты СХД;
• включенный MPIO на стороне Windows, Linux или гипервизора.

Microsoft указывает, что MPIO помогает обеспечить высокую доступность и отказоустойчивость хранения в средах Hyper-V, кластеризации и виртуализации, но ошибки конфигурации могут приводить к потере путей, проблемам производительности и неожиданным простоям.

Частые ошибки в таких схемах:

• оба кабеля подключены к одному контроллеру;
• оба пути проходят через один коммутатор;
• MPIO не установлен или не включен;
• сервер видит один том как несколько разных дисков;
• политика выбора путей настроена наугад;
• iSCSI-трафик идет вместе с обычной пользовательской сетью;
• jumbo frames включены только на части маршрута;
• один контроллер перегружен, второй почти не используется.

Поэтому dual controller нужно оценивать вместе с путями. Два контроллера в СХД и один кабель до сервера — это не отказоустойчивая схема, а только потенциальная возможность построить ее позже.

Active-active, active-passive и ALUA простыми словами

В описаниях СХД часто встречаются термины active-active и active-passive. Их лучше понимать не как рекламные ярлыки, а как описание того, как контроллеры обслуживают тома.

В active-active оба контроллера могут участвовать в обработке операций. Это удобно, потому что ресурсы массива используются полнее. Но это не всегда означает, что любой путь одинаково хорош для любого тома. В некоторых СХД том все равно имеет предпочтительный контроллер, через который операции выполняются быстрее.

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

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

Broadcom VMware указывает, что при поддержке ALUA политика Round Robin по умолчанию использует активные оптимальные пути, а принудительное использование неоптимальных путей может приводить к деградации производительности.

На практике это означает следующее:

• не все видимые пути одинаково полезны;
• нельзя бездумно распределять ввод-вывод по всем путям;
• для VMware, Windows и Linux нужно изучать конкретные рекомендации производителя СХД;
• при смене контроллера-владельца тома политика путей должна корректно отработать;
• ошибки ALUA могут выглядеть как «странные» задержки без явного отказа.

Если после подключения dual controller СХД производительность ниже ожидаемой, стоит проверить не только диски и сеть, но и то, через какие пути реально идет нагрузка.

Зачем СХД нужен кэш

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

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

Серверы могут отправлять много мелких операций записи. Для дисков и даже для части SSD такие операции не всегда проходят быстро: они создают случайную нагрузку, очереди и задержки. Контроллер СХД принимает эти операции, временно размещает их в кэше и затем записывает на носители более эффективно.

Кэш помогает:

• быстрее подтверждать операции записи;
• объединять мелкие записи в более удобные для массива операции;
• сглаживать пики нагрузки;
• ускорять повторные чтения;
• уменьшать задержки в коротких всплесках активности;
• поддерживать более стабильную работу виртуальных машин и баз данных.

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

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

Write-back и write-through: почему режим кэша так важен

В СХД обычно встречаются два базовых режима записи: write-through и write-back.

Write-through — более осторожный режим. СХД подтверждает серверу запись только после того, как данные реально записаны на диски или SSD. Это безопасно, но медленнее.

Write-back — более производительный режим. СХД подтверждает запись после того, как данные попали в кэш контроллера. Физическая запись на диски происходит позже. Такой режим ускоряет работу, но требует защищенного кэша.

В документации Dell PowerVault ME5 указано, что в двухконтроллерной системе при работающих контроллерах write-back включен по умолчанию, а при одном контроллере или отказе контроллера используется write-through, как более безопасный. Там же объясняется роль суперконденсатора в защите кэша при потере питания.

Разница между режимами особенно заметна на нагрузках с большим количеством записи:

• базы данных;
• виртуализация;
• журналы приложений;
• терминальные серверы;
• VDI;
• файловые серверы с большим числом пользователей;
• резервное копирование с дедупликацией;
• видеонаблюдение с постоянным потоком записи.

Если кэш защищен, write-back обычно дает лучшую отзывчивость. Если защита кэша неисправна, массив может автоматически перейти в write-through. С точки зрения администратора это выглядит как резкое падение скорости записи. Но с точки зрения СХД это не «каприз», а защитная реакция: система перестает быстро подтверждать запись, пока не уверена, что данные в кэше не будут потеряны.

BBU, суперконденсатор и CacheVault: что они защищают

BBU (Battery Backup Unit) — это модуль резервного питания кэша. В старых системах чаще использовались батареи, в более новых — суперконденсаторы и энергонезависимая память. Смысл один: защитить данные, которые уже приняты СХД, но еще не записаны на носители.

Важно понимать: BBU не питает всю СХД и не заменяет UPS. Он не нужен для того, чтобы массив продолжал работать часами после отключения электричества. Его задача уже: сохранить содержимое кэша записи или дать контроллеру время перенести эти данные в энергонезависимую память.

Классическая батарея:

• питает кэш при сбое;
• имеет ограниченный срок службы;
• со временем деградирует;
• может требовать замены;
• при ошибке часто приводит к отключению write-back.

Сейчас чаще вместо батареи используют суперконденсаторы, которые работают немного иначе:

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

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

HPE в описании Smart Storage Battery связывает модуль батареи с поддержкой защиты данных в кэше для контроллеров и устройств хранения.

При покупке или обслуживании СХД важно смотреть не только на название технологии, а на фактическое состояние:

• кэш защищен или нет;
• батарея заряжена или находится в ошибке;
• суперконденсатор проходит диагностику или нет;
• нет ли событий о переходе в write-through;
• нет ли сообщений о dirty cache;
• совпадают ли версии прошивок контроллеров;
• поддерживается ли замена модуля без долгого простоя;
• доступна ли совместимая запасная часть.

Если BBU неисправен, СХД может продолжать работать, но это уже не та конфигурация, за которую платили при покупке. Формально тома доступны, но производительность записи может снизиться, а часть режимов кэша будет недоступна.

Зеркалирование кэша между контроллерами

В 2-ух-контроллерных СХД кэш записи часто дублируется между контроллерами. Это нужно для защиты от ситуации, когда один контроллер принял данные в кэш, подтвердил запись серверу, но не успел перенести данные на диски.

Процесс можно представить так:

1. Сервер отправляет запись на контроллер A.
2. Контроллер A помещает данные в свой кэш.
3. Данные копируются в кэш контроллера B.
4. СХД подтверждает запись серверу.
5. Если контроллер A отказывает, контроллер B завершает операцию.

Именно поэтому в отказоустойчивой СХД важны не только два контроллера как физические платы, но и нормальная связь между ними. Если кэш не синхронизируется, если один контроллер в ошибке, если прошивки отличаются или межконтроллерный канал нестабилен, отказоустойчивость становится сомнительной.

В журналах событий нужно проверять:

• ошибки синхронизации кэша;
• сообщения о dirty cache;
• предупреждения о батарее или суперконденсаторе;
• переходы в write-through;
• перезапуски контроллеров;
• потерю связи между контроллерами;
• ошибки портов и путей.

Для refurbished СХД это особенно важно. Массив может включаться, показывать диски и даже проходить базовый тест, но при этом иметь историю критических событий по кэшу. Такой риск нельзя увидеть просто по фото передней панели.

Сбой питания: что спасает BBU, а что должен спасать UPS

Сбой питания нужно разделять на несколько уровней.

1. Питание всей стойки или серверной. Здесь помогают UPS, две линии питания, разные PDU, корректная нагрузка на фазы и нормальная процедура завершения работы.
2. Питание самой СХД. Здесь важны два блока питания, подключенные к разным источникам. Если оба блока питания воткнуты в один PDU, реального резервирования меньше, чем кажется.
3. Данные в кэше. Именно здесь нужен BBU, суперконденсатор или аналогичная защита.

Если питание пропало полностью, СХД перестанет принимать новые операции. Но для данных, которые уже были подтверждены серверу и еще находились в кэше, критично другое: сможет ли контроллер сохранить их до восстановления питания.

BBU и UPS не заменяют друг друга:

• UPS защищает инфраструктуру от мгновенного отключения;
• BBU защищает кэш контроллера;
• два блока питания защищают от отказа одного PSU или одной линии;
• резервная копия защищает от логических ошибок и повреждения данных.

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

Отказ BBU и падение производительности записи

Один из частых неочевидных случаев — СХД внезапно начинает медленно писать, хотя диски исправны, сеть не перегружена, серверы работают нормально.

Причина может быть в кэше. Если батарея или суперконденсатор не проходят проверку, СХД может отключить write-back и перевести запись в write-through. В этом режиме каждую запись приходится подтверждать только после фактической записи на носители, поэтому задержки растут.

Это особенно заметно там, где много мелкой записи:

• журналы баз данных;
• виртуальные машины с активными дисками;
• терминальные фермы;
• VDI;
• системы учета;
• файловые шары с большим количеством пользователей;
• резервное копирование с большим количеством метаданных.

Снаружи это может выглядеть так:

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

В такой ситуации не стоит сразу менять диски или модернизировать сеть. Сначала нужно проверить:

• статус батареи или суперконденсатора;
• режим кэша на томах;
• события auto write-through;
• ошибки dirty cache;
• состояние обоих контроллеров;
• синхронизацию кэша;
• последние обновления прошивки.

Если СХД сама отключила write-back, лучше устранить причину, а не принудительно включать производительный режим любой ценой. Быстрая запись без защиты кэша может быть опаснее временной деградации, поскольку чревата невалидными данными.

Обновление прошивки и обслуживание без простоя

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

Задняя панель СХД. Источник изображения: Документация DELL

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

Перед обновлением стоит проверить:

• нет ли активных ошибок на СХД;
• оба контроллера исправны;
• кэш синхронизирован;
• BBU или суперконденсатор в норме;
• все пути видны на серверах;
• драйверы и DSM/MPIO-модули совместимы;
• есть актуальная резервная копия;
• есть план отката или инструкции производителя.

Обновлять прошивку на уже деградировавшей СХД рискованно. Если один контроллер давно в предупреждении, батарея неисправна, часть путей недоступна, а журналы полны ошибок, сначала нужно разобраться с состоянием массива. Иначе плановое обслуживание легко превращается в аварийное восстановление.

Как понять, что СХД действительно отказоустойчива

Отказоустойчивость — это не одна галочка в спецификации. Она складывается из нескольких уровней.

Хорошая конфигурация обычно включает:

• два контроллера;
• два блока питания;
• защищенный кэш записи;
• исправный BBU или суперконденсатор;
• резервирование дисков на уровне RAID или пула;
• два независимых пути от каждого сервера;
• два SAN-коммутатора или две изолированные iSCSI-сети;
• включенный multipathing;
• корректную политику выбора путей;
• актуальные и совместимые прошивки;
• мониторинг событий;
• регулярную проверку журналов;
• протестированное переключение при отказе;
• резервное копирование.

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

Плохая конфигурация тоже часто выглядит знакомо:

• СХД имеет два контроллера, но сервер подключен одним кабелем;
• оба кабеля идут в один коммутатор;
• второй контроллер установлен, но не участвует в обслуживании томов;
• write-back отключен, но администратор этого не заметил;
• BBU находится в warning-состоянии;
• прошивки контроллеров отличаются;
• часть портов не проверялась;
• логи не выгружались после поставки;
• тест отключения пути ни разу не проводился.

Поэтому при выборе СХД для бизнеса полезно задавать вопрос не «есть ли dual controller», а «как именно построена вся цепочка доступа к данным».

Проверка refurbished СХД перед покупкой

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

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

Перед покупкой стоит уточнить:

1. В СХД один контроллер или два?
2. Оба контроллера проходят диагностику?
3. Совпадают ли версии прошивок?
4. Какой статус кэша?
5. Включен ли write-back?
6. Если write-back отключен, почему?
7. Какой статус BBU, суперконденсатора или CacheVault?
8. Есть ли ошибки dirty cache?
9. Проверялись ли все порты?
10. Есть ли event log после тестирования?
11. Проводился ли тест отключения одного пути?
12. Проводился ли тест отключения контроллера?
13. Есть ли гарантия на контроллеры и батарейные модули?
14. Можно ли отдельно заменить BBU, PSU, вентилятор или контроллер?
15. Какие компоненты новые, а какие восстановленные?

Для задач начального и среднего уровня часто рассматривают СХД HP, Dell PowerVault, Dell Unity, NetApp и другие платформы. Но бренд сам по себе не решает вопрос надежности. Важнее конкретное состояние экземпляра, его комплектация и результаты диагностики.

В каких задачах два контроллера особенно важны

Dual controller стоит считать почти обязательным там, где простой быстро становится дорогим.

К таким задачам относятся:

• виртуализация;
• кластеры баз данных;
• ERP и учетные системы;
• терминальные серверы;
• файловые хранилища для бизнеса;
• VDI;
• видеонаблюдение с постоянной записью;
• резервное копирование, если СХД является основной площадкой хранения бэкапов;
• производственные системы;
• медицинские, финансовые и учетные приложения.

В этих сценариях важна не только сохранность данных, но и доступность сервиса. Иногда потеря доступа к СХД на 10–15 минут уже означает остановку отдела, простой смены или нарушение SLA.

СХД с одним контроллером может быть допустима для:

• тестовых стендов;
• лабораторий;
• временного хранения;
• архива без жестких требований к доступности;
• третьего уровня резервных копий;
• задач, где простой заранее принят как допустимый риск.

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

Почему два контроллера не всегда дают больше скорости

Распространенное заблуждение: если контроллеров два, СХД должна работать в два раза быстрее. Иногда второй контроллер действительно помогает распределить нагрузку, но прирост зависит от архитектуры массива.

На производительность влияют:

• тип дисков или SSD;
• уровень RAID или структура пула;
• размер и режим кэша;
• количество портов;
• скорость сети или SAN;
• политика multipathing;
• распределение томов между контроллерами;
• характер нагрузки;
• состояние батареи или суперконденсатора.

Если все тома фактически обслуживает один контроллер, второй может простаивать. Если пути настроены неправильно, часть операций может идти через неоптимальный маршрут. Если write-back отключен, запись может быть медленной даже на хороших дисках.

Поэтому при диагностике производительности нужно смотреть не только на «железо», но и на логику работы:

• какой контроллер владеет томом;
• какие пути активны;
• какие пути оптимальны;
• как распределяется ввод-вывод;
• включен ли кэш записи;
• нет ли ошибок защиты кэша;
• нет ли перегрузки конкретного порта.

Два контроллера — это инструмент для отказоустойчивости и балансировки, а не автоматическая гарантия удвоенной скорости.

Типичные заблуждения о dual controller, кэше и BBU

«Dual controller защищает данные от потери»

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

«Если есть UPS, батарея кэша не нужна»

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

«Write-back всегда лучше»

Write-back быстрее, но только при защищенном кэше. Если защита кэша неисправна, безопаснее работать медленнее в write-through, чем быстро подтверждать записи без гарантии сохранности и целостности (!).

«Refurbished СХД опасны по определению»

Риск зависит не от слова refurbished, а от диагностики. Восстановленная СХД с проверенными контроллерами, исправным кэшем, чистыми логами и гарантией может быть разумным вариантом. Но покупать такой массив без проверки BBU, прошивок и портов — плохая идея.

«Достаточно купить СХД с двумя контроллерами»

Нет. Нужно еще правильно подключить серверы, настроить multipathing, проверить ALUA, протестировать отказ пути и контроллера, убедиться в исправности кэша и следить за журналами.

Как корректно описывать отказоустойчивость в спецификации

Фраза «СХД отказоустойчивая, потому что dual controller» слишком общая. Она ничего не говорит о том, как массив подключен, защищен ли кэш, исправны ли порты и настроены ли пути.

Более корректная формулировка выглядит так:

«СХД оснащена двумя контроллерами, двумя блоками питания, защищенным кэшем записи и исправным модулем BBU или суперконденсатора. Серверы подключаются к массиву по двум независимым путям с настроенным multipathing. Перед вводом в эксплуатацию проверяются отказ контроллера, потеря пути, состояние кэша, версии прошивок и журналы событий».

Такая формулировка лучше отражает реальность. Отказоустойчивость — это не отдельный компонент, а результат всей схемы: СХД, серверов, адаптеров, коммутаторов, кабелей, прошивок и настроек операционной системы.

На что смотреть в первую очередь

Если нужно быстро оценить СХД, начните не с емкости, а с вопросов о рисках отказа.

Проверьте:

• два ли контроллера установлены;
• исправны ли оба контроллера;
• защищен ли кэш записи;
• в каком режиме работает кэш;
• исправен ли BBU или суперконденсатор;
• нет ли dirty cache;
• совпадают ли прошивки;
• все ли порты рабочие;
• есть ли два независимых пути от серверов;
• настроен ли multipathing;
• проводился ли тест отказа пути;
• есть ли свежие логи без критических ошибок.

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