Einmal über den großen teich mongo db in der aws-cloud von eu nach us nahezu ohne downtime migrieren

Einmal über den großen Teich

MongoDB in der AWS-Cloud von EU nach US

ohne Downtime migrieren

Markus Ostertag

Markus Ostertag - MongoDB München 2013

Wer bin ich?• Online-Business seit >15 Jahren

• Diplom-Informatik TU München

• Gründer MovieMaze.de (Verkauf 2012)

• Fokus auf Skalierung und AWS

• Seit 11/2012 bei Team Internet als Head ofDevelopment (Advertiser Products)


Übersicht

• Was ist DNTX?

• Wie wir MongoDB einsetzen

• AWS Voraussetzungen

• Architektur einer MongoDB in EC2


Übersicht

• Konzept der Migration

• Die Migration

• Die Nacharbeiten

• Happy End?



DNTX

• DNTX = Direct Navigation Traffic Exchange

• Monetarisierung von Domain Parking Traffic

• Real Time Bidding pro Request

• DNTX als Marktplatz zwischen

Parkingplattform und Advertiser


Wie wir MongoDB einsetzen

• Anfragen nach höchstem Gebot (Read)

• Tracking (Write)

• Read & Write intensiv

• Gesamtantwortzeit < 500ms



• 4 Shards (je ein Replica Set mit 3 Maschinen)

• 7 MongoS + 3 Configserver

• Read Preference

„secondaryPreferred“

• Application Server in node.js



• 600 Feedrequests/Sek. (~52 Mio./Tag)

• Avg. 4k DB-Queries/Sek. (Peaks: 20k/Sek.)

• Avg. 500 DB-Inserts/Sek. (Peaks: 2k/Sek.)

• Avg. 400 DB-Updates/Sek. (Peaks: 2k/Sek.)


AWS Voraussetzungen• Entscheidung für Amazon Web Services

• VPC als „Trusted Environment“

• Availability Zones und Regions


Architektur einer MongoDB in EC2


• Eine VPC mit 3 Availability Zones

• Primary über Priority (rs.conf()) verteilen

Sprung über den Teich


Konzept der Migration


Die Migration• Datenmenge reduzieren

• Balancer abschalten

• Jedem Shard einen „Transfer-MongoD“ als „hidden“ Secondary hinzufügen

–priority:0, hidden:true, votes:0

• Warten…


Die Migration


Die Migration• „Transfer-MongoD“ stoppen

• Snapshots ziehen und nach US kopieren

• Snapshots in US starten


Die Migration• Sync ausgehend von Transfer-MongoDs

• Alle (12) neuen MongoDs in US starten

• Sync von den jeweiligen Transfer-MongoDs

• Warten…

• Neue MongoS und Application-Server in US


rs.syncFrom("transfer-mongod-

shard1-us")

Die Migration – Kritischer Teil

• Migration der Config-Server

–Snapshots in EU -> Copy in US starten

–Alle MongoS stoppen und mit den neuen Config-Servern (US) starten -> Downtime von wenigen Minuten

• Gesamtsystem dupliziert



• Switch der Application von EU nach US (DNS)

• Switch der Secondaries nach US


cfg = rs.conf();

cfg.members[0].votes = 1

cfg.members[0].priority = 1

cfg.members[0].hidden = false

rs.reconfig(cfg)


• Switch der Primaries nach US

• Zur Sicherheit:

–Neuaufbau der Connections triggern

–EU läuft per VPN noch mit


Die Nacharbeiten

• Monitoring der US-Systeme

• VPN-Verbindung trennen

• EU abschalten

• Security Groups anpassen


Happy End?

• Probleme:

–VPN-Instanzen und der Netzwerkdurchsatz

–Ohne Downtime ist ein Config-Serverumzug

nicht möglich (MongoS müssen alle down sein)


Happy End?• Fazit:

– Vorarbeit

– Geduld

– Hidden Secondaries helfen!


Links• IPSec zwischen zwei VPCs:

http://aws.amazon.com/articles/5472675506466066

• MongoDB-Whitepaper von Amazon: http://aws.amazon.com/whitepapers/mongodb-on-aws/

• MongoDB on AWS (10Gen):http://docs.mongodb.org/ecosystem/platforms/amazon-ec2/


http://aws.amazon.com/articles/5472675506466066

http://aws.amazon.com/whitepapers/mongodb-on-aws/

http://docs.mongodb.org/ecosystem/platforms/amazon-ec2/

• Mail: [email protected]

• Xing: http://xing.to/mo

• Linkedin:

http://de.linkedin.com/in/ostertag


mailto:[email protected]

http://xing.to/mo

http://de.linkedin.com/in/ostertag

Documents

Einmal über den großen teich mongo db in der aws-cloud von eu nach us nahezu ohne downtime migrieren