From what I have read (IANANE), load following is something you get for nearly free with LFTR's design. Basically the more you extract, the cooler it gets, the more reactions happen, the more energy you can extract from it. Basically it's self balancing around a specific temperature, not a specific energy output.
The CIO is right for the most part. But I would say this. You will need to replace the redhat support with one extra FTE in order to make sure that security updates match what redhat is doing.
Right, neither one of those formats are for the END USER. They're authoring systems that publish content into a different format. You don't give LaTeX to your end users, you render it to PDF.
And that's the whole point of DevOps. To bridge the gap and bring the teams closer together. This is one of those "if you don't know who the chump is, you're the chump" situations. Because you haven't experienced it means your company(s) are missing DevOps and the whole point behind it.
From what you can see there is a "normal" looking PSU with a couple of changes.
#1 - there's only a 12v rail just like many server PSUs used by Dell, Supermicro, etc. All other voltage conversions are done by sub-converters or the motherboard. #2 - Distributed AC/DC conversion + Distributed battery backup.
As shown by things like 80Plus ratings for PSUs, if you know the exact load your server is expected to use you can build a VERY efficient AC/DC conversion. Building central AC/DC isn't really needed, besides you would still need to distribute at a higher voltage than 12v. I can't imagine the kind of bus bar you would need for a hundred racks of servers at 12vdc.
No, you really don't need to run AC to cool computers. What many modern datacenters do is use these days is evaporative coolers. You don't need to make computers cold, you just need to make them not hot. Intake air of 80F is just fine as long as you get enough of it through the server. It's also a lot more pleasant to work in a datacenter that runs at 75-80F than one that blows 50F cold air up your pants from the floor tiles.
Yea, that's not enough drives to really see useful statistics. +- 1 drive failure per year is a 20% margin of error at 1000 drives with a rated failure rate of basically 6 per year.
Sorry, but you have no clue what this is about. This has very little to do with bandwidth and much more to do with latency.
Say you live in Germany.
From California to Germany you're talking about 150ms minimum. If you're working with an interactive site like Gmail or Google maps the experience is going to suck. Say it takes the server 100ms to do the work to respond to your request. That's already faster than most website servers are designed to respond to. This means that 250ms is the time it takes to get, process, and respond to a single request. This means you can only really do things at a rate of 4 updates per second. This is very slow for highly interactive web apps.
If a site can redirect you to a server in europe you can cut 125ms off that request. That's half of the time. It's also below the 190ms it takes your brain to respond to visual changes.
Yes, it does very much work for drives. How many drives do you own/manage? 10? 100? I work on petabyte+ storage clusters where we have tens of thousands of drives. I've done the math.
MTBF as it relates to drives is only valid when you take into account population stats and the lifespan of a drive into account (Assume lifespan is 3 years)
You have an MTBF of 1,400,000 and 200,000 drives you will roughly see drives die every 7 hours. If you believe MTBF you will see about 1250 drive failures per year. This is ~0.62% which Seagate publishes as the annual failure rate.
Yup, IO rates are far more important than space for datasets of this size. As some other posts mentioned, they're probably using 2.5" enterprise drives instead of 3.5". If they were using 3.5" 2T drives the storage space would be more like 350P not 120P.
No, when people publish these kind of articles they almost always state raw capacity. They're likely using 2.5" drives which don't hold as much as 3.5" drives.
I do manage large storage farms in the petabytes range. There is a curve to the rate at which disks die. It mostly seems kinda obvious.
#1 - Infant mortality. I see a bunch of drives fail within the first few months of a new install. #2 - Increased death rate as the drives age. Usually when the drives start to reach the warranty age. This can be accelerated depending on the IO load of the system.
This is what MTBF is all about. "Enterprise" drives are rated at 1.2 million hours MTBF. 1,200,200 hours / 200,000 drives = 6 hours per drive failure. Not too bad, only 4 a day.
No, Google's business is about having data to GIVE to people. Then display ads relevant to the information you asked for.
Being able to give people accurate location information based on what wifi AP they're near by is good information. It's far easier and requires a lot less battery power than GPS. It's also less accurate than GPS which is a good thing if you're worried about location privacy.
Having accurate location information allows me to search for "tacos" and get some kind of local result. Cell phone tower location is within miles. Wifi location is within 100s of feet. I'd much rather know more about the taco truck that's closer.
Capacity planning is hard when you're growing at an unknown exponential rate to accept the network effect of new users. But since lots of invites are going out but they're rate limiting the actual setup of new accounts I think they could have avoided this. Who knows, maybe the product manager(s) is just bad a math.
Yup, there's a hundred different google services all trying to get space in geographically diverse locations for protecting them from failures. Space/compute isn't free so you have to divvy it up. I'm sure Gmail probably gets first pick for more storage space over Google+ since Gmail isn't beta and has paying customers.
Yup, I love the "why not buy enterprise hardware" comments. Based on 250 Billion page views per month, we're talking about 100k views per second. I'd like to see a zSeries box keep up with just one of the tables needed to handle this traffic level.
And that's based on monthly average, I bet their daytime peak is 10x that.
Slashdot Mirror
From what I have read (IANANE), load following is something you get for nearly free with LFTR's design. Basically the more you extract, the cooler it gets, the more reactions happen, the more energy you can extract from it. Basically it's self balancing around a specific temperature, not a specific energy output.
And of course what the post really wants is a DISTRIBUTED filesystem. Not a clustered filesystem.
No, this is not necessary at all. In fact, it's already happening.
The CIO is right for the most part. But I would say this. You will need to replace the redhat support with one extra FTE in order to make sure that security updates match what redhat is doing.
Right, neither one of those formats are for the END USER. They're authoring systems that publish content into a different format. You don't give LaTeX to your end users, you render it to PDF.
And that's the whole point of DevOps. To bridge the gap and bring the teams closer together. This is one of those "if you don't know who the chump is, you're the chump" situations. Because you haven't experienced it means your company(s) are missing DevOps and the whole point behind it.
Get rid of dev/qa/ops silos.
So you use LaTeX? Docbook XML? You know, real documentation systems?
You're pretty close. Just read this article. http://news.cnet.com/8301-1001_3-10209580-92.html
From what you can see there is a "normal" looking PSU with a couple of changes.
#1 - there's only a 12v rail just like many server PSUs used by Dell, Supermicro, etc. All other voltage conversions are done by sub-converters or the motherboard.
#2 - Distributed AC/DC conversion + Distributed battery backup.
As shown by things like 80Plus ratings for PSUs, if you know the exact load your server is expected to use you can build a VERY efficient AC/DC conversion. Building central AC/DC isn't really needed, besides you would still need to distribute at a higher voltage than 12v. I can't imagine the kind of bus bar you would need for a hundred racks of servers at 12vdc.
No, you really don't need to run AC to cool computers. What many modern datacenters do is use these days is evaporative coolers. You don't need to make computers cold, you just need to make them not hot. Intake air of 80F is just fine as long as you get enough of it through the server. It's also a lot more pleasant to work in a datacenter that runs at 75-80F than one that blows 50F cold air up your pants from the floor tiles.
http://en.wikipedia.org/wiki/Evaporative_cooler
2 years, 5 years, 10 years, it doesn't matter. These observation don't help at all if you're not looking at a large enough sample.
See also: http://en.wikipedia.org/wiki/Bathtub_curve
Yea, that's not enough drives to really see useful statistics. +- 1 drive failure per year is a 20% margin of error at 1000 drives with a rated failure rate of basically 6 per year.
Or when ISP DNS servers are so badly managed that they take seconds to respond to lookups.
Sorry, but you have no clue what this is about. This has very little to do with bandwidth and much more to do with latency.
Say you live in Germany.
From California to Germany you're talking about 150ms minimum. If you're working with an interactive site like Gmail or Google maps the experience is going to suck. Say it takes the server 100ms to do the work to respond to your request. That's already faster than most website servers are designed to respond to. This means that 250ms is the time it takes to get, process, and respond to a single request. This means you can only really do things at a rate of 4 updates per second. This is very slow for highly interactive web apps.
If a site can redirect you to a server in europe you can cut 125ms off that request. That's half of the time. It's also below the 190ms it takes your brain to respond to visual changes.
http://en.wikipedia.org/wiki/Mental_chronometry
Yup, thanks to Rob for all of the fun over the years.
Yes, it does very much work for drives. How many drives do you own/manage? 10? 100? I work on petabyte+ storage clusters where we have tens of thousands of drives. I've done the math.
No, you still don't get it. The meaning of MTBF is well understood.
http://en.wikipedia.org/wiki/Mean_time_between_failures
MTBF as it relates to drives is only valid when you take into account population stats and the lifespan of a drive into account (Assume lifespan is 3 years)
Say you use these drives:
http://www.seagate.com/www/en-us/products/enterprise-ssd-hdd/constellation/constellation-2/#tTabContentSpecifications
You have an MTBF of 1,400,000 and 200,000 drives you will roughly see drives die every 7 hours. If you believe MTBF you will see about 1250 drive failures per year. This is ~0.62% which Seagate publishes as the annual failure rate.
That highly depends on the drives, enclosures, and IO rates.
Yup, IO rates are far more important than space for datasets of this size. As some other posts mentioned, they're probably using 2.5" enterprise drives instead of 3.5". If they were using 3.5" 2T drives the storage space would be more like 350P not 120P.
No, when people publish these kind of articles they almost always state raw capacity. They're likely using 2.5" drives which don't hold as much as 3.5" drives.
I do manage large storage farms in the petabytes range. There is a curve to the rate at which disks die. It mostly seems kinda obvious.
#1 - Infant mortality. I see a bunch of drives fail within the first few months of a new install.
#2 - Increased death rate as the drives age. Usually when the drives start to reach the warranty age. This can be accelerated depending on the IO load of the system.
There's a lot of great info out there. Here's one good whitepaper:
http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/disk_failures.pdf
This is what MTBF is all about. "Enterprise" drives are rated at 1.2 million hours MTBF. 1,200,200 hours / 200,000 drives = 6 hours per drive failure. Not too bad, only 4 a day.
No, Google's business is about having data to GIVE to people. Then display ads relevant to the information you asked for.
Being able to give people accurate location information based on what wifi AP they're near by is good information. It's far easier and requires a lot less battery power than GPS. It's also less accurate than GPS which is a good thing if you're worried about location privacy.
Having accurate location information allows me to search for "tacos" and get some kind of local result. Cell phone tower location is within miles. Wifi location is within 100s of feet. I'd much rather know more about the taco truck that's closer.
Capacity planning is hard when you're growing at an unknown exponential rate to accept the network effect of new users. But since lots of invites are going out but they're rate limiting the actual setup of new accounts I think they could have avoided this. Who knows, maybe the product manager(s) is just bad a math.
Yup, there's a hundred different google services all trying to get space in geographically diverse locations for protecting them from failures. Space/compute isn't free so you have to divvy it up. I'm sure Gmail probably gets first pick for more storage space over Google+ since Gmail isn't beta and has paying customers.
Yup, I love the "why not buy enterprise hardware" comments. Based on 250 Billion page views per month, we're talking about 100k views per second. I'd like to see a zSeries box keep up with just one of the tables needed to handle this traffic level.
And that's based on monthly average, I bet their daytime peak is 10x that.