New processors in the new cloud pool
With some delays, but we are launching a new pool on new processors. Old processors Xeon L5520, new - Xeon E5-2630.
Here is Intel's opinion on how processors differ: http://ark.intel.com/compare/64593,40201
Key positions:
The price of processor time for new processors remains the same. With greater performance of each of the cores, this means that with an equal load in the new pool, the task will be done faster and in less machine time, that is, cheaper.
Along with these changes, major changes are also taking place in the cloud desk of Tulstec:
... and many more local improvements. And on the sly, they also removed ubuntu 10.04 from the list of available templates in this pool due to ... m ... uh ... loss of market relevance.
')
To be honest, 90% of these changes are the groundwork for the future. Some of them:
XCP 1.6, on which the new pool is based, was released in December 2012. A beta version of the third pool was rolled out at the end of April 2013.
There are several reasons for delays. First tests. On tests, we found several erroneous scenarios in xapi's work (they are not erroneous from the point of view of XenServer, but not at all interesting for working as a cloud thulstek). Under this case, an automatic testing system was written, which performs many operations on the finished copy of the pool with variation of parameters. The longest test takes more than 5 hours, and runs on two pools of two hosts each.
Secondly, the adaptation of our part of the tulstek to the changes in xapi. They seem cosmetic, but each of them cost us a few man-hours of work (first to find, then to adapt). Consoles are sent via TCP, not via PTS, a number of attributes were lost during the migration of operations with domains from xapi to xenopsd and we had to look for ways around). Xen, in turn, brought changes to ABI (it took to re-compile / rewrite all our SLA accounting strapping). The ability of virtual machines to at least theoretically travel between pools required serious changes to the database structure (we used to have a simple and clear relationship - “every virtual machine has its uuid pool”, and now the pool can change, and even several times a day) . A separate problem was the redistribution of IP addresses (less and less free IPv4 addresses).
A source
Here is Intel's opinion on how processors differ: http://ark.intel.com/compare/64593,40201
Key positions:
- Double cache size
- One and a half times increase in the number of operations with the system bus per second
- Support for additional AVX processor instructions
- 68% increase in RAM speed
The price of processor time for new processors remains the same. With greater performance of each of the cores, this means that with an equal load in the new pool, the task will be done faster and in less machine time, that is, cheaper.
Along with these changes, major changes are also taking place in the cloud desk of Tulstec:
- switching to a newer version of the hypervisor (3.4 -> 4.1) (changelog for 4.1 , 4.0 )
- Support storage motion (a major step to support live migration between pools)
- major xapi update ( changelog )
... and many more local improvements. And on the sly, they also removed ubuntu 10.04 from the list of available templates in this pool due to ... m ... uh ... loss of market relevance.
')
To be honest, 90% of these changes are the groundwork for the future. Some of them:
- Storage Motion allows you to transfer disks between storages and pools on the go, without interrupting work
- A new hypervisor (Xen 4.1) will allow pv_ops kernels (vanilla linux kernels) to be released to the product without any patches (bye-xen kernel versions)
- xapi finally got rid of XenSever's childhood diseases and greatly simplifies the process of balancing virtual machines between hosts
Why such a long delay?
XCP 1.6, on which the new pool is based, was released in December 2012. A beta version of the third pool was rolled out at the end of April 2013.
There are several reasons for delays. First tests. On tests, we found several erroneous scenarios in xapi's work (they are not erroneous from the point of view of XenServer, but not at all interesting for working as a cloud thulstek). Under this case, an automatic testing system was written, which performs many operations on the finished copy of the pool with variation of parameters. The longest test takes more than 5 hours, and runs on two pools of two hosts each.
Secondly, the adaptation of our part of the tulstek to the changes in xapi. They seem cosmetic, but each of them cost us a few man-hours of work (first to find, then to adapt). Consoles are sent via TCP, not via PTS, a number of attributes were lost during the migration of operations with domains from xapi to xenopsd and we had to look for ways around). Xen, in turn, brought changes to ABI (it took to re-compile / rewrite all our SLA accounting strapping). The ability of virtual machines to at least theoretically travel between pools required serious changes to the database structure (we used to have a simple and clear relationship - “every virtual machine has its uuid pool”, and now the pool can change, and even several times a day) . A separate problem was the redistribution of IP addresses (less and less free IPv4 addresses).
A source
Source: https://habr.com/ru/post/178885/
All Articles