Education and information technology (IT) are increasingly inextricable. Whether the IT in question is an application supporting a classroom whiteboard, the database supporting a university registration system, the learning management systems (LMS), or the building maintenance system controlling student access to the labs, dorms, and dining halls — if key components of your IT infrastructure suddenly go dark, neither teachers, administrators, nor students can accomplish what they are there to accomplish. The mission of the institution is interrupted. If the interruptions are too frequent, if the experiences of students, teachers, and administrators suffer, the reputation of the institution itself can suffer as well.
An IT infrastructure designed to ensure the high availability (HA) of applications crucial to the educational experience can minimize the risk of disruption and reputational loss that could occur if for any reason these systems become unresponsive. In this instance, an HA infrastructure is defined as one capable of ensuring the availability of key applications no less than 99.99% of the time. Put another way, that means that your critical applications won’t be unexpectedly offline for more than four minutes per month.
How do you achieve HA? That question is readily answered, but it is not the only question you need to ask. Just as important is this: Which applications are so critical that they warrant an HA configuration? At its heart, an IT infrastructure configured for HA has one or more sets of secondary servers and storage subsystems that are housed in a geographically distinct location (which could be a remote data center if your primary server resides on-premises or in a separate availability zone [AZ] if your servers reside in the cloud). If something causes the applications running on the primary server to stop responding, the HA software managing your application will immediately fail over the application to the secondary server, where your critical applications will start up again from the point at which the primary server stopped responding. Depending on the size and performance characteristics of the primary server you plan to replicate, that secondary server may be costly, so it’s unlikely you’re going to configure all your academic applications for HA. Once you determine which applications warrant the investment in HA, you’ll know where you need to build out an HA environment.
Choices for Achieving High Availability
Once you’ve chosen the applications you intend to protect, your options for achieving HA become clearer. Are they running on Windows or Linux? Does your database management system (DBMS) have built-in support for an HA configuration? If so, what are its limitations? If your critical applications are running on Windows and SQL Server, for example, you could enable HA using the Availability Group (AG) feature of SQL Server itself. Alternatively, you could configure HA using a third-party SANless clustering tool, which offers options that the AG services in SQL Server do not. If you’re trying to protect database servers from multiple vendors, or if some of your critical applications run on Windows while others run on Linux, your ability to manage HA will be facilitated by the use of an HA solution that supports multiple DBMS and OS platforms. Opting for a cluster solution that accommodates diverse DBMS and OS platforms simplifies management, in contrast to the potential complexity and cumbersomeness of handling multiple database-native HA services concurrently..
Ensuring High Availability via database-native HA solutions
If you’re using a database-native HA solution, such as the AG feature of SQL Server, the software will synchronously replicate all the data in your primary SQL Server database to an identical instance of that database on the secondary system server. If something causes the primary server to stop responding, the monitoring features in the AG component will automatically cause the secondary server to take over. Because the AG feature has replicated all the data in real time, the secondary server can take over immediately and there is virtually no interruption of service or loss of data.
Many database-native HA tools operate in a similar manner. There are a few caveats, though, when considering a database-native approach: If the HA services are bundled into the DBMS itself, they may replicate only the data associated with that DBMS. If other critical data resides on your primary server, that will not be replicated to the secondary server in a database-native HA scenario. There may be other limitations on what the database-native services will replicate as well. If you use the Basic AG functionality that is bundled into SQL Server Standard Edition, for example, each AG can replicate only a single SQL database to a single secondary location. You could create multiple Basic AGs if your applications involve multiple SQL databases, but you cannot control whether each AG fails over at the same time in a failover situation — and problems may arise if they do not. One way around this limitation would be to use the Always On AG functionality bundled into SQL Server Enterprise Edition, which enables the replication of multiple SQL databases to multiple secondary servers, but that can get very expensive from a licensing perspective if your applications don’t otherwise use any of the features of SQL Server Enterprise Edition.
Other database-native HA solutions may have similar constraints, so be sure to understand them before investing in such an approach.
Ensuring High Availability via SANless Clustering
As an alternative to the database-native approach to HA, you could use a third-party tool to create a SANless cluster. Just as in the AG configuration described above, the SANless clustering software automates the synchronous replication of data from the primary to the secondary server; it also orchestrates the immediate failover to the secondary server if the primary server becomes unresponsive. Because failover takes only seconds, administrator, faculty, and student access to your critical applications will remain virtually uninterrupted.
The critical differences between the SANless clustering and a database-native approach lie in the practical details. The SANless clustering approach is database agnostic. It replicates any data on a designated storage volume. That could include multiple databases from multiple vendors, text files, video files, or any other educational asset whose availability is important. This can save an institution a considerable amount of money if a database-native approach to HA would otherwise require an upgrade to a more expensive edition of the database. Finally, as noted earlier, if you are trying to protect applications and data running in multiple operating environments, a SANless clustering approach may be more manageable than individual database–native approaches. You can use SANless clustering to ensure HA in either Windows or Linux environments, which can eliminate the complexities that could accompany the deployment of database-native approaches that differ among operating environments.