Appearance
Pool Resource Model Object Reference
The PoolResourceModel object describes resources, demand, consumption, events, costs, rules, and constraints that govern future pool resource states, quantities, and license positions with respect to time.
json
{
"Settings": {},
"SimulationRules": {},
"EvolutionRules": {},
"ValuationRules": {},
"NewServerConfiguration": {},
"PowerConsumptionTerms": {},
"FacilityConsumptionTerms": {},
"SoftwareResources":{
"PoolSoftwareStack":[],
"SoftwareInventoryTerms":[]
},
"ServerInventory":[],
"JumpEvents":[],
"Constraints":[]
}
Attributes
Settings - object - required
Properties for scenario handling.
SimulationRules - object - required
Sets the objective function of the simulation and related attributes.
EvolutionRules - object - required
Rules for how pool resources evolve over time.
ValuationRules - object - required
Defines financial attributes for how resources are valued.
PowerConsumptionTerms - object - required
Defines terms for electricity consumption.
FacilityConsumptionTerms - object - required
Defines terms for facility space consumption.
NewServerConfiguration - object - required
Sets configuration of a new server or rack inventory that will be added to the pool.
SoftwareResources - object - required
Parent object of PoolSoftwareStack and SoftwareInventoryTerms objects.
PoolSoftwareStack - array of integers - required
Array that contains license ids which defines the initial software stack of the pool. License ids correspond to license terms defined in SoftwareInventoryTerms object.
SoftwareInventoryTerms - array of objects - required
Array that contains objects which describe license counting (i.e., consumption) and cost terms.
ServerInventory - array of objects - required
Array that contains objects which describe initial server or rack inventory of the pool.
JumpEvents - array of objects - required
Array that contains objects which define discrete events which may influence a pool's compositional state.
Constraints - array of objects - optional
Array that contains objects which define constraints to restrict a pool's acceptable compositional state.
Settings
This object is for configuring scenario properties.
json
{
"Version:": "1.0",
"ScenarioName": "My Scenario Name",
"ModelEffectiveDate": "2022-10-07T00:00-05",
"EmailResults": true,
"CalendarizeForecast": true,
"Pool": {
"Id": "ATL1_42_PROD",
"Name": "Name of service pool",
"Description": "A long description of pool"
}
}
Attributes
Version - string - optional
Pool Resource Model version number. Default value is '1.0'.
ScenarioName - string - optional
Name of this scenario.
INFO
Zypr auto-generates a unique Scenario Id, and its timestamp, for each simulation request. Both are added to the Settings object in the Scenario response object by Zypr.
ModelEffectiveDate - date (YYYY-MM-DDT00:00:Z) - optional
Sets the ScenarioStartDate property to this value. If left blank, the scenario start date of the resources forecast is set to the date the scenario is created. The ModelEffectiveDate cannot be a future date beyond the current date. To designate your local time zone, enter the time offset from universal time (e.g., New York on standard time would be Z-05:00). If only the date portion is entered, the time zone will be set to universal time.
Very Important!
Setting the ModelEffectiveDate property anchors the start date of the scenario to this date. This eliminates result variations, or possibly failing model validation due to date calculations, simply due to when a simulation is executed.
EmailResults - boolean - optional
An email is sent notifying you the simulation request has completed. A successfully completed simulation will have attached the ResourceRequirementsForecast object. The default setting of this property is false. If a critical error is encountered by the simulator or the host that is running the simulator, an email is sent notifying you. Non-critical errors, such as your model fails validation, do not trigger an email notification.
CalendarizeForecast - boolean - optional
Determines if a calendarized forecast is generated and the CalendarizedForecast object is returned in the Scenario response object. A calendarized forecast is a transformation of the ResourceRequirementsForecast time-series with time-series whose intervals are based on calendar months. Default is false.
Pool - object - optional
A reserved property name to custom describe attributes of a resource pool. This property is only validated for well-formed JSON. Users may append any valid JSON, which will be returned on the Scenario object when the Scenario object includes the ResourceRequirementsForecast.
Simulation Rules
This SimulationRules object defines the objective function of a scenario with respect to cost scope and time.
json
{
"SimulationType": "Optimal",
"SimulationCostScope": "All",
"ScenarioDuration": "5",
"FindSolutionMetricType": "TotalCumulativeCostPerYear",
"ServerReplacementTime": ""
}
Attributes
SimulationType - string - required
Sets type of simulation.
Simulation Type Codes
Code | Description |
---|---|
Optimal | Objective is to identify the lowest total cost solution, which includes the server turnover rates and resource mix necessary that results in the lowest cost solution. |
Fixed | Objective is to identify the evolution of server inventory transactions using a predetermined turnover time and rate. |
Server life-cycle definition
Zypr provides two very different ways for determining how long a server may be utilized in a pool. Simply because a server is no longer utilized in a pool does not necessarily mean it is retired from the fleet. It may be advantageously reassigned to a different pool for further use.
It is therefore important to distinguish the life-cycle that is being modeled:
- accounting-life,
- useful-life, or
- economic-life of a server.
'Optimal' simulations dynamically calculate servers' economic-life, with respect to a pool's unique cost structure, to determine when they are removed from a pool. Whereas 'Fixed' simulations use a predetermined fixed-time for when servers are removed the pool. It is up to you to decide what life-cycle that fixed-time represents.
SimulationCostScope - string - required
Sets which resource costs are included in simulation.
Simulation Cost Scope Codes
Code | Description |
---|---|
All | Includes resource costs for hardware, software, power and facility space |
ServerAndPowerOnly | Includes only costs for hardware and power |
ServerAndSoftwareOnly | Includes only costs for hardware and software |
ExcludeFacility | Includes only hardware, software and power |
ScenarioDuration - numeric - required
Sets the minimum duration for time-series solution. Unit is years.
Very Important!
Zypr provides information necessary to effect changes to a pool's short and long-term resource composition.
Resource planners should generally avoid using short ScenarioDuration values for tactical resources changes (e.g., next quarterly addition to pool hardware capacity) while using long ScenarioDuration values for multi-year resource commitments (e.g., software license contract negotiations). Doing so produces different resource requirements based on different assumptions. This should be avoided!
Cross-functional resource planners should define simulations based upon their collective assumptions and similar ScenarioDuration values, and then test the sensitivity of results to those collective assumptions.
FindSolutionMetricType - string - required
Sets metric used to find solution for SimulationType 'Optimal'
Solution Metric Codes
Code | Description |
---|---|
TotalCumulativeCost | Uses cumulative cost of time-series. |
TotalCumulativeCostPerYear | Uses cumulative cost per year of time-series. |
ServerReplacementTime - numeric - conditionally required
Sets preferred time of server refresh. Required when SimulationType property 'Fixed' is selected.
Evolution Rules
This EvolutionRules object defines the boundary conditions and rules for how pool server inventory is permitted to evolve.
json
{
"PoolUtilizationPercentCurrent": 63.5,
"PoolUtilizationBoundaryPercentLower": 63.0,
"PoolUtilizationBoundaryPercentUpper": 65.0,
"ServiceDemandGrowthPercent": 20.5,
"InventoryQueueBias": "Auto",
"LotUnit": "Server"
}
Attributes
ServerUtilizationPercentCurrent - numeric - required
Actual pool utilization percent at start of scenario.
ServerUtilizationPercentBase - numeric - required
Targeted minimum utilization percent for pool. This value constrains how much hardware capacity is added to the pool at a capacity addition event.
ServerUtilizationPercentPeak - numeric - required
Targeted maximum utilization percent for pool. This value, when reached, triggers a capacity addition event to the pool.
ServiceDemandGrowthPercent - numeric - required
Projected service demand growth percent for pool. The minimum accepted value is one percent.
The resource evolution process
Zypr automatically evolves the state of a pool over time and determines capacity addition events. Service demand growth percent, along with Upper and lower utilization rates, set the basic guardrails to the evolution process.
The mathematical model depicting evolution is a close-loop calculation. The model cannot arbitrarily absorb or leak resources from a pool. If you are not satisfied that actual utilization rates track closely enough to what is forecasted by simulations, two places to review are: 1) sampling methods used to arrive at actual utilization rates, 2) performance estimation of servers or other hardware (e.g., benchmarking studies).
InventoryQueueBias - string - optional
Queue order for how server inventory is sequenced for removal when SimulationType property is 'Optimal'. Queue order is based on hardware unit performance rating. Default is 'Auto'.
Queue Bias Codes
Code | Description |
---|---|
Auto | Zypr determines queue bias. |
Server | Server unit queued least-to-best. |
Processor | Processor unit queued least-to-best. |
Core | Core unit queued least-to-best. |
LotUnit - object - optional
Sets the inventory lot unit used in add/remove transactions. Default value is 'Server'.
Lot Type Codes
Code | Description |
---|---|
Rack | Rack is the add/remove unit |
Server | Server is the add/remove unit |
Do not mix lot units
A simulation cannot mix lot units (i.e., inventory mix of rack units and server units). Both the NewServerConfiguration and all ServerInventory objects must be defined consistent with the selected LotUnit property.
Valuation Rules
This ValuationRule object defines parameters for defining the financial value of pool resources.
json
{
"DiscountPercent": 10,
"IncludeServerResidualValue": true,
"ResidualValueBidAskSpreadPercent": 40,
"InitialServerInventoryIsNew": false,
"HardwareAssignmentEventUnitCost": 50,
"HardwareAssignmentEventUnitCostChangePercent": 2.5
}
Attributes
DiscountRate - numeric - required
Percentage used to convert future financial data into present value.
IncludeServerResidualValue - boolean - optional
Determines if server residual value is included in a server's net cost when removed from a pool. The default value is 'true'.
How residual value is calculated
The residual value of server removed from a pool is based on an estimated wholesale price with respect to the current market rate of a new server.
The current market rate is derived from the current NewServerConfiguration object (at the time an existing server is removed from the pool), and based upon its cost per unit of performance value. The ResidualValueBidAskSpreadPercent property specifies the percent to reduce this value. The result represents an estimated wholesale price per performance unit, which is used to calculate a residual value and applied to the removed server .
InitialServerInventoryIsNew - boolean - optional
Determines if initial inventory in ServerInventory object is new and therefore the current server ServerUnitCost property is applied. Default value is 'false'.
HardwareAssignmentEventUnitCost - integer - optional
The unit cost applied For every hardware inventory added or removed. The hardware inventory unit may be a server or rack. An add and removal counts as two events. Default value is '0'.
Assignment Event Cost
Actual cost to add or remove hardware devices may be very small or economically meaningful depending on whether devices may be reassigned logically or physically moved. If InitialServerInventoryIsNew is true, a cost for the add event is calculated and included in the first interval of the FinancialSummary object. If false (i.e., the default value), then no cost is incurred and reported in the first interval for initial existing inventory.
Execution of event may depend on existing internal labor (i.e., a semi-fixed cost) or an external vendor fee (i.e., a variable cost).
Higher assignment event costs may reduce replacement rates when Optimal simulation type is selected.
HardwareAssignmentEventUnitCostChangePercent - numeric - optional
A drift factor, up or down, that is applied to HardwareAssignmentEventUnitCost. Drift percentage may not be greater than 99 percent or less than -99 percent. Default value is '0'.
New Server Configuration
This NewServerConfiguration object sets the configuration attributes for new servers that are added to a pool consistent with the lot unit indicated by the LotUnit property in the EvolutionRules object.
This code block defines the object when the lot unit is 'Server'.
json
"EvolutionRules": {
"LotUnit": "Server"
}
"NewServerConfiguration": {
"ServerCost": 10000,
"ServerPerf": 130,
"ServerWatts": 435,
"ServerSize": 2,
"ProcessorSetSize": 2,
"CoreSetSize": 24,
"Tag": {
"Model":"SZ260"
}
}
Attributes (unique to server lot unit)
ServerCost - numeric
Unit cost of server added to inventory.
This code block defines the object when the lot unit is 'Rack'.
json
"EvolutionRules": {
"LotUnit": "Rack"
}
"NewServerConfiguration": {
"RackSize": 42,
"RackServerQty": 21,
"RackCost": 210000,
"ServerPerf": 130,
"ServerWatts": 435,
"ServerSize": 2,
"ProcessorSetSize": 2,
"CoreSetSize": 24,
"Tag": {
"Model":"RZ260"
}
}
Attributes (unique to rack lot unit)
RackSize - integer
Quantity of available rack units using rack unit 'U' rating.
RackServerQty - integer
Quantity of servers that populate the rack.
RackCost - integer
Unit cost of a populated rack added to inventory.
Attributes (common)
ServerPerf - numeric - required
Scalar value representing server's relative performance rating.
ServerWatts - integer - required
Electrical power consumption rating in watts.
ServerSize - integer - required
Rack unit 'U' rating. Valid values are 1, 2, 4, 8 (i.e., 1U, 2U, 4U, 8U).
ProcessorSetSize - integer - required
Quantity of physical processors contained in a server's cpu sockets.
CoreSetSize - integer - required
Quantity of cores contained in physical processor.
Tag - object - optional
A reserved property name to custom describe a hardware unit (e.g., model) to minimally cross-reference to a user-maintained list. The property is only validated for well-formed JSON.
Configuration validation
Configuration is validated for arithmetical consistency.
For example, a valid configuration might be: RackSize property is 42, ServerSize property is 2, and ServerQty property is 21 or less.
An invalid configuration would be RackSize property is 40, ServerSize property is 2, and ServerQty property is 22 (i.e., 2 x 22 = 44 exceeds 40).
Power Consumption Terms
This PowerConsumptionTerms object defines power consumption and its cost.
json
{
"PoolPowerDrawPercent": "80",
"DatacenterPowerkWhCostRate": ".115",
"DatacenterPue": "1.6",
"PowerCostInflationPercent": "3.5"
}
Attributes
PoolPowerDrawPercent - numeric - required
Adjustment factor to tune actual consumption with respect to server watts rating versus metered use.
DatacenterPowerkWhCostRate - numeric - required
Unit cost rate per kilowatt hour.
DatacenterPue - numeric - required
Power Usage Effectiveness (PUE) rating.
PowerCostInflationPercent - numeric - required
Annual inflation percent for DatacenterPowerkWhCostRate property.
Facility Consumption Terms
This FacilityConsumptionTerms object defines data center space consumption and its cost.
json
{
"PowerConsumptionMarkupPercent": "0",
"FacilitySpaceUnitCost": "65",
"UnitCostInflationPercent": "2.75"
}
Attributes
PowerConsumptionMarkupPercent - numeric - optional
Markup percentage on power consumption cost if facility fee includes or is solely based on power consumption. Default is 0.
FacilitySpaceUnitCost - numeric - optional
Represents the annualized unit cost for physical space based on 1U rack unit. Default is 0.
How space costs are calculated
Zypr presently uses 1U as a baseline unit and will calculate the total 1U equivalent quantity weighted by time. For example, a server size of 2U would sum to two 1U equivalent units. If the duration of an interval is .25, then total space cost would be: annualized unit cost x .25 x 2.
Current permissible rack unit values are 1U, 2U, 4U, and 8U. If that doesn't meet your requirements, please reach out to us.
UnitCostInflationPercent - numeric - optional
Annual inflation factor applied to FacilitySpaceUnitCost property only. Default is 0.
INFO
The inflation adjustor for electricity is defined by the PowerCostInflationPercent property in the PowerConsumptionTerms object.
Software Resources
This SoftwareResources object defines the initial software stack of a pool and software inventory terms.
json
{
"PoolSoftwareStack": [1,2,3],
"SoftwareInventoryTerms": [..]
}
Important
The SoftwareResources object defines software whose consumption is correlated to hardware performance or efficiency and have a financial cost for their use. It is not intended to replicate SAM, CMDB, or TBM tools. Those applications typically serve as data sources to Zypr.
Attributes
PoolSoftwareStack - array of integers - conditionally required
Integer value corresponding to LicenseId property in SoftwareItem object. Sets the initial software stack for servers or racks included in ServerInventory object. Required when the SimulationCostScope property in SimulationRules object includes software costs.
TIP
A scenario only includes software costs of software items contained in the PoolSoftwareStack array. Use SoftwareStackAdd or SoftwareStackRemove jump events to add and remove a license id from the software stack at future times. All license ids contained in the PoolSoftwareStack, or a future jump event, must be defined in the SoftwareInventoryTerms object.
Software Inventory Terms - array of objects - conditionally required
List of SoftwareItem objects. Required when the SimulationCostScope property in SimulationRules object includes software costs.
Software Item
This SoftwareItem object defines software license terms and initial entitlement quantity.
json
{
"LicenseId": 1,
"LicenseMetric": "Processor",
"LicenseClass": "Perpetual",
"ContractType": "Coterminous",
"ContractTerms": {..},
"Fee": 6000,
"PerpetualSupportPercent": 25,
"InitialPosition": null,
"ConsumptionRules": {..},
"Tag": {
"SKU": xx-xxx-xxx-xxx"
}
}
Attributes
LicenseId - integer - required
Unique number for identifying the specific license terms.
LicenseMetric - string - required
Hardware unit used by vendor for counting license consumption.
License Metric Codes
Code | Description |
---|---|
Server | A physical computer |
Processor | Unit that corresponds to a cpu socket |
Core | Processor unit within a processor |
LicenseClass - string - required
Valid license classes are: 'Perpetual', 'Subscription'. A perpetual license governed by a ContractType of 'Coterminous' will have an accompanying financial obligation for support (see Software Cost Rules), whereas a ContractType of 'Instance' does not include any support.
ContractType - string - required
Determines the rules and costs of software consumption.
Contract Type Codes
Code | Description |
---|---|
Coterminous | Licenses and/or support rights are collectively organized to terminate simultaneously per a predefined schedule. One or more predefined schedules compose a settlement calendar. |
Instance | Licenses are not collectively organized. |
Contract type definitions and attributes
A coterminous contract type has the following attributes:
- License consumption is evaluated with respect to a settlement calendar.
- For each software item, Zypr generates a calendar, whose attributes are specified in the ContractTerms object.
- Required license quantity is based on the maximum quantity of licenses consumed during a use period, and carry-forwards to the next use period.
- Incremental increases in consumption are coterminous with the schedule.
- Vendor unit pricing rules and rates, for existing and incremental additions, may be further defined using the CostRules object.
- The PositionReset property enables the carry-forward maximum quantity to be reduced (i.e., reset) at either a future annual true-up or contract renewal date.
An instance contract type has the following attributes:
- License consumption and corresponding cost directly correlate to actual hardware consumption.
- Required subscription license quantity is based on the cumulative quantity of licenses consumed, which may increase or decrease over time.
- Required perpetual license quantity is based on the maximum quantity of licenses consumed. No support fee exists.
- The ContractTerms object is not applicable.
ContractTerms - object - conditionally required
Contains properties to define software consumption terms. Required when ContractType property is 'Coterminous'. Not applicable to 'Instance' contract type.
Fee - numeric - required
Amount paid per license. Fee may represent a one-time perpetual license fee, or the annualized fee for a subscription license.
PerpetualSupportPercent - numeric - optional
Percentage of one-time perpetual license fee that is incurred annually.
InitialPosition - integer - optional
Indicates the starting license position (i.e., quantity of paid licenses). Default is null.
Defining initial license position
A null value instructs Zypr to set the initial license quantity position equal to the initial quantity of physical server inventory based on the LicenseMetric property.
For example, if the LicenseMetric property is 'Core', the initial license quantity position will be set to the total number of cores contained in the ServerInventory object.
To explicitly set the initial license position, enter a positive integer.
If the number is less than the initial quantity of physical server inventory, an "add license" transaction will be triggered to cover the shortfall. If there are no paid-up licenses (e.g., a greenfield pool), enter 0 for the initial license position.
ConsumptionRules - object - optional
This ConsumptionRules object defines how required license position is determined with respective to hardware configuration, transactions and inventory balances. Consumption rules may be applied to both coterminous and instance contract types.
If license consumption is defined based upon "conditional rules", Zypr invokes its rule engine to evaluate the conditional logic. The code block below illustrates a rule with no conditional logic. How to define more conditional rules is covered in Software License Rule Engine section.
json
{
"ConsumptionRules": {
"Id": "1",
"RequiredLicenseQty": "1"
}
}
INFO
The code block above specifies a single metric is used to both count license consumption and specify required license quantity, with no conditional logic. The single metric is defined by the LicenseMetric property. If the ConsumptionRules property is omitted, Zypr will automatically generate this rule with the RequiredLicenseQty property set to 1.
Tag - object - optional
A reserved property name to custom describe a software item (e.g., SKU property ) to minimally cross-reference to a user-maintained list. The property is only validated for well-formed JSON.
Software Contract Terms
This ContractTerms object defines key elements of a software publisher's license terms. Zypr uses this information to auto-generate a settlement calendar and schedule of how vendor prices might change over time.
This object is required when the ContractType property value is 'Coterminous'.
json
"ContractTerms": {
"AnniversaryDate" : "2024-06-1T00:00:00 -5", // TZ - Eastern Standard Time
"TermLength": 3,
"AnnualTrueUpMonth": 9,
"CreateSettlementCalendar": "Custom",
"RenewalSchedule": "Contract",
"AttemptPositionReset": true,
"CostRules": []
}
AnniversaryDate - date - required
The next upcoming actual (or planned) date when the controlling license agreement ends and subsequently renews. Therefore, this date needs to be after the simulation ModelStartDate property value, which will be the same as the ModelEffectiveDate property value if set, or if not set, then the ScenarioCreateDate property value.
TermLength - numeric - required
Number of years a contract or license is in effect. Please note that a non-whole number will impact settlement calendar generation options (i.e., generated schedules will not all coincide on the same month and day).
AnnualTrueUpMonth - integer - optional
Annual month when true-up will occur. Default is month of AnniversaryDate property value.
CreateSettlementCalendar - string - required
Determines the unique settlement schedule Zypr automatically creates for this software item. Refer to the Settlement Calendar Codes for how to shape the calendar to your needs.
Schedule generation
Schedules are generated using combinations of TermLength, AnniversaryDate, and TrueUpMonth properties to create a settlement calendar. The generated calendar contains no duplicate dates, and is used to:
- Identify annual true-up and contract anniversary dates and their respective attributes.
- Automatically execute license renewals at the time indicated by the RenewalSchedule property.
- Identify a a vendor's price schedule, for rate and duration terms, with respect to annual true-up and/or contract anniversary dates.
- Support attempts to reset positions when the AttemptPositionReset property is true.
Settlement Calendar Codes
Code | Schedule Definition |
---|---|
Union | Combines contract and annual true-up settlement anniversaries into a single series of time intervals. Annual true-up dates are derived from the month and day of the contract anniversary date. Requires the TermLength value to be an integer. At intersecting contract and true-up anniversary dates, the date is identified as a contract anniversary. The TrueUpMonth property is ignored. |
Custom | Combines contract and annual true-up settlement anniversaries into a single series of time intervals. Annual true-up and contract anniversary month are both based on TrueUpMonth value. Requires the TermLength value to be an integer. At intersecting contract and true-up anniversary dates, the date is identified as a contract anniversary. |
Merged | Combines contract and annual true-up settlement anniversaries into a single series of time intervals. This is the required option if the TermLength value is a decimal number. When TermLength value is a decimal number, it is highly likely to result in a mix of intersecting and non-intersecting contract and true-up anniversary dates. When dates do intersect, the date is identified as a contract anniversary. TrueUpMonth property may be used. |
Contract | A single series of time intervals for contract anniversaries only. The TermLength value may be a decimal number. A schedule for annual true-ups is not included. TrueUpMonth property is ignored. |
RenewalSchedule - string - optional
Schedule used to generate automatic renewals. Valid values are: 'TrueUp' or 'Contract'. Default is 'Contract'.
AttemptPositionReset - boolean - optional
Set this property to 'true' permit attempt license position reduction. A license position reduction is not guaranteed. Default is 'false'. This feature can only be used on multiple software items with the same LicenseMetric property value.
Alpha release feature
This feature supports contract agreements with "consumption-based" terms, which permit existing spend to be reduced or reassigned to other applications offered by the software publisher.
Zypr will attempt to identify excess license positions with respect to what is actually required at each time interval for the entire duration of the simulation while avoiding the undesirable cost associated with terminating licenses that will need to be re-purchased soon thereafter.
A position may be reset only when contractually permitted. This is determined by the RenewalSchedule property. For example, if set to 'Contract', which has a TermLength value of three (3) years, a reset may only occur once every three years. If set to 'TrueUp', a reset may only occur annually. Invocation of a reset may only occur after the time interval that intersects with the renewal schedule anniversary date.
If more than one software items' AttemptPositionReset property is set to true, each will be independently evaluated and then compared to each other to find a solution that satisfies all schedule-based conditions.
CostRules - array of objects - optional
Defines publisher's rules that Zypr uses to generate the unit price rate schedule with respect to annual true-up and/or contract anniversary date. For subscription licenses or perpetual support agreements, defines publisher's rules that Zypr uses to generate the fix unit duration charge schedule with respect to annual true-up and/or contract anniversary date.
Software Cost Rules
This CostRules object enables customizations to define a software vendor's price schedule, fixed duration fees, and when costs are posted in the time-series output.
This object is optional. If the LicenseClass property value is 'Perpetual', and the CostRules property is omitted, empty, or null, Zypr will automatically generate the following default object.
This default setting means there will be no change to either the Fee or PerpetualSupportPercent properties in the SoftwareItem object. Any incremental cost associated to an incremental increase in software consumption will be posted at 'FirstUse'.
Duration-based costs are calculated based on actual use duration.
json
"CostRules": [
{
"LicenseType" : "Perpetual",
"PostAt": "FirstUse",
"Rate": {
"Schedule": "None",
"ChangePercent": 0,
}
},
{
"LicenseType" : "PerpetualSupport",
"PostAt": "FirstUse",
"Rate":{
"Schedule": "None",
"ChangePercent": 0,
},
"Duration": {
"Schedule": "None",
"IntervalPercent": 0
}
}
]
If the LicenseClass property value is 'Subscription', and the CostRules property is omitted, empty, or null, Zypr will automatically generate the following default object.
Any incremental cost associated to an incremental increase in software consumption will be posted at 'FirstUse'.
json
"CostRules": [
{
"LicenseType" : "Subscription",
"PostAt": "FirstUse",
"Rate": {
"Schedule": "None",
"ChangePercent": 0,
},
"Duration": {
"Schedule": "None",
"IntervalPercent": 0
}
}
]
Attributes
LicenseType - string - conditionally required
Required if LicenseClass property is 'Perpetual' in order to distinguish between perpetual license and annual support fees. Valid values are: Perpetual, PerpetualSupport, Subscription. If LicenseClass is 'Subscription', this property may be omitted.
PostAt - string - optional
Identifies when an incremental cost is recorded in the time-series. Default is 'FirstUse'. Valid values are: FirstUse, TrueUp, Contract. Value of 'TrueUp', or 'Contract' means an incurred incremental cost is recorded at the next respective anniversary date.
Rate - object - optional
Sets the fee schedule.
Schedule (Rate) - string - optional
Sets schedule to use for determining the effective date of a price change. Valid values are: 'None', 'TrueUp', 'Contract'. A value of 'None' means the ChangePercent property value, if specified, will be applied as a continuous rate. Values of either 'TrueUp' or 'Contract' means the ChangePercent property value is only applied at the start of schedule interval and remains unchanged until the start of the next interval period. Default value is 'None'.
ChangePercent - numeric - conditionally required
Annualized percentage change that is applied to fees in SoftwareItem object. Value can be positive or negative percentage. Only required if Schedule property value is either 'TrueUp' or 'Contract'. Default value is 0;
Duration - object - optional
Converts variable duration costs into a fixed duration cost for an incremental increase in a required license position. May only be applied to duration dependent subscription fee and/or perpetual support license types.
Schedule (Duration) - string - optional
Sets calendar to use when calculating a fixed duration. Valid values are: FirstUse, TrueUp, Contract. 'FirstUse' means use duration is not modified and remains the duration of actual consumption. When 'TrueUp' or 'Contract' is selected, their respective interval duration is applied to the IntervalPercent property value to arrive at a fixed duration. Default value is 'FirstUse'.
IntervalPercent - numeric - conditionally required
Percentage of interval time, per selected schedule, used to set fixed duration. Value must be between 0-100, inclusive. Only required if Schedule property value is 'TrueUp' or 'Contract'. Default value is 0.
Software Consumption Rule Engine
Zypr's rule engine supports rule nesting using the Rules array property. Conditional rules always start with two root properties: Operator and Rules. When defining nested rules, it is important to ensure rules are mutually exclusive, yet account for all feasible values to which the rule might be applied.
At the root-level, the "Or" operator is mandatory and denotes its chid rules are mutually exclusive. At this level, the rules must account for all feasible "counting" outcomes and not overlap (i.e., an outcome can be evaluated as true for two or more rules). A publisher's specific counting methodology can then be further expressed using nested rules, as illustrated in the code block below.
For example, both consumption rule objects below correspond to a processor-based license (i.e., LicenseMetric property is 'Processor').
The code block below reads as...
1 processor license is required when the core count per processor is less than or equal to 32, or 2 processor licenses when the core count per processor is greater than 32 per processor.
json
"ConsumptionRules": {
"Operator": "Or",
"Rules": [
{
"Id": "1",
"RequiredLicenseQty": 1,
"MetricName": "CoreSetSize",
"Operator": "LessThanOrEqual",
"TargetValue": 32
},
{
"Id": "2",
"RequiredLicenseQty": 2,
"MetricName": "CoreSetSize",
"Operator": "GreaterThan",
"TargetValue": 32
}
]
}
The code block below reads as...
1 processor license is required when the core count per processor is less than or equal to 32, 2 processor licenses when the core count per processor is greater than 32 and less than 64, and 3 processor licenses when the core count per processor exceeds 64.
json
"ConsumptionRules": {
"Operator": "Or",
"Rules": [
{
"Id": "1",
"RequiredLicenseQty": 1,
"MetricName": "CoreSetSize",
"Operator": "LessThanOrEqual",
"TargetValue": 32
},
{
"Id": "2",
"Operator": "And",
"RequiredLicenseQty": 2,
"Rules": [
{
"Id": "2.1",
"MetricName": "CoreSetSize",
"Operator": "GreaterThan",
"TargetValue": 32
},
{
"Id": "2.2",
"MetricName": "CoreSetSize",
"Operator": "LessThanOrEqual",
"TargetValue": 64
}
]
},
{
"Id": "3",
"RequiredLicenseQty": 3,
"MetricName": "CoreSetSize",
"Operator": "GreaterThan",
"TargetValue": 64
}
]
}
TIP
When defining nested rules, it is highly recommended you use outline numbering to identify rules. Zypr will only validate the rule Id property for duplicates. The Id solely exists for Zypr to identify to you, in a value you will recognize, a validation or other error related to the rule that prevents Zypr from executing.
Attributes
Operator - string - conditionally required
Logical operator for comparing multiple Rules. Valid values are: Or, And.
Id - string - required
Unique id for identifying different rules.
RequiredLicenseQty - numeric - required
Required quantity of licenses for "Basic" rule, or if "Conditional" rule, when boolean logic resolves to true.
MetricName - string - required
Physical inventory target. Valid values are: ProcessorSetSize, CoreSetSize.
Operator - string - required
Comparison operator. Valid values are:
- Equal
- GreaterThan
- GreaterThanOrEqual
- LessThan
- LessThanOrEqual
TargetValue - integer - required
Quantity to which actual use (i.e., consumption) is compared.
Server Inventory
This ServerInventory object defines a collection of initial server inventory of a pool.
json
{
"ServerInventory": []
}
Attributes
ServerInventory - array of objects - required
List of ServerItem objects.
Server Inventory Item
This object defines a collection of servers (or racks) with the same configuration. A record for each server is not required.
Each item must represent a unique configuration and will fail validation if duplicate entries are discovered. Uniqueness is defined by all an inventory item properties, except Code and ServerQty (or RackQty) properties.
The Code property provides a means to describe the inventory item (e.g., reference to a master list). Zypr doesn't validate or use this value.
This code block defines the object when the lot unit is a server.
json
"ServerInventory": [
{
"ServerQty": 5,
"ServerPerf": 105,
"ServerWatts": 425,
"ServerSize": 1,
"ProcessorSetSize": 2,
"CoreSetSize": 8,
"InitialAge": 3.75,
"Tag": {
"Model": SQ320"
}
}
]
Attributes (unique to server lot unit)
ServerQty - integer - required
Quantity of servers.
This code block defines the object when the lot unit is a rack.
json
"ServerInventory": [
{
"RackQty": 8,
"RackSize": 42,
"RackServerQty": 21,
"ServerPerf": 105,
"ServerWatts": 425,
"ServerSize": 1,
"ProcessorSetSize": 2,
"CoreSetSize": 8,
"InitialAge": 3.75,
"Tag": {
"Model": SQ320"
}
}
]
Attributes (unique to rack lot unit)
RackQty - integer - required
Quantity of racks.
RackSize - integer - required
Quantity of available rack units using rack unit 'U' rating.
RackServerQty - integer - required
Quantity of servers that populate the rack.
Attributes (common)
ServerPerf - numeric - required
A scalar value indicating server's relative efficiency rating to other servers.
Scalar performance rating
The basis for this scalar rating is determined by you, not by Zypr. Zypr's only requirement is the integer part of the number must have at least 3 digits (e.g., 100 or greater). This limits derived values (e.g., cost/performance) having too many digits to the right of the decimal point, which creates unnecessary 'tolerance' rounding challenges for the simulator, and may imply to decision-makers a degree of precision that doesn't exist (e.g., 2.105 vs 21) simply due to the scalar value selected.
ServerWatts - integer - required
Electrical power consumption rating in watts.
ServerSize - integer - required
Represents 'U' unit rating. Valid values are 1, 2, 4, 8 (i.e., 1U, 2U, 4U, 8U).
ProcessorSetSize - integer - required
Quantity of physical processors contained in a server's cpu socket.
CoreSetSize - integer - required
Quantity of cores contained in physical processor.
InitialAge - numeric - optional
Chronological age of servers. Only required when SimulationType property is set to 'Fixed'
Age-based calculations
If SimulationType property is set to 'Optimal', Zypr will use initial age in age-related calculations. If initial age is not available, Zypr will use only those transactions in which Zypr can identify a date added and a date removed when calculating age-related metrics.
Tag - object - optional
A reserved property name to custom describe a hardware unit (e.g., model) or cross-reference to a user-maintained list. The property is only validated for well-formed JSON.
Jump Events
This JumpEvents array defines a collection of jump events.
INFO
A jump event defines a discrete state change to a pool, at a desired time, and therefore how resource consumption, and corresponding transactions, may evolve.
Every jump event object included in the JumpEvents array contains the properties to describe a unique EventId, a valid EventType, and a TriggerTime indicating when the jump event occurs. Each jump event type specifies additional properties necessary to define their respective state change.
json
{
"JumpEvents": []
}
Attributes
JumpEvents - array of objects - required
List of jump events that describe discrete changes to the evolution state of pool resources. Valid jump events are listed in the Jump Event Types object reference.
Constraints
This Constraints object defines a collection of Constraint objects that limit the feasible solution space.
json
{
"Constraints": [
{
ConstraintTypeName : {..}
}
]
}
Attributes
Constraints - array of objects - required
List of constraint items to limit feasible solutions.
ConstraintTypeName - string - required
Name of constraint object type. Valid values are: HardwareBalance, PowerUsage.
Constraint
Purpose
This Constraint object defines a constraint type.
Defining a constraint
A constraint limits the feasible solution space, and is best expressed by stating what is not permitted:
For example, the code block below reads as follows: "Server cumulative inventory balance is not permitted GreaterThan than 128 servers After 2.0 years."
As a result, any solution after 2.0 years, which has an inventory balance that is more than 128 servers, will not be considered a feasible solution.
json
{
"HardwareBalance": {
"Id": 1,
"MetricName": "Server",
"MetricConstraintOperator": "GreaterThan",
"MetricTargetValue": 128,
"TimeConstraintOperator": "After",
"TargetTime": 2.0
}
},
{
"PowerUsage": {
"Id": 2,
"MetricName": "kWh",
"MetricConstraintOperator": "GreaterThan",
"MetricTargetValue": 1150000,
"TimeConstraintOperator": "After",
"TargetTime": 3.5
}
}
Attributes
Id - integer - required
Unique number to identify constraint.
MetricName - string - required
Metric Name by Constraint Type
Constraint Type | Description | Metric Name |
---|---|---|
Hardware Balance | Maximum server qty | Server |
Hardware Balance | Maximum processor qty | Processor |
Hardware Balance | Maximum core qty | Core |
Power Usage | Annualized kilowatt hours | kWh |
Power Usage | Performance per annualized kilowatt hours | ckKw |
MetricConstraintOperator - string - required
Comparison operator to set constraint scope with respect to selected metric unit.
Valid values are:
- LessThan
- LessThanOrEqual
- GreaterThan
- GreaterThanOrEqual
- NotEqual
- Equal
Targeted metric unit for constraint type.
MetricTargetValue - integer - required
Value that sets desired limit.
TimeConstraintOperator - string - required
Comparison operator to set constraint scope with respect to time.
Valid values are:
- Before
- BeforeOrAt
- AtOrAfter
- After
- At
- NotAt
- Any
TargetTime - integer - optional
Time within time-series when the constraint is applied.
Important
If the TargetTime property is omitted (or left empty or null), the TimeConstraintOperator property value will be automatically assigned 'Any'.
'Any' is a convenience value - a visual cue - to clearly document the defined limitation applies for the entire duration of the simulation (i.e., at any time).