335 High Availability Cluster Storage

From Documentacao LPI
Jump to: navigation, search

335.1_DRBD_cLVM

Objetivos

Peso 3

Description: Candidates are expected to have the experience and knowledge to install, configure, maintain and troubleshoot DRBD devices. This includes integration with Pacemaker. DRBD configuration of version 8.4.x is covered. Candidates are further expected to be able to manage LVM configuration within a shared storage cluster. Key Knowledge Areas:

   Understanding of DRBD resources, states and replication modes
   Configuration of DRBD resources, networking, disks and devices
   Configuration of DRBD automatic recovery and error handling
   Management of DRBD using drbdadm
   Basic knowledge of drbdsetup and drbdmeta
   Integration of DRBD with Pacemaker
   cLVM
   Integration of cLVM with Pacemaker

Terms and Utilities:

   Protocol A, B and C
   Primary, Secondary
   Three-way replication
   drbd kernel module
   drbdadm
   drbdsetup
   drbdmeta
   /etc/drbd.conf
   /proc/drbd
   LVM2
   clvmd
   vgchange, vgs


Understanding of DRBD resources, states and replication modes

DRDB oferece um dispositivo de bloco projetado para disponibilizar dispositivos de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade (HA). Isto é feito através de espelhamento de um dispositivo de bloco inteiro através de uma rede. O DRBD pode ser entendido basicamente como raid-1 pela rede.

  • DRBD trabalha sob os dispositivos de bloco, como partições de disco ou volumes logicos LVM. Ele espelha cada bloco de dados que são gravados no disco para o nó pareado.
    • Fully synchronous: O espelhamento pode ser feito fortemente acoplado (síncrono). Isso significa que o sistema de arquivos no nó ativo é notificado de que a escrita do bloco foi concluída somente quando o bloco fez isso para ambos os discos do cluster. Espelhamento síncrono (chamado no DRBD de protocolo C) é a escolha correta para clusters de alta disponibilidade em que você não ousa perder uma única transação em caso de um crash completo do nó ativo (Chamado de primary no DRBD).
    • Asynchronous : Espelhamento assíncrono significa que a entidade que emitiu os pedidos de gravação é informada sobre a conclusão, logo que os dados são gravados no disco local. O espelhamento assíncrono é usado quando for necessário construir mirrors em longas distâncias, ou seja, o tempo de ida e volta da rede de interconexão é maior que a latência de escrita que você pode tolerar para sua aplicação. (Nota: A quantidade de dados no nó peer que pode ficar para trás é limitada pelo bandwidth-delay e o TCP send buffer.)
  • Módulo de kernel DRBD: O núcleo de funcionalidades do DRBD é implementada via modulo de kernel Linux. Especificamente, DRBD constitui um driver para dispositivos de bloco virtuais, então o DRBD está situado perto da parte inferior de um sistema de pilha I/O. Em virtude disso, DRBD é extremamente flexível e versátil o que o torna uma solução de replicação adequada para a adição de alta disponibilidade para praticamente qualquer aplicação. DRBD por definição é agnóstico em relação as camadas superiores a ele. Por exemplo: DRBD não detecta automaticamente corrupção nos sistemas de arquivos, ou adiciona a funcionalidade de gravação ativo-ativo aos sistemas de arquivo ext3 ou xfs.
  • Definições de: Primary, Secondary: O DRBD funciona de modo padrão com um nó como primário (Primary) e outro nó secundário (Secundary). Os sistemas de arquivos tradicionais permitem apenas a escrita no nó primário. Estes sistemas de arquivos são projetados para um computador que acessa um disco, assim eles não podem lidar com dois computadores que acessam um (virtualmente) disco compartilhado. Alguns sistemas de arquivos como GFS e OCFS2 permitem gravação no modo Primary-Primary.
  • Protocolos A, B e C
    • Protocolo A: Protocolo de replicação assíncrona: Operação de escrita local no primeiro nó é considerada completa quando a escrita no disco local é finalizada e o pacote de replicação for encaminhado para o "TCP send buffer" local. Em um evento de fail-over, dados serão perdidos. Os dados do nó standby estarão consistentes após o fail-over, contudo, as atualizações mais recentes poderão ser perdidas. Protocolo A é mais usado em cenários de replicações em longa distância. Quando usado em combinação com DRBD Proxy se torna uma efetiva solução de disaster recovery.
    • Protocolo B: Protocolo de replicação Memória síncrona (semi-synchronous). operação de escrita local no primeiro nó é considerada completa assim que a escrita no disco local ocorrer, e o pacote de replicação foi recebido pelo outro nó de replicação. Normalmente, as escritas não são perdidas em um caso de fail-over. Contúdo, em um evento que simultaneamente a energia falhe em ambos os nós e ocorra uma uma perda de dados no nó primário, de forma irreversível, então as escritas mais recentes completadas no nó primário serão perdidas.
    • Protocolo C: Protocolo de replicação síncrona. Operação de escrita local no primeiro nó é considerada completa apenas após tanto o local como o o disco remoto confirmarem a operação de escrita. O resultado é que mesmo a perda de um único nó não ocorre perda de dados. A perda somente ocorre se ambos os nós sofrerem perda irreversível dos discos. O uso mais comum do do DRBD é o protocolo C.

A melhor escolha de protocolo de replicação depende de dois fatores: Proteção e latência. O throughput da rede no entanto é independente do protocolo de rede selecionado.

  • Three-way replication:

Ao usar a replicação de três vias, DRBD acrescenta um terceiro nó a um cluster de 2 nós existente e replica os dados para esse nó, onde ele pode ser usado para fins de backup e recuperação de desastres. Replicação de três vias funciona adicionando um outr, recurso DRBD empilhado em cima do recurso existente guardando seus dados de produção. O recurso empilhado é replicado usando replicação assíncrona (DRBD protocolo A), Os dados de produção podem fazer uso de replicação síncrona (DRBD protocolo C).

    • Replicação de três vias pode ser usada de forma permanente, onde o terceiro nó é atualizado continuamente com os dados do cluster de produção. Como alternativa, ela também pode ser empregada sob demanda, onde o cluster de produção é normalmente desligado do site de backup e a sincronização de site-to-site é executada regularmente, por exemplo, executando uma tarefa de cron noturna.


  • Resources:

Em DRBD, recurso é o termo coletivo que se refere a todos os aspectos de um conjunto particular de dados replicado. Esses incluem:

    • Resource name: Pode ser qualquer nome pelo qual o recurso é referido, US-ASCII, não conter espaços em branco
    • Volumes: Qualquer recurso é um grupo de replicação que consiste em um ou mais volumes que partilham um fluxo de replicação comum. DRBD garante gravação fidelidade em todos os volumes no recurso. Volumes são numerados começando com 0, e pode haver até 65.535 volumes em um recurso. Um volume contém o conjunto de dados replicado, e um conjunto de metadados para uso interno do DRBD. Obs: No nível drbdadm, um volume dentro de um recurso pode ser abordado pelo nome de recurso e número do volume como <recurso> / <Volume>.
    • DRBD Devices: Este é um dispositivo de bloco virtual gerenciado por DRBD. O maior número de dispositivo é 147, e os seus números menores são numerados de 0 para frente, como é habitual. Cada dispositivo DRBD corresponde a um volume de um recurso. O dispositivo de bloco associado é geralmente chamado /dev/drbdX, onde X é o número menor do dispositivo. O DRBD também permite que os nomes dos dispositivos de blocos possam ser definidos pelo usuário, que deve, no entanto, começam com drbd_.
    • Connection: Uma conexão é um link de comunicação entre dois hosts que compartilham um conjunto de dados replicado. Cada recurso envolve apenas dois hosts e exatamente uma conexão entre esses hosts, assim, os termos de recursos e de conexão podem ser usados alternadamente. Obs: No nível drbdadm, uma conexão é abordada pelo nome do recurso.
  • Resource roles: No DRBD, cada resource tem uma função que pode ser Primary ou Secundary.

A escolha de termos aqui não é arbitrária. Esses papéis não foram deliberadamente chamados "Ativo" e "passivo" por criadores do DRBD. Primário versus secundário refere-se a um conceito relacionado com a disponibilidade de armazenamento, enquanto ativo versus passivo refere-se à disponibilidade de um aplicativo. É geralmente o caso num ambiente de alta disponibilidade que o nó principal é também a um ativo. Como visto acima, dispositivos DRBD primários podem de forma irrestrita ler e escrever. Já o dispositivo secundário recebe todos updates do dispositivo primário e não permite o acesso completo. Não pode ser utilizado para aplicações lerem ou gravarem.A razão para não permitir sequer acesso somente leitura para o dispositivo é a necessidade de manter a coerência de cache, o que seria impossível se um recurso secundário fora tornado acessível de qualquer forma.

    • A função de recursos pode, evidentemente, ser alteradas, quer por intervenção manual ou por meio de um algoritmo automatizado por uma aplicação de gestão de cluster. A alteração da função dos recursos do secundário para primário é referida como a promoção, enquanto que a operação inversa é denominada rebaixamento.

Configuration of DRBD resources, networking, disks and devices

  • Arquivo de configuração padrão e diretório de configuração dos resources e de configuração global:
/etc/drbd.conf
/etc/drbd.d/

Por convenção, /etc/drbd.d/global_common.conf contém as seções globais e comuns da configuração DRBD, ao passo que os arquivos .res contêm cada um, uma seção de resources.

  • Pré-requisitos
    • Storage: O DRBD pode ser configurado apontando para um dos seguintes dispositivos:
      • Partição de disco rígido, ou um disco rígido inteiro
      • Dispositivo de RAID por software
      • Volume lógico LVM ou qualquer outro dispositivo de bloco configurado no Linux device-mapper
      • Qualquer outro dispositivo de bloco encontrado no sistema
    • Network:
      • Recomenda-se uma conexão de rede dedicada entre os nós
      • Conexão gigabyte, preferencialmente direta
      • No caso de utilização de switch, usar componentes redundantes e a configuração de rede bounding no modo active-backup
      • Não é recomendado para executar a replicação do DRBD via roteadores
      • Cada Resource DRBD escuta em uma porta de rede. Não é possível configurar um recurso DRBD para suportar mais de uma conexão TCP. Por padrão a porta inicial é 7789.
  • Configuração dos recursos (resources):

Os arquivos de configuração devem estar iguais entre todos os nós do cluster

    • Configuração básica e mínima do arquivo global_common.conf:
# Opcoes gerais e globais
global {
  # Participar da estatistica global do drbd (http://usage.drbd.org)
  usage-count yes;
}

# Opcoes comuns a todos os resources 
common {
 # Tipo de protocolo Default
 protocol C;

 # opcoes referentes a controle de erro dos discos e modo de ação em caso de detecção de erros
 disk {
   # Fazer o que quando detectar erro de I/O de disco: 
   on-io-error detach;

   }

 # Opcoes referentes as opcoes de rede
 net {
   timeout       60;    #  6 seconds  (unit = 0.1 seconds)
   connect-int   10;    # 10 seconds  (unit = 1 second)
   ping-int      10;    # 10 seconds  (unit = 1 second)
   ping-timeout   5;    # 500 ms (unit = 0.1 seconds)
   # Permitir 2 nos como primários (usando sistemas de arquivosOCFS2/openGFS)
   # allow-two-primaries;

   ## Estratégias de auto-recuperação
   # No caso de os dois nodes ficarem como "secondary": Manter desconectados 
   after-sb-0pri disconnect;
   # Quando um dos nodes esta como primário e o antigo primário retorna: Manter desconectado
   after-sb-1pri disconnect;
   # Caso ambos nodes estiverem detectados como primarios: manter desconectado
   after-sb-2pri disconnect;
   }

 # Opcoes relacionadas a banda de transferência "bandwith" e detalhes de sicronização
 syncer {
   # Limite de banda utilizado no processo de resincronização
   rate 10M;
   # Em caso de falha da conexão com o host, ocorre Erro de I/O
   on-no-data-accessible io-error;
 }

}
    • Configuração simples de um recurso configurado em r0.res:
# Nome do recurso 
resource r0 {

  # No Host (colocar o nome do Host)
  on host01 {
    # Dispositivo DRBD à ser criado
    device    /dev/drbd1;
    # Dispositivo de bloco configurado para DRBD
    disk      /dev/sda7;
    # Endereço ip do HOST e porta
    address   10.1.1.31:7789;
    # Tipo de meta-disk
    meta-disk internal;
  }
  on host02 {
    device    /dev/drbd1;
    disk      /dev/sda7;
    address   10.1.1.32:7789;
    meta-disk internal;
  }
}

Após a configuração do DRBD, é necessário criar o meta-data nos discos e inicializar a sincronização afim de ativar os recursos de forma permanente.

  • Habilitando o recurso;
    • Necessária a criação dos meta-dados no disco que são feitos com o comando abaixo em ambos os nós:
# drbdadm create-md <nome_do_recurso>
Exemplo:

# drbdadm create-md r0
    • Iniciar a comunicação em ambos os nós:
# drbdadm up  <nome_do_recurso>
Exemplo;
# drbdadm up r0
    • Sincronização inicial: Para ativar a sincronização inicial, devemos definir qual nó será o primário
# drbdadm -- --overwrite-data-of-peer primary <nome_do_recurso> 
ou
# drbdadm primary --force <nome_do_recurso>
    • A fim de verificar em todas as fases do processo, por erros e status de replicação, analisar o resultado do comando abaixo:
# cat /proc/drbd 

. Este comando exibe o status, a relação Primary/secondary entre outras informações.
Exemplo de um ambiente em sincronização:
# cat /proc/drbd 
version: 8.3.11 (api:88/proto:86-96)
srcversion: CD5F901843FC48539A34561 

 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:1447632 nr:0 dw:0 dr:1448296 al:0 bm:88 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:648396
	[============>.......] sync'ed: 69.2% (648396/2096028)K
	finish: 0:40:31 speed: 248 (240) K/sec
  • Informações sobre o Meta Data Interno e Externo:

Os Meta-dados dos discos podem ser guardados de forma interna ou externa.

    • Interno: Significa que DRBD armazena seus meta-dados no mesmo dispositivo de baixo nível físico como os dados de produção reais. Fá-lo-a anulação de uma área no final do dispositivo para a finalidade específica de armazenamento de metadados.
    • Externo: Os meta-dados são armazenados em um dispositivo diferente dos dados de produção reais. Para algumas operações de gravação, usando meta-dados externo produz uma melhora no comportamento de latência.

Configuration of DRBD automatic recovery and error handling

Como visto, o DRBD funciona como uma Raid-1 de rede, então o DRBD prevê continuidade de serviço mesmo se um dos Devices ou mesmo Nodes vierem a ter falhar. Por padrão, em sistemas de arquivos tradicionais, uma das pontas(peers) da configuração é o primário enquanto a outra é o secundário. Somente o recurso posto em primário pode fazer a leitura e gravação de dados, assim, pode-se promover uma ponta para primário ou despromove-la para secundário. Este procedimento pode ser feito de forma manual ou também de forma automatizada. A forma automatizada pode ser utilizada em conjunto com a análise e identificação de erros, onde o erro em um dos dispositivos pode automaticamente alterar o status levando a promoção ou despromoção do recurso.

  • Promoção e despromoção manuais: Para promoção e despromoção manuais, utiliza-se os comandos abaixo:
. Desmontar o sistema em uso no node com recurso primário
# umount /dev/drbd/by-res/<resource>

. Despromover o recurso
# drbdadm secondary <resource>

. No Node que será permitida escrita, promover o recurso para primário
# drbdadm primary <resource>

. Montar o sistema de arquivos para continuar o uso
# mount /dev/drbd/by-res/<resource> <mountpoint>
  • Estrategias nos erros I/O:

Se um erro ocorrer em um disco ou dispositivo de disco configurado sob a configuração do DRBD, existem duas opções:

    • Passing on I/O errors: Se DRBD está configurado para passar os erros de I/O, quaisquer erros que ocorrem no dispositivo de nível inferior são transparentemente passados para a camada superior de I/O. Assim, é deixado para as camadas superiores para lidar com esses erros. Essa estratégia não garante a continuidade do serviço, e, portanto, não é recomendado para a maioria dos usuários.
    • Masking I/O errors: Se o DRBD está configurado para desconectar no menor nível de erro I/O, o DRBD irá fazê-lo, automaticamente, após a ocorrência do primeiro-nível mais baixo de erro I/O. O erro de I/O é mascarado das camadas superiores, enquanto o DRBD de forma transparente busca o bloco afetado a partir do nó que esta OK, através da rede. A partir de então, DRBD é alterado para operar no modo diskless, e realiza tudas as operações de leitura e escrita I/O no nó. O desempenho neste modo será reduzido, mas o serviço continua sem ser interrompido, e pode ser retornado para o nó problemático de forma deliberada em um momento conveniente.
    • A configuração da estratégia de erros I/O é feita no arquivo de configuração em resource na opção on-io-error:
resource <resource> {
  disk {
    on-io-error <strategy>;
    ...
  }
  ...
}
      • As seguintes opções podem ser colocadas em strategy:
→ detach: Este é o padrão e opção recomendada. Na ocorrência de um erro de "I/O", o nó desconecta o seu dispositivo de disco, e continua 
no modo seamless (sem disco).
→ pass_on: Isto faz com que o DRBD reporte erros de I/O para as camadas superiores (sistemas de arquivos por exemplo). 
→ call-local-io-error: Chama o comando definido como I/O error handler. Isto requer um correspondente comando +local-io-error, definido na seção handler. 
Ela é deixada a critério do administrador, para executar um script ou comando específico.
Exemplo:

----
resource <resource> {
  disk {
    on-io-error call-local-io-error;
    ...
  }
local-io-error "/usr/lib/drbd/notify-io-error.sh;

  ...
}
----


Management of DRBD using drbdadm

Drbdadm é uma ferramenta de administração de alto nível do programa DRBD. Obtém todos os parâmetros de configuração DRBD do arquivo de configuração /etc/drbd.conf e atua como um front-end para o drbdsetup e drbdmeta. Drbdadm tem um modo dry-run, também chamado de modo de checagem, invocado com a opção -d, que mostra quais chamadas dos comandos drbdsetup e drbdmeta seriam feitas porém sem realmente chamar esses comandos.

  • Principais comandos:
Formato:
# drbdadm COMANDO <recurso> ou all

COMANDOS:
→ attach: Anexa um dispositivo de armazenamento de backup ao recurso DRBD
→ detach: Remove  um dispositivo de armazenamento de backup do recurso DRBD
→ connect: Ajusta a configuração de rede do dispositivo do recurso. Se o dispositivo já está configurado em ambos os hosts, os dois dispositivos do DRBD 
irão se conectar. Se houver mais de dois hosts selecionados no recurso que você precisa para usar a opção ''--peer '' para selecionar o par que você deseja
se conectar.
→ disconnect: Remove a configuração de rede do recurso. O dispositivo irá para o stado StandAlone
→ syncer: Carrega os parametros de resincronização do dispositivo
→ up: Um atalho para attach e connect
→ down: Um atalho para disconnect e detach
→ primary: Promove os dispositivos do recurso como primario. Para executar esta opção deve-se ter acesso completo ao dispositivo, criação e montagem
 de sistema de arquivos.
→ secondary: Conduz o dispositivo para modo secundário. Isto é necessário, uma vez que apenas um nó pode ser primário, a não ser que a
 opção "allow-two-primaries" esteja setada no arquivo de configuração.
→ invalidate: Força o DRBD para considerar os dados no dispositivo de armazenamento de backup local como out-of-sync (fora de sincronia).
Portanto o DRBD irá copiar todos e cada bloco de seus pares, para trazer o dispositivo de armazenamento local de volta à sincronia. Forçar a resincronização
→ invalidate-remote: Similiar ao comando anterior, contudo, os dados são resincronizados a partir do storage de backup local para o remoto.
→ resize: Redimensiona o tamanho dos dispositivos do recurso, após reexaminar todos os tamanhos dos devices. Usado quando for acrescentado mais espaços nos
dois dispositivos pareados, para o DRBD identificar o novo tamanho. Sub-opções utilizadas:
 --assume-peer-has-space
 --assume-clean
→ check-resize: Chama o drbdmeta para eventualmente mover o meta-data.
→ create-md: Inicializa o meta-data no storage. É necessário para execução de um recurso pela primeira vez
→ get-gi: Exibe uma representação textual curta dos identificadores de geração de dados. 
→ show-gi: Exibe uma representação textual dos identificadores de geração de dados. 
→ dump-md: Despeja todo o conteúdo da armazenagem de meta-dados, incluindo o mapa de bits armazenados e atividade de registo, numa representação textual.   
→ outdate; Seta a flag outdate no meta-datos
→ adjust: Sincroniza a configuração do dispositivo com seu arquivo de configuração 
→ wait-connect: Espera até que o dispositivo está conectado ao seu dispositivo pareado.
→ role: Exibe as roles atuais do dispositivo (primary, secondary)
→ state: Depreciado, semelhante ao role
→ cstate: Mostra o estado atual das conexões dos dispositivos
→ status: Mostra o status atual de todos os dispositivos definidos no arquivo de configuração. Saída em formato XML
→ dump: Analisa o arquivo de configuração e despejá na saída padrão. Pode ser usado para verificar o arquivo de configuração para a correção sintática.
→ outdate: Usado para marcar o nó como outdate. Usualmente usado por chamadas fence-peer
→ verify: Inicia verificação online. Durante a verificação online, dados em ambos os nós são comparados.
→ pause-sync: Temporariamente suspende a resincronização
→ resume-sync: Continua a resincronização parada com o pause-sync
→ new-current-uuid: Gera um novo UUID e alterna todos os demais valores UUID.
→ dstate: Exibe o estado atual do dispositivo de armazenamento de backup

Basic knowledge of drbdsetup and drbdmeta

  • drbdsetup: Configura o módulo DRBD carregado no kernel. Todos os parâmetros para drbdsetup devem ser passados na linha de comando. A maioria dos usuários raramente precisará usar drbdsetup diretamente.

Alguns usos importantes: O drbdsetup é usado para associar dispositivos DRBD com dispositivos de bloco de baixo nível, também é usado para configurar dispositivos DRBD para espelhamento em dispositivos de bloco de baixo nível e para inspecionar as configurações que os dispositivos DRBD estão rodando.

    • Exemplos:
. Formato
# drbdsetup <device> <comando>

. Exibe as configurações
# drbdsetup /dev/drbd1 show

. Configurar dispositivo como primário:
# drbdsetup /dev/drbd1 primary
  • drbdmeta: Permite criar, descarregar, restaurar e modificar estruturas de meta-dados do DRBD. Assim como o drbdsetup, a maioria dos usuários só raramente precisa usar drbdmeta diretamente.
    • Exemplos:
. Formato
# drbdmeta <device> <comando>

. Criando meta-dados no device
# drbdmeta /dev/sda1 create-md

Integration of DRBD with Pacemaker

Um dos casos frequentes do DRBD é sua utilização em conjunto com o Pacemaker. Pacemaker é um gestor de recursos de cluster sofisticado, rico em recursos, e amplamente implantado para a plataforma Linux.

  • Verificar o funcionamento do Pacemaker
# pcs cluster status
  • Configurar DRBD normalmente
  • Criar no Pacemaker os recursos de monitoramento e de modo master/slave
. Criar um arquivo de configuração baseado no principal para incluir as configurações do DRBD 
# pcs cluster cib drbd_cfg

. Adicionar recurso associado ao script ocf → linbit para monitoramento dos hosts
# pcs -f drbd_cfg resource create WebData ocf:linbit:drbd \
         drbd_resource=wwwdata op monitor interval=60s

. Adicionar recurso para alteração master/slave do DRBD
# pcs -f drbd_cfg resource master WebDataClone WebData \
         master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 \
         notify=true

. Verificar as configurações adicionadas e empurrar as configurações para alteração efetiva
# pcs -f drbd_cfg resource show
# pcs cluster cib-push drbd_cfg

. Verificar status geral
# pcs status
  • Adicionar recurso no Pacemaker para montagem automática do sistema de arquivos, no nó primário e em caso de pane, montar o sistema de arquivos no nó que anteriormente era o slave.
. Criar novo arquivo de configuração a partir do cluster em funcionamento
# pcs cluster cib fs_cfg

. Cria o recurso de montagem do sistema de arquivos
# pcs -f fs_cfg resource create WebFS Filesystem \
         device="/dev/drbd1" directory="/var/www/html" fstype="xfs"

. Define que o sistema de arquivos será montado no mesmo nó que tem o resurso WebDataClone como MASTER
# pcs -f fs_cfg constraint colocation add WebFS with WebDataClone INFINITY with-rsc-role=Master

. Define a ordem de inicialização, primeiro o WebDataClone e depois o WebFS(Sistema de arquivos)
# pcs -f fs_cfg constraint order promote WebDataClone then start WebFS

. Ativar as configurações feitas:
# pcs cluster cib-push fs_cfg

cLVM

cLVM é uma extensão de cluster para o padrão LVM2, permitindo que o LVM2 possa ser usado de forma segura em storages compartilhados. As bibliotecas de travas (locking) do LVM2, assim como o daemon clvmd dependem do cluster CMAN e do DLM Lock Manager.

  • Requerimentos;
    • Se somente um nó do cluster requer o acesso a um dispositivo de armazenamento, então não é necessário o CLVM
    • Se mais de um nó no cluster requer acesso ao dispositivo de armazenamento, o qual é compartilhado entre os nós ativos, é necessário o uso do CLVM. O CLVM permite que um usuário configure os volumes lógicos em armazenamento compartilhado, bloqueando acesso ao armazenamento físico enquanto um volume lógico está sendo configurado, e usa os serviços de bloqueio em cluster para gerenciar o armazenamento compartilhado.
  • O Daemon clvmd: Roda em cada computador de cluster e distribui as atualizações dos metadados do LVM em um cluster, apresentando a cada computador do cluster a mesma visão dos volumes lógicos.
  • Para instalação do cLVM, no RH-7 é necessário:
. Instalar o pacote
# yum -y install lvm2-cluster

. Habilitar a configuração no LVM para trabalhar em cluster:
# lvmconf  --enable-cluster
  • O procedimento de criação de volumes LVM em um cluster é idêntico a criação de volumes em uma máquina local.

Integration of cLVM with Pacemaker

A integração do cLVM com o pacemaker se dá na medida em que é necessário, por exemplo, o uso de um sistema de arquivos de uso compartilhado em cluster, como o gfs2 por exemplo. Para ativação, é necessário, após a instalação do cLVM, criar o recurso correspondente no pacemaker, seguido de sua ordem de inicialização.

  • Configurar o Fencing Stonith para o ISCSI
# pcs stonith create scsi-shooter fence_scsi devices=/dev/disk/by-id/????? meta provides=unfencing 

# pcs property set no-quorum-policy=freeze 


  • Configurar os recursos do DLM e cLVM
. Criação do recurso referente ao DLM, aplicativo de gerenciamento de trava do cLVM
# pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence clone interleave=true ordered=true 

. Criação de recurso referente a inicialização do CLVM
# pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence clone interleave=true ordered=true 

. Ordem de inicialização, primeiro o mecanismo de trava, seguido pelo cLVM
# pcs constraint order start dlm-clone then clvmd-clone 

. Fixar a inicialização dos serviços em um mesmo servidor
# pcs constraint colocation add clvmd-clone with dlm-clone 
  • É necessário o uso de um sistema de arquivos com suporte a Cluster, exemplo de uso com gfs2
******** Colocar no GFS c/ Pacemaker***************
[root@node01 ~]# pvcreate /dev/sdb1

Physical volume "/dev/sdb1" successfully created
# create cluster volume group

[root@node01 ~]# vgcreate -cy vg_cluster /dev/sdb1

Clustered volume group "vg_cluster" successfully created
[root@node01 ~]# lvcreate -l100%FREE -n lv_cluster vg_cluster

Logical volume "lv_cluster" created.
[root@node01 ~]# mkfs.gfs2 -p lock_dlm -t ha_cluster:gfs2 -j 2 /dev/vg_cluster/lv_cluster 

# pcs resource create fs_gfs2 Filesystem \
device="/dev/vg_cluster/lv_cluster" directory="/mnt" fstype="gfs2" \
options="noatime,nodiratime" op monitor interval=10s on-fail=fence clone interleave=true 

# pcs constraint order start clvmd-clone then fs_gfs2-clone 

# pcs constraint colocation add fs_gfs2-clone with clvmd-clone 

Com estas configurações, o gerenciador de cluster Pacemaker irá monitorar os nós, com a falha de algum deles, ele irá finalizar a conexão do mesmo no dispositivo ISCSI(fencing), em seguida vai alterar o sistema de arquivos GFS do outro nó para Master e na sequencia montá-lo com opção de escrita.

335.2_Clustered_File_Systems

Objetivos

Peso: 3

Description: Candidates should know how to install, maintain and troubleshoot installations using GFS2 and OCFS2. This includes integration with Pacemaker as well as awareness of other clustered filesystems available in a Linux environment. Key Knowledge Areas:

   Understand the principles of cluster file systems
   Create, maintain and troubleshoot GFS2 file systems in a cluster
   Create, maintain and troubleshoot OCFS2 file systems in a cluster
   Integration of GFS2 and OCFS2 with Pacemaker
   Awareness of the O2CB cluster stack
   Awareness of other commonly used clustered file systems

Terms and Utilities:

   Distributed Lock Manager (DLM)
   mkfs.gfs2
   mount.gfs2
   fsck.gfs2
   gfs2_grow
   gfs2_edit
   gfs2_jadd
   mkfs.ocfs2
   mount.ocfs2
   fsck.ocfs2
   tunefs.ocfs2
   mounted.ocfs2
   o2info
   o2image
   CephFS
   GlusterFS
   AFS

Understand the principles of cluster file systems

A utilização de clusters com storage compartilhado, no qual mais de um nó precisa acessar o mesmo dispositivo, ou a mesma unidade lógica, um cluster do modo Ativo/passivo que preconiza escrita/leitura ou mesmo um cluster do tipo Ativo/Ativo que pode levar a uma configuração no storage de escrita/escrita, necessitam de um mecanismo de controle e travamento de modificação no disco. Um dos mecanismos que cumpre esta função é o DLM ou Distributed Lock Manager.

  • Localmente os Sistemas operacionais utilizam o Lock Manager para organizar e publicar o acesso aos recursos. O Distributed Lock Manager é executado em cada Nó em um cluster, com uma cópia idêntica de todo banco de dados de bloqueio do cluster. Desta forma um Distributed Lock Manager (DLM) provê uma forma para que softwares instalados nos nós do cluster possam sincronizar seus acessos a recursos de disco compartilhados.
  • Distributed Lock Manager (DLM)
    • No caso do RedHat, o dlm é um pacote que pode ser instalado caso necessário, seu nome é dlm. Ele fica instalado como um serviço sob o nome dlm.service, por fim existem alguns comandos para interação com o dlm. Ele gera um modulo para carregamento também chamado dlm.
/usr/sbin/dlm_controld
/usr/sbin/dlm_stonith
/usr/sbin/dlm_tool
    • E um arquivo de configuração
/etc/sysconfig/dlm
  • Os sistemas de arquivos mais comuns para uso em cluster, como o GFS2 e o OCFS2 utilizam o DLM para gerenciamento de acesso compartilhado aos arquivos.

Create, maintain and troubleshoot GFS2 file systems in a cluster

O GFS2 ou Global File System 2, é um sistema de arquivos para discos compartilhados em cluster de computadores Linux. o GFS2 difere de sistemas de arquivos distribuidos (como o GlusterFS por exemplo) porque permite a todos os Nós acesso direto concorrente ao mesmo "block storage" compartilhado. O GFS2 também pode ser usado como um sistema de arquivos local.

  • Características do GFS2:
    • O GFS2 utiliza um gerenciador de travas chamado glock que utiliza "por baixo" o DLM para gerenciamento de trava (lock manager).
    • Suporta journaling similar ao EXT3
    • Desenvolvimento principal mantido pela RedHat
  • Pré requisitos: Para o funcionamento do GFS em cluster, deve-se estar com o cluster configurado, para a correta troca de informações de gerenciamento de trava entre os nós. Abaixo exemplo de pré-configuração em um RH-7.
. Verificar se cluster esta OK
# pcs cluster status
# pcs cluster corosync

. Instalar pacotes do cLVM e GFS
# yum install gfs2-utils lvm2-cluster

. Ter um dispositivo de armazenamento compartilhado entre o nós (iscsi por exemplo) e verificar a situação do mesmo
# iscsiadm -m session -P 3
  • Criando o sistema de arquivos:

Usar os comandos mkfs.gfs2 ou mkfs -t gfs2

# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

Onde:
. -p → Protocolo de locking. Para cluster usar lock_dlm
. -t → Nome da tabela lock, no formato: ClusterName:FSName (ClusterName conforme configurado no cluster)
. -j → Numero de Journals. É necessário no mínimo 1 para cada nó do cluster que irá montar o sistema de arquivos
. Dispositivo 
  • Montando o GFS2

A montagem do sistema de arquivos, caso a configuração anterior esteja OK é simples.

# mount <dispositivo> <destino>

Existem algumas opções de montagem. Se recomenda utilizar as opções "noatime" e "nodiratime"
para que não ocorra muita atualização no sistema de arquivos melhorando assim a performance.

# mount -o noatime,nodiratime -t gfs2 /dev/vgteste/lvteste /mnt/gfs

Para desmontar:

# umount <dispositivo>


  • Aumentando (growing) o GFS2:

Para estender o espaço ocupado em um dispositivo, basta executar em apenas um dos nós do cluster o comando gfs_grow.

. (opcional) No LVM definir mais espaço para o dispositivo
# lvextend -L+200M /dev/vgteste/lvteste

. Estendendo o sistema de arquivos
# gfs_grow <ponto de montagem>
  • Adicionar Journals ao filesystem já criado: Para isso é usado o comando gfs2_jadd no formato:

# gfs2_jadd <opções> <device>
Onde em opções as mais utilizadas são:

 -J <size> → Tamanho dos journals, em megabytes
 -j <number> → Número de journals
  • O utilitário avançado de linha de comando para GFS2 se chama gfs2_edit. Com ele é possível exibir informações de baixo nível de um dispositivo de bloco sobre gfs2.
. Um dos usos é mostrar as informações de índice do journal
# gfs2_edit -p jindex <dispositivo>

. Exibe informações do diretório raiz do dispositivo
# gfs2_edit -p root /dev/mapper/vgteste-lvteste
  • Em casos de erro:
    • Analisar o log /var/log/messages


Create, maintain and troubleshoot OCFS2 file systems in a cluster

OCFS2 também chamado de Oracle Cluster File System, é um sistema de arquivos para discos compartilhados, desenvolvido pela Oracle. Utiliza DLM para controle de versionamentos em acesso simultâneo.

  • Algumas características:
    • Uso e Journaling
    • Quota para usuários e grupos
    • Tamanhos variáveis para tamanho de blocos e clusters
  • Principais comandos:
    • mkfs.ocfs2: Usado para criar o sistema de arquivos no dispositivo. Nele são setadas as informações de cluster.
# mkfs.ocfs2 --cluster-stack PCMK --cluster-name clusteroracle -N 2 /dev/vgteste/lvoracle
Onde:
. -cluster-stack: Indica a pilha de cluster que será utilizada. O padrão é O2CB 
. --cluster-name: Nome do cluster
. -N: Numeros de nós que farão o acesso ao dispositivo 

Obs: Se não for utilizada as opções acima, será criado o sistema de arquivos com a stack padrão o2cb
    • mount.ocfs2: Faz a montagem do sistema de arquivos no nó
    • fsck.ocfs2: Faz a checagem do sistema de arquivos, em busca de erros.
    • tunefs.ocfs2: É usado para ajustar parametros do sistema de arquivos OCFS2 no disco.
. Aumentar o espaço de um disco
# tunefs.ocfs2 -S <device>

. Aumentar o numero de Nodes que terão acesso ao sistema de arquivos
# tunefs.ocfs2 -N

. Atualiza informações do cluster no disco
# tunefs.ocfs2 --update-cluster-stack <device>
    • mounted.ocfs2: É usado para detectar volumes OCFS2 no sistema.
. Lista informações do sistema de arquivos, nós vinculados ao dispositivo e a pilha (stack) do cluster.
# mounted.ocfs2 -f
    • o2info: Utilizado para exibir informações do dispositivo em sistema de arquivo ocfs.
. Exibe informações do volume
# o2info --volinfo <device>
    • o2image: Copia ou restaura meta-data do sistema de arquivo OCFS de ou para um arquivo. isto pode ser utilizado para debugar problemas como corrupção de disco.
. Gera arquivo de backup com meta-dados do dispositivo
# o2image /dev/sda1 sda1.out

. Restaura Meta-dados para disco
# o2image -I /dev/sda1 sda1.out
  • Em caso de erros:
    • DLM Debuggin
# cat /sys/kernel/debug/o2dlm/????/dlm_state

Integration of GFS2 and OCFS2 with Pacemaker

  • Para integrar o GFS2 ao Pacemaker, basta criar os recursos de carregamento dos controles de bloqueio DLM, CLVM e montagem do sistema de arquivos, conforme segue:
. Criar o recurso para carregamento do DLM do tipo Clone (nos dois nós)
# pcs resource create dlm ocf:pacemaker:controld \
    op monitor interval=30s on-fail=fence clone interleave=true ordered=true

. Criar o recurso para carregamento do cLVM do tipo Clone (nos dois nós)
# pcs resource create clvmd ocf:heartbeat:clvm \
   op monitor interval=30s on-fail=fence clone interleave=true ordered=true

. Ajustar a ordem de inicialização e a colocação do nó de ambos os recursos
# pcs constraint order start dlm-clone then clvmd-clone
# pcs constraint colocation add clvmd-clone with dlm-clone

. Setar configuração de quorum. A partição sem quorum não fará nada, já que o GFS2 necessita do Quorum para operar
# pcs property set no-quorum-policy=freeze

. Criar recurso para montagem do sistema de arquivos gfs2:
# pcs resource create gfs2_res Filesystem device="/dev/vg_data/lv_test" \
    directory="/mnt" fstype="gfs2" options="noatime,nodiratime" \
    op monitor interval=10s on-fail=fence clone interleave=true

. Configurar a ordem de inicialização, para execução do filesystem após o CLMVD
# pcs constraint order start clvmd-clone then gfs2_res-clone

# pcs constraint colocation add gfs2_res-clone with clvmd-clone
  • Para integrar o OCFS2 ao Pacemaker
    • Segue a mesma lógica do gfs2, com a observação de alguns detalhes:
      • Se a utilização do OCFS2 for utilizada, usando a pilha do cluster Pacemaker, isto deverá estar implícito no momento da criação do sistema de arquivos, setando os parametros correspondentes.
      • No Oracle linux Versão 7, não é aconselhado o uso com LVM (cLVM)
      • Se for utilizada a pilha de cluster o2cb para cluster do file-system, um recurso o2cb deverá ser criado no pacemaker.
. Exemplo de criação de ocfs2 no pacemaker utilizando Debian com "crmsh" e stack "o2cb"
---
primitive p_dlm_controld ocf:pacemaker:controld \
  op start interval="0" timeout="90" \
  op stop interval="0" timeout="100" \
  op monitor interval="10"
primitive p_o2cb ocf:pacemaker:o2cb \
  op start interval="0" timeout="90" \
  op stop interval="0" timeout="100" \
  op monitor interval="10"
primitive p_fs_ocfs2 ocf:heartbeat:Filesystem \
  params device="<your device path>" \
    directory="<your mount point>" \
    fstype="ocfs2" \
  meta target-role=Stopped \
  op monitor interval="10"
group g_ocfs2 p_dlm_controld p_o2cb p_fs_ocfs2
clone cl_ocfs2 g_ocfs2 \
  meta interleave="true"
---


Awareness of the O2CB cluster stack

O O2CB é uma camada de pilha de cluster responsável pelo gerenciamento do sistema de arquivos Ocfs2 em cluster. Ele pode ser usado em conjunto com o Pacemaker no tratamento deste sistema de arquivos. Utilizado por exemplo no Oracle Linux

  • O Gerenciamento do o2cb é realizado através dos comandos abaixo:
    • o2cb; Responsável pela administração do cluster ocfs2.
. Criar um cluster
# o2cb add-cluster ocfscluster

. Adicionar membros ao cluster
# o2cb add-node ocfscluster oracle01 --ip 192.168.90.156

. Configurar a inicialização do cluster
# /etc/init.d/o2cb configure

. Status do cluster
# o2cb cluster-status

Este comando cria e gerencia as configurações que ficam armazenadas em: /etc/ocfs2/cluster.conf

Awareness of other commonly used clustered file systems

CephFS

A Arquitetura Ceph provê serviços de Storage Objects e/ou Block Devices (Dispositivos de armazenamentos para VM) para plataformas Cloud. É possível utilizar o Ceph Filesystem para armazenamento de arquivos e diretórios. A estrutura Ceph é conhecida como Ceph Storage Cluster e requer ao menos um Ceph Monitor, para monitorar os nós do cluster e no mínimo dois Ceph OSD, que são os armazenadores de dados, onde cada dispositivo como disco ou volume Raid precisa de um OSD.

  • O Ceph armazena os dados de um cliente como objetos dentro de pools de armazenamento. Usando o algoritmo CRUSH, o Ceph calcula qual grupo de posicionamento ( placement group) deve conter o objeto, e calcula quais Ceph OSD Daemon devem armazenar o grupo de posicionamento. O algoritmo CRUSH permite ao Ceph Storage Cluster escalabilidade, balanceamento e recuperação dinâmica.
  • O CephFS é um sistema de arquivos para ser usado com o Ceph Storage Cluster. O sistema de arquivos Ceph usa o mesmo sistema Ceph Storage Cluster.
  • O uso do Ceph Filesystem requer ao menos um Ceph Metadata Server no Ceph Storage Cluster.
  • Com o cluster Ceph ativo e funcional, a partir de um cliente de rede com acesso, pode-se criar e gerenciar um sistema de arquivo Ceph.
    • Para criação do sistemas de arquivo Ceph é necessário dois pools RADOS (reliable autonomic distributed object store), um para dados e outro para metadados.
# ceph osd pool create cephfs_data <pg_num>
# ceph osd pool create cephfs_metadata <pg_num>
    • Depois de criar os pools, deve-se habilitar o sistema de arquivos
# ceph fs new <fs_name> <metadata> <data>
    • Listar informações do sistema de arquivos
. Exibe nome dos pools
# ceph fs ls

. Exibe status do sistema de arquivos
# ceph mds stat
    • Para montar o sistema de arquivos Ceph
sudo mount -t ceph 192.168.0.1:6789:/ /mnt/mycephfs -o name=admin,secret=SENHA

GlusterFS

O 'GlusterFS é um sistema de arquivos distribuidos, definido para ser usado em user space.

  • Este sistema de arquivos elimina a necessidade de metadata
  • Adaptável para aumento e redução do tamanho dos dados
  • Os dados são armazenados em qualquer sistema de arquivos nativo, como ext4, xfs, etc.


  • Baseado em componentes de cliente/servidor:
    • Servidor: Roda o daemon glusted para gerenciar o GlusterFS
    • Cliente: Por padrão Conecta ao servidor por um protocolo específico sobre tcp/ip.
  • Definições e conceitos:
    • Brick: Qualquer diretório compartilhado através do trusted storage pool.
    • Trusted storage pool: Uma coleção de arquivos/diretórios compartilhados
    • Block Storage: Eles são dispositivos através dos quais os dados são movidos entre os sistemas. Sob a forma de blocos.
    • Volumes: É uma coleção lógica de bricks. Todas as operações são baseadas em diferentes tipos de volumes criados pelo usuário.
  • Tipos de volumes:
    • Distributed Volume: Os arquivos completos são distribuídos entre os bricks, sem contingência
    • Replicated Volume: Os arquivos completos são replicados em todos os bricks, ou seja cada arquivo tem sua cópia em cada volume (como uma Raid-1)
    • Striped Volume: O mesmo arquivo é dividido entre os bricks (como uma Raid-0).
    • Distributed-Replicated volume: Os arquivos são divididos entre volumes. Em cada volume os arquivos são replicados entre os bricks
  • Configurando um servidor GlusterFS
. Configurar o Trusted storage pool (Cluster de storage com relação de confiança)
# gluster peer probe server2

. Criar a configuração de volume
# gluster volume create gv0 replica 2 server1:/data/brick1/gv0 server2:/data/brick1/gv0

. Iniciar o volume
# gluster volume start gv0

. Montar o volume criado
# mount -t glusterfs server1:/gv0 /mnt

.. Informações sobre o volume;
# gluster volume info

# gluster volume status

... Mostra chamadas pendentes a um volume:
# gluster volume status NOME_VOLUME callpool
  • Arquivo de configuração: em /etc/glusterfs/glusterd.vol

AFS

AFS também conhecido como Andrew File System é um sistema de arquivos distribuído que utiliza um conjunto de servidores de confiança para apresentar de forma transparente um ambiente de arquivos e diretórios compartilhados para o cliente. As maiores implementações do AFS são: Transarc (IBM), OpenAFS e ARLA. o AFS utiliza um modelo de locking chamado Weak Consistency, quando um arquivo do sistema compartilhado esta em uso por algum cliente, ele fica travado para modificações. Quando outro nó tenta salvar alguma alteração, ela é salva em uma cache local, apenas após a liberação do uso do arquivo, a modificação é atualizada no arquivo em rede. Esta característica faz com que o AFS não seja indicado para trabalhar com arquivos de banco de dados compartilhado.

  • Na utilização do AFS, ele cria os sites de acesso sob o diretório /afs que é um ponto de montagem especial.
    • cell: É o dominio administrativo
    • sites: São os agrupamentos de um ou mais cells