Использование AzCopy для копирования блобов между учетными записями хранения Azure с сетевыми ограничениями.

Сводка

В этой статье описывается, как скопировать BLOB-объекты между учетными записями хранения с помощью служебной программы командной строки AzCopy. В нем также объясняется, как реализовать операцию копирования при настройке ограничений сети для учетных записей хранения.

Общие сведения

Копирование объектов BLOB между двумя аккаунтами хранения является распространенной задачей для многих пользователей Azure. служба хранилища Azure поддерживает непосредственное копирование двоичных объектов из одной учетной записи хранения в другую, что можно реализовать с помощью утилиты командной строки AzCopy. Вам не нужно скачивать файлы на локальные диски или буферы, а затем снова отправлять их.

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

Команды AzCopy для копирования блобов между учетными записями хранения

• Если вы предоставляете учетные данные авторизации с помощью идентификатора Microsoft Entra, используйте следующую команду:

  azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
  

  В этом сценарии необходимо убедиться, что удостоверение Microsoft Entra имеет правильные назначения ролей для исходных и целевых учетных записей.

• Если вы используете маркер Общей Подписи Доступа (SAS), выполните следующую команду:

  azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path><SAS-token>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path><SAS-token>'
  

  В этом сценарии необходимо добавить маркер SAS как к исходному, так и целевому URL-адресу, используемому в командах AzCopy.

Дополнительные сведения см. в статье Копирование двоичных больших объектов между учетными записями хранения Azure с помощью AzCopy v10.

Копирование BLOB-объектов между учетными записями хранения с ограничением доступа

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

Существуют два поддерживаемых сценария:

Сценарий 1. Клиент использует общедоступную конечную точку для доступа к учетным записям хранения

В этом сценарии необходимо добавить общедоступный IP-адрес клиента или виртуальную сеть (виртуальную сеть) в список разрешений брандмауэра в исходных и целевых учетных записях хранения.

На следующем рисунке показан процесс копирования блобов между хранилищами в этом сценарии.

Сценарий 2. Виртуальная сеть клиента имеет частные каналы, и использует частную конечную точку для доступа к учетным записям хранения.

В этом сценарии не требуется список разрешений брандмауэра.

На следующем рисунке показан процесс копирования блобов между учетными записями хранения в этом сценарии.

Ниже приведен полный процесс этого механизма для двух сценариев:

1. Клиент отправляет запрос PutBlockfromURL в целевое хранилище.
2. Целевое хранилище получает запросы и пытается получить блоки из заданного исходного URL-адреса. Однако, так как целевое хранилище не разрешено исходным брандмауэром, он получает ошибку 403 Запрещено .
3. После того как целевое хранилище получит ошибку 403 Запрещено , он отправляет другой запрос GetBlob от имени клиента. Если клиент имеет доступ к исходному хранилищу, получатель может получить блоки из источника и вернуть клиенту код успешного выполнения.
4. Клиент отправляет PutBlockList в целевое хранилище, чтобы зафиксировать блоки и завершить процесс после получения от запроса кода успешного ответа.

Сценарий 3. Клиент использует общедоступные конечные точки с примененным периметром безопасности сети

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

Клиентские, исходные и целевые учетные записи в одном периметре

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

Исходные и целевые учетные записи в одном периметре

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

1. Клиент отправляет запрос на операцию Put Block From URL в целевую учетную запись хранения.

   Чтобы разрешить этот запрос, убедитесь, что входящий доступ предоставляется клиенту из целевой учетной записи.

2. Целевая учетная запись отправляет запрос get Block в исходную учетную запись хранения.

   Целевая учетная запись хранения получает запрос и пытается получить блоки из заданного исходного URL-адреса. Поскольку целевая учетная запись извлекает блоки из исходной учетной записи от имени клиента, для предоставления клиенту доступа необходимо разрешить входящие соединения как в исходной, так и в целевой учетной записи.

   Чтобы разрешить этот запрос, убедитесь, что входящий доступ предоставляется клиенту из исходной учетной записи.

Клиент, исходная учетная запись и целевая учетная запись в разных периметрах

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

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

1. Клиент отправляет запрос на операцию Put Block From URL в целевую учетную запись хранения.

2. Целевая учетная запись отправляет запрос get Block в исходную учетную запись хранения.

   Чтобы разрешить этот запрос, убедитесь, что:

   • Исходящий доступ предоставляется исходной учетной записи из целевой учетной записи.
   • Входящий доступ предоставляется целевой учетной записи из исходной учетной записи.

Дополнительные сведения об управлении входящим и исходящим доступом см. в разделе "Правила доступа к периметру безопасности сети " и az network perimeter profile access-rule.

Копирование блобов между учетными записями хранения в архитектуре концентратор-периферия с использованием частных конечных точек

Ошибка 403 возникает при использовании AzCopy для копирования BLOB-объектов между хранилищами, подключенными к частным конечным точкам в разных спицевых виртуальных сетях из виртуальной машины в центральной виртуальной сети. Вы увидите ошибку 403 This request is not authorized to perform this operation - CannotVerifyCopySource в журналах AzCopy или в журналах служба хранилища Azure. На следующей схеме архитектуры показан сценарий, в котором возникает ошибка.

Решение 1. Создание частной конечной точки для конечной учетной записи хранения в исходной виртуальной сети

Создайте частную конечную точку для целевой учетной записи хранения в исходной виртуальной сети. Эта конфигурация позволяет виртуальной машине успешно копировать большие двоичные объекты между учетными записями хранения с помощью AzCopy. На следующей схеме архитектуры показан процесс копирования блобов между учетными записями хранения в Решении 1.

Решение 2. Поместите виртуальную машину в ту же виртуальную сеть, что и исходную учетную запись хранения, и настройте пиринг виртуальной сети между исходными и целевыми виртуальными сетями.

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

Дополнительные сведения см. в разделе часто задаваемые вопросы о пиринге виртуальной сети.

Обходное решение 3. Использование временной промежуточной учетной записи для копирования данных

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

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

Решение 4. Использование виртуальной машины для скачивания и отправки данных между учетными записями хранения

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