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

Refactor the mtms based discovery section to try and make the

Browse Source 
MTMS hardware discovery process more clear
This commit is contained in:
Victor Hu
2016-02-09 13:23:28 -05:00
parent bb48f7f93d
commit f283877e84
6 changed files with 181 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/config_environment.rst
View File

@ -4,7 +4,6 @@ Configure xCAT
Configure network table
```````````````````````
Normally, there will be at least two entries for the two subnet on MN in ``networks`` table after xCAT is installed::
#tabdump networks
@ -50,18 +49,10 @@ For hardware management with ipmi, add the following line::
Verify the genesis packages
```````````````````````````
Genesis packages are used to **create the root image for network boot** and **MUST** be installed before doing hardware discovery.
The **xcat-genesis** packages should have been installed when xCAT was installed, but would cause problems if missing. **xcat-genesis** packages are required to create the genesis root image to do hardware discovery and the genesis kernel sits in ``/tftpboot/xcat/``. Verify that the ``genesis-scripts`` and ``genesis-base`` packages are installed:
* **[RH]**::
* **[RHEL/SLES]**: ``rpm -qa | grep -i genesis``
# rpm -qa |grep -i genesis
xCAT-genesis-scripts-ppc64-2.10-snap201507240527.noarch
xCAT-genesis-base-ppc64-2.10-snap201505172314.noarch
* **[Ubuntu]**: ``dpkg -l | grep -i genesis``
* **[ubuntu]**::
# dpkg -l | grep genesis
ii xcat-genesis-base-ppc64 2.10-snap201505172314 all xCAT Genesis netboot image
ii xcat-genesis-scripts 2.10-snap201507240105 ppc64el xCAT genesis
**Note:** If the two packages are not installed, install them first and then run ``mknb ppc64`` to create the network boot root image.
If missing, install them from the ``xcat-deps`` package and run ``mknb ppc64`` to create the genesis network boot root image.

24
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/index.rst
View File

@ -1,11 +1,20 @@
Hardware Discovery & Define Node
================================
Have the servers to be defined as **Node Object** in xCAT is the first step to do for a cluster management.
In order to manage machines using xCAT, the machines need to be defined as ``node`` objects in xCATs database. The :doc:`xCAT Objects </guides/admin-guides/basic_concepts/xcat_object/index>` documentation describes the process for manually creating ``node`` objects one by one using the xCAT ``mkdef`` command. This is valid when managing a small sizes cluster but can be error prone and cumbersome when managing large sized clusters.
In the chapter :doc:`xCAT Object <../../../basic_concepts/xcat_object/index>`, it describes how to create a **Node Object** through `mkdef` command. You can collect all the necessary information of target servers and define them to a **xCAT Node Object** by manually run `mkdef` command. This is doable when you have a small cluster which has less than 10 servers. But it's really error-prone and inefficiency to manually configure SP (like BMC) and collect information for a large number servers.
xCAT provides several *automatic hardware discovery* methods to assist with hardware discovery by helping to simplify the process of detecting service processors (SP) and collecting various server information. The following are methods that xCAT supports:
.. toctree::
:maxdepth: 2
mtms/index.rst
switch_discovery.rst
seq_discovery.rst
manually_define.rst
manually_discovery.rst
xCAT offers several powerful **Automatic Hardware Discovery** methods to simplify the procedure of SP configuration and server information collection. If your managed cluster has more than 10 servers, the automatic discovery is worth to take a try. If your cluster has more than 50 servers, the automatic discovery is recommended.
Following are the brief characteristics and adaptability of each method, you can select a proper one according to your cluster size and other consideration.
@ -73,12 +82,3 @@ Following are the brief characteristics and adaptability of each method, you can
You have to strictly boot on the node in order if you want the node has the expected name. Generally you have to waiting for the discovery process finished before power on the next one.
.. toctree::
:maxdepth: 2
manually_define.rst
mtms_discovery.rst
switch_discovery.rst
seq_discovery.rst
manually_discovery.rst

91
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/discovery.rst Normal file
View File

@ -0,0 +1,91 @@
Discover and Define Servers
===========================
When the IPMI-based server is connected to power, the BMC automatically boots up and tries to a DHCP IP address. Once the BMC gets an IP address, xCAT can discover the BMC and obtain some basic information. Use the :doc:`bmcdiscover </guides/admin-guides/references/man1/bmcdiscover.1>` command to scan the network for BMCs.
#. Discover the BMCs over a network range. ::
bmcdiscover --range 50.0.100.1-100 -t -z
The output should be similar to: ::
node-8247-22l-10112ca:
objtype=node
groups=all
bmc=50.0.100.1
cons=ipmi
mgt=ipmi
mtm=8247-22L
serial=10112CA
nodetype=mp
hwtype=bmc
By default, ``bmcdiscover`` will use the username/password for the "ipmi" key in the xCAT ``passwd`` table. You can specify a different username or password with command line optjons to ``bmcdiscover``.
#. If the output looks good, run the command again using the ``-w`` option to write to the xCAT database and redirect the output to a file in order to create the **predefined** node stanzas: ::
bmcdiscover --range 50.0.100.1-100 -t -z -w > predefined_bmc.stanza
#. The discovered node stanza is now in the xCAT databased. Edit the ``predefined_bmc.stanza`` file and modify the following:
#. Rename the ``node-8247-22l-10112ca`` to the intended hostname for the compute node
#. Remove the ``nodetype`` and ``hwtype`` attributes for the node stanza
The resulting predefined definition should be similar to: ::
cn1:
objtype=node
groups=all
bmc=50.0.100.1
cons=ipmi
mgt=ipmi
mtm=8247-22L
serial=10112CA
#. Define the predefined node to xCAT: [#]_ ::
cat predefined_bmc.stanza | mkdef -z
#. Modify the predefined node using xCAT commands
#. Set the IP address for the compute node: ::
chdef cn1 ip=10.0.101.1
#. Set the BMC IP address to a different value: ::
chdef cn1 bmc=50.0.101.1
#. Set the chain table attribute to do BMC setup/discovery: ::
chdef cn1 chain="runcmd=bmcsetup"
#. Add the node information to ``/etc/hosts`` and DNS: ::
makehosts cn1
makedns -n
#. [**Optional**] To monitor the node discovery process, configure conserver for the **discovered** nodes: ::
makeconservercf node-8247-22l-10112ca
rcons node-8247-22l-10112ca
#. Start the discovery process by booting the **discovered** node definition: ::
rsetboot node-8247-22l-10112ca net
rpower node-8247-22l-10112ca on
#. The discovery process should complete and update the status for the **predefined** node and update the status to "bmcready": ::
lsdef cn1 | grep status
Displaying the node attributes should show more attributes discoverd for the node, necessary for xCAT to do OS deployment.
.. [#] The changes made in the next step can be made directly into the ``predefined_bmc.stanza`` before importing to xCAT.

5
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/example_environment.rst Normal file
View File

@ -0,0 +1,5 @@
Environment
===========
.. include:: ../schedule_environment.rst

34
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst Normal file
View File

@ -0,0 +1,34 @@
MTMS-based Discovery
====================
MTMS is short for **M**\ achine **T**\ ype/\ **M**\ odel and **S**\ erial which is unique for each physical server. MTMS-based hardware discovery assumes that the administator has the MTMS information for all the physical servers and has a mapping for the MTMS and hostname/IP for the servers.
Pros and Cons
-------------
Pros
````
* Limited effort to get servers defined using xCAT hardware discovery engine
Cons
````
* When compared to switch-based discovery, the administrator needs to be involved to create a **predefined-node** from each of the **discovered-nodes** stanzas. This could become difficult for a large number of servers.
Overview
--------
#. Automatically search and collect MTMS information from the servers
#. Define the **discovered-node** to xCAT
#. Create a **predefined-node** to xCAT providing additional properties
#. Power on the **discovered-nodes** triggering xCAT's hardware discovery engine.
.. toctree::
:maxdepth: 2
preverification.rst
example_environment.rst
discovery.rst

35
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/preverification.rst Normal file
View File

@ -0,0 +1,35 @@
Before Starting
===============
Before starting hardware discovery, ensure the following is configured to make the discovery process as smooth as possible.
Password Table
--------------
In order to communicate with IPMI-based (bmc) hardware, verify that the xCAT ``passwd`` table contains an entry for ``ipmi`` defininig the username and password for IPMI-based servers. ::
tabdump passwd | grep ipmi
Genesis Package
---------------
The **xcat-genesis** packages provides the utility to create the genesis network boot rootimage used by xCAT when doing hardware discivery. IT should have been installed during the xCAT installation and would cause problems if missing.
Verify that the ``genesis-scripts`` and ``genesis-base`` packages are installed:
* **[RHEL/SLES]**: ::
rpm -qa | grep -i genesis
* **[Ubuntu]**: ::
dpkg -l | grep -i genesis
If the packages are missing:
#. Install them using the OS specific package manager from the ``xcat-deps`` repository
#. Create the network boot rootimage with the following command: ``mknb ppc64``.
The resulting genesis kernel should appear in the ``/tftpboot/xcat`` directory.