Shulou(Shulou.com)06/01 Report--

This article is about how to understand the high availability of DevOps components ideas, the editor feels very practical, so share with you to learn, I hope you can learn something after reading this article, say no more, follow the editor to have a look.

Introduction:

Previously deployed applications or services are basically self-contained and will not be affected by others. Under DevOps, this mode of deployment is also changing. Because the application or service itself involves more and more components. DevOps concatenates applications or services and the components involved in applications and services to ensure the normal operation of all applications and services.

1. Traditional high availability

Under the traditional production mode, services such as applications, middleware and databases need to be highly available. To avoid downtime of business services.

Common deployment methods include service master / slave, service cluster, and high availability solutions of two places and three centers.

Highly available common metrics, as well as service downtime.

Https://en.wikipedia.org/wiki/Mean_time_between_failures

MTBF = MTTF + MTTR

36524* (1-0.99) = 87.6. In practice, the shorter the failure time, the better.

System availability ratio = MTTF/MTBF

II. Brief introduction of DevOps

The change brought about by 1?DevOps is that the entire deployment process is automated and the deployment cycle is shorter. The focus of development and operations has also changed. Developers can complete the changes in a very short time from submitting the code to seeing the changes.

two? In the process of actual contact, because DevOps concatenates multiple application services, many people will propose that all components concatenated by DevOps must be highly available. As a result, the problem arises, which makes the original simple and clear architecture has undergone great changes.

The changes brought about by 3?DevOps are different from the traditional high availability.

Third, the traditional high availability architecture model

Description: a simple way to make Gitlab services as master / slave, or master / master. Such Gitlab services have gone from a single point to a slightly more complex architecture.

In this way, our harbor has also become highly available, and when it is concatenated through the program devops, the operation and maintenance become more complex. Of course, DevOps can concatenate more components, here are just two examples.

IV. The changes brought about by DevOps

In the era of DevOps, when the cascade components are highly available in DevOps, the requirements for components have also changed. Because DevOps has the function of concatenation, we want all components to be highly available or distributed, and all services to be decoupled.

As you can see from the figure, the APP layer is a simple distributed one. This may be a typical architecture that we often deploy. Simple distributed design of the APP layer. Other components still follow the traditional cluster deployment model, but in this architecture deployment mode, it increases the difficulty of operation and maintenance.

Complex distribution looks simpler than simple distribution in the diagram. But in practice, you will find this very difficult. Because APP, Cache, DB, Storage and so on are distributed, this complexity not only puts forward high requirements for architecture, but also increases the difficulty for operation and maintenance. There are fewer pictures in the picture, but in fact there are much more complex distributions than that.

Maybe the cluster is distributed. Maybe the cluster only solves the high availability, while the distribution solves the high concurrency and high performance problem, maybe the cluster is part of the distribution. Everyone has their own understanding, understanding your own business, needs, and so on.

In fact, there is another technology that can help us achieve distributed deployment, which is container technology. Through kubernetes to achieve their own needs of the high availability of applications and the application of parts.

With the advent of microservices and devops, containerized microservices and devops are better implemented. The highly available kubernetes provides us with the basic container platform and container scheduling capabilities. Kubernetes is inherently fault tolerant.

You might say that scale-out is not a highly available architecture. But if you take into account the changing resource requirements of your business, you will find that the deployment of kubernetes is very useful to you. When traffic surges, you can take advantage of the scale-out capabilities of kubernetes. Instead of starting from scratch as before.

At the same time, reliable monitoring of Kubernetes itself is very important for highly available systems. Using a lot of commercial software or a lot of open source tools for integration or even self-development can grasp the overall business situation and system status. Additional open source software such as promethus can also be used to monitor the state of the business.

The above is how to understand the idea of high availability of DevOps components. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.