Skip to main content
How to enable StorageGRID in your environment
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Saiba mais sobre balanceadores de carga do gerenciador de tráfego local

Colaboradores
PDFs

Explore as orientações para balanceadores de carga do gerenciador de tráfego local e determine a configuração ideal.

O seguinte é apresentado como orientação geral para a configuração de balanceadores de carga de terceiros. Trabalhe com o administrador do balanceador de carga para determinar a configuração ideal para o seu ambiente.

Crie um grupo de recursos de nós de storage

Agrupe os nós de storage do StorageGRID em um pool de recursos ou grupo de serviços (a terminologia pode ser diferente com balanceadores de carga específicos). Os nós de storage do StorageGRID apresentam a API S3 nas seguintes portas:

  • S3 HTTPS: 18082

  • S3 HTTP: 18084

A maioria dos clientes escolhe apresentar as APIs no servidor virtual através das portas HTTPS e HTTP padrão (443 e 80).

Observação Cada local do StorageGRID requer um padrão de três nós de storage, dois dos quais precisam estar íntegros.

Verificação de integridade

Balanceadores de carga de terceiros exigem um método para determinar a integridade de cada nó e sua qualificação para receber tráfego. O NetApp recomenda o método HTTP OPTIONS para executar a verificação de integridade. O balanceador de carga emite solicitações HTTP OPTIONS para cada nó de armazenamento individual e espera uma 200 resposta de status.

Se qualquer nó de storage não fornecer 200 uma resposta, esse nó não poderá atender às solicitações de storage. Seus requisitos de aplicativos e negócios devem determinar o tempo limite para essas verificações e a ação que o balanceador de carga realiza.

Por exemplo, se três de quatro nós de storage no data center 1 estiverem inoperantes, você poderá direcionar todo o tráfego para o data center 2.

O intervalo de polling recomendado é uma vez por segundo, marcando o nó off-line após três verificações falhadas.

S3 exemplo de verificação de integridade

No exemplo a seguir, nós enviamos OPTIONS e verificamos para 200 OK. Usamos OPTIONS porque o Amazon S3) não oferece suporte a solicitações não autorizadas.

curl -X OPTIONS https://10.63.174.75:18082 --verbose --insecure
* Rebuilt URL to: https://10.63.174.75:18082/
*   Trying 10.63.174.75...
* TCP_NODELAY set
* Connected to 10.63.174.75 (10.63.174.75) port 18082 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: webscale.stl.netapp.com
* Server certificate: NetApp Corp Issuing CA 1
* Server certificate: NetApp Corp Root CA
> OPTIONS / HTTP/1.1
> Host: 10.63.174.75:18082
> User-Agent: curl/7.51.0
> Accept: /
>
< HTTP/1.1 200 OK
< Date: Mon, 22 May 2017 15:17:30 GMT
< Connection: KEEP-ALIVE
< Server: StorageGRID/10.4.0
< x-amz-request-id: 3023514741

Verificações de integridade baseadas em arquivo ou conteúdo

Em geral, o NetApp não recomenda verificações de integridade baseadas em arquivos. Normalmente, um pequeno arquivo —healthcheck.htm, por exemplo, é criado em um bucket com uma política somente leitura. Esse arquivo é então buscado e avaliado pelo balanceador de carga. Esta abordagem tem várias desvantagens:

  • Dependente de uma única conta. Se a conta proprietária do arquivo estiver desativada, a verificação de integridade falhará e nenhuma solicitação de armazenamento será processada.

  • Regras de proteção de dados. O esquema de proteção de dados padrão é uma abordagem de duas cópias. Nesse cenário, se os dois nós de storage que hospedam o arquivo de verificação de integridade não estiverem disponíveis, a verificação de integridade falhará e as solicitações de armazenamento não serão enviadas para nós de storage íntegros, tornando a grade off-line.

  • * Registo de auditoria bloat.* O balanceador de carga obtém o arquivo de cada nó de storage a cada X minutos, criando muitas entradas de log de auditoria.

  • Recurso intensivo. Buscar o arquivo de verificação de integridade de cada nó a cada poucos segundos consome recursos de rede e grade.

Se for necessária uma verificação de integridade baseada em conteúdo, use um locatário dedicado com um bucket S3 dedicado.

Persistência da sessão

Persistência da sessão, ou stickiness, refere-se ao tempo que uma determinada sessão HTTP é permitida para persistir. Por padrão, as sessões são descartadas pelos nós de storage após 10 minutos. Persistência mais longa pode levar a uma melhor performance porque as aplicações não precisam restabelecer as sessões para cada ação. No entanto, manter essas sessões abertas consome recursos. Se você determinar que seu workload se beneficiará, poderá reduzir a persistência da sessão em um balanceador de carga de terceiros.

Endereçamento virtual em estilo hospedado

O estilo hospedado virtual agora é o método padrão para o AWS S3 e, embora o StorageGRID e muitos aplicativos ainda ofereçam suporte ao estilo de caminho, é prática recomendada implementar suporte virtual ao estilo hospedado. As solicitações virtuais de estilo hospedado têm o intervalo como parte do nome do host.

Para oferecer suporte ao estilo virtual hospedado, faça o seguinte:

  • Suporte a pesquisas de DNS curinga: *.s3.company.com

  • Use um certificado SSL com nomes alt de assunto para suportar curinga: *.s3.company.com alguns clientes expressaram preocupações de segurança em relação ao uso de certificados curinga. O StorageGRID continua a suportar o acesso ao estilo de caminho, assim como os principais aplicativos, como o FabricPool. Dito isto, certas chamadas de API do S3 falham ou se comportam de maneira inadequada sem suporte virtual hospedado.

Terminação SSL

Há benefícios de segurança para o encerramento SSL em balanceadores de carga de terceiros. Se o balanceador de carga estiver comprometido, a grade será compartimentada.

Existem três configurações compatíveis:

  • * SSL pass-through.* O certificado SSL é instalado no StorageGRID como um certificado de servidor personalizado.

  • * Terminação SSL e re-criptografia (recomendado).* Isso pode ser benéfico se você já estiver fazendo gerenciamento de certificados SSL no balanceador de carga em vez de instalar o certificado SSL no StorageGRID. Essa configuração fornece o benefício de segurança adicional de limitar a superfície de ataque ao balanceador de carga.

  • * Terminação SSL com HTTP.* Nesta configuração, o SSL é encerrado no balanceador de carga de terceiros e a comunicação do balanceador de carga para o StorageGRID não é criptografada para aproveitar o SSL off-load (com bibliotecas SSL incorporadas em processadores modernos, isso é de benefício limitado).

Passe pela configuração

Se preferir configurar o balanceador de carga para passagem, instale o certificado no StorageGRID. Aceda ao Configuração › certificados de servidor › Object Storage API Service Endpoints Server Certificate.

Visibilidade IP do cliente de origem

O StorageGRID 11,4 introduziu o conceito de um balanceador de carga confiável de terceiros. Para encaminhar o IP do aplicativo cliente para o StorageGRID, você deve configurar esse recurso. Para obter mais informações, consulte "Como configurar o StorageGRID para funcionar com balanceadores de carga de camada 7 de terceiros."

Para permitir que o cabeçalho XFF seja usado para exibir o IP do aplicativo cliente, siga estas etapas:

Passos

  1. Registre o IP do cliente no log de auditoria.

  2. Use aws:SourceIp a política de grupo ou bucket do S3.

Estratégias de balanceamento de carga

A maioria das soluções de balanceamento de carga oferece várias estratégias para balanceamento de carga. As seguintes estratégias são comuns:

  • Round robin. Um ajuste universal, mas sofre com poucos nós e grandes transferências obstruindo nós únicos.

  • Menor conexão. Uma boa opção para cargas de trabalho de objetos pequenos e mistos, resultando em uma distribuição igual das conexões para todos os nós.

A escolha do algoritmo se torna menos importante com um número cada vez maior de nós de storage para escolher.

Caminho de dados

Todos os dados fluem através de balanceadores de carga do gerenciador de tráfego local. O StorageGRID não suporta roteamento direto de servidor (DSR).

Verificando a distribuição das conexões

Para verificar se seu método está distribuindo a carga uniformemente entre nós de storage, verifique as sessões estabelecidas em cada nó em um determinado local:

  • Método UI. Aceda ao Support › Metrics › S3 Overview › LDR HTTP Sessions

  • Metrics API. Utilização storagegrid_http_sessions_incoming_currently_established