vmware vsphere virtual volumes paper /3 vmware vsphere virtual volumes executive summary business...

VMware vSphere Virtual

Volumes

A Game Changer for Business-Critical Oracle Databases

W H I T E P A P E R

W HIT E PA PE R / 1

VMware vSphere Virtual Volumes

Table of Contents

Table of Contents Executive Summary ......................................................................................................... 3

Business Case .............................................................................................................. 3

Common Concerns about Virtualizing Business-Critical Databases ................... 3

Solution Overview ........................................................................................................ 3

Key Results ................................................................................................................... 4

Audience ........................................................................................................................ 4

Consistent Backup and Crash Consistent Backup ..................................................... 5

Factors Affecting the Time Taken for Database Backup and Restore ................ 6

Operational Challenges with Database Backup and Restore ............................... 6

Database Cloning ......................................................................................................... 6

Operational Challenges with Database Cloning ...................................................... 6

Levels of Triggering Database Operations .............................................................. 6

Proposed Solution ........................................................................................................ 7

Introduction to vSphere Virtual Volumes ...................................................................... 8

Advantages of vSphere Virtual Volumes .................................................................. 8

Key Technical Elements of Virtual Volumes ............................................................ 9

Solution Use Cases ......................................................................................................... 9

Solution Configuration ................................................................................................. 9

SANBLaze VirtuaLUN Emulator with vSphere Virtual Volume ............................. 9

Oracle Database Server ............................................................................................ 10

Oracle Database Layout using vSphere Virtual Volumes .................................... 11

Use Case 1: Database Consistent Backup and Recovery by vSphere Virtual Volume Snapshot ....................................................................................................... 13

Database Consistent Backup ............................................................................... 13

Steps for Testing Database Consistent Backup and Recovery ...................... 13

Use Case Summary ............................................................................................... 17

Use Case 2: Database Crash Consistent Backup and Recovery by vSphere Virtual Volume Snapshot........................................................................................... 17

Crash Consistent Backup ..................................................................................... 17

Steps for Testing Database Crash Consistent Backup and Recovery .......... 17

Use Case Summary ............................................................................................... 20

W HIT E PA PE R / 2


Use Case 3: Database Cloning using VMware vSphere Virtual Volume Snapshot ...................................................................................................................... 20

Cloning a Database ............................................................................................... 20

Steps for Testing Database Cloning ................................................................... 20

Use Case Summary ............................................................................................... 23

Use Case 4: Database Virtual Machine Provisioning Leveraging vSphere Virtual Volume SPBM ................................................................................................ 23

Challenges with Traditional Storage ................................................................... 23

Advantages of vSphere Virtual Volume and SPBM .......................................... 23

Storage Policy Components ................................................................................. 24

Leveraging SPBM for Databases ........................................................................ 24

Use Case Summary ............................................................................................... 28

Conclusion ................................................................................................................... 28

References ...................................................................................................................... 29

White Paper................................................................................................................. 29

Product Documentation ............................................................................................. 29

About the Author and Contributors .............................................................................. 30

WHITE PAPER /3


Executive Summary

Business Case Business-critical databases are among the last workloads virtualized in most of the enterprises, primarily because of the challenges that they pose with growth and scale. Typically the low hanging fruits with respect to virtualization are the development, testing, staging databases after running a successful Proof of Concept (POC) and then finally the last bastion to conquer is the production databases.

When mission-critical databases are virtualized, there were additional layers of complexity added to the infrastructure making common operations like backup and recovery, cloning and other day-to-day activities difficult. The most efficient storage operations for mission-critical databases leverage the capabilities of the storage array by offloading the operations to the storage array.

Common Concerns about Virtualizing Business-Critical Databases There are many common concerns about virtualizing business-critical databases that inhibit and delay virtualization of these workloads:

Business-critical virtualized databases need to meet strict SLAs for performance and storage has traditionally been the slowest component.

Databases grow quickly, while at the same time there is a need to reduce their backup window and its impact on system performance.

There is a regular need to clone and refresh databases from production to QA and other environments. However, the size of the modern databases make it harder to clone and refresh data from production to other environments.

Databases of different levels of criticality need different storage performance characteristics and capabilities.

There is a never-ending debate between DBAs and systems administrators regarding filesystems versus raw devices and VMware vSphere® Virtual Machine File System (VMFS) versus Raw Device Mapping. These are primarily due to some of the deficiencies that existed in the past with virtualization.

Solution Overview VMware vSphere Virtual Volumes™ addresses the business challenges discussed in the previous section regarding business-critical databases’ day-to-day operations like backup and recovery, cloning, and database provisioning.

vSphere Virtual Volumes are designed to make storage more virtual machine aware and much simpler for virtualization administrators and storage professionals to implement and manage. vSphere Virtual Volumes are very useful for backup and recovery, cloning, enhanced Storage Policy-Based Management (SPBM) control and other operations for business-critical databases.

vSphere Virtual Volumes is an integration and management framework for external storage that provides finer control at the VM-level, streamlines storage operation and offers flexibility of choice.

Virtual Volumes implements the core tenets of the VMware Software-Defined Storage vision to enable a fundamentally more efficient operational model for storage in virtualized environments, centering it around the VM rather than on the physical infrastructure.

WHITE PAPER /4


Figure 1. Virtual Volumes Overview

Key Results The following highlights validate that vSphere Virtual Volumes:

Enables storage-level snapshots with VM granularity due to the fact that every VMDK is represented by an independent vSphere Virtual Volume.

Snapshots create a point-in-time copy of the vSphere Virtual Volume at the storage level, which can be used for database backup and recovery operations and database cloning activities.

Provides SPBM capability for automating provisioning of Oracle database Virtual Machines across different storage tiers.

SPBM provides VM-centric operations for VM storage provisioning and management.

Audience This white paper is intended for Oracle Database administrators, storage architects, and VMware administrators involved in planning, architecting, and administering a business-critical Oracle environment.

WHITE PAPER /5


Consistent Backup and Crash Consistent Backup A database consistent backup is taken with the database in a quiesced state. In a database consistent backup, all files in the database backup correspond to the same System Change Number (SCN).

When a restore is performed using this backup, a database recovery need to happen to make the database consistent at the time of the backup.

User-managed database backups is performed using one of the following methods:

Export and import / Data Pump—Exports are "logical" database backups in that they extract logical definitions and data from the database to a file.

Hot backup (quiesced) where the database is placed in a consistent mode before the backup is performed. For example, Oracle begin/end backup mode is leveraged for Oracle.

Cold backup where the database is completely shut down during the backup process.

Oracle-managed database backups is performed using the Recovery Manager (RMAN) utility:

Used for backing-up, restoring and recovering Oracle Databases.

Only backs up used space in the database as the biggest advantage.

RMAN does not put tablespaces in backup mode, saving on redo generation overhead. RMAN will re-read database blocks until it gets a consistent image of it.

Figure 2. Sample RMAN Architecture

A crash-consistent backup is the backup of a live database. A snapshot of the database is taken at any point-in-time without any special processing.

There are a few prerequisites for the database to be recoverable. The snapshots taken need to conform to the following requirements:

Integrated with database-vendor-recommended restore and recovery operations above

Database crash consistent at the point of the snapshot

Write ordering is preserved for each file within a snapshot

Refer to Oracle Document ID 604683.1 “Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies” for detailed information.

WHITE PAPER /6


Factors Affecting the Time Taken for Database Backup and Restore The different factors that affect the duration of database backups are:

Level of backup: The duration of the backup varies based on the backup level.

A full backup has to back up the entire database while incremental or cumulative backups leverage and backup only things that have changed since the previous backup.

Data churn: The amount of data that changes between backups impacts the duration of incremental and cumulative backups. The more the churn, the longer the backups

Backup mechanism: The mechanism used for backups impacts the duration. Backups can be tape or disk based, leverage compression and parallel streams. Some backups track block-level changes and backup only the blocks that have changed.

The backup mechanism can critically affect the backup duration and potentially affect the databases being backed up.

Underlying infrastructure: The network and storage infrastructure and the medium of backup can affect the duration. If the backups happen over the network and if the network is shared with application, there can be an adverse effect on backup and database performance.

SAN-based backups traditionally have minimal impact on the infrastructure.

Operational Challenges with Database Backup and Restore Production database backup and restore operations have strict SLA’s and requirements:

Small backup windows so as to have least impact on the database.

Need to be recoverable and repeatable.

There is a tremendous pressure on reducing and optimizing backup window while database storage continues to grow exponentially.

For multi-terabyte databases due to the restricted backup windows and the data churn, it is not feasible to make full backups of these multi-terabyte backups in the allotted backup windows.

Backups for large databases have traditionally been a challenge in virtual environments due to the additional layer of abstraction it introduces. Special provisions such as dedicated RDMs and storage-level snapshots have to be leveraged for efficient backups.

Database Cloning A database clone is a complete and separate copy of a database system that includes the business data, the DBMS software and any other application tiers that make up the environment.

Cloning is a different kind of operation with respect to replication and backups in that the cloned environment is both fully functional and separate in its own right. Additionally, the cloned environment may be modified at its inception due to configuration changes or data sub-setting.

Operational Challenges with Database Cloning The challenges of cloning multi-terabyte databases are the same as backing up multi-terabyte databases.

Levels of Triggering Database Operations Generally speaking, there are three levels from which regular database operations (such as database backup and restore, database cloning) can be triggered:

Application level

WHITE PAPER /7


VMware Virtual Machine level

Storage level

Each of the above approach has advantages and drawbacks:

Application level: Leveraging database backup applications such as Oracle RMAN and Oracle Data Pump to backup/clone the databases.

It provides a finer level of granularity (tablespace, datafile, and table) but it is not always the fastest.

VMware virtual machine level: Leveraging VMware Snapshots which is how most virtual machines are backed up even with third party backup applications.

It offers granularity at a Virtual Machine level which would be the ideal case. The only caveat being, a VM level snapshot may stun a VM for some time during snapshot coalescing/deletion (Refer VMware KB 1002836).

This may not be acceptable for Tier-1 business-critical databases. Removal of snapshots may impact the performance of the Database as the VMDKs are being consolidated.

Storage Array Level: Finally, operations at the Storage level offer better performance but its lacks Virtual Machine level granularity as operations are executed at storage LUN level.

If the database to be backed up has dedicated LUNS in the SAN, it can potentially be backed up at the SAN level with a storage level snapshot.

In case the database is sharing the datastore/LUN with other databases, the database can still be backed up using the Storage Level backup excepting that it will include VMDK’s of the other databases as well.

Typically for large database, DBA’s traditionally prefer triggering the above Database operations on either the Application level or Storage level for reasons mentioned above.

Proposed Solution An ideal solution to address all of the above challenges would be to combine the flexibility of achieving granularity at a virtual machine virtual disk level with the speed of the storage array for database operations such as backup and recovery, cloning, and provisioning a database virtual machine.

The solution should be able to trigger backups and clones with VMDK granularity at the same time.

Do a storage level snapshot or clone at the VM level, which is the fastest among all the three solutions.

The solution should be able to provide:

Operations like backup and restore and cloning, the flexibility to operate at a VMDK level granularity.

Capability to quickly take a storage level snapshot or clone, triggering the operations from a virtual machine level.

Capability of aligning different database components with different storage data services needed SPBM.

WHITE PAPER /8


Figure 3. Storage with Virtual Volumes

Introduction to vSphere Virtual Volumes vSphere Virtual Volumes deliver a new storage management and automation framework that can elegantly address these requirements today:

vSphere Virtual Volumes eliminate the need for a native file system. vSphere Virtual Volume Objects are natively represented on the storage array, mitigating any performance concerns and potentially eliminating the never-ending debate between database administrators and vSphere administrators.

Backups can be triggered at a virtual machine level with VMDK level granularity with the actual operation run natively by the array.

Regular DBA tasks such as database backup and restore, cloning, and database refresh of non-production databases from production takes less time.

Advantages of vSphere Virtual Volumes Finer control

With vSphere Virtual Volumes, it is much simpler to deliver and enable the right storage service levels according to the specific requirements of individual VMs. By having finer control over storage resources and data services down to the VM level, the VI administrator can create exact combinations and precisely deliver storage service levels. Overprovisioning is eliminated because each VM will consume the exact resources needed—nothing less and nothing more.

Streamlined storage operations

For both the VI Admin and the Storage Admin, Virtual Volumes greatly simplifies management over the existing operational model. Virtual Volumes allows separating the presentation from consumption of storage for VMs. In the VMware SDS model with vSphere Virtual Volumes, the storage administrator sets up the vSphere Virtual Volumes datastore, which defines the capacity and data services. The VI administrator then uses the capabilities available in the datastore to compose policies. Any service-level changes are reflected by simply changing policies. The storage administrator is responsible for the upfront setup, but the VI administrator is self-sufficient after that.

Flexibility of choice

vSphere Virtual Volumes is an industry-wide initiative that allows IT organizations to leverage the unique capabilities of their current storage investments and transition without disruption to a simpler and more efficient operational model. IT organizations can also manage heterogeneous storage using a common control plane.

WHITE PAPER /9


Key Technical Elements of Virtual Volumes Flexible consumption at the Logical Level

Virtual Volumes virtualizes SAN and NAS devices by abstracting physical hardware resources into logical pools of capacity (vSphere Virtual Volumes datastores) that can be more flexibly consumed and configured to span a portion of, one or several storage arrays. A vSphere Virtual Volumes datastore is a logical construct that can be configured on the fly, without disruption, and does not need to be formatted with a file system.

Native VM representation

Virtual Volumes defines a new virtual disk container (vSphere Virtual Volume) that is independent of the underlying physical storage representation. This virtual disk becomes the primary unit of data management, eliminating pre-allocated LUNs/Volumes. vSphere Virtual Volumes enables storage operations with VM granularity, leveraging native array-based data services and software-based data services.

Policy-driven automation

SPBM allows capturing storage service levels requirements (capacity, performance, and availability) in the form of logical templates (policies) to which VMs are associated. SPBM automates VM placement by identifying available datastores that meet policy requirements and coupled with vSphere Virtual Volumes, it dynamically instantiates necessary data services. Through policy enforcement, SPBM also automates service-level monitoring and compliance throughout the lifecycle of the VM. Policies that combine array capabilities and software-based data services, such as third-party caching and replication services enabled through integration with vSphere APIs for IO Filtering (VAIO), can also be created in SPBM.

Solution Use Cases Use case 1: Database consistent backup and recovery by vSphere Virtual Volume Snapshot

Use case 2: Database crash consistent backup and recovery by vSphere Virtual Volume Snapshot

Use case 3: Database cloning by vSphere Virtual Volume Snapshot

Use case 4: Database virtual machine provisioning leveraging vSphere Virtual Volume SPBM

Solution Configuration This solution uses the following key components:

VMware vSphere 6.0 including:


VMware vSphere API for Storage Awareness™

SANBLaze VirtuaLUN 7.3

Oracle Database 12c Enterprise Edition (12.1.0.2.0)

Oracle Enterprise Linux 6.6

SANBLaze VirtuaLUN Emulator with vSphere Virtual Volume This solution requires vSphere Virtual Volumes enabled storage. We leveraged SANBLaze VirtuaLUN 7.3 emulator as the backend storage emulator for the various used cases.

This emulator is vSphere Virtual Volumes enabled and is one of the first vSphere Virtual Volumes certified storage solutions available.

WHITE PAPER /10


Figure 4. SANBlaze Array for vSphere Virtual Volumes Testing

Oracle Database Server The key designs for the Oracle Single Instance Database virtual machine are:

An Oracle Single Instance Database 12c Enterprise Edition (12.1.0.2.0) was set up in a VMware virtual machine called ORACLE-VVOL.

The name of the database was VVOL12C.

The virtual machine had two vCPUs, 8GB of memory running Oracle Enterprise Linux 6.6.

The virtual machine VMDKs were placed on a SANBLaze VirtualLUN.

The virtual machine was hosted on a VMware vSphere 6 environment running on Dell POWEREDGE servers.

The Oracle VMDKs were placed on a vSphere datastore of Virtual Volume type called BCA_VVOL1.

VMware vCLI Package was installed on the Guest operating system in the VM. The vSphere Command-Line Interface (vSphere CLI) command set allows you to run common system administration commands against ESX or ESXi systems from any machine with network access to those systems.

See the Installing the vCLI Package on Red Hat Enterprise Linux topic for detailed information.

http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vcli.getstart.doc/cli_install.4.4.html?path=1_0_1_2_0

WHITE PAPER /11


Figure 5. VMware Infrastructure Details

Oracle Database Layout using vSphere Virtual Volumes The SANBlaze creates a SubLUN (refers to a vSphere Virtual Volume in the SANBlaze environment) for every VMDK of the Virtual Machine, so five SubLUNs were created for five VMDKs). There is one extra SubLUN for the VMware configuration file, so there were a total of six SubLUNs.

When the VM is powered on, in additions to the six SubLUNs, there is one extra SubLUN created for the VM swap file (.vswp file).

Table 1 lists the disk layout for the virtual machine. There was no storage tiering with the default tier used for the testing.

Disk Layout for Oracle Virtual Machine

V M

H AR D

D IS K

S CS I

CO N TR O L LE R

S T OR AG E

CO N T AINE R V M DK CO N T AINS S I ZE

Hard

Disk1

SCSI (0:0) BCA_VVOL1 [BCA_VVOL1]

naa.600110dac045c04501008000008000

00/Oracle-VVOL-000001.vmdk

/ (root file

system)

30GB

Hard

Disk2


naa.600110dac045c04501008000008000

00/Oracle-VVOL_1-000001.vmdk

/u01 (Oracle

Binaries)

30GB

Hard

Disk 3


naa.600110dac045c04501008000008000


+DATA

(ASM Disk

Group)

30GB

Hard

Disk 4


naa.600110dac045c04501008000008000


+FRA (ASM

Disk Group)

30GB

Hard

Disk 5


naa.600110dac045c04501008000008000


+REDO

(ASM Disk

Group)

30GB

WHITE PAPER /12


The subtlety lies in the way a VMFS datastore of type vSphere Virtual Volume is implemented comparing to a regular VMFS datastore.

A “df” command on the ESXi server will reveal that vSphere Virtual Volume datastores are implemented as a datastore of type “VVOL”:

[root@localhost:~] df

Filesystem Bytes Used Available Use% Mounted on

VMFS-5 3298266447872 2363283734528 934982713344 72% /vmfs/volumes/OEL_Clone3

.....

vfat 299712512 216350720 83361792 72% /vmfs/volumes/54a30a0c-

93caccba-8482-ecf4bbc08ee0

.....

VVOL 10737418240000 0 10737418240000 0% /vmfs/volumes/BCA_VVOL_GOLD

VVOL 21474836480000 0 21474836480000 0%

/vmfs/volumes/BCA_VVOL_SILVER

…

[root@localhost:~]

Unlike any regular VM files in the VM folder on a datastore where we can see the different –flat.vmdk files, with VMs on vSphere Virtual Volumes, the folder contents look as follows:

[root@localhost:/vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000] ls -l

-rw-r--r-- 1 root root 43 Jul 15 04:19 Oracle-VVOL-a59e28cb.hlog

-rw------- 1 root root 8684 Jul 15 17:09 Oracle-VVOL.nvram

-rw------- 1 root root 581 Jul 15 04:19 Oracle-VVOL.vmdk

-rw-r--r-- 1 root root 0 Jul 14 05:39 Oracle-VVOL.vmsd

-rwxr-xr-x 1 root root 3996 Jul 15 17:09 Oracle-VVOL.vmx

-rw------- 1 root root 3179 Jul 14 19:47 Oracle-VVOL.vmxf

-rw------- 1 root root 555 Jul 15 05:06 Oracle-VVOL_1.vmdk




-rw-r--r-- 1 root root 379606 Jul 15 04:18 vmware-1.log

-rw-r--r-- 1 root root 273649 Jul 15 17:09 vmware.log

[root@localhost:/vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000]

Notice the lack of—flat.vmdk’s as they exist on the storage vSphere Virtual Volume.

Logging into the SANBLaze console, each of the disks and the additional SubLUNs for the configuration and the vswp files are shown as follows:

[root@sanblaze1 ~]# grep SubLun /port0/alias0lun0 ; echo ; grep SubLun /port0/alias0lun0

| grep VMW_VVOLType | echo "Number of Subluns = " `wc -l`

SubLuns=1024

SubLun0=d28000000000,d2a000000000:600110dac045c0450100800000800000 0:4096 MB (0:8388608

blocks) -1 VMW_VVOLProfile=f4e5bade-15a2-4805-bf8e-

52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_VVOLName=Oracle-

VVOL;VMW_VVOLType=Config;VMW_VmID=501109af-235d-3c2a-c6d6-a11a096364a0

SubLun1=d28000010000,d2a000010000:600110dac045c0450100800000800001 4096:30720 MB

(8388608:62914560 blocks) -1 VMW_VVOLProfile=f4e5bade-15a2-4805-bf8e-

52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_GosType=oracleLinux6

4Guest;VMW_VVOLName=Oracle-

WHITE PAPER /13


VVOL.vmdk;VMW_VVOLNamespace=/vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVOLType=Data;VMW_VmID=501109a

f-235d-3c2a-c6d6-a11a096364a0;VMW_VVOLAllocationType=4

…………

……….

SubLun13=d280000d0000,d2a0000d0000:600110dac045c045010080000080000d 327680:8192 MB

(671088640:16777216 blocks) -1 VMW_VVOLProfile=7508ed62-e4a9-4cf1-9ef9-

fb1f07b72bc1:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_VVOLName=Oracle-

VVOL-a59e28cb.vswp;VMW_VVOLNamespace=/vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVOLType=Swap;VMW_VVOLAllocati

onType=3;VMW_GosType=oracleLinux64Guest;VMW_VmID=501109af-235d-3c2a-c6d6-a11a096364a0

…

Number of Subluns = 7

Use Case 1: Database Consistent Backup and Recovery by vSphere Virtual Volume Snapshot

Database Consistent Backup Oracle defines a database consistent backup as follows.

A database consistent backup is a whole database backup that you can open with the RESETLOGS option without performing media recovery. In other words, you do not need to apply redo to datafiles in this backup for consistency. All datafiles in a consistent backup must:

Have the same checkpoint system change number (SCN) in their headers, unless they are datafiles in tablespaces that are read-only or offline normal (in which case they will have a clean SCN that is earlier than the checkpoint SCN).

Contain no changes past the checkpoint SCN, that is, are not fuzzy.

Match the data file checkpoint information stored in the control file.

See Oracle Backup and Recovery Concept for more information.

You can only take consistent backups after you have made a clean shutdown or by turning on hot backup mode of the database.

This is the most trusted backup by DBAs but is also complex, as one needs to run scripts to put the database in hot backup mode, take a snapshot and then take the database out of the hot backup mode.

Steps for Testing Database Consistent Backup and Recovery The following steps were used for this testing:

1. A database consistent virtual machine snapshot was taken by using a script “hot backup”. This script places the database in backup mode, takes a VMware snapshot of the VM at the storage vSphere Virtual Volumes level using vCLI command and takes the database out of the backup mode after the snapshot is created.

The script (hot backup) is shown as follows:

#!/bin/bash export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1

echo "BEGIN backup mode : `date`"

sqlplus /nolog <<EOF

conn / as sysdba

alter database begin backup;

https://docs.oracle.com/cd/B10501_01/server.920/a96519/glossary.htm#432346

WHITE PAPER /14


exit;

EOF

echo ‘‘BEGIN Snapshot : `date`"

/usr/bin/vmware-cmd -H 10.152.100.5 -U "vmlab\administrator" -P VMware1! --

vihost 10.152.4.9 /vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000/Oracle-VVOL.vmx

createsnapshot Oracle-VVOL-DBC-Snapshot 'Oracle-VVOL-DBC-Snapshot' 0 0

echo "END Snapshot : `date`"

echo "END backup mode: `date`"


conn / as sysdba

alter database end backup;

EOF

2. A VMware-level snapshot was taken for the database virtual machine after putting the database in a hot

backup mode. The screenshot below shows the snapshot of the virtual machine with a running database.

Figure 6. Virtual Machine Snapshot for DB Consistent Oracle

WHITE PAPER /15


3. On completion of the snapshot, you can look at the volumes associated with the Oracle virtual machine.

When the virtual machine snapshot was taken, each SubLUN for the VMDKs had an additional copy that was created at the storage level. The number of SubLUNs increased from 7 to 12 as explained earlier (7 SubLUNs for the original VM plus 5 additional SubLUNs for the VMDKs):

[root@sanblaze1 ~]# grep SubLun /port0/alias0lun0 ; echo ; grep SubLun

/port0/alias0lun0 | grep VMW_VVOLType | echo "Number of Subluns = " `wc -l`

SubLuns=1024

........


(339738624:62914560 blocks) 1 VMW_VVOLProfile=f4e5bade-15a2-4805-bf8e-

52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_GosType=oracleLi

nux64Guest;VMW_VVOLName=Oracle-


41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVOLType=Data;VMW_VmID=501

109af-235d-3c2a-c6d6-

a11a096364a0;VMW_VVOLAllocationType=4;VMW_VVOLParentContainer=600110dac045c045-

41000000f3b02415





VVOL_1.vmdk;VMW_VVOLNamespace=/vmfs/volumes/VVOL:600110dac045c045-


109af-235d-3c2a-c6d6-


41000000f3b02415







109af-235d-3c2a-c6d6-


41000000f3b02415

……

Number of SubLuns = 12

4. A PowerCLI cloning script was then run to create a cloned DB Virtual machine from the DB consistent VMware snapshot. An alternative way of creating the clone is through the vCenter GUI:

PowerCLI C:\SBala> Connect-VIServer X.X.X.X

Name Port User

---- ---- ----

X.X.X.X 443 VMLAB\sudhirb

PowerCLI C:\SBala> . .\New-VMFromSnapshot.ps1

PowerCLI C:\SBala> New-VMFromSnapshot -SourceVM Oracle-VVOL -CloneName "Oracle-VVOL-

DBC-Clone" -SnapshotName "Oracle-VVOL-DBC-Snapshot" -Cluster "BCA VSAN" -Datastore

"BCA_VVOL1‘‘

Type Value

WHITE PAPER /16


---- -----

Task task-5584

PowerCLI C:\SBala>

5. Start up the cloned virtual machine.

6. Run a script against the database, which performs a media recovery of the database using the ‘recover database’ command. The recovery script is shown below:


echo "BEGIN DB Consistent Recovery : `date`"


conn / as sysdba

startup mount pfile=initVVOL12C.ora;

recover database ;

alter database open;

exit;

EOF

echo "END DB Consistent Recovery : `date`"

7. The database recovers successfully indicating that vSphere Virtual Volume-based snapshots can be

used for database consistent backup and recovery.

A snippet of the alert log of the database shown below displays the media recovery steps taken by the database:

tail --100 alert_VVOL12C.log :

Tue Jul 21 22:38:05 2015

ALTER DATABASE RECOVER database

Tue Jul 21 22:38:05 2015

Media Recovery Start

Started logmerger process

Tue Jul 21 22:38:06 2015

Parallel Media Recovery started with 2 slaves

Tue Jul 21 22:38:06 2015

NOTE: ASMB mounting group 3 (REDO_DG)

…….

NOTE: grp 3 disk 0: REDO_DISK01 path:ORCL:REDO_DISK01

Tue Jul 21 22:38:06 2015

Recovery of Online Redo Log: Thread 1 Group 1 Seq 53 Reading mem 0

Mem# 0: +REDO_DG/VVOL12C/group01_redo01.log


Tue Jul 21 22:38:06 2015

Tue Jul 21 22:38:06 2015

Media Recovery Complete (VVOL12C)

Completed: ALTER DATABASE RECOVER database

alter database open

Tue Jul 21 22:38:18 2015

WHITE PAPER /17


Use Case Summary This use case demonstrates that VMware Virtual Volumes (VVOLs) enables storage-level snapshots with VM granularity. This is due to the fact that every VMDK is represented by an independent vSphere Virtual Volume and snapshots create point-in-time volumes that can be used for backup and recovery.

We have shown successfully that business-critical Oracle databases can be backed up and recovered in a database consistent format with ease by leveraging VMware Virtual Volumes.

Use Case 2: Database Crash Consistent Backup and Recovery by vSphere Virtual Volume Snapshot

Crash Consistent Backup A crash consistent backup is the backup of a point-in-time image of an Oracle database that is equivalent to a database crash induced by a power outage, other failures, or a shutdown abort.

This is the most common backup method used for storage based backups and is fully supported by Oracle as long as the following conditions are met.

The third party vendor needs to guarantee and is held accountable that their snapshots conform to all the following requirements:

Integrated with Oracle's recommended restore and recovery operations

Database crash consistent at the point of the snapshot

Write ordering is preserved for each file within a snapshot

Refer to Oracle Document ID 604683.1 “Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies” for detailed information.

Steps for Testing Database Crash Consistent Backup and Recovery The following steps were used for this testing:

1. A crash consistent snapshot was taken of the database with no database level quiescing; for example, no begin backup/end backup mode.

#!/bin/bash

echo "BEGIN Snapshot Oracle-VVOL-DBC-Snapshot : `date`‘‘

/usr/bin/vmware-cmd -H 10.152.100.5 -U "vmlab\administrator" -P VMware1! --vihost

10.152.4.9 /vmfs/volumes/VVOL:600110dac045c045-

41000000f3b02415/naa.600110dac045c0450100800000800000/Oracle-VVOL.vmx createsnapshot

Oracle-VVOL-CRC-Snapshot 'Oracle-VVOL-CRC-Snapshot' 0 0

echo "END Snapshot : `date`"

WHITE PAPER /18


2. A VMware snapshot was taken of the virtual machine with the database in a crash consistent mode as shown in Figure 7.

Figure 7. Virtual Machine Snapshot of a Crash Consistent Oracle Database

3. On completion of the virtual machine snapshot, you can look at the volumes associated with the Oracle virtual machine.

When the snapshot was taken, each SubLUN for the VMDKs have an additional copy that was created at the storage level. The number of SubLUNs increased from 7 to 12 as explained earlier (7 SubLUNs for the original VM plus 5 additional SubLUNs for the VMDK’s snapshots):



SubLuns=1024

........







109af-235d-3c2a-c6d6-


41000000f3b02415







109af-235d-3c2a-c6d6-


WHITE PAPER /19


41000000f3b02415







109af-235d-3c2a-c6d6-


41000000f3b02415

……


4. A PowerCLI cloning script is then run to create a cloned DB Virtual machine from the Crash consistent VMware snapshot. An alternative way of creating the clone is through the vCenter GUI:

PowerCLI C:\SBala> Connect-VIServer X.X.X.X

Name Port User

---- ---- ----

X.X.X.X 443 VMLAB\SBalab

PowerCLI C:\SBala> . .\New-VMFromSnapshot.ps1

PowerCLI C:\SBala> New-VMFromSnapshot -SourceVM Oracle-VVOL -CloneName "Oracle-

VVOL-CRC-Clone" -SnapshotName "Oracle-VVOL-CRC-Snapshot" -Cluster "BCA VSAN" -Da

tastore "BCA_VVOL1"

Type Value

---- -----

Task task-5604

PowerCLI C:\SBala>


6. Start up the Oracle database, which automatically performs crash recovery on the instance startup:


echo

echo "BEGIN Crash Consistent Recovery : `date`"


conn / as sysdba

startup pfile=initVVOL12C.ora;

exit;

EOF

echo "END Crash Consistent Recovery : `date`"

WHITE PAPER /20


7. The database recovers successfully indicating that vSphere Virtual Volumes based snapshots can be used for crash consistent backup and recovery.

A snippet of the alert log of the database shown below displays the media recovery steps:

tail -100 alert_VVOL12C.log : ….

ALTER DATABASE OPEN

Ping without log force is disabled

Tue Jul 21 23:03:40 2015

Beginning crash recovery of 1 threads

parallel recovery started with 2 processes

Tue Jul 21 23:03:41 2015

Started redo scan

Tue Jul 21 23:03:41 2015

Completed redo scan

read 71 KB redo, 28 data blocks need recovery

Tue Jul 21 23:03:41 2015

Started redo application at

Thread 1: logseq 53, block 87281

Tue Jul 21 23:03:41 2015




Tue Jul 21 23:03:41 2015

Completed redo application of 0.01MB

Tue Jul 21 23:03:41 2015

Completed crash recovery at

Thread 1: logseq 53, block 87423, scn 1081078

28 data blocks read, 28 data blocks written, 71 redo k-bytes read

Use Case Summary This use case demonstrates that business-critical Oracle databases can be backed up and recovered in a database consistent format with ease by leveraging vSphere Virtual Volumes.

Use Case 3: Database Cloning using VMware vSphere Virtual Volume Snapshot

Cloning a Database A database clone is a complete and separate copy of a database system that includes the business data, the DBMS software and any other application tiers that make up the environment.

Steps for Testing Database Cloning 1. A VMware-level cloning operation is initiated to clone the running Oracle VM. This can be performed

through PowerCLI scripts or through the vCenter GUI.

WHITE PAPER /21


Figure 8. Cloning of an Oracle Database VM on vSphere Virtual Volume

2. The cloning operation uses a point-in-time snapshot of the database virtual machine in a crash consistent state and makes a copy.

3. On completion of the clone, you can look at the volumes associated with the Oracle virtual machine. The number of SubLUNs increased from 7 to 14 as explained earlier (7 SubLUNs for the original VM plus 7 additional SubLUNs for the cloned VM). This clearly showed that the actual cloning happen at the storage level when vSphere Virtual Volume was leveraged.



SubLuns=1024

........







109af-235d-3c2a-c6d6-


41000000f3b02415







109af-235d-3c2a-c6d6-


41000000f3b02415



WHITE PAPER /22






109af-235d-3c2a-c6d6-


41000000f3b02415

……



5. Start up the Oracle database, which automatically performs the crash recovery on the instance startup.

#!/bin/bash

export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1

echo

echo "BEGIN Crash Consistent Recovery : `date`"


conn / as sysdba

startup pfile=initVVOL12C.ora;

exit;

EOF

echo "END Crash Consistent Recovery : `date`"

6. The database recovers successfully indicating that vSphere Virtual Volume based cloning can simplify

database cloning and refresh operations.

A snippet of the alert log of the database shown below displays the media recovery steps:

tail -100 alert_VVOL12C.log :

….

ALTER DATABASE OPEN

Ping without log force is disabled

Tue Jul 21 23:03:40 2015

Beginning crash recovery of 1 threads

parallel recovery started with 2 processes

Tue Jul 21 23:03:41 2015

Started redo scan

Tue Jul 21 23:03:41 2015

Completed redo scan

read 71 KB redo, 28 data blocks need recovery

Tue Jul 21 23:03:41 2015

Started redo application at

Thread 1: logseq 53, block 87281

Tue Jul 21 23:03:41 2015




Tue Jul 21 23:03:41 2015

Completed redo application of 0.01MB

Tue Jul 21 23:03:41 2015

WHITE PAPER /23


Completed crash recovery at

Thread 1: logseq 53, block 87423, scn 1081078

28 data blocks read, 28 data blocks written, 71 redo k-bytes read

Use Case Summary This use case demonstrates successfully that business-critical Oracle databases can be cloned with ease by leveraging vSphere Virtual Volumes.

Use Case 4: Database Virtual Machine Provisioning Leveraging vSphere Virtual Volume SPBM

Challenges with Traditional Storage The major challenge with traditional storage architectures is a misalignment between what the storage consumer wants and the capabilities that are actually provided. This results in inefficiencies through the over provisioning of storage resources. There is a strong need to provide alignment between application needs and storage resources.

Advantages of vSphere Virtual Volume and SPBM For both the virtual infrastructure administrator and storage administrator, vSphere Virtual Volumes greatly simplifies management and reduces dependencies over the existing operational model.

The storage administrator sets up the vSphere Virtual Volumes datastore. The capacity and data services published by the storage administrator for the vSphere Virtual Volumes datastore become simple menu items from which the virtual infrastructure administrator can select on demand when creating a VM policy.

The storage administrator retains control of the storage resources, as the virtual infrastructure administrator can only consume published capabilities. However, the virtual infrastructure administrator can now determine which data services should be assigned to a VM by selecting the appropriate policy during VM creation. Thus, the storage administrator is responsible for upfront setup, but the virtual infrastructure administrator is self-sufficient afterwards.

Figure 9. SPBM and vSphere Virtual Volumes

WHITE PAPER /24


With vSphere Virtual Volumes, the virtual infrastructure administrator gains control and becomes responsible for defining the various storage classes of service for VMs. By associating one or many VMs to the right policy, the provisioning and instantiation of storage service levels is automated for that VM or set of VMs.

Automated policy enforcement also becomes the mechanism to simplify the monitoring process and to ensure compliance of storage service levels throughout the lifecycle of the application.

Policy-driven automation enables more agile storage consumption for VMs, which ultimately delivers faster provisioning for new applications with different requirements and simplifies change management, as the virtual infrastructure administrator no longer depends on the storage administrator to fulfill infrastructure change requests. Policies that combine array capabilities and software-based data services, such as third-party caching and replication services enabled through integration with vSphere APIs for IO Filtering (VAIO), can also be created in SPBM.

Storage Policy Components Virtual machine storage policies, are an evolution of virtual machine storage profiles, and used to ensure that virtual machines are placed on storage that guarantees a specific level of capacity, performance, availability, redundancy, and so on.

When you define a storage policy, you specify storage requirements for applications that would run on virtual machines. After you apply this storage policy to a virtual machine, the virtual machine is placed to a specific datastore that can satisfy the storage requirements.

vSphere storage policies are made up of three primary components:

References to storage provider’s storage capabilities

Rules [key value pair: storage capability + (value for quantity or quality)]

Rule sets

Leveraging SPBM for Databases Databases can have varying storage requirements based on their function. SPBM can help the virtual admin use policies to match these requirements with the capabilities of the storage.

Figure 10. SPBM Maps Storage Capabilities of the Underlying Array

WHITE PAPER /25


We will look at an example of how these policies can be leveraged to create different tiers of storage with unique characteristics. The policies are used to create Gold, Silver, and Bronze example storage tiers as shown in Figure 11.

Figure 11. Gold, Silver, and Bronze Storage Tiers

Gold, Silver, and Bronze protocol endpoint containers are created as shown in Figure 12.

Figure 12. Storage Performance Profile

WHITE PAPER /26


In the next step, actual Storage LUNS making up the different tiers are identified. Datastores are then created for backend LUNS for each of these tiers would meet the appropriate capabilities advertised.

Figure 13. Datastores for Different Tiers Identified

The capability sets of the vSphere Virtual Volumes datastores are defined to match that of the storage.

Figure 14. Define Capability Sets of the vSphere Virtual Volumes Datastores

Capabilities of the Different Datastores

Storage policies are now defined for the three tiers. The policies are made up of multiple rules that map to storage capabilities.

WHITE PAPER /27


Figure 15. Defining Storage Policies

The defined storage policies can now be used by the virtual infrastructure administrator to match the requirements of the database to the storage capabilities. These policies can be applied individually to existing virtual machines and when deploying new virtual machines from templates.

Figure 16. Applying Storage Policy to a Database Server Deployed from Template

WHITE PAPER /28


Use Case Summary This use case demonstrates that vSphere Virtual Volumes provides SPBM capability for automating provisioning of Oracle database virtual machines, which can be used for creating different storage tiers for business critical databases.

Conclusion The use cases demonstrate that vSphere Virtual Volume enables storage-level snapshots with VM granularity. Every VMDK is represented by an independent virtual volume and snapshots create a point-in-time copy of the volume that can be used for backup, recovery, and cloning activities.

VMware VVOLs also provides Storage Policy Based Management capability for automating provisioning of Oracle database Virtual Machines which can be used for creating different storage tiers for business critical databases.

We have seen through SPBM concepts and examples how a VI administrator can be empowered to match database requirements with the capabilities of the storage. Leveraging vSphere Virtual Volume and SPBM enables software-defined storage to efficiently manage storage requirements for databases. SPBM provides VM-centric operations for VM storage provisioning and management.

To use vSphere Virtual Volume storage, you need vSphere 6.0 or later and certified array vendor vSphere Virtual Volumes software (APIs for Storage Awareness Provider).

WHITE PAPER /29


References

White Paper For additional information, see the following white papers:

FAQ on VMware vSphere Virtual Volumes

VMware vSphere Virtual Volumes: Getting Started Guide

What’s New: vSphere Virtual Volumes

VMware Knowledge Base: VMware Virtual Volumes (VVols) interoperability with other vSphere products and features (2112039)

Product Documentation For additional information, see the following product documentation:


vSphere Storage Policy Based Management

Oracle Backup and Recovery Concept

https://www.vmware.com/files/pdf/products/virtualvolumes/VMware_Virtual_Volumes_FAQ.pdf

https://www.vmware.com/files/pdf/products/virtualvolumes/vmw-vsphere-virtual-volumes-getting-started-guide.pdf

https://www.vmware.com/files/pdf/products/virtualvolumes/VMware-Whats-New-vSphere-Virtual-Volumes.pdf

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2112039

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2112039

https://www.vmware.com/products/vsphere/features/virtual-volumes

http://blogs.vmware.com/vsphere/2014/09/storage-policy-based-management-overview.html

https://docs.oracle.com/cd/B10501_01/server.920/a96519/glossary.htm#432346


VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Copyright © 2016 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective

companies.

About the Author and Contributors Sudhir Balasubramanian, Senior Solution Architect in the Global Technical and Professional Services team, specializes on the virtualization of Oracle business-critical applications. He has more than 20 years’ experience in IT infrastructure and database working as the Principal Oracle DBA and Architect for large enterprises focusing on Oracle, EMC storage, and Unix/Linux technologies.

Sudhir holds a Master Degree in Computer Science from San Diego State University. Sudhir is one of the authors of “Virtualize Oracle Business Critical Databases” book, which is a comprehensive authority for Oracle DBA’s on the subject of Oracle and Linux on vSphere. Sudhir is a VMware vExpert.

Mohan Potheri is currently a Senior Solutions Architect for VMware Technical Marketing focusing on virtualization of business-critical applications. He has more than 20 years’ experience in IT infrastructure with VMware virtualization, enterprise UNIX, and business-critical applications. He has extensive knowledge with virtualizing SAP with Oracle backend databases in Linux and UNIX environments. Mohan has worked at many large enterprises where he had engineered highly performing and available infrastructures for business-critical applications. Mohan is a CISSP and is VCDX#98. Mohan holds a Master Degree in Electrical Engineering and Business Administration from the University of Houston.

We would also like to thank Michael Haig, Juan Novella, and Ken Werneburg for their support and help.

We would also like to thank the SANBlaze team for their support and help during the project.

vmware vsphere virtual volumes paper /3 vmware vsphere virtual volumes executive summary business...

Documents