-
Notifications
You must be signed in to change notification settings - Fork 2
335_High_Availability_Cluster_Storage
João Batista Correa Junior edited this page Jan 18, 2023
·
1 revision
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
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.
- Three-way replication:
- 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:
- 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></recurso> / .
- 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 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.
- Fontes:
- 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.
- Storage: O DRBD pode ser configurado apontando para um dos seguintes dispositivos:
- Configuração dos recursos (resources):
- Configuração básica e mínima do arquivo global_common.conf:
# 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:
# 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 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:
. 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:
- 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.
- Fontes:
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:
. 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:
- 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:
----
resource <resource> {
disk {
on-io-error call-local-io-error;
...
}
local-io-error "/usr/lib/drbd/notify-io-error.sh;
...
}
----
- Fontes:
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:
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
- 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.
- Exemplos:
. 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:
. Criando meta-dados no device # drbdmeta /dev/sda1 create-md
- Fontes:
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
. 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.
. 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
- Fontes:
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:
. 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.
- Fontes:
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 property set no-quorum-policy=freeze
- Configurar os recursos do DLM e cLVM
. 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
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.
- Fontes:
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
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.
- Fonte: https://en.wikipedia.org/wiki/Distributed_lock_manager
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.
. 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:
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
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:
. 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:
-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.
. 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
- Fontes:
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.
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 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.
. Restaura Meta-dados para disco # o2image -I /dev/sda1 sda1.out
- Em caso de erros:
- DLM Debuggin
# cat /sys/kernel/debug/o2dlm/????/dlm_state
- Fontes:
- Wiki: https://en.wikipedia.org/wiki/OCFS2
- Oracle linux: http://docs.oracle.com/cd/E52668_01/E54669/html/ol7-about-ocfs2.html
- OpenSuse 12 - Gerenciando: https://www.suse.com/documentation/sle-ha-12/book_sleha/data/cha_ha_ocfs2.html
- OCFS2 no Debian: https://mihaiush.wordpress.com/2013/06/10/debian-wheezy-drbd-primaryprimary-corosync-clvm-ocfs2/
- 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 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.
- Segue a mesma lógica do gfs2, com a observação de alguns detalhes:
. 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"
---
- Fontes:
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.
. 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
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 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
- Fontes:
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
. 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
- Fontes:
- https://en.wikipedia.org/wiki/GlusterFS
- http://gluster.readthedocs.org/en/latest/Quick-Start-Guide/Quickstart/
- Como fazer-CentOs7: http://www.tecmint.com/introduction-to-glusterfs-file-system-and-installation-on-rhelcentos-and-fedora/
- Como fazer: https://www.digitalocean.com/community/tutorials/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers
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
- Fontes:
- https://en.wikipedia.org/wiki/Andrew_File_System
- https://www.openafs.org/