...
There are several factors in DCs network setup that dictates what needs to be thought through in application development process of Warren. Such factors include:
Network
...
Topology
This network topology aspect defines network traffic between components, servers, racks and network traffic between the DC and the internet. Network topology set defines physical extendability properties of the DC, thus, we need to consider:
How will the automated hardware discovery process be handled?
What deployment schema should be used when implementing new nodes?
Which system components are involved in discovery and deployment processes?
How will any non-positive results of discovery and deployments be handled?
Topology types:
tree,
clos
fat-tree
thorus
etc)
We are obviously not able to fine-tune Warrens setup for every type of topology. Topology is not a standalone factor and the set of variables in pre-analysis makes it too costly compared to the business-value of the expected outcome. However we can target discovery and deployment solutions most widely used by DCs with a sufficient degree of quality. Service reliability and availability metrics cannot theoretically be calculated in a platform that is under continuous heavy development. Thus these metrics will rather be defined during the DC adoption and on-boarding process.
The presumption is that the most widely used topologies in Warrens target DC client group are fat-tree and various forms of clos. Based on that, most optimizations are made for these topology types.
Services Offered by DC and Nature of
...
Although, both, this and next point seem to be trivial compared to a real problem magnets like network topology, adopting SDN solution, or better yet, consolidating different SDN solutions; this has become a major issue in public clouds (and presumably also in private ones, where such issues are usually not materialized as a series of scientific papers). Like almost all (except for SDN maybe) network-related considerations, also this one has the quantity-dependent nature.
In-DC traffic amount between racks
End-User Applications
Services offered by the DC (emphasis on RAM vs CPU vs Local or Distributed storage) and thus similarly the end-user application resource needs need to be discussed and understood. This point has a quantity and volume dependent nature similarly to network-related questions and deserves careful consideration and planning so suggestions on hardware needs can be made.
Data Traffic Volumes Between DC Hardware Racks
Data traffic volumes between hardware devices are measured to define the efficiency of Warrens service system. In case a larger DC installation is considered DC traffic between silos is additionally measured. The bigger the amounts of data-flow between hardware devices , the bigger of a problem it tends to be. This traffic (and also In-DC traffic between silos, if larger DC is under consideration), is the one that measures the service system (Warren) efficiencycreates. It's a two-fold problem, first by the traffic that is generated by the clients, secondly the one applications and end-users and secondly by the traffic that is generated by Warren as a management system.
The goal of Warren is to reallocate resources to minimize ininternal-DC traffic and in . In rare cases , it can, by doing so, destabilize this can result in destabilising the network flow for a short period of time. Management flow must always take precedence when client In cases where client application related data flow is causing problems, even if it decreases client throughput further. Because it’s system management related data flow must always take priority, even in cases where client throughput as a result decreases further. The purpose is to restore the systems previous state , or at least maximize maximise the efficiency with the currently of limited amount of available resources in a given point in time.
DC Existing SDN solution
In general, all SDN systems are based on the same principles an in major part, derived from two prevalent frameworks for SDN generation. There are several types of protocols when it comes to network device configuration, among which, OpenFlow is still the most dominant one. Almost all needed routing protocols are also supported by all major SDN solutions.
To conclude the above, there shouldn’t arise any drastic problems on a connection basis (which doesn't mean it's a trivial task!). However, there is an exception to that hypothetical balance - the security domain. All SDN systems implement some (or more) security domains, whether it’s client level or system-wide. To configure 2 or more SDN systems to cooperate simultaneously on that domain, might be more time consuming than configure the whole system to use adopt a new one.
Considerations and Goals in the
...
Storage Domain
Warren Warrens storage domain consists of three options:
Distributed storage
Shared storage
Local storage
To determine the right most desirable solution, one must the DC needs to consider several factors that are required to implement a particular storage type. As storage Storage holds the most valuable part information - client application data, so the impact on the reliability and to QoS. Afterall - Quality of Service is immense. In comparison network outage only affects the availability of data, whereas storage problems may lead to permanent data loss.
Distributed
...
Storage
Pros: reliable, multi-functional,
...
scalable
Cons: expensive
The cost of a distributed storage (that may also be shared-distributed) comes from the fact that distributed is usually (not always - one exception is HCI) implemented as a separate cluster(s). So there are three main types of costs and an additional, optional one:
...
The reliability advantage compared to shared or local storage should be obvious.
Shared
...
Storage
Pros: cheaper, faster
...
Cons: half-baked reliability
If infrastructure includes a direct-attached storage unit used as a shared storage solution, there is a high chance that the vendor has included the device software that operates with the device. There may even be distributed solution working in this unit but it must be kept in mind that this kind of storage is distributed within the device itself. If the storage device should fail, all the data is still unreachable - the data protection works at the disk level.
To raise the protected sphere to the rack level, several such storage units must be placed in one rack. Now if Infrastructure contains more than 2 racks (which should be the normal case for DC), why are they not separated from compute units to form the autonomous distributed storage cluster? One answer to that might be the performance. As off-the-shelf storage units usually include “real RAID” controllers (with detached CPU and cache) and connection to compute units is direct (not over the network) the performance may be significantly higher than that of the distributed storage could offer.
Local
...
Storage
Pros: cheapest
Cons: not fastest
Nowadays, the cost of the TB as a single disk is very low compared to the same capacity implemented in the form of an advanced storage device. However fast the single disk might be, it couldn’t compare with the direct-attached, performance-tuned shared storage system.
...