это именно в ovsdb проблема или в pacemaker?
Vladislav
icewolf
РТ МО 4 жилы...
У родственников до сих пор в Финляндии 4 жилы, или 8 не совсем понятно там какой то shdsl модем, коробка в которую приходит толи оптика толи что еще стоит на улице и от нее медью уже в дом. Прикол в том что больше 25мбит коробка не выдает, но платят якобы за 100. И платят не мало
Vladislav
icewolf
Это что за ovs и ovn тогда был?
это у ovn было, при работе с ovsdb 2.9 что ли. Стабилизировали работу только в 3.2
icewolf
при этом логика то понятная, а пот почему так криво работало, тишина.
Vladislav
это у ovn было, при работе с ovsdb 2.9 что ли. Стабилизировали работу только в 3.2
Что-то очень сомнительно. Мы с 2.13 в продакшене его используем. Ничего особенного кроме оптимизаций алгоритмов, имплементации каких-то кусков ovsdb там не припомню. Самое заметное - ovsdb-relay.
Возможно, речь не про баг, а про особенности реализации. ovsdb-server до 3.3 был однопоточным. Соответственно, если он занимается обработкой какой-то серьезной транзакции и еще имеет кучу подключенных клиентов (с внушительной базой), то пока он в блокирующем режиме процессит транзакцию и рассылкает всем клиентам в idl апдейты, могут внезапно протикать:
- election timer (raft heartbeat)
- ovsdb interval
Первое чревато перевыборами лидера и кучей переподключений (если клиентов много)
Второе - просто отключениями. Этот эффект может иметь лавинообразный характер. (Пока тратим ресурсы на обработку подключающихся клиентов, старые продалбывают хартбиты).
Эту проблему предлагается адресовать внедрением релеев. От самого кластера клиентов ограждаем таким «щитом», держащим read-нагрузку.
icewolf
вот еще багульки
https://bugs.launchpad.net/neutron/+bug/1969592
icewolf
Что-то очень сомнительно. Мы с 2.13 в продакшене его используем. Ничего особенного кроме оптимизаций алгоритмов, имплементации каких-то кусков ovsdb там не припомню. Самое заметное - ovsdb-relay.
Возможно, речь не про баг, а про особенности реализации. ovsdb-server до 3.3 был однопоточным. Соответственно, если он занимается обработкой какой-то серьезной транзакции и еще имеет кучу подключенных клиентов (с внушительной базой), то пока он в блокирующем режиме процессит транзакцию и рассылкает всем клиентам в idl апдейты, могут внезапно протикать:
- election timer (raft heartbeat)
- ovsdb interval
Первое чревато перевыборами лидера и кучей переподключений (если клиентов много)
Второе - просто отключениями. Этот эффект может иметь лавинообразный характер. (Пока тратим ресурсы на обработку подключающихся клиентов, старые продалбывают хартбиты).
Эту проблему предлагается адресовать внедрением релеев. От самого кластера клиентов ограждаем таким «щитом», держащим read-нагрузку.
именно про эту особенность я и сказал, что проблема не peacemaker и даже не в ovsdb и ovs как таковым, проблема в коде и реализации.
icewolf
и балансировать релеями надо было ну ребят лет так 7 назад.
Vladislav
и балансировать релеями надо было ну ребят лет так 7 назад.
Не было у рх таких клиентов значит
Vladislav
Появился - сделали
Artemy
остальные конкуренты оптику давно ведут уже...
Оптику до раутера в квартире? Фу, костыльно и неудобно.
icewolf
Оптику до раутера в квартире? Фу, костыльно и неудобно.
убобно! Я так левыми трансиверами пару раз спалил оборудование оператору
Grundik
Оптику до раутера в квартире? Фу, костыльно и неудобно.
норм... да сломать оптику можно неловким движением или перестановкой fc конвертора
Vladislav
очень рад что вы меня сразу поняли.
Релеи, к слову, появились в 2.16, а прям годный стал в 3.0 (с поддержкой last transaction id) — это чтобы при переключении клиента между релеями новый релей не всю базу ему скидывал, а только то, что изменилось за время переключения клиента
icewolf
Релеи, к слову, появились в 2.16, а прям годный стал в 3.0 (с поддержкой last transaction id) — это чтобы при переключении клиента между релеями новый релей не всю базу ему скидывал, а только то, что изменилось за время переключения клиента
там вроде было last commit id если я не путаю, transaction id это как раз складывание в базу.
icewolf
ну опять таки врать не буду, давно было(ну как давно? месяца три назад)
Vladislav
там вроде было last commit id если я не путаю, transaction id это как раз складывание в базу.
https://github.com/openvswitch/ovs/blob/4ba65112dc091568728d36c8226aa1568f158ca8/NEWS#L244
icewolf
* New unixctl command 'ovsdb-server/tlog-set DB:TABLE on|off".
If turned on, ovsdb-server will log (at level INFO and rate limited)
all operations that are committed to table TABLE in the DB database.
* New Local_Config schema added to support Connections (--remote)
configuration in a clustered databse independently for each server.
E.g. for listening on unique addresses. See the ovsdb.local-config.5
manpage for schema details.
Vladislav
* New unixctl command 'ovsdb-server/tlog-set DB:TABLE on|off".
If turned on, ovsdb-server will log (at level INFO and rate limited)
all operations that are committed to table TABLE in the DB database.
* New Local_Config schema added to support Connections (--remote)
configuration in a clustered databse independently for each server.
E.g. for listening on unique addresses. See the ovsdb.local-config.5
manpage for schema details.
Самое первое:
* 'relay' service model now supports transaction history, i.e. honors the
'last-txn-id' field in 'monitor_cond_since' requests from clients.
icewolf
Самое первое:
* 'relay' service model now supports transaction history, i.e. honors the
'last-txn-id' field in 'monitor_cond_since' requests from clients.
угу, ток оно в 2.16 херовато работало, точнее оно работало но с плясками и танцами
Vladislav
угу, ток оно в 2.16 херовато работало, точнее оно работало но с плясками и танцами
В 2.16 этого не было.
icewolf
А сорри v2.17.0 - 17 Feb 2022
Vladislav
v3.0.0 - 15 Aug 2022
icewolf
короче я вспомнил, поле monitor_cond было но не несло по сути никакой нагрузки когда в вышла v 3.0 логика поменялась и теперь релей начал работать уже с transaction
icewolf
А вот в 3.2 уже появилась возможность wait commit делать
icewolf
но это не точно я настолько глубоко прям до того когда relay завезли не копал.
Artemy
норм... да сломать оптику можно неловким движением или перестановкой fc конвертора
А я например хочу завести интернет на малинку а не на провайдерский раутер. И что мне с энтой оптикой делать, ставить рядом медиаконвертер? Ну и вообще имхо оптика до конечного оборудования это GPON который скорее говно чем нет
icewolf
да и автор тута
Nikolay
говорят они решили к нормальным конфиг файлам прийти
icewolf
Nikolay
это че мне теперь dslam пойти выбросить
icewolf
это че мне теперь dslam пойти выбросить
ну давай еще модемами будем пользоваться по dial апу до ближайшего POP
icewolf
уже Wi-Fi 6 настал с wpa3 и прочие зарубежные технологии мешающие нам скатится в средневековье, так нет же откопали. В GePОN тоже есть некоторые моменты которые улучают жизнь классических FTTH, но сам принцип оптику в твой PC это не останавливает
icewolf
а вот GPON с точки зрения фиксы это тупо дешевле.
icewolf
и жаловаться что 4 провода от Ростелеком, ну да можно. У Билайн местами pptp работает, в том же Питере у меня роутер от Ростелеком еще по pppoe херачит.. и это по оптике
icewolf
Ну здравствуйте, грибочки у нас уже были а вот inferitcloud нет
Aleksandr
Теперь и вопрос боюсь задать)))
icewolf
на самом деле все свои ребята из interfitcloud точно свои из софтлайна. Свое облако опенстек
icewolf
и как я понимаю не только опенстек
icewolf
я думал девопсы
Одно другому не мешает, тем более если изучить весь трэш с трансформерами то автоботы являются единственными источниками древних знаний.
Aleksandr
Добрый день. Подскажите пожалуйста.
Столкнулся с проблемой, что в OS -> VPN.
При создании Группы конечных точек.(группы узлов), где указывается более 1 CIDR(192.168.0.0/24, 192.168.1.0/24)
Перестаёт подниматься VPN.
Как только вернуть соотношение 1:1. VPN поднимается.
Версия OS - kolla ansible zed 15.2.0
icewolf
ovn?
icewolf
в логах что нить есть?
icewolf
Тебе надо бы логи самого libreswan глянуть.
На практике данный баг очень давно существует, лечится широкой маской.
J
На практике данный баг очень давно существует, лечится широкой маской.
Ну скинь ссылку то, чтоб почитать.
Или это опять какая-то фигня связанная с протухшим сто лет назад либресваном?)
icewolf
Ну скинь ссылку то, чтоб почитать.
Или это опять какая-то фигня связанная с протухшим сто лет назад либресваном?)
https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall
icewolf
The validation logic makes sure that endpoint groups and peer CIDRs are not intermixed.
Endpoint group types are subnet, cidr, network, router, and vlan. However, only subnet and cidr are implemented (for IPSec use).
The endpoints in a group must be of the same type, although can mix IP versions.
For IPSec connections, validation currently enforces that the local and peer endpoints all use the same IP version.
icewolf
CIDRs are not intermixed
icewolf
не ну можно strongswan, но легче от этого не станет, сама логика тут в том что на уже созданном ipsec, нельзя подкинуть сеть, а вот во время создания можно указать
J
CIDRs are not intermixed
Ты по-своему как-то истолковал.
Это значит что внутри эндпоинт группы нельзя мешать разные типы эндпоинтов. Все должны быть либо типа cidr либо типа subnet.
То есть, внутри одной эндпоинт группы валидация тебе не даст указать и uuid подсети какой-то и cidr. Либо набор подсетей существующих в нейтроне, которые должны войти в группу либо набор cidr.
J
https://docs.openstack.org/python-neutronclient/zed/cli/osc/v2/vpn-endpoint-group.html
J
https://docs.openstack.org/neutron/zed/admin/vpnaas-scenario.html
icewolf
https://docs.openstack.org/neutron/zed/admin/vpnaas-scenario.html
openstack vpn endpoint group create ep_cidr \
--type cidr \
--value 192.168.1.0/24
так вот тут value логическое и если мы укажем 192.168.0.0/24 то эту сеть vpn не сожрет(!). А вот если 10.10.10.0/24 то сожрет
icewolf
Не понял тебя.
ребята из libreswan просто так наверное в wiki указали вот так
neutron vpn-endpoint-group-create --name my-peers --type cidr --value 10.2.0.0/24 --value 20.2.0.0/24
icewolf
и тип у нас тоже логическое значение cidr
Aleksandr
Сделал ещё тест с микротиком, если 1 CIDR указан, то всё работает. Если указать - 2, то со стороны OS не работает. А вот со стороны микротика коннект есть)
Со стороны лог, увидел только дубликат.
J
value это логическое значение, правильно?
Нет. value ожидает что ты после него укажешь либо uuid сети либо cidr. Это строка. И опция value может повторяться.
Ты чот часто пытаешься не в проблему смотреть, а в чертоги разума и вытаскиваешь оттуда случаи из своей практики, которые на вид похожи)
Что ты пытаешься донести?
icewolf
Нет. value ожидает что ты после него укажешь либо uuid сети либо cidr. Это строка. И опция value может повторяться.
Ты чот часто пытаешься не в проблему смотреть, а в чертоги разума и вытаскиваешь оттуда случаи из своей практики, которые на вид похожи)
Что ты пытаешься донести?
value по идеи это строка, ну что бы было понятно, у тебя может быть и 2 value с типом cidr
J
value по идеи это строка, ну что бы было понятно, у тебя может быть и 2 value с типом cidr
Мне то понятно)
Все value должны быть одного типа, всё так. Ну и что дальше, к чему подводишь?)
Aleksandr
Я понимаю, что можно маску расширить. но именно интересует 2 CIDR.
если сети например 10.10.0.0/16 и 172.31.20.0/24
Aleksandr
value укажите 192.168.0.0/23 и посмотрите
С расширенной маской работать будет, это проверено.