May 7, 2013 at 12:43New processors in a 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 items:
The price of processor time for new processors remains the same. With higher performance of each core, this means that with equal load in the new pool, the task will be done faster and in less amount of machine time, that is, cheaper.
Together with these changes, major changes take place in the cloud’s tool stack:
... and many more local improvements. And by the noise they still removed from the list of available templates in this pool ubuntu 10.04 due to ... m ... uh ... loss of market relevance.
Frankly, 90% of these changes are a challenge 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 deflated at the end of April 2013.
There are several reasons for the delays. First tests. On tests, we found several erroneous scenarios in the operation of xapi (they are not erroneous from the point of view of XenServer, but they are not at all interesting for working as a cloud tool stack). An automatic testing system was written for this case, which performs many operations on a finished copy of the pool with a variation of parameters. Our longest test takes more than 5 hours and runs on two pools of two hosts each.
Secondly, the adaptation of our part of the tool stack for xapi changes. They seem cosmetic, but each of them cost us several man-hours of work (first find, then adapt). Consoles are given through TCP, and not through PTS, a number of attributes were lost during the migration of domain operations from xapi to xenopsd and we had to look for ways around). Xen, in turn, brought changes to the ABI (it was necessary to rebuild / rewrite all of our bindings that deal with SLA accounting). The ability of virtual machines to travel between pools even theoretically required serious changes to the database structure (we used to have a simple and clear relation - “every virtual machine has its pool uuid”, and now the pool can change, and even several times a day) . A separate problem was the redistribution of IP addresses (free IPv4 addresses less and less).
A source
Here is Intel's opinion on how processors differ: http://ark.intel.com/compare/64593,40201
Key items:
- Doubling cache size
- One and a half times 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 higher performance of each core, this means that with equal load in the new pool, the task will be done faster and in less amount of machine time, that is, cheaper.
Together with these changes, major changes take place in the cloud’s tool stack:
- switching to a newer version of the hypervisor (3.4 -> 4.1) (changelog for 4.1 , 4.0 )
- Storage motion support (a major step in supporting live migration between pools)
- xapi major update ( changelog )
... and many more local improvements. And by the noise they still removed from the list of available templates in this pool ubuntu 10.04 due to ... m ... uh ... loss of market relevance.
Frankly, 90% of these changes are a challenge for the future. Some of them:
- Storage Motion allows you to transfer disks between storage and pools on the go, without interruption
- The new hypervisor (Xen 4.1) will allow you to accept pv_ops kernels (linux vanilla kernels) into the product without any patches (goodbye, -xen kernels)
- xapi finally got rid of XenSever’s childhood diseases and greatly simplifies the process of balancing virtual machines between hosts
Why such a long deploy?
XCP 1.6, on which the new pool is based, was released in December 2012. A beta version of the third pool was deflated at the end of April 2013.
There are several reasons for the delays. First tests. On tests, we found several erroneous scenarios in the operation of xapi (they are not erroneous from the point of view of XenServer, but they are not at all interesting for working as a cloud tool stack). An automatic testing system was written for this case, which performs many operations on a finished copy of the pool with a variation of parameters. Our longest test takes more than 5 hours and runs on two pools of two hosts each.
Secondly, the adaptation of our part of the tool stack for xapi changes. They seem cosmetic, but each of them cost us several man-hours of work (first find, then adapt). Consoles are given through TCP, and not through PTS, a number of attributes were lost during the migration of domain operations from xapi to xenopsd and we had to look for ways around). Xen, in turn, brought changes to the ABI (it was necessary to rebuild / rewrite all of our bindings that deal with SLA accounting). The ability of virtual machines to travel between pools even theoretically required serious changes to the database structure (we used to have a simple and clear relation - “every virtual machine has its pool uuid”, and now the pool can change, and even several times a day) . A separate problem was the redistribution of IP addresses (free IPv4 addresses less and less).
A source