4th Floor, 4 Tabernacle Street London EC2A 4LU

Solaris Zones

  • 1 Overview
  • 2 Considerations before choosing zones
  • 3 Resource Management
  • 4 Configuration

    Overview

    Solaris Zones are being introduced as an alternative on servers that do not support LDOMs.

    Whilst zone’s can be used on T series servers, this is not the recommended option.

    Global Zone – overview

    The global zone is essentially the management zone, from which all non-global zones can be installed, managed or uninstalled.

    From this zone you monitor performance/resource utilisation of the chassis.

    Access to this zone is restricted to core support teams only.

    Non-Global Zone – overview

    These zones contain an installed subset of the Solaris operating system packages. They are assigned a zone ID by the global zone.

    These zones share operation under the Solaris Kernel booted from the global zone. These zones are not aware that any other zones exist. And they cannot install, manage or uninstall themselves or other zones. The FIL offering use the whole root zones, not ‘sparse.

    These are the customer facing zones.

    Considerations before choosing zones

    When should I consider using zones?

    So for what types of environment should zones be considered?

    Typical application environments that fall into this profile are small app servers or management servers.

    Typical application environments that do not suit this model are Oracle, Sybase and DB2, where I/O is performance is key and CPU/memory requirements high.

    As each zone shares the I/O capabilities of the chassis, you should not put I/O intensive applications within a zone.

    With CPU, memory and virtual memory capping, each zone is safe guarded to ensure it has an achievable maximum resource allocation/limit.

    Can Solaris 8 be provided in a zone?

    Solaris 8 is under vintage support with Sun currently, as it reached EOSL. FIL’s current fully supported offering is Solaris 10.

    Sun/Oracle provide some tools to help prove compatibility, we will help provide an environment for a team to test on (if hardware is available). High level steps involved are:

    • Unix team will provide a test environment:
      • Set-up a test Solaris 10 instance (zone, LDOM or physical).
      • Install (/restore) the application files/environment on this new instance.
    • Application team test their environment:
      • Standard in-house UAT testing.
      • Use of Sun/Oracle scripts for proving compatibility:
        • Test the application conforms to the Solaris Application Binary Interface using appcert
        • Test the system calls made by the application using apptrace

    If these test’s prove their are problems running under Solaris 10, then as an exception we will explore the option of a short term deployment (3-6 months) of Solaris 8 while the application is reworked for Solaris 10. For zones this would be acheived by supplying a branded Solaris 8 zone.

    Resource Management

    To allow for the most flexibility when deploying zones onto V series Sun servers, resourcing capping was choosen over dedicated allocation. This still allows us to limit a zone’s maximum potential use of system resources such as CPU, physical memory and virtual memory.

    The global zone manages these limits for the non-global zones, essentially using features from Solaris Resource Manager that is native in Solaris 10.

    CPU capping

    CPU capping was the only method that allowed a percentage of a CPU core being assigned. On V series Sun servers this was critical to allow the most flexibility when dividing up the available resources on a server.

    For V series units of 25% of one core allows for optimum use of the V240/V490 servers. For T series the CPU is capped based on threads per core, so in this case the capping is done by core (T2xxx = 4 threads, T5xxx = 8 threads).

    Memory capping

    Based on the CPU allocated to a given non-global zone, it limited to an equivilent percentage of the system’s overall physical and virtual memory.

    Process capping

    Each non-global zone has a LWP (light weight process) limit applied to ensure it doesn’t run more processes than the system can cope with.

    Global Zone Capping

    The global zone is not capped resource wise intentionally, to ensure it has enough resource to manage the non-global zones.

    However, a percentage of the systems resources are reserved, so cannot be allocated to a non-global zone, to provide head room for this purpose.

    Configuration

    This section covers the configuration components for Zones.

    Supported Hardware

    The Sun V series is the preferred platform for zone deployment. However, the Sun T series will run zones.

    Note, the CPU CU, Memory CU and Swap CU fields relate to the definition of a capacity unit for the given hardware configuration.

    Supported Sun Models
    Sun ModelV240CPU

    • 2 core
    Memory8192 MbCPU CU25% of 1 CPU coreMemory CU1024 MbSwap CU1/8 of total
    Sun ModelV490CPU

    • 8 core
    Memory32768 MbCPU CU25% of 1 CPU coreMemory CU1024 MbSwap CU1/32 of total
    Sun ModelT2000CPU

    • 8 core
    • 32 threads
    Memory32640 MbCPU CU4x threadMemory CU4096 MbSwap CU1/8 of total
    Sun ModelT5220CPU

    • 8 core
    • 64 threads
    Memory32640 MbCPU CU8x threadMemory CU4096 MbSwap CU1/8 of total
    For further information please contact FIL – Unix Servers.

    Note, for Sun v240 and v490 hardware we recommend the minimum zone configuration is 2 capacity units (eg 0.5 CPU / 2GB RAM).