Virtualizationbased Techniques for Enabling Multitenant Management Tools - PowerPoint PPT Presentation

Title: Virtualizationbased Techniques for Enabling Multitenant Management Tools


1
Virtualization-based Techniques for Enabling
Multi-tenant Management Tools
2
Typical Network Monitoring Infrastructure
Network
Agent
DB
ManagementWorkstation
3
Monitor Multiple Customers Using Typical
Infrastructure
Customer CNetwork
Customer BNetwork
Customer ANetwork
Customers
Agent
Agent
Agent
DB
DB
DB
MgtWS
MgtWS
MgtWS
Service provider
4
Multi-Tenant Network Monitoring Infrastructure
Customer CNetwork
Customer ANetwork
Customer BNetwork
Agent
Agent
Agent
DB
ManagementWorkstation
5
Issues

• Significant re-design and re-implementation
  required
• New authentication, authorization, accounting
  system
• Flexible configurations (specific rules and
  preferences)
• Scalability
• Problematic for legacy software products
• Network management service isnt simply
  convertible
• Firewall
• Network address contention between customers
• Private Internet addresses (10/8, 172.16/12,
  192.168/16)
• Wide use of NAT-router
• Some functions need L2 network access (DHCP,
  BOOTP)

6
Goal Make Single-tenant Tools Multi-tenant
Capable

• Approach
• Virtualization
• Creating containers for each single-tenant
  instance
• Consolidation
• Sharing common infrastructure
• How?
• Demonstrate how to make a single-tenant network
  management system multi-tenant capable

7
Example Tool OpenNMS

• Open-source with commercial support
• www.opennms.org / www.opennms.com
• Java application
• Front-end Java Servlets, JSP
• Database PostgreSQL
• Primary functions
• Device discovery
• Service and performance monitoring
• Event management
• Asset management

8
Outline

• OpenNMS architecture and service model
• Approaches to enabling multi-tenancy
• Virtualization-based back-end consolidation
• Database sharing
• Front-end consolidation
• Evaluation
• Workload profile
• Scalability
• Conclusion

9
OpenNMS Architecture
JVM
JVM
Tomcat
OpenNMS (main program)
OpenNMS UI
CustomerNetwork
PostgreSQL Nodes/Services/Events/Outages/Notifica
tions/SNMP configuration/
10
OpenNMS Service Model
L2VPN
JVM
Customer Network
PgSQL
JVM
Tomcat
OpenNMS
UI 1
RRDfiles
Network ManagementService Provider
11
Back-end Consolidation

• Goal Minimum changes to the original system
• Requirements
• Resource (memory, processes) isolation
• Independent file system
• Virtualized network layer
• Virtualization
• Secure, private
• Low-overhead (Xen, OpenVZ)
• Performance isolation

12
Database Sharing and Front-end Consolidation

• All instances use the same schema
• Database one database server
• Separate database user and database name
• Database privileges for access control
• Front-end one Tomcat server
• Different paths for different instances
• HTTP/S authentication

13
Multi-Tenancy Using Virtualization
Customer 1Network
Host OS (Dom 0)
VPN
VM 1
JVM
JVM 1
Tomcat
OpenNMS 1
UI 1
PgSQL
Customer nNetwork
VPN
VM N
JVM N
OpenNMS n
UI n
RRDfiles
Network ManagementService Provider
14
Evaluation

• Resource profiling
• Bottleneck identification
• Scalability with customer network size
• Software configuration JVM heap size
• Multi-tenant scalability
• Baseline
• Xen
• OpenVZ

15
Experiment Setup
Host OS (Dom 0)
Customer 1Network
VM 1
JVM
Apache
JVM 1
Tomcat
OpenNMS 1
VPN
UI 1
192.168.8.18.200
PgSQL
9.200
Customer nNetwork
VM N
JVM N
OpenNMS n
UI n
VPN
RRDfiles
VPN
Network Management Service Provider
Emulated Customer Network
PC Servers Core 2 Duo E6600, 4GB RAM, (2)
7,200rpm HDD, GbE
16
Resource Profile Memory CPU Usage

• Single-tenant, monitoring 200 hosts
• Memory is the bottleneck resource

17
Scalability 200 1000 Hosts

• 2MB memory / 200 monitored hosts
• Minimal incremental cost

18
Impact of JVM Heap Size 64 128 MB

• GC frequency decreases with heap size
• Live objects take up space and increase GC
  workload
• OpenNMS OpenVPN take 144MB to run

19
Baseline Simple Consolidation

• Baseline completeinstallation in each VM
• RRD disk I/O intensive
• Benchmark by scriptingfront-end activities
• Front-end and database accesses
• Dynamic web page generation (average response
  time)
• Service discovery and monitoring accuracy

20
Multi-tenant Scalability
With RRD
Without RRD

• 60 increase for Xen
• 90 increase for OpenVZ

• 58 increase for Xen
• 83 increase for OpenVZ

21
Future Work

• Java class sharing
• Duplicated class definition, but JVMs are in
  different VMs
• Coordinating JVMs
• JVMs in guest OS are unaware of VM sizing
• Dynamic JVM sizing

22
Conclusion

• An approach to enabling multi-tenant capability
• Virtualize the base platform
• Share supporting services
• Increased service density
• 60-90 more tenants on a single platform

23
Thank you for your attention.
Any questions?
chtsai,kgshin_at_eecs.umich.eduyaopruan,sambits,a
ashaikh_at_us.ibm.com