Описание целевого времени восстановления и целевой точки восстановления
Понимание целей точки восстановления и точки восстановления имеет решающее значение для вашего плана высокой доступности и аварийного восстановления (HADR), так как они являются основой для любого решения доступности.
Цель времени восстановления
Целевое время восстановления (RTO) — это максимальный срок, доступный для перевода ресурсов в оперативный режим после сбоя или проблемы. Если этот процесс занимает больше времени, чем RTO, возможны такие последствия, как финансовые санкции, невыполнение работы и т. д. RTO можно указать для всего решения, которое включает в себя все ресурсы, или для отдельных компонентов, таких как экземпляры SQL Server и баз данных.
Целевая точка восстановления
Целевая точка восстановления (RPO) — это момент времени, до которого база данных должна быть восстановлена. Он равняется максимальному объему потери данных, который может себе позволить предприятие. Например, предположим, что виртуальная машина IaaS, содержащая SQL Server, испытывает сбой в 10:00, а базы данных в этом экземпляре SQL Server имеют RPO в 15 минут. Независимо от того, какая функция или технология используется для возврата этого экземпляра и его баз данных, ожидается, что будут потеряны данные не более чем за 15 минут. Это означает, что база данных может быть восстановлена до своей версии на 09:45 или позже, чтобы обеспечить минимальные потери данных и соответствие указанной RPO. Различные факторы могут определять достижимость RPO.
Определение целевой точки восстановления и целевого времени восстановления
RTO и RPO определяются бизнес-требованиями, но также основаны на различных технологических и других факторах, таких как навыки и способности администраторов (не только администраторов баз данных). Хотя для бизнеса может быть желательным полное отсутствие простоя или нулевые потери данных, это может быть нереалистичным или невозможным по различным причинам. RTO и RPO решения следует определять в открытом и честном обсуждении с участием всех вовлеченных сторон.
Одним из аспектов, имеющих решающее значение для RTO и RPO, является знание ущерба от простоя. Если определить это число и общий эффект, который недоступен для бизнеса, проще определить решения. Например, если предприятие может терять 10 000 долларов США в час или получить штраф, если что-то не удалось обработать, это будет показателем, помогающим определить RTO и RPO. Затраты на решение должны быть пропорциональны объему или стоимости простоя. Если стоимость решения высокой доступности и аварийного восстановления равна Х, но проблема, если она возникнет, приведет к простою лишь на несколько секунд, то решение окупит себя.
С точки зрения небюзности RTO следует определить на уровне компонента (например, SQL Server), а также для всей архитектуры приложения. Общая возможность восстановления после сбоя определяется слабейшим звеном системы. Например, если SQL Server и его базы данных можно вернуть в рабочий режим в течение пяти минут, но для серверов приложений это займет 20 минут, общее значение RTO будет составлять 20 минут, а не 5. Среда SQL Server может иметь значение RTO, равное пяти минутам; это не изменит общее время восстановления.
RPO взаимодействует конкретно с данными и напрямую влияет на структуру любого решения HADR, а также на административные политики и процедуры. Используемые функции должны поддерживать RTO и RPO, которые были определены. Например, если резервные копии журналов транзакций запланированы каждые 30 минут, но существует 15-минутный RPO, база данных может быть восстановлена только до последней резервной копии журнала транзакций, доступной в худшем случае будет 30 минут назад. Такое время предполагает отсутствие любых других проблем, а также то, что резервные копии были протестированы и заверены как адекватные. Протестировать каждую резервную копию, созданную для каждой базы данных в вашей среде, непросто, но резервные копии — это просто файлы в файловой системе. Не делая по крайней мере периодические восстановления, нет никакой гарантии, что они хороши. Выполнение проверок в процессе резервного копирования может дать некоторую степень уверенности.
Конкретные используемые функции, такие как группа доступности Always On или экземпляр отказоустойчивого кластера Always On (FCI), также влияют на RTO и RPO. В зависимости от того, как настроены функции, решения IaaS или PaaS могут автоматически выполнять отработку отказа в другое расположение, что может привести к длительному простою. Определив RTO и RPO, то есть зная, какие потери времени и данных допустимы, можно разработать соответствующее этим требованиям техническое решение. Если требования оказываются нереалистичными, необходимо соответствующим образом скорректировать RTO и RPO. Например, если требуемое значение RTO равняется двум часам, но для копирования на целевой сервер резервной копии для восстановления потребуется три часа, то выполнить это требование к RTO уже невозможно. Эти типы факторов следует учитывать при определении RTO и RPO.
RTO и RPO должны быть определены и для высокого уровня доступности, и для аварийного восстановления. Высокий уровень доступности считается затрагивающим более локализованные события, после которых легко восстановиться. Одним из примеров высокого уровня доступности является группа доступности, которая автоматически выполняет отработку отказа от одной реплики к другой в регионе Azure. Это может занять секунды, и на этом этапе необходимо убедиться, что приложение может подключиться после отработки отказа. Время простоя SQL Server будет минимальным. Локальные RTO или RPO могут измеряться в минутах в зависимости от того, насколько велико значение решения или системы.
Аварийное восстановление будет аналогом ввода целого нового центра обработки данных. Головоломка состоит из множества частей, SQL Server всего лишь одна из них. Для восстановления работоспособности всего может потребоваться несколько часов или более. Именно поэтому RTO и RPO — это разные вещи. Даже если многие технологии и функции, используемые для высокого уровня доступности и аварийного восстановления, одинаковы, уровень усилий и затраченного времени может сильно различаться.
Все RTO и RPO должны быть формально задокументированы и периодически пересматриваться по мере необходимости. После того как они задокументированы, вы можете рассмотреть возможности и технологии, которые можно использовать для архитектуры.