Performance em LVM no Linux

Encontrei muito poucos artigos que descreviam sobre problemas de performance ao utilizar LVM no Linux. Neste artigo explico o que é uma LVM e como identificar uma situação em que ela pode afetar o seu sistema.

O que é Logical Volume Management (LVM)?

O Logical Volume Management (LVM) é um recurso de extrema importância disponível no Kernel do Linux.

O LVM cria uma camada de software, que abstrai o storage/disco rígido e o sistema operacional, permitindo expandir ou reduzir a capacidade de armazenamento de um servidor de forma dinâmica, realizer snapshots, …

Existem três tipos de volumes lógicos LVM: volumes lineares, volumes Striped (distribuídos) e volumes espelhados. Vou descrever os dois primeiros:

  • LVM Lineares

Um volume linear agrega espaço de um ou mais volumes físicos em um volume lógico sequencialmente. Por exemplo, se você tiver dois discos de 60 GB, pode criar um volume lógico de 120 GB. O armazenamento físico é concatenado.

  • LVM Striped

Um volume Striped (distribuído) agrega espaço de um ou mais volumes físicos. Mas quando você grava dados em um LVM Striped, o sistema de arquivos distribui os dados nos volumes físicos subjacentes. O striping melhorar a eficiência da I/O de dados gravando e lendo em um número predeterminado de volumes físicos em paralelo.

Em resumo, nas LVM lineares a escrita é serial, isto é, vai ocupando os primeiros discos. Nas LVM Striped a escrita é divida entre os discos (riscos em Laranja).

Como identifica se o seu LVM é linear ou striped?

Por padrão no Linux, as LVM são lineares, a não ser que você especifique o tipo na hora da criação.

Utilize o comando lvs –segments para isso.

# lvs --segments
 LV           VG           Attr       #Str Type   SSize
   lv_docs      vg_docs      -wi-ao----    1 linear 475.00g
   lv_docs      vg_docs      -wi-ao----    1 linear 475.00g
   lv_docs      vg_docs      -wi-ao----    1 linear 475.00g
   lv_docs      vg_docs      -wi-ao----    1 linear 475.00g
   lv_docs      vg_docs      -wi-ao----    1 linear 100.00g

Neste exemplo o disco é linear.

Situação na vida real

Em um episódio no trabalho, eu tive que investigar um problema de performance. Durante essa investigação, conseguimos identificar a seguinte situação no Sistema Operacional:

O Volume /opt/documents possuía 5 discos (4x450GB e 1x100GB) (item 2 na figura abaixo) e estávamos utilizando apenas 873GB de 2.1TB (item 1 na figura abaixo).

Analisando o volume /opt/documents, observamos que o I/O se concentrava em 3 dos 5 discos (item 3 na figura abaixo), sendo muito superior no disco /dev/sde1, início dos logical extents, e mínimo nos discos /dev/sdh1 e /dev/sdi1, final do logical extents (item 2 na figura abaixo).

Em função da formatação linear do volume e de como o SO cria os arquivos, ocorre a concentração do I/O no início do volume, não distribuindo igualmente a operações de leitura/escrita entre os discos.

Comandos utilizados

# df -h
# lsblk
# iostat -x 5

Isso pode acontecer na Nuvem?

A reposta é SIM . Esse artigo mostra o funcionamento e a perfomance entre volumes lineares vs striped no ambiente da AWS –> https://sysadmincasts.com/episodes/27-lvm-linear-vs-striped-logical-volumes

Concluindo, se o seu sistema tem um requisito que precise de armazenamento extremamente rápido em uma única máquina, você deve observar essa configuração da LVM. Ao usar LVM striped, normalmente quanto mais discos você tiver, melhor será o desempenho, isto é, se você precisar de 2TB de uma combinação de 10 discos de 200GB vai performar melhor que 5 discos de 400GB, independente ser os discos forem SSD ou não.

Leia também:

Considere utilizar Rust!

Rust é uma linguagem de programação de sistemas de código aberto que se concentra em Performance, Concorrência e Segurança de Memória.

Os desenvolvedores estão usando o Rust para criar uma ampla gama de novos aplicativos de software, como engines de jogos, sistemas operacionais, sistemas de arquivos, componentes atuais do Firefox e futuros, …

Em pesquisa de opinião da Stack Overflow, ela está entre as mais amadas por 4 anos seguidos e os desenvolvedores desejavam desenvolver com a linguagem Rust. Top!

Entre algumas características positivas do Rust temos:

* Código Nativo, você pode distribuir direto o seu binário. Aplicações como o npm foram desenvolvidas para rust.

* A linguagem e o compilador tentam Prever Problemas que acontecem em
tempo de execução. Como eles tentam evitar um conjunto de erros e problemas comuns, a
linguagem traz um conjunto de práticas que melhoram o seu estilo de
programação
.

* Rust tem o conceito de Ownership, isto é, um valor pode ser propriedade de apenas uma variável, quandoessa variável sair de contexto, o valor sai da memória, então NÃO tem Garbage Collection. Durante um Garbage Collection, a rotina verifica se tem alguém usando esse valor, o que tem um custo.

* Exceptions não coisas legais, em Rust você deve tratar as exceções.

* Ferramentas Modernas. O Rust, através do Cargo, já tem práticas modernas como Gerenciamento de Bibliotecas, Testes, Documentação, ….

* Rust está entre as melhores linguagem de programação para WebAssembly. O WebAssembly (abreviado Wasm) é um formato de instrução binário para execução nos Navegadores e Servidor de Aplicações.

Mas nem tudo são flores:

Algumas características negativas do Rust temos:

* Rust não é fácil de aprender.

* A linguagem ainda é nova, algumas features estão disponíveis apenas na versão nightly.

* Faltam items corporativos, isto é, senti falta de drivers para Banco de Dados.

Mas o que me chamou minha atenção sobre Rust é a possibilidade de economia que a sua performance e uso reduzido de memória pode trazer. Os provedores de nuvem definem suas unidades de processamento por flavors (sabores) de equipamentos levando em conta Cpu vs Memória. Uma aplicação que performa melhor terá influência direta no flavor utilizado e no valor da fatura no fim do mês. No artigo Parsing logs 230x faster with Rust – André.Arko.net, o autor descreve com como ele passou de US$ 1000,00 por mês para US$ 0 por mês, reescrevendo um script com Rust.

Se estiver disposto a arriscar, aprenda Rust. Comece desenvolvendo microsserviços, funções Lambda (Serverless), Scripts ou otimizando aplicações, através de uso de bibliotecas (.dll/.so), criadas em rust.

Não estou falando que Rust é a linguagem certa, mas acho que vale o investimento, você não estará sozinho.

Quer saber mais:

Leia também:

Expondo a sua aplicação no Kubernetes

Não vou explicar conceitos do Kubernetes, pois não é o meu foco aqui, a idéia é comparar com o modelo tradicional afim de entender melhor o Kubernetes.

Se você precisa expor qualquer serviço executando dentro de um cluster Kubernetes, você deve utilizar o Ingress.

Para explicar de forma rápida o Ingress, montei o seguinte diagrama:

Você deve pensar no Ingress, como um típico Proxy Reverso que colocamos na DMZ, para permitir acesso à sua aplicações que ficam na Intranet. No modelo tradicional usariamos um Apache HTTP server ou um Nginx, pra controlar o tráfego e proteger contra ataques da Internet.

Em um ambiente Java tradicional, teríamos um Load Balancer ou um HTTP Server na frente dos Servidores de Aplicação, mas no Kubernetes temos as figuras do Service e dos PODs, respectivamente.

Adicionei a personagem do Operado de Proxy, que seria do Admin que faz alteração no arquivo .conf. Já no K8s, essa tarefa é executada através do comando kubectl. Podendo usar o linha de comando ou através de um arquivo yaml.

Acredito que tenho deixado mais claro o funcionamento do Ingress. Bye.

Leia também:

  • Sem textos relacionados

Projetos em Node.js com boas práticas

Como o Node.js é uma plataforma e não um framework, as boas práticas ficam dependentes do projeto e dos desenvolvedores envolvidos.

Os padrões de design e as melhores práticas existem para evitar armadilhas comuns e construir aplicativos mais estáveis, mas esses princípios orientadores na maioria das vezes não são bem documentados.

Mas existem bons guias e filosofias disponíveis, recomendo visitar o The Node Way. Lá descrevem práticas recomendadas e princípios orientadores para a escrita de módulos de manutenção, aplicações escaláveis e códigos que são realmente agradáveis de ler.

 

Uma sugestão que ajuda bastante é utilizar um linter desde o início.

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs in C language source code. Wikipedia

No caso de Javascript, o mais bem availado é o ESLint, veja a comparação com outros neste link.

Como dica de uma boa leitura utilize JavaScript Standard Style, que exemplifica e evita de você criar as suas próprias regras.

Leia também:

A metodologia 12 factor

A metodologia 12 factor consiste em um série métodos que você deve seguir para construir uma aplicação como Software-as-a-Service (SaaS).

Quando li sobre a 12-factor, ficou mais claro pra mim, como aplicações rodando em Cloud estão organizadas em provedores como Amazon AWS, Microsoft Azure, IBM Bluemix ou como soluções Cloud Foundry.

Fator 1 – Um código base em um repositório com multiplos deployments.

Utilize de um sistema de controle de versão como Git ou Subversion, e a partir deste código fonte faça o deploy em múltiplos lugares, como ambiente de desenvolvimento, homologação e produção.

Fator 2 – Declare e separa as dependências.

As dependências da aplicação devem estar fora do código fonte. Por exemplo, no arquivo package.json para uma aplicação em Node.js.
Com isso, o deploy de uma aplicação pode ser feito em diversos servidores, e assim não nos preocupamos com as suas dependências.

Fator 3 – Armazene configuraçòes no seu ambiente.

As configurações da aplicação devem estar fora do código fonte. Nos principais provedores de Cloud, essas configurações são declaradas como variáveis de ambiente.

Exemplo:
set PORT “8080”
set JDBC_URL “jdbc://db_server:port/”

Fator 4 – Trate serviços de apoio como recursos anexado.

Um serviço de apoio é qualquer serviço que a aplicação faça através da rede. Exemplos: Banco de dados (MySql/MongoDB), Sistemas de Mensagens/Filas, serviços SMTP para emails externos (tais como Postfix), e serviços do IBM Watson.

Você deve preparar sua aplicação para usar estes serviços independente do local onde estejam (local ou remoto), e usar variáveis de ambiente para alterar essas configurações. Podendo usar Web UI dashboard do provedor Cloud ou comandos como “cf create-service” e “cf bind-service” para ligar os serviços.

Fator 5 – Faça a separação do Build, Release and Run.

Separe as fases de:

  • Build = Pegue uma versão do código do repositório, forneça as dependências, compile binários e empacote.
  • Release = Envie o Build para um servidor, ajuste as configurações necessárias para que ele seja executado.
  • Run = Rode a aplicação no ambiente de execução, através do início de alguns dos processos da aplicação, para que ele esteja disponível para os usuários acessarem.

Fator 6 – Execute a aplicação como um ou mais processos stateless

Execute a aplicação como um ou mais processos que não armazenam estado.

Quando você cria aplicativos, use vários processos ou serviços conforme necessário.
Evite dependências em stick sessions e mantenha os dados da sessão em um armazenamento persistente para garantir que o tráfego possa ser roteado para outros processos sem interrupção do serviço.

Fator 7 – Exporte de serviços pela porta de TCP/IP

A aplicação lê a variável de ambiente e exporta o serviço através do bind a uma porta de TCP/IP, que recebe as requisições que chegam na mesma.
Depois você pode adicionar um servidor Nginx, que faz um proxy para esse serviço ou utilizar o serviço de roteamento de tráfico do seu provedor cloud.

Fator 8 – Escale atráves do uso de um processo modelo.

Escale horizontalmente a sua aplicação através da criação de processos modelos. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador.

Fator 9 – Maximize a robustez com inicialização e desligamento rápido

Processos no 12-factor são descartáveis, significando que podem ser iniciados ou parados a qualquer momento. Um processo dever iniciar rapidamente, fazendo
o mínimo de ações. E quando o processo for encerrado, deve seguir o mesmo padrão.
Isso facilita o escalonamento, rápido deploy de código ou mudanças de configuração, e robustez de deploys de produção.

Fator 10 – Mantenha os ambientes de desenvolvimento, homologação, produção o mais semelhante possível

Manter ambientes semelhantes evita erros durante o processo de envio da aplicação para produção.

Ferramentas como Docker, Puppet auxiliam nisso. Outras soluções com Spaces no IBM Bluemix provem metodos efetivos para separar diferentes níveis da aplicação.

Esta abordagem permite a entrega de software ágil ( Agile Software) e a integração contínua (continuous integration).

Fator 11 – Trate logs como fluxo de eventos

Utilize os logs da aplicação para entender o funcionamento e utilização da sua aplicação.

A aplicação deve enviar as mensagens para a saída padrão e esta deve ser redirecionada para locais específicos de acordo com o ambiente onde a aplicação está executando, em desenvolvimento para um arquivo.

Exemplo: No Bluemix ou Cloud Foundry, o Loggregator coleta os dados de log em vários componentes do aplicativo e você pode visualizar atráves do comando cf logs.

Fator 12: Executar tarefas de administração/gerenciamento como processos pontuais

Crie tarefas que precisam ser executadas uma vez ou ocasionalmente em componentes separados que podem ser executados quando necessário em vez de adicionar o código diretamente em outro componente.
Por exemplo, se um aplicativo precisa migrar dados para um banco de dados, coloque essa tarefa em um componente separado ao invés de adicioná-lo ao código principal do aplicativo na inicialização.

E aí. Vai utilizar a metodologia 12-factor na sua próxima aplicação?

Leia também:

O que são aplicações Servless?

Apesar do termo Servless, significar “sem servidor”, o conceito de aplicação Servless é bem diferente.

Em aplicações Servless, o desenvolvedor cria uma aplicação que atende a eventos, como por exemplo uma request http, enquanto a gestão do Application server, database, container ou VM, fica por conta do provedor de Cloud.

Dessa maneira, o desenvolvedor foca no desenvolvimento da solução, não se preocupando com a infraestrutura. O faturamento também é diferente, pois o provedor de Cloud vai cobrar pelo eventos, do exemplo anterior, pela quantidade de requisições.

Em breve vou postar algumas dicas de como desenvolver, construir, fazer o deploy, manter e ganhos de eficiência de soluções de software construídas com essas modernas tecnologias de cloud.

Por enquanto, listo abaixo alguns dos principais players de cloud e as tecnologias usadas:

Leia também:

Ofertas Gratuitas do Microsoft Azure

Dica bem interessante sobre o Microsoft Azure!

Se você tem uma conta no serviço de Cloud da Microsoft, pode aproveitar algumas opções gratuitas para qualquer tipo de assinatura.

Serviço Oferta
Serviço de Aplicativo Host de 10 aplicações Web ou Mobile
Hub IoT 3000 mensagens por dia, e controle 10 dispositivos IoT
Hub de notificação 1 milhão de push notifications por mês
Azure Active Directory (AD) Até 500.000 objetos no AD e single-sign-on para 10 aplicações por usuário
AD B2C 50.000 usuários para sua aplicação B2C, a aplicação pode ser Web ou Mobile
Rede Virtual 50 redes virtuais
Visual Studio Team Services Até 5 usuários
Application Insights Ilimitado número de Hosts ou Dispositivos
Azure Search 10.000 documentos indexados
Scheduler 3.600 jobs por mês
Log Analytics 500 MB de log para análise por mês

Mais detalhes veja no link https://azure.microsoft.com/en-us/free/pricing-offers/

Leia também: