Мы используем TCP Google Cloud Loadbalancer для одного из наших сервисов.
Архитектура выглядит следующим образом: имеется балансировщик нагрузки TCP, на котором разрешен диапазон портов на внешнем интерфейсе, а его экземпляры внутреннего интерфейса подключены, и службы этих экземпляров работают на том же порту, который открыт на LB.
Например: LB IP -1.1.1.1:(100-200)т.е. диапазон портов открыт. Сейчас на бэкенде запущено 3 экземпляра и на них запущены службы на портах 100, 101 и 103.
Как пользователь, если вы хотите получить доступ к службе, работающей на порту 100, вам нужно использовать LB IP:100 для доступа к службам. Но с последних нескольких дней запрос отбрасывается. Однако, если вы попытаетесь подключиться напрямую к службе экземпляра IP:100, она будет работать нормально. Поэтому я не могу выяснить точную причину. Запросы также основаны на TCP, тогда почему LB отбрасывает их.
Пожалуйста, предложите мне некоторые входные данные. Примечание: есть ли способ проверить логи LB из GCloud или Console ???
решение1
Публикую собственный ответ OP для лучшей видимости:
Моя проблема не была связана с LB.
Мой LB использует алгоритм round robin, он просто передавал запрос, не проверяя статус сервера back-end. Только один из моих серверов был запущен, поэтому половина запросов отбрасывалась.
Я только что настроил еще один экземпляр в том же LB, и проблема была решена.
Такое решение является наиболее "грубым" и не обеспечивает никакой отказоустойчивости. Если какой-либо сервер выйдет из строя, некоторые запросы будут потеряны, и сервис будет понижен.
Самым простым решением, чтобы избежать этого, было бы создатьуправляемая группа экземплярови использоватьпроверки здоровьячтобы проверить, все ли виртуальные машины запущены, а затем создатьБалансировщик нагрузки.