Читать полный материал
Внешняя СХД оправдана, если сервер с локальными дисками не выдерживает согласованные задержки записи или время восстановления. Сравните оба варианта на одном профиле: пиковая нагрузка, задержка p95 и p99, сохранность подтверждённых транзакций и результат после отказа одного пути.
Измерить профиль приложения
Запишите объём базы, рабочий набор, доли чтения и записи, размеры операций, глубину очереди и длительность пиков. Измерьте p99 фиксации транзакций в приложении и отдельно p99 записи журнала на уровне ввода-вывода. p99 показывает, в какую задержку укладываются 99% операций. IOPS — число операций в секунду, пропускная способность — объём данных за секунду (МБ/с). Для OLTP с частой мелкой записью сравнивайте эти показатели при одинаковом размере блока, соотношении чтения и записи и глубине очереди. Рост глубины очереди может поднять IOPS, одновременно увеличив задержку. p99 показывает границу, в которую укладывается 99% наблюдений. Снимайте её за одинаковые интервалы в обычное время и во время резервного копирования или отчётной нагрузки.
В заявке укажите нагрузку, длительность теста и условия успеха. Например, если команда задала p99 подтверждения транзакции не выше 8 мс при 400 транзакциях в секунду, результат 11 мс на том же профиле означает, что конфигурация не прошла. Эти числа иллюстрируют метод, а реальные пороги задаёт владелец сервиса.
Сохранность подтверждённых транзакций
При синхронной фиксации важно, чтобы система хранения действительно сохраняла подтверждённую запись. Документация PostgreSQL о надёжности записи разделяет кэш ОС, контроллера и накопителя. Проверьте, как вся цепочка обрабатывает fsync и команды сброса кэша (flush). После подтверждения запись должна пережить потерю питания: она уже на энергонезависимом носителе или защищена кэшем с документированным восстановлением. Если в рабочей конфигурации подтверждённая транзакция должна переживать сбой, сравнивайте массивы с теми же гарантиями. В PostgreSQL отключение fsync создаёт риск повреждения данных, а synchronous_commit=off допускает потерю последних подтверждённых транзакций. См. PostgreSQL: Non-Durable Settings.
Документация Microsoft для SQL Server требует гарантированной записи на энергонезависимый носитель, соблюдения порядка операций и защиты кэша. Для кэша обратной записи проверьте защиту при потере питания: контроллер может удерживать данные с помощью батареи (BBU) или переносить их во флеш-память за счёт суперконденсатора. У выбранных серверных SSD проверьте документированную защиту данных при потере питания (PLP). ИБП не заменяет эти механизмы: сбой питания отдельного узла возможен и при работающем ИБП. Попросите поставщика документировать поведение выбранного массива и накопителей при сбое.
Пути доступа и совместимость
Сверьте протокол, версии ОС, драйверов, адаптеров и прошивки со списком совместимости массива. Для блочного доступа сравните Fibre Channel, iSCSI на выделенной IP-сети и NVMe-oF: NVMe/FC, NVMe/TCP или NVMe/RoCE, если их поддерживает вся цепочка. Документация NetApp по SAN описывает варианты подключения. Выбирайте по p99 на своём профиле и доступности резервных путей. Документация Red Hat по DM Multipath показывает, как настроенная система переходит на резервный путь при отказе кабеля, коммутатора или порта. Проверьте, что пути проходят через независимые порты или конечные точки доступа массива. ОС должна объединять пути к одному LUN или пространству имён NVMe в одно логическое устройство.
На испытательном стенде с согласованным сценарием проверьте потерю и возврат одного пути под нагрузкой. Запишите паузу, ошибки клиента и задержку после переключения.
Ёмкость и служебные операции
Раздельно учтите данные, рост, журналы, временные области, снапшоты и место для обслуживания. Для PostgreSQL используйте руководство по WAL и контрольным точкам: параметр max_wal_size — мягкий предел, поэтому его нельзя считать жёсткой квотой места. Сравнивайте полезную ёмкость после защиты и служебного резерва. Для журнала и OLTP с частыми мелкими записями начните сравнение с RAID 10: он не вычисляет чётность. RAID 5/6 обычно дают больше полезной ёмкости при том же числе одинаковых дисков, но мелкая запись может требовать дополнительных операций. Сопоставьте свойства уровней RAID, затем измерьте p99 и время перестроения на массиве под нагрузкой и после отказа диска. Для фирменных схем защиты используйте документацию производителя. Сжатие оценивайте на своих данных.
Для сравнения флеш-массива и гибридной системы держите одинаковыми профиль записи и набор данных. Зафиксируйте, помещается ли рабочий набор в быстрый слой и что происходит при длительной записи, когда его уже недостаточно.
Производительность после отказа
Проведите один и тот же сценарий в штатном и деградированном режимах. Сравните p99, число ошибок и время возврата к целевому уровню. Проверьте режим, который описан для конкретного массива: потерю одного пути, отказ контроллера или восстановление после отказа диска.
Восстановление из резервной копии проверьте отдельно. Снапшот на том же массиве позволяет быстро вернуться к предыдущему состоянию, но может стать недоступен вместе с массивом. Храните независимую копию и проверяйте её восстановление. При синхронной репликации первичная запись ждёт подтверждения устойчивой записи на второй площадке. Это увеличивает задержку и позволяет добиться RPO = 0 для подтверждённых записей, пока действует эта гарантия. Асинхронная репликация не ждёт удалённого подтверждения на пути записи: при отказе первичной площадки могут пропасть изменения, которые не успели реплицироваться. Ошибочные изменения могут попасть на реплику в обоих режимах. Для восстановления PostgreSQL на выбранный момент нужна базовая копия и последовательность архивных WAL до нужной точки. Запишите фактическую потерю данных и время, когда приложение снова приняло рабочие запросы.
Когда внешняя СХД не обязательна
Оставьте локальные диски, если они выдерживают целевую нагрузку, а проверенная схема резервирования и восстановления укладывается в требования сервиса. Рассматривайте внешнюю СХД, когда нужны управляемый общий доступ, отдельное масштабирование ёмкости или восстановление, которое локальная схема не обеспечивает.
Для сравнения используйте СХД, серверные SSD и серверные платформы. В запросе укажите СУБД, измерения, подключения, объём и критерии приёмки.
Частые вопросы
Самая высокая паспортная скорость означает лучший массив для БД?
Сравните p99 транзакций и число ошибок на том же объёме данных при одинаковой нагрузке. Паспортный максимум IOPS может быть измерен при других размерах операций и соотношении чтения и записи.
Два кабеля означают готовый multipath?
Проверьте, что ОС видит один том с независимыми путями. На стенде отключите один путь под нагрузкой и измерьте паузу и ошибки клиента.
Общая СХД автоматически делает базу отказоустойчивой?
Общий массив может повысить доступность хранения. Доступность базы проверяют отдельно: измеряют переключение и восстанавливают приложение из копии до рабочего запроса.
Авторство и источники
Автор — Сергей Коваль, коммерческий директор ANDPRO. Материал подготовлен при участии AI-ассистента по документации производителей. Собственные испытания оборудования не заявлены.
- PostgreSQL 15: надёжность WAL
- PostgreSQL 18: WAL и контрольные точки
- Microsoft: требования SQL Server к вводу-выводу
- Red Hat: настройка и работа DM Multipath
- PostgreSQL 18: восстановление на момент времени
- PostgreSQL: Non-Durable Settings
- Kingston: SSD Power Loss Protection
- NetApp: Learn about ONTAP SAN configuration
- IBM: RAID level summary
- NetApp: Learn about ONTAP SnapMirror synchronous disaster recovery
- NetApp: Learn about ONTAP SnapMirror asynchronous disaster recovery
