A elasticidade na computação em nuvem é a capacidade dessa nuvem de se adaptar às necessidades do aplicativo o mais rápido possível. Existem várias definições segundo os autores, algumas considerando as noções de Escalabilidade e elasticidade como idênticas, outras como distintas. A chegada de tais sistemas distribuídos (veja Computação Distribuída ) inevitavelmente envolve problemas técnicos que devem ser regulamentados ou limitados. Economicamente, a chegada da elasticidade teve um impacto sobre os clientes e provedores de nuvem. Por exemplo, os fornecedores criaram um sistema de pagamento “ pré-pago ” para pagar pelos recursos usados sob demanda. Assim, um cliente pode alugar um servidor por um curto período de tempo e no tamanho desejado.
Muitos provedores como Amazon Web Services , Microsoft Azure ou mesmo Google App Engine criaram servidores em nuvem sob demanda. Mas cada provedor de nuvem tem suas especificidades em termos de velocidade, elasticidade, latência, etc.
É comum pensar em elasticidade e escalabilidade como sinônimos. A elasticidade na nuvem pode ser comparada à propriedade física da elasticidade de um material, que é sua capacidade de retornar à sua forma original após a deformação que sofreu. Assim, a elasticidade pode ser calculada como a relação entre a pressão que a nuvem pode sofrer e a pressão que ela sofre.
No entanto, outros como NR Herbst e Doaa M. Shawky fazem duas definições muito distintas:
Escalabilidade Escalabilidade é a capacidade de um sistema de atender aos requisitos de recursos, sem levar em conta a velocidade, o tempo, a frequência ou a granularidade de suas ações. Elasticidade Elasticidade é o grau em que um sistema é capaz de se adaptar às demandas provisionando e desprovisionando recursos automaticamente, de forma que os recursos fornecidos correspondam à demanda do sistema.A escalabilidade é, portanto, um pré-requisito para a elasticidade. O tempo é um elo importante entre elasticidade e escalabilidade: quanto menos tempo o sistema leva para se adaptar, mais elástico ele é.
Todo o ponto de elasticidade na nuvem é responder o mais precisamente possível à demanda de recursos de um aplicativo. Para isso, os sistemas são capazes de se adaptar em poucos minutos.
Existem duas abordagens para a elasticidade. O primeiro é chamado de elasticidade horizontal. Essa forma de elasticidade é obtida adicionando ou removendo máquinas virtuais da instância do cliente. A segunda abordagem, chamada vertical, não é mais realizada adicionando servidores, mas adicionando recursos à máquina, como RAM , CPU , etc.
Como regra geral, a elasticidade horizontal tem um custo de tempo maior do que a elasticidade vertical porque você tem que esperar a máquina virtual ser criada e inicializada. Assim, para melhor desempenho, será utilizada a elasticidade vertical. O problema é que esse tipo de abordagem é muito mais limitado do que a escalabilidade horizontal. Na verdade, a escalabilidade vertical não pode se estender por recursos fora da máquina física. Assim, é necessário definir claramente em qual máquina a máquina virtual será iniciada no início, a fim de poder escalar verticalmente o maior tempo possível.
Em seu artigo, Chien-Yu Liu define um algoritmo que, segundo ele, é o mais eficiente, combinando a escalabilidade quase infinita da elasticidade horizontal e a velocidade da elasticidade vertical: Aumentar os recursos da máquina virtual, quando a máquina virtual não por mais tempo, é necessário criar novos na mesma nuvem (elasticidade horizontal). Se uma única nuvem não pode atender às demandas de recursos, máquinas virtuais de outras nuvens devem ser adicionadas (elasticidade horizontal). Quando a nuvem não atende mais às demandas, você precisa seguir para o próximo aplicativo.
NR Herbst, em seu artigo, nos apresenta uma maneira de calcular a elasticidade de cima para baixo e de baixo para cima, mas também a precisão de um sistema de nuvem superprovisionado e subprovisionado. Assim, a elasticidade para cima (respectivamente para baixo) é inversamente proporcional ao tempo médio gasto por um sistema subfornecido (respectivamente superfornecido) em um estado ótimo (respectivamente ) pela média da quantidade acumulada de recursos subfornecidos (respectivamente excesso de oferta) durante o período de teste (respectivamente ):
A precisão crescente (respectivamente decrescente) é a razão entre a quantidade acumulada dos recursos subprovisionados (respectivamente superprovisionados) (respectivamente ) e o período de teste :
A flexibilidade dos sistemas em nuvem cria alguns desafios para os fornecedores. A primeira é que existem várias configurações básicas, geralmente é muito difícil saber qual escolher. O objetivo é ter a melhor configuração e, ao mesmo tempo, ser o mais barato. Depois que essa etapa for concluída, o aplicativo terá solicitações mais ou menos importantes para o tempo. Como e quando provisionar / desprovisionar o sistema? Nesta etapa, o objetivo é minimizar os custos de infraestrutura (euros) e de transição (tempo).
Um dos maiores desafios na nuvem é solucionar erros em sistemas distribuídos muito grandes. Por se tratar de problemas relacionados a sistemas muito grandes, é impossível resolvê-los em sistemas menores, por isso os testes são feitos diretamente nos ambientes de produção. Usar máquinas virtuais pode ser uma solução. Na verdade, é possível capturar informações valiosas em uma VM , onde não é possível em máquinas físicas. Infelizmente, todos os fornecedores desenvolveram suas ofertas sem usar uma VM, seja porque começaram antes da era da virtualização ou porque sentiram que não podiam pagar.
Outro desafio é gerenciar a flexibilidade de armazenamento. Muitas tentativas foram feitas para responder a essa pergunta, variando na riqueza de solicitações e APIs de armazenamento, as garantias de desempenho oferecidas. A ideia é não apenas atender às expectativas dos programadores no que diz respeito à durabilidade, alta disponibilidade e capacidade de gerenciar e consultar dados, mantendo as vantagens da flexibilidade da nuvem.
Também existem desafios que ligam a elasticidade e a ecologia das nuvens . Na verdade, é importante que os aplicativos hospedados na nuvem liberem recursos não utilizados tanto quanto possível. Em primeiro lugar, porque um computador em standby consome "apenas" dois terços dos seus recursos, o que poupa muita energia, e em segundo lugar porque isso implica um impacto mais positivo no ambiente, embora o setor seja muito pobre. Visto pela opinião pública. Para isso, os provedores criaram o sistema de cobrança refinado ( pré-pago ) para incentivar os usuários a liberar recursos o mais rápido possível.
As licenças de software também são um problema. Na verdade, alguns fornecedores de software ainda não têm ofertas para a nuvem, o que implica custos astronômicos de licença de software. Para resolver esse problema, o código aberto é uma solução muito popular. Felizmente, alguns fornecedores como a Amazon ou a Microsoft estão começando a fazer ofertas de licenciamento de software “ pague conforme o uso ”. Embora as instâncias sejam executadas em uma estrutura de software paga, continua sendo uma alternativa muito interessante para soluções de código aberto (respectivamente $ 0,15 / h contra $ 0,10 / h).
Como a elasticidade torna possível adquirir ou liberar dinamicamente recursos de computação em resposta à demanda, é importante ter monitoramento e controle dos mesmos. Os dados a serem monitorados são classificados em três dimensões: custo, qualidade e recursos. O framework como MELA para monitorar e analisar a elasticidade dos serviços em nuvem . Para o controle deste, ferramentas como SYSBL (Simple Yet Beautiful Language), permitem ter um controle em três níveis: ao nível da aplicação, ao nível do componente e ao nível da programação, e também de atender aos requisitos de elasticidade.
Outro problema a ser considerado é o tempo de inicialização das máquinas virtuais. Na verdade, eles devem estar disponíveis a tempo e prontos para serem usados pelos usuários. Esse tempo de inicialização pode levar em consideração diversos fatores: hora do dia, tamanho da imagem do sistema operacional, tipo de instância, localização dos centros de dados e número de instâncias solicitadas ao mesmo tempo.
Cada sistema tem seus limites. No caso da nuvem , um dos primeiros identificáveis de sua elasticidade é a quantidade de recursos disponíveis, outros limites foram encontrados.
De acordo com os testes de Doaa M. Shawky, quanto mais máquinas você aloca por vez, menos elástico é o sistema. De fato, durante um experimento, ele comparou dois sistemas com os mesmos valores de estresse, um aumentando o número de máquinas por pacote em 10, o segundo em lotes em 20. Descobriu-se que o tempo médio d A extensão dos dois experimentos é 4427,2 segundos e 6334,4 segundos, respectivamente. Ao mesmo tempo, a elasticidade média foi de 0,0036 e 0,0028, respectivamente. No caso em que a elasticidade do sistema é feita horizontalmente, a elasticidade também diminui à medida que aumenta o número de máquinas alocadas. Isso ocorre porque o tempo de extensão aumenta. Esse limite é ainda mais verdadeiro para a elasticidade horizontal porque é necessário aguardar a inicialização e o início de cada máquina virtual para instanciar.
Devido à elasticidade da nuvem , os sistemas fornecedores têm uma taxa de utilização de seus sistemas entre 5% e 20%. Como resultado, sempre há recursos disponíveis caso uma forte demanda por recursos chegue de um ou mais clientes.
Os fornecedores se permitem variar seus preços por meio de variações nos custos de nuvem : estes incluem a aquisição e manutenção de hardware, como processadores, memória, disco rígido e rede. O tamanho da memória, o tamanho do espaço em disco utilizado e o custo de transmissão de dados também são levados em consideração na locação pelo cliente.
O Amazon EC2 oferece dois modelos de negócios para seus clientes:
Graças à oferta de instâncias pontuais , a Amazon incentiva seus clientes a usar sua nuvem durante os períodos fora de pico, eventualmente a empresa deseja nivelar a curva de uso de sua nuvem, o que reduzirá os custos de manutenção.
O uso da nuvem pode, devido à sua elasticidade, trazer várias vantagens para o cliente:
Por exemplo, uma start-up que precisasse fazer grandes cálculos pagaria o mesmo preço para usar 1000 máquinas Amazon EC2 por uma hora que 1 máquina por 1000h.
Da mesma forma, no caso de um uso que varia muito ao longo do tempo, é interessante usar a nuvem. Graças à elasticidade da oferta “pré-pago” que muitos fornecedores oferecem, o cliente paga apenas pelo que usa. Por exemplo, no caso de um cliente que usa 500 servidores durante os horários de pico, mas apenas 100 durante os períodos de pico, com uma média de 300 servidores durante o dia. Sem a nuvem, o cliente teria que ter 500 servidores, ou 500 x 24 = 12.000 servidores por hora. Graças à nuvem e sua elasticidade, ele usa apenas 300 x 24 = 7.200 horas de servidor.
Mas esta análise não leva em conta o fato de que a nuvem permite uma adaptação rápida a uma demanda por um recurso incomum, por exemplo, sites de vendas online em dezembro. O impacto aqui é mínimo, ao passo que se o próprio cliente hospedasse seu site, o pedido e a instalação de novos servidores poderia levar várias semanas, sem mencionar o fato de que, depois que os feriados passaram, seus servidores não teriam 'teria sido mais útil .
Em 2010, foi feita uma comparação entre os provedores de nuvem pública: Amazon AWS, Azure, AppEngine e CloudServers. Esses provedores foram avaliados em torno de 4 critérios: elasticidade do cluster , armazenamento persistente, rede intra-nuvem e grandes redes.
Por motivos legais, a identidade dos provedores de nuvem pública é anônima nos resultados e é designada de C1 a C4.
Tamanho do servidor | configuração | Custo / h | custo / núcleo |
---|---|---|---|
Amazon EC2 | |||
pequeno | 1 ECU, 1,7 GB de RAM, 160 GB de espaço em disco | $ 0,085 | $ 0,085 |
alta | 4 ECU, 7,4 GB de RAM, 850 GB de espaço em disco | $ 0,34 | $ 0,085 |
médio - rápido | 5 ECU, 1,7 GB de RAM, 350 GB de espaço em disco | $ 0,17 | $ 0,034 |
XL | 8 ECU, 15 GB de RAM, 1,7 TB de espaço em disco | $ 0,68 | $ 0,085 |
XL- rápido | 20 ECU, 7 GB de RAM, 1,7 TB de espaço em disco | $ 0,68 | $ 0,034 |
Nuvem privada | |||
pequeno | 1 núcleo, 2,8 GHz , 1 GB de RAM, 36 GB de espaço em disco | $ 0,11 | $ 0,11 |
caminho | 2 núcleos, 3,2 GHz , 2 GB de RAM, 146 GB de espaço em disco | $ 0,17 | $ 0,085 |
alta | 4 núcleos, 2 GHz , 4 GB de RAM, 250 GB de espaço em disco | $ 0,25 | $ 0,063 |
Rápido | 4 núcleos, 3 GHz , 4 GB de RAM, 600 GB de espaço em disco | $ 0,53 | $ 0,133 |
XL | 8 núcleos, 2 GHz, 8 GB de RAM, 1 TB de espaço em disco | $ 0,60 | $ 0,075 |
Fornecedor | Tipo de instância | Número de núcleos | Preço |
---|---|---|---|
C1 | C1.1 | 1 | $ 0,085 / h |
C1.2 | 2 | $ 0,34 / h | |
C1.3 | 4 | 0,68 $ / h | |
C2 | C2.1 | 4 | $ 0,015 / h |
C2.2 | 4 | $ 0,03 / h | |
C2.3 | 4 | $ 0,06 / h | |
C2.4 | 4 | $ 0,12 / h | |
C3 | por padrão | N / D | $ 0,10 / hora de CPU |
C4 | C4.1 | 1 | $ 0,12 / h |
C4.2 | 2 | $ 0,24 / h | |
C4.3 | 4 | 0,48 $ / h | |
C4.4 | 8 | $ 0,96 / h |
Um cluster de servidores é carregado para cada uso. Existem dois tipos de modelos de carga entre os provedores: IaaS (AWS, Azure e CloudServers) uma carga baseada no tempo restante alocado, esteja a instância totalmente utilizada ou não; PaaS (AppEngine), carregue com base no consumo de CPU em excesso do aplicativo do usuário por dia.
Os clusters de servidor também são "elásticos" no sentido de que um usuário pode aumentar ou diminuir dinamicamente o número de instâncias usadas. O AppEngine realiza essa mudança de forma transparente, ao contrário do AWS, Azure e CloudServer, que oferece suporte a “dimensionamento opaco”.
Para avaliar a elasticidade dos clusters , foram realizados 3 testes:
Tempo de execução do benchmark semelhante às arquiteturas tradicionais de Benchmarking, pois mede o tempo de execução das tarefas de benchmark. As tarefas de benchmark realizam um teste de estresse em todos os recursos da máquina ( CPU , memória e disco) Custo custo para realizar cada tarefa de benchmark Latência de "escalonamento" este é o tempo decorrido entre o cliente solicitar o recurso e alocar uma nova instância. A latência de "dimensionamento" pode afetar o desempenho e o custo de implantação de um aplicativo.Para os testes, os desempenhos dos clusters são comparados ( benchmark , custo por benchmark e latência de escala ).
Serviço | Cirurgia |
---|---|
Mesa | obter, colocar, consultar |
Blob | download, upload |
Cauda | enviar receber |
Os serviços de armazenamento mantêm o estado e os dados de um aplicativo e são acessíveis a instâncias por meio de chamadas de API. Existem 2 modelos econômicos para operações de armazenamento. Os serviços oferecidos pela Amazon AWS e Google AppEngine são baseados nos ciclos de CPU consumidos para realizar uma operação de armazenamento, o que torna as solicitações complexas mais caras. Azure e CloudServers têm um custo fixo por operação, independentemente da complexidade da solicitação.
Para comparar os fornecedores em termos de armazenamento, foram realizados 3 testes:
tempo de resposta das operações mede o tempo de execução de uma operação de armazenamento. As operações realizadas são apoiadas por todos os fornecedores e frequentemente utilizadas pelos clientes. Essas são operações simples de leitura / gravação, consultas SQL para testar o desempenho dos bancos de dados.Fornecedor | obter | colocar | inquerir |
---|---|---|---|
C1 | 0,13 | 0,31 | 1,47 |
C3 | 0,02 | 0,23 | 0,29 |
C4 | 0,10 | 0,10 | 0,10 |
Fornecedor | instância menor | maior instância |
---|---|---|
C1 | 773,4 | 782,3 |
C2 | 235,5 | 265,7 |
C4 | 327,2 | 763,3 |
Para comparar o desempenho dos provedores ao nível da rede, foram realizados testes na rede intra-nuvem e em redes de longa distância.
A rede intra-nuvem conecta as instâncias de um cliente entre si e os serviços compartilhados por uma nuvem . Para comparar o desempenho de uma rede intra-nuvem , são feitas medições sobre a capacidade e latência do caminho .
A rede de longa distância conecta centros de dados em uma nuvem uns com os outros e hosts externos na Internet. Os fornecedores oferecem várias zonas para hospedar os aplicativos do cliente para reduzir a latência. A AppEngine oferece serviço DNS para escolher automaticamente um data center próximo mediante solicitação, enquanto outros provedores exigem configuração manual. A latência ótima para uma rede de longa distância é definida pela latência mínima entre uma posição ideal e qualquer data center de um fornecedor. O critério para comparar os testes será, portanto, o número de centros de dados disponíveis em um ponto ideal.
: documento usado como fonte para este artigo.