Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spilo, отказоустойчивый PostgreSQL кластер / Oleksii Kliukin (Zalando SE)

2,490 views

Published on

Позвольте представить Spilo — отказоустойчивый PostgreSQL кластер.

Последние несколько лет в компании Zalando происходила постепенная децентрализация разработки приложений. Этот процесс затронул и базы данных: часть задач по их обслуживанию была передана командам разработчиков, многие из которых не имеют опыта администрирования СУБД. В таких условиях создание и обслуживание надежных PostgreSQL баз данных должно быть предельно упрощено. Для этого мы придумали Spilo (Спило) — отказоустойчивый PostgreSQL кластер.

В докладе я расскажу о том, как наша инфраструктура, основанная на Splio, упрощает типичные задачи управления PostgreSQL кластером, сохраняя при этом контроль за ним в руках разработчиков. Spilo представляет из себя систему с несколькими репликами, основанную на потоковой репликации PostgreSQL. Для ее надежной работы не требуется вмешательство оператора даже в случае аварии. Spilo берет на себя задачи добавления новых реплик в случае отказа существующих, а также своевременного создания резервных копий на основе механизма PITR (point in time recovery). Логика отказоустойчивого кластера реализуется с помощью собственной open-source разработки Zalando — Patroni (https://github.com/zalando/patroni) — программы, основанной на Compose Governor, берущей на себя задачи определения, является ли данный узел мастером или репликой, и использующей системы распределенного консенсуса, такие как Zookeeper или etcd, для предотвращения split brain.

Я покажу, как Spilo встраивает Patroni в архитектуру облачных сервисов, например, AWS, добавляя масштабирование для автоматизации запуска отказоустойчивых кластеров. Простота запуска Spilo кластеров основана на STUPS — открытой системе “платформа как сервис” (PAAS) для предоставления автономным командам разработчиков облачных ресурсов AWS с возможностью аудита их использования. Используя Spilo и STUPS наши инженеры способны создать отказоустойчивый PostgreSQL кластер с произвольным количеством узлов с помощью нескольких команд.

Слушатели этого доклада получат представление о том, как использовать Spilo, Patroni и STUPS для эффективного управления своими PostgreSQL кластерами.

Published in: Engineering
  • Be the first to comment

Spilo, отказоустойчивый PostgreSQL кластер / Oleksii Kliukin (Zalando SE)

  1. 1. Spilo, highly-available PostgreSQL cluster Oleksii Kliukin Zalando SE
  2. 2. Zalando • 15 EU countries • 3 fulfilment
 centers • 15+ million
 active customers • 2.2 billion €
 revenue 2014

  3. 3. 150 000+ products
  4. 4. We are growing!
  5. 5. Zalando platform
  6. 6. Our databases • >150 production Postgresql databases • >13.5 TB data • >5 TB biggest DB • 400-1000+ write tps • >2 DB failures/month
  7. 7. Zalando never sleeps
  8. 8. Infrastructure bottleneck ACID Team create alter deploy migrate failover upgrade 80+ teams
  9. 9. Radical Agility
  10. 10. Purpose
  11. 11. Autonomy
  12. 12. Mastery
  13. 13. Cloud • 2013: ZCloud
 • 2014: project Pequod
 • 2015: Let’s just use AWS…
  14. 14. Amazon 3-letter words • AWS - amazon web services • EC2 - elastic compute cloud • ELB - elastic load balancer • RDS - relational DB service
  15. 15. AWS • One account per team • Microservices • REST/OAuth2 • Deployment with Docker
  16. 16. Autonomous teams on AWS REST INTERNET
  17. 17. Autonomous teams • Team decides which product to build • … and which technologies to use
 • REST/OAuth2 mandatory
 • Team is responsible for its infrastructure
  18. 18. Databases? • Developers should take care of infrastructure
 • ..including production databases
 • On AWS!
  19. 19. Isn’t it dangerous? DBAs running with scissors, by Gavin M. Roy: https://www.flickr.com/photos/gavinmroy/4638958958
  20. 20. ACID team provides PostgreSQL trainings
  21. 21. What about failover?
  22. 22. Autofailover tasks • Detect the master failure • Elect a new master • Redirect clients
  23. 23. Autofailover issues • Discarded writes • Split-brain • False positives
  24. 24. RDS? • Support for PostgreSQL • Automatic failover • Most extensions • Automatic backups
  25. 25. RDS? • Vendor lock • No superuser • No untrusted languages • No logical decoding plugins • Rather expensive
  26. 26. EC2 + Linux HA • Complex setup • Lots of manual steps
 (i.e. new replica creation)
  27. 27. Spilo (!"#$%)
  28. 28. Spilo does • Rapid deployment of PostgreSQL on AWS EC2 instances
 • Streaming replication with auto-failover
  29. 29. Spilo on AWS Spilo MASTER Spilo REPLICA Spilo REPLICA Master connection Application DB request ETCD cluster status update
  30. 30. Failover Spilo REPLICA Spilo REPLICA Master connection Application DB request ETCD cluster status update
  31. 31. Failover Spilo MASTER Spilo REPLICA Master connection Application DB request ETCD cluster status update NEW SPILO STARTS…
  32. 32. Failover Spilo MASTER Spilo REPLICA Master connection Application DB request ETCD cluster status update Spilo REPLICA
  33. 33. What is Spilo? c Patroni MASTER c Patroni REPLICA c Patroni REPLICA Auto-scaling group Auto-scaling group
  34. 34. Patroni ("&'(%)#) • Handles new replicas and failover
 • Based on ideas and code of the Compose Governor
 • Open-source
  35. 35. Compose Governor idea 
 Core to our PostgreSQL HA system is the Governor application which uses etcd as its repository of truth to discover which database instance is leader.
 
 

  36. 36. Distributed configuration systems • Fault tolerant
 • Reliably store small amounts of strongly-consistent data between distributed nodes • Good for storing the PostgreSQL cluster state
  37. 37. Distributed consensus LEADER CLIENT CLIENT CLIENT
  38. 38. Distributed consensus LEADER CLIENT CLIENT CLIENT
  39. 39. Cluster state in etcd $ etcdctl ls --recursive /service /service/batman /service/batman/optime /service/batman/optime/leader /service/batman/members /service/batman/members/postgresql0 /service/batman/members/postgresql1 /service/batman/initialize /service/batman/leader
  40. 40. Leader key $ etcdctl get /service/batman/leader postgresql0 • Points to the member key • Has a TTL, autoexpires • Acts as an exclusive lock • Only the leader can become the master
  41. 41. Leader TTL $ http http://127.0.0.1:2379/v2/keys/service/batman/ leader … { "action": "get", "node": { "createdIndex": 48723, "expiration": "2015-10-23T14:51:49.686506977Z", "key": "/service/batman/leader", "modifiedIndex": 49037, "ttl": 27, "value": "postgresql0" } }
  42. 42. Member key $ etcdctl get /service/batman/members/ postgresql0 {“role":"master", “state”:"running", “conn_url”:"postgres://replicator:rep- pass@127.0.0.1:5432/postgres", “api_url”:"http://127.0.0.1:8008/ patroni", "xlog_location":67108960}
 

  43. 43. Connection and API URL c Patroni c Patroni API URL
 (check health
 during promotion) MASTER REPLICA CONNECTION URL MASTER LB REPLICA LB CONNECTION URL
  44. 44. Initialize key $ etcdctl get /service/batman/initialize 6208852353820383446 • PostgreSQL cluster system ID • Created by the first node that joins the cluster • Nodes with different system ID are not allowed to join
  45. 45. Patroni modules ETCD ZOOKEEPER ABSTRACT DCS PostgreSQL REST API High availability Asynchronous executor Callbacks
  46. 46. Demo time! https://asciinema.org/a/29087
  47. 47. From Governor to Patroni Governor Patroni
  48. 48. Location of etcd: original c Governor c Governor c Governor
  49. 49. Replace etcd with proxy c Governor c Governor c Governor Proxy Proxy Proxy
  50. 50. Embed etcd client in Patroni c Patroni c Patroni c Patroni
  51. 51. Patroni improvements • Robust exception handling • Run long-running tasks (i.e. base backup in a separate thread) • ETCD + Zookeeper • Rest API
  52. 52. Patroni improvements • Configurable replica imaging • Support for pg_rewind
  53. 53. Patroni improvements • Manual failover • Initialize from external cluster • Attach to already running PostgreSQL nodes • Tags (i.e. nofailover)
  54. 54. What you should monitor • replication lag • unhealthy member • no leader • etcd/
 Zookeeper
  55. 55. Thank you! • Spilo:
 github.com/zalando/spilo
 spilo.readthedocs.org
 • Patroni:
 github.com/zalando/patroni
 patroni.readthedocs.org
 • Feedback: @alexeyklyukin

×