AZ900-AzureFundamentals-part-8.pdf
- 1. Availability and Durability Availability and Durability Availability Will I be able to access my data now and when I need it? Percentage of time an application provides the operations expected of it Durability Will my data be available a er 10 or 100 or 1000 years? Examples of measuring availability and durability: 4 9's - 99.99 11 9's - 99.999999999 Typically, an availability of four 9's is considered very good Typically, a durability of eleven 9's is considered very good 69
- 2. Availability Availability Availability Downtime (in a month) Comment 99.95% 22 minutes 99.99% (4 9's) 4 and 1/2 minutes Typically online apps aim for 99.99% (4 9's) availability 99.999% (5 9's) 26 seconds Achieving 5 9's availability is tough 70
- 3. What does a durability of 11 9's mean? If you store one million files for ten million years, you would expect to lose one file Why should durability be high? Because we hate losing data Once we lose data, it is gone Durability Durability 71
- 4. Increasing Availability: Have multiple standbys available OR distribute the database in multiple Zones in multiple Regions Increasing Durability: Multiple copies of data (standbys, snapshots, transaction logs and replicas) in multiple Zones in multiple Regions Replicating data comes with its own challenges! We will talk about them a little later Increasing Availability and Durability of Databases Increasing Availability and Durability of Databases 72
- 5. Imagine a financial transaction being lost Imagine a trade being lost Imagine a stock exchange going down for an hour Typically businesses are fine with some downtime but they hate losing data Availability and Durability are technical measures How do we measure how quickly we can recover from failure? RPO (Recovery Point Objective): Maximum acceptable period of data loss RTO (Recovery Time Objective): Maximum acceptable downtime Achieving minimum RTO and RPO is expensive Trade-off based on the criticality of the data Database Terminology : RTO and RPO Database Terminology : RTO and RPO 73
- 6. Question - RTO and RPO Question - RTO and RPO You are running an application in VM instance storing its data on a persistent data storage. You are taking snapshots every 48 hours. If the VM instance crashes, you can manually bring it back up in 45 minutes from the snapshot. What is your RTO and RPO? RTO - 45 minutes RPO - 48 hours 74
- 7. Achieving RTO and RPO - Failover Examples Achieving RTO and RPO - Failover Examples Scenario Solution Very small data loss (RPO - 1 minute) Very small downtime (RTO - 5 minutes) Hot standby - Automatically synchronize data Have a standby ready to pick up load Use automatic failover from master to standby Very small data loss (RPO - 1 minute) BUT I can tolerate some downtimes (RTO - 15 minutes) Warm standby - Automatically synchronize data Have a standby with minimum infrastructure Scale it up when a failure happens Data is critical (RPO - 1 minute) but I can tolerate downtime of a few hours (RTO - few hours) Create regular data snapshots and transaction logs Create database from snapshots and transactions logs when a failure happens Data can be lost without a problem (for example: cached data) Failover to a completely new server 75
- 8. New reporting and analytics applications are being launched using the same database These applications will ONLY read data Within a few days you see that the database performance is impacted How can we fix the problem? Vertically scale the database - increase CPU and memory Create a database cluster (Distribute the database) - Typically database clusters are expensive to setup Create read replicas - Run read only applications against read replicas (New Scenario) Reporting and Analytics Applications (New Scenario) Reporting and Analytics Applications 76
- 9. How do you ensure that data in multiple database instances (standbys and replicas) is updated simultaneously? Strong consistency - Synchronous replication to all replicas Will be slow if you have multiple replicas or standbys Eventual consistency - Asynchronous replication. A little lag - few seconds - before the change is available in all replicas In the intermediate period, different replicas might return different values Used when scalability is more important than data integrity Examples : Social Media Posts - Facebook status messages, Twitter tweets, Linked in posts etc Read-a er-Write consistency - Inserts are immediately available However, updates would have eventual consistency Consistency Consistency 77
- 10. There are several categories of databases: Relational (OLTP and OLAP), Document, Key Value, Graph, In Memory among others Choosing type of database for your use case is not easy. A few factors: Do you want a fixed schema? Do you want flexibility in defining and changing your schema? (schemaless) What level of transaction properties do you need? (atomicity and consistency) What kind of latency do you want? (seconds, milliseconds or microseconds) How many transactions do you expect? (hundreds or thousands or millions of transactions per second) How much data will be stored? (MBs or GBs or TBs or PBs) and a lot more... Database Categories Database Categories 78