Impulsione o Desempenho do IBM InfoSphere Streams com a Ligação de Canais Linux

Você já pensou se a ligação de canais Linux® permitisse obter rendimento mais rápido usando o IBM® InfoSphere® Streams? Nós responderemos a essa questão ao executar o InfoSphere Streams release 2.0.0.2 no Red Hat Enterprise Linux release 5.5. Neste artigo descrevemos o que é ligação de canais em alto nível, como configuramos nosso ambiente de teste e os resultados que observamos. Nos nossos experimentos, a ligação de canais aumentou a largura de banda em até 68%.

Denton Hatzenbihler, Advisory Software Engineer, IBM

Denton HatzenbihlerDenton (Denny) Hatzenbihler possui mais de 34 anos de experiência na IBM. Iniciou sua carreira na IBM em Manufacturing Engineering, onde trabalhou em hardware e projeto de microcódigo de vários equipamentos de teste e no desenvolvimento de processos e software de teste do System 36 e 38. Em seguida, mudou para o laboratório de desenvolvimento, onde suas designações incluíram o desenvolvimento do código de comunicações TCP/IP no Facsimile Support 400, desenvolvimento do código C++ no AS/400 System License Internal Code em dispositivos de E/S e adaptação de vários produtos da Lotus ao iSeries, incluindo servidor do Domino HTTP, servidor do Sametime e Lotus Workplace. Depois fez consultoria e desenvolveu código para o System i Lab Services Team em vários projetos, relacionados principalmente a segurança e conexão única e soluções de projeto de aplicativo para diversos clientes. Atualmente, ele trabalha na equipe de desenvolvimento do InfoSphere Streams e é formado em Engenharia Elétrica e Eletrônica pela Universidade Estadual de Dakota do Norte.



Richard P. King, Senior Programmer, IBM

Richard King é membro da equipe do InfoSphere Streams há vários anos. Quando passou a fazer parte da IBM em 1977, foi como programador associado trabalhando no desenvolvimento do System/38. Desde sua transferência para a Research Division da IBM no IBM Thomas J. Watson Research Center in Yorktown em 1981, ele trabalhou em uma ampla gama de projetos, incluindo o design e o desenvolvimento do que se tornou a IBM Sysplex Coupling Facility. É formado em Engenharia Industrial e Pesquisa de Operações pela Universidade Cornell. Ele possui mestrado em Pesquisa de Operações e Engenharia Industrial pela Universidade Northwestern.



Wesley Most, Software Engineer, IBM

Wesley MostWesley Most passou a fazer parte da IBM em 2004 como engenheiro de software, dando apoio ao cluster InfoSphere Streams. É membro do departamento Watson IS no Thomas J. Watson Research Center. Desempenhou função importante na arquitetura, administração e ajuste do desempenho dos sistemas, rede e armazenamento para dar suporte ao trabalho de pesquisa e desenvolvimento. Ele é formado em Engenharia e Ciência da Computação pela Universidade de Connecticut.



Mike Oberholtzer, Senior Software Engineer, IBM

Mike OberholtzerMike Oberholtzer passou a fazer parte da IBM em 1984 como programador de software trabalhando no teste de dispositivos de fita do IBM System/36. Em 1986 mudou para o sistema operacional IBM OS/400, trabalhando em suporte ao dispositivo e em 1989 mudou para suporte de backup e recuperação. Em 1993, começou a trabalhar no IBM OS/400 Integrated File System com várias funções de líder do projeto e desenvolvimento e trabalhou ali até mudar para o InfoSphere Streams em 2008, trabalhando em várias funções relacionadas a teste e desenvolvimento. Ele é formado em Ciência da Computação pela Universidade Tecnológica de Michigan.



31/Ago/2012

Visão geral

Este artigo explora os efeitos da ligação de canais no Red Hat Enterprise Linux ao rendimento e à latência do IBM InfoSphere Streams. Descreve como definir e configurar um ambiente ligado a canais usando o sistema Red Hat Enterprise Linux e que tipo de melhorias de desempenho pode se esperar dos aplicativos InfoSphere Streams que executam nesse ambiente. Os leitores alvo são os familiarizados e qualificados com a configuração da interface de rede do InfoSphere Streams e Linux.


O que é ligação de canais?

Ligação de canais é um termo usado para descrever a prática de dividir um único fluxo de dados entre duas placas de interface de rede enquanto apresenta uma única interface à camada do aplicativo. Ao utilizar essa técnica pode ser alcançado um rendimento de dados mais alto, pois os dados podem fluir nas duas placas da interface de rede ao mesmo tempo. A ligação de canais está disponível em todos os kernels Red Hat Enterprise Linux suportados pelo InfoSphere Streams. Testamos uma configuração ligada a canais e explicamos os resultados observados.

Consulte a seção Recursos para obter um link para a documentação do Red Hat Enterprise Linux na ligação de canais.


Configurando a ligação de canais

Hardware

Para alcançar os melhores resultados de desempenho com ligação de canais em conexões de 1 Gbps, considere os seguintes requisitos de hardware:

  • Comutador de 1 Gbps ou uma placa de linha em um comutador maior com alta relação de alocação excessiva
  • Dois sistemas aptos ao Linux com duas conexões Ethernet de 1 Gbps

    Observação: Se estiver usando um blade, use módulos de passagem no chassi. Os módulos do comutador podem não obter o melhor desempenho devido aos algoritmos no comutador de mediação de tráfego.

No nosso ambiente de teste, comutadores Cisco 6509 formam o backbone de 1 Gbps da rede de cluster privada. Para alcançar o desempenho máximo dos sistemas individuais, são usadas placas de linha WS-X6748-GE-TX. Essas placas de linha são placas de alto desempenho (40 Gbps por slot), que fornecem quase 1 Gbps a todas as 48 portas da placa. Para esse teste, o comutador está executando a Versão 12 do IOS da Cisco e a placa de linha está atual com seu firmware. Se o comutador Cisco estiver executando NX-OS ou estiverem sendo usados produtos de outro fornecedor, esses comandos poderão precisar de modificação ou poderão ser todos diferentes. Consulte seu administrador da rede para obter assistência.

Para os números de desempenho indicados a seguir, não foi utilizada configuração especial na comutação de rede. Embora os comutadores de alguns fornecedores suportem o Link Aggregation Control Protocol (LACP), resultados de desempenho mais altos podem ser obtidos usando configuração de ligação somente de sistema operacional. Visto que os hardwares modernos podem facilmente lidar com problemas, como reordenar pacotes que não são sequenciais, sem qualquer penalidade significativa, não é importante depender do hardware do comutador para fazer todo o trabalho.

Figura 1. configuração de teste da ligação de canais do InfoSphere Streams
configuração de teste da ligação de canais do InfoSphere Streams

Software

De uma perspectiva do software, tudo que é necessário já é parte da distribuição do Red Hat Enterprise Linux 5. Para configurar uma ligação de canais no seu ambiente, para cada máquina, é necessário ajustar a configuração de rede e agregar o link no comutador. Para aperfeiçoar essas orientações, iremos presumir que qualquer servidor que for receber ligação de canais deve estar equipado com o Red Hat Enterprise Linux 5 e ter uma das duas interfaces de rede que foram definidas no tempo de desenvolvimento. No nosso exemplo, eth0 foi configurado inicialmente e /etc/sysconfig/network-scripts/ifcfg-eth0 tem aparência semelhante à Listagem 1.

Lista 1. /etc/sysconfig/network-scripts/ifcfg-eth0
              DEVICE=eth0
            
HWADDR=E4:1F:13:78:FE:98
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.6.24.43
NETMASK=255.255.252.0
DNS1=10.6.24.11

Há quatro etapas envolvidas na configuração do software para ligação de canais:

  1. Alterar ifcfg-eth0 em /etc/sysconfig/network-scripts
  2. Alterar ifcfg-eth1 em /etc/sysconfig/network-scripts
  3. Criar um novo ifcfg-bond0 em /etc/sysconfig/network-scripts
  4. Descrever a "ligação" ao sistema

Observação: É melhor executar esse trabalho com a interface desativada. Se executar enquanto estiver ativada, o sistema emitirá um aviso, já que eth0 será escravo, porém, você receberá a configuração de rede correta. Você verá que a reinicialização será mais longa.

Etapa 1: Para ifcfg-eth0, altere a linha BOOTPROTO para none. Removeremos as linhas pertinentes a IPADDR, NETMASK e DNS. Essas informações estarão no arquivo ifcfg-bond0, logo, não perca os detalhes importantes. As novas linhas para ifcfg-eth0 estão a seguir:

              MASTER=bond0
            
SLAVE=yes
USERCTL=no

Etapa 2: Para ifcfg-eth1, editaremos a configuração padrão não usada que o sistema estabeleceu no fornecimento:

              DEVICE=eth1
            
BOOTPROTO=dhcp
ONBOOT=no
HWADDR=e4:1f:13:78:fe:9a

Novamente, alteraremos a linha BOOTPROTO como fizemos para a interface eth0 e adicionaremos as três linhas que começam com MASTER, SLAVE e USERCTL. Também será necessário alterar ONBOOT para yes.

Etapa 3: Agora, definiremos o seguro-garantia através do novo arquivo ifcfg-bond0. Usando as mesmas informações de rede, esse arquivo terá a seguinte aparência:

              DEVICE=bond0
            
ONBOOT=yes
BOOTPROTO=none
IPADDR=10.6.24.43
NETMASK=255.255.252.0
DNS1=10.6.24.11
USERCTL=no

Etapa 4: Já que o seguro-garantia será considerado um novo dispositivo de rede com seu próprio módulo do kernel, será necessário fornecer ao Linux algumas informações sobre esse novo "dispositivo". Criaremos um arquivo em /etc/modprobe.d chamado bonding.conf. No arquivo, adicionaremos essas duas linhas:

             alias bond0 bonding
             
options bond0 mode=0 miimon=100

Consulte Recursos Para documentação do Red Hat Enterprise Linux na ligação do canal.


Resultados de testes

Ambiente

Implementamos um ambiente ligado por canal usando duas máquinas executando o Red Hat Enterprise Linux release 5.5. Cada máquina contém 8 processadores Intel Xeon CPU X5570 operando a 2,93 GHz. Tomamos duas NICs de 1 Gbps e as ligamos por canal através de um comutador Cisco 6509. Consulte Figura 1.

Considerando que nosso objetivo era testar o desempenho, escolhemos o método de ligação chamado Balance Round Robin (balance-rr). Uma maneira de melhorar o rendimento usando o modo de ligação de canal balance-rr é alterar a tolerância do TCP para entrega fora de serviço. Aumentando a tolerância para entrega fora de serviço, é possível reduzir a rapidez com a qual o TCP solicita uma retransmissão de pacotes. A tolerância de pacotes fora de serviço pode ser ajustada configurando o parâmetro tcp_reordering sysctl. Para esse ambiente de teste, configuramos o valor para 127, utilizando o comando Linux a seguir: sysctl -w net.ipv4.tcp_reordering=127.

Configurar o valor para 127 desativa efetivamente a retransmissão completamente. As desvantagens são custo de CPU aumentado do TCP e as conexões TCP geralmente ficarão em estado congestionado.

Rendimento

O teste de rendimento é um teste simples com um operador definido pelo usuário em uma máquina enviando tuplas para um operador de recepção em uma máquina diferente. O operador de recepção simplesmente conta as tuplas de recebidas. Além da contagem, armazena o registro de data e hora atual quando a primeira e a última tuplas são recebidas. Determinar a diferença entre o primeiro e o último registro de data e hora resulta na duração do intervalo de tempo tomado para receber todas as tuplas.

Rendimento = (Número de tuplas) / (duração do intervalo de tempo tomado para receber as tuplas)

A IBM obteve os resultados a seguir usando configuração de transporte TCP.

Figura 2. Rendimento do InfoSphere Streams para transporte TCP
Rendimento do InfoSphere Streams para transporte TCP

O mesmo teste foi executado com os aplicativos InfoSphere Streams configurados para utilizar transporte LLMRUM sobre TCP.

Figura 3. Rendimento do InfoSphere Streams com transporte LLMRUMTCP
Rendimento do InfoSphere Streams com transporte LLMRUMTCP

Conforme indicado pelo gráfico anterior, o rendimento aumentou em aproximadamente 60 por cento utilizando TCP. O rendimento utilizando LLMRUM sobre TCP aumentou quase 40 por cento. O rendimento é inferior com LLM porque o planejamento do próprio LMM pode estar interferindo com o planejamento do TCP do tráfego para as duas NICs.

Resultados de latência

O teste de latência mede a latência de roundtrip usando um operador de origem e um de dissipação na mesma máquina e um operador de functor em uma máquina diferente que meramente passa para o operador de dissipação as tuplas enviadas a ele a partir do operador de origem. A latência é calculada usando a hora que a tupla é recebida pelo operador de dissipação menos a hora que a tupla deixou o operador de origem. A diferença entre esses horários é precisa, pois é utilizado o relógio da mesma máquina para as duas leituras, eliminando, portanto, qualquer clock skew relativo.

Latência de Roundtrip = (horário de término da tupla — horário de início da tupla na mesma máquina)

A IBM obteve os resultados de latência a seguir durante testes ao enviar a uma taxa aproximada de 5.000 tuplas por segundo.

Figura 4. Latência do InfoSphere Streams usando transporte TCP
Latência do InfoSphere Streams usando transporte TCP
Figura 5. Latência do InfoSphere Streams usando transporte LLMRUMTCP
Latência do InfoSphere Streams usando transporte LLMRUMTCP

Conforme indicado pelos gráficos, a ligação por canal apresenta pouco impacto sobre a latência com tamanhos menores de tupla. Com tamanhos maiores de tupla, a latência aumenta, possivelmente devido à retransmissão de pacote fora de serviço.


Conclusão

Conforme indicado pelos experimentos acima, os principais fatores que parecem afetar o desempenho são o tamanho da tupla e a configuração de transporte. No entanto, em muitas circunstâncias, a ligação por canal pode ser uma ferramenta útil para aumentar o rendimento de aplicativos no IBM InfoSphere Streams.

Recursos

Aprender

Obter produtos e tecnologias

  • Crie seu próximo projeto de desenvolvimento com o Versão de teste do software IBM, disponível para download diretamente no developerWorks.
  • Agora é possível usar o DB2 gratuitamente. Faça o download do O DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Information Management
ArticleID=831965
ArticleTitle=Impulsione o Desempenho do IBM InfoSphere Streams com a Ligação de Canais Linux
publish-date=08312012