ceph-deploy
removido do SUSE Enterprise Storage 5
A ferramenta de implantação de cluster ceph-deploy
foi descontinuada no SUSE Enterprise Storage 4 e totalmente removida para entrada do DeepSea a partir do SUSE Enterprise Storage 5.
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 problemas de desempenho e de procedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadados ou Ceph Monitor no master Salt.
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 4.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.
Durante a Fase 0, se o master Salt for reinicializado 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: descoberta. Nessa fase, você detecta o hardware inteiro no cluster e coleta as informações necessárias para configuração do Ceph. Para obter detalhes sobre a configuração, consulte a Seção 4.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 1.3, “Removendo e reinstalando nós do cluster”.
Você encontra uma apresentação mais detalhada sobre o DeepSea em https://github.com/suse/deepsea/wiki.
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. Para obter mais informações, consulte a documentação do Salt.
/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 está implantado em um subconjunto de nós com outra(s) solução(ões) de cluster, convém “marcar” os minions relevantes aplicando um grain “deepsea”a eles. Dessa forma, você pode direcionar facilmente os minions do DeepSea nos ambientes em que a correspondência por nome de 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 “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. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obter uma descrição de todas as técnicas de direcionamento.
A página de manual do “deepsea-minions” também apresenta mais detalhes sobre o 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 perfis de OSD e implantar os nós do monitor primeiro, poderá fazer isso definindo a variável DEV_ENV
. Ela permite implantar monitores sem a presença do diretório profile/
e implantar um cluster com pelo menos um nó 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
O procedimento a seguir descreve a preparação do cluster em detalhes.
Instale e registre o SUSE Linux Enterprise Server 12 SP3 juntamente com a extensão do SUSE Enterprise Storage em cada nó do cluster.
Verifique se os produtos apropriados estão instalados e foram registrados listando os repositórios de software existentes. A lista será semelhante a esta saída:
root@minion >
zypper lr -E
# | Alias | Name | Enabled | GPG Check | Refresh
---+---------+-----------------------------------+---------+-----------+--------
4 | [...] | SUSE-Enterprise-Storage-5-Pool | Yes | (r ) Yes | No
6 | [...] | SUSE-Enterprise-Storage-5-Updates | Yes | (r ) Yes | Yes
9 | [...] | SLES12-SP3-Pool | Yes | (r ) Yes | No
11 | [...] | SLES12-SP3-Updates | Yes | (r ) Yes | Yes
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-12/book_sle_admin/data/sec_basicnet_yast.html. Para obter mais informações sobre como configurar um servidor DNS, consulte https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.
Configure, habilite e inicie o servidor de sincronização de horário NTP:
root@master #
systemctl enable ntpd.serviceroot@master #
systemctl start ntpd.service
Encontre mais informações sobre como configurar o NTP em https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html.
Verifique se o serviço AppArmor está em execução e desabilite-o em cada nó do cluster. Inicie o módulo AppArmor do YaST, selecione
(Configurações) e, em seguida, desative a caixa de seleção (Habilitar Apparmor). Para confirmar, clique em (Concluído).O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.
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@master #
systemctl stop SuSEfirewall2.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@minion >
systemctl enable salt-minion.serviceroot@minion >
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.
Ver a impressão digital de cada minion:
root@minion >
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, verifique se todos os discos que foram usados como OSD por clusters anteriores estão vazios, sem partições. Para garantir isso, você precisa limpar (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-12/stor_admin/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-12/stor_admin/data/part_software_raid.html para obter mais detalhes.
Se você receber mensagens de erro, como “partition in use” ou “kernel can not be updated with the new partition table” durante as etapas seguintes, reinicialize o servidor.
Limpe o começo de cada partição:
for partition in /dev/sdX[0-9]* do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct done
Limpe a tabela de partição:
sgdisk -Z --clear -g /dev/sdX
Limpe as tabelas de partição de backup:
size=`blockdev --getsz /dev/sdX` position=$((size/4096 - 33)) dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
Instale o DeepSea no nó master Salt:
root@master #
zypper in deepsea
Verifique se o arquivo /srv/pillar/ceph/master_minion.sls
no master Salt aponta para o seu master Salt. Se o master Salt puder ser acessado por outros nomes de host, use o que for mais adequado ao cluster de armazenamento. 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.<número da fase>
, 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.
Inclua os minions Salt pertencentes ao cluster do Ceph que você está implantando atualmente. Consulte a Seção 4.2.2.1, “Correspondendo o nome do minion” para obter mais informações sobre como direcionar os minions.
Prepare o cluster. Consulte a 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 4.4, “CLI do DeepSea”.
Opcional: crie subvolumes Btrfs para /var/lib/ceph/
. Essa etapa apenas deve ser executada antes da execução das próximas fases do DeepSea. Para migrar os diretórios existentes ou para obter mais detalhes, consulte o Seção 18.5, “Subvolume Btrfs para /var/lib/ceph”.
root@master #
salt-run state.orch ceph.migrate.subvolume
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.
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 4.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
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. Nessa fase, o pilar é validado, e os daemons dos monitores e ODS são iniciados nos nós de armazenamento. Execute o seguinte para iniciar a fase:
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:
root@master #
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, openATTIC 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.
O DeepSea também fornece uma ferramenta CLI que permite ao usuário monitorar ou executar as fases enquanto visualiza o andamento da execução em tempo real.
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 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 antes de executar qualquer comando salt-run state.orch
para que ele 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, o nó que atua como OSD ou como nó do monitor. 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, iSCSI Gateway ou openATTIC. 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”, “mds”, “igw”, “rgw”, “ganesha” ou “openattic”.
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 por 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 monitoramento ao cluster do Ceph. Essa função requer os endereços dos minions atribuídos. Desde o SUSE Enterprise Storage 5, o endereço público é calculado dinamicamente e não é mais necessário no pillar do Salt.
role-mon/cluster/mon*.sls
O exemplo atribui a função de monitoramento 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
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/stack/default/ceph/minions/xyz.domain.yml role-igw/cluster/*.sls
rgw:: o minion atuará como Object Gateway:
role-rgw/cluster/rgw*.sls
openattic: o minion atuará como servidor openATTIC:
role-openattic/cluster/openattic*.sls
Para obter mais informações, consulte Capítulo 15, openATTIC.
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.
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 14.3, “Funções personalizadas do NFS Ganesha”.
É 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
No Ceph, uma única função de armazenamento não é suficiente para descrever as várias configurações de disco disponíveis com o mesmo hardware. A fase 1 do DeepSea gerará uma proposta de perfil de armazenamento padrão. Por padrão, essa proposta será um perfil bluestore
e tentará propor a configuração com o desempenho mais alto para a configuração de hardware especificada. Por exemplo, a preferência será por diários externos do que por um único disco com objetos e metadados. O armazenamento de estado sólido terá prioridade sobre os discos giratórios. Os perfis são atribuídos no policy.cfg
similares às funções.
A proposta padrão pode ser encontrada na árvore do diretório padrão do perfil. Para incluir isso, adicione as duas linhas a seguir ao policy.cfg
.
profile-default/cluster/*.sls profile-default/stack/default/ceph/minions/*.yml
Você também pode criar um perfil de armazenamento personalizado de sua preferência usando o executor de proposta. Esse executor oferece três métodos: help, peek e populate.
salt-run proposal.help
imprime o texto de ajuda do executor sobre os vários argumentos que ele aceita.
salt-run proposal.peek
mostra a proposta gerada de acordo com os argumentos passados.
salt-run proposal.populate
grava a proposta no subdiretório /srv/pillar/ceph/proposals
. Passe name=myprofile
para nomear o perfil de armazenamento. Isso resultará em um subdiretório profile-myprofile.
Para todos os outros argumentos, consulte a saída do salt-run proposal.help
.
Desde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStore em vez do FileStore. Embora o BlueStore suporte criptografia, os Ceph OSDs são implantados sem criptografia, por padrão. Vamos supor que ambos os discos de dados e WAL/BD que serão usados para implantação do OSD estejam limpos, sem partições. Se os discos já foram usados, limpe-os seguindo o procedimento descrito na Etapa 13.
Para usar OSDs criptografados em sua nova implantação, use o executor proposal.populate
com o argumento encryption=dmcrypt
:
root@master #
salt-run proposal.populate encryption=dmcrypt
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 # MDS role-mds/cluster/ses-example-4.sls 6 # IGW role-igw/stack/default/ceph/minions/ses-example-4.yml 7 role-igw/cluster/ses-example-4.sls 8 # RGW role-rgw/cluster/ses-example-4.sls 9 # openATTIC role-openattic/cluster/openattic*.sls 10 # COMMON config/stack/default/global.yml 11 config/stack/default/ceph/cluster.yml 12 ## Profiles profile-default/cluster/*.sls 13 profile-default/stack/default/ceph/minions/*.yml 14
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. | |
O minion “ses-example-4” terá a função MDS. | |
Verifique se o DeepSea sabe o endereço IP do nó IGW. | |
O minion “ses-example-4” terá a função IGW. | |
O minion “ses-example-4” terá a função RGW. | |
Especifica para implantar a interface do usuário do openATTIC para administrar o cluster do Ceph. Consulte a Capítulo 15, openATTIC para obter mais detalhes. | |
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 | |
Informamos ao DeepSea para usar o perfil de hardware padrão para cada minion. A escolha do perfil de hardware padrão significa que todos os discos adicionais (exceto o disco raiz) devem ser OSDs. | |
Informamos ao DeepSea para usar o perfil de hardware padrão para cada minion. A escolha do perfil de hardware padrão significa que todos os discos adicionais (exceto o disco raiz) devem ser OSDs. |
ceph.conf
personalizado #
Se você precisar incluir as configurações personalizadas no arquivo de configuração ceph.conf
, consulte o Seção 1.11, “Arquivo ceph.conf
personalizado” para obter mais detalhes.