Hi,
This is a common issue in multi-cluster installations and deserves a detailed answer. Below, I’ve summarized the official IBM references and the practical guidelines I’ve gathered from working on this!!! I hope they’ll be helpful to you.
In fact, the answer is no—it’s not necessary to have a dedicated physical or virtual Windows server for each IPQ instance. The 27+ instances required by your 9 clusters can easily be consolidated onto 3 Windows servers (one per site: Primary, DR, Tiebreaker), by running multiple instances of the Java process on the same host. The current 16 servers represent significant over-provisioning compared to what is required and recommended by IBM.
Cluster limit: the maximum number of IP quorum applications that can be deployed is five per cluster; applications can be installed on multiple hosts to provide redundancy (source: IBM Documentation and IBM SVC 7.7.0 whitepaper). The “3 IPQs per cluster (Primary + DR + Tiebreaker)” scheme is therefore perfectly aligned with IBM best practices and falls well within the limit of 5.
Network requirements:
- Port 1260/TCP used by the IP quorum application to communicate from the server to all nodes/node canisters
- Maximum round-trip delay: 80 ms (40 ms per direction)
- Minimum bandwidth: 2 MB/s between the system and the quorum application
- For systems running version 9.1.2.0 or later, a dedicated Quorum IP address is available (a more secure alternative to Service IP / Cluster IP)
Supported operating systems and Java (official IBM matrix): Windows Server 2016/2019/2022 with OpenJDK 8-17 or Oracle Java 8-14 (IBM Java 8 is also supported on Win2016). Note: Windows Server 2019 and 2022 do NOT support IBM Java—only OpenJDK or Oracle.
Furthermore, multiple IPQ instances on the same Windows server are supported since, technically, each ip_quorum.jar is an independent Java process that opens outbound connections to port 1260 of the canister nodes in its cluster. Therefore, there is no conflict over listening ports on the IPQ host: dozens of JVMs can run on the same server without network issues.
CONSTRAINTS:
- Do not install the IP quorum application on a host that relies on storage presented by the system itself. IBM Documentation: “Doing so might result in a deadlock situation where the nodes in the system need to detect the IP quorum application to process I/O, but the IP quorum application needs to access storage on the system to respond.” Windows IPQ servers must therefore NOT have SAN disks originating from the 9500/7200/9200/SVC models they are arbitrating.
- The JAR file is cluster-specific and signed. It must be regenerated and redistributed to all hosts running it when: IP services are modified, the system’s SSL certificate is renewed, a node canister is added or removed, or after certain firmware upgrades.
- Each cluster has its own JAR. The 9 instances on the same server will be 9 distinct JAR files (one per array), each running in its own JVM.
Architecture I would use and recommended by IBM for 9+ arrays:
Consolidation scheme across 3 Windows servers (one per site):
Server-IPQ-PRIMARY (Primary Site) → 9 JVM instances (1 per cluster)
Server-IPQ-DR (DR Site) → 9 JVM instances (1 per cluster)
Server-IPQ-TIEBRK (Tiebreaker Site) → 9 JVM instances (1 per cluster)
On Windows, each instance must be registered as a separate service (NSSM “install IPq_<cluster>” with a unique name) and started with the -name <cluster_site> parameter for quorum traceability. Example for two clusters:
- nssm install IPq_FS9500_TB “C:\...\java.exe” -jar C:\IPQ\FS9500\ip_quorum.jar -name ipq_FS9500_TB
- nssm install IPq_SVC1_TB “C:\...\java.exe” -jar C:\IPQ\SVC1\ip_quorum.jar -name ipq_SVC1_TB
The official IBM procedure is described in the IBM Documentation under “IP quorum application configuration” / “Installing an IP quorum application”. Direct links for active releases on the affected products:
• FlashSystem 9500/9200 release 9.1.2 (Quorum IP address):
https://www.ibm.com/docs/en/flashsystem-9x00/9.1.2?topic=ip-quorum-addresses
• FlashSystem 9500/9200 release 9.1.1:
https://www.ibm.com/docs/en/flashsystem-9x00/9.1.1?topic=quorum-ip-application
• FlashSystem 9500/9200 release 8.7.0:
https://www.ibm.com/docs/en/flashsystem-9x00/8.7.0?topic=quorum-ip-application
• FlashSystem 9500/9200 release 8.6.x:
https://www.ibm.com/docs/en/flashsystem-9x00/8.6.x?topic=started-ip-quorum-application-configuration
• FlashSystem 9500/9200 release 8.5.0:
https://www.ibm.com/docs/en/flashsystem-9x00/8.5.0?topic=quorum-ip-application-configuration
• FlashSystem 7200/7300 release 8.6.0:
https://www.ibm.com/docs/en/flashsystem-7x00/8.6.0?topic=q-ip-quorum-application
Steps I’ve noted down that might be helpful to you:
1. Cluster GUI → Settings → System → IP Quorum (or CLI mkquorumapp) → download the signed JAR (IPv4 or IPv6).
2. Copy the JAR to the Windows server in a dedicated subdirectory for each cluster (e.g., C:\IPQ\<cluster_name>\).
3. Verify connectivity to the service IPs (or quorum IPs for ≥9.1.2.0) of all nodes; open outbound port 1260/TCP from the IPQ server.
4. Initial test startup: java -jar ip_quorum.jar -name <id> and verify with lsquorum on the cluster.
5. Register as a Windows service via NSSM.
6. Final verification: the output of lsquorum must show the application as “active”.
In summary, the 3 IPQs per array are correct and comply with IBM best practices (below the hard limit of 5). It is not necessary to dedicate a Windows server for each instance: it is a practice supported and documented by IBM personnel to consolidate multiple JVM instances of the same ip_quorum.jar (one per cluster) on the same server, registering them as separate Windows services via NSSM and identifying them with the -name parameter. You can therefore reduce the number of servers from 16 to 3 (one per site) without losing redundancy or violating official requirements, provided that critical constraints are met: none of the IPQ servers must depend on the storage of the clusters they are arbitrating, port 1260 must be reachable, RTT <80ms, bandwidth ≥2 MB/s, and the JAR must be regenerated with every cluster configuration change.
Best regards,
Roberto