Modelos de cluster

  • Artigo

O Azure CycleCloud usa modelos para definir configurações de cluster. Vários modelos são incluídos no CycleCloud por padrão e uma lista completa de modelos com suporte está disponível no GitHub. Você pode criar novos modelos ou personalizar os existentes. Por exemplo, talvez você queira personalizar um modelo existente para aproveitar as VMs spot ou talvez queira adicionar um VPC para estender sua própria rede.

Notação de Configuração

Todos os modelos de cluster do Azure CycleCloud têm a opção de ter uma ou mais seções [[[configuração]] que pertencem a um nó ou nodearray. Essas seções especificam opções de configuração de software sobre os nós que estão sendo iniciados pelo CycleCloud. A notação pontilhada é usada para especificar os atributos que você deseja configurar:

[[node scheduler]]
  [[[configuration]]]
  cycle_server.admin.name = poweruser
  cycle_server.admin.pass = super_secret
  cycle_server.http_port = 8080
  cycle_server.https_port = 8443

Você também pode especificar uma seção de configuração usando prefix notação para salvar a digitação. A mesma configuração também pode ser gravada como:

[[node scheduler]]
  [[[configuration cycle_server]]]
  admin.name = poweruser
  admin.pass = super_secret
  http_port = 8080
  https_port = 8443

Um nó/nodearray também pode conter várias seções de configuração, se necessário:

[[node scheduler]]
  [[[configuration]]]
  run_list = role[sge_scheduler_node]

  [[[configuration cycle_server.admin]]]
  name = poweruser
  pass = super_secret

Parâmetros de modelo de cluster

Os modelos de cluster podem conter parâmetros que alteram os valores de determinadas partes de um cluster sem precisar modificar o próprio modelo. Isso é particularmente útil em casos em que muitos clusters semelhantes com pequenas diferenças são desejados, como a implantação de ambientes de desenvolvimento e produção. A sintaxe para especificar um parâmetro dentro de um modelo de cluster é prefixar uma variável com um '$'. Um exemplo de modelo básico (não funcional) com alguns parâmetros poderia ser semelhante a:

# template.txt
[cluster gridengine]

  [[node scheduler]]
  MachineType = $machine_type

    [[[configuration]]]
    gridengine.slots = $slots

Este modelo define dois parâmetros: $machine_type e $slots. Usando esse modelo, você pode definir arquivos de texto que contêm os valores dos parâmetros nos ambientes de desenvolvimento e prod. O arquivo de parâmetros pode estar no formato JSON ou em um formato de arquivo de propriedades Java:

# dev-params.json
{
  "machine_type": "H16r",
  "slots": 2
}

# prod-params.properties
machine_type = Standard_D4v3
slots = 8

Isso criará um arquivo JSON que contém os parâmetros para desenvolvimento e um arquivo .properties que contém os valores de produção.

Observação

O sufixo de nome de arquivo para o arquivo de parâmetros é importante! Se estiver usando JSON, seu arquivo deverá ser nomeado foo.json. Se estiver usando propriedades Java, seu arquivo deverá terminar com .properties. Arquivos de parâmetro nomeados incorretamente não serão importados corretamente.

Agora você pode importar o modelo usando o arquivo de parâmetros para preencher as partes ausentes:

cyclecloud import_cluster gridengine-dev -f template.txt -p dev-params.json -c gridengine

cyclecloud import_cluster gridengine-prod -f template.txt -p prod-params.properties -c gridengine

Também é possível definir alguns ou todos os parâmetros dentro do próprio modelo de cluster:

# template.txt
[cluster gridengine]

  [[node scheduler]]
  MachineType = $machine_type

    [[[configuration]]]
    gridengine.slots = $slots

[parameters]
  [[parameter machine_type]]
  DefaultValue = Standard_D4v3

  [[parameter slots]]
  DefaultValue = 2

Os valores padrão para cada parâmetro são definidos dentro do modelo (usamos os valores 'dev' como padrão).

Agora é possível importar o modelo sem um arquivo de parâmetros e os valores de "desenvolvimento" serão usados automaticamente. Quando for hora de criar um cluster 'prod', você pode usar o arquivo prod-params.properties para substituir os valores especificados dentro do próprio arquivo de modelo.

Observação

Os nomes dos parâmetros podem incluir letras, números e sublinhados.

As referências de parâmetro no modelo podem usar uma das duas formas:

$param: usa o valor de um único parâmetro chamado param

${expr}: avalia expr no contexto de todos os parâmetros, o que permite calcular valores dinâmicos. Por exemplo:

Attribute = ${(a > b ? a : b) * 100}

Isso levaria o maior de dois parâmetros a e bo multiplicaria por 100. A expressão é interpretada e avaliada de acordo com a especificação de linguagem ClassAd.

Se existir uma referência de parâmetro por si só, o valor do parâmetro será usado, o que dá suporte a tipos que não são de cadeia de caracteres, como boolianos, inteiros e estruturas aninhadas, como listas. No entanto, se a referência estiver inserida em outro texto, seu valor será convertido e incluído em uma cadeia de caracteres. Por exemplo, suponha que param seja definido como 456 e referenciado em dois lugares:

  • Attribute1 = $param
  • Attribute2 = 123$param

O valor seria Attribute1 o número 456, mas o valor da cadeia de Attribute2 caracteres "123456"seria . Observe que ${param} é idêntico a $param, o que permite inserir referências de parâmetro em situações mais complexas:

  • Attribute3 = 123$param789
  • Attribute4 = 123${param}789

Attribute3 procuraria o parâmetro nomeado param789, mas Attribute4 usaria o valor para param obter "123456789".

Tipos de computador

O Azure CycleCloud dá suporte a vários tipos de computador por meio do MachineType atributo. Ele tentará adquirir a capacidade na ordem listada.

Especificações do Cluster Init

O aplicativo Web Azure CycleCloud permite que os usuários selecionem especificações de projeto de cluster-init ao criar um novo cluster. As especificações do projeto são configuradas dentro do modelo de cluster:

[parameter ClusterInitSpecs]
Label = Cluster-Init
Description = Cluster init specs to apply to nodes
ParameterType = Cloud.ClusterInitSpecs

[cluster demo]

  [[node defaults]]
  AdditionalClusterInitSpecs = $ClusterInitSpecs

      [[[cluster-init myproject:myspec:1.0.0]]]

Depois que esse parâmetro tiver sido adicionado ao modelo de cluster, o usuário poderá usar o seletor de arquivos para selecionar as especificações de projeto apropriadas ao criar um novo cluster.

Máquinas virtuais spot

Para reduzir o custo de suas cargas de trabalho, você pode definir Interruptible = true. Isso sinalizará sua instância como Spot e usará a capacidade excedente quando disponível. É importante observar que essas instâncias nem sempre estão disponíveis e podem ser preempidas a qualquer momento, o que significa que elas nem sempre são apropriadas para sua carga de trabalho.

Por padrão, a configuração Interruptible como true usará instâncias spot com um preço máximo definido como -1; isso significa que a instância não será removida com base no preço. O preço da instância será o preço atual para o spot ou o preço de uma instância padrão, o que for menor, desde que haja capacidade e cota disponíveis. Se você quiser definir um preço máximo personalizado, use o MaxPrice atributo no nó ou nodearray desejado.

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

Consultar Tabelas

Você pode ter uma referência de parâmetro a outra e calcular um determinado valor com uma tabela de pesquisa. Por exemplo, suponha que você tenha um parâmetro para a imagem usar, com duas opções nesse caso:

[[parameter MachineImage]]
    Label = Image
    DefaultValue = image-1000
    Description = Ubuntu 22.04
    Config.Plugin = pico.control.AutoCompleteDropdown
    [[[list Config.Entries]]]
        Name = image-1000
        Label = Ubuntu 20.04
    [[[list Config.Entries]]]
        Name = image-2000
            Label = Ubuntu 22.04

Você também pode obter a versão do sistema operacional da imagem escolhida e usá-la para outra configuração, fazendo um parâmetro cujo valor é uma tabela de pesquisa de valores:

[[parameter AmiLookup]]
  ParameterType = hidden
  [[[record DefaultValue]]]
      image-1000 = Ubuntu 20.04
      image-2000 = Ubuntu 22.04

Observe que isso está oculto, para que ele não apareça na interface do usuário.

Você pode obter a versão do sistema operacional usada para a imagem escolhida em qualquer outro lugar na definição de cluster:

[[node node]]
[[[configuration]]]
version = ${AmiLookup[MachineImage]}

Integração de GUI

Definir parâmetros dentro do modelo de cluster permite que um aproveite a GUI do Azure CycleCloud. Por exemplo, ao definir parâmetros, os seguintes atributos podem ser usados para auxiliar na criação da GUI:

# template.txt
[cluster gridengine]

  [[node scheduler]]
  MachineType = $machine_type

    [[[configuration]]]
    gridengine.slots = $slots

[parameters]
  [[parameter machine_type]]
  DefaultValue = Standard_D4v3
  Label = Machine Type
  Description = MachineType to use for the Grid Engine scheduler node
  ParameterType = Cloud.MachineType

  [[parameter slots]]
  DefaultValue = 2
  Description = The number of slots for Grid Engine to report for the node

Os atributos "Label" e "Description" estão incluídos, que aparecerão na GUI, bem como o atributo opcional "ParameterType". O "ParameterType" permite que elementos de interface do usuário personalizados sejam exibidos. No exemplo acima, o valor "Cloud.MachineType" exibirá uma lista suspensa contendo todos os tipos de computador disponíveis. Os outros valores ParameterType são:

Tipo de parâmetro Descrição
Cloud.MachineType Exibe uma lista suspensa que contém todos os tipos de computador disponíveis.
Cloud.Credentials Exibe uma lista suspensa contendo todas as credenciais disponíveis.
Cloud.Region Exibe uma lista suspensa que contém todas as regiões disponíveis.

Suporte ao Chef Server

O Azure CycleCloud suports ChefServer.

Crie o arquivo chefserver.json e adicione suas credenciais. ValidationKey corresponde ao arquivo validation.pem para seu servidor chef. Você também deve provar se validation_client_name o alterou do valor padrão de "chef-validator":

{
"AdType" : "Cloud.Locker",
"ValidationKey" : "YOURVALIDATION.PEMHERE",
"ValidationClientName" : "chef-validator",
"Credentials" : "default",
"Location" : "https://mychefserver",
"ChefRepoType" : "chefserver",
"LockerType" : "chefrepo",
"Name" : "chefrepo",
"AccountId" : "default",
"Shared" : false
}

Em seguida, coloque o arquivo no diretório /opt/cycle_server/config/data. Ele será importado automaticamente.

Imagens de usuário personalizadas em modelos

O Azure CycleCloud dá suporte a imagens personalizadas em modelos. Especifique a ID da imagem (ID do recurso) diretamente com ImageId, ou adicione a imagem ao registro de imagem. Quando a imagem estiver no registro, faça referência a ela com ou ImageImageName em seu nó. Ele aparecerá na lista suspensa de imagens na página de criação do cluster.

As imagens no registro de imagem consistem em um Package registro que identifica o conteúdo da imagem lógica e um ou mais registros correspondentes Artifact que especificam a ID de imagem real no provedor de nuvem apropriado. Por exemplo, uma imagem personalizada com r instalada nele pode consistir neste registro de pacote:

AdType = "Package"
Name = "r_execute"
Version = "2.1.1"
PackageType = "image"
Label = "R"

Depois de adicionar esse registro, você pode especificar essa imagem incluindo o Image = R modelo de cluster ou ImageName = r_execute o modelo de cluster.

Se essa imagem existisse como uma única Máquina Virtual em useast com uma ID de /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage, ela precisaria ter o seguinte artefato armazenado:

AdType = "Artifact"
Package = "r_execute"
Version = "2.1.1"
Name = "az/useast"
Provider = "az"
ImageId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage"

Você deve especificar Provider no artefato.

Você pode adicionar quantos artefatos desejar para um determinado pacote de imagem, mas deve incluir todos os artefatos necessários para usar essa imagem em todos os "locais" desejados (um por conta do provedor de nuvem, regiões, projetos etc.). O nome do artefato não é importante, exceto que ele deve ser exclusivo para todos os artefatos de um determinado pacote e versão. Normalmente, é recomendável usar uma combinação dos detalhes específicos do provedor e do provedor (por exemplo, região). O CycleCloud escolhe automaticamente o artefato certo para corresponder ao provedor e a quaisquer detalhes específicos do provedor, mas usa o atributo Provedor (e Região, etc.) em vez de analisar o Nome.

Se você adicionar mais de um pacote de imagem com o mesmo nome, eles deverão ter números de versão diferentes. Ao iniciar uma instância, o CycleCloud escolherá automaticamente a imagem com o número de versão mais alto, tratando o número de versão como uma cadeia de caracteres pontilhada e comparando cada parte como um número. Para substituir isso, especifique ImageVersion no nó, como um literal (por exemplo 1.2) ou um curinga (1.x).