Série de reportagens investiga como os principais players estão lidando com o licenciamento de software frente aos processadores de múltiplos núcleos e a virtualização.
Parte II
A IBM e a Oracle optaram por direções opostas à escolhida pela BEA, ?contando? núcleos de CPU individuais. Atualmente, o licenciamento por núcleo, da IBM, se aplica a quase metade de seus produtos de software, incluindo DB2, WebSphere, Tivoli e Domino, ao passo que o da Oracle se aplica a seu principal banco de dados. As duas fabricantes também levam em conta o desempenho de cada linha de processador, de modo que os custos são próximos da capacidade real de computação disponível para um aplicativo.
O esquema da IBM é o mais complexo. Ela cobra dos clientes por PVU (processor value unit, ou unidade de valor por processador), que é igual a 1% do preço de um processador padrão com núcleo duplo, Opteron ou Xeon. A IBM dividiu seus preços por soquete por 100 para definir o preço por PVU, o que significa que a maioria dos clientes x86 inicialmente não verá nenhuma mudança. Contudo, ao fazer a atualização para os chips x86 com processadores quádruplos, o usuário pagará o dobro por processador, porque cada um deles equivale a 200 PVUs.
A IBM afirma que este modelo é justo porque um chip com quatro núcleos pode fazer o dobro do que faz um chip com dois núcleos. O problema para a TI é que as contagens de núcleos dos chips estão aumentando exponencialmente. Isso significa que ocorrerá o mesmo com as taxas de licenciamento da IBM, se o número de PVUs por núcleo e o preço por PVU permanecerem constantes. Como esta situação é insustentável, em longo prazo, a IBM declara que ajustará o número de PVUs por núcleo para dar conta do verdadeiro desempenho, e espera diminuir os custos de acrescentar mais núcleos a um chip. Hoje, todos os núcleos x86 respondem por 50 PVUs.
O sistema de PVU, da IBM, também é o primeiro modelo de licenciamento da grande fabricante a levar em conta, explicitamente, a virtualização, por meio do que a IBM chama de “licenciamento de sub-capacidade?. Se um servidor for dividido em diversas máquinas virtuais, os aplicativos dentro de cada uma delas precisarão ser licenciados somente para o número máximo de núcleos disponíveis para cada MV, e não para todos os núcleos no servidor. Obviamente, manter o controle deste modelo foi o que causou problemas para a ferramenta Tivoli License Compliance.
O licenciamento de sub-capacidade pode resultar em economia, mas somente se as máquinas virtuais estiverem bem restritas a um limitado número de núcleos. O problema é que o maior argumento de venda da virtualização é sua flexibilidade, proporcionando a capacidade de se mover entre MVs, conforme o trabalho exigir. Para tirar proveito desse atributo, cada aplicativo precisa ser licenciado para cada núcleo em que pode ser executado, algo que a IBM admite que irá aumentar os custos para a maioria dos clientes. A medição também é muito difícil, exigindo recorrer à ferramenta da IBM. A companhia está desenvolvendo uma versão atualizada, como parte de um produto Tivoli mais amplo, destinado ao gerenciamento da virtualização, embora a ferramenta em si continuará sendo gratuita.
O licenciamento da Oracle é mais simples do que o da IBM, sendo efetuado com base na contagem de núcleos como frações de um processador, mas é menos favorável à virtualização. Um banco de dados Oracle sendo executado em VMware deve ser licenciado para cada núcleo no hardware básico ? independentemente de em quantos núcleos a MV realmente é executada. Atualmente, o único meio de economizar em licenciamento da Oracle por meio da virtualização é limitar os núcleos do processador disponíveis para um banco de dados, por meio do Solaris Containers, que a Oracle acredita estar colocando limites mais restritos do que a VMware, quando se trata de restringir o número de núcleos disponíveis para um aplicativo.
Leia as outras reportagens da série clicando aqui.
