You can always count on Rave to be your trusted advisor for the latest in technology trends, tips, and tools. Each quarter, we'll give you bits and bytes of useful information including new product notes, drivers/patches, troubleshooting tips, solutions for software issues and more.
This week's tip is about the different Virtualization technologies in Solaris as developed on Sun Sparc hardware.
Years ago, in the land of dinosaurs, everyone stuck everything on a few large systems. Later, people used cheap hardware based on x86 systems and replaced the big iron. The problem is, people couldn't scale the apps beyond the confines of the box, so it ended up with server sprawl where you had dozens of vendors, no real remote management, operating systems all over the place and lots of hardware that was provisioned to run for a certain type of load that may have not fully utilized the resources on that system. Somewhere along the way, someone decided that you could stick multiple operating systems and applications on a single piece of physical hardware and you ended up increasing the utilization of the underlying hardware. This translated to lower cost because you needed fewer resources to run the system (cooling, power, and people).
Now, people are deploying more and more virtual systems as a way to deploy a service instead of deploying systems.
There are different virtualization technologies. Some do it through hardware partitioning, others do it with virtual machines (such as xen and VMware), and even others do it with OS virtualization (Solaris 10 zones/containers, FreeBSD jails).
The benefits of virtualization and partitioning are (each of these virtualization technologies operates at a different layer in the stack) for example:
- Application virtualization Containers (creates the illusion for applications that they're in their own dedicated OS)
- Virtual Machines (creates the illusion that each OS runs on its own dedicated hardware) Logical domains
- Hardware partitioning (creates secure, electrically isolated domains within a single server) Hardware domains
As you move up the stack, you trend towards flexibility of physical resources, where as you move down the stack, you trend towards being able to isolate the application in a way that prevents other applications from affecting it.
With logical domains (LDoms), Sun creates a virtualization layer is created (a hypervisor) in firmware that virtualizes the hardware and creates a control domain that allows you to manage guest domains. The control domain sees the physical hardware. The guest domains do not see the physical hardware. In the control domain, you create a hardware "service" that lets the logical domain see the physical hardware through a virtual interface. With Sun's sun4v architecture, they've been able to treat the logical domains as sun4u and be able to run older operating systems (or even non-Solaris ones) under the control domain. LDoms are supported on the T1000/T2000/T5120/T5240, etc (T1/T2 based SPARC's).
Within an LDom, each guest domain appears as a real physical machine, all the way down to the {ok} prompt. You can do everything you would do with a real machine.
You can have up to 32 LDoms per server (on a T1 series cpu). Ideally you would not run services in the control domain. That's there to support the domains, and that's it. You should be able to do transferring of domains like xen from system to system in the future. It's not there yet (you have to shut the domain down right now, transfer it, and then bring it back up).
VMware implements a virtualization system in software. You run it as a software application on top of hardware and it creates an idealized environment (a set of simple interfaces for cpu, memory, nic,, disk, etc) that it then translates into the underlying hardware. This gives you flexibility because you've encapsulated your entire virtual machine into a format that can be run almost anywhere. The downside is that it will only run on platforms where the virtualization layer has been written for that platform. This virtualization comes at a cost because there's a big enough overhead in the virtualization layer, that you have to pay attention to how many systems you're provisioning on the hardware. The idealized interface creates a set of standard virtual hardware interfaces into the system that you can deal with in your OS.
VMotion is VMware's live vm migration tool. The caveats are that you have to use the same cpu type and stepping, you must have shared storage to make your images available to all physical systems that will be transferring images between. Additionally, this allows you to create a high availability environment where VMware transfers your images back and forth when a hardware error is detected.
Xen implements a virtualization layer that is more similar to LDoms than it is to VMware. Xen implements it's hypervisor in software though. With Xen, though, all your operating systems have to be aware that there's a hypervisor in place to interface with the hardware. Since the OSes are aware of the hypervisor, you get more performance out of it because you're not doing the instruction scanning that VMware does.
You can get virtualization technology for Solaris in the Opensolaris community release.
Paravirtualization enables high performance. Can support up to 100 active vm's on a single modern system. Live migration of domains. Checkpoint/restart and live migration (suspend your OS, move it, and have it continue where it left off).
Para vs Fully virtualization: Full virtualization is like VMware. You're emulating the entire system in a virtual machine. In para virtualization, you're creating a method for the OS to get to the underlying hardware in a virtual manner.
The Solaris Zones feature is based on the same basic concepts as FreeBSD Jails. In both FreeBSD Jails and Solaris Zones, each virtual view of the runtime environment is completely segregated, and processes from one environment cannot send signals to or even see processes in another. Both Jails and Zones share only one instance of the operating system, though, so multiple runtime environments can coexist on a machine with only one CPU.
Keep in mind that Solaris Containers or zones can be run in any instance of Solaris 10, whether already in a virtualized environment or not. This includes on bare metal, in a Dynamic System Domain, in an LDom, in a Xen domain, in an xVM server domain, in a VirtualBox instance, in a Parallels, in a VMware guest, and so on.
Solaris Zones: virtualized operating system environments, each looking like a Solaris instance. This is like FreeBSD jails. From within the global zone, it all looks like it's running in the global zone. From within the zone, you cannot see outside of it, so you can't see what else is going on outside that zone. Since there are no hardware changes or requirements, you can run thousands of zones on a single global zone instance (up to 140,000 on an F25k). With zones, you're sharing the global hardware resources and there really isn't any sort of segregation of hardware like in LDoms or Containers. With Containers, you can assign dedicated hardware to that container. Within a zone, there's a limited set of privileges. Certain system calls are forbidden inside a zone/container.
Two types of zones exist: global and non-global. A machine with the Solaris Zones feature enabled has one global zone and up to 8191 non-global zones. The maximum number of zones that a machine supports is dependent on the hardware resources available to the machine. Each zone has an ID assigned by the system when it's booted with the global zone, always listed as zone ID 0. Only the global zone contains a bootable Solaris kernel and is aware of all devices, file systems, and other zones. The global zone is also the only zone from which non-global zone configuration, installation, and management are possible.
Non-global zones contain a subset of the Solaris OS installed in the global zone and possibly additional packages not installed in the global zone. Each non-global zone has its own package database listing each software package installed relative to the zone and does not share package information with the global or other non-global zones. Non-global zones also contain localized configuration information and other zone-specific files and directories.
LDoms allow you to assign your hardware to different virtual hosts for exclusive use. Say you have a T5220 with an 8-core CPU. You could create 8 LDoms and assign a core to each. Each core will be for the exclusive use of the domain you assigned it to, regardless of the load on the other domains. With zones/containers, all zones can use any CPU core/thread that they need when they need it. Limits can be set as far as how much CPU they use, but you cannot specify which CPU/core/thread they are to use.
With LDoms you get an OBP per domain that can be configured independently from the others. Zones don't have OBPs.
Each zone can be separately administered and each zone can run an independent set of applications.
Zones allow one or more processes to run in isolation from other activity on the system. Processes running in a given zone cannot monitor or affect processes running in other zones.
Solaris 8 and Solaris 9 Containers work by utilizing the Branded Zones (BrandZ)
BrandZ provides the framework to create non-global zones that contain non-native operating environments.
Security - Network services can be run in a zone, limiting the potential damage in the event of a security violation. No process running within a zone, even one with super-user/administrator credentials, is allowed to affect activity in other zones. Certain activities, such as rebooting or shutting down the system as a whole, will only be permitted in the global zone. An administrator logged into the global zone can monitor the activity of applications running in other zones and control the system as a whole. The global, or default, zone will always exist.
Isolation - Zones allow the deployment of multiple applications on the same machine, even if the applications operate in different trust domains, require exclusive use of a global resource, or present difficulties with global configurations. Individual zones can have their own set of users and their own root password and when rebooted, any other zones running on the system are unaffected.
Virtualization - Zones provide a virtualized environment that can hide details such as physical devices and the system's primary IP address and host name from the application. This can be useful in supporting rapid deployment and redeployment of applications since the same environment can be maintained on different physical machines.
Granularity - Zones can provide isolation at almost arbitrary granularity. A zone does not require a dedicated CPU, physical device, or chunk of physical memory. These resources can either be multiplexed across a number of zones running within a single system, or allocated on a per-zone basis using resource management features available in the operating system.
Transparency - Zones avoid changing the environment in which applications execute except when necessary to achieve the goals of security and isolation. Zones do not present a new API or ABI to which applications must be ported. Instead, they provide the standard Solaris interfaces and application environment, with some restrictions that affect applications attempting to perform privileged operations.
© 2011 Rave Computer Association, Inc. All rights reserved.
Home | Contact | Privacy Policy | Site Map
