@openstack_ru - страница 1167

Михаил

А ресурсов на инстансах хватает, чтобы 10г прогнать ?

Включена тема с vCPU обработкой виртуальных адаптеров

Михаил

ну ещё бы, оно тогда дальше овн (овс) не уходит

Ну вот там как раз разница была в этом между OVN и OVS

Михаил

При этом если инстансы на одной ноде - имеем странную херню: root@testvm2:~# iperf3 -c testvm --bidir Connecting to host testvm, port 5201 [ 5] local 192.168.120.90 port 56262 connected to 192.168.120.3 port 5201 [ 7] local 192.168.120.90 port 56270 connected to 192.168.120.3 port 5201 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][TX-C] 0.00-1.00 sec 1.24 GBytes 10.6 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 0.00-1.00 sec 872 MBytes 7.31 Gbits/sec [ 5][TX-C] 1.00-2.00 sec 958 MBytes 8.03 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 1.00-2.00 sec 1.34 GBytes 11.5 Gbits/sec [ 5][TX-C] 2.00-3.00 sec 426 MBytes 3.58 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 2.00-3.00 sec 1.48 GBytes 12.7 Gbits/sec [ 5][TX-C] 3.00-4.00 sec 159 MBytes 1.33 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 3.00-4.00 sec 1.49 GBytes 12.8 Gbits/sec [ 5][TX-C] 4.00-5.00 sec 478 MBytes 4.01 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 4.00-5.00 sec 1.56 GBytes 13.4 Gbits/sec [ 5][TX-C] 5.00-6.00 sec 331 MBytes 2.78 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 5.00-6.00 sec 1.55 GBytes 13.3 Gbits/sec [ 5][TX-C] 6.00-7.00 sec 245 MBytes 2.06 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 6.00-7.00 sec 1.66 GBytes 14.3 Gbits/sec [ 5][TX-C] 7.00-8.00 sec 450 MBytes 3.77 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 7.00-8.00 sec 1.51 GBytes 13.0 Gbits/sec [ 5][TX-C] 8.00-9.00 sec 344 MBytes 2.88 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 8.00-9.00 sec 1.62 GBytes 13.9 Gbits/sec [ 5][TX-C] 9.00-10.00 sec 641 MBytes 5.38 Gbits/sec 0 2.97 MBytes [ 7][RX-C] 9.00-10.00 sec 1.49 GBytes 12.8 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-10.00 sec 5.18 GBytes 4.45 Gbits/sec 0 sender [ 5][TX-C] 0.00-10.03 sec 5.17 GBytes 4.43 Gbits/sec receiver [ 7][RX-C] 0.00-10.00 sec 14.6 GBytes 12.5 Gbits/sec 1976 sender [ 7][RX-C] 0.00-10.03 sec 14.6 GBytes 12.5 Gbits/sec receiver

Михаил

Никаких фаерволов и аппарморов нет

Михаил

неа

Михаил

да, бонд есть

Михаил

Но это никогда не было проблемой

Михаил

не не, дубовый. Active/Backup

Михаил

root@ost-c03-3:~# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v5.15.0-88-generic Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eno2 MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Peer Notification Delay (ms): 0 Slave Interface: eno2 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 10:60:4b:98:dd:2c Slave queue ID: 0 Slave Interface: eno1 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 10:60:4b:98:dd:28 Slave queue ID: 0

Михаил

Из какого-то тюнинга виртуальных адаптеров включен только multiqueied Virtio (адаптеры разумеется virtio) root@testvm2:~# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether fa:16:3e:34:ac:c5 brd ff:ff:ff:ff:ff:ff altname enp0s3 root@testvm2:~# nproc 2 root@testvm2:~# ethtool -l ens3 Channel parameters for ens3: Pre-set maximums: RX: n/a TX: n/a Other: n/a Combined: 2 Current hardware settings: RX: n/a TX: n/a Other: n/a Combined: 2

Михаил

Но это тоже проблем не вызывало на RH/CentOS OVS инсталляции

Михаил

root@testvm2:~# lspci -k | grep -A 2 Ethernet 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device Subsystem: Red Hat, Inc. Virtio network device Kernel driver in use: virtio-pci

АСБ

Добрый день! Можно ли исключить доработку напильником в моём случае, или это нормально? Openstack устанавливаю через kolla-ansible, в cinder'e дополнительные объявляю типы дисков в /etc/kolla/config/cinder.conf: enabled_backends=lvm-sata,lvm-ssd [lvm-sata] volume_group=cinder-volumes-sata volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name=LVM_SATA target_helper = tgtadm target_protocol = iscsi [lvm-ssd] volume_group=cinder-volumes-ssd volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name=LVM_SSD target_helper = tgtadm target_protocol = iscsi Этот файл мержится в /etc/kolla/cinder-volume/cinder.conf но диски на этих бэкендах не создаются, вылетает ошибка: "schedule allocate volume:Could not find any available weighted backend" a openstack volume service list Показывает такую красоту: +------------------+---------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+---------------+------+---------+-------+----------------------------+ | cinder-scheduler | 2288hv5 | nova | enabled | up | 2023-11-15T12:22:19.000000 | | cinder-volume | 2288hv5@lvm-1 | nova | enabled | up | 2023-11-15T12:22:22.000000 | | cinder-backup | 2288hv5 | nova | enabled | down | 2023-11-15T10:51:02.000000 | +------------------+---------------+------+---------+-------+----------------------------+ Приходится дорабатывать напильником /etc/kolla/cinder-volume/cinder.conf вот так: --- /etc/kolla/cinder-volume/cinder.conf.old 2023-11-20 14:50:25.680656863 +0300 +++ /etc/kolla/cinder-volume/cinder.conf 2023-11-20 14:51:47.812906507 +0300 @@ -8,7 +8,7 @@ glance_num_retries = 1 glance_ca_certificates_file = -enabled_backends = lvm-1 +enabled_backends = lvm-1,lvm-sata,lvm-ssd api_paste_config = /etc/cinder/api-paste.ini auth_strategy = keystone @@ -74,8 +74,6 @@ [coordination] -enabled_backends = lvm-sata,lvm-ssd - [lvm-sata] volume_group = cinder-volumes-sata volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver Далее: systemctl restart kolla-cinder_api-container kolla-cinder_volume-container kolla-cinder_scheduler-container Только после этого можно создать диски на этих бэкендах и появляется нужный вывод: $ openstack volume service list +------------------+------------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+------------------+------+---------+-------+----------------------------+ | cinder-scheduler | 2288hv5 | nova | enabled | up | 2023-11-20T11:57:30.000000 | | cinder-volume | 2288hv5@lvm-1 | nova | enabled | up | 2023-11-20T11:57:23.000000 | | cinder-backup | 2288hv5 | nova | enabled | down | 2023-11-20T11:19:40.000000 | | cinder-volume | 2288hv5@lvm-sata | nova | enabled | up | 2023-11-20T11:57:29.000000 | | cinder-volume | 2288hv5@lvm-ssd | nova | enabled | up | 2023-11-20T11:57:28.000000 | +------------------+------------------+------+---------+-------+----------------------------+ Как сделать, чтобы Колла правильно смержила enabled_backends в секции [DEFAULT] и напильником ничего не дорабатывать?

Artemy

Максим покинул чат вместе с командой

Михаил

Максим покинул чат вместе с командой

У кого теперь про ретрансмиты спрашивать?)

Artemy

У представителей спортлото, очевидно

Михаил

А ресурсов на инстансах хватает, чтобы 10г прогнать ?

Инстансы как и железки в большинстве своём греют воздух. Загрузка околонулевая

• _

У представителей спортлото, очевидно

Они сюда часто заглядывают с предложением криптоскама

Михаил

Вот я к вам за этим и пришёл)

Михаил

не не, база впорядке

NS 🇷🇺

Добрый день! Можно ли исключить доработку напильником в моём случае, или это нормально? Openstack устанавливаю через kolla-ansible, в cinder'e дополнительные объявляю типы дисков в /etc/kolla/config/cinder.conf: enabled_backends=lvm-sata,lvm-ssd [lvm-sata] volume_group=cinder-volumes-sata volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name=LVM_SATA target_helper = tgtadm target_protocol = iscsi [lvm-ssd] volume_group=cinder-volumes-ssd volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name=LVM_SSD target_helper = tgtadm target_protocol = iscsi Этот файл мержится в /etc/kolla/cinder-volume/cinder.conf но диски на этих бэкендах не создаются, вылетает ошибка: "schedule allocate volume:Could not find any available weighted backend" a openstack volume service list Показывает такую красоту: +------------------+---------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+---------------+------+---------+-------+----------------------------+ | cinder-scheduler | 2288hv5 | nova | enabled | up | 2023-11-15T12:22:19.000000 | | cinder-volume | 2288hv5@lvm-1 | nova | enabled | up | 2023-11-15T12:22:22.000000 | | cinder-backup | 2288hv5 | nova | enabled | down | 2023-11-15T10:51:02.000000 | +------------------+---------------+------+---------+-------+----------------------------+ Приходится дорабатывать напильником /etc/kolla/cinder-volume/cinder.conf вот так: --- /etc/kolla/cinder-volume/cinder.conf.old 2023-11-20 14:50:25.680656863 +0300 +++ /etc/kolla/cinder-volume/cinder.conf 2023-11-20 14:51:47.812906507 +0300 @@ -8,7 +8,7 @@ glance_num_retries = 1 glance_ca_certificates_file = -enabled_backends = lvm-1 +enabled_backends = lvm-1,lvm-sata,lvm-ssd api_paste_config = /etc/cinder/api-paste.ini auth_strategy = keystone @@ -74,8 +74,6 @@ [coordination] -enabled_backends = lvm-sata,lvm-ssd - [lvm-sata] volume_group = cinder-volumes-sata volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver Далее: systemctl restart kolla-cinder_api-container kolla-cinder_volume-container kolla-cinder_scheduler-container Только после этого можно создать диски на этих бэкендах и появляется нужный вывод: $ openstack volume service list +------------------+------------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+------------------+------+---------+-------+----------------------------+ | cinder-scheduler | 2288hv5 | nova | enabled | up | 2023-11-20T11:57:30.000000 | | cinder-volume | 2288hv5@lvm-1 | nova | enabled | up | 2023-11-20T11:57:23.000000 | | cinder-backup | 2288hv5 | nova | enabled | down | 2023-11-20T11:19:40.000000 | | cinder-volume | 2288hv5@lvm-sata | nova | enabled | up | 2023-11-20T11:57:29.000000 | | cinder-volume | 2288hv5@lvm-ssd | nova | enabled | up | 2023-11-20T11:57:28.000000 | +------------------+------------------+------+---------+-------+----------------------------+ Как сделать, чтобы Колла правильно смержила enabled_backends в секции [DEFAULT] и напильником ничего не дорабатывать?

ну так тут во первых не указано, что в секцию дефолт надо добавить

Михаил

Так, пойду кое-что проверю и вернусь вас мучать дальше

Михаил

Да да, я именно это и делаю)

Михаил

Я много раз им это говорил) Но они говорят, что не дадут) 1500 и всё)

АСБ

ну так тут во первых не указано, что в секцию дефолт надо добавить

Где тут? При мёрже появляется второй enabled_backends вне секции DEFAULT, это приводит к тому, что типы дисков есть, а сами диски на этих бэкендах создать нельзя. Если в секцию DEFAULT в enabled_backends добавить бэкенды, то они цепляются и с ними можно работать. Практика такая, с документацией не совпадает.

NS 🇷🇺

Где тут? При мёрже появляется второй enabled_backends вне секции DEFAULT, это приводит к тому, что типы дисков есть, а сами диски на этих бэкендах создать нельзя. Если в секцию DEFAULT в enabled_backends добавить бэкенды, то они цепляются и с ними можно работать. Практика такая, с документацией не совпадает.

так вы не добавили

NS 🇷🇺

перечитайте еще раз, что сами пишите

NS 🇷🇺

в упор не вижу секции DEFAULT

Михаил

root@testvm2:~# ping -M do -s 1472 testvm PING testvm.infra.nova (192.168.120.3) 1472(1500) bytes of data. 1480 bytes from testvm.infra.nova (192.168.120.3): icmp_seq=1 ttl=64 time=3.24 ms 1480 bytes from testvm.infra.nova (192.168.120.3): icmp_seq=2 ttl=64 time=2.04 ms 1480 bytes from testvm.infra.nova (192.168.120.3): icmp_seq=3 ttl=64 time=0.768 ms 1480 bytes from testvm.infra.nova (192.168.120.3): icmp_seq=4 ttl=64 time=0.855 ms ^C --- testvm.infra.nova ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 0.768/1.724/3.237/1.007 ms

Михаил

Между компьютами вообще никаких проблем. P.S. Но я специально проверил - всё пролазит

Михаил

Проблема с трафиком только внутри виртуалок

Михаил

1. Мту 1500. Везде 2. Что конкретно там показать? 3. Dvr нет

Михаил

Сети поданы вланами

Михаил

Ды с запуском инстанса проблем нет)

Михаил

Всё прекрасно создаётся

Михаил

Да

АСБ

в упор не вижу секции DEFAULT

Да, если тут объявить секцию DEFAULT, то всё подключается как надо, без напильника. Спасибо.

NS 🇷🇺

Да, если тут объявить секцию DEFAULT, то всё подключается как надо, без напильника. Спасибо.

Ну это ж очевидно ) обращайтесь

АСБ

Ну это ж очевидно ) обращайтесь

Как раз - нет. Я так делал сначала, но вместо списка enabled_backends = lvm-1,lvm-sata,lvm-ssd получал enabled_backends = lvm-sata,lvm-ssd Т.е. терялся дефолтный lvm-1, что я посчитал ошибкой и не стал дальше проверять. А оказалось, что cinder'у пофиг, он lvm-1 всё-равно цепляет.

NS 🇷🇺

Как раз - нет. Я так делал сначала, но вместо списка enabled_backends = lvm-1,lvm-sata,lvm-ssd получал enabled_backends = lvm-sata,lvm-ssd Т.е. терялся дефолтный lvm-1, что я посчитал ошибкой и не стал дальше проверять. А оказалось, что cinder'у пофиг, он lvm-1 всё-равно цепляет.

Он не цепляет то, чего нет в конфиге

Михаил

Дык как это мешает? Они висят на реальных ip. Балансятся через NetScaler. База кластеризована

Михаил

На каждой compute ноде ovn-controller смотрит на VIP нетскелера

АСБ

Он не цепляет то, чего нет в конфиге

Михаил

ADC

Михаил

Смотри, я думаю как устроена голова наверное большой разницы нет) В плане балансинга. Реально есть три виртуалки, на которых крутится кластерная OVNDB. North/South. Клиенты (компьюты) ходют туда через нетскелер и всё)

Михаил

Оно ведь только за управление портами считай отвечает

Михаил

Трафик оно не терминирует

Михаил

потому что keepalive нужен просто чтобы живой был инстанс базы, так? А haproxy просто балансит. Ну вот у нас вместо первого кластер, а вместо второго цитрикс

Михаил

Вот такая схема считай (только вместо хапрокси - цитрикс)

Михаил

https://satishdotpatel.github.io/openstack-ansible-ovn-clustering/

Михаил

Но мне кажется, что мы не туда пошли смотреть) (возможно я не прав). Я понимаю, что это очень интересно, но думается мне на компьюте какая-то проблема

Михаил

Хотя при запуске айперфа tcpdump какие-то пакеты в сторону south-db показывает, но думается мне, это какой-нибудь netflow

АСБ

Он не цепляет то, чего нет в конфиге

Да, он не цепляет то, чего нет в конфиге. lvm-1 в состоянии Down, а тип вольюма __DEFAULT__ замапился на lvm_sata: $ openstack volume list +--------------------------------------+-----------+--------+------+--------------------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-----------+--------+------+--------------------------------------------+ | a950523c-a91f-42d3-aeb3-ccc47a134362 | | in-use | 5 | Attached to 1 on /dev/vda | А физически диск этой VM лежит в cinder-volumes-sata: # lvm lvscan | grep a950523c-a91f-42d3-aeb3-ccc47a134362 ACTIVE '/dev/cinder-volumes-sata/volume-a950523c-a91f-42d3-aeb3-ccc47a134362' [5,00 GiB] inherit Поэтому прихожу к выводу, что надо самому все бэкенды перечислять в `/etc/kolla/config/cinder.conf`: ``` enabled_backends = lvm-1,lvm-sata,lvm-ssd ```

J

Ну-ка) Чо там сломали?

Stanley

«расстрелять»

J

Потому что там логи стронгсвана не попадают в лог нейтрона. Приходится отдельно их настраивать и собирать.

J

Та еще возня.

Stanley

Потому что там логи стронгсвана не попадают в лог нейтрона. Приходится отдельно их настраивать и собирать.

А там лебедь под капотом что ли?

J

А там лебедь под капотом что ли?

StrongSwan или LibreSwan. Чо доступно в дистрибутиве и чо выберешь в vpn_device_driver в l3_agent.ini.

Stanley

Тогда Нафига этот все? Запулил лебедя отдельно в виде вм и все

J

Тогда Нафига этот все? Запулил лебедя отдельно в виде вм и все

Ну там автоматическое переключение между экземплярами HA роутера, маршруты сами добавляются, вот это все. Всё равно чуть меньше настраивать и чуть надежнее чем выключать порт секьюрити на одном инстансе и его как vpn шлюз использовать.

Stanley

Возможно. Еще б работало

J

Возможно. Еще б работало

Работает, вроде, но из-за небольшой востребованности никто им не занимается что-то.

J

Интересно, чем конкретно) А как ты понял?

J

ааа

Stanley

По дефолту ип6. Отлично. :)

Stanley

А вот нечего на апстриме сидеть. Трейн - и нет никаких проблем

NS 🇷🇺

трейн уже мхом поросло. Yoga еще можно понять =)

Михаил

Парни, а вот ещё вопрос. Плейсмент при разливке машины пишет, что как будто стоит трейт COMPUTE_STATUS_DISABLED 2023-11-21 12:18:32.614 228948 DEBUG nova.scheduler.request_filter [req-8589f68f-720a-4007-9572-341eeae1cc7c 5b9d00faf6a9dcd7e82cd981975564f90361ff4f15fa1a57167c8cb2c7c4d5ac 2dfcf8aad3544cde946ec04f104eeb40 - f005f0e451bb4d688a8d481b5d25c269 f005f0e451bb4d688a8d481b5d25c269] compute_status_filter request filter added forbidden trait COMPUTE_STATUS_DISABLED compute_status_filter /usr/lib/python3/dist-packages/nova/scheduler/request_filter.py:254 Но фактически его нигде не стоит. Все compute службы в UP и ENABLED.

Михаил

Ванильный Zed

J

>forbidden trait

Михаил

Zed's dead, baby. Zed's dead

Stanley

compute service list?

Михаил

>forbidden trait

Ну вот фильтр возвращает, как я понял, что он видит COMPUTE_STATUS_DISABLED

Михаил

compute service list?

Михаил

Даже если в базу заглянуть, этого трейта нигде нет

Михаил

MariaDB [placement]> select * from traits where name = 'COMPUTE_STATUS_DISABLED'; +---------------------+------------+----+-------------------------+ | created_at | updated_at | id | name | +---------------------+------------+----+-------------------------+ | 2023-03-05 18:20:28 | NULL | 25 | COMPUTE_STATUS_DISABLED | +---------------------+------------+----+-------------------------+ 1 row in set (0.000 sec) MariaDB [placement]> select * from resource_provider_traits where trait_id = 25; Empty set (0.000 sec)

J

MariaDB [placement]> select * from traits where name = 'COMPUTE_STATUS_DISABLED'; +---------------------+------------+----+-------------------------+ | created_at | updated_at | id | name | +---------------------+------------+----+-------------------------+ | 2023-03-05 18:20:28 | NULL | 25 | COMPUTE_STATUS_DISABLED | +---------------------+------------+----+-------------------------+ 1 row in set (0.000 sec) MariaDB [placement]> select * from resource_provider_traits where trait_id = 25; Empty set (0.000 sec)

А чего ты к этому сообщению в логе прицепился? Проблема сама в чем?

Михаил

А чего ты к этому сообщению в логе прицепился? Проблема сама в чем?

В том, что из-за этого машину не разлить. Плейсмент отбивает, думая, что сервисы задизейблены

J

В том, что из-за этого машину не разлить. Плейсмент отбивает, думая, что сервисы задизейблены

Не думаю что дело в этом.