In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-20 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)05/31 Report--
This article introduces how the AWS server farm and database in modern cloud architecture are like. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.
Today, cloud computing technology has become one of the mainstream architectures and Internet infrastructure services. More and more enterprises, organizations and people use cloud services to implement their own service architecture. Cloud computing technology is also a basic skill that every IT person needs to master. In the cloud platform market, Amazon's AWS not only develops early and technologically advanced, but also has a large market share. We take the cloud architecture of AWS as an example to illustrate the modern cloud architecture.
AWS server: EC2 and its instance
The operation of the application mainly depends on two types: server and database. The server, which is used to host the application, allows the user to connect to the server and run the application, while the database is used to hold data.
In the AWS system, the server is organized through Elastic Cloud Compute services (referred to as EC2). Through this service, we can choose the settings of the server, such as operating system, CPU size, internal size and so on. After selecting all the settings, just click the button to start the server. A server created through EC2 is called an EC2 instance. Once the server is started, the application can be placed on the server.
But in fact, the EC2 instance is not a real machine. It's just a virtual machine. As a result, any server we create is actually an isolated virtual machine that shares space on AWS's host hardware. In short, a virtual machine, or VM, is like an analog computer in a real computer. They can have their own operating systems, dependencies, etc., but they use and share the resources of real computers.
An easier way to consider an EC2 instance or any cloud-based server is:
It's still just a computer. It's just someone else's. (in this case, it is AWS.)
We can log in to it, set it up, and do what we need to do on any other computer. You create an instance of EC2 (aka server) and set up the application on it as if you were on your own computer.
Finally, this is all you need to do when configuring the server and placing the code on the server. Manual processes are removed from all tools and automation scripts. However, if you think of it as "just another computer," it's much easier to focus on how to use it.
There will be restrictions on one server. Even if a server (EC2 instance) uses a very powerful configuration, the database is still very important. Generally speaking, the database will take up a lot of computation, a lot of storage space and a lot of network throughput. If the server is a house and the application and database are residents, the database will accumulate all the space and generate a lot of noise. Of course, this works well for local developers. However, when thousands of users (or more) start using the application, if the server has to process both the database and the application, it will quickly run out of resources.
Separate databases: RDS and Aurora
In order to deal with the inevitable hardware and network traffic bottlenecks of a single server, we want to separate the database from the application server. This is done to allow our application and database to be extended separately. On AWS, there are two ways to do this.
The first method is completely manual: create another EC2 instance (that is, another server) and install the database on that instance.
Similarly, if you think of an EC2 instance as "just another computer," it operates in a similar manner as it does on your own computer. For example, download MySQL, set it up, start the database, and allow traffic from the application. But on the whole, it is so simple.
When this is done, you can point the application server to the database server. Database management is its own domain for a reason. There are a lot of patching, updating and maintaining databases is a daunting task. Therefore, unless there is an in-house expert or team dedicated to this, it is really difficult to self-manage.
Another approach is to use the relational database service provided by AWS, also known as RDS.
Specifically, AWS has a very powerful database called Aurora. It can handle all extensions, management and patching. It is also directly compatible with MySQL and PostgreSQL. Therefore, even if you use one of these two methods for local development, you can still use Aurora directly when deploying your application. And, as the RDS marketing team likes to point out, it is five times faster than MySQL and 1/10 of the cost.
This allows users to access your server to use the application, and the application will interact with the RDS Aurora database.
But what happens if there is a peak in traffic? What happens if the service / company of the enterprise develops rapidly? This will be a problem if the database is maintained by a self-built EC2 instance. If you choose RDS Aurora, you don't have to think about the expansion of the database. But there will be another problem, the expansion of the application server.
Server cluster: EC2 Auto Scaling group
In order to solve the expansion problem. Assume that the application is already in use online and is hit by a large amount of traffic. If this is the case, the delay of the small server will not be able to bear too long.
So what choice do we have? Well, let's choose a more powerful, higher-configured instance, which alone is a short-term solution. This method is called vertical expansion. While this can help at the beginning, be aware that the server can only get so big. In addition, it is just a server, there is a single point of problem, if it fails, then all the services running on it can not be used. This is not flexible and is not a good solution.
What is the correct answer? Create more instances to jointly host (load balancing) services. This method is called scale-out. Scale out so that our architecture is not limited to individual EC2 instances.
AWS also provides EC2 Auto Scaling groups for scale-out and load balancing. Auto Scaling groups can be made up of many servers and managed as a whole, and by using Auto Scaling groups, creating and managing multiple EC2 instances is almost as simple as one instance.
So what type of server will Auto Scaling Group create? Before starting the Auto Scalin group, first create the so-called startup configuration, and then create an Auto Scaling group and specify the startup configuration for it. Then it will create instances from the template and manage them for us.
You can think of the startup configuration as a blueprint for an EC2 instance. If this is the case, the Auto Scaling group is like the foreman who uses this blueprint to build and manage instances.
Note: despite its name Auto Scaling group, it doesn't actually extend automatically. This can be done through configuration, which will be described later.
By using the Auto Scaling group, we will be able to create all the servers that can host the application.
Load balancer: scheduling traffic
With RDS services, we don't have to worry about data persistence. However, there may be multiple EC2 instances hosting our application, all pointing to the same RDS Aurora database. Joining us is like three EC2 instances, and one user accesses one of them and changes the name, which does not prevent their applications on the other instances. Why? Because all of our applications point to the same database. Therefore, when a user accesses an application on one of the instances, it still fetches its data from the same RDS Aurora database.
You can now spread the load across three different servers. But the new question is:
Where do our users connect? How do I save the session? And how do we balance the load automatically?
If we had three different instances, they would all have three different IP addresses. If your application uses session data to track users' actions, it will be lost if they jump to another instance.
At this point, a load balancer needs to be introduced. He can solve all the problems just mentioned, and even more. In essence, it is responsible for accepting incoming traffic and distributing it to the server that is best suited to handle it. It sounds like a magical technology. But just as we can set up a database on the server, we can do the same with the load balancer. Just create a server and use a reverse proxy application such as NGINX,HAProxy or Apache. Then, the tools to be selected tell the server to load balance the traffic.
AWS architecture also provides its own load balancer. In EC2, there are a variety of load balancers that automatically do all this work for us, making it very easy to connect to EC2 instances. It also provides us with a lot of options and features, which will require a lot of work if we want to implement it ourselves.
Because they integrate seamlessly with EC2 instances, we don't have to worry about telling AWS load balancers about new instances or instances to be deleted. It can also track session data, perform health checks, and return metrics. All kinds of things.
Once the load balancer is set up, there is no need to direct traffic to any single instance, but to the load balancer itself. Again, it's just another server, so if its IP address is 13.14.15.16 or something, and its load balancing software is listening on port 3000, it can be managed here. Obviously, you want to take advantage of DNS and provide it with a friendly URL, but after that, it will be able to balance traffic between the servers behind it.
The above describes the basic services in the AWS cloud infrastructure, including EC3, Auto Scaling groups, RDS Aurora databases and load balancers (and an AWS S3 service is cloud object storage, which is used as basic storage), which constitute the basic cloud services, which can be used to create most basic application architectures.
So much for sharing about the AWS server farm and database in the modern cloud architecture. I hope the above content can be of some help and learn more knowledge. 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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.