Cisco® Intelligent Traffic Director (ITD) is an innovative solution to bridge the performance gap between a multi-terabit switch and gigabit servers and appliances. ITD is much superior than legacy solutions such as PBR, ECMP, Port-channel, etc for service appliances and servers. ITD is allowing customers to achieve massive CAPEX and OPEX savings. Here is a table comparing with some of the features.
Customers are using ITD for a multitude of use-cases.
Load-balance traffic to 256 servers of 10Gbps each.
Load-balance to cluster of Firewalls. ITD is much superior than PBR.
Scale up NG IPS and WAF by load-balancing to standalone devices.
Scale the WAAS / WAE solution.
Scale the VDS-TC (video-caching) solution.
Replace ECMP/Port-channel to avoid re-hashing. ITD is resilient.
Oracle OpenWorld is a show like no other, with over 60,000 IT professionals convening in San Francisco for a week of all things, Oracle, Java and more. Cisco has a full slate of activities planned, including demos and theater sessions on the many benefits of running your Oracle workloads on the Cisco Unified Computing System (UCS). We’re also teaming with theCUBE to stream three days of live interviews with the industry’s leading thought leaders and Oracle solution experts. All of our activities have a common theme – Unleashing Oracle Performance.
With more than 25 world record benchmarks for Oracle workloads, Cisco has a proven record of delivering record-setting Oracle performance with each generation of server and processor technologies. This week at Oracle OpenWorld, we’re showcasing three recent world record benchmarks for Oracle E-Business Suite and critical Java operations.
Oracle E-Business Suite Applications R12 (12.1.3) Payroll and Order-to-Cash Benchmarks
The Cisco UCS® B200 M4 Blade Server with the Intel® Xeon® processor E5-2600 v3 product family, is the number-one server with top results on the Oracle E-Business Suite Applications R12 benchmark. The Cisco UCS B200 M4 performed over a million employees per hour on the Payroll Extra-Large Model Benchmark, outperforming the IBM Power System S824. UCS also set a world record on the Order-to-Cash workload, processing more than 11,000 more order lines per hour than the same server configured with previous-generation processors. The performance brief has all the details.
Finding a molecule with the potential to become a new drug is complicated. It’s time-consuming. Fewer than 10 percent of molecules or compounds discovered are promising enough to enter the development pipeline. And fewer of those ever come to market. At Pfizer, if it were not for data virtualization, it would be even more challenging.
Years of Data, Thousands of Decisions
The pipeline from discovery to licensing occurs in phases over 15-20 years, and few compounds complete the journey. The initial study phase represents a multimillion-dollar investment decision. Each succeeding phase – proof-of-concept study, dose range study, and large-scale population study – represents a magnitude-larger investment and risk than the one before.
Senior management and portfolio managers need to know:
Which projects the company should fund?
Which compounds are meeting Pfizer’s high standards for efficacy and safety?
What are scientists discovering in clinical trials?
Portfolio and project managers routinely make complex tactical decisions such as:
How to allocate scarce R&D resources across different projects?
How to prioritize multiple development scenarios?
What is impact of a clinical trial result on downstream manufacturing?
Before Pfizer adopted Cisco Data Virtualization, getting useful data to answer these questions took weeks or months. Why so long? The problem has several dimensions. First, each phase of development generates massive amounts of data and requires extensive analysis to provide an accurate picture. Second, data comes from Pfizer research scientists all over the world; from physicians; clinical trials; product owners and managers; marketing teams; and hundreds of different back-end systems. Third, the scientific method is based on trial and error, with unpredictable results. Thus no two decisions are alike and therefore the specific data required for each decision is unique.
Data Virtualization Provides the Solution
To support their decision-making needs, Pfizer needed a solution that would allow them to pull all this diverse information together in an agile, ad hoc way. Cisco Data Virtualization – agile data integration software that makes it easy to access and gather relevant data, no matter where data sources reside – provided the solution.
With Cisco Data Virtualization, Pfizer’s research and portfolio data resides in one virtual place and provides “one version of the truth” that is available for everyone to use to address the myriad decisions that arise. Further, by applying virtualization instead of consolidation, infrastructure costs are also reduced.
According to Pfizer, “data virtualization is far less expensive than building specialized data marts to answer questions. With Cisco Data Virtualization, our portfolio teams get answers in hours or days for about one-tenth the cost.”
This data virtualization progress has not gone unnoticed. At Data Virtualization Day 2012, Pfizer was awarded the “Data Virtualization Champion” award for consistently achieving and promoting data virtualization value within the organization and across the industry.
Learn from other leaders in the industry and see who wins this year’s Data Virtualization Leadership Awards at Data Virtualization Day 2014 on October 1. Register now!
To read more about this Pfizer case study click here.
To learn more about Cisco Data Virtualization, check out our page.
We are excited to announce the availability of Cisco Nexus Data Broker software release 2.0. Using the Cisco Nexus Data Broker software, Cisco’s approach replaces the traditional purpose-built matrix switches used for network taps or SPAN aggregation with one or more OpenFlow-enabled Cisco Nexus switches.
Visibility into application traffic has traditionally been important for infrastructure operations to maintain security, resolve problems, and perform resource planning. Now, however, as a result of technological advances and the ubiquity of the Internet, organizations increasingly are seeking not just visibility but real-time feedback about their business systems to more effectively engage their customers. Also, with the rapid evolution of cloud-based technologies, there is a strong need for scalable and cost-effective network traffic tap/SPAN aggregation for traffic monitoring solutions. The traditional approach that uses purpose-built matrix switches for netowrk tap/SPAN aggregation to feed traffic to multiple systems for security, compliance and application performance monitoring has three primary challenges:
This approach is too expensive to scale the visibility to meet today’s business requirements.
The purpose-built switches are statically programmed with predetermined filtering and forwarding rules, so they cannot act in an event-based way to provide traffic visibility in real time.
Support for interconnecting multiple switches for a scalable deployment that suits your data center architecture is limited.
With Cisco Nexus Data Broker (see Figure 1), the traffic is tapped into this bank of switches in the same manner as in a purpose-built matrix network. However, with Cisco Nexus Data Broker, you can interconnect these Cisco Nexus switches to build a scalable tap and SPAN aggregation infrastructure. You also can use a combination of network taps and SPAN sources to bring the copy of the production traffic to this infrastructure. In addition, you can distribute the network tap and SPAN sources and traffic monitoring and analysis tools across multiple Cisco Nexus switches. Cisco Nexus Data Broker also provides the flexibility to aggregate traffic from multiple tap or SPAN sources and replicate and forward traffic to multiple analysis tools for monitoring. See Table 1 for a list of important features and functions.
Supported topology for Cisco® Monitor Manager network
Cisco Nexus Data Broker software discovers the Cisco Nexus switches and associated topology for Tap/SPAN aggregation.
The software allows you to configure ports as monitoring tool ports or input Tap/SPAN ports.
You can set end-device names for easy identification in the topology.
Support for QinQ to tag input source Tap/SPAN port
You can tag traffic with a VLAN for each input Tap or SPAN port.
Q-in-Q support in edge Tap and SPAN ports allow you to uniquely identify the source of traffic and preserve production VLAN information.
Symmetric hashing or symmetric load balancing*
You can configure the hashing based on Layer 3 (IP address) or Layer 3 + Layer 4 (protocol ports) for load balancing the traffic across a port-channel link.
You can spread the traffic across multiple tool instances to meet the high-traffic-volume scale.
Rules for matching monitored traffic
You can match traffic based on Layer 1 through Layer 4 criteria.
You can configure the software to send only the required traffic to the monitoring tools without flooding the tools with unnecessary traffic.
You can configure action to set the VLAN ID for the matched traffic.
Replicate and forward traffic
You can configure the software to aggregate traffic from multiple input Tap/SPAN ports that could be spread across multiple Cisco Nexus switches.
You can replicate and forward traffic to multiple monitoring tools that can be connected across multiple Cisco Nexus switches.
This solution is the only one that supports any:many forwarding across a topology.
You can time-stamp a packet at ingress using the Precision Time Protocol (PTP; IEEE 1588), thereby providing nanosecond accuracy. You can use this capability for critical transaction monitoring and archiving data for regulatory compliance and advance troubleshooting.
You can configure the software to truncate a packet beyond specified bytes.
The minimum is 64 bytes.
You can retain a header for only analysis and troubleshooting.
You can configure the software to discard the payload for security or compliance reasons.
End-to-end path visibility
For each traffic forwarding rule, the solution provides a complete end-to-end path visibility all the way from source ports to the monitoring tools, including the path through the network.
React to changes in the Tap/SPAN aggregation network states
You can monitor and keep track of network condition changes.
You can configure the software to react to link or node failures by automatically reprogramming the flows through an alternative path.
Management for multiple disjointed Cisco Monitor Manager networks
You can manage multiple independent traffic monitoring networks, which may be disjointed, using the same Cisco Nexus Data Broker instance. For example, if you have five data centers and you want to deploy an independent Cisco Monitor Manager solution for each data center, you can manage all of these five independent deployments using a single Cisco Nexus Data Broker instance by creating a logical partition (network slice) for each monitoring network.
Role Based Access Control (RBAC)
Application access can be integrated with corporate AAA server for both authentication and authorization
You can create port groups and associate the port groups with specific user roles
Capability to assign users to specific roles and port groups; users can manage only those ports
*Feature supported only on Cisco Nexus 3500.
**Feature supported only on Cisco Nexus 3100.
Please visit the Cisco NDB website for more information. If you are going to be in NYC at Interop Sep 29 -- Oct 2, please visit us to hear Jothi Prakash Prabakaran talk about Nexus Data Broker as a scalable network traffic monitoring solution in the Cisco booth (#611) theater.
In this week’s episode of Engineers Unplugged, Intel’s Damion Desai and Cisco’s Frank D’Agostino (@fdagosti) discuss cloud in the enterprise with the challenges modern applications bring. Don’t miss it!
**Want to be Internet Famous? Join us for our next shoot: VMworld Barcelona. Tweet me @CommsNinja!**
This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
Episodes will publish weekly (or as close to it as we can manage)