Разгрузка передачи данных в хранилище Windows
Выгрузка данных Windows (ODX) — это функция, которая ускоряет операции копирования и перемещения сервера. Она доступна начиная с Windows Server 2012 и поддерживается в томах NTFS.
В этой статье описывается ODX с точки зрения устройства хранения. Сведения, связанные с файловыми системами и минифильтрами, см. в разделе "Отключенные передачи данных".
Обзор
Вместо копирования больших объемов данных во время передачи файлов Windows ODX представила маркеризованную операцию для перемещения данных на устройствах хранения. Исходный файл и целевой файл могут находиться в любом из следующих расположений:
- На том же томе.
- На двух разных томах, на которые размещается один и тот же компьютер.
- На локальном томе и удаленном томе через блок сообщений сервера (SMB2 или SMB3).
- На двух томах на двух разных компьютерах через SMB2 или SMB3.
Процесс операции копирования разгрузки на устройствах хранения с поддержкой ODX показан на следующей схеме.
- Приложение копирования отправляет запрос на чтение разгрузки диспетчеру копирования исходного устройства хранилища.
- Диспетчер копирования источника возвращает маркер. Маркер — это представление данных (ROD), копируемых.
- Приложение отправляет запрос на запись с маркером в диспетчер копирования целевого устройства хранилища.
- Диспетчер копирования массива хранилища перемещает данные из исходного устройства на целевое устройство и возвращает результат записи разгрузки в приложение.
Определение источника и назначения с поддержкой ODX
Для поддержки ODX массивы хранилища должны реализовать связанные стандартные спецификации T10 для массивов хранилища с поддержкой ODX, включая разгрузку операций чтения и записи с маркерами. Во время перечисления устройств LUN (системная загрузка или событие подключаемого модуля и воспроизведения) Windows собирает или обновляет сведения о возможностях ODX целевого устройства хранилища, выполнив следующие действия.
- Возможность разгрузки копирования запросов.
- Соберите необходимые параметры для операций копирования и ограничений разгрузки.
По умолчанию 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 с одним сервером
В конфигурации с одним сервером приложение копирования выдает разгрузку запросов на чтение и запись из той же серверной системы.
Исходный сервер (или исходная виртуальная машина) имеет доступ к исходному 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 и освобождает место в хранилище.