wiki.hpc.mk - User contributions [en]

Authentication Mechanism

2021-08-31T12:55:10Z

Boris:

{| class="wikitable" style="width: 100%; background-color:#ffffff; border-width: 0px"
! style="text-align:left; background-color:#F1EDEC" |Contents
|-
|
#[[Authentication_Mechanism#Autentication_Setting|Setting up a user authentication mechanism]]
#[[Authentication_Mechanism#Autentication_Database|Setting up a local database for storing users and policies]]
#[[Authentication_Mechanism#Autentication_Database_Config|Database configuration for storing user information]]
#[[Authentication_Mechanism#Autentication_Partition|Partition model and division of execution space ]]
|}
__NOTOC__

'''<h1 id="Autentication_Setting">Setting up a user authentication mechanism</h1>'''

For greater security in the communication of the master server with the clients, it is necessary to set up two-way authentication with the help of a shared key. According to standard practice, Slurm uses the munge protocol to validate the mutual communication of system components. In short, it is designed for large HPC environments, in which the UID and GID identifiers of users and groups are validated with a shared cryptographic key. It typically uses a 128 AES encryption scheme as well as a SHA-256 hash validation message. The generated key is then copied to all nodes to be used in the cluster along with the corresponding permissions. It should also be noted that users who will use Slurm should have the same UID and GUID everywhere, for better security and further authentication when sending tasks.

'''<h1 id="Autentication_Database">Setting up a local database for storing users and policies</h1>'''

Mariadb is used as a database to store user data. In the initial installation, tables should be created for storing data about the users, their properties, the groups they join as well as the permissions or policies that are allowed accordingly. Then the appropriate service is installed to monitor all these processes, SlurmDBD. The main and basic task of this process involves collecting data from multiple clusters at one location for all user activities.

Each user's UID is used as the main identifier, which can keep detailed statistics for each task that a user will perform. The authentication is done through the munge service, which checks the list of users on each node (reads the contents of Linux file /etc/passwd) and based it stores the information about every user. There are several different tables in which this data is written, the most important of which are:

* AccountingStorageType - Controlling the steps performed by the task as well as the required resources,
* JobCompType - Writing data about the tasks, which contains basic information such as name, user who started it, allocated nodes and resources, start time, completion time, output status. This table can be expanded with additional information about the databases it uses (MySQL or MariaDB).

Enrollment control is done by the slurmctld service (the main slurm cluster control process). Thus, potential sensitive data that is available to all users in the process should be properly protected and authenticated. The same applies if the data is sent through a network protocol (TCP, UDP) where full protection should be provided throughout the communication channel. The data stored directly in the database are encrypted with an appropriate protocol that provides security and protection in case of possible system abuses.

'''<h1 id="Autentication_Database_Config">Database configuration for storing user information</h1>'''

In addition to the standard way of storing data in a text file (which is the basic way of storing all SLURM data), in our case we use MariaDB database system. It provides high availability and tolerance in case of unwanted hardware or physical problems, which activates the backups of the databases. Newer versions of MySQL and MariaDB use InnoDB as the main table management service. The most important features when configuring InnoDB include the following parameters:
* Innodb_buffer_pool_size - The size of bytes in the buffer space, which caches all tables and indexes of the data. Depending on the processor architecture (32 or 64 bits) the maximum value in bytes is set. A higher value requires a larger amount of disk I / O operations when accessing the same table multiple times. In our case that value is set to 1024MB,
* Innodb_lock_wait_timeout - Time expressed in seconds to execute an InnoDB transaction waiting to access a queue locked by another process. In principle, if a certain transaction (INSERT or UPDATE) waits longer than the above defined, then the transaction is canceled and a roll-back is made to the entire operation. In our case the value is set to 900 seconds (i.e. 15 minutes),
*Innodb_page_size - The size of the data expressed in data files, with a standard size of 16KB. These files are organized as segments, and if a row in a table is larger than the default value, multiple files are combined into a single segment. Smaller sizes are generally recommended for drives with SSD technology for higher performance.

'''<h1 id="Autentication_Partition">Partition model and division of execution space</h1>'''

Slurm architecture involves dividing machines (nodes) into larger logical units, which depending on the resources they use (CPU, RAM, GPU) can be grouped to perform multiple common tasks. The configuration in this way is done through the partition model, which builds a set of related elements with common attributes. When performing the task, each step or sub-step of the task can be located on different partitions, depending on the task.
The user can further optimize resources by parallel running of the task steps when allocating the task configuration. As an example, a task may allocate all nodes declared for that task or several parts of the task independently use only a small portion of the resource allocation. Such an example is shown in fig. 2, by a division into two main partitions for each different task.

MediaWiki:Sidebar

2021-08-31T12:54:51Z

Boris:

MediaWiki:Sidebar

2021-08-31T12:54:39Z

Boris:

Autentication Mechanism

2021-08-31T12:54:09Z

Boris: Boris moved page Autentication Mechanism to Authentication Mechanism

#REDIRECT [[Authentication Mechanism]]

Authentication Mechanism

2021-08-31T12:54:09Z

Boris: Boris moved page Autentication Mechanism to Authentication Mechanism

{| class="wikitable" style="width: 100%; background-color:#ffffff; border-width: 0px"
! style="text-align:left; background-color:#F1EDEC" |Contents
|-
|
#[[Autentication_Mechanism#Autentication_Setting|Setting up a user authentication mechanism]]
#[[Autentication_Mechanism#Autentication_Database|Setting up a local database for storing users and policies]]
#[[Autentication_Mechanism#Autentication_Database_Config|Database configuration for storing user information]]
#[[Autentication_Mechanism#Autentication_Partition|Partition model and division of execution space ]]
|}
__NOTOC__

'''<h1 id="Autentication_Setting">Setting up a user authentication mechanism</h1>'''

For greater security in the communication of the master server with the clients, it is necessary to set up two-way authentication with the help of a shared key. According to standard practice, Slurm uses the munge protocol to validate the mutual communication of system components. In short, it is designed for large HPC environments, in which the UID and GID identifiers of users and groups are validated with a shared cryptographic key. It typically uses a 128 AES encryption scheme as well as a SHA-256 hash validation message. The generated key is then copied to all nodes to be used in the cluster along with the corresponding permissions. It should also be noted that users who will use Slurm should have the same UID and GUID everywhere, for better security and further authentication when sending tasks.

'''<h1 id="Autentication_Database">Setting up a local database for storing users and policies</h1>'''

Mariadb is used as a database to store user data. In the initial installation, tables should be created for storing data about the users, their properties, the groups they join as well as the permissions or policies that are allowed accordingly. Then the appropriate service is installed to monitor all these processes, SlurmDBD. The main and basic task of this process involves collecting data from multiple clusters at one location for all user activities.

Each user's UID is used as the main identifier, which can keep detailed statistics for each task that a user will perform. The authentication is done through the munge service, which checks the list of users on each node (reads the contents of Linux file /etc/passwd) and based it stores the information about every user. There are several different tables in which this data is written, the most important of which are:

* AccountingStorageType - Controlling the steps performed by the task as well as the required resources,
* JobCompType - Writing data about the tasks, which contains basic information such as name, user who started it, allocated nodes and resources, start time, completion time, output status. This table can be expanded with additional information about the databases it uses (MySQL or MariaDB).

Enrollment control is done by the slurmctld service (the main slurm cluster control process). Thus, potential sensitive data that is available to all users in the process should be properly protected and authenticated. The same applies if the data is sent through a network protocol (TCP, UDP) where full protection should be provided throughout the communication channel. The data stored directly in the database are encrypted with an appropriate protocol that provides security and protection in case of possible system abuses.

'''<h1 id="Autentication_Database_Config">Database configuration for storing user information</h1>'''

In addition to the standard way of storing data in a text file (which is the basic way of storing all SLURM data), in our case we use MariaDB database system. It provides high availability and tolerance in case of unwanted hardware or physical problems, which activates the backups of the databases. Newer versions of MySQL and MariaDB use InnoDB as the main table management service. The most important features when configuring InnoDB include the following parameters:
* Innodb_buffer_pool_size - The size of bytes in the buffer space, which caches all tables and indexes of the data. Depending on the processor architecture (32 or 64 bits) the maximum value in bytes is set. A higher value requires a larger amount of disk I / O operations when accessing the same table multiple times. In our case that value is set to 1024MB,
* Innodb_lock_wait_timeout - Time expressed in seconds to execute an InnoDB transaction waiting to access a queue locked by another process. In principle, if a certain transaction (INSERT or UPDATE) waits longer than the above defined, then the transaction is canceled and a roll-back is made to the entire operation. In our case the value is set to 900 seconds (i.e. 15 minutes),
*Innodb_page_size - The size of the data expressed in data files, with a standard size of 16KB. These files are organized as segments, and if a row in a table is larger than the default value, multiple files are combined into a single segment. Smaller sizes are generally recommended for drives with SSD technology for higher performance.

'''<h1 id="Autentication_Partition">Partition model and division of execution space</h1>'''

Slurm architecture involves dividing machines (nodes) into larger logical units, which depending on the resources they use (CPU, RAM, GPU) can be grouped to perform multiple common tasks. The configuration in this way is done through the partition model, which builds a set of related elements with common attributes. When performing the task, each step or sub-step of the task can be located on different partitions, depending on the task.
The user can further optimize resources by parallel running of the task steps when allocating the task configuration. As an example, a task may allocate all nodes declared for that task or several parts of the task independently use only a small portion of the resource allocation. Such an example is shown in fig. 2, by a division into two main partitions for each different task.

MediaWiki:Sidebar

2021-08-31T10:13:45Z

Boris:

Slurm Services

2021-08-31T10:12:45Z

Boris:

{|class="wikitable" style="width: 100%; background-color:#ffffff; border-width: 0px"
!style="text-align:left; background-color:#F1EDEC"|Contents
|-
|
#[[Slurm_Services#Services_Documenting|Documentation for creating SLURM Workload Manager]]
#[[Slurm_Services#Services_Installation|Required installation and predefined environment ]]
|}

__NOTOC__

'''<h1 id="Services_Documenting">Documentation for creating SLURM Workload Manager</h1>'''

Creating a scheduler in a heterogeneous cluster environment covers the following: First it is necessary to define which will be the main (master) node that will properly forward the user-defined scripts in the form of jobs to the defined machines in the cluster. There are several different platforms for creating a cluster environment, in this document SLURM Workload Manager will be discussed.

Advantages of using Slurm as a task environment are:
* Support for high cluster systems and multiprocessor tasks - The SLURM environment enables the start-up, execution and monitoring of parallel tasks implemented via Message Passing Interface (MPI), on part of the allocated nodes as well as allowing efficient use of resources (nodes) according to a specific policy users,
* Task profiling - Periodically review each resource assigned to a specific task (CPU runtime, RAM, power consumption, network resources, and disk space usage),
* Support for MapReduce + algorithm,
* Support for creating a sequence of tasks, ie one task can be divided into several sub-tasks that are performed in parallel for more efficient use of the given resources,
* Database integration - where all user parameters and settings are stored,
* Use of graphic resources to perform tasks - A large number of optional possibilities for additional use of graphic resources given to a specific task / tasks in order to better perform advanced algorithms in the field of machine learning.

'''<h1 id="Services_Installation">Required installation and predefined environment</h1>'''

First during the initial installation, a Linux Ubuntu 20.04 environment was used, with the necessary installation packages. The installation on the server side includes the installation of:
* Slurmctld - The main process through which the execution and assignment of tasks to the nodes used takes place. The same is used for monitoring the active nodes (machines) in the cluster,
* Slurmdbd - Process through which the registration of user data, their rules and policies as well as the allowed execution times takes place,
* Slurmd- Process through which the other children are controlled - Slurm sub-processes and through which the further communication with the other elements of the system takes place.

Slurm Services

2021-08-31T10:11:00Z

Boris:

Slurm Services

2021-08-31T10:10:46Z

Boris:

Slurm Services

2021-08-31T10:10:29Z

Boris:

Slurm Services

2021-08-31T10:07:33Z

Boris: Created page with "Documentation for creating SLURM Workload Manager"

Documentation for creating SLURM Workload Manager

MediaWiki:Sidebar

2021-08-31T09:28:13Z

Boris:

2021-08-30T10:30:42Z

Boris: