An Enterprise RAID array isn't strictly about redundancy (although it sounds like that was the point Score Whore was trying to make). It is also about performance. Let's say you are trying to make a 100TB SAN. You can do this using the strategy you outlined, by using 3TB drives and doing a RAID 1 on them. So, 100TB / 3TB = 34 drives * 2 (RAID 1) = 68 drives. Each spindle on a 7200 RPM SATA drive only delivers about 75 IOPs, so that gives you 5100 IOPs Total.

In an Enterprise environment, you are probably going to need a lot more than 5100 IOPs in a 100TB SAN. So, let's say you decide to use 300GB 15k SAS drives. Those give you about 175 IOPs per spindle. If you use the RAID 6 strategy you outlined, which I am fond of myself, (6+2, or 2 failures out of every 8 drives), that would put you around 448 disks total (448 / 8 disks per RAID set = 56 sets * 6 usable drives per set = 336 usable drives * 300 GB = 100800GB). With the 448 spindles, 448 * 175 IOPs = 78400 IOPs. That's a little bit closer to what we're looking for. Throw in a few spares at 30:1 (15 drives), to put you to 463 drives.

How many SATA drives would it take to match the IOPs in a RAID 1 configuration? 78400 IOPs / 75 IOPs per drive = 1046 drives. Spares at around 30:1 means another 35 disks, for 1081 total.

Next we factor power into that. With a Google search, I averaged typical power consumption from 8 7200 RPM 3TB SATA drives (8.6875 W), giving you 9391.188 W for the SATA array. For the 15k 300GB 3.5" SAS drive, it seemed like the most common Google results came back to the Samsung Cheetah, and the data sheet for that one says 7.92 W typical, or 3666.96 W for the SAS array, which means that the SATA array would require 2.5 times the power. More drives, more power means more cooling (and obviously more space as well).

It all depends on what you are trying to accomplish. In an enterprise environment, space, cooling and power are often big concerns. Depending on your environmental limitations and other factors (i.e. regulations, compliance, etc), money isn't always the primary motivator - that all depends on the nature of the business. If you work in a business that is heavily regulated, then you will likely not bet your job on a bunch of SATA disks to store your 5 (or 7, 10, or more) years worth of data that must be searchable, discoverable, highly available, etc (ok, you might bet your job on it, but I'm not going to bet mine on it). Most likely, you are going to tell your company that to protect that data (and potentially your job, depending on your responsibilities), they need to shell out for a costly SAN. Perhaps even 2 geo-redundant SANs that are replicated. Then, you might put a bunch of SATA disks behind that with a backup agent for another layer of protection. Then you might also dump that data to tapes. Which you then ship offsite. Because if things get ugly, you don't want to be the decision maker or recommender who proposed the SATA disks because they were the good enough solution.

Or maybe you do want to be in that position. But I sure don't want to be there. I'm a big fan of well-developed DR/BC plans and highly available infrastructure. When things are working, there are many solutions that can work well. However, when things stop working, you have to have a well-formed plan in mind to recover from the failure. And "we'll just get replacement drives from COSTCO" isn't a particularly well-formed plan (in fact, where I work, even suggesting that would probably result in termination). If you have to wait more than 4 hours to get replacement drives from HP, you should probably look at another storage vendor. Besides, your array should have enough hot spares for the array to rebuild itself even in the event that you don't get those drives in a timely manner.

TL;DR Higher performance disks may be required over cheap disks. It's not always just about redundancy. The same shoe doesn't fit everyone!

If I were going to relocate internationally, Brazil would be high on my list (although I don't know what their immigration policy is, and whether it's even possible). I was sent to Sao Paulo and Campinas recently for work, and although I didn't particularly care for Sao Paulo, I found Campinas to be quite beautiful - it would certainly be on my list of possibilities for relocation.

I can say from experience that working with various telcos (Algar, Embratel, GVT) and even the colo we put equipment in (Terremark Sao Paulo) is a serious challenge if you don't speak Portuguese. As more and more foreign companies start to look at Brazil for various reasons, more and more of these Brazilian companies are going to be looking to hire people who can speak both Portuguese and English. From our IT staff we have down there (who speak both Portuguese and English), the differences in salary compared to the US aren't that large, and there are other variances in compensation that make up even some of that difference (for example, they appear to have a lot more holidays and PTO than we do).

As AC mentioned, I did enjoy the slower pace, and everyone seemed fairly happy. Heck, even in the worst traffic in Sao Paulo, I didn't hear that many people blaring their car horns. Unlike places like New York City where almost everyone uses them constantly.

Yes, Brazil still has issues (corruption, poverty, etc) - but every country has issues of some sort. Pick your poison.

Agreed. If I'm scripting on a Windows box, I generally use the tools that are already installed, which means VBscript or Batch programming. Sometimes Powershell if I feel adventurous.

Here are a couple of places to look to get you started. This practice is generally disguised as "Lawful Intercept". The net effect is that any government agency can trap any data that they want to. If you look at the Google search, you will see Cisco configuration guides on how to set this feature up.

https://www.google.com/search?q=cisco+lawful+intercept
http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf

Keep in mind, this is just the published part that we know. What other capabilities exist that aren't published? It would probably scare all of us.

The reason that the government (and everyone else) is so concerned about Huawei is because vendors here in the US already have the capabilities to capture whatever the government wants. Why would China be any different? The only difference is that Huawei isn't publishing configuration guides for their implementation...

Sao Paulo. The delta between the rich and the poor is obvious just driving around the city. Granted, Sao Paulo may be the exception rather than the rule, but there are an awful lot of people there, which makes it a really big exception.

Agreed. If virtualizing Exchange broke the environment, then the environment wasn't sized properly. Too few servers, not enough IOPS, something. Of all things, Exchange is the one thing that I would almost never consider running physical. 2003, 2007, 2010 - all work flawlessly virtualized. The only thing I've not tested is the Unified Messaging role, which until recently wasn't supported virtualized.

Cisco fully supports virtualizing most of their telephony components, and most of their stuff runs on RHEL. I don't see any reason Asterisk couldn't work - it's not like Cisco is doing anything magical that others couldn't replicate.

Sadly, yes. Several (generally smaller) software companies still use them, especially in certain verticals.

USB pass-through doesn't help much with portability, though. In some cases, USB over IP (and Serial over IP) products can solve that problem.

There is an argument to be made that if you have a very non-performant and underutilized database server, virtualizing would help with consolidation by eliminating excess hardware (and power, heat, management, etc.) from the environment. But I fully agree with you on highly performant database servers - virtualizing won't help you consolidate. In that scenario, virtualizing would give you some different maintenance and protection options. For example, once virtualized, you can more easily move the database VM to different hardware if the need arises. This can be a little more time consuming in the physical realm.

There are always compromises. You just have to figure out what is most important to you. If your goal is 100% virtualization, then you are going to have to be more diligent about designing, planning, and maintaining the environment. If you are not the only person who will be responsible for the environment, you have to make sure that you put in a solution that whoever else is touching the environment can support as well - one well-meaning, but improperly-informed person can do a lot of damage in even the best-planned environment.

Personally, I would always leave at least one physical server for AD/DNS (which I would give the PDC Emulator role, since it's a fairly resource intensive one and you're likely to have plenty of spare cycles on the physical server).

As long as your environment isn't especially complex, you will probably be better off virtualizing vCenter. However, depending on your environment, there may be justification for keeping vCenter physical.

I like to have some kind of monitoring platform that is physical - it's never good to have a catastrophic failure that you don't get notified of because your monitoring software was one of the affected VMs, or your mail server VM was down and the alerts didn't make it to you (or you can virtualize your monitoring platform, and have something physical that monitors your monitoring platform - possibly something with a SMS gateway, which frequently only seem to work right with physical servers anyways). Generally, you can put this on either your physical AD/DNS server, or you vCenter server if you have one.

Any server that relies on any specific hardware to operate is certainly not a virtualization candidate, unless the vendor has a solution. Fax servers (typically requiring fax boards), servers with hardware dongles for licensing (although, sometimes you can use USB or Serial over IP devices to work around this limitation), etc.

Any highly performant database server (especially if clustered) deserves a second look before virtualizing. Not that it can't be done, but there can be an awful lot of suffering if you don't get it right the first time.

Any software vendor with whom you have support contracts should be consulted before virtualizing the corresponding server - some simply refuse to support their products when virtualized. Sometimes you can lie about it and still get support, but some of them will remote in and check for VMware services, processes, etc and not provide support if they are found.

Agreed that this is "generally incorrect". It really depends on the size and complexity of the environment, however. If you have a fairly small environment that can be covered by a small number of hosts, then I would most likely virtualize vCenter. However, if you have a large enterprise environment with redundant data centers and a non-small number of hosts, I would take a more careful look at whether virtualizing vCenter was the correct solution. There are some circumstances that make virtualizing vCenter a little ugly in a full DR situation - anything where you are taking an entire data center offline (planned power outage, cooling/power failure, etc). Especially if you are using a 3rd party distributed switching product (aka Cisco Nexus 1000v), where you can run into some circular dependencies if you have not properly planned your environment. Perhaps this has been fixed at some point, but a version or two ago, when a host initially booted, all VM network connectivity was blocked until the VEM (1000v Host software) checked in with the VSM (Virtual Supervisor). The VSM was a VM that tied into the vCenter database to provide distributed switching. If vCenter could not start for some reason (maybe because your database VM was using Nexus 1000v for network connectivity, or vCenter was using AD authentication for SQL and an AD server was unreachable, or vCenter was using DNS to reach SQL, but no DNS server was available), then none of your hosts would have network connectivity because the VSM wouldn't complete initialization until vCenter was online.

The obvious fix is that all vCenter dependencies have to be on VMs that do not rely on any Nexus 1000v ports. Unfortunately, this means you have to use hosts that are not at all controlled by Nexus 1000v, or you have to have both standard vSwitch/vDS ports and Nexus 1000v ports connected to the same host - and if you ever move vCenter around, that means all of your hosts have to have both vSwitch/vDS and 1000v ports. Or you can run all dependencies right on the vCenter server - but that isn't ideal either, because that's another SQL server (and license) that you have to manage. Of course, if you opt not to virtualize vCenter, then you are likely either going to have on-box SQL or be connecting to a physical SQL server regardless. Even if you're not using Nexus 1000v, you need to be fully aware of all of the dependencies in the virtual environment; one minor oversight can lead to fairly significant consequences.

As far as virtualizing vCenter being the "Best practice", that's fine for protecting against host failures inside a single data center. If your DR plan needs to accommodate a failure of an entire data center, then you need more than that. In that case you are typically going to be using vCenter Heartbeat or a 3rd party protection product, and the HA/DRS protection is less vital. In this type of environment, I would generally favor a physical vCenter server in each data center.

I was just short of getting that raise that would take me into the 6-figure range, but I was tired of working 60 hour work weeks. I took a job with a 15% pay cut for a 4-day work week. However, I do get bonuses here, so it didn't end up being nearly that much. Best move I've ever made in my life. The Health Insurance is a little disappointing, but it's not the worst I've heard of either. Plus, it's a great place to work - I actually feel appreciated for the first time in my working career, which is pretty amazing.

However, there don't seem to be a lot of candidates out there who are willing to make that kind of change - for most, it's all about the money.

And if I could get $20k per year just to wear a neck tie, I'd totally do it.

I think this is exactly right. Head hunters aren't much better, because most of the time they have no idea what they are talking about either.

And as AC mentioned, there is an entire generation of "engineers" who seem to know only what the books tell them (and maybe not even that much). As far as Network Engineers go, it's amazing how many people list "Microsoft" or "VMware" or "Cisco" on resumes (especially as far as Certifications go), but can't answer basic questions about the technology. I'm guessing that their TestKing's didn't prepare them well enough for that. If you are asking for a salary anywhere close to 6-figures, you shouldn't be stumped by basic questions in your field - if you are, then you are likely under-qualified and/or over-employed.

And yes, there are employers that list ridiculous qualifications and inadequate compensation. If you are a savvy person, you can identify those positions pretty quickly, and you ignore them, because they aren't targeted at you. If the compensation is dis-proportionally low compared to the qualifications, then that job is for someone who is good at lying on their resume and bs-ing their way through an Interview, not someone who has real talent. Any employer who claims otherwise is disingenuous.

I second this motion. Where do I sign up?