Страница справки по управляемому обслуживанию и сервисным обновлениям Amazon ElastiCache

Вопрос. Что такое сервисные обновления в Amazon ElastiCache?

Сервисные обновления – это функция Amazon ElastiCache, благодаря которой можно применять определенные обновления сервиса по собственному усмотрению. Такие обновления делятся на следующие типы: исправления безопасности и текущие обновления ПО. Они повышают безопасность и надежность, а также способствуют повышению производительности кластеров.

Сервисные обновления удобны тем, что их применением управляете вы (например, можно отсрочить применение сервисных обновлений, когда происходит важное бизнес-мероприятие, требующее круглосуточной доступности кластеров ElastiCache).

Подробную информацию о каждом обновлении сервиса см. в значении атрибута Update Description (Описание обновления). 

Вопрос. Как получить уведомление о доступном сервисном обновлении Elasticache?

Когда появляются сервисные обновления кластеров, мы уведомляем вас по нескольким каналам, включая консоль Amazon Elasticache, электронную почту, простой сервис уведомлений Amazon (Amazon SNS), панель работоспособности AWS и события Amazon CloudWatch.

Вопрос. Как в окне обслуживания применяются обновления, которые не являются сервисными?

Обновления, предоставляемые в ходе непрерывного управляемого обслуживания, отличаются от сервисных обновлений. Обновления, которые применяются в ходе непрерывного управляемого обслуживания, планируются непосредственно в окнах обслуживания, не требуя никаких действий с вашей стороны. Сервисные обновления проводятся в течение установленного времени, и вы можете устанавливать, требуется ли их применить в «Рекомендуемую дату применения». Если к назначенной дате они не применены, то ElastiCache может запланировать эти обновления на окно обслуживания.

Вопрос. Как узнать, требуется ли применить доступное сервисное обновление?

Если кластер Elasticache участвует в программе соответствия HIPAA, PCI или FedRAMP, вам необходимо применять сервисные обновления до даты Рекомендовано применить до, чтобы обеспечить соответствие требованиям. Подробнее см. в разделе Самостоятельное обновление безопасности для соответствия требованиям.

Сервисные обновления других кластеров рекомендуется применять в соответствии с ритмом бизнеса. Даже если вам не удается применить сервисное обновление в «Рекомендуемую дату применения», вы сможете применить его до соответствующей «Даты истечения срока действия обновления». Однако Дата истечения срока действия обновления в любой момент может измениться, если появятся новые обновления.

Вопрос. Как повлияет сервисное обновление на кластеры Elasticache? Будут ли потеряны данные или подключение к моим кластерам?

Когда вы или Amazon Elasticache назначаете сервисное обновление одного или нескольких кластеров, то оно выполняется по одному узлу в каждом сегменте, пока все выбранные кластеры не будут обновлены. Обновляемые узлы в течение нескольких секунд будут находиться в режиме простоя, в то время как остальная часть кластера продолжит работать с трафиком.

• Конфигурация кластеров не изменяется.
• В метриках CloudWatch будет заметна задержка, которая в скором времени устранится.

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

• Как замена узла повлияет на мое приложение?
  
• Каким рекомендациям следовать, чтобы замена произошла без проблем и с минимальными потерями данных?
• Каким рекомендациям по настройке клиента следовать, чтобы сократить продолжительность прерывания работы приложения во время обслуживания до минимума?
  

Вопрос. Происходит ли простой во время обновления кластеров ElastiCache for Memcached?

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

Вопрос. Можно ли отказаться от сервисных обновлений?

Вы можете определить, можно ли отказаться от сервисного обновления, проверив значение атрибута «Автоматическое обновление по истечении срока». Если для атрибута «Автоматическое обновление по истечении срока» сервисного обновления установлено значение «нет», от этого сервисного обновления можно отказаться. Но если для атрибута обновления сервиса «Автоматическое обновление после назначенной даты» установлено значение «да», а «Рекомендуемая дата применения» прошла, ElastiCache запланирует обновление сервиса для остальных кластеров на следующее окно обслуживания. Это автоматическое сервисное обновление будет запланировано до «Даты истечения срока действия обновления», и вы получите уведомление за неделю до обновления с указанием запланированного времени. Мы настоятельно рекомендуем применять обновления безопасности, даже если от них можно отказаться.  Если вы решите применить сервисное обновление к остальным кластерам до окна обслуживания, ElastiCache не будет повторно применять его во время окна обслуживания.

Вопрос. Почему сервисные обновления не могут быть применены ElastiCache непосредственно во время окна обслуживания?

Сервисные обновления дают вам свободу применять их, когда потребуется. Кластеры, которые не участвуют в поддерживаемых ElastiCache программах соответствия, могут не применять их вообще или же применять реже в течение года. Это справедливо только в ситуации, когда атрибут сервисного обновления «Автоматическое обновление после указанной даты» имеет значение 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 запланирует обновление сервиса для остальных кластеров после оповещения «Рекомендовано применить до», если значение атрибута «Автоматическое обновление после установленной даты» равно «да». Обновление будет запланировано в рамках окна обслуживания кластера, и вы получите новое оповещение за неделю до запланированной даты применения обновлений.

Запланированное обновление будет применено к кластерам так же, как и «Непрерывные управляемые обновления обслуживания». Подробную информацию о применении обновлений, изменении запланированных обновлений и подготовке к обновлению с минимальным воздействием см. в приведенном далее разделе.

Вопрос. Что произойдет, если обновление сервиса невозможно применить ко всему кластеру в рамках одного окна обслуживания?

Чтобы обеспечить стабильность кластера, 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 замена узла в кластере с одним или несколькими сегментами – резервное копирование и восстановление или масштабирование в сторону увеличения с последующим масштабированием в сторону уменьшения для замены узлов.

Подробнее обо всех этих вариантах см. на странице Действия, которые можно предпринять, когда запланирована замена узла (Actions You Can Take When a Node is Scheduled for Replacement).

Кластеры 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.

Вопрос. С какой целью выполняется эта замена узлов?

Такие замены необходимы для установки обязательных программных обновлений на базовый хост. Обновления повышают безопасность и надежность, а также способствуют повышению производительности.

Вопрос. Может ли замена узлов в нескольких зонах доступности выполняться одновременно?

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

Вопрос. Может ли замена узлов в разных кластерах из разных регионов выполняться одновременно?

Да, если окна обслуживания для этих кластеров совпадают, узлы в них могут быть заменены одновременно.