I am only going to focus on a single option for stretching Layer 2. Cisco's OTV provides a mechanism to transport native Layer-2 Ethernet frames to a remote site. With a standard Layer-3 WAN, there is no way to bridge layer-2 VLANs, and as a result, communication between two sites must be routed. Because of the routing aspect, it is not possible to define the same VLAN in two locations and have them both be actively transmitting data simultaneously.
Because OTV can operate over any WAN that can forward IP traffic, it can be used with a multitude of different underlying technologies. It provides mechanisms to control broadcasts at the edge of each site, just as with a standard Layer-3 WAN, but also gives you the ability to allow certain broadcasts to cross the islands. OTV only needs to be deployed at certain edge devices, and is only configured at those points, making it simple to implement and manage. It also supports many features to optimize bandwidth utilization, provide resiliency and scalability.
When a host at one site sends a frame to a host at the other site, it can determine the MAC address of the other host, since it is on the same VLAN/network. The host sends the Ethernet frame, which is accepted by the OTV switch and then encapsulated in an IP packet, sent across the WAN, and subsequently decapsulated by the remote OTV switch. From here, the Ethernet frame is delivered to the destination as if it had been sent locally.
In the event that there is a planned event that will impact a significant number of resources, services must be moved to an alternate location. Unfortunately, because the networks are disjointed, there is no way to seamlessly migrate virtual servers from one location to another without changing IP addresses.
As a result, Site Recovery Manager can be used to provide an offline migration to the second site, and update DNS records to reflect the new IP addresses for the affected servers. Once the event is complete, another offline migration is performed to restore services to the primary site.
By using OTV in this situation instead of having to use SRM to emulate a disaster situation, vMotion can be used to migrate the VMs from one site to the other. While this migration is still an offline event, it does provide a much simpler solution to implement and manage by allowing the VM to maintain its network identity in either location.
In addition to addressing the initial challenge, OTV provides additional benefits.
By having two functional sites with the same network attributes, it is possible to split workloads for services, providing fault tolerance and redundancy. If the primary site does have a planned event, failing resources over to the second site may not even be necessary. It also allows the infrastructure to scale by having added ESXi servers operational at the second location to distribute the load.
I have literally spent the las, including this morning, trying to figure out why I could no longer launch my Cisco UCS Manager console for the test environment. The production environment works without any issues, but when I attempt to load UCSM for the test environment it hangs at the java loading screen and after a few minutes errors out.
Knowing that Java and UCS usually don't play well together, I figured this issue was most likely related to the Java version not working with UCS 2.1.1C so I assumed that my current version of Java 7 u51 was the culprit. Here is a list of step of what I did; but you can jump iver this if you want the quick fix.
Installed Java 6 U45, tested, failed, removed, rebooted.
Installed Java 7 U25 32-bit and 64-bit… tested, failed, removed, rebooted.
I did some research on google and came across JavaRa which removed all traces of Java. Used the utility, and then used CCleaner followed by another reboot.
Installed Java 8 Beta, tested, and failed.
After looking around online I came across someone reporting a similar issues, but not related to Cisco UCS but instead another Java based application. In the post they said deleting the following locations resolved their problems.
Sure enough, deleting those files and rebooting fixed it!
On a side note; I am now running Java 8 and it seems to work fine with UCS…. but we will see how long that last for.