Yourself AWS. Part 0

    Good day,% username%!

    Today I will tell you how to use a file, a bunch of servers and such a mother to collect something vaguely similar to EC2 from Amazon.
    The article turned out to be more overview, so you have to break it into several parts .

    I blinded you from what was.

    This is a demo stand, 6 x i5-3570T / 8Gb RAM / all kinds of disks.

    Somehow I got the task to streamline all office services, randomly scattered around the zoo of servers and OSes (I even have OpenBSD running around here). And it so happened that I had long wanted to look at the clouds, but there was no real test case. So I decided to study what is now interesting in the open-source world and whether it can be applied in combat conditions.

    At the moment, I looked at solutions such asMaaS + Juju named Cannonical, RDO named RedHat, Foreman with plugin and Fuel .

    Looking ahead a bit - Fuel turned out to be the most adequate for me, but let's go in order.


    Simple and austere design

    MaaS represents the concept of Metal as a Service, in fact - it is engaged in the management of bare metal. You can choose which version of ubunta to install on this or that server, find out its TTX and basically everything. Servers can be divided by availability region. Also knows how to work with virtual machines through libvirtd. The interesting part starts when you screw Juju to all of this - now you can say “set me the bucks” and it will select a piece of iron from the list of available metal and roll all the necessary software, such as mysql, apache, wordpress / drupal / etc. Nice, convenient, but when I tried to deploy OpenStack in this way, everything got stake. Maybe I did something wrong, maybe the creators of the config for juju did something wrong. But in the end, I was not able to properly deploy the controller on one server. For each component of the controller, it wanted a separate piece of iron. Those. do you need keystone ?, no question - here is a separate server for keystone. And so with everything. To all this was added my dislike of ubuntu as a server OS, so the decision had to be postponed.


    I liked this project much more. His advantage was on the same team: packstack --allinone. This is how easy and unpretentious you get a working OpenStack on one server. Here you have both the controller and the working node. Want customization? no question - edit the answer-file received after the first run and run packstack again, specifying this file as a config. Easy, nice, comfortable. Only one thing confused - very little documentation. I had to kill a lot of time to solve strange errors, for example, because I forgot to screw the necessary repository. In some places, they even had to edit the documentation on their website so that it corresponded to the current reality, since many things were written for OpenStack Havana, and since then many things have changed.
    Perhaps now, knowing much more about OpenStack and its internal work, I would give a second chance for RDO. But it will be difficult for a beginner to build something different from the standard configuration offered by the script. In addition, the system assumes that you have already prepared the servers and Centos / RedHat minimal is installed on them. So no PXE and other delights.


    Thousands of schedules, bosses will be happy

    The Foreman itself is a web interface for managing puppet configs, and in this role it is quite convenient and interesting. But besides this, he is able and provisioning. So, as with MaaS, you can tell the server to boot over the network, and then manage the installation through a convenient webmord. Having such a convenient solution, it was difficult not to come up with the idea of ​​deploying cloud based on it. And all sorts of craftsmen began to slowly realize this. Currently, nightly builds have the foreman-installer-staypuft plugin. With it, you install both Foreman itself and the necessary plugins. The convenience of this design is that literally from one point you can install the OS (both Linux-based and Windows), then distribute the necessary roles and install the necessary set of software. Or deploy cloud, and again from foreman 'webmord and assign roles to instances in this cloud. There is only one significant BUT - nightly builds are quite unstable.
    Perhaps this solution will be finalized over time and it will be completely production-ready, but at the moment, you can only indulge and send bug reports to developers. Fortunately, they actively read the Google group .


    They seem to have a designer.

    At the moment, the most perfect solution for deploying cloud from a well-known company Mirantis. In fact, it is exclusively focused on deploying cloud software. Like rdo / foreman, he does this with puppet scripts. Installing controller + 3 compute node takes about 30 minutes, depending on the speed of your screws. You can create both High availability and non-HA cluster. Able to work with Ceph out of the box , in version 5.1 drivers were also added for Mellanox network cards, which in combination with LVM + Infiniband allows using RDMA (I haven’t checked it yet in action, I’m waiting for the switch and network cards to arrive). A huge plus is the availability of a large amount of documentation .

    Next time I’ll tell you what actually happened to me using Fuel, a little about the features of ceph, how to use several hypervisors in one cloud and how to simplify my life by automating everything and everything. And if InfiniBand reaches me, it’s possible that it’s about the features of its work with ceph and openstack.

    Also popular now: