Neutron qos overview
- 1. Quality of Service in OpenStack Neutron Sławek Kapłoński slawomir.Kaplonski@corp.ovh.com IRC: slaweq @ freenode
- 2. Agenda • What QoS means for networks • What is available and supported in Neutron currently • How to use Neutron’s QoS • How it works underneath • Plans for the future
- 3. Quality of Service for Networks Quality of Service (QoS) for networks is an industry-wide set of standards and mechanisms for ensuring high-quality performance for critical applications. The goal of QoS is to provide preferential delivery service for the applications that need it by ensuring sufficient bandwidth, controlling latency and jitter, and reducing data loss. source: https://technet.microsoft.com/
- 4. QoS in Neutron Introduced in Liberty as generic framework to provide different type of QoS rules
- 5. QoS in Neutron - model
- 6. QoS in Neutron - available rule types • Bandwidth limit rule (egress traffic only) • DSCP marking rule • Minimum bandwidth, best effort (egress traffic only)
- 7. QoS in Neutron L2 agents support for rule types Bandwidth limit rule DSCP marking rule Minimum bandwidth rule Openvswitch agent + + - Linuxbridge agent + + - SR-IOV agent + - +
- 8. How to use QoS in Neutron Create QoS policy admin@devstack-2:~$ neutron qos-policy-create Openstack-Day-QoS Created a new policy: +-----------------+--------------------------------------+ | Field | Value | +-----------------+--------------------------------------+ | created_at | 2017-03-16T13:32:17Z | | description | | | id | ce63178a-f614-4f1d-b27b-30f8b7b1c9fa | | name | Openstack-Day-QoS | | project_id | 4ec2efced54b44719377a710aacbf3da | | revision_number | 1 | | rules | | | shared | False | | tenant_id | 4ec2efced54b44719377a710aacbf3da | | updated_at | 2017-03-16T13:32:17Z | +-----------------+--------------------------------------+
- 9. How to use QoS in Neutron Create QoS rule (bandwidth limit rule) admin@devstack-2:~$ neutron qos-bandwidth-limit-rule-create --max-kbps 512 --max-burst-kbps 1024 Openstack-Day-QoS Created a new bandwidth_limit_rule: +----------------+--------------------------------------+ | Field | Value | +----------------+--------------------------------------+ | id | 917b0ffe-d747-4d28-92f5-098877a566e1 | | max_burst_kbps | 1024 | | max_kbps | 512 | +----------------+--------------------------------------+
- 10. How to use QoS in Neutron Apply QoS policy to port admin@devstack-2:~$ neutron port-update c7207985-07b5-44d6-93a8-82916f709dc2 --qos-policy Openstack-Day-QoS Updated port: c7207985-07b5-44d6-93a8-82916f709dc2 admin@devstack-2:~$ neutron port-show c7207985-07b5-44d6-93a8-82916f709dc2 neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +-----------------------+---------------------------------------+ | Field | Value | +-----------------------+---------------------------------------+ | binding:vif_type | ovs | | binding:vnic_type | normal | | device_id | 7fbd0a01-1ab9-49ef-8f22-c8299e9788cb | | id | c7207985-07b5-44d6-93a8-82916f709dc2 | | mac_address | fa:16:3e:2d:9b:e3 | | network_id | 81513106-bda5-4040-9691-51411706a24c | | qos_policy_id | ce63178a-f614-4f1d-b27b-30f8b7b1c9fa | | status | ACTIVE | +-----------------------+---------------------------------------+
- 11. QoS in Neutron - underneath Openvswitch L2 agent • DSCP marking – uses openflow rules in integration bridge admin@devstack-2:/opt/stack/neutron$ sudo ovs-vsctl list interface qvoc7207985-07 | grep ingress ingress_policing_burst: 1024 ingress_policing_rate: 512 • Bandwidth limit – uses ingress policing provided by OVS admin@devstack-2:/opt/stack/neutron$ sudo ovs-ofctl dump-flows br-int table=0, n_packets=8026, n_bytes=2700284, idle_age=9, hard_age=16, priority=65535,reg2=0,in_port=7 actions=mod_nw_tos:64
- 12. QoS in Neutron - underneath Linuxbridge L2 agent • DSCP marking – uses iptables rules in mangle table ubuntu@devstack-ubuntu-1604:~$ tc qdisc show dev tap2829f908-96 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc ingress ffff: parent ffff:fff1 ---------------- ubuntu@devstack-ubuntu-1604:~$ tc filter show dev tap2829f908-96 parent ffff: filter protocol all pref 49 basic filter protocol all pref 49 basic handle 0x1 police 0x1 rate 512Kbit burst 128Kb mtu 64Kb action drop overhead 0b ref 1 bind 1 • Bandwidth limit – uses policing on ingress qdisc in tc sudo iptables -t mangle -L neutron-linuxbri-qos-o2829f9 Chain neutron-linuxbri-qos-o2829f9 (1 references) target prot opt source destination DSCP all -- anywhere anywhere DSCP set 0x10
- 13. QoS in Neutron – underneath Why ingress policing? VM Bridge tap Traffic going out from VM It all depends on the point of view
- 14. QoS in Neutron – ingress qdisc in tc Ingress qdisc is based on TBF algorithm source: http://unix.stackexchange.com/a/100797
- 15. QoS in Neutron - underneath SR-IOV L2 agent • Bandwidth limit - using iproute2 vf features via „ip link” command $ ip link show enp8s0f0 3: enp8s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 90:e2:ba:5e:a6:40 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, tx rate 1000 (Mbps), max_tx_rate 1000Mbps, spoof checking on, link-state auto vf 1 MAC 56:92:c6:c6:e5:db, tx rate 2000 (Mbps), max_tx_rate 2000Mbps, spoof checking on, link-state auto • Minimum bandwidth - using iproute2 vf features via „ip link” command
- 16. QoS in Neutron – plans for future Better QoS rules validation (patch in review) Now admin@devstack-2:~$ neutron qos-available-rule-types +-----------------+ | type | +-----------------+ | dscp_marking | | bandwidth_limit | +-----------------+ admin@devstack-2:/opt/stack/neutron$ neutron port-update c7207985-07b5-44d6-93a8-82916f709dc2 --qos-policy Openstack-Day-QoS Rule dscp_marking is not supported by port c7207985-07b5-44d6-93a8-82916f709dc2 Will be
- 17. QoS in Neutron – plans for future Bandwidth limit for ingress traffic • data consuming apps: crawlers, dataminers, etc. • planning and allocation of bandwidth in general admin@devstack-2:/opt/stack/neutron$ neutron qos-bandwidth-limit-rule-create --max-kbps 512 --direction ingress example-policy
- 18. QoS in Neutron – plans for future Strict minimum bandwidth for ports – scheduling aware 10Gbps 10Gbps 10Gbps 8 Gbps 7 Gbps 3 Gbps 8 Gbps 7 Gbps 3 Gbps3 Gbps
- 19. QoS in Neutron – plans for future Default policy for project (patch in review) • Mark QoS policy as default for tenant • All new networks created in tenant will have this QoS policy admin@devstack-2:/opt/stack/neutron$ neutron qos-policy-create the-default-policy --default True
- 20. QoS in Neutron – plans for future Traffic classification • Apply rules to specific traffic flows • Use cases: Prioritize certain traffic, like control, realtime data, etc. +-----------+ +---------+ +-------------------+ | QosPolicy |--+--| QosRule |----| TrafficClassifier | (SSH) +-----------+ | +---------+ +-------------------+ | | +---------+ +-------------------+ +--| QosRule |----| TrafficClassifier | (HTTP) | +---------+ +-------------------+ | | +---------+ --| QosRule | (all the other traffic) +---------+
- 21. QoS in Neutron – plans for future • ECN (Explicit Congestion Notification) integration • Integration of QoS in Horizon Dashboard (patch in review)
- 22. QoS in Neutron – IRC meetings Every two weeks (on odd weeks) on Tuesday at 1500 UTC in #openstack-meeting http://eavesdrop.openstack.org/#Neutron_QoS_Meeting
- 23. Thank you Quality of Service in OpenStack Neutron Sławek Kapłoński slawomir.Kaplonski@corp.ovh.com IRC: slaweq @ freenode @slaweq
Editor's Notes
- #4: QoS w kontekście sieci ogólnie jest to zbiór standardów i mechanizmów zapewniających określony poziom usług. Celem jest dostarczenie usług sieciowych o określonych parametrach takich jak bandwidth, opóźnienie (latency) czy jitter (wachania opóźnienia)
- #5: QoS pojawił się w Liberty jako ogólny framework do tworzenia różnych polityk i reguł. Wprowadził L2 extension drivers (rozszerzenia dla agentów)
- #6: Ogólnie model: Port (lub sieć) połączona jest z jedną QoS policy w której są różne reguły (tu przykładowe podane) W jednej policy nie może być więcej niż jedna regułą danego typu
- #7: Aktualnie (Newton) w Neutronie są dostępne trzy rodzaje reguł QoS: bw_limit – limit ruchu wychodzącego z VMki Dscp marking – markuje tylko pakiety wychodzące oczywiście, pozawala otagować ruch z danej Vmki tak, aby inne urządzenia w sieci mogły np. nadać odpowiedni priorytet takim pakietom, czasami ze względów bezpieczeństwa można przepuszczać tylko ruch z określonym mark’iem Minumum bw – tylko best effort, nie ma gwarancji ponieważ to wymaga raportowania o ilości zasobów (sieci) na hoście do schedulera i będzie w przyszłości
- #8: Każdy typ reguły QoS wymaga implementacji po stronie hosta (L2 agent). QoS jest zaimplementowany w tych agentach jako tzw. L2 extension drivers Tak prezentuje się obecnie sytuacja jakie reguły są wspierane przez jakie backendy. Każdy z tych backendów implemetuje ten sam typ reguł w inny sposób, ale o tym później
- #9: Najpierw należy utworzyć policy, która jest „kontenerem” dla reguł QoS QoS policy wspierają równeż RBAC więc można utworzyć policy z –shared i później udostępnić ją jakiemuś tenantowi
- #10: Najpierw należy utworzyć policy, która jest „kontenerem” dla reguł QoS Przykład pokazuje bw limit rule, inne tworzy się podobnie, tylko z innymi parametrami.
- #11: Teraz przypisujemy politykę do portu, Na żółto pokazana interesująca nas linia z QoS’em Po tym jak wykonamy ten krok, wszystkie reguły które są w policy (tu bw limit) zostaną zaaplikowane do portu przez L2 agenta (w tym przypadku ovs agent)
- #12: Technologie używane przez różne backendy. OVS agent: bw_limit – ustawia ingress_policing w OVS’ie w parametrach interfejsu – dlaczego ingress? Kwestia tego z którego miejsca „patrzymy” na ten ruch. Dla QoS’a patrzymy na ruch z punktu widzenia bridge’a więc ruch przychodzący do portu (bridge’a) to ruch de facto wychodzący z Vmki Dscp marking – reguła openflow w br-int
- #13: Technologie używane przez różne backendy. LB agent: bw_limit – korzysta z mechanizmu traffic policing na ingress qdisc (tam jest tak naprawdę tbf używany). Dscp marking – pakiety markowane przez iptables (tabela mangle, chain POSTROUTING) Pref (prio) – The priority of this classifier. Lower numbers get tested first.
- #14: Na poprzednich slajdach mówiłem że OVS i LB używają limitowania przez ingress policing. Pytanie może być: dlaczego skoro mamy limitować ruch wychodzący? Odpowiedź jest prosta: wszystko zależy od punktu widzenia z jakiego „patrzymy” na ruch…..
- #15: Jak działą tbf (token bucket filter): Jest pewien object (coś jak wiadro). Przetrzymuje on tokeny i może trzymać tylko konkrentą ich ilość – jak będzie za dużo to zostaną usunięte (jak woda rozlana z wiadra gdy się przeleje). Rozmiar wiadra określa burst. Pakiety które czekają na wysłanie są umieszczone w kolejce która nazywa się qdisc. Pakiet który ma być wysłany musi posiadać token odpowiadający swojemu rozmiarowi (w bajtach). Długość tej kolejki określa parametr latency w ustawieniach tc-tbf. Important setting here is value of burst: too low - configured bw limit will not be reached too high - too many packets will have tokens and bw_limit higher than expected
- #16: SR-IOV agent używa feature’ów VirtualFunction udostępnianych przez urządzenie sieciowe. Niestety nie mam przykładów bo nie miałem takiego hosta do sprawdzenia :/
- #17: Poprawiona walidacja (patch w review) Teraz tylko lista wpieranych reguł ale bez żadnej walidacji później. Ma być walidacja na podstawie wspieranych reguł i parametrów dla tych reguł i to na poziomie tworzenia/aktualizacji reguł i tworzenia/update’u sieci i portu
- #18: Przydatne np. dla aplikacji, które konsumują dane z sieci (crawlery) Nie dla sr-iov (brak możliwości limitowania przychodzącego ruchu)
- #19: Ograniczenie – nie można modyfikować policy po schedulowaniu instancji (przynajmniej na początku) Bandwidt traktowany jako resource i raportowany do Nova placement API (generic resource pool)
- #21: Reguły połączone do traffic classifier’a (inny mechanism z neutron’a)
- #22: Z innych planów na przyszłość (dalszą) są jeszcze: ECN – umożliwia powiadomienie urządzeń o przeciążeniu sieci i „zdławieniu” pakietów przesyłanych między nimi Integracja QoS’a w Horizonie
- #23: Z innych planów na przyszłość (dalszą) są jeszcze: ECN – umożliwia powiadomienie urządzeń o przeciążeniu sieci i „zdławieniu” pakietów przesyłanych między nimi Integracja QoS’a w Horizonie