Preliminary analysis of OpenStack initialization

The current OpenStack deployment tools are well established, and Kolla in particular, at least for the time being. After the deployment and installation issues are resolved, we need to do a study on how to use OpenStack well in the future. Here is a summary of the current concerns and thoughts that we will answer when OpenStack delivers to users.

CPU and memory superpartition ratio

I am often asked how many virtual machines can be created from one machine. My answer to that question will always be: It depends. It's entirely up to you. It's possible to go from one to 100.

The default CPU superpartition is 16:0 and memory is 1.5:0. So how is it configured in production? This is something to think about, and the different OpenStack usage scenarios are really quite different.

For a development environment, a 16-fold overshoot is likely to run well, too. Memory can also be overdivided. And in the production environment that sees at present, safe practice is 4:0 exceed cent scale, memory does not exceed cent, such practice is more common.

Here is a simple introduction to the KVM calculation CPU super points calculation method. 1 physical CPU, is 12Core, hyperthread, then it is 24Core, if we do not do any hyperscore, 1.0, then it is 24 Core, create 4core virtual machine, can create 6. If I set the CPU hyperscale to 4.0 in the parameters, then there are 24*4=96core, for 4core vm, I can create 24.

CPU and memory reservations

As for the CPU and memory of computing nodes, how much should be reserved, especially under the current super-fusion architecture, is a controversial issue. Different software versions and different hardware conditions will result in different results.

For hyperconverged architectures, SSD used to be reserved and bound specifically for CPU, but few people seem to talk about it now. But 1 general habit, everybody is memory retention 4G, now memory is cheaper, 4G memory runs compute nodes various services, it's not a problem.

How much of CPU is reserved for host use is not set in many environments and is not reserved at all.

Flavor

In the beginning, Flavor was rarely set up, but in practice, Flavor has a lot of problems, because once Flavor has a virtual machine in use, you can't delete and modify it, so if you do anything to flavor, it will cause various problems with the virtual machine. Therefore, OpenStack, which is initialized by default, should be adjusted in practice.

Currently OpenStack supports StartFragment for special flavor for special tenants, so we recommend 2 flavor for production environment

1. 4 Core + 8 G memory

2. 8 Core + 16 G memory

3. 1 Core + 2 G memory

The third flavor is mainly for test use. Two flavor should suffice for everyday users.

This actually needs to consider how much memory the host is the most appropriate. If the machine is 512G memory, the 16G memory virtual machine can create 32, minus the system reserved memory, 30 virtual machine is not a problem.

For core, we need 240 Core. If one CPU is 15 Core and the superfractional ratio is 4, then this is basically enough. From the cost point of view, 15 Core CPU is expensive, usually 12Core CPU is more economical.

The mirror

This is important, but in the past private cloud mirroring has been very informal, causing a lot of problems. An OpenStack image of Linux takes a lot of work to make it feel good to the user.

1. To upload the image, the minimum requirements of memory and hard disk must be specified, which can avoid many user errors

2. Upload qcow2 and convert to raw format

3. Provide minimal installed linux images only (centos 7.2, centos 7.3, Ubuntu 16.04)

4. Integration of qemu agent

5. Close the selinux

6. wap partition is not set

7. Speed up ssh by setting ssh instead of dns

8. Specify the source to speed things up

You can set a password

Special OpenStack services, such as ironic, sahara, trove, also require special custom images.

Image upload, can only let the administrator upload.

Tenant and billing

In many cases, administrative rights are assigned when users are created for convenience, resulting in many administrative problems. Again, you should have one tenant and one user. This is easy to manage, not so casual.

For tenants, you need to enable the billing system to understand how resources are being consumed.