Let’s think of a physical Solaris server with 2 CPUs which needs to host:
- One Database server - one that needs a fully dedicated CPU and
- Two Web servers -one that is more flexible and can share CPUs.
To accomplish these different levels of isolation we use a Solaris Container technology called Dynamic Resource Pools that enables CPU resources to be dedicated to specific applications. In this example, the database server needs a separate resource pool, while the Web servers can share another.
Login to the Global zone as super user and activate the resource pool facility:
#pooladm –e
Check the current status of resource pools using:
#pooladm
Save the current configuration to the default file (/etc/pooladm.conf) using:
#pooladm –s
Check the number of processors available to the system:
#psrinfo
Create a processor set containing one CPU:
#poolcfg –c ‘create pset db-pset (uint pset.min=1; uint pset.max=1)’
Update the configuration:
#pooladm –c
Check the configuration:
#pooladm
Create a pool for Database zone:
#poolcfg –c ‘cerate pool dbpool’
Link the pool with processor set:
#poolcfg –c ‘associate pool dbpool (pset db-pset)’
Commit the change:
#pooladm –c
Check the configuration:
#pooladm
***************************************************
Set the pool while creating the non-global zone for Database or to an existing zone by:
zonecfg:dbzone>set pool=dbpool
zonecfg:dbzone>verify
Now if you set the default pool for other 2 web server zones, they are going to use the default pool associated with default processor set with 1 CPU, while Database zone will start using another CPU dedicatedly using processor set “db-pset”.
zonecfg:webzone1>set pool= pool_default
zonecfg:webzone2>set pool= pool_default
Check the same by trying to disable any of the processor using;
#psradm –f [0,1]
Fair Share Scheduler:
While the two Web servers are capable of sharing the remaining CPUs on the system, they each need a minimum guarantee of CPU resources that will be available to them. This is made possible by another Solaris Container technology called the Fair Share Scheduler (FSS). This technology enables CPU resources to be allocated proportionally to applications. That is, each application gets assigned a number of the available “shares” of the total CPU.
Enable FSS for pool-default:
#poolcfg -c 'modify pool pool_default (string pool.scheduler="FSS")'
Commit:
#pooladm –c
Move all the processes in the default pool and its associated zones under the FSS.
Either by rebooting the system or by using:
#priocntl -s -c FSS -i class TS
#priocntl -s -c FSS -i pid 1
(valid classes are RT for real-time, TS for time-sharing, IA for inter-active, FSS for fair-share, or FX for Fixed-Priority)
Remember, the two Web servers share the CPU resources of the default pool with each other as well as the global zone, so you need to specify how those resources should be shared using the Fair Share Scheduler (FSS).
With FSS, the relative importance of applications is expressed by allocating CPU resources based on shares—a portion of the system's CPU resources assigned to an application. The larger the number of shares assigned to an application, the more CPU resources it receives from the FSS software relative to other applications. The number of shares an application receives is not absolute – important thing is how many shares it has relative to other applications, and whether they will compete with it for CPU resources. That is how it is being dynamic.
Assign three shares to the first web server container (more priority):
zonecfg:Web-zone1> add rctl
zonecfg:Web-zone1:rctl> set name=zone.cpu-shares
zonecfg:Web-zone1:rctl> add value (priv=privileged,limit=3,action=none)
zonecfg:Web-zone1:rctl> end
zonecfg:Web-zone1> exit
Assign two shares to the second web server container (less priority):
zonecfg:Web-zone2> add rctl
zonecfg:Web-zone2:rctl> set name=zone.cpu-shares
zonecfg:Web-zone2:rctl> add value (priv=privileged,limit=2,action=none)
zonecfg:Web-zone2:rctl> end
zonecfg:Web-zone2> exit
You now have 3 containers created; one with a fixed amount of CPU, and two dynamically sharing CPU with the global zone.
Now the DB server will run on its own guaranteed CPU, protected from the other applications on this system, while the Web servers share the remaining 1 CPU. To clarify the FSS share usage, the first Web server application has three out of the total six shares (3 – web-zone1, 2 – webzone2, 1 – global zone), entitling it to 0.5 CPU worth of the 1 CPU (1*3/6=0.5); the second (web-zone2) has two of the six shares, giving it 0.33 CPUs worth; and the global zone gets the remaining one of six shares – that is 0.17 CPU worth.
Just to comment, Oracle (when you involve Oracle DB like this setup) acknowledges these types of Solaris Containers as a valid license boundary. In their terminology they are known as Capped Containers, and are made by a combination of Dynamic Resource Pools and Solaris Zones - where the amount of CPUs in the pool determines the size of the license. So you need to consider the same when using this technology with Oracle Database server or any other oracle product.
