<html><head></head><body><div style="font-family:courier new, courier, monaco, monospace, sans-serif;font-size:16px;"><div>Hi all,<br><br>First of all, my apologies in advance if I’m inadvertently<br>breaking any posting rules!<br><br>I wonder if anyone might have experience deploying OpenStack<br>Swift server(s) for production *small-scale* web apps?<br><br>If you're pressed for time, I'd appreciate any advice you can<br>provide. The rest of this is context, a few more specific<br>questions, etc, for anyone who enjoys the challenge of reading<br>a 3-part novel:<br><br>I am involved in a project right now to build a sort of<br>workflow/messaging/document control web application. The<br>application will be deployed to a number of data centres for<br>different organizations. Each organization will host between<br>5,000 and 12,000 users, although down the road a larger<br>organization (100,000 users) might be deployed as well.<br><br>Before my time, OpenStack Swift was chosen as the object storage<br>service for users' documents. I have no experience deploying,<br>maintaining or troubleshooting Swift. All I know is what I've<br>read on the OpenStack website and a few blog entries and mailing<br>list anecdotes.<br><br>Unfortunately I do not have any hard statistics about hit rates,<br>data flow, amount of storage, etc. My suspicion is that the<br>application will be used casually, perhaps a few minutes per day<br>per average user, more or less like a casual/occasional Facebook<br>user, reading a few posts and maybe writing a response or two.<br>I believe the average user would typically retrieve only images<br>from object storage (corporate logos and maybe a photo or two).<br>More rarely, a user would upload or download PDFs and Word files<br>and those sorts of documents. Most of the documents would be<br>small; my guess is that an average user would store nowhere near<br>1 gigabyte of document/object data. Some of the documents would<br>contain private/confidential data.<br><br>The recommendations I’ve found seem to suggest that 3 storage<br>nodes are the minimum to get much benefit out of Swift. Does<br>anyone have any feedback on this number? Has anyone deployed a<br>single Swift storage node to production? Or 2? For example,<br>perhaps by replicating to 3 different devices on a single node?<br><br>From a project perspective, my superiors are concerned about<br>costs. Assuming 3 object storage nodes, plus 1 PAC node (in<br>order to segregate the application tier from the data tier),<br>that’s 4 nodes to deploy at each organization.<br><br>From a performance perspective, I can’t help but question the<br>wisdom of deploying a large, scalable distributed system like<br>Swift in order to manage small-sized document objects for a<br>small number of users. Again, I have no hard statistics.<br>Guessing 1 GB per user with 12,000 users, that’s about<br>12 terabytes of object storage. Does anyone run production<br>Swift object servers with 12 TB or less in object data?<br><br>From a support perspective, the complexity of maintaining and<br>troubleshooting Swift also seems to me to be rather high for<br>such a small deployment. With rsync running in addition to<br>the Swift servers, and the potential sources of disaster or<br>corruption residing on 4+ nodes and in multiple applications<br>/ services, I would expect the cost of providing technical<br>support to be much higher than it would be to, say, maintain<br>a RAID array. I also don’t have any concept of if / how this<br>complexity would change the amount of time it takes to recover<br>from a disaster. Does anyone have any experience maintaining<br>and troubleshooting Swift in a small-scale production<br>environment?<br><br>Any feedback / statistics / analysis / advice / links / etc<br>anyone can provide would be very much appreciated.<br><br>Thanks all,<br><br>Johann Tienhaara<br>Jtienhaara AT yahoo DOT com<br><br></div></div></body></html>