Modelo de Arquitetura para Gerenciamento de Qualidade de
Transcrição
Modelo de Arquitetura para Gerenciamento de Qualidade de
Alexis Saito Ericsson Telecomunicações Marcelo Frate Instituto Federal de São Paulo – Campus Boituva Fabio Luciano Verdi Universidade Federal de São Carlos – Campus Sorocaba Qualidade de Serviço em redes Qualidade de Serviço: Entrega de conteúdo com requisitos específicos Web/File Transfer Protocol -> confiabilidade Multimedia -> entrega a tempo O grande problema: a Internet não garante a entrega de pacotes a tempo (requisito de tempo) Soluções Atuais de QoS Muitas architeturas de QoS como IntServ, Diffserv, MPLS foram propostas mas nenhuma resolveu definitivamente o problema. Porque? Estas propostas são baseadas na arquitetura de controle distribuído da Internet (hop-to-hop) e na lógica de roteamento baseado em business entre ISPs que não utiliza as informações de recursos de rede fim-a-fim. Em redes de datacenters ocorre o mesmo problema. Soluções de QoS tais como as citadas acima precisam ser incorporadas, o que eleva muito o CAPEX da rede. Soluções típicas de roteamento em datacenters tais como o ECMP não levam em conta QoS. QoS @ OpenFlow Objetivo: Gerenciar o tráfego em caminhos configurados baseados em QoS. OpenFlow: Provê visibilidade dos recursos de rede Gerenciamento instantâneo dos recursos adaptando o comportamento de rede fim-a-fim de modo transparente Diferenciação de pacotes por fluxo OF1.3: Meter table A meter table consists of meter entries, defining per-flow meters. Per-flow meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting, and can be combined with per-port queues) to implement complex QoS frameworks, such as DiffServ. A meter measures the rate of packets assigned to it and enables controlling the rate of those packets. Meters are attached directly to flow entries (as opposed to queues which are attached to ports). Any flow entry can specify a meter in its instruction set: the meter measures and controls the rate of the aggregate of all flow entries to which it is attached. Multiple meters can be used in the same table, but in an exclusive way (disjoint set of flow entries). Multiple meters can be used on the same set of packets by using them in successive flow tables. OF1.3: Meter Band entry Each meter may have one or more meter bands. Each band specifies the rate at which the band applies and the way packets should be processed. Packets are processed by a single meter band based on the current measured meter rate. The meter applies the meter band with the highest configured rate that is lower than the current measured rate. If the current rate is lower than any specified meter band rate, no meter band is applied. Diagrama de relacionamento entre as tabelas no Openflow 1.3 Flow Table 1..1 1..n 1..1 Action (output=out_port) Impacto do Meter band rate na largura de banda de porta/link L2/3 Equipment Action (output=1) Flow 1 Flow 2 Flow 3 Flow 4 Match Logic Meter 1 Meter2 Meter3 Meter4 TBp = Total Bandwidth for port Available Bandwidth = TBp (Meter 2 Band + Meter 4 Band) Exemplo Controller Links Links 1M 10 M 1M 10 M 10 M 10 M 10 M 10 M 10 M 10 M Experimento passo A Controller Set flow1, flow2 1M Set flow1, flow2 1M Links Pkt analysis Links 10 M 10 M 10 M 10 M 10 M 10 M 10 M 10 M On S2: Flow1={match="oxm{in_port="1",ipv4_src="10.0.0.1",ipv4_dst="10.0.0.6"},insts=[meter{meter="5702"},apply{acts=[out{port="2"}]}]} Flow2={match="oxm{in_port=“2",ipv4_src="10.0.0.6",ipv4_dst="10.0.0.1"},insts=[meter{meter="5702"},apply{acts=[out{port=“1"}]}]} Experimento passo B Controller Set flow1, flow2 1M Set flow1, flow2 1M Links Pkt analysis Links 10 M 10 M 10 M 10 M 10 M 10 M 10 M 10 M On S2: Flow1={match="oxm{in_port=“2",ipv4_src="10.0.0.2",ipv4_dst="10.0.0.7"},insts=[meter{meter=“3426"},apply{acts=[out{port=“7"}]}]} Flow2={match="oxm{in_port=“7",ipv4_src="10.0.0.7",ipv4_dst="10.0.0.2"},insts=[meter{meter=“3426"},apply{acts=[out{port=“2"}]}]} Implementação dos Meters Limitações impostas através dos meters: •h1 utiliza o serviço em srv 6, com limitação de banda de 512 Kbps; •h2 utiliza o serviço em srv 7, com limitação de banda de 1Mbps; •h3 utiliza o serviço em srv 8, com limitação de banda 2Mbps; •h4 utiliza o serviço em srv 9, com limitação de banda de 512 Kbps; •h5 utiliza o serviço em srv 10, com limitação de banda de 3Mbps; Resultados Sem os meters, o fluxo ocupa a banda total disponível, dividindo-a em caso de concorrência. Com os meters, o fluxo está limitado ao valor imposto pelo sistema, dividindo também a banda em caso de concorrência. h1-srv6 - Bandwidth (Kbits/sec) h2-srv7 - Bandwidth (Kbits/sec) 1500 1000 500 0 1 2 3 4 5 6 7 8 9 10 h3-srv8 - Bandwidth (Mbits/sec) 1500 6,00 1000 4,00 500 2,00 0 0,00 1 2 3 4 5 6 7 8 9 1 10 h4-srv9 - Bandwidth (Mbits/sec) 2 3 4 5 6 7 8 9 h5-srv10 - Bandwidth (Mbits/sec) 4,00 10 3,00 8 2,00 No-Meter 1,00 Meter 6 4 2 0 0,00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Modelo de Arquitetura Contract Manager Policy Control Logic Service Manager DB Controller Resource Manager Topology OF1.3 DATA CENT ER DATA CENT ER Conclusões Os Meters no OpenFlow 1.3 são uma importante ferramenta para controle de QoS maneira dinâmica e transparente No Control Plane, significam uma avanço no gerenciamento de banda como controle de recurso, centralizando o controle de QoS e propiciando o gerenciamento de políticas baseadas em recursos de rede