April 19, 2014 at 11:31 am
Comments posted to this topic are about the item Consolidation Matters
April 19, 2014 at 1:10 pm
With virtual machines, we have actually gone the other way creating instances for each application and may times on their own small VM. Currently we are limiting VM's to hold 3 instances max for small applications. With the entire host licensed, we do not have to worry about individual instances. The main reason we have gone in this direction is it is very hard to find a patching schedule when you have multiple areas in a 24X7 enterprise on the same machine. Ive found it takes months sometimes to come up with an agreed upon maintenance window. With everything separated it is much easier to patch, but requires patching on more servers. Are others doing the same thing with VM's?
- Tony Sweet
April 21, 2014 at 7:09 am
Our shop is has taken virtualization to almost an extreme. The VMWare team has modified configuration files so they can build a SQL Server from the ground up w/o DBA intervention. Sounds great, but the servers are directly delivered to the end user group before the DBAs have a chance for any follow on configuration. There is also no analysis to determine if the database(s) which require hosting can be placed on an existing asset. As a result, my team is being contacted on servers not performing well, and we don't even have the rights to login to the server, or even the instance.
Ray
April 21, 2014 at 8:54 am
nlion84DBA (4/21/2014)
Our shop is has taken virtualization to almost an extreme. The VMWare team has modified configuration files so they can build a SQL Server from the ground up w/o DBA intervention. Sounds great, but the servers are directly delivered to the end user group before the DBAs have a chance for any follow on configuration. There is also no analysis to determine if the database(s) which require hosting can be placed on an existing asset. As a result, my team is being contacted on servers not performing well, and we don't even have the rights to login to the server, or even the instance.Ray
Certainly some work to do in your shop, but that's actually what I'd like done. Let me (as the DBA) has input into the config files for SQL Server and let instances be built. The nice thing about virtualization is that we can move the VMs across hosts to balance loads as needed, whether that's manual or automatic.
April 21, 2014 at 9:18 am
When installing multiple instances on one virtual or physical machine, are you specifying the maximum memory used for each instance? I have always done that, but there is some disagreement in my organization about best practices. I just like the idea of being able to control my memory usage and allocate it to the most critical database instances.
Beth Albertson
City of Olympia
April 21, 2014 at 9:24 am
Since we have some active / active clusters, I configure my max memory for each instance, so there will be enough reserved memory on a node to at least allow the failed instance to restart on the other node. As a rule, for our standalone VMs, we only install one instance per VM.
-Ray
April 21, 2014 at 10:41 am
In general we have virtualized almost all of our Windows servers except for about 10%. We do have 3 prod SQL Server clusters that are not as busy as some would think or as large as some would think. When it comes time to replace the hardware / upgrade my boss and I are in agreement to create VMs for these. SQL Server wise all of our standalone non-clustered SQL Servers are now virtualized except for one which will will do in the near future.
April 21, 2014 at 11:44 am
Another thing we did at our last company when we consolidated databases on SQL instances is that we (I was part of the networking team) also basically created a DNS CName record for each application's DB.
So App1 had a CName record that pointed to ServerName1 AName record. So if we found a particular DB was causing too much stress on ServerName1, we could move or restore it on ServerName3 and then just edit the App1 CName record to point to the new server. It was an evening or weekend job, but it allowed us to make changes/moves that were invisible to the end user for all intents and purposes.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
April 21, 2014 at 11:49 am
Due to vendor "requirements" all of our systems have their own database installation on a dedicated server. Some of them have multiple instances to save on licensing for test. Other than that we throw away a lot of money on Windows licensing and SQL licensing.
I don't understand how you can easily migrate to a different server. Some of our applications bury the database connection where we can't modify it. In rare instances we could go in and change an ODBC connection, but that requires a downtime.
I would recommend starting with the shared design from day one, which you also recommended at the end of the article. If the server is virtual, more processors and memory can be thrown at it if any performance issues arise. Our VMWare environment is well designed, and we usually have plenty of power on any virtual server.
Dave
April 21, 2014 at 5:17 pm
Heh... this reminds me of hemlines in fashion. They change every other year.
Remember when distributed computing was all the rage? It wasnt' that long ago. Just before that was consolidation. Just before that was distributed computing. Just before that was.... etc, etc, ad infinitum.
Now we even have distrubuted computing with "central management". That's a hemline with a big ol' slit down the legs to make it sexy. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 21, 2014 at 7:24 pm
Jeff Moden (4/21/2014)
Heh... this reminds me of hemlines in fashion. They change every other year.Remember when distributed computing was all the rage? It wasnt' that long ago. Just before that was consolidation. Just before that was distributed computing. Just before that was.... etc, etc, ad infinitum.
Now we even have distrubuted computing with "central management". That's a hemline with a big ol' slit down the legs to make it sexy. 😛
Good thing I wasn't drinking coffee when I read this, because I would have 'distributed' it due to laughing at the last line.
April 22, 2014 at 11:23 am
Jeff Moden (4/21/2014)
Heh... this reminds me of hemlines in fashion. They change every other year.Remember when distributed computing was all the rage? It wasnt' that long ago. Just before that was consolidation. Just before that was distributed computing. Just before that was.... etc, etc, ad infinitum.
Now we even have distrubuted computing with "central management". That's a hemline with a big ol' slit down the legs to make it sexy. 😛
I did some consulting work for a Fortune 500 company in Oak Brook IL. I expressed amazement at all the consultants they were bringing on, only to be told by the director I was speaking to that they do this every 5 years or so. Fire the employees and bring in consultants for a few years. Then fire the consultants to save money and hire a bunch of employees. The director had been with them for decades so I presume they knew what they were talking about. I think that is very common in business, every new VP or CEO feels the need to prove their worth by increasing sales or cutting costs, and usually cutting costs is the easier, although not the best, route.
Dave
April 22, 2014 at 11:23 pm
marcia.j.wilson (4/21/2014)
Jeff Moden (4/21/2014)
Heh... this reminds me of hemlines in fashion. They change every other year.Remember when distributed computing was all the rage? It wasnt' that long ago. Just before that was consolidation. Just before that was distributed computing. Just before that was.... etc, etc, ad infinitum.
Now we even have distrubuted computing with "central management". That's a hemline with a big ol' slit down the legs to make it sexy. 😛
Good thing I wasn't drinking coffee when I read this, because I would have 'distributed' it due to laughing at the last line.
BAWAAA-HAAA!!! Oh you made my day and I did distribute some coffee when I read your response! Thanks for the laugh, Marcia!
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply