Можно ли включить Write-Back, если BBU или CacheVault неисправны?

Нет, не как штатный режим. Принудительный Write-Back без исправной защиты кэша создаёт риск потери уже подтверждённых записей при сбое питания, reset или отказе компонента. Без подтверждённой BBU, CacheVault, flash-backed cache или суперконденсатора безопаснее использовать Write-Through, устранить неисправность и проверить политику контроллера.

Чем Write-Through отличается от Write-Back на RAID-контроллере?

Write-Back подтверждает запись после её помещения в кэш контроллера, до записи на диски, поэтому может снизить задержку. Write-Through не должен использовать неподтверждённые данные только в энергозависимом кэше и является безопасным режимом при проблемах с его защитой. Write-Back допустим только при исправной защите грязного кэша и корректной политике контроллера.

Ускоряет ли Hot Spare восстановление RAID?

Зависит от того, что считать ускорением. Hot Spare сокращает время между обнаружением отказа диска и началом rebuild, если контроллер автоматически назначает совместимый резерв. Однако он не уменьшает объём фонового восстановления, не гарантирует срок его завершения и не устраняет рост задержек для работающих виртуальных машин в деградированном массиве.

Можно ли собрать отказоустойчивый локальный RAID для ESXi на HBA?

Нет, сам по себе HBA не создаёт отказоустойчивый datastore. Для обычного локального VMFS в ESXi набор дисков за HBA не превращается средствами гипервизора в зеркало или массив с чётностью. HBA используют, когда избыточностью управляет поддерживаемая программная архитектура, например vSAN, при соблюдении требований конкретной версии.

Можно ли подключить NVMe к обычному SAS/SATA RAID-контроллеру?

Нет, обычный SAS/SATA RAID-контроллер не получает поддержку NVMe изменением настроек. Для NVMe нужна отдельно поддерживаемая схема: например, tri-mode-контроллер и предусмотренная производителем PCIe-топология. Дополнительно проверяют backplane, PCIe-линии, режим подключения, охлаждение и совместимость контроллера с накопителями.

Нужно ли менять Stripe Size для хранилища виртуальных машин?

Зависит от контроллера и измеренного профиля I/O. Для Stripe Size нет универсального значения для виртуальных машин: эффект определяется размером операций, долей случайного и последовательного доступа, очередью, кэшем и firmware контроллера. Настройку следует соотнести с фактической нагрузкой и подтвердить тестом, а не выбирать по общему правилу.

RAID для VMware ESXi и Hyper-V: проектирование хранилища ВМ

Для виртуальных машин со смешанной случайной записью RAID 10 часто является безопасной отправной точкой по предсказуемости задержек, но не универсальным ответом. RAID 5 и RAID 6 могут быть оправданы, если важнее полезная ёмкость, а профиль записи, кэш и деградированный режим проверены на репрезентативной нагрузке. Проект локального RAID для VMware ESXi или Hyper-V начинают не с уровня массива, а с измерения I/O, требований к задержке, роста ёмкости и допустимого влияния rebuild на работающие ВМ.

Три разных уровня защиты

Локальный RAID защищает прежде всего от отказа отдельных накопителей в одном хосте. Отказоустойчивость кластера виртуализации защищает доступность ВМ при отказе хоста только в предусмотренной архитектуре. Резервная копия нужна для восстановления после удаления, повреждения данных, шифровальщика и других событий: подробнее — в статье «Почему RAID — не резервное копирование: защита данных сервера».

1. Зафиксируйте требования к datastore до выбора RAID

Сбор профиля нагрузки и ограничений

Результатом должен быть документ с измеренными значениями и отдельно отмеченными допущениями. Он нужен не только для выбора RAID-уровня, но и для проверки массива после сборки.

1
Разделите ВМ на группы нагрузки
Отдельно учтите инфраструктурные ВМ, файловые сервисы, базы данных, терминальные серверы, VDI, системы резервного копирования и тестовые машины. Для каждой группы запишите число ВМ, потребляемую ёмкость, ожидаемый рост, критичность и допустимый простой. Не складывайте требования по паспортным IOPS приложений без коэффициента одновременности: пики разных систем могут не совпадать.
2
Соберите временные ряды в существующей среде
Снимайте синхронизированные метрики гипервизора, datastore или тома и, если это нужно для диагностики, гостевых ОС. Для ESXi источниками обычно служат графики производительности и экспорт метрик vCenter, а также средства наблюдения хоста; для Hyper-V — счётчики Windows, средства мониторинга томов и метрики гостевых ОС. Интервал выбирают достаточно коротким, чтобы не скрыть пики, а период наблюдения должен включать обычные дни, резервное копирование, отчётность, обновления, закрытие периода и другие регламентные задания.
3
Запишите не среднее, а распределение нагрузки
Для каждого периода определите устойчивые и кратковременные пиковые IOPS, долю чтения и записи, долю случайного и последовательного доступа, размеры блоков, глубину очереди, пропускную способность и задержки чтения и записи. Отделяйте наблюдаемые перцентили от целевых: например, p99 показывает значение, в которое укладывается 99% измеренных операций. Допустимые p95 и p99, а при необходимости p99.9, задают по требованиям приложения, SLO/SLA и согласованному бюджету времени отклика. Если формальных требований нет, используйте как отправную точку базовую линию периода с подтверждённо приемлемой работой или результат пилотного теста, явно пометив такой порог как допущение. Одно среднее значение IOPS или задержки не показывает хвост, который замечает пользователь.
4
Оцените рабочий набор и ёмкость
Рабочий набор — объём активно используемых данных за характерный период; он влияет на эффективность кэшей, но не отменяет требований к устойчивой производительности дисков. Отдельно рассчитайте текущую занятую ёмкость, прогноз роста, требуемый свободный запас на datastore и накладные расходы файловой системы и виртуальных дисков. Формулы полезной ёмкости и число дисков разобраны в статье «Как рассчитать ёмкость RAID и количество дисков».
5
Для новой среды отделите модель от измерений
Если исторических метрик нет, составьте расчёт по группам ВМ: предполагаемые IOPS, read/write ratio, размер блока, рабочий набор, коэффициент одновременности и рост. Пометьте каждое значение как допущение, требование приложения или измеренный факт. Затем проверьте собранную конфигурацию нагрузочным тестом, близким к модели. Синтетический тест полезен для сравнения вариантов, но без сопоставления с реальным профилем не является точным прогнозом работы ВМ.

Как оценить рабочий набор

В существующей среде выберите характерный цикл работы — например, рабочий день, неделю или период закрытия отчётности — и оцените объём уникальных данных, которые за него активно читаются или изменяются. Для этого используют прикладную статистику, метрики баз данных и файловых сервисов, сведения о занятых и изменяемых блоках, а при необходимости — отдельный трассировочный или нагрузочный тест. Нельзя получать рабочий набор простым сложением прочитанных и записанных байтов: повторные обращения к одним блокам многократно завысят результат. Для новой среды рабочий набор задают отдельно по каждой группе ВМ как допущение и проверяют после запуска. Шаг сбора метрик должен давать несколько отсчётов внутри самого короткого значимого пика, а длительность наблюдения — охватывать полный деловой цикл и регламентные задания; фактические шаг, период и пропуски данных фиксируют вместе с результатами.

Минимальная карточка требований к локальному datastore

Параметр	Что фиксировать	Зачем это нужно
Нагрузка	Устойчивые и пиковые IOPS, чтение/запись, random/sequential, размер блока, глубина очереди	Оценить производительность массива и штраф записи
Задержка	Целевые p95/p99 отдельно для чтения и записи	Не принять высокий средний IOPS за приемлемый отклик
Ёмкость	Текущие данные, свободный запас, рост, срок планирования	Выбрать число и ёмкость рабочих дисков без скорого расширения
Деградированный режим	Допустимый рост latency, доступное окно и политика ограничения нагрузки	Проверить, переживут ли ВМ rebuild
Ограничения платформы	Число отсеков, интерфейсы, PCIe-линии, бюджет, окно простоя	Не спроектировать неподключаемую или неподдерживаемую схему

2. Выберите архитектуру: аппаратный RAID, HBA или программное хранение

Аппаратный RAID-контроллер уместен, когда ESXi или Windows Server должен видеть один логический диск, а контроллер, драйвер, firmware, дисковая корзина и накопители поддерживаются целевой версией платформы. Контроллер может дать защищённый кэш записи и берёт на себя rebuild, но это не отменяет проверки совместимости именно для выбранной версии ESXi или Windows Server/Hyper-V.

HBA передаёт отдельные диски программному слою и сам не создаёт отказоустойчивый datastore. Для обычного локального VMFS в ESXi набор дисков за HBA не превращается средствами гипервизора в зеркало или массив с чётностью; HBA допустим, когда избыточностью владеет поддерживаемая программная архитектура, например vSAN, и вся конфигурация соответствует требованиям её версии. В Hyper-V отдельные диски могут использовать локальные Storage Spaces, а в кластерной среде — предусмотренный выбранной версией вариант кластерных Storage Spaces или Storage Spaces Direct. Эти варианты различаются требованиями к контроллеру, накопителям, числу узлов и способу подключения, поэтому их поддержку проверяют отдельно для конкретной версии Windows Server. В любой программной схеме заранее определяют, какой слой отвечает за избыточность, мониторинг, замену дисков и восстановление.

Не приравнивайте passthrough к готовому RAID

JBOD, passthrough, HBA mode и один RAID 0 на диск могут по-разному представлять устройства ОС и не всегда равнозначны. Не считайте HBA самостоятельным способом получить отказоустойчивое хранилище. Для программных схем, ZFS, Ceph и mdadm выбор владельца избыточности нужно делать отдельно; сравнение подходов — в статье «HBA или RAID-контроллер: что выбрать для сервера, ZFS, Ceph и обычных дисковых массивов».

Для ESXi проверьте точную модель контроллера или HBA, версию драйвера и firmware по VMware Compatibility Guide, release notes VMware и документации производителя.
Для Hyper-V проверьте совместимость контроллера, HBA, дисков и драйверов с конкретной версией Windows Server по документации Microsoft и производителя сервера.
Отдельно проверьте матрицу сервера или контроллера для дисковой корзины, кабелей, экспандера, типов дисков и выбранной топологии.
Поддержка SAS/SATA RAID не означает поддержку NVMe RAID. Для NVMe нужна отдельная проверка контроллера, backplane, PCIe-топологии и режима подключения.

3. Подберите HDD, SATA/SAS SSD или NVMe по устойчивой нагрузке

HDD обычно выбирают для ёмкостных пулов с умеренными требованиями к случайным IOPS и задержке. SATA или SAS SSD подходят для более интенсивного случайного доступа и меньшей задержки. NVMe может дать высокий параллелизм, но не гарантирует его сам по себе: путь от накопителя до процессора, PCIe-линии, корзина, переключатели и режим RAID должны поддерживать выбранную схему.

Выбор типа накопителей для RAID виртуальных машин

Тип	Когда обычно уместен	Что дополнительно проверить
HDD	Ёмкостные ВМ, архивы, файловые сервисы с умеренной случайной нагрузкой	Задержку под случайной записью, время rebuild, состояние дисков в деградированном массиве
SATA SSD	Небольшие и средние серверы с интенсивным random I/O при совместимой SATA-подсистеме	Устойчивую запись, DWPD/TBW, PLP, секторный формат, поддержку моделью контроллера
SAS SSD	Серверные конфигурации с SAS-корзиной и требованиями к управляемости или двухпортовому подключению	Совместимость с контроллером и корзиной, выносливость, прошивку, режим обработки ошибок
NVMe SSD	Низкая задержка и высокий параллелизм при подходящей платформе	PCIe-топологию, backplane, поддержку tri-mode или программной схемы, охлаждение и устойчивую запись

Для SSD и NVMe недостаточно интерфейса и пиковых паспортных IOPS. Сверьте устойчивую производительность при длительной записи, заполнении накопителя и сборке мусора, ресурс DWPD или TBW, защиту от потери питания, секторный формат, прошивку и допустимость модели в серверном RAID. Оцените объём записи с учётом служебной нагрузки массива: частичная запись в RAID с чётностью может создавать дополнительные внутренние операции. Потребительские SSD нельзя считать эквивалентом серверных по одному названию интерфейса.

NVMe и RAID

Обычный SAS/SATA RAID-контроллер не получает поддержку NVMe обновлением настроек. Трёхрежимный контроллер, tri-mode, поддерживает SAS, SATA и PCIe/NVMe только в предусмотренной производителем топологии. Особенности M.2, NVMe и PCIe bifurcation собраны в статье «RAID на SSD, M.2 и NVMe: особенности, ограничения и выбор схемы».

4. Выберите RAID 10, RAID 5 или RAID 6 по профилю записи

RAID 10 обычно выбирают первым кандидатом для datastore с заметной смешанной или случайной записью, чувствительной к задержке. Зеркальная структура не требует вычисления чётности при каждой частичной записи и часто ведёт себя предсказуемее при изменении очереди и нагрузки. Это не означает, что RAID 10 всегда быстрее: итог зависит от числа и типа дисков, контроллера, кэша, размеров операций, параллелизма и состояния массива.

RAID 5 и RAID 6 могут быть обоснованы, когда полезная ёмкость важнее, запись относительно невелика или хорошо укладывается в полные полосы, а массив проходит проверку под реальным профилем. При мелкой частичной случайной записи чётность нередко вызывает операции read-modify-write. Упрощённая оценка иногда использует штраф около четырёх операций для RAID 5 и около шести для RAID 6, но она применима только как грубая модель частичных записей и не заменяет измерение: кэш, full-stripe write, размер полосы, очередь и реализация контроллера меняют результат.

Отправные критерии выбора RAID для виртуальных машин

Сценарий	Первый вариант для проверки	Условие принятия решения
Базы данных, VDI, активные терминальные серверы, смешанная random write	RAID 10	Только после теста p95/p99, устойчивой записи и деградированного режима
Смешанные серверные ВМ с умеренной записью	RAID 10 или RAID 6 — по измеренному профилю и ёмкости	Если запас по задержке сохраняется при пиках и rebuild
Преимущественно чтение, последовательные задачи, ёмкостные ВМ	RAID 5 или RAID 6 как кандидаты	При достаточном числе дисков, подходящем окне риска и проверенной записи
Большая ёмкость, критичен риск второго отказа во время rebuild	RAID 6 как кандидат либо другая архитектура	После оценки производительности и времени восстановления именно этой конфигурации

Параметры Stripe Size, Read Ahead и Disk Cache Policy не имеют универсальных значений для RAID виртуальных машин. Их названия, допустимые режимы и эффект зависят от PERC, Smart Array, MegaRAID или другого семейства, а также от firmware. Соотносите их с измеренным размером I/O и профилем, затем подтверждайте тестом; подробная логика — в статье «Кэш RAID-контроллера, Write Back и Stripe Size: выбор без лишнего риска».

5. Включайте Write-Back только при подтверждённой защите записи

Write-Back кэш подтверждает запись после помещения данных в кэш контроллера, до переноса на диски. Это может существенно снизить задержку, особенно для записи с чётностью, но подтверждённые данные не должны остаться только в энергозависимой памяти. Поэтому перед включением режима проверяют состояние защищённого грязного кэша, BBU, CacheVault, flash-backed cache или суперконденсатора, а также политику контроллера при неисправности этой защиты.

Убедитесь, что модель контроллера действительно имеет защищённый кэш и что модуль защиты исправен; объём кэша и поддерживаемые политики зависят от точной модели и firmware.
Проверьте, переводит ли контроллер Write-Back в Write-Through при ошибке BBU, CacheVault или суперконденсатора и как это отражается в событиях. Поведение PERC, Smart Array и MegaRAID различается по моделям и версиям.
Проверьте кэш самих HDD или SSD. Защита кэша контроллера не делает автоматически безопасным энергозависимый кэш накопителя.
Для SSD подтвердите наличие PLP и корректную обработку контроллером flush/FUA и других команд фиксации записи.
Зафиксируйте в эксплуатационной документации, какой режим должен быть активен в норме и какой считается безопасным при неисправности защиты кэша.

Не включайте принудительный Write-Back как штатный способ вернуть производительность

Принудительный Write-Back при неисправной или отсутствующей защите кэша — осознанное принятие риска потери подтверждённых записей при сбое питания, reset или отказе компонента, а не нормальная настройка RAID. Если защита не подтверждена, безопаснее оставить Write-Through, устранить причину и проверить состояние кэша по документации модели. Порядок проверки и замены модулей защиты описан в статье «BBU, CacheVault и суперконденсатор RAID-контроллера: проверка и замена».

6. Спланируйте отказ диска, Hot Spare и RAID rebuild

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

Hot Spare уменьшает время между обнаружением отказа и началом rebuild, если контроллер автоматически назначает совместимый резерв. Он не уменьшает объём фоновой операции, не гарантирует срок её завершения и не устраняет рост задержки для работающих ВМ. Выбор между global и dedicated spare, а также правила Copyback зависят от схемы массивов; детали — в статье «Hot Spare в RAID: global, dedicated и Copyback».

План rebuild и окно обслуживания

1
Определите допустимое состояние после отказа
Зафиксируйте, может ли массив работать с текущей нагрузкой в деградированном режиме, какие ВМ при необходимости переносят или ограничивают и какой рост p95/p99 задержки считается недопустимым. Для RAID 10 учитывайте, что последствия нескольких отказов зависят от того, какие именно зеркальные пары затронуты.
2
Оцените rebuild диапазоном
Оценка должна учитывать тип и ёмкость дисков, число участников, RAID-уровень, контроллер, приоритет фоновой операции, заполненность и ожидаемую рабочую нагрузку. Срок указывайте диапазоном при явно записанных условиях, а не универсальным числом часов для HDD или SSD. Начало rebuild с Hot Spare и завершение rebuild — разные контрольные точки.
3
Заложите производственный запас
Проверьте, что до отказа массива есть запас по IOPS, пропускной способности и хвостовой задержке. В план внесите действия при превышении порогов: перенос части ВМ, перенос ресурсоёмких заданий, временное ограничение резервного копирования или согласованное окно обслуживания.
4
Проверьте наблюдаемость
Оповещения должны приходить для статуса logical drive, каждого physical disk, predictive failure, ошибок связи, состояния BBU/CacheVault, отключения кэша и прогресса rebuild. Полезно регулярно проверять журналы и выполнять поддерживаемые профилактические операции, не смешивая Patrol Read, Consistency Check и Background Initialization. Регламент мониторинга разобран в статье «Мониторинг и профилактика RAID: S.M.A.R.T., Patrol Read, Consistency Check и оповещения».

Не прогнозируйте rebuild по одному тесту без нагрузки

Rebuild конкурирует с ВМ за ресурсы дисков, контроллера и шины. Измерение на пустом массиве или во время простоя показывает только один из сценариев. Реальную продолжительность и влияние на latency подтверждают для конкретной конфигурации и предполагаемой нагрузки; порядок безопасной замены диска описан отдельно в статье «Замена диска в RAID и Rebuild: порядок действий и контроль».

7. Выполните приёмку до переноса рабочих виртуальных машин

Проверки нового RAID datastore

1
Проверьте совместимость фактической конфигурации
Сопоставьте установленную модель контроллера или HBA, firmware, драйвер, сервер, корзину и диски с утверждённой матрицей. Убедитесь, что версия ESXi либо Windows Server/Hyper-V поддерживает именно это сочетание. После обновления firmware повторно зафиксируйте версии и состояние массива; безопасный порядок обновления — в статье «Как обновить прошивку RAID-контроллера и снизить риск для массива».
2
Проверьте состояние массива и всех дисков
До создания datastore Virtual Disk или Logical Drive должен иметь ожидаемый статус, а каждый физический диск — ожидаемую роль и состояние. Убедитесь, что не осталось необъяснённых Foreign Configuration, ошибок корзины, потерянных путей или незавершённых фоновых операций. Не очищайте и не импортируйте чужую конфигурацию по шаблону: такие действия могут изменить метаданные.
3
Подтвердите безопасную политику кэша
Зафиксируйте текущий режим Write-Back или Write-Through, состояние BBU/CacheVault или другой защиты, политику при её ошибке, состояние кэша накопителей и наличие PLP у SSD. Проверьте, что предупреждение об отключении Write-Back действительно попадает в систему мониторинга.
4
Проведите репрезентативный нагрузочный тест
Тестируйте на выделенном новом datastore или иной безопасной цели, а не на физических дисках действующего массива. Воспроизведите характерные размер блока, read/write ratio, случайность, параллелизм, длительность и рабочий набор. Отделите краткий burst кэша от устойчивого результата и измерьте p95/p99 задержки. Методика и ограничения benchmark разобраны в статье «Как тестировать производительность RAID: IOPS, задержки, fio и правила корректного benchmark».
5
Проверьте режим деградации без риска для рабочих данных
Если политика эксплуатации допускает такой тест, заранее определите безопасную лабораторную или выделенную конфигурацию, критерии остановки и способ возврата к нормальному состоянию. Цель — измерить влияние фоновой операции на задержку и убедиться, что события, Hot Spare и приоритет rebuild работают ожидаемо. Не имитируйте отказ извлечением диска из рабочего массива без утверждённой процедуры.
6
Проверьте восстановление ВМ из резервной копии
Восстановите тестовую ВМ или её данные в изолированной среде, проверьте запуск, целостность прикладных данных и фактическое время операции. Успешный backup job без теста восстановления не подтверждает достижение RTO и RPO.

Рабочий чек-лист перед вводом datastore в эксплуатацию

Профиль нагрузки содержит устойчивые и пиковые IOPS, read/write ratio, размеры блоков, глубину очереди, рабочий набор, прогноз роста и целевые p95/p99 задержки.
Расчётные допущения для новой среды отделены от измеренных данных и проверены репрезентативной нагрузкой.
RAID-уровень выбран с учётом производительности в нормальном и деградированном режиме, а не только полезной ёмкости.
Контроллер или HBA, драйвер, firmware, дисковая корзина, накопители и топология подтверждены для конкретной версии ESXi либо Windows Server/Hyper-V.
Для SSD или NVMe подтверждены устойчивые характеристики, ресурс, PLP, секторный формат и поддержка выбранной RAID-схемой.
Статус Virtual Disk и всех физических дисков нормальный; нет необъяснённых предупреждений, Foreign Configuration и активных неожиданных фоновых задач.
Защита кэша контроллера исправна; политика при её отказе известна; кэш дисков, flush/FUA и PLP проверены.
Настроены оповещения по массиву, дискам, корзине, контроллеру, BBU/CacheVault, отключению Write-Back и rebuild.
Есть Hot Spare либо документированный регламент быстрой замены, а для rebuild определены диапазон времени, запас производительности и действия при росте задержки.
Выполнены нагрузочные измерения и тест восстановления ВМ из резервной копии.

Для Dell PowerEdge состояние PERC и дисков удобно предварительно сверить через iDRAC, но создание Virtual Disk и конкретные пункты меню зависят от модели. Пошаговый порядок вынесен в материал «Настройка RAID на Dell PowerEdge: PERC, iDRAC и Virtual Disk».

Термины в статье

Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Грязный кэш: Грязный кэш содержит изменённые блоки, ещё не записанные в постоянное хранилище. Такие блоки нельзя безопасно отбросить до их сброса.
Деградированный режим: Состояние отказоустойчивого RAID-массива, потерявшего часть избыточности, но сохраняющего доступ, пока сочетание отказов допустимо для его уровня и раскладки.
Дисковая корзина: Дисковая корзина — узел шасси с отсеками для установки нескольких накопителей и организации их подключения к питанию и контроллеру либо HBA.
Кэш со сквозной записью: Кэш со сквозной записью — режим, в котором кэш не подтверждает запись раньше нижележащего хранилища и не оставляет подтверждённые данные только в своей энергозависимой памяти.
Кэширование записи: Кэширование записи — временное размещение записываемых данных в быстрой памяти перед их передачей в нижестоящее хранилище для снижения задержки и оптимизации ввода-вывода. Момент подтверждения записи и гарантия её сохранности зависят от политики кэша и всех уровней стека хранения.
Опережающее чтение: Метод предварительной загрузки данных в кэш при последовательном чтении. Система читает следующие блоки заранее, снижая задержку последующих запросов.
Политика кэша RAID-контроллера: Политика кэша RAID-контроллера — набор настроек обработки чтения и записи в кэше, определяющих момент подтверждения записи, режим чтения и требования к защите кэша в режиме write-back.
Полная полосовая запись: Запись в RAID с чётностью, заменяющая все блоки данных одной полосы. Новая чётность вычисляется по поступившим данным, поэтому старые данные и чётность читать не требуется.
Программный RAID: RAID, реализованный ОС или другим программным стеком хоста без отдельного аппаратного RAID-контроллера. Использует вычислительные ресурсы сервера.
Суперконденсатор: Накопитель энергии высокой мощности, применяемый для кратковременного питания кэша RAID-контроллера. При сбое питания он сохраняет данные до записи во флеш-память.
Трёхрежимный RAID-контроллер: Аппаратный RAID-контроллер, интерфейсы которого поддерживают SAS-, SATA- и PCIe/NVMe-накопители; схема подключения зависит от контроллера и платформы.
Физический диск: Физический диск — отдельный HDD, SSD или иной накопитель, распознанный RAID-контроллером как член массива либо как независимое устройство.
Фоновая инициализация: Фоновая инициализация — формирование или проверка RAID-контроллером данных избыточности нового массива без отключения логического диска.
Чётность: Избыточные контрольные данные, вычисляемые из блоков одной полосы RAID. Один блок чётности защищает от отказа одного диска, два независимых блока RAID 6 — от отказа двух.
Чтение-модификация-запись: Чтение-модификация-запись — цикл частичной записи RAID-полосы: контроллер читает прежние данные и контрольную информацию, пересчитывает их и записывает обновление.
BBU: Аккумуляторный модуль, поддерживающий питание энергозависимого кэша RAID-контроллера при сбое питания до восстановления питания и записи данных на диски.
CacheVault: CacheVault — технология защиты кэша записи RAID-контроллера, сохраняющая во флеш-память подтверждённые хосту, но ещё не записанные на диски данные при потере питания.
Ceph: Ceph — распределённая программно-определяемая система хранения, объединяющая диски серверов в масштабируемое объектное, блочное и файловое хранилище.
Consistency Check: Consistency Check — фоновая проверка согласованности избыточности RAID: зеркальных копий либо рассчитанной и записанной чётности; расхождения могут исправляться.
Copyback: Copyback — операция RAID-контроллера, копирующая данные с задействованного hot spare на диск замены, после чего spare снова становится резервным.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
Dedicated Hot Spare: Dedicated Hot Spare — резервный диск RAID-контроллера, закреплённый за конкретным массивом или группой массивов и используемый для rebuild только при отказе их дисков.
Dell PERC: Семейство RAID-решений Dell для серверов PowerEdge: аппаратные контроллеры PERC H и программные PERC S. Возможности и совместимость зависят от модели и поколения платформы.
Foreign Configuration: Состояние, при котором RAID-контроллер считает найденную на дисках конфигурацию массива не зарегистрированной или не совпадающей с текущей. Её проверяют и импортируют либо очищают.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
HBA: HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
IOPS: IOPS — число завершённых операций ввода-вывода в секунду, которое накопитель, RAID-массив или СХД обеспечивает при заданном профиле нагрузки.
JBOD: Способ подключения дисков без аппаратного RAID: обычно ОС видит каждый накопитель отдельно. Сам JBOD не обеспечивает избыточность; при необходимости её создаёт программный уровень.
M.2: M.2 — спецификация компактного разъёма и модулей расширения, определяющая размеры и ключи; накопители M.2 могут использовать интерфейс SATA или PCIe.
mdadm: Утилита командной строки Linux для создания, сборки, мониторинга и изменения программных RAID-массивов подсистемы MD.
MegaRAID: Семейство аппаратных RAID-контроллеров Broadcom, которые объединяют накопители в массивы и предоставляют ОС логические диски, обрабатывая RAID на самом контроллере.
NVMe: NVMe — протокол обмена командами с энергонезависимыми накопителями, оптимизированный для параллельного ввода-вывода; локальные NVMe-SSD обычно подключаются по PCIe.
Passthrough: Passthrough — режим контроллера, в котором отдельный накопитель предоставляется ОС как самостоятельное блочное устройство без включения в аппаратный RAID-массив.
Patrol Read: Patrol Read — фоновое сканирование накопителей RAID-контроллером для поиска скрытых ошибок чтения. В избыточном массиве контроллер может восстановить повреждённые блоки.
PCIe Bifurcation: PCIe Bifurcation — деление линий одного слота PCI Express на несколько логических портов, например x16 на два x8 или четыре x4, для прямого подключения нескольких устройств.
Predictive Failure: Predictive Failure — диагностический статус накопителя, указывающий на признаки вероятного отказа по SMART или данным контроллера до фактической недоступности диска.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
RAID 0: RAID 0 — массив минимум из двух дисков с чередованием данных без избыточности. Отказ любого участника делает весь логический том недоступным.
RAID 1: RAID 1 — уровень RAID с зеркалированием данных на двух или более дисках. Полезная ёмкость равна ёмкости наименьшего участника, а доступ сохраняется, пока исправна хотя бы одна копия.
RAID 10: Комбинированный уровень: чередование (RAID 0) поверх зеркальных пар (RAID 1). Сочетает высокую скорость и отказоустойчивость, отдавая под избыточность половину ёмкости.
RAID 5: RAID 5 — уровень RAID с чередованием данных и распределённой чётностью, выдерживающий отказ одного диска. Требует минимум трёх дисков.
RAID 6: Уровень RAID с чередованием данных и двойной распределённой чётностью. Выдерживает отказ любых двух дисков; минимум четыре диска.
RAID-контроллер: Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
RAID-кэш: Буфер быстрой памяти между хостом и накопителями RAID, используемый для кэширования чтения и записи. Может снижать задержку и повышать производительность ввода-вывода.
RAID-уровень: RAID-уровень — схема размещения данных и избыточности по накопителям массива, определяющая полезную ёмкость, отказоустойчивость и характеристики ввода-вывода.
Rebuild: Процесс восстановления избыточности массива после замены отказавшего диска: контроллер вычисляет и записывает на новый диск недостающие данные из остальных дисков.
SAS: SAS — последовательный интерфейс и набор протоколов SCSI для подключения накопителей, поддерживающий адресацию устройств, экспандеры и обычно двухпортовое подключение дисков.
SATA: SATA — последовательный интерфейс подключения HDD, SSD и оптических приводов; в обычной прямой схеме один порт контроллера соединён с одним накопителем.
Stripe Size: Параметр чередования RAID: объём последовательных данных, размещаемых на одном диске до перехода к следующему. Значение термина stripe size зависит от вендора.
vCenter Server: Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
VDI: VDI — архитектура, в которой пользовательские рабочие столы выполняются в виртуальных машинах на централизованной инфраструктуре, а пользователи подключаются к ним удалённо.
VMFS: VMFS — кластерная файловая система VMware для блочных хранилищ, формирующая datastore с согласованным доступом нескольких хостов ESXi к файлам ВМ.
vSAN: Программно-определяемое хранилище VMware, объединяющее локальные накопители хостов ESXi в общее распределённое хранилище с управлением через политики.
Write-Back кэш: Политика кэша RAID-контроллера: запись подтверждается после помещения данных в кэш, а на накопители переносится позже. Кэш требует защиты от потери питания.
ZFS: ZFS — файловая система и менеджер томов с пулами хранения, контрольными суммами и копированием при записи, объединяющий управление дисками и данными.