June 15, 2011 at 9:05 pm
Comments posted to this topic are about the item Lessons Learned from a Large Virtualization Implementation
June 16, 2011 at 12:53 am
Could you elaborate on the snapmanager for SQL issues you've been experiencing? We've went virtual and now looking to implement it as our backup strategy but having issues with single database restores.
_________________________________________________________________________________SQLGeordieWeb:- Jarrin ConsultancyBlog:- www.chrisjarrintaylor.co.ukTwitter:- @SQLGeordie
June 16, 2011 at 1:20 am
Hmm the server sprawl you describe would indicate that there aren't any change management policies or capacity management reviews in place.
I'm a big fan of virtualisation but your vendors and customers were right to be sceptical. Not every server is a suitable virtualisation candidate, some servers just shouldn't be virtualised, storage I\O is your biggest headache.
As an example, in a previous contract the organisation virtualised everything (and I do mean everything). We had a new SQL server deployment for a GIS mapping system producing maps of the county (one of the largest in the UK). AAfter working with the vendors and internal teams we decided this server had to be physical to provide the performance this system required. If you're going to provide resources to a VM that consume most of the host, it probably shouldn't be a VM 😉
In my current contract we were asked to use snap manager. We soon pushed back on this as it's ok for storage replication but not very suitable for fast single database restores. We now use Litespeed for day to day backups and scripting to DR. You need to provide a strong business case and stick to your guns.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 16, 2011 at 3:41 am
I would be interested in your experience regarding performance. The experience we made was that performance decreases significantly on a VM based system instead of using a HW based one. So we actually started migration our SQL instances onto a dedicated HW based system. The main reason for the decrease in performance was attributable to IO which went down the drain.
June 16, 2011 at 4:33 am
I am consolidating our medium and small databases on VMWare servers.
Can someone explain the advantages of using NeNetAPPanager for SQL ?
What are the benefits compared to the native SQL backups?
thanks
Thayal
June 16, 2011 at 5:02 am
Thank you Scott. The article was quite informative.
M&M
June 16, 2011 at 5:07 am
Thayal Muhunthan (6/16/2011)
Can someone explain the advantages of using NeNetAPPanager for SQL ?What are the benefits compared to the native SQL backups?
Are you using NetApp for your SAN storage? If so then i'd either speak with their consultants or do a bit of reading on snapmanager for SQL (information available on their website) before even thinking of implementing it!!!
_________________________________________________________________________________SQLGeordieWeb:- Jarrin ConsultancyBlog:- www.chrisjarrintaylor.co.ukTwitter:- @SQLGeordie
June 16, 2011 at 5:51 am
I find this very interesting. A recent article I wrote on SQL 2008 Clusters here[/url] did become a bit of a VMware discussion, the point I was (trying :pinch:) to make was that sometimes, Virtualisation is a difficult sell, even to the point where this would sacrifice a "perfect" solution in favour of a "workable" solution. Banging a bit of a different drum.
I your article is a great eye opener and good points for consideration when implementing large or small Virtualisation infrastructures. Virtualisation as a technology is there, its mature and it works. But Virtualisation has wider implications as a concept to an organisation. The impact into Operations (backups as you mention,) needs to be understood and as you also mention, collaboration and buy in from the right teams.
Great article. Thanks for sharing.
😎
June 16, 2011 at 6:36 am
Nice overview !
I always keep in mind this very to the point article by Brent Ozar (@BrentO) regarding our job and virtualization:
http://www.theinfoboom.com/articles/virtualizing-databases-too-big-to-fail/
Pay special attention on the real question !
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
June 16, 2011 at 6:37 am
I think the key point in the article is that most of this was dictated to the SQL guys. This seems to be the way these are done. There is no benifit to SQL itself, but there is to the organization with respect to overall manageabilty. Problem I am currently having is that our VM guys think the VM server is fire and forget. We end up having performance problems and they do not monitor properly so we don't get any answers on solving the issues. The age old mantra of "optimize the SQL code" becomes the crutch for VM server mismanagement.
June 16, 2011 at 6:39 am
...or they are not provisioning the servers correctly and the only way to get the performance they need is to move the DBs to individual VM SQL Servers.
June 16, 2011 at 6:50 am
We plan to provision SQL Server on VMWare to our retail outlets. Has anyone worked with cloning SQL Server using a gold standard image in a VMWare environment? I'm seeking documentation and insights from anyone who has worked in this space.
June 16, 2011 at 6:58 am
Scott, you say the VMs performed better even with much reduced CPU and RAM allocated. How old were the physical servers replaced?
Was one of the drivers for this a server refresh exercise?
---------------------------------------------------------------------
June 16, 2011 at 7:27 am
The servers ranged in age and versions. We had some very old system that certainly needed the upgrade but we also had some newly built systems. The conversion were all P2V as is. There were no OS upgrades. The VM team ran VMWare Capacity Planner 3 weeks prior to any conversions.
The virtualization project was needed in order to facilitate a move to a brand new datacenter. Virtualizing all the servers removed the need to move physical hardware. New hardware has been built in the new datacenter and the VM are being migrated as we speak. The distance between the existing datacenter and the new datacenter is about 50 miles.
June 16, 2011 at 7:36 am
Brenda,
We've looked into cloning SQL Server VM's and we've done it in limited fashion. Our issue is with the fact we maintain a large number of different possible OS and SQL Server version combinations and to keep and maintain so many templates is not feasible.
Recently we created 14 identical servers from one template. This worked great and the only thing we had to do on our end is change the @@servername. I have to be honest and say the VM team created and applied the template (we're a big company so there is a huge separation of duties), but if your interested I can try to track down the method they used. VMWare has good documentation so maybe start there. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027865
Viewing 15 posts - 1 through 15 (of 47 total)
You must be logged in to reply to this topic. Login to reply