50MB/s is pretty poor for a mirrored raid configuration over 1GbE. Even a single 7200rpm disk should be able to pull off more than that, doing sequential reads anyway. Do you see excessively high CPU utilization during the copy? Are you using software RAID?
I thought Google supported Net Neutrality as we know and understand it on wireLINE services and on wireLESS services they just wanted to prioritze traffic based on the TYPE of traffic (eg - VoIP traffic would be preferred over BitTorrent). Is this not correct?
If you're that large, or the information is that sensitive, you build a "private cloud", the REAL buzzword the industry has been falling all over itself about.
I find it humorous that you assume people still work a world where you can operate when disconnected from the Internet. Even if everything's hosted locally you can't use the web or send e-mail. So yeah, you just go home for the day, I don't care if your servers are down the hall or the other side of the country.
But the obvious answer is redundancy with physical diversity, of course -- regardless of where your IT infrastructure is hosted.
Any distro could release an updated kernel with the patch. But what you're describing isn't Linus's problem, it's a distro problem. He fixes the problems at the source and it's up to the distros to fix them downstream.
One of our network admins hooked up one of these at our CFOs (hilariously huge) house. About a week later 2 guys in a van showed up and told us it was blocking cellular signals for a several mile radius. Apparently it has to do with the distance between the base station and the antenna, and they had been installed too close. We went and re-read the instructions and sure enough the two were too close together. Apparently it's very easy to cause interference with these things.
You're referring to what they call envelope encryption. What we do is require TLS on any e-mail being sent out that is flagged by the Ironport as requiring encryption. You can then have it fail back to envelope encryption. In practice it's pretty obvious to spot someone intercepting your messages. They'd have to create an account to read the message and the intended recipient would realize it when they tried to sign up.
As far as getting caught, I assume you just unhook the other end. And it's not like people move their homes very often, I doubt you'd need many Bat-Hook Power Line Taps(tm).
No. Not it doesn't. GMail will not encrypt ePHI at rest or in transit (except reading it, via HTTPS) as required by HIPAA. You clearly have no idea what you're talking about. Please climb back under your rock.
Well that, and Client Access Licenses that you have to buy so your clients can connect to the server. I think those are about $30 a pop. Oh and Microsoft per incident support is $250/ea, just fyi.
You mean a family of 5 can't each watch a movie every day and a half? You know a lot of people watch all of their TV via Netflix as well right? Also if you use 500GB a month on video, that means they can't use any other bandwidth for the month. Dad can't VPN into work, Suzie can't stream music and little Johnny can't play online games. I think within the next few years 500GB a month won't really be a lot of bandwidth for many families. At least families that are getting all their video (TV, movies) online.
Sure, I can try anyway -- it's a communication tool that attempts to combine the best of IRC, instant messaging, e-mail and web forums into one streamlined interface.
Personally I think it failed because it was overly ambitious and was overly compromised. It was too clunky for real time communication and didn't offer enough new features for it to supplant e-mail. It was a _very_ interesting exercise and something that needs to happen. I don't know about you, but I spend all day logged into IRC (and IM via bitlbee, gtalk and AIM) as well as sending e-mails and browsing the occasionally message board. I think the next "big things" will be merging all these disparate communication mediums.
I think he's talking about 4GB/s to a single disk, which is what HDSL provides, a full 8 PCI-e 2.0 lanes of bandwidth to a single drive. Whereas with SAS, sure a single CONTROLLER has up to 16 x1 lanes available, but it still cannot communicate to an individual drive at more than 6Gb/s. Now if you're using spinning disks this isn't an issue, but once you move to high-end SSD you need more than 6Gb/s to each drive, which SAS cannot provide.
As far as FC vs SAS latency, I'd really like to see some proof to backup your claim. But really it doesn't matter. SAS is great for certain things. When you need to build a SAN you typically don't use SAS beyond the disk enclosure. You can't build an entire storage network out of SAS.
Then your guess was pretty close! I thought I read it quoted at 4x faster. There's also the fact that it uses 90% less power, and I would assume 90% less cooling as well? Not to mention the dramatic reduction in floor space (not sure on their cost per sq ft obviously). I wonder what the difference in operational costs of the SSD array would be vs magnetic disks. And of course, no matter how many spinning disks you throw at it, you'll never get 1ms access times, unless it's coming out of RAM cache. I can tell you that you can expect to pay probably close to $1k/disk for 146GB 15K drives from the major storage vendors. Even if we assume only $500k for 700 disks there's still a lot of storage infrastructure to pay for (enclosures, cabinets, directors, cabling, etc, etc). More throughput (maybe not peak theoretical?), more IOPS, less floor space, less cooling, less power. Seems like a pretty attractive solution all around, depending on your workload.
The article summary is wrong, from TFA: "So you're getting 4GB/sec. of PCIe bandwidth, not the 5Gbit/sec. or 6Gbit/sec. SAS bandwidth. You're getting almost an order of magnitude of bandwidth to the storage internally just because you're using an interface that's capable of it," Pollack said.
That's 4GB(ytes) per second. Not 4 gigaBIT per second. That's 32Gbit/s vs your 6Gbit/s via SAS.
Throughput is far less relevant in this scenario than IOPS. You 150 drives would put out a PEAK theoretical throughput of sequential reads (no writes!) of about 27k IOPS. Or about 10% of the total IOPS of AOL's SSD-based storage system. You're also comparing individual serial connection bandwidth (a single FC or SAS connection) with the entire throughput of your director. They're doing 4GB/s (32Gb/s) per connection vs your 6Gb/s per connection.
I thought that was very odd as well, but maybe their workload is dramatically more reads than writes? RAID 5 obviously gives them a LOT more capacity, so maybe it made sense for them?
I think it's just a dramatic difference in workloads. I think Facebook and Google have massive storage capacity requirements, whereas AOL just wanted more IOPS and/or throughput. But, the bottom line is, it was cheaper to throw hardware at this particular problem than engineering expertise. Right tool for the job, I suppose.
I'd ignore the cost ($20/GB) even though it's actually pretty good. The real interesting thing here is $/IOPS. To build out a similar system based on $/IOPS using 15K FC disks would cost significantly more, and wouldn't ever provide the same access time (less than 1 millisecond). I'd love to see a storage vendor quote out a DELIVERED COMPLETE SYSTEM that provides 250k IOPS using fiber channel disks and do it for under $1M. I don't think any of the big guys (EMC, 3PAR, Hitachi, etc) could touch it.
Slashdot Mirror
You're assuming they'll have anything to license when the NetApp lawsuit is over.
50MB/s is pretty poor for a mirrored raid configuration over 1GbE. Even a single 7200rpm disk should be able to pull off more than that, doing sequential reads anyway. Do you see excessively high CPU utilization during the copy? Are you using software RAID?
I thought Google supported Net Neutrality as we know and understand it on wireLINE services and on wireLESS services they just wanted to prioritze traffic based on the TYPE of traffic (eg - VoIP traffic would be preferred over BitTorrent). Is this not correct?
If you're that large, or the information is that sensitive, you build a "private cloud", the REAL buzzword the industry has been falling all over itself about.
I find it humorous that you assume people still work a world where you can operate when disconnected from the Internet. Even if everything's hosted locally you can't use the web or send e-mail. So yeah, you just go home for the day, I don't care if your servers are down the hall or the other side of the country.
But the obvious answer is redundancy with physical diversity, of course -- regardless of where your IT infrastructure is hosted.
Any distro could release an updated kernel with the patch. But what you're describing isn't Linus's problem, it's a distro problem. He fixes the problems at the source and it's up to the distros to fix them downstream.
One of our network admins hooked up one of these at our CFOs (hilariously huge) house. About a week later 2 guys in a van showed up and told us it was blocking cellular signals for a several mile radius. Apparently it has to do with the distance between the base station and the antenna, and they had been installed too close. We went and re-read the instructions and sure enough the two were too close together. Apparently it's very easy to cause interference with these things.
You're referring to what they call envelope encryption. What we do is require TLS on any e-mail being sent out that is flagged by the Ironport as requiring encryption. You can then have it fail back to envelope encryption. In practice it's pretty obvious to spot someone intercepting your messages. They'd have to create an account to read the message and the intended recipient would realize it when they tried to sign up.
As far as getting caught, I assume you just unhook the other end. And it's not like people move their homes very often, I doubt you'd need many Bat-Hook Power Line Taps(tm).
No. Not it doesn't. GMail will not encrypt ePHI at rest or in transit (except reading it, via HTTPS) as required by HIPAA. You clearly have no idea what you're talking about. Please climb back under your rock.
Cisco Ironport. Especially if you need e-mail encryption (think HIPAA).
Why would you take it down?
Well that, and Client Access Licenses that you have to buy so your clients can connect to the server. I think those are about $30 a pop. Oh and Microsoft per incident support is $250/ea, just fyi.
Assuming it has the same quality as the packages currently in the Redhat 5 repositories - it is indeed saying a lot.
Wow, someone mod this guy up. Excuse me while I take my first serious look into Mono.
(not sure if that sounded sarcastic - but I'm being serious I had no idea)
You mean a family of 5 can't each watch a movie every day and a half? You know a lot of people watch all of their TV via Netflix as well right? Also if you use 500GB a month on video, that means they can't use any other bandwidth for the month. Dad can't VPN into work, Suzie can't stream music and little Johnny can't play online games. I think within the next few years 500GB a month won't really be a lot of bandwidth for many families. At least families that are getting all their video (TV, movies) online.
Sure, I can try anyway -- it's a communication tool that attempts to combine the best of IRC, instant messaging, e-mail and web forums into one streamlined interface.
Personally I think it failed because it was overly ambitious and was overly compromised. It was too clunky for real time communication and didn't offer enough new features for it to supplant e-mail. It was a _very_ interesting exercise and something that needs to happen. I don't know about you, but I spend all day logged into IRC (and IM via bitlbee, gtalk and AIM) as well as sending e-mails and browsing the occasionally message board. I think the next "big things" will be merging all these disparate communication mediums.
I think he's talking about 4GB/s to a single disk, which is what HDSL provides, a full 8 PCI-e 2.0 lanes of bandwidth to a single drive. Whereas with SAS, sure a single CONTROLLER has up to 16 x1 lanes available, but it still cannot communicate to an individual drive at more than 6Gb/s. Now if you're using spinning disks this isn't an issue, but once you move to high-end SSD you need more than 6Gb/s to each drive, which SAS cannot provide.
As far as FC vs SAS latency, I'd really like to see some proof to backup your claim. But really it doesn't matter. SAS is great for certain things. When you need to build a SAN you typically don't use SAS beyond the disk enclosure. You can't build an entire storage network out of SAS.
Then your guess was pretty close! I thought I read it quoted at 4x faster. There's also the fact that it uses 90% less power, and I would assume 90% less cooling as well? Not to mention the dramatic reduction in floor space (not sure on their cost per sq ft obviously). I wonder what the difference in operational costs of the SSD array would be vs magnetic disks. And of course, no matter how many spinning disks you throw at it, you'll never get 1ms access times, unless it's coming out of RAM cache. I can tell you that you can expect to pay probably close to $1k/disk for 146GB 15K drives from the major storage vendors. Even if we assume only $500k for 700 disks there's still a lot of storage infrastructure to pay for (enclosures, cabinets, directors, cabling, etc, etc). More throughput (maybe not peak theoretical?), more IOPS, less floor space, less cooling, less power. Seems like a pretty attractive solution all around, depending on your workload.
The article summary is wrong, from TFA:
"So you're getting 4GB/sec. of PCIe bandwidth, not the 5Gbit/sec. or 6Gbit/sec. SAS bandwidth. You're getting almost an order of magnitude of bandwidth to the storage internally just because you're using an interface that's capable of it," Pollack said.
That's 4GB(ytes) per second. Not 4 gigaBIT per second. That's 32Gbit/s vs your 6Gbit/s via SAS.
Throughput is far less relevant in this scenario than IOPS. You 150 drives would put out a PEAK theoretical throughput of sequential reads (no writes!) of about 27k IOPS. Or about 10% of the total IOPS of AOL's SSD-based storage system. You're also comparing individual serial connection bandwidth (a single FC or SAS connection) with the entire throughput of your director. They're doing 4GB/s (32Gb/s) per connection vs your 6Gb/s per connection.
TMZ, etc, they own quote a few popular sites these days. Not to mention the untold millions of e-mail boxes I'm sure they still service to this day.
I thought that was very odd as well, but maybe their workload is dramatically more reads than writes? RAID 5 obviously gives them a LOT more capacity, so maybe it made sense for them?
I think it's just a dramatic difference in workloads. I think Facebook and Google have massive storage capacity requirements, whereas AOL just wanted more IOPS and/or throughput. But, the bottom line is, it was cheaper to throw hardware at this particular problem than engineering expertise. Right tool for the job, I suppose.
I'd ignore the cost ($20/GB) even though it's actually pretty good. The real interesting thing here is $/IOPS. To build out a similar system based on $/IOPS using 15K FC disks would cost significantly more, and wouldn't ever provide the same access time (less than 1 millisecond). I'd love to see a storage vendor quote out a DELIVERED COMPLETE SYSTEM that provides 250k IOPS using fiber channel disks and do it for under $1M. I don't think any of the big guys (EMC, 3PAR, Hitachi, etc) could touch it.