Узнайте, как автоматически создавать резервные копии озера данных с помощью моментальных снимков больших двоичных объектов и инкрементных резервных копий фабрики данных
1. Резервное копирование хранилища Azure - Введение
В службе хранилища Azure всегда хранится несколько копий ваших данных. Когда используется геоизбыточное хранилище (GRS), оно также реплицируется в парный регион. Таким образом, GRS предотвращает потерю данных в случае аварии. Однако GRS не может предотвратить потерю данных, когда данные повреждены из-за ошибок приложения. Поврежденные данные затем просто реплицируются в другие зоны / регионы. В этом случае для восстановления ваших данных необходима резервная копия. Две стратегии резервного копирования заключаются в следующем:
- Создание моментального снимка: в случае добавления или изменения большого двоичного объекта создается моментальный снимок из текущей ситуации. Из-за природы капель это эффективная операция O (1). Снимки можно восстановить быстро, однако восстановление не всегда может быть выполнено (например, удаленные капли), см. Следующую стратегию.
- Инкрементное резервное копирование: в случае добавления или изменения большого двоичного объекта инкрементная резервная копия создается в другой учетной записи хранения. Копирование больших двоичных объектов - дорогостоящая операция O (N), но ее можно выполнить асинхронно с помощью фабрики данных Azure. Восстановление может быть выполнено путем копирования больших двоичных объектов.
В этом блоге обсуждается, как можно создавать моментальные снимки и инкрементные резервные копии из учетной записи хранения, см. Также обзор, изображенный ниже.
Для поддержки создания автоматических снимков и инкрементного резервного копирования вашей учетной записи хранения используются три типа сценариев, которые обсуждаются в оставшейся части этого блога:
- Сценарий на основе событий, запускаемый производителем для создания моментальных снимков и запросов инкрементного резервного копирования после приема / изменения данных
- Сценарий триггера очереди, который создает инкрементные резервные копии с помощью ADFv2
- Сценарий на основе времени, запускаемый администратором для согласования отсутствующих снимков / добавочных резервных копий
Обратите внимание, что моментальные снимки больших двоичных объектов поддерживаются только в обычных учетных записях хранения и еще не поддерживаются в ADLSgen2 (но ожидается, что они также станут доступны в ADLSgen2). Таким образом, сценарии основаны на обычных учетных записях хранения, подробное объяснение сценариев можно найти ниже. Также обратите внимание, что скрипты предназначены для создания снимков / резервных копий, а не для их восстановления.
2. Запросы на моментальные снимки / инкрементные резервные копии на основе событий
В озере данных данные обычно загружаются с помощью фабрики данных Azure поставщиком. Для создания запускаемых по событию моментальных снимков / инкрементных резервных копий необходимо развернуть следующее:
- Разверните следующий скрипт как функцию Azure в Python. См. Эту ссылку, как создать функцию Azure в Python. См. Другой мой блог о том, как защитить Функции Azure.
- Добавьте функцию Azure в качестве связанной службы в свой экземпляр фабрики данных Azure и добавьте функцию Azure в качестве последнего шага в свой конвейер приема.
- Создайте две учетные записи хранения: исходное хранилище и хранилище резервных копий. Также создайте очередь хранения для обработки сообщений запроса резервного копирования.
Теперь каждый раз, когда новые данные загружаются с помощью ADFv2, вызывается функция Azure, которая создает моментальный снимок и отправляет запрос инкрементного резервного копирования для новых / измененных больших двоичных объектов, см. Также ниже.
Внутреннюю работу скрипта HttpSnapshotIncBackupContainerProducer можно объяснить следующим образом:
- 0. Скрипт инициализации моментального снимка / резервного копирования проверяет наличие измененных / новых больших двоичных объектов в контейнере учетной записи хранения, сравнивая ETag большого двоичного объекта с предыдущими снимками (если есть). В случае обнаружения измененного / нового большого двоичного объекта выполняются следующие 2 шага:
- 1а. Создать снимок из измененного / нового большого двоичного объекта
- 1b. Отправить сообщение с запросом инкрементного резервного копирования в очередь хранилища. Сообщение запроса резервного копирования содержит только метаданные измененного большого двоичного объекта.
Суть скрипта такова:
# Get all blobs in container prev_blob_name = "" prev_blob_etag = "" blob_list = container.list_blobs(include=['snapshots']) for blob in blob_list: if blob.snapshot == None: # Blob that is not snapshot if prev_blob_name != blob.name: # New blob without snapshot, create snapshot/backup create_snapshot_backup(blob.name, blob.etag) elif prev_blob_etag != blob.etag: # Existing blob that has changed, create snapshot/backup create_snapshot_backup(blob.name, blob.etag) prev_blob_name = blob.name prev_blob_etag = blob.etag
Обратите внимание, что только управляемое удостоверение поставщика ADFv2 и управляемое удостоверение функции Azure имеют доступ на запись в этот контейнер. Триггеры BLOB-объектов не работают в этом сценарии, поскольку при изменении BLOB-объектов не запускаются никакие события.
Асинхронное создание инкрементной резервной копии обсуждается в следующей главе.
3. Создание инкрементной резервной копии
Как только новый запрос инкрементного резервного копирования добавлен в очередь хранения, это сообщение должно быть обработано так, чтобы было создано инкрементное резервное копирование. При этом должны быть задействованы:
- Разверните следующий скрипт как функцию Azure, запускаемую очередью в Python. Можно использовать тот же план службы приложений, что и на шаге 2.
- Убедитесь, что все необходимые настройки приложения заполнены правильно, см. Здесь
- Разверните конвейер ADFv2, который создает инкрементные резервные копии путем копирования больших двоичных объектов из исходной учетной записи хранилища в учетную запись хранилища резервных копий.
- Убедитесь, что вы назначаете Управляемую идентификацию вашей функции Azure и что функция Azure имеет роль RBAC Участник для ее запуска.
Теперь каждый раз, когда новое сообщение запроса инкрементного резервного копирования поступает в очередь хранилища, запускается функция Azure, которая вызывает конвейер ADFv2, который создает добавочную резервную копию, см. Также ниже.
Работу скрипта QueueCreateBlobBackupADFv2 можно объяснить следующим образом:
- 2а. Очередь хранилища получает новое сообщение запроса резервного копирования для большого двоичного объекта. Обратите внимание, что сообщения могут обрабатываться параллельно.
- 2b. Функция Azure забирает сообщение из очереди хранилища и проверяет, не устарел ли запрос на резервное копирование. Затем он запускает конвейер ADFv2, используя REST API и управляемую идентификацию функции Azure.
- 2c. ADFv2 запускает операцию копирования, копируя большой двоичный объект из исходной учетной записи хранилища в учетную запись хранилища резервных копий.
На шаге 2b также можно решить запустить режим blob_lease, который исключительно блокирует файл и гарантирует, что правильная версия файла будет добавлена в учетную запись хранилища резервных копий. Использование аренды больших двоичных объектов зависит от множества факторов (например, максимально допустимого времени аренды, размера файла, количества заданий, неизменности).
Суть скрипта такова:
USING_BLOB_LEASE = True # check if source blob has not changed in the meantime if source_blob_changed(blob_name, blob_etag) == True: return # Start copying using ADFv2 try: if not USING_BLOB_LEASE: # Copy without locking the file copy_adf_blob_source_backup(blob_name, blob_etag) else: # Copy with blob lease locks the file copy_with_lease(blob_name, blob_etag) except: logging.info("copy failed")
В предыдущих двух главах обсуждалось, как можно создавать моментальные снимки и инкрементные резервные копии, когда производитель добавляет новые данные в озеро данных с помощью ADFv2. Однако может также возникнуть необходимость в запуске моментальных снимков / инкрементных резервных копий, основанных на времени. Об этом мы поговорим в следующей главе.
4. Запросы на моментальные снимки / инкрементные резервные копии, запускаемые по времени.
В главе 2 обсуждается, как производитель может создавать моментальные снимки на основе событий / запросы инкрементного резервного копирования. Однако также необходим сценарий согласования, который может создавать отсутствующие снимки состояния и / или отсутствующие резервные копии. Это может произойти, если производитель забывает добавить функцию Azure в свой конвейер приема и / или скрипт не запускается. Для создания функции, основанной на времени, должно быть развернуто следующее:
- Разверните следующий скрипт как функцию Azure в Python. Можно использовать тот же план службы приложений, что и на шаге 2.
- Убедитесь, что все необходимые настройки приложения заполнены правильно, см. Здесь
Теперь администратор может настроить периодический запуск сценария согласования, чтобы создавались моментальные снимки и отправлялся запрос на инкрементное резервное копирование, см. Также ниже.
Внутреннюю работу скрипта HttpSnapshotIncBackupStorageReconciliation можно объяснить следующим образом:
- 0. Сценарий инициализации моментального снимка / резервного копирования проверяет наличие измененных / новых больших двоичных объектов в учетной записи хранения, сравнивая ETag большого двоичного объекта с предыдущими снимками (если есть). В случае обнаружения измененного / нового большого двоичного объекта выполняются следующие 2 шага:
- 1а. В случае обнаружения измененного / нового большого двоичного объекта, у которого еще нет снимка, создается новый снимок:
- 1b. В случае обнаружения измененного / нового большого двоичного объекта, у которого еще нет инкрементной резервной копии, отправляется сообщение с новым запросом на резервное копирование.
Суть скрипта такова:
# Get all containers in storage account container_list = client_source.list_containers() for container in container_list: # Get all blobs in container prev_blob_name = "" prev_blob_etag = "" blob_list = container.list_blobs(include=['snapshots']) for blob in blob_list: if blob.snapshot == None: # Blob that is not snapshot # 1. Check if snapshot needs to be created if prev_blob_name != blob.name: # New blob without snapshot, create snapshot create_snapshot(blob.name, blob.etag) elif prev_blob_etag != blob.etag: # Existing blob that has changed, create snapshot create_snapshot(blob.name, blob.etag) # 2. Check if incremental backup needs to be created # Check if blob exists in backup blob_exists = check_blob_exists(blob.name, blob.etag) if blob_exists == False: # Not in backup, put backup request message on queue queue_json = "{" + "\"container\":\"{}\", \"blob_name\":\"{}\", \"etag\":\"{}\"" .format(container.name, blob.name, blob.etag) + "}" queue_service.put_message(queue, queue_json) prev_blob_name = blob.name prev_blob_etag = blob.etag
5. Заключение
В службе хранилища Azure всегда хранится несколько копий ваших данных, а геоизбыточное хранилище (GRS) дополнительно хранит копии в парном регионе. Однако хранилище GRS не защищает данные от повреждения из-за ошибок приложения. Поврежденные данные затем просто реплицируются в другие зоны и регионы. Два измерения, которые могут защитить от повреждения данных, следующие:
- Создание моментального снимка: после добавления или изменения большого двоичного объекта создается моментальный снимок для текущей ситуации.
- Инкрементное резервное копирование: после добавления или изменения большого двоичного объекта создается инкрементная резервная копия большого двоичного объекта для другой учетной записи хранения.
В этом блоге обсуждается, как можно создавать синхронные снимки и асинхронные инкрементные резервные копии с помощью скриптов в этом гитхабе. См. Также расширенный обзор высокого уровня, изображенный ниже.