Tuesday Jul 16, 2013
Wednesday Jun 12, 2013
By Jeff Victor on Jun 12, 2013
First a recap: Solaris 10 introduced the Solaris Zones feature set, way back in 2005. Zones are a form of server virtualization called "OS (Operating System) Virtualization." They improve consolidation ratios by isolating processes from each other so that they cannot interact. Each zone has its own set of users, naming services, and other software components. One of the many advantages is that there is no need for a hypervisor, so there is no performance overhead. Many data centers run tens to hundreds of zones per server!
In Solaris 10, there are two models of package deployment for Solaris Zones. One model is called "sparse-root" and the other "whole-root." Each form has specific characteristics, abilities, and limitations.
A whole-root zone has its own copy of the Solaris packages. This allows the inclusion of other software in system directories - even though that practice has been discouraged for many years. Although it is also possible to modify the Solaris content in such a zone, e.g. patching a zone separately from the rest, this was highly frowned on. (More importantly, modifying the Solaris content in a whole-root zone may lead to an unsupported configuration.)
The other model is called "sparse-root." In that form, instead of copying all of the Solaris packages into the zone, the directories containing Solaris binaries are re-mounted into the zone. This allows the zone's users to access them at their normal places in the directory tree. Those are read-only mounts, so a zone's root user cannot modify them. This improves security, and also reduces the amount of disk space used by the zone - 200MB instead of the usual 3-5 GB per zone. These loopback mounts also reduce the amount of RAM used by zones because Solaris only stores in RAM one copy of a program that is in use by several zones. This model also has disadvantages. One disadvantage is the inability to add software into system directories such as /usr. Also, although a sparse-root can be migrated to another Solaris 10 system, it cannot be moved to a Solaris 11 system as a "Solaris 10 Zone."
In addition to those contrasting characteristics, here are some characteristics of zones in Solaris 10 that are shared by both packaging models:
- A zone can modify its own configuration files in /etc.
- A zone can be configured so that it manages its own networking, or so that it cannot modify its network configuration.
- It is difficult to give a non-root user in the global zone the ability to boot and stop a zone, without giving that user other abilities.
- In a zone that can manage its own networking, the root user can do harmful things like spoof other IP addresses and MAC addresses.
- It is difficult to assign network patcket processing to the same CPUs that a zone used. This could lead to unpredictable performance and performance troubleshooting challenges.
- You cannot run a large number of zones in one system (e.g. 50) that each managed its own networking, because that would require assignment of more physical NICs than available (e.g. 50).
- Except when managed by Ops Center, zones could not be safely stored on NAS.
- Solaris 10 Zones cannot be NFS servers.
- The fsstat command does not report statistics per zone.
Solaris 11 Zones use the new packaging system of Solaris 11. Their configuration does not offer a choice of packaging models, as Solaris 10 does. Instead, two (well, four) different models of "immutability" (changeability) are offered. The default model allows a privileged zone user to modify the zone's content. The other (three) limit the content which can be changed: none, or two overlapping sets of configuration files. (See "Configuring and Administering Immutable Zones".)
Solaris 11 addresses many of those limitations. With the characteristics listed above in mind, the following table shows the similarities and differences between zones in Solaris 10 and in Solaris 11. (Cells in a row that are similar have the same background color.)
|Solaris 11||Solaris 11|
|Each zone has a copy of most Solaris packages||Yes||No||Yes||Yes|
|Disk space used by a zone (typical)||3.5 GB||100 MB||500MB||500MB|
|A privileged zone user can add software to /usr||Yes||No||Yes||No|
|A zone can modify its Solaris programs||True||False||True||False|
|Each zone can modify its configuration files||Yes||Yes||Yes||No|
|A zone can be configured to manage its own networking||Yes||Yes||Yes||Yes|
|A zone can be configured so that it cannot manage its own networking||Yes||Yes||Yes||Yes|
|A zone can be configured with resource controls||Yes||Yes||Yes||Yes|
|Integrated tool to measure a zone's resource consumption (zonestat)||No||No||Yes||Yes|
|Network processing automatically happens on that zone's CPUs||No||No||Yes||Yes|
|Zones can be NFS servers||No||No||Yes||Yes|
|Per-zone fsstat data||No||No||Yes||Yes|
As you can see, the statement "Solaris 11 Zones are whole-root zones" is only true using the narrowest definition of whole-root zones: those zones which have their own copy of Solaris packaging content. But there are other valuable characteristics of sparse-root zones that are still available in Solaris 11 Zones. Also, some Solaris 11 Zones do not have some characteristics of whole-root zones.
For example, the table above shows that you can configure a Solaris 11 zone that has read-only Solaris content. And Solaris 11 takes that concept further, offering the ability to tailor that immutability. It also shows that Solaris 10 sparse-root and whole-root zones are more similar to each other than to Solaris 11 Zones.
ConclusionSolaris 11 Zones are slightly different from Solaris 10 Zones. The former can achieve the goals of the latter, and they also offer features not found in Solaris 10 Zones. Solaris 11 Zones offer the best of Solaris 10 whole-root zones and sparse-root zones, and offer an array of new features that make Zones even more flexible and powerful.
Wednesday Nov 14, 2012
By Jeff Victor on Nov 14, 2012
New features include Optimized Shared Memory (improves DB startup time), accelerated kernel locks (improves Oracle RAC performance and scalability), virtual memory improvements, a DTrace data collecter in the DB, Zones installed on Shared Storage (simplifies migration), Data Center Bridging, and Edge Virtual Bridging.
To view the archived webcast, you must register and use the URL that you receive in e-mail.
Tuesday Nov 13, 2012
Thursday Nov 08, 2012
Wednesday Nov 07, 2012
By Jeff Victor on Nov 07, 2012
Thursday Oct 25, 2012
By Jeff Victor on Oct 25, 2012
My favorite new features:
- Solaris Zones on Shared Storage
- Support for 32 TB (!) of RAM
- Improved Oracle RAC lock latency
- Dynamically resize the Oracle DB SGA
- Industry-first support for FedFS
Tuesday Oct 23, 2012
By Jeff Victor on Oct 23, 2012
ago in a
far, far away...
I wrote four blog entries to describe the new network virtualization features that were in Solaris 11 Express:
- Part 1 introduced the concept of network virtualization and listed the basic virtual network elements.
- Part 2 expanded on the concepts and discussed the resource management features.
- Part 3 demonstrated the creation of some of these virtual network elements.
- Part 4 demonstrated the network resource controls.
All of the features described in those blog entries and that paper are also available in Solaris 11. It is possible that some details have changed, but the vast majority of the content is unchanged.
Tuesday Jan 31, 2012
By Jeff Victor on Jan 31, 2012
Next week - February 8, to be exact - I will host a session near Detroit, Michigan. You can attend by registering online. Two other Solaris experts - Dave Miner and Alex Barclay - will join me as we explain new Solaris 11 features such as the Image Packaging System and Automated Installer, network virtualization and resource controls, Immutable Zones, and ZFS Encryption and other new security features.
Registration is not required, but available seating is filling up quickly, so don't wait!
Thursday Nov 10, 2011
By Jeff Victor on Nov 10, 2011
You can download Solaris 11.
Friday Oct 28, 2011
By Jeff Victor on Oct 28, 2011
- Accelerate internal, public, and hybrid cloud applications
- Optimize application deployment with built-in virtualization
- Achieve top performance and cost advantages with Oracle Solaris 11–based engineered systems
Don't miss the Oracle Solaris 11 launch in New York on November 9. Register Today!
Tuesday Oct 11, 2011
By Jeff Victor on Oct 11, 2011
The Launch Event will be held in New York City, at Gotham Hall on Broadway. Space is limited, so if you want to attend in person you should register online. A webcast of the event will also be available. Registration is available for both.
I have registered, so if you attend perhaps I will see you there!
Monday Sep 12, 2011
By Jeff Victor on Sep 12, 2011
Oracle Solaris 11 includes the new major feature sets that are available in Solaris 11 Express, released in November 2010, and much more. You can find a complete description and download link of this Early Adopter release at oracle.com.
If you are not currently a member of the Oracle PartnerNetwork (OPN), you still have two choices:
- Learn more about OPN and register at http://www.oracle.com/partners/en/opn-program/index.html
- Begin to experience key new features by downloading Solaris 11 Express
We are looking forward to helping you learn all about these exciting new features and the benefits you will derive from them!
Thursday Aug 18, 2011
By Jeff Victor on Aug 18, 2011
Oracle Solaris 11 Express is now available on Oracle Exadata Database Machines, enabling you to benefit from all of the OLTP and DW performance of Exadata hardware, and the industry-leading scalability and availability characteristics of Oracle Solaris.
For details, see the press release.
Tuesday Feb 08, 2011
By Jeff Victor on Feb 08, 2011
This is the third in a series of blog entries that discuss the network virtualization features in Oracle Solaris 11 Express. Part 1 introduced the concept of network virtualization and listed the basic virtual network elements that Solaris 11 Express (S11E) provides. Part 2 expanded on the concepts and discussed the resource management features which can be applied to those virtual network elements (VNEs).
This blog entry assumes that you have some experience with Solaris Zones. If you don't, you can read my earlier blog entries, or buy the book "Oracle Solaris 10 System Virtualization Essentials" or read the documentation.
This entry will demonstrate the creation of some of these VNEs.
For today's examples, I will use an old Sun Fire T2000 that has one SPARC CMT (T1) chip and 32GB RAM. I will pretend that I am implementing a 3-tier architecture in this one system, where each tier is represented by one Solaris zone. The mythical example provides access to an employee database. The 3-tier service is named 'emp' and VNEs will use 'emp' in their names to reduce confusion regarding the dozens of VNEs we expect to create for the services this system will deliver.
The commands shown below use the prompt "GZ#" to indicate that the command is entered in the global zone by someone with sufficient privileges. Similarly, the prompt "emp-web1#" indicates a command which is entered in the zone "emp-web1" as a sufficiently privileged user.
Fortunately, Solaris network engineers gathered all of the actions regarding the management of network elements (virtual or physical) into one command: dladm(1M). You use dladm to create, destroy, and configure datalinks such as VNICs. You can also use it to list physical NICs:
GZ# dladm show-link LINK CLASS MTU STATE BRIDGE OVER e1000g0 phys 1500 up -- -- e1000g2 phys 1500 unknown -- -- e1000g1 phys 1500 down -- -- e1000g3 phys 1500 unknown -- --We need three VNICs for our three zones, one VNIC per zone. They will also have useful names - one for each of the tiers - and will share e1000g0:
GZ# dladm create-vnic -l e1000g0 emp_web1 GZ# dladm create-vnic -l e1000g0 emp_app1 GZ# dladm create-vnic -l e1000g0 emp_db1 GZ# dladm show-link LINK CLASS MTU STATE BRIDGE OVER e1000g0 phys 1500 up -- -- e1000g2 phys 1500 unknown -- -- e1000g1 phys 1500 down -- -- e1000g3 phys 1500 unknown -- -- emp_web1 vnic 1500 up -- e1000g0 emp_app1 vnic 1500 up -- e1000g0 emp_db1 vnic 1500 up -- e1000g0 GZ# dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID emp_web1 e1000g0 0 2:8:20:3a:43:c8 random 0 emp_app1 e1000g0 0 2:8:20:36:a1:17 random 0 emp_db1 e1000g0 0 2:8:20:b4:5b:d3 random 0
The system has four NICs and three VNICs. Note that the name of a VNIC may not include a hyphen (-) but may include an underscore (_).
VNICs that share a NIC appear to be attached together via a virtual switch. That vSwitch is created automatically by Solaris. This diagram represents the NIC and NVEs we have created.
Now that these datalinks - the VNICs - exist, we can assign them to our zones. I'll assume that the zones already exist, and just need network assignment.
GZ# zonecfg -z emp-web1 info zonename: emp-web1 zonepath: /zones/emp-web1 brand: ipkg autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: exclusive hostid: fs-allowed: GZ# zonecfg -z emp-web1 zonecfg:emp-web1> add net zonecfg:emp-web1:net> set physical=emp_web1 zonecfg:emp-web1:net> end zonecfg:emp-web1> exit
Those steps can be followed for the other two zones and matching VNICs. After those steps are completed, our earlier diagram would look like this:
Packets passing from one zone to another within a Solaris instance do not leave the computer, if they are in the same subnet and use the same datalink. This greatly improves network bandwidth and latency. Otherwise, the packets will head for the zone's default router.
Therefore, in the above diagram packets sent from emp-web1 destined for emp-app1 would traverse the virtual switch, but not pass through e1000g0.
This zone is an "exclusive-IP" zone, meaning that it "owns" its own networking. What is its view of networking? That's easy to determine. The zlogin(1M) command inserts a complete command-line into the zone. By default, the command is run as the root user.
GZ# zoneadm -z emp-web1 boot GZ# zlogin emp-web1 dladm show-link LINK CLASS MTU STATE BRIDGE OVER emp_web1 vnic 1500 up -- ? GZ# zlogin emp-web1 dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID emp_web1 ? 0 2:8:20:3a:43:c8 random 0
Notice that the zone sees its own VNEs, but cannot see NEs or VNEs in the global zone, or in any other zone.
The other important new networking command in Solaris 11 Express is ipadm(1M). That command creates IP address assignments, enables and disables them, displays IP address configuration information, and performs other actions.
The following example shows the global zone's view before configuring IP in the zone:
GZ# ipadm show-if IFNAME STATE CURRENT PERSISTENT lo0 ok -m-v------46 --- e1000g0 ok bm--------4- --- GZ# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 lo0/? static ok 127.0.0.1/8 lo0/? static ok 127.0.0.1/8 lo0/? static ok 127.0.0.1/8 e1000g0/_a static ok 10.140.204.69/24 lo0/v6 static ok ::1/128 lo0/? static ok ::1/128 lo0/? static ok ::1/128 lo0/? static ok ::1/128
At this point, not only does the zone know it has a datalink (which we saw above) but the IP tools show that it is there, ready for use. The next example shows this:
GZ# zlogin emp-web1 ipadm show-if IFNAME STATE CURRENT PERSISTENT lo0 ok -m-v------46 --- GZ# zlogin emp-web1 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 lo0/v6 static ok ::1/128An ethernet datalink without an IP address isn't very useful, so let's configure an IP interface and apply an IP address to it:
GZ# zlogin emp-web1 ipadm show-if IFNAME STATE CURRENT PERSISTENT lo0 ok -m-v------46 --- GZ# zlogin emp-web1 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 lo0/v6 static ok ::1/128 GZ# zlogin emp-web1 ipadm create-if emp_web1 GZ# zlogin emp-web1 ipadm show-if IFNAME STATE CURRENT PERSISTENT lo0 ok -m-v------46 --- emp_web1 down bm--------46 -46 GZ# zlogin emp-web1 ipadm create-addr -T static -a local=10.140.205.82/24 emp_web1/v4static GZ# zlogin emp-web1 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 emp_web1/v4static static ok 10.140.205.82/24 lo0/v6 static ok ::1/128 GZ# zlogin emp-web1 ifconfig emp_web1 emp_web1: flags=1000843
mtu 1500 index 2 inet 10.140.205.82 netmask ffffff00 broadcast 10.140.205.255 ether 2:8:20:3a:43:c8
The last command above shows the "old" way of displaying IP address configuration. The command ifconfig(1) is still there, but the new tools dladm and ipadm provide a more consistent interface, with well-defined separation between datalink management and IP management.
Of course, if you want the zone's outbound packets to be routed to other networks, you must use the route(1M) command, the /etc/defaultrouter file, or both.
Next time, I'll show a new network measurement tool and the ability to control the amount of network bandwidth consumed.
- Threads, as fas the eye can see...
- Hands-On Training
- Improving Manageability of Virtual Environments
- Fastest Engineered System
- Comparing Solaris 11 Zones to Solaris 10 Zones
- More SPARC T5 Performance Results
- IDC Reviews New SPARC T5 and M5 Servers
- New SPARC Servers Outrun the Competition - by Leaps and Bounds!
- New SPARC Chips, New Servers
- /Politics, Global Topics
- /SPARC SuperCluster
- /Solaris 10 Containers
- /Solaris 11