Поскольку развертывание ArcGIS Enterprise становится все более сложным, то когда речь идет об аварийном восстановлении, следует учитывать дополнительные факторы. Они требуют понимания неравномерных систем, формирующих архитектуру развертывания. Как и во многих технических сценариях, не существует универсального подхода к резервному копированию основных и зависимых систем в развертывании.
Ниже представлена структура, которая с высокой долей вероятности позволит выполнить успешное восстановление при аварии. Эти методы могут использоваться организациями для определения своих стандартных операционных процедур в рамках плана обеспечения непрерывности бизнеса/аварийного восстановления (BC/DR) в случае аварии для их развертывания ArcGIS Enterprise.
Рекомендации по созданию резервных копий
Изучите следующие рекомендации для создания резервных копий вашей организации ArcGIS Enterprise и связанные источники данных.
Резервная копия ArcGIS Enterprise
Организация ArcGIS Enterprise состоит из сайтаPortal for ArcGIS, всех интегрированных сайтов ArcGIS Server и связанных с ними данных, а также данных, которые хранятся в ArcGIS Data Store. Для этих компонентов можно выполнить резервное копирование с помощью встроенного инструмента Web GIS Disaster Recovery (WebGISDR), либо используя сторонние инструменты для резервного копирования на основе машин и образов.
Инструмент WebGISDR - это утилита командной строки, входящая в Portal for ArcGIS, которая используется для резервного копирования ресурсов и данных организации, информации интегрированного сайта ArcGIS Server и данных, которые находятся в реляционных хранилищах данных и хранилищах данных полистного кэша. Этот инструмент особенно полезен для обеспечения согласованности компонентов базового развертывания, а также любых дополнительных интегрированных сайтов, хотя для выполнения восстановления требуется функциональное развертывание.
Вне процесса резервного копирования WebGISDR следует учитывать, что:
- Интегрированные сайты ArcGIS Mission Server или сайты ArcGIS Notebook Server — Если у вас есть любой из них, создайте резервные копии, следуя инструкциям в документации ArcGIS Mission Server и документации ArcGIS Notebook Server.
- Резервные копии пространственно-временных хранилищ больших данных, хранилищ графов и объектов — если на сервере хостинга зарегистрирован какой-либо из этих типов ArcGIS Data Store, создайте резервные копии каждого из них с помощью утилиты ArcGIS Data Store backupdatastore.
- Конфигурация сайта ArcGIS GeoEvent Server —управляйте резервной копией конфигурации ArcGIS GeoEvent Server с помощью файла конфигурации резервной копии.
Большинство платформ виртуализации позволяют делать моментальные снимки работающих виртуальных машин, что позволяет сократить время восстановления. Хотя это и полезно, они не считаются надежными резервными копиями как часть более крупного плана BC/DR.
При создании резервной копии до или во время периода обслуживания целевое минимальное время восстановления, обеспечиваемое моментальными снимками, служит мотивацией для использования этих инструментов, когда они доступны. При выполнении стороннего резервного копирования базовые компоненты уровня данных Portal for ArcGIS и ArcGIS Data Store не интегрированы с этими методами и, следовательно, сопряжены с определенным уровнем риска, связанным с созданием динамического резервного копирования работающей базы данных. Чтобы свести к минимуму этот риск, моментальные снимки и резервные копии на основе образов следует делать после остановки службы для запущенных компонентов ArcGIS Enterprise.
В случае архитектур, использующих общий файловый ресурс для размещения общего каталога содержимого портала или хранилища конфигурации и корневых каталогов для сайтов ArcGIS Server, важно учитывать согласованность резервных копий этих расположений при использовании сторонних инструментов резервного копирования, таких как виртуальные моментальные снимки машины или резервные копии на основе образов. Например, если администратор выполняет откат после неудачного обновления Portal for ArcGIS путем восстановления моментального снимка, каталог содержимого может быть изменен в процессе обновления и больше не будет соответствовать информации, содержащейся в базе данных на восстановленном экземпляре. Чтобы минимизировать эти эффекты при использовании сторонних инструментов, резервные копии следует делать во время перерыва в работе, когда в организации не публикуется и не редактируется контент. Сюда входят оба компонента ArcGIS Enterprise, а также любые связанные хранилища файлов.
Можно создать резервную копию ArcGIS Data Store отдельно от других компонентов, чтобы свести к минимуму потерю данных в случае сбоя в этом компоненте. Выполнение планового резервного копирования реляционных хранилищ данных и хранилищ данных полистного кэша может происходить вне расписания утилиты WebGISDR и других инструментов резервного копирования.
Резервное копирование связанных источников данных
ArcGIS Server может обслуживать контент ресурсы из многих источников, включая многопользовательские базы геоданных, зарегистрированные общие папки и облачные хранилища. Эти внешние источники данных должны быть включены в план аварийного восстановления развертывания. Рекомендуется следовать инструкциям поставщика по резервному копированию или репликации данных в другое место.
Для многопользовательских баз геоданных и реляционных баз данных, содержащих данные, обслуживаемые связанными сервисами, необходимо выполнить резервное копирование в соответствии с целями точки восстановления каждой организации с помощью инструментов, предоставляемых поставщиками реляционных баз данных. Поскольку на эти данные ссылаются сервисы ArcGIS Server, согласованность опубликованных сервисов потенциально может не синхронизироваться с внутренними таблицами базы данных, если восстановление базы данных выполняется независимо от сайтов, содержащих опубликованные сервисы. Поэтому важно согласовать расписание резервного копирования для всех компонентов развертывания ArcGIS Enterprise.
Общие сетевые файловые ресурсы могут использовать инструменты резервного копирования на основе образа или файловой системы для упаковки данных, а затем переноса в надежное решение для хранения, которое существует за пределами домена сбоя развертывания.
Облачные хранилища должны быть скопированы или реплицированы в другой регион, чтобы вы могли восстановить их содержимое. Реплицированные хранилища также могут быть развернуты с использованием архива или холодного хранилища для снижения общей стоимости.
Когда выполнять резервное копирование
Частота создания резервной копии зависит от нескольких факторов, наиболее важным из которых является время, необходимое для создания резервной копии. Поскольку процессы резервного копирования могут влиять на использование системных ресурсов, полное резервное копирование обычно планируется в нерабочее время. Для разных типов резервного копирования частота резервного копирования системы может различаться в зависимости от развертывания ArcGIS Enterprise.
Например, производственная многопользовательская база геоданных может выполнять постепенное резервное копирование каждые 15 минут в целях получения низкой точки восстановления. Наиболее важные данные должны храниться в этом экземпляре базы данных, чтобы уменьшить объем потенциальной потери данных. Для развертывания ArcGIS Enterprise с большим числом сервисов по ссылкам и статическим содержимым частота резервного копирования может быть ежедневной или еженедельной, в то время как для развертываний с интенсивным использованием размещенных сервисов объектов и частым созданием веб-карт и приложений следует ориентироваться на более короткое время между резервными копиями.
Проверка резервных копий
Необходимо отслеживать успешное завершение резервного копирования и оповещать администраторов в случае сбоя. Для инструмента WebGISDR код выхода из запуска скрипта может использоваться как показатель того, успешно ли завершено резервное копирование. Нуль представляет собой успешное резервное копирование, а любой ненулевой код указывает на сбой. Существует несколько инструментов оповещения, которые можно интегрировать, чтобы разрешить отправку уведомлений по электронной почте или SMS команде, отвечающей за целостность резервной копии. Многие сторонние инструменты резервного копирования предоставляют аналогичные функции или могут быть интегрированы с другими службами для отправки предупреждений.
Другим важным аспектом проверки плана BC/DR организации является выполнение тренировки восстановления с полурегулярной частотой. Это помогает администраторам гарантировать, что в случае аварии они будут готовы к восстановлению из функциональных резервных копий и проверить план восстановления, описанный ниже.
Как долго хранить файлы резервных копий
Решение вопроса, как долго следует хранить резервные копии, зависит от наличия свободного места на диске и от необходимого вам уровня эластичности возможностей восстановления. Если вам не потребуется восстановление до состояния, предшествующего времени создания последней полной резервной копии, то можно хранить последнюю полную резервную копию и созданные позднее архивы накопившихся с тех пор изменений.
Накопительные архивы, созданные с помощью инструмента WebGISDR, являются кумулятивными; самый последний накопительный архив может быть применен к последней полной резервной копии. Поэтому, как минимум, необходимо хранить последнюю полную резервную копию и самый последний созданный с тех пор накопительный архив.
Некоторые более старые резервные копии можно перемещать в другие папки, например, в медиа хранилище. Таким образом, если вы обнаружите, что ключевые данные или сервисы удалены раньше полной резервной копии, эти файлы будут все равно вам доступны.
Примечание:
Утилита WebGISDR записывает версии программного обеспечения компонентов ArcGIS Enterprise при создании резервной копии. Развёртывание, в которое вы выполняете восстановление, должно быть той же версии, которая у него была при создании резервной копии. Дополнительно вам необходимо вернуться к тому же типу операционной системы. Например, вы не можете создать резервную копию развёртывания ArcGIS Enterprise на Linux и восстановить её на машинах с Windows.
Рекомендации по восстановлению данных вашей организации
Ознакомьтесь со следующими рекомендациями по восстановлению организации ArcGIS Enterprise с помощью созданных резервных копий.
Что следует восстанавливать
Когда в распоряжении администратора есть несколько типов резервных копий, можно восстанавливать отдельные компоненты, а не выполнять откат всего развертывания. Если кеш картографического сервиса или сервиса изображений удален, из резервной копии необходимо восстановить только эти файлы. Точно так же, если таблица случайно удалена из многопользовательской базы геоданных, эту базу данных можно восстановить, не затрагивая другие компоненты.
Если в размещенный векторный слой внесены неверные правки и данные необходимо откатить, администратор может восстановить только реляционное хранилище данных, не восстанавливая все развертывание ArcGIS Enterprise. Это снижает влияние восстановления на другие данные, хранящиеся в базе данных, но если в это время были созданы размещенные сервисы, то это может привести к тому, что сайт ArcGIS Server станет несовместимым с восстановленными таблицами базы данных, и потребуется ручная очистка и повторная публикация затронутых сервисов.
В других случаях может произойти значительный сбой, например, в центре обработки данных или облачном регионе, который требует восстановления всего развертывания ArcGIS Enterprise, а также любых внешних источников данных. Это самый экстремальный пример, требующий адекватного планирования для обеспечения полной функциональности восстанавливаемой среды.
Как выполнять восстановление
Когда развертывание ArcGIS Enterprise сталкивается с масштабным сбоем, существует несколько вариантов восстановления, которые зависят от доступных типов резервных копий. Репликация на ближайшую площадку с помощью утилиты WebGISDR является наиболее важным методом экономии времени восстановления развертывания, в то время как наличие площадки с холодным резервом, доступной для развертывания и восстановления, может облегчить как отработку восстановления, так и сократить общее время восстановления.
При выборе пути к восстановлению в первую очередь следует попробовать вариант с кратчайшими точками восстановления и временными целями. Это позволит максимально быстро получить обратную связь об успешности восстановления. Наличие администратора, знакомого со стратегией резервного копирования, который регулярно тестировал восстановление в прошлом, также может сократить время, необходимое для восстановления в аварийном сценарии.
Поскольку у ArcGIS Enterprise есть несколько уровней как для внутренних, так и для внешних компонентов, порядок, в котором эти компоненты восстанавливаются, влияет на стабильность развертывания после восстановления. Все указанные источники данных должны быть доступны в первую очередь и должны быть проверены на доступность из среды ArcGIS Enterprise, включая экземпляры базы данных и внешние общие файловые ресурсы, до восстановления компьютеров и компонентов ArcGIS Enterprise.
После установки окружающих зависимостей развертывание ArcGIS Enterprise должно быть восстановлено до согласованного состояния. Это делается для того, чтобы избежать сценариев, в которых на сайте хост-сервера может быть опубликован размещенный сервис объектов, но в реляционном хранилище данных отсутствует зависимая таблица данных, или в организации может быть элемент для сервиса, которого больше нет ни в одном из интегрированных сайтов.
Проверка после восстановления
После завершения операции восстановления необходимо выполнить проверку критически важных для бизнеса данных и общих функциональных возможностей развертывания ArcGIS Enterprise. Это может быть достигнуто путем создания контрольных списков для бизнес-центров и отделов для проверки их наиболее важного содержимого или автоматизации с помощью скриптов . Подход к этой проверке с использованием автоматических скриптов обеспечивает большую уверенность в том, что восстановление прошло успешно за меньшее время, чем ручная проверка элементов и сервисов.
Автоматизация операций резервного копирования и восстановления
Рекомендуется регулярно создавать резервные копии, чтобы защититься от значительной потери данных и сократить время простоя. Как часто вы будете создавать резервные копии, определяется допустимой потерей данных для вашей организации (RPO), которая задает допустимый уровень потери данных. Например, если ваша организация не может допустить потери данных более чем на 12 часов, вы задаете расписание, по которому резервные копии создаются с периодичностью менее 12 часов.
Создание и восстановление резервных копий может быть автоматизировано в Linux с помощью CronJob или любого другого программного обеспечения для планирования. Имейте в виду, что объем данных в вашей организации также будет влиять на то, как часто вы сможете создавать резервные копии и как быстро сможете их восстанавливать. Вы можете проверить, сколько времени это займет, прежде чем настраивать запланированную задачу, чтобы убедиться, что операции резервного копирования или восстановления будут завершены до того, как будет предпринята следующая попытка.
Кроме того, вы должны определить, успешно ли выполнены операции резервного копирования или восстановления. Инструмент WebGISDR поддерживает выходной файл, куда записываются результаты операции в формате JSON, который можно проанализировать, чтобы определить, где находится резервная копия, произошел ли сбой каких-либо компонентов и сколько времени потребовалось каждому компоненту. Этот файл может быть интегрирован в логику резервного копирования и восстановления, чтобы уведомлять администраторов о любых сбоях или действиях с элементами.