Novo site

Olá,

Todo o conteúdo deste site foi movido para um novo domínio com infraestrutura própria.

Este blog não será mais atualizado neste endereço!

Novo endereço: http://www.ramongadelha.com.br/

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!

Desmistificando as redes SAN: Noções Básicas.

Com a demanda por espaço de armazenamento de dados aumentando, as redes SAN tornam-se cada vez mais uma realidade nas empresas de todos os tamanhos. Atualmente sua ascensão vem ocorrendo no mercado de SMBs (Small Medium Business), dado que até quatro ou cinco anos atrás raramente viamos um storage ou redes de fibras opticas dedicadas a armazenamento nesse nicho de empresas. As tecnologias mais comuns nas redes SAN são: Fiber Channel, SAS e iSCSI, todas elas servem como meio de transporte para os dados, que diferentemente das redes LAN, em uma rede SAN o que se trafega são blocos ao invés de frames, o que dá a rede SAN uma característica única, uma vez que não podemos utilizar equipamentos feitos para SAN em redes LAN ou vice-versa, a não ser que adotemos algum tipo de encapsulamento como no caso do protocolo FCoE (Fibre Channel over Ethernet), geralmente utilizado em redes ethernet de 10Gbit, assim também como no caso da utilização de iSCSI, que também é considerado uma SAN dentro de uma LAN.

Fiber Channel

O tipo de meio de transporte mais utilizado nas redes SAN, é o Fiber Channel. Para a construção de uma rede SAN utilizando a tecnologia FC, precisamos de switchs SAN, que são switchs especializados em redes de armazenamento, que dispõe de portas onde podemos interligar os sistemas dependentes da rede SAN, nesse caso, os switchs SAN trabalham com uma técnica chamada de zonning, onde é preciso arbitrariamente determinar quais dispositivos podem conversar entre si.

Internamente, nos equipamentos, mesmo sendo FC, o que eles entendem são pulsos elétricos traduzidos em números binários (0 e 1), porém numa rede FC o meio de transporte é a luz, para isso existe um dispositivo chamado GBIC, o mesmo é um transceiver que emite e recebe impulsos de luz, semelhante a uma rede ethernet, o mesmo trabalha em formato RX/TX em dois canais, sendo um “aceso” e outro “apagado”,  para que um GBIC estabeleça a comunicação com outro, o lado aceso de um dos GBICs (TX) deve estar ligado diretamente ligado ao lado apagado do outro GBIC (RX), por isso que nas comunicações realizadas com fibra as mesmas são dispostas em pares. No caso de o RX de um colidir com o RX do outro a comunicação simplesmente não ocorre.

O meio de identificação entre objetos em uma rede SAN é através do WWN (World Wide Name), que assim como o MAC Address, é único para cada dispositivo. O WWN se separa em duas outras sub-entidades, que são o WWNN (World Wide Node Name) e o WWPN (World Wide Port Name). O WWNN identifica o dispositivo em sí na rede SAN, também conhecido como “nó”, e o WWPN identifica a porta do nó em que está tendo alguma conexão. Em uma situação hipotética, em um storage com duas controladoras, cada uma com um módulo de I/O Fiber Channel, teremos no mínimo dois WWNNs, sendo um para cada módulo de I/O, e supondo que cada módulo tenha quatro portas FC, teremos então oito WWPNs, sendo quatro de um módulo e quatro de outro módulo. Dessa forma é possível identificar em que nó e porta desse nó está ocorrendo a troca de dados. Sendo assim, para ficar mais fácil entender, o WWPN é o WWN de uma porta e o WWNN é o WWN de um nó.

Mais Sobre Switch SAN

Os switchs SAN trabalham em malhas de dados, conhecidas como SAN Fabric, a ligação entre dois switchs SAN é conhecida pela sigla ISL (Interlink Switch Link), no qual se faz o “merge” das zonas  configuradas entre os switchs pertencentes a uma mesma fabric. Sendo assim, é possível realizar zoneamento entre switchs diferentes. O ISL geralmente é estabelecido entre switchs da mesma marca e preferencialmente entre modelos e firmwares com versões compatíveis, existe também um modelo de fabric chamado OpenFabric que é capaz de trabalhar em um esquema de interoperabilidade, chamado de “InteropMode” pelos switchs, porém, depende do suporte entre fabricantes, modelos e firmware.

SAN Zones

As zonas garantem segurança e confidenciabilidade nas redes SAN. Um dispositivo ou grupo de dispositivos só poderá enchegar outro dispositivo ou grupo de dispositivos que habitarem uma mesma zona. A principio, as zonas lembram o conceito de VLANs no caso da ethernet, mas é bem mais completo a nível de recursos. Basicamente existem dois tipos de zoneamento: Soft Zoning e Hard Zoning.

Soft Zoning

Nesse tipo de zoneamento criamos uma zona e incluímos os WWNs que estarão autorizados a conversar entre sí, o que dispensa o controle de portas do switch, sendo assim, qualquer porta do switch irá conectar os dispositivos, não importando suas posições. A maior parte dos switchs SAN dispõe de recursos de alias, o que facilita muito o trabalho durante a sua configuração. No esquema abaixo, criamos a zona STORAGE_SPA01_SERVIDOR01_HBA01, que irá permitir a conexão entre o WWN A, representado pelo alias STORAGE_SPA01, que se refere a porta 01 da SPA (controladora primária) do storage, e o WWN B, representado pelo alias SERVIDOR01_HBA01, que se refere a HBA 1 do servidor ’01’.

Nome da Zona: STORAGE_SPA01_SERVIDOR01_HBA01
Alias do Storage (Porta 1 da SPA): STORAGE_SPA01 (WWN A)
Alias do Servidor (HBA 1): SERVIDOR01_HBA01 (WWN B)
Configuração da Zona (Agrupamento de WWNs): STORAGE_SPA01, SERVIDOR01_HBA01

Como podemos observar, a zona criou um grupo de WWNs que irão comunicar-se entre sí, independentemente das portas dispostas no switch, ou switchs no caso de fabric com múltiplos switchs (ISL).

Hard Zoning

Esse zoneamento se basea somente nas portas do switch, não importando os WWNs que estão conectados nas mesmas, sendo assim, nesse caso, as portas e suas posições são sim consideradas, e no caso de uma manutenção física, poderá acarretar em problemas de conectividade. Nesse tipo de zoneamento é importante “amarrar” no storage qual nó poderá acessar quais LUNs, pois independente dos nós que estão conectados nas portas agrupadas, poderão ter trocas de dados.

Nome da Zona: PORTS_01_03_04_06
Configuração da Zona (Agrupamento de Portas): FC_PORT01, FC_PORT03, FC_PORT04, FC_PORT06

Todo ou qualquer WWPN que estiver conectado nessas portas irão se enxergar. Ao contrário da soft zoning, em que a visibilidade é limitada pelos WWNs.

FCoE – Fiber Channel over Ethernet

O FCoE é uma evolução do protocolo FC que permite encapsular o protocolo FC através de redes ethernet. O protocolo veio para simplificar as redes SAN, já que o mesmo permite que o protocolo FC trafegue encapsulado em redes TCP/IP. Assim como o FC tradicional, é possível criar fabrics e trabalhar com zonas, porém o switch envolvido deverá suportar tais características. O FCoE funciona em equipamentos comuns de redes ethernet, não sendo necessário adquirir uma HBA especifica, já que o mesmo funciona também através do conceito initiator e target assim como no protocolo iSCSI, muito embora existam HBAs pensadas exclusivamente para FCoE.

Uma das principais vantagens do FcoE é a possibilidade de convergência de SAN e LAN numa mesma rede, eliminando fibras e equipamentos específicos para FC SAN, o que também significa diminuição de custos em equipamentos e redução de tempo durante as manutenções. Devido a sua característica de funcionar junto a rede LAN, o protocolo é bastante comparado com o já bem conhecido iSCSI, embora, tenham características bem diferentes entre si.

FCIP – Fiber Channel over IP

Esse protocolo, também uma evolução do protocolo FC, também funciona em redes ethernet assim como o seu “primo” FCoE porém tem uma aplicação bastante peculiar, o mesmo é utilizado para conexões entre redes SANs diferentes, uma vez que o mesmo é encapsulado via TCP/IP de uma rede a outra e suporte toda a gama de características de uma rede TCP/IP como roteamento, QoS (Quality of Service). Devido a sua característica é muito utilizado para backup e replicação entre sites diferentes para utilização de soluções de recuperação de desastres.

O FCIP é muito utilizado para complementar a interconexão entre diferentes redes SAN que utilizam iSCSI. Enquanto o iSCSI é o responsável por conectar localmente os hosts ao storage, o FCIP interconecta as redes iSCSI, permitindo que o servidor de uma das redes acesse o storage da outra e vice-versa.

Internet Small Computer System Interface – iSCSI

O iSCSI é basicamente o protocolo SCSI encapsulado via IP, é um meio mais barato para se criar uma rede SAN, porém com menor desempenho e confiabilidade, já que na maior parte das vezes, usam-se switchs compartilhados com outros ativos de rede. A maioria dos fabricantes de storages que suportam iSCSI aconselham a usar uma rede LAN específica para iSCSI SAN afim de garantir que o throughtput total dos switches e da rede como um todo fique disponível para a troca de dados iSCSI.

Em termos, o iSCSI encapsula uma rede SAN através da LAN, onde os comandos originários do protocolo nativo dos dispositivos SCSI são encaminhados via LAN para um storage. Diferentemente das redes FC e SAS a forma de identificação dos dispositivos numa rede iSCSI é via IQN ao invés de WWN.

Ao invés de fabric zones o iSCSI utiliza o conceito cliente (initiator) / servidor (target) com autenticação CHAP. O protocolo permite ao ‘initiator’ enviar comandos SCSI (CDBs) para o ‘target’ através de uma rede IP. Como é uma rede utilizada exclusivamente para tráfego de dados, é considerada uma rede SAN.

iSCSI Qualified Name – IQN

O formato IQN é um padrão documentado na RFC 3720 e é composto dos seguintes campos:

1. O literal IQN;
2. Data (aaaa-mm) em que a autoridade de nomeação (naming authority) tomou propriedade do domínio;
3. Domínio de autoridade em ordem reversa (exemplo: com.example);
4. Particula opcional separada por “:” contendo o target name.

Abaixo quebramos um IQN em partes para ilustrar:

IQN inteiro: iqn.1992-01.com.example:storage:diskarrays-sn-a8675309

1. Type = iqn
2. Date = 1992-01
3. Authority Naming: com.example
4. Optional Particle: storage:diskarrays-sn-a8675309

Hardware

Assim como nas redes FC e SAS, uma rede iSCSI também pode ter hardware dedicado a tal, como por exemplos HBA iSCSI, em que a própria HBA faz o trabalho de conexão com o target entregando ao ‘initiator’, o dispositivo de blocos como se fosse um disco local, assim como faz a tecnologia FC. Caso seus servidores não possuam HBAs iSCSI, o próprio sistema operacional fará o papel de initiator e irá gerenciar a conexão com os targets iSCSI.

Para se obter um bom desempenho nas redes iSCSI, geralmente se trabalha com switchs de no mínimo 1Gbit/s, sendo o recomendado de 10Gbit/s porém, mesmo em uma velocidade alta (10Gbit/s) a latência é maior do que em uma rede FC, logo a preocupação com equipamentos LAN e cabeamento de qualidade é ainda maior.

Na maioria das redes iSCSI é extremamente recomendado o uso do recurso de Jumbo Frames, no  qual aumentam drasticamente o tamanho dos frames trafegados pela rede LAN, porém tanto os switchs, quando as NICs e os sistemas operacionais envolvidos tem que suportar tal modo. O Jumbo Frames aumenta o MTU de 1500 para 9000.

Autenticação

Para initiator e target se comunicarem, é necessário antes estabelecer uma relação de confiança, a mesma é iniciada através de autenticação. O protocolo utilizado trata-se do CHAP, velho conhecido, utilizado no passado em redes Dial UP. No caso do iSCSI, não é possível autenticar em CHAP utilizando texto plano (ou “cleartext”), pois o mesmo permitiria que um ataque do tipo man-in-the-middle capturasse facilmente os dados de autenticação e iniciasse um ataque.

Infelizmente o protocolo CHAP é conhecido por suas vulnerabilidades, pois o mesmo é sensível a ataques conhecidos como força bruta e spoofing, logo a rede que preparada para o iSCSI deverá ser dotada de níveis de seguranças para diminuir a chances de potenciais ataques. Uma das formas utilizadas é a implementação de VLANs onde se trafegam os dados iSCSI, para isolar totalmente a rede SAN da rede corporativa, em alguns casos se usa IPSec, no entanto, adiciona uma camada a mais na comunicação, o que pode gerar um aumento na latência.

Jumbo Frames

É considerado um Jumbo Frame quando um pacote em uma rede ethernet ultrapassa a casa dos 1500 bytes de carga, e chega ao máximo de 9000 bytes. Sua utilização é muito comum em redes FCoE e iSCSI devido a necessidade de menos ciclos de CPU para processar as requisições.

Em redes ethernet, as informações são separadas em frames, cada frame contém o tamanho especificado pela MTU que foi configurada para essa rede, a MTU dirá o tamanho dos pacotes que deverão trafegar por toda a rede. Se o pacote de uma carga mínima de 1500 bytes e a informação contém apenas 1000 bytes, tal informação será empacotada em um frame de 1500 bytes, ou seja, a informação faltante será preenchida com zeros para completar um frame. Já no caso de uma rede que utiliza MTU de 1500 porém a informação contém 3000 bytes, a mesma será quebrada em dois pacotes de 1500 bytes e será despachada para seu destino. No caso do Jumbo Frames, acontece a mesma coisa, só que com uma carga maior. Em redes que não demandam MTUs acima de 1500 bytes, é recomendado que tal funcionalidade seja desativada, pois quanto maior o MTU envolvido, maior é o consumo de banda na rede, fazendo seu uso vantajoso apenas quando se usa uma rede ethernet para trafegar dados pesados, como por exemplo blocos de dados.

O Jumbo Frame é vantajoso porque quanto mais pacotes, mais ciclos de processamento serão consumidos para processar tal informação. Se dividirmos por exemplo 1Gbit (1073741824 bytes) por 1500 bytes, serão necessários cerca de 715828 ciclos para processar tal informação, isso inclusive afeta a capacidade de processamento não só dos servidores e storages, mas também dos switchs. Já em uma rede que faz uso de Jumbo Frames a 9000 bytes, usaremos apenas cerca de 119305 ciclos de processamento para compreender a informação de 1Gbit, ou seja  596523 ciclos a menos, isso em grande escala significa maior desempenho, menor custo de processamento e menos IOPS (I/O Per Second), lembrando que cada ciclo tem o custo de 1 I/O.

Como o Jumbo Frame aumenta a quantidade de banda utilizada, exigirá ainda mais dos switchs, interfaces de redes e cabeamento, que é um ponto importantíssimo para se obter sucesso no emprego da estratégia de Jumbo Frames.

Serial Attached SCSI – SAS

A tecnologia SAS é uma evolução do SCSI trazendo mais desempenho e confiabilidade, geralmente discos Tier 2 nos storages são de tecnologia SAS. Em redes SAN, o SAS tem sua aplicabilidade principalmente em conexões entre dispositivos e é mais utilizada ainda para dar escalabilidade a storages.

É muito comum encontrar por exemplo bibliotecas de fita LTO (Tape Library) conectada via SAS a um servidor através de uma HBA SAS do tipo PCI Express. Nesse caso, a biblioteca está fazendo o papel de DAS (Directly Attached Storage), o que poderiamos chamade SAN “ponta a ponta” em termos de analogia, já que essa rede funciona apenas entre dois dispositivos.

Já na área de escalabilidade, ela é a principal tecnologia utilizada para expansão de storages. Quando vai se adicionar uma nova “gaveta” (enclosure) ao storage existente, se utilizam cabos SAS para interconectar estas gavetas, de modo que se cria uma rede SAN no próprio equipamento. Geralmente a expansão de gavetas é feita em série, ou seja, Gaveta 1, que expande para a Gaveta 2, que expande para a Gaveta 3. No caso de um equipamento da EMC, o VNX5300 ficaria: DPE → DAE01 → DAE02 → DAE03. A imagem abaixo mostra a parte de tras de um VNX, sendo a primeira gaveta (de baixo para cima) a DPE, que é onde fica a primeira leva de discos e logo acima duas gavetas de expansão (DAEs) interligadas via cabos SAS.

Network Attached Storage – NAS

O NAS é um conceito diferente de storage, enquanto na SAN o dado trafegado é tratado a nível de blocos, não importando o tipo de arquivos, muito menos o tipo de sistema de arquivos, o NAS já funciona em camada a nível de aplicação, pois já tem um sistema de arquivos definidos e seus compartilhamentos de rede feitos através dos mais conhecidos protocolos como CIFS e NFS. A tendência atual é de que os storages unifiquem a parte de SAN e NAS em uma só solução.

Directly Attached Storage – DAS

O DAS é basicamente uma SAN ponto-a-ponto, no caso de hosts diretamente ligados as portas dos storages sem passar por switchs e por consequência sem zoneamento. Na maioria das pequenas e médias empresas ainda se utiliza DAS pois a depender da demanda, o custo é menos elevado do que uma rede SAN, porém com a multiplicação de servidores e exigência de sistemas com elevados níveis de redundência de dados, os switchs SAN estão sendo cada vez mais utilizados, no caso da tecnologia FC.
No caso de se utilizar iSCSI também vale o conceito DAS e SAN, porém ao contrário do FC, no iSCSI pode-se utilizar switchs ethernet comuns para a comunicação entre vários servidores e storages.

Conclusão

Existem várias maneiras e recursos para se viabilizar uma rede SAN. Cada protocolo tem sua aplicabilidade que irá variar dependendo do objetivo e dos custos envolvidos na rede. Em redes pequenas que não exijam tanto tráfego, redes iSCSI podem ser o suficiente, porém em redes medianas a recomendação já é caminhar para a tecnologia FC, que provem excelente desempenho e confiabilidade.

Tudo isso tem que ser estudado de acordo com o tipo de rede e equipamentos que serão utilizados, um storage por exemplo dependendo do modelo e dos Tiers de discos utilizados, talvez funcione muito bem em iSCSI, porém ao se investir em FC no mesmo equipamento é possível não sentir ganho de performance e sim queda, pois a velocidade dos discos, cache e processadores do storage influem no desempenho final, assim como pode ocorrer o contrário, um storage ser subutilizado devido o uso de iSCSI ao invés de FC que nesse caso aproveitaria todo o potencial do mesmo. Cada rede tem suas características, aplicabilidades e valor a ser investido.

Running EMC Unisphere Service Manager natively on Linux

I was installing a new EMC VNX 5100 Block on a customer and was using a Linux distribution for others tasks. I was too lazy to reboot and switch to Windows to open Unisphere and continue with the installation, so I thought: USM is written in Java, why don’t  make it run on Linux? Well, EMC says it is compatible with Windows, but hypothetically it may run on Linux, just need some tweaks, so I did it. First you’ll need to download EMC Unisphere and install it with WINE, it will show some warnings about the JRE, so just ignore it and continue with the “next-next-finish” phylosophy.

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.

 

Virtualização: Visão Geral

Nos dias de hoje, estamos vivendo um verdadeiro BOOM no que diz respeito a tecnologias de virtualização. No entanto, os seus primórdios sejam de décadas atrás, com os mainframes IBM, dos quais, “particionava” seu hardware em partições independentes e isoladas, nascendo aí o que se chama hoje em dia de “virtualização por design”, presente inclusive nas linhas IBM Power, o PowerVM. No entanto, com o ganho de performance e confiabilidade da arquitetura x86, a virtualização se popularizou e hoje é  utilizada em larga escala. O conceito de “cloud computing” é outro fator que está muito ligado à virtualização, e está popularizando mais ainda a tecnologia.

Na prática, a virtualização nada mais é do que ter um computador executando vários S.Os ao mesmo tempo de forma independente, porém, na prática existem muitos fatores a serem levados em consideração na hora de implementar seu ambiente virtual.

Como quase toda inovação tecnológica, o seu principal objetivo é a diminuição de custos pela utilização total do hardware existente. Ou seja, se antes você tinha dez servidores, cada um rodando um serviço diferente, você pode ter dois servidores mais robustos rodando todos estes serviços ou até mais. O que ocorria é que estes dez servidores, na maioria dos casos, eram subutilizados durante a maior parte do tempo, e o pior, quanto mais hardware, mais custo de energia, manutenção e recursos humanos para operar tudo isso, com a virtualização você faz seu hardware trabalhar e realmente “pagar” aquilo que ele consome em energia e manutenção, e lhe consumiu durante sua aquisição, além disso, dois servidores consumem muito menos do que dez! Outra característica que agrega valor à virtualização é a alta disponibilidade. Como praticamente em 80% dos ambientes virtualizados se tem storages, as máquinas virtuais ficam armazenadas no mesmo, e suas LUNs são compartilhadas entre os hosts, sendo assim, caso um host venha a cair, o outro assume as VMs que estavam no host que caiu.

Na virtualização, quem orquestra as VMs (Virtual Machines / Máquinas Virtuais), são os hypervisors, para um hypervisor, uma VM nada mais é do que um processo, e seu disco, é apenas um arquivo virtual. Alguns hypervisors permitem o “bypass” e criam acesso direto à disco ou LUN, conhecido como Raw Device Mapping (no VMware).

No próximo artigo falarei sobre os tipos de hypervisors e as diferenças entre eles.

XtraBackup: backup no MySQL “no quente”, sem read lock

O MySQL tem um utilitário muito utilizado para backups, sendo bastante versátil para bases pequenas, que é o mysqldump. Mas quando se tem uma base grande e de alta criticidade, ou seja, não pode parar de maneira alguma, aí aparecem os problemas com o utilitário mysqldump. Podemos contar alguns de seus principais problemas:

• Lento para fazer backup de grandes bases;
• Lento para efetuar restore, principalmente quando se usa InnoDB;
• O conteúdo do backup, como o próprio nome da ferramenta sugere, é um DUMP, é todo em texto ASCII, o que o torna inseguro e pesado, já que a leitura e gravação de dados em ASCII é bem mais lenta do que em binários;
• E o principal: trava as tabelas durante o backup, tornando partes do banco temporariamente indisponíveis.

Existe uma ferramenta paga, conhecida como MySQL Enterprise Backup, que realiza os backups “no quente”, sem travamentos e garante sua consistência. O grande problema, é que essa ferramenta é paga e cara, nem todo mundo está disposto a pagar.

Mas, para a felicidade de todos, existe um clone Open Source do MySQL Enterprise Backup chamado de XtraBackup desenvolvido pela Percona, uma empresa especializada em consultoria  de banco de dados MySQL. O mesmo está disponível para uma variedade de distribuições Linux, bastando acessar o site do produto para obter informações de instalação.

Neste artigo não irei abordar a instalação do produto, pois a mesma pode variar de acordo com sua plataforma.

Mãos à Obra

Uma vez instalado, tomaremos como base o comando abaixo para a realização do backup:

# innobackupex –stream=tar –defaults-file=/etc/my.cnf –user=usuario –password=senha ./ | gzip -c -9 > $BDIR/backup.`date +%m%d%Y%H%M%S`.tar.gz

Agora aguarde o resultado, se tudo ocorrer bem, seu backup será executado como previsto.

Abaixo, um pequeno script para ajudar a automatizar as coisas, podendo ser inclusive agendado no crontab para sua execução automática:

#!/bin/bash

# 19022012 – Written by Ramon Gadelha
# This script uses xtrabackup utility to hot backup mysql databases in a non-halt mode

BDIR=”/home/backup/mysql”
USER=”xtrabackup”
PASSWORD=”xtrabackup”
CONFIG=”/etc/my.cnf” 

# Run backup

innobackupex –stream=tar –defaults-file=$CONFIG –user=$USER –password=$PASSWORD ./ | gzip -c -9 > $BDIR/backup.`date +%m%d%Y%H%M%S`.tar.gz

# Remove backups older than 7 days
find $BDIR -name backup.\* -ctime +7 -exec rm {} \;

Espero que esse artigo tenha lhe sido útil.

Migração de grande quantidade de dados em storage bloco-a-bloco de forma rápida com Linux e DD

Salve, após um certo tempo de hiato, estou de volta para postar coisas interessantes e úteis (no meu ponto de vista) para quem se interessar.

Migração de grandes quantidades de dados pode ser algo cansativo e traumático dependendo das condições e prazos que se tenha para fazê-la. Num senário como este, nem sempre se dispõe de soluções apropriadas para tal tipo de tarefa, então torna-se necessário improvisar de maneira coesa e simples. Passei por uma situação parecida tempos atrás e pensando nisso, peguei parte da documentação que criei para tais procedimentos e preparei esse pequeno e simples artigo, do qual espero que lhe seja útil.

O Cenário

A sua estrutura dispõe de dois storages, um que já está em produção, e outro novo, que irá substituir o atual e você tem apenas parte do final de semana para migrar aproximadamente 4TB de dados de um para o outro.

Equipamentos envolvidos:

2 Storages;
1 Servidor com duas HBA FC a 8gbit/s;
2 Pares de fibra ligando cada HBA do servidor a dos storages a 8gbit/s.

Software:

Linux (o cara!);
DD (o salvador!);
iostat (para monitorar a entrada e saída de dados).

Aprovisionamento

Primeiro deve-se provisionar o novo storage, de acordo com o antigo, mesma quantidade de LUNs e tamanhos, quanto mais identicos eles forem entre si, mais fácil será identificá-los no Linux.

Estratégia

A estratégia a ser utilizada, vai ser apresentar LUN a LUN. Por exemplo, no storage atual, existe a LUN VMW_R5_DADOS, então apresentamos a LUN ao Linux, e verificamos com o comando ‘fdisk -l’. O mesmo irá mostrar o novo dispositivo (que é a LUN do storage atual) e suas partições. Nesse exemplo, o dispositivo será o /dev/hdb. Logo após, repita o mesmo passo no storage de destino, e agora o comando ‘fdisk -l’ irá listar os dois storages, vamos assumir para este artigo que o dispositivo de destino será /dev/hdc.

Plano de ação

Após apresentar as LUNs pro host, podemos iniciar o trabalho:

dd if=/dev/hdb of=/dev/hdc

Observe que a migração começou, mas está indo de forma bastante lenta. Por que? O DD migra dados por padrão em blocos de 512 bytes, para alguns dispositivos comuns, essa velocidade é o bastante, mas como estamos falando de dispositivos de Enterprise Level, com HDs SAS 15K RPM e FC a 8Gbit/s podemos “esticar” um pouco, e colocá-lo para migrar em blocos de 8 a 16k.

dd if=/dev/hdb of=/dev/hdc bs=8k

Após isso, devemos observar a taxa de I/O com o comando ‘iostat’, caso seja satisfatória, podemos deixar como estar, ou ir incrementando até 16k, que é um nível que não causa muito enfileiramento nessa velocidade. No caso, eu consegui copiar cerca de 1TB a cada 1h. O DD simplesmente copia, ele não sabe o que é filesystem ou arquivos, sua cópia é totalmente baixo nível, com acesso direto aos dispositivos.

Atenção: quanto maior o block size, mais memória RAM consumirá do host. Se seu host tem acima de 16GB de RAM, pode ficar despreocupado, caso contrário, é recomendável monitorar para ficar entre o ideal e o responsável.

Vale observar que: o ‘dd’ não faz tarefas de compressão de dados, muito menos checagem de erros de I/O, então tome o cuidado de fazer backup antes e verificar a consistência dos dados após cada migração.

Postfix: balanceando carga de e-mails de saída entre vários links.

Existem várias razões para se balancear a carga de saída de e-mails. Por exemplo, você pode ser um grande  ESP (Email Service Provider) e  cada Postfix seu fica atrelado à um só link e o mesmo já está “topado”. Ou você quer uma situação que garanta que as mensagens irão sair, mesmo se um dos links caírem. Com o método que irei demonstrar neste artigo, você poderá quantos links de saída quiser.

Para tal, iremos precisar do Postfix compilado com suporte a MySQL. Mas por que MySQL? Porque nele está a solução!

Como isso funciona?

O Postfix permite que você crie vários transports de saída e entrada, mas pode originalmente sair apenas por um transport padrão, e o resto terá que ser mapeado na rasão ‘dominio -> transport’ através da diretiva transport_maps. O que iremos fazer, é criar um banco de dados simples, com uma Stored Function que irá dizer ao Postfix via transport_maps por qual transport a mensagem irá sair, e tal transport estará usando um link especifico.

Coletando as informações necessárias:

Quantos links você tem, por quais você irá querer que as mensagens sejam disparadas? Para este artigo, imaginei a seguinte situação:

Link 1 – IP: 1.1.1.1
Link2 – IP: 1.1.1.2
Link3 – IP: 1.1.1.3

Mãos à obra!

Considerando que você já tem Postfix e MySQL devidamente instalados, iremos configurar o Postfix, primeiramente o arquivo máster.cf para definir os transports de saída. No caso, eu quero usar meus três links disponíveis para enviar mensagens, então, devo criar três transports independentes para tal:

L1      unix    –       –       n       –       –       smtp

  -o smtp_bind_address=1.1.1.1

L2      unix    –       –       n       –       –       smtp

  -o smtp_bind_address=1.1.1.2

L3      unix    –       –       n       –       –       smtp

  -o smtp_bind_address=1.1.1.3

Pronto, criei três transports, são eles L1, L2 e L3.

Agora iremos criar um banco de dados chamado Postfix com duas tabelas:  current e transports.

CREATE DATABASE `postfix`;

CREATE TABLE `current` (
`transportId` int(10) DEFAULT NULL
) ENGINE=MyISAM;

CREATE TABLE `transports` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`transport` varchar(50) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`id`)
) ENGINE=MyISAM;

Criadas as tabelas, iremos agora criar uma stored function, é ela quem irá dizer ao Postfix por onde a mensagem deve ser disparada, efetuando então, o balanceamento de carga.

CREATE FUNCTION `f_transport`() RETURNS varchar(50) CHARSET latin1
BEGIN
DECLARE current_transport INT(11);
DECLARE count_transport INT(11);
DECLARE result varchar(50);

SELECT * INTO @current_transport FROM current;
SELECT count(*) INTO @count_transport FROM transports;

IF @current_transport < @count_transport THEN
SELECT @current_transport + 1 INTO @current_transport;
ELSE
SET @current_transport = 1;
END IF;

UPDATE current SET transportId = @current_transport;

SELECT transports.transport INTO @result
FROM transports,current
WHERE transports.id=current.transportId
AND transports.id = @current_transport;

RETURN @result;

Feito isso, iremos agora cadastrar no MySQL, os transports criados la no master.cf. O nome do transport deverá ser sempre finalizado com ‘:’.

INSERT INTO transports (transport) VALUES (‘L1:’);
INSERT INTO transports (transport) VALUES (‘L2:’);
INSERT INTO transports (transport) VALUES (‘L3:’);

Uma vêz terminada a configuração do MySQL, voltamos ao Postfix, mais especificamente no arquivo main.cf, onde iremos adicionar a diretiva:

transport_maps=mysql:/etc/postfix/mysql-transports.cf

Logo após, criamos o arquivo mysql-transports.cf em /etc/postfix com o seguinte conteúdo:

hosts=ip_do_mysql
user=usuario_do_mysql
dbname=postfix
query=SELECT f_transport() as transport

Uma vez feito, reinicie o Postfix para que as alterações surtam efeito:

# postfix stop
# postfix start

Pronto, se você tiver seguido este artigo de forma criteriosa, seu Postfix já deverá estar balanceando a carga entre os links. Basta monitorar as suas interfaces de rede. Não se esqueça de conferir os logs pra ver se tudo está indo como o esperado.

Convertendo videos facilmente com o Mencoder.

Feriadão aqui em Fortaleza, pouco dinheiro pra gastar, ou seja, passar mais tempo em casa, resultado ? Filmes e mais filmes.

Baixei alguns filmes e seriados para assistir na minha TV, mas alguns formatos, como RMVB por exemplo, não são suportados pelo firmware da TV. Logo, tive que procurar uma solução para converter esses videos para um formato suportado por ela, por exemplo, MPEG4.

Pesquisando, encontrei o mencoder, após umas lidas nos manuais e pesquisas na internet, encontrei o conjunto de parâmetros necessários para iniciar a conversão.

# mencoder arquivo.rmvb -oac mp3lame -lameopts preset=128 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1200 -ofps 25 -of avi -o arquivo.avi

Depois disso, é só esperar… 😛

No meu caso, agilizei ainda mais, pois eram muitos vídeos para serem convertidos, então, usei um pouco de shell scripting a meu favor:

# ls -1 *.rmvb | while read arquivo ; do mencoder $arquivo -oac mp3lame -lameopts preset=128 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1200 -ofps 25 -of avi -o $arquivo.avi ; done

Então, eu ia abastecendo o pendriver com os videos já convertidos, assistia, voltava no pc e copiava outros videos ja convertidos pro pendriver, enquanto o restante ainda era convertido, simples não?

Fica aí a dica! 😉