Tag: AWS


Реализация защищенной корпоративной системы резервного копирования и восстановления в AWS

Андрей Зайчиков, Архитектор AWS

Всем привет!

Сегодня мы поговорим о том, как реализовать защищенную корпоративную систему резервного копирования и восстановления с использованием сервисов AWS.

Для начала – пара слов о проблематике.

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

Очевидно, что системы резервного копирования и восстановления стоят денег, однако выделять деньги на подобные системы компании не спешат, т.к. стоимость данных решений в общем ИТ портфеле компании нередко довольно высока. Кроме того, для подобных систем характерны классические «железные» проблемы – неэффективное использование ресурсов, необходимость планировать ресурсы сильно заранее, сложность внедрения и сопровождения. В итоге, системы внедряются в ограниченном объеме (если вообще внедряются), что приводит к очевидным потерям в случае возникновения непредвиденных ситуаций.

Преимущества облачных технологий для данного класса систем кажутся очевидными, среди них можно отметить:

  • Практически неограниченный объем доступных ресурсов;
  • Использование ресурсов по pay-as-you-go модели;
  • Высочайший SLA по надежности и доступности;
  • Широкие возможности оптимизации хранения данных.

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

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

(more…)

Миграция кластеров NoSQL DB между регионами AWS

Андрей Зайчиков, Архитектор AWS

Роман Скваж, CTO FunCorp

Александр Домнин, SysOps Engineer FunCorp

Всем привет!

Сегодня у нас в гостях замечательные специалисты и просто хорошие люди из компании FunCorp – Роман Скваж (CTO) и Александр Домнин (SysOps). Мы расскажем вам об одном интересном проекте по миграции больших кластеров нереляционных баз данных между регионами AWS (из Европы в США).

Что мигрировать?

По словам Романа Скважа: «Флагманский продукт компании – iFunny (https://ifunny.co/) одно из наиболее популярных развлекательных приложений среди американской молодежи. За 5 лет сервис обзавелся внушительной аудиторией: мобильные приложения обслуживают более 3,5 миллионов активных пользователей в день и работают во всех часовых поясах.  Backend приложения полностью реализован на Amazon Web Services и его масштаб впечатляет:

  • Кластер Apache Cassandra – 25 узлов, 18 TB данных;
  • Кластер Apache Cassandra – 18 узлов, 16 TB данных;
  • Кластер MongoDB – 5TB данных, распределенных по 8 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;
  • Кластер MongoDB – 150GB данных, распределенных по 4 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;
  • Кластер Elasticsearch – поисковый индекс объемом 1 TB;
  • 3 ReplicaSet Redis – Master + 2 Slave с 15 GB, 10 GB и 1 GB данных и крайне высокой скоростью записи.

Силами наших DevOps и Backend команд, нам предстояло перенести все это из одного региона AWS в другой без downtime и крупных изменений в приложении. При этом желательно было не задействовать сторонние приложения и платные сервисы».

(more…)