License an Oracle Cluster from multiple licenses

[mfranz]

Hi,

I would like to share a little issue I am having when trying to have FNMS license an Oracle Cluster from multiple licenses. I would like to hear if anyone else is seeing similar behaviour.

The background: Multiple Oracle instances are running on mutliple VMs on multiple ESX-Hosts in one Cluster. There are multiple licenses for Oracle databases and this distinction is needed for organizational reasons. Also there are potential (minor) differences in the use rights.

What FNMS does: FNMS licenses the whole cluster via one license, "overusing" it and completely ignoring the second license.

My understanding: This might be related to the idea that on VMware, Oracle Database and attached features need to be licensed not only for the host, but the Cluster (and from ESX 6 on the whole vCenter). So it sounds like FNMS just applies that rule, but is not able to stop when one license is full and to continue on the next one, based on license priority.

The general behaviour has been confirmed by engineering, the root cause was not. Currently, the only workaround seems to be to manually allocate the hosts to both licenses and force some to consume from one and some from the other license, while have exemptions to avoid double consumption.

Best regards,

Markward

[spierce]

Hi Markward, Your analysis of what is happening is correct and once FNMS starts to consume one of your Oracle licenses against the ESX cluster it will continue to do so until the full cluster is licensed. The answer could be to review the way you split your entitlement. I generally recommend that the number of licenses for the same product is rationalised as much as possible wherever the entitlement is for the same product and metric and has the same use-rights and scope. If your licenses are split by organisation it may be better to maintain separate purchases for the different organisations but assign them to the same license. Then in terms of consumption per organisation you could develop reports to cover that requirement based on the number of licensed cores (On VMs where the software is licensed), VM Ownership, number of cores in the cluster and core licenses owned per organisation. With your licenses split as they are, even if you did manage to make the cluster consume multiple licenses, how would you decide or control how many of each license were consumed by the cluster? Of course there are a number of factors here, so you may have other reasons for splitting out the licenses and I note your mention of slightly different use-rights in some cases. Stewart

[mfranz]

Hi Stewart,

Combining the entitltements into one license was my first reflex. Reason for the split is that the customer has part of their entitlements directly from Oracle and part from their parent company. 

Regarding "control how many of each license were consumed by the cluster", if FNMS could do the split, it would just consider the license priority. I would do the same, fill up the license with the highest prio, then use the next one.

I guess this is a bit more complicated than the average device license, but wouldn't it be great if this worked ootb? 

Best regards,

Markward

[spierce]

Hi again, I can certainly see a case for consumption of processor and core based licenses rolling over into another license when the first is full. Having said that, in the use case you describe I do think using a single license is perhaps the way to go. If you reconcile the single license you can see in the Group Assignment tab the total number consumed versus the break down of purchases owned per Enterprise group, so the number from the parent company, the number purchased directly and the number consumed in total would be easily available (assuming you have suitable Enterprise groups to map the purchases to). Stewart

[JensWalton]

Hi @spierce 

The downside of rationalising the processor entitlements into a single license is that you will lose the benefit of FNMS Contract management and the license relationships to that contract record.

If you use the Contract Module and create the relationships with the license records it enables an easy way to look for those cost optimisation opportunities at renewal/anniversary time.

Rationalizing the entitlement to force desired behavior loses that and creates additional manual effort which nobody wants.

If you have multiple license records linked to an application and there are no restrictions/scoping in place...then FNMS should recognise where spare entitlement is to draw upon and use.

Jens

[Natalie]

Hi @JensWalton ,

I don't think this is quite true - you can relate the distinct purchases to distinct contracts, without limiting the license itself to a single contract. You can also link a license to multiple contracts. Using the relationship contract -> purchase -> license, I think you can maintain the cost optimization visibility while at the same time allowing FNMS to take advantage of all your entitlements. 

Best,

Natalie

[ChrisG]

The following line in the background writeup here is potentially significant: "Also there are potential (minor) differences in the use rights."

If there really are different use rights, then I imagine Oracle would not look too favorably on the deployment of Oracle Database on VMware as described here. When you start to think about needing to license all processors in the cluster, trying to say that some processors are going to be licensed according to one set of use rights and other processors are going to be licensed according to a different set of use rights quickly gets to be a nonsensical discussion.

So while I don't know Oracle's license terms and conditions deeply enough to speak with authority here, I would tread cautiously. You may find you really need to have the whole cluster licensed under a single set of terms and conditions, in which case a single license record in FlexNet is appropriate. Remember that first and foremost you use license records in FlexNet to model the entitlements granted by the vendor to the organization on a holistic basis; as soon as you start to try to split license records to model internal organizational considerations which are different from the vendor's view you will start to run into quirks like you describe here.

[JensWalton]

Hi @Natalie 

I understand and agree, however, I think Flexera can make this simpler without the need for customers to create possibly onerous manual relationships which of course will need to be documented outside of the tool (attached as a note document to the contract or license record).

Where distinct relationships exist between a contract and a PO, and if multiple PO's make up a single license record to consolidate the entitlement (as suggested) once that license is assigned to a contract or multiple contracts, there is no breakdown to suggest that licenses linked to a contract may be sharing entitlements from another contract.

Detailed knowledge and history of any such association and relationship must be maintained.  Which if not well documented and shared could lead to future reporting problems and inaccuracies.

Jens

[Natalie]

Hi @JensWalton ,

I was able to make a report that shows what I think you want: 

* Contracts
* Licenses
* Purchases
* Contracts 

The way FNMS does the join, the first "Contracts" will be all contracts, but the second one will be an inner join with its predecessor item, Purchases.

While it's not possible to further filter this report in the FNMS UI to the exception items where the license contract doesn't match the purchase contract, the report has the data you need and could be further refined in Excel or, if you are on prem, via a SQL report.