What High Availability Options Are Available with InMotion Cloud?

Downtime costs money. For e-commerce sites, a single hour of outage can mean thousands in lost revenue. For SaaS platforms, it damages customer trust. For healthcare systems, it can impact patient care. The question most teams ask when evaluating cloud infrastructure is simple: "Does InMotion Cloud provide high availability?"

The answer is yes. But understanding exactly what that means requires looking at two distinct layers: infrastructure HA and application HA. InMotion Cloud provides excellent building blocks for resilient architectures. How you assemble those blocks determines whether your applications survive failures gracefully or crash when a single component fails.

What Does High Availability Mean?

High availability describes systems designed to remain operational during failures. Rather than hoping nothing breaks, HA architectures assume failures will happen and plan accordingly.

The core principles include:

• Minimizing downtime through redundant components that take over when primary systems fail
• Eliminating single points of failure so no single component can bring down the entire system
• Automatic failover that switches to backup systems without human intervention
• Redundancy at every critical layer, from compute to storage to networking

Consider a simple example. A single web server handles all traffic for your application. When that server fails, your application goes offline until someone fixes it. Now imagine two web servers behind a load balancer. When one server fails, the load balancer automatically routes traffic to the healthy server. Users never notice the failure.

That second architecture costs more to run. But for production workloads where uptime matters, the investment pays for itself the first time a server fails at 3 AM and your application keeps running.

Infrastructure HA vs Application HA

These two concepts often get confused. Understanding the distinction helps you design systems that actually stay online.

Infrastructure HA covers the cloud platform itself. This includes:

• Redundant controllers that keep the cloud API responsive even when nodes fail
• Clustered databases using technologies like Galera that replicate data across multiple nodes
• Redundant networking with multiple paths between components
• Resilient storage backends with replication and failover capabilities
• Load-balanced API services distributed across multiple physical machines

InMotion Cloud handles infrastructure HA. Our deployment runs on redundant controllers, clustered databases, and resilient storage. When a controller node fails, the cloud keeps operating. You do not need to manage this layer.

Application HA covers your workloads running on the cloud. This includes:

• Multiple web servers distributing traffic across instances
• Database replication and clustering within your application stack
• Redundant application servers for backend processing
• Container orchestration platforms like Kubernetes that reschedule failed workloads
• Data replication between instances and availability zones

Application HA is your responsibility. InMotion Cloud provides the tools. You design and implement the architecture.

Think of it this way: Infrastructure HA keeps the cloud running. Application HA keeps your specific workloads running. A perfectly healthy cloud cannot prevent your single-instance application from failing when that instance crashes.

HA Features Available in InMotion Cloud

InMotion Cloud provides several features specifically designed to help you build highly available applications.

Managed Load Balancers

Load balancers distribute incoming traffic across multiple backend servers. On InMotion Cloud, the Octavia service provides load balancing as a managed feature.

Key capabilities include:

• Traffic distribution using algorithms like round-robin, least connections, or source IP affinity
• Health monitoring that continuously checks backend servers and removes failed nodes from rotation
• Automatic failover that happens transparently when backend servers fail
• Support for active-active deployments where all backend servers handle traffic simultaneously

Creating a load balancer through Horizon or the CLI gives you a virtual IP address. Point your DNS at that IP. Add your application servers as pool members. The load balancer handles the rest.

For web applications, this means deploying two or more identical application servers behind a load balancer. When traffic spikes, add more servers to the pool. When a server fails, the load balancer stops sending it traffic within seconds.

Floating IPs

Floating IPs provide public IP addresses that you can move between instances. Unlike fixed IPs that belong to a specific instance, floating IPs exist independently and can be reassigned instantly.

Common use cases include:

• Manual failover for active/passive configurations where you move the IP from a failed primary to a standby
• Maintenance scenarios where you detach the IP, perform maintenance, and reattach it
• Blue-green deployments where you shift traffic between old and new application versions

For applications that cannot run in active-active mode behind a load balancer, floating IPs enable a different HA pattern. Deploy a primary server and a standby server. When the primary fails, move the floating IP to the standby. Traffic starts flowing to the backup server within seconds.

This pattern works well for legacy applications, Windows servers with specific licensing requirements, or any workload where only one instance should handle traffic at a time.

Persistent Block Storage with Cinder

Cinder provides persistent block volumes that exist independently of compute instances. Unlike ephemeral storage that disappears when an instance terminates, Cinder volumes retain their data.

This enables several HA patterns:

• Instance rebuilds where you terminate a failed instance and attach its volume to a new one
• Data persistence that survives instance failures, allowing quick recovery
• Snapshots that capture point-in-time copies of your data for backup and recovery
• Volume migration between instances without data loss

For database servers, store your data on Cinder volumes rather than ephemeral storage. If the instance fails, launch a new instance, attach the existing volume, and start the database. Your data remains intact.

Combine this with regular snapshots for disaster recovery. Schedule daily snapshots of critical volumes. If something corrupts your data, restore from the most recent clean snapshot.

Snapshots and Backups

Snapshots capture the complete state of an instance or volume at a specific moment. For HA and disaster recovery, snapshots provide a safety net when other protections fail.

Snapshot strategies include:

• Scheduled instance snapshots that capture your entire server configuration
• Volume snapshots that protect specific data volumes
• Image-based recovery where you launch new instances from snapshots
• Cross-region backups for geographic disaster recovery

Snapshots complement but do not replace real-time HA. A snapshot from six hours ago means you lose six hours of data if you need to restore. But when your database corruption goes unnoticed for a day, that week-old snapshot becomes invaluable.

Monitoring and Alerting

Detecting failures quickly limits their impact. InMotion Cloud provides monitoring capabilities that help you identify problems before they cascade.

Effective monitoring covers:

• Instance health including CPU, memory, disk, and network metrics
• Application endpoints that verify your services respond correctly
• Log aggregation that captures errors and warnings across your infrastructure
• Alerting rules that notify your team when thresholds are exceeded

The faster you detect a failure, the faster you can respond. Automated monitoring combined with load balancer health checks can remove failed components from service before users notice problems.

Common HA Architectures

Theory matters less than implementation. Here are proven architectures you can deploy on InMotion Cloud today.

Two Web Servers Behind a Load Balancer

The simplest HA pattern for web applications. Deploy two identical servers running your web application. Place them behind an Octavia load balancer. Configure health checks that verify your application responds correctly.

Benefits of this architecture:

• Automatic failover when either server fails
• Rolling maintenance where you update one server at a time
• Horizontal scaling by adding more servers to the pool
• Zero-downtime deployments using blue-green or rolling update strategies

This pattern works for stateless web applications, APIs, and microservices. For stateful applications, you need shared storage or session replication, but the basic architecture remains the same.

Active/Passive Server Pair

Some applications cannot run on multiple servers simultaneously. License restrictions, legacy architectures, or application design may require a single active instance.

For these cases, deploy a primary server and a standby server. Configure monitoring on the primary. When it fails, move the floating IP to the standby and start the application.

This pattern suits:

• Windows applications with per-server licensing
• Legacy software not designed for clustering
• Database servers where only one instance should write data
• License servers that must run on a single host

Automation makes this pattern more effective. Scripts that detect primary failure and automatically move the floating IP reduce recovery time from minutes to seconds.

Database High Availability

Databases require special consideration because they manage persistent state. Several proven technologies provide database HA on InMotion Cloud:

MariaDB Galera provides synchronous multi-master replication. All nodes can accept writes. Data replicates to all nodes before transactions commit. Deploy three or more nodes for automatic failover.

PostgreSQL with Patroni uses streaming replication with automatic failover. Patroni manages leader election and failover. Combined with HAProxy, clients connect to a single endpoint that routes to the current primary.

MySQL Group Replication provides native clustering for MySQL. Similar to Galera, it supports multi-primary or single-primary modes with automatic failover.

SQL Server Always On availability groups work on Linux or Windows. Configure replicas across multiple instances. SQL Server handles replication and failover.

In all cases, InMotion Cloud provides the compute instances, networking, and storage. The database software provides replication and failover logic. Deploy database nodes across different compute hosts using anti-affinity rules to prevent a single hardware failure from taking down multiple nodes.

Kubernetes for Self-Healing Workloads

For containerized applications, Kubernetes provides built-in HA capabilities. Deploy a Kubernetes cluster on InMotion Cloud with multiple worker nodes.

Kubernetes handles:

• Pod scheduling across available nodes
• Automatic restart of failed containers
• Service discovery that routes traffic to healthy pods
• Rolling updates that replace containers without downtime

When a worker node fails, Kubernetes reschedules its pods to surviving nodes. When a container crashes, Kubernetes restarts it automatically. The declarative model means you describe what you want running, and Kubernetes maintains that state.

For production Kubernetes, deploy at least three control plane nodes and multiple worker nodes. Spread worker nodes across failure domains using anti-affinity rules.

Best Practices for High Availability

These recommendations apply across architectures and workload types.

Deploy multiple application servers. A single server is a single point of failure. Two servers behind a load balancer provide basic HA. Three servers allow maintenance without reducing redundancy.

Use load balancers for all external traffic. Even if you run a single backend server, the load balancer provides a stable endpoint. When you add servers later, no DNS changes are required.

Avoid single points of failure everywhere. Review your architecture for components where a failure causes downtime. Add redundancy or design for graceful degradation.

Separate application and database tiers. Running your database on the same server as your application means both fail together. Separate tiers allow independent scaling and maintenance.

Use persistent storage for stateful data. Cinder volumes survive instance failures. Ephemeral storage does not. Design your data persistence accordingly.

Schedule regular snapshots. Daily snapshots of critical volumes provide disaster recovery options. Automate the schedule so it happens consistently.

Monitor everything. You cannot fix problems you do not know about. Instrument your applications and infrastructure. Set up alerts for anomalies.

Test failover regularly. An HA architecture you have never tested is an assumption, not a guarantee. Schedule regular failover tests to verify your systems behave as expected.

Use anti-affinity server groups. When you deploy multiple instances for redundancy, use server groups with anti-affinity policies. InMotion Cloud schedules those instances on different compute hosts, preventing a single hardware failure from affecting multiple instances.

Common Misconceptions

One question comes up repeatedly: "If my VM crashes, does InMotion Cloud automatically move it to another host?"

The short answer is no. When an instance fails, InMotion Cloud does not automatically migrate or restart it. The instance remains in an error state until you take action.

This surprises people who expect cloud platforms to handle everything automatically. But consider the implications. If your instance crashed due to a bug in your application, automatically restarting it just causes it to crash again. If the crash corrupted data, restarting could make things worse.

InMotion Cloud provides the building blocks for resilient architectures. It does not make architectural decisions for you. You design how your workloads respond to failures by choosing patterns like load balancers, database clustering, Kubernetes, or automated recovery scripts.

This design philosophy gives you control. For simple workloads, you might accept manual recovery. For critical workloads, you implement automated HA patterns using the tools InMotion Cloud provides.

The InMotion Cloud Alternative: Transparent, Predictable Pricing

Building highly available architectures on hyperscaler platforms often comes with billing surprises. Load balancer hours, data transfer between availability zones, storage IOPS charges, and network egress fees accumulate in ways that are difficult to predict. Teams discover their HA setup costs twice what they expected only after the invoice arrives.

InMotion Cloud takes a different approach. Our pricing is transparent and based on actual resource consumption. You know exactly what compute instances, storage volumes, and networking components cost before you deploy them. No hidden fees for internal traffic. No surprises when your load balancer handles more connections than expected.

When you deploy your HA architecture on InMotion Cloud, you work directly with cloud architects who understand InMotion Cloud and distributed systems. Need help designing a database cluster? Want to review your failover strategy? Our team provides guidance without additional consulting fees. You get the technical expertise of a managed service with the flexibility of infrastructure you control.

Fair billing means running redundant infrastructure for HA does not require painful budget negotiations. When adding a second application server costs a predictable amount rather than triggering complex pricing tiers, teams build resilient systems from the start rather than treating redundancy as a luxury.

Conclusion

High availability on InMotion Cloud requires understanding two layers. InMotion Cloud maintains infrastructure HA: redundant controllers, clustered databases, and resilient storage keep the platform running. You design application HA: load balancers, database clustering, and redundant instances keep your specific workloads available.

The building blocks are proven and powerful. Load balancers distribute traffic and remove failed backends automatically. Floating IPs enable manual failover for active/passive configurations. Cinder volumes persist data independently of instances. Snapshots provide disaster recovery options. Monitoring detects failures before they cascade.

The architecture you choose depends on your requirements. Stateless web applications work well behind load balancers. Legacy applications may need active/passive with floating IPs. Databases require clustering software appropriate to your platform. Kubernetes provides self-healing for containerized workloads.

Whatever pattern you implement, design with redundancy from the start. Adding HA after deployment is harder and more expensive than building it in from the beginning.

Ready to design a highly available architecture for your workloads? Contact the InMotion Cloud team. Our cloud architects can help you evaluate options, plan your deployment, and implement resilient infrastructure that keeps your applications running.