Рубрики
Без рубрики

Сделайте резервную копию вашего кластера AWS Redshift правильно и спите лучше!

В этой статье объясняется, как использовать функцию AWS Lambda для управления моментальными снимками кластера Amazon Redshift вручную.

Автор оригинала: Petr Hecko.

“Все терпит неудачу, все время” – Это знаменитые слова одного-единственного Вернера Фогельса. Любой, кто работает в ИТ-индустрии, должен согласиться с этим заявлением технического директора и вице-президента Amazon. Просто вспомните, когда в последний раз у вас был инцидент на производстве?

Когда в последний раз ваши клиенты испытывали перебои с использованием вашего сервиса? Когда в последний раз что-то выходило из строя и приводило к потере дохода? Вещи ломаются по разным причинам, и мы все это знаем. Поддерживать работоспособность наших приложений на уровне 100% сложно и дорого. То, что мы делаем, – это изо всех сил стараемся устранить любые возможные сбои, и у нас есть резервные планы, чтобы устранить любые сбои быстро и с минимальным воздействием на наших клиентов и доходы.

В этой статье я сосредоточусь на том, как правильно создать резервную копию вашего кластера AWS Redshift. Если вы являетесь пользователем AWS Redshift, то большие данные, вероятно, являются большой частью вашего бизнеса, и любой сбой или потеря данных без надлежащего резервного копирования могут оказать большое влияние на ваш бизнес. Поскольку мы знаем, что все время терпит неудачу , давайте ограничим возможное влияние нашего сбоя кластера Redshift правильным решением для резервного копирования!

Что это за красное смещение AWS, спросите вы?

Давайте начнем с краткого вступления к AWS Redshift таким образом, мы все находимся на одной странице, прежде чем углубляться в стратегии резервного копирования. Amazon Redshift-это быстрое, полностью управляемое хранилище данных. Вы можете загрузить до петабайт данных в кластеры Amazon Redshift, а затем проанализировать их с помощью стандартного SQL и существующих инструментов бизнес-аналитики. Redshift | это очень экономичное решение для анализа ваших данных, и, как говорит Amazon, оно обойдется вам “менее чем в десятую часть стоимости традиционных решений”.

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

Поскольку Redshift полностью управляется Amazon, вы будете получать автоматические резервные копии по умолчанию, из коробки. Автоматическое резервное копирование включается по умолчанию при создании кластера Redshift. Amazon всегда будет пытаться поддерживать как минимум три копии данных – оригинал и реплику на вычислительных узлах и резервную копию в сервисе Amazon S3 (s3 – Simple Storage Service). Управлять настройками автоматического резервного копирования из самой консоли AWS очень просто, и мы больше не будем говорить об этом типе резервного копирования. В дальнейшем мы поговорим о резервном копировании вашего кластера Красного смещения вручную – почему и как вы это сделаете?

Зачем делать снимки вручную, если у нас есть автоматизированные “из коробки”?

Если по какой-либо причине вы удалите свой кластер Redshift, все снимки, сделанные автоматически, также будут удалены. Это означает, что если по какой-то причине, например по человеческой ошибке, кластер будет удален, все ваши данные исчезнут. Это главная причина, по которой вы также должны делать регулярные снимки вручную. Ручные моментальные снимки не будут автоматически удалены Amazon, а также сохранятся в том случае, если был удален весь кластер. Если кластер был удален по ошибке, вы всегда можете восстановить его из последнего моментального снимка вручную. Поскольку по умолчанию существует ограничение в 20 моментальных снимков вручную для вашего кластера, вам также необходимо удалить старые моментальные снимки, чтобы освободить место для новых.

Так как же создать снимок вручную?

Это хороший вопрос! Очень легко перейти к консоли AWS Redshift и выполнить ручной снимок, нажав одну кнопку, однако это не очень практично, что мы хотим делать ежедневно. Вместо этого было бы здорово иметь сценарий, который сделает это за нас. Было бы еще лучше, если бы этот скрипт мог работать без сервера – это означает, что мы не будем развертывать скрипт на любой виртуальной машине, которой нам нужно будет управлять, вместо этого мы просто будем использовать AWS Lambda для запуска скрипта. Было бы также очень хорошо, если бы этот скрипт удалил старые снимки и уведомил нас в случае возникновения какой-либо ошибки. Что ж, у меня есть отличная новость – такой скрипт существует, и вы вольны использовать его для своих нужд!

Где я могу найти скрипт и как начать его использовать?

Еще один отличный вопрос, вы в огне! Скрипт можно найти на GitHub . Теперь я объясню функциональные возможности скрипта, а также как начать его использовать (я также объясняю использование в файле Readme для вашего удобства). Я не буду вдаваться в подробности настройки различных сервисов AWS, а скорее свяжу их с документацией. Также не стесняйтесь комментировать ниже, если что-то не ясно с настройкой, и я с удовольствием постараюсь помочь!

Создание моментальных снимков вручную

Функция создания моментальных снимков вручную ( redshift_manual_snap ) будет перебирать все автоматические моментальные снимки Redshift и сортировать их по самой последней дате. Затем будет сделан ручной снимок для последнего автоматизированного снимка для каждого кластера в регионе AWS, где развернута эта функция.

Удаление моментальных снимков вручную

Функция удаления моментальных снимков вручную ( redshift_snapshot_remover ) будет циклически перебирать все моментальные снимки вручную Redshift и сравнивать дату создания моментального снимка с периодом хранения, заданным в качестве переменной среды (см. раздел ниже). Если определенные снимки должны сохраняться, функцию нужно будет настроить, чтобы исключить эти снимки, или в этом случае существует также переменная окружения с именем max_back , которая будет указывать максимальное время для просмотра старых снимков, поэтому, если вам нужно сохранить снимки, сделанные несколько месяцев назад, установите значение max_back , например, на 30, чтобы функция не удаляла снимки, сделанные более 30 дней назад.

Уведомления SNS о сбоях

Функция push message to AWS SNS (Simple Notification Service) ( notify_devops ) опубликует сообщение в теме SNS. Цель этой функции-уведомить команду о любых сбоях в создании моментального снимка. Если вам нужна помощь в создании темы SNS в AWS, страница Getting Started – отличный ресурс. Затем тема SNS ARN должна быть определена как переменная окружения при создании лямбда-функции. Рекомендуется подписаться на список рассылки электронной почты в этой теме SNS, чтобы правильная команда или служба были уведомлены о сбоях.

Регистрация

Когда эта лямбда-функция запущена, все журналы записываются в журналы Amazon Cloudwatch. Для этого не требуется никакой настройки, и единственное требование-настроить Лямбду с правильной ролью/разрешениями (см. Ниже). После первого запуска будет автоматически создана новая группа журналов (что-то похожее на /aws/lambda/YOURFUNCTIONNAME ), и журналы будут создаваться после каждого запуска функции.

Начальная настройка

Лямбда-функция

Эта лямбда-функция должна быть настроена в регионе AWS, где существует кластер Redshift и можно сделать снимки вручную. Если вы совершенно новичок в AWS Lambda, взгляните на учебники Getting Started для быстрого обучения. Функция должна быть настроена как Python 2.7 Runtime, а Обработчик должен быть основной функцией lambda_function.lambda_handler . Для того чтобы эта функция работала, необходимо правильно прикрепить роль IAM – эта роль IAM должна иметь доступ к Redshift, а также к журналам Cloudwatch. Поскольку функция должна считывать/записывать данные, для роли рекомендуется использовать управляемые политики AWS AmazonRedshiftFullAccess и CloudWatchLogsFullAccess – если вам нужна помощь в создании этой роли IAM, пожалуйста, обратитесь к документации AWS или добавьте комментарий ниже. Также рекомендуется увеличить лямбда-тайм-аут в зависимости от среды, количества и размера кластеров красного смещения, но в большинстве случаев 30 секунд должно быть достаточно.

Раздражители

Amazon делает автоматические снимки кластера Redshift несколько раз в день, обычно каждые 8 часов или после каждого изменения данных в 5 ГБ. Этот сценарий предназначен для создания ручного снимка последнего автоматизированного снимка для каждого кластера и НЕ БУДЕТ делать моментальных снимков для КАЖДОГО автоматизированного снимка. Поскольку этот скрипт делает один ручной снимок в день, рекомендуется настроить лямбда-триггер в качестве расписания событий Cloudwatch: Например cron(0 4 * * ? *) будет вызывать эту функцию каждый день в 4 часа утра по Гринвичу.

Переменные среды

Сценарий требует настройки 3 переменных окружения. Переменные должны установить Период хранения, SNS topic ARN и Максимальное время, чтобы оглянуться назад для любых ручных снимков – это делается для того, чтобы избежать удаления любых старых устаревших снимков, которые все еще могут понадобиться в будущем. Пример настройки переменной можно увидеть здесь:

{
  "ret_period":"7",
  "sns_topic":"arn:aws:sns:us-east-1:123456789101:topic_name",
  "max_back":"25"  
}

Вывод

Если вы дошли до этого момента, я приветствую вас, я лично использовал этот сценарий или несколько другие его варианты в нескольких различных проектах. Хорошо то, что после того, как вы сделаете первоначальную настройку, вам не нужно будет беспокоиться о ваших ручных снимках. Если по какой-либо причине что-то пойдет не так, AWS SNS отправит вам уведомление, и вы сможете устранить эту ошибку. Я надеюсь, что это может помочь некоторым из вас в достижении ваших целей аварийного восстановления!