How to tame clouds: examples of practical use. What did we get?
The fourth post, written by Mikhail Mikheev on his practical experience in vCloud IT-GRAD : The project has entered the applied stage. The conditions were agreed, resources were allocated, access was given. What now?"
We are given a link and account. Using them, we get to the interface (Fig. 1 "The main interface window of our cloud").
')
Since we have agreed to do work from scratch, it is empty here - and we need to create our own virtual machines.
Let me remind you that the task before us is the following:
1) Deploy vSphere (your own, virtual)
2) deploy server View
3) ideally, make the configuration replicable - in case of tests that did not go there, in case of deployment of the test site for the changed conditions.
We begin, obviously, with creating the necessary virtual machines, or rather their groups - vApp (Fig. 2 "Creating vApp").
In the wApp creation wizard (or at any time later) you can specify:
Then, in general, that's all.
We see the VMs created, open the console to any console and begin to perform the tasks of the project. Installing the OS, configuration, software, and so on (Fig. 3 "Several created VM and console to one of them").
That is really all it is - we need a few minutes from the moment of receiving the account to get to the moment when we are ready to start installing the necessary operating systems and applications.
For example, what happened with me (Fig. 4 "Infrastructure that solves my problem"):
Virtual desktops are running on virtual ESXi. Of course, this matryoshka is not for the working environment and not for the pilot - but for the test it is excellent and convenient.
The View server is given access from the Internet - I calmly test the connection in different conditions.
If tomorrow there will be a task to test any alternative solution for VDI - I will deploy AD + another server from the template, and after 5-10 minutes from the moment I receive the task I will begin to perform it.
And if another person takes up this alternative project, I will create an additional account in the cloud, and indicate how many virtual machines this user can create and how long to store them (Fig. 5 "Creating a user who can then be given rights to a part of virtual servers" ).
I will draw your attention to one small organizational nuance: vDC, virtual data center
This is the piece of computing resources that is allocated for our tasks. Simply put, this is a resource pool in the vSphere cloud provider.
We just simply create the required virtual machines with the required number of megahertz and megabytes, and then we see the one allocated to us in the interface (Fig. 6 "Our slice of the cloud").
Interesting setting Allocation Model
As you can see, the setting option called Pay-As-You-Go is used .
This means that resource settings are specified for each VM, and pool settings are the sum of VM reserves and limits.
Thus, how many resources we need, so much we get.
This option is good because we simply create virtual machines upon us being needed - without coordinating anything with anyone. And in fact of resource consumption we pay.
The option is good for its clouds - convenient. There is no unnecessary bureaucracy, coordination, loss of time for all this ..
This resource allocation option is the default option - for the simple reason that it is convenient for most. At the very beginning of communication, we will not be begging for how many resources we need - unless it is a scale. They will give access - and everything that we want to use as much.
Two other options for resource allocation are when resources are allocated for us not by the fact of our virtual machine settings, but by the cloud administrator. That is, the virtual machines we create fall into a pool of resources with resources limited from above. Between themselves, these options are different guarantee - we can request a 100% reservation of resources for our tasks, or partial. Of course, this difference will pull the difference in the invoice.
Everything. And then we dive a little into what lies behind all this.
Ok, all on the ointment - what I have ...
We are given a link and account. Using them, we get to the interface (Fig. 1 "The main interface window of our cloud").
')
Since we have agreed to do work from scratch, it is empty here - and we need to create our own virtual machines.
Let me remind you that the task before us is the following:
1) Deploy vSphere (your own, virtual)
2) deploy server View
3) ideally, make the configuration replicable - in case of tests that did not go there, in case of deployment of the test site for the changed conditions.
We begin, obviously, with creating the necessary virtual machines, or rather their groups - vApp (Fig. 2 "Creating vApp").
In the wApp creation wizard (or at any time later) you can specify:
- how long this vApp can be enabled; for test purposes, the very thing is not to produce entities beyond what is necessary;
- at the same step - how long vApp should be stored;
- which VMs are included in it - moreover, you can create new ones, or you can take them from the template catalog;
- specify the number of vCPUs, the amount of memory, disks, the number of network interfaces and to which networks these interfaces are connected. Just as for them must be configured IP addresses.
Then, in general, that's all.
We see the VMs created, open the console to any console and begin to perform the tasks of the project. Installing the OS, configuration, software, and so on (Fig. 3 "Several created VM and console to one of them").
That is really all it is - we need a few minutes from the moment of receiving the account to get to the moment when we are ready to start installing the necessary operating systems and applications.
For example, what happened with me (Fig. 4 "Infrastructure that solves my problem"):
- my little vSphere is 2 ESXi and vCenter;
- Separately from them - a pair of Windows virtual machines - an AD domain controller and a View server. Separately - because it was convenient for me to make a template from this pair;
- still separately - one auxiliary Windows.
Virtual desktops are running on virtual ESXi. Of course, this matryoshka is not for the working environment and not for the pilot - but for the test it is excellent and convenient.
The View server is given access from the Internet - I calmly test the connection in different conditions.
If tomorrow there will be a task to test any alternative solution for VDI - I will deploy AD + another server from the template, and after 5-10 minutes from the moment I receive the task I will begin to perform it.
And if another person takes up this alternative project, I will create an additional account in the cloud, and indicate how many virtual machines this user can create and how long to store them (Fig. 5 "Creating a user who can then be given rights to a part of virtual servers" ).
I will draw your attention to one small organizational nuance: vDC, virtual data center
This is the piece of computing resources that is allocated for our tasks. Simply put, this is a resource pool in the vSphere cloud provider.
We just simply create the required virtual machines with the required number of megahertz and megabytes, and then we see the one allocated to us in the interface (Fig. 6 "Our slice of the cloud").
Interesting setting Allocation Model
As you can see, the setting option called Pay-As-You-Go is used .
This means that resource settings are specified for each VM, and pool settings are the sum of VM reserves and limits.
Thus, how many resources we need, so much we get.
This option is good because we simply create virtual machines upon us being needed - without coordinating anything with anyone. And in fact of resource consumption we pay.
The option is good for its clouds - convenient. There is no unnecessary bureaucracy, coordination, loss of time for all this ..
This resource allocation option is the default option - for the simple reason that it is convenient for most. At the very beginning of communication, we will not be begging for how many resources we need - unless it is a scale. They will give access - and everything that we want to use as much.
Two other options for resource allocation are when resources are allocated for us not by the fact of our virtual machine settings, but by the cloud administrator. That is, the virtual machines we create fall into a pool of resources with resources limited from above. Between themselves, these options are different guarantee - we can request a 100% reservation of resources for our tasks, or partial. Of course, this difference will pull the difference in the invoice.
Everything. And then we dive a little into what lies behind all this.
Source: https://habr.com/ru/post/119499/
All Articles