Business Ready Convergence with Oracle Solaris 11

The goal of this blog entry is to familiarize the reader with the reasoning and methodologies behind easing deployments of Oracle Solaris, as enabled by technologies in Oracle Solaris 11.  The entry is intended to build awareness and instill confidence for deploying Oracle Solaris 11 technologies in large installations; whether on the SuperCluster platform or an an all x86-based platform.

After reading this entry you will get a better idea on the what, the why, and the a bit on the how of 5 important guiding principles that have driven us toward simplifying operations and maintenance of Solaris environments.

First, we focused on providing a better approach for building out infrastructure. Customers operate in a world where a system is deemed useful only when it is totally available for applications and related services, henceforth referred to as a business ready state.   Elements in Oracle Solaris 11 that ease the process of getting systems to the business ready state are reviewed.

Second, we recognized that the pressures associated with cost-reduction are continuing to grow.  We review what we’ve done in order to help answer our customers’ requests for lowering investment of capital and time needed to derive benefit from Oracle Solaris environments.

Third, we highlight the relevance of providing determinism and consistency that persists across deployments of physical and virtual environments. This is core to enabling predictable massive-scale roll-outs.

Fourth, we review the benefits of investment protection that are realizable on Oracle Solaris because its software packages are the same across SPARC and x86 hardware platforms.

Finally, we discuss the available capabilities surrounding guaranteed reversibility, which are fundamental to today’s maintenance and update operational requirements.

The blog entry explains why the challenges associated with rolling out, and subsequently maintaining, traditional operating system installations arose in the enterprise over the past decade; how we’ve recognized that we were facing an opportunity to make improvements to the distribution model of Solaris, by extending it from what it once had been.   A better approach was needed in order to keep pace with the evolutionary demands driven by businesses and consumers of infrastructure.  This blog also touches on the built-in tools provided for transitioning from Oracle Solaris 10 (or earlier) to Oracle Solaris 11, as well as specific technical innovations that can ease installation and life cycle management.

A bit about core deployment technologies at play

A number of ongoing innovations in installation, configuration, cloning and package management have made the deployment processes easier.

Automated Installer (AI)

Automated Installer is a robust framework for conducting hands-off, automated installations of Solaris 11 – on SPARC or x64 platforms.  It is extensible and extremely powerful, making it easy to express deployment logic in terms of automated workflows.

Service Management Facility (SMF)

With the maturity of Oracle Solaris Service Management Facility (SMF) entering its 8th year since introduction in Oracle Solaris 10, it has continued to play an increasing role in the installation, configuration and overall serviceability of the operating system.   Previously, in large Oracle Solaris deployments, customers have had to write their own deployment systems to be functionally usable. Now Oracle Solaris 11 provides that functionality as part of the product. It leverages key assets of the Oracle Solaris ecosystem such as SMF, ZFS, and Image Packaging System (IPS).

Image Packaging System (IPS)

The Oracle Solaris Image Packaging System is the result of many years’ of effort in surveying the industry, architecting for scalability and for tomorrow’s needs, and collaborating with customers to define a new approach to package management. Image Packaging System provides a smarter and safer means to perform OS software updates. It offers:

  • Increased predictability that system updates are executed correctly, due to automatic dependency checking and resolution
  • A means to easily revert to a previous state by saving the boot environment (the current system state) before a new boot environment is created, where changes are made.
  • Increased business value by combining with other Oracle Solaris ZFS features such as encryption, thin provisioning, and de-duplication to increase efficiency

 The following Oracle Solaris technologies make the migration process onto Solaris 11 easy:

  • Automated Installer (AI) – provides an architectural deployment framework for creating and managing the lifecycle of installation services, and installs client systems
  • System Management Facility (SMF) configuration profiles – provide “personalization” configuration information applied immediately on reboot of newly-installed systems or zones
  • JumpStart to Automated Installer (JS2AI)  – a facility that aids System Administrators in transitioning elements of legacy Solaris JumpStart infrastructure into the AI framework
  • Distribution Constructor – enables the creation of customized boot images, typically useful for building media for distribution
  • Boot Environments – offers insurance against undesired application-level conditions that may arise after upgrades or changes to system-level files, coupled with ability to upgrade the OS without disturbing the running system.  This is a refinement of the Live Upgrade facility available in earlier versions of Oracle Solaris, providing enhancements whilst leveraging ZFS. Further, this capability is available for use in Zones, too, making Zones even more flexible.
  • Oracle Solaris Zones integration – allows System Administrators to leverage the same processes, methodologies and tools for deploying and administering non-global zones as well as global zones
  • Image Packaging System – provides an enterprise-class framework for serving software packages, offering capabilities to ease the lifecycle management, software accessibility, automatic dependency resolution, image minimization and distribution

 

Why Customers Care about Simplifying Their Deployments

Historically, computing platforms were about having one, possibly two or three application workloads sharing a single compute resource. If a certain application needed to be modified, it would be re-rolled out on another computing platform.

Increasingly, over time, many of the compute platforms are being used to host dozens of unlike application environments, and at the same time, are expected to be re-provisioned at a push of a button.  Hardware abstraction capabilities that offer virtualization solutions are now considered to be part of the core definition of application deployment and infrastructure readiness.

With growing complexity in scale and building out scale-out infrastructures, customers and the industry at large have been forced to deal with multiple vendors and an array of solution providers. This growing complexity of product capabilities provides an entirely new set of complexity in feature co-existence, which in turn puts to question many of the assumptions about software versions and application-to-operating system behavioral relationships.

Considering the above nuances, datacenter managers can’t help but find themselves in dealing with an amazing set of modern requirements.  While this directly contributes to increased complexity, customers (with an ever-increasing focus on simplification) are goaled on driving cost reduction.  It is precisely because of the intent to ease this cycle that a radical approach to simplified deployment was seen as being necessary within the Oracle Solaris eco-system.

One of the complex metrics businesses use when choosing and deploying infrastructure is a valuation of “what am I going to get, what will it cost me and how much effort is necessary to put in to get my systems to be “business ready”?   It is with the notion of aiding systems administrators and making it easier for them to get the systems to be at the “business ready” state that has been a key focus area in producing Oracle Solaris 11. 

The re-design of the installation experience brings about many benefits due to its integration with a completely revamped software package management system (IPS) and the use of Oracle Solaris ZFS as the root file system.

The Value of “Business Ready”

End-users mold infrastructure components into a collection of service offerings that are, ultimately, the measure of how infrastructure is able to provide value to the business.   This partially the notion behind the relevance of converged infrastructure.  Getting to “business ready” state entails not just being able to install the system, but also includes being able to automate its configuration, create virtualized environments on it, conduct configuration that is in-line with accepted standards and policies, validate the configuration, apply security hardening, provision necessary users and enforce appropriate network parameters, and then layer specific application software and configuration files on top.

The system that goes through that cycle is deemed ready for “hand-over” and use by the teams that are responsible for running application services.  Based on the requirements of the late 1980’s, Solaris JumpStart did, and has continued to perform a certain amount of that set of activities, and does it well.  Overtime, however, it became apparent that in the “real world” the amount of additional work that has to be done to get systems to be “business ready” is more involved.

In an effort to automate propagation of configuration information for applications, security policies and other elements, customers invested in utilities like the JumpStart Enterprise Toolkit (JET), JumpStart Architecture for Securing Solaris (JASS), which subsequently became known as Solaris Security Toolkit (SST). There were important collaborative efforts in the open development communities, that also lead to tools such as the Solaris Package Companion.

These utilities add value in drastically easing deployments by encapsulating various types of customizations and policies reflective of the actual business need. It can be observed that overtime the amount of capabilities provided by core JumpStart is limited whilst the aforementioned tools compensate and provide the rest of the required functionality for customers.   The mere presence on these tools is illustrative of the fact that Solaris JumpStart had been designed with assumptions that are simply no longer true in the modern day datacenter.  Older assumptions needed to be challenged and re-visited, and a new set of assumptions needed to be considered as Oracle Solaris 11 was developed.

Understanding the Costs of Deployment and Maintenance

The challenges associated with deploying and maintaining systems running traditional Oracle Solaris versions became evident as more demands were being placed on the Oracle Solaris JumpStart framework with the arrival of many new Oracle Solaris features. Over time, the demands have grown to include aspects of post-installation configuration and customization, as well as support for a greater variety of installation methods. Fast-forwarding to today, Oracle Solaris 11 can now be installed on a wide variety of hardware platforms and offers flexibility for different types of installation methods.

Additionally, the historical challenges associated with package management and patching often resulted in an increased cost of deployment and maintenance of systems. Package management in SVR4 lacked automatic dependency resolution tools and its software management functionality was limited. For many organizations, this translated to exposure to service downtime as well as increased risk of a downgraded customer experience. These side effects were due, in part, to the fact that systems were not self-sustaining.  This had brought about the cost of having to write scripts and further seeing those scripts break with release of new features. Couple that with the inability to rollback safely, that lead to system administrators lacking confidence in the consistency of maintenance and upgrade process. As these issues became more clear, there came a strong desire for simplified safety tools that would help mitigate the risk associated with managing system lifecycle; providing for predictable updates and safe rollback scenarios became one of the fundamental requirements.

All of the challenges associated with deploying and maintaining systems running in Solaris 10 and earlier could be classified into the following categories of rising costs: fragility, unpredictability and risky to maintain.

On one hand, the business logic had to be expressed through scripts that in turn had to be maintained by customers. Whenever a new feature in the operating system was introduced or updates had to be applied to it, it could “break” some of the custom-written scripts and at the same time impact the ability to rollback quickly and easily. Whenever someone would leave the company there would be an increase in fragility and that would drive the cost through unpredictability of complex environments. Scale-out and virtualization demands would complicate the process because now the issues would be exacerbated and have wider impact.

application-ready1

Figure 1. Bottom-up steps, and tools, necessary to bring a system to a “business ready” state

Differences between package management and patching technologies resulted in increased cost of maintenance yielding environments customers were becoming uncomfortable maintaining and being held responsible for.  This becomes increasingly important, as the functionality in releases has continued to evolve, with introduction of Zones and associated patching capabilities in Oracle Solaris 10.

Often times this meant a delay in customers’ scheduling updates and upgrades; lack of reversibility and consistency led to questionable predictable behaviors and ultimately risk – because the environment could not be rolled back easily for any reason its stability would be put in question.

Re-designing Deployment and Maintenance

It became apparent that businesses processes were being kept in custom scripts and that this approach is no longer scale-worthy in modern datacenter economics. There was a need to let go of some of the older approaches and bring in mechanisms that are more maintainable and that actually support policies.

This was additionally driven by the need for newer architectures, leveraging improvements in network bandwidth and other industry-led requirements such as hardware commoditization and storage and network ubiquity.

In developing Oracle Solaris 11 we recognized that there are many established tools and facilities that had come in to Solaris ecosystem earlier, such as Zones, ZFS, SMF, all of which had been designed to provide value for dynamic changes in the business world. To address and provide solutions to the aforementioned challenges, to give System Administrators a framework that brings a newly installed system much further, significantly closer to the “business ready” state, taking away the need for scripting a set of new features had been designed from the ground-up; these features are Automated Installer and Image Packaging System.

The figure below shows a comparison of deployment and maintenance technologies present in Oracle Solaris 11 and Oracle Solaris 10.

s10vsS11

Figure 2. Comparison of associated elements between Oracle Solaris 10 and Oracle Solaris 11

There are a number of important points to be made regarding this comparison. The left-hand portion corresponds to many pieces, some of which dating back to mid-1980’s, having slowly grown over the past 30 years to keep up with the demands of the changing datacenter economics. The right-hand portion of the figure corresponds to Oracle Solaris 11. It looks much cleaner and simpler than the left-hand side. This simplicity is the result of many functions being consolidated into the Image Packaging System based on the valuable lessons that have been learned over the years from supporting hundreds of thousands of Oracle Solaris deployments.

The Oracle Solaris 10 technology overview on the left is much more involved because, at its core, there were a number of technologies that had been accepted as fundamental layers for many years. Additionally, alternative technologies had not yet been available (such as Oracle Solaris ZFS and Image Packaging System).

At the heart of provisioning systems with Oracle Solaris 11 is a modern, common installation engine that acts as a central vehicle, leveraged by different (interactive and hands-off) installation methods.  There is a network-based software distribution and packaging technology (IPS) that goes beyond the traditional JumpStart-based process by offering many new improvements in tackling software lifecycle management. These improvements were accomplished by re-visiting some of the legacy design principles that had defined earlier deployment technologies. Those legacy design principles were challenged as to their relevance for today’s enterprises. Oracle Solaris engineers created a modernized design that addresses today’s needs while also offering a fully capable and extensible environment for meeting future requirements.

The illustration is meant to show how the newer tools and technologies in Oracle Solaris 11 have enabled a cleaner, simpler, and more efficient deployment model. The re-design offered by the Image Packaging System is, in large part, responsible for the simplification. Oracle Solaris 10 continues to have a strong deployment footprint and, at this time, an indefinite support window in accordance with Oracle’s industry-leading lifetime support policies.

Understanding Deployment Strengths of Oracle Solaris 11

The below illustration gives a pictorial view of how much more capable Oracle Solaris installation and deployment framework has become as a result, over the course of time.

application-ready3

Figure 3. Improved capabilities added over time, enabling “business ready” state

In some ways, there are methods for performing procedures that have been refined, and in some ways there are new methods for provisioning systems.   Oracle Solaris 11 can now handle more of what customers want to do – as a product, reducing the need for complex scripting, and reducing the chance of resulting in a combination of software that may not have gone through the desired validation cycles. Because of its modularity, the Automated Installer framework is extensible, and lends itself to additional future enhancements – much more capably then JumpStart does.

Deployment Predictability Through the Eyes of “Business Ready”

The common installation engine provided in Oracle Solaris 11 allows for a cleaner, scalable and extensible installation experience, whether installation is performed interactively or non-interactively.  While there are two categories of installation – interactive and non-interactive (hands-off), the focus of this document is on the non-interactive installation, which is known as Automated Installer.

First, let’s review the two interactive installation methods that are available:

  • Using a Text installer – for cases where a server system has a virtual console and no monitor attached and the installation questions need to be answered in an interactive manner
  • Using a LiveMedia installer (formerly LiveCD and LiveDVD) – that targets systems that have a monitor and can render a graphical user interface for the purposes of providing a good look and feel of the system desktop and features, prior to deciding on installing it

Additionally, there is an installation method that allows for full automation, enabling commonality and consistency in provisioning physical and virtual resources — appropriately named the Automated Installer.

Under the hood of the deployment technologies is a common engine that these installation methods share. The presence of this common engine provides the ability to enable different installation methods to share features and functionality, and to provide extensibility for the new capabilities that will be identified in the future.

These tools provide a rich set of capabilities and focus on reducing the time it takes to install and then configure the system. A consistent mechanism for getting Zones deployed is now possible, too.  When needed, Zones can be pre-configured and installed as part of the deployment process. This happens the first time the system boots, immediately following the initial installation sequence. Alternatively, if a previously-deployed system may require Zones in the future, the creation processes can re-use the infrastructure to provision Zones. This offers the benefit of achieving consistency by using the same SMF profile and AI manifest technologies to configure and provision environments where Zones might be required.

While interactive installation procedures are typical and appropriate for systems used in exploring a new software release, production deployments of any operating system must use automated deployment technologies to scale deployment using a cost-effective level of staffing. Existing technologies such as Oracle Solaris JumpStart provide a basic framework for automated deployment. However, in almost all cases, the customer must provide a significant set of site-specific enhancements to build out deployment of the complete software stack required for each application. With Oracle Solaris 11 Automated Installation (AI), customers obtain a ready-to-run automation framework that can deploy significant and complex software stacks with little or no additional effort on the customer’s part.

To begin using AI, the customer only needs access to the Oracle Solaris 11 package repository. The AI services are first installed using pkg or Package Manager to install the installadm package. Once the package is installed, the user then uses the installadm command to set up the network boot services that each AI client boots from to run the installation. The initial boot service is established as the default boot service for all AI clients and DHCP is configured to provide the necessary boot parameters for SPARC or x86 clients.

Each AI boot service is configured with one or more manifests that specify the deployment to be performed. A service will typically have a default manifest that specifies some standard deployment of Oracle Solaris 11 used across most systems. Additional manifests are then configured for more custom deployments, with manifests assigned to clients through the use of criteria sets. The criteria sets consist of IP or MAC addresses, client architecture or client memory size and are configured using the installadm command. An AI manifest specifies the storage layout for the system: the devices used to construct the root ZFS pool and additional desired ZFS pools, the ZFS datasets within the pools, and sizes of swap and dump ZFS volumes. The software payload to be installed is also specified in the manifest in the form of IPS publishers and packages supplied by those publishers. To assist in deploying applications that are designed to be installed on both Oracle Solaris 11 and prior Oracle Solaris versions, AI’s manifest also supports specification of SVR4 packages and cpio archives.

One way in which Automated Installation provides enhanced scalability of deployment for more complex environments is via a feature called Derived Manifests.

If a large number of fairly distinct deployments are required, it can often be burdensome to maintain a corresponding number of static AI manifests.  It is possible to take advantage of configuration profile templates, where a single profile can use a group of distinct variables to set different configuration parameters on different clients.

Furthermore, it can sometimes be easier in to provide a script that is run by the client at installation time to generate the manifest dynamically, based on the characteristics of the client. AI provides easy-to-use support for such specific scripting via the aimanifest interface, executing in a controlled environment that ensures the script interacts correctly with the Automated Installer and will be compatible with future enhancements to AI.

Automated deployment of a system also requires that the system be configured to be usable once it is rebooted. AI provides a comprehensive system configuration capability using Service Management Facility (SMF) profiles, leveraging an expanded use of SMF as the configuration mechanism in Oracle Solaris 11. As a result, when additional configuration parameters are migrated in future releases to SMF, configuration of those parameters through AI will be automatically possible. The profiles to be applied to each system are specified via criteria, configured using the installadm command.

To perform an Automated Installation, the administrator boots the target system, selecting a network boot. The network parameters are configured using DHCP, and the boot loader is downloaded from the AI server using either HTTP (for SPARC systems) or TFTP (for x86 systems). On x86 systems, a GRUB boot menu is presented, allowing interactive selection of the desired boot mode. The Oracle Solaris net boot image and associated root archive is then obtained from the AI server in order to boot the client. Finally, the AI manifest and configuration profile are downloaded, and the installation is executed. ZFS pools and datasets are created and mounted, the software payload is installed, and the configuration profile is copied into the installed system. Once the installation is completed, the system may automatically reboot into the installed Oracle Solaris instance.

Investment Protection with Identical Experience Across SPARC and x64 platforms

Similarly as in earlier versions of Solaris, but in a more refined fashion from SVR4 package meta-clusters, Oracle Solaris 11 Automated Installer and IPS offer a means of expressing how software sets are defined and how they are to be installed. These software sets are known as group packages.

There are three specific group installation packages that have been defined:

  • Desktop Group package — This group targets a desktop use-case, historically known as LiveUSB and LiveCD (now, due to growth in image size and popularity of DVD media over CD media, referred to as LiveDVD).
  • Small Server Group package — This group targets systems that are to be deployed with a minimal image as a starting point, to be potentially grown later. This group package consists of an image containing a set of drivers needed to boot the system and a limited set of networking services needed to identify the system on the network. After installing this group package, the user could subsequently add other desired software services.
  • Large Server Group package — This group package targets a server instance where a number of additional software services are pre-installed. It includes many more network services, including common network services such as DHCP and Apache.

The reason we have these is because now, with IPS, we have a more robust and predictable way of providing layered software, whereas historically we did not have a good clean way of doing that.  This approach fits nicely with models that take into account the size of initial image being deployed.   Because IPS is network-repository based, instead of a push model it is a pull model; this allows for the end-user system to gain granularity regarding specific sets of software (and their versions) to be distributed.

Furthermore, IPS offers the notion of “fat packages”, whereby fewer larger packages can be used instead of having to deploy multiple fine grained packages.  In Oracle Solaris 11 IPS repositories, there are SPARC and x86 binaries located in the same package, including man pages and localizations. Files have special tags, specifying the architecture on which they need to be installed.  This way only the files that are appropriate for a specific platform are actually installed (or updated).  This provides for much fewer files to manage, as part of the deployment process. This is of great benefit for software that is multi-platform by nature. For software that is highly platform-specific, but is available on Solaris, this is still much more desirable than the alternatives.

Reducing Risk by Designing with Reversible Maintenance in mind

Reversibility of system maintenance or upgrades is also a key requirement of a deployment technology.  Special areas of the boot disks are known as Boot Environments and they exist for the purposes of reducing outages and minimizing risk by maintaining multiple known states. When the time comes to perform system maintenance, whether a package update or system upgrade, the system figures out whether this operation will introduce a change to the system’s boot environment structure and automatically creates another boot environment into which the said changes are introduced. The current boot environment is unaffected and is available for the end-user to rollback into, in case a new boot environment introduces unanticipated risk through some unforeseen and unexpected behavior.

This is provided through tight co-engineering with the Oracle Solaris ZFS technology, on top of which the root file system rests. This means that the COW (copy-on-write) mechanisms of Oracle Solaris ZFS design are fully available to be used in accomplishing these higher-level operational requirements. This is one of the many indicators of how Oracle Solaris 11 continues to add value and be unique in the space of enterprise-grade operating systems. Besides having boot environments being created automatically by the update and upgrade processes, it is also possible to create boot environments at will, using the beadm command.

How Deployment and Lifecycle Management Have Improved

To understand how the entire set of components is integrated together with Image Packaging System, it is helpful to look at the steps involved in the installation and configuration workflow. Figure 1 illustrates the workflow elements and the following paragraphs explain the components of Automated Installer and Image Packaging System that are involved in executing the installation steps. It shows a number of important elements, each of which play a core role in the overall process of deploying services, and doing so with cloud-like characteristics.

solaris-deployment-overview

Figure 4. Overview of installation and configuration workflow

Starting from the center of the figure where there are empty boxes representing the servers that are waiting to be provisioned with application services, notice the arrows on the bottom leading up to them. Each of the arrows comes from a distance, expressive of being on the network (an internal “data highway”), across which services are provisioned. One of the first things that must happen is identification of the appropriate operating system image to be installed onto a system. This is a function that is performed by the Automated Installer and the single interface, installadm.  The administrator identifies which OS image to use and then sets that up using installadm.  As and when a system is installed, the actual behavior of the payload that gets installed is defined by an Automated Installation manifest, which is a file containing basic information about software to be installed, and the network address location where this software comes from. This “pull” mechanism is performed from an Image Packaging System (IPS) repository.

The operating system image itself could either be one that is supplied by Oracle, or a customized image that is crafted by the end-user. The customization of such an image is something that is usually done for the purposes of addressing minimization requirements, controlling what software components comprise an image, what software packages have to be installed, and what higher-level services have to be made available on the system in order for it to be considered ready for servicing its users. (It is possible that one of the services that the system would need to offer could be a number of Oracle Solaris Zones. A consistent mechanism for getting Zones deployed is now possible, too.  Zones can be installed at first boot after OS installation by using the same SMF profile and AI manifest technologies to configure and provision the zones.

When an installation manifest is created, it can optionally include appropriate tags for expressing Zones and associated parameters that define how these Zones are to be created. When the system is deployed and Oracle Solaris is installed, appropriate zone manifests are placed on the file system. When the system boots for the first time, an SMF service is triggered that provides the intelligence to install Zones in accordance with installation manifests and system configuration profiles specific to those Zones. This provides the mechanism for making it possible to deploy Zones through Automated Installer, and is one of the key differentiators that makes it easy to deploy Zones under Oracle Solaris 11. The rectangles on the bottom of Figure 1 represent various forms of manifests that result in consistent, well-defined collections of packages (services), ranging from those supplied by Oracle to those resulting from manifest customizations by the end-user, culminating in customized “golden” images.

For use-cases that require building specific media for interactive installations, a key enabling technology that aids in this customization process is known as Distribution Constructor. Distribution Constructor gives an end-user the ability to construct a customized OS image and to then either burn it onto physical media or boot it over the network. The customization offers modularity in selecting what the end-user sees, what packages are deployed, and what services are available for the purposes of booting Oracle Solaris and then deciding what to install. In the case of building network-bootable images, Distribution Constructor allows for creation of a mini-root that contains a certain set of services that are operational for the purposes of getting Oracle Solaris installed. The actual content of what gets installed is controlled by the Automated Installer manifest, which supports customization of what packages, and essentially what services would constitute a fully customized “golden” installation.

The same consistent mechanisms are used to deploy customized images, also known as “golden” images amongst system administrators. Irrespective of whether the end-user chooses an Oracle-supplied stock Oracle Solaris 11 installation or the one that they’ve customized on their own, when the installation is deployed it takes advantage of descriptions of software packages that need to be installed and reaches out to the specified network-based software repositories, from which such software packages are retrieved.

The software packages are installed with automatic dependency resolution. Even if and when customers want to deploy Oracle Solaris Zones, exact mechanisms get invoked for building out Oracle Solaris Zones, leading to consistency, reduced risk of disparate software sets, and improved velocity in deployments.

There are a number of technologies that helps make this possible, including those that have been mentioned already, such as SMF, service configuration profiles, ZFS and IPS, which provides the network-based software repository where software packages reside and are pulled from during installation. It is also possible to have IPS software repositories hosted in files, and not on the network – if that should be a preference for developers or system administrators. IPS is illustrated by a red arrow on the right, just off the center in the above figure.

De-coupling Configuration from Installation

As the system’s installation process comes to an end, certain system configuration parameters, illustrating personalities, are applied to the system. These procedures ensure that the system is auditable and therefore compliant in accordance with desired policies. While there are default settings that are available, most of the time there’ll be some level of customization that users will want to perform. For example, an administrator may want to indicate what time zone the system should reflect, what users should be created, what their passwords are, what name services the system should participate in, etc. Streamlining and de-coupling system configuration steps from previously having it semi-integrated in the JumpStart process is one of the fundamental improvements in easing the process of deploying Oracle Solaris 11 systems. The technology that is responsible for this is known as System Configuration Tool, and it is tightly co-engineered with the Service Management Facility (SMF) technology that has been included since Oracle Solaris 10.

Taking this approach allows Oracle Solaris to leverage the value of previously delivered technologies, many of which have now moved beyond the 8-year maturity mark. System Configuration Tool creates System Configuration SMF profiles that are used to provide system configuration information and provision systems as indicated by the shrink-wrapped items shown near the top of Figure 1. The shrink-wrapped icons indicate that the systems, which were initially shown as empty boxes, have now evolved into colorful service-ready servers. Each server may have its own value to the end-user, its own purpose with its own set of services, and may even utilize Oracle Solaris Zones.

Simplifying the Update Process

Thus far, the focus of the discussion has been on technologies that make it easier to deploy the system anew. There is another part that helps measure the lowered cost of systems and that is the effort required in keeping the system up-to-date and maintaining it. What happens after an installation is

complete and a software component on that system or the operating system itself needs to be updated the next release?

There are a number of integrated technologies that aid in making this process much easier then previously possible. One of these, IPS, has already been briefly mentioned. IPS repositories not only contain versions of software packages that are used to initially install a system, but the repositories can also host updated versions of software packages. In fact, one of the strengths of IPS is its ability to empower developers to publish their own customized software packages and make them available for deployments.

The second and third technologies that are important in the update and upgrade processes are Boot Environments and Fast Reboot. In Figure 4, boot environments are illustrated by the shadows slightly below and to the left of the deployed systems.

Additional engineering work has gone into providing a consistent administrative user-experience for managing Zones, too. Specifically, Zone administrators can now take advantage of Boot Environments from inside zones, so that if there is a need for a change in the zone, the zone administrator becomes self-sufficient in implementing that change without having to rely on the system administrator responsible for the entire physical server. Just like in the Global Zone, the beadm command is a recognized and supported command to be invoked inside zones. This is extremely helpful for customers that are undergoing aggressive consolidation planning and are deploying multiple virtual environments with a focus on reducing cost and minimizing downtime. What other operating system provides automatic no-cost insurance? What other operating system can extend a consistent administrative experience for boot environments and storage management of virtualized environments at no additional upfront or ongoing cost?

Fast Reboot technology is illustrated in Figure 1 by the red arrows forming a circle, The circle of arrows is indicative of the shorter time required when booting into a newly upgraded environment (or booting into a previously created boot environment). The Fast reboot technology is available on SPARC and x86 platforms and significantly reduces the time needed to bring the system back in service by bypassing lower-level hardware self-tests and loading the Oracle Solaris kernel from a known location on disk. The reason the lower-level hardware tests can be by-passed is because, at the time Fast Reboot is invoked, the operating system is in a state where it has previously performed such tests and can therefore trust the presence of those devices. Clearly, if devices have been removed or added since the last boot, then it will be necessary for the operating system to validate such changes and the assumptions of a fast reboot mechanism would no longer apply.

Simplifying the Roll-back Process

The roll-back process of reversing to a previous state (if an update resulted in a failed condition) is enabled by the integration of the IPS package management system with ZFS snapshot technology. As previously touched upon, this provides that necessary element that offers assurance by providing reversibility. This helps reduce upgrade risk because in the past, prior to Solaris 11 (and even in other/earlier operating systems), you’d have to manually untangle the web of updates to get to a known pre-update state, and that translates to increased cost and lack of assurance that this process will be successful.

Transitioning from Oracle Solaris JumpStart

Many end-users of Oracle Solaris 11 are existing Oracle Solaris 10 customers. A natural question to ask is how to make the transition from Oracle Solaris 10 to Oracle Solaris 11, and how to have the new deployment architecture coexist with the existing one. Oracle Solaris 11 addresses this problem in several ways.

Customers with existing Oracle Solaris JumpStart deployments will find it beneficial to know that existing Oracle Solaris JumpStart services can be hosted on Oracle Solaris 11. The way this is accomplished is by adding a network boot package and a number of files, just as done traditionally on Oracle Solaris 10. This would allow JumpStart and Automated Installer services to be hosted on the same system running Oracle Solaris 11. While Oracle Solaris 11 requires an Oracle Solaris 11 deployment server, that deployment server is also capable of serving Oracle Solaris 10 JumpStart clients. Thus, there is no need to maintain multiple Oracle Solaris deployment infrastructures. The existing Oracle Solaris 10 setup_install_server and add_install_client scripts provided on the Oracle Solaris 10 media will operate correctly to configure Oracle Solaris 10 JumpStart services on Solaris 11 servers. Additionally, the DHCP configuration required for Solaris 11 will not conflict with Solaris 10 deployments that use DHCP. If DHCP is not used already for Solaris 10 JumpStart, there will be no conflicts.

Furthermore, Solaris 11 is capable of installing existing SVR4 packages designed for Oracle Solaris 10. Therefore, existing site-specific content or third-party software will usually still be installable on Oracle Solaris 11. Oracle does recommend converting these packages to the IPS format, though, in order to take advantage of the robustness and reliability of IPS.  It is also possible to host a  separate instance of a JumpStart server on a system running Oracle Solaris 11 in a co-located manner, side by side with Automated Installer services.

For customers that are looking to re-deploy existing Oracle Solaris 10 workloads in an unmodified manner, directly on top of Oracle Solaris 11, Oracle encourages the use of the mature and time-proven Oracle Solaris Zones technology. If there are reasons why a particular workload may not be executed natively in Oracle Solaris 11, then a Physical-to-Virtual (P2V) technology may be of value. Oracle Solaris 11 comes with support for Oracle Solaris 10 Zones, which provide a secure execution environment, giving a sense to the applications running inside it that they’re operating on top of an Oracle Solaris 10 system. This is one of the tools that can help in the transition process.

Furthermore, in Oracle Solaris 11, Oracle is providing a facility known as js2ai. The goal of the facility is to aid customers with existing JumpStart deployments in migrating those environments and the associated configuration files into appropriate configuration files for Oracle Solaris 11 Automated Installer.

Specifically, the following three elements (used by JumpStart-based installations) are evaluated and translated into their equivalent objects for Oracle Solaris 11 Automated Installation:

  • sysidcfg configuration files
  • Profiles files
  • Rules files

Most of the values from Oracle Solaris 10 are reusable, but some now have to be handled slightly differently because they are better handled in concert with the rest of the overall build-out process. This was one of the design decisions made to provide a solution for some of the previously mentioned challenges with installations based on the legacy JumpStart design.

Simply, js2ai attempts to convert existing JumpStart rules, profiles and sysidcfg files to AI equivalents. The conversion is done on a best-effort basis, with full logging. Error reporting is provided in cases where a particular value has no direct convertible equivalent. In these cases, information is also provided about how to resolve them.

js2ai converts a JumpStart rules file into Automated Installation criteria definitions, JumpStart profiles into Automated Installation manifests, and sysidcfg configuration files into SMF configuration profiles. Once a converted configuration has been generated, the customer will need to examine it to ensure that the results are as desired. The remaining step that is required is to convert any JumpStart begin and finish scripts to their Automated Installation equivalents. Often, this is mostly a matter of deleting the scripts, as the most common usages (applying patches, installing additional customer or third-party packages) are supported directly by Automated Installation. The main case where scripts will actually be converted is where a begin script was used to generate a JumpStart profile programmatically (often called a “derived profile”).  These can be converted to “Derived Manifest scripts.

Additionally, instructions on scenarios that may require manual intervention are provided. In the process of deploying Oracle Solaris 11 services, the first step would be to deploy an Oracle Solaris 11 system manually. That system could also be configured to host Oracle Solaris 10 JumpStart services. Then the process of using js2ai entails simply converting rules to AI criteria, translating profiles to AI manifests, and translating sysidcfg to SMF configuration profiles.

The process also includes using installadm to publish resulting manifests and profiles to AI services. When it comes to converting post-install tasks and finish scripts, the logic expressed in those needs to be converted to SMF services that get executed on the first boot of the system. IPS is used to package up these SMF services and then publish them to the IPS repositories. From the IPS repositories they can be downloaded by a client system as part of an Automated Install process. Patching of systems is effectively a non-issue as updates to systems are delivered through (currently monthly) Service Repository Updates. These updates leverage IPS as the vehicle for updating software packages to newer versions of packages, and dealing with maintenance windows that are now far smaller — on the order of seconds or minutes as opposed to hours or days. What makes the overall process much less time-consuming is the flexibility added with support for in-house mirroring of Oracle-hosted IPS repositories. This enables customers to build out IPS services on the inside of the network infrastructure by syncing only a number of selected IPS servers with those hosted by Oracle. The ability to then deploy systems from the local, regionalized servers grants customers more control and freedom. It also avoids building-in dependencies on access to the Internet during the installation and updating phase(s) of servers being provisioned.

Conclusion

Having read this blog you now have seen how the following 5 important points reflect on improved capabilities in Oracle Solaris 11:

  • 1 – A better approach to getting infrastructure to be “business ready”, by providing a cleaner architecture for deploying application workflows
  • 2 – Cost-reduction by lowering investment of time needed to deploy, and subsequently maintain fewer standard operating system environments
  • 3 – Commonality and determinism in provisioning physical and virtual environments, enabling predictable massive-scale deployments
  • 4 – Investment protection offered by availability of same software packages across SPARC and x86 infrastructure
  • 5 – Reversibility during maintenance and upgrade operations

In conclusion, Oracle Solaris 11 simplifies the administration model and the deployment process for enterprise customers by reducing the time and cost associated with provisioning and maintaining Oracle Solaris environments. Massive-scale creation of virtualized environments is done on par with building out bare-metal systems, ensuring predictability through the tools used to deploy and maintain Oracle Solaris environments. Additionally, cross-platform support for SPARC and x86 architectures provides an extremely similar end-user administration experience, enabling investment protection when choosing between various hardware platforms.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: