Передача данных с разгрузкой в хранилищах Windows

Передача данных с разгрузкой в Windows (ODX) — это функция, которая ускоряет серверные операции копирования и перемещения. Она доступна начиная с Windows Server 2012 и поддерживается в томах NTFS.

В этой статье описывается ODX с точки зрения устройства хранения. Для получения информации, связанной с файловыми системами и минифильтрами, смотрите раздел Передача данных с разгрузкой.

Обзор

Вместо копирования больших объемов данных во время передачи файлов Windows ODX внедрила операцию с использованием токенов для перемещения данных на устройствах хранения. Исходный файл и целевой файл могут находиться в любом из следующих расположений:

• На том же томе.
• На двух разных томах, размещённых на одном и том же компьютере.
• На локальном томе и удаленном томе через блок сообщений сервера (SMB2 или SMB3).
• На двух томах на двух разных компьютерах через SMB2 или SMB3.

Процесс операции разгрузочного копирования на устройствах хранения с поддержкой ODX показан на следующей диаграмме.

Операция разгрузки копирования с помощью ODX.

1. Приложение для копирования отправляет запрос на чтение с разгрузкой менеджеру копирования исходного устройства хранения данных.
2. Диспетчер копирования источника возвращает токен. Маркер — это представление данных (ROD), копируемых.
3. Приложение отправляет запрос на запись с маркером в менеджер копирования назначенного устройства хранения.
4. Диспетчер копирования массива хранилища перемещает данные из исходного устройства на целевое устройство и возвращает результат переноса записи в приложение.

Определите источник и цель с поддержкой ODX

Для поддержки ODX массивы хранилища должны реализовать соответствующие стандартные спецификации T10 для массивов с поддержкой ODX, включая операции передачи чтения и записи с использованием маркеров. Во время перечисления устройств LUN (при загрузке системы или событии подключения устройств) Windows собирает или обновляет сведения о возможностях ODX целевого устройства хранения, выполнив следующие действия.

1. Возможность разгрузки копирования запросов.
2. Соберите необходимые параметры для операций копирования и ограничений разгрузки.

По умолчанию Windows пытается сначала использовать путь ODX для операции копирования, если исходный и целевой LUN поддерживают ODX. Если устройство хранилища отклоняет первоначальный запрос ODX, Windows помечает сочетание исходного и целевого LUN как путь, который не поддерживает ODX, и следует традиционному способу копирования файлов.

Операции чтения и записи ODX

Синхронное внедрение команд и API

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

• Если целевое устройство хранилища не предоставляет оптимальный размер передачи, задайте оптимальный размер передачи в 64 МБ.
• Если оптимальный размер передачи, установленный целевым устройством, превышает 256 МБ, задайте оптимальный размер передачи в 256 МБ.
• Оптимальный размер передачи, указанный целевым устройством хранилища, больше нуля и меньше 256 МБ.

Синхронные разгрузочные команды чтения и записи SCSI снижают сложность сценариев отработки отказа в MPIO и кластерах. Windows ожидает, что диспетчер копирования завершит синхронную разгрузку команд чтения и записи SCSI в течение 4 секунд.

Приложения могут использовать API FSCTL, DSM IOCTL или SCSI_PASS_THROUGH для взаимодействия с массивами хранилища и выполнения операций разгрузки копирования. Чтобы избежать повреждения данных или нестабильности системы, Windows ограничивает приложения от прямой записи на том, подключенный к файловой системе, без предварительного получения эксклюзивного доступа к этому тому. Это ограничение необходимо, поскольку запись в хранилище может конфликтовать с записями файловой системы. При возникновении таких коллизий содержимое тома может оказаться в несогласованном состоянии.

Разгрузка операций чтения

Запрос на чтение выгрузки приложения может указать время существования токена (тайм-аут бездействия). Если приложение устанавливает время существования маркера равным нулю, таймер бездействия по умолчанию используется в качестве времени существования маркера. Менеджер копирования массива хранилища поддерживает и проверяет токен в соответствии с его временем ожидания бездействия и учетными данными. Хост Windows также ограничивает количество фрагментов файлов до 64. Если запрос на чтение с разгрузкой состоит из более чем 64 фрагментов, Windows отклоняет запрос на разгрузку копирования и возвращается к традиционной операции копирования.

После завершения запроса на чтение разгрузки копировальный менеджер подготавливает токен отображения данных (ROD) для команды результата чтения разгрузки. Поле маркера ROD указывает представление данных пользователей и сведений о защите на определенный момент времени. ROD может быть данными пользователя в формате "только для чтения" или "открыть для общего доступа". Диспетчер копирования может аннулировать токен в соответствии с параметром политики ROD. Если ROD открыт исключительно для операции разгрузки копирования, то маркер ROD может быть аннулирован при изменении или перемещении ROD. Если ROD находится в формате "открыт с возможностью общего доступа", токен ROD остается действительным при изменении ROD. Токен ROD составляет 512 байтов со следующим форматом:

Размер в байтах	Содержимое токена
4	Тип токена ROD
508	Идентификатор токена ROD

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

Разгрузка операций записи

После получения маркера ROD из диспетчера копирования приложение отправляет запрос на запись разгрузки с маркером ROD в диспетчер копирования массива хранилища. Когда команда записи синхронной разгрузки отправляется на целевое устройство, Windows ожидает, что диспетчер копирования завершит команду в течение 4 секунд. Если выполнение команды прерывается из-за истечения времени ожидания или других условий ошибки, Windows сообщает о сбое команды. Приложение возвращается к устаревшей операции копирования в соответствии с возвращенным кодом состояния.

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

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

• Предполагаемое значение задержки обновления состояния равно нулю.
• Ход передачи данных составляет 100 процентов.

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

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

Размер в байтах	Содержимое токена
4	Тип токена ROD
2	Хорошо известный шаблон
506	Идентификатор токена ROD

При записи данных с использованием известного токена ROD клиентское приложение не может использовать чтение разгрузки для запроса известного токена. Менеджер копирования проверяет и поддерживает хорошо известные токены ROD в соответствии с собственной политикой.

Параметры настройки производительности реализации ODX

Производительность ODX не зависит от скоростей транспортного канала сети клиента или сети хранилища (SAN) между сервером и массивом хранилища. Диспетчер копирования и серверы устройств массива хранилища перемещают данные.

Не каждое разгружение копирования приносит пользу от технологии ODX. Например, диспетчер копирования массива хранилища iSCSI 1 Гбит/с может завершить копию файла размером 3 ГБ в течение 10 секунд, и скорость передачи данных будет больше 300 МБ в секунду. Скорость передачи данных уже опережает максимальную теоретические скорости передачи интерфейса Ethernet 1-Гбит.

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

• Windows задает минимальное требование к размеру файла для операций разгрузки копирования в 256 КБ в обработчике копирования. Если файл меньше 256 КБ, подсистема копирования возвращается к устаревшей процедуре копирования.

• Хост Windows использует максимальный размер передачи токенов и оптимальное число передач для подготовки оптимального размера передачи команды чтения или записи SCSI. Общий размер передачи в количестве блоков не должен превышать максимальный размер передачи токенов. Если массив хранилища не сообщает оптимальное количество передач, Windows использует 64 МБ в качестве значения по умолчанию.

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

Обработка ошибок ODX и поддержка высокой доступности

Если операция ODX завершается сбоем запроса на копирование файлов, подсистема копирования и файловая система Windows (NTFS) возвращаются к устаревшей операции копирования. Если выгрузка копии завершается сбоем в середине операции записи, движок копирования и NTFS возобновляют работу с использованием стандартной операции копирования с первого места сбоя в записи выгрузки.

Обработка ошибок ODX

ODX использует надежный алгоритм обработки ошибок в соответствии с функциями массива хранилища. Если разгрузочная копия завершается ошибкой в пути, поддерживающем ODX, система Windows ожидает, что приложение вернется к устаревшей операции копирования. На этом этапе механизм копирования Windows уже реализовал механизм "возврата к традиционному копированию". После сбоя разгрузки копирования NTFS помечает исходный и целевой LUN как не поддерживающий ODX в течение трех минут. После прохождения этого периода времени подсистема копирования Windows повторяет операцию ODX. Массив хранилища может использовать эту функцию для временной отключения поддержки ODX в некоторых путях во время очень стрессовых ситуаций.

Отказоустойчивость ODX в конфигурациях MPIO и серверных кластеров

Выгрузка операций чтения и записи должна быть завершена или отменена из той же ссылки на хранилище (I_T nexus).

При переключении на резервный узел MPIO или сервера кластера во время синхронной операции чтения или записи Windows обрабатывает этот процесс следующим образом:

• Если происходит отработка отказа пути MPIO, Windows повторит сбой команды ODX. Если команда снова не выполняется, Windows:

  • Инициирует переключение узла кластера при работе в составе кластерного сервера.
  • Выполняет сброс LUN на устройстве хранения и сообщает приложению о сбое ввода-вывода, если переход на резервный сервер кластера невозможен.

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

Если команда чтения или записи после отказа пути MPIO и узла кластера завершилась неудачно, Windows выполняет сброс LUN на устройство хранения после отказа. Устройство хранилища завершает выполнение всех команд и ожидающих операций на LUN.

В настоящее время Windows из стека хранения не выдает команды SCSI для асинхронной разгрузки операций чтения или записи.

Модели использования ODX

ODX на физическом диске, виртуальном жестком диске и общем диске SMB

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

Базовые поддерживаемые целевые объекты источника и назначения ODX.

Операция ODX с одним сервером

В конфигурации с одним сервером приложение переноса данных осуществляет перенос запросов на чтение и запись из той же серверной системы.

Исходный сервер (или исходная виртуальная машина) имеет доступ к исходному LUN (VHD или физическому диску) и целевому LUN (VHD или физическому диску). Приложение разгрузки отправляет запрос на чтение разгрузки исходному LUN и получает токен от исходного LUN. Затем приложение для копирования с разгрузкой использует маркер для выдачи запроса на разгруженную запись в целевой LUN. Диспетчер копирования перемещает данные из исходного LUN в целевой LUN в одном массиве хранилища.

Операция ODX с двумя серверами

В конфигурации с двумя серверами существует два сервера и несколько массивов хранилища, управляемых тем же диспетчером копирования.

• Один сервер (или виртуальная машина) — это узел исходного LUN, а другой сервер (или виртуальная машина) является узлом целевого LUN. Исходный сервер использует исходный LUN с клиентом приложения через протокол SMB, а конечный сервер также предоставляет конечный LUN клиенту приложения через протокол SMB. Таким образом, клиент приложения имеет доступ как к исходному LUN, так и к целевому LUN.
• Исходные и целевые массивы хранилища управляются тем же диспетчером копирования в конфигурации SAN.
• Из клиентской системы приложение для переноса выдает запрос на чтение в исходный LUN и получает маркер из исходного LUN, а затем выдает запрос на запись с маркером в целевой LUN. Диспетчер копирования перемещает данные из исходного LUN в целевой LUN между двумя разными массивами хранения в двух разных местоположениях.

Массовая миграция данных

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

• Один сервер является узлом устаревшей системы хранения, а другой — узлом новой системы хранения. Исходный сервер использует исходный LUN в качестве клиента приложения миграции данных через протокол SMB, а конечный сервер использует целевой LUN в качестве клиента приложения миграции данных через протокол SMB. Таким образом, клиент приложения имеет доступ к исходному и целевому LUN.
• Устаревшая система хранения и новая система хранения управляются тем же диспетчером копирования в конфигурации SAN.
• Из клиентской системы приложения миграции данных приложение копирования отправляет запрос на чтение в исходный LUN и получает маркер от исходного LUN. Затем приложение отправляет запрос на разгрузочную запись, используя токен, на целевой LUN. Диспетчер копирования перемещает данные из исходного LUN в целевой LUN в двух разных системах хранения в двух разных расположениях.
• Массовая миграция данных также может осуществляться с одним сервером в том же месте.

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

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

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

• Сервер — это узел многоуровневой системы хранения. Источник LUN — это устройство хранилища Уровня 1, а целевой LUN — устройство хранилища Уровня 2.
• Тот же диспетчер копирования управляет всеми многоуровневыми устройствами хранения.
• С серверной системы приложение миграции данных отправляет запрос на выгрузку чтения к исходному LUN и получает токен от исходного LUN. Затем это приложение отправляет запрос на запись отгруженных данных с токеном в целевой LUN. Диспетчер копирования перемещает данные с исходного LUN на целевой LUN между двумя различными устройствами хранения разных уровней.
• После завершения задачи миграции данных приложение удаляет данные с устройства хранилища Уровня 1 и освобождает место в хранилище.