Etapa 1: Criar uma verificação de integridade (opcional)

As verificações de funcionamento são anexos opcionais para conjuntos de origem. Eles são executados em um intervalo configurável para verificar um corpo de resposta ou código de status específico e monitorar a integridade do pool. Depois de criar uma verificação de funcionamento, é possível incluí-la em um conjunto de origem novo ou existente.

Se você não definir nenhuma verificação de integridade personalizada, o CIS usa / como seu caminho padrão para a verificação de integridade.

1. No console CIS, clique em Confiabilidade > Balanceadores de carga globais > Verificações de integridade e, em seguida, clique em Criar.

2. Configure os seguintes campos:

   • Nome: Nome do exame de saúde.
   • Tipo de monitor: o protocolo a ser usado para a verificação de funcionamento. (Padrão: HTTP).
   • Porta: Clique nas setas para aumentar ou diminuir o número da porta.
   • Caminho: O caminho do endpoint no qual deve ser realizada a verificação de integridade. (Padrão: /)

3. Expanda as opções avançadas para configurar:

   • Intervalo de teste: o intervalo (em segundos) entre cada verificação de funcionamento. Intervalos mais curtos podem melhorar o tempo de failover, mas aumentam a carga nos servidores de origem, já que as verificações são feitas a partir de vários locais. (Padrão: 60).
   • Método: O método HTTP a ser utilizado para a verificação de integridade. (Padrão: GET)
   • Tempo limite (segundos): O tempo antes de marcar a verificação de integridade como falha. (Padrão: 5)
   • Número de tentativas: O número de tentativas a serem realizadas caso ocorra um tempo limite, antes de marcar a origem como inativa. CIS tentativas de nova tentativa imediatamente. (Padrão: 2)
   • Códigos de resposta esperados: O código de resposta esperado HTTP ou o intervalo de códigos da verificação de integridade. Esse valor deve estar entre 200 e 299, com caracteres curinga indicados por x.
   • Corpo da resposta: Uma subcadeia de caracteres (sem distinção entre maiúsculas e minúsculas) a ser comparada com o corpo da resposta. Se o site CIS não encontrar essa cadeia de caracteres, ele marcará a origem como não saudável.
   • Limite de integridade: O número de respostas consecutivas bem-sucedidas de verificação de integridade que o site CIS deve receber antes de marcar uma origem como íntegra. Essa configuração impede que o CIS marque uma origem saudável após uma única sonda bem-sucedida e ajuda a evitar oscilações durante a recuperação intermitente. (Padrão: 1)
   • Limite de insalubridade: O número de respostas consecutivas de verificação de integridade com falha que deve ocorrer antes que o site CIS marque uma origem como não saudável. Essa configuração ajuda a evitar que problemas temporários de rede ou de aplicativos acionem imediatamente o failover. (Padrão: 1)
   • Seguir redirecionamentos: Determina se a verificação de integridade segue automaticamente as respostas de redirecionamento do HTTP 3xx. Quando ativada, a verificação de integridade continua até o local redirecionado e avalia a resposta final em relação aos critérios de sucesso configurados (código de status e corpo de resposta opcional). Quando desativado, as respostas de redirecionamento são avaliadas diretamente em relação aos códigos de resposta esperados.

4. Expanda “Configurar cabeçalhos de solicitação (opcional) ” para adicionar e configurar os cabeçalhos de solicitação d HTTP, a serem enviados na verificação de integridade.

   Definir um cabeçalho “Host” como padrão. O cabeçalho User-Agent não pode ser substituído.

5. Clique em Criar para concluir sua configuração de verificação de funcionamento.

Etapa 2: Criar um pool de origem

Pelo menos um conjunto é necessário para cada balanceador de carga provisionado. Agrupa as origens para que o balanceador de carga as utilize.

1. No console CIS, clique em Confiabilidade > Balanceadores de carga globais > Pools de origem e, em seguida, clique em Criar.

2. Selecione se deseja ativar esse pool. As piscinas para deficientes não recebem tráfego e o site CIS as exclui dos controles de saúde. Quando você desativa um pool, todos os balanceadores de carga que o utilizam passam para o próximo pool, se houver.

3. Configure os campos obrigatórios:

   • Nome: um nome abreviado (tag) para o conjunto. Apenas caracteres alfanuméricos, hifens e sublinhados são permitidos.
   • Origens: a lista de origens dentro desse conjunto. CIS distribui o tráfego direcionado a esse pool entre todas as origens que estão em bom estado no momento, desde que o próprio pool esteja em bom estado.

   Se seus servidores de aplicativos estiverem atrás de um balanceador de carga local, como um balanceador de carga do tipo “ IBM Cloud ”, adicione o FQDN ou o IP virtual do seu balanceador de carga como origem, em vez de adicionar seus servidores individualmente.

4. Configure os campos opcionais conforme necessário:

   • Limite de origens operantes: o número mínimo de origens que devem estar operantes para esse conjunto servir o tráfego. Se o número de origens em bom estado cair abaixo desse número, o CIS marca o pool como em mau estado e realiza a failover para o próximo pool disponível. (Padrão: 1)
   • Região de verificação de integridade do pool: Região na qual a verificação de integridade realiza o monitoramento.
   • Verificação de funcionamento: a verificação de funcionamento a ser usada para verificar as origens dentro desse conjunto. (Padrão: sem verificação de integridade )

5. Clique em Save (Salvar ) para concluir a configuração do pool de origem.

O conjunto de origem aparece inicialmente como Não funcional. Esse estado passa para “São” após uma verificação de integridade bem-sucedida realizada por CIS. Pode ser necessário atualizar seu navegador para ver a mudança de estado.

Defina tantos conjuntos de origem quanto o número de farms de aplicativos que você possui. Essas farms podem estar dentro das mesmas ou diferentes regiões geográficas.

Etapa 3: Configurar o balanceador de carga global

Os balanceadores de carga ajudam a distribuir o tráfego entre vários conjuntos de servidores de origem.

1. No console CIS, clique em Confiabilidade > Balanceadores de carga globais > Balanceadores de carga e, em seguida, clique em Criar.

2. Habilite o balanceador de carga.

3. Para o Proxy, verifique se o tráfego passa pelas funções de segurança e desempenho em CIS. 'Desligado' ignora esses sistemas.

4. Configure as seguintes informações:

   • Nome (opcional): O nome a ser associado ao seu balanceador de carga.

   • TTL: Tempo de Vida (TTL) da entrada de DNS para o endereço IP retornado por esse balanceador de carga. Essa opção se aplicará somente ao balanceador de carga sem proxy; caso contrário, ela será padronizada para Automatic.

   • Direcionamento de tráfego: Controla como as solicitações de entrada de usuários são distribuídas entre os pools de origem configurados, determinando o algoritmo que o CIS usa para decidir qual data center (pool) atende a cada solicitação. Para obter mais informações, consulte Otimização do direcionamento do tráfego.

   • Afinidade de sessão: sempre rotear por meio da mesma instância de desempenho e métricas. Essa opção está disponível apenas se o proxy estiver ativado.

   • Rotas geográficas: Um mapeamento de códigos de região ou país para uma lista de pools (ordenados por sua prioridade de failover) para a região especificada. Quaisquer regiões não definidas explicitamente efetuam fallback para usar os conjuntos padrão.

     IBM são diferentes das regiões geográficas usadas pelo site CIS. Para obter detalhes sobre as regiões geográficas, consulte Direção geográfica.

5. Clique em “Criar” para concluir a configuração do balanceador de carga global.

Etapa 4: Verificar a conectividade

Por fim, verifique a conectividade com o seu aplicativo acessando o FQDN URL em um navegador.

Para obter mais informações sobre como atualizar e excluir balanceadores de carga globais, verificações de integridade e pools de origem no console, consulte Gerenciamento de balanceadores de carga globais.

Etapa 1: criação de uma verificação de integridade na CLI (opcional)

As verificações de funcionamento são anexos opcionais para conjuntos de origem. Se você não definir nenhuma verificação de integridade personalizada, o sistema utilizará / como seu caminho padrão para a verificação de integridade.

Para criar uma verificação de integridade a partir da CLI, execute o seguinte comando:

ibmcloud cis glb-monitor-create (--json @JSON_FILE | JSON_STRING) [-i, --instance INSTANCE] [--output FORMAT]

Em que:

--json

O arquivo JSON ou a cadeia de caracteres JSON que é usada para descrever uma verificação de integridade. Obrigatório.

• Os campos obrigatórios em dados JSON são type.
  • type: O protocolo a ser utilizado para a verificação de integridade. Os valores válidos são HTTP, HTTPS e TCP.
• Os campos opcionais são description, timeout, retries, interval.
  • description: Uma descrição da avaliação de saúde.
  • timeout: O tempo de espera (em segundos) antes de marcar a verificação de integridade como malsucedida.
  • retries: O número de tentativas a serem realizadas caso ocorra um tempo limite antes que a origem seja marcada como inativa.
  • interval: O intervalo entre cada verificação de saúde.
• Para TCP, digite verificação de funcionamento. Os campos adicionais obrigatórios são port.
  • port: A porta do serviço “ TCP ” a ser utilizada para a verificação de integridade.
• Para HTTP/HTTPS, digite verificação de funcionamento. Os campos de opção adicionais são port, expected_body, expected_codes, method, path, header, follow_redirects, allow_insecure.
  • port: A porta do serviço “ TCP ” a ser utilizada para a verificação de integridade.
  • expected_body: Uma subsequência, sem distinção entre maiúsculas e minúsculas, a ser procurada no corpo da resposta.
  • expected_codes: O código de resposta HTTP esperado ou o intervalo de códigos para a verificação de integridade.
  • method: O método HTTP a ser utilizado para a verificação de integridade.
  • path: O caminho do endpoint a ser verificado.
  • header: Os cabeçalhos de solicitação HTTP a serem enviados na verificação de integridade.
  • follow_redirects: Siga os redirecionamentos, caso sejam retornados pelo servidor de origem.
  • allow_insecure: Não valide o certificado quando o monitor utilizar o HTTPS.
  • probe_zone: Atribua este monitor para emular a zona especificada durante o teste.

Dados JSON de amostra:

Para HTTP/HTTPS:

{
  "description": "Health monitor of web service",
  "type": "https",
  "method": "GET",
  "path": "/health",
  "header": {
     "Host": [
        "example.com"
     ],
     "X-App-ID": [
        "abc123"
     ]
  },
  "timeout": 5,
  "retries": 2,
  "interval": 90,
  "follow_redirects": true,
  "allow_insecure": false,
  "expected_codes": "2xx",
  "expected_body": "alive",
  "probe_zone": "example.com"
}

Para TCP:

{
  "description": "Health monitor of TCP",
  "type": "tcp",
  "port": 80,
  "timeout": 5,
  "retries": 2,
  "interval": 90
}

-i, --instance

O ID ou o nome da instância. Se você não definir o nome ou a ID da instância, o comando usará a instância de contexto (ibmcloud cis instance-set INSTANCE).

--output

O formato de saída. Atualmente, json é o único valor compatível.

Etapa 2: criação de um pool de origem a partir da CLI

Para criar um pool de origem pela CLI, execute o seguinte comando:

ibmcloud cis glb-pool-create (--json @JSON_FILE | JSON_STRING) [-i, --instance INSTANCE] [--output FORMAT]

Em que:

--json

O arquivo JSON ou a string JSON utilizada para descrever um conjunto de origens. Obrigatório.

• Os campos obrigatórios nos dados JSON são name, origins e check_regions:
  • name: Um nome abreviado (tag) para o pool.
  • origins: Uma lista de origens contidas nesse conjunto.
  • check_regions: Uma lista de códigos de regiões geográficas.
• Os campos opcionais são description, minimum_origins, enabled, monitor.

Dados JSON de amostra:

{
   "name": "us-pool",
   "description": "application server pool in US",
   "origins": [
      {
            "name": "us-app-dal01",
            "address": "1.1.1.1",
            "enabled": true,
            "header": {
               "host": ["test.com"]
            }
      },
      {
            "name": "us-app-dal02",
            "address": "2.2.2.2",
            "enabled": true,
            "header": {
               "host": ["example.com"]
            }
      }
   ],
   "minimum_origins": 1,
   "check_regions": [ "WNAM" ],
   "monitor": "f1aba936b94213e5b8dca0c0dbf1f9cc",
   "enabled": true
}

-i, --instance

O ID ou o nome da instância. Se você não definir o nome ou a ID da instância, o comando usará a instância de contexto (ibmcloud cis instance-set INSTANCE).

--output

O formato de saída. Atualmente, json é o único valor compatível.

Etapa 3: Criação de um balanceador de carga global a partir da CLI

Para criar um balanceador de carga global pela CLI, execute o seguinte comando:

cis glb-create DNS_DOMAIN_ID (--json @JSON_FILE | JSON_STRING) [-i, --instance INSTANCE] [--output FORMAT]

Em que:

DNS_DOMAIN_ID

A ID do domínio DNS. Obrigatório.

--json

O arquivo JSON ou a string JSON utilizada para descrever um balanceador de carga global. Obrigatório.

• Os campos obrigatórios nos dados JSON são name, fallback_pool e default_pools:
  • name: O nome de host DNS a ser associado ao seu balanceador de carga.
  • fallback_pool iD do pool a ser usado quando o site CIS detectar que todos os outros pools não estão saudáveis.
  • default_pools: Uma lista de IDs de pool ordenados por sua prioridade de failover.
• Os campos opcionais são description, ttl, region_pools, proxied, enabled, session_affinity, session_affinity_ttl, steering_policy:
  • description: Uma descrição do seu balanceador de carga.
  • ttl: Tempo de vida (TTL) da entrada DNS correspondente ao endereço IP que este balanceador de carga retorna.
  • region_pools: Uma correspondência entre os códigos de região e de país e uma lista de IDs de pool (ordenados por sua prioridade de failover) para a região.
  • proxied: Controle se o tráfego passa pelas funções de segurança e desempenho no CIS.
  • enabled: Se deseja ativar (opção padrão) este balanceador de carga.
  • session_affinity ajuda a garantir que o CIS direcione consistentemente as solicitações de um usuário para o mesmo servidor de back-end durante uma sessão. Os valores válidos são cookie e none.
  • session_affinity_ttl cookie de afinidade de sessão: Tempo, em segundos, até que o cookie de afinidade de sessão desse balanceador de carga expire depois que CIS o criar. O valor válido está entre [1800, 604800]. O valor padrão é 82800.
  • steering_policy : Os valores válidos para steering_policy são off, ` `geo, random e ` `dynamic_latency.
    • off: Use default_pools.
    • geo: Use region_pools/pop_pools.
    • random: Selecione um grupo aleatoriamente.
    • dynamic_latency: Use o tempo de ida e volta para selecionar o pool mais próximo em default_pools (requer verificações de integridade do pool).

Dados JSON de amostra:

{
      "name": "www.example.com",
      "fallback_pool": "17b5962d775c646f3f9725cbc7a53df4",
      "default_pools": [
         "17b5962d775c646f3f9725cbc7a53df4",
         "9290f38c5d07c2e2f4df57b1f61d4196"
      ],
      "description": "Example global load balancer.",
      "ttl": 60,
      "region_pools": {
         "WNAM": [
               "de90f38ced07c2e2f4df50b1f61d4194",
               "9290f38c5d07c2e2f4df57b1f61d4196"
         ],
         "ENAM": [
               "00920f38ce07c2e2f4df50b1f61d4194"
         ]
      }
}

-i, --instance

O ID ou o nome da instância. Se você não definir o nome ou a ID da instância, o comando usará a instância de contexto (ibmcloud cis instance-set INSTANCE).

--output

O formato de saída. Atualmente, json é o único valor compatível.

Para obter mais informações sobre como criar, atualizar e excluir balanceadores de carga globais, verificações de integridade e pools de origem, consulte Comandos da CLI do balanceador de carga global.

Etapa 1: criação de um controle de integridade com a API (opcional)

As verificações de funcionamento são anexos opcionais para conjuntos de origem. Se você não definir nenhuma verificação de integridade personalizada, o sistema utilizará / como seu caminho padrão para a verificação de integridade.

Siga estas etapas para criar um controle de integridade com a API:

1. Configure seu ambiente de API com as variáveis corretas.
2. Armazene o valor a seguir nas variáveis a serem utilizadas no comando da API:

CRN: o CRN completo codificado por url da instância de serviço.

1. Quando todas as variáveis estiverem inicializadas, crie a verificação de integridade:

   curl -X POST https://api.cis.cloud.ibm.com/v1/:crn/load_balancers/monitors
     -H 'content-type: application/json'
     -H 'x-auth-user-token: Bearer xxxxxx'
     -d '{
       "description": "",
       "type": "http",
       "interval": 60,
       "retries": 2,
       "timeout": 5,
       "expected_body": "",
       "expected_codes": "200",
       "follow_redirects": true,
       "allow_insecure": false,
       "path": "/status",
       "header": {
    	   "Host": ["www.example.com"],
    	   "X-App-ID": ["abc123"]
       },
       "method": "GET"
   }'
   

Etapa 2: Criação de um pool de origem com a API

Siga estas etapas para criar um pool de origem com a API:

1. Configure seu ambiente de API com as variáveis corretas.
2. Armazene o valor a seguir nas variáveis a serem utilizadas no comando da API:

CRN: o CRN completo codificado por url da instância de serviço.

1. Quando todas as variáveis estiverem inicializadas, crie o pool de origem:

   curl -X POST https://api.cis.cloud.ibm.com/v1/:crn/load_balancers/pools
     -H 'content-type: application/json'
     -H 'x-auth-user-token: Bearer xxxxxx'
     -d '{
       "description": "",
       "enabled": true,
       "minimum_origins": 1,
       "monitor": "92859a0f6b4d3e55b953e0e29bb96338",
       "name": "eu-pool",
       "notification_email": "",
       "check_regions": [
           "EEU"
       ],
       "origins": [
           {
               "name": "eu-origin1",
               "address": "150.0.0.1",
               "enabled": true,
               "weight": 1
           },
           {
               "name": "eu-origin2",
               "address": "150.0.0.2",
               "enabled": true,
               "weight": 1
           }
       ]
   }'
   

Etapa 3: Criação de um balanceador de carga global com a API

Siga estas etapas para criar um balanceador de carga global com a API:

1. Configure seu ambiente de API com as variáveis corretas.
2. Armazene os valores a seguir nas variáveis a serem usadas no comando da API:

CRN: o CRN completo codificado por url da instância de serviço.

ZONE_ID: o ID de domínio.

1. Quando todas as variáveis forem iniciadas, crie os balanceadores de carga globais:

   curl -X POST https://api.cis.cloud.ibm.com/v1/:crn/zones/:zone_id/load_balancers
     -H 'content-type: application/json'
     -H 'x-auth-user-token: Bearer xxxxxx'
     -d '{
       "description": "",
       "proxied": true,
       "enabled": true,
       "name": "www.example.com",
       "session_affinity": "none",
       "session_affinity_ttl": 5000,
       "steering_policy": "geo",
       "fallback_pool": "4112ba6c2974ec43886f90736968e838",
       "default_pools": [
        "6563ebae141638f92ebbdc4a821bef8c",
        "4112ba6c2974ec43886f90736968e838"
       ],
       "pop_pools": {},
       "region_pools": {
           "EEU": [
               "4112ba6c2974ec43886f90736968e838"
           ],
           "ENAM": [
               "6563ebae141638f92ebbdc4a821bef8c"
           ],
           "WEU": [
               "4112ba6c2974ec43886f90736968e838"
           ],
           "WNAM": [
               "6563ebae141638f92ebbdc4a821bef8c"
           ]
       }
   }'
   

Para obter mais informações sobre como criar, atualizar e excluir balanceadores de carga globais, verificações de integridade e pools de origem, consulte API Global load balancer.

Etapa 1: criar uma verificação de integridade com o Terraform (opcional)

As verificações de funcionamento são anexos opcionais para conjuntos de origem. Se você não definir nenhuma verificação de integridade personalizada, o sistema utilizará / como seu caminho padrão para a verificação de integridade.

Para criar uma verificação de integridade com o Terraform, use o recurso ibm_cis_healthcheck:

resource "ibm_cis_healthcheck" "health_check" {
  cis_id         = ibm_cis.instance.id
  description    = "Health check for web servers"
  expected_body  = "alive"
  expected_codes = "200"
  method         = "GET"
  timeout        = 5
  path           = "/health"
  interval       = 60
  retries        = 2
  type           = "http"
  port           = 80
  allow_insecure = false
  follow_redirects = true
}

Etapa 2: Criando um pool de origem com o Terraform

Para criar um pool de origem com o Terraform, use o recurso ibm_cis_origin_pool:

resource "ibm_cis_origin_pool" "origin_pool" {
  cis_id = ibm_cis.instance.id
  name   = "us-pool"
  origins {
    name    = "us-app-dal01"
    address = "1.1.1.1"
    enabled = true
  }
  origins {
    name    = "us-app-dal02"
    address = "2.2.2.2"
    enabled = true
  }
  description        = "Application server pool in US"
  enabled            = true
  minimum_origins    = 1
  monitor            = ibm_cis_healthcheck.health_check.id
  notification_email = ""
  check_regions = [
    "WNAM"
  ]
}

Etapa 3: Criação de um balanceador de carga global com o Terraform

Para criar um balanceador de carga global com o Terraform, use o recurso ibm_cis_global_load_balancer:

resource "ibm_cis_global_load_balancer" "global_load_balancer" {
  cis_id           = ibm_cis.instance.id
  domain_id        = ibm_cis_domain.domain.id
  name             = "www.example.com"
  fallback_pool_id = ibm_cis_origin_pool.origin_pool.id
  default_pool_ids = [
    ibm_cis_origin_pool.origin_pool.id
  ]
  description      = "Global load balancer for example.com"
  proxied          = true
  enabled          = true
  session_affinity = "cookie"
  steering_policy  = "geo"
  pop_pools {
    pop = "LAX"
    pool_ids = [
      ibm_cis_origin_pool.origin_pool.id
    ]
  }
  region_pools {
    region = "WNAM"
    pool_ids = [
      ibm_cis_origin_pool.origin_pool.id
    ]
  }
}

Para obter mais informações sobre os recursos do Terraform para balanceadores de carga globais, verificações de integridade e pools de origem, consulte os seguintes recursos no registro do Terraform do provedor IBM Cloud:

• ibm_cis_healthcheck
• ibm_cis_origin_pool
• ibm_cis_global_load_balancer