Requirements and Limitations

ScaleOut StateServer runs as a Windows service on multiple servers within a server farm. To operate properly, it requires that adequate resources, primarily memory, network bandwidth, and CPU capacity, be available at all times. By far the most common source of problems is inadequate provisioning of these resources; details on resource requirements are explained in more detail below. It is also important to ensure that resource usage by SOSS and other processes does not encroach on the provisioned limits. You should be certain to carefully provision these resources as needed by your application and to track their usage to make sure that adequate resources are always available to SOSS.

Because ScaleOut StateServer runs across a server farm as a set of cooperating service processes, the behavior of each service process can affect the stability and reliability of instances on other hosts. ScaleOut StateServer provides robust mechanisms to detect and handle the failure of servers and/or networking components. On server farms, these mechanisms are intended to enable recovery from single failures (or double failures if two replicas per object are used) while preserving the high availability of data or from multiple successive failure/recovery episodes of up to N-1 hosts in an N-host store without loss of the caching service. However, these mechanisms cannot cope with all failure scenarios, such as (but not limited to) an unstable store due to inadequate or fluctuating resources, multiple failures in rapid succession while recovery is taking place, or failure to follow the procedures documented in the Management topic.

Server Requirements

ScaleOut StateServer was designed and tested for use on physical servers and networks. The product is intended to provide a high performance distributed store that quickly detects and recovers from a single (or if configured, double) server failure when running on fast, reliable hardware. The heartbeat and host discovery mechanisms for detecting the presence of remote SOSS hosts rely on uninterrupted CPU and network operations for proper operation. In some cases, the use of virtual servers can degrade the CPU and network quality of service available to an SOSS host, which can result in a disruption of normal operations and unexpected membership changes. If you run ScaleOut StateServer on virtual servers, be sure that the virtual servers are provisioned with adequate physical server and network capacity to avoid these problems. Also, dynamically migrating virtual servers with active SOSS hosts is not supported.

Although ScaleOut StateServer runs on a single server, you should use a minimum of two servers in your farm so that stored data can be replicated and remain highly available in case a server fails. To take full advantage of ScaleOut StateServer’s data replication, you should use three or more servers. This will enable ScaleOut StateServer to improve redundancy by creating two replicas for each stored object.

Memory Requirements

Since ScaleOut StateServer stores data objects in server memory, you must ensure that ample RAM is installed in each server to cover your storage needs. It is critically important to follow these guidelines to ensure that the StateServer service is provisioned with adequate physical memory. However, the exact amount of memory needed by ScaleOut StateServer varies with the number and size of objects stored, the number of SOSS hosts and clients, and changes made by the dynamic load-balancer. To avoid exhaustion of physical memory, which will prevent normal operation of ScaleOut StateServer, memory usage must be tracked over time to ensure that adequate reserves of physical memory always are maintained. For example, be sure that other processes do not dynamically claim physical memory and encroach of the provisioned amount for SOSS. Continuous operation with insufficient physical memory can prevent normal operations and must be avoided.

The total memory needed across the farm for data storage should be enough to hold all data objects and two additional replicas of each object (or just one additional replica on farms with no more than two servers or when the use of one replica per object is specified). Each server should have enough memory to hold its portion of this total amount. For example, if you plan to store up to 100MB of workload data on your farm, you should have enough memory to hold 300MB of stored data if the use of two replicas per object is specified. If the farm has three servers, each server needs 100MB of memory available for data storage (unless you configure ScaleOut StateServer to allocate a larger portion to selected servers). Since ScaleOut StateServer incurs additional memory overhead for each stored object and for operation of the StateServer service, you should increase these memory requirements by approximately 50%. Please see the section Best Practices for more information on memory requirements.

The ScaleOut GeoServer option uses memory to buffer outbound object update requests awaiting replication to remote SOSS stores. The amount of memory required for this purpose varies with the store’s access rate and the speed of the communications link to remote stores. It is important that the communications link to remote stores be sufficiently reliable and fast that memory consumption for this purpose remains stable.

To allow for graceful recovery in case a server fails, the surviving servers must have sufficient extra memory capacity to handle the total workload. For example, if you have two servers in your farm, the surviving server should have the capacity to handle 100% of the total workload. The amount of required extra capacity decreases as you add servers to the farm. If you have four servers, the surviving three servers together have to handle 25% of the total workload, or only about an extra 8.4% on each server.

Best practice: To avoid loss of data if server or network outages should occur, your server farm should use at least two or more servers. Please see the section Recovery from Failures for details on this issue. Using three servers also improves the redundancy of your data in case a server fails.

CPU Requirements

Sufficient CPU capacity should be available to run the StateServer service on each host. If the CPU on a host becomes overloaded, ScaleOut StateServer is unable to sustain normal operations, and other hosts may remove it from the distributed store. Be sure to track CPU usage to make sure that adequate CPU capacity is available at all times Continuous operation with insufficient CPU capacity can prevent normal operations and must be avoided.

Networking and Security Requirements

All servers must have at least one network interface running the TCP/IP protocol, and they must be connected using the same network subnet when multicast discovery is enabled. This allows ScaleOut StateServer to use multicast IP communication to detect other servers and to help recover from failures. (All other internal communications are point-to-point.) ScaleOut StateServer requires three IP ports to be allocated for its use; default values are specified in the parameters file. A multicast IP address is also required when multicast discovery is enabled. They can be changed using the management tools or by directly editing the parameters file. ScaleOut StateServer supports up to 254 network interfaces on each server. These ports must not be firewalled.

ScaleOut StateServer requires adequate network bandwidth at all times to perform access operations and to maintain the membership of the distributed store. If the network becomes overloaded, access delays can become very large, and SOSS hosts may intermittently be removed from the membership. Continuous operation with insufficient network bandwidth can prevent normal operations and must be avoided. ScaleOut Software strongly recommends that you use a gigabit Ethernet for interconnecting caching servers. Experience has shown that typical cache access loads can easily saturate a 100Mbit per second Ethernet. For example, most ASP.NET Web farms need to use gigabit Ethernet to avoid network saturation. Please see the section Best Practices for more information on networking requirements.

[Note] Note

ScaleOut StateServer does not require the use of a dedicated network subnet. It can share the network subnet with other services, such as a DBMS. However, it is important to ensure that adequate network bandwidth is always available.

ScaleOut StateServer is designed for use within a data center on a network subnet which is physically secure from unauthorized access. Its internal communications do not provide specific measures to safeguard against observation and attack. To maximize performance, ScaleOut StateServer does not encrypt stored data within its internal, point-to-point communications.

Best practice: If your "front-end" network subnet is connected to the Internet (for example, in a Web farm), you should be certain to configure ScaleOut StateServer for use on a separate, secure network subnet, typically a firewalled, "back-end" network used to connect your servers to an internal database management server (DBMS).

Best practice: You should connect all servers to the same network switch whenever possible. If the servers are connected to two (or more) switches and the link between the switches fails, the distributed store will partition itself into two separate stores. This can lead to disruption of operations and to loss of data when the connection is re-established and the partitioned stores recombine into a single distributed store. It also can lead to a disruption of operations due to network delays on the link between switches. Please see the section Recovery from Failures for details on this issue.

[Note] Note

ScaleOut StateServer is designed to work seamlessly with load balancers such as Network Load Balancing (NLB) in the Windows Server operating system. However, you cannot use ScaleOut StateServer on the same network interface that has NLB installed and enabled. (NLB filters incoming multicast network traffic, and this blocks ScaleOut StateServer’s multicast management messages.) Instead, be sure to configure ScaleOut StateServer to use a different network interface.

Networking and Security Requirements for the GeoServer Option

The ScaleOut GeoServer option requires that a remote ScaleOut StateServer (SOSS) store’s gateway addresses be reachable using a TCP connection from the local SOSS store. You can specify the gateway IP address and port for each server in an SOSS store. Since ScaleOut StateServer does not encrypt data sent between SOSS stores, you should be sure to use a secure network for communication. Gateway addresses should never be directly accessible from the Internet.

Best practice: You can use a virtual private network (VPN) to connect SOSS stores using the ScaleOut GeoServer option. This provides secure communications between sites and allows you to use gateway addresses that are only routable across the VPN.

The communication link between SOSS stores should be as fast as possible so that object updates (i.e., object creation, update, and remove requests) on the local store can be quickly transmitted to the remote store. The link’s bandwidth should match or exceed the total object update bandwidth at the local SOSS store. In addition, the link should be highly reliable so that object replication is not interrupted by a link failure.

[Note] Note

The local SOSS store uses host memory to buffer object updates that are awaiting communication to a remote store. If the communication link is too slow or fails, SOSS could run out of memory on the local store. In this case, it will inhibit object creation on the local store until pending updates have been sent.

Networking and Security Requirements for the Remote Client Option

The Remote Client option requires that a remote ScaleOut StateServer (SOSS) store’s gateway addresses be reachable using a TCP connection from the local SOSS store using the specified gateway addresses. You can specify the gateway IP address and port for each server in an SOSS store. Since ScaleOut StateServer does not encrypt data sent between SOSS stores, you should be sure to use a secure network for communication if you are communicating outside of a single data center. Gateway addresses should never be directly accessible from the Internet.

Best practice: You can use a virtual private network (VPN) to connect remote clients to an SOSS store using the ScaleOut Remote Client Support option. This provides secure communications from remote clients located outside the SOSS store’s data center and allows you to use gateway addresses that are only routable across the VPN.

File System Requirements for the Backup/Restore Option

The ScaleOut Backup/Restore Option, which is a component of the ScaleOut Management Pack, requires that the StateServer service have read/write rights to the selected backup files within the file system. Also, the file system should have enough free space to store all objects selected for backup.

Software Requirements

All servers should be running Windows Windows Server 2008, Windows Server 2012, or Windows Server 2016. To use the Management Console (and ScaleOut StateServer’s support for ASP.NET session-state), you need to have the .NET Framework installed and operational on all servers.

Installation Requirements

You need to log in with Administrator privileges to install ScaleOut StateServer. This allows the install program to install ScaleOut StateServer’s Windows service. You optionally can specify an installation directory for ScaleOut StateServer, which by default is set to "\Program Files\ScaleOut_Software\StateServer". The StateServer service and SOSS management tools must have read/write permission to the SOSS installation directory; client applications must have read access to this directory.

.NET and ASP.NET Requirements

To store objects, including session-state objects, in ScaleOut StateServer, you must define the classes for these objects as serializable (to allow the objects to be copied to and from the store in a binary stream). In .NET, this can be accomplished by using the [Serializable] predefined attribute for the classes that you want to store.

To transparently store ASP.NET session-state objects using ScaleOut StateServer, be sure to run ASP.NET version 3.5 or higher. ScaleOut StateServer’s requirements for ASP.NET session-state are the same as those for Microsoft’s built-in State Server or SQL Server options for "out-of-process" storage. They specify that in addition to defining the classes for these objects as serializable, you should create these classes in C# (.cs) or VB.NET (.vb) source files and not inline within an ASP.NET .aspx file. (This allows the binary formatter to work consistently across on all hosts.)

Using any form of out-of-process session state with ASP.NET in a Web farm requires that the application path in the IIS metabase be the same for every Web server in the farm. (See Microsoft’s knowledge base article 325056 for a discussion of this issue.) Web applications that run out of the default Web Site in IIS typically will encounter problems because the instance ID of the Web site defaults to 1. However, applications that run out of other Web sites will need to have their application paths synchronized in the IIS metabase.

ScaleOut StateServer supports up to 200 applications within one .NET application pool (i.e., worker process). Although there is no predefined limit on the number of client processes that can connect to the StateServer service, the number of clients is limited by available memory and other resources used by the SOSS host.

ScaleOut StateServer requires .NET 3.5 or higher; LINQ query support requires .NET 4.0 or higher; query InvokeFilter support requires .NET 4.5. The optional ScaleOut ComputeServer requires .NET 4.5.