Arabic Arabic Chinese (Simplified) Chinese (Simplified) Dutch Dutch English English French French German German Italian Italian Portuguese Portuguese Russian Russian Spanish Spanish
| (844) 627-8267
0

Understanding Multipath Logic on Linux Servers | #linux | #linuxsecurity | #hacking | #aihp


Multipath is a fault-tolerance technique that generally aims to back up the connection of physical servers with storage. When there is damage to the fiber cables, it is important that the server does not lose access to the storage and maintains accessibility. That’s why systems like banks and global e-commerce sites use multipath.

Here’s everything you need to know about multipath on Linux.

Identifiers for Multipath Devices on Servers

For multipath, it is also necessary to browse for multipath devices. If you’ve ever heard of the WWID (World Wide Identifier) ​​concept before, it won’t sound too foreign to you.

By default, the names of multipath devices are set to their WWID. This is a system that guarantees that the multipath device is globally unique and immutable. You can set the default naming here with some manipulations to the multipath configuration file by changing the user_friendly_names setting.

As an example, you can think of it like this. Imagine you have storage devices connected to your server such as:

  • /dev/sda
  • /dev/sdb
  • /dev/sdc
  • /dev/sdd

If the user_friendly_names option is set to “yes” at this point, the device names will change.

cat /etc/multipath.conf


defaults {
user_friendly_names yes
}

If you have an Ubuntu server that uses virtualization technologies, you might receive the following outcome. What you must remember here is that the device you wish to control must be a physical device.

After you set the user_friendly_names option to yes in the configuration file, you can check the device name as follows:

sudo fdisk -l

Procedure for Consistent Multipath Device Names

The name assigned to the multipath devices by this procedure will be unique to a node. It is not feasible to state that it applies to all nodes. If you want consistent multipath devices on all nodes, set the user_friendly_names option to “no”. You will reduce any troubles in this manner as the devices will no longer have a unique moniker and will instead utilize WWID.

However, in other circumstances, you may wish to design nodes that are both consistent and easier to reach and utilize.

For such a case, you must first install all multipath devices on one machine. You should also disable all multipath devices on other machines after this step. You can run the following commands for this:

sudo systemctl stop multipath-tools.service
sudo multipath -F

With these commands, you will respectively stop the multipath service and clear all multipath device maps. Now become a root user and copy the bindings file located in the /etc/multipath directory to other machines.

At this point, you will be using the daemon processes of Linux. After all these steps, you need to run the multipathd daemon again:

sudo systemctl start multipath-tools.service

Overview of General Features of Multipath Devices

Multipath devices’ features and configuration settings are not limited to user_friendly_names. Below you will find information about some other configurations you can make in the /etc/mutipath.conf file:

  • blacklist { }: If you want to specify which devices to exclude from multipath, you can write their names between the two curly braces.
    blacklist {
    devnode "^sda"
    }
  • devices { }: Between these two curly brackets, you can put some details for specific devices.
    devices {
    vendor "DELL"
    product "MD32xx"
    }
  • multipath { }: In this field, you can set the attributes of specific multipath devices. As with other attributes, multipath also has many different sub-attributes.
    multipath {
    wwid 3500405b170164c3911244b325426400b
    alias yellow
    failback manual
    }
  • blacklist_exceptions { }: This field is for devices that are on the blacklist but you want multipath enabled for them. Instead of blacklisting all devices one by one, you can blacklist them all and specify the ones you want to use later in this field.
    blacklist_exceptions {
    wwid "3500405b170164c3911244b325426400b"
    }

Of course, not all attributes are limited to these, and each attribute has its own sub-qualities. Moreover, you can use them in tandem with each other. Below is a sample configuration file for you to review:

defaults {
user_friendly_names no
}
blacklist {
devnode "^sda"
}
blacklist_exceptions {
devnode "sda|sdb"
device {
vendor "DELL"
product "MD32xx"
}
}
devices {
device {
vendor "HP"
product "A6189A"
}
}
multipaths {
multipath {
wwid 3500405b170164c3911244b325426400b
alias red
}
}

Logic in Multipath Devices

You can think of multipath devices as physical units. For example, let /dev/mapper/mpatha be the name of a multipath device. This device will act as a physical unit. When you create an LVM (Logical Volume Management), you will also need to edit the /etc/lvm.conf file.

With the configurations you make here, you will need to filter the disks under the multipath devices. If you don’t, LVM will scan the passive path and multipath will start working again, because the active path can automatically change to the passive path.

To prevent this, you can do the following manipulation on the /etc/lvm.conf file:

filter = [ "a/loop.*/", "r/.*/" ]

This command will add loops and remove all devices. However, the process does not end there. After making this change in /etc/lvm.conf, save the file, and update the initrd as well. initrd allows you to perform some manipulations on the RAM disk. The reason you make changes here is to copy them at boot time.

update-initramfs -u -k all

Every time the lvm.conf and multipath.conf files are updated, it is necessary to perform this update on initramfs. This is how you get a stable and sustainable server. You should also not forget about the initramfs update, especially if you have made changes to the blacklist and filter attributes.

Importance of a Multipath System

In multipath environments, servers can continue to access disks even if one of the components (HBA, SAN, storage controller) they use fails. This is a matter of particular interest to system and server administrators.

It is very important for high-traffic servers that contain important information, where security protocols must be high. Because if the server of a website with thousands of credit card information or hundreds of thousands of registered customers is inaccessible because only one component malfunctioned, it would be a huge problem.

It is necessary to master the details of all these operations and the sub-attributes of the attributes in the configuration file. This is because making server configurations always involves a risk. For this type of operation, it makes sense to back up everything or run tests on a test server.

If you don’t have a server to test all this on, installing Ubuntu Server is the optimal choice and is pretty simple too.

Click Here For The Original Source.


————————————————————————————-

National Cyber Security

FREE
VIEW