Overview

This document is intended as a guide for those considering implementing SIF at the enterprise level and are looking for assistance in setting up a Zone Integration Server, specifically Visual Software's ZIServer product.

In this guide, we will consider a few configurations that will vary with the needs of the organization. These will include:

Test lab configuration – place where new versions of applications are tested before being deployed
Smaller enterprise where redundancy is important, but the volume of traffic may not warrant very large servers or implementations
Large enterprise where redundancy is important, volume of traffic is high and servers are likely to all be installed at the same location
Enterprises where servers are likely to be installed in different locations – these may be located in places prone to natural disruptions such as earthquakes, storms, etc. and need to be set up with disaster recovery centers.

High Availability Support

High availability options exist for both your Windows and SQL Server implementations and you have many choices for each. We've tried to support in our software as many as we find a reasonable fit for the application and those that don't collide with the SIF Specification.

Collisions with a specification? An example of a technology that some could label as "high availability" that would collide with the SIF specification would be using SQL Server replication to make database snapshots at given intervals. Although in some very rare circumstances you might be able to get this to work, in most it would only yield disastrous results. SIF is a real (or near-real) time protocol and having some parts of the data hours older than other parts will not work well. It's better to choose something else.

Windows Server Versions We Support

As of September 2009, we support:

Microsoft Windows Server 2003, 2003 R2 (any version except Web Edition and Small Business Edition)
Microsoft Windows Server 2008, 2008 R2 (any version except Web Edition and Small Business Edition)

Windows High Availability Technologies We Support

As of September 2009, we support:

Hardware Devices: These sit in front of the servers and distribute the traffic between them. These are relatively easy to set up, but are a more costly solution and don't tie into some of the other parts of the Windows Server applications that work with Windows Load Balancing solutions (like SharePoint, for example). We've found that sometimes you even need to redundantly install software that you wouldn't need to if you used a solution like Network Load Balancing.
Windows Failover Clustering: this option requires special hardware (sharable disks or a Storage Area Network (SAN)) and will create a solution where one server backs up another. If the first fails, the second automatically picks up the duties of the first. Since the two were sharing the same storage, there is no question of them being out of sync.

The issue with this solution, however, is that you have a single point of failure – the SAN. Although these are built to be reliable, if a main component like the backplane has problems, your entire enterprise becomes unavailable.
Windows Network Load Balancing: This option (as of Windows 2008) requires no specialized hardware and allows the "system of servers" to scale as necessary to meet the load requirements of the community. This is inexpensive and very simple to implement, but doesn't offer as high performance as the first two options.

How does performance typically compare between Windows Network Load Balancing (Active-Active) and Windows Failover Clustering (Active-Passive)?

When configuring Windows Network Load Balancing, it is recommended that you aim for an average utilization under 40% (if you are going to have two servers in the farm, for example), so that if one of the two servers go down, the one remaining server will be able to handle the “typical” load on its own.

For example, you estimate that your average message traffic will be 40 messages/ second. If each of the two servers in your farm can process 20 messages/ second using 30% of their capacity and could process 40 messages/second using 60% of their capacity.

With both running, your farm can easily handle the 40/second and can also handle peak loads of 80/second using 60% of each of the servers. If one were to go down, the single leftover machine could still handle the 40/second with 60% with a little left over.

For Windows Clustering, you configure a server to always be handling the entire load. So, the configuration of each of the two machines would like be more highly configured than the NLB servers because they would need to always have the headroom necessary to handle peak conditions.

Other considerations that “play against” the Windows Clustered systems:

The shared disks are connected to the servers at fast speeds, but the NLB servers use local disks (10Gbits vs. hundreds of Gbytes transfer speeds)
Network Balanced servers have redundant copies of all data

SQL Server Versions We Support

As of September 2009, we support:

SQL Server 2005, any edition
SQL Server 2008, any edition

SQL Server High Availability Technologies Available

As of the writing of this article, these were the high-availability technologies for SQL Server we could find being used.

SQL Server failover clustering
- high-availability support for an entire SQL Server (the entire server is backed up)
- requires special hardware support (shared disks)
- the cluster appears on the network as a single server (application sees it as a single computer)
- does not protect against disk failure (there is a single point of failure)
- all transactions are received by and processed by a single server (other server serves as a "hot spare")
Database Mirroring (asynchronous – also known as "high-performance" mode)
- database-specific (not server-wide), so non-critical databases don't need to be mirrored if not necessary
- is faster than synchronous mirroring, but writes are not guaranteed
- does not require special hardware
- stores multiple copies of data,
- copies of data may be located in different locations
Database Mirroring (synchronous – also known as "high-safety" mode)
- database-specific (not server-wide), so non-critical databases don't need to be mirrored if not necessary
- is slower than asynchronous mirroring, but writes are guaranteed, the difference between them depends on the speed of the network connecting them
- does not require special hardware
- stores multiple copies of data
- copies may be located in different locations, but if the connection between them is not very fast, the performance if the ZIS will be greatly impacted
- simple to set up and maintain
- if used with the Enterprise or Standard Edition of SQL Server, supports automatic page repair. If a page becomes corrupted on the hard drive of one server, it will be repaired from the copy on the other server.
Transactional Replication
- low overhead, backup model
- difference between copies of the database are much farther apart
- will most likely interfere with most SIF subscribers if caught in the middle of a failure/recovery cycle
Log Shipping
- older high-availability method, not automatic, uses T-SQL
- might be good possibility for a second-level backup when applied to one of the first three methods
- has same faults as transactional replication with regard to clashing with SIF subscribers
Windows Server Virtualization with SQL Server Failover Clustering and Mirrored Disks
- an elegant choice, but it does use failover clustered servers and mirrored disks
- requires special hardware, both for virtualization and for shared disks
- difficult to set up, but gives best level of protection

Of all of these technologies, we support SQL Server failover clustering, synchronous (high safety) database mirroring and Windows Server Virtualization with SQL Server Failover Clustering and Mirrored Disks.

Given the technologies we support, we recommend for smaller installations or for setting up test labs:

Disk Mirroring, high-safety mode
Windows Server 2008 R2, with Network Load Balancing

…and as installations get larger..

Windows Server Virtualization with SQL Server Failover Clustering and Mirrored Disks
Hardware devices for Network Load Balancing

ZIServer Zone Integration Server Editions

Visual Software offers three editions of ZIServer, two of which are appropriate for deployment at the enterprise level. The Standard and Enterprise Editions support high-availability technologies and all three support all supported versions of the SIF specifications. The difference between them are:

the size of the community that they support
the high-availability technologies that they will support

ZIServer Compact Edition

The Compact Edition of ZIServer is designed for test lab implementations or smaller implementations with a single or only a few schools where the entire implementation will be supported from a single server.

All components are installed on the same server, including SQL Server (which stores the data for ZIServer's two databases). This server hosts two web sites: one for ZIS administration and the other used by applications to pass data to and receive data from the ZIS.

ZIServer Standard Edition

The standard edition is intended for institutions for less than 15,000 learners and would be supported by a either a single or a pair of web servers and one or two database servers.

In high-availability mode, the two web servers would be running the Standard version of Microsoft Windows Server and would use Network Load Balancing to distribute the message traffic between them. The database servers might be dedicated or might be shared with other applications. The database servers may be configured with any of the technologies we support.

ZIServer Enterprise Edition

The Enterprise Edition is our designed to support large installations. It may be configured on one or more active servers, depending on the Windows Server configuration hosting it. Examples include:

Single Enterprise ZIServer: a high-availability example would be where Windows Server 2008 R2 is configured with failover clustering and a single server backed up by another server. ZIServer Enterprise Edition would be installed on both servers but would only be running on one at a time. This would count as a single ZIServer Enterprise license.
Load Balanced Farm (software): using Windows Server 2008 R2 Network Load Balancing, two servers distribute the incoming load and share the outbound traffic as well.
Load Balanced Farm (hardware): using an external hardware device, multiple servers share the inbound traffic. Outbound traffic to push agents is handled the same way as would be in the software load balanced farm.

Farm Support – Distributed Transactions

When choosing a Zone Integration Server for a large implementation, you should be comfortable that is able to properly handle the following classes of transactions:

inbound traffic for push agents
inbound traffic for push agents
outbound traffic for pull agents
outbound traffic for push agents

…both in terms of distributing the load between servers in the server farm, but also in terms of load transferring and recovery if an when a server in the farm fails. The first three classes of transactions in the list are relatively simple to handle; the last is much more difficult to handle properly.

Inbound transactions are handled through the web management features of the operating system. In a multi-machine installation, this would come from either Window’s Network Load Balancing or from the hardware device that you choose for your implementation.

Pull mode agents receive messages that are being sent to them by sending a message to the ZIS and receiving the data back in the acknowledgement to the same message, so to the ZIS it looks like an inbound message.

The last type of a message, where the ZIS needs to send messages to push mode SIF agents is where the ZIS needs to establish the connection to the agent and send the data. Furthermore, if it is sending a stream of response messages, it needs to make sure that the order of the messages is correct and, lastly it needs to verify the acknowledgements it receives from the push agent.

If it is interrupted while it does this, the remainder of the process needs to be correctly resumed by another server in the farm. There are a few other things in the SIF protocol in terms of ordering that must be done in exactly the right order as well.