Oracle Solaris 11 in the Cloud
by Duncan Hardie and Pavel Anni
Published November 2013
Hands-On Labs of the System Admin and Developer Community of OTN
This lab demonstrates how Oracle Solaris can provide the best cloud environment by setting up a multilayer application environment, effectively creating a "cloud in a box."
Table of Contents
Lab Introduction
Within cloud environments, multiple considerations and functionality are key to building a successful cloud. These can be grouped into five main areas:
- Rapid deployment
- Flexibility
- Availability
- Security
- Monitoring
To demonstrate how Oracle Solaris can provide the best cloud environment, this lab will describe how to set up a multilayer application environment. The lab will effectively create a cloud in a box, along the way touching on each of the main areas.
The final environment will consist of a WordPress blog contained within an Oracle Solaris Zone. The application environment will be supported by a web server and a database.
During this lab, you will learn how Oracle Solaris 11 places cloud at its core, integrating the cloud with key Oracle Solaris 11 features.
Prerequisites
You should have the following:
- A basic familiarity with Oracle Solaris administration operations
- A basic understanding of virtual environments
The Environment
You will be working on an Oracle Solaris 11 instance contained within an Oracle VM VirtualBox environment. You can treat the Oracle Solaris 11 instance as a bare-metal installation as far as the lab is concerned.
- User:
ouser - Password:
Oracle123 - Root password:
solaris11
Lab Outline
Table 1. Description of Exercises| Exercise | Name | Topics Covered |
|---|---|---|
| 1 | Configuring the System and Setting Up the Network |
|
| 2 | Configuring the Storage Layer |
|
| 3 | Configuring the Web Layer |
|
| 4 | Configuring the Database Layer |
|
| 5 | Configuring the Application Layer | Configure and install the WordPress blog application. |
| 6 | Monitoring Zones | Monitor system activity using ps, prstat, and zonestat. |
| 7 | Performing Resource Management |
|
| 8 | Ensuring Availability |
|
| 9 | Securing the Environment | Create and test an immutable zone. |
Lab Goals
At the end of the lab, you will have created two zones: one from a standard installation and one via cloning. You will have configured the network and added applications to those zones giving you your own blog, which has a three-tier environment consisting of application, middleware, and database.
At the end of the lab, your configuration should look something like Figure 1.
Figure 1. Layout of your finished environment.
Note: When this lab refers to the "global zone," it is referring to the default zone for the system, which is also used for system-wide administrative control.
Now that we understand what we are trying to do, in the exercises, we will go through the steps, including command-line examples, for exactly how to achieve our goals.
While going through this lab, refer to Figure 2 for a quick reminder of the settings we will use.
Figure 2. Cheat sheet of settings.
Exercise 1: Configuring the System and Setting Up the Network
In this portion of the lab, we will look at the settings on the system so you can see the differences as you progress though the lab.
First, let's look at how the system is currently configured.
Log in to your system:
user: ouser
password: Oracle123
Q: Why did we log in as ouser and not root? |
A: Because in Oracle Solaris 11, root is now what we call a "role" and is no longer a user. |
Open up a terminal window. For the rest of the lab, it will be useful to be root, so let's do that now:
ouser@solaris:~$ su -
Password: solaris11
Oracle Corporation SunOS 5.11 11.1 September 2012
root@solaris:~#
Let's start by checking how the ZFS file system is set up:
root@solaris:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 15.3G 13.0G 4.90M /rpool
rpool/ROOT 4.17G 13.0G 31K legacy
rpool/ROOT/solaris 4.17G 13.0G 3.79G /
rpool/ROOT/solaris/var 284M 13.0G 220M /var
rpool/VARSHARE 54K 13.0G 54K /var/share
rpool/dump 1.03G 13.1G 1.00G -
rpool/export 5.19M 13.0G 32K /export
rpool/export/home 5.16M 13.0G 32K /export/home
rpool/export/home/ouser 5.13M 13.0G 5.13M /export/home/ouser
rpool/repository 9.02G 13.0G 9.02G /repository
rpool/swap 1.03G 13.1G 1.00G -
Make a note of what file systems are present; you will need this information later.
Next, let's look at the network. There are some new commands in Oracle Solaris 11 that you will become very familiar with: ipadm and dladm.
ipadm let's you look at the IP stack, as shown in Listing 1. Let's see what interfaces and IP addresses we have:
root@solaris:~# ipadm show-if
IFNAME CLASS STATE ACTIVE OVER
lo0 loopback ok yes --
net0 ip ok yes --
root@solaris:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.1.222/24
lo0/v6 static ok ::1/128
Listing 1
Note in Listing 1 that we have a loopback interface (lo0) and a network interface (net0); both these interfaces have been assigned an IPv4 address. We can also see that net0 has been assigned its IPv4 address statically.
Now let's look at the data link layer using the dladm command, as shown in Listing 2:
root@solaris:~# dladm show-link
LINK CLASS MTU STATE OVER
net1 phys 1500 unknown --
net0 phys 1500 up --
root@solaris:~# dladm show-vnic
root@solaris:~# dladm show-etherstub
Listing 2
Note in Listing 2 that we can see we have two physical network interfaces and we have no VNICs or Etherstubs (don't worry you will learn what these are later).
Q: Why did net1 not show up in the ipadm command in Listing 1? |
| A: Because it has not been assigned an IP address. |
Ok, now we are ready to set up the storage layer.
Exercise 2: Configuring the Storage Layer
For a full discussion on all the steps involved in creating and managing ZFS, please check out the Oracle Solaris 11.1 Administration: ZFS File Systems guide.
Before We Start
Check the status of the ZFS file system:
root@solaris:~# zfs list | grep zones
root@solaris:~# zfs list | grep mydata
Note: There are no ZFS data sets associated with any zones nor is there a ZFS data set for mydata.
Configure the Zone ZFS Data Set
We want a ZFS data set to put all our zone root directories in; it will be created in our root pool and mounted at /zones. Let's do that now:
root@solaris:~# zfs create -o mountpoint=/zones rpool/zones
Now, let's look at what that gives us:
root@solaris:~# zfs list rpool/zones
NAME USED AVAIL REFER MOUNTPOINT
rpool/zones 31K 13.0G 31K /zones
root@solaris:~# ls /zones
Note that we don't actually have to do this step. The zone creation will actually do that for you; however, we do it here just so you see how easy it is to create a data set and give it a mount point of your choosing.
Configure the Database ZFS Data Set
We also want to create a separate file system to store MySQL data files. Later this will be assigned to the database zone. This enables the database zone administrator to manage this data set separately, for example, to change its compression and deduplication parameters, create snapshots, and so on.
root@solaris:~# zfs create rpool/mydata
root@solaris:~# zfs list rpool/mydata
NAME USED AVAIL REFER MOUNTPOINT
rpool/mydata 31K 13.0G 31K /rpool/mydata
Exercise 3: Configuring the Web Layer
We will start by creating our web layer, which will involve setting up a network, creating and installing a zone, and adding an application into our zone. Let's start by configuring the network.
Configuring the Network
The Oracle Solaris instance you are using is configured with two internal networks. We can see them and what IP addresses they have by using the dladm and ipadm commands (just like we did in Exercise 1 in Listing 1 and Listing 2):
root@solaris:~# dladm show-link
LINK CLASS MTU STATE OVER
net1 phys 1500 unknown --
net0 phys 1500 up --
root@solaris:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.1.222/24
lo0/v6 static ok ::1/128
We are going to create an internal network to allow webzone and dbzone to communicate with each other. To do this, we will use an etherstub. We will connect to the etherstub using VNICs that we will dedicate to each of our zones (once we create them).
| Q: What is an etherstub? |
| A: Etherstubs are pseudo Ethernet NICs that are managed by the system administrator. You can create VNICs over etherstubs instead of over physical links. VNICs over an etherstub become independent of the physical NICs in the system. With etherstubs, you can construct a private virtual network that is isolated both from the other virtual networks in the system and from the external network. The simple way to think of an etherstub is as an internal network switch. |
First let's create the etherstub:
root@solaris:~# dladm create-etherstub vswitch0
root@solaris:~# dladm show-etherstub
LINK
vswitch0
Now we will create our first VNIC, and we will associate it with vswitch0:
root@solaris:~# dladm create-vnic -l vswitch0 webint0
root@solaris:~# dladm show-vnic
LINK OVER SPEED MACADDRESS MACADDRTYPE VID
webint0 vswitch0 40000 2:8:20:de:f4:40 random 0
Configuring webzone
webzone will need to be configured and installed, and then a network needs to be set up and an application needs to be added to it.
Let's start by entering the configuration information for the zone we are about to create. By default, all that you need to supply to a zone to create it is its name and its zonepath (the place where the zone root will live; remember, we created the rpool/zones ZFS data set to hold this information). However, in this case we will take the opportunity to also add in the webint0 VNIC.
root@solaris:~# zonecfg -z webzone
Use 'create' to begin configuring a new zone.
zonecfg:webzone> create
create: Using system default template 'SYSdefault'
zonecfg:webzone> set zonepath=/zones/webzone
zonecfg:webzone> add net
zonecfg:webzone:net> set physical=webint0
zonecfg:webzone:net> end
zonecfg:webzone> verify
zonecfg:webzone> commit
zonecfg:webzone> exit
Q: What are the verify and commit commands? |
A: These commands in zonecfg verify that the information is correct and then commit that configuration. It is good practice to use these commands when editing zone configuration information. |
Installing webzone
Now, webzone is configured, but it is not installed yet. We could install it right now, but if we did, after the first boot we would have to log in to it and create a system profile that includes host name, time zone, root password, and so on. Another way of achieving this—and have our zone be ready to use right after the first boot—is to create its profile before installation. This way also enables the automation of future zone creation.
root@solaris:~# sysconfig create-profile -o /root/webzone-profile.xml
In the dialog box that appears, enter the following parameters:
Computer Name: webzone
Network connection: None (we will configure networking later from within the zone)
Time Zone: Select your time zone (hint: when selecting the country, press its first letter, for example, U for United States)
Root password: solaris11
User real name: Zone User
User id: zuser
User password: oracle1
For everything else, accept the defaults, and then press F2 or ESC-2 to continue.
Now let's install the zone (this will take a few minutes to complete):
root@solaris:~# zoneadm -z webzone install -c /root/webzone-profile.xml
Progress being logged to /var/log/zones/zoneadm.20130812T145306Z.webzone.install
Image: Preparing at /zones/webzone/root.
AI Manifest: /tmp/manifest.xml.ZnaOeg
SC Profile: /root/webzone-profile.xml
Zonename: webzone
Installation: Starting ...
Creating IPS image
Startup linked: 1/1 done
Installing packages from:
solaris
origin: http://192.168.1.222/
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 183/183 33556/33556 222.2/222.2 328k/s
PHASE ITEMS
Installing new actions 46825/46825
Updating package state database Done
Updating image state Done
Creating fast lookup database Done
Installation: Succeeded
Note: Man pages can be obtained by installing pkg:/system/manual
done.
Done: Installation completed in 1096.528 seconds.
Next Steps: Boot the zone, then log into the zone console (zlogin -C)
to complete the configuration process.
Log saved in non-global zone as /zones/webzone/root/var/log/zones/zoneadm.20130812T145306Z.webzone.install
Once installation is done, we can boot webzone and log in to its console:
root@solaris:~# zoneadm -z webzone boot; zlogin -C webzone
[Connected to zone 'webzone' console]
Loading smf(5) service descriptions: 116/116
Hostname: webzone
webzone console login: zuser
Password: oracle1
Oracle Corporation SunOS 5.11 11.1 September 2012
Now let's exit the console using "~.":
zuser@webzone:~$ exit
logout
webzone console login: ~.
[Connection to zone 'webzone' console closed]
Setting Up a Network for webzone
Now we need to set up the webzone network, and log back in again using zlogin (see Listing 3). Note how we don't use the -C option and, hence, we don't connect to the console. Also note how we connect straight in with the root role. We'll do a quick check of the initial network setup using the ipadm and dladm commands, which you should be familiar with by now:
root@solaris:~# zlogin webzone
[Connected to zone 'webzone' pts/3]
Oracle Corporation SunOS 5.11 11.1 September 2012
root@webzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
root@webzone:~# dladm
LINK CLASS MTU STATE OVER
webint0 vnic 9000 unknown ?
net0 vnic 1500 up ?
Listing3
We don't have any IP addresses configured, but we have two data links available. Why two? We have configured only one interface using zonecfg. The second network interface, net0, is configured for us automatically. Even if we didn't configure any network using zonecfg, we would still have an automatic data link net0.
Now let's configure our IP interfaces for this zone. We need one interface to communicate with the outside world, and we are going to use net0 for that. We will assign a static IP address (though note that you could use DHCP here if you wanted to).
root@webzone:~# ipadm create-ip net0
root@webzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
net0 ip down -- --
Now net0 appears in our IP stack, but it still has no IP address. Let's assign one now:
root@webzone:~# ipadm create-addr -T static -a 192.168.1.225/24 net0
net0/v4
root@webzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
net0 ip ok -- --
net0/v4 static ok -- 192.168.1.225/24
Now let's try to ping the global zone on our newly created network:
root@webzone:~# ping 192.168.1.222
ping: sendto Network is unreachable
We are not able to ping the global zone, so let's check our routing table to make sure that is correct:
root@webzone:~# netstat -nr
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
127.0.0.1 127.0.0.1 UH 2 0 lo0
192.168.1.0 192.168.1.225 U 3 1 net0
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------- -----
::1 ::1 UH 2 0 lo0
The routing is also configured correctly.
This issue is actually being caused because of the "secure by default" nature of Oracle Solaris, which enables strict firewalls for manually created network interfaces. Note that if we had assigned a static network when we did the system configuration step previously, we would not have seen this issue.
Let's investigate the settings and then disable the firewall service. Note that outside the lab, you would implement some rules to follow your security policies.
root@webzone:~# ipfstat -io
block out log all
pass out quick on lo0 all
pass out quick proto udp from any to any port = bootps
block in log all
pass in quick on lo0 all
pass in quick proto udp from any to any port = bootpc
root@webzone:~# svcadm disable svc:/network/ipfilter
root@webzone:~# ping 192.168.1.222
192.168.1.222 is alive
Let's finish up the network setup for webzone by configuring the network for our internal communications between webzone and dbzone, as shown in Listing 4:
root@webzone:~# ipadm create-ip webint0
root@webzone:~# ipadm create-addr -a local=10.0.3.10/24 webint0/v4
root@webzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
net0 ip ok -- --
net0/v4 static ok -- 192.168.1.225/24
webint0 ip ok -- --
webint0/v4 static ok -- 10.0.3.10/24
Listing4
In Listing 4, note how we used a different format of the ipadm command this time (using local instead of static).
We also need to add host names to /etc/hosts for the WordPress installation.
root@webzone:~# echo '10.0.3.10 webzone' >> /etc/hosts
root@webzone:~# echo '10.0.3.11 dbzone' >> /etc/hosts
root@webzone:~# cat /etc/hosts
#
# Copyright 2009 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# Internet host table
#
::1 webzone localhost
127.0.0.1 webzone localhost loghost
10.0.3.10 webzone
10.0.3.11 dbzone
Adding Packages to webzone
The final step in the webzone installation is to add packages. We could install separate sets of packages into webzone and dbzone, but for simplicity sake we will install the full set of AMP (Apache, MySQL, PHP) packages into webzone and then clone webzone to create dbzone. We will use the pkg command. Note how all the package dependencies are worked out for us so we get everything we need using one simple command.
root@webzone:~# pkg install amp
Packages to install: 45
Mediators to change: 1
Create boot environment: No
Create backup boot environment: No
Services to change: 2
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 45/45 4351/4351 93.7/93.7 845k/s
PHASE ITEMS
Installing new actions 5844/5844
Updating package state database Done
Updating image state Done
Creating fast lookup database Done
Let's check the contents of what we installed:
root@webzone:~# pkg list *apache*
NAME (PUBLISHER) VERSION IFO
web/server/apache-22 2.2.22-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-dtrace 0.3.1-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-fcgid 2.3.6-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-php5 5.2.17-0.175.1.0.0.18 i-r
web/server/apache-22/module/apache-php52 5.2.17-0.175.1.0.0.24.0 i--
root@webzone:~# pkg list *php*
NAME (PUBLISHER) VERSION IFO
web/php-52 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-apc 3.0.19-0.175.1.0.0.24.0 i--
web/php-52/extension/php-idn 0.2.0-0.175.1.0.0.24.0 i--
web/php-52/extension/php-memcache 2.2.5-0.175.1.0.0.24.0 i--
web/php-52/extension/php-mysql 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-pear 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-suhosin 0.9.29-0.175.1.0.0.24.0 i--
web/php-52/extension/php-tcpwrap 1.1.3-0.175.1.0.0.24.0 i--
web/php-52/extension/php-xdebug 2.0.5-0.175.1.0.0.24.0 i--
web/php-common 11.1-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-php5 5.2.17-0.175.1.0.0.18 i-r
web/server/apache-22/module/apache-php52 5.2.17-0.175.1.0.0.24.0 i--
root@webzone:~# pkg list *mysql*
NAME (PUBLISHER) VERSION IFO
database/mysql-51 5.1.37-0.175.1.0.0.24.0 i--
database/mysql-51/library 5.1.37-0.175.1.0.0.24.0 i--
database/mysql-common 0.5.11-0.175.1.0.0.24.0 i--
library/apr-util-13/dbd-mysql 1.3.9-0.175.1.0.0.24.0 i--
web/php-52/extension/php-mysql 5.2.17-0.175.1.0.0.24.0 i--
All that is left to do is to start the web server service and check that it is running:
root@webzone:~# svcadm enable apache22
root@webzone:~# svcs apache22
STATE STIME FMRI
online 9:12:18 svc:/network/http:apache22
In your Oracle Solaris desktop, open the Firefox browser and enter the webzone IP address (192.168.1.225) into the address line. The resultant page should read "It works!"
Now that webzone is created and configured, we need to clone it to create dbzone. To do this, we must first halt webzone:
root@webzone:~# exit
logout
[Connection to zone 'webzone' pts/3 closed]
root@solaris:~# zoneadm -z webzone shutdown
root@solaris:~#
Exercise 4: Configuring the Database Layer
The next step is to create a database server zone. Instead of installing it, we will clone our existing zone, which saves time and disk space. As before, we need to set up the network, do the configuration and profile creation, and replace the installation with the cloning operation.
Configuring the dbzone VNIC
We want the database zone to be connected only internally to webzone, so we'll create a virtual NIC that is connected to the virtual switch we created before.
root@solaris:~# dladm create-vnic -l vswitch0 dbint0
root@solaris:~# dladm
LINK CLASS MTU STATE OVER
net1 phys 1500 unknown --
net0 phys 1500 up --
vswitch0 etherstub 9000 unknown --
webint0 vnic 9000 up vswitch0
dbint0 vnic 9000 up vswitch0
Configuring dbzone
Because this zone will be running the database part of our application, we will call it dbzone. In this configuration, we will set the path where the zone will be located (/zones/dbzone) and its network interface (dbint0), and also we will assign the data set we created at the very beginning of the lab (rpool/mydata) to use inside the zone.
root@solaris:~# zonecfg -z dbzone
Use 'create' to begin configuring a new zone.
zonecfg:dbzone> create
create: Using system default template 'SYSdefault'
zonecfg:dbzone> set zonepath=/zones/dbzone
zonecfg:dbzone> add net
zonecfg:dbzone:net>set physical=dbint0
zonecfg:dbzone:net> end
zonecfg:dbzone> add dataset
zonecfg:dbzone:dataset> set name=rpool/mydata
zonecfg:dbzone:dataset> end
zonecfg:dbzone> verify
zonecfg:dbzone> commit
zonecfg:dbzone> exit
Next let's create the zone profile for dbzone.
root@solaris:~# sysconfig create-profile -o /root/dbzone-profile.xml
In the dialog box that appears, enter the following parameters:
Computer Name: dbzone
Network connection: None (we will configure networking later from within the zone)
Time Zone: Select your time zone (hint: when selecting the country, press its first letter, for example, U for United States)
Root password: solaris11
User real name: Zone User
User id: zuser
User password: oracle1
For everything else, accept the defaults by pressing F2 or ESC-2 to continue.
Installing dbzone Using Cloning
Instead of installing the zone from our newly created profile, this time we will clone webzone to create dbzone.
root@solaris:~# zoneadm -z dbzone clone -c /root/dbzone-profile.xml webzone
Progress being logged to /var/log/zones/zoneadm.20130812T195010Z.dbzone.clone
Log saved in non-global zone as /zones/dbzone/root/var/log/zones/zoneadm.20130812T195010Z.dbzone.clone
root@solaris:~# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
- webzone installed /zones/webzone solaris excl
- dbzone installed /zones/dbzone solaris excl
This time, the installation was much quicker, and we also ended up with a copy of our original zone. This technique is extremely useful in a cloud environment to allow us to rapidly provision new instances.
Also important is how efficiently space is used by our virtualization technology. Let's take a look at the disk usage now:
root@solaris:~# zfs list rpool/zones rpool/zones/webzone rpool/zones/dbzone
NAME USED AVAIL REFER MOUNTPOINT
rpool/zones 619M 12.0G 33K /zones
rpool/zones/dbzone 391K 12.0G 34K /zones/dbzone
rpool/zones/webzone 619M 12.0G 33K /zones/webzone
Listing 5
Listing 5 shows that the total space used is 619 MB, but when you total up the two zones you get 1010 MB—how can that be? It is because we are using ZFS, which means that we get a copy-on-write file system—only the differences between dbzone and webzone will need to be stored on disk.
Setting Up dbzone
Let's check out dbzone and do some final configuration. First let's start up both our zones:
root@solaris:~# zoneadm -z webzone boot
root@solaris:~# zoneadm -z dbzone boot
root@solaris:~# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
3 webzone running /zones/webzone solaris excl
4 dbzone running /zones/dbzone solaris excl
We can see that both zones are running. Now log in to dbzone and see whether we have a full copy of webzone by checking the AMP packages and checking whether the Apache web server is running:
root@solaris:~# zlogin dbzone
[Connected to zone 'dbzone' pts/2]
Oracle Corporation SunOS 5.11 11.1 September 2012
root@dbzone:~# pkg list *apache*
NAME (PUBLISHER) VERSION IFO
web/server/apache-22 2.2.22-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-dtrace 0.3.1-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-fcgid 2.3.6-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-php5 5.2.17-0.175.1.0.0.18 i-r
web/server/apache-22/module/apache-php52 5.2.17-0.175.1.0.0.24.0 i--
root@dbzone:~# pkg list *php*
NAME (PUBLISHER) VERSION IFO
web/php-52 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-apc 3.0.19-0.175.1.0.0.24.0 i--
web/php-52/extension/php-idn 0.2.0-0.175.1.0.0.24.0 i--
web/php-52/extension/php-memcache 2.2.5-0.175.1.0.0.24.0 i--
web/php-52/extension/php-mysql 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-pear 5.2.17-0.175.1.0.0.24.0 i--
web/php-52/extension/php-suhosin 0.9.29-0.175.1.0.0.24.0 i--
web/php-52/extension/php-tcpwrap 1.1.3-0.175.1.0.0.24.0 i--
web/php-52/extension/php-xdebug 2.0.5-0.175.1.0.0.24.0 i--
web/php-common 11.1-0.175.1.0.0.24.0 i--
web/server/apache-22/module/apache-php5 5.2.17-0.175.1.0.0.18 i-r
web/server/apache-22/module/apache-php52 5.2.17-0.175.1.0.0.24.0 i--
root@dbzone:~# pkg list *mysql*
NAME (PUBLISHER) VERSION IFO
database/mysql-51 5.1.37-0.175.1.0.0.24.0 i--
database/mysql-51/library 5.1.37-0.175.1.0.0.24.0 i--
database/mysql-common 0.5.11-0.175.1.0.0.24.0 i--
library/apr-util-13/dbd-mysql 1.3.9-0.175.1.0.0.24.0 i--
web/php-52/extension/php-mysql 5.2.17-0.175.1.0.0.24.0 i--
root@dbzone:~# svcs apache22
STATE STIME FMRI
online 4:25:11 svc:/network/http:apache22
All the packages are there and the Apache web server is up and running, just like our webzone. We actually don't need Apache here in dbzone, so let's stop it.
root@webzone:~# svcadm disable apache22
root@dbzone:~# svcs apache22
STATE STIME FMRI
offline 6:39:24 svc:/network/http:apache22
We also need to finish configuring our network. Note that we do not need to disable the firewall this time because we did that in webzone already.
root@dbzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
root@dbzone:~# dladm
LINK CLASS MTU STATE OVER
dbint0 vnic 9000 up ?
net0 vnic 1500 up ?
root@dbzone:~# ipadm create-ip dbint0
root@dbzone:~# ipadm create-addr -a local=10.0.3.11/24 dbint0/v4
root@dbzone:~# ping 10.0.3.10
10.0.3.10 is alive
root@dbzone:~# ping webzone
webzone is alive
root@dbzone:~# ipadm
NAME CLASS/TYPE STATE UNDER ADDR
dbint0 ip ok -- --
dbint0/v4 static ok -- 10.0.3.11/24
lo0 loopback ok -- --
lo0/v4 static ok -- 127.0.0.1/8
lo0/v6 static ok -- ::1/128
Q: How were we able to ping webzone by host name, since we haven't set up /etc/hosts in this zone? |
A: Because /etc/hosts was already set up in webzone, it was cloned across with the rest of the webzone contents. |
The last task is to configure and start our database. You may remember that we set up a ZFS data set for the database information. We need to configure MySQL to use that.
First, check that the mydata ZFS data set was correctly delegated to this zone:
root@dbzone:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mydata 31K 11.9G 31K /mydata
rpool 64.0M 11.9G 31K /rpool
rpool/ROOT 63.9M 11.9G 31K legacy
rpool/ROOT/solaris-0 63.9M 11.9G 618M /
rpool/ROOT/solaris-0/var 261K 11.9G 28.7M /var
rpool/VARSHARE 19K 11.9G 39K /var/share
rpool/export 74.5K 11.9G 32K /export
rpool/export/home 53.5K 11.9G 32K /export/home
rpool/export/home/zuser 32.5K 11.9G 32.5K /export/home/zuser
Now, set up the correct ownership for the /mydata directory and configure MySQL to use it:
root@dbzone:~# chown -R mysql:mysql /mydata
root@dbzone:~# chmod -R 700 /mydata
root@dbzone:~# svccfg -s mysql:version_51 setprop mysql/data=/mydata
root@dbzone:~# svcadm refresh mysql:version_51
root@dbzone:~# svccfg -s mysql:version_51 listprop mysql/data
mysql/data astring /mydata
Finally, let's start MySQL and check that it is working. You can check whether it has started up using the svcs command because MySQL might take a little time to start:
root@dbzone:~# svcadm enable mysql
root@dbzone:~# svcs mysql
STATE STIME FMRI
online 4:26:21 svc:/application/database/mysql:version_51
root@dbzone:~# mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.37 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Exercise 5: Configuring the WordPress Application
The last part of our stack is to configure and run our application, in our case WordPress.
While we are still in the database zone and logged into the MySQL instance, let's create the database we need for WordPress:
mysql> create database wp01;
Query OK, 1 row affected (0.01 sec)
Let's add access privileges for the user wordpress from host webzone with password oracle1:
mysql> grant all privileges on wp01.* to 'wordpress'@'webzone' identified by 'oracle1';
Query OK, 0 rows affected (0.01 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)
mysql> quit;
Bye
That is all the tasks for the database zone, so quit out to the global zone:
root@dbzone:~# exit
logout
[Connection to zone 'dbzone' pts/2 closed]
root@solaris:~#
Now, let's copy the WordPress binaries into place in webzone. We will use the network connection we created when we configured webzone:
root@solaris:~# scp /root/files/wordpress-3.6.zip zuser@192.168.1.225:
The authenticity of host '192.168.1.225 (192.168.1.225)' can't be established.
RSA key fingerprint is 68:20:37:5f:fe:d8:92:e0:b4:6f:2d:53:a0:3e:c6:74.
Are you sure you want to continue connecting (yes/no)? yes
Password: oracle1
wordpress-3.6.zip 100% |**********************************************************************************
***************************| 4371 KB 00:00
root@solaris:~#
Next, let's log in to webzone and extract the WordPress application. Remember to copy or move the archive from the zuser location.
root@solaris:~# zlogin webzone
[Connected to zone 'webzone' pts/2]
Oracle Corporation SunOS 5.11 11.1 September 2012
root@webzone:~# pwd
/root
root@webzone:~# mv /home/zuser/wordpress-3.6.zip .
root@webzone:~# unzip wordpress-3.6.zip
Archive: wordpress-3.6.zip
creating: wordpress/
inflating: wordpress/wp-settings.php
inflating: wordpress/wp-cron.php
(output omitted)
inflating: wordpress/wp-includes/Text/Diff.php
inflating: wordpress/wp-includes/update.php
inflating: wordpress/wp-includes/comment.php
inflating: wordpress/wp-config-sample.php
root@webzone:~#
Now, we need to configure WordPress to use our MySQL database. First, copy the configuration file, and then make the changes shown below:
root@webzone:~# cd wordpress
root@webzone:~/wordpress# cp wp-config-sample.php wp-config.php
root@webzone:~/wordpress# vi wp-config.php
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wp01');
/** MySQL database username */
define('DB_USER', 'wordpress');
/** MySQL database password */
define('DB_PASSWORD', 'oracle1');
/** MySQL hostname */
define('DB_HOST', 'dbzone');
We now need to copy the WordPress distribution to the web server document root.
root@webzone:~/wordpress# mkdir /var/apache2/2.2/htdocs/blog
root@webzone:~/wordpress# cp -r * /var/apache2/2.2/htdocs/blog
root@webzone:~/wordpress# ls /var/apache2/2.2/htdocs/blog/
index.php wp-activate.php wp-comments-post.php wp-cron.php wp-load.php wp-settings.php xmlrpc.php
license.txt wp-admin wp-config.php wp-includes wp-login.php wp-signup.php
readme.html wp-blog-header.php wp-content wp-links-opml.php wp-mail.php wp-trackback.php
We are now ready to install WordPress using your browser. Start a browser from the desktop in your global zone, and enter the URL http://192.168.1.225/blog/wp-admin/install.php. The rest is easy. Enter the name of the blog ("Oracle Solaris 11 Blog"), your administrator's login name (admin, by default) and the password (solaris1, for example), and an e-mail address, as shown in Figure 3.
Figure 3. The WordPress installation screen.
Figure 4. WordPress successful installation screen.
Now, log in to your new blog using the credentials you selected.
Figure 5. WordPress login screen.
Once you are at the dashboard, access your blogging window by clicking "Oracle Solaris 11 Blog" at the top of the browser window.
Figure 6. WordPress dashboard.
Figure 7. WordPress blog screen.
Exercise 6: Monitoring Zones
Monitoring what resources your zones and—hence, your cloud—are using is important for debugging issues and also for capacity planning, and even for charging. Oracle Solaris 11 adds features that make this even simpler. We will look at them now.
Zone Extensions to Existing Commands
Some Oracle Solaris 11 commands now have a -Z parameter to help you when you examine a system. Let's try a couple now. Note that the following examples are run from the global zone, and some of the output has been truncated to be more readable.
With the ps command, it is now possible to see which zone a process belongs to:
root@solaris:~# ps -efZ
ZONE UID PID PPID C STIME TTY TIME CMD
global root 0 0 0 Aug 11 ? 0:04 sched
global root 5 0 0 Aug 11 ? 1:02 zpool-rpool
global root 6 0 0 Aug 11 ? 0:13 kmem_task
global root 1 0 0 Aug 11 ? 0:01 /usr/sbin/init
dbzone root 12762 1 0 06:39:26 ? 0:00 /usr/lib/pfexecd
webzone root 11549 1 0 06:38:20 ? 0:00 /usr/lib/utmpd
webzone daemon 11217 1 0 06:38:11 ? 0:00 /lib/crypto/kcfd
With the prstat command, there is a summary for zone-related information:
root@solaris:~# prstat -Z
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
0 120 3103M 703M 34% 0:26:36 1.4% global
4 29 306M 108M 5.3% 0:01:57 0.2% dbzone
3 38 1182M 336M 17% 0:01:02 0.2% webzone
The zonestat Command
There is a new command called zonestat, which is extremely useful for examining zone and network information, as shown in Listing 6:
root@solaris:~# zonestat 5 2
Collecting data for first interval...
Interval: 1, Duration: 0:00:05
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.17 17.4% 1432M 69.9% 1899M 61.8% 212 0.00%
[system] 0.01 1.67% 449M 21.9% 1019M 33.1% - -
global 0.14 14.2% 747M 36.5% 572M 18.6% 212 0.00%
dbzone 0.00 0.47% 100M 4.88% 99M 3.22% 0 0.00%
webzone 0.00 0.99% 135M 6.61% 207M 6.77% 0 0.00%
Interval: 2, Duration: 0:00:10
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.17 17.8% 1432M 69.9% 1899M 61.8% 936 0.00%
[system] 0.02 2.44% 449M 21.9% 1019M 33.1% - -
global 0.13 13.3% 748M 36.5% 572M 18.6% 936 0.00%
dbzone 0.01 1.01% 100M 4.88% 99M 3.22% 0 0.00%
webzone 0.00 0.96% 135M 6.61% 208M 6.77% 0 0.00%
Listing 6
You can also use zonestat from within a zone, as shown in Listing 7. Can you spot what the differences are between Listing 6 and Listing 7?
root@solaris:~# zlogin webzone
[Connected to zone 'webzone' pts/2]
Oracle Corporation SunOS 5.11 11.1 September 2012
root@webzone:~# zonestat 5 2
Collecting data for first interval...
Interval: 1, Duration: 0:00:05
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.16 16.6% 1435M 70.1% 1901M 61.9% 212 0.00%
[system] 0.15 15.8% 1297M 63.3% 1692M 55.1% - -
webzone 0.00 0.75% 138M 6.74% 209M 6.81% 0 0.00%
Interval: 2, Duration: 0:00:10
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.17 17.1% 1435M 70.1% 1901M 61.9% 628 0.00%
[system] 0.16 16.1% 1297M 63.3% 1692M 55.1% - -
webzone 0.01 1.02% 138M 6.74% 209M 6.81% 0 0.00%
root@webzone:~# exit
logout
[Connection to zone 'webzone' pts/2 closed]
Listing 7
Look at the zonestat man page and experiment with the different output types.
Exercise 7: Performing Resource Management
Resource management is very important in the cloud. You might want to control misbehaving applications or bill on a per-CPU basis. Among other features, Oracle Solaris Zones and the Oracle Solaris network stack also allow you to control resources. While you can control many different things, in this lab, we will look at controlling processing power via Oracle Solaris Zones.
Loading a Zone Without Resource Management
Let's look first at Oracle Solaris Zones without any resource management in place. This can be beneficial for cases where loads are "bursty" and resources need to be instantly available or shared across multiple instances. However, in the cloud case, it is much more likely that resources need to be assigned. We will look at the output here simply for comparison.
We start by looking at the system in its current state. We will use the vmstat and zonestat commands to look at the processor load, as shown in Listing 8.
root@solaris:~# vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 -- in sy cs us sy id
0 0 0 1497124 759028 57 233 0 0 0 0 9 13 0 0 0 465 1795 817 2 4 94
0 0 0 1085060 430068 7 11 0 0 0 0 0 0 0 0 0 463 408 376 1 2 97
0 0 0 1085060 430068 0 0 0 0 0 0 0 0 0 0 0 457 443 373 0 2 98
0 0 0 1085060 430068 0 0 0 0 0 0 0 0 0 0 0 455 392 370 1 1 98
0 0 0 1085060 430068 0 0 0 0 0 0 0 0 0 0 0 456 412 368 0 2 98
root@solaris:~# zonestat 5 2
Collecting data for first interval...
Interval: 1, Duration: 0:00:05
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.12 12.2% 848M 41.4% 1232M 40.1% 212 0.00%
[system] 0.01 1.09% 307M 15.0% 812M 26.4% - -
global 0.10 10.1% 347M 16.9% 196M 6.38% 212 0.00%
dbzone 0.00 0.56% 90.9M 4.44% 87.0M 2.83% 0 0.00%
webzone 0.00 0.48% 102M 4.98% 136M 4.44% 0 0.00%
Interval: 2, Duration: 0:00:10
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.14 14.8% 848M 41.4% 1233M 40.1% 936 0.00%
[system] 0.01 1.03% 307M 15.0% 813M 26.4% - -
global 0.13 13.0% 347M 16.9% 196M 6.38% 936 0.00%
dbzone 0.00 0.37% 90.9M 4.44% 87.0M 2.83% 0 0.00%
webzone 0.00 0.40% 102M 4.98% 136M 4.44% 0 0.00%
Listing 8
In Listing 8, we can see from vmstat that the system is pretty idle, and zonestat shows us that both dbzone and webzone are using very few CPU resources.
Let's run a simple CPU-intensive script in webzone. We'll run three instances to put the system under some measurable load:
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[1] 2376
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[2] 4352
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[3] 5820
Let's look at the effect on the system:
root@solaris:~# vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 -- in sy cs us sy id
0 0 0 1458340 728048 57 257 0 0 0 0 9 12 0 0 0 465 1697 781 2 4 94
5 0 0 1073088 420496 2991 25178 0 0 0 0 0 0 0 0 0 508 12344 572 42 58 0
4 0 0 1072960 420404 3001 25325 0 0 0 0 0 0 0 0 0 488 12404 573 42 58 0
4 0 0 1072920 420484 3003 25323 0 0 0 0 0 0 0 0 0 496 12488 609 42 58 0
4 0 0 1072896 420400 2962 24986 0 0 0 0 0 0 0 0 0 508 12341 610 42 58 0
System time hits a high of 58. Also let's look at what zonestat is telling us:
root@solaris:~# zonestat 5 2
Collecting data for first interval...
Interval: 1, Duration: 0:00:05
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.99 99.9% 854M 41.7% 1241M 40.4% 212 0.00%
[system] 0.07 7.82% 308M 15.0% 813M 26.4% - -
webzone 0.80 80.5% 106M 5.18% 139M 4.54% 0 0.00%
global 0.11 11.2% 349M 17.0% 200M 6.53% 212 0.00%
dbzone 0.00 0.34% 90.9M 4.44% 87.0M 2.83% 0 0.00%
Interval: 2, Duration: 0:00:10
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 1.00 100% 855M 41.7% 1242M 40.4% 936 0.00%
[system] 0.05 5.46% 308M 15.0% 814M 26.5% - -
webzone 0.83 83.0% 106M 5.18% 139M 4.55% 0 0.00%
global 0.11 11.0% 349M 17.0% 201M 6.54% 936 0.00%
dbzone 0.00 0.38% 90.9M 4.44% 87.0M 2.83% 0 0.00%
Listing 9
In Listing 9, we can clearly see that webzone is using 83 percent of the available CPU resources.
Let's kill off the scripts before we add some resource control.
root@solaris:~# fg 1
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
root@solaris:~# fg 2
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
root@solaris:~# fg 3
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
Adding CPU Resource Control
Now let's limit webzone to half a CPU:
root@solaris:~# zonecfg -z webzone
zonecfg:webzone> add capped-cpu
zonecfg:webzone:capped-cpu> set ncpus=0.5
zonecfg:webzone:capped-cpu> end
zonecfg:webzone> verify
zonecfg:webzone> commit
zonecfg:webzone> exit
Resource limitations are applied only after a zone reboot, so let's reboot now:
root@solaris:~# zoneadm -z webzone reboot
root@solaris:~# zoneadm list -iv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
2 dbzone running /zones/dbzone solaris excl
3 webzone running /zones/webzone solaris excl
Now, let's run the same tests again, as shown in Listing 10, and look at the output:
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[1] 4305
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[2] 4545
root@solaris:~# zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'" &
[3] 4747
root@solaris:~# vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 -- in sy cs us sy id
0 0 0 1419676 695904 171 1164 0 0 0 0 8 12 0 0 0 468 2298 838 3 6 90
0 0 0 1013684 350316 1289 11358 0 0 0 0 0 0 0 0 0 482 5726 508 23 33 44
0 0 0 1013684 350236 1248 11121 0 0 0 0 0 0 0 0 0 484 5577 510 23 32 45
0 0 0 1013684 350224 1264 11361 0 0 0 0 0 0 0 0 0 475 5732 508 23 32 45
1 0 0 1013692 350256 1292 11464 0 0 0 0 0 0 0 0 0 486 5769 505 23 32 45
root@solaris:~# zonestat 5 2
Collecting data for first interval...
Interval: 1, Duration: 0:00:05
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.64 64.9% 919M 44.9% 1296M 42.2% 212 0.00%
[system] 0.05 5.83% 375M 18.3% 871M 28.3% - -
webzone 0.47 47.9% 103M 5.05% 136M 4.46% 0 0.00%
global 0.10 10.7% 349M 17.0% 201M 6.54% 212 0.00%
dbzone 0.00 0.39% 90.9M 4.44% 87.0M 2.83% 0 0.00%
Interval: 2, Duration: 0:00:10
SUMMARY Cpus/Online: 1/1 PhysMem: 2047M VirtMem: 3071M
---CPU---- --PhysMem-- --VirtMem-- --PhysNet--
ZONE USED %PART USED %USED USED %USED PBYTE %PUSE
[total] 0.65 65.9% 920M 44.9% 1296M 42.2% 936 0.00%
[system] 0.03 3.26% 375M 18.3% 871M 28.3% - -
webzone 0.48 48.3% 103M 5.06% 136M 4.45% 0 0.00%
global 0.13 13.9% 349M 17.0% 201M 6.55% 936 0.00%
dbzone 0.00 0.42% 90.9M 4.44% 87.0M 2.83% 0 0.00%
Listing 10
In Listing 10, you can see how the resource controls have limited the CPU usage of webzone. To complete this part of the lab, let's stop the scripts and remove the CPU resource limit from webzone (don't forget to reboot webzone at the end to apply the resource changes):
root@solaris:~# fg 1
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
root@solaris:~# fg 2
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
root@solaris:~# fg 3
zlogin webzone "bash -c 'while true ; do date > /dev/null ; done'"
^C
root@solaris:~# zonecfg -z webzone
zonecfg:webzone-1> remove capped-cpu
zonecfg:webzone-1> verify
zonecfg:webzone-1> commit
zonecfg:webzone-1> exit
root@solaris:~# zoneadm -z webzone reboot
There are lots of other resource control settings you can apply to a zone. Have a look at the man page or documentation to see what other options there are.
Exercise 8: Ensuring Availability
Oracle Solaris offers many ways to make your applications available. You can simply rely on the reliability, availability, and serviceability (RAS) features built into the hardware or you might want to go all the way and implement a highly available environment with Oracle Solaris Cluster. Oracle Solaris offers availability at all levels. Here, we will take a very quick look at the Service Management Framework of Oracle Solaris.
For a quick demonstration, let's look at the processes associated with our Apache web server, as shown in Listing 11:
root@webzone:~# svcs -p apache22
STATE STIME FMRI
online 5:05:46 svc:/network/http:apache22
5:05:46 20538 httpd
5:05:47 20539 httpd
5:05:48 20540 httpd
5:05:48 20541 httpd
5:05:48 20542 httpd
5:05:48 20543 httpd
5:05:48 20544 httpd
Listing 11
Now, let's simulate a failure in the service by killing the httpd processes, as shown in Listing 12, and see what happens to them:
root@webzone:~# pkill httpd
root@webzone:~# svcs -p apache22
STATE STIME FMRI
online 5:28:01 svc:/network/http:apache22
5:28:01 20585 httpd
5:28:01 20586 httpd
5:28:02 20587 httpd
5:28:02 20588 httpd
5:28:02 20589 httpd
5:28:02 20590 httpd
5:28:02 20591 httpd
Listing 12
The Apache httpd processes are still there. If you look closely at Listing 12, you will see that the process IDs have changed from Listing 11, and the service was automatically restarted after it was stopped. This is a standard part of the Service Management Framework and provides a small insight into how Oracle Solaris maintains your cloud service availability.
Exercise 9: Securing the Environment
Security is always important, but in a cloud space with shared environments and an "open" network, it is even more important to protect your environment.
Oracle Solaris includes the ability to secure your environment at many different layers. You might want to use ZFS encryption for your data or use data link protection to harden your network. Here, we will look at Oracle Solaris' unique ability to create read-only environments called immutable zones.
Turning webzone into an Immutable Zone
Let's start by turning our webzone into an immutable zone or read-only environment. This is very simple to do via a configuration change. To apply the change, we need to reboot the zone:
root@solaris:~# zonecfg -z webzone
zonecfg:webzone> set file-mac-profile=fixed-configuration
zonecfg:webzone> verify
zonecfg:webzone> commit
zonecfg:webzone> exit
root@solaris:~# zoneadm -z webzone reboot
That's all we need to do. We now have a read-only environment.
Trying to Do Some Damage
Let's see what we can do from inside our read-only environment:
root@solaris:~# zlogin webzone
[Connected to zone 'webzone' pts/2]
Oracle Corporation SunOS 5.11 11.1 September 2012
root@webzone:~# touch /etc/a_file
touch: cannot create /etc/a_file: Read-only file system
root@webzone:~# touch /var/tmp/a_file
root@webzone:~# touch /tmp/a_file
root@webzone:~# pkg install emacs
pkg install: Could not complete the operation on /var/pkg/lock: read-only filesystem.
root@webzone:~# rm /usr/bin/vi
rm: /usr/bin/vi not removed: Read-only file system
root@webzone:~# useradd larry
/usr/lib/passmgmt: Password file(s) busy. Try again later
/usr/lib/passmgmt: Password file(s) busy. Try again later
/usr/lib/passmgmt: Password file(s) busy. Try again later
UX: useradd: ERROR: Cannot update system - login cannot be created.
root@webzone:~# svcadm disable apache22
root@webzone:~# svcs apache22
STATE STIME FMRI
disabled 8:56:10 svc:/network/http:apache22
root@webzone:~# exit
logout
[Connection to zone 'webzone' pts/2 closed]
But what do we need to do if we need to make some changes to webzone? Well, you can boot the zone in read/write mode, but note that you can do this only from the global zone. A similar thing happens when you do updates from the global zone that affect the zone.
root@solaris:~# zoneadm -z webzone reboot -w
root@solaris:~# zlogin -C webzone
[Connected to zone 'webzone' console]
Hostname: webzone
webzone console login: zuser
Password: oracle1
Last login: Tue Aug 13 09:39:27 from 192.168.1.222
Oracle Corporation SunOS 5.11 11.1 September 2012
zuser@webzone:~$ su -
Password: solaris11
Aug 14 12:02:57 webzone su: 'su root' succeeded for zuser on /dev/console
Oracle Corporation SunOS 5.11 11.1 September 2012
root@webzone:~# touch /etc/a_file
root@webzone:~# rm /etc/a_file
root@webzone:~# exit
logout
zuser@webzone:~$ exit
logout
webzone console login: ~.
[Connection to zone 'webzone' console closed]
Finally, let's return the zone back to its normal mode:
root@solaris:~# zonecfg -z webzone
zonecfg:webzone> clear file-mac-profile
zonecfg:webzone> verify
zonecfg:webzone> commit
zonecfg:webzone> exit
root@solaris:~# zoneadm -z webzone reboot
Conclusion
That's it; you're all done. Having completed the lab, you've learned how Oracle Solaris is the best foundation for your cloud infrastructure. You've seen how easy it is to rapidly deploy applications, configure flexible networks, and control resources, and you've seen how Oracle Solaris works to keep your services running. You've also seen how to implement a read-only virtual environment. If you got this far and have some time to spare, why not look at the following section and see how far you can get.
For the Adventurous
If you have finished the lab, why not try the following:
- Look at assigning some network resource management and testing it.
- Try cloning
webzoneagain and configure a load balancer for the two web servers.
See Also
- See Oracle Solaris 11.1 Administration: Oracle Solaris Zones, Oracle Solaris 10 Zones, and Resource Management
- See "Introducing the Basics of Image Packaging System (IPS) on Oracle Solaris 11"
- See "How to Configure Oracle Solaris 11 Using the
sysconfigCommand" - Check out Duncan Hardie's blog
Also see the following resources:
- Download Oracle Solaris 11
- Access Oracle Solaris 11 product documentation
- Access all Oracle Solaris 11 how-to articles
- Learn more with Oracle Solaris 11 training and support
- See the official Oracle Solaris blog
- Check out The Observatory blog for Oracle Solaris tips and tricks
- Follow Oracle Solaris on Facebook and Twitter
Revision 1.0, 11/22/2013