As IT budgets are squeezed, and managers are looking for new ways to save money yet deliver the same services, this may be the perfect time to look into vendor-independent solutions. Vendor lock-in is great for the vendor, but not as much for the IT shop. In this article we focus on the infrastructure side of IT, exploring how enterprise-grade services can be had for drastically reduced costs, or even for free.
Are you still running Oracle on proprietary Sun SPARC hardware? How about SAS on large, expensive IBM POWER servers? Now is the time to test these applications, and realize the performance gain, on more "commodity" hardware.
A pair of quad-core Intel Xeon processors will simply amaze you, and at a fraction of the cost. Switching architectures is never easy, but know that most everyone supports your most critical applications on Linux with x86, including the two examples we mentioned above. The performance gains alone are enough, but wait, there's more.
The best part about using off-the-shelf hardware is that it is cheap enough, even when you purchase the loaded server configurations (RAID, Lights-out Management, etc), you're still at a fraction of the cost compared to SPARC or POWER based servers. Not to imply reliability is a concern--it isn't--but at that price point, you can afford to purchase extra servers for redundancy or even high-availability clustering.
The x86 server market has matured tremendously over the last ten years, and remote, centralized management is now much better than proprietary vendors' options. It's especially better if you purchase a blade server, which consolidates hardware management for up to 15 servers into a single interface.
IBM Tivoli and HP OpenView are the large, industry standard network and systems monitoring solutions. Unfortunately, their licenses, depending on options, can comprise as much as 10 percent of an IT department's budget.
In the monitoring space, open source enlightened IT shops use OpenNMS, Nagios, or more recently Zenoss. They are all free, extremely powerful and easy to use, and most importantly have community-contributed modules to extend their functionality. Instead of paying thousands of dollars to enable a feature in your current NMS, just download the community created, approved, and verified module. Here are several articles we've written on these tools in the past:
On the virtualization management front, we are pleased to finally be able to report that VMware ESX is not the only viable option. It used to be, but open source tools have caught up. Citrix's XenServer, made free back in February 2009, is a full-featured and reliable virtualization infrastructure. If you want features like live migration in ESX, you must purchase the most expensive license. Then, you must license ESX for each physical server, which is two to three times the cost of the hardware itself. It's seriously insane, to put it bluntly. Citrix will try to sell you a reasonable license, but they don't hold critical features ransom. Red Hat has a fully open source ESX-like product, called oVirt. It's not quite production ready yet, but look into it very soon, if you're so inclined.
Ever wonder if you're doing something wrong when you see that support renewal bill for your storage array hit your inbox, at hundreds of thousands of dollars? While the SAN infrastructure may be nice, from the centralized management aspect, it's also a burden. You hire specialized employees to deal with it, and never really get great performance due to its shared architecture. Certain storage applications may be well suited for SAN storage, but not most.
The most expensive storage you have is probably grossly underutilized, to keep resource contention down for the critical applications that use it. Oh, and it shares a single point of failure. SAN-attached arrays have tons of redundancy built in, but they are still a single hardware device that can and will fail. What if your critical applications had local on-server storage that was replicated to a secondary server, which could take over application serving duties in the event of hardware failure. That setup, using DRBD to replicate storage, costs nothing more than the price of two servers with locally installed disks.
There is a reason the huge players (e.g. Google) use off-the-shelf hardware in a highly available redundant configuration such as this. Performance and true redundancy can be yours; again the architectural changes when moving to much cheaper solutions also provide huge benefits, ignoring even cost. The centralized management arguments don't really hold water these days, with tools for Unix/Linux server management such as Cobbler for automated deployments and Puppet for configuration management.
Need disaster recovery for your SAN due to regulatory compliance? First you have to get a license to enable it (hundreds of thousands of dollars, usually), and then you must buy a copy of your entire SAN!
Instead, you can replicate your block devices with DRBD, or just install another OpenFiler node (which uses DRBD) and enable replication. LINBIT, the makers of DRBD, even have a product that will allow replication over slow WAN links, called DRBD Proxy. It isn't free, but the price point is an order of magnitude less than SAN and NAS providers' solutions.
Take, for example, the easy target: e-mail. Do you have 10, 20, or more servers dedicated to running Exchange? Or even an open source solution such as Cyrus? Either way, you're maintaining servers and services that are difficult, time consuming, and really don't provide anything for your business other than a commodity service. If you're a Microsoft shop and can't get along without Exchange, Microsoft has exchange hosting at a quite reasonable price. Zimbra, too, (a Yahoo! Company) can provide hosted e-mail at a fraction of the cost of keeping it in-house. Google, of course, will provide up to 100 free e-mail accounts for your business with Google Apps.
E-mail is the canonical example, but there are certainly other areas your IT department can look to, and ask the question, "should we really be doing this?" The answer is often, "no."
Article courtesy of Enterprise Networking Planet.