CycleCloud Clusters
No CycleCloud, o termo cluster é utilizado para descrever um grupo de computadores ligados (nós) a trabalhar em conjunto como um único sistema. Os clusters podem ser aninhados; por exemplo, um cluster de computação composto por um nó principal do agendador do Motor de Grelha e nós de computação pode montar um cluster BeeGFS composto por vários metadados e servidores de armazenamento, com clusters de computação e armazenamento a agruparem-se num único cluster ou sistema HPC principal.
Nós e Matrizes de Nós
Os clusters são fundamentalmente compostos por nós, cada um dos quais desempenha uma função específica no sistema HPC. Os termos nó e VM são utilizados alternadamente ocasionalmente, mas são separados semanticamente no CycleCloud. Os nós que compõem um cluster são essencialmente máquinas virtuais no Azure que concluíram o processo de preparação e configuração. Por outras palavras, as VMs são aprovisionadas a partir das camadas do serviço de infraestrutura do Azure e os respetivos estados finais são nós de um cluster HPC depois de passarem pelos passos de instalação e configuração de software.
Existem duas encarnações separadas de nós no CycleCloud. O primeiro como nó autónomo e o segundo como uma nodearray, que é uma coleção de nós configurados de forma idêntica (a distinção nó vs. nodearray segue a analogia DevOps Pets vs Cattle em espírito). De uma forma geral, mas não estritamente falando, os nós autónomos são construídos a partir de VMs individuais no Azure, enquanto os nós mapeiam para conjuntos de dimensionamento de Máquinas Virtuais (VMSS).
No entanto, existem diferenças cruciais entre as matrizes de nós e os conjuntos de dimensionamento de VMs, sendo que a principal é que uma única matriz de nós pode ser composta por vários conjuntos de dimensionamento de VMs. Isto permite que uma única matriz de nós seja compilada a partir de VMs de tamanhos de diferença ou até mesmo famílias de VMs diferentes, sendo que a única restrição é que todos os nós numa matriz de nós desempenham a mesma função no cluster, por exemplo, fornecendo recursos a uma fila única de um agendador.
Modelos de Cluster
A topologia, ou a forma como os nós são organizados num cluster do CycleCloud, são definidos em modelos de texto que estabelecem as relações entre nós de um cluster e, no caso dos clusters aninhados, a relação principal-subordinado dos clusters. Os modelos também fornecem a forma de definir a função que cada nó desempenha.
Os modelos de cluster são definidos num formato INI. As secções, delineadas com parênteses retos, são utilizadas []para definir clusters, nós e nós. O elemento básico dos ficheiros INI são asserções de par chave-valor que fornecem os detalhes de configuração de cada secção. Estes detalhes de configuração fornecem informações contextuais utilizadas para criar cada nó de um cluster, a partir da imagem da máquina virtual utilizada para arrancar a VM para a sub-rede na qual a VM deve ser aprovisionada. Leia mais sobre os modelos de cluster do CycleCloud
Preparação e Configuração de Nós
O CycleCloud aprovisiona VMs a partir de imagens de VM base definidas no modelo de cluster e através de uma série de passos geridos pelo agente CycleCloud (Jetpack) durante o processo de arranque, inicializa e configura o SO na VM para convertê-lo num nó HPC funcional. Estes passos vão desde scripts até à instalação e configuração do software de agendamento até à configuração de última milha para montar um sistema de ficheiros.
Definidas na secção de configuração de cada nó são especificações init de cluster – especificações fornecidas a cada VM de arranque que são utilizadas para prepará-la para uma função específica no cluster. O CycleCloud utiliza o Chef como plataforma de automatização de infraestrutura para preparar e configurar cada nó. Essencialmente, cada especificação do cluster-init mapeia para uma das mais Funções de Chef e/ou Receitas de Livro de Receitas que precisam de ser executadas na VM de arranque.
O CycleCloud utiliza o Chef num modo autónomo que não depende de um servidor Chef centralizado. Em vez disso, todo o conjunto de Guias de Receitas do Chef necessários para preparar cada VM é transferido a partir de uma Conta de Armazenamento do Azure pertencente ao utilizador durante a fase de arranque da VM. Este conjunto de Livros de Receitas é colocado em cache a partir do servidor de aplicações CycleCloud para a Conta de Armazenamento durante a fase de criação do cluster.
Depois de transferir estes Livros de Receitas, o Chef processa a lista de Receitas definidas nas especificações do cluster-init do nó, acionando uma fase de preparação e configuração que converte a VM num nó HPC em funcionamento.
As especificações são criadas como coleções lógicas denominadas Projetos. Por exemplo, um projeto para um agendador de lotes, como o Slurm, inclui um mínimo de duas especificações: um para os nós principais do agendador e o outro para os nós de computação. Leia mais sobre os Projetos CycleCloud
Orquestração de Nós
Consoante o agendador e os serviços utilizados num cluster, por vezes o CycleCloud tem de orquestrar a fase de preparação dos nós num cluster através da coordenação de diferentes nós. Por exemplo, alguns agendadores exigem que cada nó de computação se registe no daemon do agendador, o que não só exige que os nós de computação estejam cientes do endereço do nó principal, como também conseguem reconhecer que o nó principal está totalmente preparado e aguardar se não estiver.
Este elemento da Deteção de Serviços também é utilizado para relações servidor-cliente do Sistema de Ficheiros e é uma funcionalidade no CycleCloud.