Изменение способа репликации для учетной записи хранения

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

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

Параметры изменения типа репликации

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

• Как ваши данные реплицируются в пределах основного региона. Данные в основном регионе можно реплицировать локально с помощью локально избыточного хранилища (LRS) или между зонами доступности Azure с использованием избыточного между зонами хранилища (ZRS).
• Выполняется ли георепликация данных. Георепликация обеспечивает защиту от региональных аварий путем репликации данных во второй регион, географически удаленный к основному региону. Геореплицированные конфигурации включают геоизбыточное хранилище (GRS) и геозонально-избыточное хранилище (GZRS).
• Требуется ли приложению доступ на чтение к реплицированным данным в дополнительном регионе. Вы можете настроить учетную запись хранения, чтобы разрешить доступ на чтение к данным, реплицированным в дополнительный регион, если основной регион становится недоступным по какой-либо причине. Конфигурации, обеспечивающие доступ на чтение к данным в дополнительном регионе, включают геоизбыточное хранилище с доступом на чтение (RA-GRS) и геозонально-избыточное хранилище с доступом на чтение (RA-GZRS).

Подробный обзор всех параметров избыточности см. в разделе избыточность хранилища Azure.

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

Существует три способа изменения параметров репликации:

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

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

Ответы на распространенные вопросы об изменении типов репликации см. в статье часто задаваемых вопросов об избыточности хранилища .

Изменение конфигурации избыточности

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

¹Добавление геоизбыточности вызывает одноразовую плату за исходящий трафик.
² Если учетная запись хранения содержит большие двоичные объекты на уровне архива, просмотрите ограничения уровня доступа перед изменением типа избыточности на геоизбыточное или избыточное между зонами.
³ Тип поддерживаемого преобразования зависит от типа учетной записи хранения. Дополнительные сведения см. в таблице учетной записи хранилища.
⁴ Преобразование учетной записи LRS в ZRS или GZRS в результате отработки отказа не поддерживается. Чтобы получить дополнительную информацию, см. Переключение и восстановление.
⁵ Преобразование из LRS в ZRS не поддерживается, если поддержка протокола NFSv3 включена для Azure Blob Storage или если учетная запись хранения содержит общие папки Azure Files NFSv4.1 с настроенными общедоступными конечными точками.
⁶ Несмотря на то, что включение географической избыточности происходит мгновенно, переход на резервный регион не может быть инициирован до завершения синхронизации данных между двумя регионами.

Изменение параметра репликации

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

Изменение конфигурации избыточности с помощью портала Azure, PowerShell или Azure CLI

В большинстве случаев можно использовать портал Azure, PowerShell или Azure CLI для изменения параметра геоизбыточной репликации или настройки доступа для чтения (RA) для учетной записи хранения.

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

Set-AzStorageAccount -ResourceGroupName <resource_group> `
    -Name <storage_account> `
    -SkuName <sku>

az storage account update \
    --name <storage-account> \
    --resource-group <resource_group> \
    --sku <sku>

Выполнение преобразования

Преобразование избыточности — это процесс изменения аспекта зональной избыточности учетной записи хранения.

Во время преобразования не требуется потери данных или простоя приложения.

Существует два способа инициировать преобразование:

• Инициированный клиентом
• Инициированная поддержка

Преобразование, инициированное клиентом

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

Преобразование, инициированное клиентом, можно выполнить в поддерживаемых регионах с помощью портал Azure, PowerShell или Azure CLI. Преобразование обычно начинается в течение 72 часов после запуска, но может занять больше времени из-за доступности ресурсов, объема данных и других факторов.

Start-AzStorageAccountMigration
    -AccountName <String>
    -ResourceGroupName <String>
    -TargetSku <String>
    -AsJob

# Define the CSV file path 
 $csvFilePath = "path\to\your\input.csv" 

# Read the CSV file 
 Write-Host "Reading CSV file..." 
 $storageAccounts = Import-Csv -Path $csvFilePath 

# Iterate through each storage account in the CSV file 
 foreach ($account in $storageAccounts) { 
     $storageAccountName = $account.'storageAccount' 
     $resourceGroupName = $account.'resourceGroup' 
     $targetSku = $account.'targetSku'
 
    Write-Host "Processing storage account: $storageAccountName in resource group: $resourceGroupName to target SKU: $targetSku"
 
    # Get the storage account 
     $storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

    # Example of adding a check for the SKU 
    if ($storageAccount.Sku.Name -ne "Standard_LRS") { 
         Write-Host "Storage account $storageAccountName is not using Standard_LRS. Skipping..." 
         continue 
     }

    # Submit the storage account SKU conversion 
     Write-Host "Submitting storage account $storageAccountName conversion to target SKU: $targetSku..." 
     Start-AzStorageAccountMigration -AccountName $storageAccountName -ResourceGroupName $resourceGroupName  -TargetSku $targetSku -NoWait 
 }

az storage account migration start  \
    --account-name <string> \
    --resource-group <string> \
    --sku <string> \
    --no-wait

# Define the CSV file path  
csvFilePath='path\to\your\input.csv'

# Read the CSV file  
echo 'Reading CSV file...'  

# Iterate through each storage account in the CSV file 
# each row should have values for storageAccountName, resourceGroupName, targetSku
while IFS=',' read -r storageAccountName resourceGroupName targetSku 
do 
    echo "Processing storage account: $storageAccountName in resource group: $resourceGroupName to target SKU: $targetSku" 
    # Get the storage account  
    sku=$(az storage account show --resource-group $resourceGroupName --name $storageAccountName  --query sku.name) 
	
    # Example of adding a check for the SKU 
    if [ $sku != '"Standard_LRS"' ] ; then 
        echo "Storage account $storageAccountName is not using Standard_LRS. Skipping..." 
        continue  
    fi 

    # Submit the storage account SKU conversion 
    echo "Submitting storage account $storageAccountName conversion to target SKU: $targetSku"  
    az storage account migration start --account-name $storageAccountName --resource-group $resourceGroupName --target-sku-name $targetSku --no-wait --yes   

    echo '--------------' 
done < <(tr -d '\r' < $csvFilePath | tail -n +2) 

Мониторинг хода выполнения преобразования, инициированного клиентом

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

¹ Преобразование обычно начинается в течение 72 часов после запуска, но может занять больше времени из-за доступности ресурсов, объема данных и других факторов. Дополнительные сведения о времени выполнения преобразования, инициированного клиентом, см. в разделе Время и частота.
² При сбое преобразования отправьте запрос на поддержку в корпорацию Майкрософт, чтобы определить причину сбоя.

Get-AzStorageAccountMigration
   -AccountName <String>
   -ResourceGroupName <String>

# Define the CSV file path 
 $csvFilePath = "path\to\your\input.csv"

# Read the CSV file 
 Write-Host "Reading CSV file..." 
 $storageAccounts = Import-Csv -Path $csvFilePath 

# Iterate through each storage account in the CSV file 
 foreach ($account in $storageAccounts) { 
     $storageAccountName = $account.'storageAccount' 
     $resourceGroupName = $account.'resourceGroup' 

     # Get the storage account migration status 
     Get-AzStorageAccountMigration -AccountName $storageAccountName -ResourceGroupName $resourceGroupName  | ft ResourceGroupName,@{Name="StorageAccountName"; Expression={$storageAccountName}},DetailMigrationStatus,DetailTargetSkuName
 }

az storage account migration show \
    --account-name <string> \
    --resource-group <string> \
    --name "default"

# Define the CSV file path 
csvFilePath="path\to\your\input.csv" 

# Read the CSV file 
echo 'Reading CSV file...' 
# Iterate through each storage account in the CSV file
# each row should have values for storageAccountName, resourceGroupName, targetSku
while IFS=',' read -r storageAccountName resourceGroupName targetSku
do
    echo "Checking status for storage account: $storageAccountName in resource group: $resourceGroupName"
    # Get the storage account 
    az storage account migration show --account-name $storageAccountName --resource-group $resourceGroupName -n default -o table

    echo '--------------'
done < <(tr -d '\r' < $csvFilePath | tail -n +2)  

Преобразование, инициированное службой поддержки

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

Выполните следующие действия, чтобы запросить преобразование от Корпорации Майкрософт:

1. В портал Azure перейдите к учетной записи хранения, которую требуется преобразовать.

2. В группе Поддержка и устранение неполадок выберите Новый запрос на поддержку.

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

   • Сводка: (некоторый описательный текст).
   • Тип проблемы: выберите Техническая.
   • Подписка: выберите подписку в раскрывающемся списке.
   • Служба: выберите "Мои службы", а затем "Управление учетными записями хранения" для типа службы.
   • Ресурс. Выберите учетную запись хранения для преобразования. Если необходимо указать несколько учетных записей хранения, это можно сделать на вкладке "Дополнительные сведения ".
   • Тип проблемы: выберите Перенос данных.
   • Подтип проблемы: выберите Миграция на ZRS, GZRS или RA-GZRS.

   

4. Выберите Далее. Вкладка "Рекомендуемое решение " может отображаться кратко перед переходом на страницу "Решения ". На странице "Решения" можно проверить соответствие учетных записей хранения для преобразования:

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

   

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

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

   

7. Укажите необходимые сведения на вкладке "Дополнительные сведения", а затем нажмите кнопку "Рецензирование" и "Создать", чтобы просмотреть и отправить запрос в службу поддержки. Агент поддержка Azure проверяет ваш случай и обращается к вам, чтобы предоставить помощь.

Ручная миграция

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

Миграцию необходимо выполнить вручную, если:

• Вы хотите перенести учетную запись хранения в другой регион.
• Ваша учетная запись хранения — это блочный BLOB-аккаунт.
• Учетная запись хранения содержит данные на уровне архива и повторное форматирование данных не нужно.

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

• Скопируйте данные с помощью существующего средства, например AzCopy, одной из клиентских библиотек служба хранилища Azure или надежного средства, отличного от Майкрософт.
• Если вы знакомы с Hadoop или HDInsight, вы можете подключить исходную учетную запись хранения и учетную запись назначения к кластеру. Затем выполните процесс копирования данных параллельно, используя такой инструмент, как DistCp.

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

Ограничения для изменения типов репликации

Ограничения применяются к некоторым сценариям изменения репликации в зависимости от следующих:

• Регион
• Конфликты компонентов
• Тип учетной записи хранения
• Уровень доступа
• Поддержка протоколов
• Переключение на резерв и возврат к основному

Область/регион

Убедитесь, что регион, в котором находится учетная запись хранения, поддерживает все требуемые параметры репликации. Например, если вы преобразуете учетную запись в зональную избыточность (ZRS, GZRS или RA-GZRS), убедитесь, что ваша учетная запись хранения находится в регионе, поддерживающем её. Ознакомьтесь со списками поддерживаемых регионов для зонально-избыточного хранилища и гео-зонально-избыточного хранилища.

Конфликты компонентов

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

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

Попытки преобразования для добавления избыточности зоны, такие как из LRS в ZRS или из GRS в GZRS, выполняются сбоем. Чтобы преобразовать учетную запись в SKU с зональной избыточностью, отключите диагностику загрузки для учетной записи и повторно отправьте запрос. Дополнительные сведения о диагностике загрузки см. в статье о диагностике загрузки Azure .

Тип учётной записи хранилища

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

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

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

¹ Преобразование, инициированное клиентом, для общих файловых ресурсов уровня "Премиум" можно выполнить с помощью портала Azure, PowerShell или Azure CLI. Можно также отправить запрос в службу поддержки.
^{Для LRS и ZRS доступны 2} управляемых диска, хотя диски ZRS имеют некоторые ограничения. Если диск LRS является региональным (не указанная зона), его можно преобразовать, изменив номер SKU. Если диск LRS зональный, его можно перенести только вручную, выполнив процесс преобразования диска из LRS в ZRS. Вы можете сохранять моментальные снимки и образы управляемых стандартных SSD-дисков в хранилище стандартных HDD-дисков с возможностью выбора между LRS и ZRS. Сведения об интеграции с группами доступности см. в статье Общие сведения об управляемых дисках Azure.
³ Если учетная запись хранения имеет версию 1, необходимо обновить ее до версии 2 перед преобразованием. Сведения об обновлении учетной записи версии 1 см. в статье "Обновление до учетной записи хранения общего назначения версии 2".
^{Не рекомендуется использовать 4} классические учетные записи хранения ZRS. Сведения о преобразовании классических учетных записей ZRS см. в разделе "Преобразование классических учетных записей ZRS".

Преобразование классических учетных записей ZRS

Классическая версия ZRS была доступна только для блочных BLOB-объектов в учетных записях хранения общего назначения версии 1 (GPv1). Дополнительные сведения об учетных записях хранения см. в статье Общие сведения об учетной записи хранения.

Классические учетные записи ZRS асинхронно реплицируют данные в центрах обработки данных в одном или двух регионах. Реплицированные данные не были доступны, пока Microsoft не инициировала переключение на вторичный узел. Классическую учетную запись ZRS невозможно преобразовать в учетную запись LRS, GRS или RA-GRS, и наоборот, никакую из этих учетных записей нельзя преобразовать в ZRS. Учетные записи ZRS Classic также не поддерживают использование метрик и ведение журналов.

Чтобы изменить ZRS Classic на другой тип репликации, используйте один из следующих методов:

• Сначала обновите его до ZRS
• Перенос данных вручную в другой тип репликации

Чтобы обновить классическую учетную запись хранения ZRS до ZRS, используйте портал Azure, PowerShell или Azure CLI в регионах, где доступны ZRS:

Set-AzStorageAccount -ResourceGroupName <resource_group> -AccountName <storage_account> -UpgradeToStorageV2

az storage account update -g <resource_group> -n <storage_account> --set kind=StorageV2

Чтобы вручную перенести данные классической учетной записи ZRS в другой тип репликации, выполните действия по миграции вручную.

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

Уровень доступа

Убедитесь, что нужный параметр избыточности поддерживает уровни доступа, используемые в настоящее время в учетной записи хранения. Например, учетные записи хранения ZRS, GZRS и RA-GZRS не поддерживают архивный уровень. Дополнительные сведения см. в статье Горячий, холодный и архивный уровни доступа к данным BLOB-объектов. Чтобы преобразовать учетную запись LRS, GRS или RA-GRS в ту, которая поддерживает зональную избыточность, сначала переместите архивные BLOB-объекты в учетную запись хранения, которая поддерживает большие двоичные объекты на уровне архивации. Затем преобразуйте исходную учетную запись в ZRS, GZRS и RA-GZRS.

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

Поддержка протоколов

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

• Поддержка протокола NFSv3 включена для объектного хранилища Azure Blob.
• Учетная запись хранения содержит файловые ресурсы Azure NFSv4.1 с включенным доступом к общедоступной конечной точке.

Преобразование разделяемых ресурсов NFSv4.1 с включёнными публичными конечными точками не поддерживается. Чтобы изменить резервирование общих папок NFS с общедоступными конечными точками, выполните следующие действия.

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

Переключение при отказе и восстановление после переключения

После автоматического переключения учетной записи на вторичный регион можно инициировать возврат отказа с нового первичного обратно на новый вторичный с помощью PowerShell или Azure CLI (версии 2.30.0 или позже). Инициируйте переключение на резервный канал.

Если вы выполнили переключение управляемой клиентом учетной записи для восстановления после сбоя учетной записи GRS или RA-GRS, учетная запись становится локально избыточной (LRS) в новом основном регионе после переключения. Преобразование учетной записи LRS в ZRS или GZRS вследствие отработки отказа не поддерживается. Вместо этого выполните ручную миграцию, чтобы добавить зональную избыточность.

Требования к простою

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

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

Время и частота

При инициировании преобразования зоны избыточности в портале Azure процесс преобразования обычно начинается в течение 72 часов после запуска, но может затянуться из-за доступности ресурсов, объема данных и других факторов. Чтобы отслеживать ход выполнения преобразования, инициированного клиентом, см. сведения о ходе выполнения преобразования, инициированного клиентом.

После преобразования избыточности зоны необходимо подождать не менее 72 часов, прежде чем снова изменить параметр избыточности учетной записи хранения. Временное удержание позволяет фоновым процессам выполняться перед внесением другого изменения, обеспечивая согласованность и целостность учетной записи. Например, переход из LRS в GZRS — это 2-шаговый процесс. Необходимо добавить избыточность зоны за одну операцию, а затем добавить геоизбыточность во вторую. После выхода из LRS в ZRS необходимо подождать не менее 72 часов, прежде чем переходить из ZRS в GZRS.

Затраты, связанные с изменением способа репликации данных

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

• Система регистрации и отслеживания (LRS)
• ZRS
• ГРС
• RA-GRS
• GZRS
• RA-GZRS

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

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

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

При удалении геоизбыточности (изменение с GRS на LRS) не начисляется плата за изменение, но реплицированные данные удаляются из вторичного расположения.

См. также

• Репликация службы хранилища Azure
• Вопросы и ответы об изменении избыточности хранилища
• Используйте геоизбыточность для разработки высокодоступных приложений
• Перемещение учетной записи службы хранилища Azure в другой регион
• Проверка свойства "Время последней синхронизации" для учетной записи хранения