Sanjay R. Radia

The SunSCALR framework for Internet servers

Internet servers need to be highly-available, inexpensive, and scalable. These goals are often conflicting and most designs meet, with limited success, only few of them. In this paper we describe the SunSCALR framework that achieves these goals by combining proven technologies, careful system design, and engineering trade-offs. It uses a distributed, self-stabilizing algorithm for status monitoring and failure detection, and IP failover for automatic reconfiguration. SunSCALR provides high-availability against message loss, host crashes, and scheduled downtime, and allows on-the-fly addition and removal of hosts. We present detailed performance of SunSCALR. It can provide 10 second failover latency (i.e., better than 99.999% availability if machines fail for 2 hours/month). SunSCALR based products have been in use within Sun and are also available in the market.

Using interface inheritance to address problems in system software evolution

Two specific problems faced in large distributed systems are (1) evolving and managing different versions of an interface while minimizing the impact on existing clients, and (2) supporting the addition of auxiliary interfaces that are orthogonal to the main interface of an abstraction.In the context of the Spring distributed system, we addressed both problems using an object-oriented interface definition language. Different versions of an interface are represented as different types with an inheritance relationship that minimizes the impact on existing clients and allows easy management of versions.We distinguish between fundamental and auxiliary properties each of which are defined as separate types. Rather than use simple root inheritance, we use a combination of root and leaf inheritance. This provides flexibility in supporting auxiliary properties and allows us to add new auxiliary properties as the system evolves without forcing the system to be recompiled.The solutions have been tested and refined through their use in the Spring system.

Persistence in the Spring system

The Spring system does not provide persistent object identifiers and not all Spring objects are persistent. Instead, we rely on a general name service and persistent name-to-object bindings to support persistence. The name service is separate from the various subsystems that implement persistent objects, so that new object types can be added, and the implementation of existing types can be changed, without rebuilding the name service. We distinguish among the concepts of freezing, pickling, and externalizing. We then develop a general framework for freezing that can be used by any client, including the name server,for making objects persistent. It allows subsystems that implement objects of various types to maintain autonomy from the name service and retain control over how their objects are implemented and made persistent, and yet be well integrated with the name service.<<ETX>>