Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
No CycleCloud, o termo cluster descreve um grupo de computadores conectados (nós) trabalhando juntos como um único sistema. Os clusters podem ser aninhados. Por exemplo, um cluster de computação composto por um nó principal do planejador do Grid Engine e nós de computação pode montar um cluster BeeGFS composto por vários servidores de metadados e armazenamento. Os clusters de computação e armazenamento se agrupam em um único cluster ou sistema de HPC pai.
Nós e matrizes de nós
Os clusters compreendem fundamentalmente nós, cada um deles executa uma função específica no sistema HPC. Os termos nó e VM são ocasionalmente usados de forma intercambiável, mas são semanticamente separados no CycleCloud. Os nós que compõem um cluster são máquinas virtuais no Azure que completam o processo de preparação e configuração. Em outras palavras, você cria VMs das camadas de serviço de infraestrutura do Azure. Depois de instalar o software e concluir as etapas de configuração, as VMs são nós de um cluster HPC.
O CycleCloud tem dois tipos de nós: nós autônomos e matrizes de nós. Uma matriz de nós é uma coleção de nós configurados de forma idêntica. A distinção entre nós e matriz de nós segue a analogia DevOps Pets vs Cattle. Nós autônomos são construídos a partir de VMs únicas no Azure. Os conjuntos de nós são mapeados para conjuntos de escala de máquina virtual.
No entanto, há diferenças cruciais entre matrizes de nós e conjuntos de dimensionamento de máquinas virtuais. Uma única matriz de nós pode compreender vários conjuntos de dimensionamento de máquinas virtuais. Essa configuração permite que uma única matriz de nós seja criada a partir de VMs de tamanhos diferentes ou até mesmo famílias de VM diferentes. A única restrição é que todos os nós em uma matriz de nós executam a mesma função no cluster. Por exemplo, todos os nós fornecem recursos para uma única fila de um agendador.
Modelos de cluster
Defina a topologia ou como os nós são organizados em um cluster cycleCloud, em modelos de texto. Os modelos estabelecem as relações entre nós de um cluster. Se houver clusters aninhados, os modelos definirão o relacionamento pai-filho dos clusters. Os modelos também definem a função de cada nó.
Defina modelos de cluster no formato INI. Use seções delineadas com colchetes [e ] para definir clusters, nós e matrizes de nós. Os elementos básicos dos arquivos INI são declarações de par chave-valor que fornecem os detalhes de configuração de cada seção. Esses detalhes de configuração fornecem informações contextuais para criar cada nó de um cluster, como a imagem da máquina virtual para inicializar a VM e a sub-rede da VM. Para obter mais informações, consulte os modelos de cluster do CycleCloud.
Preparação e configuração do nó
O CycleCloud provisiona VMs a partir de imagens de VM base definidas no modelo de cluster. Por meio de uma série de etapas gerenciadas pelo agente do CycleCloud (Jetpack) durante o processo de inicialização, ele inicializa e configura o sistema operacional na VM para convertê-lo em um nó HPC em funcionamento. Essas etapas variam de scripts para instalar e configurar o software de agendamento até a configuração de última milha para montar um sistema de arquivos.
Você pode controlar como os nós são personalizados na inicialização criando um projeto de cluster-init personalizado. Um projeto contém os scripts e outros arquivos necessários para personalizar um nó, separados em especificações para os diferentes tipos de funções em um cluster. Por exemplo, um projeto para um agendador em lotes, como o Slurm, compreende um mínimo de três especificações: uma para os nós de cabeçalho do agendador, uma para os nós de computação e outra para os nós de logon. Leia mais sobre os projetos do CycleCloud.
Na definição do nó, você faz referência às especificações que devem ser executadas nesse nó. O Jetpack usa essas especificações na inicialização para preparar um nó para a sua função no cluster. Os arquivos de especificação vêm da Conta de Armazenamento de Blobs do usuário e são preparados do servidor de aplicativos CycleCloud para a conta de armazenamento antes que os nós sejam iniciados.
Observação
As especificações para modelos internos (como o tipo de cluster Slurm) são armazenadas no GitHub. O CycleCloud os baixa automaticamente para a conta de armazenamento do usuário quando o nó é iniciado.
Quando um nó é inicializado, o Jetpack baixa as especificações definidas no nó na seção [[[cluster-init]]] e as processa para convergir o nó para um estado operacional (por exemplo, para ser um nó de computação).
Orquestração de nós
Dependendo do agendador e dos serviços usados em um cluster, o CycleCloud às vezes precisa orquestrar a fase de preparação de nós em um cluster coordenando nós diferentes. Por exemplo, alguns planejadores exigem que cada nó de computação se registre no daemon do planejador. Esse requisito significa que os nós de computação devem estar cientes do endereço do nó principal. Os nós de computação também devem reconhecer que o nó principal está totalmente preparado e esperar caso isso não aconteça.
O CycleCloud usa esse elemento de Descoberta de Serviço para relações servidor-cliente do sistema de arquivos.