Reliability
Catastrophes can happen at the worst possible times. Reliable server applications can help reduce downtime when something does go awry. Windows Server 2008 has many features that support reliable server applications, some of which we often take for granted.
You don’t need to buy a sophisticated database to get reliable storage. Indeed, SQL Server itself depends on the NTFS file system for much of its reliability. When you write a file to the NTFS file system, you can be confident that even if the server crashes, your file will be intact. By using the file I/O classes in the System.IO namespace coupled with .NET serialization services, you can quickly get up and running with a simple and highly reliable storage subsystem.
While many services need only the simplicity of direct file storage, there is a class of server application that requires something more. Imagine a mission-critical system that requires a high degree of data consistency with atomic updates, all while servicing many clients concurrently. This is made much cleaner through the use of ACID transactions.
Transactions are important in Windows Server 2008, which includes two built-in resource managers in the kernel: a transactional file system (TxF) and a transactional registry (TxR).
Note |
|---|
| TxF and TxR require native code. |
A transaction manager in the kernel (KTM) coordinates transactions efficiently for these resource managers. KTM also implements the protocols necessary to integrate with the distributed transaction coordinator (DTC) to support two-phase commit where necessary to distribute transactions across resource managers and perhaps even across server computers.
SQL Server and Message Queuing support local and distributed transactions, and along with the in-memory transaction model supported by the .NET Framework, this allows you to enlist any of these resource managers on a single ACID transaction. The System.Transactions namespace simplifies how transactions are used in managed code, and allows you to manage a complex distributed transaction with virtually no code at all.
When you write a highly reliable application, you assume the worst: the application will crash from time to time. But that’s OK; you have a plan for recovery after a crash. On Windows Server 2008, when a fatal error occurs, your application can use Application Recovery to perform a last-minute write before shutting down. And by registering with Application Restart, your application can automatically be restarted and pick up where it left off.
Note |
|---|
| Application Recovery and Application Restart require native code. |
While NTFS provides a highly reliable file system, it clearly cannot protect your application from low-level damage that may occur to disks due to either misconfiguration or a physical catastrophe. Therefore the ability to regularly back up data is important. This might seem tricky for systems that run 24x7, but Windows Server 2008 provides this ability with the Volume Shadow Copy Service (VSS), which helps a running application like SQL Server cooperate with a backup application, giving it a snapshot of data that is safe for backup. If you’re not using SQL Server, you can programmatically integrate with VSS.
Note |
|---|
| VSS integration requires native code. |
Note