Reducing OpenSolaris (Part1: Approaches and Strategies)
Pátek VI 26, 2009
This entry is part of OpenSolaris JeOS (Just Enough Operating System) Prototype workshop.
Abstract
Most modern mature OSes distributions allow users to tune set of installed packages by simple procedures like selecting install profile Basic CLI server or Rich GUI Workstation and many of them offer even more precision profiling to better suit user OS usage profile - like for example profile optimized by size and amount set of packages in CLI server mode to get close to ideal OS profile for Virtual Images creation.
This document present approaches and procedures how user can easily create this OpenSolaris install profiles - set of OS packages for OpenSolaris 200811, 200906 and prove then they are good fit for various user requirements.
Approach
Use advanced features of OpenSolaris (new) ZFS root to create one OpenSolaris OS install profiles for experimenting with multiple bootable OpenSolaris 200811, 200906 setups on one OS installation to speed up Light Weight Server Oriented OpenSolaris Image creation knowledge gain processes.
Target is, list of needed/not needed packages in our OpenSolaris JeOS configurations which can be used in future in Automated Installer to install OpenSolaris 200811, 200906 release JeOS.
This approaches was developed part of WebSynergy Server Oriented Virtual Images Creation and resulted image can be obtained here Simplify Your Portal Deployment: Web Space Server 10 VM Template
Approaches to OpenSolaris reduction
We define our target as Reduced OS image - User Level OpenSolaris JeOS , in similar way as use in Creating OpenSolaris based JeOS (For Amazon EC2), any of our JeOS configurations must be still usable for Administrator logins and Administrator must be able to process in JeOS enviroment diversity of tasks. This is main difference from approaches targeting primary very strong OS Minimalization, when main target is Back-Box like Appliances to only get minimized OS environment to just execute not interactively some specialized tasks - like Automatic Installer focussed enviroment for Network Installations, this sort of JeOS don't have requirement of any sort of rich Administrator Environment/Access enviroment.
OS Reduction Strategies
There are 3 main reduction strategies, we can use with standard OpenSolaris Live CD GUI installation as starting point to create our Server Oriented OpenSolaris JeOS image:
- Reduce booting time
- Reduce size of image
- Reduce number of packages
There is an obvious limitation then these optimization targets can be archived only for distribution image, due to dependencies handled in external OS Repositories outside of our control for already released OS version, user can initiate just by installation of one package trigger massive packages installation driven by enforced dependencies, so most reduction effort will be lost in this situations. For deep minimalization we need target packages and dependencies refactoring, this process is currently out of scope if this effort.
OS Reduction Methods
To get reduced OpenSolaris JeOS image we can use this 3 method:
- Reconfiguration - Don't change size/packages, just change OS runtime configurations and behavior
- Targeting - Selecting most influencing configuration ( by size and/or number of packages and/or by category) - passive approach
- Profiling - Try to define needed set of OS functionality (what set of packages we need) - active approach
Many times you need to combine this approaches and process them in loops to get final results. One challenge is then OpenSolaris have very strong dependencies enforcement in OS Repositories and in pkg tool, is hard evaluate scenarios what if I select/de-select this (set of) package(s), I will demonstrate it later in general issues section.
Variety of JeOS images
From JeOS variety we see possibility to have these levels of JeOS based images and these possible gains:
| Level | Name | Main Method | Booting speed | Resulted Size | No of Packages | Comments |
| L0 | Original FULL GUI | Clone | 0 | 0 | 0 | Original Live CD or other default profile image |
| L1 | Original FULL GUI in CLI | Reconfiguration | ++ | 0 | 0 | Just disable GUI and services |
| L2 | Reduced GUI | Targeting | 0 | ++ | + | Remove most top sized user pkgs |
| L3 | Reduced GUI in CLI | Targeting + Reconfiguration | 0 | ++ | + | Remove most top sized user pkgs + CLI mode |
| L4 | Remote X inn CLI (No GUI env) | Targeting GUI apps | ++ | ++++ | +++ | Not GUI envs, only GUI libs if needed for installed OS pkgs |
| L5 | Pure CLI | Profiling | +++ | +++++ | +++++ | No X or GUI libs at all |
| --- | ------- | --------- | ------- | -------- | -------- | These bellow is out of scope, because they will required special creation procedures |
| L6 | (Over) Minimalized CLI | Profiling | ??? | ??? | ??? | Very small user space, like for Black Box Virtual Applainces |
| L7 | Hardcore CLI | Profiling | ??? | ??? | ??? | This is special purpose image and can have broken depndecies - non upgradeable, like Live CD installer stuff |
| L8 | Tarball based CLI | Profiling | ??? | ??? | ??? | This is special purpose image , like root in Live CD or FLASH disk |
Yes, JeOS is not only about OS reduction, its about to match OS functionality to hosted applications , there can be packages in OpenSolaris REPO to add, or even ones with don't have there and they need to be added like JDK 6 ???
Right JeOS setup
How to prove then we have right JeOS setup ?
We need to ensure then created JeOS comply with this main target audience requirements :
- Created JeOS is consistent from OS point of view, pkgs and OS image can be refreshed, updated, installed/removed and so on (all OS Admin tools are present and are functional)
- Crerated JeOS is complete from Admin point of view, like there is one instance of tool for common Admin tasks (like one editor) , Admin can login remotely login , have persistent configurations, stress on security
- Crerated JeOS is suitable for running selected application , run functional test on hosted app(s) to be sure, then JeOS is feature complete form app point of view
Main Idea - Use different Boot Environments in single image
OpenSolaris have possibility for layered applications installations (ones which don't depend on OpenSolaris IPS repository) to separate OS and App install trees. In this manner we can have different configurations of OpenSolairs boot environments (BE are basically independent ZFS roots) to access one instance of installed application. This way we can easily test different OS setups in single image by simple OS reboots.
OpenSolaris BE is part of Snap upgrade feature Snap Update PDF
Multiple Boot Environments
We will like to have this test OpenSolaris BE (Boot Environments)
Reduction Level BE name Source Result Reduction Approach L0 OpenSolaris Full LiveCD base Full LiveCD base GUI Original L0 osol0906gui Full LiveCD clone Full LiveCD base GUI Original L1 osol0906cli Full LiveCD clone Full LiveCD base CLI Original| - Reconfigured L2 osol0906size Full LiveCD clone Reduced LiveCD installation Remove - Targeted (User - Size) L4 osol0906rgui Full LiveCD clone Reduced LiveCD installation Remove - Targeted (No GUI Env - No GUI pkgs) L5 osol0906redu Full LiveCD clone Reduced LiveCD installation Profile - Uninstall Rest L5 osol0906inst Empty BE Fresh bootable installation Profile - Fresh Install
In next posts I will demonstrate how to create this different OpenSolaris Reduced environments in separate BE (Boot Environments)
|
|
|
|
Tags: jeos opensolaris virtualbox virtual_appliances