Высокая доступность по уровням служб
Чтобы разобраться в вариантах и возможностях обеспечения доступности в SQL Azure, необходимо изучить уровни служб. Выбранный уровень служб определяет базовую архитектуру базы данных или управляемого экземпляра, которые вы развертываете.
Существует две модели приобретения, которые следует учитывать: DTU и vCore. На этом уроке мы поговорим об уровнях служб на основе виртуальных ядер и их архитектурах для обеспечения высокой доступности. В модели на основе единиц DTU можно приравнять уровни "Базовый" и "Стандартный" к уровню "Общего назначения", а уровни "Премиум" — к уровню "Критически важный для бизнеса".
Общего назначения
Базы данных и управляемые экземпляры на уровне служб "Общего назначения" имеют одинаковую архитектуру обеспечения доступности. Используя приведенный ниже рисунок в качестве иллюстрации, сначала рассмотрите варианты приложения и кольцевого управления. Приложение подключается к имени сервера, который затем подключается к шлюзу (GW), который указывает подключение приложения к правильному серверу, работающему на виртуальной машине. При использовании общего назначения первичная реплика использует локально подключенный SSD для tempdb. Файлы данных и журналов хранятся в хранилище Azure класса Premium, которое является локально избыточным (несколько копий в одном регионе). Затем файлы резервных копий сохраняются в Службе хранилища Azure (цен. категория "Стандартный"), которая по умолчанию является RA-GRS. RA-GRS является глобально избыточным хранилищем с копиями в нескольких регионах.
Как обсуждалось в предыдущем модуле в рамках данной схемы обучения, вся служба SQL Azure строится на Azure Service Fabric, выступающей основой Azure. Если Azure Service Fabric определяет, что должна произойти отработка отказа, процедура будет похожа на то, что происходит в экземпляре отказоустойчивого кластера (FCI). Service Fabric найдет узел со свободной емкостью и запустит новый экземпляр SQL Server. Затем файлы базы данных будут присоединены, будет выполняться восстановление, а шлюзы будут обновлены, чтобы указать приложения на новый узел. Виртуальная сеть, прослушиватель или обновления не требуются. Это встроенная возможность.
Критически важный для бизнеса
Следующим является уровень служб "Критически важный для бизнеса", который в общем случае обеспечивает максимальную производительность и доступность всех уровней служб SQL Azure ("Общего назначения", "Гипермасштабирование", "Критически важный для бизнеса"). Уровень "Критически важный для бизнеса" предназначен для критически важных приложений, которым требуется низкая задержка и минимальное время простоя.
Уровень "Критически важный для бизнеса" аналогичен развертыванию группы доступности Always On в фоновом режиме. В отличие от уровня общего назначения, файлы данных и журналов в критически важный для бизнеса выполняются на ssd с прямым подключением, что значительно снижает задержку в сети. (Для общего назначения используется удаленное хранилище.) В этой группе доступности существует три вторичных реплики. Вы можете использовать одну из них в качестве конечной точки только для чтения (без дополнительной платы). Транзакция может завершить фиксацию, если по меньшей мере одна из вторичных реплик зафиксировала изменение для своего журнала транзакций.
Горизонтальное масштабирование чтения с помощью одной из вторичных реплик поддерживает согласованность на уровне сеанса, поэтому если сеанс только для чтения повторно подключается после ошибки подключения, вызванной недоступностью реплики, она может быть перенаправлена на реплику, которая не 100 % до актуальной реплики чтения и записи. Аналогичным образом, если приложение записывает данные с помощью сеанса, доступного для чтения и записи, и сразу же считывает их с помощью сеанса, доступного только для чтения, возможно, что последние обновления будут отражены в реплике не сразу. Такая задержка вызвана асинхронной операцией повторной обработки журнала транзакций.
Если возникает какой-либо тип сбоя, и service fabric определяет необходимость отработки отказа, отработка отказа на вторичную реплику быстра, так как реплика уже существует и содержит данные, подключенные к нему. При отработке отказа прослушиватель не требуется. Шлюз перенаправляет подключение к первичной даже после отработки отказа. Этот коммутатор происходит быстро, то service fabric заботится о спиннинге другой вторичной реплики.
Гипермасштабирование
Уровень служб "Гипермасштабирование" доступен только в База данных SQL Azure. Этот уровень служб обладает уникальной архитектурой с многоуровневым слоем кэшей и страничными серверами, обеспечивая более быстрый доступ к страницам баз данных без обращения к файлу данных напрямую.
Архитектура с использованием связанных серверов страниц позволяет выполнять горизонтальное масштабирование и распределять, таким образом, данные между уровнями кэширования. Кроме того, благодаря новой архитектуре уровень "Гипермасштабирование" поддерживает базы данных до 100 ТБ. Поскольку в ней используются моментальные снимки, почти мгновенное резервное копирование базы данных возможно независимо от размера. Восстановление баз данных занимает несколько минут, а не часов или дней. Масштаб можно также увеличивать и уменьшать на фиксированное время с учетом рабочих нагрузок.
Интересно отметить, как в этой архитектуре реализована служба журналов. Служба журналов используется для передачи реплик, а также серверов страниц. Транзакции могут зафиксироваться, если служба журналов ужесточена в целевой зоне, поэтому для фиксации не требуется использование изменений вторичной репликой вычислений. В отличие от других уровней служб, можно определить, требуются ли вторичные реплики. Вы можете настроить ноль до четырех вторичных реплик, все из которых можно использовать для масштабирования чтения.
Как и в других уровнях служб, автоматическое отработка отказа произойдет, если service fabric определяет, что это необходимо, но время восстановления будет зависеть от существования вторичных реплик. Например, если реплик нет и происходит переход на другой ресурс, он выполняется так же, как на уровне служб "Общего назначения", где Service Fabric сначала обнаруживает незанятое пространство. Если у вас есть одна или несколько реплик, восстановление выполняется быстрее и больше соответствует уровню "Критически важный для бизнеса".
критически важный для бизнеса обеспечивает высокую производительность и доступность рабочих нагрузок с небольшими записями журналов, которые требуют низкой задержки, но уровень служб Гипермасштабирования позволяет получить более высокую пропускную способность журнала с точки зрения МБ/секунды, предоставляет наибольший размер базы данных и предоставляет до четырех вторичных реплик для более высокого уровня масштабирования чтения. Поэтому при выборе между ними необходимо учитывать рабочую нагрузку.