You must have never worked in a big enough enterprise. Sure, buying a few HP or Dell boxes with 2 sockets will run you a few grand, but when the support costs on 1 superdome can pay for 2 IT workers per year, not even mentioning the costs of additional disk or the initial purchase, you would be hard pressed to think that a few IT workers will clog the costs up too much. In all, about 8 UNIX guys can administer 500 machines pretty effectively. Cut that to 5 and you end up with loose ends and lots of problems. You saved a lot of nothing doing that.
Are you 100% sure his problems are IO bound? I agree that human error is something to take a careful look at, however there are multiple ways to skin this cat. Sure, SSD will help if the issue is IO bound, however, there are other things to think about, such as whether or not the concern is truly IOPS or throughput. If it is throughput, then 4+ spinning disks will be easily as fast, as the bus is the limiting factor and not the "spinning" parts. If he really wants speed, why not take things off the workstation, and have a build server with 8 sockets (dual or quad core) and >64GB RAM and then simply check out the executable code........?
My enclosure cost me $199. I bought 4 1TB drives for $90 each. The enclosure came with a card for ESATA (and the enclosure is whisper quiet) and I am doing RAID in software with Linux. Also, I got WD10EADS drives, which are some of the lowest power drives on the market, as the platter density is high and the throughput of 4 drives is more than the 1x pci-e can sustain anyhow. I also enabled 7 second TLER in the firmware on each drive. Your SSD drives can't handle as much fault tolerance as 4 drives. If the bus is pinned on throughput, the only difference is seek and IO, in so much as the controller can handle on either end.
The demands of the application will dictate the ultimate decision. I merely opened for alternatives, to decide if it was simply an issue of feeding the chain in sequential data, or strict IO bound issues for the build process.
in the case of something like this, the difference between SAS and SATA becomes negligible, except for added cost. Sure, the controller will have more fancy logic, however, I would recommend software RAID -OR- A good RAID controller (Not LSI/PERC). The costs start to add up as you go into Areca/3ware, and above-land. If you go software RAID, then make sure you have at least a decent dual core CPU, or your build time will suffer. A dual socket quad or dual socket dual would be preferred, and the more RAM, the merrier, as stated.
Now, even if you go SSD RAID 10, you don't get much more performance until you start using 4x PCI-e or better. You will likely have no real use for that kind of read speed, as it will hit a logical plateau for compile speed.
If speed were a real concern and no price mattered, everybody would sit with a 20 disk multipath fiber channel system feeding a Sun x4600 M2 box with 32 cores and 128GB of RAM.
Something like that would almost compile before you hit commit.
Then forget the SSD drive, unless you are worried about head crashing during a fall. Get yourself a 4+ bay ESATA enclosure and do a Raid 1+0. You will pin the bus for throughput and have fault tolerance out the wazoo. I would recommend larger drives, simply for the larger outer tracks (Larger, meaning high density, not necessarily greatest total capacity).
Data allocation is usually a function of the FS or other internals. However, proper queuing of the access can also optimize a drive. There are no free lunches. You can never have a drive/filesystem that excels at everything as you make trade offs based on the intended workload. Moving around database objects would likely have better performance from 8K or 16K block sizes, depending on the block read of the database. Moving around large data sets, with likely linear read, like tar files would be better served with >64K sizes, even into 128 or 256K block size, etc.
The issue with the Vraptors is that while they are fast, most of that is geared for the data written to the smaller tracks on the outside of the platter(s). In a system with say 250GB per platter, the outer edge is more dense, and a proper fetch/queue will keep speed acceptable with a slower rotational speed.
I am not questioning the speed of the drive, but rather that there is a lower likely-hood that all the benchmarks will be good. Much of the data will be written at the inner rings. Rotational speed is not the only measure of a drive's speed in single disk setups. When you go into multiple disk setups, then access time matters more, when discussing large arrays, and then rotational speed and RAID cache matter more.
Rotational speed is only one component of the equation. As well, a lower capacity drive will be able to keep less data on the outer edge, where the fastest speed of the drive can be measured. Platter density and intelligent drive head mechanics can matter more.
I would only break things out by application if there was a real need. I would recommend against a high usage database being on the same machine as a fileserver, for example but not necessarily keep a fileserver seperated from a low use dns server.
Yes! Anybody whose answer is to use the same tool for any job is either selling something, or only knows how to use that tool (Else they are a zealot). I fall into the zealot category quite a bit, but I also recognize that sometimes, the right tool is not the one I want to use. I hate seeing it, but life is rough.
Well, here's the thing: You took an example as a point. Sure, you may only have to patch firmware once in the HW's life. What about hardware problems? What about other hardware maintenance? Perhaps you need to add another NIC for some reason? In the virtual world, you can move the machine off, etc and not have downtime for that.
Also, if you had to patch the kernel, change the initrd image, modify drivers, and it blew up in your face, how do you rectify this? In a VM world, you roll back the changes. You can even snapshot off an image of your machine, change the virtual network/hostname and test your new kernel, on your app server, in a "lab" environment without additional hardware or downtime.
How about hardware vendor issues? Say your contract with HP is terminating and you can't get as good a deal as Dell or Sun will give you on new hardware. Your management wants to ditch your DLXYZs for Poweredge ABCs. On virtual OSes, you don't have to worry, necessarily, about the underlying hardware. It makes forklift upgrades a snap.
If I were more versed in Solaris I'd be more onboard with it. However, the fact that you can run different OSes is great, however I am not really big on the idea of running Linux in a zone. I do like the debugger on Solaris, though. HP-UX can't exactly do that, as far as my experience. Vpars and Npars seem rather last decade:).
Because your anecdote can be trumped by another anecdote..
Virtualization CAN save money on hardware, cooling, rack space, etc. You have a single multi purpose server. That means that virtualization may not meet your needs. However, take into account the areas where I work, which include a data center that is thousands of square feet (No, this is not a hosting site for web servers, though I have worked for a hosting facility).
Imagine taking into account environments where you need testing, development, pre production, staging and production. Rather than put them on a single machine (Highly unlikely) you can instead buy a small farm of machines, say 20 boxes for multiple applications/environments and then have them pooled into units and use virtual servers of varying priority and power levels. Your staging should have near production capabilities, your dev box, maybe not. Set the thresholds and hardware differences to your liking. However, if each unit was a physical box, even a 1U you would have a lot more rack space required, perhaps multiple node clusters for each, for availability. In a virtual environment, you are pooling physical machines, so at worst, you are overusing capacity beyond your original spec, but the machines should still be available as much as the OS allows.
Your scenario doesn't have any availability for downtime. In mine, if Physical box 11 needs a firwmware patch, I migrate VMs to the other machines and then take P11 offline. I patch it, and rotate in low priority machines to ensure it works as needed. What do you do when you have to go down to the physical machine to patch firmware/bios? You lose all your applications, right?
Are you purposefully trying to look incompetent? Do you know that if you don't want to support SSE3 extensions on a non SSE3 CPU you don't include them in the kernel? How about parts of the kernel that are for ARM, you can strip it out. You can do almost anything with the kernel and YES packages will still run.
It, unfortunately, does not always work that way. MS also depends on selling things that are OS dependent. How many new development tools will MS be able to push for full vendor lock in when people are shown to have a low install base of $NEW_OS? They may continue to develop for older versions or even for multi-platform.
Part of MS' lock-in was that the OS kept you wanting the applications and the applications kept you wanting the OS.
Now, the big part is lazy familiarity. That only goes so far. When people see they can get similar functionality and applications on a different platform that does NOT fuck them over, they will be more inclined to switch to another product.
I have a friend who is totally into sony gear. He has a PS3, Sony TV, DVD player, sound system, etc. Now, if Sony gave him shitty stuff a few times in a row, do you think he'd continue to give them his money? Perhaps, but the chance he may look at Samsung or such increases.
Yes, but changing legality now does not change legality then. And, the telecom immunity does not state it is no longer illegal, just that you cannot prosecute them for their illegal activity and nullifying anything they have done that is illegal in the past, but not making it illegal. That IS an ex-post facto law.
Ex-post-facto laws are illegal, which is also why the "retroactive immunity" bullshit should never fly. If it was legal to smoke pot in 1988 and you smoked pot in 1988, and now in 2009 it is illegal, they can have pictures of you smoking pot out of a GIANT bong and you cannot be charged.
When you cannot run your 3yr old documents on OpenOffice businesses don't even consider running it. Microsoft REALLY wants you to use their macros on a free product they cannot control. In fact, the less that works with Microsoft the better. We should not use SAMBA and instead force everybody to use NFS for windows.....
Get over yourself. The fact is, Novell is giving a lot back. They are taking WAY too much flack for their ill advised involvement with Microsoft. They did not sell out. They are helping AMD build their 3d drivers, doing important work with KDE, Gnome, the kernel, AppArmor, et al. And, until software patents are tossed out in their entirety, they are putting their portfolio of patents together as part of the OIN to help protect open source initiatives.
RAID 5+1 is not a backup solution either. You have created a fault tolerant scenario. Backups are there for after the rebuild when you find out that there are additional issues. The issue is not just the part where a drive can be unusable. People have already given scenarios about what can happen to the data. Any "Backup" solution should keep the data in at least 3 places, one of which, should be portable. Tapes, DVDs, removable disks, etc that can be away from the site.
What good is your RAID if you just had a power spike take out the disks along with their motherboard? Small flood in the room took out your tapes and system? Data's all gone now.
Slashdot Mirror
You must have never worked in a big enough enterprise. Sure, buying a few HP or Dell boxes with 2 sockets will run you a few grand, but when the support costs on 1 superdome can pay for 2 IT workers per year, not even mentioning the costs of additional disk or the initial purchase, you would be hard pressed to think that a few IT workers will clog the costs up too much. In all, about 8 UNIX guys can administer 500 machines pretty effectively. Cut that to 5 and you end up with loose ends and lots of problems. You saved a lot of nothing doing that.
Are you 100% sure his problems are IO bound? I agree that human error is something to take a careful look at, however there are multiple ways to skin this cat. Sure, SSD will help if the issue is IO bound, however, there are other things to think about, such as whether or not the concern is truly IOPS or throughput. If it is throughput, then 4+ spinning disks will be easily as fast, as the bus is the limiting factor and not the "spinning" parts. If he really wants speed, why not take things off the workstation, and have a build server with 8 sockets (dual or quad core) and >64GB RAM and then simply check out the executable code........?
My enclosure cost me $199. I bought 4 1TB drives for $90 each. The enclosure came with a card for ESATA (and the enclosure is whisper quiet) and I am doing RAID in software with Linux. Also, I got WD10EADS drives, which are some of the lowest power drives on the market, as the platter density is high and the throughput of 4 drives is more than the 1x pci-e can sustain anyhow.
I also enabled 7 second TLER in the firmware on each drive.
Your SSD drives can't handle as much fault tolerance as 4 drives. If the bus is pinned on throughput, the only difference is seek and IO, in so much as the controller can handle on either end.
The demands of the application will dictate the ultimate decision. I merely opened for alternatives, to decide if it was simply an issue of feeding the chain in sequential data, or strict IO bound issues for the build process.
I do believe I came well under in cost....
in the case of something like this, the difference between SAS and SATA becomes negligible, except for added cost. Sure, the controller will have more fancy logic, however, I would recommend software RAID -OR- A good RAID controller (Not LSI/PERC). The costs start to add up as you go into Areca/3ware, and above-land. If you go software RAID, then make sure you have at least a decent dual core CPU, or your build time will suffer. A dual socket quad or dual socket dual would be preferred, and the more RAM, the merrier, as stated.
Now, even if you go SSD RAID 10, you don't get much more performance until you start using 4x PCI-e or better. You will likely have no real use for that kind of read speed, as it will hit a logical plateau for compile speed.
If speed were a real concern and no price mattered, everybody would sit with a 20 disk multipath fiber channel system feeding a Sun x4600 M2 box with 32 cores and 128GB of RAM.
Something like that would almost compile before you hit commit.
Then forget the SSD drive, unless you are worried about head crashing during a fall. Get yourself a 4+ bay ESATA enclosure and do a Raid 1+0. You will pin the bus for throughput and have fault tolerance out the wazoo. I would recommend larger drives, simply for the larger outer tracks (Larger, meaning high density, not necessarily greatest total capacity).
The issue with the Vraptors is that while they are fast, most of that is geared for the data written to the smaller tracks on the outside of the platter(s). In a system with say 250GB per platter, the outer edge is more dense, and a proper fetch/queue will keep speed acceptable with a slower rotational speed.
I am not questioning the speed of the drive, but rather that there is a lower likely-hood that all the benchmarks will be good. Much of the data will be written at the inner rings. Rotational speed is not the only measure of a drive's speed in single disk setups. When you go into multiple disk setups, then access time matters more, when discussing large arrays, and then rotational speed and RAID cache matter more.
Rotational speed is only one component of the equation. As well, a lower capacity drive will be able to keep less data on the outer edge, where the fastest speed of the drive can be measured. Platter density and intelligent drive head mechanics can matter more.
I would only break things out by application if there was a real need. I would recommend against a high usage database being on the same machine as a fileserver, for example but not necessarily keep a fileserver seperated from a low use dns server.
Yes! Anybody whose answer is to use the same tool for any job is either selling something, or only knows how to use that tool (Else they are a zealot). I fall into the zealot category quite a bit, but I also recognize that sometimes, the right tool is not the one I want to use. I hate seeing it, but life is rough.
Use the same hardware to run a test environment for that case without any virtualization products like OpenVZ/Virtuozzo or Xen/VMware etc?
Also, if you had to patch the kernel, change the initrd image, modify drivers, and it blew up in your face, how do you rectify this? In a VM world, you roll back the changes. You can even snapshot off an image of your machine, change the virtual network/hostname and test your new kernel, on your app server, in a "lab" environment without additional hardware or downtime.
How about hardware vendor issues? Say your contract with HP is terminating and you can't get as good a deal as Dell or Sun will give you on new hardware. Your management wants to ditch your DLXYZs for Poweredge ABCs. On virtual OSes, you don't have to worry, necessarily, about the underlying hardware. It makes forklift upgrades a snap.
If I were more versed in Solaris I'd be more onboard with it. However, the fact that you can run different OSes is great, however I am not really big on the idea of running Linux in a zone. I do like the debugger on Solaris, though. HP-UX can't exactly do that, as far as my experience. Vpars and Npars seem rather last decade :).
Virtualization CAN save money on hardware, cooling, rack space, etc. You have a single multi purpose server. That means that virtualization may not meet your needs. However, take into account the areas where I work, which include a data center that is thousands of square feet (No, this is not a hosting site for web servers, though I have worked for a hosting facility).
Imagine taking into account environments where you need testing, development, pre production, staging and production. Rather than put them on a single machine (Highly unlikely) you can instead buy a small farm of machines, say 20 boxes for multiple applications/environments and then have them pooled into units and use virtual servers of varying priority and power levels. Your staging should have near production capabilities, your dev box, maybe not. Set the thresholds and hardware differences to your liking. However, if each unit was a physical box, even a 1U you would have a lot more rack space required, perhaps multiple node clusters for each, for availability. In a virtual environment, you are pooling physical machines, so at worst, you are overusing capacity beyond your original spec, but the machines should still be available as much as the OS allows.
Your scenario doesn't have any availability for downtime. In mine, if Physical box 11 needs a firwmware patch, I migrate VMs to the other machines and then take P11 offline. I patch it, and rotate in low priority machines to ensure it works as needed. What do you do when you have to go down to the physical machine to patch firmware/bios? You lose all your applications, right?
He has 3 of them hooked up via monster cables (Sony co-branded) and looped into his Walkman for maximum mind-fuck.
Are you purposefully trying to look incompetent? Do you know that if you don't want to support SSE3 extensions on a non SSE3 CPU you don't include them in the kernel? How about parts of the kernel that are for ARM, you can strip it out. You can do almost anything with the kernel and YES packages will still run.
Part of MS' lock-in was that the OS kept you wanting the applications and the applications kept you wanting the OS.
Now, the big part is lazy familiarity. That only goes so far. When people see they can get similar functionality and applications on a different platform that does NOT fuck them over, they will be more inclined to switch to another product.
I have a friend who is totally into sony gear. He has a PS3, Sony TV, DVD player, sound system, etc. Now, if Sony gave him shitty stuff a few times in a row, do you think he'd continue to give them his money? Perhaps, but the chance he may look at Samsung or such increases.
Yes, but changing legality now does not change legality then. And, the telecom immunity does not state it is no longer illegal, just that you cannot prosecute them for their illegal activity and nullifying anything they have done that is illegal in the past, but not making it illegal. That IS an ex-post facto law.
The US Constitution clearly states no ex-post facto laws. They are not defined within constraints of exoneration or otherwise
Technically, no
Ex-post-facto laws are illegal, which is also why the "retroactive immunity" bullshit should never fly. If it was legal to smoke pot in 1988 and you smoked pot in 1988, and now in 2009 it is illegal, they can have pictures of you smoking pot out of a GIANT bong and you cannot be charged.
More like:
ARGH!! I built a business around my own stupidity. I never did any backups of crucial information and I have only one copy.
This is like drinking DURING your liver replacement.
They are clearly derivative works and protected by fair use.
ESXi is free. ESX is not
Get over yourself. The fact is, Novell is giving a lot back. They are taking WAY too much flack for their ill advised involvement with Microsoft. They did not sell out. They are helping AMD build their 3d drivers, doing important work with KDE, Gnome, the kernel, AppArmor, et al. And, until software patents are tossed out in their entirety, they are putting their portfolio of patents together as part of the OIN to help protect open source initiatives.
RAID 5+1 is not a backup solution either. You have created a fault tolerant scenario. Backups are there for after the rebuild when you find out that there are additional issues. The issue is not just the part where a drive can be unusable. People have already given scenarios about what can happen to the data. Any "Backup" solution should keep the data in at least 3 places, one of which, should be portable. Tapes, DVDs, removable disks, etc that can be away from the site.
What good is your RAID if you just had a power spike take out the disks along with their motherboard? Small flood in the room took out your tapes and system? Data's all gone now.