Forgot your password?
New user?
Document Actions
Part VII: Comoonics Enterprise Copy
Usage guide for the versatile com-ec tool.
Userguide for the Linux Cloning Concept
2007-03-06
| Revision History | ||
|---|---|---|
| Revision 1.4 | 2007-11-21 | RR |
| revised revision | ||
| Revision 1.3 | 2007-05-16 | MH |
| revised revision | ||
| Revision 1.2 | 2007-03-22 | MH |
| revised and added examples | ||
| Revision 1.1 | 2007-03-06 | MH |
| added information about v2 | ||
| Revision 1.0 | 2006-07-20 | MG |
| first draft version | ||
Abstract
This userguide describes the cloning configuration used for the Linux Cluster infrastructure. It includes a description on how to use the cloning software Comoonics Enterprisecopy and how to use the preconfigured template based cloning configurations.
Table of Contents
- About this guide
- Comoonics Enterprisecopy Suite
- The Comoonics Enterprisecopy process definition file
- The Comoonics Enterprisecopy configuration
- A. Examples
- B. Glossary
This document uses the following conventions
Warning
Warning
This is a warning.
Caution
Caution
This cautions the reader.
Hint
Tip
This is a hint.
Note
Note
This is a note.
File name
file.extension
Directory name
directory
Commands to be typed
commandApplications Names
applicationPrompt of users command under bash shell
bash$
Prompt of root users command under bash shell
bash#
Prompt of user command under tcsh shell
tcsh$
Environment Variables
VARIABLE
Emphasized word
word
Quoted text
“quote”
Code Example
<para>Beginning and end of paragraph</para>
This userguide is devided in two sections. One section describes the basic usage of the Comoonics Enterprisecopy tools, and the other one the preconfigured configuration files . The appendix gives some exampes and step by step instructions for specific cloning exercises.
This document, Comoonics Enterprisecopy - Users guide for the Linux Cloning Concept, is copyrighted (c) 2007 by ATIX GmbH. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
Linux is a registered trademark of Linus Torvalds.
No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.
All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.
Feedback is most certainly welcome for this document. Send
your additions, comments and criticisms to the following
email address : <grimme (at) atix.de> or
<hlawatschek (at) atix.de>.
The Comoonics Enterprisecopy Suite (comoonics-ec) is a software designed to help cloning and copying new Linux clusters or servers.
The comoonics-ec is part of the com.oonics cluster suite (comoonics-cs). It consists of two software packages - the comoonics-cs-py and the comoonics-ec-py packages. The comoonics-cs-py package holds the base python libraries and binaries for the Comoonics Clustersuite which is the base for the packages comoonics-ec-py. This package provides all libraries and binaries for the Comoonics Enterprisecopy functionality itself. Both packages should always be available as RPMs.
Note
The comonics-cs package also has to be installed to
fulfill all dependencies.
First of all the RPM libxslt-python has to be installed.
Note
As the dependency in RHEL4 U3 of the RPM libxslt-python is broken it has to be installed manually. That means download it with up2date --get libxslt-pyton and then install it manually with rpm -ivh /var/spool/up2date/libxslt-python-1.1.11-1.*.rpm
Use the up2date command to install the comoonics rpms up2date -i comoonics-cs comoonics-ec-py comoonics-cs-py
The main tool providing the functionality to the user is the com-ec
binary normally found in /usr/bin/com-ec.
If you call com-ec -h it will output a help screen as shown in Figure 1, “Execution of com-ec”
Figure 1. Execution of com-ec
root@node627b:~# com-ec -h
/usr/bin/com-ec [-h|--help] [-U|--noundo] [-v|--version] [-m|--modificationset value] [-x|--xslt value] [-n|--novalidate] [-X|--onlydisplay] [-S|--simulate] [-a|--ask] [-s|--sets value] [-d|--debug] [-c|--copyset value] file [valuepath=value]*
The comoonics Enterprisecopy binary parses an xml configfile and then goes through every copy and modificationset and
does it.
-h|--help this help
-U|--noundo don't do the undoing if anything goes wrong
-v|--version output the version
-m|--modificationset value <name>|all only do all or the given modification set (default: None)
-x|--xslt value preconvert xmlfile with given xsltfile. (default: /opt/atix/comoonics-cs/xsl/comoonics-enterprise-copy.xsl)
-n|--novalidate novalidate don't validate the xml. Handle with care!!!
-X|--onlydisplay only display the resulting dom as xml
-S|--simulate don't execute anything just simulate
-a|--ask ask before any command is executed
-s|--sets value Execute the given sets (serperated by ,), regular exception are also accepted (default: None)
-d|--debug toggle debugmode and be more helpful
-c|--copyset value <name>|all only do all or the given modification set (default: None)
Calling com-ec -h or com-ec without any options shows which options you can choose.
com-ec can be called in different operational modes.
com-ec can be called with the debug and ask flags set. The debug (-d) flag enables the output of debug information whearas the ask (-a) flag enables an interactive processing. Both flags set, gives a good possibility to debug and verify the enterprise-copy configuration.
The com-ec processes all instructions given by the enterprise-copy process definition (ec-pd).
The process definition can be defined in a single XML file. (The enterprise-copy process definition file - ec-pdf).
As the process definition and the resulting process definition file can get very large and complex to adapt, com-ec supports XSL transformation. A XML based process definition template (ec-pdt) can be used together with a XSL file to create the process definition.
The basic part of the com-ec command is the enterprise-copy process
definition file (ec-pdf).
This is a normal XML file following the DTD found
in /opt/atix/comoonics-cs/xml/comoonics-enterprise-copy.dtd. A detailed
description of the
ec-pdf can be found in
the section called “The Comoonics Enterprisecopy process definition file”. A
really basic ec-pdf is shown in Figure 2, “A basic ec-pdf for the comoonics-ec”
Figure 2. A basic ec-pdf for the comoonics-ec
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE enterprisecopy SYSTEM
"file:/opt/atix/comoonics-cs/xml/comoonics-enterprise-copy.dtd">
<enterprisecopy name='clone-bootdisk-partitions'>
<copyset name='copy-bootdisk' type='partition'>
<source type='disk'>
<disk name='/dev/sda'/>
</source>
<destination type='disk'>
<disk name='/dev/sdc'/>
</destination>
</copyset>
</enterprisecopy>
Every comoonics-ec ec-pdf needs a name describing the job to be done. In this case the name is clone-bootdisk-partitions which tells us the sense of this job is to clone the partitions of two disks. Every enterprisecopy process definition can have multiple childs of either copyset or modificationset. Basically the difference between a copyset and modificationset is that a copyset copies data described by the type from one source to one destination. Destitination or source themselves are again defined by a type and more children describing the type in more detail (again have a look at the section called “The Comoonics Enterprisecopy process definition file”). In this case either source or destination are of the same type disk. One describes the source disk and the other the destination disk.
After creating the enterprise copy process definition file (ec-pdf), the clone process can be started.
Warning
A misconfigured ec-pdf can destroy all your data! If you are unsure about your ec-pdf, you should first run the com-ec in the “debug” and “ask” mode.
You should never execute com-ec without using any command switch if you created a configuration for the first time, because every copy or modificationset can currupt all data on any stated destination. So first we will execute com-ec in the following way com-ec -a -d ./clone-bootdisk-partitions.xml
Tip
The ec-pdf creation can be simplified with the use of a xslt file
Figure 3. Example executing com-ec with baseconfig
root@node202a:~# com-ec -a -d ./clone-bootdisk-partitions.xml
-------Parsing document ./clone-bootdisk-partitions.xml--------
DEBUG:root:copyset, enterprisecopy
-----Execution of businesscopy clone-bootdisk-partitions-------
-----------Executing None copysets 1---------------------------
INFO:root:Executing copyset PartitionCopyset(copy-bootdisk:partition)
/usr/lib/python2.3/site-packages/comoonics/enterprisecopy/ComPartitionCopyset.py:45: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam("/tmp")
DEBUG:root:/sbin/sfdisk -d /dev/sdc
/sbin/sfdisk -d /dev/sdc (y,n)y
DEBUG:root:/sbin/sfdisk -d /dev/sda
/sbin/sfdisk -d /dev/sda (y,n)y
DEBUG:root:partition tables are the same. No need to update
-------Executing None modificationsets 0-----------------------
------Successfully executed businesscopy. ---------------------
You can savely ignore the RuntimeWarning. What the copyset does,
is to copy the whole partitiontable from device /dev/sda to
/dev/sdc. But the copyset detects that both partitions are equal so
no update has to be done. If you are really sure what you are doing you can leave the
options -a and -d so the whole process is executed
without debug messages and without asking before every command execution.
The Comoonics Enterprisecopy process definition file (ec-pdf) consists of “copyset” and “modificationset” definitions (sets).
Note
The sets are processed in sequential order, i.e. one set after the other.
The ec-pdf is a XML file defined by the comoonics-enterprise-copy.dtd
DTD. This file may be found in /opt/atix/comoonics-cs/xml/.
The parent element is the “enterprisecopy” with an unique “name”. The childs are “copyset” and “modificationset” elements.
Example:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE enterprisecopy SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-copy.dtd">
<enterprisecopy name='an_unique_name'>
<copyset .../>
<.../>
<modificationset .../>
<.../>
<enterprisecopy/>
A copyset is used to clone specific information from “source” to “destination” E.g. clone a complete filesystem to another device or backup mechanism. It is described by a unique “name”, the “type” attribute, a “source” and a “destination” element.
The source and destination elements contain information about their “type”, i.e. they can be either a resource on the physical disk or an archive definition.
Example:
<copyset type='a_defined_type' name='a_unique_name'>
<source type='a_defined_type'>
<a_source_definition/>
</source>
<destination type='a_defined_type'>
<a_destination_definition/>
</destination>
</copyset>
The partition copyset is used to copy partition tables
Right now the following source and destination types are supported:
Example:
<copyset type='partition' name='copy-rootdisk'>
<source type='disk'>
<disk name='/dev/mapper/mpath1'/>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-node627-02.tar' format='tar' type='file' compression='none'>
<file name='./partition-root.xml'/>
</archive>
</metadata>
</destination>
</copyset>
The LVM copyset is used to copy LVM volumegroups
Right now the following source and destination types are supported:
Example:
<copyset type='lvm' name='copy-lvm-root'>
<source type='lvm'>
<volumegroup name='vg_node627_sr'/>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-node627-02.tar' format='tar' type='file' compression='none'>
<file name='./lvm-root.xml'/>
</archive>
</metadata>
</destination>
</copyset>
The filesystem copyset is used to copy filesystem data and meta information
Right now the following source and destination types are supported:
The filesystem type represents a filesystem on the pysical disks connected to the computer. I.e. all meta information like filesystem type, blocksize and all data will be used to copy to or from a filesystem.
Example:
<copyset type='filesystem' name='copy-sharedroot'>
<source type='filesystem'>
<device id='sourcerootfs' name='/dev/vg_node627_sr/lv_sharedroot' options='skipmount'>
<filesystem type='gfs'/>
<mountpoint name='/'/>
</device>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-node627-02.tar' format='tar' type='file' compression='none'>
<file name='./fs-root.xml'/>
</archive>
</metadata>
<data>
<archive name='/data/linux/clones/in/li//root-clone-node627-02.tgz' format='tar' type='file' compression='gzip'/>
</data>
</destination>
</copyset>
The Bootloader copyset is used to copy bootloaders. Note that in the current release, only the “grub” bootloader is supported.
Right now the following source and destination types are supported:
Note
Only the “grub” bootloader is supported. The bootloader cannot be archived.
Example:
<copyset type='bootloader' name='bootloader'>
<source type='none'/>
<destination type='disk'>
<disk name='/dev/mapper/mpath3'/>
<bootloader type='grub'/>
</destination>
</copyset>
A modification set is used to perform modifications on a system. Typically host or cluster specific configuration files are modified. But generally all kind of modifications are possible.
The set is defined by a “type” and has an unique “name”.
The first child element defines the destination, where the underlying lists of modifications are done.
Example:
<modificationset type='a_valid_type' name='an_unique_name'>
<a_type_specific_destination>
<modification type='a_valid_type'>
<modification_information/>
</modification>
<modification type='a_valid_type'>
<modification_information/>
</modification>
</modificationset>
A modification can have a “requirement”, that has to be done before the real modification is performed
Example:
<modification type='a_valid_type'>
<requirement .../>
<the_real_modification/>
</modification>
The archive requirement extracts an archive to “dest”. After the modifications the archive is re-created again.
Right now, gzipped cpio archives are supported for modification requirements.
Tip
The gzipped cpio archives can be used to modify initrd images.
Example:
<requirement dest='/var/lib/com-ec/tmp' format='cpio' type='archive' name='/var/lib/com-ec/dest/initrd_sr-2.6.9-42.0.3.ELsmp.img'/>
A filesystem modificationset is used to perform modifications on a specific filesystem, e.g. file modifications or filesystem operations.
All modifications are done on the filesystem defined by the “device” and “filesystem” elements.
The filesystem modifciationset can use different “modifciations”.
Note
The modification is done with the filesystem mountpoint as current working directory.
Example:
<modificationset type='filesystem' name='an_unique_name'>
<device refid='a_device_reference'>
<modification type='a_valid_type'>
</modification>
<...>
</modificationset/>
A copy modification is used to copy files on a filesystem. It walks though a list of “file” definitions. A file definition for a copy modification uses a “sourcefile” and a “name” attribute.
Example:
<modification type='copy'>
<file sourcefile='path_of_the_sourcefile1' name='path_of_the_destination_file1'/>
<file sourcefile='path_of_the_sourcefile2' name='path_of_the_destination_file2'/>
<.../>
</modification>
A move modification is used to move a file in the filesystem. It walks through the list of “file” elements.
Example:
<modification type="move">
<file name="etc/myfile" sourcefile="etc/myfile.orig"/>
</modification>
A regular expression regexp modification is used to perform regular expression based search and replace operations to a file. E.g. you could search ifcfg-eth1 for a string like “IPADDR=.*” and replace this with a valid IP address like “ IPADDR=192.168.234.234”.
Note
Per default, a backup of the modified file is made. This can be disabled with
nopackup='1'.Example:
<modification search='IPADDR=.*' nobackup='1' type='regexp' replace='IPADDR=10.0.46.47'>
<file name='cluster/cdsl/1/etc/sysconfig/network-scripts/ifcfg-bond1'/>
</modification>
A typical com-ec user basically uses two different types of cloning configurations. One which locally clones the running cluster or single server- the localclone - and the other which clones a source cluster or single server on basis of a clone archive. This clone is called the masterclone
The following tasks have to be done to create a clone:
Create directories
mkdir -p /var/lib/com-ec/dest
mkdir -p /var/lib/com-ec/source
mkdir -p /var/lib/com-ec/tmp
The localclone procedure can be used to do the following tasks:
Create a bootable local clone of a running cluster or single server
Create a backup of a cluster or single server
Restore a cluster or single server from a backup
The following general information is needed to configure and run the clone process successfully.
- Name of node or cluster
The name of the single server or the cluster
- Source bootdisk and partition
The disk the cluster boots from. Normally this is
/dev/sdawhereas the bootpartition is/dev/sda1.- Destination bootdisk and partition
The disk and partition where the source bootdisk has to be cloned to.
- Destination rootdisk and partition
The destination partition where the sharedroot should be cloned to. Typically this is
/dev/sddand on some clusters it is partitioned so that the partition is/dev/sdd1. If the root resides on an unpartitioned disk the partition should be defined as the disk/dev/sdd.- Clone archives
The names of the clone archives. There are three archives defined. A metadata archive, a boot archive and a root archive. They reside at
node601:/data/linux/clones/- Kernelversion
The version of the running kernel
As the enterprise copy process definition file (ec-pdf) can be quite large, a enterprise copy process definition template (ec-pdt) can be used instead. This template file is much easier to adapt for new cluster configurations. An example of the template configuration file can be seen below. Every parameter except the clustername has a default value and can be left out. The default value will be taken instead. Figure 5, “Minimum Preconfiguration for localclone” shows a minimum configurationfile. Table 1, “Defaultvalues in the localclone configuration” shows all default values if not overwritten by the localclone configuration.
Figure 4. Template configuration file for comoonics-ec and a localclone
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE localclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<localclone source="disk" destination="disk">
<cluster name="node627" sourcesuffix="" destsuffix="C"></cluster>
<sourcedisks>
<bootdisk name="/dev/mapper/mpath0"/>
<rootdisk name="/dev/mapper/mpath1"/>
</sourcedisks>
<destdisks>
<bootdisk name="/dev/mapper/mpath3"/>
<rootdisk name="/dev/mapper/mpath4"/>
</destdisks>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</localclone>
Figure 5. Minimum Preconfiguration for localclone
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE localclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd"> <localclone> <cluster name="node202"></cluster> <kernel version="2.6.9-34.0.1.ELsmp"/> </localclone>
Table 1. Defaultvalues in the localclone configuration
| sourcedisks/bootdisk/@name |
/dev/sda
|
| sourcedisks/rootdisk/@name |
/dev/sdb
|
| destdisks/bootdisk/@name |
/dev/sdc
|
| destdisks/bootdisk/@name |
/dev/sdd
|
| kernel/@version | 2.6.9-34.0.1.ELsmp |
If you have created a localclone template, you need
the translation file that creates a full ec-pdf for the com-ec
command. This file can be
found at node601:/opt/atix/comoonics-cs/xsl/localclone.xsl.
To be able to use it for the localclone process, the file localclone.xsl has
to be copied to the local directory /etc/comoonics/enterprisecopy/ or must be used with full path.
com-ec has to be called as follows: com-ec -a -d -x
/opt/atix/comoonics-cs/xsl/localclone.xsl
/etc/comoonics/enterprisecopy/localclone.xml if you want debugging and
askmode enabled.
This procedure clones a running cluster to a second diskset. The cluster can be started from the localclone.
Figure 6. Template configuration file for comoonics-ec and a localclone
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE localclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<localclone source="disk" destination="disk">
<cluster name="node627" sourcesuffix="" destsuffix="C"></cluster>
<sourcedisks>
<bootdisk name="/dev/mapper/mpath0"/>
<rootdisk name="/dev/mapper/mpath1"/>
</sourcedisks>
<destdisks>
<bootdisk name="/dev/mapper/mpath3"/>
<rootdisk name="/dev/mapper/mpath4"/>
</destdisks>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</localclone>
After successfully verification the localclone process (i.e. the clone has been successfully booted) the clone process can be automatically executed via cron every night.
Figure 7. Commandsequence and output of a successfully executed localclone job
root@node202a:~# com-ec -x /opt/atix/comoonics-cs/xsl/localclone.xsl /etc/comoonics/enterprisecopy/localclone.xml -------------------com-ec : INFO Start of enterprisecopy node202a-local-clone-------------------- -------------------com-ec : INFO Executing all sets 8-------------------- 2007-11-21 14:16:06,653 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset PartitionCopyset(copy-bootdisk:partition) 2007-11-21 14:16:17,968 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemCopyset(copy-bootdisk-filesystem:filesystem) 2007-11-21 14:16:33,623 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset BootloaderCopyset(copy-bootdisk-sector:bootloader) 2007-11-21 14:16:35,374 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset PartitionCopyset(copy-rootdisk:partition) 2007-11-21 14:16:46,461 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset LVMCopyset(copy-rootdisk-lvm:lvm) 2007-11-21 14:16:51,129 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemCopyset(copy-rootdisk-filesystem:filesystem) 2007-11-21 14:30:59,837 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemModificationset(modifyroot:filesystem) 2007-11-21 14:31:02,595 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemModificationset(modifyboot:filesystem) -------------------com-ec : INFO Finished execution of enterprisecopy node202a-local-clone successfully--------------------
The Comoonics Enterpriscopycan also be used to create backups of a whole cluster or a single server. Note, that the backup again can be used as clone master to clone a new cluster or a single server.
Figure 8. Template configuration file for a single server backup
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE localclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<localclone source="disk" destination="backup" nolvm="no">
<node name="node631"/>
<sourcedisks><disk name="/dev/cciss/c0d0"/></sourcedisks>
<sourcepartitions>
<bootpartition name="/dev/cciss/c0d0p1"/>
<rootpartition name="/dev/cciss/c0d0p2"/>
</sourcepartitions>
<destarchive name="clone-node631" path="/data/linux/clones/in/li">
<metaarchive name="meta-clone-node631-01.tar"/>
<rootarchive name="root-clone-node631-01.tgz"/>
<bootarchive name="boot-clone-node631-01.tgz"/>
</destarchive>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</localclone>
Figure 9. Template configuration file for a cluster backup
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE localclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<localclone source="disk" destination="backup">
<cluster name="node000" sourcesuffix="" destsuffix="C"></cluster>
<sourcedisks>
<bootdisk name="/dev/sda"/>
<rootdisk name="/dev/sdb"/>
</sourcedisks>
<destarchive name="clone-node000" path="/mnt/archive/clones">
<metaarchive name="meta-clone-node000-04.tar"/>
<rootarchive name="root-clone-node000-04.tgz"/>
<bootarchive name="boot-clone-node000-04.tgz"/>
</destarchive>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</localclone>
Figure 10. Commandsequence and output of a successfully executed localclonejob
root@node000a:/etc/comoonics/enterprisecopy# com-ec -x /etc/comoonics/enterprisecopy/localclone.xsl /etc/comoonics/enterprisecopy/localclone.xml
--------------------Execution of enterprisecopy node000-local-clone---------------------------------
--------------------Executing None copysets 6---------------------------------
INFO:root:Executing copyset PartitionCopyset(copy-bootdisk:partition)
/usr/lib/python2.3/site-packages/comoonics/enterprisecopy/ComPartitionCopyObject.py:50: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam("/tmp")
INFO:root:Executing copyset PartitionCopyset(copy-rootdisk:partition)
INFO:root:Executing copyset LVMCopyset(copy-lvm-root:lvm)
INFO:root:Executing copyset FilesystemCopyset(copy-boot:filesystem)
INFO:root:Executing copyset FilesystemCopyset(copy-sharedroot:filesystem)
INFO:root:Executing copyset BootloaderCopyset(bootloader:bootloader)
/usr/lib/python2.3/site-packages/comoonics/ComBootDisk.py:43: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam(self.__tmp)
--------------------Executing None modificationsets 2---------------------------------
INFO:root:Executing modificationset FilesystemModificationset(modifyroot:filesystem)
INFO:root:Executing modificationset FilesystemModificationset(modifyboot:filesystem)
--------------------Successfully executed enterprisecopy.---------------------------------
The masterclone process creates a new cluster or single server from either an other installation or a previously created localclone backup.
The following general information is needed in order to configure and run the clone process successfully.
- Source and destination clustername or nodename
The clustername defines from which cluster com-ec is going to clone to which cluster. As a sideeffect the source and destination volumegroups are also set from the clusternames in the format “vg_{sourceclustername}_srC” and the new volumegroup name will be “vg_{destclustername}_sr”.
The name of either the source or destination node that shall be created.
- Source bootdisk and partition
The disk where the cluster boots from. Normally this is the disk corresponding to the source LUN whereas the bootpartition is always the fist one.
- Destination bootdisk and partition
The disk and partition where the source bootdisk has to be copied on.
- Destination rootdisk and partition
The destination disk and partition where the sharedroot resides on.
- Clone archives
The names of the clone archives. There are three archives defined. A metadata archive, a boot archive and a root archive. They reside at
node601:/data/linux/clones/- Kernelversion
Which kernelversion are we talking about. Normally it can be queried with uname -r
As the enterprise copy process definition file (ec-pdf) can be quite large, a enterprise copy process definition template (ec-pdt) can be used instead. This template file is much easier to adapt for new cluster configurations. An example of the template configuration file can be seen below. Every parameter except the clustername has a default value and can be left out. The default value will be taken instead. Table 2, “Defaultvalues in the masterclone configuration” shows all default values if not overwritten by the masterclone configuration.
Every node of the cluster has to be defined by the destcluster section. All network interfaces can be defined by nic sections. Don't define the network inferfaces for the cluster interconnect. Those are defined in the cluster configuration. If the root filesystem resides on a partition instead of a whole disk you can again use the destpartition section as stated in the localclone configuration.
Figure 11. Template file for comoonics-ec and a cluster masterclone
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE masterclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<masterclone source="backup" destination="disk">
<sourcecluster name="node000"></sourcecluster>
<destcluster name="node627" nodes="2">
<node name="node627a" nodeid="1">
<nic name="bond1" ip="10.0.46.47"/>
<nic name="bond2" ip="192.226.3.81"/>
</node>
<node name="node627b" nodeid="2">
<nic name="bond1" ip="10.0.46.48"/>
<nic name="bond2" ip="192.226.3.82"/>
</node>
</destcluster>
<sourcearchive name="clone-node000" path="/data/linux/clones/">
<metaarchive name="meta-clone-node000-04.tar"/>
<rootarchive name="root-clone-node000-04.tgz"/>
<bootarchive name="boot-clone-node000-04.tgz"/>
</sourcearchive>
<destdisks>
<bootdisk name="/dev/mapper/mpath0"/>
<rootdisk name="/dev/mapper/mpath1"/>
</destdisks>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</masterclone>
Figure 12. Template file for comoonics-ec and a single server masterclone
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE masterclone SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-clone.dtd">
<masterclone source="backup" destination="disk" nolvm="no">
<destnode name="node631">
<nic name="bond1" ip="10.0.46.53"/>
<nic name="bond2" ip="192.226.3.41"/>
</destnode>
<destdisks><disk name="/dev/cciss/c0d0"/></destdisks>
<destpartitions>
<bootpartition name="/dev/cciss/c0d0p1"/>
<rootpartition name="/dev/cciss/c0d0p2"/>
</destpartitions>
<sourcearchive name="clone-node625" path="/data/linux/clones/">
<metaarchive name="meta-clone-node002-01.tar"/>
<rootarchive name="root-clone-node002-01.tgz"/>
<bootarchive name="boot-clone-node002-01.tgz"/>
</sourcearchive>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</masterclone>
Table 2. Defaultvalues in the masterclone configuration
| destpartitions/rootdisk/@name | “destdisks/rootdisk/@name”1 |
| kernel/@version | 2.6.9-34.0.1.ELsmp |
| dirs/tmp/@name | /tmp/test |
In order to create a new cluster you have to provide a few additional
configuration files that are automatically copied on to the new cluster. All of these
files are found in /etc/comoonics/enterprisecopy and have to be
named as follows. The variable {clustername} has to set to the
cluster defined as destination cluster.
This is the cluster configuration file where a lot changes have to be made. All the node name's IP addresses and fencing have to be set for the new cluster. One should also clean up all cluster services. For an example see the section called “Example”
Besides the cluster configuration you should not forget to uncomment all mounts except from the root filesystem and all virtual filesystems. Because even the tempfilesystem and all other filesystems are normally not configured on new clusters and will be configured later when the cluster is up and running. For an example see the section called “Example”
Last but not least you should provide a hosts file where all IPs relevant to this cluster are defined. For an example see the section called “Example”
If you have created a masterclone template, you need
the translation file that creates a full ec-pdf for the com-ec
command. This file can be
found at node601:/data/services/ec/masterclone.xsl.
To be able to use the configuration files, node601:/data has to be mounted
on /data.
com-ec has to be called in the following way com-ec -a -d -x
/data/services/ec/masterclone.xsl
/data/services/ec/[hostname]/masterclone.xml if you want debugging and
askmode enabled.
Figure 13. Commandsequence and output of a successfully executed masterclone job
[root@node000a:/etc/comoonics/enterprisecopy# com-ec -x /opt/atix/comoonics-cs/xsl/masterclone.xsl /etc/comoonics/enterprisecopy/masterclone.xml -------------------com-ec : INFO Start of enterprisecopy /etc/comoonics/enterprisecopy/masterclone.xml-------------------- -------------------com-ec : INFO Executing all sets 8-------------------- 2007-11-22 10:50:21,026 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset PartitionCopyset(copy-bootdisk:partition) 2007-11-22 10:50:31,903 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemCopyset(copy-bootdisk:filesystem) 2007-11-22 10:50:52,579 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset BootloaderCopyset(copy-bootdisk-sector:bootloader) 2007-11-22 10:50:54,476 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemModificationset(modify-bootdisk-filesystem:filesystem) 2007-11-22 10:52:21,163 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset PartitionCopyset(copy-rootdisk:partition) 2007-11-22 10:52:32,622 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset LVMCopyset(copy-rootdisk-lvm:lvm) 2007-11-22 10:52:34,738 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemCopyset(copy-rootdisk:filesystem) 2007-11-22 10:54:50,909 comoonics.enterprisecopy.ComEnterpriseCopy INFO Executing copyset FilesystemModificationset(modify-rootdisk-filesystem:filesystem) -------------------com-ec : INFO Finished execution of enterprisecopy /etc/comoonics/enterprisecopy/masterclone.xml successfully--------------------
A. Examples
Caution
This is an example of a cloning procedure for server node000. When using other clusters especially other architectures recheck any path for sense !
This section discribes the process of backing up an already installed cluster.
First the dependent filesystems from node601 has to be mounted as follows:
root@node000a:~# mount node601:/data /data root@node000a:~# mount node601:/data/linux/clones/in/li /data/linux/clones/in/li
On the cluster change into directory /etc/comoonics/enterprisecopy
and verify that
localclone.dtd, localclone.xsl and
copysets.xslexist and are actual.
Then create a new file called localclone-node000-backup.xml
as follows.
Note
The files localclone.xsl, localclone.dtd
and copysets.xsl can be copied from node601
using the following commands:
root@node000a:~# scp node601:/data/services/ec/localclone.xsl /etc/comoonics/enterprisecopy/ root@node000a:~# scp node601:/data/services/ec/localclone.dtd /etc/comoonics/enterprisecopy/ root@node000a:~# scp node601:/data/services/ec/copysets.xsl /etc/comoonics/enterprisecopy/
Caution
The number in the archive file names (e.g. 04) should be increased. Otherwise an old release could be overwritten.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE localclone SYSTEM "localclone.dtd">
<localclone source="disk" destination="backup">
<cluster name="node000" sourcesuffix="" destsuffix="C"></cluster>
<sourcedisks>
<bootdisk name="/dev/sda"/>
<rootdisk name="/dev/sdb"/>
</sourcedisks>
<destarchive name="clone-node000" path="/data/linux/clones/in/li">
<metaarchive name="meta-clone-node000-04.tar"/>
<rootarchive name="root-clone-node000-04.tgz"/>
<bootarchive name="boot-clone-node000-04.tgz"/>
</destarchive>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</localclone>
The next step is to start the clone process as follows.
Caution
You may ignore all warning by tar on creating socket files or the like.
root@node000a:~# com-ec -x /etc/comoonics/enterprisecopy/localclone.xsl /etc/comoonics/enterprisecopy/node000/localclone-node000-backup.xml --------------------Execution of enterprisecopy node000-local-clone--------------------------------- --------------------Executing None copysets 5--------------------------------- INFO:root:Executing copyset PartitionCopyset(copy-bootdisk:partition) INFO:root:Executing copyset PartitionCopyset(copy-rootdisk:partition) INFO:root:Executing copyset LVMCopyset(copy-lvm-root:lvm) INFO:root:Executing copyset FilesystemCopyset(copy-boot:filesystem) INFO:root:Executing copyset FilesystemCopyset(copy-sharedroot:filesystem) /bin/tar: ./tmp/.font-unix/fs7100: socket ignored /bin/tar: ./tmp/fence_tool.bak/dev/log: socket ignored /bin/tar: ./cdsl.local/var/run/dbus/system_bus_socket: socket ignored [...] /bin/tar: ./cluster/cdsl/1/var/spool/postfix/private/tlsmgr: socket ignored /bin/tar: ./cluster/cdsl/1/var/spool/postfix/private/ifmail: socket ignored /bin/tar: ./cluster/cdsl/1/var/spool/postfix/private/proxymap: socket ignored --------------------Executing None modificationsets 0--------------------------------- --------------------Successfully executed enterprisecopy.---------------------------------
After an archive clone has been successfully created, the archive files have
to be moved to the right place. To do this, login to node601 and move the files
from /data/linux/clones/in/li to
/data/linux/clones/$HOST
Caution
This is an example of a cloning procedure for server node000. When using other clusters especially other architectures recheck any path for sense !
This section describes the process of backing up an already installed cluster.
On the cluster change into directory /etc/comoonics/enterprisecopy
and verify that localclone.dtd, localclone.xsl
and copysets.xsl exist and are actual.
Then create a new file called localclone-node000-backup.xml as follows.
Note
The files localclone.xsl, localclone.dtd
and copysets.xsl can be copied from node601
using the following commands:
root@node000a:~# scp node601:/data/services/ec/localclone.xsl /etc/comoonics/enterprisecopy/ root@node000a:~# scp node601:/data/services/ec/localclone.dtd /etc/comoonics/enterprisecopy/ root@node000a:~# scp node601:/data/services/ec/copysets.xsl /etc/comoonics/enterprisecopy/
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE localclone SYSTEM "localclone.dtd"> <localclone source="disk" destination="disk"> <cluster name="node000"></cluster> <kernel version="2.6.9-42.0.3.ELsmp"/> </localclone>
The next step is to start the clone process as follows.
root@node000a:/etc/comoonics/enterprisecopy# com-ec -x /etc/comoonics/enterprisecopy/localclone.xsl /etc/comoonics/enterprisecopy/localclone.xml
--------------------Execution of enterprisecopy node000-local-clone---------------------------------
--------------------Executing None copysets 6---------------------------------
INFO:root:Executing copyset PartitionCopyset(copy-bootdisk:partition)
/usr/lib/python2.3/site-packages/comoonics/enterprisecopy/ComPartitionCopyObject.py:50: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam("/tmp")
INFO:root:Executing copyset PartitionCopyset(copy-rootdisk:partition)
INFO:root:Executing copyset LVMCopyset(copy-lvm-root:lvm)
INFO:root:Executing copyset FilesystemCopyset(copy-boot:filesystem)
INFO:root:Executing copyset FilesystemCopyset(copy-sharedroot:filesystem)
INFO:root:Executing copyset BootloaderCopyset(bootloader:bootloader)
/usr/lib/python2.3/site-packages/comoonics/ComBootDisk.py:43: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam(self.__tmp)
--------------------Executing None modificationsets 2---------------------------------
INFO:root:Executing modificationset FilesystemModificationset(modifyroot:filesystem)
INFO:root:Executing modificationset FilesystemModificationset(modifyboot:filesystem)
--------------------Successfully executed enterprisecopy.---------------------------------
Caution
This is an example of a cloning procedure for server node631. In case an other server has to be created, make sure all data is adapted to the new server!
This section describes the installation process of a single server with the use of an archive clone. In this example the single server node631 will be created.
On cluster node601 goto /data/services/ec and create a
new directory with the name of the new node.
root@node601a:~# cd /data/services/ec/ root@node601a:/data/services/ec# mkdir node631 root@node601a:~# cd node631
Create the masterclone-node631.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE masterclone SYSTEM "masterclone.dtd">
<masterclone source="backup" destination="disk" nolvm="no">
<destnode name="node631">
<nic name="bond1" ip="10.0.46.53"/>
<nic name="bond2" ip="192.226.3.41"/>
</destnode>
<destdisks><disk name="/dev/cciss/c0d0"/></destdisks>
<destpartitions>
<bootpartition name="/dev/cciss/c0d0p1"/>
<rootpartition name="/dev/cciss/c0d0p2"/>
</destpartitions>
<sourcearchive name="clone-node625" path="/data/linux/clones/">
<metaarchive name="meta-clone-node002-01.tar"/>
<rootarchive name="root-clone-node002-01.tgz"/>
<bootarchive name="boot-clone-node002-01.tgz"/>
</sourcearchive>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</masterclone>
Create the file hosts_node631
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 node631 localhost.localdomain localhost
# This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/vg_local/lv_root / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/vg_local/lv_tmp /tmp ext3 defaults 1 2 LABEL=SW-cciss/c0d0p3 swap swap defaults 0 0 /dev/hda /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0 /dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0
To boot the new server, perform the follwing steps:
On node601 execute the following command:
/opt/atix/comoonics-fencing/fence_ilo -x /data/services/ec/ILOMapLiveCD.xml -a node631-rc -l root -p somepassword
At the ILO console of the new server: login as root and do:
Change password with comoonics# passwd
Start sshd with comoonics# service sshd start
Start portmap with comoonics# service portmap start
Check the dhcp assigned IP address with comoonics# ifconfig
Login to new server with ssh.
bash$ ssh root@10.0.45.172 root@10.0.45.172's password: Welcome to COMOONICS LiveCD 64bit [root@comoonics ~]#
Mount /data from node601:
[root@comoonics ~]# mkdir /data [root@comoonics ~]# mount node601:/data /data
Copy needed files to new server:
[root@comoonics ~]# mkdir -p /etc/comoonics/enterprisecopy/ [root@comoonics ~]# cp /data/services/ec/node631/* /etc/comoonics/enterprisecopy/
start comoonics enterprisecopy
[root@comoonics ~]# com-ec -ad -x /data/services/ec/masterclone.xsl /etc/comoonics/enterprisecopy/masterclone-node631.xml
Create the tmp filesystem
[root@comoonics ~]# mkfs.ext3 /dev/mapper/vg_local-lv_tmp
Label the boot device
[root@comoonics ~]# e2label /dev/cciss/c0d0p1 /boot
Caution
This is an example of a cloning procedure for cluster node624. In case an other cluster has to be created, make sure all data is adapted to the new cluster!
This section describes the installation process of a cluster with the use of an archive clone. In this example the cluster node624 will be created.
On cluster node601 goto /data/services/ec and create a
new directory with the name of the new node.
root@node601a:~# cd /data/services/ec/ root@node601a:/data/services/ec# mkdir node123 root@node601a:~# cd node123
create the masterclone-node624.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE masterclone SYSTEM "../masterclone.dtd">
<masterclone source="backup" destination="disk">
<sourcecluster name="node000"></sourcecluster>
<destcluster name="node624" nodes="2">
<node name="node624a" nodeid="1">
<nic name="bond1" ip="10.0.46.41"/>
<nic name="bond2" ip="192.226.3.75"/>
</node>
<node name="node624b" nodeid="2">
<nic name="bond1" ip="10.0.46.42"/>
<nic name="bond2" ip="192.226.3.76"/>
</node>
</destcluster>
<sourcearchive name="clone-node000" path="/data/linux/clones/">
<metaarchive name="meta-clone-node000-04.tar"/>
<rootarchive name="root-clone-node000-04.tgz"/>
<bootarchive name="boot-clone-node000-04.tgz"/>
</sourcearchive>
<destdisks>
<bootdisk name="/dev/sda"/>
<rootdisk name="/dev/sdb"/>
</destdisks>
<kernel version="2.6.9-42.0.3.ELsmp"/>
</masterclone>
Create the file hosts_node624
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost #################### # public ips for cluster (to resolve the hostname) 10.0.46.40 node624.example.com node624 10.0.46.41 node624a.example.com node624a 10.0.46.42 node624b.example.com node624b #################### # private ips for cluster 192.226.3.74 node624-srv.example.com node624-srv 192.226.3.75 node624a-srv.example.com node624a-srv 192.226.3.76 node624b-srv.example.com node624b-srv #################### # Heartbeat ips for cluster (gfs and clustersuite) 192.168.14.17 node624a-ics0 icsa 192.168.14.18 node624b-ics0 icsb #################### # Ilo ips to resolve ilos for fencing 192.226.10.138 node624a-rc.example.com node624a-rc 192.226.10.139 node624b-rc.example.com node624b-rc #################### # Clusteralias ########################################################################### # Overrule DNS entry for NetBackup Master / Media Servers ########################################################################### 192.226.2.4 aladin.example.com aladin # Netbackup Master Server 192.226.2.24 krake1.example.com krake1 # Netbackup Media Server 192.226.2.60 krake2.example.com krake2 # Netbackup Media Server 192.226.2.94 krake3.example.com krake3 # Netbackup Media Server 192.226.2.99 krake4.example.com krake4 # Netbackup Media Server
# This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/vg_node624_sr/lv_sharedroot / gfs defaults,noatime,nodiratime 0 0 #UUID=59b4f50b-fbb5-4dff-830a-af0e83259112 /boot ext3 defaults,noauto 1 2 # /dev/sda1 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults,noauto 0 0 /dev/vg_local/lv_tmp /tmp ext3 defaults 1 2 /dev/cciss/c0d0p1 swap swap defaults 0 0 /dev/hda /media/cdrecorder2 auto pamconsole,exec,noauto,managed 0 0
<?xml version="1.0"?>
<!DOCTYPE cluster SYSTEM "/opt/atix/comoonics-cs/xml/rh-cluster.dtd">
<cluster config_version="1" name="node624">
<cman expected_votes="1" two_node="1"/>
<fence_daemon clean_start="1" post_fail_delay="0" post_join_delay="3"/>
<clusternodes>
<clusternode name="node624a-ics0" votes="1" nodeid="1">
<com_info>
<hostname name="node624a"/>
<syslog name="node601"/>
<rootvolume name="/dev/vg_node624_sr/lv_sharedroot"/>
<eth name="bond0" ip="192.168.14.17" mask="255.255.255.248" gateway=""/>
<eth name="eth0" mac="00:19:BB:E9:6E:A8" master="bond0" slave="yes"/>
<eth name="eth4" mac="00:19:BB:E9:2F:40" master="bond0" slave="yes"/>
<fenceackserver user="root" passwd="somepassword"/>
</com_info>
<fence>
<method name="1">
<device name="fence_ilo" hostname="192.226.10.138"/>
</method>
<method name="2">
<device name="fence_manual" nodename="node624a-ics0"/>
</method>
</fence>
</clusternode>
<clusternode name="node624b-ics0" votes="1" nodeid="2">
<com_info>
<hostname name="node624b"/>
<syslog name="node601"/>
<rootvolume name="/dev/vg_node624_sr/lv_sharedroot"/>
<eth name="bond0" ip="192.168.14.18" mask="255.255.255.248" gateway=""/>
<eth name="eth0" mac="00:19:BB:E9:48:60" master="bond0" slave="yes"/>
<eth name="eth4" mac="00:19:BB:E9:7B:8C" master="bond0" slave="yes"/>
<fenceackserver user="root" passwd="somepassword"/>
</com_info>
<fence>
<method name="1">
<device name="fence_ilo" hostname="192.226.10.139"/>
</method>
<method name="2">
<device name="fence_manual" nodename="node624a-ics0"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice agent="fence_manual" name="fence_manual"/>
<fencedevice agent="/opt/atix/comoonics-fencing/fence_ilo" login="power" name="fence_ilo" passwd="somepassword" action="hardoff"/>
</fencedevices>
<rm>
<failoverdomains>
<failoverdomain name="node624a" ordered="1" restricted="0">
<failoverdomainnode name="node624a-ics0" priority="1"/>
<failoverdomainnode name="node624b-ics0" priority="1"/>
</failoverdomain>
<failoverdomain name="node624b" ordered="1" restricted="0">
<failoverdomainnode name="node624b-ics0" priority="1"/>
<failoverdomainnode name="node624a-ics0" priority="1"/>
</failoverdomain>
<failoverdomain name="node624a_only" ordered="0" restricted="1">
<failoverdomainnode name="node624a-ics0" priority="1"/>
</failoverdomain>
<failoverdomain name="node624b_only" ordered="0" restricted="1">
<failoverdomainnode name="node624b-ics0" priority="1"/>
</failoverdomain>
</failoverdomains>
<resources>
<!-- LDAP -->
<script file="/etc/init.d/ldap" name="ldap"/>
</resources>
<service autostart="1" domain="node624a" name="LDAP">
<script ref="ldap"/>
</service>
</rm>
</cluster>
To boot the new server, perform the follwing steps:
Note
Depending on the version of the comoonics liveCD, a password for root is set or not. The default root password is “atix”.
On node601 execute the following command:
/opt/atix/comoonics-fencing/fence_ilo -x /data/services/ec/ILOMapLiveCD.xml -a node631-rc -l root -p somepassword
At the ILO console of the new server: login as root and do:
Change password with comoonics# passwd
Check the dhcp assigned ip address with comoonics# ifconfig
Login to new server with ssh.
bash$ ssh root@10.0.45.172 root@10.0.45.172's password: Welcome to COMOONICS LiveCD 64bit [root@comoonics ~]#
Mount /data from node601:
[root@comoonics ~]# mount node601:/data /data
Copy needed files to new server:
[root@comoonics ~]# mkdir -p /etc/comoonics/enterprisecopy/ [root@comoonics ~]# cp /data/services/ec/node624/* /etc/comoonics/enterprisecopy/
start comoonics enterprisecopy
[root@comoonics ~]# com-ec -ad -x /data/services/ec/masterclone.xsl /etc/comoonics/enterprisecopy/masterclone-node624.xml
Create the tmp filesystem. This procedure has to be done for every cluster member
bash# mkfs.ext3 /dev/mapper/vg_local-lv_tmp
label the boot device
bash# e2label /dev/sda1 /boot
B. Glossary
- Extensible Stylesheet Language
A language for expressing stylesheets written in XML. It includes the XSL formatting objects (XSL-FO) language, but refers to separate documents for the transformation language and the path language.
See Also Extensible Markup Language.
- XSL Transformation
The part of XSL for transforming XML documents into other XML documents, HTML, or text. It can be used to rearrange the content and generate new content.
See Also Extensible Markup Language, Extensible Stylesheet Language.
- XML Path Language
A language for addressing parts of an XML document. It is used to find the parts of your document to apply different styles to. All XSL processors use this component.
See Also Extensible Markup Language, Extensible Stylesheet Language, XSL Transformation.
- Extensible Markup Language
The Extensible Markup Language (XML) is a W3C-recommended general-purpose markup language that supports a wide variety of applications.
New Comoonics Productive Version Released !!