LVS-mini-HOWTO

Os servidores reais rodam normalmente em redes privativas (ex 192.168.1.0/24) Eles não possuem contato direto com os clientes, em alguns casos os servidores reais são máquinas (na rede local) muitas vezes usadas para outras coisas, que neste caso as deixa na rede original (pública).

O direcionador é contactado pelo(s) cliente(s) no IPV. Se o IPV precisa estar disponível publicamente (A configuração mais comum), então eles deverão estar numa rede diferente dos servidores reais, e neste caso você terá duas redes LVS. o IPV estará numa rede que que conecte o direcionador ao roteador (ou cliente de teste), se os clientes estiverem na mesma rede dos servidores reais então você terá apenas uma rede LVS.

O número de redes não tem relação com o número de placas de rede. Uma única placa de rede pode ter vários IPs e pode estar é várias redes diferentes. Você pode ter uma placa de rede no direcionador com duas redes LVS.

	Nota
	o IPV está normalmente no dispositivo de rede (ex eth0). Porém dec (arroba) rm-f (ponto) net 01 Jun 2002 colocou na lo e o LVS funcionou muito bem.

Para uma configuração inicial, você precisa apenas de 1 placa de rede no direcionador. Com 2 placas de rede no direcionador você poderá separar os pacotes que são de fora dos que são de dentro, de maneira simples, com regras de filtragem e segurança. Placas de rede de 100Mbps são baratas para a produção, você pode ter tantas placas de rede quanto derem em sua placa mãe (Existem ainda placas de rede duplas e até quadruplas), eu usei uma D-link quad tulip no meu direcionador. O volume de pacotes será limitado pelo barramento PCI e pela pilha TCP/IP (em 2000 as placas mãe serão de 400Mhz) - ex. 4 Placas de rede. O direcionador poderá ter uma placa para cada servidor real uma vez que ela não esteja operando em toda a velocidade. Aumentando o número de placas de rede irá aumentar o desempenho até que haja um limite de taxas, como a velociade da CPU ou do barramento PCI.

O script de configuração irá manipular 1 ou 2 placas de rede no direcionador. No caso de 1 placa de rede, ela se conecta tanto ao lado de fora quando ao lado interno da rede dos servidores reais. No caso de 2 placas de rede, as duas redes estarão fisicamente separadas, uma conectada ao mundo de fora e outra conectada a rede dos servidores reais.

Para o direcionador, você precisa de um kernel padrão, obtenha a partir do site ftp do Kernel. Para os linux 2.4.x, você precisará instalar o patch "hidden" ou "oculto"; (Que somente foi testado com o mesmo kernel padrão).

Note

O Kernel que vem na sua distribuição é normalmente marcado com uma versão superior ou avançada, e provavelmente não funcionará a instalação do Patch para o LVS. O Kernel do RedHat já possui o patch do LVS pré aplicado, com uma versão certamente mais antiga em relação a atual lançada no site do LVS. O SuSE (Maio 2003) está fazendo a mesma coisa. Se você fizer o LVS funcionar com o kernel padrão e não com o que vem na sua distribuição, então nós saberemos onde o problema está, mas será melhor se você entrasse em contato com a sua distribuição - eles precisam de um retorno seu, não nós. Se você estiver realmente interessado em fazer o kernel da sua distribuição funcionar com o LVS, você poderá tentar novamente após faze-lo funcionar com o kernel padrão.

	Nota
	Os kernels 2.4.23 e superiores já possuem o código do ipvs internamente. Você não precisa aplicar o patch neles.

Vá para o link de Programas na Homepage do LVS. Obtenha o último pacote tar para o Direcionador (disponíveis para 2.2.x, 2.4.x, e 2.5.x). Ele contém o patch do Kernel e o código fonte para outros programas e utilitários.

Você deverá aplicar o patch no kernel padrão que combine com o patch do ip_vs, recompile o kernel, reinicie e compile os programas de nível de usuário. ipvsadm.

O Direcionador opera em um (ou vários) métodos de encaminhamento; LVS-NAT (network address translation | Tradução de Endereços de Rede); LVS-DR (direct routing | Roteamento Direto) e LVS-tun (Tunelamento). O método de encaminhamento é especificado para cada servidor-real/serviço através das ferramentas do usuárioipvsadm disponíveis no site do LVS.

O código do Direcionador foi muito bem testado em computadores Intel. Mas várias pessoas rodam o Linux em computadores Alpha. Espera-se que o LVS rode em qualquer computador que rode o Linux.

O Servidor-Real deve ser configurado adequadamente de acordo com o método de encaminhamento do LVS. para fazer isto você precisa:

Para resolver o problema do ARP para o LVS-DR/LVS-tun, servidores-reais com o Linux e kernel 2.2.x/2.4.x precisam ter o patch "hidden" aplicado (patch disponível em Na página de Patches e Programas do Julian). Para kernels 2.2.x, o patch já está no kernel padrão (ex já está pré-aplicado para você). Para kernels 2.4.x você mesmo terá que aplicá-lo manualmente. A partir de 2001, ambos os patchs "hidden" e "ipvs" já podem ser aplicados simultaneamente ao Kernel, permitindo a você usar o mesmo kernel para o Direcionador e para o Servidor-Real. A parte do Kernel onde tem o patch aplicado não se altera muito em relação as outras versões, assim, o patch "hiddem against 2.4.5" também funcionará para a versão 2.4.19pre4.

Nota

O patch hidden é apenas um dos métodos para resolver o problema do arp. (Este é o método mais antigo em uso e por isso é o mais conhecido pelas pessoas que vem usando o LVS já por um bom tempo. Outros métodos ex. Módulo Noarp de Maurizio Sartori. (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#sartori) e Filtragem de Arp do Julian. (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#arp_filtering) também estão disponíveis.

Esta é uma lista dos sistemas operacionais que foram testados com os métodos de encaminhamento. (Nós acreditamos que todos os sistemas operacionais deverão funcionar de alguma forma)

A forma mais comum de resolver o problema do ARP é escondendo o IPV das requisições arp.

O exemplo abaixo mostrará como resolver o problema do ARP. Todos os métodos para resolver este problema funcionam e possuem a mesma performance (throughput e latência) e são igualmente fáceis ou difíceis de configurar.

O método "hidden" para esconder os dispositivos das requisições de arp é considerado o método padrão para solucionar o problema e é o mais cmomumente usado nos servidores-reais Linux.

Para Kernels anteriores (2.0.x e até o mais recente dos 2.2.x kernels), outro método simples é colocar uma placa de rede extra no servidor-real para o IPV e não conectar esta placa em nenhuma rede. A placa de rede não manipulará nenhum pacote, ela servirá apenas como um meio de colocar o IPV no servidor-real. A placa de rede pode ser até mesmo a mais antiga modelo ISA, e uma placa PCI tulip custa bem menos do que você pagaria para alguém recompilar o Kernel com o patch hidden para você. (Nota, 2002: - isto não funciona para Kernels 2.4.x).

Horms 29 de Outubro de 2003

Se você estiver usando o LVS-DR então os pacotes que chegam ao servidor-real possuem o IP de destino definidos para o IPV. Então o servidor-real precisa de uma meio de aceitar este tráfego como local. Uma forma é adicionar uma interface no dispositivo de loopback e esconde-la, assim ela não responderá as requisições ARP.

A máscara deve ser 255.255.255.255 porque a interface de loopback irá responder aos pacotes para _todos_ os hosts em qualquer interface configurada. Assim 192.168.1.110 com máscara de rede 255.255.255.0 fará com que a máquina aceite pacotes de _todos_ os endereços na faixa 192.168.1.0 - 192.168.1.255, o que na verdade não é o que você quer.

Gregory Boehnlein

Eu estou indo trabalhar com um grupo de máquinas com Solaris 9 num futuro próximo , e eu gostaria de adicioná-los ao meu já existente LVS Cluster. Alguém possui alguma informação sobre O que/Como o Solaris poderá ser usado como um Servidor_Real num Cluster LVS-DR? No Linux eu implementei o patch Hidden-arp. Como isto pode ser resolvido no Solaris?

Roberto Nibali ratz (arroba) drugphish (ponto) ch 11 Aug 2003

O Solaris não possui este problema ;-).

ifconfig lo0:1 <IPV> netmask 255.255.255.255 up

e é isto. Funcionará porque o Solaris não responde ao arp para dispositivos de loopback.

Aqui está a informação original do Ratz para servidores-reais que não usam o Linux.

#uname      : FreeBSD
#uname -r   : 3.2-RELEASE
#<command>  : ifconfig lo0 alias <IPV> netmask 0xffffffff -arp up
#ifconfig -a: lo0: flags=80c9<UP,LOOPBACK,RUNNING,NOARP,MULTICAST>mtu 16837
#                  inet 127.0.0.1 netmask 0xff000000
#                  inet <IPV> netmask 0xffffffff
#
#uname      : IRIX
#uname -r   : 6.5
#<command>  : ifconfig lo0 alias <IPV> netmask 0xffffffff -arp up
#ifconfig -a: lo0: flags=18c9<UP,LOOPBACK,RUNNING,NOARP,MULTICAST,CKSUM>
#                  inet 127.0.0.1 netmask 0xff000000
#                  inet <IPV> netmask 0xffffffff
#
#uname      : SunOS
#uname -r   : 5.7
#<command>  : ifconfig lo0:1 <IPV> netmask 255.255.255.255 up
#ifconfig -a: lo0:  flags=849<UP,LOOPBACK,RUNNING,MULTICAST>mtu 8232
#                   inet 127.0.0.1 netmask ff000000
#             lo0:1 flags=849<UP,LOOPBACK,RUNNING,MULTICAST>mtu 8232
#                   inet <IPV> netmask ffffffff
#
#Atenção: O HP-UX responde as requisições arp para IPs na lo mesmo com -arp.
#(ex assim como no Linux).
#Você terá que colocar o servidor-real HP-UX numa rede diferente (Método do Lars)
#
#uname      : HP-UX
#uname -r   : B.11.00
#<command>  : ifconfig lan1:1 10.10.10.10 netmask 0xffffff00 -arp up
#ifconfig -a: lan0:   flags=842<BROADCAST,RUNNING,MULTICAST>
#                     inet <some IP> netmask ffffff00
#             lan0:1: flags=8c2<BROADCAST,RUNNING,NOARP,MULTICAST>
#                     inet <IPV> netmask ffffff00
#

Chris Kennedy ckennedy (arroba) iland (ponto) net

Uma coisa que eu encontrei por fora é que no Solaris 2.6, e provavelmente em outras versões dele, você tem que fazer alguma mágica para configurar o alias do loopback. Você deve rodar os seguintes comandos, um de cada vez:

ifconfig lo0:1 <IPV> ifconfig lo0:1 <IPV> <IPV> ifconfig lo0:1 netmask 255.255.255.255 ifconfig lo0:1 up

Que funciona bem e é atualmente parecido com uma conexão ponto-a-ponto ppp Que deve ser a maineira que o Solaris usa fazer um alias para a interface lo. Isto não fará com que você faça tudo de uma vez, apenas um passo por vez ou você terá que fazer todo o procedimento de inicialização da interface.

Ramon Kagan rkagan (arroba) YorkU (ponto) ca 05 Jun 2002

Apenas para quem estiver interessado. Você pode fazer o seguinte com a lo0:1 ou para paranóicos como eu hmel.

ifconfig <intfc> plumb ifconfig <intfc> <IPV> ifconfig <intfc> <IPV> <IPV> ifconfig <intfc> netmask 255.255.255.255 ifconfig <intfc> up

Isto é da FAQ, mas eu quero adicionar que isto não precisa ser na lo0.

A única forma é compilando um novo Kernel, reiniciar, então compilar e instalar a versão do ipvsadm que combine com o novo kernel, assim como se você estivesse começando uma instalação do zero. Você não pode fazer uma atualização em plena atividade, para isso você deve desativar o Direcionador.

Eu uso o script rc.system_map (que vem com o script de configuração) para ter certeza de que eu estou com as corretas versões dos arquivos do ipvsadm, Kernel e System.map trabalhando juntos, quando eu estiver testando várias versões do LVS. (ex.uma versão 2.2 e uma 2.4).

O repositório CVS do IPVS está disponível em

cvs -d :pserver:anonymous@cvs.linuxvirtualserver.org:/home/lvscvsroot login
(type anything for the password of user anonymous)
cvs -d :pserver:anonymous@cvs.linuxvirtualserver.org:/home/lvscvsroot co ipvs

Malcolm Turnbull Malcolm (ponto) Turnbull (aroba) crocus (ponto) co (ponto) uk 03 Jun 2003, fez uma edição bootável pelo CD do seu swoftware de balanceamento de carga do loadbalancer.org O link está em http://www.loadbalancer.org/modules.php?name=Downloads&d_op=viewdownload&cid=2 mas atualmente está fora (Dec 2003).

Aqui está um blurb do Malcolm

A idéia básica é criar uma aplicação de switch da camada 4 que fosse fácil de usar para competir com o Coyote Point Equalizer / CISCO local director ... Todo o meu código fonte está no GPL, mas a distribuição pela imagem ISO contém arquivos que não estã na GPL para proteger o trabalho e permitir que vendedores licenciem o programa. A imagem ISO requer uma licença antes de você usá-la legalmente em produção.

Queime o CD com a imagem e use-a para iniciar um servidor sobressalente com pentium/celeron + CDROM ATAPI + 64MB de RAM + 1 ou 2 Placas de Rede e HD de 20GB.

A senha de root é : loadbalancer O endereço IP é : 10.0.0.21/255.255.0.0 O login da interface web é : loadbalancer A senha da interface web é : loadbalancer

A configuração padrão é a DR (Roteamento Direto) então basta plugá-la na mesma linha do seu HUB como o seu servidor web e comece a fazer uso. Baixe os manuais para obter informações de configuração ...

Você pode configurar o LVS manualmente com o ipvsadm. Isto leva muitas vezes ao tédio e a condições de erro. Enquanto for viável de fazer para um simples LVS este não é o caminho para configurar vários LVS de configurações diferentes.

O script de configuração está na página de programas do LVS (no rodapé). Ele somente configura um direcionador simples e não manipula falhas no direcionador (Uso de Direcionadores de Backup). Para sistemas de produção você provavelmente precisará usar um que faça a manipulação das falhas do direcionador. Algumas pessoas já configuraram dois direcionadores através do Linux-HA (Alta Disponibilidade) usando o script de configuração, mas eu não tenho como mensionar detalhes de como elas fizeram isto.

O script de configuração foi desenvolvido para configurar um LVS rapidamente, assim eu pude fazer testes. A versão atual (0.9.x) faz um grande número de checagens, encontrando todos os erros que deliberadamente e patologicamente eu venho encontrando nos últimos 2 anos. Checagens elementares são feitas no roteamento e conectividade e o script tem produzido LVS funcionando quando nehum erro é encontrado.

	Nota
	O script de configuração testa e usa os links entre todas as máquinas - a rede já deve estar funcionando antecipadamente. Você já deve estar habilitado a pingar todas as máquinas da mesma rede. Você precisará estar com as placas de rede configuradas com todos os IPRs, e IPS e PIP (para versões 0.10.x e mais antigas) ou IPD (0.9.x e mais novas).

O script de configuração lê um arquivo conf e configura o LVS-DR, LVS-NAT, LVS-Tun, com máquinas de uma ou mais placas de rede usando dispositivos de rede normais ou através dos pacotes aceitos por um proxy transparente. A saída é um arquivo rc.lvs e rc.mon bem comentados para rodar no boot da máquina. (ou quando você estiver configurando um LVS).

O script de configuração detecta a versão do Kernel do direcionador (para versões antigas de kernels/ipvs) e rodará no direcionador para produzir os arquivos rc.lvs. O arquivo rc.lvs rodará no direcionador e nos servidores-reais. Isto permitirá que o script rc.lvs verifique as conexões com o agora configurado direcionador.

Eu tenho os arquivos/diretórios de configuração nas exportações NFS para os servidores-reais. Após rodar o script rc.lvs no direcionador, eu posso rodar o mesmo rc.lvs nos servidores-reais. (Após a configuração, as conexões de rede necessárias para as exportações dos diretórios podem ser removidas) Alternativamente o script de configuração pode copiar e executar o arquivo rc.lvs usando o ssh com a opção "-i" (para verificar se isto funciona execute `ssh servidor-real nome_do_host` - você deve voltar atras o nome do servidor-real). O arquivo rc.lvs sabe se ele está rodando num direcionador ou num servidor-real observando o IP da máquina e fazendo a comparação com o definido no arquivo de configuração.

O script rc.lvs é verboso e mostra todo o seu progresso. Ele procura por qualquer tipo e caso encontre ele o mensionará. ex.- Você poderá rodar o script quantas vezes queira na mesma máquina. Você pode copiar o script rc.lvs do direcionador para o servidor-real. Eu tenho o arquivo de configuração do direcionador localizado no diretório /etc/lvs (mas eles podem ficar em qualquer lugar) O diretório das exportação NFS podem ser os mesmos para todos os servidores-reais. Desta maneira o script rc.lvs pode ser executado por todos os servidores-reais. Num sistema de produção você deve desmontar os diretórios NFS após a execução do script e o término da configuração. Alternativamente, se você executar com a opção "-i" (instalação), o script de configuração usará o ssh para copiar os arquivos de saída para o servidor real e executará o script a partir do servidor real.

O script de configuração foi testado com direcionadores usando kernels 2.2 e 2.4. Ele alertará caso encontre versões de kernel mais antigas das que ele sabe a respeito. Estes alertas podem ser usualmente ignorados pois não se espera que o ipvs altere as suas configurações.

O arquivo de configuração e o script podem usar tanto IPs ou nomes-de-host (a partir do arquivo /etc/hosts) e podem usar tanto números de porta (ex 23) ou nomes do serviço (ex telnet) (a partir de /etc/services). Pode ser necessário fazer adições ao seu arquivo /etc/services como abaixo

ftp-data        20/tcp
ssh             22/tcp
domain          53/tcp  nameserver      dns #the string "dns" needs to be added here
domain          53/ucp  nameserver      dns #and here
shell           514/tcp cmd             rsh #add rsh here
https           443/tcp
https           443/udp
printer         515/tcp spooler         lpd #add the string "lpd" here
nfs             2049/udp        nfs
mysql           3306/tcp
mysql           3306/udp
netpipe         5002/tcp

Para muitas instãncias, uma máquina precisará de múltiplos IPs. Você pode colocar vários IPs numa mesma placa de rede usando o alias de IP (uma opção existente na configuração do kernel) - apenas entre com a interface virtual (ex. eth0:12) para cada IP no arquivo *.conf. (Nota: versões do script de configuração a partir de 0.10.x em diante moverão para a ferramenta iproute2 e não usarão os aliases `ifconfig` e `netstat -rn` não funcionarão para a configuração da rede pela feramenta iproute2 - Você deverá usar apenas as ferramentas do iproute2)

A documentação do script de configuração está no formato perldoc (acima de v0.9, versões mais antigas ainda estão no formato xmt/html).

director:/etc/lvs:$ perldoc configure.pl

O script é em perl e requer módulos perl não necessários nesta demonstração. No entanto, o script não rodará sem eles, portanto verifique se você possui os módulos requeridos executando

$perl -w configure.pl

Se algum módulo estiver faltando (ex DNS.pm) você terá uma mensagem de erro como esta

direcionador:/etc/lvs# ./configure lvs_dr.conf.IP.two_NIC_two_network -i
Can't locate Net/DNS.pm in @INC (@INC contains: /usr/local/lib/perl5/5.6.0/i586-linux /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/i586-linux /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl .) at ./configure line 1365.
BEGIN failed--compilation aborted at ./configure line 1365.

Obtenha os módulos extras através do site da perl ou pegue diretamente usando o módulo CPAN, que você pode fazer da seguinte maneira

direcionador:# cpan
ou
direcionador:# perl -MCPAN -e "shell"

Você receberá um prompt do cpan. Ajuda, você obterá digitando "help" no prompt do cpan, é segredo. Para terminar o cpan, tente o comando `r`, que listará os módulos mais recentes disponíveis para os que já estão instalados. Você poderá instalar o módulo Net::DNS da seguinte forma

cpan> install Net::DNS

Se a instalação de um módulo tiver dependências, você será informado para baixar as mesmas.

O script rc.lvs usa fping para testar as conexões fping está disponível em

ftp://ftp.kernel.org/pub/software/admin/mon

As versões mais recentes do ping já possuem a funcionabilidade do fping e a atual versão do script de configuração testará esta nova funcionabilidade. Para versões mais antigas do script de configuração, caso você não queira baixar o fping, você poderá usar este script ao invés do fping (coloque ele em /usr/local/bin e fáça-o executável).

#!/bin/sh
#fping replacement

ping -c 1 $1
#-----fping-------------

Obtenha um modelo apropriado do arquivo de configuração(lvs_nat.conf, lvs_tun.conf ou lvs_dr.conf) de acordo com o modo de operação do LVS (VS-NAT, LVS-Tun ou LVS-DR respectivamente) e edite os IPs e serviços de acordo com a sua situação ou planejamento. Há modelos de arquivos de configuração para vários tipos de encaminhamento, números de redes e números de placas de rede. O formato do arquivo de configuração é o mesmo para todas as configurações de LVS - apenas os IPs e Redes são alterados quando você altera de um direcionador de 1 ou 2 placas de rede. São disponibilizados vários exemplos de arquivos de configuração mas somente o diagrama da rede é que muda (e os destinos do gateway padrão), não o formato das diretivas do arquivo. Os arquivos vem pré-configurados para telnet como serviço. Este é o serviço mais simples para testes iniciais: O serviço é facilmente disponibilizado e no seu teste você saberá em qual servidor conectou. Use o agendamento de round robin, assim, você se conectará a cada servidor de forma rotacionada, confirmando que tudo está funcionando adequadamente.

Outros serviços podem ser adicionados apenas descomentando/adicionando ou editando as entradas no arquivo de exemplo *.conf. O arquivo *.conf traz sugestões de IP como (192.168.1.x/24, 10.1.1.x/24) para as várias máquinas.

execute o script de configuração

$ ./configure.pl lvs_nat.conf

Isto produzirá um script chamado rc.lvs_xxx (ex rc.lvs_nat, rc.lvs_tun, rc.lvs_dr), e um script mon_xxx.cf. (Após fazer seus testes, coloque o script rc.lvs_xxx dentro de /etc/rc.d ou /etc/init.d e coloque o mon_xxx.cf dentro de /etc/mon)

Execute o script rc.lvs no direcionador e nos servidores-reais com o comando

$ . ./rc.lvs_dr

ou possivelmente (caso você tenha mensagens de erro, ex. it doesn't detect correctly whether it's running on a director or a realserver - isto aconteceu no meu servidor-real cuja versão era 2.0.36)

$sh rc.lvs_dr

O script rc.lvs -

O script rc.lvs não -

Verifique as saídas do ipvsadm, ifconfig -a e netstat -rn no direcionador e no servidor-real, para ver se os serviços/IPs estão todos corretos. Caso tenha algo de errado re-edite e re-execute os scripts.

Telnet é um serviço não persistente (no senso the http, assim como no senso LVS) e permitirá verificar se todos os servidores-reais estão presentes (você reberá a mensagem de login de cada um a cada conexão).

Verifique se o(s) serviço(s) estão rodando em cada servidor no IPV (use o netstat -an). Alguns serviços (ex. telnet ficam escutando no endereço 0.0.0.0, que representa todos os IPs disponíveis na máquina).

Caso não tenha nenhum erro ao executar o script rc.lvs_xxx, então faça um telnet de um cliente para o IPV (aqui 192.168.1.110). Você será roteado para um dos servidores-reais e será apresentado o prompt de login (e o nome do servidor-real).

No direcionador, observer a saída do ipvsadm, você verá uma conexão para um servidor-real na porta:23.

No servidor-real faça o seguinte:

$ netstat -an | grep 23

e procure por conexões na porta do telnet.

Dê Logout e faça telnet novamente no IPV. Você terá o prompt de login dos outros servidores-reais.

Edite o arquivo lvs_nat.conf para ativar o serviço http, re-execute o configure.pl e re-execute os novos arquivos do rc.lvs_nat.

http: Aponte o seu navegador para o IPV http://192.168.1.110. Você terá do Documento Raiz de um dos servidores-reais. Abra outra cópia do Navegador e conecte novamente. Você estará agora se conectando ao outro servidor. (Será fácil de identificar caso as páginas sejam diferentes). Ovserve a saída do ipvsadm no direcionador e procure por conexões na porta http, e no servidor veja a saída do netstat -an | grep 80 (ou 8080 caso você esteja usando o LVS-NAT e tenha remapeado as portas) para conexões.

Caso o seu httpd seja persistente (é o normal do http), você irá/ou não conectar no mesmo servidor a cada vez.

cliente:     	Endereço IP do Cliente	=IPC
gateway:     	IP do gateway/roteador	=GWD (o roteador será o cliente na maioria das configurações)
direcionador:	IP do direcionador      =IPD no direcionador   eth0
             	IP Virtual	        =IPV no direcionador   eth0:x (eg eth0:1)
servidor-real:  IP do Servidor-Real     =IPR no servidor-real  eth0
             	IP Virtual	        =IPV no servidor-real  eth0:x/lo:0/tunl0/dummy0
             	gateway             	=GWS

	Nota
	o IPD e o IPV devem ter IPs diferentes (mas podem estar na mesma placa de rede).

	Nota
	O IPD e o IPV serão movidos para outro direcionador na falha de outro direcionador. Estes IPs serão configurados como secundários (aliases na antiga linguagem dos kernels 2.0 e 2.2) assim, mais tarde você poderá usar o direcionador que falhou. O scrip de configuração define estes IPs para você (ex. você não deverá ter o IPV assim como o IPD como primários em suas placas de rede do direcionador).

Julian Anastasov ja (arroba) ssi (ponto) bg 06 Nov 2001

Se IPD==IPV o servidor-real receberá pacotes com saddr=local_ip (IPV) do direcionador. (Este é o problema do "source martian".) Você tem que colocar IPs adicionais (IPD) no seu direcionador e quando executar o ip route get x.y.z.230 você verá que x.y.z.180 não é a sua origem preferida. A forma normal de conseguir isto é configurando um IPV em outro dispositivo (como lo) ou configurar eles após o IPD estiver configurado. Desta maneira o IPD achará o melhor caminho quando estiver falando com a sua rede.

Adicionar IPD não é obrigatório para que qualquer LVS funcione mas você não será capaz de gerar tráfego não-LVS entre o direcionador e os servidores-reais (ping no seu caso).

Chris chrisd (arroba) better-investing (ponto) org 15 Apr 2002

1. Eu baixei o kernel do kernel.org.
2. Eu baixei o pacth d ipvs (um patch simples)
3. Eu baixei o hidden patch.
4. Eu descompactei o source do kernel em /usr/src
5. Eu descompactei o patch hidden em /root
6. Eu descompactei os arquivos do ipvs.
7. Eu copiei o arquivos do patch hidden para /usr/src/linux
8. Eu executei: patch -p1 <hidden-2.4.5-1.diff
9. Eu copiei o patch do ipvs para /usr/src/linux
10. Eu executei: patch -p1 <linux-2.4.18-ipvs-1.0.2.patch
11. Eu dei um make menuconfig, e configurei o Kernel
12. Eu dei exatamente os mesmos passos que você deu para compilá-lo:

    make dep;make clean;make bzImage;make modules;make modules_install

E não pulei nenhuma linha.

Coisas para seren pensadas:

• Não aplicar o patch mais de uma vez!
• Caso ele não funcione com estes passos e você tenha o RH 7.2, esteja certo de possuir todos os pacotes gcc instalados. Caso precise, coloque o CD na máquina e instale ou atualize os pacotes necessários.
• Se mesmo assim não funcionar, esteja certo que o seu gcc está atualizado. Uma boa maneira de se fazer isto é fazendo o download do red-carpet do Ximian.org. Ele é um popular atualizador para Xwindows. Você não precisa do gnome para executar este programa. (Nunca mais).
• Caso ele não funcione, consiga um guru *real*, afinal, eu não sei mais o que pode ser!

As instruções atuais para compilação do kernel variam de acordo com as versões. Você pode compilar o ip_vs diretamente dentro do kernel ou como um módulo carregável - ambas as formas irão funcionar normalmente para uma configuração inicial.

Você precisa habilitar o "Prompt for developmental code... " na seção "Code Maturity". Na seção "Networking" você deverá habilitar o IP:masquerading antes de ver as opções do ipvs

Algumas das opções de compilação do kernel abaixo não são explicitamente necessárias para funcionar com o LVS, mas você poderá necessitar delas - ex ip aliasing caso você queira fazer um direcionado com apenas uma placa de rede, ou tunneling caso você queira fazer uma LVS-Tun, a não ser que você saiba exatamente o que está fazendo, habilite todas estas opções com um '*' no início de cada linha. As opções de configuração do kernel abaixo são exlusivamente para o LVS. Certamente você precisa configurar outras coisas (ex. filesystems, hardware...).

As instruções atuais de compilação do kernel irão variar de acordo com o número do patch do kernel. Aqui está o que eu usei para ipvs-0.9.9 no kernel 2.2.15pre9 nas opções de rede.

           [*] Kernel/User netlink socket
           [*] Routing messages
   	< > Netlink device emulation
*          [*] Network firewalls
           [*] Socket Filtering
   	<*> Unix domain sockets
*          [*] TCP/IP networking
           [ ] IP: multicasting
*          [*] IP: advanced router
*          [*] IP: policy routing
           [ ] IP: equal cost multipath
           [ ] IP: use TOS value as routing key
           [ ] IP: verbose route monitoring
           [ ] IP: large routing tables
           [ ] IP: kernel level autoconfiguration
*          [*] IP: firewalling
           [ ] IP: firewall packet netlink device
*          [*] IP: use FWMARK value as routing key (NEW)
*          [*] IP: transparent proxy support
*          [*] IP: masquerading
           --- Protocol-specific masquerading support will be built as modules.
*          [*] IP: ICMP masquerading
           --- Protocol-specific masquerading support will be built as modules.
*          [*] IP: masquerading special modules support
*  	<M> IP: ipautofw masq support (EXPERIMENTAL)
*  	<M> IP: ipportfw masq support (EXPERIMENTAL)
*  	<M> IP: ip fwmark masq-forwarding support (EXPERIMENTAL)
*          [*] IP: masquerading virtual server support (EXPERIMENTAL)
*          (12) IP masquerading LVS table size (the Nth power of 2)
*  	<M> IPVS: round-robin scheduling
*  	<M> IPVS: weighted round-robin scheduling
*  	<M> IPVS: least-connection scheduling
*  	<M> IPVS: weighted least-connection scheduling
*          [*] IP: optimize as router not host
*  	<M> IP: tunneling
   	<M> IP: GRE tunnels over IP
           [*] IP: broadcast GRE over IP
           [ ] IP: multicast routing
           [*] IP: PIM-SM version 1 support
           [*] IP: PIM-SM version 2 support
*          [*] IP: aliasing support
           [ ] IP: ARP daemon support (EXPERIMENTAL)
*          [*] IP: TCP syncookie support (not enabled per default)
           --- (it is safe to leave these untouched)
   	< > IP: Reverse ARP
           [*] IP: Allow large windows (not recommended if <16Mb of memory)
   	< > The IPv6 protocol (EXPERIMENTAL)

Não altere o tamanho da tabela do IP masquerading LVS a menos que você saiba muito sobre como trabalha o ip_vs. Mas caso você tenha fortes motivos para alterar o tamanho da tabela, pelo menos dê uma lida neste HOWTO .

Faça todas as demais tarefas da compilaçãod do kernel, como "make modules", "make modules_install" e copie o novo kernel (e opcionalmente o System.map, requerido pelo Script de configuração.) para o diretório / ou /boot, e edite o seu carregador de inicialização (lilo ou grub). Esteja certo de manter o seu antigo kernel e suas configurações guardadas em local seguro por questões de segurança no caso de uma recuperação. Agora, reinicie a máquina com o seu novo kernel. Quando estiver carregando o novo kernel (com o ip_vs compilado como módulo), esteja certo de que os módulos ip_vs* estejam carregados. O arquivo README contido no diretório do kernel possui todas as informações que você precisa para aprender sobre os procedimentos de compilação e instalação de um novo kernel.

Os pacthes para versões anteriores ao Kernel 2.4.x foram configurados e instalados separadamente do "make menuconfig" para o kernel. Isto requeria que arquivos fossem movidos para os diretórios /lib/modules e carregados manualmente. Com as versões mais recentes do kernel, você pode obter um conjunto de arquivos onde os patches são colocados na árvore de diretório e configurados por make configure. O configurador poderá variar com diferentes patches do ip_vs Esteja certo de ter lido os documentos.

Nota

As instruções abaixo referen-se a versões mais recentes do kernel 2.4.x. Você pode esperar que ocorra alguma diferença pequena. Para o Kernel 2.4.18 (Simon Young simon-lvs (arroba) blackstar (ponto) co (ponto) uk, 1 Oct 2002) O IP Masquerading está em: Networking options ---> IP: Netfilter Configuration ---> <M> IP tables support (required for filtering/masq/NAT) <M> Full NAT <M> MASQUERADE target support Tudo referente ao LVS deve estar em: Networking options ---> IP: Virtual Server Configuration --->

Aqui está a configuração das opções de rede

	<*> Packet socket
	[ ] Packet socket: mmapped IO
	[*] Kernel/User netlink socket
	[*] Routing messages
	<*> Netlink device emulation
	[*] Network packet filtering (replaces ipchains)
	[*] Network packet filtering debugging
	[*] Socket Filtering
	<*> Unix domain sockets
	[*] TCP/IP networking
	[ ]   IP: multicasting
	[*]   IP: advanced router
	[*]     IP: policy routing
	[*]       IP: use netfilter MARK value as routing key
	[*]       IP: fast network address translation
	[*]     IP: equal cost multipath
	[*]     IP: use TOS value as routing key
	[*]     IP: verbose route monitoring
	[*]     IP: large routing tables
	[*]   IP: kernel level autoconfiguration
	[ ]     IP: BOOTP support
	[ ]     IP: RARP support
	<M>   IP: tunneling
	< >   IP: GRE tunnels over IP
	[ ]   IP: multicast routing
	[ ]   IP: ARP daemon support (EXPERIMENTAL)
	[ ]   IP: TCP Explicit Congestion Notification support
	[ ]   IP: TCP syncookie support (disabled per default)
	  IP: Netfilter Configuration  --->
	  IP: Virtual Server Configuration  --->
	< >   The IPv6 protocol (EXPERIMENTAL)
	< >   Kernel httpd acceleration (EXPERIMENTAL)
	[ ] Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)

Aqui está a minha configuração para o IP: Virtual Server configuration: (ative todas as opções)

	<M> virtual server support (EXPERIMENTAL)
	[*]   IP virtual server debugging (NEW)
	(12)   IPVS connection table size (the Nth power of 2) (NEW)
	--- IPVS scheduler
	<M>   round-robin scheduling (NEW)
	<M>   weighted round-robin scheduling (NEW)
	<M>   least-connection scheduling scheduling (NEW)
	<M>   weighted least-connection scheduling (NEW)
	<M>   locality-based least-connection scheduling (NEW)
	<M>   locality-based least-connection with replication scheduling (NEW)
	<M>   destination hashing scheduling (NEW)
	<M>   source hashing scheduling (NEW)
	--- IPVS application helper
	<M>   FTP protocol helper (NEW)

Não altere o tamanho da tabela (hash) da conexão IPVS a não ser que você tenha um bom conhecimento de como o ip_vs funciona. Caso você tenha fortes motivos para alterar o tamanho da tabela, pelo menos dê uma lida no HOWTO.

Aqui está o exemplo da minha configuração para o netfilter

	<M> Connection tracking (required for masq/NAT)
	<M>   FTP protocol support
	<M> Userspace queueing via NETLINK (EXPERIMENTAL)
	<M> IP tables support (required for filtering/masq/NAT)
	<M>   limit match support
	<M>   MAC address match support
	<M>   netfilter MARK match support
	<M>   Multiple port match support
	<M>   TOS match support
	<M>   Connection state match support
	<M>   Unclean match support (EXPERIMENTAL)
	<M>   Owner match support (EXPERIMENTAL)
	<M>   Packet filtering
	<M>     REJECT target support
	<M>     MIRROR target support (EXPERIMENTAL)
	<M>   Full NAT
	<M>     MASQUERADE target support
	<M>     REDIRECT target support
	<M>   Packet mangling
	<M>     TOS target support
	<M>     MARK target support
	<M>   LOG target support
	< > ipchains (2.2-style) support
	< > ipfwadm (2.0-style) support

	Nota
	Eu removi a opção do ipchains aqui. Isto foi definido como <M> nas versões anteriores do mini-HOWTO. Entretanto isto levantou alguns problemas para pessoas que não compreendiam os problemas de compatibilidade do ipchains

O ipchains nos kernels 2.2.x foram substituídos pelo iptables no kernel 2.4.x. Para os kernels 2.4.x, o ipchains ainda existe por uma questão de compatibilidade. Entretanto, o ipchains e iptables não podem ser usados ao mesmo tempo. Você nunca deve ativar o ipchains nos kernels 2.4.x. (2.4.x está em produção desde 1999).

O ipchains nos Kernels 2.4.x faz o conntrack ficar mais lento (Veja o HOWTO).

O módulo do ip_tables é imconpatível com o ipchains. Se ele estiver presente, o módulo do ip_tables deve ser descarregado para fazer com que o ipchains funcione.

Caso você esteja com o ip_tables carregado, você receberá uma série de mensagens de erro ao tentar executar comandos do ipchains no 2.4. Mesmo dizendo que existe a compatibilidade do ipchains no kernel 2.4, seria mais fácil informar que os comandos do ipchains estão disponíveis para que você possa re-escrever os seus scripts para o iptables e no caso de problemas você poderia até usar a compatibilidade por questões temporárias. Muitos outros programas ou scripts tentarão executar os comandos do ip_tables na sua máquina com o kernel 2.4, tenha isso em mente caso queira manter o ipchains.

Faça todas as demais tarefas do Kernel - make modules, copie o novo kernel para o diretório / ou /boot (Dê um nome diferente para o seu novo Kernel ex bzImage-0.9.4-2.4.12), edite o lilo.conf e re-execute o lilo. Mantenha as informações do seu antigo kernel no seu lilo.conf, assim você poderá recorrer em caso de problemas. Agora, reinicie a máquina com o seu novo Kernel.

Reinicie com o novo Kernel e verifique se o diretório /usr/src/linux está apontando para a atual árvore de diretórios do código fonte do kernel (Você pode usar o rc.Sysmap, que acompanha o Script de configuração), antes de compilar o ipvs (caso você esteja fazendo separadamente) e o ipvsadm.

Não esqueça de executar depmod -a após você instalar os módulos do ip_vs.

Você poderá opcionalmente compilar o ipvsadm com as biblicotecas do popt, Isto permite que o ipvsadm manipule argumentos mais complicados na linha de comando. Caso a sua biblioteca libpopt for muito antiga, o seu ipvsadm irá segv. A compilação padrão usa a linkagem estática, mas atualmente pode usar as bibliotecas dinâmicas. Caso você tenha problemas e erros tipo "POPT não encontrado", então você ainda não instalou o popt ou não possui a versão mais recente dele.

Torsten Buslei

Eu compilei e instalei um novo kernel (2.4.18 com o patch 2.4.19-pre8 e o linux-2.4.18-ipvs-1.0.2.patch.gz). Após o reboot (tudo parecia estar ok até aqui), compilando o ipvsadm (tanto o ipvs-1.0.2.tar.gz quanto o ipvsadm-1.20.tar.gz) Eu obtive as seguintes mensagens de erro:

ipvsadm.c:345: `POPT_ARGFLAG_OPTIONAL' undeclared (first use in this function)

Eu comentei uma parte do ipvsadm.c:345

{"persistent", 'p', POPT_ARG_STRING/*|POPT_ARGFLAG_OPTIONAL*/, &optarg, 'p'},

agora o ipvsadm compilou e está rodando normalmente. Há algum problema em fazer isto?

Horms horms (arroba) vergenet (ponto) net 05 May 2002

Parece que você tem uma versão do opot que não suporta argumentos opcionais (POPT_ARGFLAG_OPTIONAL). A sua correção estará correta, com o efeito lateral que você terá dando a opção -p/--persistent caso você a use.

Ramish Patel escreveu:

Eu estou usando o RedHat Linux 7.2 com kernel 2.4.7-10 e eu tentei aplicar inúmeros pacthes do LVS, apenas dois deles foram aplicados sem erros - eles vieram de ipvs-1.0.4.tar.gz, Que continham os dois pacthes aplicados com sucesso ao kernel, linux_kernel_ksyms.c.diff , linux_net_netsyms.c.diff .

Recompilei o kernel mais tarde. E continuo tendo mensagens de erro:

"Could not open the /proc/net/ip_masq/vs file Are you sure that the IP Virtual Server is supported by the kernel?"

Horms horms (arroba) verge (ponto) net (ponto) au 31 Jul 2002

Primeiramente, eu recomendo que você comece a partir de um novo kernel obtido no site www.kernel.org (como o 2.4.18) ao invés de usar o kernel da redHat, a não ser que você saiba exatamente o que e por que está fazendo isto. O ipvs-1.0.4 não funciona com o kernel que acompanha o RedHat 7.2 e vice-versa.

Entretanto, caso você insista em fazer isto, aqui está um guia útil.

Alex Kramarov escreveu instruções para compilar/atualizar o kernel da RedHat.

Para linux,

Caso você esteja trabalhando com o problema do arp escondendo o dispositivo IPV nos servidores reais, você precisará aplicar o patch nestes servidores se

As versões atuais do 2.2.x, ex. 2.2.19 já estão com o patch "hidden" aplicados ex. você não tem que aplicar o patch nos kernels 2.2.x atuais. Para Linux-2.0.x você pode usar a opção NOARP ao configurar o IPV no dispositivo.

Para Servidores Reais com Linux 2.4.x, aplique o patch "hidden" (obtenha-o no site da LVS na página de programas) ao seu kernel e proceda com a recompilação usando as opções tradicionais. Para o Kernel 2.4.4 -

servidor_real:/usr/src/linux# patch -p1 <../arch/hidden-2.4.4-1.diff

Esta é uma lista de servidores reais postada por Ratz. Lembre-se de definir a máscara de rede para /32 para o IPV nos LVS-DR e LVS-Tun (Para o LVS-NAT você pode colocar qualquer máscara). Caso você esteja rodando servidores reais UNIX que não sejam linux, você poderá resolver o problema do arp normalmente ao configurar o dispositivo do IPV com a opção -arp.

O código do Ratz para configurar os servidores reais não-linux está em Scripts de configuração. Esta parte do script ainda não foi muito bem testada (pode acontecer de você observar que este script não configura o seu servidor real não-linux apropriadamente, então, por favor entre em contato comigo - Joe).

Nota

(Nos 3 anos de edição do script de configuração, Eu não ouvi ninguém que tenha utilizado esta parte do código, por isso não vejo motivos para mante-lo). A versão 0.10 do script de configuração (apareceu em 2003) não terá este código nele. O Script de configuração usará o iproute2 para a instalação dos dispositivos de rede e rotas. Você terá que configurar os servidores reais que não sejam Linux por si próprio.

Aqui tem informações para os sistemas UNIX (não-linux) Em alguns sistemas UNIX você tem que colocar as interfaces em prumo antes de lhes assinalar um IP. As informações de como colocar as interfaces em prumo não estão incluídas aqui.

#uname      : FreeBSD
#uname -r   : 3.2-RELEASE
#<command>  : ifconfig lo0 alias <IPV> netmask 0xffffffff -arp up
#ifconfig -a: lo0: flags=80c9<UP,LOOPBACK,RUNNING,NOARP,MULTICAST>mtu 16837
#                  inet 127.0.0.1 netmask 0xff000000
#                  inet <IPV> netmask 0xffffffff

#uname      : IRIX
#uname -r   : 6.5
#<command>  : ifconfig lo0 alias <IPV> netmask 0xffffffff -arp up
#ifconfig -a: lo0: flags=18c9<UP,LOOPBACK,RUNNING,NOARP,MULTICAST,CKSUM>
#                  inet 127.0.0.1 netmask 0xff000000
#                  inet <IPV> netmask 0xffffffff

#uname      : SunOS
#uname -r   : 5.7
#<command>  : ifconfig lo0:1 <IPV> netmask 255.255.255.255 up
#ifconfig -a: lo0:  flags=849<UP,LOOPBACK,RUNNING,MULTICAST>mtu 8232
#                   inet 127.0.0.1 netmask ff000000
#             lo0:1 flags=849<UP,LOOPBACK,RUNNING,MULTICAST>mtu 8232
#                   inet <IPV> netmask ffffffff

#uname      : HP-UX
#uname -r   : B.11.00
#<command>  : ifconfig lan1:1 10.10.10.10 netmask 0xffffff00 -arp up
#ifconfig -a: lan0:   flags=842<BROADCAST,RUNNING,MULTICAST>
#                     inet <some IP> netmask ffffff00
#             lan0:1: flags=8c2<BROADCAST,RUNNING,NOARP,MULTICAST>
#                     inet <IPV> netmask ffffff00
#

Ratz em 16 de Abril de 2001

na maioria dos casos (quando usar a opção NOARP) você precisará de suporte a aliases. Alguns UNIXes não possuem suporte a aliases de interface ou somente limitações, como o QNX, Aegis ou Amoeba por exemplo. Outros possuem problemas inerentes a flags da interface, como o HP-UX onde é impossível ter um alias de interface para outra a não ser a interface física (como acontece com o Linux 2.2 e 2.4 - Joe). Então para o HP/UX você precisa de uma configuração especial porque a tradicional não iráfuncionará com o DR. Eu fiz a maioria dos UNIXes como servidores reais e fiquei assombrado com as variações existentes nestes UNIXes, isto pode ser um resultado de uma implementação RFC que não tenha ficado muito clara.

O Windows não é manipulado pelo Script de configuração (no qual precisaria de um bash para ser executado).

Instruções de como configurar o Windows como um servidor real é uma maioria em perguntas nas listas de email. Está pode ter sido uma parte difícil de encontrar aqui no mini-HOWTO ;-\. Existem várias formas de fazer a configuração. Aqui está algumas respostas.

Esta é a receita original do Sr. Wensong para ajustar o dispositivo lo no servidor real NT.

Caso você não tenha o "MS Loopback Adapter Driver" instalado no seu servidor NT, entre no Painel de Controle, Rede, Clique na parte dos Adaptadores, clique para adicionar um novo adaptador, selecione o "MS Loopback Adapter". O CD do Windows seré necessário para fazer esta instalação. Então adicione o endereço do seu IPV (IP Virtual) no "MS Loopback Adapter" , não entre com o endereço do gateway neste adaptador. Uma vez que a máscara de rede 255.255.255.255 não é aceita pela M$, então aceite a máscara padrão, entre no MS-DOS e remova a entrada extra na tabela de roteamento.

c:route delete <IPV's network> <IPV's netmask>

Isto fará com que os pacotes destinados a esta rede passem pela outra interface de rede, não pela interface MS Loopback. Pelo que me lembro, colocando a máscara de rede como 255.0.0.0 também funcionará.

Jerome Richard jrichard (arroba) virtual-net (ponto) fr

No Windows NT Server, você só tem que instalar o "MS Loopback Adapter" (fornecido no CD do windows NT na parte "novo hardware") e então configure o IPV neste interface.

o1004g o1004g (arroba) nbuster (ponto) com

robert.gehr (arroba) web2cad (ponto) de; 24 Oct 2001

O Adaptador MS-Loopback é o dispositivo virtual no Windows que não responde a nenhuma requisição arp. Ele deve estar no CD do WindowsNT/2000 edição Servidor. Instale ele e então defina o o endereço IP apropriado. Devido a Microsoft não aceitar a máscara de rede "x.x.x.x/32" para o adaptador de loopback, você acabará tendo duas rotas apontando para a mesma rede. Se eu disser que o seu IPR é 10.10.10.10 e o seu adaptador MS-Loopback é 10.10.10.11. Você terá duas rotas na sua tabela de roteamento, ambas apontando para a rede 10.0.0.0. Para corrigir este problema você deve deletar a rota que aponta para a interface MS-Loopback com um comando assim:

route del 10.0.0.0 mask 255.0.0.0 10.10.10.11

Johan Ronkainen jr (arroba) mpoli (ponto) fi

Funciona com o Windows NT4, mas com o Windows 2000 você pode apenas configurar uma métrica bem alta para a interface de Loopback. Tentei este método anos atrás com uma métrica de valor 254 e nunca tive problemas. Eu acredito que você possa alterar o valor da máscara de rede com o regedit para /32. Não tentei com o WindowsNT4 nem com o 2000, mas funcionou com o Windows98SE.

Brent Knotts brent (ponto) knotts (arroba) mylocalgov (ponto) com 28 Jan 2003

A respeito dos Servidores Reais com Windows 2000

É possível alterar a máscara de subrede pelo registro para 255.255.255.255 e realmente funciona para a minha configuração RD, esta forma é mais fácil de fazer do que ficar deletando a rota extra na tabela de roteamento a cada inicialização.

No Windows 2000, as interfaces podem ser encontradas em:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

Encontre a interface com o IP apropriado e altere a máscara de subrede, não é necessário reiniciar o computador, apenas desative e reative a interface.

Outros idiomas para a MS

Sebastien Sebastien.Bonnet (arroba) experian (ponto) fg 12 Apr 2002

O "Adaptador Loopback da MS" é chamado de "carte de bouclage"

Malcolm Turnbull

Eu configurei um LVS-DR simples com 4 servidores web IIS (win2k) por trás. Eu configurei uma interface de loopback local em cada 2k com métrica definida para 254. O balanceamento de carga está funcionando normalmente ... Mas parece estar confundindo a rede Windows, a busca SMB parece não estar mais funcionando (Requisitado pelo RoboCopy).

Martijn Klingens mklingens (arroba) ism (ponto) nl 10 Sep 2002. Assunto: Re: Configuração do LVS DR nos servidores Windows 2000

Nós estamos usando uma configuração muito similar, apenas estamos utilizando um xcopy e queremos migrar para DFS. O que não muda o princípio das coisas. Detalhes que eu encontrei:

• O Windows sempre adiciona uma rota para a subrede do adaptador de loopback. Se esta subrede também está disponível na LAN a sua tabela de roteamento se tornará confusa. No nosso caso nós migramos os IPs existentes para o LVS então tivemos que usar máscara subnet classe C inteira. A solução foi deletar manualmente as rotas /24 para a interface Loopback.
• Desativar o compartilhamento de arquivos e impressoras na interface Loopback também ajuda.
• Verifique os gateways e servidores DNS em todas as suas interfaces. Caso alguma coisa não esteja correta nestes campos você poderá enfrentar diversos problemas esquisitos (Existem casos em que os DNS são para ficar diferentes em cada placa de rede, mas é um caso muito incomum).

Acredito que esta ajuda tenha sido suficiente, mas caso não tenha resolvido o seu problema, tente nos passar mais informações a respeito das suas configurações. Caso você tenha problemas com os servidores-reais, ele é capaz de descobrir os outros servidores por meio do dns e ping?

Ah, você falou também na busca de computadores usando o Ambiente de Rede, o que não é exatamente o mesmo do que abrir um compartilhamento em um computador em que já se conhece o nome. Você realmente precisa da busca funcionando? Eu normalmente tenho a busca de computadores sempre desativada, assim evita que os intrusos tomem conhecimento de imediatdo sobre a minha rede. Vale informar que o DNS pode lhe fornecer as mesmas informações, com um pouco menos de risco.

Malcolm Turnbull

Alguém já usou o Mac OS X como um servidor real no LVS/DR?

Jerome RICHARD jrichard (arroba) virtual-net (ponto) fr 20 Nov 2002

Se você quer configurar vários IPs no Mac OS X, deve usar o seguinte comando:

sudo ifconfig lo0 alias 10.0.0.80 netmask 255.255.0.0
 

Há mais informações em Documentos da AppleCare

Roberto Nibali ratz (arroba) drugphish (ponto) ch 20 Nov 2002

Sim, eu fui a uma apresentação por volta de um ano atrás e me lembro que os participantes tinham um novo G4 com Mac OS X. Funcionou perfeitamente.

Há algum problema em usar a interface de loopback?

Pode usar, mas não há necessidade. O OS X é do tipo BSD, por isso você deve usar a mesma sintax dos BSD:

ifconfig lo0 alias IPV netmask 255.255.255.255 -arp up
 

Malcolm Turnbull Malcolm.Turnbull (arroba) crocus (ponto) co (ponto) uk 22 Nov 2002

Deixe Funcionando:

• Solaris:

  ifconfig lo0:1 plumb ifconfig lo0:1 <vip-addr> netmask 255.255.255.255 up

• Mac OS X:

  ifconfig lo0 alias IPV netmask 255.255.255.255 -arp up