Introdução
Organizações frequentemente requerem um certo nível de tempo de atividade do sistema para suas implantações ArcGIS Enterprise, como 99 por cento do tempo ou mais. Para essas organizações, implementar uma estratégia para garantir alta disponibilidade é crucial.
Alta Disponibilidade (HA), embora relacionada à Recuperação de Desastres (DR), é um conceito separado. Geralmente, HA está focada em evitar tempo de inatividade para a entrega do serviço, enquanto DR está focada em reter os dados e recursos necessários para restaurar um sistema a um estado aceitável anterior após um desastre.
Este post focará nas melhores práticas para configurar o load balancer local (Local Traffic Manager, LTM) em um único local para alta disponibilidade, e não incluirá considerações para configurar o Global Traffic Manager (GTM) para failover automático entre diferentes locais.
Para alcançar alta disponibilidade, você deve reduzir pontos únicos de falha através da duplicação e balanceamento de carga.
Load balancers atuam como proxy reverso e distribuem o tráfego para servidores back-end. Um load balancer de terceiros é necessário em uma implantação ArcGIS Enterprise altamente disponível para melhorar a capacidade e confiabilidade do software. Eles gerenciam o tráfego dos clientes para seus sites portal e server, bem como o tráfego interno entre os componentes do software.
ArcGIS Web Adaptor
Embora o ArcGIS Web Adaptor seja considerado um load balancer, ele é inadequado para servir como o único load balancer em uma implantação altamente disponível, pois o ArcGIS Web Adaptor também requer redundância para alcançar alta disponibilidade.
O ArcGIS Web Adaptor é um componente opcional, já que load balancers podem encaminhar solicitações diretamente para seus sites portal e server, mas é um componente recomendado. As vantagens de usar web adaptors são:
- Fornece uma maneira fácil de configurar uma única URL para o sistema
- Permite escolher nomes de contexto para os diferentes componentes do sistema, por exemplo portal, server, mapping, etc.
- É integrado nativamente com outros componentes do software ArcGIS Enterprise, os sites portal e server, e automaticamente gerencia verificações de saúde e tarefas de configuração, por exemplo adicionando nova máquina a um site server
URL de Contexto Web
A URL de contexto web é a URL pública para o portal. Como qualquer item no portal tem uma URL - arquivo, camada, mapa e app - a propriedade WebContextURL do portal ajuda a construir as URLs corretas em todos os recursos que envia ao usuário final.
Acesso Externo e DNS
O portal ArcGIS Enterprise suporta apenas um DNS para a URL pública do portal (a URL de contexto web), e atualmente não há uma forma suportada de alterar a URL de contexto web sem refazer tarefas administrativas, por exemplo federar sites server com seu portal. Se seu ArcGIS Enterprise requer acesso externo, por exemplo para permitir acesso a usuários móveis, contratados, parceiros ou agências, sem VPN, ou se você antecipa que precisará permitir acesso externo no futuro, você deve usar um nome DNS resolvível externamente para a URL de contexto web do portal, por exemplo https://gis.company.com/portal.
Para garantir acesso externo seguro ao ArcGIS Enterprise, é comum hospedar um load balancer em uma DMZ, e implementar um Sistema Dividido de Nomes de Domínio (Split DNS), ou seja, acesso interno ao DNS do ArcGIS Enterprise (exemplo gis.company.com) será resolvido para um IP interno do load balancer, assim usuários internos permanecerão atrás do firewall, e acesso externo ao DNS do ArcGIS Enterprise será resolvido para um IP externo (DMZ) do load balancer.
URLs usados na federação
Diversas URLs diferentes são usadas em uma implantação ArcGIS Enterprise altamente disponível.
URL dos Serviços
Esta é a URL usada por usuários e aplicações clientes para acessar sites ArcGIS Server. É a URL do load balancer que gerencia o tráfego do ArcGIS Server e encaminha solicitações seja para o Web Adaptor do site server ou diretamente às máquinas server.
URL Administrativo
Esta URL é usada por administradores e internamente pelo portal para acessar um site ArcGIS Server ao realizar operações administrativas. Esta URL também é usada para publicar serviços GIS com referência a uma data store registrada, por exemplo geodatabase empresarial SQL Server, em um site server federado. Deve apontar para um load balancer; se a URL administrativa apontar para uma única máquina no site server e essa máquina estiver offline, a federação não funcionará. Pode ser a mesma URL da URL dos serviços ou pode ser um segundo load balancer (VIP) para cada URL administrativa do site server federado via porta 6443. Configurar um VIP dedicado para cada URL administrativa do site server federado via porta 6443 exigirá abrir esta porta para administradores e publicadores, e você pode desabilitar o acesso administrativo através do web adaptor, proporcionando controles adicionais de segurança para a organização.
Recomendo usar a mesma URL da URL dos serviços pois simplifica a configuração. O acesso administrativo ao ArcGIS Server será controlado pela autenticação ArcGIS Enterprise e papéis dos usuários, similarmente ao acesso administrativo ao portal, por exemplo Diretório Portal ArcGIS (portaladmin) e Configurações da Organização. Para usar a URL do web adaptor como URL administrativa, você deve habilitar o acesso administrativo no web adaptor do servidor.
URL privado do portal
Esta é uma URL interna usada pelos seus sites server para comunicar-se com o portal. Também deve apontar para um load balancer e deve ser definida antes da federação. Se você federar seus sites server antes de definir privatePortalURL, siga os passos 8 e 9 no tópico Configure an existing deployment for alta disponibilidade para atualizar a URL dentro do seu deployment. Similar à URL administrativa, esta pode ser a mesma que a URL pública para o portal (URL do contexto web do portal), ou pode ser um segundo load balancer (VIP) via porta 7443.
Para simplicidade de configuração, eu recomendaria usar a URL pública para o portal como a URL privada do portal. Se você optar por usar um load balancer VIP dedicado via porta 7443 para a URL privada do portal, você deve configurar o load balancer para verificar a saúde das máquinas do portal.
Configuração do Load Balancer
Configurações de Verificação de Saúde
A capacidade mais importante a ser usada é uma Verificação de Saúde. Conforme descrito na documentação da verificação de saúde do portal:
“A verificação de saúde informa se a máquina Portal for ArcGIS que está respondendo é capaz de receber e processar solicitações. Por exemplo, antes de criar o portal, a URL da verificação de saúde informa que o site está indisponível porque não pode aceitar solicitações naquele momento.”
O portal ArcGIS Enterprise e o server possuem verificações de saúde.
Quando você usa ArcGIS Web Adaptors, os web adaptors cuidam de realizar as verificações de saúde contra o portal e os servers. Neste caso, você pode configurar o load balancer com uma verificação básica TCP/443 ou uma verificação de página estática, com configurações padrão para timeout, gatilho de falha, intervalo de sondagem e limiar saudável.
Se você configurar o load balancer para acessar diretamente o portal e/ou os servers, por exemplo, se você não incluir web adaptors na sua arquitetura, ou se usar uma URL dedicada do load balancer para a URL privada do portal (porta 7443) ou URL administrativa federada do server (porta 6443), você deve configurar o load balancer para verificar a saúde das máquinas do portal e dos servers.
Existem algumas considerações importantes sobre as configurações da verificação de saúde no load balancer. A maioria das organizações que usam um load balancer utilizam uma página estática como sua verificação de saúde (por exemplo, index.html) para determinar se o servidor web está saudável. Este é um arquivo estático que requer apenas uma busca no disco. Além disso, a maioria dos servidores web tende a ter gargalos com I/O em vez de CPU.
No entanto, o ArcGIS Server da Esri é diferente porque nossa verificação de saúde requer uma pequena quantidade de CPU porque nossa verificação é mais do que apenas uma busca no disco, já que o software precisa determinar se certos processos estão funcionais.
Com as verificações de saúde há um valor de timeout na sondagem. A maioria dos administradores de load balancer define o valor do timeout muito baixo porque buscas no disco geralmente são muito rápidas (embora frequentemente deixem alguma margem para latência ruim na rede).
Ao usar um valor baixo de timeout com ArcGIS Server e em uma configuração multi-máquina, existe a chance de uma das máquinas exceder esse valor baixo e uma máquina saudável ser removida.
A Esri recomenda um valor maior para timeout, idealmente pelo menos 5 segundos. Dependendo do sistema, pode ser necessário aumentar ainda mais esse valor. Você deve monitorar seu ambiente e ajustar esse valor conforme necessário. Isso pode parecer um número alto para Administradores de Rede já que uma verificação em uma página simples normalmente leva menos de 10ms (mais latência da rede).
No entanto, é crítico para os load balancers distinguir entre quando uma máquina está apenas lenta versus quando ela está realmente morta e não responde. Se o portal ou server estiver realmente fora do ar e não escutando em nenhuma porta, a maioria dos load balancers detectará isso ainda antes dos 5 segundos, então esse timeout não impacta falhas "normais" onde uma máquina desaparece.
A segunda consideração é o gatilho de falha - quantas vezes a sondagem precisa falhar antes de remover a máquina do load balancer.
Como regra geral, Administradores de Rede definem o gatilho de falha para mais de 1 falha porque eles não querem que um único problema na rede derrube o sistema. Como mencionado acima, um pequeno pico no uso da CPU (comum em sistemas ArcGIS Server) pode causar timeout, e não é desejável derrubar uma máquina por causa de um único pico na CPU em uma única máquina.
A Esri realizou testes internos significativos com load balancers e descobriu que uma configuração de 5 falhas reduziu drasticamente o número de falsos positivos enquanto ainda detectava falhas reais. Descobrimos que um valor 3 ainda era altamente suscetível a falsos positivos.
A terceira consideração é o intervalo da sondagem. A Esri descobriu que intervalos de sondagem de 30 segundos, combinados com 5 falhas foram um ponto ideal para detectar falhas reais e ignorar falsos positivos.
Com essa combinação, o valor esperado (usando termo estatístico) ou tempo médio até detecção é 1 minuto e 15 segundos de downtime antes da detecção, com pior caso sendo 2 minutos e 30 segundos. É possível buscar um tempo médio menor até detecção, mas o trade-off é receber falsos positivos.
Se for preferido um tempo médio menor até detecção, pode ser necessário aumentar a capacidade para haver recursos suficientes para suportar uma falha real em uma máquina e um falso positivo sem sobrecarregar as máquinas restantes.
A configuração final relacionada às verificações de saúde é o limiar saudável para que o load balancer comece a enviar requisições novamente. A Esri não tem recomendação específica para isso e não observamos muitas diferenças nesse número, mas normalmente vemos 3 sondagens consecutivas saudáveis antes da reintegração.
Controle de Fluxo
As configurações de controle de fluxo valem ser consideradas. O ArcGIS Server é limitado pela CPU, o que significa que a maior parte do tempo da requisição é gasto usando CPU ao invés de esperar por I/O.
Isto significa que se houver 8 cores, o ArcGIS Server pode lidar com pouco mais que 8 requisições simultâneas na prática. Se o ArcGIS Server estiver ocupado, ele começa a enfileirar requisições até haver centenas na fila, e após esse limite ele recusa conexões. Quando há um grande acúmulo de requisições isso resulta em longo tempo de espera, mas eventualmente a requisição é processada.
O ArcGIS Server possui configurações para controlar esse comportamento, reduzindo essas requisições abandonadas sendo processadas, mas também é boa prática controlar isso no nível do load balancer via sua capacidade de controle de fluxo.
A Esri não tem recomendação numérica porque depende muito da arquitetura específica e dos tipos de requisições recebidas, mas tipicamente se controla fluxo em valores significativamente menores do que os administradores normalmente fariam para um servidor web.
Isto está além do controle do Administrador de Rede, mas as aplicações cliente devem ser escritas para lidar com eventos de controle de fluxo e fazer re-tentativas em intervalos crescentes (ex: na primeira vez você pode tentar imediatamente novamente, na segunda espera 1 segundo, na terceira tenta novamente esperando 5 segundos etc.).
Sessões Persistentes
A Esri não recomenda sessões persistentes exceto em circunstâncias muito raras. Sessões persistentes teoricamente podem sobrecarregar uma máquina. A Esri realizou testes de carga usando sessões persistentes para verificar se encontrávamos resultados que sobrecarregassem nosso GIS Server, e isso não ocorreu. Também não recebemos reclamações dos clientes. Dito isso, como nosso software é stateless não vemos valor em usar sessões persistentes.
Camada 4 vs. Camada 7
A configuração final a mencionar é se o load balancer faz abordagem "nível 7" ou "camada 4". Isso pode ser tema de debate entre Administradores de Rede, mas abaixo está um resumo conciso da situação descrevendo as diferenças e vantagens de cada um.
Um load balancer camada 7 entende http e https, portanto descriptografa conteúdo https e depois recriptografa. Porque entende http e https ele pode armazenar conteúdo em cache e economizar requisições ao servidor backend.
Um load balancer camada 4 vê todo tráfego como pacotes TCP e não sabe o significado dos pacotes; eles podem ser ftp, https, smtp, mas isso não importa para um load balancer camada 4. Como resultado ele não precisa entender payload http e pode ser mais rápido.
O ArcGIS Server pode funcionar com qualquer abordagem e não há recomendação sobre essa configuração para Administradores de Rede, mas há algumas informações que um Admin vai querer estar ciente.
Os payloads do ArcGIS Server podem ser muito maiores que páginas HTML, CSS e JS (a quantidade exata seria útil mas depende frequentemente dos dados usados pelo cliente). Isso significa mais carga na CPU em um load balancer camada 7 descriptografando e criptografando por requisição.
Além disso, como muitos dados do ArcGIS Server são dinâmicos e frequentemente mudam por padrão cabeçalhos cache proíbem cache no cliente e no load balancer. Se os dados mudam pouco e o cliente quiser usar um load balancer camada 7 eles podem alterar e controlar essas configurações cache.
Resumo das Recomendações
Verificação De Saúde
- Se você configurar seus load balancers com ArcGIS Web Adaptors você pode configurar o load balancer com verificação básica TCP/443 ou verificação estática contra os servidores web
- Se você configurar o load balancer para acessar diretamente portal e/ou os servers (via portas 6443 e 7443), use Ponto de verificação de integridade HTTPS:<\/SPAN>Portal:<\/SPAN>Requisição: <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
OU<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>Resposta: {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Servidor:<\/SPAN>Requisição: <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
OU<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>Resposta: {"success":true}<\/SPAN><\/LI><\/UL><\/LI>Use um valor maior para o tempo limite do health check, pelo menos 5 segundos<\/SPAN><\/LI>Use um valor de 5 para o gatilho de falha<\/SPAN><\/LI>Use intervalos de sondagem de 30 segundos<\/SPAN><\/LI>Use 3 sondagens consecutivas saudáveis antes de reintegrar<\/SPAN><\/LI><\/UL><\/LI><\/UL>Controle de taxa <\/SPAN><\/P>Use uma configuração de throttle em um valor significativamente menor que servidores web típicos<\/SPAN><\/LI><\/UL>Sessões Sticky<\/SPAN><\/P>NÃO use sessões sticky<\/SPAN><\/LI><\/UL>Certificados<\/SPAN><\/H1>Os componentes do ArcGIS Enterprise vêm pré-configurados com certificados de servidor autoassinados, o que permite que o software seja testado inicialmente e ajuda você a verificar rapidamente se sua instalação foi bem-sucedida. No entanto, em quase todos os casos, uma organização deve solicitar um certificado de uma autoridade certificadora confiável (CA) e configurar o software para usá-lo. O certificado pode ser assinado por uma CA corporativa (interna) ou comercial. CA comercial (known-CA) deve ser usada para DNS resolvível externamente, por exemplo, DNS VIP do balanceador de carga; certificados de domínio interno podem ser usados para servidores internos. <\/SPAN>
Para sistemas ArcGIS Enterprise com DNS resolvível externamente, se o método SSL do balanceador de carga for SSL-passthrough (o balanceador de carga não descriptografa nem recriptografa conteúdo https), ele não requer certificado, e um certificado CA comercial deve ser instalado nos servidores mapeados (por exemplo, servidores web onde os web adaptors estão instalados). Se o método SSL do balanceador de carga for recriptografia SSL, um certificado CA comercial deve ser instalado no balanceador de carga.<\/SPAN><\/SPAN><\/P>
.png)
