#java #kubernetes #openshift #hazelcast
Вопрос:
У меня есть небольшой кластер Hazelcast, работающий внутри Openshift 4(kubernetes) в нескольких блоках. Моя проблема в том, что, когда я выпускаю новую версию, иногда мне нужно изменить конфигурацию экземпляров hazelcast в новой версии. Затем возникает проблема, потому что модули и старый кластер все еще работают, потому что новые модули еще не запущены должным образом. Новые обновленные элементы не будут работать, поскольку их конфигурации несовместимы с запущенным кластером (старые модули). Мы используем тип обнаружения службы без головы, описанный здесь. https://github.com/hazelcast/hazelcast-kubernetes. Данные в кластере hazelcast могут быть удалены между развертываниями, нам не нужно ничего хранить в старом кластере при запуске нового.
Мне бы хотелось, чтобы новые участники и старые участники либо игнорировали свои различия, либо создавали их как два отдельных кластера, которые не находят друг друга, либо просто не копировались между старыми и новыми участниками вообще.
Я изучил функцию переносимой сериализации https://docs.hazelcast.com/imdg/4.1.2/serialization/implementing-portable-serialization но это кажется мне излишним, так как нам не нужны данные кластера, чтобы выжить между развертываниями. Я также не уверен, поможет ли это, когда мы изменим что-то в конфигурации для экземпляров hazelcast, что сделает кластеры несовместимыми.
Наконец, я рассмотрел возможность изменения стратегии развертывания для kubernetes, чтобы старые модули были уничтожены до запуска новых модулей, но это приведет к простою приложения при развертывании, что не очень хорошо.
Ответ №1:
Некоторые части конфигурации Hazelcast не могут быть настроены во время выполнения, что означает, что вы не сможете выполнить переходящее обновление. Другими словами, вы не сможете создать кластер с участниками, работающими с разными конфигурациями одновременно.
Если данные для вас не важны, вы всегда можете использовать развертывание синего/зеленого цвета, что означает, что вы сначала запускаете весь новый кластер (с новой конфигурацией), переключаетесь на новый кластер, а затем останавливаете старый кластер.
Комментарии:
1. Спасибо вам за ответ. Есть ли хороший способ сделать это с помощью метода обнаружения безголовых служб в hazelcast-kubernetes? Любая служба, созданная для развертывания, по-видимому, соответствует одному и тому же DNS, по крайней мере в нашей среде, что заставляет участников кластера находить друг друга независимо от того, на какую службу я указываю кластер hazelcast.
2. Нет, я думаю, вам нужно «организовать» это самостоятельно. Это означает, что вы используете два разных имени службы, а затем переключаете свое приложение с одного на другое.
3. Не могли бы вы, случайно, знать, где я могу найти описание того, какие именно части конфигурации могут быть несовместимы? Я видел предупреждение о несовместимости в разделах «Соединители» и «сериализаторы», но, похоже, я не могу найти страницу в руководстве, на которой перечислены части конфигурации, которые должны быть идентичными.
4. Конечно, вы можете добавлять новые структуры данных. Проверьте эту ссылку: docs.hazelcast.com/imdg/4.1.2/configuration/…