AWS VPC distilled for MongoDB devOps

AWS VPC Distilled

- For MongoDB devOps

Krishna Sankar @ksankar

October 27,2012

Essential DevOps

2

Ref: h4p://speakerdeck.com/u/dampier/p/rock-‐‑solid-‐‑mongo-‐‑ops

AWS VPC Top 10 1.  Any mature AWS infrastructure should

use VPC (for prod & dev !) 2.  VPC is not that hard, but really requires

devOps skills 3.  cccc

4.  Designing VPC is a heist, single-‐handed ! 5.  VPC gives greater control & flexibility –

use the force wisely & keep your designs simple

AWS VPC Top 10 6.  VPC allows one to design multi-‐layered

security – security groups at the application layer & network layer ACLs

7.  VPC gives isolation semantics viz private subnet vs. public subnet, routing via internet gateway, NAT et al

8.  Incorporate resilience, knowing that VPC can span availability zones

9.  For now, inter VPC routing & VPC designs across regions are not that easy

10. Plan your Reserved Instances o  vpc & non-‐vpc RIs are separate & not changeable. They will

work, but capacity is not guaranteed i.e. you could get into trouble when you bounce the instances

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP

> Availability Zone : us-east-1a

AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24

Availability Zone : us-west-2a

AZ : us-west-2b

NAT <Public IP

>

Canonical VPC Architecture

o  Normally your instances would be created here

o  With a public DNS o  And a host name viz:

ec2-‐46-‐137-‐23-‐217.eu-‐west-‐1.compute.amazonaws.com

o  Amazon does protect it’s cloud from attacks et al. Still not fully secure, and less control (for example cannot reconfigure security groups)

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  VPC o  Create a separate VPC for each

function – usually dev & prod o  AWS has regions (US-‐Virginia, US-‐

California, US-‐Oregon, EU-‐Ireland, AsiaPac-‐Singapore, AsiaPac-‐Tokyo & SouthAmerica-‐Sao Paulo

o  Each region has 2 or more availability zones

o  A VPC can span Availability Zones, but not Regions

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Subnets o  Create multiple subnets in a VPC o  Subnets cannot span availability

zones (or regions) – so create (at least) one subnet per availability zone

o  There are two types of subnets Public subnet & Private subnet

o  We will take a look into each of them in the next couple of slides

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Public Subnets (1 of 3) o  Public subnets are for instances that

need to be accessed from the Internet – usually web servers, application servers, cache servers and ssh bastions belong in this category

o  The instances in the public subnet communicate with the external world via an Internet Gateway (igw)

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Public Subnets (2 of 3) o  The security groups determine

which ports are open and for which hosts

o  Usually web-‐server-‐group(80,443), app-‐server-‐group & ssh-‐group(22) are the two major port groups

o  You can also restrict the hosts that can communicate via the security groups

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Public Subnets (3 of 3) o  Unlike the non-‐vpc instances, the

instances in the public subnets do not have a public IP; nor do they have a host name that is externally resolvable

o  So you need to allocate an elastic IP & then assign it to the instance in the public subnet

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Private Subnets o  The instances in the private subnet

cannot be accessed directly from the internet

o  By default, all the instances inside a VPC can access the private subnet

o  Usually a NAT instance would be created and then the instances in the private subnet can access out – this is mainly for upgrades & downloads

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  VPC subnetting patterns o  Put your web/application server,

cache & ssh gateways in public subnets

o  Database servers should be in the private subnet

o  Control access via security groups o  You can add network level ACLs for

one more layer of security (in case of misconfiguration at the security group layer)

Amazon Cloud

Dev VPC - 10.200.0.0/16

Prod VPC 10.100.0.0/16

IGW

IGW

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

NAT <Public IP


AZ : us-east-1b

AZ : us-east-1c

Public subnet

10.200.70.0/24 Private su

bnet

10.200.80.0/24

Private subnet

10.200.90.0/24


AZ : us-west-2b

NAT <Public IP

>


o  Topics for another day o  Scale out the web tier with

multiple public subnets across availability zone

o  Dynamic Scaling with AutoScaling o  Load balancing with ELB across

subnets & regions o  Disaster Recovery Architectures

with cross region & cross-‐cloud

VPC Pragmatics 1.  Amazon has (very) detailed documentation

o  I really like the users guide http://goo.gl/loUcI (Good work guys) o  Print it, read it & annotate it with notes in the margin !

2.  Multi-‐layer security capable o  Security groups o  Network ACLs are fully open initially

3.  No private DNS – you need to run your own DNS o  I use /etc/hosts – it is not scalable, but works fine. For example

MongoDB replication needs to resolve the hosts in a replica set o  AWS Feature request -‐ Private DNS in Ruote53

4.  Have granular security groups for more control o  ssh-‐group that opens port 22 o  web-‐server-‐group that opens 80 & 443 o  app-‐server-‐group – as needed o  db-‐group that opens database ports -‐ 3306 for mysql, 27017 for mongo

et al

VPC Pragmatics 5.  Have a scheme & assign IP addresses to

the instances – private and public subnet o  The host name will be created from this IP address o  For example if you assign an IP 10.100.23.67 to an instance,

it will have a host name ip-‐10-‐100-‐23-‐67

6.  Use a different port than 22 for ssh. o  A decent port scan will let the world know what your ssh

port is o  While it doesn’t guarantee any more security, it will be a

quick defense against script-‐kiddies

Amazon Cloud

Prod VPC 10.100.0.0/16

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24

Availability Zone : us-east-1a

AZ : us-east-1b

AZ : us-east-1c

MongoDB Replicasets over Amazon VPC

q Goals (1 of 2) o  Security (Healthcare-‐

grade) o  Max resilience against data

loss o  No SPOF (Single Point Of

Failure) o  Consistently high average

throughput o  Reasonable resilience &

failure separation( Start with availability zones & extend to region as needed)

o  Balance cost, latency, availability & survivability

Amazon Cloud

Prod VPC 10.100.0.0/16

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24


AZ : us-east-1b

AZ : us-east-1c


q Goals (2 of 2) o  Recoverability

o  > 1 Replicaset o  Operations efficiency o  Good backup against all

possible failure scenarios o  Good snapshot strategy for

frequent & consistent snapshots

o  Recovery scripts/processes o  Operational finesse – e.g.

Zero Downtime upgrades

Amazon Cloud

Prod VPC 10.100.0.0/16

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24


AZ : us-east-1b

AZ : us-east-1c

MongoDB Replicasets over Amazon VPC o  Web Servers, Application

servers & cache servers in the public subnet

o  MongoDB Primary in the same availability zone, but in a private subnet

o  m2.xlarge instance with enhanced I/O; EBS

o  2 Secondary MongoDB in private subnet in two different availability zones

o  m1.large instances; EBS

Amazon Cloud

Prod VPC 10.100.0.0/16

Private subnet

10.100.20.0/24

Private subnet

10.100.40.0/24

Private subnet

10.100.30.0/24

Public subnet

10.100.10.0/24


AZ : us-east-1b

AZ : us-east-1c


q  Backup Strategy o  Snapshot from Secondary o  Hourly backup – rotate

every 24 hrs o  Daily backup – rotate every

month o  Weekly backup – rotate

yearly. o  Keep a copy in a

different cloud

VPC/MongoDB Pragmatics 1.  DNS for replication

o  MongoDB replication needs to resolve the hosts in a replica set o  I use /etc/hosts – it is not scalable, but works fine. o  AWS Feature request -‐ Private DNS in Ruote53

2.  10Gen has (very) detailed documentation 3.  And MongoDB replication setup is easy &

straightforward o  Thanks Guys

4.  Snapshots are important 1.  Against program errors 2.  Against database corruption 3.  Against operations mistakes 4.  Snapshot scripts could be a little trickier o  I will update after a few days of experience

AWS VPC distilled for MongoDB devOps

Technology

Transcript of AWS VPC distilled for MongoDB devOps