Como alterar configurações de Filesystems exportados via NFS sem reiniciar o serviço

Nesse post vou mostrar como você pode alterar as configurações de um filesystem exportado via NFS, adicionar novos filesystems para exportar, ou removê-los sem ter que reiniciar o serviço do NFS.

Como os caros colegas já devem estar cansados de saber, para exportar filesystems via NFS (vulgo compartilhar diretórios), deve-se criar entradas no arquivo /etc/exports. Cada filesystem exportado deve ser colocado em uma nova linha do arquivo juntamente com as configurações de exportação. Algo como o exemplo abaixo.

[root@linuxserver01 ~]# cat /etc/exports
/bkp/dumps 192.168.0.21(rw,no_root_squash)
/isoimagem *(ro,no_root_squash)
/publico *(rw,no_root_squash)

A questão é que não basta alterar esse arquivo para que as alterações entrem em vigor.
De uma forma geral o processo do NFS Server lê as configurações desse arquivo apenas quando ele é iniciado.
Dessa forma vejo vários colegas reiniciando o serviço NFS para que as alterações sejam efetivadas. O problema disso é que se a alteração ocorrer em servidores de produção esse tipo de ação pode requerer uma janela de manutenção, abertura de uma GMUD, reunião do CAB, e toda a burocracia e demora que estamos acostumados.

A boa notícia é que nem tudo está perdido! 😉
Você pode aplicar as alterações efetuadas no /etc/exports sem reiniciar o NFS Server. Para isso basta usar o comando exportfs!

[root@linuxserver01 ~]# exportfs -r

O parâmetro “-r” informa que você deseja “reexportar” os filesystems listados no arquivo /etc/exports.

Caso você execute o exportfs sem passar nenhum parâmetro, ele listara os filesystems atualmente exportados. Você pode usar o parâmetro “-v” (verbose) para exibir informações mais detalhadas das exportações.

Configurar Instâncias Oracle com Linux HugePages

Os Sistemas Operacionais Linux possuem uma funcionalidade muito interessante chamada de HugePages, que quando usada por um banco Oracle oferece grandes ganhos de performance.

HugePages consiste em tornar os blocos de alocação de memória muito maiores do que os 4KB padrão. No Linux os HugePages possuem 2MB por padrão. Outra vantagem é que os HugePages são sempre alocados na memória física e nunca vão para a área de swap. Na verdade esses blocos de memória sequer são considerados como candidatos a ir para swap.

Configuração

A primeira coisa a ser feita para a configuração é identificar quanta quantidade de memória você necessita para ser usada como HugePages. No caso de uma instância Oracle você deve alocar uma quantidade de memória suficiente para acomodar todo o seu SGA. Para isso use a fórmula abaixo.

X = Y / Z

Onde:

X: Quantidade de HugePages necessárias
Y: Tamanho do seu SGA também em KB
Z: Tamanho do HugePage em KB

Obs.: Uma dica é sempre configurar um valor um pouco maior do informado na fórmula. Eu normalmente somo 8 no resultado encontrado.

Agora que você já sabe o número de HugePages que deve configurar, vamos colocar a mão na massa!

Configurando o Linux

O primeiro passo é editar o arquivo /etc/sysctl.conf e adicionar os seguintes parâmetros:

vm.nr_hugepages=<Número de HugePages>
vm.hugetlb_shm_group=<ID do grupo principal do usuário oracle>

Para verificar o ID do grupo principal (gid) do usuário oracle utilize o comando id:

# id oracle
uid=500(oracle) gid=501(oinstall) groups=501(oinstall),500(dba)

No exemplo acima o ID é 501.

O passo seguinte é editar o arquivo /etc/security/limits.conf e definir a quantidade máxima de memória que o usuário oracle pode alocar:

oracle     soft    memlock  8404992 oracle     hard    memlock  8404992

O valor deve ser informado em KB e ser maior que o SGA.

Depois de configurar esses parâmetros reinicie o S.O. para que as configurações entrem em vigor. Para validar use os seguintes comandos:

# cat /proc/meminfo
MemTotal:       264234552 kB
MemFree:        10208592 kB
Buffers:          924660 kB
Cached:         103365808 kB
SwapCached:        74752 kB
Active:         61245124 kB
Inactive:       66576684 kB
Active(anon):   56581924 kB
Inactive(anon):  5085572 kB
Active(file):    4663200 kB
Inactive(file): 61491112 kB
Unevictable:      347136 kB
Mlocked:          347136 kB
SwapTotal:      25165820 kB
SwapFree:       24892344 kB
Dirty:              4444 kB
Writeback:             0 kB
AnonPages:      24014904 kB
Mapped:         23040796 kB
Shmem:          37860316 kB
Slab:            1418188 kB
SReclaimable:     958620 kB
SUnreclaim:       459568 kB
KernelStack:       26880 kB
PageTables:      1871460 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    97907480 kB
Committed_AS:   78301368 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     1053720 kB
VmallocChunk:   34358648516 kB
HardwareCorrupted:     0 kB
HugePages_Total:   57984
HugePages_Free:     5085
HugePages_Rsvd:     5082
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6144 kB
DirectMap2M:     2082816 kB
DirectMap1G:    266338304 kB

Verifique se o item de HugePages_Total está com o valor configurado.

Para validar o limite de alocação de memória do usuário oracle, logue-se com ele e use o comando abaixo:

# ulimit -l

Verifique se o valor retornado é igual ao configurado.

Agora basta configurar o Oracle.

Configurando o Oracle

No Oracle é necessário desabilitar o Automatic Memory Management (AMM). Esse recurso que simplifica o gerenciamento de memória da instância, ajustando automaticamente os tamanhos da SGA e da PGA, não é compatível com HugePages.

Nota: O AMM foi introduzido na versão 11g, portanto se você está configurando uma versão anterior não precisa se preocupar com ele.

Para desabilitar o AMM, basta desconfigurar os parâmetros MEMORY_TARGET e MEMORY_MAX_TARGET, e configurar o SGA_TARGET, SGA_MAX_SIZE e PGA_AGGREGATE_TARGET.

SQL> show parameter target;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target                   integer     0
db_flashback_retention_target        integer     1440
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     300
memory_max_target                    big integer 0
memory_target                        big integer 0
parallel_servers_target              integer     240
pga_aggregate_target                 big integer 6G
sga_target                           big integer 24G
SQL> show parameter sga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 24G
sga_target                           big integer 24G

Se estiver usando uma versão de banco anterior à 11.2.0.3, precisa ter atenção redobrada na hora de configurar a quantidade/tamanho de HugePages, pois nessas versões não existe uso parcial de HugePages. Ou seja, versões até 11.2.0.2 tentam colocar a SGA inteira em HugePages, caso a quantidade não seja suficiente, a SGA será alocada integralmente em páginas normais.

A partir da versão 11.2.0.3 passa ser possível colocar apenas parte da SGA em HugePages, e a parte que sobrar é alocada em páginas regulares. Por exemplo, caso sua SGA seja de 32GB e o número de HugePages configurado some apenas 20GB, os 12GB excedentes serão alocados em páginas regulares.

Para verificar se a instancia iniciou usando corretamente as HugePages olhe o Alert log, conforme abaixo.

Starting ORACLE instance (normal)
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 24 GB (100%)
Large Pages used by this instance: 12289 (24 GB)
Large Pages unused system wide = 3 (6144 KB) (alloc incr 64 MB)
Large Pages configured system wide = 57984 (113 GB)
Large Page size = 2048 KB
***********************************************************

Para facilitar o controle sobre quando a instância iniciou usando corretamente as HugePages e evitar que algo errado aconteça e somente seja percebido posteriormente, quando o banco estiver apresentando problemas de performance, na versão 11.2.0.2 foi criado o parâmetro USE_LARGE_PAGES.

Esse parâmetro poder ter os seguintes valores TRUE, FALSE e ONLY.

  • FALSE a instância nunca usará as HugePages.
  • TRUE a instância tentará usar as HugePages conforme descrito acima, podendo ser afetada pela configuração incorreta do número de HugePages e alocando a SGA de forma parcial ou total em páginas regulares.
  • ONLY a instância tentará alocar toda a SGA em HugePages, caso não consiga será gerado um erro e a instância não iniciará.

O erro gerado pelo parâmetro USE_LARGE_PAGES=ONLY é o seguinte:

SQL> startup
ORA-27137: unable to allocate large pages to create a shared memory segment
Linux-x86_64 Error: 12: Cannot allocate memory

Essa situação também pode ser verificada no Alert log.

****************** Large Pages Information *****************
Parameter use_large_pages = ONLY

Large Pages unused system wide = 0 (0 KB) (alloc incr 4096 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB

ERROR:
  Failed to allocate shared global region with large pages, unix errno = 12.
  Aborting Instance startup.
  ORA-27137: unable to allocate Large Pages to create a shared memory segment

ACTION:
  Total Shared Global Region size is 24 GB. Increase the number of
  unused large pages to atleast 12289 (24 GB) to allocate 100% Shared Global
  Region with Large Pages.
***********************************************************

Usando esse parâmetro, você pode ter certeza que quando a instância inicia ela está efetivamente carregada em HugePages.

Criar ASM Diskgroups dentro de volumes NFS

Neste artigo vou abordar a utilização de arquivos em volumes NFS como discos ASM.
A ideia dessa configuração surgiu da minha necessidade de montar um ambiente de laboratório com Oracle 12c em RAC usando o Hyper-V do meu notebook.
Como o Hyper-V não suporta (até o momento em que este post foi criado, em 2016) o compartilhamento de discos entre VMs quando usados apenas discos locais, foi necessário buscar um método alternativo para criar o ambiente. Dessa forma, além das duas máquinas virtuais para os hosts do RAC, criei mais uma para ser o servidor NFS.

Nota: Apesar da utilização de arquivos em volumes NFS como discos ASM ser uma configuração suportada pela Oracle, ela deve ser utilizada com muita cautela, principalmente se pretende usá-la em produção. A utilização de volumes NFS requer a montagem no modo “hard”, o que faz com que a instância ASM ou o Database esperem indefinidamente por uma resposta do servidor NFS quando este ficar indisponível. Isso significa que o ASM não poderá fornecer de forma efetiva o espelhamento de dados.
De uma forma geral, para usar essa configuração os Diskgroups devem ser configurados com redundância “External” e a comunicação com os volumes NFS deve ser confiável.
Ref.:  How To Create ASM Diskgroups using NFS/NAS Files? (Doc ID 731775.1)

Configurando o servidor NFS (O Storage)

No ambiente de laboratório que estou montando o SO usado é o Oracle Linux 7, portanto todos os comandos aqui são relativos a essa versão, que trouxe varias novidades em relação ao Oracle Linux 6, principalmente a adição do systemd como mecanismo de controle e gerenciamento de serviços, devices, sockets e pontos de montagem.

Primeiramente instale o servidor NFS.

[root@ol7nfs01 ~]# yum install nfs-utils

Crie o diretório onde serão colocados os arquivos que serão usados como discos pelo ASM

[root@ol7nfs01 ~]# mkdir /nfs

Edite o arquivo /etc/exports para configurar a publicação do diretório pelo servidor NFS. Tenha atenção aos parâmetros usados e somente altere-os se souber o que está fazendo. Nesse laboratório o diretório que estou exportando é o “/nfs”.

[root@ol7nfs01 ~]# cat /etc/exports
/nfs    *(rw,sync,no_wdelay,insecure_locks,no_root_squash)

Inicie e ative o serviço do NFS, para que o mesmo inicie sempre que o servidor reiniciar.

[root@ol7nfs01 ~]# systemctl start nfs-server
[root@ol7nfs01 ~]# systemctl enable nfs-server

Configurando o cliente NFS (O Database Server)

A primeira atividade nos servidores de banco que montarão o diretório NFS é criar a pasta que servirá de ponto de montagem.

[root@ol7db01 ~]# mkdir -p /u01/oradata

Em seguida edite o arquivo /etc/fstab para que o volume NFS seja montado sempre que o servidor for reiniciado. Adicione a seguinte linha ao fstab, sendo que “ol7nfs01” é o nome do servidor NFS. Novamente atenção aos parâmetros e somente altere-os se souber o que está fazendo.

ol7nfs01:/nfs    /u01/oradata    nfs     rw,bg,hard,nointr,tcp,vers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0  0 0

Agora você pode montar o volume NFS

[root@ol7db01 ~]# mount -a

Em seguida configure o “ownership” e as permissões do diretório. Estou assumindo que o usuário oracle e o grupo oinstall já estão criados.

[root@ol7db01 ~]# chown -R oracle:oinstall /u01/oradata
[root@ol7db01 ~]# chmod -R 775 /u01/oradata

O próximo passo é criar os arquivos que serão usados como discos para o ASM. Vou criar alguns arquivos de 10 GB para usar nos diskgroups DATA e RECO. Como no meu laboratório vou instalar o Grid Infrastructure sob o usuário grid, usarei ele para criar os arquivos.

[grid@ol7db01 ~]$ mkdir /u01/oradata/asm
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data01.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data02.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data03.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data04.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data05.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/reco01.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/reco02.disk bs=1k count=10000000

Devemos ajustar novamente as permissões no diretório e arquivos criados.

[grid@ol7db01 ~]$ chmod 775 /u01/oradata/asm
[grid@ol7db01 ~]$ chmod 664 /u01/oradata/asm/*

Agora o ambiente já está preparado e podemos iniciar a instalação do Grid Infrastructure. Na tela de criação do diskgroup do ASM inicialmente não vão aparecer os discos candidatos. Basta clicar em “Change Discovery Path” e indicar o diretório NFS onde foram criados os arquivos.

Na tela para alterar o caminho de descoberta dos discos, digite o caminho com o asterisco como caractere coringa.

Quando retornar à tela de seleção de discos, os arquivos aparecerão listados.

Deste ponto em diante o processo é exatamente igual à qualquer instalação do Grid Infrastructure.

Configurar RedHat 5 para utilizar o repositório do CentOS 5 no Vault

Antes de mais nada é preciso dizer que não é recomendado utilizar uma versões tão antiga do RedHat/CentOS, principalmente se ela estiver acessível publicamente na Internet, visto que são versões já sem suporte à algum tempo e que não estão recebendo atualizações de segurança que podem ser críticas.

Mas se por qualquer necessidade você precisa utilizar essa versão, este procedimento pode ser útil. Principalmente se você utiliza o RedHat e não possui uma subscription ativa.

Aviso: Não execute esse procedimento em instalações RedHat que estejam em produção. Apesar do CentOS ser teoricamente uma ‘cópia’ do RedHat, compilado a partir dos mesmos códigos fonte, ainda assim é possível que em nível binário existam diferenças que quebrem a aplicação que está rodando no servidor.

Limpando cache local do yum:

# yum clean all

Baixando pacotes mais recentes do release do CentOS 5, do YUM e da lista de mirrors:

# wget http://vault.centos.org/5.11/os/x86_64/RPM-GPG-KEY-CentOS-5
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/centos-release-5-11.el5.centos.x86_64.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/centos-release-notes-5.11-0.x86_64.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-3.2.22-40.el5.centos.noarch.rpm 
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-updatesd-0.9-6.el5_10.noarch.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-fastestmirror-1.1.16-21.el5.centos.noarch.rpm

Importando a chave GPG do CentOS:

# rpm --import RPM-GPG-KEY-CentOS-5

Removendo o pacote de release dele do RedHat, pois será substituído pelo do CentOS:

# rpm -e --nodeps redhat-release

Instalar os pacotes baixados:

# rpm -Uvh --force yum*.rpm centos*.rpm

Atualizando o arquivo de repositório Base com as informações do repositório do Vault.

# head -37 /etc/yum.repos.d/CentOS-Vault.repo > /etc/yum.repos.d/CentOS-Base.repo
# sed -i 's/enabled=0/enabled=1/g' /etc/yum.repos.d/CentOS-Base.repo

Removendo arquivo desnecessário com as informações do Vault para evitar conflitos:

# rm -f /etc/yum.repos.d/CentOS-Vault.repo

Em seguida já pode rodar o yum para instalar os pacotes necessários, como por exemplo:

# yum install net-snmp

Linux: Alterando discos e partições sem reiniciar

Caso tenha alterado o tamanho de um disco, por exemplo, aumentando o tamanho de um disco já existente em uma VM, use o comando abaixo para forçar o kernel do linux a reler as informações do disco.

# echo 1 > /sys/class/block/sdd/device/rescan

Sendo que “sdd” no comando acima é o dispositivo do disco que teve o tamanho alterado.

Caso tenha incluído ou removido um ou mais discos do servidor, utilize o comando abaixo para forcar uma releitura nos barramentos das controladoras por alterações de dispositivos. É importante ressaltar que o comando abaixo não tem nenhum efeito no caso de alteração de tamanho para um disco já reconhecido previamente pelo sistema.

# for host in /sys/class/scsi_host/*; do echo "- - -" | tee $host/scan; lsblk -S ; done

Após utilizar os comandos acima e os discos estarem devidamente reconhecidos com os tamanhos corretos, é possível seguir com a criação e/ou redimensionamento do sistema de arquivos.

Redimensionando partições de disco no Linux

Recomendo usar o utilitário “parted”, pois o “fdisk” precisa remover e recriar a partição. O risco é muito maior de dar problema.

No exemplo abaixo vamos redimencionar a partição 2 do disco /dev/sda para ocupar todo o espaço livre existente no disco. Esse espaço foi gerado quando o disco foi aumentado no VMware (ou outro virtualizador qualquer) ou quando fez um clone para um disco maior.

# parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 268GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 1075MB 1074MB primary ext4 boot
2 1075MB 172GB 171GB primary lvm

(parted) resizepart 2 100%
(parted) print
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 268GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 1075MB 1074MB primary ext4 boot
2 1075MB 268GB 267GB primary lvm

(parted) quit
Information: You may need to update /etc/fstab.

Depois disso, sendo a partição um LVM, basta expandir o PV:

# pvresize /dev/sda2
Physical volume "/dev/sda2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Depois disso o procedimento para expandir o volume logico LV é o mesmo de quando é feita adição de novos discos.

# lvextend -r -l +100%FREE /dev/cl_aplprd01dc/root
Size of logical volume cl_aplprd01dc/root changed from <151.00 GiB (38655 extents) to <241.00 GiB (61695 extents).
Logical volume cl_aplprd01dc/root successfully resized.
meta-data=/dev/mapper/cl_aplprd01dc-root isize=512 agcount=4, agsize=9895680 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1
data = bsize=4096 blocks=39582720, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=19327, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 39582720 to 63175680