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

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

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


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



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


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


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


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


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

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




  • EC2 для Битрикс24;

  • EC2 для Астериска;

  • S3 для файлов папки upload Битрикс24;

  • RDS для БД Битрикс24;

  • Auto Scaling групп на 1 инстанс для автоматического восстановления сервера Битрикс24 в случае падения. 


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


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

  • использовать 8й Mysql;

  • разместить базу данных в другом регионе (оказалось запрещено законом);

  • разместить базу данных на MySql совместимой БД Aurora Serverless (такой вариант оказался недоступным для региона);

  • разместить базу данных на одном инстансе с приложением Битрикс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 попугаев)


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


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


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

  

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


  1. Далее были настроены автоматические снапшоты серверов с использованием 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 не включена в данные калькуляции)


Комментарии

Популярные сообщения из этого блога

Настройка почты через biz.mail.ru в БитриксВМ

Git обновить текущую ветку из master

AWS S3 - Лучшие практики