Reduzindo custos com Microsoft na AWS
•Transferir como PPTX, PDF•
0 gostou•193 visualizações
O documento discute várias estratégias para reduzir custos com Microsoft na AWS, incluindo otimizar bancos de dados SQL, armazenamento, sistemas operacionais, computação de usuário final, aplicações e serviços de identidade. É fornecida orientação detalhada sobre como mover cargas de trabalho para a nuvem de forma econômica.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Reduzindo custos com Microsoft na AWS
Semelhante a Reduzindo custos com Microsoft na AWS (20)
Mais de Amazon Web Services LATAM
Mais de Amazon Web Services LATAM (18)
Reduzindo custos com Microsoft na AWS
- 1. © 2021, Amazon Web Services, Inc. or its Affiliates. Caio Ribeiro César Principal Microsoft Specialist Solutions Architect Amazon Web Services (AWS) Reduzindo custos com Microsoft na AWS
- 2. © 2021, Amazon Web Services, Inc. or its Affiliates. Agenda • Redução de custos – Bancos de DadosWindows • Redução de custos – StorageWindows • Redução de custos – Sistemas Operacionais & Operações Windows • Redução de custos – Computação de Usuário final (EUC) Windows • Redução de custos – AplicaçõesWindows • Redução de custos – Serviços de IdentidadeWindows • Redução de custos - Outras considerações
- 3. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Bancos de Dados Windows
- 4. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – Bancos de DadosWindows Parte 1) SQL em EC2 a) Utilize o Migration Evaluator e o OLA http://tiny.cc/aws_ola b) De acordo com o right sizing, tipo de instância certo (r5, x1e, m5) c) CPU Optimization d) BYOL vs. LI e) SQL Workload Consolidation
- 5. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – Bancos de DadosWindows f) Step Down de Ent para Std g) Utilizando Dedicated Hosts h) Block Level Replication para DR i) GP2 Striping vs. IO1-IO2 vs. GP3 j) Dev Edition & Dev Fabric http://tiny.cc/4htutz Sessões 1hr e BlogPost -- Cost-Optimize SQL Server on AWS - http://tiny.cc/rgtutz Blog Post - http://tiny.cc/tgtutz
- 6. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – Bancos de DadosWindows Parte 2) RDS SQL a) RDS Reservation b) Backup – ETL vs. Snapshots
- 7. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Storage Windows
- 8. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – StorageWindows Parte 1) Amazon FSx a) Data Deduplication Documentos de usuário final – 30-50% General Purpose – 50-60% SW Dev DB – 70-80% SQL – 0% :) b) % disco *PROVISIONADO* - integração com Cloudwatch + Alarm
- 9. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – StorageWindows f) Quota g) Benchmark correto para throughput (diskpd, perfmon, etc) h) DFS-N fs-0123456789.example.comSales fs-9876543210.example.comProjects fs-5678901234.example.comMarketing example.comcorp Sales Marketing Projects
- 10. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – StorageWindows Parte 2) EBS a) GP3 http://tiny.cc/vhtutz b) HDD vs. SSD
- 11. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: S.O. & Operações Windows
- 12. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de custos – Sistemas Operacionais & Operações Windows 1) Migration Evaluator, OLA, Trusted Avisor, Cloudwatch, SNMP, right sizing, right sizing, right sizing! 2) WSUS vs. SSM 3) RDGW vs. SSM 4) Whatever vs. SSM 5) ADFS vs. Azure AD Connect Passthrough auth (+1 staging) 6) Dev vs. PRD e o benchmark de 39% (AWS Instance Scheduler) 7) BYOL para OS (DH) 8) EC2 Reservation
- 13. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: EUC Windows
- 14. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: EUC Windows 1) Bring Your Own Windows Desktop Licenses == 200 seats (mix AlwaysOn, AutoStop) http://tiny.cc/5itutz 2) AppStream 2.0 versus Workspaces
- 15. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Aplicações Windows
- 16. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos AplicaçõesWindows 1) EC2 vs. Containers (ECS, EKS) [App2Container] 2) ECS com Spot Instances 3) PortingAssistant (Windows vs. Linux)
- 17. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Serviços de Identidade Windows
- 18. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Serviços de Identidade Windows 1) AWS SSO + MFA + ABAC + AD = custo apenas da camada de Broker (AD) 2) AWS MAD (SPLA) vs. Modelo Microsoft (CAL) a) Perpetual, por ano ou algum acordo específico com MS b) Exemplo 100k usuários AWS MAD Enterprise Edition, São Paulo USD 4.5k/ano Microsoft 2x DCs (custo de VMs, etc) + CAL 100k*15= USD 1.5MM/ano
- 19. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Outras considerações
- 20. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Outras considerações 1) GRU vs. US Pontos de atenção: DTO, Latência 2) AWS Cost Explorer Mais Informações - http://tiny.cc/awscost
- 21. © 2021, Amazon Web Services, Inc. or its Affiliates. Redução de Custos: Outras considerações 3) Babelfish para Aurora PostgreSQL (PREVIEW) 4) Programas de benefício Aceleração de migração da AWS para Windows http://tiny.cc/mapwindows Startups – USD 100k credits http://aws.amazon.com/activate Database Freedom (DMS SQL para Aurora) http://tiny.cc/xjtutz
- 22. © 2021, Amazon Web Services, Inc. or its Affiliates. Muito Obrigado!
Notas do Editor
- AWS Webinar Series Brasil: Reduzindo custos com Microsoft na AWS entender como a AWS pode ajudar a otimizar seu licenciamento, reduzindo seus custos com Windows Server e SQL Server. Você aprenderá como executar workloads de Windows Server e SQL Server na AWS, bem como trazer seu licenciamento da Microsoft para a AWS, estratégias para reduzir o custo dessas cargas de trabalho e como gerenciar suas licenças na nuvem. Principais tópicos apresentados: • Licenciamento da Microsoft na AWS; • Licenciamento do SQL Server na AWS; • Otimização de custos para cargas de trabalho Microsoft Windows (Banco de Dados, Storage, Sistema Operacional, Soluções de End User Compute, Aplicações, Identidade).
- 1) Como posso utilizar o OLA? Você pode trabalhar com um parceiro como Cloudmize, Cloudchomp ou até mesmo diretamente junto a AWS, conversando com seu gerente de conta. Faremos uma avaliação detalhada, coletando seus dados de infraestrutura. O OLA fornecerá uma compreensão de como seus recursos estão sendo utilizados na origem, com relação as licenças e recursos, para nos dar um ponto de dados melhor para fornecer uma previsão precisa de como reduzir no ambiente de destino. Mas como? A partir da avaliação, podemos obter dados de desempenho e entender se você está com provisionamento excessivo ou com licenciamento acima do necessário. 2) Precisamos sempre alinhar a carga de trabalho com o tipo certo de instância necessária. As instâncias amarelas desta lista também estão disponíveis em RDS e as sublinhadas também podem ser usadas como Dedicated Hosting. Para cargas de trabalho SQL Server associadas à memória tradicional, damos ênfase para as instâncias com memória otimizada, como r5 ou x1, e geralmente são instâncias adequadas. Se o seu ambiente for CPU “bounded” (com maior foco no consumo de CPU), oferecemos instâncias de computação intensiva, como a família c5. Ao escolher o tamanho de computação correto para sua carga de trabalho significa que você está obtendo a proporção correta de memória e CPU e não está superprovisionando recursos, portanto, custos de licenciamento também. Além disso, as instâncias R5b trazem IOPS mais alto e, consequentemente, maior largura de banda. Como a maioria dos ambientes SQL Server são IOPS “bounded“, você pode precisar de menos núcleos (vCPU) e mais memória e performance de disco, portanto, menos necessidades de licenciamento. 3) Se olharmos para trás no mundo on-premises, ao construir o SQL Server, pediríamos um servidor com muita memória RAM (suponhamos 4 TB de memória) para um ambiente SQL clássico. Naquela época, normalmente não precisávamos de altas contagens de CPU, pois dependíamos da memória. Hoje em dia você pode obter o mesmo servidor na nuvem, com os mesmos 4 TB de memória, que será fornecido com uma alta de quantidade de CPU, o que aumentará o custo de licenciamento. Porém podemos reduzir este custo de licenciamento com o CPU Optimization. Isso significa que podemos solicitar uma instância com muita memória RAM (como a r5 ou x1 mencionada anteriormente*) e, em seguida, habilitar o recurso de CPU Optimization para ela, usando menos núcleos e pagando menos licenças do SQL Server, o que reduzirá seus custos de banco de dados. 4) Como você já deve ter percebido neste ponto, entender o licenciamento é fundamental para reduzir o custo dos ambientes de SQL Server. Os clientes adotam o BYOL (Bring Your Own License) por uma série de razões, sendo algumas delas exemplos como: já possuir suas licenças no ambiente de origem, aproveitar o benefício de usar suas licenças não utilizadas em ambientes híbridos, usar seus benefícios de garantia de software, como não pagar por seus nós passivos em cenários de HA ou DR com software assurance. Por outro lado, os clientes também optam pelo modelo de “license included”, pois evita a complexidade dos requisitos de licença do SQL Server, como high water mark rule e outros. Consequentemente estes clientes também podem licenciar seu ambiente em uma base mensal e, em seguida, desligar os servidores quando o projeto for concluído, pagando apenas pelo que usam e também eliminando a necessidade de ter acordos com a Microsoft, como o Enterprise Agreement e o SCE. Além disso, às vezes não sabemos o quão “ocupado” o servidor vai estar, portanto, a licença incluída ajuda a não fazer um compromisso até que entendamos a carga de trabalho Não existe mágica. A combinação dessas duas ofertas tornará você mais dinâmico e adaptável às mudanças em seu ambiente. O mais importante é simplesmente entender quando escolher uma das opções. Lembre-se: BYOL só é aplicável ao EC2, enquanto License Included se aplica tanto ao EC2 quanto ao RDS. 5) Lembram quando mencionamos que precisamos de licenças de 4 núcleos no mínimo como um requisito para SQL Server? Isso significa que é uma boa ideia consolidar cargas de trabalho de SQL de pequeno porte em instâncias de tamanhos maiores. O que significa que posso escolher instâncias com tamanho abaixo dos quatro núcleos mínimos e combiná-los em um único servidor. No exemplo abaixo, temos quatro instâncias SQL, cada uma dimensionada com 2 vCPUs para um total de 8 vCPUs, mas que requer 16 núcleos sendo licenciados! Ao consolidar essas quatro instâncias em 2 instâncias maiores, eliminamos 50% do custo de licenciamento.
- 6) O step-down (reduzir o nível do licenciamento) da edição Enterprise para a Standard reduzirá o custo de licenciamento, bem como os custos anuais de Software Assurance. A partir do Service Pack 1 do SQL Server 2016, muitos recursos exclusivos para Enterprise também se tornaram disponíveis para a versão Standard. Isso significa que você pode estar executando um ambiente que não requer mais a edição Enterprise. Mais recentemente, no SQL Server 2019, a funcionalidade Transparent Data Encryption (TDE) tornou-se uma opção da edição Standard. Neste ponto, a pergunta que precisamos nos fazer é: eu preciso da edição Enterprise? Se você estiver usando Read Replica, reindexação online, se seus servidores usarem mais de 128 GB de RAM para SQL Server, então sim. Compreender o ambiente e combinar a edição de licença apropriada é importante. Outro exemplo é a arquitetura de alta disponibilidade para essas versões. Para a edição Enterprise, conforme ilustrado abaixo, usamos o grupo de disponibilidade Always On, com réplicas primária, passiva e de leitura versus o Standard, em que podemos implementar o mesmo modelo de alta disponibilidade usando cluster de failover do Windows Server e FSx como nosso armazenamento compartilhado. Antes de fazer o downgrade, temos que levar alguns pontos em consideração, como por exemplo se você está no meio do prazo de seu Contrato Empresarial e se já adquiriu essas licenças em direitos de uso perpétuo. 7) Se você já possui licenciamento do sistema operacional Windows e deseja trazer suas licenças de software da Microsoft que não estão cobertas pelos benefícios do Software Assurance ou Mobilidade de Licença, você pode. Contanto que as licenças sejam adquiridas antes de 1º de outubro de 2019, ou adicionadas como um true-up sob um Enterprise Enrollment ativo que entrou em vigor antes de 1º de outubro de 2019. EC2 Dedicated Hosts são recomendados para clientes que desejam trazer suas licenças de SQL Server sem Software Assurance ativo. Para que o SQL Server sem Software Assurance ativo seja elegível ao BYOL no EC2 Dedicated Host, a versão requerida deve ser um SQL Server 2017 ou anterior, e a licença deve ser adquirida junto a Microsoft antes de 1º de outubro de 2019, ou adquirida como um true-up sob um contrato Enterprise ativo que entrou em vigor antes de 01/10/2019. O que significa que se a licença não atender a esses requisitos, os termos de licenciamento da Microsoft não permitirão o BYOL e consideramos então um RDS SQL ou EC2 com licença inclusa. Hosts dedicados (DH – Dedicated Hosts) podem oferecer benefícios de custo significativos e permitir que os clientes controlem o colocation de suas instâncias e licenças em um host fisicamente dedicado ao seu uso. Para sistemas locais que usam intensamente virtualização ilimitada do Windows/SQL Server e desejam continuar a usar essa licença, DH é o caminho para fazer isso. Se você usa muito seu hypervisor e licencia o SQL Server por núcleos físicos, a locação compartilhada rapidamente torna o custo elevado demais para as cargas de trabalho do SQL Server, portanto, o DH pode ser uma opção melhor. É importante ressaltar que nem todos os clientes licenciam o SQL Server no modelo de “core licensing”. Clientes podem licenciar o Host Dedicado completo com SQL Enterprise Server + CAL, mas não podem alocar um número ilimitado de instâncias dentro deste Dedicated Host. Se formos comparar com ambientes on-premises, mesmo um host VMware não pode tecnicamente executar um número ilimitado de VMs com SQL Server. Uma licença SQL Server Enterprise + CAL cobre o host, e então esse host é coberto por até 4 instâncias para um total de 20 vCPUs para estas instâncias. Se o cliente deseja ter mais de 4 instâncias/20 vCPUs em execução no host, ele pode simplesmente adicionar outra licença SQL Server Enterprise + CAL ao mesmo host para permitir um total de 4 instâncias/20 vCPUs adicionais. Além disso, neste modelo de licenciamento, o cliente também deve ter o número correto de CALs do SQL Server para cobrir os usuários/dispositivos com acesso direto ou indireto às instâncias do SQL Server no host. Para finalizar, a automação do DH lida com a alocação de hosts, alocação de instâncias e, mais importante, recuperação (por exemplo, um auto-recovery em uma AZ diferente do DH original). Isso torna a experiência de configuração consistente, como as implantações de “shared tenancy”. 8) A replicação em bloco não apenas eliminará o requisito de licença do SQL Core em DR, mas também eliminará as instâncias EC2 que estariam em execução 24 horas por dia, 7 dias por semana no ambiente de recuperação de desastres (DR). A replicação de bloco é simplesmente copiar os dados brutos do disco de origem para o disco de destino – em nosso caso, o EBS. Digamos que temos uma carga de trabalho SQL ativa/passiva usando BYOL, e já estamos usando os direitos de uso passivos do licenciamento. No entanto, é realmente importante entender que você só tem o direito de 1 uso passivo. O que acontecerá se também tivermos um requisito de DR para esse mesmo ambiente? Não importa como você projeta o nó de DR, se o SQL Server está lidando com a replicação ou mesmo o envio de log, você está sem direitos de uso passivo gratuito e tem que licenciar o DR como se fosse um ambiente ativo. É por isso que usar grupos de disponibilidade Always On para oferecer suporte a DR multirregional pode aumentar o custo da licença! Qual poderia ser a solução? Algo tão simples como a replicação em bloco para o ambiente de DR pode fornecer proteção de DR sem exigir nenhuma licença SQL Server, até que você mude para o DR. Isso evita o custo de licenças extras necessárias e pode reduzir os custos de computação de DR, uma vez que o SQL Server não está em execução até que ocorra um evento de DR. Logicamente, o grupo de disponibilidade Always On é uma tecnologia superior ao block-level replication. Porém, temos que ter em mente o custo-benefício da solução e principalmente valores necessários de RPO (Recovery Point Objective) e RTO (Recovery Time Objective), já que em block-level replication, temos que configurar o cluster via script ou manualmente. 9) O armazenamento em bloco persistente é um componente crítico e, em última análise, responsável pela velocidade, segurança e durabilidade de seus dados. A AWS fornece armazenamento em bloco de alto desempenho e fácil de usar para atender às necessidades do SQL Server por meio do EBS. Embora você possa usar um único volume Provisioned IOPS (io1 ou io2) para atender aos seus requisitos de IOPS e taxa de transferência, os volumes General Purpose SSD (gp2) oferecem um equilíbrio líder de preço e desempenho para cargas de trabalho do SQL Server quando configurados adequadamente. Os volumes GP2 fornecem latências de milissegundos de um dígito e a capacidade de expandir para 3.000 IOPS por longos períodos. Essa propriedade é adequada para SQL Server em cargas de trabalho não críticas, onde o desempenho máximo não é necessário 24 horas por dia. Além disso, o GP3 tem custo menor quando comparado ao GP2 (uma redução de aproximadamente 20%) e não possui a necessidade de aumentar o volume para aumentar IOPS! Se você precisar de desempenho consistente, precisará de soluções IOPS provisionadas, como io1 e io2. O IO2 tem mais rendimento por gibibyte e muito mais durabilidade quando comparado ao IO1. Para mais informações de GP2 striping, clique aqui. 10) Embora possa parecer simples, alguns clientes pagam licenciamento para seu ambiente de desenvolvimento. O SQL Server Developer é uma edição gratuita com recursos completos, licenciada para uso como banco de dados de desenvolvimento e até mesmo de teste em um ambiente de não produção. Isso significa que você pode desenvolver e testar SQL Server sem a necessidade de licenciar. Também podemos dar um passo adiante se quisermos reduzir mais custos – na camada do sistema operacional – com ressalvas. Com o SQL Server no Linux, temos o mesmo mecanismo de banco de dados SQL, com recursos e serviços semelhantes. Alguns clientes optam por executar seus ambientes de desenvolvimento e homologação no Linux. O Ubuntu, por exemplo, terá um custo menor de implementação quando comparado ao Windows. Suponhamos que você tenha um ambiente de desenvolvimento SQL Server e queira permitir que seus desenvolvedores façam testes de unidade, que são, em resumo, testes de pequenas alterações em seus códigos. Alguns ambientes de desenvolvimento usam licenciamento de produção incorretamente para seu ambiente de desenvolvimento. Com as inscrições do MSDN, esse não era um problema real; mas hoje em dia pode ser. Com o AWS Dev fabric para SQL Server, que é uma solução de código aberto disponível no GitHub e criada por nossa equipe de arquitetos, podemos ajudar os clientes a reduzir significativamente o trabalho pesado do Amazon EC2. Isso é específico para ambientes de desenvolvimento, permitindo a implantação de várias instâncias do SQL Server em minutos para oferecer suporte às necessidades individuais dos desenvolvedores e aos esforços da equipe de desenvolvimento em minutos, além de remover as necessidades de licenciamento do Windows EC2. Esta solução executa o Ubuntu Linux em contêineres e traz a possibilidade de economizar quando comparada ao Amazon EC2 Windows, tornando-o uma boa opção para ambientes de desenvolvimento enquanto replataforma a camada de banco de dados.
- As instâncias reservadas do Amazon RDS permitem que você reserve uma instância de banco de dados por um período de vigência de um ou três anos e, em troca, receba um desconto considerável em comparação à definição de preço de instâncias sob demanda para a instância de banco de dados. ETL – para s3, tempo maior Snap - snap needs enterprise if restore from Std
- Dedup para sql não existe
- Dedup para sql não existe
- Dedup para sql não existe
- ECS is not just containers, ecs is an orchestration platform for docker. Similar to kubernetes or docker swarm. With Ecs you still need to provide the underlying hosts to ecs - ecs simply manages your 'services' and 'task definitions' to help with scaling and auto healing. Ecs is free service - you pay for the underlying host (ec2). So the title of your post is ECS vs EC2 means more of 'should I use ecs or use another docker orchestration tool self managed on ec2.' The answer to that question is difficult and depends on your needs - if you need an extremely robust, scalable, and need tight controls over your containers, you would use kubernetes on ec2 or EKS. If you just need simple orchestration but still want to manage it - you would use docker swarm on ec2. If you want ease of use and want access to your hosts - you'd want ecs and supply and configure your own ec2. If you want to never think about anything other than the container - you want fargate. Pricing (your second question) - removing the possibility of doing enterprise licensing and assuming you're going open source - kubernetes on ec2 and swarm on ec2 are probably your most expensive as you'll need to run at least 3 manager nodes that are doing no work and then a few worker nodes that have containers. If you use EKS or ecs on ec2 your talking middle of the road to cheapest option - but still have to manage the host (updates, manage scaling etc). Then there's fargate - potentially expensive if you use it unoptimized - but if you optimize your app it can be the cheapest - with the added bonus of not having to ever deał with hosts - you can focus exclusively on your app and the containers.
- Se as estações de trabalho em sua organização estiverem conectadas em rede, você provavelmente dependerá do software do servidor de rede para executar certas funções, como compartilhamento de arquivos e impressão. Para acessar este software de servidor legalmente, pode ser necessária uma Client Access License (CAL). Uma CAL não é um produto de software; em vez disso, é uma licença que dá ao usuário o direito de acessar os serviços do servidor. CALs são necessárias para cada usuário ou dispositivo que acessa um servidor e isso vai depender do que? Quantos usuários você tiver!
- Run Microsoft SQL Server applications on PostgreSQL with little to no code change - babel