Разблокировка Azure: как построить высокогибкую инфраструктуру базы данных SQL

Ни для кого не секрет, что в последние годы «Инфраструктура как услуга» и «Платформа как услуга» получают все большее распространение в различных проектах благодаря своим возможностям, особенно эффективности использования ресурсов и гибкости. В результате Microsoft потратила много времени и усилий на создание удобной для пользователя среды, в которой можно использовать SQL.

Команда Social Discovery Group использует различные базы данных, включая SQL, для работы наших продуктов. Благодаря портфолио из более чем 40 глобальных услуг, которые помогают встречаться и общаться по всему миру, наша база пользователей насчитывает более 250 миллионов человек по всему миру. Чтобы гарантировать надежность наших продуктов для пользователей, мы храним часть ключевой инфраструктуры в облаке. Это помогает повысить его устойчивость, безопасность и гибкость.

У нас имеется большой опыт развертывания серверных и сервисных баз данных на различных платформах, включая кластеры Kubernetes. Однако мы столкнулись с необходимостью сделать часть соответствующей инфраструктуры баз данных SQL в облаке Azure максимально гибкой, эффективной и надежной. Существует 3 способа использования SQL в облаке Microsoft Azure:

• База данных SQL Azure
• Управляемый экземпляр Azure SQL
• SQL Server на виртуальных машинах Azure

После исследования мы решили использовать базы данных Azure SQL. Просто чтобы уточнить для тех, кто никогда не слышал о так называемых базах данных Azure SQL: это управляемые облачные базы данных, предоставляемые как часть Microsoft Azure.

Я выделил следующие преимущества:

• Нет необходимости беспокоиться об обновлениях или поддержке по окончании срока службы;
• Простая настройка и развертывание;
• Скорость развертывания (и, следовательно, разработки) и масштабируемость;
• Высокая доступность;
• Отказоустойчивость;
• Простота резервного копирования;
• Оптимизация затрат;
• Интегрированная система мониторинга Microsoft Azure.

Теперь давайте поговорим обо всем шаг за шагом и рассмотрим процесс развертывания и создания базы данных. Это можно сделать с помощью сценария Power Shell или Azure CLI, но для ясности я рассматриваю процесс с помощью графического интерфейса портала. Для этого перейдите в Azure SQL, нажмите «Создать» и выберите «Базы данных SQL».

Указываем группу ресурсов, выбираем, есть ли существующий сервер или создаем новый (с указанием имени и данных администратора), и придумываем имя для базы данных. Я бы рекомендовал выбирать пакеты на основе DTU (единицы транзакций базы данных) со сбалансированным сочетанием вычислительных ресурсов и ресурсов хранения для наших общих рабочих нагрузок.

Также есть несколько вкладок настроек: Сеть, Безопасность, Дополнительные настройки и Теги; для минимальной стандартной конфигурации их можно оставить без изменений по умолчанию. Затем ждем создания базы данных. На этом минимальная настройка завершена, и основа готова.

Размер ресурсов базы данных можно изменить очень легко, буквально одним щелчком мыши, а в случае недостаточности ресурсов мы можем установить нужные нам параметры с точки зрения размера и производительности.

Затем вы можете подключиться к своей базе данных любым удобным для вас способом извне, не забывая при этом добавлять свой IP-адрес или подсеть, а также разрешать все подключения в брандмауэре сервера, на котором размещена эта база данных.

Подключаться и осуществлять дальнейшее управление удобно через SQL Server Management Studio (SSMS), но это также можно сделать и с помощью других инструментов и самого портала Azure.

Помимо общедоступной точки подключения, вы также можете создать частную, добавив сервер в нужную подсеть и настроив частные зоны DNS.

Если говорить об отказоустойчивости, то здесь мы видим очень удобную и понятную реализацию отказоустойчивости, группы защищаемых серверов, находящихся в разных регионах.

В Azure можно добавлять и удалять базы данных на серверах в группе отработки отказа, принудительном переходе на другой ресурс и в режиме автоматического перехода на другой ресурс.

Вы можете увидеть это на скриншоте ниже. Придумаем имя для отказоустойчивой группы и переведем сервер в отказоустойчивый режим. Синхронизация указанных баз данных начнется автоматически. Второй сервер будет в режиме только для чтения. В случае сбоя трафик автоматически переключается на второй регион, а основной и вторичный серверы автоматически меняются местами.

Но аварийное переключение не поможет, если существует проблема на уровне данных в самих базах данных. Наверняка в этом случае нужно создавать резервные копии. Настраивать резервное копирование можно как внутри портала, так и через сторонние инструменты или, например, Azure DevOps (в конвейере можно использовать задачу SqlAzureDacpacDeployment + AzureFileCopy). На портале на вкладке Резервные копии настраиваются резервные копии и задаются необходимые политики хранения.

Если вы предпочитаете использовать сторонние инструменты резервного копирования, я бы рекомендовал рассмотреть инструменты Azure DevOps или пакета SQL.

Сам процесс восстановления на портале, на мой взгляд, не очень удобен. Первое, что бросается в глаза, — это длительное время восстановления простых тестовых баз данных. Например, мне потребовалось более получаса, чтобы восстановить базу данных базового размера размером 30 МБ из вчерашней резервной копии! После обращения в службу поддержки Microsoft Azure мне посоветовали использовать сценарии PowerShell для восстановления и уведомили, что для процесса восстановления размер базы данных должен быть не ниже S3, а в дальнейшем размер можно уменьшить. Ниже я собираюсь представить некоторые свои скрипты и разработки на эту тему, их можно улучшать и дорабатывать, но я уверен, что многим из вас они найдутся полезными.

Я проведу вас шаг за шагом:

1. Если у вас не установлен PowerShell ISE в Windows, загрузите его здесь: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Далее вам необходимо установить модуль Azure: Install-Module Az.
3. После установки модуля AZ импортируйте модуль AZ: Import-Module Az.
4. После импорта вы можете подключиться к своей учетной записи Azure: Connect-AzAccount. Появится всплывающее окно для входа в вашу учетную запись Azure, после чего вы будете подключены.
5. Запустите сам сценарий PowerShell.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 — этот код инициирует восстановление базы данных с другим именем. Если исходное имя восстанавливаемой базы данных — «dbforscript», то имя восстанавливаемой базы данных будет dbforscript_new. Восстановленная база данных будет SLO версии S3 или выше. Это рекомендуемый способ выполнения этого действия. Для этого используется переменная $PITRSLO = "S3", вы можете использовать S3 или выше. После этого сбросим уровень SLO на исходный, это только для восстановления.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 — этот код удалит исходную базу данных из группы отработки отказа: исходная база данных: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3. Этот код удалит базу данных реплики с сервера, на котором она расположена: dbforscript на сервере test-serv2.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 — Этот код переименует исходную базу данных под другим именем: после переименования dbforscript будет dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 — этот код переименует восстановленную базу данных в исходное имя базы данных, переименовав dbforscript_new в dbforscript.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 — этот код вернет уровень SLO вашей базы данных к предыдущему (исходному) значению S0. Если ваша база данных является базовой, вы можете обновить ее с S0 до базовой после входа на портал.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 — Последний код добавляет восстановленную базу данных в отказоустойчивую группу, которая уже имеет исходное имя (поскольку мы изменили его в предыдущем коде).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Вы можете рассмотреть возможность добавления параметра - ErrorAction Stop после команды. Это предотвратит выполнение следующих команд в случае ошибки и не будет лавинного кома.

Также вы можете добавить Get-Date в начало и конец скрипта для расчета времени выполнения. В моем случае база данных объемом около 3,3 ГБ была восстановлена таким скриптом менее чем за 6 минут.

При желании вы, конечно, можете оптимизировать скрипт, добавить его через Azure DevOps, уменьшить количество переменных или что-то жестко закодировать, но я постарался описать это максимально подробно и так, чтобы каждый мог понять.

Отдельного внимания заслуживает мониторинг баз данных в Azure и возможность интеграции с различными системами, например Datadog. Мониторинг довольно удобен, но не без нюансов (на момент написания статьи, например, пользователи с правами только на чтение могли видеть мониторинг только по одной базе данных, а не все сразу... ну вот такие оттенки).

В заключение, наша команда успешно оптимизировала расходы, а также решила проблемы, связанные с обновлениями и прекращением поддержки. Мы добились улучшения производительности, устойчивости, скорости разработки и гибкости. Кроме того, внедрение сценариев заметно расширило нашу способность быстро восстанавливаться в случае необходимости.

Автор: Павел Шапуров, ведущий DevOps-инженер Social Discovery Group.