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

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

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

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

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

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

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

  1. использовать 8й Mysql;
  2. разместить базу данных на MySql совместимой БД Aurora Serverless (такой вариант оказался недоступным для региона);
  3. разместить базу данных на одном инстансе с приложением Битрикс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$ следующим омхитектуры): https://calculator.aws/#/estimate?id=2b7e505cf75079271bbec60bf1c0a6d1a4b21e27 

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

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

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

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

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

Об авторе:

Инженер-программист по образованию, web-программист по призванию, Битрикс-программист по любви и 1с-программист по стечению обстоятельств, руководитель команды web-разработчиков, внедренец 1С-Битрикс и Битрикс24, основатель одноименной студии.

bedrosova3

Подпишитесь на рассылку!

Fields marked with an * are required

Комментарии

 

Комментировать

 

Подписаться на рассылку:

Fields marked with an * are required