- Why Edgenexus?
- Try
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
Tutorial do balanceador de carga/ADC ALB-X Test drive
(Controlador de entrega de aplicações ADC)
Faça o seu test drive aqui
Índice
Esperamos que goste da sua experiência com o equilibrador de carga ALB-X e gostaríamos que tivesse uma configuração realista para jogar.
-
Como parte deste teste, pré-configurámos alguns serviços de exemplo para que possa começar a trabalhar.
-
Alojamos esta configuração no Azure, mas não se preocupe, não precisa de ter uma conta Azure e é GRÁTIS.
-
Pode reconfigurar o aparelho para o experimentar nos seus próprios servidores.
Eis algumas palavras para o ajudar a navegar na interface do utilizador e a tirar o máximo partido do seu test drive, por isso aperte o cinto de segurança....
Depois de se ter inscrito no teste ALB-X, ser-lhe-á apresentado o seu próprio URL exclusivo para aceder à interface gráfica do ALB-X a partir do seu navegador Web. Se possível, recomendamos a utilização do navegador Google Chrome.
- Note-se que a GUI é acedida utilizando uma porta não padrão: 27376, de modo a que a porta HTTPS padrão: 443 esteja disponível para atribuição como um serviço de carga equilibrada.
- Não se preocupe com o facto de lhe ser apresentado um aviso de segurança SSL - isto deve-se ao facto de a ligação de gestão estar protegida por defeito utilizando um certificado local.
Para a implantação em tempo real, você pode carregar seu próprio certificado para confirmar a autenticidade da conexão de gerenciamento.
Quando solicitado, digite seu nome de usuário e senha exclusivos para esta sessão de teste (você recebeu isso no e-mail).
Configuração do Test Drive do Azure
- O Azure utiliza o mapeamento de portas NAT 1:1 para fornecer acesso a partir do espaço de endereço IP público da Internet para o endereço IP privado interno.
-
O endereço IP configurado automaticamente no dispositivo de balanceamento de carga usa um endereço IP privado do Azure.
-
É claro que pode configurar o Azure para abrir e NAT mais portas para serviços adicionais.
-
Apenas as portas 80, 443 e 27376 (para a GUI) foram abertas para esta demonstração.
ALB-X Test Drive Serviços pré-preenchidos
Como este é um test drive personalizado, preenchemos previamente os IP-Services com alguns serviços que você pode experimentar imediatamente. Para fins de test drive, disponibilizamos o conteúdo real do servidor em dois servidores da Web disponíveis publicamente:
- O ALB-X é capaz de utilizar o DNS para resolver os nomes para os endereços IP públicos. Cada um destes sítios tem texto/imagens para mostrar qual o sítio que serviu o conteúdo, para que possa ver o processo de equilíbrio de carga em ação.
Existem 4 serviços de demonstração que preparámos para si:
|
Nome
|
Porto
|
Acessibilidade
|
|---|---|---|
|
Balanceamento de carga das ligações HTTP mínimas
|
80
|
http://yoururl
|
|
Descarregamento de HTTPS
|
443
|
https://yoururl
|
|
Persistência baseada em cookies
|
601
|
http://yoururl/601/
|
|
Reescrita do teste de corpo de prova
|
602
|
http://yoururl/?602
|
Serviço na porta 80 - balanceamento de carga das ligações HTTP mínimas
O primeiro serviço é um balanceador de carga de servidor web básico de porta 80 usando nossa política de balanceamento de carga "menos conexões" para 2 "servidores reais".
- Utilize o seu browser para abrir uma ligação HTTP ao mesmo endereço IP público utilizado para o acesso de gestão do ALB-X e deverá obter algo semelhante ao seguinte.
Serviço na porta 443 - Descarregamento SSL
O segundo serviço está na porta 443. Neste caso, o balanceador de carga está a fazer a encriptação, por vezes designada por SSL "offload".
- Utilizámos o certificado SSL predefinido para a demonstração do teste, pelo que receberá o mesmo alerta de segurança no seu browser quando se ligar a este canal.
Pode carregar o seu próprio certificado SSL e aplicá-lo ao serviço, ver instruções mais adiante. Depois de ter clicado para ultrapassar a exceção de segurança, verá o mesmo conteúdo apresentado no seu browser.
Redireccionamento de HTTP para HTTPS
A primeira coisa que podemos ver que utiliza o flightPATH é o redireccionamento de HTTP para HTTPS.
Trata-se de uma funcionalidade frequentemente utilizada para garantir que o tráfego Web é servido através de uma ligação segura.
- Pré-configurámos uma regra flightPATH e aplicámo-la ao canal HTTP da porta 80 para procurar pedidos que tenham uma cadeia de consulta de: /?secure
/?secure
Se o flightPATH vir esta "condição", actuará sobre o tráfego e devolverá um redireccionamento 302 ao browser, dizendo-lhe para efetuar outro pedido GET para HTTPS://your.original.request.location que, neste caso, será o mesmo endereço IP público do serviço, mas no canal 443.
Talvez queira dar uma vista de olhos à forma como a regra flightPATH está configurada.
Para tal, basta clicar no separador Library (Biblioteca ) à esquerda e selecionar flightPATH.
Clique na entrada "Force HTTPS - when query string is secure" (Forçar HTTPS - quando a cadeia de consulta é segura ) e pode ver a
- "Condição" é Query String Contém seguro
OU
- "Action" é Redirect 302 https://$host$$path$$querystring$ ($ são variáveis úteis que pode utilizar em acções de regras)
Persistência de cookies e utilização do servidor com base no caminho
Como você deve ter visto, até agora as conexões foram distribuídas entre os dois servidores reais – é por isso que você vê imagens retornadas tanto do servidor 1 quanto do servidor 2. Isso ocorre porque a política de balanceamento de carga padrão é “menos conexões”, o que tentará manter um número uniforme de conexões com todos os servidores configurados para um serviço.
- LEMBRE-SE: Todos os objectos de uma página Web, como imagens, vídeo e JS, terão um pedido GET separado para o servidor Web. Este comportamento pode não ser compatível com a aplicação, que pode exigir "persistência" ou "aderência".
Para os serviços HTTP, isto pode ser conseguido através da aplicação de um cookie de sessão especial que o browser apresentará em todos os pedidos subsequentes a esse serviço, normalmente durante o período da "sessão".
- Para o demonstrar, configurámos o serviço 'interno' 601 para o balanceamento de carga baseado em cookies de sessão ALB. Como dissemos, uma vez que o serviço 601 não é diretamente acessível a partir do exterior da rede Azure, utilizámos uma regra flightPATH para direcionar o tráfego para este serviço.
A regra flightPATH analisa o caminho solicitado e, se for /601/, enviará o tráfego para o serviço em execução na porta 601. Eis os pormenores desta regra flightPATH.
Esta regra flightPATH mostra como o tráfego pode ser enviado para outro serviço com base no caminho, o que constitui uma ferramenta poderosa para a manipulação do tráfego ou para a direção de conteúdos.
Podemos ver a configuração do VIP na porta 601:
- Agora tente adicionar o caminho /601/ ao IP público "http://myurl/601/", deverá obter um resultado como este:
http://myurl/601/
Pode ver aqui que todo o conteúdo é servido a partir do Servidor 1 - pode verificar as ferramentas de desenvolvimento do seu browser e verá que foi definido um cookie chamado jnAccel=.
Avaliação de Path Rewrite e RegEx
Como o servidor real não tem qualquer conteúdo no caminho /601/ , precisámos de o remover do pedido ou receberíamos um erro 404 (que também podemos ocultar utilizando flightPATH).
- Isto foi feito aplicando outra regra flightPATH chamada 'Remove Path 601' ao serviço que está a correr na porta :601.
Aqui procuramos novamente o 601 no caminho como uma condição para acionar esta regra.
- Neste caso, utilizamos a função Avaliação que utiliza a Expressão Regular para permitir a criação de uma nova variável através da manipulação de uma variável do Sistema existente, neste caso o valor original do Caminho que vimos.
Assim, criamos o NewPath extraindo apenas os dados após o prefixo de caminho /601/.
A 'Ação' é reescrever o caminho utilizando $NewPath1$ e $querystring$ se estiverem presentes.
Substituição do texto do corpo HTML
No outro exemplo de serviço que utiliza a porta :602 , mostramos como também é possível manipular o conteúdo HTML e não apenas o cabeçalho HTTP.
- Em vez de utilizar um caminho para direcionar o tráfego que chega à porta 80 para utilizar o serviço 602, utilizámos o querystring /?602. - "http://myurl/?602"
http://myurl/?602
Se introduzir o endereço IP público do seu ALB-X de teste no seu browser e acrescentar /?602 , deverá obter o seguinte resultado.
Pode ver uma linha adicional de texto a laranja que indica que -
- "Este texto foi adicionado por flightPATH"
Isto é conseguido através de 2 regras flightPATH.
A seguinte regra aplicada à porta:80 procura um valor de cadeia de consulta de 602 e envia todos os pedidos correspondentes para o serviço em execução na porta 602.
Aplicada ao serviço em execução na porta :602 é uma regra flightPATH que executa uma função 'Body Replace Last' à procura da etiqueta de fecho do corpo
</body>
e substituindo-o por
<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>
Não é necessária qualquer condição ou avaliação neste caso, pelo que a função se aplicará a todo o tráfego que passe pelo serviço.
Esperemos que consiga ver de que outra forma estas facilidades podem ser combinadas para efetuar uma manipulação inteligente do tráfego HTTP e isto é apenas a ponta do iceberg do que o flightPATH pode fazer.
Experimente você mesmo e teremos todo o prazer em conhecer as suas necessidades específicas.
Verificações reais do estado do servidor
A próxima coisa que vamos analisar é a verificação real do estado do servidor. É vital que o tipo certo de verificação do estado de saúde seja aplicado a um serviço para permitir a deteção fiável do estado do(s) servidor(es) back end, de modo a garantir que o tráfego de clientes só é enviado para servidores que estão operacionais.
Quando criamos um novo serviço, temos de definir um conjunto de parâmetros por defeito. Para a monitorização do servidor, utilizamos o controlo de saúde da ligação TCP. A opção Monitorização do servidor encontra-se no separador Básico do serviço que está a ser configurado.
Embora este seja um ponto de partida razoável, é altamente recomendável que seja configurado e aplicado um controlo de saúde mais fiável a um serviço, e tornámos muito fácil a criação de controlos de saúde HTTP personalizados.
- O controlo de saúde pode ser encontrado em "Biblioteca / Monitores de servidores reais".
No Test Drive, adicionámos um terceiro Monitor de Servidor Real para mostrar um exemplo de uma verificação do estado da resposta HTTP.
HTTP 200 OK Método de monitorização
O 200OK Utiliza um pedido HTTP GET para a localização da página configurada para a verificação e certifica-se de que é devolvida uma resposta de estado 200OK.
Não procura qualquer conteúdo específico, apenas verifica se um servidor Web está a funcionar na porta e se é capaz de servir a página pedida.
- Este é um monitor melhor do que a ligação TCP, uma vez que funciona na camada 7, verificando se a aplicação está a ser executada, mas não verifica uma resposta específica do conteúdo devolvido.
Aplicámos este monitor, como pode ver acima, ao serviço em execução na porta:601.
Método de monitorização da resposta HTTP
O Monitor NLS configurado no Test Drive utiliza a verificação de resposta HTTP.
Para tal, define-se a localização específica da página (pode ser o URL completo quando são necessários cabeçalhos de anfitrião) e define-se o conteúdo (uma cadeia de texto) que deve estar presente nos dados devolvidos pelo servidor/aplicação.
Este é um teste muito melhor, uma vez que a página tem de estar presente e o conteúdo específico tem de estar disponível.
- Nos casos em que a aplicação está ligada a uma base de dados back end, é boa ideia fazer com que o estado do conteúdo recuperado na página de verificação do estado de saúde dependa de respostas em tempo real da base de dados e não apenas de conteúdo estático no servidor web front end.
Pode ver que aplicámos este monitor ao serviço em execução na porta:602.
Pode modificar o texto no campo Conteúdo obrigatório para este controlo de saúde e verá os servidores ficarem vermelhos para mostrar que falharam o controlo de saúde. Reverta o conteúdo necessário para o valor correto e os servidores voltarão a ficar verdes.
Intervalo de monitorização
No separador avançado, é possível manipular a frequência e o tempo limite, etc., da operação de verificação do estado de saúde desse serviço.
Para o teste de condução, definimos o Intervalo do monitor para 3 segundos com um tempo de espera de 2 segundos.
O Monitoring Out Count está definido para 3, pelo que tem de falhar a obtenção de 3 respostas consecutivas antes de marcar o servidor como inacessível.
- Com um Monitor In Count (Contagem de Monitorização) de 2, tem de haver 2 respostas consecutivas bem sucedidas antes de marcar o servidor como estando de novo em serviço. Estes são valores sensatos a utilizar na maioria dos casos.
Certificados HTTPS e SSL
Cada vez mais sítios Web estão a utilizar HTTPS e, no início de 2017, a percentagem de sítios a favor do HTTPS tinha aumentado.
A maior parte das aplicações empresariais requerem proteção através de encriptação, pelo que é bastante seguro apostar que será necessário utilizar certificados no ALB-X. A implementação de um balanceador de carga com HTTPS é uma forma rápida e fácil de proteger o acesso a aplicações não encriptadas.
- O ALB-X tem um certificado privado instalado por defeito, denominado "default", que é utilizado para permitir a conetividade HTTPS à GUI de gestão. Aplicámos este certificado ao serviço configurado Test Drive :443 HTTPS no Serviço Virtual ou no lado do cliente.
O serviço está configurado para descarregamento SSL, pelo que o lado do Servidor Real está configurado para Sem SSL.
Carregamento / importação de certificados
Pode carregar os seus próprios certificados assinados para o ALB-X utilizando o menu Certificados SSL na secção Biblioteca
Tal como destacado nos campos de introdução de texto, o certificado tem de estar no formato PKCS#12 para ser importado para o ALB-X.
- Este tipo de certificado contém a chave privada e é protegido por uma palavra-passe que é exigida no momento da importação.
O nome (que não deve conter espaços) que dá ao certificado na importação será o que aparece nos menus suspensos de seleção de certificados no separador Básico do serviço IP.
Reencriptação do servidor real
Se os servidores reais necessitarem de reencriptação SSL/TLS, a opção mais sensata a selecionar é "Qualquer" no menu pendente Certificado SSL de servidor real.
- Isto significa que o ALB-X aceitará qualquer certificado apresentado pelos servidores reais como sendo válido.
SNI (Indicação do nome do servidor)
Com a escassez de endereços IP públicos e o facto de apenas um VIP poder ser configurado no Azure, é útil poder suportar vários domínios seguros / URLs de anfitrião através de um serviço virtual, o que é possível no ALB-X porque suportamos SNI.
- Para utilizar o SNI, basta selecionar todos os certificados necessários na caixa pendente Certificado SSL de Serviço Virtual. Cada clique irá selecionar ou anular a seleção do certificado como parte da lista SNI.
No lado do Servidor Real, se os serviços forem recriptografados e alojados em servidores comuns, necessitarão do SNI para a identificação e negociação correctas do serviço, pelo que o SNI deve ser selecionado como opção no menu pendente do Certificado SSL do Servidor Real.
Aplicações
O ALB-X suporta a implementação de características e funcionalidades adicionais através da aquisição e transferência de aplicações da nossa App Store para implementação no ambiente contentorizado do ALB-X.
- Os dois primeiros add-ons principais disponíveis são uma Web Application Firewall e um Global Server Load Balancing para redundância automatizada de centros de dados e failover/balanço de carga de nuvens híbridas.
Criámos dois Test Drives separados no Azure onde pode ver esta funcionalidade em funcionamento, por isso, se estiver interessado, verifique-os.
Autenticação
O ALB-X suporta a pré-autenticação em conjunto com um servidor MS AD (Microsoft Active Directory) / LDAP.
- Pode explorar esta funcionalidade se tiver acesso a um servidor MS AD / LDAP acessível publicamente (utilize LDAPs). O guia do utilizador online do ALB-X apresenta a configuração desta funcionalidade.
Esta funcionalidade é um substituto popular para o produto Microsoft TMG descontinuado.
Monitorização da utilização do aparelho e da ligação
A secção de visualização do menu fornece-lhe os meios para poder ver o estado da ligação e o estado real do servidor em tempo real (Estado) ou como uma tendência ao longo do tempo (Histórico).
- Este é também o local onde se encontram os registos do W3C e do sistema. Também pode criar os seus próprios widgets personalizados para apresentar no Painel de Controlo. Aconselhamo-lo a consultar as várias opções apresentadas nesta secção.
Sistema
É aqui que se encontram as opções de configuração que se aplicam às funções do sistema, tais como definir a hora e a data, ativar o alerta por correio eletrónico, licenciar o produto, escolher a forma como o registo é efectuado e para onde são enviados, reiniciar e reiniciar o aparelho, configurar o SNMP e adicionar outros utilizadores de gestão, etc.
Avançado
No menu avançado é possível fazer backup e restaurar a configuração e também carregar configurações de modelos jetPACK.
- Pode modificar o comportamento do protocolo HTTP comum e pode efetuar a atualização do software e descarregar outros pacotes de software a partir da biblioteca da nuvem.
Por último, existe uma secção de resolução de problemas onde facilitámos a transferência de um pacote de ficheiros de suporte, a execução de PING de rede e a realização de vários rastreios do sistema e capturas de pacotes de rede.
Obrigado.
- Esperamos sinceramente que aprecie o seu test-drive ALB-X.
Agradecemos todas as perguntas que possam ter para pre-sales@edgenexus.io
Não acredite em nossa palavra - faça um teste gratuito
Hardware, software ou até mesmo sua própria imagem on-line completa com um ambiente de teste completo.
Basta nos informar o que você precisa aqui
Copyright © 2021 Edgenexus Limited.