|
Campo
|
Descrição
|
|
Endereço IP
|
Digite um novo endereço IP Virtual para ser o ponto de entrada alvo para acessar o Servidor Real. Este IP é onde os usuários ou aplicações irão apontar para acessar a aplicação balanceada de carga.
|
|
Máscara de sub-rede/Prefixo
|
Este campo é para a máscara de sub-rede relevante para a rede em que o ADC está localizado.
|
|
Porto
|
A porta de entrada utilizada ao acessar o VIP. Este valor não precisa necessariamente ser o mesmo que o Servidor Real se você usar a Reverse Proxy.
|
|
Nome do serviço
|
O nome do serviço é uma representação textual do propósito do VIP. É opcional, mas recomendamos que você o forneça para maior clareza.
|
|
Tipo de serviço
|
Há muitos tipos diferentes de serviços disponíveis para você selecionar. Os tipos de serviço de camada 4 não podem usar a tecnologia flightPATH.
|
|
Campo
|
Descrição
|
|
Atividade
|
O campo de atividade pode ser usado para mostrar e alterar o status do servidor real balanceado de carga.
Online - Denota que o servidor está ativo e recebendo solicitações balanceadas de carga
Offline - O servidor está offline e não está recebendo solicitações
Drenagem - O servidor foi colocado em modo de drenagem de modo que a persistência possa ser descarregada e o servidor movido para um estado offline sem afetar os usuários.
Standby - O servidor foi colocado em estado de espera
|
|
Endereço IP
|
Este valor é o endereço IP do Servidor Real. Ele deve ser preciso e não deve ser um endereço DHCP.
|
|
Porto
|
A porta de acesso alvo no Servidor Real. Ao utilizar um proxy reverso, este pode ser diferente da porta de entrada especificada no VIP.
|
|
Ponderação
|
Esta configuração geralmente é configurada automaticamente pelo ADC. Você pode alterar isto se desejar alterar a ponderação de prioridade.
|
|
Opção
|
Descrição
|
|
Cluster
|
Cluster é o papel padrão do ADC na instalação, e a coluna Principal/Modo indicará o modo em que ele está funcionando atualmente. Quando você tiver um par de dispositivos ADC HA em seu centro de dados, um deles mostrará Ativo e o outro Passivo
|
|
Manual
|
O papel do Manual permite que o par ADC funcione em modo Ativo-Ativo para diferentes endereços IP virtuais. Nesses casos, a coluna Primária conterá uma caixa ao lado de cada IP Virtual exclusivo que pode ser marcado para Ativo ou deixado desmarcado para Passivo.
|
|
Stand-Alone
|
O ADC está agindo como um dispositivo independente e não está no modo High Availability (Alta Disponibilidade). Como tal, a coluna primária indicará Independente.
|
|
LED
|
Significado
|
|
l
|
Online
|
|
l
|
Failover-Standby. Este serviço virtual é hot-standby
|
|
l
|
Indica que um "secundário" está se segurando para um "primário".
|
|
l
|
O serviço precisa de atenção. Esta indicação pode resultar de um servidor real falhar em uma verificação do monitor de saúde ou ter sido alterado manualmente para fora de linha. O tráfego continuará a fluir, mas com capacidade reduzida do Real Server
|
|
l
|
Fora de linha. Os servidores de conteúdo são inacessíveis, ou não há servidores de conteúdo habilitados
|
|
l
|
Encontrar o status
|
|
l
|
IPs virtuais não licenciados ou licenciados excedidos
|
|
Tipo de serviço
|
Porto/Protocolo
|
Camada de serviço
|
Comentário
|
|
Camada 4 TCP
|
Qualquer porta TCP
|
Camada 4
|
O ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga
|
|
Camada 4 UDP
|
Qualquer porto UDP
|
Camada 4
|
Assim como no TCP de Camada 4, o ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga
|
|
Camada 4 TCP/UDP
|
Qualquer porta TCP ou UDP
|
Camada 4
|
É ideal se seu serviço tem um protocolo primário como o UDP, mas voltará ao TCP. O ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga.
|
|
HTTP
|
Protocolo HTTP ou HTTPS
|
Camada 7
|
O ADC pode interagir, manipular e modificar o fluxo de dados usando o flightPATH.
|
|
FTP
|
Protocolo de transferência de arquivos
|
Camada 7
|
Usando controle separado e conexões de dados entre cliente e servidor
|
|
SMTP
|
Protocolo simples de transferência de correio
|
Camada 4
|
Usar ao equilibrar a carga dos servidores de correio
|
|
POP3
|
Protocolo dos Correios
|
Camada 4
|
Usar ao equilibrar a carga dos servidores de correio
|
|
IMAP
|
Protocolo de acesso a mensagens na Internet
|
Camada 4
|
Usar ao equilibrar a carga dos servidores de correio
|
|
RDP
|
Protocolo de Desktop Remoto
|
Camada 4
|
Uso em servidores de Serviços Terminais de balanceamento de carga
|
|
RPC
|
Chamada de procedimento remoto
|
Camada 4
|
Usar quando sistemas de balanceamento de carga usando chamadas RPC
|
|
RPC/ADS
|
Troca 2010 Static RPC para serviço de catálogo de endereços
|
Camada 4
|
Uso em servidores de troca de balanceamento de carga
|
|
RPC/CA/PF
|
Troca 2010 RPC Estático para Acesso ao Cliente e Pastas Públicas
|
Camada 4
|
Uso em servidores de troca de balanceamento de carga
|
|
DICOM
|
Imagens e Comunicações Digitais em Medicina
|
Camada 4
|
Uso quando servidores de balanceamento de carga usando protocolos DICOM
|
|
LED
|
Significado
|
|
l
|
Conectado
|
|
£
|
Não monitorado
|
|
l
|
Drenagem
|
|
l
|
Offline
|
|
l
|
Aguarde
|
|
l
|
Não Conectado
|
|
l
|
Status de busca
|
|
l
|
Servidores reais não licenciados ou licenciados excedidos
|
|
Opção
|
Descrição
|
|
Online
|
Todos os Servidores Reais designados Online receberão tráfego de acordo com a política de balanceamento de carga definida dentro da guia Básica.
|
|
Drenagem
|
Todos os Servidores Reais designados como Drain continuarão a servir as conexões existentes, mas não aceitarão nenhuma nova conexão. A luz de status piscará verde/azul enquanto o dreno estiver em processo. Uma vez que as conexões existentes tenham fechado naturalmente, os Servidores Reais ficarão offline, e a luz de Status será azul sólido. Você também pode visualizar estas conexões navegando para a seção Navegação > Monitor > Status.
|
|
Offline
|
Todos os Servidores Reais configurados como Offline serão imediatamente desconectados e não receberão nenhum tráfego.
|
|
Aguarde
|
Todos os Servidores Reais configurados como Standby permanecerão offline até que TODOS os servidores do grupo Online falhem suas verificações do Monitor de Saúde do Servidor. O tráfego é recebido pelo grupo Standby de acordo com a política de balanceamento de carga quando isto acontece. Se um servidor do grupo Online passar na verificação do Monitor de Saúde do Servidor, este servidor Online receberá todo o tráfego, e o grupo Standby deixará de receber tráfego.
|
|
Opção
|
Descrição
|
|
Mais rápido
|
A política de balanceamento de carga mais rápida calcula automaticamente o tempo de resposta para todas as solicitações por servidor suavizadas ao longo do tempo. A coluna Peso Calculado contém o valor calculado automaticamente. A entrada manual só é possível quando se utiliza esta política de balanceamento de carga.
|
|
Round Robin
|
Round Robin é comumente usado em firewalls e equilibradores de carga básicos e é o método mais simples. Cada Real Server recebe um novo pedido em seqüência. Este método só é adequado quando você precisa carregar as solicitações de balanceamento de carga para servidores de forma uniforme; um exemplo seria servidores web look-up. Entretanto, quando você precisa carregar o equilíbrio baseado na carga da aplicação ou na carga do servidor, ou mesmo garantir que você use o mesmo servidor para a sessão, o método Round Robin é inadequado.
|
|
Mínimas conexões
|
O equilibrador de carga manterá um registro do número de conexões atuais para cada servidor real. O Servidor Real com a menor quantidade de conexões recebe o novo pedido subseqüente.
|
|
Afinidade/Persistência de Camada 3 Sessões - Limite IP
|
Neste modo, o endereço IP do cliente forma a base para selecionar qual Servidor Real irá receber a solicitação. Esta ação proporciona persistência. Os protocolos HTTP e Layer 4 podem usar este modo. Este método é útil para redes internas onde a topologia da rede é conhecida, e você pode ter certeza de que não há "super proxies" upstream. Com a Camada 4 e proxies, todas as solicitações podem parecer como se viessem de um cliente, e como tal, a carga não seria uniforme. Com HTTP, a informação do cabeçalho (X-Forwarder-For) é usada quando presente para lidar com os proxies.
|
|
Afinidade/Persistência de Camada 3 Sessões - Lista baseada em IP
|
A conexão com o Servidor Real inicia usando "Menos conexões" então, a afinidade da sessão é alcançada com base no endereço IP do cliente. Uma lista é mantida por padrão por 2 horas, mas isto pode ser alterado usando um jetPACK.
|
|
Afinidade/Persistência de Camada 7 - ALB Cookie de Sessão
|
Este modo é o método de persistência mais popular para o balanceamento de carga HTTP. Neste modo, o ADC usa o balanceamento de carga baseado em lista IP para cada primeira solicitação. Ele insere um cookie nos cabeçalhos da primeira resposta HTTP. Depois disso, o ADC usa o cookie do cliente para encaminhar o tráfego para o mesmo servidor back-end. Este cookie é usado para persistência quando o cliente precisa ir ao mesmo servidor back-end a cada vez. O cookie expira quando a sessão é encerrada.
|
|
Afinidade/Persistência de Camada 7 Sessões - ALB Cozinheiro Persistente
|
O modo de balanceamento de carga baseado na lista IP é usado para cada primeira solicitação. O ADC insere um cookie nos cabeçalhos da primeira resposta HTTP. Depois disso, o ADC usa o cookie do cliente para encaminhar o tráfego para o mesmo servidor back-end. Este cookie é usado para persistência quando o cliente deve ir ao mesmo servidor back-end a cada vez. O cookie expirará após 2 horas, e a conexão será balanceada de acordo com um algoritmo baseado em lista IP. Este tempo de expiração é configurável usando um jetPACK.
|
|
Cookie de Sessão - Cookie de Sessão Clássico ASP
|
O Active Server Pages (ASP) é uma tecnologia do lado do servidor da Microsoft. Com esta opção selecionada, o ADC manterá a persistência da sessão para o mesmo servidor se um cookie ASP for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie ASP, ele será balanceado de carga usando o algoritmo de Mínimas Conexões.
|
|
Cookie de sessão - Cookie de sessão ASP.NET
|
Este modo se aplica ao ASP.net. Com este modo selecionado, o ADC manterá a persistência da sessão no mesmo servidor se um cookie ASP.NET for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie ASP, ele será balanceado de carga usando o algoritmo de Mínimas Conexões.
|
|
Cookie de Sessão - Cookie de Sessão JSP
|
Java Server Pages (JSP) é uma tecnologia do lado do servidor Oracle. Com este modo selecionado, o ADC manterá a persistência da sessão para o mesmo servidor se um cookie JSP for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie JSP, ele será balanceado de carga usando o algoritmo de Mínimas Conexões.
|
|
Cookie de sessão - Cookie de sessão JAX-WS
|
Java web services (JAX-WS) é uma tecnologia do lado do servidor Oracle. Com este modo selecionado, o ADC manterá a persistência da sessão para o mesmo servidor se um cookie JAX-WS for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie JAX-WS, ele será carregado balanceado usando o algoritmo de Conexões Mínimas.
|
|
Cookie de Sessão - Cookie de Sessão PHP
|
A Personal Home Page (PHP) é uma tecnologia de código aberto do lado do servidor. Com este modo selecionado, o ADC manterá a persistência da sessão para o mesmo servidor quando um cookie PHP for detectado.
|
|
Sessão Cookie - RDP Cookie Persistência
|
Este método de balanceamento de carga utiliza o RDP Cookie criado pela Microsoft baseado no nome de usuário/domínio para fornecer persistência a um servidor. A vantagem deste método significa que é possível manter uma conexão com um servidor, mesmo que o endereço IP do cliente mude.
|
|
Baseado em Cookie-ID
|
Um novo método muito parecido com "PhpCookieBased" e outros métodos de balanceamento de carga, mas usando CookieIDBased e cookie RegEx h=[^;]+
Este método usará o valor definido no campo de notas do Real Server "ID=X;" como o valor do cookie para identificar o servidor. Isto, portanto, significa que é uma metodologia similar ao CookieListBased, mas usa um nome de cookie diferente e armazena um valor único de cookie, não o IP codificado, mas o ID do Servidor Real (lido em tempo de carga).
O valor padrão é CookieIDName="h"; entretanto, se houver um valor de sobreposição na configuração avançada do servidor virtual, use-o em seu lugar. NOTA: Se este valor for definido, nós substituímos a expressão cookie acima para substituir h= pelo novo valor.
O último bit é que se um valor de cookie desconhecido chegar e corresponder a uma das IDs do Servidor Real, ele deve selecionar esse servidor; caso contrário, use o próximo método (delegar).
|
|
Opção
|
Descrição
|
|
Nenhum
|
Neste modo, o Real Server não é monitorado e está sempre funcionando corretamente. A configuração Nenhum é útil para situações em que o monitoramento perturba um servidor e para serviços que não devem participar da ação de fail-over do ADC. É uma rota para hospedar sistemas não confiáveis ou legados que não são primários para as operações H/A. Use este método de monitoramento com qualquer tipo de serviço.
|
|
Ping/ICMP Echo
|
Neste modo, o ADC envia um pedido de eco ICMP para o IP do servidor de conteúdo. Se uma resposta de eco válida for recebida, o ADC considera o Servidor Real ativo e em funcionamento, e o fluxo de tráfego para o servidor continua. Ele também manterá o serviço disponível em um par H/A. Este método de monitoramento é utilizável com qualquer tipo de serviço.
|
|
Conexão TCP
|
Neste modo, uma conexão TCP é feita ao Servidor Real e imediatamente quebrada sem o envio de quaisquer dados. Se a conexão for bem sucedida, o ADC considera o Servidor Real como estando em funcionamento. Este método de monitoramento é utilizável com qualquer tipo de serviço. Os serviços UDP são os únicos atualmente não apropriados para o monitoramento da conexão TCP.
|
|
ICMP Inacessível
|
O ADC enviará um cheque de saúde UDP ao servidor e marcará o Servidor Real como indisponível se ele receber uma mensagem inalcançável de porta ICMP. Este método pode ser útil quando você precisa verificar se uma porta de serviço UDP está disponível em um servidor, tal como a porta DNS 53.
|
|
RDP
|
Neste modo, uma conexão TCP é inicializada como explicado no ICMP Unreachable method (método inalcançável). Após a inicialização da conexão, uma conexão RDP de Camada 7 é solicitada. Se a conexão for confirmada, o ADC considera que o Servidor Real está em funcionamento. Este método de monitoramento é utilizável com qualquer servidor de terminal Microsoft.
|
|
200 OK
|
Neste método, uma conexão TCP se inicializa no Servidor Real. Após o sucesso da conexão, o ADC envia ao Servidor Real um pedido HTTP. Uma resposta HTTP é aguardada e verificada para o código de resposta "200 OK". Se o código de resposta "200 OK" for recebido, o ADC considera o Servidor Real ativo e em funcionamento. Se o ADC não receber um código de resposta "200 OK" por qualquer motivo, incluindo timeouts, falha na conexão e outros motivos, o ADC marca o Servidor Real indisponível. Este método de monitoramento só é válido para uso com tipos de serviço HTTP e HTTP acelerado. Se um tipo de serviço Layer 4 estiver em uso para um servidor HTTP, ele é utilizável se o SSL não estiver em uso no Servidor Real ou se for tratado apropriadamente pelo recurso "Conteúdo SSL".
|
|
DICOM
|
Uma conexão TCP é inicializada ao Servidor Real no modo DICOM, e uma "Solicitação de Associado" Echoscu é feita ao Servidor Real na conexão. Uma conversa que inclui uma "Associate Accept" do servidor de conteúdo, uma transferência de uma pequena quantidade de dados seguida por uma "Release Request", e depois uma "Release Response" conclui com sucesso o monitor. Se, por qualquer razão, o monitor não for concluído com sucesso, então o Servidor Real é considerado como desligado.
|
|
Definido pelo usuário
|
Qualquer monitor configurado na seção de Monitoramento do Servidor Real aparecerá na lista.
|
|
Opção
|
Descrição
|
|
Por Host
|
O cache por anfitrião é baseado na aplicação por nome de anfitrião. Um Cache separado existirá para cada domínio/nome de host. Este modo é ideal para servidores web que podem servir múltiplos websites, dependendo do domínio.
|
|
Por Serviço Virtual
|
O cache por serviço virtual está disponível quando você escolhe esta opção. Apenas um Cache existirá para todos os domínios/nomes de domínios que passarem pelo serviço virtual. Esta opção é um cenário especializado para uso com vários clones de um único site.
|
|
Opção
|
Descrição
|
|
Fora
|
Desligue a compressão para o Serviço Virtual
|
|
Compressão
|
Quando selecionada, esta opção ativa a compressão para o Serviço Virtual selecionado. O ADC comprime dinamicamente o fluxo de dados para o cliente, mediante solicitação. Este processo só se aplica a objetos que contenham a codificação de conteúdo: cabeçalho gzip. O conteúdo de exemplo inclui HTML, CSS, ou Javascript. Você também pode excluir certos tipos de conteúdo usando a seção Exclusões Globais.
|
|
Opção
|
Descrição
|
|
Sem SSL
|
O tráfego desde a fonte até o ADC não é criptografado.
|
|
Padrão
|
Esta opção resulta na aplicação de um certificado criado localmente chamado "Default" ao lado do navegador do canal. Use esta opção para testar SSL quando um não tiver sido criado ou importado.
|
|
Certificados SSL Importados pelo Usuário
|
Qualquer certificado que você tenha importado para o ADC será afixado aqui.
|
|
Opção
|
Descrição
|
|
Sem SSL
|
O tráfego do ADC para o Servidor Real não é criptografado. A seleção de um certificado no lado do navegador significa que "No SSL" pode ser escolhido no lado do cliente para fornecer o que é conhecido como "SSL Offload".
|
|
Qualquer
|
O ADC atua como um cliente e aceitará qualquer certificado que o Real Server apresentar. O tráfego do ADC para o Servidor Real é criptografado quando esta opção é selecionada. Use a opção "Qualquer" quando um certificado é especificado no lado do Serviço Virtual, fornecendo o que é conhecido como "SSL Bridging" ou "SSL Re-Encryption".
|
|
SNI
|
O ADC atua como um cliente e aceitará qualquer certificado que o Real Server apresentar. O tráfego do ADC para o Servidor Real é criptografado, se este for selecionado. Use a opção "Qualquer" quando um certificado for especificado no lado do Serviço Virtual, fornecendo o que é conhecido como "SSL Bridging" ou "SSL Re-Encryption". Escolha esta opção para habilitar o SNI no lado do servidor.
|
|
Certificados SSL Importados pelo Usuário
|
Qualquer certificado que você tenha importado para o ADC aparece aqui.
|
|
Opção
|
Descrição
|
|
Proxy Reversa
|
O Proxy Reverso é o valor padrão e funciona em Layer7 com compressão e cache. E na Camada4 sem caching ou compressão. Neste modo, seu ADC atua como um proxy reverso e se torna o endereço de origem visto pelos Servidores Reais.
|
|
Retorno direto do servidor
|
Direct Server Return ou DSR como é amplamente conhecido (DR - Direct Routing em alguns círculos) permite que o servidor atrás do equilibrador de carga responda diretamente ao cliente contornando o ADC na resposta. O DSR é adequado apenas para uso com balanceamento de carga de Camada 4. Portanto, o Caching e a Compressão não estão disponíveis com esta opção escolhida.
O balanceamento de carga da camada 7 não funciona com este DSR. Além disso, não há nenhum outro suporte de persistência além do baseado na lista IP. O balanceamento de carga SSL/TLS com este método não é o ideal, pois o suporte de persistência IP Source é o único tipo disponível. O DSR também exige que sejam feitas mudanças no Real Server. Consulte a seção Mudanças no Servidor Real.
|
|
Porta de entrada
|
O modo Gateway permite encaminhar todo o tráfego através do ADC, permitindo que o tráfego dos Servidores Reais seja encaminhado através do ADC para outras redes através das máquinas virtuais ou interfaces de hardware do ADC. Usar o dispositivo como um dispositivo gateway para Servidores Reais é ideal quando executado em modo multi-interface.
O balanceamento de carga de camada 7 com este método não funciona, pois não há outro suporte de persistência além do baseado na lista IP. Este método requer que o Real Server defina seu gateway padrão para o endereço de interface local (eth0, eth1, etc.) do ADC. Favor consultar a seção Mudanças no Servidor Real.
|
