Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to define VPC in the context of private cloud. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

A few days ago, ZStack launched a new version of network architecture VPC 2.0. as an important feature in ZStack 2.3.0, VPC 2.0 provides comprehensive and powerful support for network functions, including flexible network configuration, secure and reliable logical isolation, and enabling distributed routing functions. Advanced strategies such as optimizing east-west network traffic and interworking between different subnets without direct interconnection through cloud routers It can meet the implementation of rich network scenarios.

After years of market education and practice of VPC, most public cloud users have accepted that VPC is an essential basic component in the public cloud. But for private and hybrid clouds, how to ensure business security? How to take full advantage of the potential of the cloud? It is not clear whether or not to follow the past design experience of virtualization.

What attempts has ZStack made in private and hybrid cloud technologies and products? How does VPC2.0 address the business requirements of network flexibility and scalability? How to define VPC in the context of private cloud?

What problems and pain points does Q1:VPC2.0 solve in the construction of private and hybrid clouds, as well as its best application scenarios?

In ZStack VPC1.0, the concept and design of VPC mainly comes from the design of public cloud for isolation, but lacks in many aspects such as current network access and network flexibility, and can not fully meet our needs in complex private cloud and hybrid cloud scenarios. Therefore, ZStack has made a lot of changes to the network model, focusing on improving flexibility, ease of use and performance.

At present, most of the IaaS products VPC come from the public cloud, focusing on security and isolation. On the basis of security and isolation, ZStack VPC2.0 considers a lot of users' actual use scenarios, software-hardware use scenarios, obsolete scenarios, etc., and brings a feature-rich and easy-to-use VPC2.0 on the basis of the existing VPC1.0, which can meet the enterprise's large-scale deployment from dozens of virtual machines to tens of thousands of virtual machines. And will fully dock the hybrid cloud VPC to complete a new definition of private cloud VPC.

What is the main value that Q2:VPC2.0 brings to users?

Flexible network configuration

Safe and reliable isolation

Rich network scenarios

Lower administrative costs

Higher network performanc

What direction will Q3:VPC technology develop, and what network optimization will be carried out in the next step?

The next step is first of all on more open network functions. We hope to open up the network functions into a platform, not only with the network services we provide, but also with NFV, firewall, monitoring and other products from various manufacturers can be seamlessly connected to the ZStack cloud platform, so as to further improve efficiency and reduce user use and operation and maintenance costs. At present, OPNFV and other organizations, OpenDaylight and other projects have done some work, but it is still a long way from being delivered to users.

The second is more automation. At present, there are inevitably some manual processes for hybrid cloud opening and tunnel establishment, which are many steps that users need to wait for and are the most error-prone. In the future, we hope to make this process more efficient by introducing technologies such as SDWAN, and show customers the current network status and quality carefully and intuitively, so that users can "fool" for error checking and management.

Next, we will give you a detailed interpretation of the design ideas and architecture of ZStack VPC 2.0.

Safety

When users use the public cloud, the first consideration is often security. Over the past year, various security incidents have occurred continuously, making users hesitate that such a problem does not exist in the private cloud-from the cabinet to the power supply is completely under the control of the enterprise itself, and expensive network security devices are often deployed at the exit, which is naturally better to ensure the enterprise's exclusive network and data than walking the data on the network line shared with others. But it also brings a lot of operation and maintenance costs to users.

Therefore, how to reduce the security operation and maintenance costs of users on the premise of ensuring security is our first consideration. It is important to know that network isolation and flexible computing are naturally opposed to each other-the more detailed the isolation, the more difficult it is to rapidly expand capacity, arrange services, and recover resources, and this difficulty increases exponentially with the number of businesses.

In the past, we might have thought that firewalls at the exit would be sufficient to withstand all attacks-like setting up a castle in the middle of a storm, with the outer walls getting higher and higher in an attempt to resist all attacks.

But in fact, with the rise of SaaS services, the enterprise Internet and more and more devices involved in corporate intranets, this design is becoming more and more difficult to maintain:

Enterprises have more and more external data and network portals, such as websites, employee VPN, purchased SaaS services, external API services, data channels provided for the developed website App or mobile phone App, and even mobile phones connected by employees themselves may have security risks, so that enterprises need to set up more and more external walls and higher and higher.

The explosive growth of applications, in the past, the expansion of an application may be calculated in monthly or even quarterly units, and once on the shelf may be enough to support business growth within a few months, but now under the rapid outbreak of the Internet, once the application is well received, it may spread rapidly, which puts forward extremely high requirements for computing capacity expansion, while artificial network changes are prone to errors and leaks.

The demand for hybrid cloud brought about by the explosive growth of data, in parallel with the growth of business, is the growth of storage demand and the continuous improvement of data value. More and more enterprises have a richer demand for storage-in addition to traditional SAN and NAS, some businesses may need ultra-high performance, some businesses need object storage, cold and hot separation, a large number of log storage and so on. It is not cost-effective to purchase equipment completely at this time. It is undoubtedly feasible for me to dock with public clouds to form hybrid clouds, but the network requirements are more complex.

In this situation, Google put forward the security architecture of BeyondCorp, its basic idea is: security isolation is no longer based on IP, MAC but applications, account access control is no longer static, but dynamic, automatic follow to restrict business access rights and even protocols, but how to apply this advanced security architecture to enterprises? How can a private cloud help customers achieve these security goals? Let's look at a network design under the ZStack architecture.

Two-layer isolation

For all network isolation, nothing is more thorough than layer 2 network isolation. However, the traditional layer 2 network isolation is based on VLAN or 802.1ad, the former has few domains available, while the latter is too troublesome to configure. Fortunately, ZStack has provided VXLAN as a network isolation technology since 2.0.

Unlike most IaaS on the market, ZStack provides extremely flexible and rich methods to configure VXLAN network. ZStack records VXLAN's Underlay network Overlay network as VXLAN Pool and VXLAN Network. The former is used to load into the cluster, load VNI Range, and so on. When loading, you can select the address field of VTEP, and ZStack will automatically find the appropriate VTEP address and load it.

Each cluster can use a different VTEP address range, and administrators can arbitrarily define the VNI range, share the Pool with end users or departmental operation and maintenance personnel, and then create a VXLAN network on it. The whole process is highly automated and flexible-even the address needed by VTEP on the server has been modified for some reason, and you only need to reconnect the physical machine on the ZStack interface to automatically synchronize!

In production practice, VXLAN can be deployed separately for the required business, or VXLAN can be assigned to the business unit for its free configuration to ensure its lowest-level network isolation-no matter the underlying ARP spoofing or high-level service sniffing can not break through this barrier.

Custom rout

Since ZStack 2.1we have provided the ability to customize routing, which seems to have nothing to do with security, but it is not.

First of all, in the public cloud, the public network is often better defined-it must be Internet, the only difference is that it may be a telecommunications network or Unicom network or BGP network and so on. This is not the case in the private cloud. The private network in the private cloud must be the network where the business is deployed, while the public network may not be the Internet, for example, the architecture in the figure below:

Suppose we have two VPC deployed with three businesses, in which the application and database are placed in a VPC for performance considerations, while the Web service is a public service in a separate VPC. In this case, the application service can be routed through the cloud and take a custom route to the VPC2. Here VPC2 uses our cloud routing to support multiple public networks, which must be used in conjunction with custom routing.

In addition, how to ensure the security of the database? Not to be infiltrated or detected? Security groups are on the one hand, on the other hand, in order to prevent the database from being discovered externally by probe traffic and unexpected routes, we can also specify black hole routes in ZStack:

This completely ensures that the address field of the database service will not be leaked outside the VPC.

Considering the routing complexity of complex networks, ZStack also provides API for administrators to see which routing entries in cloud routes are in effect and which, although configured, are not.

Source-based security group

The traditional security group is based on IP, protocol and port. It is difficult to say how many advantages such a security group has over traditional ACL and zone based firewall except for policy following (virtual machine drift does not affect the effectiveness of its security policy).

However, ZStack has provided source-based security groups since 2.1. that is, security groups can be used as a security domain. ZStack can automatically identify traffic from different security groups, thus achieving flexible access control without repeatedly setting IP or network segments, reducing errors and improving efficiency.

As shown in the figure above, we can set security group rules for the source security group. For example, security group 1 can configure which ports are open when the source is from security group 2 and which ports are opened when the source is from security group 3.

Other

In addition, ZStack has many other security technologies, such as source address filtering to prevent IP and MAC address forgery, DHCP server forgery prevention to prevent users from obtaining addresses from the wrong server, and so on. Through the effective use of these technologies, administrators can make a secure and reliable network according to their own needs and actual environment configuration.

Unlike private clouds and public clouds, the settings and use of these systems can be configured and used by users. At the same time, users can access some existing security devices such as WAF, firewall, traffic cleaning, and so on. Please refer to the following.

Flexible

For the public cloud, all the rules are decided by the supplier, and the supplier often defines these rules according to their own considerations or technical limitations. On the one hand, the network use on the cloud is different from the traditional one, and some management operations bring inconvenience. For example, the public cloud database brings the convenience of scale, but also brings the inconvenience of debugging. On the other hand, it is easy to form all in for the use of its resources. For example, we may only want to use the database on the public cloud, but we have to move the business virtual machine to the cloud, and then we have to migrate the storage system, backup system and even a set of matching content, which brings a lot of inconvenience.

When we design a private cloud, all of this needs to be considered, rather than thinking that the customer's needs are unreasonable on the grounds that "the customer needs to design the Cloud Native." In particular, ZStack is a product-oriented private cloud, products will continue to upgrade, not only to add new features and scenarios, but also to be compatible with the old design and use, or even unreasonable use by users.

ZStack VPC 2.0 brings the following highlights in terms of flexibility:

Multiple network service multiplexing address

A common requirement for small and medium-sized private clouds is that there is not enough IP address for the public network, especially if the common network is a real IPv4 address on Internet.

ZStack provides users with a wealth of network services, including but not limited to elastic IP, load balancer, IPSec VPN, port forwarding, SNAT, and so on. At the same time, users'IP addresses may be limited. For example, users have only one address but want to use SNAT to access virtual machines to the public network and to connect to hybrid clouds as addresses of IPSec.

This requirement is feasible in the data plane, but it poses a great challenge to the control plane of the cloud platform. The cloud platform should well coordinate the IP requirements of each service and configure it reasonably to the cloud routing. Since ZStack 2.3.0, we have supported an IP for load balancing, IPSec, port forwarding, SNAT and other services that do not require exclusive IP! And users can define the use of their ports at will, and from then on, VIP is completely opened from a network attribute to a pooled resource, which greatly liberates the use of IP in private clouds.

In addition, considering that each service uses a different port (outside of SNAT), different QoS can be made for each port in ZStack to achieve the ability to QoS not only VIP itself, but also different services.

Physical network access

In the private cloud, the access to existing devices or networks is also an unavoidable problem. On the one hand, enterprises should avoid the waste of investment, and on the other hand, the performance or function of many software can not be comparable to that of hardware in a short time, such as application delivery controller ADC, flow cleaning equipment and so on.

In order to solve the access of physical devices, ZStack provides many schemes, such as multi-public network, custom routing, multi-network card, VXLAN gateway and so on. Among them, the first two have been introduced before, and multiple network cards are easy to understand. The scheme based on VXLAN gateway is because ZStack uses the standard VXLAN protocol, so other network devices using VXLAN protocol can theoretically negotiate with the VTEP of ZStack to form the same VXLAN Underlay network, achieving the effect of mixing virtual network and physical network.

In many cases, cloud network technology will optimize traffic through DVR, resulting in a series of problems caused by forged gateways, resulting in increased complexity of operation and maintenance and even some requirements can not be realized. This problem does not exist in ZStack, which will be described in the following distributed routing.

Network service follows

In many clouds, network services are defined in VPC and implemented on top of cloud routing, so cloud routing becomes a key role of VPC. Public clouds often avoid exposing cloud routing directly to users, while private clouds often list cloud routing operations as a key operation-users cannot delete or uninstall them at will, otherwise network services may disappear.

However, it is different in ZStack. We believe that users' network service creation is business-oriented and business-oriented (especially elastic IP, port forwarding, etc.). At this time, it is not advisable to lose network services if we want to transfer virtual machines to another VPC or delete cloud routes. By implementing the network service to follow, we achieve that once the network service is created, it will follow the virtual machine instead of the cloud route. If the cloud route is deleted, once it is recreated or loaded, all network services will be automatically re-applied-- just like the NAT rules from now on no longer rely on an actual firewall, but directly bind to your business, even if you change a firewall and rebuild a firewall. The system will always try to help you restore your business so that resources are truly pooled, undependent, and completely flexible.

As shown in the figure above, although network services are defined on cloud routing, they are eventually used for VM2, so VM2 does not disappear. No matter what happens to cloud routing, network services will eventually be applied to VM2.

Performance

Although it does not host a million or more virtual machines in a single region like the public cloud, the private cloud is not without performance requirements, and even as the needs of users change, we need to be able to adapt to the scale requirements of users from small to large. Small-scale do not waste additional resources, large-scale should also have a plan to deal with it.

In particular, after the cloud route is connected to multiple subnets, the traffic on it may become very large due to the enterprise's demand for east-west traffic. If a cloud route becomes the performance bottleneck of the entire network, it will not be accepted by users, except for the single point problem. The performance is also considerable.

Traditional network protocols generally define the whole process as centralized, such as DHCP servers, such as routing gateways, and centralized control also brings convenience in implementation-especially services such as SNAT and routing table, while some services we find that it can actually do distributed optimization through some means, and its importance is worth doing, such as DHCP and gateway.

Distributed DHCP

ZStack supports distributed DHCP from the earliest Flat network, but the cloud routing network is centralized DHCP. From 2.1, we began to change the cloud routing network DHCP to distributed design, and inherited into the VPC network.

Distributed routing

Distributed routing is a very important feature in ZStack VPC 2.0. Unlike some DVR implementations in the industry that are limited in scale or even fragile and difficult to apply to production, ZStack VPC 2.0 has been carefully considered at the beginning of its design, so it has the following characteristics:

No prior knowledge

No message queue

No gateway spoofing

Non-centralized controller

Instant switch

First of all, no prior knowledge means that the whole traffic optimization system does not need to pull information from the ZStack database. Why is this important? Because there is a very important point in the ZStack design principle, that is, the separation of the control plane and the data surface, the failure of the control plane will not spread to the data surface, in any case priority to ensure that the user business will not be affected.

Under this design principle, we naturally cannot pull the information of the ZStack database-even if all the network information is recorded on the ZStack database, on the one hand, we can not guarantee the permanent downtime of the database, on the other hand, the data of the database can not really reflect the state of the network, and users may modify their IP, create virtual network cards and so on at any time.

Second, there is no message queue. The execution of DVR control data through message queues in OpenStack is ultimately considered an ill-considered design, because message queues have both capacity limitations and their own reliability problems, so ZStack DVR abandons message queues and implements a private protocol called ZSNP (ZStack Network Protocol), through which messages are delivered directly on the IP layer. It also realizes the function of delivering the signaling directly to the Host on the Host without knowing the information of the virtual machine.

Third, there is no gateway cheating. The traditional DVR is based on gateway spoofing, which is very straightforward-since I want to be a gateway, I must implement a pseudo gateway. At the same time, it brings a series of problems, such as preventing gateway leakage, judging between pseudo gateway and true gateway, and so on. Moreover, it is easy to make user-defined routing difficult to implement and physical devices difficult to access.

ZStack hopes that when doing distributed routing, one should be reliable, and the other is to avoid affecting users' habits as far as possible, so it realizes the stateless traffic optimization without gateway deception, so it is completely compatible with all the functions of the past, and users can also enjoy the benefits of distributed routing transparently.

Fourth, there is no centralized controller. In the traditional DVR design, in addition to interacting with the CMS database, there is often the problem of centralized controller, so once the controller fails, the traffic can not be optimized, or the network interruption is serious, which is unacceptable to users.

In ZStack VPC, traffic optimization is initiated by Agent in cloud routing. Each Agent only cares about the traffic on its own cloud route, so there is no system single point, and such an Agent is similar to a side-hanging mechanism rather than a direct connection, so even if the Agent dies, it will not cause network failure. Instead, optimized traffic gradually falls back to the traditional centralized path.

Finally, an interesting feature is that the distributed routing of ZStack VPC is up to users to decide whether to enable it or not, and through the introduction of the previous principle, we can know that this switch is distributed on each cloud route. Users can choose to enable part of the cloud route and turn it off, and this switch takes effect immediately, and the shutdown will completely fall back to the traditional path after the rule aging.

In addition, ZStack VPC 2.0 still has a lot of potential to be tapped-- such as network connection detection based on optimized data, optimized traffic statistics, and so on, which will be gradually launched in future versions.

This is the end of how to define VPC in the context of private cloud. I hope the above content can be helpful to you and learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.