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 ModelV240 CPU - 2 core
Memory8192 Mb CPU CU25% of 1 CPU core Memory CU1024 Mb Swap CU1/8 of total Sun ModelV490 CPU - 8 core
Memory32768 Mb CPU CU25% of 1 CPU core Memory CU1024 Mb Swap CU1/32 of total Sun ModelT2000 CPU - 8 core
- 32 threads
Memory32640 Mb CPU CU4x thread Memory CU4096 Mb Swap CU1/8 of total Sun ModelT5220 CPU - 8 core
- 64 threads
Memory32640 Mb CPU CU8x thread Memory CU4096 Mb Swap 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).
- Unix team will provide a test environment: