By Guest: Matthew Pollard (LinkedIn)
Company: SIOS Technology
Show: Mission Critical
Topic: High Availability
High availability architecture isn’t just about preventing downtime. It’s about understanding what happens when systems fail, how data replicates across cloud regions, and whether your provider can actually prevent catastrophic scenarios like split brain conditions. For enterprises running mission-critical workloads like SAP HANA or SQL Server, choosing the wrong HA solution can be more dangerous than having no strategy at all.
📹 Going on record for 2026? We're recording the TFiR Prediction Series through mid-February. If you have a bold take on where AI Infrastructure, Cloud Native, or Enterprise IT is heading—we want to hear it. [Reserve your slot
Matthew Pollard, Customer Experience Software Engineer at SIOS Technology, emphasizes that enterprises need to ask deeper questions about what their HA providers actually monitor and protect. The conversation reveals critical gaps that many organizations overlook when evaluating solutions.
Beyond Basic Server Monitoring
Most HA solutions monitor server health, but that’s only part of the picture. Pollard explains that SIOS products provide versatility across multiple failure points. “We monitor and protect against various failures at the application level, the network level, and the storage level,” he says. This includes resource kits for handling application-specific failures, monitoring system reachability and network availability, and providing replication of data across nodes for consistent access.
The key distinction is comprehensiveness. An HA solution that only monitors system availability while ignoring application-level failures creates blind spots that can lead to service disruptions.
Replication Strategies for Disaster Recovery
When it comes to disaster recovery scenarios requiring replication across cloud regions and availability zones, the physics of distance creates challenges. Pollard acknowledges this directly: “While geographic separation provides higher protection against larger-scale failures, the simple physics of it incurs performance overhead and delays.”
SIOS addresses this through tunable replication options. Customers can choose between synchronous and asynchronous replication, trading some performance overhead for slightly lower protection thresholds in disaster recovery scenarios. “Those are the things you should be asking your HA provider about,” Pollard notes. “What options do we have? What tuning parameters are available?”
The Cloud Storage Question
Cloud providers already offer redundant storage built into their platforms, which raises an important question: why would enterprises need third-party clustering solutions like SIOS? Pollard’s answer cuts to the core of the problem.
Cloud-level redundancy focuses on infrastructure, the hardware layer that hosts your systems. But there’s an entirely separate layer at the application level. “Products like SIOS high availability products come in and monitor and protect and orchestrate switchovers, failovers, monitoring, enabling maintenance on those applications,” he explains. That application-level protection isn’t covered by cloud provider infrastructure redundancy.
Preventing Split Brain Scenarios
Split brain conditions represent one of the most dangerous situations in HA architecture. When network partitions occur and systems can’t agree on which node is the source of truth, data corruption becomes a real risk. SIOS products include automated split brain resolution and consistent tracking of the proper source node across systems.
“If not all nodes can agree on what the actual source is supposed to be, we can stop that scenario of a source with bad data overriding a former source that still had the correct data,” Pollard says. The system uses validation checks and fencing to prevent corruption, while alerting administrators to the situation.
Orchestrating Complex Failovers
Moving complex databases like SAP HANA or SQL Server during failover involves boot order dependencies, service placement requirements, and vendor-specific configurations. SIOS handles this through application recovery kits, software components engineered specifically for particular resources following vendor best practices.
These recovery kits understand what components need to be present, what needs to move together, and how to handle dependencies automatically. For unique environment needs, SIOS provides customization through generic applications and quick service protection, allowing organizations to define their own scripts for components they’ve developed internally.
The message from Pollard is clear: before committing to an HA solution, enterprises need to ask about monitoring scope, replication flexibility, application-level protection, split brain prevention, and failover orchestration capabilities. The right questions reveal whether a provider can actually protect mission-critical workloads or just check basic infrastructure boxes.
