GlobalScheduler: частые проблемы

GlobalScheduler: частые проблемы#

algid parse error, not a sequence#

При запуске globalscheduler в логах может возникнуть ошибка следующего вида:

Job Default.22 threw a JobExecutionException: org.quartz.JobExecutionException: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: IOException : algid parse error, not a sequence

Чаще всего данная проблема связана с некорректным форматом приватного ключа. Для работы с Globalscheduler требуется 2048-битный ключ RSA формата PKCS#8. Ключи формата PKCS#1 не подходят для работы c Globalscheduler.

Чтобы убедиться, что ваш ключ верного формата, проверьте, что сгенерированный вами неотформатированный приватный ключ (quartz.privatekey.txt/quartz.private.pem) начинается со следующей строки:

-----BEGIN PRIVATE KEY-----

В случае, если ваш ключ неверного формата (PKCS#1), он будет начинаться со следующей строки:

-----BEGIN RSA PRIVATE KEY-----

Также проверить формат ключа можно при помощи openssl, что может быть полезно, если ключ доступен только в отформатированном для Globalscheduler виде (quartz.private.txt/quarz.private.pem), и не содержит заголовков.

Для этого используйте следующую команду, заменив значение <key_path> на путь до приватного ключа:

base64 -d <key_path> | openssl asn1parse -inform DER | grep -q rsaEncryption && echo "Ключ верного формата" || echo "Ключ неподходящего формата"

Чтобы сгенерировать ключ подходящего формата, воспользуйтесь генерацией пары ключей в системе Global, или следующей командой:

openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

Illegal base64 character#

В случае возникновения ошибки «Illegal base64 character» убедитесь, что ключи верно отформатированы. Ключи, используемые Globalscheduler, не должны содержать заголовков (—–BEGIN PUBLIC KEY—–, —–END PUBLIC KEY—– и пр.) и знаков переноса строки.

Если вы используете kubernetes, убедитесь, что файл ~/globalserver/workspace/mnt/secret/scheduler/private.key внутри контейнера Globalscheduler содержит приватный ключ в читаемом формате (должен начинаться с букв MIIE).

Плавающие ошибки Connection Refused (Kubernetes)#

Если ошибка Connection Refused возникает непостоянно - появляется и исчезает без видимых причин - её нужно локализовать пошагово, исключая промежуточные компоненты один за другим.

Шаг 1. Подключение напрямую к exclusive-поду, в обход прокси#

Первым делом уберите из цепочки все прокси и подключите GlobalScheduler напрямую к exclusive-порту GlobalServer.

В настройках btk (Планировщик заданий) задайте:

  • HTTPS: выключить;

  • Soap хост: gs-cluster-1-global-server-excl-external (или ваше название сервиса);

  • Soap порт: 8088.

После изменения настроек сбросьте кеши (или перезапустите поды шедулера и серверов приложений), выполните тестовые задания и проверьте логи scheduler в Grafana.

Если ошибка не воспроизводится - переходите к шагу 2. Если воспроизводится - проблема находится внутри самого пода или конфигурации планировщика.

Шаг 2. Подключение через внутренний HAProxy#

Следующая ступень - подключение через внутренний HAProxy кластера.

В тех же настройках btk задайте:

  • HTTPS: включить (если используется и заранее настроены cacerts);

  • Soap хост: gs-cluster-1-haproxy-external (или ваше название сервиса);

  • Soap порт: 443.

Аналогично сбросьте кеши или перезапустите поды, выполните задания и посмотрите логи в Grafana.

Если ошибка не воспроизводится и здесь - инфраструктура кластера со своей стороны работает корректно.

Шаг 3. Проверка внешней инфраструктуры#

Если оба шага выше прошли без ошибок, проблема находится за пределами зоны ответственности кластера Global. Проверьте:

  • настройки Ingress и reverse proxy;

  • значения таймаутов на всех уровнях;

  • конфигурацию сетевых политик;

  • антивирусное ПО и межсетевые экраны, которые могут разрывать долгоживущие соединения.

Error 401 JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted#

Данная ошибка связана с тем, что установленный публичный ключ не подходит к установленному приватному ключу. Убедитесь, что установленные в Globalscheduler ключи из одной пары (в Kubernetes можно удалить под шедулера - при запуске нового в лог контейнера будет выведена информация о соответствии ключей), либо сгенерируйте новую пару ключей (Генерация ключей шифрования)

Содержание