Performance Isolation in Multi- Tenant Relational Database-asa-Service. Sudipto Das (Microsoft Research)

Size: px

Start display at page:

Download "Performance Isolation in Multi- Tenant Relational Database-asa-Service. Sudipto Das (Microsoft Research)"

Cornelius Peters
5 years ago
Views:

1 Performance Isolation in Multi- Tenant Relational Database-asa-Service Sudipto Das (Microsoft Research)

2 CREATE DATABASE CREATE TABLE SELECT... INSERT UPDATE SELECT * FROM FOO WHERE

5 App1 App2 App3 App1 App2 App3 App1 App2 App3 AA 1 AA 2 AA 3 Application OS OS OS OS OS OS Hardware Hardware Hardware Hardware Tenant 1 Tenant 2 Tenant 3 Stronger Isolation Higher Consolidation

6 shared Major concern affected Machine in cluster Database server process Tenant1 database Tenant2 database Tenant2 Application

7 Throughput (qps) Other tenant workloads start Tenant of interest Time

8 want unaffected other queries/sec query latency vastly different amounts of resources WHERE Country= Honduras China rich support for SQL Even ad-hoc queries

9 Database server process (25% CPU utilization, 4GB RAM) Tenant1 database 100 IOPS Tenant is promised minimum reservation of DBMS resources Logical resource container inside DBMS process CPU utilization, IOPS, Memory, Resource governance Fine-grained dynamic resource scheduling mechanisms for CPU, I/O, memory Targeted towards requirements of multi-tenancy Metering (auditing) Monitor actual and promised resources for tenant Determine violations

10 isolation consolidation Accountability overbook resources

12 Throughput (qps) Other tenant workloads start Tenant of interest Time

13 CPU Utilization (%) Disk reads / sec (IOPS) Throughput (qps) Latency (ms) Other tenant workloads start Tenant of interest Time Time Time Time

14 CPU Utilization (%) Disk reads / sec (IOPS) Throughput (qps) Latency (ms) Other tenant workloads start Tenant of interest Time Time Time Time

17 VLDB 2014

18 Reservation of CPU utilization at the server Client-facing abstractions may vary Tenant1 Tenant2 without any knowledge of workload Low latency Non-preemptive scheduling Flexible provider-enforced policies

20 CPU utilization % T 1 : Dell DVD benchmark (OLTP) Min=20%, Max=20% T 2 : TPC-H (Data warehousing) Min=30%, Max=30% T 3 : Very short CPU bursts (CPU Loop) Min=40%, Max=40% T 3 : CPU Loop Min = 40, Max = 40 T 2 : DSS Min = 30, Max = 30 Time T 1 : OLTP Min = 20, Max = 20 Sharing scheduling opportunities in proportion of MinCPU

21 Deficit largest deficit (d i ) Key idea:

22 MinCPU 1 = MaxCPU 1 = 50% MinCPU 2 = MaxCPU 2 = 25% d i = MinCPU i CurCPU i MinCPU i T 1 s quantum 4X that of T 2 d 1 d 2 (50 0) 50 (25 0) 25 = 1 = 1 (50 0) 50 (25 100) 25 = 1 = 3 (50 80) 50 (25 20) 25 = 0. 6 = 1 ( ) 50 ( ) 25 = = (50 50) 50 (25 25) 25 = 0 = 0 T 2 T 1 Guarantees minimum CPU Sharing at a fine time granularity results in better latency response

CPU utilization % CPU utilization % T 1 : Dell DVD benchmark (OLTP) T 2 : TPC-H (Data warehousing) T 3 : CPU intensive (very short queries) 100 90 80 70 60 50 40 30 20 10 0 T 3 : CPU Loop Min = 40,

23 CPU utilization % CPU utilization % T 1 : Dell DVD benchmark (OLTP) T 2 : TPC-H (Data warehousing) T 3 : CPU intensive (very short queries) T 3 : CPU Loop Min = 40, Max = 40 T 2 : DSS Min = 30, Max = 30 Time T 1 : OLTP Min = 20, Max = T 3 : CPU Loop Min = 40, Max = 40 T 2 : DSS Min = 30, Max = 30 Time T 1 : OLTP Min = 20, Max = 20

24 Guarantees minimum CPU Global reservations Dynamic priority work-conserving scheduler Additional policies by adapting the definition of deficit

25 insufficient demand provider not adequately allocating resources Intuition delaying metering interval Numerator: Denominator: Violation if and only if CPU i Eff < MinCPUi

26 Meets reservations excellent performance isolation

27 Deficit Round Robin (DRR) same deficit formula Round robin scheduling Earliest Deadline First (EDF) (MinCPU i CurCPU i ) Different deficit formula greedy similar

28 99th Perc Latency (ms) Eight tenants LDF DRR EDF No Res T 8 : 25% 85% capacity reservation CPU-IO benchmark eight bully workloads: 5,000 4,500 4,000 3,500 3,000 2,500 2,000 1,500 1, Number of Bullies

30 100 IOPS 50 IOPS Tenant1 Application Machine in cluster Tenant2 Application SQL Server process Capacity: 200 IOPS Tenant1 database Tenant2 database

31 Promised IOPS not achieved Metering interval (e.g. 1 sec) Promised: 100 IOPS Achieved: 80 IOPS Insufficient workload Sufficient workload, but system unable to meet promise Burst of 200 I/Os arrive Each I/O request: Deadline, Actual Issue 50 I/Os 100 I/Os 50 I/Os

32 Tenant1 Application Machine in cluster SQL Server process Tenant2 Application Tenant1 database 2GB Tenant2 database 4 GB

34 M S L Telemetry Outputs: Scaling action, scaling explanation... Auto-scaling Solution Inputs: Cost budget, container size ranges Performance goals, sensitivity...

35 MinIOPS 1 : 150 MinIOPS 2 : 125 Tenant1 Application Tenant2 Application Capacity: 200 IOPS Tenant1 database Node DBMS Tenant2 database

36 Multi-tenancy performance service tiers SQLVM Microsoft Research

38 More information:

Rack-scale Data Processing System

Rack-scale Data Processing System Jana Giceva, Darko Makreshanski, Claude Barthels, Alessandro Dovis, Gustavo Alonso Systems Group, Department of Computer Science, ETH Zurich Rack-scale Data Processing