It’s been a couple of weeks since the Cisco data center and partner teams wrapped up a terrific Oracle OpenWorld 2014. We had a great week of conversations with customers and partners on how Cisco UCS provides a superior platform for Oracle Data Base and applications. We also announced three record-setting benchmarks for Oracle E-Business Suite and Java operations (SPECjbb2013).
This year, we placed a greater emphasis on communicating beyond our booth via video, digital and social streams. We staged a studio in the Cisco booth that enabled us to stream live video interviews with industry luminaries and Cisco experts hosted by theCUBE, the leading interview format show in enterprise tech. We were honored to host Intel CIO Kim Stevenson immediately following her main stage keynote presentation. Other featured guest included Jim McHugh, Cisco VP of UCS Marketing; Intel VP, Shannon Poulin; Cisco VP of Global Partner Marketing; Sherri Liebo; and Red Hat VP, Mike Evans. The videos are now available for replay here.
The Cisco booth was a hub of non-stop action in our theater where we hosted a terrific line-up of presentations by Cisco experts, customers and partners. We took advantage of this opportunity to record video summaries of these sessions and are pleased to present this video library from Oracle OpenWorld 2014.
House of Brick Technologies on the Advantages of Cisco UCS for Oracle Workloads
Why is Cisco UCS everywhere? Dave Welch, CTO of House of Brick Technologies, highlights the many advantages of UCS for Oracle workloads in this discussion with Jim McHugh, Cisco VP of UCS Marketing.
In my last post I discussed how Cisco UCS Mini is helping us expand beyond the traditional confines of the data center, to deliver desktop and app virtualization with exceptional user experience, manageability and TCO savings – at the enterprise edge.
We’re only going to see more investment and focus in this space, thanks to the general trend towards making VDI and app virtualization more tenable in a wider array of use cases across the enterprise, pushing from data center to enterprise edge. This week, I want to offer a proof point I alluded to in my last post, enabled by our partners Nimble Storage and VMware.
Let’s take a look at the Nimble Storage SmartStack for ROBO (Remote Office / Branch Office) Desktop Virtualization. As you know, we’ve seen incredible traction with our friends at Nimble. Their CS array has seen wide market acceptance, and is now offered as an Integrated Infrastructure solution in the form of SmartStack, delivering the modularity, scale and manageability that IT demands.
I’m pleased to highlight that SmartStack now offers a solution optimized for ROBO. In case you missed it, check out Nimble Storage’s announcement. Bringing together best-of-breed components including VMware Horizon 6, Nimble’s CS300 array, and UCS Mini, this offering delivers on the key attributes critical to the enterprise edge:
Greater Consolidation: dense storage, compute and expansive I/O capacity of the Nimble + Cisco UCS solution, allows for hundreds of users in a small footprint, 50% of what traditional solutions might occupy.
Simplified Management: anchored on UCS Manager, this platform enables centralized IT to remotely spin up desktop and application virtualization capacity at remote/branch offices, without the error-prone, manual intervention required by traditional compute platforms.
High Performance: the combination of Nimble’s large IOPS footprint, low latency and Cisco UCS processing power delivers adaptive, exceptional performance in a compact form factor. This, along with VMware Horizon, allows IT to maintain an exceptional user experience through heavy application use and periods such as boot/login storms, patch operations and upgrades.
For more information on the Nimble SmartStack for ROBO Desktop Virtualization, please check out Sheldon D’Paiva’s blog on SmartStack ROBO.
I recently wrote about how Cisco is helping customers more effective manage massive amounts of data, types of data and unprecedented distribution of data. This will be one of the toughest challenges brought on by the Internet of Everything (IoE) and, with solutions such as Data Virtualization and Big Data Warehouse Expansion, Cisco is enabling our customers to meet the challenge head on of bringing all of this data together in ways that are meaningful to business users.
After the business can access and view all of this data, however, the question becomes…now what? The next challenge is to extract insights from the data to make better business decisions. After all, more data is only good if you use it to make better decisions than you would have made otherwise.
The rules of customer and business relationships are constantly changing due to technological innovation and consumption patterns. Analytics can reveal patterns in customer data that affect business processes and outcomes. Advanced analytics is different than reporting because it prescribes what to do, or predicts what is likely to happen, instead of just reporting what has already happened.
Utilizing the network to securely connect data throughout the IoE, whether in motion (streaming) or at rest (historical), is the future of advanced analytics. For a retailer, it will give them the opportunity to take intelligent actions to engage customers directly at the point of purchase and in real-time. But it’s so much more than that. What can real-time analytics in retail tell us about how to serve customers more effectively? What can real-time analytics in manufacturing tell us about how to make the workplace safer? What can real-time analytics in healthcare tell us about how to better treat cancer patients?
When our customers can accurately predict outcomes by combining years of historical data with real-time information, they can drive better decisions…better outcomes.
Interested in hearing how Cisco is paving the way to the future of analytics? Please join us for a webcast at 9 AM Pacific time on October 21st entitled ‘Unlock Your Competitive Edge with Cisco Big Data and Analytics Solutions.’ #UnlockBigData
To learn more about Data and Analytics, check out our page.
[Note: This is the second of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 3 | Part 4]
Following on from the first part of our series, this blog post takes a closer look at some of these architectural components of Cisco ACI and the VMware NSX software overlay solution to quantify the advantages of Cisco’s application-centric policies and demonstrate how the architecture supports greater scale and more robust IT automation.
As called for in the requirements listed in the previous section, Cisco ACI is an open architecture that includes the policy controller and policy repository (Cisco APIC), infrastructure nodes (network devices, virtual switches, network services, etc.) under Cisco APIC control, and a protocol communication between Cisco APIC and the infrastructure. For Cisco ACI, that protocol is OpFlex.
OpFlex was designed with the Cisco ACI policy model and cloud automation objectives in mind, including important features that other SDN protocols could not deliver. OpFlex supports the Cisco ACI approach of separating the application policy from the network and infrastructure, but not the control plane itself. This approach provides the desired centralization of policy management, allowing automation of the entire infrastructure without limiting scalability through a centralized control point or creating a single point of catastrophic failure. Through Cisco ACI and OpFlex, the control engines are distributed, essentially staying with the infrastructure nodes that enforce the policies.
The second revolution in server virtualization is here. Virtual Machines were the first revolution that allowed users the ability to run multiple workloads on a single server through a hypervisor. Now the next wave is here. Linux Containers have recently started to gain momentum with many enterprise customers asking me if they should consider it and if Cisco offered Docker support in the enterprise-grade virtual networking products.
I approached my engineers to see whether our recently introduced Nexus 1000v for the Linux KVM hypervisor, which already has 10000+ customers across various hypervisors, is able to support linux containers or more specifically the popular linux container technology, Dockers.
One of the key advantages of Nexus 1000V today is that it allows easy management of policies for all of the virtual machines. For example, with a single command or REST API call, a security policy can be deployed or altered across all virtual interfaces connected to a Virtual Extensible LAN (VXLAN). My reasoning was that we should able to extend that to support to linux containers/dockers.
So I approached Tim Kuik (@tjkuik) and Dave Thompson (@davetho610) and much to my delight, they not only said Nexus 1000V can do it but also showed how to do it so that customers can take advantage of this today in their deployments.
I have included Tim and Dave’s how to attach Docker containers to the Nexus 1000v and to assign policies write-up below so that you can try this in your setup. Happy reading.
How to use Dockers with Nexus 1000V for KVM Hypervisor:
Begin by installing the Nexus 1000v to manage one or more Ubuntu servers: The Nexus 1000v is managed by a Virtual Supervisor Module (VSM). Once the package is installed on your servers, the servers will appear on the VSM as Virtual Ethernet Modules (VEM). Below we can see our VSM is managing a server named Bilbo:
We’ve also pre-configured our server to have a port-channel that is capable of carrying vlan traffic 100-109. We’ve used an Ethernet Port-profile to conveniently manage the uplinks for all of our servers:
A key concept of the Nexus 1000v is that of a Port-profile. The Port-profile allows for a shared set of port attributes to be cohesively managed in a single policy definition. This policy can include an ACL definition, Netflow specification, VLAN or VXLAN designation, and/or other common port configuration attributes. We can, of course, create multiple Port-profiles. Perhaps we would have one per level of service or tenant. The Port-profile provides the mechanism to collect and manage the set of containers that share the same policy definition.
Below we create a Port-profile that could be used by any number of containers on any number of servers.
Install docker on your server. [https://docs.docker.com/installation/ubuntulinux/]
The purpose of the container is to run our application. Let’s create one for this example which can handle ssh sessions. Here is an example Dockerfile which does that:
At this point, via Docker, you can build an image specified by this Dockerfile.
All the pieces are now in place. The Nexus 1000v is running. We have a policy definition that will assign the interfaces to vlan 100 (port-profile vlan100). Docker is installed on our server. We have created a useful container image. Let’s create an actual container from this image:
The container instance started at this point is running with just a loopback interface since we used the argument “–networking=false”. We can now add an eth0 interface to this container and set it up to be handled by the Nexus 1000v on the host.
Setup a few env variables we will use as part of the procedure. Find the PID of the running container and generate UUIDs to be used as identifiers for the port and container on the Nexus 1000v:
In this example the following PID and UUIDs were set:
Create a linux veth pair and assign one end to the Nexus 1000v. We will use the port-profile defined on the VSM named “vlan100’ which will configure the port to be an access port on VLAN 100:
When an interface is added to the Nexus 1000v, parameters are specified for that interface by adding keys to the external_ids column of the Interface table. In the example above the following keys are defined:
iface-id: Specifies the UUID for the interface being added. The Nexus 1000v requires a UUID for each interface added to the switch so we generate one for this.
attached-mac: Provides the MAC of the connected interface. We get this from the ‘ip link show’ command for the interface to be added to the container.
profile: Provides the name of the port-profile which the Nexus 1000v should use to configure policies on the interface.
vm-uuid: Specifies the UUID for the entity which owns the interface being added. So in this case that’s the container instance. Since Docker doesn’t create a linux type UUID for the container instance, we generate one for this as well.
vm-name: Specifies the name of the entity which owns the interface. In this case it’s the container name.
Move the other end of the linux veth pair to the container’s namespace, rename it as eth0, and give it a static IP address of 172.22.64.201 (of course DHCP could be used instead to assign the address):
On the Nexus 1000v’s VSM you will see logs like this indicating the interface has been added as switch port vethernet1 on our virtual switch:
The following VSM commands show that switch port veth1 is up on VLAN 100 and is connected to host interface veth18924_eth0 on host bilbo:
On the host bilbo we can use vemcmd to get information on the port status:
That’s it. We now have a useful Docker container with an interface on the Nexus 1000v using our selected policy. Using another server (and/or container) that is on the same vlan, we can ssh into this container using the IP address we assigned:
When shutting down the Docker container, remove the port before removing the container: