{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Cluster de dois n\u00f3s \u2013 o diabo est\u00e1 nos detalhes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr! Apresento a voc\u00eas a tradu\u00e7\u00e3o do artigo \u00abDois N\u00f3s \u2014 O Diabo Est\u00e1 Nos Detalhes\u00bb<\/a><\/noindex> do autor Andrew Beekhof.<\/p>\n

Muitas pessoas preferem clusters com dois n\u00f3s, pois parecem mais simples conceitualmente e tamb\u00e9m s\u00e3o 33% mais baratos do que seus irm\u00e3os de tr\u00eas n\u00f3s. Embora seja poss\u00edvel montar um bom cluster com dois n\u00f3s, na maioria dos casos, devido a cen\u00e1rios n\u00e3o considerados, essa configura\u00e7\u00e3o criar\u00e1 muitos problemas n\u00e3o evidentes.
\n<\/a><\/noindex>
\nO primeiro passo para criar qualquer sistema de alta disponibilidade \u00e9 identificar e tentar eliminar os pontos \u00fanicos de falha, muitas vezes abreviados como SPoF<\/i> (ponto \u00fanico de falha).<\/p>\n

\u00c9 importante lembrar que em qualquer sistema n\u00e3o \u00e9 poss\u00edvel eliminar todos os riscos de downtime. Isso decorre, pelo menos, do fato de que a prote\u00e7\u00e3o t\u00edpica contra risco envolve a introdu\u00e7\u00e3o de certa redund\u00e2ncia, o que aumenta a complexidade do sistema e cria novos pontos de falha. Portanto, inicialmente, fazemos compromissos e nos concentramos em eventos relacionados a pontos \u00fanicos de falha, em vez de cadeias de eventos inter-relacionados e, portanto, cada vez menos prov\u00e1veis.<\/p>\n

Considerando os compromissos, n\u00e3o buscamos apenas SPoF, mas tamb\u00e9m equilibramos riscos e consequ\u00eancias; como resultado, o que \u00e9 cr\u00edtico pode diferir para cada implanta\u00e7\u00e3o.<\/p>\n

Nem todos precisam de fornecedores alternativos de energia com linhas de transmiss\u00e3o independentes. Embora a paranoia tenha se justificado pelo menos para um cliente, quando sua monitora\u00e7\u00e3o detectou um transformador defeituoso. O cliente ligou tentando avisar a empresa de energia, at\u00e9 que o transformador defeituoso explodiu.<\/p><\/blockquote>\n

\nUm ponto de partida natural \u00e9 ter mais de um n\u00f3 no sistema. No entanto, antes que o sistema possa mover servi\u00e7os para o n\u00f3 sobrevivente ap\u00f3s a falha, em geral, \u00e9 necess\u00e1rio garantir que os servi\u00e7os movidos n\u00e3o estejam ativos em outro lugar.<\/p>\n

Um cluster de dois n\u00f3s n\u00e3o tem desvantagens se, como resultado de uma falha, ambos os n\u00f3s gerenciam o mesmo site web est\u00e1tico. No entanto, tudo muda se, como resultado, ambos os lados gerenciam uma fila de tarefas compartilhada de forma independente ou fornecem acesso de grava\u00e7\u00e3o n\u00e3o coordenado a um banco de dados replicado ou a um sistema de arquivos compartilhado.<\/p>\n

Portanto, para evitar a corrup\u00e7\u00e3o de dados como resultado da falha de um n\u00f3 - confiamos no que chamamos de \u00abfencing\u00bb<\/i> (cercamento).<\/p>\n

O princ\u00edpio do cercamento<\/h2>\n

\nO princ\u00edpio do cercamento est\u00e1 baseado na quest\u00e3o: um n\u00f3 concorrente pode causar a corrup\u00e7\u00e3o de dados? Se a corrup\u00e7\u00e3o de dados for um cen\u00e1rio prov\u00e1vel - uma boa solu\u00e7\u00e3o ser\u00e1 isolar o n\u00f3 tanto de solicita\u00e7\u00f5es de entrada quanto de armazenamento persistente. A abordagem mais comum ao cercamento \u00e9 desconectar n\u00f3s falhos.<\/p>\n

Existem duas categorias de m\u00e9todos de cercamento que eu chamarei de diretos<\/i> e indiretos<\/i>, mas igualmente podem ser chamados de ativos<\/i> e passivos<\/i>. Os m\u00e9todos diretos incluem a\u00e7\u00f5es por parte dos n\u00f3s remanescentes, como interagir com o dispositivo IPMI (Intelligent Platform Management Interface \u2014 interface para monitoramento e gerenciamento remoto do estado f\u00edsico do servidor) ou iLO (meio de gerenciamento de servidores na aus\u00eancia de acesso f\u00edsico a eles), enquanto os m\u00e9todos indiretos dependem do n\u00f3 falhado para reconhecer de alguma forma que est\u00e1 em estado insalubre (ou, pelo menos, impede que os outros membros se recuperem) e sinalizar hardware watchdog<\/a><\/noindex> sobre a necessidade de desconectar o n\u00f3 falhado.<\/p>\n

O qu\u00f3rum ajuda no uso tanto dos m\u00e9todos diretos quanto dos indiretos.<\/p>\n

Cercamento direto<\/h3>\n

\nNo caso de cercamento direto, podemos usar o qu\u00f3rum para evitar corridas de cercamento em caso de falha na rede.<\/p>\n

Tendo a concep\u00e7\u00e3o de qu\u00f3rum, o sistema possui informa\u00e7\u00f5es suficientes (mesmo sem conex\u00e3o com seus parceiros) para que os n\u00f3s saibam automaticamente se devem iniciar o cercamento e\/ou recupera\u00e7\u00e3o.<\/p>\n

Sem qu\u00f3rum, ambas as partes da separa\u00e7\u00e3o de rede pressup\u00f5em justificadamente que a outra parte est\u00e1 inativa e tentar\u00e3o se desassociar uma da outra. No pior cen\u00e1rio, ambos os lados conseguem desligar todo o cluster. Um cen\u00e1rio alternativo \u00e9 um 'deathmatch', um ciclo infinito de n\u00f3s aparecendo, n\u00e3o vendo seus pares, reinicializando-os e iniciando a recupera\u00e7\u00e3o apenas para reiniciar quando seu par segue a mesma l\u00f3gica.<\/p>\n

O problema da desassocia\u00e7\u00e3o \u00e9 que os dispositivos mais frequentemente utilizados ficam indispon\u00edveis devido aos mesmos eventos de falha que queremos direcionar para a recupera\u00e7\u00e3o. A maioria dos cart\u00f5es IPMI e iLO est\u00e1 instalada em hosts que eles controlam e, por padr\u00e3o, utilizam a mesma rede, levando os n\u00f3s alvo a acreditar que os outros n\u00f3s est\u00e3o offline.<\/p>\n

Infelizmente, as caracter\u00edsticas de opera\u00e7\u00e3o dos dispositivos IPMI e iLO raramente s\u00e3o consideradas no momento da compra de equipamentos.<\/p>\n

Desassocia\u00e7\u00e3o indireta<\/h3>\n

\nO qu\u00f3rum tamb\u00e9m \u00e9 importante para gerenciar desassocia\u00e7\u00f5es indiretas; se tudo for feito corretamente, o qu\u00f3rum pode permitir que os sobreviventes assumam que os n\u00f3s perdidos, ap\u00f3s um certo per\u00edodo, passar\u00e3o para um estado seguro.<\/p>\n

Com essa configura\u00e7\u00e3o, o timer do hardware watchdog \u00e9 reiniciado a cada N segundos, se o qu\u00f3rum n\u00e3o for perdido. Se o timer (geralmente v\u00e1rias vezes N) expirar, o dispositivo executa um desligamento sem gra\u00e7a (n\u00e3o shutdown).<\/p>\n

Essa abordagem \u00e9 muito eficaz, mas sem qu\u00f3rum para gerenci\u00e1-la, h\u00e1 informa\u00e7\u00e3o insuficiente dentro do cluster. N\u00e3o \u00e9 f\u00e1cil distinguir entre a perda de rede e a falha do n\u00f3 parceiro. A raz\u00e3o pela qual isso \u00e9 importante \u00e9 que, sem a capacidade de distinguir entre os dois casos, voc\u00ea \u00e9 for\u00e7ado a escolher o mesmo modo de comportamento em ambas as situa\u00e7\u00f5es.<\/p>\n

O problema de escolher um \u00fanico modo \u00e9 que n\u00e3o existe um curso de a\u00e7\u00e3o que maximize a disponibilidade e previna a perda de dados.<\/p>\n