Серию официальных постов в блоге компании про то, как работать с облаком я ещё продолжу, но параллельно мне хочется рассказать про те проблемы, с которыми мы столкнулись во время адаптации Xen Cloud Platform под нашу модель работы облака. Эти посты будут чуток сложнее и предполагают, что читатель хотя бы в общих чертах знает, как работает Xen.
Когда концепция «оплата по потреблению» только-только оформлялась, а я судорожно искал «как считать», мне казалось, что процессор и память — это два самых простых ресурса.
Действительно, у нас есть xencontrol (библиотека управления гипервизором Xen), которая может точно сказать про каждый домен (запущенную виртуальную машину), сколько у неё есть памяти, сколько наносекунд времени было потрачено. Эта библиотека запрашивает информацию напрямую (через xenbus) у гипервизора и подвергает её минимальной обработке.
Выглядит эта информация примерно так (вывод биндинга xencontrol для питона):
{
'paused': 0,
'cpu_time': 1038829778010L,
'ssidref': 0,
'hvm': 0,
'shutdown_reason': 0,
'dying': 0,
'mem_kb': 262144L,
'domid': 3,
'max_vcpu_id': 7,
'crashed': 0,
'running': 0,
'maxmem_kb': 943684L,
'shutdown': 0,
'online_vcpus': 8,
'handle': [148, 37, 12, 110, 141, 24, 149, 226, 8, 104, 198, 5, 239, 16, 20, 25],
'blocked': 1
}
Как мы видим, есть поле mem_kb, соответствующее выделенной памяти для виртуальной машины и есть поле cpu_time, содержащее какое-то умопомрачительное число (хотя на самом деле это всего лишь 17 минут). cpu_time считает с точностью до наносекунд (точнее, величина, которая тут хранится считается в наносекундах, реальная точность около микросекунды). Память, как понятно, в килобайтах (хотя внутренней единицей учёта, что гипервизора, что ядра линукс является
страница — её размер по-умолчанию 4 килобайта).
Казалось бы «бери и считай», однако, дьявол кроется в деталях…
Извините за жёлтый заголовок ниже, но именно так звучал вопрос в полемике в ходе обсуждения одной из проблем:
Hyper-threading + Xen = воровство денег у клиентов
