ScaleOut Software has a product to manage sessions on a web farm. I have tried this product and have had nothing but issues. I did actually end up getting it working once, but it turns out, even when it does work correctly, it gives your network problems
It seems that the fix for any issue is “You arent running the latest version” – which might be true, but many times, we would be running version 1.3.2 for example that we downloaded two days ago, and then they release 1.3.2.1 the day after we downloaded 1.3.2 – this is a cop out in saying that its on our end, when in reality it is just buggy software that has releases every other day to fix bugs. I dont know if there is any other competing product in the market right now though, so they kind of have it locked. You can use Microsoft’s ASP.Net Session provider, but that is limited when in a farm scenario. Using MSSQL for your sessions has performance issues. I have heard that ex-microsofties tell people to just roll their own, but that seems too much, especially in a small shop. Hopefully ScaleOut gets more stable, because it could be a good product, if it just didn’t cause issues 🙂
Steve Novoselac's Blog 
3 replies on “ScaleOut StateServer”
As a new company working hard to build our reputation, we make our customers’ satisfaction the number one priority. We first introduced ScaleOut StateServer (SOSS) in January, 2005, and since then we have made new releases available approximately every one to two months (not days!). These releases have added new capabilities requested by customers (for example, asynchronous event handling), made compatibility improvements for ASP.NET 1.1, and incorporated bug fixes. (SOSS’s release history is published on our Web site; the last release, version 1.3.1, was in April.) Our goal has been to be as responsive as we can to our customers as we gain field experience and hear feedback.
Please bear in mind that SOSS represents a new product category and solves the very challenging problem of simultaneously scaling storage access across a server farm while maintaining high availability. Also, session-state support for ASP.NET 1.1 requires that we shadow ASP.NET’s in-process storage while maintaining compatibility with its out-of-process alternatives. (ASP.NET 2.0 uses a provider model for third parties.) For all of these reasons, we expected to discover “surprises” from the field and to react quickly to meet our customers’ needs.
For example, we designed ScaleOut StateServer to follow the typical guidelines of high availability clustering by maintaining availability after a single server fails and by stopping if it loses quorum after multiple servers fail. We found that customers need the ability to reboot multiple servers simultaneously without notifying SOSS (for example, to automatically apply security updates late at night), and they want the SOSS service to keep running even if all servers are restarted and data is lost. With our forthcoming version 2.0, we have redesigned SOSS’s recovery mechanisms to meet these and other needs.
The Cicso “bad hop count” errors described in the article has not been reported to us. SOSS does not broadcast packets on the network subnet. Instead, it multicasts UDP packets to a configurable IP address, and it does not set nor change the time-to-live (TTL) value. By default, the multicast address is set to a value that routers recognize as non-routable (224.0.0.17) specifically to confine the packets to the local subnet. This may be causing the TTL to be set to 1.
SOSS’s network overheads are designed to be extremely low. It performs a multicast discovery protocol about every five seconds, and the total bandwidth required for this is about 600 bytes per second per host. In addition, each active host heartbeats other hosts using a point-to-point UDP protocol that consumes about 800 bytes per second per host (and does not grow with the size of the farm). Since these packets are periodic, they will show up on a network analyzer, but the total bandwidth they consume is very low.
Let me take this opportunity to highly encourage your suggestions and feedback. If there are any further unanswered questions about the blog entry on ScaleOut StateServer, or if you have any other questions or comments, please don’t hesitate to contact me, Bill Bain (founder and CEO), at wbain@scaleoutsoftware.com; +1-425-450-3216.
LikeLike
When I blogged about this product http://blog.super-networking.net/?p=8 and the effect it had on the bad hop count on my Cisco I was not complaining about the bandwidth this product used. I am complaining about the effect this product’s packets have on the errors counts on the Cisco. In a complex environment a few million errors and mask other real problems, there should be some testing on this and there should be a way for this product to talk without sending error counts into the millions. An extra not on this is this error count was caused by less than 10 servers! If we did this across the board I shudder at the amount of errors I would have.
LikeLike
[…] It looks like the blogs about a product called ScaleOut State Server has caught some attention here. I have also commented on this blog entry. I am not complaining about the bandwidth being used just be the errors is causes on the Cisco. My original blog on this topic is below. […]
LikeLike