O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

AWS på kartet

173 visualizações

Publicada em

Utnyttelse av AWS i Geodata AS. Hvordan Geodata benytter muligheter i AWS-plattformen til effektiv drift av tjenester, apps og dataprosessering.

Publicada em: Dados e análise
  • Seja o primeiro a comentar

AWS på kartet

  1. 1. AWS PÅ KARTET Pål Kristensen Teamleder Systemdrift / DevOps
  2. 2. OM GEODATA • Etablert i 1988 • Samtlige eiere har fortsatt tilknytning til selskapet • Solid selskap med jevn vekst • Distributør av Esri i Norge • Ca 117 ansatte (122 m Geocap) • Omsetning 2014: ca 218 MNOK, Resultat 34,1 • Omsetning 2015: ca 219 MNOK, Resultat 27,9* • Mål 2016: ca 230 MNOK Steinkjer Oslo Stavanger *) Endring av regnskapsføringsprinsipper i 2015
  3. 3. ØKONOMISK UTVIKLING 0 5000000 10000000 15000000 20000000 25000000 30000000 35000000 40000000 - 50,000,000 100,000,000 150,000,000 200,000,000 250,000,000 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015B Utvikling i omsetning og resultat Omsetning Resultat
  4. 4. GEODATA ER EN «GIS-INTEGRATOR» • Leverer tjenester på tvers av hele verdikjeden til kundene • Programvare • Prosjektleveranser • Rådgivning • Support • Opplæring • Innholdstjenester • Datatilrettelegging • Drift av løsninger • Erfaring fra noen av de største og tyngste forvaltningsprosjektene
  5. 5. KUNDER PÅ TVERS AV ALLE SEGMENTER
  6. 6. • Innholdstjenester • Offline innhold • Hosting av apps • Hosting av tjenester
  7. 7. VÅR REISE I AWS • 2008: Sped begynnelse, eksperimentering • 2009: Noen få tjenester kjørende på en single EC2 boks • 2010: Gradvis flere tjenester settes opp i AWS. Fremdeles helt manuell workflow for oppsette og drift av infrastrukturen. Hver EC2 boks var en silo • 2011: Gradvis en mer lagdelt infrastruktur • Fillagring, Databaser, Tjenester/Apps • 2012-2015: Gradvis mer automatisering av infrastruktur. Utvikling av egen dataflyt og prosesseringsplattform • 2015-2016: «All in» på VPC og CloudFormation, med cfn-init og bootstrapping. Implementering av rutiner for continuous delivery for tjenester og apps. Alle tjenester, apps og selve infrastrukturen er underlagt versjonskontroll. • 2016: Fullstendig automatisert deploy av tjenester og apps, inkludert tilbakerulling til tidligere versjoner. Hele infrastrukturen satt opp som CloudFormation stacks • 2016: Implementerer Spot. Lambda og API gateway for micro services
  8. 8. TEKNOLOGI - HOVEDKOMPONENTER
  9. 9. AWS-BYGGEKLOSSER
  10. 10. • AWS SDK for Python (Boto) • AWS SDK for .Net • AWS SDK for Java • AWS SDK for PHP • AWS SDK for Ruby
  11. 11. • Continuous integration • Integrering eller «merge» av kode i nærsanntid, og samtidig sikre at funksjonalitet og egenskaper ikke brytes. «Build» server som kontinuerlig lytter på endringer i kildekodesystem og gjør forsøk på å bygge kode og kjøre tester • Continuous delivery • All kode som «leveres» skal være produksjonsklar og produksjonstestet. I prinsippet skal koden kunne deployes om kunder og organisasjonen for øvrig er klar • Continuous deplyment • Er å ta det enda et steg. All kode som leveres blir også regelmessig (om ikke automatisk) kjør ut i produksjon. • Hvorfor? For å korte ned tiden fra ideer og behov oppstår til funksjonalitet kan rulles ut til kunder. Mindre sårbar som organisasjon og mindre avhengig av enkeltpersoner. • Amazon har flere mekanismer som muliggjør konseptene rent praktisk
  12. 12. THE AMAZON WAY
  13. 13. • Hvordan får vi til Continuous Delivery for ArcGIS for Server? • Innhold (data) • Tjenester
  14. 14. AMI RDS snapshot gdvh-master gdvh-prodRoute53 private hosted zone • Hvordan får vi til Continuous Delivery for ArcGIS for Server? • Innhold (data) • Tjenester
  15. 15. S3 «site»-staging.geodataonline.no «site».geodataonline.no CF OK signal Elastic • Hvordan får vi til Continuous Delivery for ArcGIS for Server? • Innhold (data) • Tjenester
  16. 16. DEPLOYMENTSTEG 1. Ny Windows Server 2012 R2 instans booter, eget AMI (ca 1-2 minutter) 2. EC2 Windows Servicen starter 3. Bootstrapping kjører (cfn-init) 1. Deploymentpakke lastes ned fra S3 2. Komponentene pakkes ut 3. Deploymentscript kjører (ca 22 minutter) 4. Kontrollscript kjører Hvis alle tjenester er OK aktiveres helsesjekk URLen 4. cfn-init sender OK til stacken
  17. 17. CLOUDFORMATION - «SECRET SAUCE» • Infrastruktur som kode
  18. 18. Spot - AutoScaling group Spot - Launch Configuration Spot On-Demand - AutoScaling group - Launch Configuration Elastic
  19. 19. DEPLOYE OPPDATERINGER • Prinsipielt to ulike metoder å deploye oppdatert kode/config • Oppdatere kode (pushe) til kjørende EC2 instanser som er «in service», instansen konfigurerer seg selv. (cfn-init, cfn-hup og custom deploy-kode) • Bytte ut kjørende instanser med nye, som da enten har koden bakt inn i AMI, eller som konfigurerer seg ved oppstart via såkalt bootstrapping (cfn-init og custom deploykode) • NB, enkelte endringer krever utskifting av instanser! • Nytt AMI • Ny maskintype • Endringer i user-data • Hva som er best egnet kommer an på din app/tjeneste
  20. 20. ROLLING UPDATE POLICY VS REPLACE UPDATE POLICY Rolling Update Replace Update Deployment tid Lang i noen tilfeller Kort Tid for eventuell rollback Lang Kort Oppdateringsmetode Batch Alle på en gang Krever utskifting av instanser for å deploye kode Nei Ja Garantert konsistent kode i prod på alle noder Nei Ja Tar hensyn til AutoScaling actions / ScaleOut Ja Nei (workaround med Lambda og CloudFormation custom actions) Fungerer greit med spot (ved utskifting av instanser) Nei (ingen workaround) Nei (workaround med Lambda og CloudFormation custom actions) Redusert kapasitet ved deploy (On Demand) Kan skje ved rollback Nei (Ja, hvis scaling actions er aktive) Redusert kapasitet ved deploy (Spot) Ja Ja (workaround med Lambda og CloudFormation custom actions) Replace Update Policy har en mer robust og vesentlig raskere rollback ved eventuelle deployment feil
  21. 21. DEPLOYE OPPDATERINGER
  22. 22. DEPLOYE OPPDATERINGER
  23. 23. DEPLOYE OPPDATERINGER
  24. 24. CASE - ROLLING UPDATE - SPOT SpotOnDemand Booting In Service
  25. 25. ROLLING UPDATE – SPOT!!!!! NB! MinInstancesInService må være 0
  26. 26. CASE - REPLACE UPDATE - SPOT SpotOnDemand Booting In Service
  27. 27. CASE - REPLACE UPDATE – SPOT (WORKAROUND) SpotOnDemand Booting In Service
  28. 28. WORKAROUND
  29. 29. HVORDAN LAGRE STORE DATAMENGDER I EN FILSTRUKTUR PÅ AWS? • Vi har tjenester som er avhengig av å nå data på en filstruktur, altså ikke bare jobbe mot S3 • Hvordan bygger du fillagring på +80TB? • Som ikke koster skjorta • Som gir bra ytelse • Som har god nok oppetid • Som kan benyttes som SMB v3.0 i Microsoft noder • Som ikke er overkomplisert
  30. 30. HVORDAN LAGRE STORE DATAMENGDER I EN FILSTRUKTUR PÅ AWS? • Linux • NFS and CIFS Options for AWS (STG401) | AWS re:Invent 2013 • GlusterFS • SoftNAS • Zadara Storage • Windows • Scale-Out File Server for Application Data Overview • Storage Spaces Overview • EFS • Kostbart • Relativt lav IO og throughput • Kun NFSv4
  31. 31. https://aws.amazon.com/ebs/details/ VOLUMTYPER • Max 27 EBS volumer pr Windows Server, inkludert /dev/sda1 • Det «gamle» standard HDD EBS volumet er begrenset til max 1TB pr volum
  32. 32. VI VALGTE • Windows Server 2012 R2 • Storage Spaces • EBS Cold HDD for lagring • EBS GP SSD for Write Back Cache
  33. 33. TAKK FOR OPPMERKSOMHETEN! pal.kristensen@geodata.no

×