Category: DevOps


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

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

Всем привет!

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

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

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

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

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

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

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

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

(more…)

Основные способы оптимизации стоимости на AWS

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

Всем привет!

Сегодня мы поговорим об основных и наиболее часто используемых возможностях оптимизации затрат на сервисы AWS.

Основные варианты оптимизации затрат
К таким вариантам относятся в первую очередь:

  • Зарезервированные инстансы (Reserved Instances) – для постоянных нагрузок;
  • Scheduled Reserved Instances – для нагрузок, постоянно возникающих в четко определенные моменты времени;
  • Спотовые инстансы (Spot Instances) – ­ для получения во временное пользование простаивающих серверов на сотовом рынке (с существенной скидкой);
  • Оптимизация времени использования ресурсов;
  • Оптимизация объема использования ресурсов;
  • Контроль неиспользуемых ресурсов.

Читать дальше

AWS для разработчиков. Типовые сценарии использования AWS

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

Всем привет!

Этим постом мы открываем серию публикаций по использованию Amazon Web Services для создания и управления средами разработки и тестирования. Это будет серия постов, отражающих разные аспекты создания, управления и использования сред разработки и тестирования на AWS.

Однако для начала хотелось бы сделать краткий обзор того, для чего вообще создавать тестовые среды с использованием AWS. В чем преимущества? Какие основные сценарии? Какие основные возможности?

Если вы когда-нибудь начинали работать над ИТ проектом с нуля – вы точно знаете, что Аристотель был прав. Это как раз тот случай, когда начало – это, как минимум, половина дела.

Читать дальше