Using Oracle Solaris Unified Archives to Replicate an Oracle Solaris Cluster 4.2 Cluster

1. Install
   

   and configure a new cluster from archives. The cluster is in the
   
   initial state, just like one created using the standard method of
   
   running scinstall(1M) on the
   
   potential cluster nodes.

2. Restore
   

   cluster nodes from recovery archives created for the same nodes, due
   
   to hardware failures on the nodes.

3. Replicate
   

   a new cluster from archives created for the nodes in a source
   
   cluster. The software packages and the cluster configuration on the
   
   new nodes will remain the same as in the source cluster, but the new
   
   nodes and some cluster objects (such as zone clusters) can have
   
   different system identities.

This
document shows how to replicate a new cluster from the Oracle Solaris
Unified Archives.

Replicating
clusters can greatly reduce the effort of installing the Oracle
Solaris OS, installing Oracle Solaris Cluster packages, configuring
the nodes to form a cluster, installing and configuring applications,
and applying SRUs or patches for maintenance. All of this can be done
in one installation.

At
first, the source cluster needs to be set up. This effort cannot be
omitted. However, for use cases such as engineered systems, archives
can be created for the source cluster nodes as master images, and can
be used to replicate multiple clusters, as many as one wants, using
this feature in Oracle Solaris Cluster 4.2 software. The more
clusters you replicate, the more effort it saves.

The
procedure to replicate a cluster includes the following steps:

• Set
  
  up the source cluster and create archives for each source node.
• Set
  
  up the AI server and the DHCP server.
• Run
  
  scinstall on the AI server to
  
  configure the installation of the new cluster nodes, and add the new
  
  nodes to the configuration of the DHCP server.
• Boot
  
  net install the new cluster nodes.

These
same steps also apply to configuring a new cluster and restoring
cluster nodes. The only difference is that, when running scinstall
on the AI server, the menu options and inputs are different.

Requirements
of the new cluster

When
replicating a new cluster from a source cluster, the new cluster
needs to have the following similar hardware configuration as the
source cluster:

• Same
  
  number of nodes.
• Same
  
  architecture.
• Same
  
  private adapters for cluster transport.

As
for the archives used to install the new cluster nodes, they must be
created for the global zone, not from a non-global zone; do not mix
using clone and recovery
types of archives; and exclude datasets on shared storage when
creating archives and migrate the data separately.

Currently,
Oracle Solaris Unified Archive only supports ZFS, therefore other
file systems and volume managers that are configured in the source
cluster are not included in the archive. They can be migrated using
the corresponding methods of those types.

If
quorum servers or NAS devices are configured in the source cluster,
the cluster configuration related to these objects are carried to the
new cluster. However, the configuration on these hosts is not
updated. Manual intervention is needed on these systems for them to
function in the new cluster.

Set up the
source cluster and create an archive for each node

The
source cluster can be set up with any of the existing supported
methods. Let’s use a two-node cluster (host names source-node1
and source-node2)
with HA for NFS agent and a zone cluster as simple examples just for
illustration purpose. This source cluster has a shared disk quorum
device.

The
zone cluster myzc is
configured, installed, and booted online, and the two zone cluster
nodes have host name source-zcnode1
and source-zcnode2.

# clzonecluster status === Zone Clusters === — Zone Cluster Status — Name Brand Node Name Zone Host Name Status Zone Status —- —– ——— ————– —— ———– myzc solaris source-node1 source-zcnode1 Online Running source-node2 source-zcnode2 Online Running

The
HA for NFS resource group (named nfs-rg)
contains a logical-hostname resource nfs-lh,
an HAStoragePlus resource hasp-rs,
and a SUNW.nfs resource nfs-rs.
The local mount point for the NFS file system is /local/ufs as shown
using clresource show.

# clresource list -v Resource Name Resource Type Resource Group ————- ————- ————– nfs-rs SUNW.nfs:3.3 nfs-rg hasp-rs SUNW.HAStoragePlus:10 nfs-rg nfs-lh SUNW.LogicalHostname:5 nfs-rg # clresource show -v -p HostnameList nfs-lh === Resources === Resource: nfs-lh — Standard and extension properties — HostnameList: source-lh-hostname Class: extension Description: List of hostnames this resource manages Per-node: False Type: stringarray # clresource show -p FilesystemMountPoints hasp-rs === Resources === Resource: hasp-rs — Standard and extension properties — FilesystemMountPoints: /local/ufs Class: extension Description: The list of file system mountpoints Per-node: False Type: stringarray

On
each node in this source cluster, create an unified archive for the
global zone. The archive can be of clone
type or recovery type. A clone
archive created for the global zone contains multiple deployable
systems. Non-global zones are excluded from the global zone, and each
non-global zone is a single deployable system. A recovery
archive created for the global zone consists just one single
deployable system. Installing from a global zone recovery archive
installs the global zone as well as the non-global zone that it
contains. Check the Unified
Archive introduction blog for more details.

Since
there is a zone cluster in the source cluster, create a recovery
archive for each node so that the zones will get installed.

As
an example, we use archive-host
as
the name of the host that is mounted under /net and
exports a file system to store the archives.

source-node1# archiveadm create -r /net/archive-host/export/source-node1.sua source-node2# archiveadm create -r /net/archive-host/export/source-node2.sua

Note
even though the recovery archive contains multiple boot environment
(BE), only the current active BE is updated to function in the new
cluster.

Set Up the
AI server and the DHCP server

The
new cluster nodes must be networked with a designated AI server, a
DHCP server, and the host for storing the archive files. The AI
server must have static IP and be installed with Oracle Solaris 11.2.
The archive files created for the source cluster nodes must be
accessible from the AI server as well. The archive location can be an
autofs mount point mounted via /net/host, an http, or an https
URL.

On
the AI server, install the Oracle Solaris Cluster installation
package ha-cluster/system/install.
Do not install other Oracle Solaris Cluster packages. Installing this
package also installs the Oracle Solaris installadm
package and the Internet Systems Consortium (ISC) DHCP package
service/network/dhcp/isc-dhcp,
if they are not yet installed.

# pkg publisher PUBLISHER TYPE STATUS P LOCATION solaris origin online F http://ipkg.us.oracle.com/solaris11/release/ ha-cluster origin online F http://ipkg.us.oracle.com/ha-cluster/release # pkg install ha-cluster/system/install

Run
scinstall on the AI server to
configure the installation

The
tool to configure the AI installation of the new cluster nodes is
/usr/cluster/bin/scinstall. As
the same tool to configure a new cluster in the non-AI method, it
gives a different menu when it runs at the AI server. Use the
interactive method (running the scinstall
command without any options) instead of the command line options
method, as it gives help texts and prompts.