The End of Estimation

  • Comments posted to this topic are about the item The End of Estimation

  • On a far smaller scale, this is what we also do. As our hosting is outsourced, it also saves money directly as we have fewer physical machines to pay for, and it saves power too (though we don't see this saving directly). There are also great options for moving VMs between physical machines in the farm, business continuity, etc.

    The difficult bits are:

    - Application vendors who won't warrant that their apps will be happy on VMs

    - Buying the big machines you need in the first place swallows a lot of budget and may take you into territories that your infrastructure team are new to (eg SAN management)

    - The world and his wife will want to get a VM for everything - we have VM PCs, SQL servers, file servers, Exchange.... so a successful roll out seems to need more physical hardware annually.

    But my experience is that it's well worth it. Get your infrastructure people trained in the necessary hardware and software first though...

  • I must admit that until a few months ago, I hadn't considered how virtualization worked and had sort of assumed it was similar to emulation (like running old PDP-11 software on an X86) except the emulated machine was the same as the host machine. Hence I thought there must be trade-offs.

    Having watched the whole of Eric Traut's talk ?http://www.acm.uiuc.edu/conference/2007/video/UIUC-ACM-RP07-Traut.wmv%5B/url%5D I now understand that, most of the time, software on the VM is actually running on the host. So virtualization is mostly about containment and better use of resources.

    What this means is that to run an 8x32 VM, you must already have an 8x32 (or probably much better) host. In fact, Virtual PC and Virtual Server won't start a VM unless they can allocate it all it's requested physical memory. I haven't tried, but I assume it won't let a VM start with more CPUs that physically exist.

    The upshot is that if you want to run SQLserver (or anything else) on an 8x32 VM (or whatever) then you already need to have justified and purchased a physical 8x32 (or more likely 8x40+ ?) server. The only advantage you get is that you can balance resource usage - you can run the 2x4 development server, the 2x4 QA server and the 2x4 production server all on one 4x8 hardware box (although you probably wouldn't put all your eggs in one basket!).

    So you still have to argue the case for getting budget for the 8x32 box, it's just that you have extra arguments to use for getting it, and once you have it you can look at how heavily used it is and make better use of it's capacity without having various implementations interfere with each other. As you say, you can start with a 2x2 running on 4x8 hardware and 'upgrade' to 2x4 just by rebooting!

    Of course, the other great use for VMs is testing. I've already tested some of our production databases on Katmai (SS2K8) without needing dedicate another test machine to it and will be much better able to justify upgrades because I'll already have benchmarks to show how the new features improve performance.

    Derek.

    Derek

  • PolyServe


    Kindest Regards,

    scoinva

  • scoinva (1/24/2008)


    PolyServe

    Can you elaborate?

    A quick glance at info on the polyServe database utilitity would indicate that it's used to ease relocation of SQL instances between physical servers. VMs can be moved between different hardware and the instance isn't even aware of the change, so I'd say VMs are the better solution.

    Or have I missed something?

    Derek.

    Derek

  • I belive this is a natural step for many but I'm not sure if the step is ready.

    What effects on performence does it have? How much does the VM decrease the effectivity of the sytems with?

  • There is an inherent IO load on a virtual machine. This is perfectly OK for smaller databases to medium sized database & DBs most database in a development environment. For large databases this starts to become a problem. PolyServe gives the ability to move around databases in a database farm very similar to VMotion. Admittedly there is a few seconds of downtime unlike VMware ESX. You get the administration cost savings of virtualization without the IO, memory, and processor overhead you get with ESX. You can also schedule a database to move to a different server based needs of the business. PolyServe can also failover if the server "dies" similar to Windows Cluster but much easier to manage.

    I predict much of what PolyServe does gets rolled into a future version of Windows and SQL.

    Disclaim: Parts or all of the information maybe incorrect. 🙂


    Kindest Regards,

    scoinva

  • As most people have already mentioned, until a year ago, I was very suspect in terms of using virtualization due to the required mental change from physical thinking to a software based "thinking", although the underlaying VM infrastructure is hardware based.

    After working on a number of projects, where the technical architechture was designed around VM machines and delving deeply into the "inner workings" of this technology, the benefits became very clear. Being able to consolidate a number of separate SQL Server builds into a centralized and more powerful piece of hardware and have resources on-tap as and when needed was awesome. More importantly, the cost and power savings became a real driver and started to re-direct my thinking in terms of infrastructure simplicity, although I still have a worry about single point of failure due to the centralized nature of virtualization.

    In addition, virtualization does not take away the mundane issues such as licensing, patching etc.., as these still exists in the virtual world.

    Overall, virtualization looks very promising.

  • As every CIO gets hyped up about virtualization and reducing TCO, lets not forget that a certain degree of virtualization is built into the product already, read: Instances.

    While you don't get the same degree of separation, you don't always need it either, and adding an instance to an Enterprise SQL Server doesn't cost you more money for licenses for MS SQL and some other related products. (Such as LiteSpeed) Sure, that doesn't mean you can hot-add 2 GB of RAM but how many people really would have much for unallocated hardware resources? No employer I've ever had would, we'd allocate it even if it wasn't needed. Even with instances you could deallocate CPUs and RAM from one to another.

    I've looked at Polyserve, even had HP come in and spend time here, they agreed they couldn't do much to consolidate our envionrment. If you do a lot of Client Server stuff on a database during the day and then batch processing at night there aren't many spare cycles.

    I'm not looking into the MS virtualation technologies, they look wonderfull for web and app servers but I'm just not sold that they make sense for us for db servers.

    Just my .02.

    Chris.

    Chris.

  • Virtualization (VMWare) with blade center has been a very good move for us. Scalability, flexability, cost-effective, redundancy - all the things we DBAs look for in a server. Take that across all applications, not just databases, and everyone gets what they want (except the hardware vendors).

    One benefit we've had to take advantage of is VMotion, moving across blades as CPU demands change or as hardware problems demand. This has saved us downtime when a blade goes bad.

    I agree with Bill on vendors not guaranteeing their apps for virtualization. Even the vendor that helped us with all the virtualization hardware, software, and data center hosting is pushing back, repeatedly stating that apps like SQL, Exchange, AD, etc don't work best on virtual (mainly because of performance). What we are really getting is uninformed people, where some of the vendor's staff is a believer, and the rest aren't convinced, and we get different responses depending on who we're talking to that day. We've just had to take a hard stance and flatly state our corporate position that virtualization is here to stay and we design solutions to take advantage of what it offers.

    Once really great feature of virtualization is being able to copy an image. Upside: I've never had a test server up so fast. Downside: I could easily suck the system down with all the reasons I can dream up for yet another test server. 🙂

    It also helps with DR testing - no worry about hardware compatability and what hardware is on hand.

  • The main thing that scares me about virtualization (and an issue I am still fighting today) is that while it can work incredibly well in organizations that put a lot of spare horsepower behind the the VM's to allow for said upgrades, it can and will go horribly wrong if you DON't put enough horsepowee out there to be shared. If you have a technically-challenged and financially aware (we call that a CIO model "ID ten T"), then they tend to miss the part about having the hardware behind the virtual server to actually DO the work. They just hear "you can run 8 servers virtually against only one piece of hardware". Which of course is true (sort of), but the piece of hardware you end up with is a PIECE of hardware, much bigger than any one of the individual servers you might be replacing.

    It's like SAN's - if you don't change the entire paradigm as to the concept of "ownership of resources", you will end up with a system worse than you had previously. You also need a whole new layer of folks out there to keep an eye on performance, and who can make the right determination as to when a given instance needs more "juice".

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • I like many am not a huge advocate of Virtualization in my worlds. Part of that is due to my ignorance which I work to eliminate. Everyone says small\medium SQL databases work well on a well designed VM. What are you clasifying as small\med. How many users? what is the amount of data change? What is the environment? Maybe I just miss classify my systems when I think they are large. The large ones i think of as my 500+ GB customers which add upwards of 5GB per month however are running intense research all the time. The database is handling thousands of queries per minute. If someone can prove to me that Virtualization can handle this i would be thrilled. We typically span the db on 4 seperate disk sets to isolate IO and to allow us to ensure performance to a higher degree. Our larger environments are reaching 1.5-2TB databases.

    I had one customer which implemented Virtualization without our knowledge. They were a small customer (<150GB) and they were corrupting their db daily which everythign i could find was leading to their vm environment.

    Again my ignorance and inability to get budget dollars to really test this well lead to my personal push back against this. I look forward to the future and improvements and training which will allow me to pursue the vm side of the house more. I see it as a great use for so many other uses and would like to see us leverage it on a high end SQL Server side.

  • I think the important thing to remember with VMs is that they're not the end-all be all, and implementing VMs doesn't mean implementing them for all servers. If you have heavily loaded servers, you probably would leave them on a server.

    You also don't save money on licensing, in fact, it's worse than instances on Enterprise. You need to license each instance.

    However, when I have managed multiple servers, I've often found that most of them sat at 10% CPU all day. Only a few were really busy, or really critical. those I'd never move, but having the ability to consolidate some less busy SQL Servers, maybe with a DC or other low use server on VMs, makes some sense.

    Where I have seen VM issues is where you buy 1 4x4 and put 3 servers on it. It goes down, you have issues. Or you overload it with VMs. I'd recommend highly that you not go with VMs without a SAN (to manage IO loads) and without multiple servers, preferebly blades, and make sure you can move VMs from blade to blade to balance the loads.

    I have definitely liked the idea of balancing QA instances with production in VMs and being able to shut down QA or development for a period if we need more resources. However that has to fit your environment and everyone has to understand the implications here.

  • For us, virtualization looks like it has some good advantages. The thing that we need the most is to recover space in our racks! Our server room is kinda crowded, and we could easily combine 5 physical boxes of 11 instances total and free up space and heat/energy/UPS reserves. And the ability to instantly bring up a test machine is extremely appealing.

    Granted, we could also get a big non-blade box and combine the servers, but we lose out on instant test machines. The virtual environment also makes it easier to test patches -- clone one VM, test on the clone.

    I looked at Polyserve and, while it is an impressive product, I don't think it is appropriate to our needs. And I've had to put HP.Com on my spammer list! The so-and-so's don't honor unsubscribes!

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Steve Jones - Editor (1/24/2008)


    You also don't save money on licensing, in fact, it's worse than instances on Enterprise. You need to license each instance.

    Per SQL Server's "How to license".

    For enterprise edition there is an added option : if all processors in a machine have been licensed, then the customer may run unlimited instances of SQL server 2005 on an unlimited number of virtual operating environments on that same machine.

    So - as long as you pay for an enterprise processor license for all PHYSICAL processors, you don't have to worry about the separate instances.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic. Login to reply