Você está na página 1de 12

Migration from VMware to Oracle VM

– A Case Study
ORAC LE WHITE P APER | NOVEM BER 2015
Disclaimer
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.

MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Table of Contents

Disclaimer 1

Oracle on Oracle Introduction 1

VMware to OVM Migration – a Structured Approach 1

Discovery and Assessing the Source VMware Environment 2

Building the Target VM Migration Environment 2

Oracle VM Management (OVMM) Design and Deploy 3

Oracle VM Shared Storage Design and Deploy 3

Oracle VM Network Design and Deploy 3

PoC Network Topology of Oracle Sun X4-2 Servers and ZFS Storage 4

OVM Network Topology - A Logical View 5

OVM Migration and Automation 7

Conclusion 8

MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Oracle on Oracle Introduction
This paper is based on an Oracle Consulting project that was initiated following the acquisition of
Micros Corporation by Oracle. One of the technical objectives resulting from that acquisition was to
deliver the Micros Hospitality applications as a software as a solution (SaaS) via the Oracle Cloud.

The first phase of that SaaS effort involved building a Proof of Concept (PoC) environment,
representative of the Oracle Cloud for Industries (OCI) hardware and software infrastructure, and
migrating the Micros applications over to that infrastructure.

Micros had historically deployed their multi-tiered, highly distributed, Global Hospitality Cloud
applications on infrastructures based on VMware 5 virtualization, and operating systems and hardware
from Microsoft, HP, EMC, Cisco and HP-3Par. Micros also had all of the associated datacenter costs
and issues including fragmented environments with various critical applications running on disparate
operating systems and proprietary hardware from an array of vendors; all with their loosely integrated
point product tools for infrastructure management.

The desired end state, as well as a Corporate mandate, was to have the core Oracle-Micros
Hospitality Cloud applications running on Oracle hardware, i.e. Oracle on Oracle, while leveraging the
OCI recommended framework and Maximum Availability Architecture (MAA) best practices for Oracle
Virtual Machine 3 (OVM 3), Sun X-Series enterprise grade servers, and ZFS-SA storage provided over
SAN and NAS topologies. This paper focuses specifically on the approach used to migrate Micros
applications from VMware VM onto the Oracle VM using the PoC Oracle on Oracle platform.

VMware to OVM Migration – a Structured Approach


The VMware VM to OVM migration approach involved 3 primary phases outlined below.
» Discovery/Assessment Phase. The primary steps in this phase included reviewing the existing
virtualization system architecture, discovery of the existing VMware foot prints at the Micros
datacenters, and establishing a target architecture recommendation. During this process the existing
compute, memory, network interfaces, network topologies and storage profiles were compiled for
each ESXi server cluster in the environment using VMware Tools, vSphere Client or vCenter
functionalities. In some cases other third party tools are used for this purpose. RVTools for example,
is a third party product and is capable of generating an RV Report for the VMware VM infrastructure
providing a detailed outline of the VM configurations.
» Target OVM Environment Build Phase. This phase entailed the process of constructing the new
OVM Cloud PoC environment utilizing the newly acquired Oracle X4-2 servers, a Cisco network
infrastructure, ZFS-SA storage appliances, and with OVM 3 vitalization technology; following the OCI
recommended guidelines while building the PoC ecosystem.

1 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


» Automated Migration Phase. This phase was comprised of the actual migration of VMware VM
image (OVA) files to Oracle VM Assembly by executing custom scripts developed using Oracle VM
APIs and CLI scripts. Automated migration process is illustrated at a high level in Figure 1,

Figure 1: Automated Migration process for Converting VMware images to OVM Assembly

Discovery and Assessing the Source VMware Environment


The process of assessing the existing VMware environment involved gaining a thorough understanding
of the Micros VMware landscape by determining the number, sizes, and contents of the VM’s that were
to be migrated. Ultimately this process led to establishing the target OVM architecture and mapping of
VMware VMs, from current state to OVM based future state. The steps followed were to:
» Collect vSphere Reports. by selecting the vSphere Client Virtual Machines Tab or using RV Tools
» Collect Compute, Storage and Network capacity statistics from Oracle Enterprise Manager, and other
similar resource management platform used to monitor host, network and storage resources.
» Review provisioned Virtual Machine specifications for Memory, Network, CPU, and Storage; noting
over-provisioning factors
» Translate above data to an equivalent Oracle VM target, OVS server cluster and overall VM design.

Building the Target VM Migration Environment


There were three key design considerations when architecting and deploying the virtual machine
environment using Oracle VM 3. For the PoC, Oracle Consulting followed the OCI recommended
framework with slight modifications required to suit Micros’ requirements.

2 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Oracle VM Management (OVMM) Design and Deploy
Oracle Virtual Server (OVS) is comprised of a lean, highly optimized, hypervisor component that runs
on the physical server(s) and are typically clustered to provide VM High Availability (HA) functionality.
OVS provides the compute, network, and storage resources to the guest VMs. A separate tightly
integrated virtual infrastructure management platform component, Oracle Virtual Machine Manager
(OVMM), runs on either a separate physical or virtual server, usually in an HA manner. These two major
software components, OSV and OVMM, are collectively known as OVM. For the PoC OVM Manager
was installed on a physical server, which is the preferred practice. OVM Manager was used to create,
provision and manage one or more OVS physical server pools, manage and provision the various
resources to the guest VMs running in the pools; resources such as SAN and NAS storage and the
virtual networking utilized by the guest OSs and application stacks. There were some key design
considerations for OVMM that were factored into the overall Oracle VM deployment architecture and
these are:
» Location of OVMM – physical or virtual server; a physical server is preferred.
» Standalone or high availability configuration for OVMM – HA is preferred.
» Location and technology for OVMM data store – MySQL or Oracle DB – MySQL for PoC.
Oracle VM Manager stores its management data in a database, which could have either been installed
locally on the Oracle VM Manager Server or remotely on another server. For the PoC, the default
MySQL local database was sufficient; however for more enterprise production environment
deployments Oracle Database 11gR2 Standard Edition could be used.

Oracle VM Shared Storage Design and Deploy


As with any IT ecosystem, the storage platforms chosen and how they are configured are critical to the
overall performance of the environment. The following areas were considered during the PoC storage
design and deployment:
» Planning and architecting for shared multi-tiered storage resources; in the PoC an Oracle ZFS
Storage Appliance (SA) ZS3-4 array was used, composed of an Active-Active HA operating mode
and utilizing 10K SAS HDD drives and write biased SSDs
» Provisioning of the shared storage to the OVM server pool repositories utilizing the ZFS-SA
capabilities of providing a variety of block and file level access over: FC, iSCSI, NFS and CIFS, in
order to provide performant and capacity oriented resources over various media types. For the PoC,
performant NFS and iSCSI over 10GBE LACP and IPMP bonded links were used to provide 40Gb/s
of network bandwidth from each ZFS-SA controller node
» Assuring that SLA dependent storage resources for performance, availability and capacity are
provided when creating the repositories (i.e., storage resources) that align well to established
application IO characterizations for Micros’ applications
» Presenting of the OVM repository based storage, if used, and Raw Device Mapped (RDM) storage to
Oracle VM guests, in a manner that provides the most optimal storage performance aligned to the
application IO characterizations. For the PoC, only repository based storage was used

Oracle VM Network Design and Deploy


The following areas were considered carefully during the OVM network design and deployment, and are
described in brief below. Generally speaking, six to eight network service types are deployed for a
Maximum Availability Architecture (MAA) compliant OVM environment. For the PoC, certain functions
that would otherwise be on dedicated networks were combined onto one VLAN. Specific network

3 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


service configurations utilized in the PoC are depicted and described below in Table 1. The various
network types provide the virtualization servers and network infrastructure functional areas used in the
PoC OVM ecosystem.
Network Service Types
Network IP Network – Description Type Design & Usage Consideration

Sun X4-2 Server Client access: OVMM was installed on a


1 10.0.1.0/24 Oracle Server VLAN Routable Physical X4-2 server. This network was used for direct access to the
X4-2 OVS Server Pools.

Application Server Client Access: This network was used for


2 10. 0.2.0/24 Application VLAN Routable Application server VMs. Application servers, Web-tier and
Infrastructure servers all used this network.

Database Server Client Access: This network is exclusively used


3 10.0.3.0/24 Database VLAN Routable
for Database server VM machines.

Server Management: OVM Manager communicates with agents on


the physical OVS servers using this network.
Cluster Heartbeat: The Oracle Cluster File System heartbeat
occurs over this typically dedicated network between the OVS
servers within a physical server pool. This network is extremely
192.168.4.0/24 OVM Management
4 Non-Routable latency sensitive and should not be shared with other traffic when
VLAN
possible.
Live Migrate: This network is used for OVM Live Migrations of
running virtual machines from one OVS server to another within the
OVM server pool. Normally a dedicated network is used for this
purpose

Storage Network: This network was used to provide a high


performance storage network for the OVS servers. When possible
192.168.5.0/24 ZFS Storage VLAN for
5 Non-Routable this network should use TCP/IP ‘Jumbo’ frames, which uses a 9K
NFS
frame vs. the standard 1.5K frames. In the PoC we used 1.5K
frames

RAC Cluster Heartbeat: this network was used to provide a RAC


192.168.6.0/24 Database Heartbeat
6 Non-Routable cluster heartbeat between nodes and is latency sensitive; therefore
VLAN
it is a dedicated network.

PoC Network Topology of Oracle Sun X4-2 Servers and ZFS Storage
Figure 2 below illustrates the physical network topology used for the OVM based Hospitality Cloud PoC
infrastructure, and depicts the network types and usage described above in Table 1. The PoC had (1)
X4-2 for the OVM Manager, OVM Tools and a local My SQL database. The array of (15) X4-2 Servers
formed the compute node pool(s). An Active-Active ZFS-SA cluster provided the highly performant,
highly available NFS and iSCSI based storage environment used to define the OVM Storage
Repositories.

4 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Client Network, RAC-DB HB
NET2 – eth2 -> bond1
NET3 – eth3 -> bond1
VLANs: 901,903,904,905

Client Network – (1GigE)

OVM Manager – Configuration

PS PS
PS1 1 2 3
PCIe3 PCIe3 PCIe3
x16 x8 x8

100-10GbE

SER MGT
NET MGT
PS0

HOST NMI SP LNK/ACT NET 3 Spd LNK/ACT NET 2 Spd LNK/ACT NET 1 Spd LNK/ACT NET 0 Spd
STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

Management/Storage/HB/Live

Storage Network – 10GigE


HDD
MAP
12-23

0-11

Migration 4x 10GigE HDD


MAP
STORAGE
DE2-24P

Links
12-23

0-11

NET0 – eth0 -> bond0


SP FAN CPU MEM PS

TOP REAR

5 FILLER
SUN ZFS STORAGE
7420

4 FILLER

3 FILLER

2 FILLER

SATA 500GB
7200 RPM
1

NET1 – eth1 -> bond0

SATA 500GB
7200 RPM
0

SP FAN CPU MEM PS

TOP REAR

5 FILLER
SUN ZFS STORAGE
7420

4 FILLER

VLANs: 900,902
3 FILLER

2 FILLER

SATA 500GB
7200 RPM
1

SATA 500GB
7200 RPM
0

STORAGE
DE2-24P

ILOM Management Network Management/Storage/HB/LiveMigration/ – 1GbE HDD


MAP
12-23

4x 10GigE
0-11

STORAGE
DE2-24P

Links
HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD
MAP
12-23

0-11

STORAGE
DE2-24P

HDD

PS PS
MAP
12-23

0-11

PS1 1 2 3 STORAGE
DE2-24P

PCIe3 PCIe3 PCIe3


x16 x8 x8 HDD
MAP
12-23

0-11

PS PS 100-10GbE
PS1 1 2 3
SER MGT
NET MGT
PS0

PCIe3 PCIe3 PCIe3


x16 x8 x8

PS PS 100-10GbE
1 2 NET 3 NET 2 NET 1 NET
30
SER MGT
NET MGT

PS1 HOST NMI SP LNK/ACT Spd LNK/ACT Spd LNK/ACT Spd LNK/ACT Spd
PS0

PCIe3 PCIe3 PCIe3


x16 x8 x8

100-10GbE
HOST NMI SP LNK/ACT NET 3 Spd LNK/ACT NET 2 Spd LNK/ACT NET 1 Spd LNK/ACT NET 0 Spd
SER MGT
NET MGT
PS0

HOST NMI SP LNK/ACT NET 3 Spd LNK/ACT NET 2 Spd LNK/ACT NET 1 Spd LNK/ACT NET 0 Spd
Cloud Computing
ZS3-4
OVS Server – Configuration 15 X-Series Servers

Figure 2: OVM Network Topology

OVM Network Topology - A Logical View


Figure 3 below illustrates the logical network topology used for the OVM based Hospitality Cloud PoC
infrastructure, and depicts the network types and usage described above in Table 1. The PoC had (1)
X4-2 for the OVM Manager, OVM Tools and a local My SQL database. An array of (15) X4-2 Servers
formed the compute node OVS cluster pool(s). An Active-Active ZFS-SA cluster provided highly
performant, highly available NFS and iSCSI based storage resources used to define the OVM Storage
Repositories.

5 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Figure 3: Physical Network & VLANs used for Client and Management Access

Figure 4, shown below, illustrates the PoC network topology used in the OVS server pool created for
the migration effort. There are four physical 1/10 Gigabit Ethernet (GBE) link ports on the Sun X4-2 PoC
servers that were used (eth0 - eth3) on each OVS server to provide the various network connectivity
and services required, as described in Table 1 earlier. The 4 GBE link ports were used to first create
Virtual Interfaces (VIF) on each physical interface, the VIFs were then associated with unique VLANs to
create the two bonded network interfaces (bond0, bond1). VLAN groups were then assigned as
described earlier using the bonded interfaces. As shown below Net0 and Net1 forms bond0 for the
OVM Management network and for the storage network; VLANs 900 and 902 respectively. Net2 and
Net3 formed bond1 providing Client Access over VLAN 901 for the X4-2 OVM server client access
network, VLAN 903 for client application access to the guest VM network, VLAN 904 was used for the
guest VM Database server client access network, and VLAN 905 was utilized for the RAC Database VM
machines Cluster heat beat network.

6 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Figure 4: Network Link Bonds & VLANs established for the PoC Network Services

OVM Migration and Automation


While there are limited opportunities for automation in the discovery and assessment, and target build
phases; the actual migration process of converting the VMware image files offers the best opportunity
for automation. To facilitate a VMware to Oracle VM migration effort, Oracle Consulting has built and
packaged a number of scripts to perform the following migration tasks:

» Migrate OVA images to Assembly


» Covert Assembly to Template
» Generate VM Machines from the Template
» Template from Open Cloud repository
» Convert Open Cloud template to VM Machines

Automation Scripts

 OVA to Assembly
 Assembly to
Template
Exported VMware
 Template to VM
OVA images
 VM on OVM

7 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


Automation Scripts

 OVA to Assemble
 Assemble to
Template
Exported VMware  Template to VM
OVA images

MCS Microsoft Creation Services


KMS Key management Service
MAK Multiple Activation Key

Figure 5: Automation of VMware VM to OVM VM

Figure 5 above illustrates the actions that create VMware OVA images as inputs to the OVM
Assemblies, and subsequently used to create OVM VM Templates used to create the Oracle Linux and
Windows VMs utilized by the OPERA and SIMPHONY applications.

Conclusion
The Micros re-platforming project proved the viability of a structured and repeatable process for
migrating the Oracle-Micros Hospitality core application sets, from a VMware 5 Enterprise grade
environment of all non-Oracle hardware, to an Oracle Virtual Machine environment running on Oracle
hardware. The additional effort invested in automating key components of the overall migration process
resulted in the ability to scale the migration process, with a cost efficiency that accommodates the
migration of large enterprise landscapes of VMware infrastructures.

Oracle Corporation, World Headquarters Worldwide Inquiries


500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

8 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY


C ON N EC T W IT H U S

blogs.oracle.com/oracle
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
facebook.com/oracle warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
twitter.com/oracle formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.
oracle.com Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0615

VMware VM to Oracle Virtual Machine Migration – a case study


November 2015
Author: Prakash V. Menon
Contributing Authors: Dennis O’Neal

2 | MIGRATION FROM VMWARE TO ORACLE VM – A CASE STUDY