May 19, 2015 at 12:00 am
Comments posted to this topic are about the item VMs are not VMs
May 19, 2015 at 6:42 am
In our small environment we have one person that does it all. So he'll be talking to himself about our VMs.
May 19, 2015 at 7:18 am
Iwas Bornready (5/19/2015)
In our small environment we have one person that does it all. So he'll be talking to himself about our VMs.
Yes, in small companies the IT department is often times a one-man show when it comes to anything server related. In large corporations there may be a dozen database admins and a dozen server admins, but the IT department(s) are so compartmentalized and politicized, none of them communicate beyond the subject of sports and cable TV shows while standing in the cafeteria line for lunch.
Medium sized companies are where DevOps works best; and that's where most of the innovation takes place these days IMHO. What's ideal is an IT department where there are enough staff for proper role separation, yet it's small enough that there are cross functional architecture meetings.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 19, 2015 at 7:21 am
I guess simply, not all usage scenarios are the same.
A receptionist will not necessarily need the same computing power as a DBA or developer, for example.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 19, 2015 at 7:25 am
There are also differences between transactional, data warehouse, and machines running cubes. Designing for the load peaks is critical. I was fortunate enough to have a couple server admins that worked through the bumps with me. And when corporate wanted to consolidate, they funded an engagement with Microsoft to outline an architecture. It was rewarding when it came back, as everyone else was expecting very little about the SSAS and Data Warehouse, and a great deal was about how different these workloads were. Something I had been pointing out for a long time. When they looked at the diagrams, it was so similar to what I had worked towards over several years and upgrades, it almost seemed like I paid them for some influence.
It was a great learning experience for both sides, as we had to work together even closer. I had no access to the host machines, which was a whole new layer to troubleshoot when things were slow. One time we tracked what was supposed to be our file server having issues to being it was being used for backups for all the VM's, causing us to have users complain at 6am. Another was when our SSRS reports - data driven, emailed to multiple people, would hang in the middle of a run, only sending out a partial run of a report. That ended up a configuration issue on their end. We had been spreading out the schedule, which helped, but it got worse over time. When the server configuration was fixed, we could send a hundred reports out in a minute with no failures.
So to a great degree, VM's are like trying to run SQL, a data warehouse, and a cube on the same machine. Each piece places different loads and pressures on the hardware, and you need to be able to balance this out. Sometimes a degree of isolation (or resource allotment) is needed to handle the peaks. Just throwing hardware at something rarely works for the long run.
May 19, 2015 at 7:29 am
We are currently in the planning phase to implement a SAN and visualization at our main site and then our DR site. We've hired a consulting company who have sent us some really sharp people and it is going the way the article mentioned in that they are really driving the project and planning things. These guys not only know VMware and storage, they have major experience with SQL Server that is not only related to deploying in a virtual environment, but a lot of experience as system admins.
The planning for most things has been methodical and you could say slow, but we are getting there. The deployment of the database servers as become one of the more complicated matters. The more we talk through things the more our plans change.
Cheers
June 14, 2019 at 5:39 pm
Some people swear by VMs. I am one that swears at VMs. I've been burned too many times by VMs.
June 14, 2019 at 5:57 pm
This is why so many folks are moving their databases to Azure. Instead of debating about VMs, Cores, and storage controllers, it's simply setting the right DTUs (database transfer units) and RUs (request units per second) that work for your current workloads, and then from there you can scale up, down, and out as needed.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 18, 2019 at 4:52 pm
If the VM isn't working for your workload, either you're a) extreme, or b) improperly set up.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply