domingo, 24 de janeiro de 2010

Divulgados videos do FISL 10

Bom dia!

Hoje lembrei de verificar novamente se os videos das palestras do FISL 10 já foram publicados. Para a minha surpresa eles já estão todos disponíveis e já faz alguns meses! hehehe

Esse é o link da minha palestra de Técnicar Avançadas de Segurança com Iptables.
http://stream.softwarelivre.org/video/tecnicas-avan%C3%A7adas-de-seguran%C3%A7-com-iptables

E no link http://stream.softwarelivre.org podem ser vistos todos os outros materiais da TV Software Livre.

Abraço!

sábado, 23 de janeiro de 2010

Linux Shared Memory - Parte 2

Continuando...

SHMMNI

Esse parâmetro serve para definirmos o número máximo de segmentos de memória para todo o sistema, ou seja, quantas bloquinhos de memória compartilhada ele vai poder criar.

Esse parâmentro é bem tranquilo. Seria problema apenas se o valor dele mutiplicado pelo shmmax ultrapassasse o tamanho de memória disponível no sistema, passando a usar Swap e degradando a performance do sistema. Mas embora isso seja possível, nunca vi acontecer. Por outro lado se tiver um valor muito baixo pode ocorrer de alguma aplicação tentar criar um segmento e não conseguir acarretando uma corrupção de dados, travamento, etc.

Minha dica para a correta configuração desse parâmetro é definir um valor que multiplicado por SHMMAX fique um pouco (uns 25%) abaixo da memória total.

Algumas aplicações, como o Oracle 10g, já tráz em suas documentações o valores mínimos necessários na configuração... Mas não precisa ser levado à risca pois eles sempre chutam bem alto e raramente será usado o valor indicado por eles. O ideal é sempre adequar as proporções do servidor e da aplicação.

O que ocorre muito comunmente é colocarem valores enormes para "garantir" que nunca falte. Na minha opinião isso pode ser feito tranquilamente, mas quando não existe conhecimento para deixar com a configuração ideal.

A falta de conhecimento sempre gera medo!! Quer um exemplo? Já viu algum bastardo dar permissão 777 em um arquivo sem nem saber se o problema é permissão e ainda virar e falar: "É só para garantir! Depois eu arrumo!!" hehe Isso ali nunca mais vai ser arrumado.
O que me deixa feliz quanto à isso é que certamente esse administrador vai deixar um furo cedo ou tarde pela sua imprudência. E nesse caso eu poderei dar consultoria para ele e ganhar dinheiro. hehehe
Bom! Empolguei.

Ah, outro tópico importante nesse shmmni é que dificilmente os segmentos terão o tamanho de shmmax. Normalmente são bem menores.


SHMALL

Bom, o shmall define o tamanho máximo reservado para compartilhamento de memória em paginação do sistema. Ao contrário dos outros parâmentros ele é definido em página e não em bytes. Seu valor é bem relacionado com o shmmax, inclusive na maioria dos lugares que pesquisei o pessoal coloca como regra para seu valor a seguinte fórmula SHMMAX/PAGE_SIZE.

Isso não está errado, mas também não deve ser dito como um regra. A impressão que tenho é que as grandes empresas criam um padrão que acreditam agradar todos levando em consideração que nenhum administrador terá conhecimento para definir do seu próprio jeito. Depois esses adminsitradores lêem essa documentação e acreditam cegamente nela. O suporte técnico da ferramenta e qualquer outro administrador que não se interessa em pesquisar e estudar vão fazer a mesma coisa. Pronto!! Virou regra! Daí quando vem um louco que estudou sobre o assunto e disse aquele não é o valor mais adequado e todos tem a audácia de falar "Mas a documentação oficial manda fazer assim...!!". E assim termina a justificativa. Digo isso pois já passei por casos como esse com consultores SAP... Mas isso não interessa agora!! Putz, empolguei-me novamente. : )

Voltando ao que interessa... Essa dica para dividir o shmmax pelo valor de paginação funciona e é bem interessante. Um arquivo de paginação sempre tem um tamanho fixo e definido. As memórias compartilhadas serão formadas por arquivos de paginação. Logo o total de paginação não poderia ser maior que shmmax. Mas isso considerando apenas uma instância do oracle, por exemplo.

Tentarei ser mais claro. Seguindo as dicas que coloquei no post do shmmax, faremos um cálculo do que os SGAs, PGAs e SOs usarão de memória compartilhada no total. Feito isso temos o máximo de memória compartilhada que nosso servidor pode usar. Legal.
Agora vamos definir o shmall, que na mairia das distros é em páginas e não em bytes. Esse kra vai dizer qual o tamanho máximo de memória compartilhada em arquivos de paginação. Sabendo que nosso sistema tem páginas de tamanho 4096 bytes através do comando $ getconf PAGE_SIZE e que o tamanho máximo de memória compartilhada é igual a shmmax basta dividirmos SHMMAX por 4096 e fica legal.

Pronto! Explicada a regra milagrosa que quase todo mundo usa. Mas eis o ponto que quero chegar... O que eu faço com esses parâmentros se eu quiser uma segunda insttância do oracle com mesmo tamanho de SGA? hehe.
Ta bom! Vamos usar exemplos concretos. Tenho um SGA de 5G e PGA de 2G. Somo os dois e acrescento 25%. Isso daria 8.75G. Arredondei para 9G para ficar melhor já que isso não causa impacto. Transformo em bytes e tenho o shmmax de 9663676416. O tamanho do meu arquivos de paginação é de 4096 bytes.
Logo shmall é 9663676416 / 4096 = 2359296.

Agora se eu quiser colocar mais uma instância desse oracle exatamente igual, meu shmmax não mudará, pois a instância é igual. O que precisa ser mudado é o total de memória compartilhada para todo o sistema. Sendo um pouco menos burocrático podemos simplesmente consideram que teremos dois kras usando o valor de shmmax. Logo shmall = 9663676416 / 4096 = 2359296 * 2 = 4718592.

Espero que agora tenha ficado mais claro, pois eu perdi um tempo procurando documentação para entender isso. Pelo menos agora está documentado de forma clara (espero!!).



SHMMIN

Esse é o oposto do SHMMAX e significa o tamanho mínimo possível de um segmento de memória compartilhada. O padrão desse parâmentro já é 1 em quase todas as distros e outras nem mesmo o trazer disponível para alterações.

Pesquisei um monte e não encontrei nem consegui imaginar uma razão para deixar esse kra maior que 1. Talvez até tenha algum motivo que eu não conheça, mas por enquanto acho que é a mesma coisa que procurar chifre em cabeça de cavalo, ou seja, não vai melhorar em nada e ainda pode causar algum problema.

Aqui finalizo os posts sobre Linux Shared Memory. Acho que postarei alguns sobre semáforos qualquer hora dessas.

Abração!

Linux Shared Memory - Parte 1

Uepas!!

Bom, neste exato momento (05:22) de um sábado estamos executando um procedimento de Upgrade de Oracle 9i para 10g em um SLES 9 x86_64 e dentre os requisitos para o Oracle 10g estão os tunninngs de kernel para memória compartilhada, semáforos e manipulações de arquivos.

O que vem a ser memória compartilhada?
Atualmente, nos Sistemas Operacionais já é quase improvável um sistema grande, como um Oracle, SAP, Postfix e outros, trabalhar com apenas 1 processo. Usa vários processos torna tudo mais rápido pois diversos processos podem trabalhar em conjunto fazerndo diversas ações diferentes ou atendendo múltiplus clientes ao mesmo tempo.

Porém, quando uma aplicação usa multi-processos esses sempre chegarão em um ponto em comum. Em um banco de dados, por exemplo, existe apenas uma database e vários processos que precisam usá-la. Para garantir a integridade, os processos devem usá-la sequencialmente e de forma civilizada. Nosso fabuloso kernel faz esse serviço deslumbrante permitindo que apenas um processo use determinada informação por vez.

Agora imagine um sistema com 200 processos precisando manipular uma única informação. Em um ambiente sem memória compartilhada o kernel precisaria copiar toda a informação para a área de memória do processo que estava na vez, depois copiar novamente para o outro e assim por diante. Nossa!! Até para escrever isso já fica mais demorado : ), imagina um usuário cliquemaníaco esperando que seu processo seja concluído!!

Para evitar esse problema e dar uma velocidade realmente boa para essa briga desenfreada por manipulação de uma única informação, os processo usam memória compartilhada. Isso significa que a informação em comum para todos os processos ficará em uma área de memória acessível por todos eles. A diferença nessa ambiente é que o kernel precisará apenas controlar que processo terá acesso e não mais fazer a cópia da informação para a memória privada de cada processo. Felizmente isso existe e é muito usado.

Ah! O nome desse compartilhamento de informações entre processos chama-se Interprocess Communication (IPC). Por coincidência temos um comando chamado "ipcs" no Linux. : )

Ok! Agora que entendemos o que é memória compartilhada podemos seguir com o tunning de Kernel no Linux.

Como verifico os parametros atuais?
Através do diretório /proc, onde estão todos os arquivos de configuração que interagem diretamente com kernel e SO.
Ex: $ cat /proc/sys/kernel/shmmax

Outra forma de verificar essas opções é através do comando: $ sysctl -a
Esse comando vai listar todas as configurações do /proc. Daí é só fazer um fltro na saída.

Parâmetros de Memmória Compartilhada

Bom, falando em memória compartilhada em Linux temos as seguintes configurações principais:
SHM = Abreviatura de Shared Memory

SHMMAX
Esse parâmentro diz qual será o tamanho máximo de um bloco de memória compartilhada que poderá ser alocado por processo. Não existe uma receita de bolo para isso. Tudo vai depender do que você vai rodar nesse servidor. Na maioria dos casos esse parâmetro serve para todos os aplicativos do servidor, mas no caso do Oracle, por exemplo, podemos querer configurá-lo para um maior desempenho aumentando seu SGA (System Global Área) para 5 GB.

OBS.: Esses valores estou inventando agora apenas para explicar sobre o shmmax.

Nesse caso significa que precisaremos configurar nosso shmmax para um valor que seja, no mínimo, 5 GB.
Lembrando que o shmmax é sempre configurado em bytes.
Caso eu tenha uma aplicação que precise de um bloco de memória compartilhada maior do que está especificado no SHMMAX, as probabilidades dessa aplicação dar "zica" são bem grandes.

Exemplo de erro no Oracle decorrente disso:
ORA-27123: unable to attach to shared memory segment
Para verificarmos informações de memória compartilhada no nosso sitema podemos usar o seguinte comando:
$ ipcs -lm

DICA: Sempre que precisar alterar esses valores utilize o arquivo /etc/sysctl.conf.


Depois de pesquisar bastante e fazer alguns testes cheguei em uma "regra" para definirmos o valor mais adequado para shmmax. Devemos descobrir os tamanhos dos blocos utilizados pelas aplicações como SGA, PGA, etc. Os administradores de tais aplicações devem trabalhar em conjunto para isso.
Uma vez definidos os tamanhos de blocos usados pelas aplicações somamos todos eles e acrescentamos 25% para processos do Sistema Operacional (Gerenciamento). Ex: SGA=5G, PGA=2G. (5+2)+25% = 8.75G. Podemos até arredondar para 9G que está tranquilo.

Importante: Em estruturas 32 Bits procure evitar valores próximos ou maiores de 4G. Pois nesses casos o sistema usará swap/paginação e o tunning pode acabar andando na contra-mão.

Extra
Não existe limite para o valor de shmmax, porém alguns pontos devem ser considerados.
1 - Caso configure ele para um valor acima da memória total resultará em Swap e perda de desempenho. É, no mínimo, uma loucura!!
2 - Caso configure ele para um valor acima da memória disponível (sobrando) resultará em Swap e perda de desempenho caso as aplicações usem todo esse tamanho. É para quem gosta de emoção!!
Nesse caso seu sistema funcionará corretamente se as aplicações estiverem funcinando abaixo desse valor, mas qualquer alteração no comportamento dessas aplicações poderá afetar o sistema.
3 - Em alguns forum reportaram que foi feita uma instalação do Oracle com esse valor bem alto e depois baixada. Quando precisaram de suporte a Oracle se negou a continuar até que o valor voltasse para o valor inicial
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1264240898189+28353475&threadId=811971

Por via das dúvidas, ajuste esse valor de acordo com as necessidades e depois vá aumentando caso necessário.

Como ficou grande esse post continuarei em outro...

segunda-feira, 18 de janeiro de 2010

LAN Switching

Buenas!!

Com esse post inicio uma série de posts relacionados à Networking. Estou estudando pela enésima vez para a CCNA e para ajudar na memoriazação e ainda no compartilhamento de informações publicarei informações quentinhas e sequenciais no decorrer dos estudos....


Conceitos de Switch
Bom, primeiramente vamos ao significado da palavra Switch. Acredito e sempre defendo que entender as origens dos nomes e conceitos é primordial para um entendimento claro. Fica muito mais fácil de memorizar e fazer analogias... Mas enfim... em todos os livros em português que já li sobre network o nome Switch é comumente traduzido para Comutador.

Mas o que é comutar? Pelo menos para mim era uma palavra bem incomum de ser usada no dia-a-dia. Para poupar o trabalho de quem está lendo, já fiz uma boa pesquisa tempos atrás e o melhor significado da palavra (relacionada a networking) está em unir, ou seja, um comutador/switch tem a função de unir equipamentos em um site. Mais especificamente criar uma LAN.

Hub x Switch
Aos conceitos... Normalmente vemos escreverem HUB e não Hub, como se fosse a sigla para algum conjunto de palavras como LAN, WAN, etc. Isso está errado. Hub não é uma sigla. É uma palavra inglêsa que significa cubo e diversas outras palavras. Esse equipamento foi chamado assim devido à uma analogia com as rodas raiadas de carros da época. Tais rodas possuiam um cubo/hub que interligava todos os raios formando uma estrela. Em network o que o hub faz é exatamente isso. Liga os raios/hosts.

Atualmente nem vemos muitos HUBs por aí (Isso me deixa muito feliz). Posso dizer que Hubs são equipamentos defasados e contra-indicados para as nossas nessecidades de networking. Ainda podem ser usados em casa para criar uma pequena rede domestica sob única justificativa de preço ou por administradores de rede para analises de tráfego (sniffing). Tirando essas situações o Hub não possui nenhuma vantagem em relação ao Switch.

Hub é um dispositivo que atua na camada 1 do modelo OSI, ou seja, a única coisa que ele faz e amplificar o sinal elétrico e repetí-lo para todas as suas portas com excessão da porta que recebeu o sinal original. Isso é um caos para a segurança e para o desempenho da rede. Como um mesmo sinal é repetido em todas as portas chegamos a conclusão que apenas um host pode transmitir simultaneamente, ou seja, quando ligarmos uma rede usando Hubs jamais teremos uma conexão Full-Duplex. Será sempre Half-Duplex. Isso causa uma disperdício completamente desnecessário na LAN somado com as colisões que ocorrem caso dois hosts tentem trasmitir ao mesmo tempo. Na prática: Quanto mais hubs na nossa rede, maior será nossa tristeza. : )

Na área da segurança o Hub é o melhor amigo do atacante. Como os sinais são sempre repetidos em todas as interfaces, basta eu estar naquele domínio de colisão que poderei ver QUALQUER informação transmitida pelos hosts desse mesmo domínio.

Extra: Uma vez vi um projetos de Cluster Beowulf de pequeno porte que estava usando Hubs no lugar de Switches sob justificativa que os hubs eram mais rápidos na transmissão de pacotes do que os Switches pois cusavam um delay ao analisar os pacotes na camada 2. Foi bem engraçada a justificativa.
Primeiramente o tempo gasto na análise de camada 2 compensa tranquilamente o tempo perdido com colisões, retrasmissões e half-duplex. Além disso os switches gerenciáveis e semi-gerenciáveis permitem que confuguremos o modo de análise dos pacotes (Store-and-forward, Cut-through e Fragment-free).

Bridge
Bridges/Pontes são equipamentos usados para separar fisicamente pela camada 2 conjuntos de computadores. O que elas fazem é impedir que pacotes de camada 2 passem para o outro segmente desnecessáriamente. Para isso ela mantém uma lista de MAC Address de todos os dispositivos conectados em cada porta dela e quando chega algum pacote até ela, a mesma o retransmite apenas para a porta onde o MAC Address de destino se encontra.

Switch
Finalmente os Switches... Switches são como bridges multiportas, pois funcionam exatamente como as bridges, mas possuem bem mais que duas portas. O correto é ligarmos um host a cada porta do Switch.
Inicialmente e por pouquíssimo tempo, quanto os switches são ligados, atuam como Hubs, porém são dispositivos de camada 2 que trabalham com endereços MAC e toman decisões com eles.

Para tomada de decisões o switch pressisa de um banco de dados com informações de MAC Address conhecidos. Essa tabela chama-se tabela ARP. No momento que o Switch é ligado sua tabela ARP se encontra vazia e sua população ocorre na medida que pacotes vão chegando. Por exemplo, a máquina1 possui o MAC 11:11:11:11:11:11 e está ligada na porta 0/1. Assim que ela mandar um pacote para a rede esse pacote entrará no Swicth pela porta 0/1 e com o MAC de origem 11:11:11:11:11:11. O Switch fará uma associação na tabela ARP entre essa porta e esse MAC e quando o Swicth receber um pacote com destino ao MAC 11:11:11:11:11:11 já saberá que o pacote deve ser encaminhado para a porta 0/1. Isso ocorre sucessivamente até a tabela ficar completa.

Resumo: Para popular a tabela ARP o que importa é o endereço de origem e sempre que um pacote chega no switch a tabela ARP é consultada antes de encaminhar o pacote.

Caso chegue um pacote com destino à um endereço que não consta na tabela ARP daquele switch o mesmo enviará um broadcast (flooding) de camada 2 (FF:FF:FF:FF:FF:FF) pedindo quem possui determinado MAC. Na resposta ele já atualiza a tabela ARP.

Com essa tabela bem definida, o Switch consegue criar circuitos virtuais entre hosts que estão se comunicando, ou seja, uma comunicação ocorrerá somente entre os hosts interessados. Dessa forma o sniffing não poderá ser feito de forma normal e todas as máquinas poderão trafegar em Full-Duplex.

Forward x Filter Decision
A situação descrita acima consiste em Forward, ou seja, o Switch aprende o MAC conforme os pacotes vão chegando e armazena na tabela ARP associado com uma porta.
Quando algum pacote passa por ele, o Switch lê o MAC de destino e consulta sua porta na tabela ARP. Se não existir ele manda um broadcast de camada 2 pedindo quem o possui e armazena na tabela. Caso o MAC de destino esteja na tabela e associado à uma porta diferente da qual o pacote chegou, o switch repassa esse pacote, ou seja, forward.
Caso o MAC esteja na tabela, mas associado à mesma porta que o pacote chegou o switch fará um filter, ou seja, descartará o pacote. Isso caracteriza, por exemplo, uma comunicação entre duas máquinas ligadas à um Hub que está ligado à uma porta do Switch. Não faz sentido o switch repassar esse pacote.

Conclusão: Hub é um lixo comparado aos Switches. Use switches sempre que possivel e seja feliz.

EXTRA: Tabela ARP também é chamada de Content Addressable Memory (CAM) devido ao tipo de memória física usada para isso. Ela é especial para converter IP em MAC muito rapidamente.

Até a próxima.