This content has been marked as final. Show 4 replies
robinsc wrote:It is not typical. That statement is incorrect.
During the Exadata three day training from Oracle university ( and also in the student guide) we were told that merging of the Exadata client network and management network were quite typical . On the Exadata Database Administration Workshop page 8-11 it states ' The client access network can be separate from the management network ( as in the diagram ) or both functions can be provided by the same network.Single network configurations are quite typical.
However in the Exadata User's guide and in the configuration worksheets it states that these need to be separate.You don't need to dedicate a subnet for Exadata Database Machine. The downsides that immediately come to mind are these:
Which is correct and are there any downsides to combining the functions ? We do not want to waste a large subnet on something that is unlikely to see any expansion...
1. There is no redundancy in the management network and no redundancy possible since all connections go into a single 1GbE switch in the rack. (This single reason is enough for just about everyone to stop reading and look for another option.) We recommend bonded connections to the client access network with each of the 2 interfaces going to separate switches in the customer's client access network VLAN.
2. There are bandwidth concerns since there is only a single 1GbE uplink from the management switch to the customer network. All nodes share that single uplink. Think of two people in a house sharing an internet connection...if one starts a huge download, the other notices immediately.
3. You're limited to 1GbE. The DB servers also have 10GbE available and would be preferred if application bandwidth requirements are expected to be large.
4. See #1 again - completely no possibility of redundancy. For most customers, #2 and #3 don't really matter after #1 is stated.
So would like to eliminate the client network requirement if possible.Finally - consider that all of the testing done in-house by development, QA and all the other groups use the network layout shown in the product documentation. That is, separate management and client access networks. To get the best value from the system you're deploying, you want to leverage all that testing that Oracle does. Varying the network configuration significantly would mean that a significant portion of the testing Oracle does would not apply directly to your environment, so you'd have to invest in testing and stressing all aspects yourself. It's always a good idea to test on your own, but you'd be starting "from scratch" instead of taking advantage of the testing already done for HA, NIC failover, etc.
Dan is right on this one (once again). I've worked on at least 30 different Exadata racks - he's worked on tons more than that - and I've never seen the management network merged with the client access network.
What they may have been discussing was having the management and public networks existing on the same subnet. While it is possible, it's not recommended by Oracle. The management and public networks were designed to meet different needs. The management network has backend access to all of the components on the Exadata (ILOMs, IB switches, KVM, etc). The public network is only to be used for database client traffic. In most environments, the network is segmented so that application servers can only access the public network. This keeps the application servers from getting access that they do not need.
What they may have been discussing was having the management and public networks existing on the same subnet.
But that would imply having two network cards with different ip addresses on the same subnet... which would be a routing problem...
The document I referred to is an Oracle University document ....
And I believe it is still unchanged.....
Regarding the statement: "The client access network can be separate from the management network (as illustrated in the diagram) or both functions can be provided by the same network. Though not recommended, single-network configurations are quite common."
The original intention of these sentences was to indicate that the client access and management networks could share the same physical infrastructure even though they are separate networks using different subnets.
It was never intended to indicate that the networks could be merged into the same subnet.
The statement will be removed from future editions of the course notes.
Sorry for the confusion.