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.