Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Swift requires that 2 storage nodes successfully write the object before returning success (in the default config where there are 3 replicas). The third copy will be attempted, but if it fails, replication will handle creating it on the third object server. The second copy is essential, because a single hardware failure immediately after a successful write to a single object server may cause the data to be permanently lost.

To increase user performance (reduce write latency), the three writes to storage nodes happen concurrently. This means that the internal network ports on the proxy servers have an effective throughput of one-third their listed rate. In Rackspace's case, this means that if a user were able to get a sustained 3Gbps to the proxy servers (the load balancers, actually), this would be their network cap. In reality, since each object write is written to one spindle, the actual limiting factor is hard drive spindle speed.

If you were attempting to maximize large write speeds to swift (and cost is no factor), first get really fast disk IO, then fast networks to the storage nodes, then fast public access to the proxy servers (ensuring that the pubic speed is at least 3x the storage network). Finally, start increasing processors and memory on the proxy and storage nodes. For Rackspace, these optimizations would do very little for the average use case, and provide almost no benefit even for the exceptional use case. As always, your use case could be different, so your milage may vary.