Кейс: перенос локальной инфраструктуры клиента в облако AWS

Компания Cyber Finance LTD — это компания из Южной Африки, которая занимается юридическим и брокерским обслуживанием. 

В связи с карантином 2020 руководство компании приняло решение перевести всех сотрудников компании на удаленную работу, закрыть офис за ненадобностью и перенести развернутую локально инфраструктуру в облако. Было выбрано облако AWS.

Так выглядела инфраструктура компании:

1) Террабайт данных на файловом сервере (Clear OS)

2) Внутренний портал для управления задачами и CRM система Битрикс24, 600Г пользовательских файлов, база данных на том же сервере, что и приложение, занимала около 25Г. К внутреннему порталу были подключены диски файлового сервера, была интегрирована офисная АТС (Астериск).

3) Сервер Астериск — офисная АТС. 

Клиент обозначил, что мы можем ни в чем себе не отказывать в рамках 200$ в месяц. Уложиться в данный бюджет было сложно, потому что по нашим изначальным расчетам необходимо хотя бы 400$ в месяц, а лучше 500$ (датацентр в Кейптауне открыт недавно, и цены в нем намного выше, чем, в Вирджинии, для многих сервисов не доступны маленькие EC2 инстансы). В этом посте я расскажу подробно, как мне удалось решить задачи клиента и уложиться в бюджет, не в ущерб производительности системы.

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

Первым этапом в ночь с пятницы на понедельник мы провели предварительный тест: развернули предполагаемые ресурсы:

  1. EC2 для Битрикс24;
  2. EC2 для Астериска;
  3. S3 для файлов папки upload Битрикс24;
  4. RDS для БД Битрикс24;
  5. Auto Scaling групп на 1 инстанс для автоматического восстановления сервера Битрикс24 в случае падения. 

Далее мы перенесли все в тестовом режиме (не забирая все файлы, и взяв только срез по 3000 записей из каждой таблицы БД), чтобы понять, в каком порядке нужно действовать и сколько времени потенциально может занимать каждый этап. Той же ночью все входящие на старый Астериск транки были отключены, подключены на новый Астериск — чтобы убедиться, что провайдеры телефонии не блокируют ip-адрес нового Астериска, к понедельнику транки снова были подключены на старом Астериске.

Основная проблема, которая вскрылась в ходе тестового переезда, заключалась в том, что RDS с 5м Mysql в Кейптауне никак не вписывалась в бюджет (даже в минимальной конфигурации) из-за отсутствия в регионе возможности взять маленький инстанс. Были проработаны несколько вариантов:

  1. использовать 8й Mysql;
  2. разместить базу данных в другом регионе (оказалось запрещено законом);
  3. разместить базу данных на MySql совместимой БД Aurora Serverless (такой вариант оказался недоступным для региона);
  4. разместить базу данных на одном инстансе с приложением Битрикс24, взяв инстанс помощнее и EBS-оптимизированный;

Было перепробовано несколько вариантов RDS инстансов с MySQL 8, которые позволяли вписаться в бюджет: t3.small, t3.medium, t3.large, но ни один из них не давал требуемой производительности (получалось 11-18 попугаев) из-за низкого IOPS на маленьком 100G SSD. Даже замена диска на  Provision 1000 IOPS 100Г не дала результата, а диск большего размера, который разгонялся бы до больших IOPS уже не вписывался в бюджет.

Поэтому было принято решение разместить базу данных на одном инстансе с приложением Битрикс24, взяв EBS-оптимизированный инстанс m5d.large, отказавшись при этом от Auto Scaling Group (отказавшись от автоматического восстановления сервера после возможного сбоя) и отказавшись от возможности увеличивать размер жесткого диска автоматически. Производительность же получилась даже выше требуемой (60-70 попугаев)

В понедельник, поняв, что в бюджет, в принципе, можно уложиться, мы включили синхронизацию файлов внутреннего портала Битрикс24 с S3 бакетом в облаке. Битрикс24 поддерживает хранение пользовательских файлов в S3 бакете, поэтому мы включили синхронизацию новых загружаемых файлов его средствами, а старые файлы синхронизировали через консоль ssh командой aws s3 sync. Для этого на старый сервер приложения был установлен aws cli. Средствами Битрикс файлы переносились в облако со скоростью 1G в час, из консоли получалось 4-5G в час. В последствии на таблице файлов b_file был выполнен запрос, помечающий флаг, что файлы должны тянуться из соответсвующего бакета.

В середине недели телефония старого Битрикс24 и все софтфоны были переключены на новый Астериск.

В следующую ночь с пятницы на понедельник, когда почти все файлы папки upload строго Битрикс24 уже были синхронизированы с S3 бакетом, мы закрыли доступ пользователям к старому Битрикс24, сняли бекап с базы данных и перенесли ее в облако, новый Битрикс24 был подключен к новому Астериску, общие диски для хранения файлов все еще подтягивались со старого файлового сервера, когда пользователи начали использовать Битрикс24, установленный в облаке AWS. Со старого сервера Битрикс24 еще продолжали загружаться файлы.

Последним этапом были синхронизированы нужные файлы с файлового сервера.

Далее были настроены автоматические снапшоты серверов с использованием AWS EC2 Lifecycle Manager, межрегиональная репликация файлового хранилища S3, настроены уведомления об использовании ежемесячного запланированного бюджета и о доступности/здоровье развернутых ресурсов.

Первоначально в попытке вписать в бюджет базу данных на RDS, планировалось распределить 200$ следующим образом (но 200$ слишком мало для подобной архитектуры): https://calculator.aws/#/estimate?id=2b7e505cf75079271bbec60bf1c0a6d1a4b21e27 

В итоге пришлось перераспределить 200$ так, получив отличную производительность, но отказавшись от возможности автоматического восстановления и автоматического масштабирования:

https://calculator.aws/#/estimate?id=d80de3b1271a238c42cc2bd428511766f717f648

А вот такой вариант мы предложим тому клиенту, для которого великолепная производительность, высочайшая надежность, автоматическое масштабирование, автоматическое восстановление — все сразу и одновременно —  важнее цены: 

https://calculator.aws/#/estimate?id=891fde270ac1854a8ca0d229171fb52cb10b9f73

(первичная передача данных в AWS не включена в данные калькуляции)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *