How to tame the clouds: practical examples. 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 on vSphere. It has information about clusters and pools, distributed switches and port groups, and repositories. The task that this add-in solves is the convenient allocation of the above resources to groups of virtual machines - the essence is to provide an interface.

    What is there on the technical side? Details ...



    As already mentioned, the foundation is the right hardware + vSphere + vCloud Director, Datacener Tier 3 and the most technological advanced platform for building a virtualization infrastructure.

    Details:

    image

    But on the means of turning the infrastructure into the cloud let us dwell a little more - so that there is an understanding of what and how to use it to do it.

    The key object of the cloud we're talking about is VMware vCloud Director.

    Technically speaking, vCloud Director is an add-on for vSphere.
    It has information about clusters and pools, distributed switches and port groups, and repositories.

    The task that this add-in solves is the convenient allocation of the above resources to groups of virtual machines - the essence is to provide an interface.

    On the one hand, the interface for the administrator of the cloud provider is to divide a lot of the many available resources into the "clouds" of different customers.

    On the other hand, providing an interface to an administrator, or a customer’s representative, without the skills of a system administrator, for deploying virtual servers, working with them, and managing an intra-cloud network.

    That is, it is enough for the administrator or operator to specify - to allocate so many resources to this customer. For the processor, these are megahertz, gigabytes for memory, on which storage (roughly faster / slower) should the disks of its VM be located, which networks are available (more about the networks a bit later).

    Now the company’s administrator, who receives this cloud at his disposal, creates a necessary number of virtual machines for himself in a couple of clicks, within the specified framework, allocates the necessary number of resources to them 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 specified for our VMs — we got so much and paid for so much; then with the networks I’ll tell you a little more.

    For example, what I see when I go to the corresponding section of the interface (Fig. 1):

    image
    Figure 1. Intra-cloud networks

    Here I see two networks available to me. They are quite clearly called NAT and Internal.

    What does this mean (Fig. 2):

    image
    Figure 2. Illustration of the default intra-cloud networks

    that, if necessary, we 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 the same network with one tick (Fig. 3) can be isolated from each other - as if they are connected to different switches - it can be very convenient to raise several identical configurations so as not to worry about the absence of conflicts in our network.

    image
    Figure 3. Automatic isolation of this group of virtual servers in an intra-cloud network

    In this screenshot, the wizard’s step to deploy vApp from the template is visible - just here 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 you to do all commonplace 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 out of the box, we just configure it for ourselves (Fig. 4).

    image
    Figure 4. Configuring a regular DHCP server

    Configuring a firewall that protects our virtual machines from the dangers of the outside world (Fig. 5).

    image
    Figure 5. Configuring a full-time firewall between the outside world and the NA network

    What public IP addresses are available to us (there is no screenshot, but there is just a list), and port mapping settings (Fig. 6).

    image
    Figure 6. Configuring port forwarding from the outside to the VM VM of the NAT network

    Thus, you can implement any option we need for the interaction of virtual machines with each other and, if necessary, with the outside world. Moreover, for simpler cases, we will have enough DHCP servers, firewalls and NATs offered by the infrastructure itself. DNS, of course, is also provided.

    So, in a short time I created a couple of the vApp-sets of virtual machines I need (Fig. 7):

    image
    Figure 7. Infrastructure for my task

    You can open a console to any virtual machine and, with minimal NAT setup, 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 replicate once prepared virtual machines in a trivial way, moreover, with depersonalization, if necessary (Fig. 8.9).

    image
    Figure 8. Start of VM group deployment from the template

    image
    Figure 9. Steps of the VM group deployment wizard from the template The

    test environment is deployed.

    List of virtual machines (Fig. 10).

    image
    Figure 10. List of virtual machines from all groups in my cloud

    Consoles, RDP open to them, the View client connects to desktops - in general, everything is in the ointment.

    A separate plus is the simplicity of building network infrastructures. For example, for View, the task of deploying a security server acting as an intermediary may be relevant. And in the framework of strengthening protection, it will be correct to divide the networks into external and internal, see picture (Fig. 11).

    image
    Figure 11. Illustration of the change in 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, one connected to the internal, and the other to the external network. Well, install the required service inside.

    In principle, the minimum task is solved - I installed the necessary operating systems, the necessary applications, performed the required settings.

    The optimum task and the maximum task - a pilot project and implementation. They will require a minimum of effort. Look here (Fig. 12).

    image
    Figure 12. Illustration of the triviality of loading servers from the cloud to ourselves.

    As you can see, we can unload "acquired by overwork" to ourselves in a couple of clicks, and already run debugged and obviously working services at our place. Moreover, there is no dependence on the arrival of our local iron - we will unload it when we are ready (Fig. 13, 14).

    image
    Figure 13. There is a download operation from the cloud to us locally

    image
    Figure 14. From these files you can import the loaded VM group to your local vSphere

    And if we like everything in the cloud - why unload? We continue to operate the services we need in the cloud, while continuing to use all the goodies. This lack of need to invest in their local hardware, and adding resources at a time, and the absence of a headache about low-level administration, the highest availability.

    So, according to the test results, you can implement your solution in the production environment in the cloud too - 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.

    Also popular now: