How to tame clouds: examples of practical use. What is there on the technical side?
The fifth post, written by Mikhail Mikheev on his practical experience in vCloud IT-GRAD :
“From a technical point of view, vCloud Director is an add-on application over vSphere. It has information about clusters and pools, distributed switches and port groups, and storages. The task that this add-in solves is to conveniently allocate the above resources to groups of virtual machines — the essence of the interface.
As already mentioned, it is based on the correct hardware + vSphere + vCloud Director, Datacener Tier 3 and the most advanced technology platform for building a virtualization infrastructure.
')
Details:
But on the means of turning the infrastructure into the cloud, we’ll dwell a little bit more - so that there is an understanding of what can be done with it.
The key object of the cloud we are talking about is VMware vCloud Director.
From a technical point of view, vCloud Director is an add-on application over vSphere.
It has information about clusters and pools, distributed switches and port groups, and storages.
The task that this add-in solves is to conveniently allocate the above resources to groups of virtual machines — the essence of the interface.
On the one hand, the interface for the cloud provider administrator is to divide a lot of many available resources into “clouds” of different customers.
On the other hand, providing the interface to an administrator, or a customer representative without the skills of a system administrator, for deploying virtual servers, working with them, and managing the intraclouds network.
That is, it is enough to indicate to the administrator or operator - to allocate so many resources to this customer. For a processor, these are megahertz, gigabytes for memory, in which storage (roughly faster / slower) to locate disks of its VM, which networks are available (more detailed about networks later).
Now the company administrator, who receives this cloud at his disposal, in a couple of clicks creates the necessary number of virtual machines for himself, allocates the necessary number of resources to them within the specified limits and connects them to the necessary networks. Everything, then you can begin to do the work we need. Details of what and how - were given in previous posts.
If everything is pretty clear with the allocation of processor performance, memory and disks - usually how much we have specified for our VMs, we received so much and paid for so much; I will tell you a bit more about networks.
For example, what I see when I go to the appropriate section of the interface (Fig. 1):
Figure 1. Cloud networks
Here I see two networks available to me. They are quite clearly called NAT and Internal.
What does this mean (Fig. 2):
Figure 2. Illustration of default intracloud networks
That, if necessary, we will connect some VMs to an isolated network, and some - to a network with access to the outside world.
Moreover, even groups of virtual machines connected to one network with one tick (Fig. 3) can be isolated from each other - as if they are connected to different switches - to lift several identical configurations it can be very convenient not to worry about the absence of conflicts in our network.
Figure 3. Automatic isolation of this group of virtual servers in the internal cloud network
In this screenshot you can see the step of the wizard for deploying vApp from a template - this is where we can specify the isolation of this vApp from others, even if it is connected to the same Internal or NAT network.
Moreover, the VMware cloud infrastructure allows us to do all the trivial things in a very trivial way. If we go into the network properties from the first picture, we will see the following settings:
Built-in DHCP - it is already present out of the box, we just customize it for ourselves (Fig. 4).
Figure 4. Setting up a regular DHCP server
Configure a firewall to protect our virtual machines from the dangers of the outside world (Figure 5).
Figure 5. Configuring a regular firewall between the outside world and the NA network
What public IP addresses are available to us (not in the screenshot, but there is just a list), and port mapping settings (Fig. 6).
Figure 6. Configuring port forwarding from outside to a NAT network VM
Thus, we can implement any version of the interaction of virtual machines we need with each other and, if necessary, with the outside world. Moreover, for simpler cases, the DHCP server, firewall and NAT servers offered by the infrastructure itself will suffice. DNS is, of course, also provided.
So, in a short time I created a couple of vApp-sets of virtual machines that I needed (fig.7):
Figure 7. Infrastructure for my task
You can open a console to any virtual machine and, with the minimal configuration of NAT, rdp or any other necessary session.
On any group of virtual machines (there are three of them in the previous figure), in the context menu it is possible to save this group as a template - and then trivially replicate once prepared virtual machines, moreover, with depersonalization, if necessary (Fig. 8.9).
Figure 8. Starting the deployment of a VM group from a template
Figure 9. Steps to the VM Group Deployment Wizard from a template
The test environment is deployed.
List of virtual machines (Fig. 10).
Figure 10. List of virtual machines from all my cloud groups
Consoles open to them, RDP, the View client connects to desktops - in general, everything is in the ointment.
A separate advantage is the ease of building network infrastructures. For example, for the View, the task of deploying a security server acting as an intermediary may be relevant. And within the framework of enhanced protection, it will be correct to divide the network into external and internal, see the picture (Fig. 11).
Figure 11. Illustration of changing the View infrastructure
So, the transition from configuration one to configuration two is again a couple of mouse clicks. Add a VM, indicate that it has two network interfaces, that one is connected to the internal and the other to the external network. Well, install the required service inside.
In principle, the minimum problem has been solved - I installed the necessary operating systems, the necessary applications, completed the required settings.
The task is optimum and the task is maximum - a pilot project and implementation. They will require a minimum of effort. Look here (fig. 12).
Figure 12. Illustration of the triviality of loading servers from the cloud to themselves
As you can see, in a couple of clicks we can unload the “acquired by overwork” to ourselves, and start up well-established and knowingly working services already at home. Moreover, there is no dependence on the arrival of our local iron — we will unload when we are ready (fig. 13, 14).
Figure 13. Downloading from the cloud to us locally
Figure 14. From these files, you can import a loaded VM group to your local vSphere
And if we like everything in the cloud - why unload it? We continue to exploit the services we need in the cloud, continuing to use all the buns. This is the absence of the need to invest in their local hardware, and adding resources at times, and the lack of a headache about low-level administration, the highest availability.
So, according to the results of testing, you can also implement your solution in the production environment in the cloud - most likely you will like everything.
And then we will talk about other types of tasks that can be solved with the use of such infrastructure, and about the near future - what other nice things will be added.
“From a technical point of view, vCloud Director is an add-on application over vSphere. It has information about clusters and pools, distributed switches and port groups, and storages. The task that this add-in solves is to conveniently allocate the above resources to groups of virtual machines — the essence of the interface.
What is there on the technical side? Details ...
As already mentioned, it is based on the correct hardware + vSphere + vCloud Director, Datacener Tier 3 and the most advanced technology platform for building a virtualization infrastructure.
')
Details:
But on the means of turning the infrastructure into the cloud, we’ll dwell a little bit more - so that there is an understanding of what can be done with it.
The key object of the cloud we are talking about is VMware vCloud Director.
From a technical point of view, vCloud Director is an add-on application over vSphere.
It has information about clusters and pools, distributed switches and port groups, and storages.
The task that this add-in solves is to conveniently allocate the above resources to groups of virtual machines — the essence of the interface.
On the one hand, the interface for the cloud provider administrator is to divide a lot of many available resources into “clouds” of different customers.
On the other hand, providing the interface to an administrator, or a customer representative without the skills of a system administrator, for deploying virtual servers, working with them, and managing the intraclouds network.
That is, it is enough to indicate to the administrator or operator - to allocate so many resources to this customer. For a processor, these are megahertz, gigabytes for memory, in which storage (roughly faster / slower) to locate disks of its VM, which networks are available (more detailed about networks later).
Now the company administrator, who receives this cloud at his disposal, in a couple of clicks creates the necessary number of virtual machines for himself, allocates the necessary number of resources to them within the specified limits and connects them to the necessary networks. Everything, then you can begin to do the work we need. Details of what and how - were given in previous posts.
If everything is pretty clear with the allocation of processor performance, memory and disks - usually how much we have specified for our VMs, we received so much and paid for so much; I will tell you a bit more about networks.
For example, what I see when I go to the appropriate section of the interface (Fig. 1):
Figure 1. Cloud networks
Here I see two networks available to me. They are quite clearly called NAT and Internal.
What does this mean (Fig. 2):
Figure 2. Illustration of default intracloud networks
That, if necessary, we will connect some VMs to an isolated network, and some - to a network with access to the outside world.
Moreover, even groups of virtual machines connected to one network with one tick (Fig. 3) can be isolated from each other - as if they are connected to different switches - to lift several identical configurations it can be very convenient not to worry about the absence of conflicts in our network.
Figure 3. Automatic isolation of this group of virtual servers in the internal cloud network
In this screenshot you can see the step of the wizard for deploying vApp from a template - this is where we can specify the isolation of this vApp from others, even if it is connected to the same Internal or NAT network.
Moreover, the VMware cloud infrastructure allows us to do all the trivial things in a very trivial way. If we go into the network properties from the first picture, we will see the following settings:
Built-in DHCP - it is already present out of the box, we just customize it for ourselves (Fig. 4).
Figure 4. Setting up a regular DHCP server
Configure a firewall to protect our virtual machines from the dangers of the outside world (Figure 5).
Figure 5. Configuring a regular firewall between the outside world and the NA network
What public IP addresses are available to us (not in the screenshot, but there is just a list), and port mapping settings (Fig. 6).
Figure 6. Configuring port forwarding from outside to a NAT network VM
Thus, we can implement any version of the interaction of virtual machines we need with each other and, if necessary, with the outside world. Moreover, for simpler cases, the DHCP server, firewall and NAT servers offered by the infrastructure itself will suffice. DNS is, of course, also provided.
So, in a short time I created a couple of vApp-sets of virtual machines that I needed (fig.7):
Figure 7. Infrastructure for my task
You can open a console to any virtual machine and, with the minimal configuration of NAT, rdp or any other necessary session.
On any group of virtual machines (there are three of them in the previous figure), in the context menu it is possible to save this group as a template - and then trivially replicate once prepared virtual machines, moreover, with depersonalization, if necessary (Fig. 8.9).
Figure 8. Starting the deployment of a VM group from a template
Figure 9. Steps to the VM Group Deployment Wizard from a template
The test environment is deployed.
List of virtual machines (Fig. 10).
Figure 10. List of virtual machines from all my cloud groups
Consoles open to them, RDP, the View client connects to desktops - in general, everything is in the ointment.
A separate advantage is the ease of building network infrastructures. For example, for the View, the task of deploying a security server acting as an intermediary may be relevant. And within the framework of enhanced protection, it will be correct to divide the network into external and internal, see the picture (Fig. 11).
Figure 11. Illustration of changing the View infrastructure
So, the transition from configuration one to configuration two is again a couple of mouse clicks. Add a VM, indicate that it has two network interfaces, that one is connected to the internal and the other to the external network. Well, install the required service inside.
In principle, the minimum problem has been solved - I installed the necessary operating systems, the necessary applications, completed the required settings.
The task is optimum and the task is maximum - a pilot project and implementation. They will require a minimum of effort. Look here (fig. 12).
Figure 12. Illustration of the triviality of loading servers from the cloud to themselves
As you can see, in a couple of clicks we can unload the “acquired by overwork” to ourselves, and start up well-established and knowingly working services already at home. Moreover, there is no dependence on the arrival of our local iron — we will unload when we are ready (fig. 13, 14).
Figure 13. Downloading from the cloud to us locally
Figure 14. From these files, you can import a loaded VM group to your local vSphere
And if we like everything in the cloud - why unload it? We continue to exploit the services we need in the cloud, continuing to use all the buns. This is the absence of the need to invest in their local hardware, and adding resources at times, and the lack of a headache about low-level administration, the highest availability.
So, according to the results of testing, you can also implement your solution in the production environment in the cloud - most likely you will like everything.
And then we will talk about other types of tasks that can be solved with the use of such infrastructure, and about the near future - what other nice things will be added.
Source: https://habr.com/ru/post/123697/
All Articles