Para efetuar login no Ceph Dashboard, aponte seu navegador para o URL dele, incluindo o número da porta. Execute o seguinte comando para encontrar o endereço:

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

O comando retorna o URL em que o Ceph Dashboard está localizado. Se você tiver problemas com esse comando, consulte o Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”.

Figura 2.1: Tela de login do Ceph Dashboard #

 

Efetue login usando as credenciais que você criou durante a implantação do cluster (consulte o Book “Guia de Implantação”, Chapter 5 “Implantação com cephadm”, Section 5.3.2.9 “Configurando as credenciais de login do Ceph Dashboard”).

Dica: Conta do usuário personalizada

Se você não deseja usar a conta padrão admin para acessar o Ceph Dashboard, crie uma conta do usuário personalizada com privilégios de administrador. Consulte Capítulo 11, Gerenciar usuários e funções na linha de comando para obter mais detalhes.

A interface do usuário do painel de controle é dividida graficamente em vários blocos: o menu de utilitários na lateral superior direita da tela, o menu principal na lateral esquerda e o painel de conteúdo principal.

Figura 2.2: Home page do Ceph Dashboard #

 

A lateral superior direita da tela contém um menu de utilitários. Ele inclui tarefas gerais relacionadas mais ao painel de controle do que ao cluster do Ceph. Ao clicar nas opções, você pode acessar os seguintes tópicos:

O menu principal do painel de controle ocupa a lateral esquerda da tela. Ela abrange os seguintes tópicos:

O painel de conteúdo ocupa a parte principal da tela do painel de controle. A home page do painel de controle mostra muitos widgets úteis para informar você brevemente sobre as informações de status atual, capacidade e desempenho do cluster.

No Ceph Dashboard, você costuma trabalhar com listas. Por exemplo, listas de pools, nós OSD ou dispositivos RBD. Todas as listas se atualizarão automaticamente por padrão a cada cinco segundos. Os seguintes widgets comuns ajudam você a gerenciar ou ajustar essas listas:

Clique em para acionar uma atualização manual da lista.

Clique em para exibir ou ocultar colunas individuais da tabela.

Clique em e insira (ou selecione) quantas linhas serão exibidas em uma única página.

Clique em e filtre as linhas digitando a string de pesquisa.

Use para mudar a página exibida no momento, se a lista ocupar várias páginas.

Cada widget do painel de controle mostra informações de status específicas relacionadas a um determinado aspecto de um cluster do Ceph em execução. Alguns widgets são links ativos e, depois de clicar neles, redirecionarão você para uma página detalhada relacionada do tópico que eles representam.

Dica: Mais detalhes ao mover o cursor do mouse

Alguns widgets gráficos mostram mais detalhes quando você move o cursor do mouse sobre eles.

2.6.1 Widgets de status #

 

Os widgets de status apresentam uma breve visão geral do status atual do cluster.

Figura 2.3: Widgets de status #

 

Status do Cluster

Apresenta informações básicas sobre a saúde do cluster.

Hosts

Mostra o número total de nós do cluster.

Monitores

Mostra o número de monitores em execução e o quorum deles.

OSDs

Mostra o número total de OSDs e o número de OSDs ativos e incluídos.

Gerentes

Mostra o número de daemons Ceph Manager ativos e em standby.

Gateways de Objetos

Mostra o número de Gateways de Objetos em execução.

Servidores de Metadados

Mostra o número de Servidores de Metadados.

iSCSI Gateways

Mostra o número de gateways iSCSI configurados.

2.6.2 Widgets de capacidade #

 

Os widgets de capacidade mostram informações resumidas sobre a capacidade de armazenamento.

Figura 2.4: Widgets de capacidade #

 

Capacidade Bruta

Mostra a proporção de capacidade de armazenamento usado e bruto disponível.

Objetos

Mostra o número de objetos de dados armazenados no cluster.

Status do PG

Exibe um gráfico dos grupos de posicionamento de acordo com o status deles.

Pools

Mostra o número de pools no cluster.

PGs por OSD

Mostra o número médio de grupos de posicionamento por OSD.

2.6.3 Widgets de desempenho #

 

Os widgets de desempenho referem-se aos dados básicos de desempenho dos clientes do Ceph.

Figura 2.5: widgets de desempenho #

 

Leitura/Gravação do Cliente

A quantidade de operações de leitura e gravação dos clientes por segundo.

Throughput do Cliente

A quantidade de dados transferidos de e para os clientes do Ceph em bytes por segundo.

Throughput de Recuperação

O throughput de dados recuperados por segundo.

Depuração

Mostra o status da remoção (consulte a Seção 17.4.9, “Depurando um grupo de posicionamento”). Ele é inativo, habilitado ou ativo.

Clique em no menu de utilitários e selecione Gerenciamento de usuários.

A lista contém o nome de usuário, o nome completo e o e-mail de cada usuário, uma lista de funções atribuídas, se a função está habilitada e a data de vencimento da senha.

Figura 3.1: Gerenciamento de usuários #

 

Clique em Criar na parte superior esquerda do cabeçalho da tabela para adicionar um novo usuário. Insira seu nome de usuário, senha e, opcionalmente, um nome completo e um e-mail.

Figura 3.2: Adicionando um usuário #

 

Clique no ícone pequeno de caneta para atribuir funções predefinidas ao usuário. Clique em Criar usuário para confirmar.

Clique na linha da tabela de um usuário para realçar a seleção e escolha Editar para editar os detalhes sobre o usuário. Clique em Editar Usuário para confirmar.

Clique na linha da tabela de um usuário para realçar a seleção, escolha o botão suspenso ao lado de Editar e selecione Excluir na lista para apagar a conta do usuário. Ative a caixa de seleção Sim, desejo e clique em Excluir usuário para confirmar.

Clique em no menu de utilitários e selecione Gerenciamento de usuários. Em seguida, clique na guia Funções.

A lista mostra o nome e a descrição de cada função e se é uma função do sistema.

Figura 3.3: Funções de usuário #

 

Clique em Criar na parte superior esquerda do cabeçalho da tabela para adicionar uma nova função personalizada. Insira o Nome e a Descrição e selecione as permissões apropriadas ao lado de Permissões.

Dica: Purgando funções personalizadas

Se você cria funções de usuário personalizadas e depois planeja remover o cluster do Ceph com o comando ceph-salt purge, precisa purgar primeiro as funções personalizadas. Encontre mais detalhes na Seção 13.9, “Removendo um cluster inteiro do Ceph”.

Figura 3.4: Adicionando uma função #

 

Dica: Ativação múltipla

Ao ativar a caixa de seleção que antecede o nome do tópico, você ativa todas as permissões para esse tópico. Ao ativar a caixa de seleção Tudo, você ativa todas as permissões para todos os tópicos.

Clique em Criar função para confirmar.

Clique na linha da tabela de um usuário para realçar a seleção e escolha Editar na parte superior esquerda do cabeçalho da tabela para editar uma descrição e as permissões da função personalizada. Clique em Editar Função para confirmar.

Clique na linha da tabela de uma função para realçar a seleção, escolha o botão suspenso ao lado de Editar e selecione Excluir na lista para apagar a função. Ative a caixa de seleção Sim, desejo e clique em Excluir função para confirmar.

Clique em Cluster › Hosts para ver uma lista de nós do cluster.

Figura 4.1: Hosts #

 

Clique na seta suspensa ao lado do nome de um nó na coluna Nome de host para ver os detalhes do desempenho do nó.

A coluna Serviços lista todos os daemons que estão em execução em cada nó relacionado. Clique no nome de um daemon para ver sua configuração detalhada.

Clique em Cluster › Inventário para ver uma lista de dispositivos. A lista inclui o caminho, o tipo, a disponibilidade, o fornecedor, o modelo, o tamanho e os OSDs do dispositivo.

Clique para selecionar o nome de um nó na coluna Nome de host. Quando selecionado, clique em Identificar para identificar o dispositivo no qual o host está sendo executado. Esse procedimento instrui o dispositivo a piscar os LEDs. Selecione a duração dessa ação entre 1, 2, 5, 10 ou 15 minutos. Clique em Executar.

Figura 4.2: Serviços #

 

Clique em Cluster › Monitores para ver uma lista de nós do cluster com monitores do Ceph em execução. O painel de conteúdo é dividido em duas telas: Status e No Quorum ou Não está no Quorum.

A tabela Status mostra as estatísticas gerais dos Ceph Monitors em execução, incluindo as seguintes:

Os painéis No Quorum e Não está no Quorum incluem o nome, o número de classificação, o endereço IP público e o número de sessões abertas de cada monitor.

Clique no nome de um nó na coluna Nome para ver a configuração do Ceph Monitor relacionado.

Figura 4.3: Ceph Monitors #

 

Clique em Cluster › Serviços para ver os detalhes de cada um dos serviços disponíveis: crash, Ceph Manager e Ceph Monitors. A lista inclui o nome da imagem do container, o ID da imagem do container, o status do elemento que está em execução, o tamanho e a data da última atualização.

Clique na seta suspensa ao lado do nome de um serviço na coluna Serviço para ver os detalhes do daemon. A lista de detalhes inclui nome de host, tipo de daemon, ID do daemon, ID do container, nome da imagem do container, ID da imagem do container, número da versão, status e data da última atualização.

Figura 4.4: Serviços #

 

Clique em Cluster › OSDs para ver uma lista de nós com daemons OSD em execução. A lista inclui nome, ID, status, classe do dispositivo, número de grupos de posicionamento, tamanho, uso, cronograma de leituras/gravações e taxa de operações de leitura/gravação por segundo de cada nó.

Figura 4.5: Ceph OSDs #

 

Selecione Flags no menu suspenso Configuração de todo o cluster no cabeçalho da tabela para abrir uma janela popup. Ela mostra uma lista de flags que se aplicam a todo o cluster. É possível ativar ou desativar flags individuais e clicar em Enviar para confirmar.

Figura 4.6: Flags OSD #

 

Selecione Prioridade de Recuperação no menu suspenso Configuração de todo o cluster no cabeçalho da tabela para abrir uma janela popup. Ela mostra uma lista de prioridades de recuperação de OSD que se aplicam a todo o cluster. É possível ativar o perfil de prioridade preferencial e ajustar os valores individuais a seguir. Clique em Enviar para confirmar.

Figura 4.7: Prioridade de recuperação de OSD #

 

Clique na seta suspensa ao lado do nome de um nó na coluna Host para ver uma tabela estendida com os detalhes das configurações e do desempenho do dispositivo. Ao navegar pelas diversas guias, você pode ver listas de Atributos, Metadados, Saúde do dispositivo, Contador de desempenho, um Histograma gráfico das leituras e gravações e Detalhes de Desempenho.

Figura 4.8: Detalhes do OSD #

 

Dica: Executando tarefas específicas nos OSDs

Depois que você clicar no nome de um nó OSD, a linha da tabela será realçada. Isso significa que agora você pode executar uma tarefa no nó. É possível executar qualquer uma das seguintes ações: Editar, Criar, Remoção, Remoção Profunda, Reponderar, Marcar como Saída, Marcar como Entrada, Marcar como Inativo, Marcar como Perdido, Purgar, Destruir ou Excluir.

Clique na seta para baixo na parte superior esquerda do cabeçalho da tabela ao lado do botão Criar e selecione a tarefa que deseja executar.

Clique em Cluster › Configuração para ver uma lista completa de opções de configuração de cluster do Ceph. A lista contém o nome da opção, sua descrição resumida e seus valores atuais e padrão e indica se a opção é editável.

Figura 4.14: Configuração do cluster #

 

Clique na seta suspensa ao lado de uma opção de configuração na coluna Nome para ver uma tabela estendida com informações detalhadas sobre a opção, como tipo de valor, valores mínimo e máximo permitidos, se é possível atualizá-la em tempo de execução etc.

Após realçar uma opção específica, você poderá editar o(s) valor(s) dela clicando no botão Editar na parte superior esquerda do cabeçalho da tabela. Clique em Salvar para confirmar as mudanças.

Clique em Cluster › Mapa CRUSH para ver um Mapa CRUSH do cluster. Para obter mais informações gerais sobre Mapas CRUSH, consulte a Seção 17.5, “Manipulação de mapa CRUSH”.

Clique em cada raiz, nó ou OSD para ver informações mais detalhadas, como peso do CRUSH, profundidade na árvore de mapa, classe de dispositivo do OSD e muitos mais.

Figura 4.15: Mapa CRUSH #

 

Clique em Cluster › Módulos do gerenciador para ver uma lista dos módulos disponíveis do Ceph Manager. Cada linha consiste no nome do módulo e nas informações que indicam se ele está ou não habilitado no momento.

Figura 4.16: Módulos do gerenciador #

 

Clique na seta suspensa ao lado de um módulo na coluna Nome para ver uma tabela estendida com as configurações detalhadas na tabela Detalhes abaixo. Para editá-las, clique no botão Editar na parte superior esquerda do cabeçalho da tabela. Clique em Atualizar para confirmar as mudanças.

Clique na seta suspensa ao lado do botão Editar na parte superior esquerda do cabeçalho da tabela para Habilitar ou Desabilitar um módulo.

Clique em Cluster › Registros para ver uma lista das entradas de registro recentes do cluster. Cada linha consiste em uma marcação de horário, no tipo de entrada de registro e na própria mensagem registrada.

Clique na guia Registros de Auditoria para ver as entradas de registro do subsistema de auditoria. Consulte a Seção 11.5, “Fazendo auditoria das solicitações de API” para ver os comandos que habilitam ou desabilitam a auditoria.

Figura 4.17: Registros #

 

Clique em Cluster › Monitoramento para gerenciar e ver detalhes sobre os alertas do Prometheus.

Se o Prometheus estiver ativo, você poderá ver informações detalhadas sobre Alertas Ativos, Todos os Alertas ou Silêncios nesse painel de conteúdo.

Nota

Se você não tiver o Prometheus implantado, um banner de informações será exibido com um link para a documentação relevante.

Para adicionar um novo pool, clique em Criar na parte superior esquerda da tabela de pools. No formulário do pool, você pode inserir o nome, o tipo, os aplicativos, o modo de compactação e as cotas do pool, incluindo o máximo de bytes e de objetos. O próprio formulário do pool pré-calcula o número de grupos de posicionamento mais adequado a esse pool específico. O cálculo é baseado na quantidade de OSDs no cluster e no tipo de pool selecionado com suas configurações específicas. Assim que um número de grupos de posicionamento for definido manualmente, ele será substituído por um número calculado. Clique em Criar Pool para confirmar.

Figura 5.2: Adicionando um novo pool #

 

Para apagar um pool, selecione-o na linha da tabela. Clique na seta suspensa ao lado do botão Criar e clique em Excluir.

Para editar as opções de um pool, selecione-o na linha da tabela e clique em Editar na parte superior esquerda da tabela de pools.

É possível mudar o nome do pool, aumentar o número de grupos de posicionamento, modificar a lista de aplicativos e as configurações de compactação do pool. Clique em Editar Pool para confirmar.

Para ver informações mais detalhadas sobre um dispositivo, clique na linha dele na tabela:

Figura 6.2: Detalhes do RBD #

 

Para ver a configuração detalhada de um dispositivo, clique na linha dele na tabela e, em seguida, na guia Configuração na tabela inferior:

Figura 6.3: Configuração do RBD #

 

Para adicionar um novo dispositivo, clique em Criar na parte superior esquerda do cabeçalho da tabela e faça o seguinte na tela Criar RBD:

Figura 6.4: Adicionando um novo RBD #

 

Para apagar um dispositivo, selecione-o na linha da tabela. Clique na seta suspensa ao lado do botão Criar e clique em Excluir. Clique em Excluir RBD para confirmar a exclusão.

Dica: Movendo RBDs para o lixo

A exclusão de um RBD é uma ação irreversível. Em vez disso, se você Mover para Lixo, poderá restaurar o dispositivo posteriormente selecionando-o na guia Lixo da tabela principal e clicando em Restaurar na parte superior esquerda do cabeçalho da tabela.

Para criar um instantâneo de Dispositivo de Blocos RADOS, selecione o dispositivo na linha da tabela, e o painel de conteúdo da configuração detalhada é exibido. Selecione a guia Instantâneos e clique em Criar na parte superior esquerda do cabeçalho da tabela. Insira o nome do instantâneo e clique em Criar Instantâneo do RBD para confirmar.

Após selecionar um instantâneo, você poderá executar outras ações no dispositivo, como renomear, proteger, clonar, copiar ou apagar. Rollback restaura o estado do dispositivo com base no instantâneo atual.

Figura 6.5: Instantâneos do RBD #

 

É possível espelhar as imagens de Dispositivo de Blocos RADOS de forma assíncrona entre dois clusters do Ceph. Você pode usar o Ceph Dashboard para configurar a replicação de imagens RBD entre dois ou mais clusters. Esse recurso está disponível em dois modos:

O espelhamento é configurado por pool nos clusters de peer e pode ser configurado em um subconjunto específico de imagens no pool ou configurado para espelhar automaticamente todas as imagens em um pool ao usar apenas o espelhamento com base em diário.

O espelhamento é configurado usando o comando rbd que, por padrão, está instalado no SUSE Enterprise Storage 7. O daemon rbd-mirror é responsável por capturar as atualizações da imagem do cluster de peer remoto e aplicá-las à imagem no cluster local. Consulte a Seção 6.6.2, “Habilitando o daemon rbd-mirror” para obter mais informações sobre como habilitar o daemon rbd-mirror.

Dependendo da necessidade de replicação, o espelhamento de Dispositivo de Blocos RADOS pode ser configurado para replicação unidirecional ou bidirecional:

Importante

Cada instância do daemon rbd-mirror deve ser capaz de se conectar aos clusters do Ceph local e remoto simultaneamente, por exemplo, todos os hosts de monitor e OSD. Além disso, a rede deve ter largura de banda suficiente entre os dois data centers para processar a carga de trabalho de espelhamento.

Dica: Informações gerais

Para obter informações gerais e a abordagem de linha de comando para espelhamento do Dispositivo de Blocos RADOS, consute a Seção 20.4, “Espelhos de imagens RBD”.

6.6.1 Configurando clusters principais e secundários #

 

O cluster principal é onde o pool original com as imagens é criado. O cluster secundário é onde o pool ou as imagens são replicados do cluster principal.

Nota: Nomeação relativa

Os termos principal e secundário podem ser relativos no contexto de replicação porque estão mais relacionados aos pools individuais do que aos clusters. Por exemplo, na replicação de duas vias, é possível espelhar um pool do cluster principal para o secundário. É possível também espelhar outro pool do cluster secundário para o principal.

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm \
  1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

Dica: Mais informações sobre gateways iSCSI

Para obter mais informações gerais sobre os Gateways iSCSI, consulte o Capítulo 22, Ceph iSCSI Gateway.

Para listar todos os gateways e imagens mapeadas disponíveis, clique em Bloco › iSCSI no menu principal. A guia Visão geral é aberta com a lista atual dos iSCSI Gateways configurados e das imagens RBD mapeadas.

A tabela Gateways lista o estado de cada gateway, o número de destinos iSCSI e a quantidade de sessões. A tabela Imagens lista o nome de cada imagem mapeada, o tipo de backstore do nome do pool relacionado e outros detalhes estatísticos.

A guia Destinos lista os destinos iSCSI configurados no momento.

Figura 6.14: Lista de destinos iSCSI #

 

Para ver informações mais detalhadas sobre um destino, clique na seta suspensa na linha da tabela de destinos. Um esquema estruturado em árvore é aberto com uma lista de discos, portais, iniciadores e grupos. Clique em um item para expandi-lo e ver seu conteúdo detalhado, opcionalmente com uma configuração relacionada na tabela à direita.

Figura 6.15: Detalhes do destino iSCSI #

 

6.7.1 Adicionando destinos iSCSI #

 

Para adicionar um novo destino iSCSI, clique em Criar na parte superior esquerda da tabela Destinos e insira as informações necessárias.

Figura 6.16: Adicionando um novo destino #

 

1. Digite o endereço de destino do novo gateway.

2. Clique em Adicionar portal e selecione um ou vários portais iSCSI na lista.

3. Clique em Adicionar imagem e selecione uma ou várias imagens RBD para o gateway.

4. Se você precisa usar a autenticação para acessar o gateway, ative a caixa de seleção Autenticação ACL e insira as credenciais. Você poderá encontrar opções de autenticação mais avançadas após ativar Autenticação mútua e Autenticação de descoberta.

5. Clique em Criar Destino para confirmar.

Dica: Para obter mais informações

Para obter mais informações gerais e uma descrição das opções de configuração de QdS do RBD, consulte a Seção 20.6, “Configurações de QdS”.

É possível configurar as opções de QdS em diferentes níveis.

A configuração global fica na parte superior da lista e será usada para todas as imagens RBD recém-criadas e para as imagens que não anulam esses valores no pool nem na camada da imagem RBD. Um valor de opção especificado globalmente pode ser anulado por pool ou por imagem. As opções especificadas em um pool serão aplicadas a todas as imagens RBD desse pool, exceto se forem anuladas por uma opção de configuração definida em uma imagem. As opções especificadas em uma imagem anularão as opções especificadas em um pool e globalmente.

Dessa forma, é possível definir padrões globalmente, adaptá-los a todas as imagens RBD de um pool específico e anular a configuração do pool para imagens RBD individuais.

6.8.2 Configurando opções em um novo pool #

 

Para criar um novo pool e definir opções de configuração do RBD nele, clique em Pools › Criar. Selecione replicado como tipo de pool. Em seguida, você precisa adicionar a tag do aplicativo rbd ao pool para poder configurar as opções de QdS do RBD.

Nota

Não é possível definir opções de configuração de QdS do RBD em um pool codificado para eliminação. Para definir opções de QdS do RBD para pools codificados para eliminação, você precisa editar o pool replicado de metadados de uma imagem RBD. Na sequência, a configuração será aplicada ao pool de dados codificado para eliminação dessa imagem.

6.8.3 Configurando opções em pool existente #

 

Para definir opções de QdS do RBD em um pool existente, clique em Pools, clique na linha do pool na tabela e selecione Editar na parte superior esquerda da tabela.

Você deve ver a seção Configuração do RBD na caixa de diálogo, seguida de uma seção Qualidade do Serviço.

Nota

Se a seção Configuração do RBD ou Qualidade do Serviço não for exibida, provavelmente você estará editando um pool codificado para eliminação, que não pode ser usado para definir opções de configuração do RBD, ou o pool não foi configurado para uso por imagens RBD. Neste último caso, atribua a tag do aplicativo rbd ao pool, e as seções de configuração correspondentes serão exibidas.

Para adicionar uma nova exportação do NFS, clique em Criar na parte superior esquerda da tabela de exportações e insira as informações necessárias.

Figura 7.3: Adicionando uma nova exportação do NFS #

 

Para apagar uma exportação, selecione-a e realce-a na linha da tabela. Clique na seta suspensa ao lado do botão Editar e selecione Excluir. Ative a caixa de seleção Sim, desejo e clique em Excluir exportação do NFS para confirmar.

Para editar uma exportação existente, selecione-a e realce-a na linha da tabela e clique em Editar na parte superior esquerda da tabela de exportações.

Em seguida, você pode ajustar todos os detalhes da exportação NFS.

Figura 7.4: Editando uma exportação do NFS #

 

Clique em Sistemas de arquivos no menu principal para acessar a visão geral dos sistemas de arquivos configurados. A tabela principal mostra o nome e a data de criação de cada sistema de arquivos, e se ele está ou não habilitado.

Ao clicar na linha de um sistema de arquivos na tabela, você revela detalhes sobre sua classificação e os pools adicionados a ele.

Figura 8.1: Detalhes do CephFS #

 

Na parte inferior da tela, você pode ver estatísticas que mostram o número de inodes MDS relacionados e solicitações de clientes, coletadas em tempo real.

Figura 8.2: Detalhes do CephFS #

 

Para ver uma lista de Gateways de Objetos configurados, clique em Gateway de Objetos › Daemons. A lista inclui o ID do gateway, o nome de host do nó do cluster onde o daemon do gateway está sendo executado e o número da versão do gateway.

Clique na seta suspensa ao lado do nome do gateway para ver informações detalhadas sobre ele. A guia Contadores de Desempenho mostra detalhes sobre as operações de leitura/gravação e as estatísticas do cache.

Figura 9.1: Detalhes do gateway #

 

Clique em Gateway de Objetos › Usuários para ver uma lista dos usuários existentes do Gateway de Objetos.

Clique na seta suspensa ao lado do nome do usuário para ver detalhes sobre a conta do usuário, como informações de status ou os detalhes de cota do usuário e do compartimento de memória.

Figura 9.2: Usuários do gateway #

 

9.2.1 Adicionando um novo usuário do gateway #

 

Para adicionar um novo usuário do gateway, clique em criar na parte superior esquerda do cabeçalho da tabela. Preencha as credenciais dele, os detalhes sobre a chave S3 e as cotas do usuário e do compartimento de memória e clique em Criar Usuário para confirmar.

Figura 9.3: Adicionando um novo usuário do gateway #

 

Os compartimentos de memória do Gateway de Objetos (OGW) implementam a funcionalidade dos containers OpenStack Swift. Os compartimentos de memória do Gateway de Objetos servem como containers para armazenar objetos de dados.

Clique em Gateway de Objetos › Compartimentos para ver uma lista de compartimentos de memória do Gateway de Objetos.

9.3.1 Adicionando um novo compartimento de memória #

 

Para adicionar um novo compartimento de memória do Gateway de Objetos, clique em Criar na parte superior esquerda do cabeçalho da tabela. Insira o nome do compartimento de memória, selecione o proprietário e defina o destino de posicionamento. Clique em Criar Compartimento para confirmar.

Nota

Nesta fase, você também pode habilitar o bloqueio selecionando Habilitado; no entanto, esse recurso poderá ser configurado após a criação. Consulte a Seção 9.3.3, “Editando o compartimento de memória” para obter mais informações.

9.3.2 Visualizando detalhes do compartimento de memória #

 

Para ver informações detalhadas sobre um compartimento de memória do Gateway de Objetos, clique na seta suspensa ao lado do nome do compartimento de memória.

Figura 9.4: Detalhes do compartimento de memória do gateway #

 

Dica: Cota de compartimento de memória

Abaixo da tabela Detalhes, você encontra detalhes sobre as configurações de cota e bloqueio de compartimento de memória.

9.3.3 Editando o compartimento de memória #

 

Selecione e realce um compartimento de memória e clique em Editar na parte superior esquerda do cabeçalho da tabela.

Você pode atualizar o proprietário do compartimento de memória ou habilitar o controle de versão, a autenticação multifator ou o bloqueio. Clique em Editar Compartimento para confirmar qualquer mudança.

Figura 9.5: Editando os detalhes do compartimento de memória #

 

Por padrão, todas as conexões HTTP com o painel de controle são protegidas com TLS/SSL. Uma conexão segura requer um certificado SSL. Você pode usar um certificado autoassinado ou gerar um certificado assinado por uma autoridade de certificação (CA, certificate authority) reconhecida.

Dica: Desabilitação de SSL

Talvez você tenha algum motivo específico para desabilitar o suporte a SSL. Por exemplo, se o painel de controle for executado por meio de um proxy que não suporta SSL.

Tenha cuidado ao desabilitar o SSL, já que os nomes de usuário e as senhas serão enviados ao painel de controle não criptografados.

Para desabilitar o SSL, execute:

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

Dica: Reiniciando os processos do Ceph Manager

Você precisará reiniciar os processos do Ceph Manager manualmente após mudar o certificado SSL e a chave. Para fazer isso, é possível executar

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

ou desabilitar e habilitar novamente o módulo do painel de controle, o que também aciona o gerenciador para se reativar:

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 Criando certificados autoassinados #

 

A criação de um certificado autoassinado para uma comunicação segura é simples. Dessa forma, você pode fazer com que o painel de controle seja executado rapidamente.

Nota: Reclamação dos browsers da Web

A maioria dos browsers da Web reclamará de um certificado autoassinado e exigirá a confirmação explícita antes de estabelecer uma conexão segura com o painel de controle.

Para gerar e instalar um certificado autoassinado, use o seguinte comando incorporado:

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 Usando certificados assinados por CA #

 

Para proteger apropriadamente a conexão com o painel de controel e eliminar as reclamações do browser da Web por causa de um certificado autoassinado, recomendamos o uso de um certificado assinado por uma CA.

Você pode gerar um par de chaves do certificado com um comando semelhante ao seguinte:

root # openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

O comando acima resulta nos arquivos dashboard.key e dashboard.crt. Após receber o arquivo dashboard.crt assinado por uma CA, habilite-o para todas as instâncias do Ceph Manager executando os seguintes comandos:

cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

Dica: Certificados diferentes para cada instância do gerenciador

Se você precisar de certificados diferentes para cada instância do Ceph Manager, modifique os comandos e inclua o nome da instância da seguinte maneira. Substitua NAME pelo nome da instância do Ceph Manager (normalmente, o nome de host relacionado):

cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

O Ceph Dashboard está vinculado a um endereço TCP/IP e uma porta TCP específicos. Por padrão, o Ceph Manager ativo no momento e que hospeda o painel de controle está vinculado à porta TCP 8443 (ou 8080 quando o SSL está desabilitado).

Nota

Se um firewall estiver habilitado nos hosts que executam o Ceph Manager (e, portanto, o Ceph Dashboard), talvez seja necessário mudar a configuração para habilitar o acesso a essas portas. Para obter mais informações sobre as configurações de firewall do Ceph, consulte o Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Por padrão, o Ceph Dashboard está vinculado a "::", que corresponde a todos os endereços IPv4 e IPv6 disponíveis. Você pode mudar o endereço IP e o número da porta do aplicativo Web para que eles se apliquem a todas as instâncias do Ceph Manager usando os seguintes comandos:

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

Dica: Configurando as instâncias do Ceph Manager separadamente

Como cada daemon ceph-mgr hospeda sua própria instância do painel de controle, talvez seja necessário configurá-los separadamente. Mude o endereço IP e o número da porta para uma instância específica do gerenciador usando os seguintes comandos (substitua NAME pelo ID da instância do ceph-mgr):

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

Dica: Listando endpoints configurados

O comando ceph mgr services exibe todos os endpoints que estão configurados. Procure a chave dashboard para obter o URL de acesso ao painel de controle.

Se você não deseja usar a conta de administrador padrão, crie uma conta de usuário diferente e associe-a a pelo menos uma função. Oferecemos um conjunto de funções de sistema predefinidas que você pode usar. Para obter mais detalhes, consulte a Capítulo 11, Gerenciar usuários e funções na linha de comando.

Para criar um usuário com privilégios de administrador, use o seguinte comando:

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

Para usar a funcionalidade de gerenciamento do Gateway de Objetos do painel de controle, você precisa fornecer as credenciais de login de um usuário com o flag system habilitado:

Nota

Por padrão, o firewall está habilitado no SUSE Linux Enterprise Server 15 SP2. Para obter informações sobre configuração de firewall, consulte o Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Há vários pontos a serem considerados:

O Ceph Dashboard gerencia destinos iSCSI usando a API REST fornecida pelo serviço rbd-target-api do gateway Ceph iSCSI. Verifique se ela está instalada e habilitada nos gateways iSCSI.

Nota

A funcionalidade de gerenciamento de iSCSI do Ceph Dashboard depende da versão 3 mais recente do projeto ceph-iscsi. Verifique se o seu sistema operacional tem a versão correta; do contrário, o Ceph Dashboard não habilitará os recursos de gerenciamento.

Se a API REST do ceph-iscsi estiver configurada no modo HTTPS e usar um certificado autoassinado, configure o painel de controle para evitar a verificação do certificado SSL ao acessar a API do ceph-iscsi.

Desabilite a verificação do SSL da API:

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

Defina os gateways iSCSI disponíveis:

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

O Login Único (SSO, Single Sign-On) é um método de controle de acesso que permite aos usuários efetuar login com ID e senha exclusivos em vários aplicativos simultaneamente.

O Ceph Dashboard suporta autenticação externa de usuários por meio do protocolo SAML 2.0. Como a autorização ainda é realizada pelo painel de controle, você precisa primeiro criar as contas de usuário e associá-las às funções desejadas. No entanto, o processo de autenticação pode ser efetuado por um Provedor de Identidade (IdP, Identity Provider) existente.

Para configurar o Login Único, use o seguinte comando:

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

Parâmetros:

Nota: Solicitações SAML

O valor do emissor das solicitações SAML seguirá este padrão:

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

Para exibir a configuração atual do SAML 2.0, execute:

cephuser@adm > ceph dashboard sso show saml2

Para desabilitar o Login Único, execute:

cephuser@adm > ceph dashboard sso disable

Para verificar se o SSO está habilitado, execute:

cephuser@adm > ceph dashboard sso status

Para habilitar o SSO, execute:

cephuser@adm > ceph dashboard sso enable saml2

Por padrão, o recurso de política de senha está habilitado, incluindo as seguintes verificações:

O recurso de política de senha pode ser ativado ou desativado completamente:

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

Cada uma destas verificações pode ser ativada ou desativada:

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

As seguintes opções tambem estão disponíveis para configurar o comportamento da política de senha.

O Ceph Dashboard suporta o gerenciamento de várias contas de usuário. Cada conta de usuário consiste em nome de usuário, senha (armazenada em formato criptografado com bcrypt), além de nome e endereço de e-mail opcionais.

As contas de usuário são armazenadas no banco de dados de configuração do Ceph Monitor e compartilhadas globalmente com todas as instâncias do Ceph Manager.

Use os seguintes comandos para gerenciar as contas de usuário:

Esta seção descreve quais escopos de segurança você pode atribuir a uma função de usuário, como gerenciar as funções deo usuário e atribuí-las a contas de usuário.

11.3.2 Especificando funções de usuário #

 

Uma função especifica um conjunto de mapeamentos entre um escopo de segurança e um conjunto de permissões. Há quatro tipos de permissões: “read”, “create”, “update” e “delete”.

O exemplo a seguir especifica uma função em que um usuário tem permissões de "leitura" e "criação" para recursos relacionados ao gerenciamento de pools e tem permissões completas para recursos relacionados ao gerenciamento de imagens RBD:

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

O painel de controle já dispõe de um conjunto de funções predefinidas que chamamos de funções de sistema. Você pode usá-las logo após uma instalação recente do Ceph Dashboard:

administrator

Concede permissões completas para todos os escopos de segurança.

read-only

Concede permissão de leitura para todos os escopos de segurança, exceto as configurações do painel de controle.

block-manager

Concede permissões completas para os escopos “rbd-image”, “rbd-mirroring” e “iscsi”.

rgw-manager

Concede permissões completas para o escopo “rgw”.

cluster-manager

Concede permissões completas para os escopos “hosts”, “osd”, “monitor”, “manager” e “config-opt”.

pool-manager

Concede permissões completas para o escopo “pool”.

cephfs-manager

Concede permissões completas para o escopo “cephfs”.

11.3.2.1 Gerenciando funções personalizadas #

 

Você pode criar novas funções de usuário executando os seguintes comandos:

Criar uma nova função:

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

Apagar uma função:

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

Adicionar permissões de escopo a uma função:

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

Apagar permissões de escopo a uma função:

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 Atribuindo funções às contas dos usuários #

 

Use os seguintes comandos para atribuir funções a usuários:

Definir funções de usuário:

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

Adicionar mais funções a um usuário:

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

Apagar funções de um usuário:

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

Dica: Purgando funções personalizadas

Se você cria funções de usuário personalizadas e posteriormente pretende remover o cluster do Ceph com o executor ceph.purge, precisa purgar primeiro as funções personalizadas. Encontre mais detalhes na Seção 13.9, “Removendo um cluster inteiro do Ceph”.

11.3.2.3 Exemplo: Criando um usuário e uma função personalizada #

 

Esta seção ilustra um procedimento para criar uma conta de usuário capaz de gerenciar imagens RBD, ver e criar pools do Ceph e obter acesso apenas leitura a qualquer outro escopo.

1. Criar um novo usuário chamado tux:

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. Criar uma função e especificar permissões de escopo:

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. Associar as funções ao usuário tux:

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Para estabelecer um URL fixo para acessar o Ceph Dashboard, ou se você não deseja permitir conexões diretas com os nós do gerenciador, pode configurar um proxy que encaminhe automaticamente as solicitações recebidas para a instância ativa do ceph-mgr no momento.

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 Exemplo de configuração do HAProxy #

 

O exemplo de configuração a seguir refere-se à transferência de TLS/SSL por meio do HAProxy.

Nota

A configuração funciona nas seguintes condições: Se o painel de controle falhar, o cliente de front end poderá receber uma resposta de redirecionamento HTTP (303) e será redirecionado para um host não resolvido.

Isso acontece quando o failover ocorre durante duas verificações de saúde do HAProxy. Nessa situação, o nó do painel de controle que antes estava ativo agora responderá com um código 303 que aponta para o novo nó ativo. Para evitar essa situação, você deve desabilitar o comportamento de redirecionamento nos nós de standby.

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

A API REST do Ceph Dashboard pode gravar solicitações PUT, POST e DELETE no registro de auditoria do Ceph. Por padrão, o registro está desabilitado, mas você pode habilitá-lo com o seguinte comando:

cephuser@adm > ceph dashboard set-audit-api-enabled true

Se habilitado, os seguintes parâmetros serão registrados por cada solicitação:

Veja a seguir um exemplo de entrada de registro:

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

Dica: Desabilitar o registro de payload de solicitação

Por padrão, o registro de payload de solicitação (a lista de argumentos e seus valores) está habilitado. Você pode desabilitá-lo da seguinte forma:

cephuser@adm > ceph dashboard set-audit-api-log-payload false

O Ceph Dashboard pode gerenciar exportações do NFS Ganesha que usam o CephFS ou o Gateway de Objetos como backstore. O painel de controle gerencia os arquivos de configuração do NFS Ganesha armazenados em objetos RADOS no cluster do CephFS. O NFS Ganesha deve armazenar parte da sua configuração no cluster do Ceph.

Execute o seguinte comando para configurar o local do objeto de configuração do NFS Ganesha:

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

Agora você pode gerenciar as exportações do NFS Ganesha usando o Ceph Dashboard.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

Os plug-ins do Ceph Dashboard estendem a funcionalidade do painel de controle. O plug-in de depuração permite a personalização do comportamento do painel de controle de acordo com o modo de depuração. Ele pode ser habilitado, desabilitado ou verificado com o seguinte comando:

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

Por padrão, esse modo está desabilitado. Essa é a configuração recomendada para implantações de produção. Se necessário, o modo de depuração pode ser habilitado sem necessidade de reinicialização.

Você pode detectar o estado imediato do cluster usando ceph status ou ceph -s:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

A saída apresenta as seguintes informações:

Dica: Como o Ceph calcula o uso de dados

O valor usado reflete o valor real do armazenamento bruto utilizado. O valor xxx GB/xxx GB indica o valor disponível (o menor número) da capacidade de armazenamento geral do cluster. O número estimado reflete o tamanho dos dados armazenados antes de serem replicados, clonados ou capturados como instantâneos. Portanto, a quantidade de dados realmente armazenados costuma exceder o valor estimado armazenado, pois o Ceph cria réplicas dos dados e também pode usar a capacidade de armazenamento para fazer clonagem e criar instantâneos.

Outros comandos que exibem informações de status imediatas são:

Para obter as informações atualizadas em tempo real, especifique qualquer um desses comandos (incluindo o ceph -s) como um argumento do comando watch:

root # watch -n 10 'ceph -s'

Pressione Ctrl–C quando estiver cansado de observar.

Após iniciar o cluster e antes de começar a leitura e/ou gravação de dados, verifique a saúde dele:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Dica

Se você especificou locais diferentes do padrão em sua configuração ou no chaveiro, deve especificar estes locais:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

O cluster do Ceph retorna um dos seguintes códigos de saúde:

Dica

Se você especificou locais diferentes do padrão em sua configuração ou no chaveiro, deve especificar estes locais:

root # ceph -c /path/to/conf -k /path/to/keyring health

Para verificar o uso e a distribuição dos dados de um cluster entre pools, use o comando ceph df. Para obter mais detalhes, use ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

A seção RAW STORAGE da saída apresenta uma visão geral da quantidade de armazenamento que seu cluster usa para os dados.

A seção POOLS da saída apresenta uma lista dos pools e o uso estimado de cada pool. A saída dessa seção não reflete réplicas, clones ou instantâneos. Por exemplo, se você armazenar um objeto com 1 MB de dados, o uso estimado será de 1 MB, mas o uso real poderá ser de 2 MB ou mais, dependendo do número de réplicas, clones e instantâneos.

Nota

Os números na seção POOLS são estimativas. Eles não incluem o número de réplicas, instantâneos ou clones. Como resultado, a soma dos valores USEDe %USED não incluirá os valores RAW USED e %RAW USED na seção RAW STORAGE da saída.

Você pode verificar os OSDs para garantir que estejam ativos e em execução:

cephuser@adm > ceph osd stat

ou

cephuser@adm > ceph osd dump

Você também pode ver os OSDs de acordo com a posição deles no mapa CRUSH.

O ceph osd tree imprimirá uma árvore CRUSH com um host, os OSDs, se eles estão ativos e o peso:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

O Ceph impede você de gravar em um OSD cheio para evitar a perda de dados. Em um cluster operacional, você deve receber um aviso quando o cluster está próximo cota máxima. O padrão do valor mon osd full ratio é de 0,95, ou 95% da capacidade antes de impedir que os clientes gravem dados. O padrão do valor mon osd nearfull ratio é de 0,85, ou 85% da capacidade, quando ele gera um aviso de saúde.

O ceph health relata os nós OSD cheios:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

ou

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

A melhor maneira de resolver um cluster cheio é adicionar novos hosts/discos OSD, o que permite ao cluster redistribuir os dados para o armazenamento recém-disponibilizado.

Dica: Evitando OSDs cheios

Depois que um OSD fica cheio (usa 100% do espaço em disco), ele costuma falhar rapidamente sem aviso. Veja a seguir algumas dicas para se lembrar na hora de administrar nós OSD.

• O espaço em disco de cada OSD (normalmente montado em /var/lib/ceph/osd/osd-{1,2..}) precisa ser colocado em um disco ou partição subjacente dedicado.

• Verifique os arquivos de configuração do Ceph e certifique-se de que o Ceph não armazene o arquivo de registro em discos/partições dedicados para uso por OSDs.

• Confirme se nenhum outro processo faz gravações nos discos/partições dedicados para uso por OSDs.

Após iniciar o cluster e antes da primeira leitura e/ou gravação de dados, verifique o status do quorum dos Ceph Monitors. Quando o cluster já estiver processando solicitações, verifique o status dos Ceph Monitors periodicamente para garantir que estejam em execução.

Para exibir o mapa do monitor, execute o seguinte:

cephuser@adm > ceph mon stat

ou

cephuser@adm > ceph mon dump

Para verificar o status do quorum para o cluster do monitor, execute o seguinte:

cephuser@adm > ceph quorum_status

O Ceph retornará o status do quorum. Por exemplo, um cluster do Ceph com três monitores pode retornar o seguinte:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

Os grupos de posicionamento mapeiam objetos para OSDs. Ao monitorar seus grupos de posicionamento, você deseja que eles estejam ativos e limpos. Para ver uma discussão detalhada, consulte a Seção 12.9, “Monitorando OSDs e grupos de posicionamento”.

Quando um cluster de armazenamento do Ceph está próximo da sua capacidade máxima, o Ceph impede você de gravar ou ler os Ceph OSDs como medida de segurança para evitar perda de dados. Portanto, permitir que um cluster de produção se aproxime da sua cota máxima não é uma boa prática, porque coloca em risco a alta disponibilidade. A cota máxima padrão está definida como 0,95, que significa 95% da capacidade. Essa é uma configuração muito agressiva para um cluster de teste com um número pequeno de OSDs.

Dica: Aumentar a Capacidade de Armazenamento

Ao monitorar o cluster, fique atento aos avisos relacionados à cota nearfull. Eles indicam que a falha de alguns OSDs pode resultar em interrupção temporária de serviço. Considere adicionar mais OSDs para aumentar a capacidade de armazenamento.

Um cenário comum para clusters de teste envolve um administrador do sistema que remove um Ceph OSD do cluster de armazenamento do Ceph para observar a redistribuição do cluster. Em seguida, ele remove outro Ceph OSD, e assim por diante, até o cluster atingir a cota máxima e ser bloqueado. Recomendamos um pouco de planejamento de capacidade, mesmo com um cluster de teste. O planejamento permite estimar a quantidade de capacidade sobressalente que você precisará para manter a alta disponibilidade. O ideal é planejar uma série de falhas de Ceph OSDs em que o cluster possa se recuperar ao estado ativo + limpo sem substituir os Ceph OSDs imediatamente. Você pode executar um cluster no estado ativo + degradado, mas isso não é ideal em condições normais de operação.

O diagrama a seguir retrata um cluster de armazenamento do Ceph simples contendo 33 nós do Ceph com um Ceph OSD por host, cada um deles lendo e gravando em uma unidade de 3 TB. Esse cluster de exemplo tem uma capacidade máxima real de 99 TB. A opção mon osd full ratio está definida como 0,95. Se o cluster atingir 5 TB da capacidade restante, ele não permitirá que os clientes leiam e gravem dados. Portanto, a capacidade operacional do cluster de armazenamento é de 95 TB, não de 99 TB.

Figura 12.1: Cluster do Ceph #

 

Nesse tipo de cluster, é normal haver falha de um ou dois OSDs. Um cenário menos frequente, mas considerável, envolve uma falha no roteador do rack ou no fornecimento de energia, o que desligaria vários OSDs ao mesmo tempo (por exemplo, OSDs 7-12). Nesse cenário, você ainda deve recorrer a um cluster capaz de se manter operante e atingir o estado ativo + limpo, mesmo que isso signifique adicionar alguns hosts com outros OSDs a curto prazo. Se o uso da capacidade for muito alto, talvez você não perca os dados. Porém, você ainda poderá colocar em risco a disponibilidade dos dados ao resolver uma interrupção em um domínio de falha, se o uso da capacidade do cluster exceder a cota máxima. Por esse motivo, recomendamos pelo menos algum planejamento de capacidade estimada.

Identifique dois números para o cluster:

Se você dividir a capacidade total pelo número de OSDs do cluster, encontrará a capacidade média de um OSD no cluster. Considere multiplicar esse número pela quantidade de OSDs que podem falhar simultaneamente durante as operações normais (um número relativamente pequeno). Por fim, multiplique a capacidade do cluster pela cota máxima para chegar a uma capacidade operacional máxima. Em seguida, subtraia o número da quantidade de dados dos OSDs que podem falhar para chegar a uma cota máxima razoável. Repita o processo anterior com um número maior de falhas de OSD (um rack de OSDs) para chegar a um número razoável para uma cota quase máxima.

As seguintes configurações aplicam-se apenas à criação de cluster e são armazenadas no mapa OSD:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Dica

Essas configurações aplicam-se apenas durante a criação do cluster. Depois disso, elas precisarão ser mudadas no Mapa OSD usando os comandos ceph osd set-nearfull-ratio e ceph osd set-full-ratio.

Dica: Verificar o peso do OSD

Se alguns OSDs estiverem quase cheios, mas outros tiverem bastante capacidade, talvez você tenha problemas com o peso do CRUSH para os OSDs quase cheios.

As altas disponibilidade e confiabilidade exigem uma abordagem tolerante a falhas para gerenciar problemas de hardware e software. O Ceph não tem um ponto único de falha e pode processar solicitações de dados no modo "degradado". O posicionamento de dados do Ceph introduz uma camada de indireção para garantir que os dados não sejam diretamente vinculados a determinados endereços de OSD. Isso significa que o monitoramento de falhas no sistema requer encontrar o grupo de posicionamento e os OSDs subjacentes na raiz do problema.

Dica: Acesso em caso de falha

Uma falha em uma parte do cluster pode impedir você de acessar um determinado objeto. Isso não significa que você não pode acessar outros objetos. Em caso de falha, siga as etapas para monitorar os OSDs e grupos de posicionamento. Em seguida, comece a solução de problemas.

Em geral, o Ceph tem a funcionalidade de conserto automático. No entanto, quando os problemas persistem, o monitoramento de OSDs e grupos de posicionamento ajuda você a identificá-los.

12.9.1 Monitorando OSDs #

 

O status de um OSD é no cluster (“in”) ou fora do cluster (“out”). Ao mesmo tempo, ele é em execução (“up”) ou inativo e não operante (“down”). Se um OSD é “up”, ele pode estar no cluster (você pode ler e gravar dados) ou fora do cluster. Se ele estava no cluster e foi recentemente removido do cluster, o Ceph migra os grupos de posicionamento para outros OSDs. Se um OSD estiver fora do cluster, o CRUSH não atribuirá grupos de posicionamento a ele. Se um OSD é “down”, ele também deve ser “out”.

Nota: Estado não saudável

Se um OSD é “down” e “in”, há um problema, e o estado do cluster não é saudável.

Se você executar um comando, como ceph health, ceph -s ou ceph -w, poderá perceber que o cluster nem sempre retorna HEALTH OK. Em relação aos OSDs, você deve esperar que o cluster não retorne HEALTH OK nas seguintes circunstâncias:

• Você ainda não iniciou o cluster (ele não responderá).

• Você iniciou ou reiniciou o cluster e ele ainda não está pronto, porque os grupos de posicionamento estão sendo criados e os OSDs estão no processo de emparelhamento.

• Você adicionou ou removeu um OSD.

• Você modificou o mapa do cluster.

Um aspecto importante do monitoramento de OSDs é garantir que, quando o cluster estiver em execução, todos os OSDs no cluster também estejam funcionando. Para ver se todos os OSDs estão funcionando, execute:

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

O resultado deve indicar o número total de OSDs (x), quantos estão “up” (y), quantos estão “in” (z) e a época do mapa (eNNNN). Se o número de OSDs que estão “in” no cluster for maior do que o número de OSDs que estão “up”, execute o seguinte comando para identificar os daemons ceph-osd que não estão funcionando:

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Por exemplo, se um OSD com ID 1 estiver desativado, inicie-o:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Consulte o Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running” para ver os problemas associados aos OSDs que estão parados ou que não serão reiniciados.

12.9.2 Atribuindo conjuntos de grupos de posicionamento #

 

Quando o CRUSH atribui grupos de posicionamento a OSDs, ele analisa o número de réplicas para o pool e atribui o grupo de posicionamento aos OSDs de modo que cada réplica do grupo de posicionamento seja atribuída a um OSD diferente. Por exemplo, se o pool exigir três réplicas de um grupo de posicionamento, o CRUSH poderá atribuí-las a osd.1, osd.2 e osd.3, respectivamente. Na verdade, o CRUSH busca um posicionamento pseudo-aleatório que considera os domínios de falha definidos no seu Mapa CRUSH. Sendo assim, você raramente verá grupos de posicionamento atribuídos aos OSDs vizinhos mais próximos em um cluster de grande porte. Nossa referência é ao conjunto de OSDs que deve incluir as réplicas de um determinado grupo de posicionamento como o conjunto de atuação. Em alguns casos, um OSD no conjunto de atuação está inativo ou, de alguma outra forma, não pode processar as solicitações para objetos no grupo de posicionamento. Nesses tipos de situação, um dos seguintes cenários pode ocorrer:

• Você adicionou ou removeu um OSD. Em seguida, o CRUSH reatribuiu o grupo de posicionamento a outros OSDs e, portanto, mudou a composição do conjunto de atuação, provocando a migração dos dados com um processo de “provisionamento”.

• Um OSD estava “down”, foi reiniciado e agora está se recuperando.

• Um OSD no conjunto de atuação está “down” ou não pode processar as solicitações, e outro OSD assumiu temporariamente as tarefas dele.

  O Ceph processa uma solicitação de cliente usando o conjunto ativo, que é o conjunto de OSDs que processará de fato as solicitações. Na maioria dos casos, o conjunto ativo e o conjunto de atuação são praticamente idênticos. Quando não são, isso pode indicar que o Ceph está migrando dados, que um OSD está se recuperando ou que há um problema. Por exemplo, o Ceph costuma retornar o estado HEALTH WARN com a mensagem “stuck stale” em cenários assim.

Para recuperar uma lista de grupos de posicionamento, execute:

cephuser@adm > ceph pg dump

Para ver quais OSDs estão no conjunto de atuação ou no conjunto ativo para um determinado grupo de posicionamento, execute:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

O resultado deve indicar a época do osdmap (eNNN), o número do grupo de posicionamento (PG_NUM), os OSDs no conjunto ativo (“up”) e os OSDs no conjunto de atuação (“acting”):

Dica: Indicador de problema no cluster

Se o conjunto ativo e o conjunto de atuação não forem os mesmos, isso pode ser um indicador de que o cluster está realizando a própria redistribuição ou de um possível problema com o cluster.

12.9.3 Emparelhamento #

 

Antes que você possa gravar dados em um grupo de posicionamento, ele deve estar no estado ativo e, de preferência, limpo. Para o Ceph determinar o estado atual de um grupo de posicionamento, o OSD principal do grupo de posicionamento (o primeiro OSD no conjunto de atuação), é emparelhado com os OSDs secundários e terciários para estabelecer um acordo em relação ao estado atual do grupo de posicionamento (considerando um pool com três réplicas do PG).

Figura 12.2: Esquema de emparelhamento #

 

12.9.4 Monitorando estados de grupos de posicionamento #

 

Se você executar um comando, como ceph health, ceph -s ou ceph -w, poderá perceber que o cluster nem sempre retorna a mensagem HEALTH OK. Após verificar se os OSDs estão em execução, verifique também os estados do grupo de posicionamento.

É esperado que o cluster não retorne HEALTH OK em várias circunstâncias relacionadas ao emparelhamento de grupos de posicionamento:

• Você criou um pool, e os grupos de posicionamento ainda não foram emparelhados.

• Os grupos de posicionamento estão se recuperando.

• Você adicionou ou removeu um OSD do cluster.

• Você modificou seu Mapa CRUSH, e seus grupos de posicionamento estão sendo migrados.

• Há dados inconsistentes em diferentes réplicas de um grupo de posicionamento.

• O Ceph está depurando as réplicas de um grupo de posicionamento.

• O Ceph não tem capacidade de armazenamento suficiente para concluir as operações de provisionamento.

Se uma das circunstâncias mencionadas acima fizer com que o Ceph retorne HEALTH WARN, não se preocupe. Em muitos casos, o cluster se recuperará por conta própria. Em alguns casos, pode ser necessário tomar medidas. Um aspecto importante do monitoramento dos grupos de posicionamento é garantir que, quando o cluster estiver em funcionamento, todos os grupos de posicionamento estejam "ativos" e, de preferência, no "estado limpo". Para ver o status de todos os grupos de posicionamento, execute:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

O resultado deve indicar o número total de grupos de posicionamento (x), quantos grupos de posicionamento estão em determinado estado, como “ativo+limpo” (y) e a quantidade de dados armazenados (z).

Além dos estados do grupo de posicionamento, o Ceph também retornará a quantidade de capacidade de armazenamento utilizada (aa), a quantidade de capacidade de armazenamento restante (bb) e a capacidade total de armazenamento do grupo de posicionamento. Esses números podem ser importantes em alguns casos:

• Você está atingindo a cota quase máxima ou cota máxima.

• Seus dados não estão sendo distribuídos por todo o cluster por causa de um erro na configuração do CRUSH.

Dica: IDs dos grupos de posicionamento

Os IDs dos grupos de posicionamento consistem no número do pool (não no nome do pool) seguido de um ponto (.) e no ID do grupo de posicionamento: um número hexadecimal. Você pode ver os números de pool e os respectivos nomes na saída do comando ceph osd lspools. Por exemplo, o pool padrão rbd corresponde ao número do pool 0. Um ID de grupo de posicionamento totalmente qualificado tem o seguinte formato:

POOL_NUM.PG_ID

Normalmente, ele tem a seguinte aparência:

0.1f

Para recuperar uma lista de grupos de posicionamento, execute o seguinte:

cephuser@adm > ceph pg dump

Você também pode formatar a saída em JSON e gravá-la em um arquivo:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Para consultar um determinado grupo de posicionamento, execute o seguinte:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

A lista a seguir descreve os estados comuns do grupo de posicionamento em detalhes.

CREATING

Quando você cria um pool, ele cria o número de grupos de posicionamento que você especificou. O Ceph retornará “creating” (criando) durante a criação de um ou mais grupos de posicionamento. Quando são criados, os OSDs que fazem parte do conjunto de atuação do grupo de posicionamento são emparelhados. Quando o emparelhamento é concluído, o status do grupo de posicionamento deve ser “ativo+limpo”, o que significa que um cliente Ceph pode começar a gravar no grupo de posicionamento.

Figura 12.3: Status dos grupos de posicionamento #

 

PEERING

Quando o Ceph está emparelhando um grupo de posicionamento, ele leva os OSDs que armazenam as réplicas do grupo de posicionamento a um acordo em relação ao estado dos objetos e metadados nesse grupo. Quando o Ceph conclui o emparelhamento, isso significa que os OSDs que armazenam o grupo de posicionamento concordam sobre o estado atual desse grupo. No entanto, a conclusão do processo de emparelhamento não significa que cada réplica tem o conteúdo mais recente.

Nota: Histórico de autorização

O Ceph não confirmará uma operação de gravação em um cliente até que todos os OSDs do conjunto de atuação continuem a operação de gravação. Esta prática garante que pelo menos um membro do conjunto de atuação tenha um registro de cada operação de gravação confirmada desde a última operação de emparelhamento bem-sucedida.

Com um registro preciso de cada operação de gravação confirmada, o Ceph pode construir e ampliar um novo histórico de autorização do grupo de posicionamento: um conjunto completo e totalmente organizado de operações que, se executadas, mantêm uma cópia do OSD de um grupo de posicionamento atualizada.

ACTIVE

Quando o Ceph conclui o processo de emparelhamento, um grupo de posicionamento pode se tornar ativo. O estado ativo significa que os dados no grupo de posicionamento geralmente estão disponíveis no grupo de posicionamento principal e nas réplicas para as operações de leitura e gravação.

CLEAN

Quando um grupo de posicionamento está no estado limpo, o OSD principal e os OSDs de réplica foram emparelhados com êxito e não há réplicas perdidas para o grupo de posicionamento. O Ceph replicou o número correto de vezes todos os objetos no grupo de posicionamento.

DEGRADED

Quando um cliente grava um objeto no OSD principal, esse OSD é responsável por gravar as réplicas nos OSDs de réplica. Depois que o OSD principal gravar o objeto no armazenamento, o grupo de posicionamento permanecerá no estado "degradado" até que o OSD principal receba uma confirmação dos OSDs de réplica de que que Ceph criou os objetos de réplica com êxito.

O motivo pelo qual um grupo de posicionamento pode ser “ativo+degradado” é que um OSD pode ser “ativo” mesmo que ainda não armazene todos os objetos. Se um OSD ficar inativo, o Ceph marcará cada grupo de posicionamento atribuído ao OSD como “degradado”. Os OSDs deverão ser emparelhados novamente quando o OSD voltar a ficar ativo. No entanto, um cliente ainda poderá gravar um novo objeto em um grupo de posicionamento degradado se ele for “ativo”.

Se um OSD for “inativo” e a condição “degradado” permanecer, o Ceph poderá marcar o OSD inativo como “fora” do cluster e remapear os dados do OSD “inativo” para outro OSD. O tempo entre ser marcado como “inativo” e como “fora” é controlado pela opção mon osd down out interval, que por padrão está definida como 600 segundos.

Um grupo de posicionamento também pode ser "degradado" porque o Ceph não encontra um ou mais objetos que deveriam estar no grupo de posicionamento. Embora você não possa ler ou gravar em objetos não encontrados, ainda pode acessar todos os outros objetos no grupo de posicionamento “degradado”.

RECOVERING

O Ceph foi projetado para tolerância a falhas em escala, quando os problemas de hardware e software são constantes. Quando um OSD fica “inativo”, o conteúdo dele pode não acompanhar o estado atual das outras réplicas nos grupos de posicionamento. Quando o OSD volta a ficar “ativo”, o conteúdo dos grupos de posicionamento deve ser atualizado para refletir o estado atual. Durante esse período, o OSD pode refletir um estado de "recuperação".

A recuperação nem sempre é comum, porque uma falha de hardware pode causar uma falha em cascata de vários OSDs. Por exemplo, em uma possível falha do switch de rede para um rack ou gabinete, os OSDs de várias máquinas host podem não acompanhar o estado atual do cluster. Cada um dos OSDs deverá se recuperar quando a falha for resolvida.

O Ceph oferece uma série de configurações para equilibrar a contenção de recursos entre as novas solicitações de serviço e a necessidade de recuperar os objetos de dados e restaurar os grupos de posicionamento ao estado atual. A configuração osd recovery delay start permite que um OSD reinicie, emparelhe novamente e até processe algumas solicitações de reprodução antes do início do processo de recuperação. A osd recovery thread timeout define um tempo de espera do thread porque vários OSDs podem falhar, ser reiniciados e novamente emparelhados em fases. A configuração osd recovery max active limita o número de solicitações de recuperação que um OSD processará simultaneamente para impedir falha no processamento do OSD. A configuração osd recovery max chunk limita o tamanho dos blocos de dados recuperados para evitar congestionamento de rede.

BACK FILLING

Quando um novo OSD ingressa no cluster, o CRUSH reatribui os grupos de posicionamento dos OSDs no cluster para o OSD recém-adicionado. Forçar o novo OSD a aceitar os grupos de posicionamento reatribuídos imediatamente pode sobrecarregar o novo OSD. O provisionamento do OSD com os grupos de posicionamento permite que este processo seja iniciado em segundo plano. Quando o provisionamento for concluído, o novo OSD começará a processar solicitações quando estiver pronto.

Durante as operações de provisionamento, você pode ver um dos vários estados: “backfill_wait” indica que uma operação de provisionamento está pendente, mas ainda não está em andamento; “backfill” indica que uma operação de provisionamento está em andamento; “backfill_too_full” indica que uma operação de provisionamento foi solicitada, mas não pôde ser concluída devido à capacidade de armazenamento insuficiente. Quando não é possível provisionar um grupo de posicionamento, ele pode ser considerado “incompleto”.

O Ceph dispõe de várias configurações para gerenciar a carga associada à reatribuição de grupos de posicionamento para um OSD (especialmente um novo OSD). Por padrão, osd max backfills define o número máximo de provisionamentos simultâneos de/para um OSD como 10. A cota máxima de provisionamento permite que um OSD recuse uma solicitação de provisionamento se ele estiver próximo da sua cota máxima (90%, por padrão) e faça a modificação com o comando ceph osd set-backfillfull-ratio. Se um OSD recusar uma solicitação de provisionamento, o osd backfill retry interval permitirá que um OSD repita a solicitação (após 10 segundos, por padrão). O OSDs também podem definir osd backfill scan min e osd backfill scan max para gerenciar intervalos de exploração (64 e 512, por padrão).

REMAPPED

Quando o conjunto de atuação que processa um grupo de posicionamento é modificado, os dados são migrados do conjunto de atuação antigo para o conjunto de atuação novo. Pode levar algum tempo para um novo OSD principal processar as solicitações. Por isso, talvez seja solicitado para o conjunto principal antigo continuar processando as solicitações até que a migração do grupo de posicionamento seja concluída. Quando a migração dos dados for concluída, o mapeamento usará o OSD principal do novo conjunto de atuação.

STALE

Enquanto o Ceph usa os heartbeats para garantir que os hosts e daemons estejam em execução, os daemons ceph-osd também podem entrar em um estado “travado” quando não estiverem relatando estatísticas em tempo hábil (por exemplo, uma falha temporária na rede). Por padrão, os daemons OSD relatam suas estatísticas de grupo de posicionamento, inicialização e falha a cada meio segundo (0,5), que é mais frequente do que os limites de heartbeat. Se o OSD principal do conjunto de atuação de um grupo de posicionamento não puder relatar para o monitor ou se outros OSDs relataram o OSD principal como “inativo”, os monitores marcarão o grupo de posicionamento como “obsoleto”.

Quando você inicia o cluster, é comum ver o estado "obsoleto" até o processo de emparelhamento ser concluído. Depois que o cluster estiver funcionando por um tempo, ver grupos de posicionamento no estado "obsoleto" indicará que o OSD principal para esses grupos está inativo ou não está relatando as estatísticas de grupo de posicionamento para o monitor.

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

Para modificar a configuração de um cluster do Ceph existente, siga estas etapas:

Para adicionar um novo nó a um cluster do Ceph, siga estas etapas:

Dica: Remover OSDs

Se o nó que você vai remover executa OSDs, remova-os primeiro e verifique se nenhum OSD está sendo executado nesse nó. Consulte Seção 13.4.4, “Removendo OSDs” para obter mais detalhes sobre como remover OSDs.

Para remover um nó de um cluster, faça o seguinte:

Importante

Em caso de falha e se o minion que você está tentando remover estiver em um estado permanentemente desligado, você precisará remover o nó do Master Salt:

root@master # salt-key -d minion_id

Em seguida, remova o nó de pillar_root/ceph-salt.sls. Normalmente, ele está localizado em /srv/pillar/ceph-salt.sls.

Esta seção descreve como adicionar, apagar ou remover OSDs de um cluster do Ceph.

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 Apagando dispositivos de disco #

 

Para reutilizar um dispositivo de disco, você precisa apagá-lo (ou zap) primeiro:

ceph orch device zap HOST_NAME DISK_DEVICE

Por exemplo:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Nota

Se você já implantou os OSDs por meio de DriveGroups ou da opção --all-available-devices sem o flag unmanaged definido, o cephadm implantará esses OSDs automaticamente depois que você os apagar.

13.4.3 Adicionando OSDs por meio da especificação DriveGroups #

 

Os DriveGroups especificam os layouts dos OSDs no cluster do Ceph. Eles são definidos em um único arquivo YAML. Nesta seção, usaremos drive_groups.yml como exemplo.

Um administrador deve especificar manualmente um grupo de OSDs que estão interligados (OSDs híbridos implantados em uma combinação de HDDs e SDDs) ou compartilhar opções idênticas de implantação (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. O cephadm fornecerá o código que converte esses DriveGroups em listas reais de dispositivos para inspeção pelo usuário.

O comando para aplicar a especificação de OSD ao cluster é:

cephuser@adm > ceph orch apply osd -i drive_groups.yml

Para obter uma visualização das ações e testar seu aplicativo, você pode usar a opção --dry-run junto com o comando ceph orch apply osd. Por exemplo:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Se a saída --dry-run atender às suas expectativas, basta executar novamente o comando sem a opção --dry-run.

13.4.3.1 OSDs não gerenciados #

 

Todos os dispositivos de disco limpos disponíveis que correspondem à especificação DriveGroups serão usados como OSDs automaticamente depois que você os adicionar ao cluster. Esse comportamento é chamado de modo gerenciado.

Para desabilitar o modo gerenciado, adicione a linha unmanaged: true às especificações relevantes, por exemplo:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Dica

Para mudar os OSDs já implantados do modo gerenciado para não gerenciado, adicione as linhas unmanaged: true aos locais aplicáveis durante o procedimento descrito na Seção 13.1, “Modificando a configuração do cluster”.

13.4.3.2 Especificação DriveGroups #

 

Veja a seguir um exemplo do arquivo de especificação DriveGroups:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
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)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Nota

A opção antes chamada de "criptografia" no DeepSea foi renomeada para "criptografada". Ao usar o DriveGroups no SUSE Enterprise Storage 7, adote essa nova terminologia na especificação do serviço; do contrário, haverá falha na operação ceph orch apply.

13.4.3.3 Correspondendo dispositivos de disco #

 

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

  

  Dica

  Insira DISK_VENDOR_STRING sempre em letras minúsculas.

  Para obter detalhes sobre o modelo e o fornecedor do disco, observe a saída do seguinte comando:

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• Se um disco é ou não rotacional. Os SSDs e as 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

13.4.3.4 Filtrando dispositivos por tamanho #

 

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.

Exemplo 13.1: Correspondendo por tamanho do disco #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

Nota: Aspas obrigatórias

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.

Dica: Atalhos de unidade

Em vez de Gigabytes (G), você pode especificar os tamanhos em Megabytes (M) ou Terabytes (T).

13.4.3.5 Exemplos de DriveGroups #

 

Esta seção inclui exemplos de configurações de OSD diferentes.

Exemplo 13.2: Configuração simples #

 

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:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
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:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
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:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

Exemplo 13.3: Configuração avançada #

 

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:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

Exemplo 13.4: Configuração avançada com nós não uniformes #

 

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:

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

seguido de

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

Exemplo 13.5: Configuração técnica #

 

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

Exemplo 13.6: Configuração complexa (e improvável) #

 

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:

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Um HDD permanecerá enquanto o arquivo está sendo analisado de cima para baixo.