OVH Lab - Enterprise Cloud Databases

1
OVH LAB
Enterprise Cloud Databases
Product presentation
V2019-05-20
Wilfried ROSET, Engineering Manager // Bastien VERDEBOUT, Product Manager

2
Summary
1. Offers context
2. Architecture principles
3. Failover/Switchover scenarios
4. Features
5. Pricing
6. Roadmap
7. FAQ

4
Before starting…
Our goal : provide relational databases for your critical workloads, with no compromises.
This document focus on offers, architecture, features, roadmap and pricing.
Please note that we are still in early access phase, allowing you to test but not to buy.
Lab page : https://labs.ovh.com/ha-database
Contact us if you have questions (last slide) !

5
Performance
Services
Included in Web products
Or in standalone
No SLA, No HA
Databases
« Cloud Databases »
From free to 20€/month
Databases
Public Cloud
Databases
« Enterprise »
Brick in Public Cloud
Pay as you Go
Openstack compliance
Multi-tenant
Can be HA
No compromises
Dedicated hardware
(Single tenant)
Prodded
Early access phase
R&D
Starting 800€/month
Starting 20€ /month
You are here !

6
Databases built with passion
During the last 2 years at OVH, our internal DBA team worked hard on internal industrialization of
critical relational databases architectures, starting with PostgreSQL, for our own needs.
We now have dozens of internal clusters benefiting from our new technology and decided to work
on a public offer, because you tend to have the same needs as OVH.
We started Early Access in January 2019, allowing us to gather customers feedbacks and fine-tune our
offers. This document explains where we are, and what we imagine, for you. Enjoy the reading !
R&D (done) + internal use
General Availability
January
2019
Early access. Infra & offers fine-tuning, API, …
Today October 2019
You
are
here

7
Databases for a S.M.A.R.T. Cloud
Dedicated hardware
Each node is on a dedicated server,
just for you. We provide constant CPU
performances, constant IOPS and real
isolation.
100% Managed
We monitor your services 24/7. We
perform software maintenance and
hardware maintenance, and daily
backup your critical data.
Vanilla software
No vendor lock-in. We use open source
and vanilla software, trusted but the
community.
Simple pricing
Network traffic ? Included. Storage and
constant IOPS ? Included/
Observability tools, daily backups, and
so on ? Included !
Scalability
You databases can grow with your
needs. Change you database plan
when you want, and add up to 50
replicas for horizontal scalability.
High-Availability by default
Your workloads are critical. Our
architecture are highly available by
default, with automatic failover in few
seconds. We provide 99,99% SLA.
</>

8
You should continue to read if…
• If you recognize yourself in some customers profiles below, the next slides are for you !
DB Admin
 I want to take 0 risks on the infra. High-Availability is key point
 I want well-managed services and observability tools
 I want an offer who respect DB best practices (ACID, local
storage, security…)
 I don’t trust custom-made DBMS. Vanilla or nothing, no vendor-
lockin for my company
IT Provider company
 I need worry-free Databases service for my customers
 I need to be competitive to win RFP
 Pricing should be simple
 Performance and high-availability are key points
CTO
 I need a 24/7 monitored infra and high level SLA
 I need to control my costs easily (TCO)
 I want to be able to move from one Cloud Provider to another one
easily (no vendor lock-in)

10
Architecture principles / schema
Read Only endpointRead Write endpoint
Backuper
node
Primary
node
R-W
Replica
node
R-O
Horizontal
Scaling
Replication
Load Balancing
1 x Database cluster. Includes by default 3 x dedicated nodes (primary, replica, backup)
Internet
Replication
Filer
storage
Filer
storage

11
Architecture principle / roles description
Each database cluster is composed of different items :
• Load balancing : based on replicated appliances and HAProxy, they balance the network trafic to your nodes
(primary and replicas). You can use different ports for Read-Only and Read-Write, or use the same.
• Primary node : based on 1 x dedicated host (single-tenant), it accepts Read-Write operations. If you configure
your application to use the same port for Read and Write operations, Primary Node will also accept Read-Only
operations.
• Replicas nodes : based on n x dedicated host (single-tenant), they accept Read-Only operations. They allow you
horizontal scaling. By default, a cluster is composed of 1 x Replica Node.
• Backup node : based on 1 x dedicated host (single-tenant), it will NOT accept Read nor Write operations. It
replicates your data and is used for non-degradating backuping. Backups are performed on this dedicated node
instead of the production one.
• Cluster Storage : based on local SSD storage, with RAID10 (replicated storage). They will store your operational
data. Backups are stored in OVH filer storage
• Backup storage : based on 2 x OVH filer storage, they store your backups and allow you to restore backups.

12
Architecture principles / roles discovery
Load Balancing
RW traffic:
Are you
primary?
Relational database clustering implies specific roles.
To counter outages scenarios, such as a “Primary Node
down”, we implemented high-availability templates :
• Automatic role discovery
– Primary node for RW traffic
– Secondaries nodes for RO traffic
– No traffic for backup node
– … everything made with Quorum (wikipedia explanation)
• Fast & Continuous discovery
– Probe every 30 seconds
Node
RO traffic:
Are you
primary?
Node
YES No

13
Architecture principles / Regions & Availability Zones
Region
AZ AZ
LB Backup LB
Node Node
Backup
For improved resiliency, we propose multi-AZ redundancy

14
Failover/Switchover scenarios

15
Outage #1 : replica down
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
1. Replica down, no other replicas
2. Automatic Failover : roles discovery
3. After max 30 seconds, Primary will handle Read-Only and Read-Write
4. OVH will re-attach a new replica automatically, back to nominal mode after synchronization
Read-Write impacts : No downtime, but can feel degraded performance
Read-Only impacts : degraded performance (1 node to accept all RO+RW instead of 2)
Steps
Animated slide
 Presentation mode

16
Outage #2 : primary down
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
1. Primary down, 1 x replica up
2. Automatic Failover : roles discovery
3. After max 30 seconds, Replica will be elected as Primary, handling Read-Only and Read-Write
Read-Write impacts : downtime, unable to perform operation during few seconds
Read-Only impacts : no downtime, potential degraded performances
Steps
Animated slide

17
Outage #3 : AZ down, quorum remain
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
1. Availability zone down, 1 x primary up
2. Quorum Remain: After max 30 seconds, RO traffic is rerouted via load balancer automatically
3. Primary will handle Read-Only and Read-Write
Read-Write impacts : No downtime, but can feel degraded performance
Read-Only impacts : degraded performance (1 node to accept all RO+RW instead of 2)
Steps
Animated slide

18
Outage #4 : AZ lost, quorum lost
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
R
O
1. Availability zone down, 1 x replica up,
2. Quorum is lost. Cluster switch to Read-Only in order to avoid split brain
3. OVH will automatically reattach a Primary node, in a new AZ if possible
4. Back to nominal mode after synchronization
Read-Write impacts : downtime, until we reattach a Primary.
Read-Only impacts : no downtime, degraded performance (1 node to accept all RO+RW instead of 2)
Steps
Animated slide

19
Outage #5 : All cluster down
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
R
O
1. Both availabilities Zones down
2. We still have access to backups : we restore a snapshot in another region
3. We don’t have access to backup : commitment of a 12 hours maximum RPO
Read-Write impacts : downtime, until we recover.
Read-Only impacts : downtime, until we recover
Steps
Animated slide

20
Planned #1 : Minor version update
Region
AZ AZ
LB Backup LB
Primary Replica
Backup
1. We update host per host to ensure that the cluster will not suffer any downtime
2. Before updating the primary we will switchover RW traffic to a replica by promoting it
Read-Write impacts : downtime during the switchover (max 30 seconds)
Read-Only impacts : no downtime, degraded performance (1 node to accept all RO+RW instead of 2)
Steps
Animated slide

22
Features list
Critical Cloud Databases
Billing method Monthly
SLA 99,99% (4 minutes per month)
DBMS proposed
Available : PostgreSQL 9.6, 10, 11
Planned : MariaDB
Managed Service Yes. Operating system, minor DBMS versions, hardware parts, network.
High Availability Yes, by default
Auto Failover Yes, performed in 30 seconds maximum
Geo-redundancy intra region (multiple
AZ)
Yes, optional
Clustering Yes, by default
Replicas (increase RO perfs) Yes, by default. You can add up to 10 replicas
DB instance resizing Yes (size up only for now)
Backups
Yes, 3 rolling months included for Daily Backups
On-demand backup
Always performed on a separated node (backuper) to avoid noise on production
Point-in-time recovery (PITR) Yes
Restore Yes
IP whitelisting Yes
End-to-end TLS/SSL Yes
Full disk encryption (LUKS) Yes
Public Network access Yes
Private network (vRack) Not for now, planned
Observability tools Yes, Logs, full metrics
API management Yes
CLI management Yes (super admin)
Web interface management Yes
Infrastrucutre
Backups
Management
Network
Security

23
Managed service
Hardware Maintenance
Daily Backups
With 2 months retention included
Monitored 24/7
Software Maintenance
For minor versions

24
High Availability & Automatic Failover
• Automatic failure detection
– Continuous probing
• Fault Tolerant
– Remove failed node from cluster
• Fast Failover
– Maximum 30 sec
– No need to update DNS records
• In case of outage (node down, AZ down …)
– No downtime (except from failover)
– Lower performance

25
Dedicated hardware
We guarantee performance
Physical
Nodes
No noisy neighbors
Isolation
Network
Nodes communicate
in their own network
with tight control using
security group
Zero trustConstant IOPS
Local Storage
Hardware RAID 10 for
both security & speed
Yours only
Cpu, Ram, I/O
dedicated &
guaranteed for your
workload
Performance

26
Automatic and on-demand backups
Your data, safe and sound
Each Day
Your cluster is
backuped, replicated
multiple times.
Backups are performed
on dedicated node
(the backuper) to
avoid noise on
production. We keep
them 3 rolling months.
01
Daily
Right when
you want
You can always ask for
a backup when you
want, like for example
before a major update
in your app.
Backup are performed
on dedicated node
(the backuper) to avoid
noise on production.
02
On Demand
03
Whenever
Log files are also
backuped. This way
you can go back in
time, right to the
second.
PITR

27
Restore
You are able to request backups restore when you want
• No downtime
– Restore on a dedicated host
• Close to the second
– Choose between your backups or specify a date (PITR)
• Pay per restore
– You select a cloud instance flavor, and you will pay your restore hourly.

28
Backups/Restore : sum-up
What is done Perimeter included
Data daily auto backups We perform daily physical ZFS snapshots (we don’t use pg_dump). Datafiles on filesystem
Data “on demand” backups You can perform “on demand” backup through API and control panel, when you want Same as daily backups
Data backups process
Each backup is made on the “backuper node”, isolated from the production.
No impacts on your performances. We stop postgresql process on this node during this time.
N/A
Data backups retention By default, we keep all your backups for 3 rolling months. Daily backups
Data backups replication We keep data backups on 2 different and autonomous spaces, called filers storage Daily + “On demand” backups
Data backups integrity
We perform backup on a dedicated host (the backuper node) and we stop postgresql process
during this process. Integrity is preserved. We don’t perform integrity checks after (but soon)
Daily + “On demand” backups
WAL backup/retention We perform continuous backups of WAL, limited to 3 rolling month, on Object Storage. All WAL from primary node
Logs/Metrics retention
We store logs for 1 rolling month, metrics for 1 year, and give you observability tools to access
them.
Logs : PostgreSQL process
Metrics : all nodes
PITR feature We keep all your WAL allowing you PITR, see after. N/A
Restore a data backup
When you ask for a restore, you can request a backup ID or a specific day+hour.
If you request a backup ID, we will spawn an instance with your snapshot, in read-only, and
provide you and IP and ports to connect. You pay the same prices as OVH Public Cloud.
You are then free to do what you want (dump+restore on production, …)
If you ask for a specific day+hour, we will use PITR feature.
Daily backups
+
“On demand” backups

29
End-to-End security
Combination of multiple layers
TLS
We only accept
secure flows
Security group
IP whitelisting
Encryption at Rest
LUKS

30
Observability tools
Have a close look on your cluster
Logs & Metrics
We collect several
data on your cluster.
01
Collect
No extra cost
You don’t have to do
anything, we parse,
store and expose your
date right for you, for
2 months
02
Store
03
Open Source
Use industry
standard to use your
data. We provide
Graylog, Kibana
and Grafana for this
matter.
Profit

31
Observability tools : example for metrics

32
Management
• CLI
– We provide vanilla database with super admin access. Use your standards commands!
• API
– Our OVH API allow you to start, resizing, delete a cluster, handle the backup and restore, whitelist IPs, …
• WEB Control Panel
– Everything you can do through API, but from a web interface. You will also be able to access billing console
and observability tools

33
PostgreSQL extensions
• On top of PostgreSQL default extension we include :
– Ip4r
– Pglogical
– Pgrouting
– Postgis
– Wal2json
• This list is growing as our community can ask for more extensions coming for PGDG
repository

35
Pricing : how-to
• Select a plan
• Add some options if needed
• Done ! Everything else is included
1
2
3
Included Optional
Managed service
Dedicated Nodes
1 x Primary
1 x Replica
1 x Backuper
RAID10 Storage with
constant IOPS
In/Out network traffic
Backup (3 months)
Additional replicas
Snapshot restore

36
Estimated pricing tables
Nodes amount RAM (GB) /node IOPS /node Storage /node Price €H/T./month
3 dedicated nodes
are included by
default (primary,
replica, backuper).
16 To bench 450 GB RAID10 We target prices below AWS RDS /
Google SQL (simulating 1TB data
out + HA + std storage).
It includes in/out network traffic,
compute with constant IOPS,
storage, backups with 3 rolling
months retention, observability,
maintenance, …
32 To bench 450 GB RAID10
64 To bench 960 GB RAID10
128 To bench 1,9 TB RAID10
256 To bench 1,9 TB RAID10
Option Price / month
Replica (max 50) Depend of the cluster size
Backup restore OVH Public Cloud instance price

37
Pricing comparison with RDS: 16GB cluster
• Needs : PostgreSQL 11 cluster in FRANCE region, with HA intra region (at least 1 x primary + 1 x replica) FULL TIME up
– 16GB RAM per node
– 450 GB storage per node
– Backups : 2 months (let’s say 1TB of storage)
OVH
Enterprise cloud DB
AWS RDS
General purpose storage
AWS RDS
Provisionned IOPS storage
1 x cluster 16GB
Included :
• 3 x nodes (primary, replica, backuper)
• 3 months backups
• In/Out traffic (unlimited)
• Storage : 450GB RAID10 with
constant IOPS (target min. 10’000),
i.e. 900 GB usable
Compute : 2 x db.m5.xlarge (single AZ) : $600
Storage : 450 GB : $119
Backup (0,095$ per GB) : 2TB : $190
Network In : free
Network out (0,09$ per GB) : $90
Compute : 2 x db.m5.xlarge (single AZ) : $600
Storage : 450 GB x : $130
Provisioned IOPS (5000) : $1160
Backup (0,095$ per GB) : 2TB : $190
Network In : free
Network out ( 0,09$ per 1TB) : $90
Total : $950 USD /month estimated.
Please consult us for pricing.
Total : $999 USD / month
/! you will have only 1350 IOPS at this price
GP = 3 IOPS per GB (punctual burst possible)
Total : $2170 USD /month
Made 07/05/2019. Prices from
https://calculator.s3.amazonaws.com/index.html

38
Pricing comparison with RDS : 32GB cluster
• Needs : PostgreSQL 11 cluster in FRANCE region, with HA intra region (at least 1 x primary + 1 x replica) FULL TIME up
– 32GB RAM per node
– 450 GB storage per node
– Backups : 2 months (let’s say 1TB of storage)
OVH
Enterprise cloud DB
AWS RDS
General purpose storage
AWS RDS
Provisionned IOPS storage
1 x cluster 32GB
Included :
• 3 x nodes (primary, replica, backuper)
• 3 months backups
• In/Out traffic (unlimited)
• Storage : 450GB RAID10 with
constant IOPS (target min. 10’000),
i.e. 900 GB usable
Compute : 2 x db.m5.2xlarge (single AZ) :
$1200
Storage : 450 GB : $119
Backup (0,095$ per GB) : 2TB : $190
Network In : free
Network out (0,09$ per GB) : $90
Compute : 2 x 2db.m5.xlarge (single AZ) :
$1200
Storage : 450 GB x : $130
Provisioned IOPS (5000) : $1160
Backup (0,095$ per GB) : 2TB : $190
Network In : free
Network out ( 0,09$ per 1TB) : $90
Total : $1200 USD /month estimated.
Please consult us for pricing.
Total : $1599 USD / month
/! you will have only 1350 IOPS at this price
GP = 3 IOPS per GB (punctual burst possible)
Total : $2770 USD /month
With 5000 IOPS which is still low
Made 07/05/2019. Prices from
https://calculator.s3.amazonaws.com/index.html

40
Estimated Roadmap
Public documentation Private network (vRack)
PostgreSQL
April 2020Today (April)
New DBMS (MariaDB, Redis, …)
More regions
August October
Offers
DBMS
Features
Doing
Pg_HBA
General Availability
Early access. Infra & offers fine-tuning, API, …
Custom settings (timezone, ..)

42
F.A.Q.
How big can be the database?
How much querie/s the cluster can
handle?
It depends of the selected offer. Our
smallest offer provide ~900GB storage
available for PostgreSQL.
The offers above provide even more
storage, such as 1.8TB.
At some point it may be wise to use
sharding.
There is no better benchmark that your
own use-case. The amount of requests
per second depends a lot of the
worlkoad type (size of the request, in-
RAM use for your whole data, amount of
reads, amount of writes, CPU
consumption, etc).

43
F.A.Q.
Can I customize my PostgreSQL
configuration?
Can I use extension? Can I use homemade
extension or patched extension?
Not for now on your side, but some
selected settings will be available soon.
Today each cluster is configured and
optimized by OVH. The configuration is
crafted based on years of experience
running our core databases.
As extension can impact cluster stability
and therefore QoS, You may install
extensions based on a OVH vetted list.
You cannot install/use homemade or
patched extension.

44
F.A.Q.
How are backups managed?
Is the integrity of the backups checked?
How?
Backups are based on ZFS. They are made daily
by OVH and can be done on demand via the
OVH API.
To avoid bad impact on the production, we
process the backups jobs on a isolated host,
then we archive them on another location.
PostgreSQL service is stopped on this isolated
host before taking the snapshot to ensure the
consistency of the backup.
Not at the moment. To ensure backup integrity
we must know the business logic behind the
data (which we don't have). We plan to test
every single snapshot by restoring it on a test
instance and start PostgreSQL service.

45
F.A.Q.
What is the backup frequency? What is the backup retention?
When activated, backups are
created daily. You also have the
possibility to perform manual
backups.
We keep backups during 3 rolling
months.

46
F.A.Q.
Can I access all the backups? Can we restore a database with PITR
(Point-in-time-recovery)?
Backups are available via OVH API
and you cannot restore on a dedicated
host.
Yes, transaction logs are archived. This
way we can on your demand deploy a
dedicated host with a restoration of
your data right to the second.

47
F.A.Q.
How is the load distributed on the cluster?
Is the replication synchronous or
asynchronous?
Read requests are distributed across the
cluster using a load balancer (HAproxy
on top of dedicated hardware).
There are two endpoints available, one
for read-write requests, one for read-only.
Only one server will receive read-write
requests. Based on your cluster host
count, one or more servers will receive
read-only requests.
So, in nominal mode, we provide one
host for read-write and one for read-only.
The replication is asynchronous.
Synchronous will be available soon.

48
F.A.Q.
How a failed disk impact the
cluster/host?
How data corruption impact my cluster?
Disks are setup with RAID 10 so a
single disk failure won't impact its
host. Disks can be hot-swapped to
avoid downtime during replacement.
Therefore neither the host nor the
cluster is impacted by a failed disk.
• Application corruption
(malformed data inserted):
This is not per say a corruption
case but more a malformed data
case. This type of "corruption" will
be replicated across all nodes.
• Physical corruption:
We are using physical replication
(based on WAL), this means that
unless the corruption is written in
WAL files, the corruption will not be
spread across the cluster.

49
F.A.Q.
If an issue happens, how the failover works? What
are the impacts?
Can I perform a "manual fallback", i.e. electing
another node as ”primary" ?
• If we lose a replica node (read access), there
is no need for failover. OVH will detect the
failure and will recover the replica.
• If we lose a primary node (read/write access),
automatic failover will happen. Another node
will be elected as a primary. During the
failover, some connections may be closed and
some write queries may fail but it will last for
few seconds only.
No, because there is no use-case who need a
manual fallback. For example, if there an
hardware issue on the primary node, OVH will
see it and perform the required operations to
recover from this issue.

50
F.A.Q.
Worst-case scenario: what's happening if
OVH have an electrical failure inside the
whole datacenter?
Worst-case scenario: what's happening if we
have a cluster down, when writes operations
were ongoing, causing WAL corruptions?
We deploy cluster on regions, grouping
multiple availability zones, grouping multiple
datacenters:
• if minority of nodes is down (< 50%),
cluster will be safe
• if majority of nodes is down (>= 50%),
cluster will be in read-only mode
• if all nodes are down (= 100%), cluster will
reject connections
On region ca-west-qc-1 (Canada), there is
only one availability zone with electrical
connections across datacenters. An
electrical failure can take down the whole
infrastructure (extremely rare).
To avoid WAL corruption like this, the theory
is: hardware RAID cards + UPS with battery.
Our experience showed that these RAID
cards were causing much more troubles
compared to benefits (freezes, hazardous
rebuilds, ...).
If it's happening, our cluster will detect the
failure and promote another node as
”primary".
If physical corruption has been replicated
across the cluster, we will have to restore a
previous backup.

51
F.A.Q.
Worst-case scenario: after a cluster
downtime, how long does it take to be up
again?
How can I monitor my cluster? May I use zabbix,
shinken, nagios?
If the cluster went down, but is able to
restart properly without data corruption or
hardware failures, it will take the same
time as rebooting. Few minutes.
Yes, you can monitor everything related to
PostgreSQL on the cluster using the
connection provided. We recommend you to
configure a dedicated user for monitoring.
Internally, we have everything in place to
monitor each clusters. Our solution is based
on shinken (mostly community plugin).
Furthermore, we will provide soon
observability tools such as Grafana and
Graylog.

52
F.A.Q.
What are the exact maintenance tasks
performed by OVH?
Our goal is to simplify our customers life.
We deliver managed databases cluster, which
means in terms of maintenance:
• Linux OS security patches, distribution updates,
distribution upgrades
• DBMS security patches and minor versions
patches
• Hardware monitoring and maintenance: disk
failure, network failure, hosts failure, ...
DBMS major versions upgrade has to be defined
commonly and are not included. It could imply
services costs if needed (migration scenarios etc)
Where can I found all extensions available
on my cluster?
While connected to your cluster your can issue the
following command:
SELECT name
FROM pg_available_extensions
order by name;

53
F.A.Q.
Where can I found all extensions available
offline?
Here is the list of available extensions at the time of
writing: address_standardizer,
address_standardizer_data_us, adminpack,
amcheck, autoinc, bloom, btree_gin, btree_gist,
citext, cube, dblink, dict_int, dict_xsyn, earthdistance,
file_fdw, fuzzystrmatch, hstore, hstore_plpython2u,
hstore_plpythonu, insert_username, intagg, intarray,
ip4r, isn, jsonb_plpython2u, jsonb_plpythonu, lo,
ltree, ltree_plpython2u, ltree_plpythonu,
moddatetime, pageinspect, pg_buffercache,
pg_freespacemap, pg_prewarm,
pg_stat_statements, pg_trgm, pg_visibility, pgcrypto,
pglogical, pglogical_origin, pgrouting, pgrowlocks,
pgstattuple, plpgsql, plpython2u, plpythonu, postgis,
postgis_sfcgal, postgis_tiger_geocoder,
postgis_topology, postgres_fdw, refint, seg, sslinfo,
tablefunc, tcn, timetravel, tsm_system_rows,
tsm_system_time, unaccent, uuid-ossp, xml2.

54
Contact us
Questions, feedbacks ?
Feel free to contact us !
Request early access
Fill the form below :
@bastienOVH
databases@ml.ovh.net
https://labs.ovh.com/ha-database

OVH Lab - Enterprise Cloud Databases

Recommended

More Related Content

What's hot (20)

Similar to OVH Lab - Enterprise Cloud Databases (20)

More from OVHcloud (20)

Recently uploaded (20)

OVH Lab - Enterprise Cloud Databases