Multitenancy. Berthold Reinwald, IBM Almaden Research Center. UW MSR Summer Institute, 2010

Transcription

1 Multitenancy Berthold Reinwald, IBM Almaden Research Center UW MSR Summer Institute, 2010

2 Two Use Cases for Multi-Tenancy SaaS ISVs (Multi-tenant s): - Long tail of tenants - very large number of small tenants using same logical database schema App DB 1 App DB 2 App DB 10k Multi-tenant User 1,1 App 1 App 50 User 10k,100 << # app DBAs << # system DBAs DB 1 DB 10 Large nbr of small tenants /Database Consolidation: - Long tail of applications (with different schemas) App 1 DB 1 App 2 DB 2 App 10k DB 10k Consolidation App 1 App 2 App 10k = # app DBAs << # system DBAs DB 1 DB 100 Large nbr of small apps 2 IBM Research

3 3 IBM Research

4 Some Observations regarding SaaS s Extremely low pricing for SMB-oriented Saas offerings - E.g. each food shop pays service fee $1/day, or very small amount of data Lower delivery costs - Tooling/automation/standardization in hosting center - By maximizing resource sharing Isolation - Data/Security, Performance (workload), system (failure), maintenance Customization - Several alternative, e.g. reserved fields, xml columns. SLAs - Ranging from app level to DB level - s upgrade/downgrade SLAs. Lower developments costs for ISVs - transparent programming interface for multi-tenants apps Scalability & availability - Larger number of tenants (millions), incremental scale-out on low end machines w/o impacting existing service 4 IBM Research

5 Multi-instance single-tenant applications vs. single-instance multi-tenant applications S4: Multi-VM S3: Multi-Stack S2: Multi-App S1: Multi- Multi- OS OS OS OS OS Hardware Hardware Hardware Hardware shared hardware shared OS shared middleware shared application Isolation Sharing From Single-tenant to Multi-tenant: Isolation and customization Time-to-Market Economy of multi-tenancy 5 IBM Research

6 Higher Query Optimization/runtime Complexity, Higher Security Worries Database Multi-Tenancy Models Multi-tenant App App Server Multi-tenant App App Server A B Multi-tenant App App Server Separate s/dbs A B Separate Schemas s w/ different schemas (e.g. customization) Larger catalog footprint Table statistics -specific backup/restore Shared Tables s w/ same schema Smallest metadata Difficult tenant-specific optimizations and tooling Comparable Performance Higher Multitenancy, better resource utilization 6 IBM Research

7 Economy of Multi-Tenancy - Scale-Out Quantification - Characteristics 100 registered users per tenants 5% active user ratio (5 users) Active tenant ratio 10% S3: Shared OS S2: Shared Middleware S1: Multi- # concurrent tenants (footprint/tenant) 9 due to memory footprint 32 due to memory footprint 300 due to performance bottlenecks # registered tenants 9 inactive tenants consume runtime resources 32 inactive tenants consume runtime resources 3,000 inactive tenants don t consume runtime resources Scaling Nbr of s 1x 3x 300x 7 IBM Research

8 Economy of Multi-Tenancy - Cost Savings Analysis - count S3: shared OS S2: shared middleware S1: Multi- 333 systems 3,000 3,0004,000x middle ware maint ce & app operations inst ,0003,000x systems middle ware maint ce & app operations inst. systems middle ware MTapp maint ce & operations 8 IBM Research

9 Multi-Tenancy Comparison Single-tenant Apps Multi-tenant Apps Time to Market App development on boarding deployment transformation or new developmt Limited customization through tenant subscription Isolation in application and DB Isolation Security Performance Availability Isolation per Row & schema & system level Isolation Governance Maintenance Load balancing & Sharding High availability & Fault tolerance Scaling Registered s 1~3x 300x Cost HW, SW, daily op s & maint ce 200~400x 1x 9 IBM Research

10 Multi-tenancy Challenges DB Multi- Layer Virtual Multi- Layer Isolation, Scalability, Performance, Customization, Resource Utilization, Metering 10 IBM Research

11 Research Challenges High Availability and Failover and Load Balancing Large number of instances/databases At the database level, or below the database Distributed Fabric - Many different levels of failure detection - Scale out Isolation: data, performance, system, maintenance Customization SLAs for availability and performance Benchmarks - Footprint/tenant, cost/tenant 11 IBM Research