Global Site

Displaying present location in the site.

Points to Note When Building a Mirror Disk Type Cluster on Linux in a Cloud Environment

EXPRESSCLUSTER Official Blog

October 27th, 2021

Machine translation is used partially for this article. See the Japanese version for the original article.

Introduction

Here are some things to keep in mind when building a mirror disk type cluster on Linux in a cloud environment.

When building a mirror disk type cluster on Linux, you must specify a device file name.
However, it is important to note that depending on the cloud environment, the device file name may change during production.

At the time of writing this article, we have confirmed that the device file name has been changed in the following cloud environments.

    • ・ Amazon Web Services
    • ・ Microsoft Azure

    • * In the Amazon Web Services (hereinafter called "AWS") environment, we have confirmed that the device file name has been changed when using the Nitro System based instance type.
    • * In the Oracle Cloud Infrastructure environment, device file names can be fixed, so changes to device file names will not occur.
    • * In the Microsoft Azure environment, it can now be available to use persistent naming for device file name. (This is based on information as of August 2021.) For more information, refer to the following:
popupTroubleshoot Linux VM device name changes

In this article, we will introduce the points to note and what to do when building a mirror disk type cluster using the AWS environment as an example.
Please note that the same procedure applies to other cloud environments.

Contents

1. Points to Note When Building Mirror Disk Type Clusters

When building a mirror disk type cluster on Linux, specify the device file names of the each partition for the data partition device name and the cluster partition device name in the mirror disk resource.
(e.g. /dev/sdb1, /dev/sdb2)

mirror-disk-resource-properties-1zoomLarger View

However, in an AWS environment, the device file name may be changed due to changing instance type, restarting instance, attaching additional EBS, etc.
If the device file name is changed during the operation of a mirror disk type cluster, there is a risk that mirroring will not be performed correctly.

1.1 Device File Name Differences by Instance Type

Instance types for EC2 instances in AWS include Nitro System based instance types and non-Nitro System based instance types.
Be careful when changing instance types during production, because different instance types have different device file names.

The differences in device file names are as follows:

  • ・Non-Nitro System based instance types
    (e.g. Instance type: t2 instance, OS: Red Hat Enterprise Linux 7.6)

# lsblk
NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda                        202:0     0  10G  0 disk
├─xvda1                  202:1     0   1M  0 part
└─xvda2                  202:2     0  10G  0 part /
xvdb                        202:16   0  11G  0 disk

  • ・Nitro System based instance types
    (e.g. Instance type: t3 instance, OS: Red Hat Enterprise Linux 7.6)

# lsblk
NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1                 259:2    0  10G  0 disk
├─nvme0n1p1         259:3    0   1M  0 part
└─nvme0n1p2         259:4    0  10G  0 part /
nvme1n1                 259:0    0  11G  0 disk

1.2 Replacing Device File Names by Attaching Additional EBS

Here is a case study of a Nitro System based instance on which the device file name were replaced when you attaching additional EBS.
In addition, there are cases where the device file name was replaced when the OS restarted.

・Before EBS addition

# lsblk
NAME              MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1         259:1    0  10G  0 disk
├─nvme0n1p1 259:4    0   1M  0 part
└─nvme0n1p2 259:5    0  10G  0 part /
nvme1n1         259:0    0  11G  0 disk  ★Existing device name
├─nvme1n1p1 259:2    0   1G  0 part
└─nvme1n1p2 259:3    0  10G  0 part
nvme2n1         259:6    0   5G  0 disk  ★Existing device name


・After EBS addition

# lsblk
NAME              MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1         259:4    0  10G  0 disk
├─nvme0n1p1 259:5    0   1M  0 part
└─nvme0n1p2 259:6    0  10G  0 part /
nvme1n1         259:0    0   8G  0 disk   ★Added disk
nvme2n1         259:1    0  11G  0 disk  ★Changing Device name
├─nvme2n1p1 259:2    0   1G  0 part
└─nvme2n1p2 259:3    0  10G  0 part
nvme3n1         259:7    0   5G  0 disk  ★Changing Device name

2. Building Mirror Disk Type Clusters Using Logical Volumes

As mentioned, the device file name may be changed when EBS is added in the AWS environment.
As a workaround, we will introduce the use of logical volumes.

By creating a logical volume and setting the logical volume name to the mirror disk resource, the logical volume name can be used without any change even if the device file name of the partition is changed.

The following is an example of creating a logical volume.
(e.g. instance type: t3 instance, OS: Red Hat Enterprise Linux 7.6)
The device file name varies depending on the environment, so please read it as appropriate.

  • 1.Create a partition on your device.
    (e.g. device file name: /dev/nvme1n1, partition system ID: Linux LVM)

# fdisk /dev/nvme1n1
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x6d528fd3.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-23068671, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-23068671, default 23068671):
Using default value 23068671
Partition 1 of type Linux and of size 11 GiB is set

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'

Command (m for help): p

Disk /dev/nvme1n1: 11.8 GB, 11811160064 bytes, 23068672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x6d528fd3

        Device Boot      Start         End      Blocks   Id  System
/dev/nvme1n1p1            2048    23068671    11533312   8e  Linux LVM

  • 2.Create a physical volume on the partition created in 1.

# pvcreate /dev/nvme1n1p1

  • 3.Create a volume group.
    (e.g. volume group name: lvg-test)

# vgcreate lvg-test /dev/nvme1n1p1

  • 4.Create a logical volume for the cluster partition.
    (e.g. logical volume name: lvm-test1, size: 1GB)

# lvcreate --name lvm-test1 --size 1GB lvg-test

  • 5.Create a logical volume for the data partition.
    (e.g. logical volume name: lvm-test2, size: all remaining sizes)

# lvcreate --name lvm-test2 -l 100%FREE lvg-test

Set the logical volumes you created to a mirror disk resource.

mirror-disk-resource-properties-2zoomLarger View

Conclusion

This time, we introduced the points to note when building a mirror disk type cluster on Linux in a cloud environment.
If you are building a mirror disk type cluster on Linux in a cloud environment, please read it in advance.
If you consider introducing the configuration described in this article, you can perform a validation with the popuptrial module of EXPRESSCLUSTER. Please do not hesitate to contact us if you have any questions.

Thank you for reading to the end.