Voice of the DBA

Tag: virtualization

  • Confidential VMs

    Ever since we started to offload workloads to hardware that we didn’t physically control, there have been security concerns. I remember when this started with application service providers and web workloads. This has continued to be an issue as more and more types of workloads have moved to cloud vendors and other hosting providers.

    Google is trying to ameliorate some of the concerns by offering customers confidential VMs. These are special types of VMs, using encryption and hardware capabilities to protect the workloads from any unauthorized access. I don’t know to what extent this practically protects a workload compared to a non-confidential VM, as the details are a bit confusing. I’m sure there is some extra protection, but the weak point in most cases here is still likely the humans that use credentials to access the VM. I’d suspect a determined attacker would try to hack the sysadmin and their laptop rather than the VM itself.

    In any case, Google is trying to ensure the added encryption doesn’t cause any workload degradation. Hardware can likely help her, but I’m not sure that you can perform encryption and decryption without using more resources. There might be minimal impact, but there has to be some resource impact. At least compared to a non-confidential VM.

    I’m glad there is research and work still happening to find ways to improve security for systems that we might no longer control. I think that’s increasingly the trend. Whether you go with a cloud vendor like AWS, Azure, GCP, etc., or you look to host with a Rackspace like provider, more and more of our infrastructure is being outsourced, and I don’t know that the trend will reverse itself anytime soon. Even if it does, the more we can provide security hurdles against unauthorized access, the better.

    Steve Jones
    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: How Virtualized?

    Last day at the MVP Summit, so enjoy this today: How Virtualized?

  • Virtual Failback

    I saw a very interesting tweet from Scott Stauffer asking this: “… looking for quick’n’easy way to make workload virtual w/ fail-fast method to physical if performance doesn’t meet expectation.” This was part of a conversation Scott was having in looking to move to a virtual environment from his current physical one. That’s something I think more and more people are being asked to do, whether they do in inside of their own data center, or they move to some type of hosted or cloud environment. There is increasing pressure from management to consider using cloud-type environments to reduce the capital expenditures for new systems and move to an operating cost model.

    I don’t have a fundamental problem with cloud environments, though I think it is important to carefully consider the pros and cons, but I can certainly appreciate Scott’s concern. No matter how well we architect things or prepare for the movement of a physical environment to a virtual one, there could be problems. Having a fall back plan becomes important, and even more important if we discover problems when some time has passed.

    While there are utilities that can move a physical machine to a virtual environment, there aren’t any (or any I know of) to reverse the process. Honestly, though, I think virtualization has so many advantages, that if I really had performance issues and needed to return to a physical host, I’d continue to virtualize my instance, but I’d have only one VM on my physical host, with access to almost all the resources on the hardware. Today’s hypervisors have so little overhead, I wouldn’t hesitate to run one virtual machine on a host.

    Ultimately, moving to a virtual environment is very much like moving to new hardware. There are definitely different configuration options you may need to set, but you can contract for some help with configuring your system. In the worst case, just use a single VM on a host, get hardware abstraction, and manage the machine like any other. Just don’t forget to have the hypervisor and your guest start up automatically after a reboot.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • VMs are not VMs

    I was at VMWare recently. One of the main things that all of the SQL Server professionals that were there tried to emphasize is that SQL Server workloads are not like other workloads. The impact on the various host resources, the stress on the storage systems, these are fundamentally different in a database server. The loads tend to be higher, but not always, however the tolerance for delays tends to be lower than for many other types of applications.

    This becomes an issue if you work in an organization that doesn’t understand the challenges of database systems. It’s entirely possible that your virtualization administators, or your storage administrators don’t recognize that the SQL Server might need more resources. Or they don’t believe the impact is greater for the organization. To be fair, that might be true, but someone other than the DBA or system administrator should decide if the database is more important than the file server and should be treated differently from an infrastructure perspective.

    No matter what level of resources your database server need, it’s not going to run like other systems. Typically this means that the density of VMs has to change when a database server is involved. As an example, I know of a system that typically has a 10:1 guest:host ratio for most of their server systems. However for SQL Servers it’s 4:1 or lower. The same is true for storage. Aggregate bandwidth doesn’t always reflect the ability of a storage system to keep up with database requests. It becomes important that both you and your storage administrators learn to speak the same language and understand what requirements exist for SQL Server VMs.

    Virtualization really starts to highlight the advantages of a DevOps environment. DBAs and developers should work closely with the virtualization and storage administrators to learn what each others’ requirements are and how each of us can help the other perform their particular job at a higher level. Infrastructure staff can help prepare standard environments and ensure production looks like staging. Developers and DBAs can help a vSphere admin learn a little PowerCLI and programming. That might get them to be more cognizant of the particular requirements of your SQL Server and be more willing to work with you.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn.