quinta-feira, 29 de novembro de 2018

IGNITE FOR LINUX

Ignite for Linux Disaster Recovery

O que é Ignite-LX?

O Ignite-LX é uma estrutura de scripts de recuperação de desastres gratuita que permite recuperar uma distribuição Linux. Este conjunto de ferramentas é baseado nas ideias do HP-UX Ignit-UX. Ele não habilita um daemon HP-UX Ignite em uma distribuição Linux, porem é uma solução como o Ignite no HP-UX.

Pré-requisitos

Ignite-LX requer os pacotes/binarios:

ip (iproute)
mkisofs 

Como o Ignite-LX trabalha


O Ignite-LX coleta todas as informações relevantes do sistema, como discos, lvm, raid, rede, etc. e cria um arquivo cpio compactado do sistema. Existem vários scripts que fazem esse trabalho. O resultado será uma imagem "ISO inicializavel e "Kernel + configurações Initrd" (isto pode ser usado para o netboot PXE, exp. by Cobbler) e um arquivo do seu sistema. A "ISO" ou "Kernel + Initrd" não contem todos os arquivos para a restauração do sistema, contém somente o necessário para rodar o recovery (baseado em menu). Somente o arquivo CPIO compactado contem todos os arquivos do SO relevantes e "este local" também está incluíndo no "ISO".

O Ignite-LX suporta "backends" multibel para criação e restauração de desastres. No momento há apenas um back-end disponível, o "nfs".  O NFS permite a criação e a restauração do seu Linux por meio de um compartilhamento NFS. Há previsão para desenvolvimento para criação do back-end em http, sftp e arquivos.

Como Instalar

Não há pacote de instalação criado até o momento. Simplesmente extraia o "ignite-lx.tar.gz" dentro do diretório "/opt", isso é tudo.
Se você quer utilizar outro diretório você deve estar a variável de ambiente "IGX_BASE" apontando para o diretório de instalação "ignite-lx".

Exemplo: export IGX_BASE=$HOME/ignite-lx"

O Ignite-LX vem com os seguintes diretórios padrão:

bin   # contem o script make_recovery.sh para a criação da imagem.
bin/backup/backends   # contem backup disponíveis.
bin/common   # contem as principais funções e os scripts auxiliares.
bin/restore/backends  # contem os arquivos de restore.

data/boot64/image   #  localização do local para criação da ISO, initrd e kernel (64 bit)

data/boot64/initrd_root   #   contem os arquivos de sistemas relevantes para restore (64 bit)

data/boot64/iso_root   #  arquivos requeridos para criação do boot (ISO) (64 bit)
data/config   # localização do local de todos os conjuntos de recuperação (info do sistema)

etc   # contem o arquivo ignite.conf para configuração de todo o ignite e back-end

log   # contem o ignite.log

mnt/arch_mnt   # ponto de montagem para o NFS 

O back-end do NFS permite a criação e a restauração do seu Linux por meio de um compartilhamento NFS.

Como utilizar o Ignite-LX (criar uma imagem de recuperação de desastre)

Ignite-LX é simples de rodar. Para o usuário final, apenas a execução de um script é necessária. Este script é chamado "make_recovery.sh" e esta localizado dentro do diretório "bin" do ignite-LX.
Adicionalmente existem alguns outros scripts de ajuda/trabalho, localizado dentro do diretório "bin/common".

Visão geral dos scripts relevantes:

bin/common/ignite_common.inc   # Principais funções de framework, (Includes nos scripts)
bin/common/make_boot.sh            # Cria o live system + iso
bin/common/make_config.sh         # Coleta as informações necessárias para o restore
bin/common/make_image.sh         # Cria o arquivo CPIO compactado
bin/make_recovery.sh                    # Scrip para o usuário final criar o backup
bin/restore/edit_restore.sh              # Utilizado num live system para editar as informações de restore
bin/restore/make_restore.sh           # Restaura o sistema se o live system é inicializado
etc/ignite.conf                                 # Contem as configurações do ignite

Para criar uma imagem de desastre do sistema, veja o seguinte exemplo abaixo:

Em um sistema secundário (chamado "backupsrv"neste exemplo) exporte um compartilhamento gravável "root", por exemplo "/var/ignite" e crie um diretório de cliente que deve ser usado para backup.

# mkdir -p /var/ignite/linuxbox
# echo "/var/ignite linuxbox(rw,no_root_squash,sync,subtree_check)" >> /etc/exports
# exportfs -a

No sistema que deve fazer o backup, edite o arquivo etc/ignite.conf

# vi /etc/ignite.conf
# ""
#
# NFS Backend configuration
#
IGX_NFS_URL="backupsrv:/var/ignite/linuxbox"
IGX_NFS_MOUNTPOINT="$IGX_BASE/mnt/arch_mnt"


Agora, execute o script de recuperação como segue e certifique-se de que todos os dispositivos ou grupos de volumes necessários para executar seu SO (Não os disco Externo) estão incluindos (consulte os detalhes de ajuda do script).

# cd /opt/ignite-lx/bin
# ./make_recovery.sh -b nfs -i vg00 -i /dev/md0 -x /tmp -x /var/tmp -x /wwwroot

As opções fazem o seguinte:

-i   inclue os devices ou grupo de volumes que queira incluir no backup
-x   diretório definido é excluido do backup
-b   define o back-end utilizado para criação do backup.

Explicação 

O sistema "linuxbox" possui os seguinte pontos de montagens:

/dev/md0 on / type xfs (rw)
/dev/mapper/vg00-lv_home on /home type xfs (rw)
/dev/mapper/vg00-lv_opt on /opt type xfs (rw)
/dev/mapper/vg00-lv_tmp on /tmp type xfs (rw)
/dev/mapper/vg00-lv_usr on /usr type xfs (rw)
/dev/mapper/vg00-lv_local on /usr/local type xfs (rw)
/dev/mapper/vg00-lv_var on /var type xfs (rw)

Os pontos de montagem acima são pontos de montagem nativo do sistema operacional e são necessários em um backup.

O script "make_recovery.sh"  resolve o ponto de montagem por dispotivos e group de volumes, portanto, temos que definir "/dev/md0" para o monto de montagem root e "vg00"para o grupo de volume chamado "vg00".

terça-feira, 16 de outubro de 2018

Testes de desempenho de I/O no Linux usando o comando dd



No Linux, o comando dd pode ser usado para medir o desempenho de I/O em disco utilizando escritas sequenciais. Este artigo fornecerá informações sobre quais parâmetros devem ser utilizados.


Noções básicas

dd pode ser usado para cópia de dados de baixo nível. Ao fazer isso, arquivos de dispositivos são acessados diretamente. Cuidado com o fato de que o uso incorreto do dd pode levar rapidamente à perda de dados. É recomendável executar as etapas descritas abaixo com muita atenção. Se o dd for utilizado incorretamente, o resultado será perda de dados.

Medindo o desempenho de gravação

Sistemas Operacionais modernos normalmente não gravam arquivos diretamente em sistemas de RAID ou discos rígidos. A memória temporaria que não está em uso no momento, será usada para armazenar em cache gravações e leituras.

Assim, essa medida de desempenho de I/O não será afetada por esses caches (memória temporaria),  o parâmetro oflag pode ser usado. Assim, os dois flags a seguir são interessantes (para detalhes, consulte dd --help e dd utilizando I/O direto ou sincronizado).

  • direct (utiliza I/O direto para dados)
  • dsync (utiliza I/O sincronizado para dados)
  • sync (da mema forma, mas também para metadados)
Para medir o desempenho de gravação, os dados a serem escritos devem ser lidos de /dev/zero e depois gravados em um RAID, disco rígido ou uma partição vazia (usando algo como of=/dev/sda para o primeiro disco rígido, ou of=/dev/sda2 para uma segunda partição no primeiro disco rígido. Se isso não for possível, uma file system normal pode ser utilizada (usando algo como of=/root/teste.img). Por razões de segurança se não tiverem certeza do que estão fazendo, faça os testes em um arquivo dentro da file system. No meu caso vou fazer os testes em discos raw e file system para comparação. O desempenho de gravação obtido nos testes com arquivos em file system será um pouco mais lento (porque os metadados também serão gravados no sistema de arquivo).

Importante: Ao gravar em um dispositivo (algo como /dev/sda), os dados armazenados serão perdidos. Por essa razão, escolha um RAID, disco ou partição vazia.

Nos meus testes estarei utilizando o seguinte equipamento: 
  • HP EliteBook 8460w
    • 8 GiB de RAM
    • sda (SSD)
    • sdb (SATA)
Observação:
  • Quando usar if=/dev/zero and bs=1G, o Linux precisará de 1GiB de espaço livre em memoria RAM. Se o seu ambiente de teste não tiver memória livre o suficiente, utilize um valor menor para o parâmetro bs (algo como 512MiB).
  • A fim de obter resultados mais próximos da realidade do nosso dia-a-dia, recomendo realizar os testes descritos varias vezes (tres a dez vezes, por exemplo). Ao fazer isso poderá detectar variações isoladas. Tais variações isoladas pode incluir jobs no cron, interrupções ou condições gerais devido ao processamento paralelo, o que pode afetar gravemente o desempenho. Um exemplo ao extremo, para esclarecermos essa questão, seria um job executando uma store procedure onde a mesma poderia estar fazendo muitos inserts em um banco de dados. 
HP Elite Book 8460w

Neste exemplo, nosso teste vai escrever um arquivo em /tmp , sendo a file system um XFS e SATA 5400 RPM.

1 GiB será escrito no arquivo /tmp/teste.img, primeiro com o cache ativado

merlin:/ # hdparm -W1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 9,96763 s, 108 MB/s
merlin:/ # 

agora com o cache desativado

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 10,0717 s, 107 MB/s
merlin:/ # 

Nesse teste vamos ver a latência, 512 bytes serão escritos 1000 vezes, primeiro com o cache desativado.

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 11,7722 s, 43,5 kB/s
merlin:/ # 

agora com o cache ativado

merlin:/ # hdparm -W1 /dev/sdv

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0947568 s, 5,4 MB/s
merlin:/ # 

Agora teste feito no disco SSD

cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,09522 s, 512 MB/s

merlin:/ # 

 cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída

1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,11989 s, 507 MB/s

Latencia, cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0521671 s, 9,8 MB/s

merlin:/ # 

Latência, cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 1,29057 s, 397 kB/s

merlin:/ # 

quinta-feira, 11 de outubro de 2018

Exportar e Importar usuarios SAMBA (pdbedit)

Para manter uma copia de segurança dos usuarios SAMBA.
Exportar
pdbedit -e smbpasswd:/home/amilcar/samba_backup.bak
Importar
pdbedit -i smbpasswd:/home/amilcar/samba_backup.bak

ou 

pdbedit -e tdbsam:/home/amilcar/samba_backup.bak

quinta-feira, 27 de setembro de 2018

Exemplos com o comando sed

Alterar padrão de data em arquivos 

exemplo de um arquivo texto


11|16952|1|0|065277493000408|7739|3|944783|1|729904|93.03|93.03|1.65|7.60|1.53|7.07|1862519|1|0|30/10/2017 00:17:50|56|
11|16953|1|0|065277493000408|7737|3|944540|1|729902|88.98|88.98|1.65|7.60|1.46|6.77|1862517|1|0|30/10/2017 00:17:47|56|

sed -E 's,([0-9]{2})/([0-9]{2})/([0-9]{4}),\3-\2-\1,g' frete.csv > frete.unl

resultado:


11|16952|1|0|065277493000408|7739|3|944783|1|729904|93.03|93.03|1.65|7.60|1.53|7.07|1862519|1|0|2017-10-30 00:17:50|56| 11|16953|1|0|065277493000408|7737|3|944540|1|729902|88.98|88.98|1.65|7.60|1.46|6.77|1862517|1|0|2017-10-30 00:17:47|56|

quinta-feira, 14 de junho de 2018

Os três principais Shells do Unix

Vou tirar um tempinho hoje para escrever um pouco sobre os 3 principais shells na maioria dos Sistemas Unix, hoje há algumas controversas pelo crescimento do Linux que utiliza o Bash Shell, porem o Bash não deixa de ser uma evolução do Bourne Shell que é um dos principais no qual vou comentar, mas vamos lá. Esses três Shell são:

  • Bourne Shell (AT&T shell)
  • C Shell (Berkeley shell)
  • Korn Shell ( Um superconjunto do Bourne Shell
Esses shells se comportam praticamente da mesma maneira quando executados de forma interativa, mas possuem algumas diferenças de sintaxe e eficiência quando usados como linguagens de scripts.

O Bourne Shell é o shell padrão na maioria dos Unix's,  muito utilizado para administrar o sistema. A maioria dos scripts de administração de sistema, como os scripts rc start / stop e shutdown são escritos em Bourne Shell, é o shell padrão também utilizado pelo root quando o sistema esta no estado de single mode. Esse Shell foi escrito pela AT&T e é conhecido por ser um shell consistente, compacto e rapido. O símbolo do prompt default do Bourne Shell é um sinal de dólar ($).

O C Shell foi desenvolvido em Berkeley e adicionou vários recursos, como o history de linha de comando, aliases, aritmética integrada, nome de arquivo completo, e controles de jobs. O C Shell tem algumas vantagens sobre o Bourne Shell na interactividade, mas os administradores preferem o Bourne Shell para scripts, porque os shells scripts do Bourne são mais simples e mais rápidos do que os mesmos scripts escritos no C Shell. O símbolo do prompt default do C Shell é um sinal de percentagem (%).

O Korn Shell é um superconjunto do Bourne Shell, escrito por David Korn na AT&T. Vários recursos foram adicionados a esse shell muito alem do C Shell. Os recursos do Korn Shell incluem um history evitável, aliases, funções, wildcards (curingas) de expressões regulares, aritmética incorporada, controle de Jobs, coprocessamento e recursos de debug. O Bourne Shell é quase totalmente compatível com o Korn Shell, portanto, programas do Bourne Shell rodarão normalmente nesse Shell. O símbolo do prompt default do Korn Shell é um sinal de dollar também ($).

No proximo post, vou descrever um pouco da historia do Shell.

quarta-feira, 13 de junho de 2018

Backup e Restore utilizando o I/O padrão (STDIO) - Informix

O Ontape permite utilizar o STDIO para operações físicas de backup e restore. Durante o backup, o ontape pode gravar dados no STDOUT. Durante o restore, o ontape pode ler o STDIN. O ontape utiliza pipes como um mecanismo de buffer de memória fornecido pelo sistema operacional para executar backup e restore utilizando o STDIO. As vantagens de utilizar o STDIO com o ontape são:
  • Nenhuma operação de leitura ou gravação para mídia de armazenamento é necessária (se você decidir direcionar diretamente os dados de  backup para uma operação de restauração).
  • Você pode usar os utilitários do sistema operacional para compactar os dados de backup antes do armazenamento.
  • Você pode enviar os dados de backup por meio de qualquer utilitário.
  • Você pode criar um servidor de banco de dados, restaurando imediatamente os dados em outro servidor, como configurar um servidor secundário (HDR) ou (RSS).
Configure o valor do parametro TAPEDEV como STDIO.

Os parâmetros de configuração TAPEBLK e TAPESIZE não são utilizados para fazer backup usando o STDIO. No entanto, o valor de TAPEBLK ainda é usado para a transferencia de dados entre o servidor de banco de dados e o processo ontape. O parametro TAPESIZE não é usado, porque a capacidade de STDIO é assumida como ilimitada.

O backup utilizando o STDIO é gravado diretamente no STDOUT. Portanto, o fluxo de dados precisa redirecionar para um arquivo. Caso contrario, o fluxo de dados sera enviado para a tela. Ao redirecionar o STDOUT para um arquivo, certifique-se que há espaço suficiente disponível no file system. Mensagens de erros e informações são gravadas no STDERR.

ontape -s -L 0 > /informix/backup/archive_L0


Executa o backup de nivel 0 utilizando o STDIO. O stdout do comando ontape é redirecionado para um arquivo chamado archive_L0 no diretório /informix/backup. O comando é o mesmo que o backup físico padrão ontape, exceto neste cenário, o sistema operacional manipula o fluxo de dados para o arquivo de saída.




ontape -s -L 0 | compress -c > /informix/backup/archive_L0

Executa backup de nivel 0, em que o comando ontape é redirecionado para um canal e os dados são compactados antes de serem gravados nos nomes de arquivos archive_L0 no diretorio /informix/backup.

O Backup e a restauração do lógico log não são compatíveis com o ontape usand o STDIO. No entanto, se houver backups de lógico logs padrao disponíveis, eles poderão ser restaurados usando o comando ontape -l após uma restauração fisico do ontape utilizando o STDIO. Alem disso, o salvamento de lógico logs não é possivel durante o processo de restauração. Portanto voce deve salvar manualmente todos os logs usando o comando ontape -S antes de executar uma restauração utilizando STDIO.

Durante a restauração padrão, o ontape imprime informações para stdout, mas com STDIO, as mensagens são omitidas. Da mesma forma, após restaurar um backup de nível 0,  o ontape solicita a restauração de backups de nível 1 e nível 2. Ma durante uma restauração para STDIO, esses prompts são omitidos. Em vez disso, o fluxo de entrada é varrido para mais dados. Se mais dados forem encontrados, o próximo nível de backup poderá ser restaurado. Portanto, todos os dados necessários devem fazer parte do fluxo de entrada para o comando de restauração, e os dados devem estar na ordem correta. 

cat /informix/backup/archive_L0 /informix/backup/archive_L1 | ontape -p

A função STDIO permite clonar um servidor de banco de dados Informix ou configurar rapidamente o HDR executando um backup simultâneo  para stdout e restaurando de stdin. Se o backup e restauração forem feitos apenas para duplicar um servidor de banco de dados Informix, use a opção -F para evitar que o archive seja salvo. Durante o backup e a restauração simultâneos, embora um backup seja feito, ele não pode ser restaurado posteriormente porque o backup não é salvo em um dispositivo de armazenamento; os dados de backup serão transferidos para outro sistema através de um pipe e, usando uma operação rsh, os dados serão imediatamente restaurados para outro sistema.

ontape -s -L 0 -F | rsh serverB "ontape -p"

O backup ontape nivel 0 é executado na maquina local. Os dados são canalizados para stdout em uma máquina remota chamada serverB usando o utilitário do sistema operacional rsh e uma restauração física é executada na máquina remota.
O Comando ontape ignora a opção -F se TAPEDEV não estiver configurado como STDIO. A opção ontape -F com a configuração STDIO significa que as informações do arquivo não são registradas nas paginas reservadas.

quarta-feira, 6 de junho de 2018

ORACLE - OPTIMIZER_INDEX_COST_ADJ

PROPRIEDADES, DESCRIÇÃO

Parameter type, integer
Default value, 100
Modifiable, ALTER SESSION - ALTER SYSTEM
Range of Values, 1 to 10000

OPTIMIZER_INDEX_COST_ADJ - permite ajustar o comportamento do otimizador para que a seleção do caminho de acesso seja mais ou menos amigável ao índice, ou seja, tornar o otimizador mais ou menos propenso a selecionar um caminho de acesso ao índice em uma varredura completa da tabela.

O padrão para esse parâmetro é 100%, no qual o otimizador avalia os caminhos de acesso ao índice no custo regular. Qualquer outro valor faz com que o otimizador avalie o caminho de acesso nessa porcentagem do custo regular. Por exemplo, uma configuração  de 50 faz com que o caminho de acesso ao índice pareça tao caro quanto o normal.