We’re happy to announce the release of both Open Cluster Scheduler 9.1.3 and Gridware Cluster Scheduler 9.1.3. As always, the two share the same foundation: all core scheduler improvements and fixes in this release land in the open-source Open Cluster Scheduler, and Gridware Cluster Scheduler builds on top of that solid base, adding enterprise capabilities for specific use cases. In 9.1.3 those additions are substantial: PostgreSQL as a spooling backend – one of the most requested infrastructure improvements in recent memory – and continued progress on Qontrol, our web-based administration UI.
In short: if you run Open Cluster Scheduler, 9.1.3 brings you all the reliability, and core system improvements. If your environment calls for high-availability spooling on PostgreSQL or centralized administration through Qontrol, that’s where Gridware Cluster Scheduler comes in.
PostgreSQL Spooling: Simpler, Safer, Built for High Availability (Gridware Cluster Scheduler)
Until now, sge_qmaster stored its state either in classic filesystem spooling or in BerkeleyDB – both solid, well-proven options. Where things get tricky is at the edges: shadow-master failover configurations need shared state, but BerkeleyDB is not fully supported on NFS, and classic spooling inherits whatever reliability your shared filesystem provides.
With 9.1.3, there’s a third option for exactly these cases: point your cluster’s spool state at a PostgreSQL database.
Classic and BerkeleyDB spooling remain fully supported and are proven, reliable choices for most clusters. PostgreSQL spooling is aimed at the setups where they hit their limits.
Why this matters for your cluster:
A shared store for environments where filesystem spooling is hard. BerkeleyDB does not fully support NFS, which has always constrained failover configurations, and classic spooling depends on the behavior of the shared filesystem underneath it. With PostgreSQL, every spool write is a database transaction over TCP – your cluster configuration, jobs, queues, and share tree live in an ACID-compliant store that is independent of NFS quirks and storage-vendor differences.
High availability without the NFS constraints. Multiple shadow masters can share the same PostgreSQL instance over the network. Since the bulk of the cluster state travels over TCP to the database, there is no BerkeleyDB environment directory on NFS and no storage-specific locking to work around – exactly the scenario where the existing backends couldn’t offer a clean answer.
Simplified setup. Provisioning is deliberately minimal: one database role, one database, and the installer takes care of the schema. Credentials are handled the way PostgreSQL operators expect – via a standard .pgpass file with proper permissions – so no secrets ever end up in world-readable configuration.
Backup and restore that just works. The familiar installer tooling now handles PostgreSQL spools end to end, producing consistent dumps and performing all-or-nothing restores. Disaster recovery for your qmaster state becomes a routine database operation.
An easy on-ramp if you need it. For sites that do want PostgreSQL — typically those planning a shadow-master setup on storage where the existing backends are constrained — the standard upgrade procedure doubles as the migration path: choose PostgreSQL during the upgrade, provide the connection details, and the upgraded qmaster starts fresh against your database. No separate migration project required. And if classic or BerkeleyDB spooling serves you well today, there’s no need to change anything.
Connection handling builds on standard libpq, so everything you already know about PostgreSQL — TLS options, keepalives, connection timeouts — applies directly. Full details are in the “PostgreSQL Spooling” chapter of the Installation Guide and the “High Availability and Reliability” chapter of the Administration Guide.
Qontrol Keeps Growing into Its Role (Gridware Cluster Scheduler)
Qontrol, our modern replacement for qmon, gains several quality-of-life improvements in this release. Administrators can now edit the dbwriter configuration and rules directly from the UI, manage cluster configuration files such as prolog, epilog, and bootstrap from a dedicated “Configuration Files” section, and configure port ranges without dropping to the command line.
We’ve also invested in forward compatibility: Qontrol now gracefully displays configuration parameters it doesn’t yet know about, so a Qontrol version never has to hide parts of your global or scheduler configuration from you. Rounding things out, workflows like associating parallel environments or calendars with queues and adding API keys now behave exactly as you’d expect.
The direction is clear: day-to-day cluster administration should be possible — and pleasant — from one place.
SQL DB Integration for Accounting and Reporting (dbwriter): Easier Installs, More Dependable Reporting
Accounting and reporting data is only valuable if the pipeline feeding it is dependable. This release brings a round of stabilization to dbwriter, with a focus on the installation experience: automated installs via template files, cleaner handling of existing configurations and coexisting databases, and fixes that prevent reporting data from being silently discarded in edge cases. If reporting is part of your compliance or chargeback story, 9.1.3 makes that foundation noticeably sturdier.
Better Support for AI Workloads
Our work on AI workload support continues. The MCP server now handles large accounting logs without stalling and gains structured logging for easier debugging.
Reliability Across the Board — in Both Editions
The core system improvements in 9.1.3 benefit Open Cluster Scheduler and Gridware Cluster Scheduler alike. This release resolves a series of issues that improve robustness in daily operation – from smoother execution daemon reconnects in TLS setups and correct systemd integration on shadow-only hosts, to fixes in share-tree usage reporting and privilege handling. Upgrades and migrations are also quieter and cleaner, with several cosmetic and logging issues addressed.
Additionally, license integration gains finer control: operators can now choose to expose only the licenses defined in the alias file as scheduler complexes, keeping the complex configuration focused on what your site actually uses.
Get Started
Open Cluster Scheduler 9.1.3 and Gridware Cluster Scheduler 9.1.3 are available now. Open Cluster Scheduler remains a fully capable, production-grade workload manager – and everything in it flows directly into Gridware Cluster Scheduler, which adds enterprise features like PostgreSQL spooling, Qontrol, and professional support for sites that need them. As always, the release notes contain the complete list of changes, and the Installation and Administration Guides cover the new PostgreSQL spooling backend in depth.
If you’d like to talk about whether PostgreSQL spooling is the right fit for your environment – or whether Open Cluster Scheduler or Gridware Cluster Scheduler is the better match for your site – get in touch; we’re happy to help.
