DRS

Introducing DRS DumpInsight

In an effort to provide a more insightful user experience and to help understand how vSphereDRS works, we recently released a fling:DRS Dump Insight.

DRS Dump Insight is a service portal where users can upload drmdump files and it provides a summary of the DRS run, with a breakup of all the possible moves along with the changes in ESX hosts resource consumption before and after DRS run.

Users can get answers to questions like:

  • Why did DRS make a certain recommendation?
  • Why is DRS not making any recommendations to balance my cluster?
  • What recommendations did DRS drop due to cost/benefit analysis?
  • Can I get all the recommendations made by DRS?

Once the drmdump file is uploaded, the portal provides a summary of all the possible vMotion choices DRS went through before coming up with the final recommendations.

The portal also enables users to do What-If analysis on their DRS clusters with options like:

  • Changing DRS Migration Threshold
  • Dropping affinity/anti-affinity rules in the cluster
  • Changing DRS advanced options

 

The post Introducing DRS DumpInsight appeared first on VMware VROOM! Blog.

Read more..

DRS Lens – A new UI dashboard for DRS

DRS Lens provides an alternative UI for a DRS enabled cluster. It gives a simple, yet powerful interface to monitor the cluster real time and provide useful analyses to the users. TheUI is comprised ofdifferent dashboards in the form of tabs for each cluster being monitored.

Cluster Balance

Dashboardshowing the variations in the cluster balance metric plotted over time with DRS runs. This shows how DRS reacts to and tries to clear cluster imbalance every time it runs.

VM Happiness

This dashboard shows VM happiness for the first time in a UI. This chart shows the summary of total VMs in the cluster that are happy and those that are unhappy based on the user defined thresholds. Users can then select individual VMs to view performance metrics related to its happiness, like CPU ready time and memory swapIn rate.

vMotions

This dashboard provides a summary of vMotions that happened in the cluster over time. For each DRS run period, there will be a breakdown of vMotions as DRS-initiated and user-initiated. This helps users see how actively DRS has been working to resolve cluster imbalance. It also helps to see if there are vMotions outside of DRS control, which may be affecting cluster balance.

Operations

This dashboard tracks different operations (tasks, in vCenter Server) that happened in the cluster, over time. Users can correlate information about tasks from this dashboard against DRS load balancing and its effects from the other dashboards.

 

Users can download DRS Lens from VMware flings website.

The post DRS Lens - A new UI dashboard for DRS appeared first on VMware VROOM! Blog.

Read more..

Spotlight on the New DRS Groups and VM-Host Rule Cmdlets!

We&#rsquo;re kicking off the first in a series of blog posts taking an in-depth look at some of the new cmdlets that were made available with the PowerCLI 6.5.1 release. This first post is going to be covering the cmdlets targeted at managing DRS groups and their associated rules.

These new cmdlets are as follows:

  • Get-DrsClusterGroup
  • New-DrsClusterGroup
  • Set-DrsClusterGroup
  • Remove-DrsClusterGroup
  • Get-DrsVMHostRule
  • New-DrsVMHostRule
  • Set-DrsVMHostRule
  • Remove-DrsVMHostRule

If you&#rsquo;ve never used DRS groups and DRS affinity rules or don&#rsquo;t know what they are, these are a way to control which VMs are able to exist on which hosts. This control is leveraged through either affinity or anti-affinity rules that are configured at the cluster level. These rules are configured between groupings of VMs and groupings of hosts. These rules also have types, which basically describes how the enforcement should work. The types are: Must Run On, Should Run On, Must Not Run On, Should Not Run On

Please see the documentation for more information about: DRS Affinity Rules

Taking A Closer Look – A Use Case Demonstration

We have been given a lab environment and our end result is to have the even numbered App VMs run on the even numbered hosts whenever possible, and likewise with the odd numbered VMs and hosts.

First, a look at the lab environment:

  • 1 Cluster
  • 4 Hosts
  • 50 VMs

We&#rsquo;ll start by taking a look at the DRS Cluster Group cmdlets. These are used in order to create, manage, and remove VM and host based DRS groups. These cluster groups are then referenced by the DRS VM-Host affinity rules, which we&#rsquo;ll discuss in a bit.

Let&#rsquo;s create the first host DRS group, which will be for the odd numbered hosts. This can be done with the &#lsquo;New-DrsClusterGroup&#rsquo; cmdlet while specifying a name, the cluster, and the desired hosts. A command for our sample environment looks like this:

New-DrsClusterGroup -Name HostsOdd -Cluster Demo -VMHost esx01.corp.local,esx03.corp.local

We&#rsquo;ll repeat a similar process for the even hosts, only this time we&#rsquo;ll store the cluster and desired hosts in their own variables:

We now have the required host DRS groups, so we can move forward and create the VM DRS groups. These are created with the same &#lsquo;New-DrsClusterGroup&#rsquo; cmdlet, except we&#rsquo;ll now use the VM parameter and specify the VMs for each group.

Starting again with our odd numbered VMs, we&#rsquo;ll use the following command:

New-DrsClusterGroup -Name VMsOdd -Cluster $cluster -VM app01,app03,app05

If you&#rsquo;ll notice, that&#rsquo;s nowhere close to all of the necessary odd numbered VMs. We&#rsquo;ll now make use of the &#lsquo;Set-DrsClusterGroup&#rsquo; cmdlet to add the remaining VMs (which I&#rsquo;ve already stored into a variable). This cmdlet also requires usage of either the &#lsquo;Add&#rsquo; or &#lsquo;Remove&#rsquo; parameter in order to specify what kind of modification is being requested.

The command to add the remaining odd system should be similar to the following:

Set-DrsClusterGroup -DrsClusterGroup VMsOdd -VM $VMsOdd –Add

We&#rsquo;ll repeat a similar process for the even VMs’ DRS group:

Before moving on to creating the VM-Host affinity rules, let&#rsquo;s review the DRS groups we&#rsquo;ve created to this point with the &#lsquo;Get-DrsClusterGroup&#rsquo; cmdlet.

This cmdlet also has a couple parameters to help gain additional information. The &#lsquo;Type&#rsquo; parameter can be used to specify whether to return VM groups or host groups. The &#lsquo;VM&#rsquo; and &#lsquo;VMHost&#rsquo; parameters can be used to only return DRS groups belonging to that VM or host.

Some examples of these parameters in use:

Moving on to the creation of the rules… We&#rsquo;ll be using the &#lsquo;New-DrsVMHostRule&#rsquo; cmdlet along with several parameters. These parameters will be &#lsquo;Name&#rsquo;, &#lsquo;Cluster&#rsquo;, &#lsquo;VMGroup&#rsquo;, &#lsquo;VMHostGroup&#rsquo;, and &#lsquo;Type&#rsquo;. Most of those should be self-explanatory, but &#lsquo;Type&#rsquo; may not be. Thanks to tab complete, we&#rsquo;ll see that the type options are &#lsquo;MustRunOn&#rsquo;, &#lsquo;ShouldRunOn&#rsquo;, &#lsquo;MustNotRunOn&#rsquo;, and &#lsquo;ShouldNotRunOn&#rsquo; and apply to how the rule is enforced against the cluster.

Remembering that our goal is to have the even VMs run on the even hosts whenever possible, we&#rsquo;ll issue the following command:

New-DrsVMHostRule -Name 'EvenVMsToEvenHosts' -Cluster $cluster -VMGroup VMsEven -VMHostGroup HostsEven -Type ShouldRunOn

We&#rsquo;ll do a similar command for the odd rule:

Our objective should be complete and we can verify that by using the &#lsquo;Get-DrsVMHostRule&#rsquo; cmdlet. The output should be similar to the following:

These VM-Host rules can also be modified once they&#rsquo;ve created with the &#lsquo;Set-DrsVMHostRule&#rsquo; cmdlet. This cmdlet has the ability to rename the rule, enable or disable it, and modify either the VMGroup and/or the VMHostGroup.

The rules can easily be disabled using the following command:

Get-DrsVMHostRule | Set-DrsVMHostRule -Enabled $false

This environment happens to be a lab, so before wrapping up this post we should probably clean it up. We can do this while utilizing the &#lsquo;Remove-DrsClusterGroup&#rsquo; and &#lsquo;Remove-DrsVMHostRule&#rsquo; cmdlets. The commands could look like the following:

Remove-DrsVMHostRule -Rule EvenVMsToEvenHosts,OddVMsToOddHostsGet-DrsClusterGroup | Remove-DrsClusterGroup

Summary

These eight new cmdlets are a terrific addition to the PowerCLI 6.5.1 release. They are also a great compliment to the already existing DRS cmdlets! Start using them today and let us know your feedback!

The post Spotlight on the New DRS Groups and VM-Host Rule Cmdlets! appeared first on VMware PowerCLI Blog.

Read more..

Oracle on VMware vSAN – Dispelling the Licensing myths

Introduction to VMware vSphere & vSAN

Some key things to keep in mind when we talk about VMware vSphere Platform , ESXi hypervisor and vSAN:

  • VMware vSphere is a platform of virtualized hardware that creates a total abstraction layer between the O/S and the Hardware
  • ESXi, is a non-Para virtualized, Type1 hypervisor and therefore makes no changes to the kernel of the guest operating system
  • VMware vSAN , the industry-leading software powering Hyper-Converged Infrastructure solution, in no way changes the location of where compute runs, and hence does not directly impact the licensing impact of any CPU Core or Socket based licensing

Oracle Licensing Myths

There are myths floating around that

  • Oracle Licensing requires licensing every vSphere host attached to a given vCenter
  • Oracle licensing requires licensing every Site connected to the Primary site where the Oracle workloads primarily resides

These myths are perpetuated by overzealous licensing and sales teams which is in contrast of the reality of the actual Contractually Impactful documents.

If this were true , it would require you to license EVERY existing vSphere host in EVERY datacenter and cloud , be that yours or a company down the street as vCenter&#rsquo;s and SSO domains are not an obstacle to vMotion. and So by this faulty logic you would need to license every host in the galaxy.

That faulty logic would cost you many $$$ , probably buy you a beautiful island

 

This post intends to clear up the reality of how to effectively license Oracle workload on VMware vSphere & vSAN and to make it a cost effective one as well.

Oracle Licensing on VMware vSphere

Oracle Licensing on VMware sessions have been run successfully in many Trade shows / Events ( notably IOUG, EMC World, VMworld ) , also Webinars, where it has been proved beyond any doubt , that there are only there are only 3 documents which are contractual and relevant for any Oracle licensing discussion and contractual:

  • Technical Support Policy
  • Processor Core Factor Table
  • Oracle License and Service Agreement (OLSA) / Oracle Master Agreement(OMA)
    • The OLSA/OMA defines Processor as &#rsquo;Processor: shall be defined as all processors where the Oracle programs are installed and/or running.&#rdquo;

Thanks to numerous collateral and efforts by our premier partners notably House of Bricks and License Consulting , we are able to dismiss the ridiculous claim by Oracle Sales about licensing &#rsquo;All Sites&#rdquo; or &#rsquo;Galaxy licensing&#rdquo; as we call it , when it comes to licensing Oracle on VMware.

Anyone who has read the Oracle licensing document, most important, the OLSA / OMA, is well aware that Oracle licenses are either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based.

More information about it can be found in the below documents:

SOFTWARE INVESTMENT GUIDE
http://www.oracle.com/us/corporate/pricing/sig-070616.pdf

Database Licensing
http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf

Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, its either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based.

So you do not need any memory segmentation, storage segmentation or for that matter any network segmentation based on the above.

Keep in mind none of these segmentation requirements are stipulated in the OLSA/OMA which is a contractual document.

The illustration below of an &#rsquo;Oracle Parking Garage&#rdquo; from House of Bricks sums up the FUD!!!

 

The Oracle Parking Garage

Example of Licensing Oracle workloads on classic VMware vSphere Cluster

For example, let&#rsquo;s say we have a vSphere Cluster dedicated to run Oracle workloads called &#rsquo;OraCluster&#rdquo; with 3 ESXi servers, each ESXi server having 2 socket x 10 cores each.The processor is Intel Family.

Total no of effective cores for licensing Oracle workloads in &#rsquo;OraCluster&#rdquo; using Enterprise Edition (EE)
= Absolute number of cores in cluster * Processor Core Factor
= 3 servers * 2 sockets * 10 cores/socket * Processor Core Factor
= 60 * 0.5
= 30 Effective cores liable for Oracle licensing

The Processor Core factor table is published by Oracle and can be found at the below url:

http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf

VMware vSAN

It should be known that running vSAN In no way impacts Oracle licensing and existing tools of segmentation (DRS affinity groups and rules) and existing auditing tools (VMware LogInsight) perform as expected.

vSAN 6.5 is the fifth generation of VMware&#rsquo;s industry-leading software powering Hyper-Converged Infrastructure solutions. vSAN&#rsquo;s unique in-kernel architecture delivers flash-optimized performance and elastically scalable storage for any virtualized application, with TCO savings of up to 50%.

 

Running Oracle workloads on VMware vSAN (Hybrid/All Flash)
As part of the effort to validate VMware Virtual SAN ability to host business critical applications we have published a reference architecture (RA) which covers the design, configuration and performance study of Oracle Real Application Clusters (RAC) on Virtual SAN Hybrid 6.1.

Oracle Real Application Clusters on VMware Virtual SAN

With VMware All Flash Virtual SAN 6.2, we introduced a suite of new features for data integrity and space efficiency including Checksum, Erasure Coding, Deduplication and Compression.

Using these features we developed an architecture for deploying and running Oracle 12c OLTP and DSS workloads on VMware All Flash Virtual SAN 6.2.

Oracle 12c OLTP & DSS workloads on Virtual SAN 6.2 All Flash

 

Licensing Oracle workloads on VMware vSAN (Hybrid/All Flash)

Oracle licensing DOES NOT change from a licensing perspective, whether you run Oracle workloads on a classic vSphere environment or Hyper-Converged Infrastructure solution like vSAN.

Oracle VM uses the compute power of the ESXi servers in the vSAN Cluster to run the Oracle workload just as in the case of a Classic vSphere Cluster.

As pointed our earlier, Oracle licenses are either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based regardless of whether Oracle workloads run on ESXI servers in a vSAN cluster OR vSphere cluster.

In the example below, we have a vSAN cluster called &#rsquo;vSANCluster&#rdquo; comprising of 4 ESXi servers contributing Compute, Storage & Network resources to the cluster.

Each ESXi server has 2 socket x 16 cores as shown below. The processor is Intel Family.

Oracle VM&#rsquo;s created can be pinned using CPU Affinity to a set of ESXi servers in the &#rsquo;vSANCluster&#rdquo; for Oracle licensing reasons.

Let&#rsquo;s see how we can go about doing it.

Create a VM/Host Group mapping as shown below. In the example below, &#rsquo;OracleVM&#rdquo; is the group created which has a VM &#rsquo;testoravm&#rdquo;. There is a 1:1 mapping between the &#rsquo;OracleVM&#rdquo; group and &#rsquo;testoravm&#rdquo; VM.

Create a new Host Group &#rsquo;OracleVM-Host&#rdquo; as shown below. Hosts w2-pe-vsan-esx-029.eng.vmware.com and w2-pe-vsan-esx-030.eng.vmware.com are part of this host group.

Create new VM/Host rules as shown below which basically will have the VM group &#rsquo;OracleVM&#rdquo; created above (with the &#rsquo;testoravm&#rdquo; VM in the group) mapped to the Host Group &#rsquo;OracleVM-Host&#rdquo; with a &#rsquo;must run on hosts in group&#rdquo;.

In effect, the Oracle VM &#rsquo;testoravm&#rdquo; is now constricted and contained to run in the Compute Segmentation effectively created above.

In the example above, to run Oracle workloads in the above scenario:

Total no of effective cores for licensing Oracle workloads on 2 ESXi servers in the vSAN Cluster above using Enterprise Edition (EE)
= Absolute number of cores in cluster * Processor Core Factor
= 2 servers * 2 sockets * 16 cores/socket * Processor Core Factor
= 64 * 0.5
= 32 Effective cores liable for Oracle licensing

As we can see from the above example, we only need to license 2 ESXI servers for Oracle workloads as Oracle workloads runs only 2 ESXI servers, regardless of the size of the vSAN Cluster.

The ultimate proof of the above statement comes from the Oracle OLSA/OMA which defines Processor as &#rsquo;Processor: shall be defined as all processors where the Oracle programs are installed and/or running.&#rdquo;

From the example above Oracle VM &#rsquo;testoravm&#rdquo; can run only on hosts w2-pe-vsan-esx-029.eng.vmware.com and w2-pe-vsan-esx-030.eng.vmware.com based on the DRS Affinity Rules.

Virtual Machine log file

The second important artifact which helps to prove without any doubt that the Oracle VM &#rsquo;testoravm&#rdquo; ran on only 2 ESXI servers is via audit trail in the Virtual Machine log file.

By default, ESXi/ESX hosts store virtual machine-specific logging in the same directory as the virtual machine’s configuration files. The default log file name is vmware.log.

Let&#rsquo;s see the contents of the vmware.log file for &#rsquo;testoravm&#rdquo; when we power it up.

[root@w2-pe-vsan-esx-029:/vmfs/volumes/vsan:52803547e520f694-1f6104395ada7b7c/05735458-cc86-e1e9-ca71-0025b501004e] cat vmware.log
2016-12-27T21:09:09.124Z| vmx| I125: Log for VMware ESX pid=2597049 version=6.5.0 build=build-4564106 option=Release
2016-12-27T21:09:09.124Z| vmx| I125: The process is 64-bit.
2016-12-27T21:09:09.124Z| vmx| I125: Host codepage=UTF-8 encoding=UTF-8
2016-12-27T21:09:09.124Z| vmx| I125: Host is VMkernel 6.5.0
2016-12-27T21:09:09.091Z| vmx| I125: VTHREAD initialize main thread 0 “vmx” tid 2597049
2016-12-27T21:09:09.092Z| vmx| I125: Msg_SetLocaleEx: HostLocale=UTF-8 UserLocale=NULL
……….
……….
2016-12-27T21:09:09.124Z| vmx| I125: Hostname=w2-pe-vsan-esx-029
2016-12-27T21:09:09.124Z| vmx| I125: IP=127.0.0.1 (lo0)
…..
[root@w2-pe-vsan-esx-029:/vmfs/volumes/vsan:52803547e520f694-1f6104395ada7b7c/05735458-cc86-e1e9-ca71-0025b501004e]

Based on the DRS Affinity rules, &#rsquo;testoravm&#rdquo; can only power on ESXi servers w2-pe-vsan-esx-029 or w2-pe-vsan-esx-030.

More information about the vmware.log files can be found in the below KB articles:

Locating virtual machine log files on an ESXi/ESX host (1007805)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007805

Location of log files for VMware products (1021806)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021806

Another product from VMware which helps for purpose of Oracle Auditing is the VMware vRealize Log Insight which delivers heterogeneous and highly scalable log management with intuitive, actionable dashboards, sophisticated analytics and broad third-party extensibility. It provides deep operational visibility and faster troubleshooting across physical, virtual and cloud environments.

VMware LogInsight dashboard can help customers gather by means of audit trail records which can then be presented to Oracle LMS team as proof of Oracle workload footprint within a vSphere Cluster or a vSAN cluster.

The video below demonstrates the capabilities of VMware vRealize LogInsight for Oracle License Compliance:
https://www.youtube.com/watch?v=EHcT4xDyONc

An important factor to keep in mind is vSAN’s in kernel design reduces the need for compute sprawl and hence more Oracle licensing as compared to some of the other competitor products found in the market.

Conclusion

In conclusion, Oracle licensing does not change from a licensing perspective, whether you run Oracle workloads on a classic vSphere environment or Hyper-Converged Infrastructure solution like vSAN. Keep in mind, Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, its either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition).

To reiterate, there are only 3 documents which are contractual and relevant for any Oracle licensing discussion and contractual:

  • Technical Support Policy
  • Processor Core Factor Table
  • Oracle License and Service Agreement (OLSA) / Oracle Master Agreement(OMA)
    • The OLSA/OMA defines Processor as &#rsquo;Processor: shall be defined as all processors where the Oracle programs are installed and/or running.&#rdquo;

All Oracle licensing collateral on vSphere can be found at

  • Oracle Licensing Webinar Recording – Links to the webinar and corresponding introduction article
    • http://www.dbta.com/Webinars/722-Straight-Talk-on-Oracle-on-VMware-Licensing.htm
  • Updated Understanding Oracle Licensing, Certification and Support on VMware guide
    • http://www.vmware.com/files/pdf/solutions/oracle/Understanding_Oracle_Certification_Support_Licensing_VMware_environments.pdf
  • Licensing Databases on EMC and VMware Technology
    • http://blogs.vmware.com/vsphere-new/2016/08/new-database-licensing-white-paper-house-brick.html

Who you gonna call ? &#rsquo;Myth busters&#rdquo;

For any Oracle Licensing on VMware help , please reach out to your respective VMware Account teams who can get our team involved in a discussion (Internal VMware folks can reach directly to us at the Tier1-Apps-Sales-Support team mailing list) and we can definitely help guide you and connect you to some of our premier partners if required for further discussions.

The post Oracle on VMware vSAN – Dispelling the Licensing myths appeared first on Virtualize Business Critical Applications.

Read more..

Go Que Newsroom Categories

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 40 bytes) in /home/content/36/8658336/html/goquecom/wp-includes/wp-db.php on line 1995