EMC and VMware Deliver Service Assurance for Virtual Data Centers
Register Now<https://emcinformation.com/72105/REG/.ashx?reg_src=WEB>
Date:
Jul 24, 12
Time:
11:00 AM - 12:00 PM EDT (Set Time Zone)
Event Type:
EMC Live Webcast
Category:
Virtualization
Location:
Online
Details:
Join us for this informative live webcast to understand how EMC and VMware Operations Management Suite for Virtual Data Center environments can help you deliver new services quickly and reliably, identify and resolve problems before service impact, and improve operational efficiency.
Register to learn how Operations Management Suite for Virtual Data Center can help you:
* Resolve problems 80% faster
* Ensure maximum service uptime, and
* Achieve a 2 times improvement in operational efficiency
________________________________
Original Page: http://www.emc.com/events/2012/q3/07-24-12-emc-and-vmware-deliver-service-assurance-for-vdcs.htm?CMP=RSS-events
Thursday, June 28, 2012
Performance Study of Oracle RAC on VMware vSphere 5.0 - Eric Sloof
IT organizations that have implemented Oracle Real Application Clusters (RAC) often use RAC to support critical functions of their business. Performance of these database clusters is key to enabling IT organizations to meet the requirements of their businesses, customers, and shareholders.
VMware vSphere provides a high performance virtualization platform that is capable of hosting the most critical portions of infrastructure, including Oracle RAC databases. vSphere 5 has increased these capabilities, including support for virtual machines with up to 32 vCPUs and 1TB of RAM. This support for larger virtual machines (VMs) combined with vSphere's high performance capabilities makes vSphere a great platform for running large Oracle RAC database clusters.
EMC IT has implemented vSphere throughout many parts of their infrastructure and is now in the process of moving the largest and most critical applications to vSphere. EMC and VMware worked together to evaluate the performance of one of EMC's largest Oracle RAC databases on vSphere 5. A copy of this database was used to conduct a series of tests to compare physical performance versus virtual performance.
This testing, which was done with an Oracle RAC cluster made up of six 32-CPU-based nodes, four of them virtual and two of them physical, found that virtual performed within 12% of native and was acceptable to be used for the production instance. EMC IT plans to adopt this virtual configuration in its next refresh cycle.
http://www.vmware.com/files/pdf/techpaper/OracleRAC-perf-vSphere5.pdf
feedproxy.google.com [cid:/images/orig-link.png] <http://feedproxy.google.com/~r/Ntpronl/~3/ZhZzOGu7CPo/2076-Performance-Study-of-Oracle-RAC-on-VMware-vSphere-5.0.html>
VMware vSphere provides a high performance virtualization platform that is capable of hosting the most critical portions of infrastructure, including Oracle RAC databases. vSphere 5 has increased these capabilities, including support for virtual machines with up to 32 vCPUs and 1TB of RAM. This support for larger virtual machines (VMs) combined with vSphere's high performance capabilities makes vSphere a great platform for running large Oracle RAC database clusters.
EMC IT has implemented vSphere throughout many parts of their infrastructure and is now in the process of moving the largest and most critical applications to vSphere. EMC and VMware worked together to evaluate the performance of one of EMC's largest Oracle RAC databases on vSphere 5. A copy of this database was used to conduct a series of tests to compare physical performance versus virtual performance.
This testing, which was done with an Oracle RAC cluster made up of six 32-CPU-based nodes, four of them virtual and two of them physical, found that virtual performed within 12% of native and was acceptable to be used for the production instance. EMC IT plans to adopt this virtual configuration in its next refresh cycle.
http://www.vmware.com/files/pdf/techpaper/OracleRAC-perf-vSphere5.pdf
feedproxy.google.com [cid:/images/orig-link.png] <http://feedproxy.google.com/~r/Ntpronl/~3/ZhZzOGu7CPo/2076-Performance-Study-of-Oracle-RAC-on-VMware-vSphere-5.0.html>
Wednesday, June 27, 2012
Why I need a MacBook Air
I had the pleasure of having Chris Fraser (@CoureurDeNuage) from EMC in town last week and as we travelled between meetings it became apparent why a number of “professional travelers” have moved over to MacBooks.
The first thing that caught my eye was the sheer size and weight of his device. As we sat in Starbucks, Chris was able to pull out his MacBook from his bag, balance it on one knee, drink his coffee and carry on a conversation with me, while I was still struggling to pull my ThinkPad from my bag.
Once my ThinkPad was out of the bag, it was time to clear the spot on the table to fit this mammoth heavy beast that I call my laptop. I sat back and watched Chris clack away on his keyboard (still balancing it on his knee) while I was smashing the keys on the keyboard trying to wake mine from sleep. By this point Chris had sent me 2 emails with information that we had discussed earlier in the day.
I asked Chris if he had any issues connecting to the Wi-Fi, he said it was slow (we were in a really busy Starbucks) but he had no issues connecting. So after I disabled and re-enabled the Wi-Fi a couple of times with no success it was time for a reboot (which is normal for me after taking my laptop out of sleep).
Luckily I got a phone call as I was waiting for my laptop to reboot so the time it didn’t seem drag on too long, but knowing full well that it was at least 2 minutes for the whole process to finish. As I got off the phone I looked at the time and decided it was time to move on to our next meeting. Chris snapped his MacBook closed and slide it effortlessly into his bag and was up and ready to go, I on the other had had decided to fully shut down my ThinkPad so I didn’t have Wi-Fi issues the next time we stopped somewhere to get some quick work done. The whole shutdown process and then having to fight to get the ThinkPad back into my backpack took a number of minutes but then we were on our way.
As we were leaving I was thinking to myself, in the 20 minutes we were in the coffee shop, Chris was productive for close to 18 of those minutes, while I was productive on my laptop for none (I guess if I didn’t take that phone call I may of been able to get my laptop up and running for 2 or 3 minutes)
For those of you who know me well you are probably asking “Why wasn’t Mike using his iPad, he never leaves home without it” and that is a fair question. When I was on the private side of IT I only traveled with my iPad because I never had to do much more than send out a few emails or create a word document, but now that I am on the dark side, I have to use a number of websites for configurations and pricing that do not work with the iPad browsers (or at least do not work well) and I spend the majority of my time in spreadsheets working with formulas and pricing, again which isn’t the greatest on the iPad.
I’m not saying that a MacBook will cure all my technology and productivity issues, but from this experience (and the same scenario plays out almost every time I sit down to do some work when I am not in one of my offices) it is defiantly worth investigating a move to a MacBook.
Monday, June 25, 2012
VMware: VMware vSphere Blog: How to use Port-Mirroring feature of VDS for monitoring virtual machine traffic?
I would like to clarify few things in this blog entry about the Port-mirroring feature that is available on vSphere Distributed Switch (VDS). This feature is similar to the port mirroring capability available on the physical switches. Network administrators can use this feature to troubleshoot any network related issues in the virtual infrastructure and monitor virtual machine to virtual machine traffic that is flowing on the same ESXi host. Network administrators use network analyzer tool, which captures traffic, along with the port mirror feature to perform monitoring and troubleshooting activities. In the physical network, depending on where the analyzer or debug tool is placed in the network, network administrators choose different port mirroring options. The following are some of the standard port mirroring options available on physical switches:
- Switch Port Analyzer (SPAN)
- Remote Switch Port Analyzer (RSPAN)
- Encapsulated Remote Switch Port Analyzer (ERSPAN)
SPAN feature is local to the switch and requires the monitored ports and the destination port are on the same switch. With the release of vSphere 5.0, VMware provides support for only SPAN feature on VDS. The following blog entry<http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-port-mirroring.html> discusses the feature in little more detail. During the setup of a SPAN session customers have to select a virtual port that needs monitoring and then choose a destination virtual port where all the traffic will be mirrored. Here are some of the common monitoring and troubleshooting use cases based on where the analyzer tool is running.
1) Mirroring to an analyzer tool running in a virtual machine on the same host.
As shown in the figure below, you can have a virtual machine run analyzer tool. In such scenario you have to configure the pot mirror session with source as virtual port of the monitored virtual machine and destination as the virtual port of the virtual machine running analyzer tool.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-pi>
2) Mirroring to an external physical analyzer connected directly to the uplink port of the host.
In this case the analyzer tool is running on an external physical device, which is directly connected to the host through a NIC. As shown in the figure below, the source virtual port of the port mirror session remains same but the destination is changed to the uplink port connected to vmnic1. The mirror packets are sent through the vmnic1 to the analyzer device for monitoring.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-pi>
3) Mirroring to an external physical analyzer connected to a physical switch where the host is also connected.
This setup is possible provided you configure a SPAN session on the VDS and physical switch as well. Let's dig a little more here. As mentioned earlier, SPAN feature is local to a switch and requires both monitored and destination ports on the same switch. If you look at the diagram below, the analyzer is not directly connected to the VDS. It is connected through a physical switch. So this is not a straightforward use case 2.
Let's take a look at the mirror packet flow. The port mirror session is configured on the VDS with the virtual port of the monitored virtual machine as the source and uplink connected to vmnic 1 as the destination. All packets flowing through the monitored virtual machine are now copied through the vmnic1 to the physical switch port. On the same physical switch the analyzer is connected to a different port. The analyzer connected to a port on the same switch is not going to see the traffic mirrored by VDS. For this use case to work, it is not enough to configure the port mirror session on VDS. You have to configure SPAN session on the physical switch with the switch port where the host's vmnic 1 is connected is the monitored port and the destination port is where the analyzer is connected.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-pi>
VDS currently doesn't support RSPAN capability, which allows network administrators to monitor the traffic remotely multiple hops away from the source. Customers have to create a dedicated VLAN to carry the RSPAN traffic and the switches supporting RSPAN feature have to encapsulate all the monitored traffic in this special VLAN.
There is also some confusion because of the GUI screen options provided during the port mirroring setup on VDS.
If you take a look at the configuration screen shown below, there is an encapsulation option shown in the red box. This encapsulation option gives the feeling that RSPAN is supported. However, it is not and you shouldn't configure this parameter.
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-pi>
________________________________
Original Page: http://blogs.vmware.com/vsphere/2012/06/how-to-use-port-mirroring-feature-of-vds-for-monitoring-virtual-machine-traffic.html
- Switch Port Analyzer (SPAN)
- Remote Switch Port Analyzer (RSPAN)
- Encapsulated Remote Switch Port Analyzer (ERSPAN)
SPAN feature is local to the switch and requires the monitored ports and the destination port are on the same switch. With the release of vSphere 5.0, VMware provides support for only SPAN feature on VDS. The following blog entry<http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-port-mirroring.html> discusses the feature in little more detail. During the setup of a SPAN session customers have to select a virtual port that needs monitoring and then choose a destination virtual port where all the traffic will be mirrored. Here are some of the common monitoring and troubleshooting use cases based on where the analyzer tool is running.
1) Mirroring to an analyzer tool running in a virtual machine on the same host.
As shown in the figure below, you can have a virtual machine run analyzer tool. In such scenario you have to configure the pot mirror session with source as virtual port of the monitored virtual machine and destination as the virtual port of the virtual machine running analyzer tool.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-pi>
2) Mirroring to an external physical analyzer connected directly to the uplink port of the host.
In this case the analyzer tool is running on an external physical device, which is directly connected to the host through a NIC. As shown in the figure below, the source virtual port of the port mirror session remains same but the destination is changed to the uplink port connected to vmnic1. The mirror packets are sent through the vmnic1 to the analyzer device for monitoring.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-pi>
3) Mirroring to an external physical analyzer connected to a physical switch where the host is also connected.
This setup is possible provided you configure a SPAN session on the VDS and physical switch as well. Let's dig a little more here. As mentioned earlier, SPAN feature is local to a switch and requires both monitored and destination ports on the same switch. If you look at the diagram below, the analyzer is not directly connected to the VDS. It is connected through a physical switch. So this is not a straightforward use case 2.
Let's take a look at the mirror packet flow. The port mirror session is configured on the VDS with the virtual port of the monitored virtual machine as the source and uplink connected to vmnic 1 as the destination. All packets flowing through the monitored virtual machine are now copied through the vmnic1 to the physical switch port. On the same physical switch the analyzer is connected to a different port. The analyzer connected to a port on the same switch is not going to see the traffic mirrored by VDS. For this use case to work, it is not enough to configure the port mirror session on VDS. You have to configure SPAN session on the physical switch with the switch port where the host's vmnic 1 is connected is the monitored port and the destination port is where the analyzer is connected.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-pi>
VDS currently doesn't support RSPAN capability, which allows network administrators to monitor the traffic remotely multiple hops away from the source. Customers have to create a dedicated VLAN to carry the RSPAN traffic and the switches supporting RSPAN feature have to encapsulate all the monitored traffic in this special VLAN.
There is also some confusion because of the GUI screen options provided during the port mirroring setup on VDS.
If you take a look at the configuration screen shown below, there is an encapsulation option shown in the red box. This encapsulation option gives the feeling that RSPAN is supported. However, it is not and you shouldn't configure this parameter.
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-pi>
________________________________
Original Page: http://blogs.vmware.com/vsphere/2012/06/how-to-use-port-mirroring-feature-of-vds-for-monitoring-virtual-machine-traffic.html
VMware: VMware vSphere Blog: Multi-disk replication into common directory with vSphere Replication
When replicating VMs with vSphere Replication you have control over the target location for your VMDKs that are being replicated. For example, you may have a VM with two disks and choose to place them in different directories and locations than they were in the primary site from which they are being copied.
That's great, but something that never came up with array replication is what happens when we want to put all the disks in the *same* directory at the recovery site?
If we have a machine ("VM1") that has 2 VMDKs each on different datastores, for example, they might both be named the same. We might have two "VM1.vmdk" files. In fact, this happens by default - the first disk in a directory is named for the parent VM without consideration for the fact that there may be other VMs elsewhere on different disks.
Disk one:
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-pi>
Looks a lot like disk 2:
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-pi>
Obviously attempting to replicate these VMs into a single directory on the same datastore will cause difficulty on the recovery site. We can't have more than one VMDK of a particular name in a directory.
vSphere Replication is smart - it will detect that an existing disk is in that directory, but it is not so smart that it understands what it is. It assumes very smartly that this is a seed disk you have copied in via sneakernet. If you've got this far with a multi-disk VM, don't choose this option, or you'll use the 'first' disk as a seed and it will do a full synch of the second disk against it, overwriting it!
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-pi>
What are the options? Well first, you can get to the CLI and use vmkfstools to detach, rename, and re-attach the disk then replicate to your heart's content.
Another idea is to create folders for these disks and populate them into unique folders. I.e. "VM1" is the main folder and within it there will be the VMX and all other items and sundry for a VM. In your other directories (such as "OS Disk" and "Data Disk") you can replicate the individual VMDKs. Each directory will then contain a unique but homonymous named "vm1.vmdk".
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-pi>
Set your VR target per-disk, and choose the appropriate directory at the recovery site by selecting to "specify datastore folder". This keeps your data separate, retains easy management and the ability to identify a VMDK by function easily, as well as giving you the freedom to use separate data stores at the source and single data stores at the recovery site.
Original Post by Ken Werneburg
Original Page: http://blogs.vmware.com/vsphere/2012/06/multidisk-replication.html
That's great, but something that never came up with array replication is what happens when we want to put all the disks in the *same* directory at the recovery site?
If we have a machine ("VM1") that has 2 VMDKs each on different datastores, for example, they might both be named the same. We might have two "VM1.vmdk" files. In fact, this happens by default - the first disk in a directory is named for the parent VM without consideration for the fact that there may be other VMs elsewhere on different disks.
Disk one:
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-pi>
Looks a lot like disk 2:
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-pi>
Obviously attempting to replicate these VMs into a single directory on the same datastore will cause difficulty on the recovery site. We can't have more than one VMDK of a particular name in a directory.
vSphere Replication is smart - it will detect that an existing disk is in that directory, but it is not so smart that it understands what it is. It assumes very smartly that this is a seed disk you have copied in via sneakernet. If you've got this far with a multi-disk VM, don't choose this option, or you'll use the 'first' disk as a seed and it will do a full synch of the second disk against it, overwriting it!
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-pi>
What are the options? Well first, you can get to the CLI and use vmkfstools to detach, rename, and re-attach the disk then replicate to your heart's content.
Another idea is to create folders for these disks and populate them into unique folders. I.e. "VM1" is the main folder and within it there will be the VMX and all other items and sundry for a VM. In your other directories (such as "OS Disk" and "Data Disk") you can replicate the individual VMDKs. Each directory will then contain a unique but homonymous named "vm1.vmdk".
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-pi>
Set your VR target per-disk, and choose the appropriate directory at the recovery site by selecting to "specify datastore folder". This keeps your data separate, retains easy management and the ability to identify a VMDK by function easily, as well as giving you the freedom to use separate data stores at the source and single data stores at the recovery site.
Original Post by Ken Werneburg
Original Page: http://blogs.vmware.com/vsphere/2012/06/multidisk-replication.html
Friday, June 22, 2012
EMC Live Webcast: Consolidate Backup and Archiving with EMC Data Domain and EMC SourceOne
Consolidate Backup and Archiving with EMC Data Domain and EMC SourceOne
Register Now<https://emcinformation.com/68911/REG/.ashx?reg_src=WEB>
[http://www.emc.com/images/common/spacer.gif]
Date:
Jul 12, 12
Time:
11:00 AM - 12:00 PM EDT (Set Time Zone)
Event Type:
EMC Live Webcast
Category:
Storage, Intelligent Information Management, Information Governance, Archiving
Location:
Online
Details:
This webcast illustrates how EMC Data Domain deduplication storage systems and EMC SourceOne archiving software together can transform your backup and archiving strategies. Attend and learn how these products provide complete archiving and discovery while delivering consolidated backup and archive storage with high-speed, inline deduplication.
Attend this webcast and learn how EMC can help you transform backup and archiving:
* Increase productivity with integrated content archiving for email, files, and Microsoft SharePoint.
* Enhance data value with fast, online access for search and eDiscovery.
* Reduce cost with deduplication storage capable of storing massive amounts of backup and archive data for years.
* Meet governance and compliance standards including SEC 17a-4, FINRA, and other leading regulations.
[http://www.emc.com/images/events/buttons/btn_register_view_recorded.gif]<https://emcinformation.com/68911/REG/.ashx?reg_src=WEB>
Register Now<https://emcinformation.com/68911/REG/.ashx?reg_src=WEB>
[http://www.emc.com/images/common/spacer.gif]
Date:
Jul 12, 12
Time:
11:00 AM - 12:00 PM EDT (Set Time Zone)
Event Type:
EMC Live Webcast
Category:
Storage, Intelligent Information Management, Information Governance, Archiving
Location:
Online
Details:
This webcast illustrates how EMC Data Domain deduplication storage systems and EMC SourceOne archiving software together can transform your backup and archiving strategies. Attend and learn how these products provide complete archiving and discovery while delivering consolidated backup and archive storage with high-speed, inline deduplication.
Attend this webcast and learn how EMC can help you transform backup and archiving:
* Increase productivity with integrated content archiving for email, files, and Microsoft SharePoint.
* Enhance data value with fast, online access for search and eDiscovery.
* Reduce cost with deduplication storage capable of storing massive amounts of backup and archive data for years.
* Meet governance and compliance standards including SEC 17a-4, FINRA, and other leading regulations.
[http://www.emc.com/images/events/buttons/btn_register_view_recorded.gif]<https://emcinformation.com/68911/REG/.ashx?reg_src=WEB>
Tuesday, June 19, 2012
Performance of vCenter 5.0 in ROBO environments white paper released
by Duncan Epping
I just finished reading the "Performance of VMware vCenter 5.0 in remote offices and branch offices (ROBO)" white paper. I thought it was an excellent read and recommend it to anyone who has a ROBO environment. Also it is interesting to know what kind of traffic hosts / VMs drive in general to vCenter. Especially the details around the statistics level are worth reading for those deploying larger environments as it also gives a sense of the amount of data that vCenter is processing.
Nice work Fei Chen! You can find the paper here:
Performance of VMware vCenter 5.0 in Remote Offices and Branch Offices (ROBO)
<http://www.vmware.com/resources/techresources/10165>This document details the performance of typical vCenter 5.0 operations in a use case where vCenter manages ESXi hosts over a network with limited bandwidth and high latency, which is also known as a remote office, branch office (ROBO) environment.
(Although the date stamp on this entry says 2010 it is a June / 2012 paper, I will try to get this fixed!
________________________________
Original Page: http://feedproxy.google.com/~r/YellowBricks/~3/jw6HFBeViHo/
I just finished reading the "Performance of VMware vCenter 5.0 in remote offices and branch offices (ROBO)" white paper. I thought it was an excellent read and recommend it to anyone who has a ROBO environment. Also it is interesting to know what kind of traffic hosts / VMs drive in general to vCenter. Especially the details around the statistics level are worth reading for those deploying larger environments as it also gives a sense of the amount of data that vCenter is processing.
Nice work Fei Chen! You can find the paper here:
Performance of VMware vCenter 5.0 in Remote Offices and Branch Offices (ROBO)
<http://www.vmware.com/resources/techresources/10165>This document details the performance of typical vCenter 5.0 operations in a use case where vCenter manages ESXi hosts over a network with limited bandwidth and high latency, which is also known as a remote office, branch office (ROBO) environment.
(Although the date stamp on this entry says 2010 it is a June / 2012 paper, I will try to get this fixed!
________________________________
Original Page: http://feedproxy.google.com/~r/YellowBricks/~3/jw6HFBeViHo/
Subscribe to:
Posts (Atom)