1 / 30

Three Shades of SPARC Enterprise M-Series Virtualization

Three Shades of SPARC Enterprise M-Series Virtualization. Roman Zajcew Ray Urciuoli Martien Ouwens. Safe Harbor.

booth
Download Presentation

Three Shades of SPARC Enterprise M-Series Virtualization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Three Shades of SPARC Enterprise M-Series Virtualization Roman Zajcew Ray Urciuoli Martien Ouwens

  2. Safe Harbor The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

  3. Program Agenda • Why Server and Application Consolidation? • Oracle SPARC M6-32 Consolidation and Virtualization Technologies • Layered Consolidation with the SPARC M6-32 • Use Cases • Summary

  4. Why Server and Application Consolidation?

  5. Benefits of Consolidation and Virtualization • Reduced number of managed objects and increased server utilization • Lower acquisition costs • Reduced service costs • Reduced power and cooling costs • Reduced data center infrastructure costs • Improved capacity and response time • Newer and faster processors, interconnects, and I/O • Increased flexibility • Faster time to deployment of new applications

  6. Consolidating & Sharing Headroom • One app per server leads to overload or extra headroom • Consolidate many apps to share and reduce headroom Single Larger Server Many Smaller Servers Consolidated and shared headroom Overload 15% 70% Overload Overload 40% 10% 5% 5% Overload 5% Distributed headroom

  7. SPARC M6-32: A Large Pool of Resources Deployment Flexibility Up to 32 processors, 384 cores, 3072 threads, and 32 TB memory • Single, shared memory image • Easier application deployment • Data partitioning not needed • Simplified software environment • Extreme system bandwidth • Extreme I/O bandwidth • Can be partitioned using virtualization tools • Any size workloads 3072 GB/sec Internal Bandwidth Up to 32 disks, 64 I/O slots, and 32 network ports SPARC M6-32: A real consolidation platform Deploy any size workload

  8. SPARC M6-32 Consolidation and Virtualization Technologies

  9. Physical Domains, PDomsaka Dynamic System Domains • Complete isolation • Resource, security, service, fault • No overhead • Separate OS or VM for SPARC instance per domain • No cost to end user Domain 1 Domain 2 Domain x Solaris Solaris Solaris CPU CPU CPU CPU CPU CPU CPU CPU Mem Mem Mem Mem Mem

  10. PDoms, Dynamic System Domains How and What • Domain Configuration Units • PDom • Bound • Limit 8 sockets • Central Switch notused • Unbound • > 1 DCU • Central Switch used • OpsCenter Integration

  11. NEW for High-End SPARC Oracle VM Server for SPARC (LDoms) • One OS instance for each LDom • Different patch levels for each LDom • Complete software isolation • Single-thread granularity • Dynamic • Secure Live Migration • No or very low overhead • No cost to end user LDom 1 LDom 2 LDom x Solaris Solaris Solaris Hypervisor CPU CPU CPU CPU CPU CPU CPU CPU CPU Mem Mem Mem Mem Mem

  12. Oracle VM for SPARC No Overhead virtualization • 128 LDoms per physical domain / system • best compromise between virtualization and performance • No or very low overhead • OpsCenterIntegration OVM A OVM B OVM C OVM D Zone Zone Application applications in each logical (or virtual) domain App App Application Oracle Solaris 11 Oracle Solaris 11 Kernel (Isolated OS’s) Hypervisor Firmware-based hypervisor Oracle SPARC Server OVM’s run on dedicated HW resources

  13. Oracle Solaris ZonesReduce Risk By Isolating Applications Application OS AppServer WebServer DBServer Server • One OS instance for all zones • Resource, namespace, file, network, process isolation • Scalable and native performance • Sub-thread granularity • Hardware independent • Dynamic and mobile • No overhead • No cost to end user

  14. SPARC M6-32 Virtualization Infrastructure No-cost virtualization to improve system utilization Solaris Legacy Zone Solaris 10 Zone Solaris 11 Zone Solaris 10 Zone Solaris Legacy Zone Solaris 10 Zone Solaris 11 Zone Oracle Solaris 11 Oracle Solaris 10 Oracle Solaris 10 Oracle VM Server for SPARC Oracle Solaris 11 Oracle VM Server for SPARC Dynamic Domain Dynamic Domain Dynamic Domain SPARC M6 Platform

  15. Oracle Enterprise Manager Ops CenterComprehensive Management for Physical and Virtual Systems CLI BUI API Management Monitoring Virtualization Management Asset Management Provisioning Patching Policy Management Solaris Resource Management Zones Operating System Virtual Machine Hypervisor Physical Server Zone Zone Zone Zone Zone Zone Solaris Solaris Solaris Solaris Windows LDom1 LDom2 Logical Domain SPARC Server SPARC Server X86 Server X86 Server X86 Server

  16. Layered Consolidation with the SPARC M6-32

  17. Oracle Solaris Virtualization Licensing • Part of System / Solaris, no extra charge • Support included in maintenance fee • Recognized as hard license boundary: • PDom aka Dynamic System Domains • LDom • Capped zones • http://www.oracle.com/technetwork/server-storage/vm/ovm-sparc-hard-partitioning-1403135.pdf

  18. Layered Consolidation PDoms, LDoms and zones v • Intro and Consolidation Philosophy each LDom hosts a fully isolated O/S instance. Trend to isolation and complexity Trend to flexibilty and simplicity zone 1 PDom, 1 LDom, 64 Zones 4 4 PDom, 16 LDom, 64 Zones 1 PDom, 4 LDom, 64 Zones 4 PDom, 64 LDom, 64 Zones LDom PDom

  19. Configuration Examples Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Oracle Solaris Zone 1 Zone 2 Oracle Solaris Zone 3 Zone 1 Zone 2 Zone 3 LDom LDom LDom LDom LDom LDom LDom LDom LDom LDom LDom LDom LDom PDom 0 PDom 1 PDom 2 DCU2 DCU3 DCU1 DCU0 HW platform (CPU, MEM, PCI, HDD) CMU CMU CMU CMU CMU CMU CMU CMU CMU CMU CMU CMU I/O I/O I/O I/O

  20. Use Cases

  21. Reallocate Resources in Logical Domains Logical Domain C Logical Domain B Logical Domain A Logical Domain B Logical Domain A Logical Domain A Zone B Zone A Zone A Zone A Zone A User/Services App App App App App App App App App App App App App App App Kernel Solaris 10 Solaris 11 Solaris 10U11 Solaris 11 Solaris 11 Solaris 10U9 + Patches Hypervisor Hypervisor Hardware Hardware PDom 0 PDom 1 DCU DCU DCU

  22. Migration in Logical Domains Logical Domain C Logical Domain D Logical Domain D Logical Domain B Logical Domain A Logical Domain C Logical Domain A Zone B Zone B Zone B Zone A Zone A Zone A Zone A User/Services App App App App App App App App App App App App App App App App App App App App Kernel Solaris 11 Solaris 11 Solaris 11 Solaris 11 Solaris 10U11 Solaris 10U9 + Patches Solaris 11 Hypervisor PDom 0 Hardware PDom 1 DCU DCU DCU

  23. Internal I/O Channels – Logical Architecture Logical Domain C Logical Domain B Logical Domain B Logical Domain A Logical Domain A Zone B Zone A Zone A User/Services App App App App App App App App App Kernel Solaris 10 Web Proxy Solaris 11 Solaris Solaris Solaris App Server Firewall Back End Virtual Network -- 192.168.XX.XX Hypervisor Hypervisor Hardware Hardware PDom 0 PDom 1 DCU DCU DCU

  24. Mapping A Typical SAP Architecture SAP Prod APP LDomB SAP Prod APP LDomA SAP Prod DB+CS/CI (HA Node #1 of 2) Domain B SAP Prod APP LDomA SAP Prod APP LDomA Zone H Zone G Zone B Zone C Zone D Zone E Zone F Zone A User/Services SRM D1 SRM D2 ECC D2 ECC D1 BW D2 BW D1 EP D1 EP D2 ECC SRM Solaris 11 Solaris 11 Solaris 11 Kernel Solaris 10 U11 Solaris 10 U11 Hypervisor Hypervisor Hardware Hardware PDom 0 PDom 1 DCU DCU DCU

  25. To fill a shape with an image. Use existing picture box, DO NOT delete and create new picture box. Right click on the shape. At the bottom of the submenu select “Format Shape” Select “Fill” at the top of the “Format Shape” dialog box. Select “Picture or Texture fill” from the options. And select “File” under the “Insert from” option. Navigate to the file you want to use and select “Insert” On the “Format” tab, in the Size group, click on “Crop to Fill” in the Crop tool and drag the image bounding box to the desired size DELETE THIS INSTRUCTION NOTE WHEN NOT IN USE Summary

  26. Summary • SPARC M5-32 / M6-32 virtualization included and recognized license boundary • PDom aka Dynamic System Domain • LDom • Zones • Reducing cost • Increase server utilization • Increase flexibility • Simplified management

  27. What Next? • Find out more about the SPARC M6-32 server • http://www.oracle.com/goto/m6-32 • Download from the above site • “Consolidation Using the SPARC M6-32 High End Server” • “SPARC M6-32 Server Architecture” • “Maximizing Application Reliability and Availability with SPARC M6-32” • EXPECTED SOON : “Best practices: SPARC M6 Domaining” • Contact your local Oracle or Partner sales rep

More Related