Web-интерфейс становится пустым при выпадении одного инстанса из кластера

При выпадении любого инстанса из кластера, в веб-интерфейсе перестает отображаться состояние всех инстансов

admin=> select * from _pico_instance ;
 instance_id  |            instance_uuid             | raft_id | replicaset_id |           replicaset_uuid            | current_state | target_state  |             failure_domain              |  tier   
--------------+--------------------------------------+---------+---------------+--------------------------------------+---------------+---------------+-----------------------------------------+---------
 default-1000 | 2f2478ec-132b-32b4-9c5b-f9a202c6283d |       1 | r1            | e0df68c5-e7f9-395f-86b3-30ad9e1b7b07 | ["Online",18] | ["Online",18] | {"HOST":"192.168.101.166","DC":"[DC1]"} | default
 default-1001 | a70fb1e8-1bb7-30e1-8ffe-b251b0d8cb0c |       4 | r2            | eff4449e-feb2-3d73-87bc-75807cb23191 | ["Online",6]  | ["Online",6]  | {"HOST":"192.168.101.166","DC":"[DC1]"} | default
 default-2000 | 763e15c3-bc72-3b86-aec1-c384ca47f5c1 |       3 | r1            | e0df68c5-e7f9-395f-86b3-30ad9e1b7b07 | ["Online",15] | ["Online",15] | {"HOST":"192.168.101.167","DC":"[DC2]"} | default
 default-2001 | 24d92557-b366-3e58-800e-712a99b05371 |       5 | r2            | eff4449e-feb2-3d73-87bc-75807cb23191 | ["Online",5]  | ["Online",5]  | {"HOST":"192.168.101.167","DC":"[DC2]"} | default
 default-3000 | 41fd77d1-7990-346d-b521-3fc43493905c |       2 | r1            | e0df68c5-e7f9-395f-86b3-30ad9e1b7b07 | ["Online",17] | ["Online",17] | {"HOST":"192.168.101.168","DC":"[DC3]"} | default
 default-3001 | 709071e5-0f99-3c3c-ac4e-fc868f48a048 |       6 | r2            | eff4449e-feb2-3d73-87bc-75807cb23191 | ["Offline",5] | ["Offline",5] | {"HOST":"192.168.101.168","DC":"[DC3]"} | default
(6 строк)

added 1 deleted label

added bug label

https://git.picodata.io/picodata/picodata/picodata/-/blob/cdd93da681322df626c9a75b68ab1faa6c838a40/src/http_server.rs#L247-248

мы отправляем запрос на все инстансы, даже те у которых стейт Offline и Expelled. И потом ждём ответа от всех целых 60 секунд. То есть если один инстанс не отвечает, мы не узнаем ничего ни про один инстанс

Как вариант, можно понизить таймаут секунд до 5.

Хотя правильным решением на мой взгляд было бы сделать webui более динамическим. Для начала можно разбить api/v1/cluster на 2, один эндпоинт возвращает только инфу о инстансах/репликасета/тирах, которая доступна в глобальных таблицах. Для этого не надо ходить на все инстансы, и поэтому оно будет работать почти всегда.

А следующим шагом можно уже запрашивать runtime_info с количеством памяти и т.п. Это можно было тоже разбить на по одному запросу на инстанс или хотя бы на репликасет, но это уже задача на будущее.

В карже была такая же проблема https://github.com/tarantool/cartridge/issues/1274. Там мы укоротили таймаут до 1сек и это всех устроило. Но глобально использование map_call в webui так и остался нерешенной проблемой. Помимо потенциальных задержек он еще пару раз в ulimit по fd упирался на больших кластерах.

Я поддерживаю идею с разделением апи. По крайней мере базовые запросы точно не должны map reduce делать. Если какой-то информации не хватает в _pico_instance то это повод ее туда добавить.

Проблему с fd мы уже решили, Web api делает rpc через коннекшен пул.

Rpc там к слову делается, чтобы посмотреть количество используемой памяти процесса, ты же не предлагаешь эту информацию в _pico_instance хранить?

Нет. Я имел в виду http_address и version

mentioned in commit ef0c9181

Решение "в лоб" с понижением таймаута не сработало.

Как воспроизвести на мастере:

Билдимся

make build

Поднимаем кластер из двух нод:

rm -rf i1 i2
mkdir i1 i2
./target/debug/picodata run -l 127.0.0.1:3301 --instance-id i1 --advertise 127.0.0.1:3301 --peer 127.0.0.1:3301 --http-listen localhost:8081 --data-dir i1
./target/debug/picodata run -l 127.0.0.1:3302 --instance-id i2 --advertise 127.0.0.1:3302 --peer 127.0.0.1:3301 --http-listen localhost:8082 --data-dir i2

Проверяем через curl, что запрос работает:

curl http://localhost:8081/api/v1/cluster

При помощи iptables дропаем все пакеты на бинарный порт второго узла пикодаты

sudo iptables -A INPUT -p tcp --destination-port 3302 -j DROP

Проверяем через curl, что запрос висит при любом значении таймаута и не видим в логах сообщений об упавших по таймауту футурах

curl http://localhost:8081/api/v1/cluster

Дропаем правило iptables

sudo iptables -D INPUT -p tcp --destination-port 3302 -j DROP

проблема в том, что в ConnectionPool не передаётся таймаут при установке tcp соединения. Вот тикет #991

Как временный воркэраунд можно добавить .timeout(DEFAULT_TIMEOUT) напрямую к фьюче, которую возвращает pool.call_raw(). Она не будет уязвима к блокировке ConnectionPool, т.к. этот await будет в рамках другого block_on и расчёт таймаутов будет корректным.

Важно ещё не забыть сделать use tarantool::fiber::r#async::timeout::IntoTimeout;

mentioned in issue #991

changed milestone to %24.6 - Plugins and Tiers

@d.rodionov это блокер для 24.6 к сожалению

added 1 deleted label

assigned to @UngiftedPoet

marked this issue as related to #991

assigned to @vifley and unassigned @UngiftedPoet

mentioned in commit b5da6736

mentioned in commit c450eaf4

mentioned in merge request !1336 (merged)

mentioned in commit 53a71ddc

mentioned in commit 8de53aef

Resolved by #1336

closed

mentioned in commit 4762ad20