<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Joe Arnold&#039;s Blog</title>
	<atom:link href="http://joearnold.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://joearnold.com</link>
	<description>Agility and Cloud Computing</description>
	<lastBuildDate>Thu, 10 Nov 2011 14:41:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on Swift in the Small by joearnold</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1120</link>
		<dc:creator><![CDATA[joearnold]]></dc:creator>
		<pubDate>Thu, 10 Nov 2011 14:41:07 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1120</guid>
		<description><![CDATA[Hi Nguyen,
Yes, what you would need to do is either add additional nodes, or break out machines into separate zones. Don&#039;t forget to &#039;squeeze&#039; data by adjusting their weights down to 0 for the drives you&#039;re going to repurpose into other zones. Keep me posted.]]></description>
		<content:encoded><![CDATA[<p>Hi Nguyen,<br />
Yes, what you would need to do is either add additional nodes, or break out machines into separate zones. Don&#8217;t forget to &#8216;squeeze&#8217; data by adjusting their weights down to 0 for the drives you&#8217;re going to repurpose into other zones. Keep me posted.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by Nguyen Thinh</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1119</link>
		<dc:creator><![CDATA[Nguyen Thinh]]></dc:creator>
		<pubDate>Thu, 10 Nov 2011 13:03:44 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1119</guid>
		<description><![CDATA[Great post!
 If i start with one node(4 hdds); and the system grow, could i add one more node?]]></description>
		<content:encoded><![CDATA[<p>Great post!<br />
 If i start with one node(4 hdds); and the system grow, could i add one more node?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Elastic pricing for clouds is not a requirement by John</title>
		<link>http://joearnold.com/2011/08/13/elastic-pricing-for-clouds-is-not-a-requirement/#comment-1104</link>
		<dc:creator><![CDATA[John]]></dc:creator>
		<pubDate>Sat, 15 Oct 2011 16:19:48 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.wordpress.com/?p=255#comment-1104</guid>
		<description><![CDATA[Consumption pricing makes total sense in a public cloud offering that caters to a diverse set of customers (and therefore likely a diverse set of use cases). With consumption pricing, customers win because they only pay for what they use, and providers win because (since everyone&#039;s usage peaks don&#039;t happen at the same time) they can charge for 100% of the usage instead of billing at a 95 percentile rate.

However, smaller cloud offerings (including internal, private deploys of cloud infrastructure) absolutely need to calculate cost based on capacity, not consumption.]]></description>
		<content:encoded><![CDATA[<p>Consumption pricing makes total sense in a public cloud offering that caters to a diverse set of customers (and therefore likely a diverse set of use cases). With consumption pricing, customers win because they only pay for what they use, and providers win because (since everyone&#8217;s usage peaks don&#8217;t happen at the same time) they can charge for 100% of the usage instead of billing at a 95 percentile rate.</p>
<p>However, smaller cloud offerings (including internal, private deploys of cloud infrastructure) absolutely need to calculate cost based on capacity, not consumption.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Elastic pricing for clouds is not a requirement by Tom G. Price</title>
		<link>http://joearnold.com/2011/08/13/elastic-pricing-for-clouds-is-not-a-requirement/#comment-1095</link>
		<dc:creator><![CDATA[Tom G. Price]]></dc:creator>
		<pubDate>Tue, 23 Aug 2011 21:05:54 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.wordpress.com/?p=255#comment-1095</guid>
		<description><![CDATA[Joe, glad to see some info on cloud pricing. A company called Cloud Cruiser just announced a cloud cost management solution for OpenStack. Here&#039;s a link to the release:http://bit.ly/qAKSql. If you would like a demo, just click here: http://www.cloudcruiser.com/solutions/request_a_demo.asp.]]></description>
		<content:encoded><![CDATA[<p>Joe, glad to see some info on cloud pricing. A company called Cloud Cruiser just announced a cloud cost management solution for OpenStack. Here&#8217;s a link to the release:<a href="http://bit.ly/qAKSql" rel="nofollow">http://bit.ly/qAKSql</a>. If you would like a demo, just click here: <a href="http://www.cloudcruiser.com/solutions/request_a_demo.asp" rel="nofollow">http://www.cloudcruiser.com/solutions/request_a_demo.asp</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by lotlwc</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1086</link>
		<dc:creator><![CDATA[lotlwc]]></dc:creator>
		<pubDate>Mon, 04 Jul 2011 07:36:15 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1086</guid>
		<description><![CDATA[Thanks a lot for your reply. Its been useful info to get a bit of a picture to start playing with this stuff.]]></description>
		<content:encoded><![CDATA[<p>Thanks a lot for your reply. Its been useful info to get a bit of a picture to start playing with this stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by SquareCows.com &#187; Community Weekly Newsletter (June 24 – July 1)</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1085</link>
		<dc:creator><![CDATA[SquareCows.com &#187; Community Weekly Newsletter (June 24 – July 1)]]></dc:creator>
		<pubDate>Sat, 02 Jul 2011 03:37:34 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1085</guid>
		<description><![CDATA[[...] Swift in the Small by Joe Arnold &#8211; http://joearnold.com/2011/06/27/swift-in-the-small/ [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Swift in the Small by Joe Arnold &#8211; <a href="http://joearnold.com/2011/06/27/swift-in-the-small/" rel="nofollow">http://joearnold.com/2011/06/27/swift-in-the-small/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by joearnold</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1082</link>
		<dc:creator><![CDATA[joearnold]]></dc:creator>
		<pubDate>Fri, 01 Jul 2011 07:42:23 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1082</guid>
		<description><![CDATA[No. That&#039;s .50-.70 cents a GB usable. Yes, that&#039;s for capital buy price -- it doesn&#039;t include rent, power, transit, etc.

As to your first question, if you&#039;re looking to squeeze RAM/CPU down, at least profile convergence times with the configuration. You can watch your cycle times on the replicator processes or the object-auditor (if you&#039;re running it). Also, it depends on how active your object stores are and how many account/container/object processes are required to satisfy the number of requests. This is definitely an area that could use more benchmarking.]]></description>
		<content:encoded><![CDATA[<p>No. That&#8217;s .50-.70 cents a GB usable. Yes, that&#8217;s for capital buy price &#8212; it doesn&#8217;t include rent, power, transit, etc.</p>
<p>As to your first question, if you&#8217;re looking to squeeze RAM/CPU down, at least profile convergence times with the configuration. You can watch your cycle times on the replicator processes or the object-auditor (if you&#8217;re running it). Also, it depends on how active your object stores are and how many account/container/object processes are required to satisfy the number of requests. This is definitely an area that could use more benchmarking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by lotlwc</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1081</link>
		<dc:creator><![CDATA[lotlwc]]></dc:creator>
		<pubDate>Fri, 01 Jul 2011 05:56:30 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1081</guid>
		<description><![CDATA[Thanks for your response. You mention extended recovery times depending based on the CPU/RAM config, do you see big differences here? For example does the difference between 24 and 48GB RAM in the nodes, have 50% recovery variance of more like 10% (of course I&#039;m not expecting an exact answer, just want to get a feel for resource allocation vs performance). 

When you say you target .50-.70cents per GB, you mean capital buy price? So you would take that figure, multiple it by three (for redundancy), add overhead, and divide by 36months to get rough monthly costs over three years?]]></description>
		<content:encoded><![CDATA[<p>Thanks for your response. You mention extended recovery times depending based on the CPU/RAM config, do you see big differences here? For example does the difference between 24 and 48GB RAM in the nodes, have 50% recovery variance of more like 10% (of course I&#8217;m not expecting an exact answer, just want to get a feel for resource allocation vs performance). </p>
<p>When you say you target .50-.70cents per GB, you mean capital buy price? So you would take that figure, multiple it by three (for redundancy), add overhead, and divide by 36months to get rough monthly costs over three years?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by joearnold</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1080</link>
		<dc:creator><![CDATA[joearnold]]></dc:creator>
		<pubDate>Fri, 01 Jul 2011 05:21:45 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1080</guid>
		<description><![CDATA[Of course the answer is &quot;it depends&quot;. I tend to over provision a bit on RAM/CPU as these clusters are generally used for web-based workloads with a lot of concurrent requests. A good price/performance CPU (e5620) and 24/48 GB of RAM for a 36/48 drive chassis is what I&#039;ve provisioned. You&#039;ll be able to get away with thinner provisioning, but expect extended recovery times during recovery scenarios. 

At scale we target .50-.70 cents / GB with triplicate redundancy and a reasonable amount of front-end &quot;head&quot; units to serve requests.]]></description>
		<content:encoded><![CDATA[<p>Of course the answer is &#8220;it depends&#8221;. I tend to over provision a bit on RAM/CPU as these clusters are generally used for web-based workloads with a lot of concurrent requests. A good price/performance CPU (e5620) and 24/48 GB of RAM for a 36/48 drive chassis is what I&#8217;ve provisioned. You&#8217;ll be able to get away with thinner provisioning, but expect extended recovery times during recovery scenarios. </p>
<p>At scale we target .50-.70 cents / GB with triplicate redundancy and a reasonable amount of front-end &#8220;head&#8221; units to serve requests.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Swift in the Small by lotlwc</title>
		<link>http://joearnold.com/2011/06/27/swift-in-the-small/#comment-1079</link>
		<dc:creator><![CDATA[lotlwc]]></dc:creator>
		<pubDate>Thu, 30 Jun 2011 21:08:31 +0000</pubDate>
		<guid isPermaLink="false">http://joearnold.com/?p=219#comment-1079</guid>
		<description><![CDATA[Awesome post. What sort of CPU/RAM specs do you use in these nodes? Are you using 2TB or 3TB SATA spindles? Do you have a target cost per GB per month when building one of these clusters?]]></description>
		<content:encoded><![CDATA[<p>Awesome post. What sort of CPU/RAM specs do you use in these nodes? Are you using 2TB or 3TB SATA spindles? Do you have a target cost per GB per month when building one of these clusters?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

