Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
No CycleCloud, o termo cluster descreve um grupo de computadores (nós) interligados que trabalham em conjunto como um único sistema. Os clusters podem ser aninhados. Por exemplo, um cluster de computação que consiste em um nó principal do agendador do Grid Engine e nós de computação pode montar um cluster BeeGFS que consiste em vários metadados e servidores de armazenamento. Os clusters de computação e armazenamento unem-se sob um único cluster ou sistema HPC principal.
Nós e matrizes de nós
Os clusters compreendem fundamentalmente nós, cada um dos quais desempenha uma função específica no sistema de 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 concluem o processo de preparação e configuração. Em outras palavras, você cria VMs a partir 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 um nó e um conjunto de nós segue a analogia de DevOps entre Animais de Estimação e Gado. Os nós autônomos são construídos a partir de VMs únicas no Azure. As matrizes de nó são mapeadas para conjuntos de dimensionamento de máquina virtual.
No entanto, há diferenças cruciais entre arrays de nós e conjuntos de dimensionamento de máquinas virtuais. Uma matriz de nó único pode incluir vários conjuntos de dimensionamento de máquina virtual. Essa configuração permite que uma matriz de nó único seja criada a partir de VMs de tamanhos diferentes ou até mesmo famílias de VMs 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 do CycleCloud em modelos de texto. Os modelos estabelecem as relações entre os nós de um cluster. Se houver clusters aninhados, os modelos definem a relação hierárquica 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 asserçõ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 para a VM. Para obter mais informações, consulte Modelos de cluster do CycleCloud.
Preparação e configuração de nós
O CycleCloud provisiona VMs a partir de imagens de VM de base definidas no modelo de cluster. Através de uma série de etapas gerenciadas pelo agente 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. Esses passos variam desde scripts para instalar e configurar o software de agendamento, até a configuração final para montagem de um sistema de ficheiros.
Você pode controlar como os nós são personalizados na inicialização criando um projeto 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 de lotes como o Slurm compreende um mínimo de três especificações: uma para os nós principais do agendador, uma para os nós de computação e outra para os nós de login. Leia mais sobre os projetos 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 sua função no cluster. Os arquivos de especificação vêm da conta de armazenamento Blob do usuário e são transferidos do servidor de aplicações CycleCloud para a conta de armazenamento antes de os nós serem 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ó com a [[[cluster-init]]] seção e as processa para convergir o nó para um estado de trabalho (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 dos nós em um cluster coordenando nós diferentes. Por exemplo, alguns agendadores exigem que cada nó de computação se registre com o daemon do agendador. Este 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 aguardar caso contrário.
O CycleCloud usa esse elemento do Service Discovery para relações servidor-cliente do sistema de arquivos.