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

Протокол SCSI — это как старый добрый корабль, который уже более четырёх десятилетий уверенно держится на плаву, несмотря на смену эпох, интерфейсов и даже поколений инженеров. Он прошёл путь от параллельных шин SCSI-1 до современных транспортов — SAS, Fibre Channel, iSCSI — оставаясь при этом тем же протоколом на командном уровне. При этом за привычными командами READ и WRITE скрывается целый арсенал редко упоминаемых, но крайне интересных возможностей.

Большинство специалистов, сталкивающихся со SCSI, знают его на уровне базовых операций: LUN, форматирование, резервирование и чтение блоков. Но стандарт T10 за десятилетия оброс десятками расширений — от механизмов защиты данных (Protection Information) и устойчивых резервирований (Persistent Reservations) до асимметричного доступа (ALUA) и оффлоад-копирования (XCOPY). Эти функции почти никогда не затрагиваются в учебниках и документации, но именно они отличают промышленную систему хранения от простого набора дисков.

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

В этой серии статей мы заглянем под обшивку SCSI и разберём:

• как работает T10 Protection Information и зачем хосту нужны дополнительные 8 байт на каждый блок;
• как Persistent Reservations позволяют нескольким хостам безопасно делить один LUN без фатальных конфликтов;
• что такое ALUA (Asymmetric Logical Unit Access) и как он обеспечивает оптимальную маршрутизацию в многопутевых системах;
• как работает XCOPY и другие механизмы оффлоад-операций, разгружающие хост от рутинной работы;
• а также другие малоизвестные механизмы, делающие SCSI удивительно живым и современным стандартом.

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

Начнём мы с самой практичной темы — Persistent Reservations. Эта функция решает фундаментальную проблему: как дать нескольким серверам доступ к одному LUN так, чтобы они не затоптали данные друг друга? Именно PR лежит в основе работы кластерных файловых систем, систем виртуализации и других решений, требующих совместного доступа к хранилищу.

Добро пожаловать в путешествие по скрытым глубинам SCSI.

Persistent Reservations: Искусство не мешать друг другу на одном диске

Проблема совместного доступа

Представьте ситуацию: два сервера в кластере имеют доступ к одному LUN. Оба могут читать и писать в любой момент времени. Что произойдёт, если первый сервер решит отформатировать диск, пока второй активно пишет данные? Или если оба одновременно попытаются обновить метаданные файловой системы?

В мире однохостового доступа такой проблемы не существует — операционная система сама координирует доступ к диску. Но как только мы подключаем один LUN к нескольким хостам (а это стандартная практика для кластеров, виртуализации и отказоустойчивых систем), возникает фундаментальный вопрос: кто контролирует доступ?

Именно для этого в SCSI существует механизм Persistent Reservations (PR) — система блокировок на уровне протокола, позволяющая хостам координировать доступ к разделяемому хранилищу.

От RESERVE/RELEASE к Persistent Reservations

В ранних версиях SCSI существовали простые команды RESERVE и RELEASE — один хост мог «захватить» весь LUN, блокируя доступ остальным. Проблема была очевидной: если хост с резервированием упал, LUN оставался заблокированным, и требовалось ручное вмешательство.

Persistent Reservations (появившиеся в SCSI-3) решили эту проблему, введя:

• Регистрацию — хост сначала регистрируется на LUN с уникальным ключом
• Резервирование — зарегистрированный хост может создать резервирование определённого типа
• Типы резервирований — от эксклюзивного доступа до сложных схем совместной работы
• Persistent — резервирования сохраняются при перезагрузках и сбоях

Типы резервирований

SCSI-3 Persistent Reservations предлагает несколько типов блокировок:
Write Exclusive (WE)
Только владелец резервирования может писать. Все остальные зарегистрированные хосты могут читать. Упрощенный тип блокировки — обычно используется WERO (см. ниже).
Exclusive Access (EA)
Только владелец может и читать, и писать. Все остальные полностью заблокированы. Используется редко, в основном для монопольного доступа при критических операциях.
Write Exclusive — Registrants Only (WERO)
Писать может только владелец резервирования, но читать могут все зарегистрированные хосты. Незарегистрированные хосты видят LUN, но не могут выполнять I/O операции (включая большинство INQUIRY команд, кроме базовых). 
Exclusive Access — Registrants Only (EARO)
Полный доступ только у владельца, остальные зарегистрированные хосты заблокированы. Незарегистрированные хосты видят устройство, но получают RESERVATION CONFLICT при попытке любых операций чтения/записи.
Write Exclusive — All Registrants (WEAR)
Все зарегистрированные хосты могут писать. Это кооперативный режим, где сами хосты должны координировать запись через другие механизмы (например, DLM в кластерных ФС).
Exclusive Access — All Registrants (EAAR)
Все зарегистрированные хосты имеют полный доступ. Редко используется, так как смысл резервирования теряется.

Наиболее часто используемые — WERO и WEAR. Остальные типы резервирований более нишевые.

Жизненный цикл резервирования

Типичная последовательность работы с PR выглядит так:

1. Register — хост регистрируется на LUN с уникальным 64-битным ключом
2. Reserve — один из зарегистрированных хостов создаёт резервирование нужного типа
3. Работа — хосты выполняют операции в рамках ограничений резервирования
4. Release — владелец снимает резервирование (или оно снимается принудительно через Preempt)
5. Unregister — хост удаляет свою регистрацию

Важный момент: если хост с резервированием упал и не ответил на SCSI-команды в течение таймаута, другой хост может выполнить Preempt — принудительно снять чужое резервирование и установить своё. Это ключевой механизм отказоустойчивости.

Инструменты для работы с PR

Linux: sg3_utils
Пакет sg3_utils предоставляет низкоуровневый доступ к SCSI-командам, включая PR.

Основной инструмент: sg_persist

# Установка (Debian/Ubuntu)
apt-get install sg3-utils

# Проверка поддержки SCSI-PR
sg_persist --in --report-capabilities /dev/sdb

# Регистрация на LUN с ключом 0x123abc
sg_persist --out --register --param-sark=0x123abc /dev/sdb

# Создание Write Exclusive резервирования
sg_persist --out --reserve --param-rk=0x123abc --prout-type=1 /dev/sdb

# Проверка текущего статуса (резервы и ключи)
sg_persist --in --read-status /dev/sdb

# Снятие резервирования
sg_persist --out --release --param-rk=0x123abc --prout-type=1 /dev/sdb

# Очистка всех ключей
sg_persist --out --clear --param-rk=0x123abc /dev/sdb

# Preempt: снять чужое резервирование (с ключом 0x456def)
sg_persist --out --preempt --param-rk=0x123abc --param-sark=0x456def \
           --prout-type=1 /dev/sdb

Mpathpersist

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

Резюме

Persistent Reservations — это не экзотическая функция для энтузиастов, а фундаментальный механизм, на котором построена вся современная кластеризация и виртуализация с разделяемыми LUN.

Ключевые тезисы:

• PR решает проблему координации доступа к разделяемым LUN между несколькими хостами
• Существует шесть типов резервирований для разных сценариев использования

В Linux есть удобные инструменты (sg_persist, mpathpersist) для работы с PR