mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-05-29 17:23:08 +00:00
Refactor the MTMS section again to handle the DHCP and STATIC ip address case
Delete the mtms_discovery.rst file since the content is in the mtms directory
This commit is contained in:
Victor Hu
parent
60112243db
commit
7e2c7b680d
@ -1,7 +1,7 @@
|
||||
Hardware Discovery & Define Node
|
||||
================================
|
||||
|
||||
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 order to manage machines using xCAT, the machines need to be defined as xCAT ``node objects`` in the 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.
|
||||
|
||||
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:
|
||||
|
||||
|
||||
@ -1,79 +1,135 @@
|
||||
Discover and Define Servers
|
||||
===========================
|
||||
Discovery
|
||||
=========
|
||||
|
||||
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.
|
||||
When the IPMI-based servers are connected to power, the default setting from manuafacturing is DHCP mode and the BMCs will obtain a IP address from an open range DHCP server on your network. (xCAT can start an open range on the DHCP server by setting the ``dynamicrange`` attribute in the networks table)
|
||||
|
||||
#. Discover the BMCs over a network range. ::
|
||||
When the BMCs have an IP address and is pingable from the xCAT management node, administrators can discover the BMCs using the xCAT :doc:`bmcdiscover </guides/admin-guides/references/man1/bmcdiscover.1>` command and obtain basic information to start the hardware discovery process. When hardware discovery is running, xCAT uses the genesis kernel to discover attributes of the compute node and populate the node attributes so xCAT can then manage the node.
|
||||
|
||||
bmcdiscover --range 50.0.100.1-100 -t -z
|
||||
The following example outlines the MTMS based hardware discovery for a single IPMI-based compute node.
|
||||
|
||||
The output should be similar to: ::
|
||||
+-------------------------+------------+
|
||||
| Environment | Value |
|
||||
+=========================+============+
|
||||
| Compute Node Model Type | 8247-22l |
|
||||
+-------------------------+------------+
|
||||
| Compute Node Serial Num | 10112CA |
|
||||
+-------------------------+------------+
|
||||
| Compute Node Hostname | cn01 |
|
||||
+-------------------------+------------+
|
||||
| Compute Node IP address | 10.1.2.1 |
|
||||
+-------------------------+------------+
|
||||
| BMC DHCP IP address | 172.30.0.1 |
|
||||
+-------------------------+------------+
|
||||
| BMC STATIC IP address | 172.20.0.1 |
|
||||
+-------------------------+------------+
|
||||
|
||||
node-8247-22l-10112ca:
|
||||
#. Gather the **predefined** nodes
|
||||
|
||||
Using the ``bmcdiscover`` command, discover the nodes over an IP range and save the output to a file to use as a base for creating the **predefined** compute nodes.
|
||||
|
||||
To discover the BMC with an IP address of 172.30.0.1, use the command: ::
|
||||
|
||||
bmcdiscover --range 172.30.0.1 -z > predefined.stanzas
|
||||
|
||||
The discovered nodes has the naming convention: node-<*model-type*>-<*serial-number*> ::
|
||||
|
||||
# cat predefined.stanzas
|
||||
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
|
||||
bmc=172.30.0.1
|
||||
cons=ipmi
|
||||
mgt=ipmi
|
||||
mtm=8247-22L
|
||||
serial=10112CA
|
||||
|
||||
|
||||
#. Define the predefined node to xCAT: [#]_ ::
|
||||
|
||||
cat predefined_bmc.stanza | mkdef -z
|
||||
#. Gather the **discovered** nodes
|
||||
|
||||
Using the ``bmcdiscover`` command again to discover the nodes over the IP range, but use the ``-t`` option to get machine type information and the ``-w`` option to automatically write the output to the xCAT database.
|
||||
|
||||
To discover the BMC with an IP address of 172.30.0.1, use the command: ::
|
||||
|
||||
bmcdiscover --range 172.30.0.1 -t -z -w
|
||||
|
||||
The discovered nodes will be written to xCAT database: ::
|
||||
|
||||
# lsdef node-8247-22l-10112ca
|
||||
Object name: node-8247-22l-10112ca
|
||||
bmc=172.30.0.1
|
||||
cons=ipmi
|
||||
groups=all
|
||||
hwtype=bmc
|
||||
mgt=ipmi
|
||||
mtm=8247-22L
|
||||
nodetype=mp
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
serial=10112CA
|
||||
|
||||
|
||||
#. Edit the **predefined** nodes and set their intended ``hostname`` and ``IP adress``
|
||||
|
||||
#. Modify the predefined node using xCAT commands
|
||||
#. Edit the file saved from the above step. ::
|
||||
|
||||
#. Set the IP address for the compute node: ::
|
||||
vi predefined.stanzas
|
||||
|
||||
chdef cn1 ip=10.0.101.1
|
||||
#. Rename the object names to their intended compute node hostnames. ::
|
||||
|
||||
#. Set the BMC IP address to a different value: ::
|
||||
node-8247-22l-10112ca ==> cn01
|
||||
|
||||
chdef cn1 bmc=50.0.101.1
|
||||
#. Set the ``ip=`` attribute for the compute node IP address. ::
|
||||
|
||||
#. Set the chain table attribute to do BMC setup/discovery: ::
|
||||
ip=10.1.2.1
|
||||
|
||||
chdef cn1 chain="runcmd=bmcsetup"
|
||||
#. Repeat for additional nodes in the predefined.stanza file based on the MTMS mapping.
|
||||
|
||||
|
||||
#. Add the node information to ``/etc/hosts`` and DNS: ::
|
||||
In this example, our **predefined.stanzas** file now looks like the following: ::
|
||||
|
||||
# cat predefined.stanzas
|
||||
cn01:
|
||||
objtype=node
|
||||
groups=all
|
||||
bmc=172.30.0.1
|
||||
cons=ipmi
|
||||
mgt=ipmi
|
||||
mtm=8247-22L
|
||||
serial=10112CA
|
||||
ip=10.1.2.1
|
||||
|
||||
|
||||
#. Define the **predefined node** to xCAT: ::
|
||||
|
||||
cat predefined.stanzas | mkdef -z
|
||||
|
||||
#. **[Optional]** Change the BMC IP address from DHCP to STATIC
|
||||
|
||||
Some sites would prefer to configure the BMCs to use static IP addresses to avoid issues when DHCP leases expire. xCAT provides a way for the administrator to modify theDHCP IP address to a static IP address during the hardware discovery process using the xCAT chain concept.
|
||||
|
||||
Set the BMC IP address to a different value for the **predefined** compute node definitions.
|
||||
|
||||
To change the DHCP IP address of 172.30.0.1 to a STATIC IP address of 172.**20**.0.1, run the following command: ::
|
||||
|
||||
chdef cn01 bmc=172.20.0.1 chain="rumcmd=bmcsetup"
|
||||
|
||||
|
||||
#. Add the compute node IP information to ``/etc/hosts``: ::
|
||||
|
||||
makehosts cn01
|
||||
|
||||
#. Refresh the DNS configuration for the new hosts: ::
|
||||
|
||||
makehosts cn1
|
||||
makedns -n
|
||||
|
||||
#. **[Optional]** Monitor the node discovery process using rcons
|
||||
|
||||
#. [**Optional**] To monitor the node discovery process, configure conserver for the **discovered** nodes: ::
|
||||
Configure the conserver for the **discovered** node to watch the discovery process using ``rcons``::
|
||||
|
||||
makeconservercf node-8247-22l-10112ca
|
||||
|
||||
In another terminal window, open the remote console: ::
|
||||
|
||||
rcons node-8247-22l-10112ca
|
||||
|
||||
#. Start the discovery process by booting the **discovered** node definition: ::
|
||||
@ -81,11 +137,4 @@ When the IPMI-based server is connected to power, the BMC automatically boots up
|
||||
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.
|
||||
#. The discovery process will network boot the machine into the diskless xCAT genesis kernel and perform the discovery process. When the discovery process is complete, doing ``lsdef`` on the compute nodes should show discovered attributes for the machine. The important ``mac`` information should be discovered, which is necessary for xCAT to perform OS provisioning.
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
Environment
|
||||
===========
|
||||
|
||||
.. include:: ../schedule_environment.rst
|
||||
|
||||
@ -1,34 +1,27 @@
|
||||
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.
|
||||
MTMS stands for **M**\ achine **T**\ ype/\ **M**\ odel and **S**\ erial which is a way to uniquely define each physical server.
|
||||
|
||||
Pros and Cons
|
||||
-------------
|
||||
MTMS-based hardware discovery assumes the administator has the model type and serial number information for the physical servers and a plan for mapping the servers to intended hostname/IP addresses.
|
||||
|
||||
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
|
||||
--------
|
||||
**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.
|
||||
|
||||
**Pros**
|
||||
|
||||
* Limited effort to get servers defined using xCAT hardware discovery engine
|
||||
|
||||
**Cons**
|
||||
|
||||
* When compared to switch-based discovery, the administrator needs to create the **predefined-node** for each of the **discovered-nodes** stanzas. This could become difficult for a large number of servers.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
preverification.rst
|
||||
example_environment.rst
|
||||
verification.rst
|
||||
discovery.rst
|
||||
|
||||
@ -1,35 +0,0 @@
|
||||
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.
|
||||
|
||||
@ -0,0 +1,39 @@
|
||||
Verification
|
||||
============
|
||||
|
||||
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 hardware (with BMCs), verify that the xCAT ``passwd`` table contains an entry for ``ipmi`` which defines the username and password to communicate with the IPMI-based servers. ::
|
||||
|
||||
tabdump passwd | grep ipmi
|
||||
|
||||
If not configured, use the following command as an example to set the ``usernam=ADMIN`` and ``password=admin``. ::
|
||||
|
||||
chtab key=ipmi passwd.username=ADMIN passwd.password=admin
|
||||
|
||||
|
||||
Genesis Package
|
||||
---------------
|
||||
|
||||
The **xcat-genesis** packages provides the utility to create the genesis network boot rootimage used by xCAT when doing hardware discovery. 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 missing:
|
||||
|
||||
#. Install them from the ``xcat-dep`` repository using the Operating Specific package manager (``yum, zypper, apt-get, etc``)
|
||||
|
||||
#. Create the network boot rootimage with the following command: ``mknb ppc64``. The resulting genesis kernel should be present in ``/tftpboot/xcat`` directory.
|
||||
|
||||
@ -1,80 +0,0 @@
|
||||
MTMS-based Discovery
|
||||
====================
|
||||
|
||||
MTMS is short for Machine Type/Model and Serial which is unique for a physical server. The idea of MTMS based hardware discovery is that the admin know the physical location information of the server with specified MTMS. Then the admin can assign nodename and host ip address for the physical server.
|
||||
|
||||
.. include:: schedule_environment.rst
|
||||
.. include:: config_environment.rst
|
||||
|
||||
Discover server and define
|
||||
--------------------------
|
||||
|
||||
After environment is ready, and the server is powered, we can start server discovery process. The first thing to do is discovering the FSP/BMC of the server. It is automatically powered on when the physical server is powered.
|
||||
|
||||
The following command can be used to discover BMC(s) within an IP range and write the discovered node definition(s) into a stanza file::
|
||||
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -z > ./bmc.stanza
|
||||
|
||||
**Note**: bmcdiscover will use username/password pair set in ``passwd`` table with **key** equal **ipmi**. If you'd like to use other username/password, you can use ::
|
||||
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -z -u <username> -p <password> > ./bmc.stanza
|
||||
|
||||
You need to modify the node definition(s) in stanza file before using them, the stanza file will be like this::
|
||||
|
||||
# cat pbmc.stanza
|
||||
cn1:
|
||||
objtype=node
|
||||
bmc=50.0.100.1
|
||||
mtm=8247-42L
|
||||
serial=10112CA
|
||||
groups=pbmc,all
|
||||
mgt=ipmi
|
||||
|
||||
Then, define it into xCATdb::
|
||||
|
||||
# cat pbmc.stanza | mkdef -z
|
||||
1 object definitions have been created or modified.
|
||||
|
||||
The server definition will be like this::
|
||||
|
||||
# lsdef cn1
|
||||
Object name: cn1
|
||||
bmc=50.0.100.1
|
||||
groups=pbmc,all
|
||||
hidden=0
|
||||
mgt=ipmi
|
||||
mtm=8247-42L
|
||||
nodetype=mp
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
serial=10112CA
|
||||
|
||||
After the physical server is defined into xCATdb, the next thing is update the node definition with the example node attributes::
|
||||
|
||||
chdef cn1 ip=10.0.101.1
|
||||
|
||||
In order to do BMC configuration during the discovery process, set ``runcmd=bmcsetup``. For more info about chain, please refer to :doc:`Chain <../../../../../advanced/chain/index>` ::
|
||||
|
||||
chdef cn1 chain="runcmd=bmcsetup"
|
||||
|
||||
Then, add node info into /etc/hosts and DNS::
|
||||
|
||||
makehosts cn1
|
||||
makedns -n
|
||||
|
||||
|
||||
|
||||
Start discovery process
|
||||
-----------------------
|
||||
|
||||
To start discovery process, just need to power on the host remotely with the following command, and the discovery process will start automatically after the host is powered on::
|
||||
|
||||
rpower cn1 on
|
||||
|
||||
**[Optional]** If you'd like to monitor the discovery process, you can use::
|
||||
|
||||
chdef cn1 cons=ipmi
|
||||
makeconservercf
|
||||
rcons cn1
|
||||
|
||||
.. include:: standard_cn_definition.rst
|
||||
Loading…
x
Reference in New Issue
Block a user