Кратко

  • RFC 7147 поместил iSCSIProtocolLevel в атрибуты отдельного сеанса, сохранив границы согласования между инициатором и целью.
  • Значение уровня 2 описывает состояние протокола в этом сеансе; оно не подтверждает завершение конкретной задачи SCSI или принятие результата приложением.

Один накопитель — не один разговор

В спецификации устройства хочется видеть один статус: поддерживается, совместимо, актуально. У работающей iSCSI-системы может быть несколько экземпляров, узлов, порталов, сеансов и TCP-соединений. Каждый сеанс связывает инициатор с целью. Параметры протокола согласуются именно между этими двумя сторонами; другой сеанс может иметь иного инициатора и иное состояние.

Это различие и закрепила модель RFC 7147. Документ вышел в апреле 2014 года, заменил RFC 4544 и обновил iSCSI MIB в соответствии с RFC 7143 и RFC 7144. В таблицу атрибутов сеанса добавили два доступных только для чтения объекта: iscsiSsnProtocolLevel и iscsiSsnTaskReporting. Первый показывает уровень iSCSI, согласованный для данного сеанса. Второй фиксирует согласованную с целью семантику отчётов о завершении задач.

Размещение значения в строке сеанса сохраняет ответ на вопрос «кто с кем договорился?». Если панель превратит его в характеристику устройства, соглашение с одним инициатором станет необоснованным обещанием для всех путей. RFC 7147 следует границе самого протокола: уровень относится к конкретному сеансу и остаётся привязанным к нему.

Согласование создаёт условие, а не подтверждает результат

RFC 7144 требует согласовать значение 2 для iSCSIProtocolLevel, чтобы использовать описанные там возможности. Но тот же документ прямо говорит: согласование необходимо, но недостаточно для использования соответствующих возможностей SCSI. Реализация всё ещё может отклонить конкретную функцию управления задачами. Инициатор должен обработать ответ SCSI; чтение SNMP не может заменить этот ответ.

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

Второй новый атрибут показывает ту же границу. TaskReporting — набор согласованных правил отчётности о завершении задач: базовая семантика RFC 3720, а также ResponseFence и FastAbort. Он описывает, как сообщается завершение задачи. Он не удостоверяет, что определённая задача была выполнена, данные сохранены надёжно или приложение приняло результат.

Модель управления разделяет уровни

Структура MIB начинается с экземпляра iSCSI, а ниже располагает узлы, порталы, сеансы и соединения. Каждый нескалярный объект сначала индексируется экземпляром. Он может обозначать физический или виртуальный раздел системы хранения. RFC 7147 подчёркивает: экземпляр не заменяет контекст SNMP, но позволяет связать раздел с одним или несколькими контекстами без повторного назначения для каждой строки узла, портала и сеанса.

Так сохраняются разные источники свидетельств. Таблица сеансов показывает согласованное состояние iSCSI; TCP MIB описывает транспортные соединения; SCSI MIB может отражать атрибуты уровня SCSI. У хоста и приложения есть собственные критерии успеха. Система управления может сопоставить эти представления, но отдельное поле не превращает их в единое доказательство.

Приоритет работающего кода здесь проявляется как инженерная конкретика. Спецификация имеет значение, когда инициатор и цель её реализуют, согласуют параметры и обмениваются командами. MIB полезен, когда позволяет наблюдать заданное состояние работающей системы. Однако наблюдение всегда относится к определённому уровню и моменту времени. Чтобы утверждать, что операция прошла успешно, нужно проследить доказательства до ответа SCSI и потребителя результата.

Что позволяет заключить значение

Уровень в разрезе сеансов помогает объяснить, почему два пути к одной системе хранения ведут себя по-разному. Он поддерживает анализ совместимости, проверку изменений и разбор инцидентов; позволяет увидеть, совпала ли фактическая договорённость с ожиданиями конфигурации. Сведение значения к статусу всего устройства уничтожило бы эту точность.

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

Вывод ограничен, но важен: уровень протокола принадлежит соглашению, которое его создало. RFC 7147 дал этому соглашению отдельную строку; результат операции требуют подтверждать другие данные.

Источники