Linode.com – upgrade sem custo!

A Intercom utiliza VPS (“Virtual Private Server”) da Linode.com desde 2009. A reputação da Linode é ótima, tanto na plataforma de hw/sw quanto na qualidade de suporte.

Mas a Linode se superou recentemente: ofereceu upgrade gratuito a todos os clientes, dobrando a memória, CPU e tráfego mensal para TODOS os servidores!

Todos os servidores da Intercom foram migrados de forma previsível e sem nenhum percalço. Linode.com está de parabéns!

Estudo de caso AWS – Mubisys

Em Março/2013, a Intercom entregou mais um projeto que ilustra as vantagens de “cloud computing”.

Um novo cliente, Mubisys, procurou a Intercom para implementar um servidor Linux, para hospedar um sistema LAMP de impressão, em fase final de desenvolvimento. As premissas do projeto foram:

  • rapidez no provisionamento da infra-estrutura
  • custo baixo de operação inicial
  • segurança de dados
  • flexibilidade para upgrade

Após pesquisar diversos IDCs tradicionais e provedores “cloud computing”, a seleção de fornecedor contou como finalistas a Amazon Web Services e Linode.com. A escolha final foi AWS, pelo quesito de flexibilidade para upgrade.

O processo completo de provisionamento e implantação do servidor Linux foi executado em 2 dias úteis. A EC2 escolhida foi m1.large, na região US East. Ao término do 2o. dia, o sistema LAMP já estava em operação, já com HTTPS, e o desempenho do sistema foi avaliado como muito satisfatório.

Atualmente o sistema LAMP já se encontra em produção, e desejamos sucesso à Mubisys.

 

Estudo de Caso – rede Linux, Editora Manifesto

Nesta semana, tivemos a satisfação de entregar uma rede 100% Linux na Editora Manifesto, que publica a revista Retrato do Brasil.

A Editora utilizava uma rede LTSP adquirida da empresa Samurai em 2001. A tecnologia e a rede eram muito estáveis, mas a plataforma de HW e SW estava defasada, tanto em velocidade de processamento quanto em novas tecnologias Internet (streaming, flash, HTML5, etc.), além de crescente dificuldade de manutenção.

O projeto do upgrade tecnológico teve os seguintes pontos de partida: baixo custo, estabilidade e gerenciamento centralizado.

A Editora adquiriu um lote minibooks Intel ATOM dual-core como desktops, com 2GB de RAM e 320GB de HD Sata2, que forneceria um desempenho compatível com as necessidades dos usuários. O servidor escolhido foi HP ML-110G7. Todos os equipamentos foram fornecidos pela Bluetech.

Os desktops foram instalados com Ubuntu Desktop 11.04 LTS, o qual oferece uma alternativa robusta, moderna e atraente ao Microsoft Windows, além do conjunto de softwares de produtividade (browser, email, editor de texto, planilha eletrônica) competitivo e gratuito.

O servidor é um capítulo à parte. Pela premissa de gerenciamento centralizado, decidiu-se implementar diretório OpenLDAP 2.4 como backend de autenticação de todos os desktops, com transporte seguro via TLS. O gerenciamento de contas de usuários ficou a cargo do LDAP Account Manager (LAM), um aplicativo PHP. Finalmente, o serviço NFSv4 fornece o mapeamento transparente das pastas de trabalho locais aos desktops Ubuntu a um compartilhamento centralizado no servidor, facilitando os procedimentos de backup.

Este projeto foi concebido, definido, implementado e implantando em um mês, e demonstra a convergência entre tecnologia de ponta, custo contido e facilidade de gerenciamento de operação num ambiente Linux.

 

Amazon EBS Snapshot Copy

Em meados de Dezembro/2012, Amazon Web Services anunciou uma facilidade adicional para Elastic Block Store (EBS): a função Snapshot Copy permite que snapshots EBS possam ser copiados facilmente entre diferentes regiões de disponibilidade AWS.

Antes desta facilidade, a cópia de um EBS (ou de um snapshot) de uma região para outra envolvia um processo tortuoso. Era necessário anexá-lo a uma instância EC2 Linux, na região-origem; criar um novo EBS do mesmo tamanho e anexá-lo na região-destino a uma instância EC2 Linux, e depois utilizar o comando dd para copiar bloco-a-bloco do EBS-origem, via ssh, ao EBS-destino (ex. dd if=/dev/sdg | ssh -i root-key root@destino “dd of=/dev/sdf”)

Para usar esta nova facilidade, basta acessar o console de gerenciamento AWS, selecionar um snapshot para cópia, definir a região-destino, e comandar o início da cópia. Esta função de cópia pode ser iniciada via linha de comando, através da EC2 Command Line Interface, facilitando sua execução em modo batch. O snapshot copiado para a região-destino é como qualquer snapshot, e poderá ser usado para criar novos volumes EBS para serem anexados a instâncias EC2.

Esta função facilita o uso de múltiplas regiões de disponibilidade AWS para diversas finalidades, como entregar aplicações web em várias regiões geográficas, migrar aplicações de datacenter, implementar plano de recuperação de desastre, etc.

Amazon Glacier – Arquivamento de elevado volume

A área de tecnologia de qualquer empresa tem que lidar com volume cada vez maior de dados ativos (documentos, planilhas, emails – ninguém deleta mais emails hoje em dia -, vídeo de treinamento, gravações de ligações de voz, etc.). Como consequência, o arquivamento desta grande massa de dados – por períodos determinados por lei ou pelas boas práticas de governança – está se tornando um processo trabalhoso e caro, requerendo cada vez mais tempo e esforço na escolha da tecnologia (fita, disco, mídia óptica), no planejamento de capacidade, na manutenção de hardware e na negociação com fornecedores.

A Amazon Web Services apresentou recentemente um serviço de arquivamento, denominado Glacier, que interessará a muitos profissionais de TI. Com Glacier, qualquer volume de dados poderá ser arquivado de forma durável e fácil, e a um custo extremamente competitivo com as mais tradicionais bibliotecas de fitas e robôs, que formam o esteio das soluções de arquivamento há décadas.

Glacier oferece armazenamento para arquivamento de dados a um custo extremante baixo – até US$ 0,01 (um centavo de dólar) por Gigabyte por mês. Pode ser usado para qualquer volume, de megabyte a terabytes a petabytes, e não ná nenhum custo para setup inicial. Glacier acaba com as preocupações tradicionais de acerto no “capacity planning”, de falta de espaço para arquivamento, de verificar a integridade de hardware e dados, e de planejar redundância geográfica no arquivamento – independentemente do período de retenção do arquivamento.

Para começar a arquivar dados usando Glacier, basta criar um vault (em tradução livre, uma caixa-forte) e nomeá-lo. Cada região AWS permite até 1.000 vaults. Assim que criar o vault, basta fazer upload de dados, e estes serão organizados em arquivos (pela nomenclatura AWS). Cada arquivo pode conter até 40TB de dados, e há múltiplas maneiras de fazer upload. Os dados enviados serão criptografados com AES-256, e armazenados em formato de elevadíssima durabilidade. Glacier executará checagens regulares de integridade, e corrigirá eventuais erros de forma automática.

Para restaurar os dados, basta enviar um job para Glacier. O Amazon SNS poderá ser programado para avisá-lo assim que os dados estiverem disponíveis para download. Os dados pederão ser acessados via solicitações de HTTP GET.

Os custos do serviço Glacier estão aqui.

Atualmente, Glacier está disponível nas regiões S-East (N. Virginia), US-West (N. California), US-West (Oregon), Asia Pacific (Tokyo) e EU-West (Irlanda).

 

Estudo de Caso – Migração de Domínio CONAB

Neste final de semana passado, finalizamos com grande sucesso a migração de domínio para nosso cliente CONAB.

A CONAB possuía um servidor Linux SAMBA 2.2 com quase uma centena de usuários, trabalhando com várias versões MS Windows desktop (XP, Vista, 7) e thin-clients com MS Terminal Services em servidores Windows 2003 e 2008.  O servidor Linux SAMBA 2.2 foi instalado há aprox. 6 anos, e implementava um domínio NT, autenticando usuários para acesso a recursos de rede. Com o crescimento do volume de dados e envelhecimento de hardware, um novo servidor Samba tornou-se necessário, além da necessidade de acomodar desktop MS Windows 7.

A Intercom propôs instalar um servidor Samba 3 com OpenLDAP como backend de autenticação, fornecendo hardware novo HP via faturamento direto Officer.

A migração de Samba 2 em servidor existente para Samba 3 em novo servidor implica em migração de domínio Windows. Depois da instalação e configuração Samba + OpenLDAP, intensos testes de migração de domínio foram executados em todas as versões de desktop Windows e de servidores Windows Terminal Services, para certificar os procedimentos envolvidos (migrar emails, arquivos e ícones de desktop) e documentá-los. Atenção especial foi dada aos múltiplos mapeamentos de unidade de rede, pois a  localização de arquivos via unidades de rede era usada em múltiplas planilhas Excel e dentro do sistema ERP. A Intercom sugeriu a adoção da notação Windows UNC – Universal Naming Convention para localização de arquivos no novo servidor.

Os controles de acesso a compartilhamento e arquivos no servidor Samba 2.2 haviam evoluído ao longo do tempo sem muito planejamento, e deixaram atender às novas necessidades da empresa. A equipe de TI da CONAB aproveitou a oportunidade da implantação de novo servidor para re-estruturar estes controles, e a Intercom prestou importante consultoria neste trabalho, que resultou numa estrutura de controle ao mesmo tempo sofisticado mas de simples administração e manutenção. Foi instalada a interface gráfica LAM (LDAP Account Manager) para facilitar o gerenciamento de usuários e grupos.

A implantação do novo servidor Samba 3 foi efetivada num único final de semana, com pequenos ajustes técnicos de última hora (exemplo: usuários de Windows Terminal Server 2003 não conseguiam selecionar a impressora padrão – problema tratado no MS Knowledge Base 933996). No primeiro dia de operação de produção, houve necessidade apenas de pequenos ajustes no controle de acesso (alguns mapeamentos de drives e mudanças de usuários e grupos). O sucesso desta implantação é resultado, em grande parte, do extenso trabalho de preparo e testes realizado pela equipe da Conab e pela Intercom.

A Intercom tem muito orgulho por este projeto, e parabeniza a equipe da Conab pelo sucesso da sua execução.

Como bloquear Facebook? MSN? Twitter?

Facebook e Twitter facilitam o destaque da sua empresa nas mídias sociais, mas seus funcionários produzem menos porque passam muito tempo postando no Facebook ou “twittando”? ou ficam batendo papo com amigos e parentes via MSN ou Skype?

Um servidor proxy Linux permite facilmente bloquear ou liberar acessos a mídias sociais,  a programas de chat, ou a qualquer site ou conteúdo Internet. Os controles podem ser baseados por computador, por grupo de funcionários, por horário, por tipo de palavra-chave, etc. E relatórios detalhados mostram claramente o que cada pessoa faz na Internet durante o dia.

Entre em contato conosco para saber mais detalhes sobre esta ferramenta importante!

vTiger CRM

Conforme seu crescimento, qualquer empresa depara com a necessidade da escolha de uma ferramenta CRM. A Intercom já utiliza Best Practical Request Tracker como issue-tracker; agora chegou a vez de escolher uma ferramenta CRM para as áreas comercial e marketing.

Wikipedia define CRM como “um modelo largamente utilizado para gerenciar as interações de uma empresa com clientes, contatos e prospecção de vendas. Envolve o uso de tecnologia para organizar, automatizar e sincronizar práticas de negócios – principalmente para atividades de vendas, mas também aquelas para marketing, atendimento a cliente e suporte técnico”.

Uma simples pesquisa no Google mostra uma enorme gama de alternativas. Existem os nomes de pesos-pesados (Oracle CRM, SalesForce, Microsoft Dynamics CRM), existem os inúmeros produtos de empresas menores, existem os GPL e/ou “community” (SugarCRM, Vtiger,Compiere, Cream), e existem os baseados em modelo SaaS (Zoho,  Salesforce Cloud, Microsoft Dynamics Cloud).

Optamos por instalar nosso próprio servidor CRM por várias razões: queremos uma aplicação LAMP; já temos uma estrutura de servidores cloud – web, banco de dados, DNS, email, etc.; temos extenso know-how técnico; não queremos guardar dados comerciais em provedores SaaS; e não queremos ter custos recorrentes adicionais. No final, a escolha ficou entre SugarCRM e vTiger. Pela comparação entre os dois, optamos por vTiger.

O processo de instalação foi surpreendentemente fácil. Baixamos o código (atualmente, versão 5.4.0), copiamo-no na pasta adequada e setamos devidamente owner para apache:apache, e apontamos o browser para iniciar um wizard de instalação. Após alguns poucos passos (upgrade ou instalação, verificação de requisitos PHP – alguns parâmetros exigidos pelo Vtiger são contrários aos recomendados em php.ini para sistemas de produção LAMP -, configuração de banco de dados Mysql – criamos o banco de dados e o usuário Mysql via linha de comando – e alguns parâmetros de sistema, e escolha de pacotes de funções e linguagens). Depois de 5 minutos, já temos a tela de login do Vtiger CRM.

Os próximos passos são a criação de usuários e começar a cadastrar clientes e contatos. Esperamos conseguir maior agilidade e transparência nos processos comerciais e de marketing.

 

Voxblue – Migração de Infraestrutura Cloud

Recentemente, a Intercom executou uma migração típica “cloud/cloud”: mudamos uma estrutura de servidores Linux anteriormente hospedados na Linode.com para Amazon Web Services, para a empresa Voxblue.

A Voxblue possui um conjunto de ferramentas Internet voltadas para comunicação empresarial via email e redes sociais. Atua no segmento corporativo. Anteriormente, hospedava seus servidores Linux na Linode.com, que é um provedor de serviços Linux VPS/Cloud com excelente reputação técnica e no atendimento, e apresentava custos razoáveis.

A migração foi precedida por minucioso estudo de viabilidade. Os recursos técnicos de “cloud computing” – CPU, memória, espaço de disco, banda de Internet, snapshots, backups, balanceadores, DNS, etc., foram avaliados e dimensionados de forma equivalente. Um ambiente de testes foi montado com AWS, idêntico ao ambiente existente na Linode.com, para testar as funcionalidades das aplicações Voxblue. Um detalhado plano foi definido para execução da migração na data de corte estabelecida.

A principal razão para a migração foi econômica. A Linode.com oferece vários pacotes de serviços pré-determinados (número de CPUs, quantidade de memória, espaço de disco, volume de tráfego mensal – veja os planos aqui), com pagamento antecipado mensal, e oferece descontos de 10% para assinaturas pré-pagas de 1 ano, e 15% para 2 anos. Mas a Amazon Web Services oferece um desconto vencedor: para Instâncias Reservadas por 3 anos com pagamento antecipado, o desconto chega a 75%!  Tendo um plano agressivo de crescimento da Voxblue nos próximos 36 meses, manter a plataforma estável e operacional num mesmo provedor de “cloud computing” por 3 anos é uma boa decisão de planejamento. O resultado desta migração é uma redução de custo operacional de datacenter da ordem de 80%, liberando recursos que serão injetados para pesquisa e desenvolvimento de novos produtos.

 

Cloud Computing – Falhas e Recuperação de Desastres

Na região norte do estado da Virgínia, EUA, a Amazon Web Services mantém duas “zonas de disponibilidade” em dois datacenters. “Zonas de disponibilidade” são definidas como “localidades físicas distintas que são projetadas para ficarem isoladas uma das outras quando há falhas”. Em 29 de Junho passado, uma pesada tempestade atingiu esta região e derrubou a energia elétrica pública. Em um dos datacenters, o chaveamento automático para gerador de backup falhou por causa de uma sobretensão, o que causou quedas de inúmeras instâncias EC2 e bug inédito de software no “Elastic Load Balancer”, resultando em indisponibilidade de até 6 horas.

Além de problemas com eventos do tempo (estado atmosférico), “cloud computing” ainda é baseado em equipamentos físicos, e eles também falham. Por isso, provedores e usuários de “cloud computing” devem sempre ter planos de recuperação de desaster (DR).

Já é prática comum para grandes provedores de “cloud computing” distribuir recursos entre  datacenters físicos distintos e regiões geográficas distintas. Recentemente o conceito de “cloud balancing” começa a ganhar popularidade, pois permite que tráfego e carga de processamento seja distribuído e assumido por múltiplos datacenters distintos, trazendo como benefício a melhora na redundância e disponibilidade para seus usuários.

Mas usuários que dependem de “cloud computing” para fazer negócios devem sempre planejar a recuperação de desastres e a continuidade dos seus negócios. Contratar provedores de “cloud computing” independentes ou distribuir sua aplicação em várias regiões geográficas distintas são alternativas que devem ser consideradas seriamente, apesar dos seus maiores custos de operação adicionais.