RU2788309C1 - Method for centralized response to a network failure or server failure in a high availability cluster and virtual machine recovery in a high availability cluster and a system implementing this method - Google Patents
Method for centralized response to a network failure or server failure in a high availability cluster and virtual machine recovery in a high availability cluster and a system implementing this method Download PDFInfo
- Publication number
- RU2788309C1 RU2788309C1 RU2022112461A RU2022112461A RU2788309C1 RU 2788309 C1 RU2788309 C1 RU 2788309C1 RU 2022112461 A RU2022112461 A RU 2022112461A RU 2022112461 A RU2022112461 A RU 2022112461A RU 2788309 C1 RU2788309 C1 RU 2788309C1
- Authority
- RU
- Russia
- Prior art keywords
- computer
- cluster
- daemon
- restore
- recovery
- Prior art date
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 56
- 230000004044 response Effects 0.000 title claims abstract description 6
- 108060004353 leuD Proteins 0.000 claims description 23
- 238000004891 communication Methods 0.000 claims description 6
- 230000011664 signaling Effects 0.000 claims description 2
- 230000000694 effects Effects 0.000 abstract description 3
- 238000005516 engineering process Methods 0.000 abstract description 3
- 239000000126 substance Substances 0.000 abstract 1
- 238000000034 method Methods 0.000 description 7
- 230000005012 migration Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 230000000875 corresponding Effects 0.000 description 1
- 230000000737 periodic Effects 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
Images
Abstract
Description
[0001] Настоящее изобретение относится к области вычислительной техники, а именно к системам для создания и администрирования виртуальной инфраструктуры на группе серверов в центрах обработки данных. [0001] The present invention relates to the field of computing, namely to systems for creating and administering a virtual infrastructure on a group of servers in data centers.
[0002] Применительно к данной заявке используемые термины имеют следующие значения: [0002] As used in this application, the terms used have the following meanings:
[0003] «Heartbeat» (перевод с англ. «сердцебиение») – периодический сигнал, генерируемый программным обеспечением для индикации корректной работы или для синхронизации других частей компьютерной системы;[0003] "Heartbeat" (translated from English. "Heartbeat") - a periodic signal generated by software to indicate correct operation or to synchronize other parts of a computer system;
[0004] «IPMI» (англ. Intelligent Platform Management Interface) – интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ, в том числе для выполнения операций автономного включения, выключения и перезагрузки ЭВМ;[0004] "IPMI" (English Intelligent Platform Management Interface) - an intelligent platform management interface designed for autonomous monitoring and control of functions built directly into the hardware and firmware of server platforms, including for performing autonomous power-on, shutdown and reboot operations COMPUTER;
[0005] «Агент» – программа, которая вступает в отношение посредничества с пользователем или другой программой;[0005] "Agent" is a program that enters into an intermediary relationship with a user or another program;
[0006] «База данных» – совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, независимая от прикладных программ; [0006] "Database" - a collection of data organized according to certain rules, providing general principles for describing, storing and manipulating data, independent of application programs;
[0007] «Виртуализация» – группа технологий, основанных на преобразовании формата или параметров программных или сетевых запросов к компьютерным ресурсам с целью обеспечения независимости процессов обработки информации от программной или аппаратной платформы информационной системы; [0007] "Virtualization" - a group of technologies based on the transformation of the format or parameters of software or network requests to computer resources in order to ensure the independence of information processing processes from the software or hardware platform of the information system;
[0008] «Виртуальная машина» (далее – ВМ) – виртуальная вычислительная система, которая состоит из виртуальных устройств обработки, хранения и передачи данных и которая дополнительно может содержать программное обеспечение и пользовательские данные;[0008] "Virtual Machine" (hereinafter - VM) - a virtual computing system that consists of virtual devices for processing, storing and transmitting data and which may additionally contain software and user data;
[0009] «Гипервизор» – программа, создающая среду функционирования других программ, в том числе других гипервизоров за счет имитации аппаратных средств вычислительной техники, управления данными средствами и гостевыми операционными системами (далее – ОС), функционирующими в данной среде.[0009] “Hypervisor” is a program that creates an environment for the operation of other programs, including other hypervisors, by simulating computer hardware, managing these tools and guest operating systems (hereinafter referred to as OS) operating in this environment.
[0010] «Гостевая операционная система» – операционная система, установленная в ВМ;[0010] "Guest operating system" means the operating system installed in the VM;
[0011] «Демон» – программа в системах класса UNIX, работающая в фоновом режиме без прямого общения с пользователем;[0011] "Daemon" is a program on UNIX-class systems that runs in the background without direct communication with the user;
[0012] «Кластер» – группа компьютеров, объединённых высокоскоростными каналами связи, представляющая с точки зрения пользователя единый аппаратный ресурс; [0012] "Cluster" - a group of computers united by high-speed communication channels, representing a single hardware resource from the user's point of view;
[0013] «Хост» - любое устройство, предоставляющее сервисы формата «клиент-сервер» в режиме сервера по каким-либо интерфейсам и уникально определённое на этих интерфейсах. В более широком смысле под хостом могут понимать любой компьютер, подключённый к локальной или глобальной сети;[0013] "Host" - any device that provides services in the client-server format in server mode on any interfaces and is uniquely identified on these interfaces. In a broader sense, a host can be understood as any computer connected to a local or global network;
УРОВЕНЬ ТЕХНИКИBACKGROUND OF THE INVENTION
[0014] Как было указано выше заявляемое изобретение относится к системам для создания и администрирования виртуальной инфраструктуры на группе серверов в центрах обработки данных. На серверах выполняются виртуальные машины (ВМ), в которых запущены гостевые операционные системы (ОС) с различными приложениями. Серверы могут объединяться в кластеры для осуществления различных функций, например, динамическая миграция ВМ (англ. «live migration»), балансировка нагрузки для равномерного использования ресурсов серверов («DRS кластер») и автоматическое восстановление виртуальных машин при отказах оборудования, или сети (кластер высокой доступности) (англ. High Availability Cluster).[0014] As mentioned above, the claimed invention relates to systems for creating and administering a virtual infrastructure on a group of servers in data centers. The servers run virtual machines (VMs) that run guest operating systems (OS) with various applications. Servers can be combined into clusters to perform various functions, for example, live migration of VMs (“live migration”), load balancing for even use of server resources (“DRS cluster”) and automatic recovery of virtual machines in case of hardware or network failures (cluster high availability) (English High Availability Cluster).
[0015] Высокая доступность (англ. High Availability, cокращен. HА) предоставляет собой функции для обнаружения отказов гостевых операционных систем виртуальных машин (ВМ) или оборудования, на которых они запущены. При обнаружении отказов HA автоматически восстанавливает виртуальные машины на других хостах в кластере без ручного вмешательства. [0015] High Availability (High Availability, abbreviated HA) provides functions for detecting failures in guest operating systems of virtual machines (VMs) or the hardware on which they are running. When failures are detected, HA automatically restores virtual machines to other hosts in the cluster without manual intervention.
[0016] На каждом физическом сервере должны выполняться одна или несколько рабочих нагрузок, таких как виртуальные машины, экземпляр серверного приложения (веб-сервер или сервер приложений, и/или экземпляр приложения для обработки данных, например, клиент распределенных вычислений). [0016] Each physical server must run one or more workloads, such as virtual machines, a server application instance (web server or application server, and/or a data processing application instance, such as a grid client).
[0017] Экземпляры программного приложения могут быть связаны, например, храниться в одном или нескольких устройствах хранения данных, так что экземпляр программного приложения может быть перенесен или перезапущен на любом хосте с доступом к хранилищу данных, который соответствует экземпляру программного приложения.[0017] Instances of the software application may be associated, for example, stored on one or more storage devices, such that the instance of the software application may be migrated or restarted on any host with access to the data store that corresponds to the software application instance.
[0018] Существующая технология кластеризации высокой доступности имеет ограничения в отношении доступности виртуальных машин. Например, когда отказ в сети управления происходит для подмножества хостов кластера, для этих изолированных хостов может быть потеряна возможность обмениваться данными по сети управления с другими хостами в кластере. [0018] Existing high availability clustering technology has limitations regarding the availability of virtual machines. For example, when a control network failure occurs for a subset of cluster hosts, those isolated hosts may lose the ability to communicate over the control network with other hosts in the cluster.
[0019] Кроме того, один из хостов в изолированном разделе может потерять подключение к сети виртуальных машин, что приведет к тому, что этот конкретный хост станет полностью изолированным от всех других хостов. Это приводит к потере доступа к сети для всех виртуальных машин, работающих на этом конкретном хосте, что дополнительно приводит к потере доступа к этой виртуальной машине пользователей или клиентов до тех пор, пока, по крайней мере, сетевое подключение виртуальной машины не будет вручную исправлено для соответствующего хоста.[0019] In addition, one of the hosts in the isolated partition may lose connectivity to the virtual machine network, causing that particular host to become completely isolated from all other hosts. This results in the loss of network access for all VMs running on that particular host, further resulting in the loss of access to that VM by users or clients until at least the VM's network connectivity is manually fixed to corresponding host.
[0020] Из существующего уровня техники наиболее близким по технической сущности и достигаемому техническому результату к заявляемому изобретению является способ обработки сетевого разделения в кластере высокого давления (НА-кластер) и система для его реализации [патент US10521315B1, дата публикации 31.12.2019].[0020] Of the existing prior art, the closest in technical essence and achieved technical result to the claimed invention is a method for processing network separation in a high-pressure cluster (HA-cluster) and a system for its implementation [patent US10521315B1,
[0021] В патенте US10521315B1 предложены методы управления подключением виртуальной машины для хостов в изолированном НА-кластере.[0021] US10521315B1 proposes methods for managing virtual machine connectivity for hosts in a standalone HA cluster.
[0022] Способ включает в себя определение того, что первый хост, на котором выполняется виртуальная машина, в НА-кластере находится в изолированном разделе. При обнаружении отказа сети виртуальной машины для первого хоста выполняется обработка сетевого отказа, который включает в себя передачу выполнения виртуальной машины на первом узле на узел, имеющий сетевое подключение.[0022] The method includes determining that the first host running the virtual machine in the HA cluster is in the isolated partition. When a virtual machine network failure is detected for the first host, network failure processing is performed, which includes transferring the execution of the virtual machine on the first host to a host that has network connectivity.
[0023] В НА - кластере может быть назначен главный или основной хост, и на него могут быть возложены обязанности по мониторингу состояния других хостов (подчиненных хостов или вторичных хостов) в кластере и организации автоматического восстановления ВМ. [0023] In a HA cluster, a master or primary host may be designated, and may be responsible for monitoring the status of other hosts (slave hosts or secondary hosts) in the cluster and organizing automatic recovery of the VM.
[0024] В предложенных вариантах осуществления функции мониторинга и восстановления ВМ осуществляют агенты HA. Агент HA также включает инструкции для работы в качестве главного хоста и для работы в качестве вторичного хоста. [0024] In the proposed embodiments, the functions of monitoring and restoring the VM are performed by HA agents. The HA agent also includes instructions for running as a master host and for running as a secondary host.
[0025] Описанный в патенте US10521315B1 способ обработки сетевого разделения в кластере высокого давления может выполняться любым из хостов, при этом каждый хост может выбирать главный хост, действовать как главный хост и действовать как вторичный хост, в зависимости от обстоятельств.[0025] The method described in US10521315B1 for processing network partitioning in a high pressure cluster can be performed by any of the hosts, with each host choosing a master host, acting as a master host, and acting as a secondary host, as the case may be.
[0026] В системе обработки сетевого разделения в НА-кластере по патенту US10521315B1 требуется установка на все физические серверы кластера агента HA, а также Fault Domain Manager (FDM), который фактически является частью Virtualization Manager. Агент HA, находясь в роли вспомогательного хоста, выполняет, в частности, функции выбора главного хоста, обмена данными с другими серверами через общую систему хранения данных, отключения или перезагрузки виртуальных машин в случае отказа в гостевой операционной системе. В роли главного хоста агент HA также принимает решения о перезапуске виртуальных машин на доступных серверах.[0026] The network partitioning processing system in a HA cluster according to US10521315B1 requires the installation of an HA agent on all physical servers of the cluster, as well as a Fault Domain Manager (FDM), which is actually part of the Virtualization Manager. The HA agent, being in the role of an auxiliary host, performs, in particular, the functions of selecting the main host, communicating with other servers through a shared storage system, shutting down or rebooting virtual machines in the event of a failure in the guest operating system. In its role as master host, the HA agent also makes decisions about restarting virtual machines on available servers.
[0027] Необходимость установки на каждый физический сервер обязательного специализированного программного обеспечения НА - кластера фактически делает систему обработки сетевого разделения в НА - кластере по патенту US10521315B1 распределенным решением.[0027] The need to install the required dedicated HA cluster software on each physical server effectively makes the network separation processing system in the HA cluster of US10521315B1 a distributed solution.
[0028] Таким образом, можно выделить основной недостаток ближайшего аналога, который заключается в необходимости установки специализированного программного обеспечения кластера высокой доступности – агентов высокой доступности на каждый физический сервер. Это может быть невозможно, либо избыточно, при использовании серверов с установленным программным обеспечением в минимальной конфигурации, например, при использовании дистрибутива Linux c открытым гипервизором Kernel-based Virtual Machine (далее - КVM) и другими свободно распространяемыми утилитами для управления виртуальными машинами. [0028] Thus, we can highlight the main drawback of the closest analogue, which is the need to install specialized high availability cluster software - high availability agents on each physical server. This may be impossible or redundant when using servers with installed software in a minimal configuration, for example, when using a Linux distribution with an open hypervisor Kernel-based Virtual Machine (hereinafter referred to as KVM) and other freely distributed utilities for managing virtual machines.
СУЩНОСТЬ ИЗОБРЕТЕНИЯSUMMARY OF THE INVENTION
[0029] Техническая проблема, на решение которой направлено заявляемое изобретение, заключается в организации инфраструктуры автовосстановления виртуальных машин на кластере без необходимости установки на все физические серверы специализированного программного обеспечения – агентов высокой доступности. [0029] The technical problem to be solved by the claimed invention is to organize the infrastructure for auto-recovery of virtual machines on a cluster without the need to install specialized software on all physical servers - high availability agents.
[0030] Технический результат, достигаемый при реализации заявляемого изобретения, заключается в обеспечении выявления сетевого отказа или отказа сервера в кластере высокой доступности и восстановления доступности виртуальной машины (ВМ) на доступном сервере в кластере без необходимости установки агентов высокой доступности на каждый физический сервер. Установка агентов высокой доступности на каждый физический сервер может быть невозможна, либо избыточна, при использовании серверов с установленным программным обеспечением в минимальной конфигурации, например, при использовании дистрибутива Linux c открытым гипервизором KVM и другими свободно распространяемыми утилитами для управления виртуальными машинами.[0030] The technical result achieved by implementing the claimed invention is to ensure the detection of a network failure or server failure in a high availability cluster and restore the availability of a virtual machine (VM) on an available server in the cluster without the need to install high availability agents on each physical server. Installing high availability agents on each physical server may not be possible or redundant when using servers with installed software in a minimal configuration, for example, when using a Linux distribution with an open KVM hypervisor and other freely distributed utilities for managing virtual machines.
[0031] Заявляемый технический результат достигается за счет того, что способ централизованного реагирования на отказ сети или отказ сервера в кластере высокой доступности и восстановления виртуальной машины в кластере высокой доступности (2), содержащего набор виртуальных машин (ВМ), развернутых на группе ЭВМ (1, 2 … N) (1) c установленным гипервизором (7), снабженными платой-IPMI (6), ЭВМ-контроллер (4), ЭВМ-СХД (5), содержащая базу данных (9) гостевой операционной системы виртуальных машин (ВМ), коммутатор Ethernet (3), обеспечивающий связь между элементами системы посредство IPMI интерфейса, при этом ЭВМ-контроллер (4) содержит управляющий программный комплекс, включающий «демон (10) опроса ЭВМ из кластера», «демон (11) определения состояний ЭВМ кластера», «демон (12) ограждения узлов ЭВМ кластера», «демон (13) восстановления ВМ», а также базу данных (8), в которой хранятся конфигурационные данные гипервизора (7) выключенных виртуальных машин (ВМ) и служебные настройки, включающие по меньшей мере флаг включения функции высокой доступности, флаг включения автоматического выбора ЭВМ для восстановления, перечень и порядок ЭВМ, на которых необходимо выполнить восстановление ВМ, флаг включения выбора ЭВМ для восстановления ВМ с наименьшей загрузкой оперативной памяти, количество попыток восстановления ВМ, временной промежуток между попытками восстановления ВМ, характеризуется тем, что:[0031] The claimed technical result is achieved due to the fact that the method of centrally responding to a network failure or server failure in a high availability cluster and restoring a virtual machine in a high availability cluster (2) containing a set of virtual machines (VMs) deployed on a group of computers ( 1, 2 ... N) (1) with an installed hypervisor (7), equipped with an IPMI board (6), a computer controller (4), a storage computer (5) containing a database (9) of the guest operating system of virtual machines ( VM), an Ethernet switch (3) that provides communication between the elements of the system via the IPMI interface, while the computer controller (4) contains a control software package that includes a "daemon (10) for polling computers from the cluster", "daemon (11) for determining states Cluster computer", "daemon (12) fencing cluster computer nodes", "daemon (13) restoring VM", as well as a database (8), which stores the configuration data of the hypervisor (7) of turned off virtual machines (VM) and service settings , including n at least the flag for enabling the high availability function, the flag for enabling automatic selection of computers for recovery, the list and order of computers on which it is necessary to restore the VM, the flag for enabling the selection of computers for restoring the VM with the least RAM load, the number of attempts to restore the VM, the time interval between attempts to restore a VM is characterized by the fact that:
демон (10) опроса ЭВМ (1) из кластера подключается по соответствующим протоколам к ЭВМ (1), принимает сигнальные сообщения «heartbeat» от ЭВМ (1), ВМ и плат-IPMI (6), формирует информационные сообщения и помещает их в очередь для обработки демоном (11) определения состояний ЭВМ (1);the daemon (10) of polling the computer (1) from the cluster connects to the computer (1) via the appropriate protocols, receives signaling messages "heartbeat" from the computer (1), VM and IPMI boards (6), generates informational messages and places them in the queue for processing by the demon (11) of determining the states of the computer (1);
демон (11) определения состояний ЭВМ (1) в кластере (2) выявляет отсутствие информационный сообщений в очереди в течение определенного времени и меняет запись состояния ЭВМ (1) в базе данных (8) ЭВМ–контроллера (4) на «узел недоступен»; the daemon (11) for determining the states of the computer (1) in the cluster (2) detects the absence of informational messages in the queue for a certain time and changes the record of the state of the computer (1) in the database (8) of the computer controller (4) to "node unavailable" ;
демон (12) ограждения узлов ЭВМ (1) кластера (2) периодически считывает запись статуса ЭВМ (1) в базе данных (8) ЭВМ-контроллера (4) и при обнаружении состояния «узел недоступен» выполняет операцию принудительного выключения ЭВМ (1) через плату–IPMI (6) – «ограждение» и вносит в базу данных (8) ЭВМ-контроллера (4) запись о том, что данная ЭВМ (1) находится в состоянии «узел огражден»;the demon (12) of the fence of the computer nodes (1) of the cluster (2) periodically reads the record of the status of the computer (1) in the database (8) of the computer controller (4) and, upon detecting the state "node unavailable", performs the operation of forced shutdown of the computer (1) through the IPMI board (6) - “fencing” and enters into the database (8) of the computer controller (4) a record that this computer (1) is in the “node fenced” state;
демон (13) восстановления ВМ периодически считывает в базе данных (8) ЭВМ-контроллера (4) запись состояния ЭВМ (1) и состояния «ограждения» ЭВМ (1) и при обнаружении состояния «узел огражден» начинает операцию восстановления ВМ на другой ЭВМ (1), при этом демон (13) восстановления ВМ опрашивает в базе данных (8) ЭВМ–контроллера (4) флаг включения автоматического выбора ЭВМ (1) для восстановления; the daemon (13) of restoring the VM periodically reads in the database (8) of the computer controller (4) the record of the state of the computer (1) and the state of the "fencing" of the computer (1) and when the state "node is fenced" is detected, it starts the operation of restoring the VM on another computer (1), while the VM recovery demon (13) polls the database (8) of the computer controller (4) for the automatic selection flag of the computer (1) for recovery;
в случае, если флаг включения автоматического выбора ЭВМ (1) для восстановления включен, то демон (13) восстановления ВМ опрашивает по очереди записи в базе данных (8) ЭВМ–контроллера (4) с уровнем загрузки оперативной памяти на каждой ЭВМ (1) и делает попытку восстановления ВМ на ЭВМ (1) с состоянием «доступен» с наименьшей загрузкой оперативной памяти;if the flag for enabling automatic selection of computers (1) for recovery is enabled, then the daemon (13) for restoring the VM polls in turn the records in the database (8) of the computer controller (4) with the level of RAM load on each computer (1) and makes an attempt to restore the VM on the computer (1) with the state "available" with the least load of RAM;
в случае, если флаг включения автоматического выбора ЭВМ (1) для восстановления отключен, то демон (13) восстановления ВМ считывает из базы данных (8) ЭВМ – контроллера (4) запись с перечнем и порядком ЭВМ (1), на которых необходимо выполнить восстановление ВМ;if the flag for enabling automatic selection of computers (1) for recovery is disabled, then the daemon (13) for restoring the VM reads from the database (8) of the computer-controller (4) an entry with the list and order of the computers (1) on which it is necessary to perform VM recovery;
демон (13) восстановления ВМ опрашивает флаг включения выбора ЭВМ (1) для восстановления ВМ с наименьшей загрузкой оперативной памяти;the VM recovery daemon (13) polls the computer selection enable flag (1) to restore the VM with the least RAM load;
в случае, если флаг включения выбора ЭВМ (1) для восстановления ВМ с наименьшей загрузкой оперативной памяти отключен, то демон (13) восстановления ВМ предпринимает попытку восстановления ВМ на первой ЭВМ (1) из перечня с состоянием «доступен»; if the enable flag for selecting a computer (1) for restoring a VM with the least RAM load is disabled, then the VM restore daemon (13) attempts to restore the VM on the first computer (1) from the list with the “available” state;
в случае, если флаг включения выбора ЭВМ (1) для восстановления ВМ с наименьшей загрузкой оперативной памяти включен, то демон (13) восстановления ВМ делает попытку восстановить ВМ на ЭВМ (1) с состоянием «узел доступен» с наименьшей загрузкой оперативной памяти; if the enable flag of the choice of computer (1) for restoring the VM with the least RAM load is enabled, then the VM restore daemon (13) makes an attempt to restore the VM on the computer (1) with the "node available" state with the least RAM load;
в случае, если попытка восстановления ВМ неуспешна, то демон (13) восстановления ВМ делает попытку восстановления ВМ на следующей ЭВМ (1) с наименьшей загрузкой оперативной памяти или следующей ЭВМ (1) по порядку из выбранного пользователем перечня с состоянием «узел доступен», при этом перед каждый следующей попыткой демон (13) восстановления ВМ должен ожидать завершение тайм-аута, заданного пользователем при настройке функции высокой доступности ВМ; if the attempt to restore the VM is unsuccessful, then the VM restore daemon (13) makes an attempt to restore the VM on the next computer (1) with the least RAM load or the next computer (1) in order from the list selected by the user with the state "node available", at the same time, before each next attempt, the VM restore daemon (13) must wait for the end of the timeout specified by the user when configuring the high availability function of the VM;
восстановление ВМ осуществляется путем передачи демоном (13) восстановления ВМ на ЭВМ (1) конфигурационных данных гипервизора (7).VM recovery is carried out by transferring the VM recovery daemon (13) to the computer (1) with configuration data of the hypervisor (7).
Также технический результат достигается за счет того, что система централизованного реагирования на отказ сети или отказ сервера в кластере высокой доступности и восстановления виртуальной машины в кластере высокой доступности (2), включает набор виртуальных машин (ВМ), развернутых на группе ЭВМ (1, 2 … N) (1) с установленным гипервизором (7), снабженными платой - IPMI (6), ЭВМ-контроллер (4), ЭВМ–СХД (5), содержащая базу данных (9) гостевой операционной системы виртуальных машин (ВМ), коммутатор Ethernet (3), обеспечивающий связь между элементами системы посредство IPMI интерфейса, при этом ЭВМ–контроллер (4) содержит управляющий программный комплекс, включающий «демон (10) опроса ЭВМ из кластера», «демон (11) определения состояний ЭВМ кластера», «демон (12) ограждения узлов ЭВМ кластера», «демон (13) восстановления ВМ», а также базу данных (8), в которой хранятся конфигурационные данные гипервизора (7) выключенных виртуальных машин (ВМ), служебные настройки, включающие по меньшей мере флаг включения функции высокой доступности, флаг включения автоматического выбора ЭВМ для восстановления, перечень и порядок ЭВМ, на которых необходимо выполнить восстановление ВМ, флаг включения выбора ЭВМ для восстановления ВМ с наименьшей загрузкой оперативной памяти, количество попыток восстановления ВМ, временной промежуток между попытками восстановления ВМ.Also, the technical result is achieved due to the fact that the system of centralized response to network failure or server failure in a high availability cluster and restoration of a virtual machine in a high availability cluster (2) includes a set of virtual machines (VM) deployed on a group of computers (1, 2 ... N) (1) with installed hypervisor (7), equipped with a board - IPMI (6), computer controller (4), computer-storage system (5), containing a database (9) of the guest operating system of virtual machines (VM), an Ethernet switch (3) that provides communication between system elements via the IPMI interface, while the computer-controller (4) contains a control software package, including a “daemon (10) for polling computers from the cluster”, “daemon (11) for determining the states of the cluster computers” , "daemon (12) fencing cluster computer nodes", "daemon (13) restoring VMs", as well as a database (8), which stores the configuration data of the hypervisor (7) of turned off virtual machines (VMs), service settings, including lesser measures e flag for enabling the high availability function, flag for enabling automatic selection of computers for recovery, list and order of computers on which it is necessary to restore the VM, flag for enabling the selection of computers for restoring a VM with the least RAM load, number of attempts to restore a VM, time interval between attempts to restore VM.
[0032] Заявляемое техническое решение имеет централизованную архитектуру, в которой все управляющие решения принимаются модулем контроллером, устанавливаемым на отдельный сервер или виртуальную машину – ЭВМ – контроллер (4). ЭВМ – контроллер (4) осуществляет управление физическими серверами ЭВМ (1) с запущенными виртуальными машинами. Таким образом, на физические серверы в контуре управления ЭВМ – контроллера (4) может не требоваться установка специализированного программного обеспечения высокой доступности – агентов высокого давления.[0032] The proposed technical solution has a centralized architecture in which all control decisions are made by the controller module installed on a separate server or virtual machine - computer - controller (4). Computer - controller (4) manages the physical servers of the computer (1) with running virtual machines. Thus, the physical servers in the control loop of the computer-controller (4) may not require the installation of specialized high-availability software - high-pressure agents.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯIMPLEMENTATION OF THE INVENTION
[0033] Заявляемое изобретение обеспечивает создание и администрирование виртуальной инфраструктуры на группе серверов в центрах обработки данных. На серверах выполняются виртуальные машины (ВМ), в которых запущены гостевые операционные системы с различными приложениями. Серверы могут объединяться в кластеры для осуществления различных функций, например, динамическая миграция ВМ («live migration»), балансировка нагрузки для равномерного использования ресурсов серверов («DRS кластер») и автоматическое восстановление виртуальных машин при отказах оборудования или сети (кластер высокой доступности).[0033] The claimed invention provides for the creation and administration of a virtual infrastructure on a group of servers in data centers. The servers run virtual machines (VMs) that run guest operating systems with various applications. Servers can be combined into clusters to perform various functions, for example, live migration of VMs (“live migration”), load balancing for even use of server resources (“DRS cluster”), and automatic recovery of virtual machines in case of hardware or network failures (high availability cluster) .
[0034] Реализация изобретения поясняется чертежами, на которых изображены:[0034] The implementation of the invention is illustrated by drawings, which show:
Фиг.1 – типовая схема инфраструктуры для организации функции высокой доступности;Fig.1 is a typical infrastructure diagram for organizing a high availability function;
Фиг.2 – функциональная схема механизма высокой доступности ВМ;Fig. 2 is a functional diagram of the VM high availability mechanism;
Фиг.3 – блок -схема алгоритма, реализуемого демоном восстановления ВМ. Fig.3 is a block diagram of the algorithm implemented by the VM recovery daemon.
На чертежах позиции имеют следующие обозначения:In the drawings, positions have the following designations:
1 – ЭВМ, формирующие кластер высокой доступности;1 - computers forming a high availability cluster;
2 – кластер высокой доступности;2 – high availability cluster;
3 – коммутатор Ethernet;3 – Ethernet switch;
4 – ЭВМ – контроллер;4 - computer - controller;
5 – ЭВМ – СХД;5 - computer - storage system;
6 – IPMI – плата;6 - IPMI - board;
7 – гипервизор;7 - hypervisor;
8 – данные гостевой ОС;8 – guest OS data;
9 – база данных;9 - database;
10 – демон опроса ЭВМ из кластера;10 – daemon for polling computers from the cluster;
11 – демон определения состояний ЭВМ из кластера;11 – daemon for determining computer states from the cluster;
12 – демон ограждения узлов ЭВМ кластера;12 – daemon for fencing cluster computer nodes;
13 – демон восстановления ВМ.13 - VM recovery daemon.
[0035] Типовая схема инфраструктуры под управлением ЭВМ – контроллера (4) представлена на фиг. 1. Виртуальная машина (ВМ) устанавливается на группе ЭВМ (ЭВМ 1, 2 … N) (1) с одинаковой процессорной архитектурой, формирующих кластер высокой доступности (2) (далее – «кластер»). ЭВМ (1) для запуска ВМ объединены в сеть с ЭВМ-контроллером (4) и ЭВМ-СХД (5) через коммутатор Ethernet (3). [0035] A typical scheme of the infrastructure controlled by a computer-controller (4) is shown in Fig. 1. A virtual machine (VM) is installed on a group of computers (
[0036] ЭВМ (1) содержит материнскую плату с интерфейсом IPMI – IPMI-плата (6) для запуска ВМ, которая должна быть подключена к общей сети Ethernet.[0036] The computer (1) contains a motherboard with an IPMI interface - an IPMI board (6) for running the VM, which must be connected to a common Ethernet network.
[0037] На ЭВМ (1) установлен гипервизор (7), конфигурационные данные которого хранятся в базе данных (8) ЭВМ-контроллера (4), на котором также установлен управляющий программный комплекс. Данные гостевой ОС (9) хранятся на ЭВМ-СХД (5) в виде файлов или блочных дисковых разделов. [0037] A hypervisor (7) is installed on the computer (1), the configuration data of which is stored in the database (8) of the computer controller (4), on which the control software package is also installed. Guest OS data (9) is stored on the storage computer (5) in the form of files or block disk partitions.
[0038] ЭВМ-контроллер (4) устанавливается на отдельный сервер или виртуальную машину (ВМ) и выполняет следующие основные функции: [0038] The computer controller (4) is installed on a separate server or virtual machine (VM) and performs the following main functions:
- управление виртуальной инфраструктурой на группе серверов с графического веб-интерфейса;- management of virtual infrastructure on a group of servers from a graphical web interface;
- хранение информации о состоянии всей виртуальной инфраструктуре в базе данных;- storage of information about the state of the entire virtual infrastructure in the database;
- мониторинг и журналирование событий;- monitoring and logging of events;
- балансировка нагрузки для равномерного использования ресурсов серверов;- load balancing for uniform use of server resources;
- мониторинг доступности виртуальных машин и восстановление на доступных серверах кластера;- monitoring the availability of virtual machines and recovery on available cluster servers;
- аутентификация пользователей и разграничение доступа.- user authentication and access control.
[0039] В минимальной конфигурации развертывания инфраструктуры ЭВМ-контроллером (4) централизованно выполняется вся логика управления, в том числе принимаются все решения о восстановлении ВМ ЭВМ (1) в кластере (2).[0039] In the minimum infrastructure deployment configuration, the computer controller (4) centrally executes all management logic, including all decisions to restore the computer (1) in the cluster (2).
[0040] В общем виде ВМ ЭВМ (1) в выключенном состоянии представляет собой конфигурационные данные гипервизора (7) и может также включать данные гостевой ОС (9) в виде файлов (в форматах qcow2, iso) или дисковых блочных разделов. Конфигурационные данные гипервизора (7) выключенной ВМ постоянно хранятся в базе данных (8) ЭВМ-контроллера (4).[0040] In general, the computer VM (1) in the off state is the configuration data of the hypervisor (7) and may also include guest OS data (9) in the form of files (in qcow2, iso formats) or disk block partitions. The configuration data of the hypervisor (7) of the switched off VM is permanently stored in the database (8) of the computer controller (4).
[0041] ВМ во включенном состоянии представляет собой процесс гипервизора (7) с конфигурационными данными ВМ и данными гостевой ОС (9), загруженными в энергозависимую оперативную память ЭВМ (1) (физического сервера). Процесс гипервизора (7) создается на основе конфигурационных данных гипервизора, которые ЭВМ – контроллер (4) из базы данных (8) передает на физический сервер, например, по протоколу SSH.[0041] The VM in the on state is a hypervisor process (7) with VM configuration data and guest OS data (9) loaded into the volatile RAM of the computer (1) (physical server). The hypervisor process (7) is created based on the configuration data of the hypervisor, which the computer-controller (4) transfers from the database (8) to the physical server, for example, via the SSH protocol.
[0042] Данные гостевой ОС (9) могут храниться как в энергонезависимой памяти ЭВМ (1), на которой выполняется ВМ, так и на внешних ЭВМ, в том числе на специализированных системах хранения данных – ЭВМ – СХД (5). Данные процесса гипервизора (7) могут храниться только в памяти ЭВМ (1).[0042] Guest OS data (9) can be stored both in the non-volatile memory of the computer (1) on which the VM is running, and on external computers, including specialized data storage systems - computers - storage systems (5). Hypervisor process data (7) can only be stored in computer memory (1).
[0043] Исходя из этого, возможно отделить ЭВМ (1), на которой непосредственно производится вычислительный процесс выполнения ВМ, и ЭВМ (1), на которых хранятся данные ВМ. Так как для запуска ВМ на любой ЭВМ (1) с одинаковой процессорной архитектурой достаточно, чтобы были доступны данные конфигурации и гостевой ОС (9), то становится возможным перемещать ВМ между несколькими ЭВМ (1) с минимальным перерывом, необходимым для загрузки данных в оперативную память ЭВМ (1).[0043] Based on this, it is possible to separate the computer (1) on which the computational process of executing the VM is directly performed, and the computer (1) on which the VM data is stored. Since to run a VM on any computer (1) with the same processor architecture, it is enough that the configuration data and the guest OS (9) are available, it becomes possible to move the VM between several computers (1) with a minimum interruption necessary to load data into the operating system. computer memory (1).
[0044] На этом принципе основывается заявляемый способ централизованного реагирования на отказ сети или отказ сервера в кластере высокой доступности и восстановления виртуальной машины в кластере высокой доступности. Если конфигурационные данные гипервизора (7) хранятся в базе данных (8) ЭВМ – контроллера (4) и данные гостевой ОС (9) хранятся на внешней системе хранения данных ЭВМ – СХД (5), то возможно с помощью ЭВМ – контроллера (4) автоматизировать восстановление ВМ на любой ЭВМ (1) из кластера (2) без необходимости установки агентов высокой доступности на каждый физический сервер – ЭВМ (1). [0044] Based on this principle, the inventive method of centrally responding to a network failure or server failure in a high availability cluster and restoring a virtual machine in a high availability cluster. If the configuration data of the hypervisor (7) is stored in the database (8) of the computer - controller (4) and the data of the guest OS (9) is stored on the external data storage system of the computer - storage system (5), then it is possible with the help of the computer - controller (4) automate VM recovery on any computer (1) from the cluster (2) without the need to install high availability agents on each physical server - computer (1).
[0045] Разработанные алгоритмы реагирования на отказ сети или отказ сервера в кластере высокой доступности и восстановления виртуальной машины в кластере высокой доступности реализуются управляющим программным комплексом, установленным на выделенной ЭВМ – контроллер (4), взаимодействуя с ЭВМ (1) и развернутыми на них виртуальными машинами (ВМ). [0045] The developed algorithms for responding to a network failure or server failure in a high-availability cluster and restoring a virtual machine in a high-availability cluster are implemented by the control software package installed on a dedicated computer - controller (4), interacting with computers (1) and virtual machines deployed on them. machines (VM).
[0046] На ЭВМ–контроллере (4) установлены следующие программные компоненты, формирующие управляющий программный комплекс (фиг. 2):[0046] The following software components are installed on the computer controller (4), which form the control software complex (Fig. 2):
- демон (10) опроса ЭВМ из кластера;- daemon (10) polling computers from the cluster;
- демон (11) определения состояний ЭВМ из кластера;- demon (11) for determining the states of the computer from the cluster;
- демон (12) ограждения узлов ЭВМ на кластере;- demon (12) for fencing computer nodes on the cluster;
- демон (13) восстановления ВМ.- VM recovery daemon (13).
[0047] Предварительного пользователь должен через графический интерфейс ЭВМ – контроллера (4) кластера или отдельных ВМ ввести следующие служебные настройки, которые должны быть занесены в базу данных (8) ЭВМ-контроллера (4):[0047] The preliminary user must, through the graphical interface of the computer - the controller (4) of the cluster or individual VMs, enter the following service settings, which must be entered into the database (8) of the computer controller (4):
- флаг включения функции высокой доступности;- flag for enabling the high availability function;
- флаг включения автоматического выбора ЭВМ для восстановления ВМ;- flag for enabling automatic selection of a computer for restoring a VM;
- перечень и порядок ЭВМ, на которых необходимо выполнить восстановление ВМ (действует при отключенном флаге автоматического выбора ЭВМ);- list and order of computers on which it is necessary to restore the computer (valid when the computer automatic selection flag is disabled);
- флаг включения выбора ЭВМ для восстановления ВМ с наименьшей загрузкой оперативной памяти (далее – ОП) (действует при отключенном флаге автоматического выбора ЭВМ);- the flag for enabling the choice of a computer for restoring a computer with the least load of RAM (hereinafter referred to as RAM) (valid when the automatic computer selection flag is disabled);
- количество попыток восстановления ВМ (по умолчанию – 5);- number of attempts to restore the VM (default - 5);
- тайм-аут (временной промежуток) между попытками восстановления ВМ (по умолчанию устанавливается – 60 секунд).- timeout (time interval) between VM recovery attempts (default is 60 seconds).
[0048] При установке настроек для кластера (2), все ВМ в кластере должны наследовать этим настройки.[0048] When setting the settings for a cluster (2), all VMs in the cluster must inherit these settings.
[0049] В штатном режиме работы кластера (2) ЭВМ – контроллер (4) должен обрабатывать так называемые heartbeat-сигналы от серверов – ЭВМ (1) и ВМ.[0049] In the normal mode of operation of the cluster (2), the computer - the controller (4) must process the so-called heartbeat signals from the servers - the computer (1) and the VM.
[0050] В предложенном способе централизованного реагирования предлагается обрабатывать следующие типы heartbeat-сигналов:[0050] In the proposed centralized response method, it is proposed to process the following types of heartbeat signals:
- сигналы от ЭВМ (1): ping-запрос или делать попытки подключиться по SSH;- signals from the computer (1): ping request or make attempts to connect via SSH;
- сигналы активности ВМ: проверка активности записи в образ ВМ через определённые периоды времени;- VM activity signals: checking the activity of writing to the VM image after certain periods of time;
- сигналы от платы IPMI (6).- signals from the IPMI board (6).
[0051] Демон (10) опроса ЭВМ из кластера подключается по соответствующим протоколам к ЭВМ (1), принимает сигнальные сообщения «heartbeat» от ЭВМ (1), ВМ и платы-IPMI (6), формирует информационные сообщения и помещает их в очередь для обработки демоном (10) определения состояний ЭВМ (1).[0051] The daemon (10) for polling a computer from the cluster connects to the computer (1) using the appropriate protocols, receives heartbeat signal messages from the computer (1), VM and IPMI board (6), generates information messages and puts them in the queue for processing by the demon (10) of determining the states of the computer (1).
[0052] Демон (11) определения состояний ЭВМ (1) в кластере (2) выявляет отсутствие информационных сообщений в течение определенного времени (тайм-аута) (по умолчанию – 60 секунд) и меняет запись состояния ЭВМ (1) в базе данных (8) ЭВМ -контроллера (4) на «узел недоступен».[0052] The daemon (11) for determining the states of the computer (1) in the cluster (2) detects the absence of information messages for a certain time (timeout) (by default - 60 seconds) and changes the record of the state of the computer (1) in the database ( 8) Computer-controller (4) to "node unavailable".
[0053] Демон (12) ограждения узлов ЭВМ кластера (2) периодически считывает запись статуса ЭВМ (1) в базе данных (8) ЭВМ – контроллера (4) и при обнаружении состояния «узел недоступен» выполняет операцию принудительного выключения ЭВМ (1) через интерфейс IPMI (6) – «ограждение». Операция «ограждения» необходима, чтобы гарантировать выключение ВМ на недоступной ЭВМ (1) для исключения возможности повреждения данных вследствие одновременного выполнения операции записи двух экземпляров ВМ на один участок дисковой памяти. Демон (12) ограждения узлов ЭВМ кластера направляет сигнал принудительного выключения ЭВМ (1) на плату IPMI (6). В случае успешного принудительного выключения ЭВМ (1) плата-IPMI (6) возвращает демону (12) ограждения узлов ЭВМ кластера положительный сигнал. После чего демон (12) ограждения узлов ЭВМ кластера вносит в базу данных (8) ЭВМ-контроллера (4) запись, подтверждающую, что данная ЭВМ (1) находится в состоянии «узел огражден».[0053] The daemon (12) fencing the nodes of the cluster computer (2) periodically reads the record of the status of the computer (1) in the database (8) of the computer-controller (4) and, upon detecting the state "node unavailable", performs the operation of forced shutdown of the computer (1) through the IPMI interface (6) - "fencing". The “fencing” operation is necessary to ensure that the VM is turned off on an inaccessible computer (1) to exclude the possibility of data corruption due to the simultaneous write operation of two VM instances to one disk memory area. The daemon (12) for fencing the nodes of the cluster computers sends a forced shutdown signal for the computer (1) to the IPMI board (6). In the event of a successful forced shutdown of the computer (1), the IPMI board (6) returns a positive signal to the demon (12) of the fence of the cluster computer nodes. After that, the demon (12) of fencing the nodes of the cluster computer enters into the database (8) of the computer controller (4) a record confirming that this computer (1) is in the "node is fenced" state.
[0054] Далее выполняется алгоритм восстановления ВМ, реализуемый демоном (13) восстановления ВМ (фиг. 3).[0054] Next, the VM recovery algorithm implemented by the VM recovery daemon (13) is executed (FIG. 3).
[0055] Демон (13) восстановления ВМ периодически считывает запись состояния ЭВМ (1) и состояния «ограждения» ЭВМ (1) в базе данных (8) ЭВМ-контроллера (4) и при обнаружении состояния ЭВМ (1) «узел огражден», начинает операцию восстановления ВМ на другой ЭВМ (1). Демон (13) восстановления ВМ опрашивает в базе данных (8) ЭВМ – контроллера (4) флаг включения автоматического выбора ЭВМ (1) для восстановления ВМ.[0055] The VM recovery daemon (13) periodically reads the record of the state of the computer (1) and the state of the "fencing" of the computer (1) in the database (8) of the computer controller (4) and upon detection of the state of the computer (1) "node is fenced" , starts the VM recovery operation on another computer (1). The VM recovery daemon (13) queries the database (8) of the computer-controller (4) for the flag enabling automatic selection of the computer (1) for VM recovery.
[0056] Если данный флаг включен, то демон (13) восстановления ВМ опрашивает по очереди записи в базе данных (8) ЭВМ – контроллера (4) с уровнем загрузки ОП на каждой ЭВМ (1) и делать попытку восстановления ВМ на ЭВМ (1) с состоянием «доступен» с наименьшей загрузкой ОП.[0056] If this flag is enabled, then the VM recovery daemon (13) queries in turn the entries in the database (8) of the computer-controller (4) with the OP load level on each computer (1) and attempt to restore the VM on the computer (1 ) with the state "available" with the least load of the OP.
[0057] Если флаг включения автоматического выбора ЭВМ (1) для восстановления ВМ отключен, то демон (13) восстановления ВМ считывает из базы данных (8) ЭВМ – контроллера (4) запись с перечнем и порядком номером ЭВМ (1), на которых необходимо выполнить восстановление ВМ.[0057] If the flag for enabling automatic selection of computers (1) for restoring the VM is disabled, then the daemon (13) for restoring the VM reads from the database (8) of the computer-controller (4) an entry with a list and order of the number of computers (1) on which you need to restore the VM.
[0058] Демон (13) восстановления ВМ опрашивает флаг включения выбора ЭВМ (1) для восстановления ВМ с наименьшей загрузкой ОП.[0058] The VM recovery daemon (13) polls the computer selection enable flag (1) to recover the VM with the least RAM load.
[0059] Если данный флаг отключен, то демон (13) восстановления ВМ предпринимает попытку восстановления ВМ на первой ЭВМ (1) из перечня с состоянием «доступен». [0059] If this flag is disabled, then the VM restore daemon (13) attempts to restore the VM on the first computer (1) from the list with the "available" state.
[0060] Если флаг включения выбора ЭВМ (1) для восстановления ВМ с наименьшей загрузкой ОП включен, то демон (13) восстановления ВМ делает попытку восстановить ВМ на ЭВМ (1) с состоянием «узел доступен» с наименьшей загрузкой ОП. [0060] If the enable flag of the selection of the computer (1) for restoring the VM with the least RAM load is turned on, then the VM restore daemon (13) makes an attempt to restore the VM on the computer (1) with the node available state with the least RAM load.
[0061] Если попытка восстановления ВМ неуспешна, то демон (13) восстановления ВМ делает попытку восстановления на следующей ЭВМ (1) с наименьшей загрузкой ОП или следующей ЭВМ (1) по порядку из выбранного пользователем перечня с состоянием «узел доступен». Перед каждой следующей попыткой восстановления ВМ демон (13) восстановления ВМ должен ожидать завершение тайм-аута, заданного пользователем при служебной настройке функции высокой доступности ВМ, занесенных в базу данных (8) ЭВМ – контроллера (4). Количество попыток восстановления ВМ задается пользователем при служебной настройке функции высокой доступности ВМ.[0061] If the VM restore attempt is unsuccessful, then the VM restore daemon (13) attempts to restore on the next computer (1) with the least RAM load or the next computer (1) in order from the list selected by the user with the node available state. Before each next attempt to restore the VM, the daemon (13) for restoring the VM must wait for the end of the timeout specified by the user during the service setting of the high availability function of the VMs listed in the database (8) of the computer-controller (4). The number of attempts to restore the VM is set by the user during the service configuration of the high availability function of the VM.
[0062] Восстановление ВМ осуществляется путем передачи демоном (13) восстановления ВМ ЭВМ (1) конфигурационных данных гипервизора (7) по протоколу SSH и команды включения ВМ. [0062] Recovery of the VM is carried out by sending the daemon (13) of recovery of the VM to the computer (1) of the configuration data of the hypervisor (7) via the SSH protocol and the command to turn on the VM.
[0063] Если были отключены все ЭВМ (1) и коммутатор Ethernet (3), входящие в инфраструктуру кластера (2), то после включения может возникнуть следующий сценарий: операционная система ЭВМ (1) может загрузиться позже, чем управляющий программный комплекс на ЭВМ-контроллере (4), что повлечет за собой установку флага «узел недоступен» для ЭВМ (1), их принудительное выключение и попытки восстановления ВМ. [0063] If all computers (1) and the Ethernet switch (3) included in the cluster infrastructure (2) were turned off, then after turning on the following scenario may occur: the operating system of the computer (1) may boot later than the control software package on the computer -controller (4), which will entail the setting of the "node unavailable" flag for computers (1), their forced shutdown and attempts to restore the VM.
[0064] Для исключения данного сценария управляющий программный комплекс ЭВМ-контроллере (4) должен ожидать завершение тайм-аута 600 сек. прежде, чем запустить демон (13) восстановления ВМ.[0064] To exclude this scenario, the control software complex of the computer controller (4) must wait for the completion of the timeout of 600 seconds. before starting the VM recovery daemon (13).
Claims (24)
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2788309C1 true RU2788309C1 (en) | 2023-01-17 |
Family
ID=
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060085792A1 (en) * | 2004-10-15 | 2006-04-20 | Microsoft Corporation | Systems and methods for a disaster recovery system utilizing virtual machines running on at least two host computers in physically different locations |
| US20100211829A1 (en) * | 2009-02-18 | 2010-08-19 | Vmware, Inc. | Failure detection and recovery of host computers in a cluster |
| US9020895B1 (en) * | 2010-12-27 | 2015-04-28 | Netapp, Inc. | Disaster recovery for virtual machines across primary and secondary sites |
| RU2568282C2 (en) * | 2014-04-18 | 2015-11-20 | Закрытое акционерное общество "Лаборатория Касперского" | System and method for ensuring fault tolerance of antivirus protection realised in virtual environment |
| RU2595540C9 (en) * | 2011-10-25 | 2017-04-25 | Ницира, Инк. | Chassis controllers for converting universal flows |
| US10521315B2 (en) * | 2016-02-23 | 2019-12-31 | Vmware, Inc. | High availability handling network segmentation in a cluster |
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060085792A1 (en) * | 2004-10-15 | 2006-04-20 | Microsoft Corporation | Systems and methods for a disaster recovery system utilizing virtual machines running on at least two host computers in physically different locations |
| US20100211829A1 (en) * | 2009-02-18 | 2010-08-19 | Vmware, Inc. | Failure detection and recovery of host computers in a cluster |
| US9020895B1 (en) * | 2010-12-27 | 2015-04-28 | Netapp, Inc. | Disaster recovery for virtual machines across primary and secondary sites |
| RU2595540C9 (en) * | 2011-10-25 | 2017-04-25 | Ницира, Инк. | Chassis controllers for converting universal flows |
| RU2568282C2 (en) * | 2014-04-18 | 2015-11-20 | Закрытое акционерное общество "Лаборатория Касперского" | System and method for ensuring fault tolerance of antivirus protection realised in virtual environment |
| US10521315B2 (en) * | 2016-02-23 | 2019-12-31 | Vmware, Inc. | High availability handling network segmentation in a cluster |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10404795B2 (en) | Virtual machine high availability using shared storage during network isolation | |
| US9804901B2 (en) | Update management for a distributed computing system | |
| US8874954B1 (en) | Compatibility of high availability clusters supporting application failover with shared storage in a virtualization environment without sacrificing on virtualization features | |
| US8239518B2 (en) | Method for detecting and resolving a partition condition in a cluster | |
| KR100368078B1 (en) | Method and apparatus for building and managing multi-clustered computer systems | |
| US9507566B2 (en) | Entropy generation for a distributed computing system | |
| US9026848B2 (en) | Achieving ultra-high availability using a single CPU | |
| KR100336729B1 (en) | Method and apparatus for managing clustered computer system | |
| JP4345334B2 (en) | Fault tolerant computer system, program parallel execution method and program | |
| US7380155B2 (en) | System for highly available transaction recovery for transaction processing systems | |
| CN109634716B (en) | OpenStack virtual machine high-availability management end device for preventing brain cracking and management method | |
| US8473692B2 (en) | Operating system image management | |
| US20120180070A1 (en) | Single point, scalable data synchronization for management of a virtual input/output server cluster | |
| CN109684032B (en) | OpenStack virtual machine high-availability computing node device for preventing brain cracking and management method | |
| US20120179798A1 (en) | Autonomous primary node election within a virtual input/output server cluster | |
| US20120303594A1 (en) | Multiple Node/Virtual Input/Output (I/O) Server (VIOS) Failure Recovery in Clustered Partition Mobility | |
| CN109614201B (en) | OpenStack virtual machine high-availability system for preventing brain cracking | |
| KR20040047209A (en) | Method for automatically recovering computer system in network and recovering system for realizing the same | |
| US8990608B1 (en) | Failover of applications between isolated user space instances on a single instance of an operating system | |
| US9529656B2 (en) | Computer recovery method, computer system, and storage medium | |
| US20220300384A1 (en) | Enhanced fencing scheme for cluster systems without inherent hardware fencing | |
| RU2788309C1 (en) | Method for centralized response to a network failure or server failure in a high availability cluster and virtual machine recovery in a high availability cluster and a system implementing this method | |
| JP3947381B2 (en) | Method for processing unit synchronization for scalable parallel processing | |
| US11762741B2 (en) | Storage system, storage node virtual machine restore method, and recording medium | |
| US11119872B1 (en) | Log management for a multi-node data processing system |