Key to Success

Cloud environments are complex, costly installations with countless individual components. Because they should scale seamlessly across the board, their planning is already far more complex than that of conventional setups. Various basic design parameters are set by the platform's administrator before even a single machine is installed in the rack.

If you are planning a large, scalable platform, you need to do it in a way that leaves as many options open for later as possible. These tasks involve varying complexity at the various levels of a setup. Compute nodes, for example, easily need to be more powerful than current generation systems in a few years' time. If necessary, existing systems are replaced by new ones as soon as the older ones are no longer maintainable.

Critical infrastructure is more difficult. If the network switches are on their last legs, all the power in the world from the compute nodes is not going to help. If the network has not been sensibly planned, its hardware cannot be replaced or scaled easily. Mistakes in the design of a platform are therefore a cardinal sin, because they can only be corrected later with considerable effort or, in the worst case, not at all.

In this article, I look at the aspects you need to consider when planning the physical side of a cloud environment at four levels: network, storage, controller, and compute.

Network: Open Protocols and Linux

The first aspect to consider is the network, because this is where all the threads literally come together. If you come from a conventional IT background and are planning a setup for the first time, you will probably be used to having an independent team take care of the network. Usually, this team will not grant other admins a say in the matter of the hardware to be procured. The vendors are then generally Cisco or Juniper, which ties you to a central network supplier. In large environments, however, this is a problem, not least because the typical silo formation of conventional setups no longer works in the cloud.

Centralized compute management, whether with OpenStack, CloudStack, OpenNebula, or Proxmox, comprises several layers with different protocols. At the latest, when protocols such as the Ethernet virtual private network (EVPN) are used, debugging must always be able to cover the different layers of the cake.

The classic network admin who debugs the switches from the comfort of a quiet office does not exist in clouds like this because you always have to trace the path of packages across the boundaries of Linux servers. Therefore, good generalists should be preferred as administrators over network and storage specialists.

Future Security

The question of future-proofing a certain solution arises when it comes to the topic of networks. Undoubtedly, several powerful software-defined network (SDN) approaches are on the market, and each major manufacturer has its own portfolio. These solutions regularly spread across multiple network layers, so they need to be integrated tightly with the virtualization solution.

However, you do not build a cloud for the next five years and then replace it with another system. If you are establishing a setup on the order of decades, one of the central questions is whether the provider of the SDN solution will still support it in 10 years' time. Will Cisco 2030 still support OpenStack in a way that it remains integrated into Cisco's application-centric infrastructure (ACI) SDN solution? And what is your plan if support is discontinued? During operation, the SDN can hardly be replaced by another solution on a single platform.

In my experience, I have found it sensible to rely on open standards such as the Border Gateway Protocol (BGP) and EVPN when it comes to networks. Switches with Linux offer admins a familiar environment (Figure 1) and are now available with throughput rates of up to 400Gbps per port (Figure 2). In this way, you can build a typical spine-leaf architecture. Each rack acts as a separate Layer 2 domain, and the switches use internal (i)BGP and route the traffic between the racks in Layer 3 of the network.

Figure 1: Open networking allows the operation of switches with Linux so that administrators have the usual tools at their disposal.

Figure 2: Network hardware, such as these Mellanox switches, achieves at least 200Gbps per port – less than 25Gbps does not make sense. © Mellanox

Unlike the classical star architecture, not every lower switch level has less bandwidth available in such an environment. If you later discover that the spine layer is no longer up to the demands of the environment, an additional layer can be added from the running operation – without any downtime.

However, you do not want to be stingy with bandwidth. Redundant 25Gbps links per Link Aggregation Control Protocol (LACP) need to be available for each server, but more is always better.

Open Protocols in the Cloud

If you construct your network as described, you get a completely agnostic transport layer for the overlay traffic within the cloud. EVPN and iBGP are currently difficult to merge with the SDN solutions of common platforms. Ultimately, however, this step is no longer necessary because Open vSwitch, in particular, has seen massive change in recent years. In the form of open virtual networking (OVN), a central control mechanism is now available for Open vSwitch that works far better than Open vSwitch itself. Support for OVN is already found in many cloud solutions, most notably OpenStack, in which it has become the standard, so worries about an end to OVN support are unfounded.