Quantas vezes já necessitamos ter nossos serviços, ou melhor, manter nossos serviços sempre disponíveis, e quantas vezes já nos aconteceu que o disco rígido de nosso servidor está danificado e não temos backup, enfim, pensando nesses circunstâncias, decidi criar este tutorial para garantir que nossos servidores, ou melhor, nossos serviços estejam sempre online.
Levando em consideração que o tutorial é voltado para pessoas avançadas em Linux, não vou tocar em tópicos como a instalação do sistema básico que irei usar desta vez CentOS 6 64 bits em sua última atualização. Da mesma forma, mencionarei apenas o estritamente necessário para o funcionamento do cluster (servidores de alta disponibilidade).
Também faço o comentário que este guia é direcionado à necessidade de manter o serviço web sempre ativo, embora eu o tenha usado com outros serviços com sucesso, acho que para começar ou melhor dito, para começar, o mais simples é criar um cluster de servidor web.
Sem mais delongas, vamos passar para as coisas boas.
Requisitos de sistema.1. Memória RAM 1 GB
2. Disco Rígido 80 GB
3. Processador Celeron
4. Partição de dados para o cluster (qualquer tamanho que você deseja criar)
5. Sistema operacional CentOS 6 (em sua última atualização)
Se você atender aos requisitos, vamos começar o Instalação de cluster Linux.
O próximo passo é instalar o DRBD para a sincronização das partições em ambos os servidores, para isso é necessário execute o shell as seguintes instruções:
1. Adicione ELRepo à lista de repositórios do sistema
[root @ node1 ~] rpm -ivh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
2. Instale os utilitários drbd (dispositivo de bloco replicado distribuído) e os pacotes kmod
[root @ node1 ~] yum install -y kmod-drbd83 drbd83-utils(Pessoalmente, uso 8.3, pois 8.4 me deu problemas com algumas distribuições)
3. Drbd é adicionado ou inserido no kernel do sistema
[root @ node1 ~] modprobe drbd
4. O arquivo de recurso para o drbd deve ser criado
Ele está localizado em /etc/drbd.d/mydrbd.res; onde mydrbd.res é o nome do arquivo e pode ser modificado por quem quisermos, desde que mantenhamos a extensão .res; Este arquivo deve ser criado em ambos os servidores, ou, quando o arquivo está configurado corretamente, é copiado para o segundo nó; a configuração seria mais ou menos a seguinte:
resource mydrbd {#este é o nome do recurso de protocolo C; inicialização {wfc-timeout 180; degr-wfc-timeout 120;} # 180 segundos de espera pelo dispositivo escravo, 120 segundos, se ele não responder é degradado e permanece como disco secundário {on-io-error detach; } net {cram-hmac-alg "sha1"; shared-secret "secret key";} # Nesta parte, uma chave com criptografia sha1 é especificada, esta chave é para comunicação entre os dois nós. syncer {rate 100M;} # velocidade de sincronização, não importa que tenhamos placa de rede Gigabit, ela não funciona a 1000M, a velocidade máxima recomendada é 100M (instalei com 10M e funciona muito bem, um pouco lento a primeira sincronização, mas você não vê a diferença) no node1 {device / dev / drbd0; # aqui especificamos qual é o dispositivo reservado para o drbd, podemos ter vários dispositivos para diferentes dados, ou serviços diferentes, como SAMBA, MySQL, entre outros disk / dev / md2; #especifique a partição que será usada para o endereço drbd 172.16.0.1:7788; # Especificamos um IP fora do alcance de nossa rede, vale ressaltar que o cabo de rede deve ser conectado diretamente entre servidores, sem passar por switch ou hub, se forem placas de rede de modelo recente, não é necessário um cabo crossover. meta-disco interno; } no node2 {# as especificações do segundo devem ser as mesmas do primeiro, apenas o endereço IP muda, deve ser a mesma porta, isso porque se tivermos 2 clusters juntos, eles entrarão em conflito e não funcionarão apropriadamente, se quisermos ter vários clusters, é recomendável usar portas diferentes, nem é preciso dizer que essas portas devem ser iguais em ambos os nós. dispositivo / dev / drbd0; disco / dev / md2; endereço 172.16.0.2:7788; meta-disco interno; }}
PROLONGAR
5. A seguir está a configuração do arquivo hostIsto é para que os servidores sejam pesquisados através do IP de sincronização e não pelo IP da rede local e assim evitamos conflitos com os serviços:
/ etc / hosts 192.168.1.1 node1 #name of node1 no segmento de rede local 192.168.1.2 node2 #name of node2 no segmento de rede local 172.16.0.1 node1 #name of node1 no segmento de rede de sincronização 172.16.0.2 node2 #name from node2 in sync segmento de rede
6. A unidade de armazenamento para o drbd é inicializada
[root @ node1 ~] drbdadm create-md disk1
7. O serviço drbd ou deamon é iniciado
/etc/init.d/drbd start
8. No nó que queremos ser o principal, executamos o seguinte comando
drbdadm - -overwrite-data-of-peer disco primário 1
9. Nós monitoramos a sincronização de ambos os nós
Para isso executamos:
cat / proc / drbdA resposta do comando acima é algo como o seguinte:
versão: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c construído por phil @ Build32R6, 2012-12-20 20:23:49 1: cs: SyncSource ro: Primário / Secundário ds: UpToDate / C rn- ns inconsistentes: 1060156 nr: 0 dw: 33260 dr: 1034352 al: 14 bm: 62 lo: 9 pe: 78 ua: 64 ap: 0 ep: 1 wo: f oos: 31424 [===== =============>.] sincronizado: 97,3% (31424/1048508) K final: 0:00:01 velocidade: 21.240 (15.644) K / s # Aqui podemos ver que a Sincronização vai para 97,3% e especifica-se que este é o nó primário e o nó secundário aparece como inconsistente, pois a sincronização ainda não foi finalizada. # Uma vez terminado, executamos cat / proc / drbd novamente e temos o seguinte: version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c construído por phil @ Build32R6, 2012-12-20 20: 23: 49 1: cs: Conectado ro: Primário / Secundário ds: UpToDate / UpToDate C r- ns: 1081628 nr: 0 dw: 33260 dr: 1048752 al: 14 bm: 64 lo: 0 pe: 0 ua: 0 ap: 0 ep: 1 wo: f oos: 0 # Ao retornar a mensagem UpToDate, estamos cientes de que a sincronização foi concluída e as partições drbd são exatamente as mesmas.
10. O próximo passo é formatar nosso dispositivo drbdPara isso executamos:
mkfs.ext3 / dev / drbd1Eu uso ext3 porque me deu uma boa estabilidade, mas também poderíamos usar ext4, não recomendo usar qualquer tipo de partição abaixo de ext3.
Até agora já somos capazes de montar manualmente a partição / dev / drbd1 em qualquer ponto de montagem do sistema, no meu caso eu uso / home para montagem já que cada um dos usuários registrados em ambos os nós tem seus próprios diretórios para páginas web, portanto Eu corro:
mount -t ext3 / dev / drbd1 / homeE começo a criar os usuários para replicação de dados em ambos os servidores, o seguinte é o instalação de pulsação, aplicativo utilizado para monitorar os servidores entre si e que se encarregará de fazer as alterações pertinentes caso o primário caia por qualquer motivo e transforma o secundário em primário para garantir a funcionalidade do Sistema.
Para a instalação de pulsação apenas as etapas a seguir devem ser seguidas. O repositório é instalado para download com o seguinte comando:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmEdite o arquivo:
epel.repo /etc/yum.repos.d/epel.repomudar a linha # 6 ‘Habilitar = 1 por habilitar = 0’; você pode usar os editores vi ou nano, como desejar.
[epel] name = Pacotes extras para Enterprise Linux 6 - $ basearch # baseurl = http: //download.fedoraproject.org/pub/epel/6/$basearch mirrorlist = http: //mirrors.fedoraproject.org/metalink? repo = epel-6 & arch = $ basearch failovermethod = priority enabled = 0 # Esta é a linha que devemos editar Instale o heartbeat com o seguinte comando: yum -enablerepo = epel install heartbeat Assim que a instalação for concluída, ele nos dirá algo semelhante para: Instalado: heartbeat .i686 0: 3.0.4-1.el6 Concluído!Assim que o processo de instalação for concluído, a próxima coisa a fazer é editar os 3 arquivos essenciais para que a pulsação funcione; localizado em /etc/ha.d
- authkeys
- ha.cf
- haresources
Abrimos o arquivo authkeys com o seguinte comando:
vi /etc/ha.d/authkeysAs seguintes linhas são adicionadas:
auth 1 1 sha1 chave para conexão entre heartbeats # Nesta linha definimos qual será a chave para que os heartbeats de cada nodo se comuniquem entre si, pode ser a mesma usada no drbd ou diferente.Mudamos as permissões do arquivo authkeys para que só possa ser lido pelo root:
chmod 600 /etc/ha.d/authkeysAgora vamos editar o segundo arquivo:
vi /etc/ha.d/ha.cfAdicionamos as seguintes linhas:
logfile / var / log / ha-log # log do sistema está habilitado para erros futuros logfacility local0 keepalive 2 deadtime 30 # o sistema espera 30 segundos para declarar node1 como inoperável initdead 120 # o sistema espera 120 segundos para inicialização do nó para esperar pelo outro . bcast eth0 # é especificada a placa Ethernet pela qual a comunicação entre os servidores será transmitida, é muito importante estar atento pois aqui definimos qual placa de rede vai para a rede local e qual direciona a sincronização udpport 694 # a porta de sincronização é especificada , como no drbd, podemos ter vários servidores e cada par com sua respectiva porta definida auto_failback off # marcando-o como desligado, evitamos que o node1 uma vez danificado e degradado retorne como primário ou tente retornar, causando conflito com outro nó node1 node2 # especificamos os nomes de ambos os nós.
PROLONGAR
Para finalizar a configuração, devemos editar o arquivo haresources com o comando:
vi /etc/ha.d/haresourcesAdicione as seguintes linhas:
node1 192.168.1.10/24/eth0 drbddisk :: mydrbd Filesystem :: / dev / drbd0 :: / home :: ext3 #esta linha é responsável por montar a partição de dados no nó referenciado como node1 primário 192.168.1.10/24/ eth0 httpd #esta linha é responsável por definir o serviço apache ou servidor web para o nó referido como primário
PROLONGAR
Os 3 arquivos devem ser copiados para o node2, o seguinte comando cuidará disso:
scp -r /etc/ha.d/root@node2:/etc/O arquivo deve ser editado httpd.conf para que escute as requisições do ip virtual, neste caso 192.168.1.10:
vi /etc/httpd/conf/httpd.confA linha é adicionada ou modificada Ouça 192.168.1.10:80
O arquivo modificado é copiado para o segundo servidor:
scp /etc/httpd/conf/httpd.conf root @ node2: / etc / httpd / conf /Iniciamos o serviço de pulsação em ambos os nós:
/etc/init.d/heartbeat startCom isso, temos nosso servidor de alta disponibilidade pronto, basta entrar em nosso navegador de internet e colocar o ip 192.168.1.10 ou instalar um painel de sua escolha para administração de domínio e gerar os respectivos usuários para acessar as páginas ou domínios cadastrados no servidor.
O servidor de alta disponibilidade pode ser usado conforme já mencionado no início deste tutorial como: servidor de e-mail, servidor web, servidor de banco de dados, servidor samba entre outros; Da mesma forma, ajuda-nos a prevenir a perda de informação devido a falhas de hardware, e podemos reforçá-la ainda mais com invasões nas unidades de disco, seja por hardware ou software, nunca é demais ter discos em invasão para manter o sistema.
No entanto, o servidor de alta disponibilidade não está isento de problemas ou erros, quando um nó está degradado, podemos ir para o log de pulsação para ver o que aconteceu, isso é feito acessando o arquivo atribuído na configuração de haresources em /etc/ha.d
Da mesma forma, pode acontecer que quando você reinicia os dois servidores por algum motivo, eles não iniciam como primário / secundário e começam como primário / desconhecido e desconhecido / secundário.
PROLONGAR
Para resolver isso, devemos seguir os seguintes passos.
Na casca do nó caído, digitamos:
recurso secundário drbdadmSubseqüentemente:
recurso de desconexão drbdadmE depois:
drbdadm - recurso de conexão --discard-my-dataFinalmente, no nó sobrevivente, ou primário, digitamos:
recurso de conexão drbdadmAgora ele vai iniciar a ressincronização dos nós do nó sobrevivente para o nó caído, começando imediatamente ao pressionar a tecla "Digitar" na instrução 4.
O que aconteceu aqui é conhecido como um Cérebro dividido, isso acontece quando por algum motivo o nó primário falha e está degradado, uma vez que isso aconteça, é altamente recomendável revisar e analisar em profundidade o nó caído e antes de reincorporá-lo ao cluster para resolver qualquer problema existente, também pode ser necessário reinstalar todo o sistema operacional deste nó, e sem nenhum problema, incorporá-lo ao cluster como secundário para sincronização e se for o caso, uma vez sincronizado, altere-o para primário.
Finalmente, gostaria de enfatizar o revisão regular da saúde do clusterSabemos bem que, para alto desempenho, é sempre bom estar um passo à frente dos desastres de computador; Já que como pessoal de TI, a responsabilidade de cuidar dos dados da empresa ou empresas a que pertencemos recai sobre nós, como uma observação adicional, acho que vale a pena sempre ter um backup em alguma unidade alternativa aos nós e assim ter a segurança das informações garantidas.
Instale e configure o Ubuntu Server
Gostou e ajudou este tutorial?Você pode recompensar o autor pressionando este botão para dar a ele um ponto positivo
