KR20190130903A - Method and system for swapping booting disk - Google Patents

Abstract

Disclosed are a method and system for changing a boot disk. According to one embodiment of the present invention, the system comprises: a disk copy module copying data stored in a first operating system (OS) disk to a second OS disk; and a setting module adding OS kernel information of the second OS disk to a boot loader configuration file included in the first OS disk and changing a boot order in the configuration file to designate an OS kernel of the second OS disk as a priority.

Description

How to change the boot disk and system {METHOD AND SYSTEM FOR SWAPPING BOOTING DISK}

Embodiments of the invention relate to techniques for changing the boot disk of a Linux computing device.

Recently, in the server market, Linux-based x86 server has been actively used to replace the conventional UNIX server. In addition, if you have a lot of I / O and you need to deal with high-critical tasks, you often use bare metal Linux servers instead of virtualized environments.

Unlike a virtual machine, a bare metal server cannot back up an operating system (OS) in the form of a snapshot. Accordingly, in the related art, the OS of the bare metal server is backed up in a separate media or network storage space, and when the bare metal server fails, the backup data is overwritten on the bare metal server. However, in this case, it takes a long time to recover, and there is a problem that the bare metal server cannot be started while the recovery is in progress.

Republic of Korea Patent Publication No. 10-2003-0062793 (2003. 07. 28)

The disclosed embodiments are provided to provide a technical means for effectively performing a failover and patching operation when a bare metal Linux server fails or a patching operation of an OS or software is required.

According to an exemplary embodiment, a method performed in a computing device having one or more processors and a memory storing one or more programs executed by the one or more processors, the method comprising: a first operating system (OS); Copying the data stored in the disk to the second OS disk; And adding OS kernel information of the second OS disk to a boot loader configuration file included in the first OS disk and changing a boot order in the boot loader configuration file to prioritize the OS kernel of the second OS disk. There is provided a method of changing a boot disk, comprising the step of setting.

The method may further include: converting an OS disk currently operating in the computing device to the first OS disk, and one of the disks other than the first OS disk among the disks connected to the computing device before performing the copying step. The method may further include designating an OS disk.

The specifying may further include receiving selection information about the second OS disk from a user when the number of the disks other than the first OS disk among the disks connected to the computing device is two or more.

The setting may further include setting a boot order of a boot loader configuration file included in the second OS disk to be the same as the first OS disk.

The boot loader configuration file is a grub.cfg file stored in a / boot directory in the first OS disk.

After performing the setting, the method may further include setting a file system table (fstab) of the second OS disk to be the same as the first OS disk.

The method may further include executing a boot loader in a master boot record of the first OS disk according to rebooting of the computing device after performing the setting step; And driving, by the boot loader, an operating system of the second OS disk based on the changed boot order of the boot loader configuration file.

The method may further include resetting an OS kernel of the first OS disk to a priority by changing a boot order in the boot loader configuration file after performing the driving step.

According to another exemplary embodiment, a disk copy module for copying data stored in a first operating system (OS) disk to a second OS disk; And adding OS kernel information of the second OS disk to a boot loader configuration file included in the first OS disk and changing a boot order in the boot loader configuration file to prioritize the OS kernel of the second OS disk. A bootable disk change system is provided that includes a configuration module for specifying.

The setting module may set an OS disk currently operating in the computing device as the first OS disk and one of disks other than the first OS disk among the disks connected to the computing device as the second OS disk.

The setting module may receive selection information regarding the second OS disk from a user when the number of the disks other than the first OS disk among the disks connected to the computing device is two or more.

The configuration module may set a boot order of a boot loader configuration file included in the second OS disk in the same manner as the first OS disk.

The boot loader configuration file may be a grub.cfg file stored in the / boot directory of the first OS disk.

The setting module may set a file system table (fstab) of the second OS disk in the same manner as the first OS disk.

When the computing device is rebooted, the computing device executes a boot loader in a master boot record of the first OS disk, the boot loader based on the changed boot order of the boot loader configuration file. Can run the operating system.

After operating the operating system of the second OS disk, the configuration module may reset the OS kernel of the first OS disk to priority by changing the boot order in the boot loader configuration file again.

According to the embodiments of the present disclosure, when a bare metal Linux server fails, recovery may be performed by changing a boot order of the boot loader to swap a boot disk with a backup OS disk. You can recover from failures quickly and simply.

In addition, according to the disclosed embodiments, the boot order of the bare metal Linux server may be changed to boot to a backup OS disk, and then an OS update or software patch of the original OS disk may be performed. As a result, OS or software changes can be easily performed without stopping the bare metal Linux server.

1 is an exemplary diagram for explaining a booting process of a Linux computing system
2 is a block diagram illustrating a configuration of a boot disk change system according to an embodiment of the present invention.
3 to 5 are exemplary diagrams for explaining a process of changing a boot disk according to one siling of the present invention
6 is a flowchart illustrating a boot disk change method according to an embodiment of the present invention.
7 to 10 are exemplary diagrams for explaining the process of performing the operating system version upgrade and software patch for a plurality of systems using a boot disk change system according to an embodiment of the present invention
11 through 16 are diagrams for explaining an example of a process of performing an operating system version upgrade and a software patch in a multi-node cluster environment by using a boot disk change system according to an embodiment of the present invention.

Hereinafter, specific embodiments of the present invention will be described with reference to the drawings. The following detailed description is provided to assist in a comprehensive understanding of the methods, devices, and / or systems described herein. However, this is only an example and the present invention is not limited thereto.

In describing the embodiments of the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. In addition, terms to be described below are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of a user or an operator. Therefore, the definition should be made based on the contents throughout the specification. The terminology used in the description is for the purpose of describing embodiments of the invention only and should not be limiting. Unless expressly used otherwise, the singular forms “a,” “an,” and “the” include plural forms of meaning. In this description, expressions such as "comprises" or "equipment" are intended to indicate certain features, numbers, steps, actions, elements, portions or combinations thereof, and one or more than those described. It should not be construed to exclude the presence or possibility of other features, numbers, steps, actions, elements, portions or combinations thereof.

1 is an exemplary diagram for explaining a booting process of a Linux computing system. When the Linux computing system boots, the BIOS of the computing system first performs basic hardware checks and then recognizes devices such as I / O devices and disks connected to the computing system. In this process, BIOS recognizes the boot order of a plurality of connected disks and reads and executes boot loader stage 1 in the master boot record (MBR) of the first bootable OS disk (sda) ( Stage 1). In this case, the master boot record means 0 to 512 bytes at the beginning of the OS disk. In addition, a boot loader is a program that is executed before the operating system starts up, and which has the purpose of finishing all related tasks necessary for the kernel to start properly and finally starting the operating system. Stage 1 and Stage 2 may be included, and in some cases, Stage 1.5 may be further included. For example, for the GRUB (Grand Unified Bootloader) bootloader commonly used on Linux computer systems, stage 1 is stored in the master boot record in the form of a boot.img file, and the stage 2 grub.cfg file is located on the disk. It is stored in the boot directory and can separately include stage 1.5, core img, in the promised location on disk.

The boot.img reads the core.img file, which is the bootloader stage 1.5 stored in a predetermined location on the disk (stage 1.5), and core.img reads the grub.cfg file located in the / boot directory on the disk again ( stage 2). grub.cfg is a file that stores the configuration needed to boot a Linux computing system. The reason why boot.img does not read the grub.cfg file directly is because the file system cannot be read directly due to the capacity limitation of boot.img. This causes boot.img to read the grub.cfg file using core.img, which contains the modules needed to load grub.cfg. Finally, the boot loader completes the boot by loading the kernel into memory and giving control to the kernel.

2 is a block diagram illustrating a configuration of a bootable disk change system 200 according to an embodiment of the present invention. The bootable disk change system 200 according to an embodiment of the present invention backs up data stored on the first OS disk of the bare metal Linux computing system to the second OS disk, and then, when a failure of the first OS disk occurs, the second OS disk It is a system for quickly and effectively recovering from a failure by booting the system. In the disclosed embodiments, the bare metal Linux computing system refers to a Linux-based computing system built on physical hardware rather than a virtualized environment. However, the disclosed embodiments are not necessarily limited to the bare metal Linux computing system, and may be implemented in the computing system operating in a virtualized environment if necessary.

As shown, the bootable disk change system 200 according to an embodiment of the present invention includes a disk copy module 202 and a configuration module 204.

The disk copy module 202 copies (backs up) data of a first operating system (OS) disk to a second OS disk. As illustrated in FIG. 3, the disk copy module 202 may back up each partition of the first OS disk / dev / sda to the second OS disk / dev / sdb. In the disclosed embodiments, an OS disk refers to a disk on which an operating system for driving a computing system is installed.

The configuration module 204 adds OS kernel information of the second OS disk to a boot loader configuration file included in the first OS disk, changes the boot order in the configuration file, and prioritizes the OS kernel of the second OS disk. To give. In one embodiment, the boot loader configuration file may be a grub.cfg file stored in the / boot directory of the first OS disk.

As shown in FIG. 3, the boot loader configuration file (eg, grub.cfg) of the first OS disk includes only OS kernel information of the root directory (/ dev / sda2) of the first OS disk. The same applies to the second OS disk in which data of the first OS disk is backed up. That is, the boot loader configuration file of the second OS disk also includes only OS kernel information of the root directory (/ dev / sda2) of the first OS disk.

The setting module 204 first checks the currently operating OS disk and the change target OS disk. For example, if the first OS disk and the second OS disk are connected to the computing system and are currently booted with the first OS disk, the configuration module 204 may be configured as the OS disk currently operating. 2 OS disks can be recognized as OS disks to be changed. The disk copy module 202 may back up data of the currently operating OS disk to the change target OS disk based on the information of the first OS disk and the second OS disk recognized by the setting module. If there are three or more OS disks connected to the computing system (that is, if the number of disks other than the first OS disk is two or more), the setting module 204 may receive setting information about the change target OS disk from an administrator or the like. Can be. In the following description, it is assumed that the first OS disk is an operating OS disk and the second OS disk is a change target OS disk.

Next, the configuration module 204 adds OS kernel information of the root directory (/ dev / sdb2) of the second OS disk to the boot loader configuration file of the first OS disk. In this case, the boot loader configuration file may be a grub.cfg file stored in the / boot file system of the first OS disk. Through this process, as shown in FIG. 4, the boot loader configuration file of the first OS disk includes two OS kernel information as follows.

OS kernel on / dev / sda2

2. OS kernel on / dev / sdb2 (added)

Next, the configuration module 204 changes the boot order (priority) of the boot loader configuration file so that the kernel information of the second OS disk comes before the kernel information of the first OS disk. Then, as shown in FIG. 5, the following information is stored in the boot loader configuration file of the first OS disk.

1.OS kernel in / dev / sdb2 (order change)

2. OS kernel on / dev / sda2

In the case of the GRUB boot loader, the aforementioned kernel information may be stored in a monumentary item of the grub.cfg file. For example, kernel information (monumentary A) of the first OS disk and kernel information (monumentary B) of the second OS disk may have the following form.

monumentary A (sda) {

(Various information areas for kernel loading)

}

monumentary B (sdb) {

(Various information areas for kernel loading)

}

The configuration module may change the boot priority of each OS disk by changing the order of monumentary A and monumentary B.

Meanwhile, the configuration module 204 may set the boot order of the boot loader configuration file included in the second OS disk in the same manner as the first OS disk. In this way, even if booting is performed through the master boot record of the second OS disk instead of the first OS disk, the preset boot order can be maintained. Specifically, the configuration module 204 temporarily mounts the / boot file system of the second OS disk, and overwrites grub.cfg of the temporarily mounted / boot file system with grub.cfg of the first OS disk. can do. Afterwards, the configuration module 204 reads the newly updated grub.cfg again to check whether the changed part is properly reflected and unmounts the temporarily mounted / boot file system to change the boot order of the boot loader configuration file included in the second OS disk. It may be set in the same manner as the first OS disk.

Next, the configuration module 204 recalls the file system table (fstab) of the second OS disk so that the / dev / sda2 directory can be properly mounted as a root directory when booting using the OS kernel of the second OS disk. It is set the same as a 1st OS disk. The configuration module 204 backs up the file system table of the first OS disk to a separate storage space, and overwrites the file system table of the second OS disk by using the file system table of the second OS disk. It may be set in the same manner as the first OS disk.

Then, after rebooting the bare metal Linux computing system, the bare metal Linux system is started using the OS kernel of the second OS disk, not the first OS disk. In this case, the reboot process of the Linux computing system will be described in more detail as follows.

First, the BIOS of the bare metal Linux computing system reads and executes boot loader stage 1 in the Master Boot Record (MBR) of the first OS disk. Even if the operating system or software of the first OS disk fails, this step may be normally performed as long as the master boot record of the first OS disk is not damaged.

Next, the boot loader stage 1 reads core.img (boot loader stage 1.5) stored in the promised location of the first OS disk, and core.img is again a boot loader configuration file located in the / boot directory on the first OS disk. Read (grub.cfg) (bootloader stage 2). However, the boot order of the boot loader configuration file is changed by the configuration module 204 to preferentially load the OS kernel of the second OS disk. The boot loader is not the / dev / sda2 directory, but the / dev / sdb2 directory. This completes the boot by loading the OS kernel into memory. That is, in the embodiments of the present invention, when a failure of the first OS disk occurs, the bare metal Linux computing system performs booting using the boot loader of the first OS disk and the OS kernel of the second OS disk. As such, according to the embodiments of the present invention, the system can be quickly restarted without a process of overwriting the backed up data on the first OS disk when a bare metal Linux system fails.

Thereafter, the administrator may complete the failure recovery by restoring the boot order so that the system may be started again using the OS kernel of the first OS disk after performing an action on the failure factor of the first OS disk. In more detail, the administrator may reset the OS kernel of the second OS disk to priority by changing the boot order in the boot loader configuration file through the configuration module 240.

In one embodiment, disk copy module 202 and configuration module 204 may be implemented on a computing device that includes one or more processors and a computer readable recording medium associated with the processors. The computer readable recording medium may be inside or outside the processor and may be connected with the processor by various well-known means. A processor within the computing device may cause each computing device to operate according to the example embodiments described herein. For example, a processor may execute instructions stored on a computer readable recording medium, and the instructions stored on the computer readable recording medium cause the computing device to operate in accordance with the exemplary embodiment described herein when executed by the processor. It can be configured to perform these.

6 is a flowchart illustrating a boot disk change method 600 according to an embodiment of the present invention. The method according to the flowchart shown is performed by a computing device having one or more processors and a memory storing one or more programs executed by the one or more processors, for example the boot disk change system 200 described above. Can be. In the illustrated flow chart, the method is divided into a plurality of steps, but at least some of the steps may be performed in a reverse order, in combination with other steps, omitted, divided into substeps, or not shown. One or more steps may be added and performed.

In step 602, the boot disk change system 200 copies the data of the first OS disk to the second OS disk. As described above, the configuration module 204 of the boot disk change system 200 may use the OS disk currently operating in the computing system as the first OS disk, and the disk other than the first OS disk among the disks connected to the computing device. One can be set as the second OS disk. In addition, if necessary, the setting module 204 may receive selection information about the second OS disk from the user when the number of the disks other than the first OS disk among the disks connected to the computing system is two or more.

In operation 604, the boot disk change system 200 adds OS kernel information of the second OS disk to a boot loader configuration file included in the first OS disk, and changes a boot order in the configuration file to a second OS. Prioritizes the OS kernel on disk. In this process, the boot disk change system 200 may set the boot order of the boot loader configuration file included in the second OS disk in the same manner as the first OS disk.

In addition, if necessary, the boot disk changing system 200 may set a file system table (fstab) of the second OS disk to be the same as the first OS disk.

Then, when the computing system is rebooted, the computing system executes a boot loader in the master boot record of the first OS disk, and the boot loader runs the operating system of the second OS disk based on the changed boot order in step 604. .

On the other hand, after operating the operating system of the second OS disk, the administrator may reset the OS kernel of the second OS disk to priority by changing the boot order in the boot loader configuration file again.

On the other hand, the boot disk change system 200 according to an embodiment of the present invention can be utilized not only for the failure recovery of the bare metal Linux system, but also for operating system version upgrades and software patches for a plurality of systems.

Depending on the nature of the operating system or software, updating or patching can take a long time, or not just install a new version of the operating system / software, but also require additional data copies or configuration. However, it is often difficult to secure the time required for such a task when it is difficult to interrupt service for a long time due to the nature of IT work. In this case, by using the boot disk change system 200 described above, it is possible to effectively perform a version upgrade and patch operation of a large number of servers, which are illustrated in FIGS. 7 to 10.

First, as shown in FIG. 7, assume that there are N bare metal Linux servers from server 1 to server N, and each server is equipped with OS version A and software version 1.0. The administrator copies the operating system and software stored in the first OS disk (Disk 1) of each server to the second OS disk (Disk 2) by using the boot disk change system 200.

Next, the administrator changes the OS version of the second OS disk of each server from A to A 'as shown in FIG. 8, and also updates the software version from 1.0 to 2.0. At this time, each server is normally running while being booted through OS disk 1.

Next, the administrator changes the boot priority of each server from OS disk 1 to OS disk 2 using the boot disk change system 200. After rebooting all the servers at the same time, as shown in Figure 9, each server is driven through the updated operating system and software.

Through this process, the administrator can smoothly update and patch each server without bringing down each server. In this case, it is possible to complete the update and patch of each server very efficiently compared to the case of sequentially shutting down and updating each server, and if a problem occurs in the new version as shown in FIG. Simply reverting the boot priority from OS disk 2 to OS disk 1 allows you to quickly return to the previous version.

On the other hand, the boot disk change system 200 according to an embodiment of the present invention can be effectively used even when compatibility between versions when the OS and software version upgrade in a multi-node cluster environment.

For example, assume that the compatibility between the versions of the virtual multi-node software and the operating system has a relationship as shown in Table 1 below.

OS A OS B S / W 1.0 O X S / W 2.0 X O

In other words, S / W version 1.0 runs only on OS A, while S / W version 2.0, on the other hand, cannot run on OS A, and can only run on OS B. In this case, to update S / W 1.0 to 2.0 in each node, the following process must be performed in each server.

Remove S / W 1.0-> Reboot-> Upgrade OS from A to B-> Reboot-> Install S / W 2.0-> Reboot

In this case, the updated node cannot be joined because the software version is different from the existing cluster. Therefore, the entire cluster must be stopped while each node is updated.

However, even in such a case, when using the above-described boot disk change system 200, it is possible to effectively perform the upgrade and patch operation for each node without stopping the operation of the cluster, which is shown in Figures 11 to 16.

First, as shown in FIG. 11, suppose that there are three database servers from DB # 1 to DB # 3, and each server is equipped with OS version A and software version 1.0. Also assume that the software running on each server is connected to one cluster. The administrator copies the operating system and software stored in the first OS disk (Disk 1) of each server to the second OS disk (Disk 2) by using the boot disk change system 200.

Next, as shown in FIG. 12, the administrator first changes DB # 1 to an offline state and excludes it from the cluster. In the drawing, the outline of DB # 1 is indicated by a dotted line instead of a solid line (online state) to indicate that the DB # 1 is offline.

Thereafter, the administrator changes the OS version of the first OS disk from A to B, and also updates the software version from 1.0 to 2.0, as shown in FIG.

In FIG. 14, the administrator changes the boot priority of DB # 1 from OS disk 1 to OS disk 2 using the boot disk change system 200 and reboots DB # 1. OS disk 2 of DB # 1 is still running OS version A and software version 1.0, so rebooted DB # can join the existing cluster without problems.

In this way, the administrator can update the operating system and software stored in OS disk 1 of DB # 2 and DB # 3 as shown in FIG. 15.

Finally, the administrator restores each server's boot priority to OS Disk 1 and reboots each server. Each database is then run with the OS and software updated at the same time, allowing clusters to be configured without compatibility issues between versions. In addition, the administrator can update multiple servers at the same time instead of updating each server sequentially, thereby reducing the time required for updating and minimizing the disconnection of services that may occur during the update process.

Meanwhile, an embodiment of the present invention may include a program for performing the methods described herein on a computer, and a computer readable recording medium including the program. The computer-readable recording medium may include program instructions, local data files, local data structures, etc. alone or in combination. The media may be those specially designed and constructed for the purposes of the present invention, or those conventionally available in the field of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical recording media such as CD-ROMs, DVDs, and specially configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Hardware devices are included. Examples of such programs may include high-level language code that can be executed by a computer using an interpreter as well as machine code such as produced by a compiler.

Although exemplary embodiments of the present invention have been described in detail above, those skilled in the art will appreciate that various modifications can be made to the above-described embodiments without departing from the scope of the present invention. . Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims below and equivalents thereof.

200: disk changer
202: disk copy module
204: configuration module

Claims (16)

One or more processors, and
A method performed in a computing device having a memory that stores one or more programs executed by the one or more processors, the method comprising:
Copying data stored on a first operating system (OS) disk to a second OS disk; And
OS kernel information of the second OS disk is added to a boot loader configuration file included in the first OS disk, and the OS kernel of the second OS disk is prioritized by changing a boot order in the boot loader configuration file. And changing the boot disk.
The method according to claim 1,
Before performing the copying step,
Designating an OS disk currently operating in the computing device as the first OS disk and designating one of the disks other than the first OS disk among the disks connected with the computing device as the second OS disk. How to change disk.
The method according to claim 2,
The specifying step,
If the number of disks other than the first OS disk of the disk connected to the computing device is more than one, further comprising the step of receiving selection information for the second OS disk from the user, boot disk change method.
The method according to claim 1,
The setting step,
And setting a boot order of a boot loader configuration file included in the second OS disk to be the same as the first OS disk.
The method according to claim 1,
The boot loader configuration file is a grub.cfg file stored in a / boot directory in the first OS disk.
The method according to claim 1,
After performing the setting step,
And setting a file system table (fstab) of the second OS disk to be the same as the first OS disk.
The method according to claim 1,
After performing the setting step,
Executing a boot loader in a master boot record of the first OS disk according to the rebooting of the computing device; And
Based on the changed boot order of the boot loader configuration file, the boot loader further comprising operating the operating system of the second OS disk.
The method according to claim 7,
After performing the driving step,
Resetting the boot kernel in the boot loader configuration file to reset the OS kernel of the first OS disk to priority.
A system for changing a boot disk of a computing device,
A disk copy module for copying data stored in a first operating system (OS) disk to a second OS disk; And
OS kernel information of the second OS disk is added to a boot loader configuration file included in the first OS disk, and the OS kernel of the second OS disk is prioritized by changing a boot order in the boot loader configuration file. A boot disk change system comprising a configuration module.
The method according to claim 9,
The setting module is configured to set an OS disk currently operating in the computing device as the first OS disk and one of disks other than the first OS disk among disks connected with the computing device as the second OS disk. Disk change system.
The method according to claim 11,
The setting module, when the number of disks other than the first OS disk among the disks connected to the computing device is two or more, receives the selection information for the second OS disk from the user, boot disk change system.
The method according to claim 9,
The setting module,
And booting the boot loader configuration file included in the second OS disk in the same manner as the first OS disk.
The method according to claim 9,
The boot loader configuration file is a grub.cfg file stored in a / boot directory in the first OS disk.
The method according to claim 9,
The setting module,
And a file system table (fstab) of the second OS disk is set equal to the first OS disk.
The method according to claim 9,
When the computing device is rebooted, the computing device executes a boot loader in the master boot record of the first OS disk,
And the boot loader drives an operating system of the second OS disk based on the changed boot order of the boot loader configuration file.
The method according to claim 7,
After operating the operating system of the second OS disk,
And the configuration module resets the OS kernel of the first OS disk to a priority by rechanging the boot order in the boot loader configuration file.

Images