Arquivo

Archive for the ‘Virtualização’ Category

Blocos de Dados: tamanho é documento?

A tecnologia da informação está cada vez mais ligada ao nosso cotidiano, seja em casa, no carro, ou no trabalho nós convivemos o tempo inteiro com dispositivos tecnológicos. Quanto maior é a nossa dependência de tecnologia, mais informação é gerada e mais espaço é utilizado para guardar as informações relevantes (ou não). No meio corporativo onde a demanda por espaço é bem maior e geralmente são informações que tem que estar disponíveis sempre que necessário, da maneira mais performática possível.

Com o crescimento acelerado de banco de dados e a adoção cada vez maior de sistemas virtualizados, os blobs (arquivos binários) gerados hoje em dia estão cada vez mais volumosos. Se antes uma imagem iso de pouco mais de 700MB era uma coisa enorme, hoje em dia em algumas empresas encontramos blobs de 1TB ou mais, geralmente blobs que ocupam uma LUN ou um Pool de LUNs inteiro apenas para sí, muitas vezes resultando em um desempenho sofrível principalmente no caso de bancos de dados quando precisam fazer algum tipo de “data scan” ou de arquivos que são tratados de forma sequencial e precisam serem lidos do inicio até o fim. O mesmo senário se repete para o contrário: arquivos pequenos demais que resultam em uma grande quantidade de informação, talvez esse senário seja pior, pois por gerar um maior número de IOPS, fazem uso do hardware muitas vezes de forma extrema, porém nada otimizada. Se você está sofrendo com algo parecido com isso, esse artigo é pra você!

De forma alguma venho através deste artigo dizer que X é certo e Y é errado, mesmo porque cada ambiente  tem suas regras de negócios, particularidades, limitações e etc. Venho aqui discutir sobre como otimizar esses dados a partir de ajustes em níveis mais baixos, como por exemplo a “blocagem” do seu sistema de arquivos e/ou o stripesize de seu RAID.

Blocos de Dados

Os blocos, também chamados de INODE (no caso de sistemas baseados em UNIX) ou CLUSTER (no caso de sistemas baseados em Windows) são a maneira que o sistema de arquivos armazena e gerenciam os blobs gravados no disco (que pode ser realmente um disco ou qualquer outro dispositivo de bloco como LUN, RAID, etc).  Por exemplo, se seu sistema de arquivos usa blocos com o tamanho de 14KB, os arquivos serão quebrados em unidades de 14KB de tamanho, o que quer dizer, que para cada leitura, de um arquivo, o disco terá que ler X blocos de 14KB por Y vezes.  Nesse senário hipotético um arquivo de 1MB (1024KB) seria dividido em aproximadamente 74 partes de 14KB, o que significa que a cabeça de leitura do disco seria reposicionada 74 vezes durante a leitura deste único arquivo. Esse senário “hipotético” é tão comum quanto você não imagina, pois na maioria das vezes, os administradores de sistema não se preocupam muito com a blocagem a ser utilizada no sistema de arquivos como fator de desempenho final.

Também podem existir casos extremos em que se usam uma blocagem grande para escrever arquivos pequenos, o que incide no espaço final que ficará disponível, pois os blocos tem tamanhos fixos e uma vez alocados para uma determinado arquivo, não serão utilizados para gravar outro arquivo, mesmo que exista espaço de sobra. Por exemplo: o sistema de arquivos foi formatado para blocos de 1MB, se você cria varios arquivos de 500KB, essa formatação é ineficiente, pois para cada arquivo de 500KB, estão sendo gerados blocos de 1MB, o que significa que metade do espaço disponível está sendo desperdiçado.

Não existe uma matemática exata da relação tamanho de arquivos X blocos, o que vale é o bom senso durante a escolha do tamanho dos blocos a depender do tipo e tamanho de arquivos que serão armazenados nesse disco.

Cíclos de CPU

A operação de leitura de cada bloco consiste em várias etapas que vão desde a localização deste bloco no disco pois os dados geralmente não são sequenciais e são passíveis de fragmentação, reposicionamento de cabeça de agulha e etc.

Quando se lê um arquivo de 1MB em um sistema de arquivos utilizando blocos de 14KB, você estará utilizando aproximadamente 75 ciclos de CPU e o mesmo número de I/O para realizar tal leitura. Cada ciclo de CPU é independente e faz com que aquele “core” fique ocupado e indisponível para outras chamadas até que o ciclo se complete ou seja interrompido (no caso de ciclos preemptivos).  É importante também observar a quantidade de IOPS (I/O Per Second) suportados pelo dispositivo de blocos, pois se chegar no máximo em apenas uma leitura, o desempenho do equipamento estará comprometido para outras operações, principalmente se for um storage que geralmente é compartilhado com outras aplicações e máquinas.

Ao utilizar blocos maiores, você estará diminuindo a quantidade necessária de ciclos de CPU e IOPS e aumentando o uso de banda disponível.  Num senário bastante realista os storages funcionam com fibras a velocidades de 8Gbit, o que resulta em uma largura de banda bastante generosa para acesso a dados, e ao se utilizar blocos maiores, você conseguirá aumentar seu desempenho utilizando esta banda disponível sem precisar sacrificar o processamento de seu hardware.

Vale salientar que…

Para um sistema operacional, é mais fácil gerenciar grandes arquivos do que pequenos arquivos. Já experimentou comparar a cópia de uma arquivo de 1GB e vários arquivos pequenos que resultam em 1GB? A cópia do único arquivo é muito mais rápida, pois o S.O. já tem indexado a localização dos blocos desse arquivo de maneira a antecipar a leitura no disco por exemplo, porém tal operação irá incidir em um maior consumo de banda no disco e memória RAM, enquanto que quando precisamos copiar varios arquivos, o S.O. precisa recorrer ao seu índice saber a localização dos blocos de cada arquivo que irá copiar, reposicionar as agulhas do disco, e então começar a operação de cópia. O mesmo vale para leitura.

Porém, no caso de uma varredura de dados, comum em SGDBs, a quebra dos arquivos grandes em arquivos médios, poderá facilitar tal operação. Pois apesar de otimizar o uso da banda quando precisar realizar um full table scan por exemplo, o mesmo terá de fazer em um blob grande, e em uma única operação, enquanto que utilizando vários arquivos, mesmo num full table scan, o SGDB se beneficiará do paralelismo entre os cores, podendo varrer vários arquivos correspondentes ao dados procurados de uma só vez.

Conclusão

Esse tipo de tuning deve levar em conta o ambiente, o tipo de dados e a proposta de performance que vai se querer extrair do mesmo. No caso de um file server talvez não compense utilizar blocos grandes, pois o número de arquivos menores poderá não compensar e acabar aumentando o gasto de espaço de forma desnecessária, mas no caso de grandes bancos de dados e de discos de máquinas virtuais, por exemplo, deverá sim ser levado em conta o tamanho dos blocos do sistema de arquivos. Atualmente os sistemas já projetados para virtualização vem preparados por padrão para grandes arquivos, como é o caso do VMFS, sistema de arquivos utilizados pelo VMware, que vem com uma blocagem padrão superior ao que é utilizado normalmente em sistemas operacionais comuns. Em resumo: quanto menor o bloco, maior economia de espaço, porém maior será o uso de ciclos de CPU e menor será a otimização no acesso aos dados, quanto maior o bloco, maior será o uso do espaço em disco, inclusive a chance de desperdício de espaço é maior também, porém no caso de acesso aos dados,  é necessário um número menor de ciclos de CPU resultando em maior performance e aproveitamento de banda e memória RAM disponíveis.

E você, o que acha? Me envia um email para ramongadelha@gmail.com e/ou deixa teu comentário logo abaixo deste artigo!

Virtualização: Hypervisors

O hypervisor (ou VMM – Virtual Machine Manager) é o software que gerencia a execução e monitoramento das VMs, bem como sua interação com o hardware físico. É o hypervisor quem fornece recursos virtuais como: memória, processador, disco rígidos, NICs, etc, para que as VMs funcionem adequadamente. Basicamente existem três tipos de hypervisors disponíveis no mercado, dois são baseados na arquitetura x86, e o outro é baseado em System z e System p (Mainframe e Power, da IBM).

Hypervisors x86

Na arquitetura x86, temos dois tipos de hypervisors, são eles: hosted e baremetal.

Hosted

O hypervisor do tipo hosted depende de um sistema operacional para funcionar, ou seja, você precisa ter algum S.O. antes do hypervisor, em que o hypervisor é carregado como um programa qualquer e executado. Esse é o tipo de virtualização utilizada em nossos computadores pessoais (VMware Player, VirtualBox, etc), o mesmo não fornece confiabilidade para uso empresarial, embora muitas empresas se arrisquem ao utilizar, pois o mesmo além de depender de um S.O. qualquer concorrendo assim com todos os outros processos do S.O., ainda fica exposto á possíveis instabilidades e falhas de segurança, além de não ter contato diretamente com o hardware, pois precisa utilizar as APIs do S.O. para isso, impedindo a adição de muitos recursos de alta disponibilidade e aumentando a latência de processamento, acesso  à disco, rede e etc. O que o torna tão popular, é a possibilidade de rodar em qualquer hardware, pois o mesmo já é reconhecido e administrador pelo S.O. em que o mesmo está rodando.

Baremetal

Esse hypervisor cria uma camada fina entre as máquinas virtuais e o hardware do seu servidor. Ou seja, ele é seu próprio S.O., nesse caso, como ele se auto gerencia, é muito mais estável, pois não dependerá de um S.O. para executar suas funções, e como se comunica diretamente com o hardware, o mesmo tem latências e overheads muito menores do que os hypervisors do tipo hosted. Além do mais, o hypervisor tipo baremetal implementa muitos recursos de desempenho e alta disponibilidade extras. Um clássico exemplo, é a possibilidade de se migrar uma VM que está funcionando em um host, para outro host  sem downtime. Esse é o típico ambiente cloud: você sabe que existe uma VM rodando, mas não necessariamente precisa saber onde a mesma está rodando. Ela pode estar rodando em um servidor na sala ao lado, como pode estar em um datacenter ligado via fibra do outro lado do país. Exemplo de hypervisor baremetal: VMware ESXi. A “desvantagem”, é que o mesmo só roda em hardware devidamente homologado, porém, por ser um hardware certificado, garante a confiabilidade e estabilidade à solução.

O gráfico abaixo ilustra a diferença entre os dois tipos de hypervisors:

 

Virtualização “Por Design”

É assim que a IBM denomina sua tecnologia de virtualização disponível para z/OS (System z) e Power (System p). Ela ocorre diretamente no hardware, onde o mesmo é dividido em partições independentes. Por exemplo: seu hardware tem um processador de 16 cores, então você pode pegar 2 cores e entregar para uma partição, assim como também pode micro particionar esta partição já criada. Uma das grandes vantagens, é a possibilidade de rodar alguns tipos de S.O. de arquitetura x86 junto com arquitetura Power, no caso do PowerVM rodando em IBM AIX. O hypervisor nesse caso, fica fora do hardware do servidor, ele nada mais é do que uma appliance (rodando sob x86, com Intel Xeon!), que interage diretamente com o hardware dos servidores Power e System Z.