Transferir como PDF, PPTX
![Como acessar um sistema de arquivos a partir de
uma instância
• Você “monta” um sistema de arquivos numa
instância EC2 (comando padrão) — o sistema de
arquivos vai aparecer como um conjunto local de
diretórios e arquivos
• NFS v4 é padrão nas distribuições linux
mount –t nfs4
[file system DNS name]:/
/[user’s target directory]](https://image.slidesharecdn.com/elasticfilesystemeaurora-150608180025-lva1-app6891/75/Elastic-file-system-e-aurora-20-2048.jpg)
![Simule falhas usando SQL
• Para causar a falha de um componente no nó do banco de dados:
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
• Para simular uma falha no storage:
ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval
• Para simular uma falha na rede:
ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval](https://image.slidesharecdn.com/elasticfilesystemeaurora-150608180025-lva1-app6891/75/Elastic-file-system-e-aurora-62-2048.jpg)
Carregado porAmazon Web Services LATAM
Elastic file system e aurora
1. O documento apresenta o novo banco de dados relacional da AWS chamado Amazon Aurora. 2. O Aurora foi projetado para superar as limitações das arquiteturas de bancos de dados tradicionais, que são monolíticas e não escalam horizontalmente de forma eficiente. 3. O Aurora usa uma arquitetura orientada a serviços, distribuindo camadas como armazenamento e log em outros serviços AWS para melhor desempenho, disponibilidade e escalabilidade.
Mais conteúdo relacionado
Semelhante a Elastic file system e aurora
Elastic file system e aurora
- 1.
- 2. ©2015, Amazon WebServices, Inc. or its affiliates. All rights reserved Introduzindo Amazon Elastic File System (EFS) Angelo Carvalho, Partner Solutions Architect, AWS
- 3. Agenda 1. Visão geraldo EFS 2. Conceitos técnicos do EFS 3. Mecanismos de Segurança do Sistema de Arquivos 4. Modelo de disponibilidade e durabilidade
- 4. Visão Geral doAmazon EFS
- 5. Portfolio de Storageda AWS Amazon S3 • Storage de Objetos: dados apresentados como buckets de objetos • Dados acessados por APIs através da Internet Amazon EFS • Storage de arquivos (análogo ao NAS): dados apresentados como um file system • Acesso de baixa latência e compartilhado a partir de múltiplas instâncias EC2 Amazon Elastic Block Store • Storage de Blocos (análogo ao SAN): dados apresentados como discos/volumes • Acesso de menor latência a partir das Instâncias EC2 Amazon Glacier • Storage para Arquivamento: dados apresentados como vaults/archives de objetos • Storage de menor custo, para dados não acessados frequentemente
- 6. O Que éo Amazon EFS? • Um sistema de arquivos gerenciado para as instâncias EC2 • Fornece a semântica padrão para sistema de arquivos • Funciona com as APIs de sistemas operacionais para sistemas de arquivos • Compartilhável entre milhares de instâncias • Cresce elasticamente a uma escala de petabytes • Entrega performance para uma variedade de workloads • Altamente disponível e durável • Baseado em NFS v4
- 7. EFS é desenhadopara um amplo leque de casos de uso, como… • Repositório de Conteúdo (CMS) • Ambientes de Desenvolvimento • Diretórios de Usuários • Big data
- 8. Operar um storagede arquivos compartilhado é difícil Application owner or developer IT administrator Business owner • Estima a demanda • Compra hardware • Reserva espaço físico • Configura e mantém o hardware (e a rede) • Gerencia acesso e segurança • Fornece uma estimativa de crescimento • Precisa adicionar o tempo do provisionamento da infra no seu cronograma • Limita a flexibilidade e e agilidade • Faz investimentos adiantados, compram mais do que o necessário, ciclo constante de atualização/modernização • Sacrificam a agilidade do negócio • Distraem as pessoas da verdadeira missão do negócio
- 9. EFS muda estejogo completamente EFS é simples EFS é elástico EFS é escálavel 1 2 3
- 10. EFS é simples •Totalmente gerenciado – Sem hardware, rede, camada de arquivos – Cria um sistema de arquivos escalável em segundos! • Integração precisa com ferramentas e aplicações existentes – NFS v4—muito adotado, aberto – Semântica padrão para o sistema de arquivos – Funciona com as apis padrões do SO • Preço simples = Estimativa simples 1
- 11. EFS é elástico •Sistemas de arquivos crescem e diminuem automaticamente conforme você adiciona ou remove arquivos • Não é preciso provisionar capacidade ou performance • Você paga somente pelo que você usa, não existe valor mínimo 2
- 12. • Sistemas dearquivos podem crescer para uma escala de petabytes • Throughput e IOPS escalam automaticamente conforme o sistema de arquivos cresce • Baixa latência consistente independente do tamanho do arquivo • Suporte para milhares de conexões NFS concorrentes EFS é escalável3
- 13. Porque isso éimportante?... … para app owners e developers? … para seu negócio? • Fácil mover para a nuvem código existente, aplicações e ferramentas que hoje usam servidores NFS • Storage de arquivos simples para novas aplciações nativas para cloud • Preço previsível sem investimento inicial • Mais agilidade • Gaste menos tempo gerenciando storage e mais tempo focado no seu business … para administradores de TI? • Elimina a necessidade de gerenciar e manter storage em larga escala
- 14.
- 15. Alguns conceitos chaveque precisamos entender • Região • Zona de Disponibilidade (AZ) • Amazon Virtual Private Cloud (VPC)
- 16. Região • Áreas geográficasonde os serviços AWS estão disponíveis • Clientes escolhem a região onde irão provisionar seus recursos • Onze regiões ao redor do mundo REGIÃO
- 17. Zona de Disponibilidade(AZ) • Cada região tem múltiplas localidades isoladas conhecidas como zonas de disponibilidade • Links de baixa latência entre AZs dentro de uma região • Ao lançar uma instância EC2, o cliente escolhe qual AZ AVAILABILITY ZONE 3 EC2 AVAILABILITY ZONE 2 AVAILABILITY ZONE 1 EC2 EC2 EC2 REGIÃO
- 18. Virtual Private Cloud(VPC) • Sessão isolada da nuvem AWS, rede virtual definida pelo cliente • Ao lançar instâncias e outros recursos, clientes os colocam numa VPC • Todos os novos clientes tem uma VPC default AVAILABILITY ZONE 1 REGION AVAILABILITY ZONE 2 AVAILABILITY ZONE 3 VPC EC2 EC2 EC2 EC2
- 19. O que éum sistema de arquivos? • O recurso primário no EFS • Onde você armazena arquivos e diretórios • Você pode criar quantos sistemas de arquivos você quiser pra cada conta.
- 20. Como acessar umsistema de arquivos a partir de uma instância • Você “monta” um sistema de arquivos numa instância EC2 (comando padrão) — o sistema de arquivos vai aparecer como um conjunto local de diretórios e arquivos • NFS v4 é padrão nas distribuições linux mount –t nfs4 [file system DNS name]:/ /[user’s target directory]
- 21. O que éum “mount target”? • Para acessar o seu sistema de arquivos a partir das instâncias numa VPC, você cria mount targets na VPC • Um mount target é um endpoint NFSv4 endpoint na sua VPC • Um mount target tem um endereço IP e um nome DNS que você usa no seu comando “mount” AVAILABILITY ZONE 1 REGION AVAILABILITY ZONE 2 AVAILABILITY ZONE 3 VPC EC2 EC2 EC2 EC2 Mount target
- 22. Juntando tudo, ficaassim: ZONA DE DISPONIBILIDADE 1 REGIÃO ZONA DE DISPONIBILIDADE 2 ZONA DE DISPONIBILIDADE 3 VPC EC2 EC2 EC2 EC2 File System do Cliente
- 23. Existem três formasde configurar e gerenciar um sistema de arquivos • AWS Management Console • AWS Command Line Interface (CLI) • AWS Software Development Kit (SDK)
- 24. Cada uma lhepermite executar uma variedade de tarefas de gerenciamento • Criar um sistema de arquivos • Criar e gerenciar mount targets • Adicionar uma Tag num sistema de arquivos • Excluir um sistema de arquivos • Ver os detalhes dos sistemas de arquivos da sua conta AWS
- 25. Configurar e montarum sistema de arquivos leva menos de um minuto 1. Criar um sistema de arquivos 2. Criar um “mount target” em cada AZ onde você pretende acessar o sistema de arquivos 3. Habilitar o cliente NFS nas suas instâncias 4. Executar o comando “mount”
- 26. Segurança no seuSistema de Arquivos
- 27. Vários mecanismos deSegurança • Controle o tráfego de rede para e a partir dos seus sistemas de arquivos (mount targets) usando os security groups e network ACLs da sua VPC • Controle o acesso aos arquivos e diretórios usando o mecanismo padrão de permissões para diretórios e arquivos do seu sistema operacional • Controle o acesso administrativo (acesso a API) aos sistemas de arquivos usando o AWS Identity and Access Management (IAM)
- 28. Apenas instâncias EC2na VPC que você especificar podem acessar o seu sistema de arquivos Sistema de arquivos do Cliente VPC EC2 EC2 EC2 EC2 VPC EC2 EC2 EC2 EC2
- 29. VPC EC2 EC2 Security groups controlamquais instâncias na sua VPC podem se conectar aos seus “mount targets” Sistema de arquivos do Cliente Security group: sg-allowed Security group: Permit inbound traffic from “sg-allowed” Security group: sg-not-allowed
- 30. EFS suporta permissõesa nível de usuário para arquivos e diretórios • Configure permissões nos arquivos e diretórios para especificar permissões read-write-execute para usuários e grupos
- 31. Integração com IAMfornece segurança administrativa • Use IAM policies para controlar quem usa as APIs administrativas para criar, gerenciar e excluir sistemas de arquivos • EFS suporta permissões action-level e resource-level
- 32. Disponibilidade Regional eDurabilidade
- 33. Em quais regiõesposso usar o EFS? • US-West (Oregon) • US-East (Northern Virginia) • EU (Ireland)
- 34. Dados são armazenadosem múltiplas AZs para alta disponibilidade e durabilidade • Cada objeto do sistema de arquivos (diretório, arquivo, e link) é redundantemente armazenado em múltiplas AZs na mesma região ZONA DE DISPONIBILIDADE 1 REGIÃO ZONA DE DISPONIBILIDADE 2 ZONA DE DISPONIBILIDADE 3 Amazon EFS
- 35. Dados podem seracessados a partir de qualquer AZ na região enquanto mantém consistência total • Suas instâncias EC2 podem se conectar ao seu sistema de arquivos EFS a partir de qualquer AZ na região • Todas as leituras e escritas serão totalmente consistentes em todas as AZs — isto é, uma leitura em uma AZ retornará o dado mais atualizado, mesmo se este dado tiver sido escrito em outra AZ AVAILABILITY ZONE 1 REGION VPC EC2 EC2 EC2 AVAILABILITY ZONE 2 AVAILABILITY ZONE 3 EC2 Write Read
- 36.
- 37. Preço simples eprevisível • Com o EFS, você paga somente pelo espaço de storage que você usa • Sem valor mínimo ou adiantamentos de pagamento – Não é necessário provisionar adiantado – Nenhuma outra taxa ou cobrança • Preço do EFS: $0.30/GB-month
- 38. ©2015, Amazon WebServices, Inc. or its affiliates. All rights reserved Amazon Aurora: Novo Engine de Banco de Dados Relacional da Amazon Angelo Carvalho, Partner Solutions Architect, AWS
- 39. As arquiteturas debancos de dados atuais são monolíticas Múltiplas camadas de funcionalidades numa única caixa SQL Transactions Caching Logging
- 40. As arquiteturas debancos de dados atuais são monolíticas Mesmo quando você escala horizontalmente, você ainda está replicando a mesma pilha de funcionalidades SQL Transactions Caching Logging SQL Transactions Caching Logging Application
- 41. As arquiteturas debancos de dados atuais são monolíticas SQL Transactions Caching Logging SQL Transactions Caching Logging Application Mesmo quando você escala horizontalmente, você ainda está replicando a mesma pilha de funcionalidades
- 42. As arquiteturas debancos de dados atuais são monolíticas SQL Transactions Caching Logging SQL Transactions Caching Logging Storage Application Mesmo quando você escala horizontalmente, você ainda está replicando a mesma pilha de funcionalidades
- 43. Isto é umproblema. Para custo. Para flexibilidade. E para disponibilidade.
- 44. Reimaginando o bancode dados relacional E se você estevise inventando os bancos de dados hoje? Você não o desenharia da mesma forma como nós fizemos em 1970. pelo menos não inteiramente. Você costruirira algo que escala horizontalmente, que se recupera automaticamente de falhas, e que faz uso dos serviços AWS existentes.
- 45. Bancos de dadosreimaginados para a nuvem Velocidade and disponibilidade dos bancos de dados comerciais de última geração Simplicidade e custo-benefício dos bancos de dados open source Compatiblidade com MySQL Precificação simples pay as you go Entregue como um serviço gerenciado
- 46. Uma arquitetura orientadaa serviços aplicada a um banco de dados • Movemos as camadas de logging e storage para um storage multi-tenant, que escala horizontalmente e que é otimizado para bancos de dados • Integramos com oustros serviços AWS como Amazon EC2, Amazon VPC, Amazon DynamoDB, Amazon SWF, and Amazon Route 53 para as operações de control plane • Integrado com o Amazon S3 para backup contínuo com 99.999999999% de durabilidade Control PlaneData Plane Amazon DynamoDB Amazon SWF Amazon Route 53 Logging + Storage SQL Transactions Caching Amazon S3
- 47. • Se inscrevapara ter acesso ao preview em: https://aws.amazon.com/rds/aurora/preview • Agora disponível nas regiões US West (Oregon) e EU (Ireland), além da região US East (N. Virginia) • Milhares de clientes já foram convidados para o preview • Agora mudando para o unlimited preview; aceitando todos os requests em 2–3 semanas • Lançamento oficial do produto nos próximos meses Aurora preview
- 48. Preço simplificado • Semlicenças • Sem lock-in • Pague somente o que você usa Descontos • 44% para 1 ano de reserva • 63% para 3 anos de reserva vCPU Mem Hourly Price db.r3.large 2 15.25 $0.29 db.r3.xlarge 4 30.5 $0.58 db.r3.2xlarge 8 61 $1.16 db.r3.4xlarge 16 122 $2.32 db.r3.8xlarge 32 244 $4.64 • Storage consumed, up to 64 TB, is $0.10/GB-month • IOs consumed are billed at $0.20 per million I/O • Prices are for Virginia Categoria Enterprise, preço open source
- 49. Aurora Funciona comSuas Aplicações Existentes
- 50. Estabelecendo nosso ecosistema BusinessIntelligence Data Integration Query and Monitoring SI and Consulting “It is great to see Amazon Aurora remains MySQL compatible; MariaDB connectors work with Aurora seamlessly. Today, customers can take MariaDB Enterprise with MariaDB MaxScale drivers and connect to Aurora, MariaDB, or MySQL without worrying about compatibility. We look forward to working with the Aurora team in the future to further accelerate innovation within the MySQL ecosystem.”— Roger Levy, VP Products, MariaDB
- 51. Amazon Aurora ÉFácil de Usar
- 52. Simplifique o gerenciamentodo banco de dados • Crie um banco de dados em minutos • Aplicação automática de patches • Escale o processamento apertando um botão • Backup contínuo para o S3 • Detecção de falhas e failover automático Amazon RDS
- 53. Simplifique o gerenciamentodo storage • Read replicas estão disponíveis como targets para failover —sem perda de dados • Crie snapshots instantaneamente—sem impacto de performance • Backup para o S3 contínuo e incremental • Storage escala automaticamente até 64 TB—sem impacto de performance ou disponibilidade • Restriping, mirror repair, hot spot management e criptografia automáticos
- 54. Simplifique a segurançados dados • Criptografia para proteger o dado armazenado – AES-256; aceleração por hardware – Todos os blocos no disco e no Amazon S3 são criptografados – Gerenciamento de chaves via AWS KMS • SSL para proteger o dado em transito • Isolamento na rede via Amazon VPC por default • Sem acesso direto aos nós • Suporta padrões de segurançã de mercado e certificações para proteção de dados Storage SQL Transactions Caching Amazon S3 Application
- 55. Amazon Aurora éAltamente Disponível
- 56. Aurora storage • Altamentedisponível por padrão – Replicação de 6 vias em 3 AZs – 4 de 6 write quorum • Diminui automaticamente para 3 de 4 se uma AZ está indisponível – 3 de 6 read quorum • SSD, escalável na horizontal, multi-tenant – Storage escalável – Até 64 TB – Pague somente o que você usa • Log-structured storage – Muitos segmentos pequenos, cada um com seu próprio redo log – Log pages usados para regerar data pages SQL Transactions AZ 1 AZ 2 AZ 3 Caching Amazon S3
- 57. Escritas com baixalatência e consistentes AZ 1 AZ 2 Primary Instance Standby Instance Amazon Elastic Block Store (EBS) Amazon S3 EBS mirror EBS EBS mirror AZ 1 AZ 3 Primary Instance Amazon S3 AZ 2 Replica Instance Melhorias • Consistência—Tolerância a valores extremos • Latência— replicação síncrona vs assíncrona • Uso de network I/O significativamente mais eficiente Log records Binlog Data Double-write buffer FRM files, metadata Type of writes MySQL com standby Amazon Aurora async 4/6 quorum PiTR Sequential write Sequential write Distributed writes
- 58. Self-healing, tolerante afalhas • Perca duas cópias ou uma AZ sem impacto na leitura ou escrita • Perca três cópias sem impacto de leitura • Detecção de falha, replicação, e reparo automático SQL Transactio n AZ 1 AZ 2 AZ 3 Caching SQL Transactio n AZ 1 AZ 2 AZ 3 Caching Read and write availabilityRead availability
- 59. Bancos de dadostradicionais • Precisam fazer um replay dos logs desde o último checkpoint • Single-threaded no MySQL; requer um número alto de acessos a disco Amazon Aurora • Storage faz o replay dos redo records sob demanda como parte de uma leitura no disco • Paralelo, distribuído, assíncrono Checkpointed Data Redo Log Crash no T0 requer uma re-aplicação do SQL do redo log desde o último checkpoint T0 T0 Crash no T0 resultará em redo logs sendo aplicados para cada segmento sob demanda, em pararelo, de forma assíncrona Recuperação de falha instantânea
- 60. Caches sobrevivem • Nósmovemos o cache para fora do processo do banco de dados • Cache permanece quente no evento de um restart do banco de dados • Instant crash recovery + survivable cache = recuperação de falhas rapidamente e facilmente SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching Processo do cache vive fora do processo do Banco e permanece quente mesmo após um restart no banco
- 61. Múltiplos alvos parafailover—sem perda de dados Page cache invalidation Aurora Master 30% Read 70% Write Aurora Replica 100% New Reads Shared Multi-AZ Storage MySQL Master 30% Read 70% Write MySQL Replica 30% New Reads 70% Write Single-threaded binlog apply Data Volume Data Volume Escalando as leituras no MySQL • Replicas precisam fazer o replay dos logs • Replicas aumentam a carga no master • Replica lag pode crescer indefinidamente • Failover resulta em perda de dados
- 62. Simule falhas usandoSQL • Para causar a falha de um componente no nó do banco de dados: ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}] • Para simular uma falha no storage: ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN [DISK index | NODE index] FOR INTERVAL interval • Para simular uma falha na rede: ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type [TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval
- 63. Amazon Aurora éRápido
- 64. Performance de escrita(screenshot do console) • MySQL Sysbench • R3.8XL com 32 cores e 244 GB RAM • 4 máquinas clientes machines com 1,000 threads cada
- 65. Performance de leitura(screenshot do console) • MySQL Sysbench • R3.8XL com 32 cores e 244 GB RAM • Único cliente with 1,000 threads
- 66. Lag na Readreplica (screenshot do console) • Aurora Replica com 7.27 ms replica lag com 13.8 K updates/second • MySQL 5.6 no mesmo hardware tem ~2 s de lag com 2 K updates/second
- 67. Escritas escalam deacordo com o número de tabelas - 10 20 30 40 50 60 70 10 100 1,000 10,000 ThousandsofWritesperSecond Number of Tables Performance de escrita e quantidade de tabelas Aurora MySQL on I2.8XL MySQL on I2.8XL with RAM Disk RDS MySQL with 30,000 IOPS (Single AZ) Tables Amazon Aurora MySQL I2.8XL Local SSD MySQL I2.8XL RAM Disk RDS MySQL 30K IOPS (Single AZ) 10 60,000 18,000 22,000 25,000 100 66,000 19,000 24,000 23,000 1,000 64,000 7,000 18,000 8,000 10,000 54,000 4,000 8,000 5,000 Write-only workload 1,000 connections Query cache (default on for Amazon Aurora, off for MySQL)
- 68. Melhor concorrência - 20 40 60 80 100 120 50 5005,000 ThousandsofWritesperSecond Concurrent Connections Performance de escrita e Concorrência Aurora RDS MySQL with 30,000 IOPS (Single AZ) Conexões Amazon Aurora RDS MySQL 30K IOPS (Single AZ) 50 40,000 10,000 500 71,000 21,000 5,000 110,000 13,000 OLTP Workload Variable connection count 250 tables Query cache (default on for Amazon Aurora, off for MySQL)
- 69. Caching melhora aperformance - 50 100 150 200 250 300 350 400 100/0 50/50 0/100 ThousandsofOperations/Second Read/Write Ratio Performance com query cache on e off Aurora without Caching Aurora with Caching RDS MySQL;30,000 IOPS (Single AZ) - without caching RDS MySQL;30,000 IOPS (Single AZ) - with caching R/W Ratio Amazon Aurora Sem Caching Amazon Aurora Com Caching RDS MySQL 30K IOPS Sem Caching RDS MySQL 30K IOPS Com Caching 100/0 160,000 375,000 35,000 19,000 50/50 130,000 93,000 24,000 20,000 0/100 64,000 64,000 16,000 16,000 OLTP workload 1,000 connections 250 tables Query cache on/off tested
- 70. Replicas tem até400 vezes menos lag 2.6 3.4 3.9 5.4 1,000 2,000 5,000 10,000 0 50,000 100,000 150,000 200,000 250,000 300,000 350,000 Updates per Second ReadReplicaLaginMilliseconds Lag na Read Replica Aurora RDS MySQL;30,000 IOPS (Single AZ) Updates/ Second Amazon Aurora RDS MySQL 30K IOPS (Single AZ) 1,000 2.62 ms 0 s 2,000 3.42 ms 1 s 5,000 3.94 ms 60 s 10,000 5.38 ms 300 s Write workload 250 tables Query cache on for Amazon Aurora, off for MySQL (best settings)
- 71.