[GTER] Cloud que aceite vmware
Roberto Lima
smuxbr at gmail.com
Mon Jan 23 13:40:02 -02 2017
Concordo com você Flavio na parte do sysadmin velhaco. Mesmo usando AWS as
vezes ainda me vejo com mentalidade de manter uma estrutura grande que não
uso todo o processamento por completo do que hospedar minhas aplicações em
ambientes dos quais facilmente poderia esticar (duplicar instancia e
incluir na elb) ou dando terminate na instancia desejada reduzindo o poder
de processamento com menos utilização e consequentemente os custos.
Em 23 de janeiro de 2017 08:56, Flavio Rescia Dias <
flavioresciadias at gmail.com> escreveu:
> Israel,
>
> Tudo o que você disse, e agradeço por compartilhar suas experiências
> conosco, resumem o que eu disse: "depende".
>
> Apenas uma coisa sobre suas considerações (o Lima também falou disso),
> quando falamos de "desligar o que não precisamos" em EC2, não nos
> referimos, apenas, a dar shutdown em determinados horário, o que queremos
> dizer é "crie as instâncias (ou outros serviços) quando precisar", com isso
> o custo efetivo do que está desligado/não existe é sim zero. Esse é um
> paradigma de quem começa a mexer com AWS, pois é diferente do antigo modelo
> que os sysadmin estão acostumados a trabalhar. É claro que isso não é
> possível com qualquer aplicação e que a persistência dos dados precisa ser
> pensada.
>
>
> On Jan 21, 2017 6:49 PM, "Israel Ramos" <israel.melo.ramos at gmail.com>
> wrote:
>
> Vamos aos números dos que fica mais fácil de entender meu ponto de vista:
> O projeto que citei acima:
>
> 1. Tinha cargas variáveis? SIM. Existiam processos que rodavam em
> horários específicos e consumiam muito CPU, Memória e IO. O tempo de
> duração desses processos era determinado pela performance da máquina de
> cada processo, número de cores e memória.
> 2. Existia consumo de tráfego de dados externo por esses processos? SIM.
> Haviam processos de crawling e chamadas para APIs externas para coleta
> de
> dados de redes sociais.
> 3. Havia necessidade por grande volume de armazenamento? SIM. Na época
> havia cerca de 3 TB armazenados no total e subindo, fora backup.
> 4. Havia necessidade por performance de I/O. SIM. Tínhamos usávamos SSD
> para alguns processos e HDD pra outros.
> 5. Quantas VMs no total? 4 Windows Server 2012 e 8 Ubuntu Server todas
> com diferentes configurações de recursos.
> 6. Havia reserva de recursos não utilizados? SIM. Havia folga para
> provisionar mais máquinas caso necessário tanto para uso em produção
> como
> para testes e outros motivos.
> 7. A performance de hardware era satisfatória para a execução plena do
> negócio e todos os processos. SIM. Com folga.
> 8. Custo mensal disso tudo rodando no dedicado com ESXi na OVH? Cerca de
> €250.
> 9. Custo mensal de uma estrutura com menos máquinas na Amazon AWS?
> Variava entre €450 e €600.
> 10. A performance na AWS era satisfatória? NÃO. Se
> quiséssemos melhora-la teríamos que contratar instancias maiores para
> algumas máquinas e subir novas instancias. O que aumentaria
> drasticamente
> custo total.
>
>
> Ficou mais claro agora?
>
>
>
> On Sat, 21 Jan 2017 at 00:12 Israel Ramos <israel.melo.ramos at gmail.com>
> wrote:
>
> > Flávio,
> >
> > A maioria dos projetos que trabalho são projetos de redução de custos.
> > Utilizando para isso técnicas que vão desde a troca de tecnologias
> > proprietárias por Open Source, passando por reformulação de arquiteturas
> > tanto de software quanto de hardware/rede, passando também por automação
> de
> > processos ou coisas, até chegar a contratação, troca ou eliminação de
> > fornecedores/intermediários de tecnologia. Basicamente os clientes com
> quem
> > trabalho chegam em mim e dizem: "Preciso reduzir os custos do meu
> negócio.
> > Qual é a solução?".
> >
> > Sempre que o cliente faz essa pergunta (Qual é a solução?), a primeira
> > resposta que vem à mente é aquela palavra mágica, velha conhecida de
> > muitos, "DEPENDE". E pelo visto concordamos nesse ponto.
> >
> > Eu poderia responder sua mensagem com um simples "depende". Apesar de ser
> > a resposta mais sincera e correta na maioria das situações, acho chato
> ter
> > que ouvi-la ou dize-la, principalmente quando temos um problema para ser
> > resolvido, assim como o autor da thread demonstrou ter. Então eu vou
> tentar
> > comentar sua mensagem da maneira mais construtiva possível.
> >
> > Primeiramente, só pra reforçar, eu acredito sim que existam casos que AWS
> > e afins são melhor solução. Gosto dessas soluções e as considero serviços
> > fantásticos. Existe muita engenharia brilhante por trás dessas
> plataformas.
> > É muito prazeroso trabalhar com essas soluções. Mas para que a utilização
> > desse tipo de plataforma realmente traga efetividade e custo benefício é
> > necessário fazer a lição de casa e refletir sobre algumas coisas.
> >
> > Quando falamos em AWS estamos falando em um conjunto enorme serviços
> > diferentes montados sob uma estrutura virtualizada composta por N
> camadas.
> > Cada serviço isolado é construído para um determinado propósito. O ponto
> em
> > comum entre todos esses serviços é que foram abstraídos em uma interface
> de
> > operação que permite o provisionamento e gerenciamento facilitado por
> parte
> > do cliente. Trata-se de IaaS - Infrastructure as a Service. Em outras
> > palavras é como um Self Service de infraestrutura.
> >
> > Quanto você contrata 1 serviço na AWS, na verdade está contratando pelo
> > menos 2 coisas diferentes. O primeiro é a capacidade computacional e
> > armazenamento. O segundo é justamente a plataforma de abstração do
> > provisionamento que tenta tornar um pouco mais simples e rápido a
> operação.
> > E apesar de parecer uma coisa só, acredite você está pagando por esses
> dois
> > serviços. E adivinha? É assim que AWS ganha dinheiro. Simplesmente
> > tornando, na maioria das vezes, mais fácil/simples a vida de quem precisa
> > de provisionamento rápido e, em alguns casos mais complexos,
> "elasticidade".
> >
> > Parece um mar de rosas não é mesmo? Concordo. Mas existem fatores
> > importantíssimos a serem considerados, são eles:
> >
> > 1. Todos os recursos na AWS são cobrados separadamente (instancia,
> > armazenamento, recursos e funcionalidades de rede, backup, IP, load
> > balance, etc, etc).
> > 2. Os recursos são oferecidos com perfis de performance diferentes.
> > Geralmente os mais baratos são compartilhados e com limites bem
> estreitos.
> > 3. Se engana quem acha que instancia parada não custe dinheiro.
> > 4. Elasticidade é algo que todo entusiasta de AWS utiliza como
> > principal argumento. Porém, quantos de nós realmente utilizam de forma
> > correta e eficiente os recursos de elasticidade da plataforma?
> Aumentar
> > numero de CPU e memória de uma instancia é possível fazer em qualquer
> > plataforma de virtualização e os recursos de Elasticidade na AWS vão
> muito
> > além disso. Grande parte nem tem conhecimento ou tempo suficientes
> para
> > montar arquiteturas de fato elásticas. É necessário ter tempo, braço,
> > dinheiro e expertise para planejar e implementar sistemas voltados e
> que
> > funcionem para esse propósito (sistemas distribuídos). E para esses
> poucos
> > que tem esses recursos e decidem construir isso em cima da plataforma
> AWS
> > acabam ficando reféns dos próprios serviços existentes lá. De modo que
> se
> > precisar migrar haverá muita dor de cabeça. Ou seja, clientes
> vitalícios,
> > rsrs.
> > 5. Usar AWS pra hospedar um monte de instancias pequenas e isoladas
> > (sem interoperabilidade) ou, o contrário, uma única instancia enorme
> com
> > tudo dentro é burrice na maioria dos casos. Pois os serviços que
> trazem
> > maior beneficio na AWS não são o aluguel instancias. Para aluguel de
> > instancia isolada existem outros fornecedores bem mais baratos como
> por
> > exemplo DigitalOcean ou Linode que, apesar de não oferecerem a grande
> > quantidade de recursos que AWS oferece, também possuem
> provisionamento
> > rápido de coisas simples.
> >
> > Eu poderia listar aqui mais uns 20 fatores a serem considerados, mas não
> > vou me apegar a detalhes. A conclusão que quero expor é que, quando você
> > opta por usar AWS precisa ter clareza sobre suas as reais necessidades e
> > quais recursos da AWS serão indispensáveis para para seu projeto.
> >
> > Na maioria dos casos que abordo acabam sendo necessidades de arquiteturas
> > simples. Geralmente um conjunto de algumas VMs rodando sistemas
> > específicos, funcionalidades de rede básicas, mas que demandam bom poder
> de
> > processamento dedicado e armazenamento. Na ponta do lápis se botar lado a
> > lado você vê que consegue montar estruturas muito mais poderosas pagando
> > muito menos e ainda possuir reserva de recursos de sobra pra suportar o
> > crescimento da empresa por um bom período ou até mesmo para suportar
> alguma
> > demanda sazonal. Tudo isso usando a infraestrutura segura e resiliente do
> > datacenter.
> >
> > Um ponto negativo de trabalhar com dedicado está ligado ao fato de que se
> > alguma falha de hardware ocorrer na sua instancia haverá um tempo de
> > downtime até que o pessoal do dc substitua. Coisa que se evita
> contratando
> > outro hardware e colocando como redundância ou trabalhando em HA (feature
> > que a plataforma de virtualização já te fornece).
> > Outro ponto negativo a ser considerado é que você terá muito mais
> trabalho
> > e complexidade para montar seu ambiente. Mas uma vez montado e
> configurado
> > a manutenção se assemelha muito ao da AWS. A maior parte das tarefas de
> > operação são no escopo de aplicações, serviços, dados e monitoramento,
> > coisa que você precisa fazer pra tocar os negócios independente de rodar
> em
> > dedicado ou AWS.
> >
> > Grande abraço.
> >
> > On Fri, 20 Jan 2017 at 16:14 Flavio Rescia Dias <
> > flavioresciadias at gmail.com> wrote:
> >
> > Israel,
> >
> > Discordando um pouco do que você disse, acredito que em alguns casos o
> > serviço da Bare Metal, como o contratado com os servidores Dedicados da
> > OVH, são mais adequado. Porém não acho que o uso de AWS só se aplique a
> > "coisinhas pequenas" com com orçamento infinito, há diversos casos de
> > aplicações onde o uso de AWS sai mais baixo mesmo se compararmos
> "hardware
> > por hardware" e sem falar dos custos implícitos, seguem alguns deles:
> >
> > - *Uso de muito variável:* Com OVH por exemplo, você mesmo disse que
> > multiplica por 5 sua capacidade computacional, porém se você tem um
> > ambiente que é 6x maior em alguns períodos do dia, mês, ou ano, sua
> > conta
> > fecharia melhor com AWS/Azure/Google Cloud pois com bare metal você
> > precisaria ter 100% do necessário e ainda subtrair contingência, e
> > margem
> > para o que não for previsto, e não estamos falando de ambientes
> > pequenos;
> > - *Alto Processamento:* Você precisaria compra servidores físicos
> muito
> > grande, enquanto com EC2 o custo "a grosso modo" é o mesmo se você
> > tiver 1
> > instância com 1vCPU por 2 horas ou 2 com 1vCPU por 2 horas. Além disse
> é
> > possível o uso de instâncias Spot o diminui muito o custo ;
> > - *Curto Tempo de Deploy:* Quando você trabalha em ambientes que
> > precisam subir estruturas novas em questão de minutos, não conheço um
> > fornecedor que faça mais rápido que a OVH, mas isso depende do estoque
> > deles e pode levar dias.
> >
> > Eu entendi o que você quis dizer e não acho AWS barato, só acho que
> existem
> > outros cenário que AWS/Azure/Google Cloud cai bem.
> >
> > Flávio Rescia Dias
> >
> > Em 20 de janeiro de 2017 10:38, Israel Ramos <
> israel.melo.ramos at gmail.com>
> > escreveu:
> >
> > > Christiano,
> > >
> > > Montei um projeto pra uma empresa Irlandesa.
> > > Contratei um dedicado na OVH (www.ovh.co.uk).
> > > Usei VMware ESXi.
> > > Usei um datacenter deles localizado no Norte da França.
> > > O atendimento dos caras é um pouco ruim, mas o produto é bom.
> > >
> > > Eu migrei a infra inteira deles que estava em instancias EC2 da AWS e
> > > reformulei em cima do ESXi. A capacidade computacional multiplicou por
> 5
> > e
> > > o custo reduziu pela metade.
> > > AWS na minha opinião sempre custou muito caro. Só vale a pena para
> > > coisinhas pequenas ou quando o dinheiro não é problema.
> > >
> > > No caso foi para uma empresa que estava na Irlanda então a latência não
> > foi
> > > problema para hospedar na França. Agora se a empresa/usuários/trafego
> for
> > > proveniente do Brasil talvez não valha a pena (depende muito do tipo de
> > > serviço que você vai querer hospedar). Nesse caso tentaria algo em DCs
> > aqui
> > > do Brasil mesmo.
> > >
> > > Se precisar de ajuda, estamos ai.
> > >
> > > Grande abraço.
> > >
> > >
> > > On Fri, 20 Jan 2017 at 10:05 Luzemário Dantas <
> luzemario at luzehost.com.br
> > >
> > > wrote:
> > >
> > > > Sim, a SoftLayer aceita.
> > > >
> > > > Fornecem licenças VMWARE Server atá nos pacotes Cloud (como opcional,
> > > > pago à parte), assim você tem "virtualização dentro da
> virtualização".
> > > >
> > > > Luzemário
> > > >
> > > > Em 19-01-2017 15:41, Douglas Fischer escreveu:
> > > > > Talvez tua pergunta seria:
> > > > > Clouds que aceitem Nested Virtualization...
> > > > >
> > > >
> > > > --
> > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list