Общее у всех этих продуктов - то, что они лицензируются не на базе процессоров (как vSphere), а на базе виртуальных машин. Эта особенность, с одной стороны, как бы ближе к облачной концепции - типа нам не важно где и как работают виртуальные машины, а важно сколько сервисов мы используем, соответственно, за них и платим.
Но с другой стороны, с этим возникают специфические проблемы, на которые обратили внимание в блоге компании VKernel. Суть проблем такова:
Когда организация использует модель лицензирования по физическим процессорам, ее основная цель - достичь максимальной консолидации виртуальных машин на хосте, поскольку она платит за инфраструктурные составляющие (стойки, питание, охлаждение, площади), а также за весьма недешевые лицензии на продукты для виртуализации. А вот когда лицензируются виртуальные машины - увеличение коэффициента консолидации не сказывается на стоимости лицензий, а значит нет и соответствующей мотивации у администраторов и менеджеров датацентра.
Когда используется лицензирование по числу виртуальных машин - это очень сложно учитывать. Виртуальные машины постоянно создаются, удаляются, развертываются в тестовых целях и забываются. Учитывать число лицензий в таких окружениях очень сложно и затратно.
Также автор обратил внимание на проблему, изложенную на одной из веток комьюнити, где у человека возникли проблемы с применением продукта CapacityIQ - он пытался строить отчеты о емкостях инфраструктуры не для всех виртуальных машин (поскольку некоторые не должны влиять на ее будущее состояние). Но оказалось в продукте нет такой возможности - он собирает информацию со всего окружения vCenter и нам рекомендуют лицензировать виртуальных машин столько, сколько нам реально нужно в анализе. Однако это очень неформализованное правило, которое нельзя отразить в EULA.
То есть, в данном случае совсем непонятно, какие виртуальные машины нам надо лицензировать (если она работает раз в году - надо?). Подобные проблемы в будущем будут возникать и в других продуктах (просто вышеозначенные - пока весьма не распространены). А это плохо, вот.
RSS
