Há uma limitação para os servidores zSeries e S/390 que compartilham a placa OSA, porque esse adaptador opera de maneira diferente do que a maioria das placas de rede. A placa OSA possui sua própria implementação de camada de linbk virtual, que não tem nada a ver com a placa ethernet, que é apresentada para os hosts do Linux e z/OS por trás dele. De modo efetivo, cada placa OSA é semelhante aos hosts ethernet-para-ethernet (e não para os hosts OSA), e os hosts que a usam responderão como se fossem ethernet.
A placa OSA também executa algumas funções que são relacionadas diretamente à camada IP. Responder aos pedidos de protocolo de resolução de endereço (ARP) é um exemplo de uma função que ela executa. Outro exemplo são os pacotes de IP de rotas OSA compartilhadas com base no endereço IP de destino, em vez de endereço ethernet como um comutador de 2 camadas. Efetivamente, a placa OSA é um segmento de rede em ponte por si só.
O Load Balancer que é executado em um host S/390 Linux ou zSeries pode ser encaminhado para os hosts no mesmo OSA ou para os hosts no ethernet. Todos os hosts no mesmo OSA compartilhado estão efetivamente no mesmo segmento.
O Load Balancer pode encaminhar um OSA compartilhado devido à natureza da ponte OSA. A ponte conhece a porta OSA que possui o IP de cluster. A ponte conhece o endereço MAC dos hosts diretamente conectados com o segmento ethernet. Portanto, o Load Balancer pode encaminhar o MAC entre uma ponte OSA.
Entretanto, o Load Balancer não pode encaminhar para um OSA compartilhado. Isso inclui o Load Balancer em um S/390 Linux quando o servidor de backend estiver em uma placa OSA diferente do Load Balancer. O OSA para o servidor de backend divulga o endereço OSA MAC para o IP do servidor, mas quando um pacote chega com o endereço de destino ethernet do OSA e o IP do servidor do cluster, a placa OSA do servidor não sabe quais dos seus hosts, se houver, devem receber esse pacote. Os mesmos princípios que permitem que o encaminhamento MAC OSA para ethernet funcione para um OSA compartilhado não são mantidos quando tentar encaminhar para um OSA compartilhado.
Solução Alternativa:
Se os servidores na configuração do Load Balancer estiverem no mesmo tipo de plataforma zSeries ou S/390, você poderá definir conexões ponto a ponto (CTC ou IUCV) entre o Load Balancer e cada servidor. Configure os terminais com endereços IP privados. A conexão ponto a ponto é usada apenas para o tráfego Load Balancer para servidor. Em seguida, inclua servidores com o endereço IP do terminal do servidor do túnel. Com essa configuração, o tráfego de cluster é proveniente da placa OSA do Load Balancer e é encaminhado entre a conexão ponto a ponto onde o servidor responde por meio de sua própria rota padrão. A resposta usa a placa OSA do servidor para sair, o que pode estar ou não na mesma placa.
Se os servidores na configuração do Load Balancer não estiverem no mesmo tipo de plataforma zSeries ou S/390, ou se não for possível definir uma conexão ponto a ponto entre o Load Balancer e cada servidor, é recomendado usar o recurso de encapsulação do Load Balancer, que é um protocolo que permite que o Load Balancer seja encaminhado entre os roteadores.
Quando usar a encapsulação, o pacote IP cliente->cluster é recebido pelo Load Balancer, encapsulado e enviado para o servidor. No servidor, o pacote de IP cliente->cluster original é encapsulado e o servidor responde diretamente para o cliente. A vantagem de usar o GRE é que o Load Balancer vê apenas o tráfego cliente para servidor, e não o tráfego servidor para cliente. A desvantagem é que ele diminui o tamanho de segmento máximo (MSS) da conexão TCP devido à sobrecarga de encapsulação.
Consulte o tópico Usar o Encaminhamento de Encapsulação para Encaminhar o Tráfego Entre os Segmentos de Rede para obter mais informações sobre como configurar o Load Balancer para encaminhar com a encapsulação.