Arquivo

Archive for the ‘Uncategorized’ Category

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/

Anúncios
Categorias:Uncategorized

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.
Image
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.

Image

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.

Categorias:Uncategorized Tags:

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.

Leia mais…

Categorias:Uncategorized

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.

Categorias:Uncategorized

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

fevereiro 21, 2012 6 comentários

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.

Categorias:Uncategorized

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

fevereiro 12, 2012 Deixe um comentário

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.

Categorias:Uncategorized

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

outubro 13, 2011 16 comentários

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.

Categorias:Uncategorized