Implante o IBM Spectrum LSF com o Conector de Recursos Configurado para OCI

Resolva o problema da alocação de recursos fixos ajustando dinamicamente o número de recursos alocados para uma carga de trabalho com base na demanda real com o dimensionamento automático do conector de recursos do IBM Spectrum LSF. Otimize o uso de recursos, reduza custos e melhore a eficiência geral em ambientes de computação de alto desempenho (HPC).

O IBM Spectrum LSF (Load Sharing Facility) é uma plataforma de gerenciamento de carga de trabalho usada para ambientes de computação distribuídos. Ele permite que os usuários gerenciem e agendem trabalhos de computador em uma rede de computadores ou clusters de computação, garantindo que os trabalhos sejam concluídos de forma eficiente e sem interrupções.

O conector de recurso para o recurso IBM Spectrum LSF (anteriormente chamado de fábrica do host) permite que os clusters LSF emprestem recursos de provedores de recursos suportados. Quando a carga de trabalho é baixa, o LSF está usando o conector de recursos para reduzir o número de recursos alocados, economizando custos e melhorando a utilização. Quando a carga de trabalho é alta, mais recursos são solicitados do provedor de nuvem.

Observe que os privilégios administrativos são necessários para a implantação desta arquitetura.

Arquitetura

Essa arquitetura de referência mostra o cluster IBM Spectrum LSF implantado em uma sub-rede existente com um host principal, nós de cluster (criados sob demanda quando o conector de recursos chama a API do OCI) e o serviço bastion.

O host principal LSF requer autorização instance_principal para interagir com a API do OCI e tem uma configuração padrão (VM.Standard.E4. Flex / 2 OCPUs/ 8 GBs) que podem ser ajustados durante a criação da pilha.

O LSF resource_connector é pré-configurado para a fila dinâmica e pode solicitar da API do OCI dois tipos de recursos de computação (amd2 - VM.Standard.E3. Flex / 2 OCPUs / 4 GBs e amd4 - VM.Standard.E4. Flex / 2 OCPUs / 8 GBs) dependendo dos requisitos do job. Os modelos disponíveis para resource_connector podem ser modificados nos arquivos de configuração LSF (<lsf_top>/conf/resource_connector/oci/conf/oci_config.json e <lsf_top>/conf/resource_connector/oci/conf/ociprov_templates.json) e recarregar a configuração do cluster, recarregando a configuração do cluster usando estes comandos:

$ lsadmin reconfig
$ badmin reconfig
$ badmin mbdrestart

O número máximo padrão de hosts que resource_connector pode solicitar do OCI é oito para cada modelo disponível ( maxNumber poderá ser alterado no arquivo <lsf_top>/conf/resource_connector/oci/conf/ociprov_templates.json se mais nós forem necessários).

A abordagem de implantação recomendada está usando o link de implantação com um clique no Oracle Cloud Infrastructure Resource Manager.

O diagrama a seguir ilustra essa arquitetura de referência.



oci-ibm-lfs-arquitetura-oracle.zip

A arquitetura tem os seguintes componentes:

  • Tenancy

    Uma tenancy é uma partição segura e isolada que a Oracle configura no Oracle Cloud quando você se inscreve no Oracle Cloud Infrastructure. Você pode criar, organizar e administrar seus recursos no Oracle Cloud em sua tenancy. Uma tenancy é sinônimo de uma empresa ou organização. Normalmente, uma empresa terá uma única locação e refletirá sua estrutura organizacional dentro dessa locação. Uma única tenancy geralmente é associada a uma única assinatura, e uma única assinatura geralmente só tem uma tenancy.

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Compartimento

    Os compartimentos são partições lógicas entre regiões em uma tenancy do Oracle Cloud Infrastructure. Use compartimentos para organizar, controlar o acesso e definir metas de uso para seus recursos do Oracle Cloud. Em um determinado compartimento, você define políticas que controlam o acesso e definem privilégios para recursos.

  • Domínios de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.

  • Domínios de falha

    Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falha no servidor físico, manutenção do sistema e falhas de energia dentro de um domínio de falha.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.

  • Gateway de conversão de endereço de rede (NAT)

    Um gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet de entrada.

  • Gateway de serviço

    O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e não passa pela internet.

  • Gateway de internet

    O gateway de internet permite o tráfego entre as sub-redes públicas em uma VCN e a internet pública.

  • Serviço Bastion

    O Oracle Cloud Infrastructure Bastion fornece acesso seguro restrito e limitado por tempo a recursos que não têm pontos finais públicos e que exigem controles rígidos de acesso a recursos, como bare metal e máquinas virtuais, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE) e qualquer outro recurso que permita acesso ao Secure Shell Protocol (SSH). Com o serviço OCI Bastion, você pode permitir o acesso a hosts privados sem implantar e manter um jump host. Além disso, você ganha uma postura de segurança aprimorada com permissões baseadas em identidade e uma sessão SSH centralizada, auditada e limitada por tempo. O OCI Bastion elimina a necessidade de um IP público para acesso ao bastion, eliminando o aborrecimento e a potencial superfície de ataque ao fornecer acesso remoto.

  • Serviço IAM (Identity and Access Management)

    O Oracle Cloud Infrastructure Identity and Access Management (IAM) é o plano de controle de acesso do Oracle Cloud Infrastructure (OCI) e do Oracle Cloud Applications. A API do serviço IAM e a interface do usuário permitem gerenciar domínios de identidades e os recursos dentro do domínio de identidades. Cada domínio de identidades do OCI IAM representa uma solução de gerenciamento de identidade e acesso independente ou uma população de usuários diferente.

  • Oracle Cloud Infrastructure Resource Manager

    O OCI Resource Manager automatiza a implantação e as operações de todos os recursos do OCI. Usando o modelo infrastructure-as-code (IaC), o serviço é baseado no Terraform.

Recomendações

Use as seguintes recomendações como ponto de partida para garantir a escalabilidade e a disponibilidade do cluster LSF:Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • VCN e sub-redes

    Ao selecionar uma sub-rede existente, você precisa considerar um bloco CIDR grande o suficiente para acomodar todos os recursos de computação solicitados pelo conector de recurso LSF.

    Use sub-redes regionais (no caso de regiões com vários anúncios).

    Permita toda a comunicação dentro da sub-rede (adicione à lista de segurança da sub-rede uma regra permitindo todas as conexões de entrada do bloco CIDR da sub-rede para todas as portas de destino).

Considerações

Ao provisionar, considere os aspectos a seguir.

  • Binários LSF do IBM Spectrum

    Os binários e a licença necessária para instalar/executar LSF não estão incluídos. Esta implantação foi testada com LSF versão 10.1 e patch versão 601088.

    Antes da implantação, você pode fazer download dos arquivos abaixo do portal de suporte da IBM, carregá-los em um bucket de armazenamento de objetos do OCI e criar solicitações pré-autenticadas.

    • lsf10.1_lsfinstall.tar.Z
    • lsf10.1_lnx310-lib217-x86_64.tar.Z
    • lsf10.1_lnx310-lib217-x86_64-601088.tar.Z
    • lsf_entitlement.dat
  • VCN

    A resolução de DNS deve ser ativada para a VCN e a sub-rede usadas para o nó mestre LSF.

Implante

O código do Terraform para implantar a solução está disponível em GitHub.

  1. Vá para GitHub.
  2. Clone ou faça download do repositório para seu computador local.
  3. Siga as instruções no documento README.

Explorar Mais

Saiba mais sobre o IBM Spectrium LSF, o conector de recursos IBM Spectrium LSF e a OCI.

Revise estes recursos adicionais:

Reconhecimentos

Authors: Chandrashekar Avadhani, Andrei Ilas

Contributors: John Sulyok