Для корпоративных систем с ожиданиями, требованиями или обязательствами по доступности критически важен четко определенный, действенный и хорошо проверенный подход к резервному копированию и аварийному восстановлению (DR). Разработка стратегии резервного копирования или подхода к аварийному восстановлению требует, чтобы организации сначала понимали масштабы и зависимости своих систем, прежде чем тщательно устанавливать цели восстановления, понимать доступные ИТ-ресурсы и учитывать процесс восстановления, начиная с запуска резервного копирования или восстановления и заканчивая возможностью поддержки персонала и воздействия на пользователей.
Важность или роль резервного копирования в первую очередь связана с бизнес-критичностью системы, а также с тем, какие рабочие процессы она поддерживает, и с категориями данных, которые в ней хранятся. Некоторые системы, такие как сервер разработки или сервер, используемый небольшой группой, могут не нуждаться в стратегии резервного копирования, в то время как другие системы могут использовать подходы резервного копирования и аварийного восстановления в первую очередь для тестирования процессов и информирования об их успешном применении в производственной системе.
В этом разделе представлен обзор процесса резервного копирования и аварийного восстановления, включая последствия для компонентов программного обеспечения ArcGIS и доступные варианты поддержки резервного копирования или аварийного восстановления для различных приложений ArcGIS.
Процесс резервного копирования системы, фрагмента данных или аппаратного компонента всегда был важен для ИТ-систем. Несмотря на то, что исторически резервное копирование в основном осуществлялось на уровне хранилища, распространение облачных сервисов привело к появлению нескольких новых возможностей, связанных с резервным копированием, в первую очередь в связи с необходимостью резервного копирования облачных данных и систем SaaS, а также новых местоположений и поставщиков, которые могут использоваться для хранения резервных копий на уровне данных.
Рекомендации по резервному копированию включают тщательное определение следующих параметров:
Кроме того, важен метод, используемый для восстановления системы из резервной копии, а также влияние, которое он оказывает на пользователей.
Исторически сложилось так, что надежное резервное копирование осуществлялось только в наиболее важных бизнес-системах или данных, поэтому объем резервного копирования был сосредоточен на наиболее важных системах, серверах или базах данных. В связи с тем, что стоимость хранения данных в настоящее время значительно ниже, чем в прошлом, объем резервного копирования значительно расширился, в сторону резервного копирования всей системы, а не выборочного резервного копирования одного компонента приложения или типа данных.
Методы, используемые для создания резервных копий, могут быть самыми разными: от форматов резервных копий для конкретных приложений, таких как дамп двоичной базы данных, до образов виртуальных машин, резервных копий конфигураций или составных резервных копий, которые могут объединять состояние приложения с данными и самим кодом приложения. Метод, используемый для создания резервных копий, может оказывать значительное влияние на время, необходимое для создания резервной копии, его частоту, а также способ восстановления. Резервные копии также могут различаться по способу их создания и тому, насколько хорошо они отражают состояние работающей системы. Существует три основных типа резервного копирования, которые следует учитывать в системах ArcGIS:
Частота резервного копирования системы и время инициации резервного копирования также являются важными факторами. Слишком частое резервное копирование может привести к чрезмерным затратам или частым перебоям в работе системы, в то время как слишком редкое резервное копирование может привести к недопустимой потере данных между сбоем и последним резервным копированием. Большинство резервных копий разработаны таким образом, чтобы не прерывать работу пользователей на каком-либо уровне, но время резервного копирования может повлиять на то, какие данные и рабочие процессы будут захвачены в резервной копии. Обычно резервные копии делаются в «нерабочие часы» системы (если таковые существуют), чтобы зафиксировать большую часть данных и информации за предыдущий день, а не в середине рабочего дня, когда резервное копирование может захватить только часть более длительного процесса или большого набора данных, над которым активно ведется работа.
Причина, по которой существует процесс резервного копирования, может показаться самоочевидной, например, для восстановления состояния системы, но резервные копии дополнительно используются для различных целей. Некоторые резервные копии привязаны к обновлениям системы, поэтому в случае обнаружения проблемы с обновлением систему можно вернуть в известное состояние. То же самое соображение обусловливает процессы резервного копирования, связанные с деструктивными изменениями в системе, такими как удаление сервера или добавление нового компонента. Некоторые резервные копии создаются только на случай наихудшего сценария, так что в случае аварии их можно использовать для восстановления после нее. Другие используются для создания моментального снимка состояния среды и создания новой, более низкой среды в виде копии или для продвижения ресурсов в обратном направлении из более низкой среды в систему более высокого производственного уровня.
Аварийное восстановление или DR — это тема, которая часто тесно связана с процессом резервного копирования и восстановления, но они не являются синонимами. В частности, DR относится к тому, «что мы делаем для восстановления после аварии», к процессу, который потребуется для восстановления, и к определению того, что означают термины «авария» и «восстановление» в контексте конкретной организации. Аварийные ситуации обычно относятся к значительным сбоям в работе ИТ-системы, вызванным проблемами с оборудованием, окружающей средой или пользовательской конфигурацией, которые приводят к значительному прерыванию времени бесперебойной работы, доступности или функциональности системы.
Одним из первых шагов в создании процесса аварийного восстановления является то, что представляет собой «авария», которая требует процесса аварийного восстановления. Важно тщательно определить это понятие, так как слишком чувствительное определение (например, один неудачный запрос к основной системе) может привести к частым действиям аварийного переключения, а ожидание до тех пор, пока сбой не превысит четыре часа, может оказаться слишком свободным и привести к длительному прерыванию работы пользователя. В конечном счете, определение того, «что представляет собой авария», чтобы система могла предпринять действия для инициирования восстановления или переключения на другой ресурс, включает в себя как автоматизированное, так и управляемое человеком принятие решений, а также будет опираться на организационные определения таких понятий, как доступность, критичность и время безотказной работы. Типичными примерами «инициатора» аварийного восстановления могут быть потеря доступа к центру обработки данных, сбой хранилища, сбои гипервизора виртуальных машин, сбой DNS или проблемы с сетевым подключением, а также повреждение данных или атака программ-вымогателей на систему.
Еще одним ключевым определением в процессе аварийного восстановления является целевая точка восстановления (RPO) и целевое время восстановления (RTO) организации. RPO приравнивается к тому, сколько данных мы теряем в случае аварии , и относится к типу создаваемых резервных копий и частоте резервного копирования данных или конфигураций. RPO в четыре часа будет означать, что в худшем случае четыре часа данных или работы будут потеряны при сбое на уровне аварийного восстановления, и организация может потерять эти 4 часа данных или входных данных в процессе аварийного восстановления. Несмотря на то, что низкий RPO кажется очевидным подходом, в большинстве систем сложность резервного копирования и возможность прерывания работы пользователей означают, что низкий RPO имеет слишком высокие затраты на ресурсы, хранилище или влияние на пользователя.
RTO — это время, затраченное на восстановление резервных копий в системе аварийного восстановления, создание новой системы с нуля или автоматическое развертывание ресурсов для восстановления после аварии. RTO часто ниже RPO, так как отказоустойчивая система или ее компоненты могут уже существовать, и для переключения на эту систему требуется только изменение DNS или сети. Определение и достижение реалистичных RPO и RTO являются важными частями построения стратегии DR, а также получения согласия заинтересованных сторон относительно стоимости и последствий для рабочего процесса реализации этой стратегии.
Одним из распространенных подходов к реагированию на аварийный сценарий является переключение трафика на отказоустойчивую систему, которая предназначена для приема трафика, когда основная система обнаруживает или испытывает проблемы. Этот подход имеет несколько важных требований, которые влияют на затраты и рабочий процесс:
Другой подход к аварийному восстановлению заключается в использовании резервных копий для восстановления системы, что может привести к увеличению RTO, но снижает текущие затраты, поскольку система аварийного переключения не поддерживается постоянно. Он может включать в себя создание резервных копий виртуальных машин или резервных копий на уровне приложений, а затем перестроение системы либо автоматически с помощью автоматизации развертывания инфраструктуры как кода и программного обеспечения, либо вручную с помощью опытной команды, прежде чем резервная копия будет восстановлена, трафик будет переключен обратно в систему, и пользователи смогут возобновить рабочие нагрузки в системе.
Процессы аварийного восстановления также могут иметь более широкие последствия или подходы, которые не являются уникальными для многопользовательской системы, созданной с помощью ArcGIS. Например, весь центр обработки данных может иметь стратегию аварийного восстановления, которая использует репликацию виртуальных машин для обслуживания набора виртуальных машин в отдельном центре обработки данных, и при обнаружении сбоя в компоненте хранилища или гипервизора все пользователи могут переключиться на доступ к дополнительному центру обработки данных.
Процессы аварийного восстановления также должны учитывать то, что происходит после восстановления. Если имеется основная система или центр обработки данных, а событие аварийного восстановления приводит к переключению на резервную систему, является ли стандартным подход к переключению трафика обратно на основные системы после устранения сбоя? Или резервная система теперь становится основной, а исходная система настраивается как резервная для поддержки следующей ситуации с аварийным восстановлением? Оба сценария имеют ценность, и определение того, что произойдет после разрешения инцидента, является важной частью разработки стратегии и подхода к аварийному восстановлению.
В системах ArcGIS существует несколько подходов к инициированию процесса резервного копирования, которые встроены в программное обеспечение ArcGIS. Однокомпонентное резервное копирование, которое создает резервные копии только содержимого и состояния одного приложения, доступно для компонентов ArcGIS Enterprise, включая Portal for ArcGIS, ArcGIS Server и ArcGIS Data Store. Эти резервные копирования для конкретных компонентов в первую очередь не предназначены для аварийного восстановления, а предназначены для резервного копирования и восстановления на месте - для целей аварийного восстановления рекомендуется использовать инструмент WebGISDR. Каждый компонент имеет свой подход к резервному копированию, в том числе:
Некоторые роли ArcGIS Server, как правило, не имеют состояния, где все соответствующие конфигурации хранятся в виде элементов портала и, как правило, не нуждаются в резервном копировании. К ним относятся Notebook Server, Business Analyst Enterprise Server (GeoEnrichment Server) и Raster Analytics Server. Каждый из этих компонентов обычно может быть воссоздан с пустого компьютера или установленного образа вместо восстановления конкретного развертывания, поскольку ресурсы хранятся в ArcGIS Enterprise. Единственное соображение, выходящее за рамки этого, — это сценарии, в которых пользовательский код или сторонние библиотеки были развернуты в системе для обеспечения рабочего процесса на основе Python или другого процесса.
Помимо функциональности резервного копирования для конкретных компонентов, ArcGIS Enterprise также имеет многокомпонентный инструмент резервного копирования под названием Web GIS Disaster Recovery tool (сокращенно WebGISDR), который может выполнять резервное копирование состояния нескольких различных компонентов ArcGIS Enterprise одновременно.
Инструмент WebGISDR полностью описан в документации ArcGIS Enterprise, но важно отметить, что этот инструмент отдает приоритет коллективной согласованности и состоянию приложения, а не скорости резервного копирования или гибкости процесса. На практике это означает, что инструмент пытается зафиксировать состояние системы точно в тот момент, когда был выполнен запрос. Если во время резервного копирования будет опубликовано дополнительное содержимое или данные, они не будут отображаться ни в одном из файлов резервных копий и не будут подлежать восстановлению в системе аварийного переключения. Этот акцент аналогичен фокусу на RPO вместо RTO, когда приоритет отдается функциональной полноте системы, а не скорости восстановления системы (что может привести к неправильным конфигурациям или плохим данным).
Помимо резервного копирования для конкретных приложений ArcGIS, существует множество других методов, которые могут быть предложены или предпочтительны для организации, которые могут быть встроенными для конкретного компонента или поставщика инфраструктуры. Эти методы могут подойти для резервного копирования ArcGIS или процесса аварийного восстановления, но их следует тщательно оценить и рассмотреть, поскольку их использование также может нарушить работу системы.
Например, моментальные снимки виртуальных машин являются распространенным подходом к резервному копированию системы, но могут создавать сложные проблемы, если метод создания моментального снимка включает внезапный перезапуск компьютера или захватывает только состояние данных, так как внутрипроцессные операции или конфигурации могут не быть записаны или частично захвачены, что может привести к неожиданному и поврежденному состоянию при восстановлении.
Стратегии резервного копирования на основе виртуальных машин иногда перемещают ресурсы виртуальных машин между двумя источниками данных, чтобы предотвратить сбой. В этих сценариях убедитесь, что хосты ArcGIS Server и ArcGIS Pro обращаются к базе данных в своем собственном центре обработки данных, не выполняя запросы к исходному центру данных, так как это приведет к задержке, которая негативно повлияет на взаимодействие с пользователем.
Облачные инструменты резервного копирования и аварийного восстановления, такие как Microsoft Azure Site Recovery, могут быть совместимы с системами ArcGIS Enterprise, если они тщательно спланированы таким образом, чтобы разрешение DNS, подключение к базе данных и подключение клиентов к системе сохранялись в случае операции восстановления сайта. Эти подходы к резервному копированию работают при относительно низком уровне доступа к виртуальной машине, поэтому они не обеспечивают гарантий согласованности приложений. Это означает, что, хотя система восстановления часто успешно восстанавливается и эксплуатируется, в некоторых случаях могут возникать несоответствия на уровне приложений, т.е. процесса публикации или редактирования сервисов объектов, который выполняется в процессе резервного копирования. Существуют способы планирования, такие как создание моментальных снимков виртуальных машин в периоды наименьшей нагрузки, но в целом рекомендации по «планированию, тестированию и тщательному анализу последствий» применимы к этим подходам с использованием внешних инструментов.
Поставщики баз данных, которые создают реляционные базы данных, с которыми работает ArcGIS (либо в качестве многопользовательской базы геоданных, либо в качестве источника слоя запроса), предоставляют свои собственные варианты резервного копирования для конкретной базы данных, которые обычно могут создать файловую резервную копию содержимого базы данных и конфигураций для восстановления в новой системе или развертывания при необходимости.
ArcGIS Online, как предложение и система SaaS, нуждается в другом подходе с точки зрения резервного копирования и восстановления. В рамках обеспечения стабильности системы Esri выполняет требования к резервному копированию и восстановлению в случае сбоев оборудования и системного уровня без участия пользователя, и Договор о сервисном обслуживании для ArcGIS Online отражает это обязательство. В настоящее время ArcGIS Online не предоставляет пользователям метод создания резервных копий или резервных копий ресурсов в масштабах всей организации, и организациям необходимо будет определить стратегию для собственного дополнительного резервного копирования ресурсов или конфигураций в ArcGIS Online с помощью различных схем, в том числе:
Обратите внимание, что партнеры Esri также создали решения для резервного копирования, которые можно просмотреть или приобрести через ArcGIS Marketplace.
В ArcGIS Online недавно появилась функция Корзина, которая будет хранить удаленные ресурсы в течение 14 дней (по умолчанию) перед безвозвратным удалением. Содержимое корзины может быть восстановлено до прежнего состояния и местоположения с помощью простого рабочего процесса. Это поможет предотвратить удаление ресурса, который связан с другим ресурсом, но четко не определен как зависящий от этого другого ресурса или полагающийся на него.
Для основных данных размещенного сервиса объектов использование возможности Отслеживание изменений для сохранения содержимого предыдущих строк по мере внесения изменений. Доступ к этим предыдущим версиям можно получить с помощью операции извлечения изменений .