Muitos novos clientes, quando começam a usar a CloudSigma, querem testar o desempenho; eles geralmente procuram comparar os resultados de desempenho entre servidores em nuvem e sua própria infraestrutura, e isso faz sentido. Uma comparação direta de preços por recurso não conta nem de longe toda a história; o que realmente importa é o resultado final: quanto custa realizar uma tarefa de computação específica?
Para qualquer requisito específico, o número de recursos necessários para alcançá-lo pode variar amplamente entre as nuvens. Isso significa que comparar apenas preços não funciona. O outro lado da moeda é que comparar o desempenho isoladamente não é melhor. Comparações significativas precisam reunir tanto o preço quanto o desempenho para calcular alguma medida de custo por unidade de computação. Neste post, vou compartilhar algumas das minhas reflexões sobre a realização de testes de benchmark em nossos servidores em nuvem e em outros. Também fornecerei algumas dicas para obter resultados úteis e o que eles realmente significam.
Advertências
Para explicar desde o início, sou bastante cético em relação a benchmarks em geral. Eles raramente oferecem uma visão real do uso no mundo real. Em suma, não há substituto real para executar os aplicativos reais que você pretende usar na plataforma. Se você puder fazer isso a um custo razoável em termos de tempo, não há substituto para tal exercício.
Outro fator é o quão ocupado está o provedor de nuvem. Você pode testar servidores em nuvem e obter excelentes resultados. No entanto, estes podem ser em grande parte devidos ao nível de uso (ou à falta dele) daquele provedor específico. Isso pode não ser um sinal positivo. Pode refletir dificuldades na operação, perda de clientes, problemas anteriores de disponibilidade e confiabilidade, etc. Portanto, você deve sempre pesquisar o provedor de nuvem em busca de interrupções anteriores e outros problemas potenciais ao interpretar os resultados de seus benchmarks.
Como uma advertência final, o desempenho não é o único fator que você deve considerar. Muitas vezes, um desempenho inferior pode refletir uma arquitetura de hardware subjacente mais robusta (e redundante). Portanto, é sempre importante ter uma compreensão muito clara de em qual infraestrutura a nuvem foi construída. Assim, você pode comparar os resultados de forma justa, permitindo-lhe tomar uma decisão de compra significativa.
Defina o problema
Mais adiante neste post, apresento os vários aspectos do desempenho e a melhor forma de interpretar os resultados. Antes de realizar qualquer benchmark, no entanto, é importante caracterizar o tipo de computação que você pretende realizar na nuvem; isso determinará a importância relativa de diferentes métricas de desempenho. For exemplo, se você deseja hospedar um servidor de banco de dados que terá alto acesso de leitura, mas baixo acesso de gravação, deve prestar atenção ao desempenho do disco na nuvem e, particularmente, ao acesso de leitura não sequencial.
Portanto, antes de iniciar qualquer benchmark de servidores em nuvem, defina claramente o que você consideraria um bom desempenho da nuvem. Você deve determinar quais aspectos são fundamentais e têm um impacto desproporcional no desempenho real da sua computação. Assim que tiver uma ideia clara disso, estará em condições de começar a analisar os benchmarks.
Desempenho Computacional
Quando analisamos o desempenho computacional bruto, estamos falando de CPU e RAM. As diferenças de desempenho em um nível puramente computacional entre as nuvens na verdade não são tão grandes. No entanto, existem alguns fatores que causam as diferenças reais.
De longe, o maior fator que afeta o desempenho computacional na nuvem é a concorrência. As nuvens públicas são ambientes multi-tenant. A RAM e o armazenamento não podem ser realmente superalocados (embora possam ser sobrevendidos), mas a CPU pode ser e é. Os níveis de concorrência variam consideravelmente, mas, essencialmente, os provedores de nuvem pública conseguem vender a capacidade de CPU de um host físico a mais de 100%.
Alguns dos maiores fornecedores usam taxas de contenção de CPU de mais de três vezes. Isso significa que a capacidade total de CPU ‘vendida’ de todos os servidores virtuais na mesma máquina física pode ser o triplo de sua capacidade real de CPU. Eles fazem isso porque a maioria dos servidores virtuais não utiliza nada próximo de 100% de sua alocação de CPU na maior parte do tempo. Ainda assim, as taxas de contenção afetarão diretamente os benchmarks de desempenho dos servidores em nuvem e o uso no mundo real. Se a contenção for alta (ou seja, em qualquer valor superior a 200% de alocação de CPU), o desempenho do servidor em nuvem se deteriorará significativamente.
Simplificando, se a carga em qualquer máquina física atingir mais de 1 por núcleo, as tarefas computacionais serão enfileiradas e o tempo necessário para que essa máquina virtual conclua o trabalho será maior. Dado que a maioria das nuvens cobra com base na capacidade/hora, isso tem um impacto direto nos custos para os clientes dessa nuvem.
O outro fator importante que afeta o desempenho computacional é o número de núcleos de CPU aos quais a máquina virtual tem acesso. Isso não é um fator para todas as aplicações, mas muitas aplicações modernas suportam multi-threading. Efetivamente, isso significa que a aplicação e/ou o sistema operacional é capaz de distribuir as tarefas computacionais por vários núcleos. Uma ótima dica para melhorar o desempenho da sua computação é fazer corresponder o número de threads (ou seja, núcleos) que uma aplicação pode suportar ao número de núcleos aos quais a máquina virtual tem acesso.
Infelizmente, isso não é possível com muitas nuvens públicas. Isso ocorre porque suas plataformas de virtualização não suportam a virtualização no nível do núcleo da CPU. Em outras palavras, cada núcleo só pode ser usado por uma máquina virtual de cada vez. Em nuvens que suportam a virtualização de núcleos de CPU, você deve experimentar variar o número de núcleos para essa máquina, mantendo o tamanho total da CPU igual.
Por exemplo, se você tiver uma máquina de 2GHz, poderá ver como duplicar os núcleos em uso de dois para quatro afeta seu benchmarking. Ao fazer isso, as aplicações executadas nessa máquina virtual poderão executar tarefas através de quatro núcleos simultaneamente. No nosso caso, você pode definir o número de núcleos que uma máquina virtual usa através da aba ‘avançado’ no modal de detalhes do servidor do console web. Lembre-se apenas de sempre verificar qual é o tamanho padrão do núcleo do fornecedor de nuvem antes de substituir manualmente o número de núcleos em uso. No nosso caso, é de 2.2GHz por núcleo, mas varia de nuvem para nuvem.
Eu recomendaria considerar o uso de POV-RAY, CoreMark, Dhrystone ou Whetstone para benchmarking do desempenho de servidores em nuvem.
Armazenamento: o verdadeiro benchmark de desempenho de servidores em nuvem
Todo o desempenho é limitado pelo elo mais fraco onde se desenvolve um gargalo. Atualmente, a tecnologia avançou significativamente no campo da virtualização no que diz respeito ao uso de CPU e RAM. Por exemplo, uma única máquina física pode ser virtualizada e ter múltiplos servidores em nuvem com perda mínima no desempenho agregado total. Infelizmente, no caso do armazenamento, ainda há um grande progresso a ser feito. O resultado final é que, na maioria dos casos, o desempenho dos servidores virtuais na nuvem é determinado pelo desempenho da solução de armazenamento dessa nuvem.
Em suma, o armazenamento é atualmente o fator limitante no desempenho da maioria das tarefas computacionais na nuvem. Quaisquer que sejam os resultados que o pov-ray e outros benchmarks possam produzir para tarefas computacionais puras, a realidade é que a velocidade com que o servidor virtual pode recuperar e gravar dados em discos de armazenamento físico determinará o desempenho no mundo real de um servidor em nuvem atualmente.
Com isso em mente, as diferenças reais observadas no desempenho na nuvem, mesmo em relação a tarefas computacionais, tendem a decorrer de diferenças no desempenho do armazenamento. Como mencionado anteriormente neste post, existem necessidades de clientes muito diferentes dependendo da tarefa de computação. Isso nunca foi tão verdadeiro quanto em relação ao armazenamento. Você precisa de acesso rápido de leitura a grandes blocos sequenciais de dados (como streaming de mídia) ou a pequenas partes díspares de informações (talvez em um grande banco de dados)? Você precisa manter um acesso pesado de gravação para dados que mudam rapidamente e que são acessados periodicamente em grandes picos? Existem inúmeros cenários e cada um terá um desempenho diferente na mesma plataforma.
Fundamentalmente, as diferenças de desempenho resumem-se à arquitetura. Essas diferenças de arquitetura geralmente resultam de diferentes graus de robustez em relação ao armazenamento de dados, sua redundância e, portanto, na verdade, a probabilidade de se perderem irreparavelmente. Em um nível alto, as nuvens empregam soluções de dados centralizadas na forma de uma Storage Area Network (SAN) ou soluções de armazenamento local mais distribuídas. Nessas, o armazenamento está localizado em cada máquina física individual.
Boas SANs têm intrinsecamente um alto nível de redundância integrado. No entanto, o desempenho é prejudicado, pois os dados precisam ser enviados da SAN através da rede para a CPU e RAM da máquina virtual para tarefas de computação. Como resultado, as nuvens baseadas em SAN tendem a ter um desempenho inferior, comparando de igual para igual, em relação às nuvens com soluções de armazenamento distribuído local. Outra desvantagem de uma SAN é que ela representa um ponto único de falha muito grande. As SANs são extremamente confiáveis. Se elas apresentarem algum problema sério (e já apresentaram), você provavelmente enfrentará uma grande interrupção e corrupção de dados.
A maioria dos provedores de nuvem que usam SANs não emprega soluções de fail-over totalmente redundantes do tipo usado em ambientes corporativos, em grande parte por razões de custo. É importante perceber que nem toda SAN é igual e entender, por parte do provedor de nuvem, qual nível de redundância eles empregam em suas SANs.
Nuvens baseadas em armazenamento local tendem a ter um bom desempenho de disco. No entanto, muitas vezes elas oferecem apenas armazenamento local de forma não persistente. Isso não é uma comparação justa com o armazenamento persistente. O armazenamento temporário não precisa ser robusto a falhas da mesma forma que o armazenamento permanente. É sempre importante comparar armazenamento persistente com armazenamento persistente para obter resultados significativos.
Ao analisar nuvens com soluções de armazenamento local distribuído, você também precisa saber qual redundância elas possuem. Os discos rígidos falham a uma taxa significativa e, portanto, o método de armazenamento é crítico. A maioria dos provedores usa alguma forma de RAID mas existem níveis de segurança muito diferentes. No nível mais baixo, você tem o RAID1, onde dois discos estão essencialmente espelhando um ao outro. Isso geralmente tem um bom desempenho. Mas quando um disco falha, até que o disco de substituição copie todos os dados do disco antigo, os dados correm o risco de perda total se o segundo disco (fortemente carregado) falhar. Além disso, durante qualquer reconstrução da matriz RAID1, o desempenho do disco provavelmente será muito, muito inferior ao normal.
Muitos provedores, portanto, usam RAID5 (resiliente a uma falha de disco) ou RAID6 (resiliente a duas falhas de disco). RAID6 oferece, de longe, a solução mais segura para armazenamento local, mas exige uma grande penalidade no desempenho. Nossa abordagem é usar RAID6, mas combinar isso com placas controladoras RAID de hardware de ponta. Elas possuem grandes caches de memória e são alimentadas por bateria. As placas controladoras RAID que usamos são, na verdade, significativamente mais caras do que as matrizes de disco inteiras. Assim, podemos fornecer um desempenho comparável ao de configurações muito menos resilientes, ao mesmo tempo em que oferecemos a enorme rede de segurança do armazenamento RAID6. Leia mais sobre a nossa configuração de infraestrutura de nuvem, sobre a qual somos muito abertos.
Eu recomendo usar IOzone ou Bonnie++ para benchmarks de desempenho de disco.
Portanto, ao interpretar os resultados dos benchmarks de armazenamento, certifique-se de ter também as seguintes informações:
- qual arquitetura de armazenamento a nuvem está usando (local, SAN, outra)?
- quais medidas de fail-over e redundância estão implementadas para os dados?
- o armazenamento que estou avaliando é temporário ou persistente?
Reunir as respostas a essas três perguntas com os resultados do benchmarking lhe dará uma visão bastante clara do desempenho real do armazenamento.
Rede
O desempenho de rede é significativamente mais simples de determinar e medir do que o desempenho computacional e de disco. O desempenho de rede tem dois aspectos principais: latência e largura de banda.
Dependendo de suas necessidades, a latência da rede que o provedor de nuvem utiliza pode ou não ser importante. Se você estiver usando a nuvem para operações amplamente independentes, é improvável que a latência seja uma prioridade. Se, no entanto, você estiver executando aplicativos em tempo real que interagem com o mundo fora da nuvem, a latência será um determinante crítico de desempenho.
Geralmente, a grande maioria da latência resulta de uma mera distância física. Por exemplo, a maior parte da latência entre Londres e São Francisco é, na verdade, o tempo que a luz leva para percorrer essa distância. As diferenças na latência são determinadas pela eficiência variável da rota percorrida. Este é o aspecto que difere de nuvem para nuvem. A eficiência da rota é um resultado direto dos provedores de rede com os quais a nuvem possui conexões diretas. Isso acontece ao obter conectividade IP deles ou por meio de peering. Ao analisar as latências, você pode simplesmente dar um ping no seu servidor em nuvem e determinar seu desempenho. No entanto, é importante determinar o desempenho entre seus usuários finais reais e seu servidor em nuvem.
Se a maioria dos seus usuários estiver baseada em uma região geográfica ou se o acesso for feito principalmente a partir da sede da sua empresa, é importante testar o desempenho a partir desses locais. Serviços comerciais como Pingdom oferecem uma maneira econômica de determinar a latência de um grande número de locais gerais simultaneamente em todo o mundo.
A real largura de banda que o seu servidor em nuvem pode alcançar também é muito importante. Ao contrário de soluções de hospedagem mais tradicionais, os provedores de nuvem tendem a cobrar em relação ao volume agregado de transferência de dados. Em outras palavras, não depende do tempo, como em um modelo por Mbit que oferece um nível fixo de conectividade 24 horas por dia, 7 dias por semana. Apesar disso, muitos provedores de nuvem vão ‘limitar’ a largura de banda de qualquer servidor virtual. Isso será invisível para o usuário até que você atinja esse limite. Se você tiver um perfil de largura de banda com muitos picos, esse pode ser um fator de desempenho importante a ser levado em consideração.
Para testar a largura de banda real do seu servidor em nuvem, é importante tentar baixar dados para o servidor em nuvem a partir de uma fonte que não esteja realmente restringindo a taxa de transferência do lado deles. Muitas vezes acho que uma ótima maneira de determinar a velocidade disponível é baixar um arquivo grande de um grande fornecedor como Microsoft, Ubuntu ou, melhor ainda, atualizando o sistema operacional. Isso tende a baixar muitos arquivos diferentes de vários locais simultaneamente. Isso lhe dará uma boa noção da velocidade da sua conexão.
Geralmente eu baixo um Fedora live CD do site principal deles como um teste padrão, mas você deve sempre experimentar pelo menos alguns arquivos e locais diferentes. Se você faz questão de ter sua própria rede corporativa muito rápida, pode preferir baixar um arquivo do seu servidor em nuvem para a sua própria rede como um teste.
Agora Adicione o Preço de Volta para Ponderar os Resultados
Usando os métodos acima, você deve conseguir ter uma boa noção de como os vários provedores de servidores em nuvem se comportam. Além disso, você saberá em quais aspectos focar que são mais importantes para suas necessidades específicas.
O passo final é adicionar uma dimensão de preço aos resultados do benchmark. Não existe uma fórmula para isso. Depende do desempenho relativo dos vários aspectos acima e é você quem os determina. Se uma nuvem estiver produzindo um desempenho 40% melhor (conforme determinado por você) mas for apenas 30% mais cara, então claramente ela parece atraente. Da mesma forma, se você tiver uma grande necessidade de largura de banda, um menor desempenho computacional pode ser superado por um plano de preços de transferência de dados competitivo. A chave para tomar a decisão certa é reunir todos os vários fatores.
Finalmente, o benchmarking deve fazer parte de um processo maior para determinar quais servidores em nuvem são adequados para você. Isso deve incluir outros aspectos. Por exemplo, esses podem incluir acordos de nível de serviço, considerações de lock-in de dados/fornecedor, localização física e jurisdição legal. Ao reunir todos esses aspectos, você se posicionará para fazer a escolha certa do fornecedor de computação em nuvem.
Comentários
Nenhum comentário ainda. Seja o primeiro.