A Shakespearean saunter through a navigable mine field of grid and script engines
How Came’st Thou in This Pickle?
Most Ion Group’s Openlink clients are familiar with the term “Grid”, a feature that enables the product to seamlessly distribute processing across server nodes. Grid should be contrasted with “Script Engines”, that use server nodes to process tasks, but in a non-distributed way. Long time users of the product typically leverage both types of engines to make the most of their license (and pennies), and fine-tune configuration on a regular basis to achieve optimal performance.
This is a highly technical, often poorly communicated area of the product, and there can be confusion about how to achieve the best results. Newer / less experienced clients may not even realize they can use both grid and script engines in tandem. In one extreme case, a client we work with did not even realize they owned grid engines!
Ion Group’s licensing approach to grid and script engines is also undergoing a change. Clients nearing an upgrade or that are in commercial discussions with Ion may have been offered a one for one conversion of script engines to grid engines. Now is a good time to review this complex layer of the application, and reach out if you have any questions.
The Ion plan to convert script engines to grid engines might in principle sound like an appealing offer, in line with Ion’s general push to Cloud strategy. However, just like the cloud, moving from one to the other is not all black and white, but different shades of grey…
To Grid or Not to Grid
Firstly, it is important to understand that, for now, the grid itself is not a mandatory feature of Openlink Products.
Services, such as batch processing of accounting or simulations, can be configured to run directly on Application Servers. The application servers have more than one script engine to deliver the solution’s horse power. Switching all services to run directly on the grid can prove counter-productive: by doing so the client is effectively not using script engines and is therefore reducing processing capacity.
Instead, a hybrid approach to distributing can be adopted, whereby some tasks are distributed to the grid whilst others run directly on application servers, making use of these script engines. Such an approach is particularly beneficial to granular processes, such as simulations. Note the more intricate the setup, the more understanding will be required on the part of the team supporting the system in the event of an outage (e.g., what to do if a given application server is down etc.).
The Grid-Only approach has advantages as it is self-balancing, supports failover of jobs to other servers if one is down, and is fully scalable (new servers or engine licenses can be purchased and added easily). If optimizing license cost is not paramount, this is the easiest, lowest-maintenance configuration possible for grid-enabled services.
Therefore, which way to go depends on your priorities. If ease of support and stability is a priority, a “set it and forget it” full-grid configuration should be the favored approach. However, if the target is to get the most processing power for your buck, a hybrid configuration is an attractive proposal, assuming there is in-house knowledge of how to recover in the event of an outage, a pain known to anyone with script engine experience.
All that is Grid-Only is not Gold
In later versions of its product, Ion Group has started to offer their clients a Grid-Only license type. It is aligned with the direction the Openlink product has been evolving in recent years (i.e., its new Openlink cloud offering).
It is important to understand the implications of that new license type, as it is understood to take away script engines altogether and firmly moving processing away from local user sessions and application servers, and onto the grid.
At this point in time, it is not clear whether losing script engines will not only move processing from application servers to the grid, but also processes that currently run within local user sessions such as ad-hoc reporting or post-processing operation services. Tasks running on the grid are also distributed by a dispatcher job that itself takes up an engine, which can have a negative impact on those clients with a small number of grid engines.
All of this can result in reduced performance if the grid is not properly sized and configured.
It is therefore recommended to conduct extensive performance testing to have a true understanding of the performance cost and assess if the new license type properly compensates clients for losing their script engines. One should establish the required number of additional grid engines to guarantee like-for-like performance. As far as we know this license type is not yet mandatory, but it feels like that directive is coming soon.
With Bated Breath
While we await the decision from Ion, it is important to review your setup in preparation for the change. As it is, the application services and grid setup should be regularly reviewed and adjusted as required – portfolios grow, configuration changes and the optimal solution last year may not be so this year.
If you are still running the setup configured as part of your original implementation, you should consider a review as your system requirements may have evolved significantly since go-live. This becomes more important with the looming move to Grid-Only.
Health checks are advisable on your application and grid-enabled services, especially around EOD and simulations, where there are potential performance bottlenecks. There are strategies available to make the most of certain grid-enabled services, allowing you to leverage distributed processing in places you may not have considered.
If you are interested in assessing whether you are making the most of your current license, or want some help assessing what a Grid-Only license would mean to you, reach out!
