From: Manish Mittal (manishm_at_microsoft.com)
Date: Wed Feb 25 2004 - 14:03:57 PST
This paper starts out by describing Porcupine which is a cluster-based
mail service that scales well for large client populations and achieves
high availability, high manageability and high performance. This system
partitions the user information and their mailboxes across the nodes and
replicates them to achieve high availability. Mail application is chosen
for Porcupine due to the large and varying traffic load and its
read-write domination. Paper then presents an overview of the system's
architecture and compares this architecture with alternatives such as
Grapevine. Then it talks about manageability of the system (how the
system adapts to changes in configuration automatically). It then
describes the system's scalable approach to fine-grained load balancing.
Paper then evaluates the performance of the Porcupine prototype on a
30-node cluster and then discusses some of the system's scalability
problems.
Porcupine makes extensive use of "functional homogeneity". Functional
homogeneity means that any node can execute part or all of any
transaction. The goal is for system administrators to be able to just
plug in a new box or remove an old one and have it all work. This to me
seems like a very powerful feature. In our Web service, we use Hardware
load balancer to achieve this functionality. Any nodes\machines can be
taken out or added in by simply removing it from the Load balancer IP
list.
Porcupine uses dynamic load balancing to distribute the workload across
nodes in the cluster in order to maximize throughput. Since there is no
central discovery server for each node to know about all other available
nodes, I am not sure how the discovery is done efficiently. This problem
seems quite similar to P2P service. Porcupine also uses eventual
consistent replication. There is a small window of inconsistency after
failures, but the inconsistency is such that deleted mails are still in
the system for some duration of time or duplicate copies of mail are
present. If a change in the cluster is detected, a cluster-wide
membership protocol is run (Three Round Membership Protocol). I am not
sure what happens if a user tries to access emails while the change is
happening. Or a request for the email goes to the Coordinator of the
Membership protocol. Like Grapevine, this paper also describes the whole
system in great detail. Each data structure and managers are described
in great depth and helps in visualizing the design.
This archive was generated by hypermail 2.1.6 : Wed Feb 25 2004 - 14:04:15 PST