`<< Back <../>`__ .. _5-hardware-delivery-and-configuration-requirements: 5. Hardware Delivery and Configuration Requirements =================================================== .. raw:: html

scope

Table of Contents ----------------- - `5.1 Introduction <#5.1>`__ - `5.2 Requirements <#5.2>`__ - `5.2.1 General <#5.2.1>`__ - `5.2.2 Check point <#5.2.2>`__ - `5.3 Descriptor file definition <#5.3>`__ - `5.3.1 Resource pool <#5.3.1>`__ - `5.3.2 NIC template <#5.3.2>`__ - `5.3.3 Cabinet <#5.3.3>`__ - `5.3.4 Server <#5.3.4>`__ - `5.3.5 Network device <#5.3.5>`__ - `5.3.6 EOR card <#5.3.6>`__ - `5.3.7 Cabling <#5.3.7>`__ - `5.3.8 Server model <#5.3.8>`__ - `5.3.9 Network device model <#5.3.9>`__ - `5.4 Appendix <#5.4>`__ - `5.4.1 HDV Original collection. <#5.4.1>`__ .. _51-introduction: 5.1 Introduction ---------------- **must**: Requirements that are marked as *must* are considered mandatory and must exist in the reference implementation and implemented by installer. The same applies to *must not*. **may**: Requirements that are marked as *may* are considered optional. The same applies to *may not*. .. _52-requirements: 5.2 Requirements ---------------- As we known, the NFVi software builds upon a set of hardware resources. For the operator(user) having a set of hardware resources, there is an inevitable step to examine it before deployment of the software. If there is only limited nodes for lab demonstration or something like this, it's acceptable to do it manually, however it would be a time consuming process especially there are large scale of hardware nodes, for example 1000 node. Also,adding the different provider's factor, that's much complicated to validate it and a headache thing if doing it in manual. In order to resolve this issue of how to validate hardware efficiently , we call on here to build up a common data model for describing the hardware data, which is extensible to large scale and can be recognized by some automated check tool (Let's call it checker). Let's also name it to description file, which is align with the one for software deployment definition already commited in another chapter. The description file defines the same information data model accross the hardware vendor provider. At present, in the first release,only the "readable" hardware parameter can be focused, in future release, "writable" parameter might add also. Besides, we also collect the common hardware check requiremnt here, most of which are origially from Prague meeting. We are expecting that by utilizing the common hardware description file, the check tool will perform all the neccessary hardware check point automatically. We believe this is a mutual interest for all operators having such needs. .. _521-general: 5.2.1 General ~~~~~~~~~~~~~ A Descriptor File defines the configuration required by the checker in a common schema. The "checker tool" validates the current hardware against the descriptor file, listing mismatches or differences, as failures, allowing the user to quickly identify and correct any errors in hardware, network wiring, or configuration. If failures are detected, the process can be rerun after corrective actions are taken. This checking process must be completed before the software stack deployment. +--------------------+--------------+--------------------------------+ | Ref # | sub-category | Description | +====================+==============+================================+ | ``req.gen.chk.01`` | Checker | Checker **must** accept a | | | | descriptor file to finish | | | | hardware delivery validation. | +--------------------+--------------+--------------------------------+ | ``req.gen.chk.02`` | Checker | Checker **must** report the | | | | checking result of success or | | | | failure with reason. | +--------------------+--------------+--------------------------------+ | ``req.gen.des.01`` | Descriptor | Descriptor file **must** | | | | include neccessary information | | | | to remote access hardware | | | | resource | +--------------------+--------------+--------------------------------+ | ``req.gen.des.02`` | Descriptor | Descriptor file **may** | | | | automate to generate from a | | | | user defined rule of how to | | | | generate asset name, IP | | | | address, gateways, VLAN ID, | | | | etc | +--------------------+--------------+--------------------------------+ .. raw:: html

Table 5-2-1: Check tool requirements

.. _522-check-point: 5.2.2 Check point ~~~~~~~~~~~~~~~~~ Till now, following the check point requirements are collected: (#5.4.1) +-----------------+-----------------+-----------------+------------+ | Test Type # | Purpose | Example | Check when | +=================+=================+=================+============+ | BIOS Settings | Verifies all | Boot mode/Boot | | | | applicable BIOS | Sequence | | | | settings per | Retry/AC Power | | | | hardware model. | Recovery/Power | | | | | Setting | | | | | (balanced / | | | | | per | | | | | formance)/Virt. | | | | | Technolo | | | | | gy/Simultaneous | | | | | Multith | | | | | reading/Trusted | | | | | platform module | | +-----------------+-----------------+-----------------+------------+ | Firmware | Verifies all | BIOS/Storage | | | Settings | applicable | Array | | | | Firmware | Controller/NIC | | | | settings. | (e.g.Intel | | | | | X710)/PXE | | | | | Enabled Ports | | +-----------------+-----------------+-----------------+------------+ | Boot Order | Verifies | First boot, | | | | applicable boot | Second boot. | | | | order settings. | | | +-----------------+-----------------+-----------------+------------+ | Hardware Health | Queries | Raid/System | | | | Intelligent | Board/CPU | | | | Platform | temp/Power | | | | Management | Supply | | | | Interface | | | | | (IPMI) is for | | | | | all hardware | | | | | components and | | | | | their health | | | | | status. | | | +-----------------+-----------------+-----------------+------------+ | PCI Slot Status | Which cards are | card(s) in | | | & MAC | in which slot, | slot/port/PCI | | | | which slot is | partition /Slot | | | | assigned to | speed / type / | | | | which CPU, slot | CPU / Slot | | | | type | assignment | | +-----------------+-----------------+-----------------+------------+ | NIC | Validates that | Correct LLDP | | | | all NICs are in | neighbor MAC | | | | the correct | Addresses. | | | | slots, with a | | | | | healthy status | | | | | (per IPMI), | | | | | have correct | | | | | MAC addresses, | | | | | and are | | | | | detecting a | | | | | cable | | | | | connection (or | | | | | not). | | | +-----------------+-----------------+-----------------+------------+ | IPMI Logs | Check for | Physical event | | | | existence of | logged. E.g. | | | | logs. | chassis open on | | | | | power up. | | +-----------------+-----------------+-----------------+------------+ | IPMI Users | Check for | Check if IPMI | | | | existence of | is available, | | | | user accounts. | if IPMI account | | | | | is existing, if | | | | | IPMI default | | | | | credentials. | | +-----------------+-----------------+-----------------+------------+ | Hardware | Inventory of | CPU and count, | | | Inventory | h/w on | NUMA topology, | | | | platform. | CPU Freq, RAM, | | | | | speed, size, | | | | | model, etc. | | +-----------------+-----------------+-----------------+------------+ | Physical Disk | Verifies | Physical disk | | | Configuration | storage / disk | type, card/port | | | | config (type, | lo | | | | size) | cation,capacity | | +-----------------+-----------------+-----------------+------------+ | SRIOV Port | Verifies global | Confirm setting | | | Validation | and NIC level | is enabled (or | | | | enabled. | none) | | +-----------------+-----------------+-----------------+------------+ | Hardware Check | Verifies basic | RAM size/number | | | | OS config | of cores. | | | | attributes | | | | | (i.e. Linux | | | | | running on the | | | | | host and | | | | | reporting these | | | | | values). | | | +-----------------+-----------------+-----------------+------------+ | Cabling | Verifies the | Check if | | | Connection | wired | cabling is | | | check | connection | plugin correct | | | | between server | as expected | | | | NIC port and | design data | | | | switch port, or | | | | | the between | | | | | switches. | | | +-----------------+-----------------+-----------------+------------+ | Redfish | Verifies that | system | | | interface | support classic | service/Manager | | | | interface. | servi | | | | | ce/ChassisServi | | | | | ce/SessionServi | | | | | ce/AccountServi | | | | | ce/EventService | | | | | etc. | | +-----------------+-----------------+-----------------+------------+ .. raw:: html

Table 5-2-2: Hardware check point.

.. _53-descriptor-file-definition: 5.3 Descriptor file definition ------------------------------ As mentioned at the beginning, the description file is used to define the common hardware data which are used by the checker implementation The entry information must be included in the description file,which are the remote access parameter settings. .. _531-resource-pool: 5.3.1 Resource pool ~~~~~~~~~~~~~~~~~~~ Resource pool is the conception which a NFV resource is planned to build up. It consists hardware server device, network device and cabling among them. It is referenced by other resource type to introduce later. +--------------------+--------+-----------+---------------------------------------+ | Field # | type | mandatory | Instruction | +====================+========+===========+=======================================+ | serial_no | String | Yes | | +--------------------+--------+-----------+---------------------------------------+ | resource_pool_name | String | Yes | resource name, e.g: NFV-RP-HZZZ-03A_0 | +--------------------+--------+-----------+---------------------------------------+ | type | String | Yes | TOCHECK: OTHER | +--------------------+--------+-----------+---------------------------------------+ .. raw:: html

Table 5-3-1: Resource pool.

.. _532-nic-template: 5.3.2 NIC template ~~~~~~~~~~~~~~~~~~ NIC Template defines network interface card parameters, it includes the crucial port number on the NIC, which is used as the reference in the cabling data and check. +------------------+--------+-----------+----------------------+ | Field # | type | mandatory | Instruction | +==================+========+===========+======================+ | serial_no | String | Yes | | +------------------+--------+-----------+----------------------+ | vendor | String | Yes | vendor name: | | | | | ZTE,HUAWEI | +------------------+--------+-----------+----------------------+ | server_type | String | Yes | ZTE "R5300 G4", | | | | | HUAWEI | | | | | "TaiShan200-2280" | +------------------+--------+-----------+----------------------+ | customized_model | String | No | customized model: | | | | | C2,C21 | +------------------+--------+-----------+----------------------+ | nic_vendor | String | Yes | nework interface | | | | | card vendor: intel | +------------------+--------+-----------+----------------------+ | nic_type | String | Yes | Intel "x520" | +------------------+--------+-----------+----------------------+ | rootbdf | String | Yes | e.g "00:03:01:00" | +------------------+--------+-----------+----------------------+ | slot_id | String | Yes | the slot id number | | | | | of card plugged-in | +------------------+--------+-----------+----------------------+ | connect_type | String | Yes | plugin | +------------------+--------+-----------+----------------------+ | port_quantity | Number | Yes | port quantity on the | | | | | card. e.g. 2 | +------------------+--------+-----------+----------------------+ | port_bandwith | String | Yes | bandwith of port. | | | | | e.g. 10G | +------------------+--------+-----------+----------------------+ | cabling_ports | Number | Yes | port name used in | | | | | the cabing data. | | | | | corresponding the | | | | | quantity e.g: | | | | | 1_1;1_2 or | | | | | Slo | | | | | t3/Port1;Slot3/Port2 | +------------------+--------+-----------+----------------------+ .. raw:: html

Table 5-3-2: NIC template.

.. _533-cabinet: 5.3.3 Cabinet ~~~~~~~~~~~~~ Cabinet is the rack holder for the server and network devices. The data will be referenced by server and network device data. ========= ====== ========= ======================================= Field # type mandatory Instruction ========= ====== ========= ======================================= serial_no String Yes room String Yes room number, e.g: 2201 column String Yes column number in the room: e.g. "J" cabinet String Yes cabinet number in the column: e.g. "01" ========= ====== ========= ======================================= .. raw:: html

Table 5-3-3: Cabinet.

.. _534-server: 5.3.4 Server ~~~~~~~~~~~~ The server device data defines key information about how to access the server remotely, for example remote IP address, user, and credentials. There are many ways to validate the hardware by remote interface verification, for example IPMI and redfish. Considering the number of servers, the user can choose to validate the server interface in a distributed way or in a centralized way. Distributed validation means that the server connects to the hardware management device (for example, BMC and IPMI) to validate the connection. Centralized validation means that the hardware management device connects to the server to validate the connection. The best practice is to use centralized validation when the number of servers is small (for example, storage servers), and use distributed validation when the number of servers is large (for example, generic servers). +--------------------+--------+-----------+----------------------+ | Field # | type | mandatory | Instruction | +====================+========+===========+======================+ | serial_no | String | Yes | | +--------------------+--------+-----------+----------------------+ | server_name | String | Yes | server name, e.g: | | | | | NFV-D-HZZZ-03 | | | | | A-2201-0J01-M-SRV-01 | +--------------------+--------+-----------+----------------------+ | vendor | String | Yes | vendor name | | | | | "ZTE","HUAWEI" etc | +--------------------+--------+-----------+----------------------+ | server_type | String | Yes | ZTE "R5300 G4", | | | | | HUAWEI | | | | | "TaiShan200-2280" | +--------------------+--------+-----------+----------------------+ | customized_model | String | No | customized model: | | | | | C2,C21 | +--------------------+--------+-----------+----------------------+ | server_sn | String | Yes | server serial number | +--------------------+--------+-----------+----------------------+ | resource_pool_name | String | Yes | resource pool name | | | | | which belongs to | +--------------------+--------+-----------+----------------------+ | cabinet | String | Yes | cabinet which | | | | | belongs to, in | | | | | format | | | | | room-column-cabinet, | | | | | e.g. "2201-J-01" | +--------------------+--------+-----------+----------------------+ | position | String | Yes | the server position | | | | | located in the | | | | | cabinet. | +--------------------+--------+-----------+----------------------+ | remote_ip | String | Yes | BMC/iLO/IPMI ip for | | | | | remote access, e.g | | | | | "2 | | | | | 409:8086:8313:81::1" | +--------------------+--------+-----------+----------------------+ | gateway | String | Yes | gateway of remote | | | | | ip, e.g | | | | | "2409 | | | | | :8086:8313:81::ffff" | +--------------------+--------+-----------+----------------------+ | outband_netmask | String | Yes | e.g. "64" | +--------------------+--------+-----------+----------------------+ | subnet | String | Yes | e.g. | | | | | "2409:8086:8313:81" | +--------------------+--------+-----------+----------------------+ | remote_user | String | Yes | e.g. "Administrator" | +--------------------+--------+-----------+----------------------+ | remote_password | String | Yes | e.g. "password" | +--------------------+--------+-----------+----------------------+ | inband_ip | String | No | temporary inband_ip | | | | | e.g | | | | | "2 | | | | | 409:8086:8313:f::24" | +--------------------+--------+-----------+----------------------+ | inband_gateway | String | No | gateway of inband | | | | | ip, e.g | | | | | "240 | | | | | 9:8086:8313:f::ffff" | +--------------------+--------+-----------+----------------------+ | inband_netmask | String | No | e.g. "64" | +--------------------+--------+-----------+----------------------+ | group | String | Yes | network assignment | | | | | "service | | | | | /management/storage" | +--------------------+--------+-----------+----------------------+ | is_bmc_configured | String | Yes | TOCHECK | +--------------------+--------+-----------+----------------------+ .. raw:: html

Table 5-3-4: Server.

.. _535-network-device: 5.3.5 Network device ~~~~~~~~~~~~~~~~~~~~ network device data defines the key data about how to remote access the network device, such as switches and routers. +--------------------+--------+-----------+----------------------+ | Field # | type | mandatory | Instruction | +====================+========+===========+======================+ | serial_no | String | Yes | | +--------------------+--------+-----------+----------------------+ | device_name | String | Yes | device name, e.g: | | | | | "NFV-D-HZZZ-03A- | | | | | 2201-0F01-DM-TOR-01" | +--------------------+--------+-----------+----------------------+ | vendor | String | yes | vendor name | | | | | "ZTE","HUAWEI" etc | +--------------------+--------+-----------+----------------------+ | device_model | String | Yes | maipu "S4320", | | | | | HUAWEI "CE6856" | +--------------------+--------+-----------+----------------------+ | device_sn | String | No | vendor name | | | | | "ZTE","HUAWEI" etc | +--------------------+--------+-----------+----------------------+ | device_type | String | Yes | "EOR","TOR" | +--------------------+--------+-----------+----------------------+ | resource_pool_name | String | Yes | resource pool name | | | | | which belongs to , | | | | | e.g. | | | | | "NFV-RP-HZZZ-03A_0" | +--------------------+--------+-----------+----------------------+ | cabinet | String | Yes | cabinet which | | | | | belongs to, in | | | | | format | | | | | room-column-cabinet, | | | | | e.g. "2201-J-01" | +--------------------+--------+-----------+----------------------+ | position | String | Yes | the server position | | | | | located in the | | | | | cabinet. | +--------------------+--------+-----------+----------------------+ | remote_ip | String | Yes | BMC/iLO/IPMI/redfish | | | | | ip for remote | | | | | access, e.g | | | | | "2 | | | | | 409:8086:8313:81::1" | +--------------------+--------+-----------+----------------------+ | gateway | String | Yes | gateway of remote | | | | | ip, e.g | | | | | "2409 | | | | | :8086:8313:81::ffff" | +--------------------+--------+-----------+----------------------+ | netmask | String | Yes | e.g. "64" | +--------------------+--------+-----------+----------------------+ | mac_address | String | Yes | mac address | +--------------------+--------+-----------+----------------------+ | protocol | String | Yes | ssh/telnet/redfish | | | | | etc. | +--------------------+--------+-----------+----------------------+ | user | String | Yes | e.g. "Administrator" | +--------------------+--------+-----------+----------------------+ | password | String | Yes | e.g. "password" | +--------------------+--------+-----------+----------------------+ | enable_password | String | Yes | e.g. "password" | +--------------------+--------+-----------+----------------------+ | group | String | Yes | network assignment | | | | | "service | | | | | /management/storage" | +--------------------+--------+-----------+----------------------+ .. raw:: html

Table 5-3-5: Network device.

.. _536-eor-card: 5.3.6 EOR card ~~~~~~~~~~~~~~ EOR card data. =============== ====== ========= =============== Field # type mandatory Instruction =============== ====== ========= =============== serial_no String Yes eor_device_name String Yes EOR device name card_model String Yes card model slot String Yes slot e.g. "01" =============== ====== ========= =============== .. raw:: html

Table 5-3-6: EOR Card.

.. _537-cabling: 5.3.7 Cabling ~~~~~~~~~~~~~ Cabling records the physical cable connection information between the ports of server and switch, or switches. Check tool will verify the correctness according to the cabling data. +--------------------+--------+-----------+----------------------+ | Field # | type | mandatory | Instruction | +====================+========+===========+======================+ | serial_no | String | Yes | | +--------------------+--------+-----------+----------------------+ | source_cabinet | String | Yes | source cabinet which | | | | | belongs to, in | | | | | format | | | | | room-column-cabinet, | | | | | e.g. "2201-J-01" | +--------------------+--------+-----------+----------------------+ | source_device_name | String | yes | server,switch device | | | | | name e.g | | | | | "NFV-D-HZZZ-03A- | | | | | 2201-0G12-DM-TOR-01" | +--------------------+--------+-----------+----------------------+ | source_device_type | String | Yes | switch or server | +--------------------+--------+-----------+----------------------+ | source_port | String | Yes | e.g | | | | | "gigabitethernet0/2" | +--------------------+--------+-----------+----------------------+ | target_cabinet | String | Yes | source cabinet which | | | | | belongs to, in | | | | | format | | | | | room-column-cabinet, | | | | | e.g. "2201-J-02" | +--------------------+--------+-----------+----------------------+ | target_device_name | String | yes | server,switch device | | | | | name e.g | | | | | "NFV-D-HZZZ-03A- | | | | | 2201-0G12-DM-TOR-01" | +--------------------+--------+-----------+----------------------+ | target_device_type | String | Yes | switch or server | +--------------------+--------+-----------+----------------------+ | target_port | String | Yes | e.g | | | | | "gigabitethernet0/2" | +--------------------+--------+-----------+----------------------+ | cabling_type | String | Yes | e.g | | | | | "SV-TO | | | | | R","TOR-TOR","ST_TOR | | | | | -ST_EOR","S_TOR-S_EO | | | | | R","S_TOR-M_EOR","M_ | | | | | TOR-M_EOR","EOR-EOR" | +--------------------+--------+-----------+----------------------+ .. raw:: html

Table 5-3-7: Cabling.

.. _538-server-model: 5.3.8 Server model ~~~~~~~~~~~~~~~~~~ The server model describes processor, memory, harddrive, raid,manufacturer, model etc. server model will be referenced by servers. +----------------------+--------+-----------+----------------------+ | Field # | type | mandatory | Instruction | +======================+========+===========+======================+ | name | String | Yes | model name will | | | | | referenced by server | +----------------------+--------+-----------+----------------------+ | manufacturer | String | Yes | | +----------------------+--------+-----------+----------------------+ | model | String | Yes | | +----------------------+--------+-----------+----------------------+ | processor | String | Yes | | +----------------------+--------+-----------+----------------------+ | memory | String | Yes | | +----------------------+--------+-----------+----------------------+ | hard_drive | String | Yes | | +----------------------+--------+-----------+----------------------+ | raid | String | Yes | | +----------------------+--------+-----------+----------------------+ | network_card_infos | List | No | interface list | | | | | definition | +----------------------+--------+-----------+----------------------+ | net | List | No | NIC bonding, might | | work_card_bond_infos | | | not be always the | | | | | case. | +----------------------+--------+-----------+----------------------+ .. raw:: html

Table 5-3-8: Server model.

.. _539-network-device-model: 5.3.9 Network device model ~~~~~~~~~~~~~~~~~~~~~~~~~~ The network device model describes processor, memory,manufacturer, model etc. network device model will be referenced by network device. +---------------+--------+-----------+----------------------------------------------+ | Field # | type | mandatory | Instruction | +===============+========+===========+==============================================+ | name | String | Yes | model name will referenced by network device | +---------------+--------+-----------+----------------------------------------------+ | manufacturer | String | Yes | | +---------------+--------+-----------+----------------------------------------------+ | model | String | Yes | | +---------------+--------+-----------+----------------------------------------------+ | processor | String | Yes | | +---------------+--------+-----------+----------------------------------------------+ | port_type | String | Yes | port type | +---------------+--------+-----------+----------------------------------------------+ | port_quantity | String | Yes | total number of port | +---------------+--------+-----------+----------------------------------------------+ | memory | String | Yes | | +---------------+--------+-----------+----------------------------------------------+ | version | String | Yes | | +---------------+--------+-----------+----------------------------------------------+ .. raw:: html

Table 5-3-9: Network device model.

.. _54-appendix: 5.4 Appendix ------------ .. _541-hdv-original-collection: 5.4.1 HDV original collection. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `CNTT Hardware Delivery Validation (01-2020 DDF) `__