Your SlideShare is downloading. ×

E Vm Virtualization

448

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
448
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Industry VM Trends as They Compare with Current VM Standards
  • 2. Virtualization • End-Goal – Leverage current and viable infrastructure and process technologies with application architecture – Expedite adoption of VM technologies and cost savings with future technologies via more thorough application interface • Virtualization Opportunities – Environmental Limitations • Security • Network • Operational – More Thorough Unix Virtualization Roadmap Needed • Solaris is the only mature roadmap being investigated • Linux on VMWare has not been accepted due to limitations – Lack of Direction Towards Storage Virtualization
  • 3. Typical Virtualized Host Operating System Details All Include a System Most are Independent of Solaris is Exception Virtualization “Hypervisor” Underneath Hosted OS Stack* Today Hosted OS VM Physical Host Shared Physical Resources Network/IO Storage CPU Memory OS Subsystems* OS OS VM VM VM OS VM Management Hypervisor/Host OS (ESX) Centralized Resource Mgmt Network Consolidation* Shared Resources CPU Memory Storage Network I/O Typical Footprint Not Large SAN Not High IO ISV Validation Might Be Requirements Requirements Required
  • 4. Virtualization Risks Network and Security Internal Switch Required on Some Technologies Not Allowed by DMZ and SSN Now Allowed and Can’t Span Networks Network / Security Licensing 3rd Party Layered SW Needs to Functional Use Best fit for Virtual Instances Charge by Re-Use Must Be Closely Application Only Requirements Be Closely Examined CPU (Multi Core Approach Risk) Monitored Management Departments May Have Different Access Difficulty in Consolidation Access in ISV Validation Critical for Short and Long Criteria Specific Government – Type Departments Term Strategies Financial Chargeback Mechanism Needed Before Financial Question Need to Be Answered Asset Ownership Massive Proliferation of Technology
  • 5. VMs and Network/Security • Issues – Network/Security standards targeted to silos – Lack of communication/relationship of a common goal • Opportunities – Leverage current and viable technologies with cooperation with Network/Security – Expedite VM technologies and cost savings with future technologies or viable non standard technology • Next Steps – Setup a COE with Network/Security • Short term goals • Long term goals – Elicit participation from Operations, Architecture and Business Unit Teams
  • 6. Verizon Internal Data Network** Different Network Trust Regions Server Server G H Definitions: Restricted SSN DMZ SSN: Secure Subnet, access Zone systems and to mgmt consoles and mgmt system is restricted. Filter request in a per application basis/submission. DMZ: The same definition as SSN, Server Server Server except we have customer facing A C E systems. Restricted Zones: Areas where we Server Server Server might have cages and government B D F security guidelines that apply to personnel. Could be in a DMZ or SSN as well as regular Network. **Terminology might differ depending on the business unit
  • 7. Proposed Virtualization @ Segment Level Legend IDN SSN or DMZ Instance Color Denotes Virtual Physical Host 1 Application or OS Instance Denotes 2 Separate Instances of Same A B A B Application or OS Physical Host •Different IDN qualified OS/App instances can be virtualized inside the Physical Host 2 OS OS same physical servers •SSN or DMZ OS/App instances can A B only be virtualized inside of physical servers dedicated for that specific OS OS application •A new physical server required for the Physical Host 3 turn up of a new application in SSN or DMZ •Can not bridge physical or virtual A B instances across network segments (IDN to SSN and/or DMZ bridging)
  • 8. Proposed Centralized Physical Host Access and VM Firewalls •App/OS virtualized instances inside of a Physical Host/Hypervisor physical host are required to have their own firewall established as if they were an ordinary physical server •Console access to the Regardless of Network Segment physical host/hypervisor App/OS App/OS Placement, is restricted and needs to Instance B Instance B OS/Zone Firewall be accessed via a secured Required method •The access and Secure standardization of such Access console and process will Console Access be key for network/security agreement to further VM Infrastructures
  • 9. Existing VM Transfers Between Physical Systems @ Internal Data Network Segment Right hand side description points out IDN V-Motion like today’s ability to migrate procedures Physical Host 1 Physical Host 2 between physical hosts. allowed across different This is something that is physical hosts App A App B App B App C allowed in our VMWare with different farms and could also be applications at implemented across IDN only different non VMWare VM Free App E Free App G infrastructures
  • 10. Proposed VM Transfers Between Physical Systems @ SSN and/or DMZ Segments Right hand side SSN or DMZ description points out V-Motion like today’s ability to migrate procedures Physical Host 1 Physical Host 2 between physical hosts. allowed across different In this example, we’re physical hosts A B B Free more constricted. We can as long as migrate VM across physical hosts physical servers, only are isolated to when they’re part of the the same C Free D Free same application because application each application must reside in the same subnet
  • 11. Proposed Optimization of Virtualization @ Physical Layer • We’d like to get to a point IDN/DMZ/SSN where the virtualization technologies and security allows us to mix different network environments Physical Host • Preferred technology App A&D Prod & Dev (IDN Dedicated NIC) would be integrated A B virtual I/O instead of App B dedicated interface cards (DMZ Dedicated NIC) • We’ll need further C D reviews with security and App C (SSN Dedicated NIC) network to allow this to happen Integrated Virtual I/O Interfaces
  • 12. Example of Lack of Strategic Load Balancing Standard for VMs Example of a recent project in which a request for Load Balancing services could not be provided due to rules regarding LB and subnets. In this example, intelligent LB needs to be provided by BUA for systems located in BUB. Network path access from BUB users would be twice that of BUA and in the event BUB was the only user, then it would be counter productive.
  • 13. Linux and VM • State Today – Linux targeted as strategic goal for enterprise – Part of thrust into Open Source Solutions – No viable virtualization strategy for ML (Medium/Large) Linux Requirements {Medium/Large make up most of the requests} • Linux Virtualization Opportunities – Modification of Current Standards • Unisys Intel architecture scales vertically • IBM Intel architecture scales vertically • HP/IBM midrange offerings provide most mature Linux VM technologies – Accelerate Application from DB/Web Segregation • Decrease application with OS dependent footprint • Reduce size of OS dependent footprint for Linux
  • 14. Goal for SUN and VMWare Virtualized Environments VMWare Physical Host SUN Physical Host Windows Solaris 10 Windows Linux VM Solaris 10 Container VM Solaris 10 VM Linux Solaris 10 Container Container VM Container Hypervisor/Host OS (ESX) Solaris 10 Global Zone Shared Resources Shared Resources CPU Memory Storage Network I/O CPU Memory Storage Network I/O SPARC Based SUN System Benefits Intel Based ESX Farm Benefits • Cost Effective • Cost Effective, Large Consolidation Factor 12:1 • Supports Large Solaris Footprints • Supports Linux, Windows, Solaris (Non Standard) • Hypervisor and Guest VM Independence Limitations Limitations • Only Supports Solaris 10 • Global Zone and Container Dependency • Large Linux VM Footprints Do Not Fit Here • Smaller Consolidation Factor (OPS Target 4:1) • Need to Maintain Large Consolidation Factor
  • 15. Example: EOSL (end of serviceable life) to Virtualized Targets EOSL Port to Virtualization Target Candidates Target OS Linux & VMWare Farm Solaris 10 Legacy Linux Linux Tru64 VM VM HP Linux App/HW Eval Redhat Linux VM Code Virtualization Legacy Port Assessment Solaris 3rd Party SUN Solaris Port SUN Containers 10 Solaris Solaris Container Container Legacy AIX IBM Solaris Container
  • 16. Goal for SUN and VMWare Virtualized Environments VMWare Physical Host SUN Physical Host Windows Solaris 10 Windows Linux VM Solaris 10 Container VM Solaris 10 VM Linux Solaris 10 Container Container VM Container Hypervisor/Host OS (ESX) Solaris 10 Global Zone Shared Resources Shared Resources CPU Memory Storage Network I/O CPU Memory Storage Network I/O SPARC Based SUN System Benefits Intel Based ESX Farm Benefits • Cost Effective • Cost Effective, Large Consolidation Factor 12:1 • Supports Large Solaris Footprints • Supports Linux, Windows, Solaris (Non Standard) • Hypervisor and Guest VM Independence Limitations Limitations • Only Supports Solaris 10 • Global Zone and Container Dependency • Large Linux VM Footprints Do Not Fit Here • Smaller Consolidation Factor (OPS Target 4:1) • Need to Maintain Large Consolidation Factor
  • 17. Vendor Strength’s & Weakness HP IBM SUN VMWare Strength Strength Strength Strength • 4 Major OS Offerings • Leaders in • Solaris Footprint is • 3 Major OS Offerings Virtualization considerable • Mature vPar and • Industry Accepted Future VM • Leaders in Mgmt • Lower Cost • Mature Product Capabilities Aspects of • Cost Virtualization • P5 and P6 Performance Unmatched Weakness Weakness Weakness Weakness • Dependence on • Can be Expensive if • Reliance on Solaris 10 • Dependence on AMD Itanium not Properly Used and X86 Architecture • Limited to 2 • Decreasing OpenVMS • Limited to 2 Supported OSes • Vertical Scalability Market Supported OSes • ISV Support • Future ISV Support
  • 18. Storage Virtualization • State Today – 3 Business Units on Different Technologies – Centralization of Support Organizations • Linux Virtualization Opportunities – Virtualization @ Frame Level • Less complicated to execute • Exists today • Vendor lock possible – Virtualization outside the frame • Outside component – Has been proven and functional at other companies – Adds another layer of complexity • @ Cisco/Router/Switch Level – Not as widespread as other technologies – Possibly biggest benefit as technology drives towards fiber encapsulation
  • 19. Storage Virtualization Options Current , Available Most Common Storage Virtualization Technologies and Possible Storage Vendors such as HDS Vendors such as IBM can Virtualization can provide @ frame provide @ external component level level Strategies External Component @ Frame Level HDS IBM Current: server server No standard storage virtualization roadmap will hinder future server virtualization technologies. Data growth is out-pacing storage cost Virtualization @ Switch/Router Layer decline due to PCI/SOX requirements. Future Fiber Virtualization Would Occur within IP Within the Cisco Layer Encapsulation No storage ILM direction will continue to increase cost Switch Fabric Storage Virtualization Environment IP Switching Future: Any There are 3 viable options. Virtualize Frame within frame, go outside of frame or server possibly go with a Cisco/Switch Solution for storage virtualization

×