Posts tagged Virtualization
Congratulations to Tegile, whose press release today (picked up on multiple news sites, links below) includes one of the reasons we chose their HA2100EP storage array for our needs: Low latency & high throughput. We also needed iSCSI and F/C for our customers.
Newcomer gets out its box, plans to sell it cheaply to all comers http://ger.ms/LTjuzY
Tegile Selected as a Red Herring Top 100 North America Tech Startup http://ger.ms/KxUJZE
Our vmForge VDC clusters are peaking around 14,000 IOPS and the MASS solution is offloading about 11,500 IOPS via SSD. I wish I could graph this and show it to the public at large but I don’t have a way yet. (those are peaks, average is closer to ~8,000 IOPS with ~6,900 IOPS via SSD)
We’ve been working on building a proper vmForge account creation and management site, so for the last couple of weeks I’ve worked a lot with the vCloud API. It’s a RESTful system, which means everything’s done by getting XML from and posting XML to a web server. It’s perhaps not the worst API I’ve ever worked with, but its tedious to work through. Even more so because their parser is insanely pedantic, to the point of requiring elements in a specific order. So that’s a point in PHP’s favor, that it maintains key order in associated arrays.
A while a go, I wrote down some personal rules to what I should do as an admin. First and foremost, and underlined about six times was this: Test Everything. It seems so simple, but you have to consider, if it’s not tested, and verified, it’s not working. Simple. Oh, it may be working, but it may not be. “May” is not good enough. So when I roll out a new server, I test and test and test. When I make a change, I test it. If I do reboot a server, I watch logs to make sure that the services are working. If the logs don’t show that everything is working, I manually test things.
Having a development server separate from your production server is a great idea. You can make changes without fear of breaking your production system. You can develop and test new features before they’re ready to roll out. And you can try out entirely new ideas without committing to development.
With that, it should be pretty clear that your development server should be as identical as possible to your production environment. It does you no good to write a new feature which leverages FiddlyC 4.2pl64 with QuirkyProc enabled if your production server is designed for and built and upon FiddlyC 3.
Fortunately, this is something which a virtual data center makes really easy. If you’ve based your production server on a template from your catalog, it’s just as easy to create two or three identical VMs based on that template as it is to create one. If you want to try something really new, create a new VM. If it doesn’t work out, tear it down and recover the resources.
You can even clone your current production vApp and servers into a template, if you have space available and can afford the downtime. You’ll need to shut down the vApp, then right-click on it and select “Add to Catalog”. Give it a name, and click OK. This will take some time, depending on how many VMs and how much disk is allocated. Once the process completes, don’t forget to restart your production vApp. But now you’ll be able to create a development environment which is exactly identical (aside from network names and addresses) to the original.
When it is time to change or update your hosting services, the choice between co-location and cloud services can become overwhelming.
This quick post on how virtualization and physical hosting compare may help you.