Warren components placement in DC
Based on network and Storage requirements, several issues can be predicted due to poorly planned location of Warren control plain components such as:
Network congestion or TCP incast in rack-top switches.
One possible solution (in case of 2 physical nodes for control) is to host them in different racks. This leaves the ability in case of the problems above in one rack, to recover all control components in the node in the other rack. Hypervisors are wise to keep in separate rack due to the type and nature of network traffic, but also because of the danger of out-of-control virtualized resources, be that then caused by poor configuration or the applications they host.Low availability markers
Depending on the network topology of DC, the reasons in section 1, but also hardware failures may be the cause of unsatisfactory MTBF and MTTR. For example, if both control nodes are placed in one rack, rack-level hardware failure is causing at least short total downtime during the diagnostics/repair process. That is not, of course, the case, when Warren is used more heavily, than just 3 nodes tryout.
On the other hand, keeping such a level of separation between nodes certainly increases in-DC traffic between racks. So there are no absolute rules in component placement, but rather it depends on an already existing setup, nature of provided services and median/peak traffic levels in racks.