Oracle Private Network Recommendations First, a good place to start is to review Oracle’s recommendation for the private interconnect. According to documents on Oracle’s website, the two most important factors for the Oracle Private Interconnect are: 1) Latency 2) Bandwidth Latency is simply the time it takes packets to reach their destination and bandwidth is the size of the pipe between source and destinations. Oracle consistently recommends the use of standalone, dedicated switches for use in the private interconnect environment. Option 1 Using Cisco Core: This option involves using Ethernet Passthroughs in the Dell 1000 server chassis. The E2 and E3 ports on the servers will be bonded and connected up to gigabit VLAN’d ports on the 6513 Chassis. Because these interfaces are bonded (active/passive), the VLANs will need to be trunked across the 6513 in an etherchannel. E2 would go to CoreA and E3 would go to CoreB Pros- Leverages the existing equipment/infrastructure Cisco specific solution (requested by customer) Backplane of 6513’s can easily accommodate the traffic Cons- Limited to 1Gbps throughput at NIC level Cabling requirements could become complicated VLAN’ing across the 6513’s would increase CPU/memory utilization in Core Latency from hops across the core switches would be increased Option Using Cisco Stacks 2: This option involves using the Cisco 3130G chassis switches and their Virtual Blade Switch (or stacking) ability. The 3130G’s have the ability to stack four chassis and 8 switches together to act as one switch. There is failover built into the stack so that in the case of chassis failure, a slave 3130G in the stack will take over as master. Pros- Backplane of 64Gbps in stacked switch fabric Cabling is a cinch- no cables to the core, simple daisy chain Offloads major data streams from the core Logically easy to visualize Allows 2Gbps LACP for server NICs Oracle recommended Cons- Max distance for stacking cables of 9ft (3 meters) Customer not comfortable with switch “stacking” technologies Striping for databases limited to four chassis Option Using Standalone Switches 3: This option involves using the Ethernet passthroughs in the Dell 1000 server chassis. These Ethernet cables would connect up to stacked Cisco 3750-48 switches. The switches would have a 32Gbps backplane between the stacked switches Pros- Decent backplane of 32Gbps between 3750s Offload major data stream from the core Logically very easy to visualize Cisco Solution Allows 2Gbps LACP for server NICs Oracle Recommended In use today in the UPRR Phase 2.5 environment Cons- Single stack of switches not five nines available (no redundant power, no redundant supes) Cabling requirements could be complicated Option Using Single Cisco Core 4: This options involves using the Ethernet Passthroughs. All the active DB cables would plug into the CoreA switch. All the standby DB cables would plug into the CoreB switch. Pros- Allows for 2Gbps LACP for server NICs Customer using this solution right now in production Cons- Physical single point of failure for the active DB at CoreA Not an Oracle recommended solution. Recommendation: In order, I would recommend the following: 1) Option 2- The Stack solution- This solution provides the highest bandwidth, most fault tolerance, and least amount of cabling of any of the solutions. The cabling distance of 9ft has to be seriously considered. 2) Option 3- The Cisco Standalone solution- This solution removes the Oracle private traffic away from the core. However, the stacked 3750’s could be a less than five nines solution easily identified by the customer. 3) Option 1-The Cisco Core Solution- Running high traffic bonded interfaces across the core of the network raises some alarms. Allows for only 1Gbps throughput to servers. This is the highest latency solution of all of those suggested. Redundancy/resiliency/track record of fully meshed core makes this the most fault tolerant solution- bandwidth and latency are key downsides however. 4) Option 4- Cisco Single Cisco Core- Plugging all the Ethernet cables from the Active DB into CoreA presents a single point of failure that would not allow ASTS to meet a five nines available solution requirement for the Active DB. This is the least resilient of all the solutions.