- База данных›
- Amazon Elasticache›
- Страница справки по управляемому обслуживанию и сервисным обновлениям Amazon ElastiCache
Страница справки по управляемому обслуживанию и сервисным обновлениям Amazon ElastiCache
Обзор
Мы часто обновляем кластеры и узлы Amazon ElastiCache, при этом многие исправления и обновления устанавливаются на инстансы незаметно для пользователей. Мы делаем это, используя один из двух способов:
а) непрерывное управляемое обслуживание; б) сервисные обновления. Обслуживание и сервисные обновления необходимы для установки обновлений, улучшающих безопасность, надежность и эксплуатационные характеристики.
Непрерывное управляемое обслуживание осуществляется периодически и непосредственно в окнах обслуживания без необходимости в каких-либо действиях с вашей стороны.
Сервисные обновления дают гибкость: их можно применять самостоятельно. Они производятся в течение установленного времени и могут быть перемещены в окно обслуживания, которое будет выделено, когда придет назначенное время.
У вас есть возможность самостоятельно управлять обновлениями в любое время до запланированного интервала обслуживания. Если клиент управляет обновлением самостоятельно, его инстанс получает обновление ОС во время перезапуска узла, при этом запланированное окно обслуживания будет отменено.
Сервисные обновления
Что такое сервисные обновления в Amazon ElastiCache?
Сервисные обновления – это функция Amazon ElastiCache, благодаря которой можно применять определенные сервисные обновления по собственному усмотрению. Такие обновления делятся на следующие типы: исправления безопасности и текущие обновления ПО. Они повышают безопасность и надежность, а также способствуют повышению производительности кластеров.
Сервисные обновления удобны тем, что их применением управляете вы (например, можно отсрочить применение сервисных обновлений, когда происходит важное бизнес-мероприятие, требующее круглосуточной доступности кластеров ElastiCache).
Подробную информацию о каждом сервисном обновлении см. в значении атрибута Update Description (Описание обновления).
Как получить уведомление о доступном сервисном обновлении Elasticache?
Когда появляются сервисные обновления кластеров, мы уведомляем вас по нескольким каналам, включая консоль Amazon ElastiCache, электронную почту, Amazon Simple Notification Service (SNS), персональную панель работоспособности AWS и события Amazon CloudWatch.
Чем обновления, применяемые во время окна обслуживания, отличаются от сервисных обновлений?
Обновления, предоставляемые в ходе непрерывного управляемого обслуживания, отличаются от сервисных обновлений. Обновления, которые применяются в ходе непрерывного управляемого обслуживания, планируются непосредственно в окнах обслуживания, не требуя никаких действий с вашей стороны. Сервисные обновления проводятся в течение определенного времени, и вы решаете, применять ли их до рекомендуемой даты применения. Если к назначенной дате они не применены, то ElastiCache может запланировать эти обновления на окно обслуживания.
Как узнать, требуется ли применить доступное сервисное обновление?
Если кластер Elasticache участвует в программе соответствия HIPAA, PCI или FedRAMP, то для обеспечения соответствия требованиям сервисные обновления необходимо применять до рекомендуемой даты применения. Подробнее см. в разделе Самостоятельное применение обновлений безопасности для соответствия требованиям.
Сервисные обновления других кластеров рекомендуется применять в соответствии с ритмом бизнеса. Даже если вам не удается применить сервисное обновление до рекомендуемой даты применения, можно применить его до даты истечения срока действия обновления. Однако дата истечения срока действия обновления в любой момент может измениться, если появятся новые обновления.
Как повлияет сервисное обновление на кластеры ElastiCache? Будут ли потеряны данные или подключение к моим кластерам?
Когда вы или Amazon Elasticache назначаете сервисное обновление одного или нескольких кластеров, то оно выполняется по одному узлу в каждом сегменте, пока все выбранные кластеры не будут обновлены. Обновляемые узлы в течение нескольких секунд будут находиться в режиме простоя, в то время как остальная часть кластера продолжит работать с трафиком.
- Конфигурация кластеров не изменяется.
- В метриках CloudWatch будет заметна задержка, которая в скором времени устранится.
Сервисные обновления, как и обновления при непрерывном управляемом обслуживании, применяются путем замены узла. Подробную информацию о применении и подготовке к обновлению с минимальным воздействием см. в указанных далее вопросах раздела Обновления при непрерывном управляемом обслуживании.
- Как замена узла повлияет на мое приложение?
- Каким рекомендациям следовать, чтобы замена произошла без проблем и с минимальными потерями данных?
- Каким рекомендациям по настройке клиента следовать, чтобы сократить продолжительность прерывания работы приложения во время обслуживания до минимума?
Происходит ли простой во время обновления кластеров ElastiCache для Memcached?
Да, узел заменяется новым пустым узлом. Содержимое кэша на нем отсутствует, и он начинает работу с нуля.
Можно ли отказаться от сервисных обновлений?
Информация о том, можно ли отказаться от сервисного обновления, указана в значении атрибута Автоматическое обновление после указанной даты. Если для атрибута Автоматическое обновление после указанной даты сервисного обновления установлено значение нет, от этого сервисного обновления можно отказаться. Но если для атрибута Автоматическое обновление после указанной даты сервисного обновления установлено значение да, а рекомендуемая дата применения прошла, ElastiCache запланирует сервисное обновление для остальных кластеров на следующее окно обслуживания. Это автоматическое сервисное обновление будет запланировано до даты истечения срока действия обновления, и вы получите уведомление за неделю до обновления с указанием запланированного времени. Мы настоятельно рекомендуем применять обновления безопасности, даже если от них можно отказаться. Если вы решите применить сервисное обновление к остальным кластерам до окна обслуживания, ElastiCache не будет повторно применять его во время окна обслуживания.
Почему сервисные обновления не могут быть применены ElastiCache непосредственно во время окна обслуживания?
Сервисные обновления дают вам свободу применять их, когда потребуется. Кластеры, которые не участвуют в поддерживаемых ElastiCache программах соответствия, могут не применять их вообще или же применять реже в течение года. Это применимо только в ситуации, когда для атрибута сервисного обновления Auto-Update after Due Date (Автоматическое обновление после установленной даты) установлено значение no (нет). Подробнее см. в вопросе «Можно ли отказаться от сервисных обновлений»?
Можно ли использовать возможность сервисных обновлений, чтобы отказаться от сервисного обслуживания Amazon ElastiCache и применить обновления самостоятельно?
Нет. Сервисные обновления и непрерывное управляемое обслуживание, которое применяется Amazon ElastiCache непосредственно во время окон обслуживания кластеров, исключают друг друга.
Где находится список всех атрибутов сервисного обновления?
Полный список атрибутов и их описаний приведен в разделе Самостоятельное применение обновлений.
По одинаковому ли графику производятся сервисные обновления?
Чтобы определить, как скоро требуется применять сервисные обновления, проверьте значение атрибута Severity (Серьезность) (приведены в порядке приоритета).
1. Критическое. Рекомендуется применить немедленно (не позднее чем через 14 дней).
2. Важное. Рекомендуется применить, как только позволят бизнес-процессы (не позднее чем через 30 дней).
3. Средней серьезности. Рекомендуется применить не позднее чем через 60 дней.
4. Низкой серьезности. Рекомендуется применить не позднее чем через 90 дней.
Подробнее см. в нашей общедоступной документации о применении обновлений.
Как часто выпускаются сервисные обновления?
График выпуска зависит от важности сервисных обновлений.
Что представляет собой атрибут Service Update SLA Met (SLA по сервисному обновлению выполнено)?
В этом атрибуте указано, был ли обновлен кластер до рекомендуемой даты применения. Если сервисное обновление применено после рекомендуемой даты применения, то для атрибута Service Update SLA Met (SLA по сервисному обновлению выполнено) будет установлено значение no (нет).
Эта информация относится к кластерам Amazon Elasticache, которые участвуют в программах соответствия HIPAA, PCI и FedRAMP. Подробнее см. в разделе Самостоятельное применение обновлений безопасности для соответствия требованиям.
Если я пропущу одно или несколько сервисных обновлений, смогу ли я применить их позже?
Да. Если в атрибуте Description (Описание) сервисного обновления не указано иное, сервисные обновления являются накопительными: если вы не примените их к дате истечения срока действия обновления, они будут включены в следующее сервисное обновление. Сервисные обновления типа security (безопасность) попадают в категорию накопительных.
Можно ли применить сервисное обновление только к некоторым узлам кластера ElastiCache?
Нет, сервисные обновления применяются на уровне кластера. Если отменить текущее обновление, некоторые узлы кластера будут обновлены, а некоторые – нет. В таком случае кластер будет включен в список кластеров, к которым требуется применить сервисное обновление. Этот кластер продолжит работать в нормальном режиме.
Почему состояние обновления одного или нескольких узлов в моих кластерах ElastiCache изменилось с not-applied (не применено) на complete (выполнено), хотя сервисное обновление не применялось?
Это может произойти в двух случаях:
а) если вы не применили необязательное сервисное обновление и это обновление сейчас находится в состоянии expired («срок действия истек»). Поэтому для кластеров, которые участвуют в программах соответствия, всегда должны применяться сервисные обновления.
б) если один или несколько узлов по какой-либо причине заменены, например в ходе планового обслуживания или обработки отказа узла, Amazon ElastiCache предоставит новые узлы с новейшим сервисным обновлением.
В обоих случаях этот кластер продолжит работать в нормальном режиме.
Что делать, если на некоторых узлах вовремя не применено сервисное обновление? Ждать ли следующего сервисного обновления?
Новые узлы содержат все применимые сервисные обновления, поэтому вы можете вручную заменить существующие узлы, которые не обновлены.
Зависят ли сервисные обновления от движка?
Да. Сервисное обновление может быть применимым только к OSS Redis, только к Memcached или к обоим из них. См. атрибуты Engine (Движок) и Engine Version (Версия движка), чтобы определить объем каждого сервисного обновления.
Можно ли перенести плановое сервисное обновление на более удобное время? Что произойдет с запланированным обновлением, если я изменю окно обслуживания?
Да, вы можете отложить обновление сервиса, изменив окно обслуживания. Запланированное обновление будет применено к кластеру только в том случае, если планируемая дата совпадает с окном обслуживания. При изменении окна и по прошествии планируемой даты обновление сервиса будет перенесено в новое указанное в течение следующих недель окно. За неделю до новой даты вы получите новое оповещение.
Безопасность в AWS – это общая ответственность. Мы настоятельно рекомендуем применить обновление как можно скорее.
Почему я получаю уведомления о нескольких обновлениях одного и того же кластера? Нужно ли применять все?
На ваш кластер могут распространяться обновления различных сервисов. Большинство обновлений не требуют отдельного применения. Как только вы примените одного обновление, другие доступные будут помечены в качестве завершенных. Если статус не изменится на «Завершено» автоматически, то может потребоваться несколько применений обновлений в одном и том же кластере.
Как сервисное обновление планируется и применяется после рекомендуемой даты применения?
ElastiCache запланирует сервисное обновление для остальных кластеров после рекомендуемой даты применения, если для атрибута Auto-Update after Due Date (Автоматическое обновление после установленной даты) установлено значение yes (да). Обновление будет запланировано в рамках окна обслуживания кластера, и вы получите новое оповещение за неделю до запланированной даты применения обновлений.
Запланированное сервисное обновление будет применено к кластерам аналогично обновлениям при непрерывном управляемом обслуживании. Подробную информацию о применении обновлений, изменении запланированных обновлений и подготовке к обновлению с минимальным воздействием см. в приведенном далее разделе.
Что произойдет, если сервисное обновление невозможно применить ко всему кластеру в рамках одного окна обслуживания?
Чтобы обеспечить стабильность кластера, ElastiCache применяет обновления по одному узлу в каждом сегменте. Если обновление сервиса не удается применить ко всему кластеру в рамках одного окна обслуживания, то оно продолжится в следующих окнах. Вы получите новые оповещения перед следующей запланированной датой и сможете подготовиться соответственно.
Можно ли откатить сервисное обновление?
Клиент не может откатить обновление сервиса после его запуска. Если после применения сервисного обновления вы обнаружите проблему, обратитесь в службу поддержки AWS.
Обновления при непрерывном управляемом обслуживании
Что такое обновление при непрерывном управляемом обслуживании?
Эти обновления обязательны, они применяются непосредственно во время окон обслуживания без необходимости в каких-либо действиях с вашей стороны. Эти обновления отличаются от сервисных обновлений.
Сколько времени занимает замена узла?
Замена узла обычно занимает несколько секунд. При определенных схемах трафика и конфигурациях инстансов замена может продолжаться дольше. Например, на первичных узлах OSS Redis может оказаться недостаточно свободной памяти, к тому же они могут получать большой объем трафика записи. При синхронизации пустой реплики с таким первичным узлом у него может не хватить памяти для обработки входящих операций записи и выполнения синхронизации. В таком случае мастер отключает реплику и перезапускает процесс синхронизации. Для успешной синхронизации реплики может потребоваться несколько попыток. При сохранении высокого трафика записи синхронизация реплики может так и не состояться.
Узлы Memcached не нуждаются в синхронизации, поэтому их замена выполняется быстрее, независимо от размера узлов.
Как замена узла повлияет на мое приложение?
В процессе замены узлов OSS Redis предпринимаются все необходимые действия для сохранения существующих данных; такой процесс требует успешной репликации. Для кластеров с одним узлом Elasticache динамически разворачивает реплику, реплицирует данные и затем переключается на работу с ней. Для групп репликации, состоящих из нескольких узлов, Elasticache заменяет существующие реплики и синхронизирует данные новых реплик с основной. Если используется поддержка нескольких зон доступности с автоматической отказоустойчивостью, замена основного узла вызывает переключение на реплику чтения. Для конфигураций кластера, настроенных на использование клиентов кластера, и некластерных конфигураций с включенной автоматической отказоустойчивостью запланированные замены узлов выполняются таким образом, что кластер продолжает обрабатывать входящие запросы на запись. Если поддержка множества зон доступности выключена, Elasticache заменяет основную реплику и затем синхронизирует данные с репликой чтения. Поскольку основной узел в это время недоступен, запись прерывается на более длительный срок.
Для узлов Memcached в процессе замены создается новый пустой узел, при этом работа текущего узла останавливается. В процессе переключения новый узел в течение некоторого времени недоступен. После переключения в приложении может наблюдаться снижение производительности, пока пустой узел заполняется кэшируемыми данными.
Каким рекомендациям следовать, чтобы замена произошла без проблем и с минимальными потерями данных?
В процессе замены узлов OSS Redis предпринимаются все необходимые действия для сохранения существующих данных; такой процесс требует успешной репликации. Мы одновременно заменяем в одном кластере столько узлов, сколько можно заменить без ущерба для его стабильности. Основной узел и реплики чтения можно разместить в разных зонах доступности. В таком случае при замене узла данные синхронизируются из соответствующего узла в другой зоне доступности. Также рекомендуется обновить версию OSS Redis до 5.0.6 или выше, поскольку эти версии отличаются повышенной стабильностью и позволяют кластерам (если у них включена функция автоматической отказоустойчивости) непрерывно обслуживать входящие запросы на запись во время установки исправлений. Если же в вашей конфигурации используется только одна первичная и одна единичная реплика на сегмент, рекомендуется добавить дополнительные реплики до внесения исправлений. Это позволит избежать снижения доступности и устранить риски, связанные с установкой исправлений. При использовании кластеров с одним узлом рекомендуется выделить OSS Redis достаточный объем памяти, как описано здесь. Для групп репликации с множеством узлов рекомендуется также планировать замену на период времени с низким входящим трафиком записи.
Для узлов Memcached рекомендуется планировать окно обслуживания на период низкого входящего трафика записи, тестировать приложение на автоматическую отказоустойчивость и использовать интеллектуальный клиент ElastiCache. В этом случае избежать потери данных невозможно, поскольку на узлах Memcached данные хранятся только в памяти.
Каким рекомендациям по настройке клиента следовать, чтобы сократить продолжительность прерывания работы приложения во время обслуживания до минимума?
Для OSS Redis оптимальную доступность во время управляемых или неуправляемых операций обеспечивает конфигурация в режиме кластера. Рекомендуется всегда использовать клиент, который поддерживает режим кластера и подключается к адресу обнаружения кластера. Если режим кластера отключен, для всех операций записи рекомендуется всегда использовать основной адрес. Отдельные адреса узлов реплики могут использоваться для всех операций чтения. Если в кластере включена автоматическая обработка отказов, основной узел может измениться, поэтому приложение должно подтвердить роль узла, обновить все прочитанные адреса и убедиться, что вы не нагружаете ведущий узел слишком сильно. Если автоматическая обработка отказов отключена, роль узла не изменится, однако время простоя в управляемых или неуправляемых операциях будет выше по сравнению с кластерами с включенной автоматической обработкой отказов. Не рекомендуется направлять запросы на чтение только на реплики чтения. Если клиент настроен для отправления запросов на чтение только на реплики чтения, убедитесь, что существует как минимум две реплики чтения, чтобы избежать прерывания чтения во время обслуживания.
Как самостоятельно управлять заменой узлов?
Мы рекомендуем предоставлять возможность выполнять замену узлов в рамках запланированного окна обслуживания сервису ElastiCache. Оптимальное время замены в рамках окна обслуживания можно указать при создании кластера ElastiCache. Чтобы перенести окно обслуживания на более удобное время, можно использовать API ModifyCacheCluster или нажать «Modify» (Изменить) в консоли управления ElastiCache.
При самостоятельном управлении заменой узлов можно выполнять различные операции в соответствии с конкретным примером использования и конфигурацией кластера.
• Изменение окна обслуживания.
• Перезапуск инстанса с использованием процедуры резервного копирования и восстановления.
• При использовании конфигурации кластера с отключенным параметром cluster_mode:
o замена реплики чтения с отключенным параметром cluster_mode – процедура замены реплики чтения в группе репликации вручную;
o замена первичного узла с отключенным параметром cluster_mode – процедура замены первичного узла в группе репликации вручную;
o замена отдельного узла с отключенным параметром cluster_mode – две разных процедуры замены отдельного узла.
• При использовании конфигурации кластера с включенным параметром cluster_mode:
o замена узла в кластере с одним или несколькими сегментами – резервное копирование и восстановление или масштабирование в сторону увеличения с последующим масштабированием в сторону уменьшения для замены узлов.
Подробнее обо всех этих вариантах см. на странице действий, которые можно предпринять, когда запланирована замена узла.
Кластеры Memcached можно просто удалить и создать заново. После замены у вашего инстанса больше не должно быть запланированного события, связанного с ним.
Как узнать о намеченной запланированной замене?
Для получения информации вы можете настроить уведомления Amazon SNS о таких важных событиях, как запланированная замена. Вы можете использовать консоль управления ElastiCache в разделе событий или вызвать API describe-events (описания событий) для проверки предстоящего события ElastiCache:NodeReplacementScheduled.
Для настройки уведомлений SNS используйте информацию по этой ссылке.
Можно ли перенести плановое обслуживание на более удобное время?
Да, окно обслуживания кластера можно изменить. Чтобы перенести окно обслуживания на более удобное время, можно использовать API (ModifyCacheCluster или ModifyReplicationGroup) либо нажать кнопку «Modify» (Изменить) в консоли управления ElastiCache.
После изменения окна обслуживания сервис ElastiCache запланирует обслуживание узла в пределах нового окна. О том, как изменения вступают в силу, рассказывается в примерах ниже.
Пример
Допустим, сейчас четверг, 9 ноября, 15:00, а следующее окно обслуживания приходится на пятницу, 10 ноября, 17:00. Ниже приводятся три сценария с результатами.
• Вы переносите окно обслуживания на пятницу, 16:00 (на будущую дату и время, до следующего запланированного окна обслуживания на текущей неделе). Узел будет заменен в пятницу, 10 ноября, в 16:00.
• Вы переносите окно обслуживания на субботу, 16:00 (на будущую дату и время, после запланированного окна обслуживания на текущей неделе). Узел будет заменен в субботу, 11 ноября, в 16:00.
• Вы переносите окно обслуживания на среду, 16:00 (на уже прошедшую дату и время на текущей неделе). Узел будет заменен в следующую среду, 15 ноября, в 16:00.
С какой целью выполняется эта замена узлов?
Такие замены необходимы для установки обязательных программных обновлений на базовый хост. Обновления повышают безопасность и надежность, а также способствуют повышению производительности.
Может ли замена узлов в нескольких зонах доступности выполняться одновременно?
В зависимости от конфигурации мы имеем возможность заменить несколько узлов, не нарушая стабильной работы кластера. В случае сегментированных кластеров мы стараемся не проводить одновременную замену нескольких узлов в пределах одного сегмента. Мы также стараемся не заменять большую часть ведущих узлов кластера в пределах всего набора фрагментов.
В случае нефрагментированных кластеров мы пытаемся выполнить замену узлов в пределах окна обслуживания таким образом, чтобы это не нарушило стабильной работы кластера.
Может ли замена узлов в разных кластерах из разных регионов выполняться одновременно?
Да, если окна обслуживания для этих кластеров совпадают, узлы в них могут быть заменены одновременно.