Physical Architecture Design
The physical architecture of each zone is designed based on the characteristics of carried services. Figure 9.2 shows a simple design example, where some zones of the same type are combined for easier demonstration. In the figure, 1 indicates the production/non-production extranet access zone, 2 is the production/non-production Internet access zone, 3 is other network access zone, 4 is O&M management zone, 5 is the production/ non-production intranet zone, and 6 is the core switching zone.
In the production/non-production intranet zone, various application networks and servers are deployed. In the case of complex network
FIGURE 9.1 Example of zones in a DC.
configurations, new services are provisioned and current services are scaled out frequently. This leads to high demand for network automation, and DCs from this zone begin to evolve into SDN. An SDN controller is deployed in this zone to manage switches and firewalls, and it automatically delivers overlay network configurations based on the VXLAN service model in order to implement automatic network deployment.
1. Deploy SDN controllers and cloud platforms based on the fabric plan.
To ensure high security and reliability, an SDN controller and a cloud platform can be independently deployed for each fabric, and a unified service platform matching user services can be developed based on the open interfaces of the cloud platforms. The service platform interconnects with the compute, storage, and network resources of multiple OpenStack systems to implement agile service provisioning and resource pool sharing. Figure 9.3 shows the overall design.
FIGURE 9.2 Overall physical architecture of the DCN zones.
In this mode, multiple controllers are deployed independently, and faults on one controller do not affect another. If a single controller fails, only new services in the fabric where that controller resides are impacted, while the current services in this fabric and services in
FIGURE 9.3 Deploying SDN controllers and cloud platforms based on the fabric plan.
other fabrics remain unaffected. A gray upgrade can be performed in a fabric network prior to a formal version upgrade, and fabrics and SDN controllers can be enabled as required.
2. Deploy SDN controllers and cloud platforms based on service types. SDN controllers and cloud platforms can be deployed based on the fabric plan, or different types of services. Independent SDN controllers are deployed in the intranet service zone, extranet zone, and development and test zone, and are connected to respective OpenStack systems. A unified service platform is developed based
FIGURE 9.4 Deploying SDN controllers and cloud platforms based on service types.
on the open interfaces of the cloud platforms, and this platform interconnects with the compute, storage, and network resources of multiple OpenStack systems to implement agile service provisioning and resource pool sharing. Figure 9.4 shows the overall design.
In this mode, one SDN controller can manage multiple fabrics of the same type, enabling the resources of multiple fabrics to be scheduled in a unified manner and allowing these fabrics to flexibly access one another. For example, it is possible to orchestrate policies for mutual access of services of the same type, for mutual access of different types of services through firewalls, and for mutual access of services across fabrics. Services of the same type can be deployed in different fabrics in order to implement fabric-level DR, improving service deployment flexibility and reliability.