Александр Гришин

Привет, Хабр! Я Александр Гришин, отвечаю за развитие облачных баз данных и объектного хранилища в Selectel. В своей практике часто сталкиваюсь с разными задачами клиентов. Среди них, например: реализовать репликацию данных между удаленными друг от друга регионами, отработать домен отказа «Регион» и повысить уровень отказоустойчивости своих сервисов, убрав привязку к одному городу и инфраструктуре. Сегодня я расскажу, как легко реализовать асинхронную репликацию данных в инфраструктуре Selectel, используя Python и boto3. Погнали! Исходная задача Нужно обеспечить географическую разнесенность и катастрофоустойчивость хранящихся у компании резервных копий по разным бакетам, городам и федеральным округам на расстоянии около 700 км. В бакете-источнике будут лежат резервные копии. Нам нужно раз в час по cron забирать эти данные и передавать в бакет-приемник. Разумеется, без оплаты за трафик при перегоне данных. Вариант реализации Разумеется, я воспользуюсь инфраструктурой Selectel. Что потребуется: бакет в ru-7 (Москва); бакет в ru-1 (Санкт-Петербург); между ними — виртуальная машина в регионе СПб в пуле ru-1, которая запускает Python-скрипт и копирует объекты из одного региона в другой. Концептуальная схема поставленной выше задачи. Такое решение позволяет нам: сокращать задержки при записи в целевой бакет; получать максимальную пропускную способность; не платить за входящий/исходящий трафик между регионами — весь он остается внутри сети Selectel, считается внутренним и не тарифицируется; вся инфраструктура находится в Selectel и не зависит от третьих лиц — получаем понятный уровень SLA и единое окно для обслуживания. Часть реализации в панели управления Selectel Я перечислю только основные шаги. Сначала создаем инфраструктуру для хранения данных. Перейдите в панель управления → Объектное хранилище. Выберете нужный регион, например Москва ru-7 → Создать контейнер (бакет). Выберите холодный класс хранения (оптимально для резервных копий). Выберите тип адресации vHosted. Это тип адресации подразумевается как базовый для S3-бакета. Тип контейнера — приватный (для работы с чувствительными данными). Повторите первые три шага в каждом интересующем вас регионе, например в Санкт-Петербург ru-1. Создайте служебного пользователя с ролью администратора объектного хранилища и доступом в этот проект. Создайте S3-ключ в панели управления. Сохраните Access Key и Secret Key (будьте внимательны: ключи не хранятся в наших системах и показываются только один раз). Создаем инфраструктуру для репликации. Перейдите в раздел Облачные серверы. Выберите нужный регион и пул, например Санкт-Петербург ru-1. Выберите необходимую конфигурацию сервера. Учтите, что объекты будут промежуточно загружаться на эту виртуальную машину, поэтому я предлагаю подключить сетевой диск. Его потом можно легко масштабировать хоть до 10 ТБ. Под OS будем использовать небольшой, но производительный локальный SSD NVMe-диск. Выбираем приватную подсеть. Добавляем SSH-ключ и создаем виртуальную машину. Для простого доступа по SSH используем публичный IP-адрес. Для дальнейшей работы репликации он не нужен, т. к. можно организовать доступ виртуальной машины в интернет из приватной сети, используя облачный роутер. Пример подходящей конфигурации облачного сервера. Используем виртуальную машину с сетевым диском сразу на 1 ТБ — этого хватит с запасом. К тому же, это не дорого. Настройка на клиенте Для автоматизации будем писать простой скрипт на Python + boto3. На виртуальной машине создаем файл replicate_s3.py. Этот скрипт реализует асинхронную репликацию объектов между двумя регионами — из пула ru-7 (Москва) в ru-1 (Санкт-Петербург). Что делает этот скрипт. Сперва он подключается к двум S3-клиентам (источник и приемник). Затем получает список всех объектов из исходного бакета. И наконец, поочередно скачивает каждый объект и загружает его в целевой бакет. Кроме того, скрипт логирует процесс: количество файлов, успешные копирования и возможные ошибки. Настройка cron для регулярного запуска Скрипт можно расширить логикой фильтрации или копирования только новых объектов. А еще он хорошо подойдет для запуска по cron, чтобы можно былорегулярного переносить данные. 1. Открываем crontab: crontab -e 2. Добавляем строку — например, запуск каждый час — для путей, по которым хранятся объекты: 0 * * * * /usr/bin/python3 /path/to/replicate_s3.py >> /var/log/replication.log 2>&1 Замените /usr/bin/python3 и /path/to/replicate_s3.py. >> /var/log/replication.log логирует вывод в файл. Это удобно для последующей отладки, если что-то пойдет не так. Все пути до исполняемых файлов следует указывать абсолютными. 3. Сохраняем файл, выходим из редактора и проверяем список заданий: crontab -l Итог Мы за полчаса реализовали географически распределенное и катастрофоустойчивое хранение резервных копий в двух локациях: Москве и Санкт-Петербурге. Репликация автоматически запускается каждый час и сопровождается логированием всех действий нашей системы. Бонус — весь трафик остается в пределах инфраструктуры Selectel и не тарифицируется. А дополнительные логи можно получить еще и со стороны хранилища. Разумеется, это тривиальный пример с простым кодом. Его цель — раскрыть ключевые идеи реализации задачи Disaster Recovery на базе инфраструктуры объектного хранилища. Для использования в проде решение стоит улучшить. Например, реализовать: поддержку копирования только новых объектов (по дате); уведомления в Telegram/Slack при сбоях; более тонкую настройку политики доступа для сервисного пользователя — например, ограничение доступа из интернета к бакету по разрешенным IP (SourceIp); хранение версий объекта, что поможет при необходимости вернуться к конкретной версии объекта. Следите за обновлениями в Академии Selectel. В следующей статье я расскажу, как работать с версионированием объектов в S3.

Александр Гришин

Материалы автора

OpenSearch как сервис: обзор и пример использования на Python

Облачные базы данных как конструктор

Разбираемся в облачных хранилищах на примере Top Gear

Apache Kafka: разбираемся в технологии в теории и на практике