Регистрация Войти
Рейтинг:1
avatar Server

балансировщик нагрузки помечает «неработоспособным» новый экземпляр члена группы (ubuntu) после dist-upgrade

флаг tl
Ivan Buttinoni

У меня есть несколько виртуальных машин (работающих как веб-сервер) за группа экземпляров на моем GCloud.

Как обычно техобслуживание обновил(apt dist-upgrade) мой "vm-source-image", создал новый шаблон и добавить в мою группу.

Новые участники, использующие этот шаблон, никогда не получают реальных рабочих запросов от балансировщика нагрузки и он запущен и работает но безработные.

Временный патч

Я делаю только частичное обновление (т. безопасности) к:

sudo автоматическое обновление -d

Вот список оставшихся пакетов, которые создают проблему:

# подходящий список --upgradable

cloud-init/bionic-updates 21.3-1-g6803368d-0ubuntu1~18.04.4 все [можно обновить с: 21.2-3-g899bfaa9-0ubuntu2~18.04.1]
dnsmasq-base/bionic-updates 2.79-1ubuntu0.5 amd64 [можно обновить с: 2.79-1ubuntu0.4]
gce-compute-image-packages/bionic-updates 20210629.00-0ubuntu1~18.04.0 все [можно обновить с: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine/bionic-updates 20210629.00-0ubuntu1~18.04.0 все [можно обновить с: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine-oslogin/bionic-updates 20210728.00-0ubuntu1~18.04.0 amd64 [можно обновить с: 20210429.00-0ubuntu1~18.04.0]
google-guest-agent/bionic-updates 20210629.00-0ubuntu1~18.04.1 amd64 [можно обновить с: 20210414.00-0ubuntu1~18.04.0]
libgnutls30/bionic-updates 3.5.18-1ubuntu1.5 amd64 [можно обновить с: 3.5.18-1ubuntu1.4]
libnetplan0/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [можно обновить с: 0.99-0ubuntu3~18.04.4]
libpcre2-8-0/bionic 10.39-1+ubuntu18.04.1+deb.sury.org+1 amd64 [можно обновить с: 10.36-2+ubuntu18.04.1+deb.sury.org+2]
netplan.io/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [можно обновить с: 0.99-0ubuntu3~18.04.4]
nplan/bionic-updates 0.99-0ubuntu3~18.04.5 все [можно обновить с: 0.99-0ubuntu3~18.04.4]
snapd/bionic-updates 2.51.1+18.04 amd64 [можно обновить с: 2.49.2+18.04]
ubuntu-advantage-tools/bionic-updates 27.3~18.04.1 amd64 [можно обновить с: 27.2.2~18.04.1]

РЕАЛЬНОЕ РЕШЕНИЕ

Поскольку у меня нет «настраиваемого» пакета на машине, а причина этой проблемы связана с обновлением системы, я не вижу решения, кроме как указать на проблему в этом посте.

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

Больше информации

  • Группа является серверной частью «внутреннего балансировщика нагрузки TCP».
  • Внешний IP-адрес балансировщика нагрузки: 10.0.0.116
  • Старый (и рабочий) IP-адрес участника: 10.0.0.48 (видны логи)
  • IP-адрес нового (и неработающего) участника: 10.0.0.54 (видны логи)
  • Балансировщик нагрузки имеет простую проверку работоспособности HTTP, известную как HTTPHC1.
  • Группа экземпляров имеет еще одну простую проверку работоспособности HTTP, известную как HTTPHC2.

Сравнение журнала доступа старого (и рабочего) участника с новым:

Журнал старого члена ВМ

35.191.1.148 "/" - - - [04/ноября/2021:10:34:59 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.144 "/" ​​- - - [04/ноября/2021:10:35:00 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.154 "/" ​​- - - [04/ноября/2021:10:35:00 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.147 "/" - - - [04/ноября/2021:10:35:01 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.145 "/" - - - [04/ноября/2021:10:35:01 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.151 "/" - - - [04/ноября/2021:10:35:02 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.153 "/" - - - [04/ноября/2021:10:35:02 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"

Журнал нового члена ВМ

35.191.1.152 "/" - - - [04/ноября/2021:10:31:01 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.154 "/" ​​- - - [04/ноября/2021:10:31:02 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.148 "/" - - - [04/ноября/2021:10:31:02 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"

Разница показывает отсутствие журналов HTTPHC1.

Таким образом, новый новый не отвечает на проверку работоспособности балансировщика нагрузки (HTTPHC1) и не получает запросы, и в этом проблема.

Другие неисправности Новая машина также недоступна через браузер-окно-SSH. введите описание изображения здесь

ДОБАВИТЬ tcpdump

Между HTTPHC1 санитарный врач и безработный член:

# tcpdump -n хост 35.191.1.151
tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
прослушивание на ens4, тип линка EN10MB (Ethernet), размер захвата 262144 байт
11:30:35.109469 IP 35.191.1.151.61838 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:36.119470 IP 35.191.1.151.61838 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:38.167436 IP 35.191.1.151.61838 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:40.110784 IP 35.191.1.151.59900 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:41.111176 IP 35.191.1.151.59900 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:43.159164 IP 35.191.1.151.59900 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
11:30:45.112162 IP 35.191.1.151.36064 > 10.0.0.116.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0

Обратите внимание, что пункт назначения — внешний IP-адрес балансировщика нагрузки: 10.0.0.116 и, конечно же, это только пакеты синхронизации.

Между HTTPHC2 санитарный врач и безработный член:

# tcpdump -n хост 35.191.1.148
tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
прослушивание на ens4, тип линка EN10MB (Ethernet), размер захвата 262144 байт
10:46:12.475724 IP 35.191.1.148.64638 > 10.0.0.54.80: Флаги [S], win 65535, параметры [mss 1420,sackOK,TS ecr 0,nop,wscale 8], длина 0
10:46:12.475788 IP 10.0.0.54.80 > 35.191.1.148.64638: флаги [S.], win 64768, параметры [mss 1420,sackOK,TS,nop,wscale 7], длина 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: Флаги [.], ack 1, win 256, опции [nop,nop,TS], длина 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: Флаги [P.], seq 1:117, ack 1, win 256, опции [nop,nop,TS], длина 116: HTTP: GET /?id=HTTPHC2 HTTP/1.1
10:46:12.476301 IP 10.0.0.54.80 > 35.191.1.148.64638: Флаги [.], ack 117, win 506, опции [nop,nop,TS], длина 0
10:46:12.476546 IP 10.0.0.54.80 > 35.191.1.148.64638: Флаги [P.], seq 1:867, ack 117, win 506, параметры [nop,nop,TS], длина 866: HTTP: HTTP /1.1 200 ОК
10:46:12.476659 IP 35.191.1.148.64638 > 10.0.0.54.80: Флаги [.], ack 867, win 267, опции [nop,nop,TS], длина 0
10:46:12.476679 IP 35.191.1.148.64638 > 10.0.0.54.80: флаги [F.], seq 117, ack 867, win 267, опции [nop,nop,TS], длина 0
10:46:12.476707 IP 10.0.0.54.80 > 35.191.1.148.64638: флаги [F.], seq 867, ack 118, win 506, параметры [nop,nop,TS], длина 0
10:46:12.476879 IP 35.191.1.148.64638 > 10.0.0.54.80: Флаги [.], ack 868, win 267, опции [nop,nop,TS], длина 0

Здесь все в порядке.

ДОБАВИТЬ 2021-11-16

После некоторых исследований я обнаружил отсутствующий псевдоним IP в местный таблице, неудивительно, что это IP-адрес внешнего балансировщика нагрузки, видимый как хост DST в tcpdump!

Вот рабочая машина:

# ip route show dev ens4 table local
локальный 10.0.0.48 прото-область ядра host src 10.0.0.48 
локальный хост области 10.0.0.116 proto 66 
# uname -r
5.4.0-1056-gcp

А вот и полностью обновленная машина:

# ip route show dev ens4 table local
локальный 10.0.0.54 прото-область ядра host src 10.0.0.54
# uname -r
5.4.0-1057-гкп

ДОБАВИТЬ 20.11.2021

Теперь это стало известной проблемой: [Облачная сеть] Возможная проблема с сервисом: расследование

Балансировщики нагрузки Google Cloud Global TCP Proxy могут не работать трафик через правила переадресации, настроенные с IP-адресами в 34.111.0.0/17 спектр. Постоянное исправление для диапазона IP-адресов находится в процессе

178
0 + 0
Wojtek_B avatar
флаг jp
Wojtek_B
Доступны ли новые ВМ из других ВМ в том же VPC? Как вы вошли в свою новую виртуальную машину?
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B виртуальная машина хорошо доступна через его IP (10.0.0.54). это LB (IMO интерфейсный компонент), который не знает реального IP-адреса машины.
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
У меня есть подозрение, что виновником здесь является [Netplan](https://netplan.io/), с которым я не знаком, но поскольку это функция сетевой утилиты, и после обновления вы потеряли внешний IP-адрес виртуальной машины и один из проверка здоровья не проходит. Проверьте ваши файлы `/etc/netplan/*.yaml` до и после обновления - они изменены?
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Вы всегда можете попробовать создать другую проверку работоспособности, которая будет работать, и изменить ее в настройках балансировщика нагрузки.
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B, если цель найти виновный пакет, да, проверка `/etc/netplan/*.yaml` может быть решением, но моя цель - решить проблему, сохранив возможность чистого подхода, например: создать новую машину с ubuntu-20 (должно быть лучше, если ubuntu-22) или удалите бесполезный пакет XYZK, который является реальным источником проблемы.
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B Я не думаю, что возможно обойти отсутствие знаний об «IP-адресе члена группы» внутри балансировщика с какой-либо реальной проверкой работоспособности. :(
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Можете ли вы попробовать выполнить обновление, но оставить старые версии пакетов `libnetplan0`, `netplan.io` и `nplan`?
0
Ответить
флаг tl
Ivan Buttinoni
Привет, @Wojtek_B, я обновил систему, кроме пакетов `*netplan*`, к сожалению, у меня проблема, они не "нарушители спокойствия"
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Может просто попробовать установить их по одному и проверить не "ломает" ли это конфигурацию. Это кажется довольно быстрым решением, так как их всего несколько.
0
Ответить
флаг tl
Ivan Buttinoni
Не так быстро, это подразумевает полный процесс развертывания: включение->обновление->выключение->образ->диск->шаблон->развертывание + или - 15/20 минут пакет. Ладно, не строить Рим, но не так быстро
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Вы всегда можете попробовать установить первую половину, и если после рестарта все работает, вы уже знаете, что вам нужно искать виновника во второй половине. Разделите его еще раз на две части и повторите процесс.
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B всегда хороший подход к b-дереву: D Попробую завтра
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B что вы думаете о моем последнем *добавлении*?
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Хорошо поработали — вы добавили маршрут? `ip route добавить к локальному IP_HERE dev ens4 proto 66`
0
Ответить
флаг tl
Ivan Buttinoni
@Wojtek_B Я только что прочитал ответ EthanWang, и теперь я предпочитаю знать ответ на его вопрос: «почему google-guest-agent не запускается автоматически» ;)
0
Ответить
Wojtek_B avatar
флаг jp
Wojtek_B
Это похоже на проблему с агентом ведения журнала, и было бы лучше сообщить об этом на [Google IssueTracker](issuetracker.google.com). Я попытался воспроизвести его с помощью простого экземпляра Ubuntu 16.04 и без проблем выполнил обновление sudo apt.
0
Ответить
Рейтинг:3
Ethan Wang avatar Server
флаг gb
Ethan Wang

После тестирования, облачная инициализация является первопричиной.

Согласно этому комментарий, disable_network_activation: правда должны быть установлены, чтобы избежать конфликта с Google-гостевой агент оказание услуг.

Решение добавляет настройку в облачная инициализация конфиг.

кошка > /etc/cloud/cloud.cfg.d/99-disable-network-activation.cfg <<EOF
# Отключите сетевую активацию, чтобы предотвратить создание сети с помощью cloud-init.
# изменения, конфликтующие с \`google-guest-agent\`.
# См.: https://github.com/canonical/cloud-init/pull/1048.

disable_network_activation: правда
EOF

Этот файл есть в официальном образе Ubuntu-1804-бионик-v20211103.

После добавления этого файла Google-гостевой агент работает нормально.

0 + 0
флаг tl
Ivan Buttinoni
Я думаю, вы отлично справились, нашли решение и создали путь bash (работает как шарм). Отличная работа!
0
Ответить
Рейтинг:0
avatar Server
флаг cn
Ethan Wang

У меня есть машина под управлением Ubuntu 18.04.5, после запуска возникла та же проблема. apt dist-upgrade, также обновить гугл-гостевой агент 20210629.00-0ubuntu1~18.04.1 (обновляется с: 20210414.00-0убунту1~18.04.0).

Обнаружение этого Google-гостевой агент не запускается после обновления. Когда я выполняю /usr/bin/google_guest_agent вручную проблема решена.

До сих пор не знаю, почему Google-гостевой агент не запускается автоматически.

0 + 0
флаг tl
Ivan Buttinoni
Спасибо, @Ethan, я передам вашу информацию в службу поддержки Google и буду держать вас в курсе.
0
Ответить
флаг tl
Ivan Buttinoni
Интересно, почему эта проблема не повсеместна? Может быть потому, что это происходит только в «настроенной» системе, поэтому, например, я отключил «apt-daily.service». То же самое для вас?
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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