Red Hat Cluster Suite: Configurando e Administrando um Cluster | ||
---|---|---|
Anterior | Capítulo 1. Instalação de Hardware e Configuração do Sistema Operacional | Próxima |
Após instalar o Red Hat Enterprise Linux, configure os componentes de hardware do cluster e verifique a instalação para garantir que os membros reconheçam todos os dispositivos conectados. Note que os passos exatos para a configuração do hardware dependem do tipo de configuração. Consulte a Seção 1.1 para mais informações sobre configurações de cluster.
Para configurar o hardware do cluster siga estes passos:
Desligue os membros e desconecte-os de suas fontes de energia.
Configure os canais Ethernet ligados, se for o caso. Consulte a Seção 1.4.1 para mais informações.
Quando usar comutadores de energia, defina os comutadores e conecte cada membro a um comutador de energia. Consulte a Seção 1.4.2 para mais informações.
Além disso, é recomendado conectar cada comutador de energia (ou o cabo de força de cada membro, se não estiver usando comutadores) a um sistema UPS diferente. Consulte a Seção 1.4.3 para mais informações sobre o uso de sistemas UPS opcionais.
Configure o armazenamento de disco compartihado de acordo com as instruções do fabricante e conecte os membros à unidade de armazenamento externa. Consulte a Seção 1.4.4 para mais informações.
Também é recomendado conectar a unidade de armazenamento a sistemas UPS redundantes. Consulte a Seção 1.4.3 para mais informações sobre o uso de sistemas UPS opcionais.
Ligue o hardware à energia e inicialize cada membro do cluster. Durante o processo de inicialização, insira a funcionalidade do BIOS para modificar a configuração do membro, conforme segue:
Certifique-se de que o número de identificação SCSI usado pelo HBA é único no canal SCSI ao qual está anexo. Consulte a Seção B.5 para mais informações sobre a execução desta tarefa.
Habilite ou desabilite a terminação onboard de cada adaptador de canal, conforme requisitado pela configuração do armazenamento. Consulte a Seção 1.4.4 e a Seção B.3 para mais informações.
Habilite o membro a inicializar automaticamente quando estiver ligado.
Saia do utilitário BIOS e continue a inicializar cada membro. Examine as mensagens de startup para verificar se o kernel do Red Hat Enterprise Linux foi configurado e pode reconhecer todo o conjunto de discos compartilhados. Use o comando dmesg para exibir as mensagens de startup do console. Consulte a Seção 1.3.3 para mais informações sobre o uso do comando dmesg.
Verifique se os membros podem comunicar-se através de cada conexão Ethernet ponto-a-ponto, usando o comando ping para enviar pacotes através de cada interface de rede.
Configure as partições compartilhadas do cluster no armazenamento de disco compartilhado. Consulte a Seção 1.4.4.3 para mais informações.
A ligação de canais Ethernet (Ethernet channel bonding) em um sistema cluster com no-single-point-of-failure permite uma conexão de rede tolerante a falhas, combinando dois dispositivos Ethernet em um dispositivo virtual. A interface resultante da ligação de canais assegura que, caso um dispositivo Ethernet falhe, o outro tornar-se ativo. Este tipo de ligação de canal, chamada de política de backup ativo, permite a conexão de ambos dispositivos a um comutador ou pode permitir que cada dispositivo Ethernet se conecte a hubs ou comutadores separados, o que elimina o single point of failure no hub/comutador de rede.
A ligação de canais (channel bonding) requer que cada membro do cluster tenha dois dispositivos Ethernet instalados. Quando é carregado, o módulo de ligação usa o endereço MAC do primeiro dispositivo de rede escravizado e atribui este endereço MAC ao outro dispositivo de rede, se o primeiro falhar na detecção da ligação.
Para configurar dois dispositivos de rede para a ligação de canais (channel bonding), execute o seguinte:
Crie um dispositivo de ligação em /etc/modules.conf. Por exemplo:
alias bond0 bonding options bonding miimon=100 mode=1 |
Isto carrega o dispositivo de ligação com o nome de interface bond0, assim como passa opções ao driver de ligação para configurá-lo como um dispositivo mestre de backup ativo para as interfaces de rede escravizadas.
Edite o arquivo de configuração /etc/sysconfig/network-scripts/ifcfg-ethX para ambas, eth0 e eth1, para que os arquivos exibam conteúdo idêntico. Por exemplo:
DEVICE=ethX USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none |
Isto tornará a ethX (substitua X pelo número atribuído ao dispositivo Ethernet) escrava do dispositivo mestre bond0.
Crie um script de rede para o dispositivo de ligação (ex.: /etc/sysconfig/network-scripts/ifcfg-bond0), que deve se parecer com o seguinte exemplo:
DEVICE=bond0 USERCTL=no ONBOOT=yes BROADCAST=192.168.1.255 NETWORK=192.168.1.0 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 IPADDR=192.168.1.10 |
Reinicialize o sistema para as alterações tomarem efeito. Alternativamente, carregue manualmente o dispositivo de ligação e reinicie a rede. Por exemplo:
/sbin/insmod /lib/modules/`uname -r`/kernel/drivers/net/bonding/bonding.o \ miimon=100 mode=1 |
/sbin/service network restart |
Os comutadores de energia possibilitam que um membro assuma os serviços do outro antes que reinicie seus serviços como parte do processo de queda. A habilidade de desabilitar remotamente um membro assegura que a integridade dos dados é mantida sob quaisquer condições de falha. É recomendado que ambientes de produção utilizem comutadores de enrgia ou timers watchdog na configuração do cluster. Somente ambientes de desenvolvimento (teste) devem utilizar a configuração sem comutadores de energia. Consulte a Seção 1.1.3 para uma descrição dos vários tipos de comutadores de energia. Note que dentro desta seção, o termo geral "comutador de energia" também inclui os timers watchdog.
Em uma configuração de cluster que utiliza comutadores de energia físicos, o cabo de força de cada membro é conectado ao comutador de energia através de uma conexão serial ou de rede (dependendo do tipo de comutador). Quando a queda ocorrer, um membro pode usar esta conexão para assumir os serviços de outro membro antes de reiniciar os serviços.
Comutadores de energia protegem contra a corrupção dos dados se um membro não responsivo (ou pendente) torna-se responsivo após a queda dos serviços, e atribui I/O para um disco que também está recebendo I/O de outro membro. Além disso, se um daemon quorum falha em um membro, o membro não está mais apto a monitorar as partições compartilhadas do cluster. Se não estiver usando um comutador de energia ou timer watchdog no cluster, então esta condição de erro pode resultar em serviços sendo executados em mais de um membro, o que pode causar a corrupção de dados e possivelmente queda do sistema.
É altamente recomendado usar comutadores de energia em um cluster. Entretanto, os administradores cientes dos riscos podem optar por configurar um cluster sem comutadores.
Um membro pode ficar pendente por alguns segundos se estiver fazendo swapping ou se tiver uma alta carga de trabalho. Por este motivo, é dado o tempo adequado antes de concluir que um outro membro tenha falhado (geralmente 15 segundos).
Se um membro determinar que um outro membro pendente caiu, e este cluster utilizar comutadores de energia, este membro assume os serviços do membro pendente antes de reiniciar seus serviços. Clusters configurados para usarem timers watchdog se auto inicializam sob a maioria das pendências do sistema. Isto faz com que o membro pendente seja reiniciado em um estado limpo e evita que este atribua I/O e corrompa dados de serviços.
Membros pendentes se auto reinicializam devido a um firing do watchdog, a uma falha ao enviar pacotes heartbeat ou — no caso de um membro não ter um comutador de energia físico — devido à perda de status do quorum.
Membros pendentes podem ser reinicializados por outros membros se estiverem conectados a um comutador de energia. Se o membro pendente nunca se tornar responsivo e não houver comutadores de energia em uso, então é necessário reinicializá-lo manualmente.
Quando usados, os comutadores de energia devem ser configurados de acordo com as instruções do fabricante. No entanto, algumas tarefas específicas do cluster podem requerer o uso de um comutador de energia. Consulte a Seção B.1 para informações detalhadas sobre comutadores de energia (inclusive informações sobre timers watchdog). Tome nota de todos os avisos ou atributos funcionais de comutadores de energia específicos. Note que as informações específicas do cluster oferecidas neste manual substituem as informações do fabricante.
Ao cabear comutadores de energia, tome cuidado especial para assegurar que cada cabo esteja plugado na saída apropriada. Isto é crucial, pois não há meios independentes para que o software possa verificar o cabeamento correto. Se o cabeamento falhar, pode fazer com que o membro incorreto assuma os serviços de outro, ou fazer com que um membro conclua de maneira errônea que assumiu os serviços de outro membro do cluster com sucesso.
Após configurar os comutadores de energia, execute estas tarefas para conectá-los aos membros:
Conecte o cabo de força de cada membro a um comutador de energia.
Conecte cada membro ao comutador de energia. O cabo usado para a conexão depende do tipo de comutador de energia. Comutadores de energia seriais anexos usam cabos de modem null, enquanto comutadores de energia anexos à rede requerem um cabo Ethernet patch.
Conecte o cabo de força de cada comutador de energia a uma fonte de energia. É recomendado conectar cada comutador de energia a um sistema UPS diferente. Consulte a Seção 1.4.3 para mais informações.
Após instalar o software do cluster, teste os comutadores de energia para garantir que cada membro possa assumir os serviços do outro (power cycle) antes de inicializar o cluster. Consulte a Seção 2.11.2 para obter mais informações.
O fornecimento ininterrupto de energia (uninterruptible power supplies - UPS) provém uma fonte de energia de alta disponibilidade. O ideal é usar uma solução redundante que incorpore sistemas UPS múltiplos (um por servidor). Para a máxima tolerância a falhas, é possível incorporar dois sistemas UPS por servidor, assim como Comutadores de Transferência Automática APC (Automatic Transfer Switches) para gerenciar a energia e o desligamento do servidor. Ambas soluções dependem somente do nível de disponibilidade desejado.
Não é recomendado usar uma grande infra-estrutura UPS simples como a única fonte de energia do cluster. Uma solução UPS dedicada ao cluster é mais flexível em termos de administração e disponibilidade.
Um sistema UPS completo deve poder oferecer a voltagem e a corrente adequadas por um período de tempo prolongado. Enquanto não há um único UPS que atenda a todos os requisitos de energia, pode-se elaborar uma solução customizada para atender uma determinada configuração.
Se o sub-sistema de armazenamento de disco do cluster tem duas fontes de energia com cabos de força separados, configure dois sistemas UPS. Então, conecte um comutador de energia (ou o cabo de força de um membro, se não há comutadores) e o cabo de força de um dos subs-sistemas de armazenamento a cada sistema UPS. A configuração de um sistema UPS redundante é exibida na Figura 1-3.
Uma configuração alternativa de energia redundante é conectar ambos comutadores de energia (ou ambos cabos de força dos membros) e o sub-sistema de armazenamento do disco ao mesmo sistema UPS. Esta é a configuração de custo mais baixo e oferece alguma proteção contra falha de energia. Entretanto, se ocorrer uma queda de energia, o sistema UPS torna-se um possível ponto único de falha. Além disso, um sistema UPS pode não ser capaz de prover a energia suficiente para todos os dispositivos anexos por um período de tempo adequado. A Figura 1-4 mostra uma configuração com um único sistema UPS.
Muitos sistemas UPS já vêm da fábrica com aplicações do Red Hat Enterprise Linux que monitoram o estado operacional do sistema UPS através de uma conexão de porta serial. Se a energia da bateria está baixa, o software de monitoração inicia um desligamento correto do sistema. Conforme isso ocorre, o software do cluster é parado apropriadamente porque é controlado por um script de nível de execução SysV (/etc/rc.d/init.d/clumanager, por exemplo).
Consulte a documentação do UPS fornecida pelo fabricante para informações detalhadas sobre a instalação.
Em um cluster, o armazenamento de disco compartilhado é usado para guardar dados dos serviços e das duas partições (principal e shadow), que armazenam informações do estado do cluster. Como este armazenamento deve estar disponível a todos os membros, não pode estar localizado em nenhum disco que dependa da disponibilidade de nenhum membro. Consulte a documentação do fabricante para informações detalhadas sobre o produto e sua instalação.
Há alguns fatores a considerar ao configurar o armazenamento de disco compartilhado em um cluster:
RAID externo
É altamente recomendado usar o RAID 1 (mirroring) para tornar os dados dos serviços e as partições compartilhadas do cluster altamente disponíveis. Opcionalmente, também é possível aplicar a paridade de RAID para alta disponibilidade. Não use o RAID 0 (striping) sozinho para partições compartilhadas porque isto reduz a disponibilidade de armazenamento.
Configurações de SCSI Multi-iniciadores
Configurações de SCSI Multi-iniciadores não são suportadas devido à dificuldade em obter a terminação apropriada do canal.
O nome do dispositivo Red Hat Enterprise Linux e o nome de cada dispositivo de armazenamento compartilhado deve ser o mesmo em cada membro. Por exemplo: um dispositivo chamado /dev/sdc de um dos membros deve ser nomeado /dev/sdc nos outros membros do cluster. Usar hardware idêntico em todos os membros geralmente garante que estes dispositivos tenham o mesmo nome.
Uma partição do disco pode ser usada por apenas um serviço do cluster.
Não inclua nenhum sistema de arquivo usado em um serviço do cluster nos arquivos locais /etc/fstab do membro, porque o software do cluster deve controlar a montagem e desmontagem de sistemas de arquivo do serviço.
Para o desempenho total de sistemas de arquivo compartilhados, especifique um bloco com tamanho 4 KB com a opção -b para mke2fs. Um bloco de tamanho menor pode causar fsck com tempos longos. Consulte a Seção 1.4.4.6.
A lista a seguir detalha os requisitos do SCSI paralelo, que devem ser seguidos quando canais SCSI paralelos são aplicados em um ambiente de cluster.
Os canais SCSI devem ser terminados em cada ponta e devem respeitar os requisitos de comprimento e hot plugging.
Os dispositivos (discos, adaptadores de canal e controladores RAID) de um canal SCSI devem ter um único número de identificação SCSI.
Consulte a Seção B.2 para mais informações.
É altamente recomendado conectar a unidade de armazenamento a sistemas UPS redundantes para uma fonte de energia de alta disponibilidade. Consulte a Seção 1.4.3 para mais informações.
Consulte a Seção 1.4.4.1 e a Seção 1.4.4.2 para mais informações sobre a configuração do armazenamento compartilhado.
Após configurar o hardware do armazenamento de disco compartilhado, particione os discos e então crie os sistemas de arquivo ou dispositivos raw nas partições. Dois dispositivos raw devem ser criados para as partições shadow e principal compartilhadas do cluster. Consulte a Seção 1.4.4.3, a Seção 1.4.4.4, a Seção 1.4.4.5 e a Seção 1.4.4.6 para mais informações.
Um canal SCSI de iniciador simples tem apenas um membro conectado a ele, e oferece a isolação da máquina e melhor desempenho que um canal de multi-iniciadores. Canais de iniciadores simples garantem que cada membro está protegido contra paradas devido à carga de trabalho, à inicialização ou ao reparo de outros membros.
Ao usar um conjunto RAID de controlador simples ou duplo, que tem portas múltiplas de máquina e ofecerece acesso simultâneo para todas as unidades lógicas compartilhadas a partir das portas da unidade de armazenamento, é possível configurar os canais SCSI de iniciador simples para conectar cada membro do cluster ao conjunto RAID. Se uma unidade lógica pode falhar de um controlador para outro, o processo deve ser transparente ao sistema operacional. Note que alguns controladores RAID restringem um conjunto de discos a um controlador ou porta específica. Nestes casos, não é possível configurar canais de iniciadores simples.
Um canal de iniciador simples deve obedecer aos requisitos descritos na Seção B.2.
Para configurar um canal SCSI de iniciador simples, é necessário o seguinte:
Habilite a terminação on-board de cada adaptador de canal da máquina.
Habilite a terminação de cada controlador RAID.
Use o cabo SCSI apropriado para conectar cada adaptador de canal da máquina à unidade de armazenamento.
A configuração da terminação do adaptador de canal é geralmente feita no utilitário BIOS do adaptador durante a inicialização do membro. Para configurar a terminação do controlador RAID, consulte a documentação do fabricante. A Figura 1-5 mostra uma configuração usando dois canais SCSI de iniciadores simples.
A Figura 1-6 mostra a terminação em um conjunto RAID de controlador simples conectada a dois canais SCSI de iniciadores simples.
A Figura 1-7 mostra a terminação em um conjunto RAID de controlador duplo conectado a dois canais SCSI de iniciadores simples.
O Fibre Channel pode ser usado tanto em configurações com iniciadores simples como com iniciadores múltiplos.
Um Fibre Channel interconnect de iniciador simples tem apenas um membro conectado a ele. Isto pode oferecer melhor isolamento da máquina e melhor desempenho que um canal de iniciador múltiplo. Interconnects de iniciadores simples garantem que cada membro esteja protegido de paradas devido à alta carga de trabalho, à inicialização ou ao reparo de outro membro.
Se estiver aplicando um conjunto RAID que tem portas múltiplas, e que oferece acesso simultâneo a todas as unidades lógicas compartilhadas a partir das portas da unidade de armazenamento, configure Fibre Channel interconnects de iniciadores simples para conectar cada membro ao conjunto RAID. Se uma unidade lógica pode falhar de um controlador para outro, o processo deve ser transparente ao sistema operacional.
A Figura 1-8 mostra um conjunto RAID de controlador simples com duas portas e os adaptadores de canal de máquina conectados diretamente ao controlador RAID, sem o uso de hubs ou comutadores Fibre Channel. Ao usar este tipo de conexão Fibre Channel de iniciador simples, seu controlador RAID deve ter uma porta separada de máquina para cada membro do cluster.
Figura 1-8. Conjunto RAID de Controlador Simples Conectado a Fibre Channel Interconnects de Iniciadores Simples
O conjunto RAID externo deve ter um canal SCSI separado para cada membro do cluster. Em clusters com mais de dois membros, conecte cada membro a um canal SCSI diferente no conjunto RAID, usando um canal SCSI de iniciador simples, conforme a Figura 1-8.
Para conectar membros múltiplos à mesma porta de máquina no conjunto RAID, use um hub ou comutador Fibre Channel. Neste caso, cada HBA é conectado ao hub ou comutador, que por sua vez é conectado à porta da máquina no controlador RAID.
Um hub ou comutador Fibre Channel também é necessário para um conjunto RAID de controlador duplo com duas portas de máquina (host ports) em cada controlador. Esta configuração é apresentada na Figura 1-9. Membros adicionais do cluster podem ser conectados ao hub ou ao comutador Fibre Channel exibido no diagrama. Alguns conjuntos RAID incluem um hub embutido para que cada porta já esteja conectada a cada um dos controladores RAID internos. Neste caso, um hub ou comutador externo adicional pode ser desnecessário.
Deve-se criar dois dispositivos raw no armazenamento de disco compartilhado para a partição compartilhada principal e partição compartilhada shadow. Cada partição compartilhada deve ter um tamanho mínimo de 10 MB. A quantidade de dados é contante em uma partição compartilhada; não aumenta ou diminiu com o passar do tempo.
As partições compartilhadas são usadas para guardar informações do estado do cluster, incluindo o seguinte:
Estados de bloqueio do cluster (lock states)
Estados de serviços (service states)
Informações de Configuração
Periodicamente, cada membro grava o estado de seus serviços no armazenamento compartilhado. Além disso, as partições compartilhadas contêm uma versão do arquivo de configuração do cluster. Isto garante que cada membro tenha uma visão em comum da configuração do cluster.
Se a partição compartilhada principal for corrompida, os membros do cluster lêem as informações da partição compartilhada shadow (ou backup) e, ao mesmo tempo, executam o reparo da partição principal. A consistência dos dados é mantida através de checksums e quaisquer inconsistências entre as partições são corrigidas automaticamente.
Se um membro não é capaz de gravar em ambas partições no momento da inicialização, não poderá se juntar ao cluster. Se um membro ativo não puder mais gravar nas duas partições, este se remove automaticamente do cluster se reinicializando (e pode ter seus serviços assumidos remotamente por um membro saudável).
Veja a seguir os requisitos das partições compartilhadas:
Ambas partições devem ter tamanho mínimo de 10 MB.
Partições compartilhadas devem ser dispositivos raw. Não podem conter sistemas de arquivo.
Partições compartilhadas podem ser usadas somente para informações de estado e configuração do cluster.
A seguir, as regras recomendadas para a configuração de partições compartilhadas:
É altamente recomendado configurar um sub-sistema RAID para o armazenamento compartilhado e usar o RAID 1 (mirroring) para criar a unidade lógica que contém as partições compartilhadas de alta disponibilidade. Opcionalmente, a paridade de RAID pode ser usada para alta disponibilidade. Não use o RAID 0 (striping) isoladamente para partições compartilhadas.
Coloque as duas partições no mesmo conjunto RAID, ou no mesmo disco se o RAID não é aplicado, pois ambas partições devem estar disponíveis para rodar o cluster.
Não coloque as partições compartilhadas em um disco que contenha dados de serviços de grande acesso. Se possível, coloque estas partições em discos que contenham dados de serviços raramente acessados.
Consulte a Seção 1.4.4.4 e a Seção 1.4.4.5 para mais informações sobre a configuração de partições compartilhadas.
Consulte a Seção 2.5 para informações sobre a edição do arquivo rawdevices, para ligar os dispositivos de caráter raw aos dispositivos em bloco cada vez que os membros inicializarem.
Após configurar o hardware do armazenamento de disco compartilhado, particione os discos para que possam ser usados no cluster. Então, crie sistemas de arquivo ou dispositivos raw nas partições. Por exemplo: deve-se criar dois dispositivos raw para as partições compartilhadas usando as regras descritas na Seção 1.4.4.3.
Use o parted para alterar uma tabela de partição de disco e divida o disco em partições. No parted, use p para exibir a tabela de partição e o comando mkpart para criar novas partições. O exemplo a seguir mostra como usar o parted para criar uma partição no disco:
Submeta o parted na janela de comandos especificando um dispositivo de disco compartilhado disponível. No prompt (parted), use o p para exibir a tabela de partição atual. O output deve se parecer com o seguinte:
Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags |
Decida o tamanho necessário de uma partição. Crie uma partição deste tamanho usando o comando mkpart no parted. Apesar do mkpart não criar um sistema de arquivo, normalmente requer um tipo de sistema de arquivo na hora da criação da partição. parted usa um intervalo do disco para determinar o tamanho da partição. Este tamanho é o espaço entre o fim e o início do intervalo dado. O exemplo a seguir mostra como criar duas partições de 20 MB cada em um disco vazio.
(parted) mkpart primary ext3 0 20 (parted) mkpart primary ext3 20 40 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary |
Quando forem necessárias mais de quatro partições em um único disco, deve-se criar uma partição extendida. O mkpart também executa esta tarefa. Neste caso, não é necessário especificar um tipo de sistema de arquivo.
![]() | Nota |
---|---|
Pode-se criar apenas uma partição extendida, e esta deve ser uma das quatro partições principais. |
(parted) mkpart extended 40 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended |
Uma partição extendida permite a criação de partições lógicas dentro dela. O exemplo a seguir mostra a divisão da partição extendida em duas partições lógicas.
(parted) mkpart logical ext3 40 1000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical (parted) mkpart logical ext3 1000 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
Uma partição pode ser removida usando o comando rm do parted. Por exemplo:
(parted) rm 1 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
Após criar todas as partições necessárias, saia do parted usando o comando quit. Se uma partição foi adicionada, removida ou alterada enquanto os dois membros estavam ligados e conectados ao armazenamento compartilhado, reinicie o outro membro para que reconheça as alterações. Após particionar um disco, formate a partição para usá-la no cluster. Por exemplo: crie sistemas de arquivo ou dispositivos raw para partições compartilhadas. Consulte a Seção 1.4.4.5 e a Seção 1.4.4.6 para mais informações.
Para informações básicas sobre o particionamento de discos rígidos durante a instalação, consulte o Guia de Instalação do Red Hat Enterprise Linux.
Após particionar os discos de armazenamento compartilhado, crie dispositivos raw nas partições. Sistemas de arquivo são dispositivos em bloco (por exemplo: /dev/sda1) que armazenam dados usados recentemente na memória do cache para melhorar o desempenho. Dispositivos raw não utilizam a memória do sistema para o caching. Consulte a Seção 1.4.4.6 para mais informações.
O Red Hat Enterprise Linux suporta dispositivos de caráter raw que não são fortemente codificados contra dispositvos em bloco específicos. Ao invés, Red Hat Enterprise Linux usa um 'character major number' (atualmente 162) para implementar uma série de dispositvos raw não restritos no diretório /dev/raw/. Qualquer dispositivo em bloco pode ter um front-end de dispositivo raw, mesmo se o dispositivo em bloco for carregado posteriormente no momento da execução (run time).
Para criar um dispositivo raw, edite o arquivo /etc/sysconfig/rawdevices para ligar um dispositivo de caráter raw ao dispositivo em bloco apropriado, a fim de habilitar o dispositivo raw para ser aberto, lido e escrito.
Partições compartilhadas e algumas aplicações de banco de dados requerem dispositivos raw, porque estas aplicações executam seu próprio caching no buffer para fins de desempenho. As partições compartilhadas não podem conter sistemas de arquivo porque, se os dados de estado foram cacheados (armazenados) na memória do sistema, os membros não teriam uma visão consistente dos dados de estado.
Dispositivos de caráter raw devem ser ligados aos dispositivos em bloco cada vez que um membro inicializar. Para garantir que isso ocorra, edite o arquivo /etc/sysconfig/rawdevices e especifique as ligações (bindings) das partições compartilhadas. Se estiver usando um dispositivo raw em um serviço do cluster, use este arquivo para ligar os dispositivos no momento da inicialização. Consulte a Seção 2.5 para mais informações.
Após editar /etc/sysconfig/rawdevices, as alterações tomam efeito reinicializando ou executando o seguinte comando:
service rawdevices restart |
Consulte todos os dispositivos raw usando o comando raw -aq. O output deve ser parecido com o seguinte:
/dev/raw/raw1 bound to major 8, minor 17 /dev/raw/raw2 bound to major 8, minor 18 |
Note que, para dispositivos raw, não existe coerência de cache entre os dispositivos em bloco e raw. Os pedidos devem ter 512 bytes e ser alinhados em termos de memória e disco. Por exemplo: o comando dd padrão não pode ser usado com os dispositivos raw, porque o buffer da memória passado pelo comando para a chamada de gravação no sistema não está alinhado com o limite de 512 bytes.
Para mais informações sobre o uso do comando raw, consulte a página man raw(8).
![]() | Nota |
---|---|
Os mesmos nomes dos dispositivos raw (por exemplo:/dev/raw/raw1 e /dev/raw/raw2) devem ser usados em todos os membros do cluster. |
Use o comando mkfs para criar um sistema de arquivo ext3. Por exemplo:
mke2fs -j -b 4096 /dev/sde3 |
Para o desempenho máximo dos sistemas de arquivo compartilhados, certifique-se de especificar o tamanho de 4 KB para o bloco com a opção -b no mke2fs. Um tamanho menor do bloco pode causar períodos longos no fsck.