Как изящно обновить ECS-сервис, образуя кластерную группу Hazelcast? - PullRequest
Новая
       98

Как изящно обновить ECS-сервис, образуя кластерную группу Hazelcast?

1 голос
/ 29 января 2020

У нас есть ECS-сервис (EC2 ECS) с несколькими задачами, образующими кластерную группу Hazelcast (hazelcast: 3.10.6, hazelcast- aws: 2.2, мы используем Hazelcast для хранения некоторых общих данных и блокировок в распределенных объектах) , Он использует непрерывное обновление службы с минимальным процентом исправности, установленным на 100, и максимумом на 200.

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

Да, мы можем реорганизовать службу, чтобы использовать модель клиент-сервер для хранения сетки памяти в отдельной службе или используйте альтернативы, такие как хранение блокировок в Redis, но было бы интересно послушать кого-то, кто уже сталкивался с подобными трудностями и нашел способ изящно обновить службы с поддержкой Hazelcast в ECS.

1 Ответ

0 голосов
/ 29 января 2020

Чтобы сделать Hazelcast надежным практически в любой контейнерной среде, вам нужно определить постепенное отключение . Это предотвратит любую потерю данных или уничтожение нескольких экземпляров Hazelcast одновременно.

Для этого вы можете проверить ECS do c о StopTask и документации Hazelcast изящное отключение . Короче говоря, вам нужно:

  • Добавить hazelcast.shutdownhook.policy=GRACEFUL в JAVA_OPTS
  • Добавить hazelcast.graceful.shutdown.max.wait=<max-waiting-time-for-data-migration> в JAVA_OPTS
  • Изменить ECS_CONTAINER_STOP_TIMEOUT переменную env <max-waiting-time-for-data-migration>

Если вы храните много данных в кластере Hazelcast, вы можете установить значение max-waiting-time-for-data-migration на большое число, например, даже на несколько часов.

...