Опыт миграции из собственного датацентра в облако AWS

Компания glassdoor.com является вторым по трафику сайтом в США для соискателей работы. SLA установлен на уровне 99.99% без возможности проводить обслуживание серверов и приложений в оффлайн режиме. Объем баз данных, которые должны быть мигрированы в облако — порядка 40Тб. В среднем сервера баз данных выполняют 2 млрд. запросов в день.

 

Ситуация до миграции

Для обеспечения высокой доступности (HADR) используется стандартная технология SQL Server Failover Cluster Instance.

 

 

Существующие особенности, которые надо было учесть при миграции:

1. Для работы кластера требуется дорогостоящее сетевое хранилище данных (SAN), подключенное оптическими каналами ко всем нодам кластера.

2. Физически имеется только одна активная копия данных, поэтому при обнаружении повреждений в страницах баз данных требуется восстановление этих страниц из бэкапов.

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

4. Клиентские приложения написаны на java и работают под управлением Linux. Используется устаревшая версия jdbc-драйвера, которая официально поддерживает только SQL2008, хотя сами базы данных были переведены на SQL2024.

5. Лицензии на SQL2024 уже были оплачены.

 

Какие вопросы надо было решить при миграции

1. AWS не поддерживает общее хранилище данных для Windows. Использование  SQL Server Failover Cluster Instance невозможно.

2. AWS не поддерживает свободный переход IP-адресов между серверами. Windows не сможет сама переместить клиентский адрес доступа на новую ноду при переключении между нодами.

3. Требуется повысить уровень отказоустойчивости при авариях.

4. Убедится, что все клиентские приложения на должном уровне поддерживают подключение к кластеру баз данных в новой архитектуре.

5. Использовать свои лицензии на SQL Server.

Лицензирование

Политика Microsoft в части лицензирования баз данных в облаке довольно сложная.

Я бы выделил три возможных варианта для AWS:

1. Для компаний с большим бюджетом дополнительные соглашения с Microsoft позволяют запускать виртуальные машины с SQL Server в облаке без особых ограничений. Вы можете запустить новую Windows VM, установить SQL и использовать без каких дополнительных манипуляций.

2. AWS предоставляет возможность запустить Windows VM с предустановленным SQL Server. При этом оплата производиться по фактическому использованию. К примеру один сервер с 512 Gb RAM и 64 CPU обойдется примерно в $23000/месяц.

3. Использовать собственные лицензии SQL Server в облаке AWS.

 

Для нас был приемлем только третий вариант:

• SQL Server должен запускаться на выделенном физическом сервере. Звучит глупо.. облако.. физический сервер, но AWS поддерживает такую возможность.

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

• AWS не позволит использовать публичные образы Windows для запуска VM на выделенном сервере. Потребуется создать собственный образ Windows VM собственными силами с помощью Hyper-V или VMWare, а затем экспортировать этот образ в AWS. Образ должен содержать собственную лицензию Windows и активироваться собственными KMS.

• AWS не поддерживает автоматическое восстановление при аварии для таких виртуальных машин. Если физический сервер умирает вы должны перевести виртуальные машины на новый сервер самостоятельно.

При построении образа потребуется установить соответствующие драйверы для работы в AWS — драйвер хранилища и сетевой драйвер.

 

Выбор HADR архитектуры

Учитывая ограничения AWS на общее сетевое хранилище, было решено использовать SQL Server AlwaysOn.

Основные достоинства:

1. Каждая нода кластера содержит собственную физическую копию данных. При повреждении страниц баз данных на одной ноде они могут восстановлены с других нод.

2. Процесс фейловера занимает всего несколько секунд. В отличие от SQL FCI, нет необходимости завершать основной процесс базы данных и запускать его на новом сервере. Фейловер в SQL FCI обычно требовал 5 минут из-за агрессивности клиентских приложений.

3. Возможность перенести нагрузку резервного копирования на другие ноды.

Недостатки:

1. Двойной коммит — все синхронные ноды должны зафиксировать коммит одновременно с мастер нодой. В результате, производительность UPDATEDELETEINSERT операций в AlwaysOn ниже, чем в SQL FCI.

2. Восстановление AlwaysOn ноды с нуля требует значительно большего времени, чем восстановление ноды в SQL FCI, т.е. необходимо восстановить все базы данных.

 

Невозможность перемещения IP адреса между нодами средствами Windows также накладывает ограничения на целевую архитектуру:

1. Каждая нода, вовлеченная в процесс фейловера, должна находится в отдельной подсети. В этом случае Windows Failover Cluster позволит установить выделенный IP-адрес для каждой ноды и его перемещение в процессе фейловера не потребуется.

2. Каждая нода должна иметь только один сетевой интерфейс для каждой подсети. Если требуется два интерфейса — расположите их в разных подсетях. Это позволит избежать проблемы, когда Windows Failover Cluster пытается активировать клиентский IP адрес на ошибочном сетевом интерфейсе.

 

Принимая во внимание рекомендации по расположению серверов баз данных в разных зонах получаем следующую архитектуру:

Две синхронные реплики в регионе us-east-1. Одна асинхронная реплика в us-west-2. Синхронные реплики позволяют защититься от аварий на уровне одного датацентра (на самом деле не так уж и редки). Асинхронная реплика страхует на случай аварии на уровне региона — но это уже на случай серьезного катаклизма, при котором автоматическое восстановление работы сайта невозможно — потребуется ручной перевод трафика в другой регион.

 

Выбор типа виртуальной машины

При всем многообразии типов VM в AWS, только три могут использоваться для баз данных эффективно.

1. I3 — наибольший инстанс имеет 512 Gb RAM и 64 CPU. Дополнительно имеется 16Tb локальных быстродействующих SSD, которые могут быть использованы для tempdb и buffer pool extension.
   После ряда болезненных экспериментов мы пришли к выводу, что этот тип для нас не подходит. Вроде как там используется устаревший гипервизор, который тратит слишком много ресурсов на поддержку VM. Например, под большой нагрузкой утилизация CPU на физическом сервер была в 2 раза больше, чем внутри виртуальной машины.

2. X1E — один из самых новых типов. Наибольший инстанс имеет 4096 Gb RAM и 128 CPU. Работает просто отлично, но цена…

3. R4 — наибольший инстанс имеет 512 Gb RAM и 64 CPU. Приемлемая цена и хорошая производительность. Используется новая версия гипервизора с малыми издержками на виртуализацию.

 

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

Тип инстанса	Максимальная пропускная способность хранилища (MB/s, 128 KB I/O)	Максимум IOPS (16 KB I/O)
i3.8xlarge	875	32,500
i3.16xlarge	1,750	65,000
r4.8xlarge	875	37,500
r4.16xlarge	1,750	75,000
x1e.16xlarge	875	40,000
x1e.32xlarge	1,750	80,000

 

Конфигурация хранилища

AWS Elastic Block Storage позволяет выбрать из нескольких видов хранилища, каждый из который имеет свои лимиты и особенности.

	Solid-State Drives (SSD)		Hard disk Drives (HDD)
Volume Type	General Purpose SSD (gp2)*	Provisioned IOPS SSD (io1)	Throughput Optimized HDD (st1)	Cold HDD (sc1)
Max. IOPS**/Volume	10,000 (when volumes size is > 3333Gb)	32,000	500	250
Max. Throughput/Volume	160 MiB/s	500 MiB/s***	500 MiB/s (40 MB/s per TiB)	250 MiB/s
Use case	Database files	Database files	Database backups	<not being used>

 

Во-первых, нужно забыть стандартную рекомендацию про создание отдельных томов для данных, логов, tempdb.

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

В-третьих, чтобы получить максимальную производительность необходимо использовать RAID0 из правильно подобранного числа томов.

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

К примеру наша конфигурация для r4.16xlarge сервера:

1. Операционная система — C: — 300Gb. Тип тома — gp2. Стоимость в месяц $27.

2. Базы данных с логами, tempdb — X: — 34Tb — десять томов gp2, каждый 3400Gb, объединенных в RAID0 средствами Windows Storage Spaces. Стоимость в месяц $3400.
   Как вышли на эту конфигурацию:

   1. Инстанс этого типа имеет лимит в 1750MB/s и 75000 IOPS.

   2. Один том gp2 имеет лимит в 160MB/s и до 10000 IOPS.

   3. Чтобы избежать проседания производительности размер каждого тома должен быть не менее 3333 Gb.

   4. Десять томов gp2, объединенных в RAID0 позволяют максимально утилизировать доступный лимит для инстанса и обеспечить максимальную пропускную способность.

Такого же эффекта можно добиться с помощью четырех io1 томов 20000 IOPS в каждом. Размер при этом не имеет значения. Но такая конфигурация обойдется значительно дороже при меньшей емкости. Например, 4 тома по 3000 Gb обойдутся в $6700 в месяц.

3. Бэкапы — S: — 4Tb — один том st1. Стоимость в месяц $180 (в два раза дешевле gp2, при хорошей производительности для бэкапов).

 

Бэкапы баз данных

Мы пробовали много разных конфигураций и в итоге остановились на наиболее эффективной для нас.

1. Бэкап базы данных выполняется на главной ноде на “локальный” диск S:. Диск является EBS томом, поэтому беспокоится за его сохранность не стоит — том можно переключить на другой сервер даже если виртуальная машина полностью потеряна. Локальный том хранит бэкапы за последние 7 дней.

2. По субботам полный бэкап загружается в AWS S3 на долговременное хранение. Для файлов изначально устанавливается тип хранилища “нечастый доступ”, а по истечение 45 дней файлы автоматически выгружаются в AWS Glacier. В итоге долговременное хранилище большого объема файлов выходит относительно дешево.

 

Клиентские приложения

В процессе работы над проектом мы осознали, что используемый jdbc-драйвер не сможет эффективно работать в новой конфигурации, т.к. он не поддерживает клиентские точки доступа с несколькими IP-адресами (multi-subnet cluster). Кстати, платформа 1С также не поддерживает такую конфигурацию в чистом виде — мне не удалось заставить сервер 1С стабильно подключаться к AlwaysOn кластеру с несколькими IP-адресами. Хотя, с определенными оговорками, есть вариант как это решить.

Суть проблемы в том, что для используемого доменного имени DNS сервер возвращает два (или больше) IP адреса вместо одного. Но только один адрес, принадлежащий мастер ноде, является активным.

Для решения проблемы нужно всего лишь добавить параметр “MultiSubnetFailover=True” в строку соединения. Но не всегда есть возможность сделать это.

Варианты решения, если поменять строку соединения невозможно:

1. Windows Failover Cluster имеет параметр, который позволяет обновлять IP адрес в DNS и регистрировать только один адрес, который активен в данный момент. Минусы:

   1. в процесс фейловера вовлечен дополнительный участник (DNS сервер).

   2. DNS кэш на клиентских серверах обновляется не так часто.

   3. Дополнительные сложности возникнут если клиенты на Linux.

В результате сложно ожидать восстановления нормальный работы приложений быстрее чем через 5-10 минут после фейловера.

2. Использовать один из сервисов AWS — Network Load Balancer

   1. NLB корректно определяет активную ноду и меняет DNS запись.

   2. Нормально работает в Linux.

   3. Проблема с DNS кэшем все равно присутствует.

Время на восстановление также 5-10 минут.

3. Использовать решения типа HAProxy

   1. С точки зрения клиента IP адрес не меняется.

   2. Время восстановления после фейловера может приблизится к 30-60 секундам.

   3. Для построения реальной отказоустойчивости на уровне HAProxy требуется построение довольно сложной архитектуры. Один из вариантов: два HAProxy + AWS Network Load Balancer. В этом случае сбой на одном HAProxy не приведет к полной потере доступа к базе данных.

 

Непосредственная миграция

Одним из условий проекта была возможность быстрого возврата в локальный датацентр при проблемах в AWS, поэтому было решено использовать AlwaysOn как средство миграции баз данных. Хотя технически это можно назвать обычным процессом фейловера между нодами, расположенными в разных датацентрах.

 

Непосредственно перед миграцией были остановлены все процессы, которые делают много изменений в базе данных, но не влияют напрямую на работоспособность веб-сайта. Это позволило снизить трафик внутри AlwaysOn и переключиться в синхронный режим.

Затем веб-сайт переводится в оффлайн режим, производится фейловер базы данных в AWS и AlwaysOn переключается обратно в асинхронный режим. В этом время, трафик переключается на приложения в AWS, которые уже подключены в новой мастер ноде.
Суммарное время даунтайма — 6 минут!