xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-06-22 22:15:30 +00:00
Code Issues Releases Wiki Activity

polish statelite doc

Browse Source
This commit is contained in:
bybai
2017-01-12 01:40:54 -05:00
parent 043806485b
commit 86a7d4b686
5 changed files with 124 additions and 220 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/advanced_features.rst
View File

@ -1,5 +1,5 @@
Advanced Statelite features
===========================
Advanced features
=================
Both directory and its child items coexist in litefile table
------------------------------------------------------------
@ -68,8 +68,8 @@ In order to describe the hierarchy scenarios we can use , ``P`` to denote parent
| | | the parent is created in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P: link C: | "ALL","/root/testlinkpers/","link",, | Both parent and child are created in tmpfs |
| link, | "ALL","/root/testlink/testlinkchild", | on the booted node following their respective |
| persistent | ,"link,persistent" | options; there's only one symbolic link of |
| link, | "ALL","/root/testlink/testlinkchild",, | on the booted node following their respective |
| persistent | "link,persistent" | options; there's only one symbolic link of |
| | | the parent is created in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link, | "ALL","/root/testlinkpers/","link,persistent",, | NOT permitted |
@ -251,7 +251,7 @@ Add an entry in policy table to permit the running of the ``getpartitioin`` comm
If Using the RAMdisk-based Image
````````````````````````````````
If you want to use the local disk option with a RAMdisk-based image, remember to follow the instructions in :ref:`Switch to the RAMdisk based solution`.
If you want to use the local disk option with a RAMdisk-based image, remember to follow the instructions in :doc:`Switch to the RAMdisk based solution <./provision_statelite>`.
If your reason for using a RAMdisk image is to avoid compute node runtime dependencies on the service node or management node, then the only entries you should have in the litefile table should be files/dirs that use the localdisk option.

80
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst
View File

@ -1,11 +1,12 @@
Configure Statelite
===================
Configuration
=============
Getting started with statelite provisioning requires that you have xCAT set up and running. Before continuing with the rest of this document, the xCAT management node must be set up, and the nodes' hardware control, resource, and type attributes must be defined correctly.
The operating system image files and the statelite files can be put on the service nodes or the management node, or any external NFS server.
Statelite uses the following tables in xCAT:
Statelite configuration is done using the following tables in xCAT:
* litefile
* litetree
* statelite
* policy
* noderes
litefile table
--------------
@ -16,7 +17,7 @@ The litefile table specifies the directories and files on the statelite nodes th
#. The second column in the litefile table is the full path of the directory or file on the node that you are setting options for.
#. The third column in the litefile table specifies options for the directory or file: ::
#. The third column in the litefile table specifies options for the directory or file:
1. tmpfs - It provides a file or directory for the node to use when booting, its permission will be the same as the original version on the server. In most cases, it is read-write; however, on the next statelite boot, the original version of the file or directory on the server will be used, it means it is non-persistent. This option can be performed on files and directories.
2. rw - Same as Above.Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system.
@ -26,44 +27,16 @@ The litefile table specifies the directories and files on the statelite nodes th
5. tmpfs,rw - Only for compatibility it is used as the default option if you leave the options column blank. It has the same semantics with the link option, so when adding new items into the _litefile table, the link option is recommended.
6. link - It provides one file/directory for the node to use when booting, it is copied from the server, and will be placed in tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to one file/directory in tmpfs. And the permission of the symbolic link is "lrwxrwxrwx", which is not the real permission of the file/directory on the node. So for some application sensitive to file permissions, it will be one issue to use "link" as its option, for example, "/root/.ssh/", which is used for SSH, should NOT use "link" as its option. It is non-persistent, when the node is rebooted, all changes to the file/directory will be lost. This option can be performed on files and directories.
7. link,ro - The file is readonly, and will be placed in tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to the tmpfs. It is non-persistent, when the node is rebooted, all changes to the file/directory will be lost. This option requires that the file/directory to be mounted must be available in one of the entries in the litetree table. The option can be performed on files and directories.
8. link,con - It works similar to the "con" option. All the files found in the litetree hierarchy will be concatenated to the file when found. The final file will be put to the tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to the file/directory in tmpfs. It is non-persistent, when the node is rebooted, all changes to the file will be lost. The option can only be performed on files.
8. link,con - Similar to the "con" option. All the files found in the litetree hierarchy will be concatenated to the file when found. The final file will be put to the tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to the file/directory in tmpfs. It is non-persistent, when the node is rebooted, all changes to the file will be lost. The option can only be performed on files.
9. link,persistent - It provides a mounted file or directory that is copied to the xCAT persistent location and then over-mounted to the tmpfs on the booted node, and finally the symbolic link in the local file system will be linked to the over-mounted tmpfs file/directory on the booted node. The file/directory will be persistent across reboots. The permission of the file/directory where the symbolic link points to will be the same as the original one in the statelite location. It requires the statelite table to be filled out with a spot for persistent statelite. The option can be performed on files and directories.
10. localdisk - The file or directory will be stored in the local disk of the statelite node. Refer to the section To enable the localdisk option to enable the 'localdisk' support.
Currently, we don't handle the relative links very well. The relative links are commonly used by the system libraries, for example, under ``/lib/`` directory, there will be one relative link matching one ``.so`` file. So, when you add one relative link to the litefile table (We don't recommend ), make sure the real file also be included, or you can put its directory name into the litefile table. However, most of the users will not put the relative links in the litefile table.
Currently, xCAT does not handle the relative links very well. The relative links are commonly used by the system libraries, for example, under ``/lib/`` directory, there will be one relative link matching one ``.so`` file. So, when you add one relative link to the litefile table (Not recommend), make sure the real file also be included, or put its directory name into the litefile table.
``Note``: It is recommended that you specify at least the entries listed below in the litefile table, because most of these files need to be writeable for the node to boot up successfully. When any changes are made to their options, make sure they won't affect the whole system.
**Note**: It is recommended that you specify at least the entries listed below in the litefile table, because most of these files need to be writeable for the node to boot up successfully. When any changes are made to their options, make sure they won't affect the whole system.
Sample Data for a RedHat statelite setup
````````````````````````````````````````
This is the minimal list of files needed, you can add additional files to the litefile table.
Notice that all files are in tmpfs, the default for the options field. This gives you an NFS root solution with no persistent storage. ::
#image,file,options,comments,disable
"ALL","/etc/adjtime","tmpfs",,
"ALL","/etc/fstab","tmpfs",,
"ALL","/etc/lvm/","tmpfs",,
"ALL","/etc/syslog.conf","tmpfs",,
"ALL","/etc/syslog.conf.XCATORIG","tmpfs",,
"ALL","/etc/ntp.conf","tmpfs",,
"ALL","/etc/ntp.conf.predhclient","tmpfs",,
"ALL","/etc/resolv.conf","tmpfs",,
"ALL","/etc/resolv.conf.predhclient","tmpfs",,
"ALL","/etc/ssh/","tmpfs",,
"ALL","/etc/sysconfig/","tmpfs",,
"ALL","/etc/inittab","tmpfs",,
"ALL","/tmp/","tmpfs",,
"ALL","/var/","tmpfs",,
"ALL","/opt/xcat/","tmpfs",,
"ALL","/xcatpost/","tmpfs",,
"ALL","/root/.ssh/","tmpfs",,
Sample Data for Redhat6/7 statelite setup
`````````````````````````````````````````
Sample Data for Red hat statelite setup
```````````````````````````````````````
This is the minimal list of files needed, you can add additional files to the litefile table. ::
@ -117,33 +90,27 @@ This is the minimal list of files needed, you can add additional files to the li
"ALL","/xcatpost/","tmpfs",,
"ALL","/root/.ssh/","tmpfs",,
``Note``: Sample Data for Fedora13/14 statelite setup refer to the setup of Redhat6.
litetree table
--------------
The litetree table controls where the initial content of the files in the litefile table come from, and the long term content of the ``ro`` files. When a node boots up in statelite mode, it will by default copy all of its tmpfs files from the ``/.default`` directory of the root image, so there is not required to set up a litetree table. If you decide that you want some of the files pulled from different locations that are different per node, you can use this table. See Advanced Statelite features.
The litetree table controls where the initial content of the files in the litefile table come from, and the long term content of the ``ro`` files. When a node boots up in statelite mode, it will by default copy all of its tmpfs files from the ``.default`` directory of the root image, for example ``/install/netboot/rhels7.3/x86_64/compute/rootimg/.default``, so there is not required to set up a litetree table. If you decide that you want some of the files pulled from different locations that are different per node, you can use this table.
You can choose to use the defaults and not set up a litetree table.
statelite table
---------------
You may want some files in the image to be stored permanently, to survive reboots. This is done by entering the information into the statelite table.
The statelite table specifies location on an NFS server where a nodes persistent files are stored. This is done by entering the information into the statelite table.
See the statelite man page for description of the attributes.
``Note``: In the statelite table, the node or nodegroups in the table must be unique; that is a node or group should appear only once in the first column table. This makes sure that only one statelite image can be assigned to a node.
An example would be: ::
In the statelite table, the node or nodegroups in the table must be unique; that is a node or group should appear only once in the first column table. This makes sure that only one statelite image can be assigned to a node. An example would be: ::
"compute",,"<nfssvr_ip>:/gpfs/state",,
Any nodes in the compute node group will have their state stored in the ``/gpfs/state`` directory on the machine with ``<nfssvr_ip>`` as its IP address. The image attribute should be left blank - currently it is not used.
Any nodes in the compute node group will have their state stored in the ``/gpfs/state`` directory on the machine with ``<nfssvr_ip>`` as its IP address.
When the node boots up, then the value of the statemnt attribute will be mounted to ``/.statelite/persistent``. The code will then create the following subdirectory ``/.statelite/persistent/<nodename>`` if there are persistent files that have been added in the litefile table. This directory will be the root of the image for this node's persistent files. By default, xCAT will do a hard NFS mount of the directory. You can change the mount options by setting the mntopts attribute in the statelite table.
When the node boots up, then the value of the ``statemnt`` attribute will be mounted to ``/.statelite/persistent``. The code will then create the following subdirectory ``/.statelite/persistent/<nodename>``, if there are persistent files that have been added in the litefile table. This directory will be the root of the image for this node's persistent files. By default, xCAT will do a hard NFS mount of the directory. You can change the mount options by setting the mntopts attribute in the statelite table.
Also, to set the statemnt attribute, you can use variables from xCAT database. It follows the same grammar as the litetree table. For example: ::
Also, to set the ``statemnt`` attribute, you can use variables from xCAT database. It follows the same grammar as the litetree table. For example: ::
#node,image,statemnt,mntopts,comments,disable
"cn1",,"$noderes.nfsserver:/lite/state/$nodetype.profile","soft,timeo=30",,
@ -158,3 +125,10 @@ Ensure policies are set up correctly in the Policy Table. When a node boots up,
chdef -t policy -o 4.7 commands=litefile rule=allow
chdef -t policy -o 4.8 commands=litetree rule=allow
noderes
-------
``noderes.nfsserver`` attribute can be set for the NFSroot server. If this is not set, then the default is the Management Node.
``noderes.nfsdir`` can be set. If this is not set, the the default is ``/install``

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/hierarchy_support.rst
View File

@ -13,7 +13,7 @@ Setup the diskfull service node
Generate the statelite image
````````````````````````````
To generate the statelite image for your own profile follow instructions in `Customize your statelite osimage`_.
To generate the statelite image for your own profile follow instructions in :doc:`Customize your statelite osimage <./provision_statelite>`.
``NOTE``: if the NFS directories defined in the litetree table are on the service node, it is better to setup the NFS directories in the service node following the chapter.

41
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/index.rst
View File

@ -1,12 +1,45 @@
Statelite Installation
======================
.. toctree::
:maxdepth: 3
**Overview**
This document details the design and setup for the statelite solution of xCAT. **Statelite** is an intermediate mode between **diskful** and **diskless**.
Statelite provides two kinds of efficient and flexible solutions, most of the OS image can be NFS mounted read-only, or the OS image can be in the ramdisk with tmpfs type. Different from the stateless solution, statelite provides a configurable list of directories and files that can be read-write. These read-write directories and files can be configured to either persist or not persist across reboots.
**Solutions**
There are two solutions: ``NFSROOT-based`` and ``RAMdisk-based``.
#. NFSROOT-based(default):
#. rootfstype in the osimage xCAT data objects is left as blank, or set to ``nfs``, the ``NFSROOT-base`` statelite solution will be enabled.
#. the ROOTFS is NFS mounted read-only.
#. RAMdisk-based:
#. rootfstype in the osimage xCAT data objects is set to ``ramdisk``.
#. one image file will be downloaded when the node is booting up, and the file will be extracted to the ramdisk, and used as the ROOTFS.
**Advantages**
``Statelite`` offers the following advantages over xCAT's stateless (RAMdisk) implementation:
#. Some files can be made persistent over reboot. This is useful for license files or database servers where some state is needed. However, you still get the advantage of only having to manage a single image.
#. Changes to hundreds of machines can take place instantly, and automatically, by updating one main image. In most cases, machines do not need to reboot for these changes to take affect. This is only for the ``NFSROOT-based`` solution.
#. Ease of administration by being able to lock down an image. Many parts of the image can be read-only, so no modifications can transpire without updating the central image.
#. Files can be managed in a hierarchical manner. For example: Suppose you have a machine that is in one lab in Tokyo and another in London. You could set table values for those machines in the xCAT database to allow machines to sync from different places based on their attributes. This allows you to have one base image with multiple sources of file overlay.
#. Ideal for virtualization. In a virtual environment, you may not want a disk image (neither stateless nor stateful) on every virtual node as it consumes memory and disk. Virtualizing with the statelite approach allows for images to be smaller, easier to manage, use less disk, less memory, and more flexible.
**Disadvantages**
However, there're still several disadvantages, especially for the ``NFSROOT-based`` solution.
#. NFS Root requires more network traffic to run as the majority of the disk image runs over NFS. This may depend on your workload, but can be minimized. Since the bulk of the image is read-only, NFS caching on the server helps minimize the disk access on the server, and NFS caching on the client helps reduce the network traffic.
#. NFS Root can be complex to set up. As more files are created in different places, there are greater chances for failures. This flexibility is also one of the great virtues of Statelite. The image can work in nearly any environment.
.. toctree::
:maxdepth: 2
overview.rst
config_statelite.rst
provision_statelite.rst
update_nodes.rst
hierarchy_support.rst
advanced_features.rst

211
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/provision_statelite.rst
View File

@ -1,59 +1,42 @@
Provision statelite
===================
Show current provmethod
-----------------------
Show current provisioning method
--------------------------------
To determine the current provmethod of your node, run: ::
To determine the current provisioning method of your node, execute: ::
lsdef <noderange> | provmethod
If an osimage name is specified for the provmethod, the osimage attribute settings stored in the osimage and linuximage table are used to locate the files for ``templates``, ``*pkglists``, ``syncfiles``, etc.
lsdef <noderange> -i provmethod
``Note``: syncfiles is not currently supported for statelite nodes.
See attributes in the osimage, linuximage and nimimage tables. For example: ::
tabdump -d osimage
tabdump -d linuximage
tabdump -d nimimage
For a hierarchical cluster, the files must be placed under the site table installdir attribute path, usually ``/install`` directory, so they will be available when mounted on the service nodes. The site table installdir directory, is mounted or copied to the service nodes during the hierarchical install of compute nodes from the service nodes.
Generate default statelite image from distoro media
---------------------------------------------------
For our example, we are going to create a new compute node test osimage for ``rhels7.3`` on ``ppc64le``. This works fine for other archtectures ( e.g. ``x86_64``). Just substitute your architecture in the paths ( e.g. ``x86_64`` ). We will set up a test directory structure that we can use to create our image. Later we can just move that into production.
In this example, we are going to create a new compute node osimage for ``rhels7.3`` on ``ppc64le``. We will set up a test directory structure that we can use to create our image. Later we can just move that into production.
Use the copycds command to copy the appropriate iso image into the ``/install`` directory for xCAT. The copycds commands will copy the contents to ``/install/rhels7.3/<arch>``. For example: ::
mkdir /iso
cd /iso
copycds RHEL-7.3-20161019.0-Server-ppc64le-dvd1.iso
The contents are copied into ``/install/rhels7.3/ppc64le/``
When copycds runs, it will automatically create default osimage names and paths in the osimage table and the linuximage table based on the os and architecture you are using. You can use these defaults as a starting point to create your own osimage definitions, or you can create your own image definition. We are going to use the statelite generated image for our example.
The configuration files pointed to by the attributes are the defaults shipped with xCAT. We will want to copy them to the ``/install`` directory, in our example the ``/install/test`` directory and modify them as needed.
The configuration files pointed to by the attributes are the defaults shipped with xCAT. We will want to copy them to the ``/install`` directory, in our example the ``/install/test`` directory and modify them as needed. ::
Statelite Directory Structure
-----------------------------
lsdef -t osimage -o rhels7.3-ppc64le-statelite-compute
Object name: rhels7.3-ppc64le-statelite-compute
exlist=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.exlist
imagetype=linux
osarch=ppc64le
osdistroname=rhels7.3-ppc64le
osname=Linux
osvers=rhels7.3
otherpkgdir=/install/post/otherpkgs/rhels7.3/ppc64le
permission=755
pkgdir=/install/rhels7.3/ppc64le
pkglist=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist
postinstall=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall
profile=compute
provmethod=statelite
rootimgdir=/install/netboot/rhels7.3/ppc64le/compute
synclists=/install/custom/netboot/rh/compute.synclist
Each statelite image will have the following directories: ::
/.statelite/tmpfs/
/.default/
/etc/init.d/statelite
All files with link options, which are symbolic links, will link to ``/.statelite/tmpfs``.
tmpfs files that are persistent link to ``/.statelite/persistent/<nodename>/``, ``/.statelite/persistent/<nodename>`` is the directory where the node's individual storage will be mounted to.
``/.default`` is where default files will be copied to from the image to tmpfs if the files are not found in the litetree hierarchy.
Customize your statelite osimage
--------------------------------
@ -61,64 +44,41 @@ Customize your statelite osimage
Create the osimage definition
`````````````````````````````
Setup your osimage/linuximage tables with new test image name, osvers,osarch, and paths to all the files for building and installing the node. So using the above generated ``rhels7.3-ppc64le-statelite-compute`` as an example, I am going to create my own image. The value for the provmethod attribute is osimage in my example.::
Setup your osimage/linuximage tables with new test image name, osvers,osarch, and paths to all the files for building and installing the node. So using the above generated ``rhels7.3-ppc64le-statelite-compute`` as an example, I am going to create my own image. The value for the provisioning method attribute is osimage in my example.::
mkdef -t osimage -o redhat7img \
profile=compute imagetype=linux provmethod=statelite osarch=ppc64le osname=linux osvers=rhels7.3
mkdef rhels7.3-custom-statelite -u profile=compute provmethod=statelite
Check your setup: ::
lsdef -t osimage rhels7.3-custom-statelite
lsdef -t osimage redhat7img
Object name: redhat7img
imagetype=linux
osarch=ppc64le
osname=linux
osvers=rhels7.3
profile=compute
provmethod=statelite
Add the paths to your ``pkglist``, ``syncfile``, etc to the osimage definition, that you require. ``Note``, if you modify the files on the ``/opt/xcat/share/...`` path then copy to the appropriate ``/install/custom/...`` path. Remember all files must be under ``/install`` if using hierarchy (service nodes).
Customize the paths to your ``pkglist``, ``syncfile``, etc to the osimage definition, that you require. ``Note``, if you modify the files on the ``/opt/xcat/share/...`` path then copy to the appropriate ``/install/custom/...`` path. Remember all files must be under ``/install`` if using hierarchy (service nodes).
Copy the sample ``*list`` files and modify as needed: ::
mkdir -p /install/test/netboot/rh
cp -p /opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist \
/install/test/netboot/rh/compute.pkglist
/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist
cp -p /opt/xcat/share/xcat/netboot/rh/compute.exlist \
/install/test/netboot/rh/compute.exlist
chdef -t osimage -o redhat7img \
chdef -t osimage -o rhels7.3-custom-statelite \
pkgdir=/install/rhels7.3/ppc64le \
pkglist=/install/test/netboot/rh/compute.pkglist \
pkglist=/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist \
exlist=/install/test/netboot/rh/compute.exlist \
rootimgdir=/install/test/netboot/rh/ppc64le/compute
Check your setup: ::
lsdef -t osimage -o redhat7img
Object name: redhat7img
exlist=/install/test/netboot/rh/compute.exlist
imagetype=linux
osarch=ppc64
osname=linux
osvers=rhels7.3
pkgdir=/install/rhels7.3/ppc64le
pkglist=/install/test/netboot/rh/compute.pkglist
profile=compute
provmethod=statelite
rootimgdir=/install/test/netboot/rh/ppc64le/compute
Setup pkglists
``````````````
In the above example, you have defined your pkglist to be in ``/install/test/netboot/rh/compute.pkglist``.
In the above example, you have defined your pkglist to be in ``/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist``.
Edit compute.pkglist and compute.exlist as needed. ::
Edit ``compute.rhels7.ppc64le.pkglist`` and ``compute.exlist`` as needed. ::
cd /install/test/netboot/rh/
vi compute.pkglist compute.exlist
vi /install/test/netboot/rh/compute.rhels7.ppc64le.pkglist
vi /install/test/netboot/rh/compute.exlist
For example to add vi to be installed on the node, add the name of the vi rpm to compute.pkglist. Make sure nothing is excluded in compute.exlist that you need.
Make sure nothing is excluded in compute.exlist that you need.
Install other specific packages
```````````````````````````````
@ -148,14 +108,14 @@ Or, if you create a sub-directory to contain the rpm packages, for example, name
Define the location of of your otherpkgs in your osimage: ::
chdef -t osimage -o redhat7img \
chdef -t osimage -o rhels7.3-custom-statelite \
otherpkgdir=/install/test/post/otherpkgs/rh/ppc64le \
otherpkglist=/install/test/netboot/rh/compute.otherpkgs.pkglist
There are examples under ``/opt/xcat/share/xcat/netboot/<platform>`` of typical ``*otherpkgs.pkglist`` files that can used as an example of the format.
Set up Post install scripts for statelite
`````````````````````````````````````````
Set up Post scripts for statelite
`````````````````````````````````
The rules to create post install scripts for statelite image is the same as the rules for stateless/diskless install images.
@ -172,62 +132,36 @@ Using postinstall files is optional. There are some examples shipped in ``/opt/x
If you define a postinstall file to be used by genimage, then ::
chdef -t osimage -o redhat7img postinstall=<your postinstall file path>.
Setting up Files to be synchronized on the nodes
````````````````````````````````````````````````
Setup the node to use your osimage
``````````````````````````````````
::
chdef -t node -o node1 provmethod=redhat7img
lsdef node1 | grep provmethod
provmethod=redhat7img
chdef -t osimage -o rhels7.3-custom-statelite postinstall=<your postinstall file path>.
Generate the image
------------------
Run the following command to generate the image based on your osimage named redhat6img. Adjust your genimage parameters to your architecture and network settings. See man genimage. ::
Run the following command to generate the image based on your osimage named ``rhels7.3-custom-statelite``. Adjust your genimage parameters to your architecture and network settings. See man genimage. ::
genimage redhat7img
genimage rhels7.3-custom-statelite
The genimage will create a default ``/etc/fstab`` in the image, for example: ::
The genimage will create a default ``/etc/fstab`` in the image, if you want to change the defaults, on the management node, edit fstab in the image: ::
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /tmp tmpfs defaults,size=10m 0 2
tmpfs /var/tmp tmpfs defaults,size=10m 0 2
compute_x86_64 / tmpfs rw 0 1
If you want to change the defaults, on the management node, edit fstab in the image: ::
cd /install/netboot/rhels6/x86_64/compute/rootimg/etc
cd /install/netboot/rhels7/ppc64le/compute/rootimg/etc
cp fstab fstab.ORIG
vi fstab
Change these settings: ::
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
#tmpfs /dev/shm tmpfs rw 0 0
compute_x86_64 / tmpfs rw 0 1
none /tmp tmpfs defaults,size=10m 0 2
none /var/tmp tmpfs defaults,size=10m 0 2
``Note``: adding ``/tmp`` and ``/var/tmp`` to ``/etc/fstab`` is optional, most installations can simply use ``/``. It was documented her to show that you can restrict the size of filesystems, if you need to. The indicated values are just and example, and you may need much bigger filessystems, if running applications like OpenMPI.
Pack the image
--------------
::
liteimg redhat7img
Boot the node
-------------
::
rinstall node1 osimage=redhat7img
Execute liteimg ::
liteimg rhels7.3-custom-statelite
Boot the statelite node
-----------------------
Execute ``rinstall`` ::
rinstall node1 osimage=rhels7.3-custom-statelite
Switch to the RAMdisk based solution
------------------------------------
@ -239,14 +173,14 @@ Set rootfstype
If you want the node to boot with a RAMdisk-based image instead of the NFS-base image, set the rootfstype attribute for the osimage to ``ramdisk``. For example: ::
chdef -t osimage -o rhels6-ppc64-statelite-compute rootfstype=ramdisk
chdef -t osimage -o rhels7.3-custom-statelite rootfstype=ramdisk
Run liteimg command
```````````````````
The ``liteimg`` command will modify your statelite image (the image that ``genimage`` just created) by creating a series of links. Once you are satisfied with your image contains what you want it to, run ``liteimg <osimagename>``: ::
liteimg rhels6-ppc64-statelite-compute
liteimg rhels7.3-custom-statelite
For files with link options, the ``liteimg`` command creates two levels of indirection, so that files can be modified while in their image state as well as during runtime. For example, a file like ``$imageroot/etc/ntp.conf`` with link option in the litefile table, will have the following operations done to it:
@ -268,8 +202,8 @@ But for files without link options, the ``liteimg`` command only creates clones
``Note``: If you make any changes to your litefile table after running ``liteimg`` then you will need to rerun ``liteimg`` again. This is because files and directories need to have the two levels of redirects created.
Boot the node
`````````````
Boot the statelite node
```````````````````````
Make sure you have set up all the attributes in your node definitions correctly following the node installation instructions corresponding to your hardware:
@ -277,45 +211,8 @@ You can now deploy the node by running the following commmands: ::
rinstall <noderange>
This will create the necessary files in ``/tftpboot/etc`` for the node to boot correctly.
You can then use ``rcons`` or ``wcons`` to watch the node boot up.
Commands
--------
The following commands are in ``/opt/xcat/bin``: ::
litefile <nodename> : Shows all the statelite files that are not to be taken from the base of the image.
litetree <nodename> : Shows the NFS mount points for a node.
liteimg <image name> : Creates a series of symbolic links in an image that is compatible with statelite booting.
lslite -i <imagename> : Displays a summary of the statelite information defined for <imagename>.
lslite <noderange> : Displays a summary of the statelite information defined for the <noderange>
Statelite Directory Structure
-----------------------------
Each statelite image will have the following directories: ::
/.statelite/tmpfs/
/.default/
/etc/init.d/statelite
All files with link options, which are symbolic links, will link to ``/.statelite/tmpfs``.
tmpfs files that are persistent link to ``/.statelite/persistent/<nodename>/``, ``/.statelite/persistent/<nodename>`` is the directory where the node's individual storage will be mounted to.
``/.default`` is where default files will be copied to from the image to tmpfs if the files are not found in the litetree hierarchy.
The noderes Table
`````````````````
``noderes.nfsserver`` attribute can be set for the NFSroot server. If this is not set, then the defaul is the Management Node.
``noderes.nfsdir`` can be set. If this is not set, the the default is ``/install``
Adding/updating software and files for the running nodes
--------------------------------------------------------