O Salt, juntamente com o DeepSea, é uma pilha de componentes que ajuda você a implantar e gerenciar a infraestrutura do servidor. Ele é muito escalável, rápido e relativamente fácil de ser executado. Leia as seguintes considerações antes de começar a implantação do cluster com o Salt:
Os minions Salt são nós controlados por um nó dedicado denominado master Salt. Os minions Salt têm funções. Por exemplo, Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway ou NFS Ganesha.
Um master Salt executa seu próprio minion Salt. Ele é necessário para executar tarefas com privilégio (por exemplo, criar, autorizar e copiar chaves para os minions), dessa forma, os minions remotos nunca precisam executar tarefas com privilégio.
O desempenho do cluster do Ceph é melhor quando cada função é implantada em um nó separado. Porém, as implantações reais às vezes exigem que um nó seja compartilhado com várias funções. Para evitar problema de desempenho e de procedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadados ou Ceph Monitor no Nó de Admin.
Os minions Salt precisam resolver corretamente o nome de host do master Salt na rede. Por padrão, eles procuram o nome de host salt
, mas você pode especificar qualquer outro nome de host acessível por rede no arquivo /etc/salt/minion
. Consulte a Seção 5.3, “Implantação do cluster”.
Nos detalhes da versão, você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Enterprise Storage. Consulte os detalhes da versão para verificar se:
seu hardware precisa de considerações especiais.
qualquer pacote de software usado foi significativamente modificado.
são necessárias precauções especiais para a instalação.
Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempo no manual. Eles também incluem notas sobre problemas conhecidos.
Após instalar o pacote release-notes-ses, encontre os detalhes da versão no diretório local /usr/share/doc/release-notes
ou no site https://www.suse.com/releasenotes/.
O objetivo do DeepSea é economizar o tempo do administrador e executar com segurança operações complexas em um cluster do Ceph.
O Ceph é uma solução de software muito configurável. Ele promove a liberdade e a responsabilidade dos administradores do sistema.
A configuração mínima do Ceph é ideal para fins de demonstração, mas não apresenta os recursos interessantes do Ceph que você pode ver com um grande número de nós.
O DeepSea coleta e armazena dados sobre os servidores individuais, como endereços e nomes de dispositivos. Para um sistema de armazenamento distribuído, como Ceph, pode haver centenas desses itens para coletar e armazenar. A coleta de informações e a entrada manual de dados em uma ferramenta de gerenciamento de configuração são exaustivas e propensas a erros.
A maioria das etapas necessárias para preparar os servidores, coletar a configuração, configurar e implantar o Ceph é a mesma. No entanto, isso não resolve o gerenciamento de funções separadas. Para operações do dia a dia, a simples capacidade de adicionar hardware a determinada função e removê-lo sem problemas é um requisito.
O DeepSea resolve essas observações com a seguinte estratégia: ele consolida as decisões do administrador em um único arquivo. As decisões incluem atribuição de cluster, atribuição de função e atribuição de perfil. E o DeepSea coleta cada conjunto de tarefas em uma meta simples. Cada meta é uma fase:
Fase 0: preparação. Durante essa fase, todas as atualizações necessárias são aplicadas, e o sistema pode ser reinicializado.
Se o Nó de Admin for reinicializado durante a fase 0 para carregar a nova versão do kernel, você precisará executar a fase 0 novamente; do contrário, os minions não serão direcionados.
Fase 1: a descoberta: nessa fase, o hardware inteiro no cluster é detectado e as informações necessárias para a configuração do Ceph são coletadas. Para obter detalhes sobre a configuração, consulte a Seção 5.5, “Configuração e personalização”.
Fase 2: configuração. Você precisa preparar os dados de configuração em um formato específico.
Fase 3: implantação. Cria um cluster básico do Ceph com os serviços obrigatórios dele. Consulte a Seção 1.2.3, “Nós e daemons do Ceph” para ver a lista.
Fase 4: serviços. É possível instalar recursos adicionais do Ceph, como iSCSI, Object Gateway e CephFS, nessa fase. Cada um deles é opcional.
Fase 5: fase de remoção. Essa fase não é obrigatória e, durante a configuração inicial, não costuma ser necessária. Nessa fase, as funções dos minions e também a configuração do cluster são removidas. Você precisa executar essa fase quando tem que remover um nó de armazenamento do cluster. Para obter detalhes, consulte o Seção 2.3, “Removendo e reinstalando nós do cluster”.
O Salt tem vários locais padrão e diversas convenções de nomeação usados no nó master:
/srv/pillar
O diretório armazena os dados de configuração para os minions do cluster. Pillar é uma interface que fornece valores globais de configuração a todos os minions do seu cluster.
/srv/salt/
O diretório armazena os arquivos de estado do Salt (também denominados sls). Os arquivos de estado são descrições formatadas dos estados em que o cluster deve estar.
/srv/module/runners
O diretório armazena os scripts do Python conhecidos como executores. Eles são executados no nó master.
/srv/salt/_modules
O diretório armazena os scripts do Python que são chamados de módulos. Os módulos são aplicados a todos os minions no seu cluster.
/srv/pillar/ceph
O diretório é usado pelo DeepSea. Os dados de configuração coletados são armazenados nele.
/SRV/salt/ceph
Um diretório usado pelo DeepSea. Ele armazena arquivos sls que podem estar em formatos diferentes, mas cada subdiretório contém arquivos sls. Cada subdiretório contém apenas um tipo de arquivo sls. Por exemplo, /srv/salt/ceph/stage
contém os arquivos de orquestração que são executados por salt-run state.orchestrate
.
Os comandos do DeepSea são executados pela infraestrutura do Salt. Ao usar o comando salt
, você precisa especificar um conjunto de minions Salt afetados pelo comando. Descrevemos o conjunto de minions como destino para o comando salt
. As seções a seguir descrevem os métodos possíveis para direcionar os minions.
Você pode direcionar um minion ou um grupo de minions correspondendo os nomes deles. Normalmente, o nome de um minion é o nome de host curto do nó onde o minion é executado. Trata-se de um método de direcionamento geral do Salt que não está relacionado ao DeepSea. Você pode usar glob, expressões regulares ou listas para limitar a faixa de nomes de minion. Veja a seguir a sintaxe geral:
root@master #
salt target example.module
Se todos os minions Salt em seu ambiente pertencerem ao cluster do Ceph, você poderá substituir com segurança o destino por '*'
para incluir todos os minions registrados.
Corresponder todos os minions no domínio example.net (considerando que os nomes dos minions sejam idênticos aos nomes de host "completos" deles):
root@master #
salt '*.example.net' test.ping
Corresponder o minion “web1” ao “web5”:
root@master #
salt 'web[1-5]' test.ping
Corresponder tanto o minion “web1-prod” quanto “web1-devel” usando uma expressão regular:
root@master #
salt -E 'web1-(prod|devel)' test.ping
Corresponder uma lista simples de minions:
root@master #
salt -L 'web1,web2,web3' test.ping
Corresponder todos os minions no cluster:
root@master #
salt '*' test.ping
Em um ambiente heterogêneo gerenciado pelo Salt, em que o SUSE Enterprise Storage 6 é implantado em um subconjunto de nós juntamente com outras soluções de cluster, você precisa marcar os minions relevantes aplicando um grain "deepsea" a eles antes de executar a fase 0 do DeepSea. Dessa forma, você pode direcionar facilmente os minions do DeepSea nos ambientes em que a correspondência por nome do minion é problemática.
Para aplicar o grain “deepsea” a um grupo de minions, execute:
root@master #
salt target grains.append deepsea default
Para remover o grain “deepsea” de um grupo de minions, execute:
root@master #
salt target grains.delval deepsea destructive=True
Após aplicar o grain “deepsea” aos minions relevantes, você poderá direcioná-los da seguinte maneira:
root@master #
salt -G 'deepsea:*' test.ping
O comando a seguir é um equivalente:
root@master #
salt -C 'G@deepsea:*' test.ping
deepsea_minions
#
A definição do destino da opção deepsea_minions
é um requisito para as implantações do DeepSea. O DeepSea a utiliza para instruir os minions durante a execução das fases (consulte Descrição das fases do DeepSea para obter detalhes).
Para definir ou mudar a opção deepsea_minions
, edite o arquivo /srv/pillar/ceph/deepsea_minions.sls
no master Salt e adicione ou substitua a seguinte linha:
deepsea_minions: target
deepsea_minions
Como destino para a opção deepsea_minions
, você pode usar qualquer método de direcionamento: tanto Correspondendo o nome do minion quanto Direcionando com um grain do DeepSea.
Corresponder todos os minions Salt no cluster:
deepsea_minions: '*'
Corresponder todos os minions com o grain “deepsea”:
deepsea_minions: 'G@deepsea:*'
Você pode usar métodos mais avançados para direcionar minions por meio da infraestrutura do Salt. A página de manual do “deepsea-minions” apresenta mais detalhes sobre direcionamento do DeepSea (man 7 deepsea_minions
).
O processo de implantação do cluster tem várias fases. Primeiramente, você precisa preparar todos os nós do cluster configurando o Salt e, em seguida, implantar e configurar o Ceph.
Se você precisa ignorar a definição de funções de armazenamento para o OSD, conforme descrito na Seção 5.5.1.2, “Atribuição de função”, e implantar primeiro os nós do Ceph Monitor, defina a variável DEV_ENV
.
Isso permite implantar monitores sem a presença do diretório role-storage/
e implantar um cluster do Ceph com pelo menos uma função de armazenamento, monitor e gerenciador.
Para definir a variável de ambiente, habilite-a globalmente configurando-a no arquivo /srv/pillar/ceph/stack/global.yml
ou defina-a apenas para a sessão do shell atual:
root@master #
export DEV_ENV=true
Como exemplo, é possível criar o /srv/pillar/ceph/stack/global.yml
com o seguinte conteúdo:
DEV_ENV: True
O procedimento a seguir descreve a preparação do cluster em detalhes.
Instale e registre o SUSE Linux Enterprise Server 15 SP1 juntamente com a extensão do SUSE Enterprise Storage 6 em cada nó do cluster.
Verifique se os produtos apropriados estão instalados e foram registrados listando os repositórios de software existentes. Execute zypper lr -E
e compare a saída com a seguinte lista:
SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates
Defina as configurações de rede incluindo a resolução de nome DNS em cada nó. O master Salt e todos os minions Salt necessários para resolução entre eles por meio dos nomes de host. Para obter mais informações sobre como configurar uma rede, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html. Para obter mais informações sobre como configurar um servidor DNS, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html.
Selecione um ou mais servidores de horário/pools e sincronize o horário local com eles. Verifique se o serviço de sincronização de horário está habilitado em cada inicialização do sistema. É possível usar o comando yast ntp-client
incluído em um pacote yast2-ntp-client para configurar a sincronização de horário.
As máquinas virtuais não são fontes confiáveis de NTP.
Encontre mais informações sobre como configurar o NTP em https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html.
Instale os pacotes salt-master
e salt-minion
no nó master Salt:
root@master #
zypper in salt-master salt-minion
Verifique se o serviço salt-master
está habilitado e foi iniciado. Se necessário, habilite-o e inicie-o:
root@master #
systemctl enable salt-master.serviceroot@master #
systemctl start salt-master.service
Se você pretende usar um firewall, verifique se o nó master Salt tem as portas 4505 e 4506 abertas para todos os nós do minion Salt. Se as portas estiverem fechadas, você poderá abri-las usando o comando yast2 firewall
e permitindo o serviço .
Há falha nas fases de implantação do DeepSea quando o firewall está ativo (e até configurado). Para percorrer as fases corretamente, você precisa desativar o firewall executando
root #
systemctl stop firewalld.service
ou definir a opção FAIL_ON_WARNING
como “False” em /srv/pillar/ceph/stack/global.yml
:
FAIL_ON_WARNING: False
Instale o pacote salt-minion
em todos os nós do minion.
root@minion >
zypper in salt-minion
Verifique se o nome de domínio completo e qualificado de cada nó pode ser resolvido para o endereço IP da rede pública por todos os outros nós.
Configure todos os minions (incluindo o minion master) para conectar-se ao master. Se o master Salt não puder ser acessado pelo nome de host salt
, edite o arquivo /etc/salt/minion
ou crie um novo arquivo /etc/salt/minion.d/master.conf
com o seguinte conteúdo:
master: host_name_of_salt_master
Se você efetuou quaisquer mudanças nos arquivos de configuração mencionados acima, reinicie o serviço Salt em todos os minions Salt:
root@minion >
systemctl restart salt-minion.service
Verifique se o serviço salt-minion
está habilitado e foi iniciado em todos os nós. Se necessário, habilite-o e inicie-o:
root #
systemctl enable salt-minion.serviceroot #
systemctl start salt-minion.service
Verifique a impressão digital de cada minion Salt e aceite todas as chaves do Salt no master Salt se as impressões digitais forem correspondentes.
Se a impressão digital do minion Salt retornar vazia, verifique se o minion Salt tem uma configuração do master Salt e pode se comunicar com o master Salt.
Ver a impressão digital de cada minion:
root@master #
salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
Após coletar as impressões digitais de todos os minions Salt, liste as impressões digitais de todas as chaves de minion não aceitas no master Salt:
root@master #
salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
Se houver correspondência de impressões digitais dos minions, aceite-as:
root@master #
salt-key --accept-all
Verifique se as chaves foram aceitas:
root@master #
salt-key --list-all
Antes de implantar o SUSE Enterprise Storage 6, limpe (zap) manualmente todos os discos. Lembre-se de substituir “X” pela letra correta do disco:
Pare todos os processos que estão usando o disco específico.
Verifique se alguma partição no disco está montada e, se necessário, desmonte-a.
Se o disco for gerenciado por LVM, desative e apague toda a infraestrutura do LVM. Consulte https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html para obter mais detalhes.
Se o disco fizer parte do RAID MD, desative o RAID. Consulte https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html para obter mais detalhes.
Se você receber mensagens de erro, como “partition in use” ou “kernel cannot be updated with the new partition table” durante as etapas seguintes, reinicialize o servidor.
Limpe o começo de cada partição (como root
):
for partition in /dev/sdX[0-9]* do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct done
Limpe o começo da unidade:
root #
dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
Limpe o fim da unidade:
root #
dd if=/dev/zero of=/dev/sdX bs=512 count=33 \
seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
Verifique se a unidade está vazia (sem estruturas de GPT) usando:
root #
parted -s /dev/sdX print free
ou
root #
dd if=/dev/sdX bs=512 count=34 | hexdump -Croot #
dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
Opcionalmente, se você precisar predefinir as configurações de rede do cluster antes da instalação do pacote deepsea , crie /srv/pillar/ceph/stack/ceph/cluster.yml
manualmente e defina as opções cluster_network:
e public_network:
. Observe que o arquivo não será sobregravado após a instalação do deepsea.
Se você precisar habilitar endereçamento de rede IPv6, consulte a Seção 7.2.1, “Habilitando o IPv6 para implantação de cluster do Ceph”
Instale o DeepSea no nó master Salt:
root@master #
zypper in deepsea
O valor do parâmetro master_minion
é derivado dinamicamente do arquivo /etc/salt/minion_id
no master Salt. Se você precisar anular o valor descoberto, edite o arquivo /srv/pillar/ceph/stack/global.yml
e defina um valor relevante:
master_minion: MASTER_MINION_NAME
Se o master Salt for acessível por mais nomes de host, use o nome do minion Salt para o cluster de armazenamento, conforme retornado pelo comando salt-key -L
. Se você usou o nome de host padrão para o seu master Salt (salt) no domínio ses, o arquivo tem esta aparência:
master_minion: salt.ses
Agora você pode implantar e configurar o Ceph. A menos que especificado de outra forma, todas as etapas são obrigatórias.
Há duas maneiras possíveis de executar salt-run state.orch
: uma é com “stage.STAGE_NUMBER”, a outra é com o nome da fase. As duas notações têm o mesmo impacto, e você decide qual comando usar de acordo com a sua preferência.
Verifique se os minions Salt que pertencem ao cluster do Ceph estão corretamente direcionados com a opção deepsea_minions
em /srv/pillar/ceph/deepsea_minions.sls
. Consulte a Seção 5.2.2.3, “Definir a opção deepsea_minions
” para obter mais informações.
Por padrão, o DeepSea implanta os clusters do Ceph com perfis ajustados ativos nos nós do Ceph Monitor, Ceph Manager e Ceph OSD. Em alguns casos, você pode precisar implantar sem os perfis ajustados. Para fazer isso, insira as seguintes linhas no /srv/pillar/ceph/stack/global.yml
antes de executar as fases do DeepSea:
alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off
Opcional: crie subvolumes Btrfs para /var/lib/ceph/
. Esta etapa precisa ser executada antes da fase 0 do DeepSea. Para migrar os diretórios existentes ou obter mais detalhes, consulte o Seção 25.6, “Subvolume Btrfs para /var/lib/ceph
em nós do Ceph Monitor”.
Aplique os seguintes comandos a cada um dos minions Salt:
root@master #
salt 'MONITOR_NODES' saltutil.sync_allroot@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
O comando Ceph.subvolume cria /var/lib/ceph
como um subvolume Btrfs @/var/lib/ceph
.
Agora, o novo subvolume está montado e /etc/fstab
está atualizado.
Prepare o cluster. Consulte Descrição das fases do DeepSea para obter mais detalhes.
root@master #
salt-run state.orch ceph.stage.0
ou
root@master #
salt-run state.orch ceph.stage.prep
Ao usar a CLI do DeepSea, você pode acompanhar o andamento da execução da fase em tempo real, seja executando a CLI do DeepSea no modo de monitoramento ou executando a fase diretamente na CLI do DeepSea. Para obter detalhes, consulte a Seção 5.4, “CLI do DeepSea”.
A fase de descoberta coleta dados de todos os minions e cria fragmentos de configuração que são armazenados no diretório /srv/pillar/ceph/proposals
. Os dados são armazenados no formato YAML em arquivos *.sls ou *.yml.
Execute o seguinte comando para acionar a fase de descoberta:
root@master #
salt-run state.orch ceph.stage.1
ou
root@master #
salt-run state.orch ceph.stage.discovery
Após a conclusão bem-sucedida do comando anterior, crie um arquivo policy.cfg
em /srv/pillar/ceph/proposals
. Para obter detalhes, consulte a Seção 5.5.1, “Arquivo policy.cfg
”.
Se você tiver que mudar a configuração de rede do cluster, edite /srv/pillar/ceph/stack/ceph/cluster.yml
e ajuste as linhas que começam com cluster_network:
e public_network:
.
A fase de configuração analisa o arquivo policy.cfg
e funde os arquivos incluídos em seu formato final. O cluster e o conteúdo relacionado à função são armazenados em /srv/pillar/ceph/cluster
, enquanto o conteúdo específico do Ceph é armazenado em /srv/pillar/ceph/stack/default
.
Execute o seguinte comando para acionar a fase de configuração:
root@master #
salt-run state.orch ceph.stage.2
ou
root@master #
salt-run state.orch ceph.stage.configure
A etapa de configuração pode levar mais tempo. Após a conclusão do comando, você poderá ver os dados do pillar referentes aos minions especificados (por exemplo, denominados ceph_minion1
, ceph_minion2
, etc.) executando:
root@master #
salt 'ceph_minion*' pillar.items
Para modificar o layout do OSD padrão e mudar a configuração dos grupos de unidades, siga o procedimento descrito na Seção 5.5.2, “DriveGroups”.
Logo após a conclusão do comando, você poderá ver a configuração padrão e mudá-la de acordo com as suas necessidades. Para obter detalhes, consulte o Capítulo 7, Personalizando a configuração padrão.
Agora você pode executar a fase de implantação. Nesta fase, o pillar é validado, e os daemons Ceph Monitor e Ceph OSD são iniciados:
root@master #
salt-run state.orch ceph.stage.3
ou
root@master #
salt-run state.orch ceph.stage.deploy
O comando pode levar algum tempo. Se ele falhar, você precisará corrigir o problema e executar novamente as fases anteriores. Depois que o comando for bem-sucedido, execute o seguinte para verificar o status:
cephadm@adm >
ceph -s
A última etapa da implantação do cluster do Ceph é a fase de serviços. Nessa etapa, você instancia qualquer um dos serviços suportados atualmente: iSCSI Gateway, CephFS, Object Gateway, e NFS Ganesha. Nessa fase, os pools necessários, os chaveiros de autorização e os serviços de inicialização são criados. Para iniciar a fase, execute o seguinte:
root@master #
salt-run state.orch ceph.stage.4
ou
root@master #
salt-run state.orch ceph.stage.services
Dependendo da configuração, o comando pode ser executado por muito tempo.
Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria do Ceph. Para obter mais informações e instruções, consulte o Seção 10.2, “Módulo de telemetria”.
O DeepSea também fornece uma ferramenta de interface de linha de comando (CLI, command line interface) que permite ao usuário monitorar ou executar as fases enquanto visualiza o andamento da execução em tempo real. Verifique se o pacote deepsea-cli está instalado antes de clicar no executável deepsea
.
Dois modos são suportados para visualização do andamento da execução de uma fase:
Modo de monitoramento: visualiza o andamento da execução de uma fase do DeepSea acionada pelo comando salt-run
emitido em outra sessão de terminal.
Modo independente: executa uma fase do DeepSea enquanto permite a visualização em tempo real das etapas de seus componentes conforme são executadas.
Apenas é possível executar os comandos da CLI do DeepSea no nó master Salt, com os privilégios de root
.
O monitor de andamento apresenta uma visualização detalhada em tempo real do que acontece durante a execução das fases usando os comandos salt-run state.orch
em outras sessões de terminal.
É necessário iniciar o monitor em uma nova janela do terminal antes de executar qualquer salt-run state.orch
para que o monitor possa detectar o início da execução da fase.
Se você iniciar o monitor após a emissão do comando salt-run state.orch
, não será exibido nenhum andamento da execução.
É possível iniciar o modo monitor executando o seguinte comando:
root@master #
deepsea monitor
Para obter mais informações sobre as opções de linha de comando disponíveis do deepsea monitor
, consulte a página de manual dele:
root@master #
man deepsea-monitor
No modo independente, é possível usar a CLI do DeepSea para executar uma fase dele, mostrando a execução em tempo real.
O comando para executar uma fase do DeepSea pela CLI tem o seguinte formato:
root@master #
deepsea stage run stage-name
em que stage-name corresponde ao modo como os arquivos de estado da orquestração do Salt são referenciados. Por exemplo, a fase deploy (implantação), que corresponde ao diretório localizado em /srv/salt/ceph/stage/deploy
, é referenciada como ceph.stage.deploy.
Esse comando é uma alternativa aos comandos com base no Salt para execução das fases do DeepSea (ou de qualquer arquivo de estado da orquestração do DeepSea).
O comando deepsea stage run ceph.stage.0
equivale ao salt-run state.orch ceph.stage.0
.
Para obter mais informações sobre as opções de linha de comando disponíveis que são aceitas pelo comando deepsea stage run
, consulte a página de manual dele:
root@master #
man deepsea-stage run
Na figura a seguir, há um exemplo da saída da CLI do DeepSea durante a execução da Fase 2:
stage run
da CLI do DeepSea #
Para usuários avançados do Salt, também oferecemos suporte a um álias para execução de uma fase do DeepSea que aplica o comando Salt usado para executar uma fase, por exemplo, salt-run state.orch stage-name
, como um comando da CLI do DeepSea.
Exemplo:
root@master #
deepsea salt-run state.orch stage-name
policy.cfg
#
O arquivo de configuração /srv/pillar/ceph/proposals/policy.cfg
é usado para determinar as funções dos nós individuais do cluster. Por exemplo, quais nós atuam como Ceph OSDs ou Ceph Monitors. Edite o policy.cfg
para refletir a configuração desejada do cluster. A ordem das seções é arbitrária, mas o conteúdo das linhas incluídas sobregrava as chaves correspondentes do conteúdo das linhas anteriores.
policy.cfg
Você encontra vários exemplos de arquivos de política completos no diretório /usr/share/doc/packages/deepsea/examples/
.
Na seção do cluster, selecione os respectivos minions. Você pode selecionar todos os minions ou incluí-los na lista negra ou na lista de permissões. Veja a seguir exemplos para um cluster denominado ceph.
Para incluir todos os minions, adicione as seguintes linhas:
cluster-ceph/cluster/*.sls
Para incluir um minion específico na lista de permissões:
cluster-ceph/cluster/abc.domain.sls
ou um grupo de minions, você pode usar a correspondência de globbing do shell:
cluster-ceph/cluster/mon*.sls
Para incluir minions na lista negra, defina-os como unassigned
:
cluster-unassigned/cluster/client*.sls
Esta seção apresenta detalhes sobre como atribuir “funções” a nós do cluster. Neste contexto, uma “função” significa o serviço que você precisa executar no nó, como Ceph Monitor, Object Gateway, ou iSCSI Gateway. Nenhuma função é atribuída automaticamente, apenas as funções adicionadas ao policy.cfg
serão implantadas.
A atribuição segue este padrão:
role-ROLE_NAME/PATH/FILES_TO_INCLUDE
Em que os itens têm o significado e os valores a seguir:
ROLE_NAME é qualquer um destes valores: “master”, “admin”, “mon”, “mgr”, “storage”, “mds”, “igw”, “rgw”, “ganesha”, “grafana” ou “prometheus”.
PATH é um caminho de diretório relativo para os arquivos .sls ou .yml. No caso de arquivos .sls, ele costuma ser cluster
, já os arquivos .yml estão localizados em stack/default/ceph/minions
.
FILES_TO_INCLUDE são os arquivos de estado do Salt ou os arquivos de configuração YAML. Normalmente, eles são compostos de nomes de host de minions Salt. Por exemplo, ses5min2.yml
. É possível usar o globbing do shell para correspondência mais específica.
Veja a seguir um exemplo para cada função:
master: o nó tem chaveiros de admin para todos os clusters do Ceph. Atualmente, apenas um único cluster do Ceph é suportado. Como a função master é obrigatória, adicione sempre uma linha semelhante ao seguinte:
role-master/cluster/master*.sls
admin: o minion terá um chaveiro de admin. Defina as funções da seguinte forma:
role-admin/cluster/abc*.sls
mon: o minion fornecerá o serviço de monitor ao cluster do Ceph. Essa função requer os endereços dos minions atribuídos. A partir do SUSE Enterprise Storage 5, os endereços públicos são calculados dinamicamente e não são mais necessários no pillar do Salt.
role-mon/cluster/mon*.sls
O exemplo atribui a função de monitor a um grupo de minions.
mgr: o daemon Ceph Manager que coleta todas as informações de estado do cluster inteiro. Implante-o em todos os minions nos quais você pretende implantar a função Ceph Monitor.
role-mgr/cluster/mgr*.sls
storage: use essa função para especificar nós de armazenamento.
role-storage/cluster/data*.sls
mds: o minion fornecerá o serviço de metadados para oferecer suporte ao CephFS.
role-mds/cluster/mds*.sls
igw: o minion atuará como iSCSI Gateway. Essa função requer os endereços dos minions atribuídos, portanto, você também precisa incluir os arquivos do diretório stack
:
role-igw/cluster/*.sls
rgw:: o minion atuará como Object Gateway:
role-rgw/cluster/rgw*.sls
ganesha: o minion atuará como servidor NFS Ganesha. A função “ganesha” requer uma função “rgw” ou “mds” no cluster; do contrário, haverá falha na validação na Fase 3.
role-ganesha/cluster/ganesha*.sls
Para instalar o NFS Ganesha com êxito, é necessária uma configuração adicional. Para usar o NFS Ganesha, leia o Capítulo 12, Instalação do NFS Ganesha antes de executar as fases 2 e 4. No entanto, é possível instalar o NFS Ganesha posteriormente.
Em alguns casos, ele pode ser útil para definir funções personalizadas para os nós do NFS Ganesha. Para obter os detalhes, consulte o Seção 21.3, “Funções personalizadas do NFS Ganesha”.
grafana, prometheus: esse nó adiciona gráficos do Grafana com base nos alertas do Prometheus ao Ceph Dashboard. Consulte o Capítulo 22, Ceph Dashboard para ver a descrição detalhada.
role-grafana/cluster/grafana*.sls
role-prometheus/cluster/prometheus*.sls
É possível atribuir várias funções a um único nó. Por exemplo, você pode atribuir as funções “mds” aos nós do monitor:
role-mds/cluster/mon[1,2]*.sls
A seção de configuração comum inclui arquivos de configuração gerados durante a descoberta (Fase 1). Esses arquivos de configuração armazenam parâmetros como fsid
ou public_network
. Para incluir a configuração comum necessária do Ceph, adicione as seguintes linhas:
config/stack/default/global.yml config/stack/default/ceph/cluster.yml
Nem sempre é prático incluir todos os arquivos de determinado diretório com globbing *.sls. O analisador de arquivos policy.cfg
reconhece os seguintes filtros:
Esta seção descreve as técnicas de filtragem para os usuários avançados. Quando não usada corretamente, a filtragem pode causar problemas. Por exemplo, em caso de mudança na numeração do nó.
Use o filtro slice para incluir apenas os itens start até end-1. Observe que os itens em determinado diretório são classificados em ordem alfanumérica. A linha a seguir inclui do terceiro ao quinto arquivo do subdiretório role-mon/cluster/
:
role-mon/cluster/*.sls slice[3:6]
Use o filtro de expressão regular para incluir apenas os itens correspondentes às expressões inseridas. Por exemplo:
role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$
policy.cfg
de exemplo #
Veja a seguir um exemplo de um arquivo policy.cfg
básico:
## Cluster Assignment cluster-ceph/cluster/*.sls 1 ## Roles # ADMIN role-master/cluster/examplesesadmin.sls 2 role-admin/cluster/sesclient*.sls 3 # MON role-mon/cluster/ses-example-[123].sls 4 # MGR role-mgr/cluster/ses-example-[123].sls 5 # STORAGE role-storage/cluster/ses-example-[5,6,7,8].sls 6 # MDS role-mds/cluster/ses-example-4.sls 7 # IGW role-igw/cluster/ses-example-4.sls 8 # RGW role-rgw/cluster/ses-example-4.sls 9 # COMMON config/stack/default/global.yml 10 config/stack/default/ceph/cluster.yml 11
Indica que todos os minions estão incluídos no cluster do Ceph. Se você tem minions que não deseja incluir no cluster do Ceph, use: cluster-unassigned/cluster/*.sls cluster-ceph/cluster/ses-example-*.sls A primeira linha marca todos os minions como não atribuídos. A segunda linha anula os minions correspondentes a “ses-example-*.sls” e os atribui ao cluster do Ceph. | |
O minion chamado “examplesesadmin” tem a função “master”. A propósito, isso significa que ele enviará chaves de admin ao cluster. | |
Todos os minions correspondentes a “sesclient*” também receberão chaves de admin. | |
Todos os minions correspondentes a “ses-example-[123]” (teoricamente três minions: ses-example-1, ses-example-2 e ses-example-3) serão configurados como nós MON. | |
Todos os minions correspondentes a “ses-example-[123]” (todos os nós MON no exemplo) serão configurados como nós MGR. | |
Todos os minions correspondentes a “ses-example-[5,6,7,8]” serão configurados como nós de armazenamento. | |
O minion “ses-example-4” terá a função MDS. | |
O minion “ses-example-4” terá a função IGW. | |
O minion “ses-example-4” terá a função RGW. | |
Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como | |
Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como |
Os DriveGroups especificam os layouts dos OSDs no cluster do Ceph. Eles são definidos em um único arquivo /srv/salt/ceph/configuration/files/drive_groups.yml
.
Um administrador deve especificar manualmente um grupo de OSDs que estão interligados (OSDs híbridos implantados em estado sólido e spinners) ou compartilhar as mesmas opções de implantação (idênticas, por exemplo, mesmo armazenamento de objetos, mesma opção de criptografia, OSDs independentes). Para evitar a listagem explícita de dispositivos, os DriveGroups usam uma lista de itens de filtro que correspondem a poucos campos selecionados dos relatórios de inventário do ceph-volume
. No caso mais simples, isso pode ser o flag “rotacional” (todas as unidades de estado sólido devem ser dispositivos db_devices, todas as unidades rotacionais devem ser dispositivos de dados) ou algo mais presente, como strings “modelo”ou tamanhos. O DeepSea fornecerá o código que converte esses DriveGroups em listas reais de dispositivos para inspeção pelo usuário.
Veja a seguir um procedimento simples que demonstra o workflow básico ao configurar DriveGroups:
Inspecione as propriedades dos discos conforme apresentado pelo comando ceph-volume
. Apenas essas propriedades são aceitas pelos DriveGroups:
root@master #
salt-run disks.details
Abra o arquivo YAML /srv/salt/ceph/configuration/files/drive_groups.yml
e ajuste-o conforme suas necessidades. Consulte a Seção 5.5.2.1, “Especificação”. Lembre-se de usar espaços em vez de tabulações. Há exemplos mais avançados na Seção 5.5.2.4, “Exemplos”. O exemplo a seguir inclui todas as unidades disponíveis para o Ceph como OSDs:
default_drive_group_name: target: '*' data_devices: all: true
Verifique os novos layouts:
root@master #
salt-run disks.list
Este executor retorna uma estrutura de discos correspondentes com base em seus grupos de unidades. Se você não ficar satisfeito com o resultado, repita a etapa anterior.
Além do executor disks.list
, há um executor disks.report
que imprime um relatório detalhado do que acontecerá ao invocar a fase 3 seguinte do DeepSea.
root@master #
salt-run disks.report
Implante os OSDs. Na invocação da fase 3 seguinte do DeepSea, os discos OSD serão implantados de acordo com a especificação do grupo de unidades.
/srv/salt/ceph/configuration/files/drive_groups.yml
aceita as seguintes opções:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION wal_devices: drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted) osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')
Para configurações do FileStore, o drive_groups.yml
pode ser da seguinte maneira:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True
Você pode descrever a especificação usando os seguintes filtros:
Por um modelo de disco:
model: DISK_MODEL_STRING
Por um fornecedor de disco:
vendor: DISK_VENDOR_STRING
Sempre insira DISK_VENDOR_STRING em letras minúsculas.
Se um disco é ou não rotacional. SSDs e unidades NVME não são rotacionais.
rotational: 0
Implante um nó usando todas as unidades disponíveis para OSDs:
data_devices: all: true
Limite também o número de discos correspondentes:
limit: 10
Você pode filtrar dispositivos de disco por tamanho, seja por um tamanho exato ou por uma faixa de tamanhos. O parâmetro size:
aceita argumentos no seguinte formato:
“10G”: Inclui discos de um tamanho exato.
“10G:40G”: Inclui discos cujo tamanho está dentro da faixa.
“:10G”: Inclui discos menores do que ou iguais a 10 GB.
“40G:”: Inclui discos iguais ou maiores do que 40 GB.
drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'
Ao usar o delimitador “:”, você precisa colocar o tamanho entre aspas; do contrário, o sinal “:” será interpretado como um novo hash de configuração.
Em vez de (G)igabytes, você também pode especificar os tamanhos em (M)egabytes ou (T)erabytes.
Esta seção inclui exemplos de configurações de OSD diferentes.
Este exemplo descreve dois nós com a mesma configuração:
20 HDDs
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
2 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
O arquivo drive_groups.yml
correspondente será da seguinte maneira:
drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ
Essa configuração é simples e válida. O problema é que um administrador pode adicionar discos de diferentes fornecedores no futuro, e eles não serão incluídos. Você pode melhorá-la reduzindo os filtros nas propriedades de núcleo das unidades:
drive_group_default: target: '*' data_devices: rotational: 1 db_devices: rotational: 0
No exemplo anterior, impomos todos os dispositivos rotacionais que serão declarados como "dispositivos de dados", e todos os dispositivos não rotacionais serão usados como "dispositivos compartilhados" (wal, db).
Se você sabe que as unidades com mais de 2 TB sempre serão os dispositivos de dados mais lentos, pode filtrar por tamanho:
drive_group_default: target: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'
Este exemplo descreve duas configurações distintas: 20 HDDs devem compartilhar 2 SSDs, enquanto 10 SSDs devem compartilhar 2 NVMes.
20 HDDs
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
12 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
2 NVMes
Fornecedor: Samsung
Modelo: NVME-QQQQ-987
Tamanho: 256 GB
Essa configuração pode ser definida com dois layouts da seguinte maneira:
drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ
drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: vendor: samsung size: 256GB
Os exemplos anteriores consideraram que todos os nós tinham as mesmas unidades. No entanto, esse nem sempre é o caso:
Nós 1-5:
20 HDDs
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
2 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
Nós 6-10:
5 NVMes
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
20 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
Você pode usar a chave de “destino” no layout para direcionar nós específicos. A notação de destino do Salt ajuda a simplificar as coisas:
drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0
seguido de
drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo
Todos os casos anteriores consideraram que os WALs e BDs usavam o mesmo dispositivo. No entanto, também é possível implantar o WAL em um dispositivo dedicado:
20 HDDs
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
2 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
2 NVMes
Fornecedor: Samsung
Modelo: NVME-QQQQ-987
Tamanho: 256 GB
drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987
Na configuração a seguir, tentamos definir:
20 HDDs com 1 NVMe
2 HDDs com 1 SSD(db) e 1 NVMe(wal)
8 SSDs com 1 NVMe
2 SSDs independentes (criptografados)
1 HDD é sobressalente e não deve ser implantado
Veja a seguir o resumo das unidades usadas:
23 HDDs
Fornecedor: Intel
Modelo: SSD-123-foo
Tamanho: 4 TB
10 SSDs
Fornecedor: Micron
Modelo: MC-55-44-ZX
Tamanho: 512 GB
1 NVMe
Fornecedor: Samsung
Modelo: NVME-QQQQ-987
Tamanho: 256 GB
A definição dos DriveGroups será a seguinte:
drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987
drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987
drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987
drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True
Um HDD permanecerá enquanto o arquivo está sendo analisado de cima para baixo.
ceph.conf
com configurações personalizadas #
Se você precisar incluir as configurações personalizadas no arquivo de configuração ceph.conf
, consulte o Seção 2.13, “Ajustando o ceph.conf
com configurações personalizadas” para obter mais detalhes.