0 Prefácio
Recentemente, finalmente tenho tempo para analisar o código Ceph. Em seguida, farei uma análise aprofundada do componente mais importante do cluster Ceph, o monitor Ceph.
1 A função do
Monitor O monitor desempenha a função de gerente no cluster Ceph, mantendo o estado de todo o cluster (abstraído em vários mapas, incluindo osdmap, monmap, mdsmap, auth, log etc.), para garantir que os componentes relevantes do cluster estejam ao mesmo tempo Ser capaz de chegar a um acordo é equivalente à liderança em um cluster. A razão pela qual ela está relacionada, e não tudo, é porque a atualização do mapa OSD adota um mecanismo semelhante à versão em escala de cinza, que fará com que a versão do OSDmap mantida por todos os OSDs ou clientes no cluster de cada vez seja inconsistente. Em resumo, o monitor é responsável por coletar informações de cluster, atualizar informações de cluster e publicar informações de cluster. Se houver apenas um monitor, esse problema será muito mais fácil.A adição, exclusão, modificação e verificação das informações do cluster são concluídas por este monitor. No entanto, como uma solução de armazenamento distribuído, evitar qualquer ponto único de falha é uma condição necessária; portanto, vários monitores também serão implantados no ambiente de produção usando o Ceph. O problema de ponto único é resolvido, mas, após mais monitores, o gerenciamento de dados do cluster correspondente se torna complicado e muitos problemas novos são introduzidos, como: Onde os dados do cluster existem? Quem está atualizando os dados? Onde outros componentes leem informações? Como sincronizar dados entre vários monitores? Portanto, em um ambiente Ceph padrão, o que o Monitor faz pode ser resumido nos dois pontos a seguir:
Cuide-se, de fato, para resolver como trabalhar em conjunto entre vários monitores, como quem é responsável pela atualização dos dados, como atualizar? Como sincronizar dados entre monitores? Quem é responsável pela publicação dos dados? Como garantir a saúde do monitor?
Gerenciar as informações do cluster, de fato, que tipo de dados são armazenados? Como os dados são armazenados? Onde é armazenado? Como garantir a precisão dos dados armazenados?
Como abstrair nos dois pontos acima? Tem que começar com o código, dê uma olhada na estrutura de diretório de código do monitor:
Obviamente, a divisão dos arquivos de origem acima não é completamente separada e ainda há algumas associações entre eles.Por exemplo, o processo de eleição realmente envolverá sincronização de dados entre monitores, ou seja, atualizações no gerenciamento de dados. A atualização de dados precisa ser persistida através do módulo de armazenamento de dados. Nos dados gerenciados pelo Monitor, as duas partes OSDMap e MDSMap não são colocadas no diretório monitor, mas nos diretórios osd e mds respectivamente, portanto, são marcadas com fontes vermelhas.
Os artigos a seguir se concentram principalmente nas tecnologias relacionadas envolvidas no monitor em detalhes nos dois aspectos acima.
2 Inicialização do
Monitor O processo de inicialização do Monitor é relativamente simples.Para o processo específico, consulte o arquivo de código-fonte ceph_mon.cc. Pode ser dividido aproximadamente nas seguintes partes:
Introduza os parâmetros que podem ser manipulados pelo comando ceph_mon e como usá-lo:
Crie uma instância MonitorDBStore denominada store com base no diretório mon_data especificado no arquivo de configuração e abra o diretório de dados. Determine se o uso atual do diretório de dados excede o limite de alarme. E leia o número mágico da loja para garantir que ela seja normal.
Quando mon é iniciado pela primeira vez, ele executa a operação mkfs para criar o monmap e, em seguida, começa a ler o monmap da loja, além de obter o endereço IP do Messengerbind e o valor de classificação do mon. Portanto, se a primeira configuração do mon estiver incorreta, a modificação subsequente do arquivo de configuração do mon e a reinicialização do mon não terão efeito.
Crie um Messenger de comunicação de dados do Monitor e defina a política e o acelerador do messager.
Crie e inicialize a instância do monitor mon. A inicialização é dividida em dois estágios preinit () e init (). No estágio preinit (), os paxos e cada paxosservice e health_monitor são inicializados. No estágio init (), o timer é inicializado e o monitor é adicionado à lista de expedidores. bootstrap (). A partir do bootstrap () também entrou no processo de eleição do Monitor, isso será apresentado em detalhes na próxima seção.
O processo do Monitor cria apenas um Messenger, o que significa que ele possui apenas um thread de dispatch_queue e um dispatcher, e todas as solicitações serão enfileiradas. Além disso, o Monitor também inicializará um cronômetro, que criará um encadeamento para lidar com todos os eventos de tempo limite da mensagem, incluindo análise, proposta, concessão e outras mensagens, para que essas mensagens também sejam processadas serialmente. Existem dois threads reais no Monitor. Portanto, quando você executa o comando no cluster por um longo período de tempo e não retorna, 80% ocorre porque a fila de despacho do Monitor é bloqueada por mensagens e a causa principal pode ser causada pela lenta atualização dos dados do armazenamento do Monitor. Isso pode ser um problema de disco ou pode ser O LevelDB / RocksDB possui uma grande quantidade de dados redundantes, o que causa uma leitura lenta.
3 Mecanismo de eleição do Monitor O que o
Monitor deve fazer é muito claro, ou seja, gerenciar, manter e publicar as informações de status do cluster, mas, para evitar pontos únicos de falha ou pontos de desempenho, geralmente são usados vários Monitores para fazer isso. A gerência possui vários membros. O funcionamento normal do cluster exige que a gerência chegue a um acordo.É necessário um consenso (líder) .Todos podem ouvi-lo. Portanto, a questão central para chegar a um acordo é escolher o monitor que pode tomar uma decisão entre muitos monitores. A solução da Ceph para esse problema é muito simples, um pouco semelhante à eleição de líderes, ou seja, monitores qualificados primeiro formam um quorum (comitê) e, em seguida, os membros do comitê selecionam um líder dentro do intervalo de quorum, atualizam as informações de status do cluster e Esse líder é responsável pela manutenção dos membros do quórum. As regras de seleção de líderes também são relativamente simples: cada monitor recebe um valor de classificação com base em seu endereço IP durante a inicialização.Quando um líder é eleito, o monitor com o menor valor de classificação ganha o líder eleito. Quando o membro do quorum muda (aumenta ou diminui), ele inicia o processo de reeleição e seleciona um líder.
Todo o processo de eleição do Monitor também é o processo de alteração de estado do Monitor de acordo com a seguinte máquina de estado:
Ou seja, depois que o Monitor é iniciado, ele encontra outros monitores de acordo com o monmap e obtém o monmap de outros monitores, a versão paxos e outras informações e, em seguida, sincroniza os dados conforme apropriado e aciona eleições dentro do intervalo de quorum. Após a eleição, o monitor se tornará o Líder ou Peon até que o serviço seja interrompido. Desligado.
Isso ainda é um pouco geral, vamos falar sobre o código, é claro, você precisa aprender a ler o código. A função de entrada da eleição é Monitor :: start_election (). Verifique o código que chama essa função. Não é difícil ver que ela será chamada quando ocorrerem as três situações a seguir:
Monitor :: handle_probe_reply (), quando o monitor executa a inicialização, ele primeiro envia uma mensagem MMonProbe para todos os membros no monmap e, em seguida, quando recebe a probabilidade provavelmente retornada pelo par, determina se uma eleição precisa ser iniciada com base nas informações de quorum retornadas e na versão do paxos.
Elector :: handle_propose (), é quando você recebe uma mensagem de solicitação de eleição de outro monitor; ela acionará uma reeleição de acordo com a situação.
Monitor :: do_admin_command () e Monitor :: handle_command (), esses dois pertencem à operação de eleição acionada pelo quorumentador e pela saída do quorum através do comando ceph ou do soquete de administração mon.
Aqui está uma introdução detalhada à eleição desencadeada no primeiro caso e para resolver todo o processo eleitoral.
Monitor :: bootstrap (), a lógica de inicialização do processo do monitor, fazendo especificamente o seguinte:
No início, defina o status do monitor como STATA_PROBING
e, em seguida, determine se o parâmetro mon_compact_on_bootstrap está definido. Se estiver definido, a operação compacta será executada para compactar o armazenamento do monitor.
Se houver apenas um monitor no cluster, o monitor vence diretamente. O
evento probe_timeout é redefinido de acordo com mon_probe_timeout
Se o monitor estiver no monmap, ele será incluído no conjunto outside_quorum.
De acordo com o monmap, envie mensagens MMonProbe para outros pares, um por um.
Após receber a mensagem, o Monitor entra em Monitor :: dispatch_op () após despachar a lógica e analisa a mensagem do tipo MSG_MON_PROBE, entra em Monitor :: handle_probe () e entra em Monitor :: handle_probe_reply para processamento.
Monitor :: handle_probe_reply (), faça aqui principalmente o seguinte.
Primeiro, determine se o status atual do monitor é Probing ou Electing e saia diretamente.
Compare a versão da época do monmap da outra parte e do seu próprio monmap.Se a sua própria versão do monmap for menor, atualize seu próprio mapa e, em seguida, volte a entrar no estágio bootstrap ().
Se o monitor atual estiver no estágio de sincronização, ele retornará diretamente
a versão do paxos comparada entre si.Se a versão do paxos da outra parte for menor, caso contrário, será julgado se a sincronização de dados é necessária. Existem dois casos aqui: se a sua versão do paxos for inferior à versão registrada pelo paxos_first_version da outra parte, será executada uma operação de sincronização. Se a versão do seu paxos e a versão da outra parte estiverem muito além do valor do parâmetro definido paxos_max_join_drift, os dados serão sincronizados primeiro sem disparar uma operação de reeleição.
Se for julgado pela mensagem retornada que já existe um quorum, e ele também descarta seu endereço IP no monmap não está vazio, inicie diretamente uma eleição. Caso contrário, você será solicitado a ingressar neste quorum.
Se não houver quorum pronto e você estiver no monmap, adicione o par ao conjunto outside_quorum. Se os membros no outside_quorum forem maiores ou iguais a monmap-> size () / 2 + 1, a eleição será iniciada; caso contrário, ela retornará e esperará que as condições sejam atendidas.
Monitor :: start_election (), faça aqui principalmente o seguinte.
Se o Paxos estiver no estado STATE_WRITING ou STATE_WRITING_PREVIOUS, aguarde a conclusão da atualização do paxos.
Redefina os serviços no monitor, incluindo evento de tempo limite do probe, verificação de tempo de parada (verificação de desvio de horário de segunda-feira), evento de integridade, evento de limpeza etc., e reinicie o paxos e todos os serviços de serviço do paxos.
Defina-se no estado STATE_ELECTING e aumente as estatísticas de l_mon_num_elections e l_mon_election_call.
Ligue para call_election () do eleitor.
Monitor :: start_election (), faça aqui principalmente o seguinte.
A leitura de eleição_epoch de segunda-feira na loja Mon é armazenada em época, e a atualização do valor de época para torná-lo um número ímpar indica que o ciclo de eleição foi inserido. época é um número par, indicando que um quorum estável foi formado.
Adicione-se ao mapa acked_me e defina electing_me como true. Espero que você se escolha como líder.
Envie a mensagem MMonElection :: OP_PROPOSE para os membros no monmap.
Depois que outros monitores recebem a mensagem, eles passam pela lógica de despacho, a saber Monitor :: ms_dispatch () -> Monitor :: _ ms_dispatch () -> Monitor :: dispatch_op () -> Elector :: dispatch () e, em seguida, insira a mensagem Fluxo de processamento.
Elector :: handle_propose (), primeiro assegure que a versão da época da mensagem recebida seja a versão eleita (número ímpar) e atenda aos requisitos do recurso. Em seguida, julgue para definir sua época de eleição com o valor da época contida na mensagem. Por fim, compare o valor da classificação: se seu valor for menor, você não reconhecerá essa eleição, mas reiniciará uma rodada de eleições. Se o seu próprio valor de classificação for maior, insira o processo Elector :: defer (), envie a mensagem MMonElection :: OP_ACK e aceite esta rodada de eleições.
Após o Monitor iniciar a eleição receber a mensagem ACK, ele entra no fluxo de processamento:
Adicione o próprio par de ACK ao mapa acked_me.Se o número de acked_me for igual ao número de membros no monmap, isso indica que a eleição foi bem-sucedida e o processo de vitória foi iniciado. O que precisa ser esclarecido aqui é como, no caso de um monitor inativo, os monitores restantes são eleitos com êxito (os membros acked_me não devem ser iguais ao número de membros do monmap).
Leader entrará em Elector :: victory (), o fluxo de processamento específico é o seguinte:
Adicione os membros em acked_me ao quorum e aumente o valor da época da eleição em um para torná-la um número par, marcando o final do processo eleitoral.
Envie MMonElection :: OP_VICTORY a todos os membros no quorum para informar que a eleição terminou.
Diga ao monitor que sua eleição foi bem sucedida.
O líder entra em Monitor :: win_election (), o fluxo de processamento específico é o seguinte:
Defina seu status como STATE_LEADER e limpe os membros em outside_quorum.
Chame paxos-> leader_init () para inicializar paxos e todos os serviços paxos_service. Na inicialização do paxos, o estado do paxos é definido como STATE_RECOVERING, e a função Paxos :: collect () é chamada para sincronizar os dados entre seg. Isso será introduzido na seção de atualização de dados do Paxos posteriormente.
Inicie o serviço health_monitor.No momento, ele verifica principalmente o uso do espaço de armazenamento mon.
Inicie a verificação de verificação de tempo para garantir que a diferença horária entre os monitores não exceda mon_clock_drift_allowed; se exceder, ele reportará mon clockskew.
Atualize os metadados do monitor, que registram principalmente as seguintes informações:
[root @ ceph02 ~] #ceph mon metadata ceph02
{
"arch": "x86_64",
"cpu": "Intel Xeon E312xx (Sandy Bridge)",
"distro": "CentOS",
"distro_codename": "Core",
"distro_description": "CentOS Linux versão 7.1.1503 (Core)",
"distro_version": "7.1.
"kernel_description": "# 1SMP ter 15 de setembro 15:05:51 UTC 2015",
"kernel_version": "3.10.0-229.14.1.el7.x86_64",
"mem_swap_kb": "0",
"mem_total_kb": " 1884312 ",
" os ":" Linux "
} O
Peon entra no Elector :: handle_victory () após receber a mensagem MMonElection :: OP_VICTORY, o fluxo de processamento específico é o seguinte:
Defina sua própria época da eleição com o valor da época na mensagem.
Vá para Monitor :: lose_election (), defina seu estado como STATE_PEON, chame peon_init para inicializar paxos e paxosservice relacionado e atualize as informações do registrador.
Cancele seu tempo de expiração_evento, que é o tempo controlado pelo parâmetro mon_election_timeout.
Neste ponto, o processo de eleição do Monitor terminou, mas o estado de Paxos ainda não entrou em estado estacionário, portanto, o restante é o Líder para coordenar a sincronização de dados de todos os membros no quorum, principalmente pelo mecanismo de envio em duas fases do protocolo Paxos. Concluído, todo o processo é relativamente complicado e será apresentado em detalhes no mecanismo de atualização de dados subsequente. Para facilitar o entendimento de todo o processo eleitoral, mostrarei a lógica principal da situação do gráfico de cronogramas.Para detalhes, veja a figura a seguir: A linha principal da figura é o Líder e vários arquivos principais envolvidos no processo eleitoral são fornecidos.
————————————————
Declaração de direitos autorais: este artigo é um artigo original do blogger da CSDN "Look at the Wind", seguindo o contrato de direitos autorais do CC 4.0 BY-SA, por favor, anexe o link da fonte original e este Declaração.
Link original: https://blog.csdn.net/scaleqiao/article/details/52315468
Link original: https://blog.csdn.net/scaleqiao/article/details/52242345
Link original: https: //blog.csdn .net / scaleqiao / article / details / 52231900
