Бюджетные системы высокой готовности

Содержание

Разработка конфигурации КВГ

КВГ предназначены для защиты вашей системы от сбоев


Поэтому на этапе разработки КВГ важно искать одиночные точки отказа (single points of failure, SPOFs). Если в архитектуре системы существуют единичные элементы, отказ которых приводит к отказу всего кластера — это одиночная точка отказа

Средство от одиночных точек отказа — избыточность. Вообще, есть «правило трех И высокой готовности»: избыточность, избыточность, избыточность. Если это звучит избыточно, то так оно и должно быть.

Рассмотрим системную архитектуру нашего примера. Мы видим избыточность в серверах, источниках бесперебойного питания, дисках и пр. Все это позволяет КВГ работать эффективно.

Данный пример не имеет внутренних одиночных точек отказа. Вне зависимости от того, что выйдет из строя в кластере, система продолжит функционировать. И хотя отказ репликационного канала приведет к невозможности синхронизации данных, это не вызовет отказа всего кластера, значит это не одиночная точка отказа. (В нашем примере мы рассматриваем реплицирующую систему, однако часто используются и разделяемые диски. Плюсы и минусы каждого варианта рассматриваются во врезке «Разделяемые диски и дисковая репликация»). Как можно понять из схемы, даже физическое уничтожение первичной системы не повлияет на работоспособность кластера и он продолжит функционировать.

Разделяемые диски и дисковая репликация

Пакет DRBD реплицирует данные между двумя дисками любого типа и реализует очень недорогое хранилище без одиночных точек отказа. Однако требования к хранилищу увеличены в два раза, а сама система иногда подвержена длинным ресинхронизациям после сбоев. Кроме того, в некоторых задачах будет ощущаться снижение производительности дисковой подсистемы.

Для многих серьезных приложений эти неудобства критичны. В таких случаях применяются разделяемые диски. Это могут быть дисковые массивы RAID с несколькими подключениями, двойные контроллеры RAID (например, IBM ServeRAID), разделяемые диски с интерфейсом fiber-channel, высокоуровневые хранилища класса IBM Enterprise Storage Server или другие EMC-решения высокого уровня. Эти системы сравнительно дороги (начиная от $5K до миллионов долларов). Однако они не страдают снижением производительности и необходимостью ресинхронизации.

Но лишь в наиболее дорогих решениях нет внутренних одиночных точек отказа.

Prerequisites

In order to automate the Floating IP reassignment, we must use the DigitalOcean API. This means that you need to generate a Personal Access Token (PAT), which is an API token that can be used to authenticate to your DigitalOcean account, with read and write access by following the section of the API tutorial. Your PAT will be used in a script that will be added to both servers in your cluster, so be sure to keep it somewhere safe—as it allows full access to your DigitalOcean account—for reference.

In addition to the API, this tutorial utilizes the following DigitalOcean features:

  • Floating IPs
  • Metadata
  • User Data (Cloud-Config scripts)

Please read the linked tutorials if you want to learn more about them.

Create Floating IP Reassignment Service

Our Heartbeat cluster is configured to maintain the service, which a node can use to assign the Floating IP to itself, but we still need to create the service. Before we set up the service itself, however, let’s create a script that will assign the Floating IP, via the DigitalOcean API, to the node that runs it. Then we will create the service which will run the Floating IP reassignment script.

Create assign-ip Script

For our example, we’ll download a basic Python script that assigns a Floating IP to a given Droplet ID, using the DigitalOcean API.

On both servers, download the Python script:

On both servers, make it executable:

Use of the script requires the following details:

  • Floating IP: The first argument to the script, the Floating IP that is being assigned
  • Droplet ID: The second argument to the script, the Droplet ID that the Floating IP should be assigned to
  • DigitalOcean PAT (API token): Passed in as the environment variable , your read/write DigitalOcean PAT

Feel free to review the contents of the script before continuing.

Now we’re ready to create the service.

Create floatip Service

To create the service, all we need to do is create an init script that invokes the script that we created earlier, and responds to and subcommands. This init script will be responsible for looking up the Droplet ID of the server, via the Droplet Metadata service. Also, it will require the Floating IP that will be reassigned, and the DigitalOcean API token (the Personal Access Token mentioned in the prerequisites section).

On both servers, add open in an editor:

Then copy and paste in this init script, replacing the highlighted parts with your DigitalOcean API key and the Floating IP that should be reassigned:

/etc/init.d/floatip

Save and exit.

Make the script executable:

When this service is started, it will simply call the Python script and assign the specified Floating IP to the Droplet that executed the script. This is the script that will be called by the secondary server, to reassign the Floating IP to itself, if the primary server fails. Likewise, the same script will be used by the primary server, to reclaim the Floating IP, once it rejoins the cluster.

How heartbeats and failover work in a cluster on Windows or Linux

The basic mechanism for synchronizing two servers and detecting server failures is the heartbeat, which is a monitoring data flow on a network shared by a pair of servers.

The SafeKit software supports shared by two servers. The heartbeat mechanism is used to implement Windows and Linux clusters. It is integrated within the SafeKit mirror cluster with real-time file replication and failover.

In normal operation, the two servers exchange their states (PRIM, SECOND, the resource states) through the heartbeat channels and synchronize their application start and stop procedures. In particular, in case of an application failover because of a software failure or a manual operation, the stop script which stops the application is first executed on the primary server, before executing the start script on the secondary server. Thus, replicated data on the secondary server are in a safe state corresponding to a clean stop of the application.

外掛說明

Heartbeat Control by WP Rocket allows you to manage the frequency of the WordPress heartbeat API in a few clicks.


The WordPress Heartbeat API is a great feature that provides real-time communication between the server and the browser when you are logged into your WordPress admin panel. It uses the file /wp-admin/admin-ajax.php to run AJAX calls from the browser. By default, AJAX requests are sent every 15 seconds on post edit pages, and every 60 seconds on the dashboard.

This is indeed helpful; but if you usually leave your WordPress admin open for long periods (for example when you write or edit posts), the AJAX requests from the API can pile up and generate high CPU usage, leading to server performance issues and even hosting account suspensions.

With Heartbeat Control by WP Rocket, you can easily choose to limit or completely stop the activity of the WordPress Heartbeat API. You can also add rules for specific locations only (Dashboard, Frontend or Post Editor).

To learn more about WordPress performance optimization and make your website faster, join our WP Rocket Facebook Community!

ШТА!

А вот сейчас я пожертвую качеством этой статьи, и изолью душу. И так, как же меня бесят псевдоблогеры, которые копируют друг у друга статьи, например: «установка таймера частоты запросов к файлу admin-ajax.php. в 60 сек. сократит расход ресурсов на данные запросы на целых 75%!». ШТА! Своих мозгов что ли нету. Везде эти 75%. Нельзя хотя бы написать 74 или 76%? Кровь в моих жилах кипит. Они даже не знают где смотреть частоту запросов на admin-ajax.php.

Но мир не без дураков. Как можно писать о 75%, если частота запросов к серверу, у каждого шаблона, плагина…. своя? Это то же самое что написать: у Маши было 3 яблока, она съела одно яблоко, теперь у неё 10 машинок. Логика, господа, где же ты! С такими вот блогерами и появляется неопределённость и ложные знания. И это касается не только cтатей о плагине Heartbeat Control. А если честно, народ — видите статью под копирку, то бегите от автора прочь. Ну да ладно, не буду дальше песочить «умников».

Split brain problem and quorum when servers are in two remote computer rooms

Most often, a HA cluster securing a critical application in a data center is implemented with two servers in two geographically remote computer rooms to support the disaster of a full room.

In situation of transient network isolation between both computer rooms, the split brain problem arises. Both servers may start the critical application.

With a hardware failover cluster, this situation must not arise because a double execution means a concurrent access on a shared storage and a potential corruption of the critical application data. That’s why a cluster quorum is implemented with a third quorum server or a special quorum disk or even a remote hardware reset when possible to avoid this concurrent execution of the critical application.

Unfortunately this new quorum devices add cost and complexity to the overall clustering architecture. And the system is not immune to a freeze of an OS: when the OS resumes from the freeze, there are a double execution of the application, even with the aforementioned mechanisms and potentially with corruption of data on the shared storage.

Değişiklik Kaydı

1.2.5

  • Fixed issue caused by previous version deployment.
  • Added hbc_disable_notice hook to force dismissal of update notices.
  • Additional documentation added.
  • Minor standards adjustments.

1.2.4

  • Updated CMB2 to 2.4.2.
  • Bumpted “tested up to” version.
  • Fixed a bug that occurred if no locations were selected.
  • Minor standards adjustments.

1.2.3

  • Added composer.json and composer.lock that were missing.
  • Updated CMB2 to 2.3
  • Translation files generated.
  • Language path and text domain added to plugin header.
  • Bumped compatible WP version.

1.2

  • Added conditional logic.
  • Multiple actions can now be performed.
  • Scripts are bundled and minified.
  • Changes to settings structure.
  • Miscellaneous bugfixes.

1.1

  • Rewritten from the ground up for future extensibility.
  • Performance enhancements.
  • Improved UI.
  • Better handling for late calls to the Heartbeat API.
  • New condition settings for filtering on the frontend.

Log zmian

1.2.5

  • Fixed issue caused by previous version deployment.
  • Added hbc_disable_notice hook to force dismissal of update notices.
  • Additional documentation added.
  • Minor standards adjustments.

1.2.4

  • Updated CMB2 to 2.4.2.
  • Bumpted „tested up to” version.
  • Fixed a bug that occurred if no locations were selected.
  • Minor standards adjustments.

1.2.3

  • Added composer.json and composer.lock that were missing.
  • Updated CMB2 to 2.3
  • Translation files generated.
  • Language path and text domain added to plugin header.
  • Bumped compatible WP version.

1.2

  • Added conditional logic.
  • Multiple actions can now be performed.
  • Scripts are bundled and minified.
  • Changes to settings structure.
  • Miscellaneous bugfixes.

1.1

  • Rewritten from the ground up for future extensibility.
  • Performance enhancements.
  • Improved UI.
  • Better handling for late calls to the Heartbeat API.
  • New condition settings for filtering on the frontend.

Changelog

1.2.5

  • Fixed issue caused by previous version deployment.
  • Added hbc_disable_notice hook to force dismissal of update notices.
  • Additional documentation added.
  • Minor standards adjustments.

1.2.4

  • Updated CMB2 to 2.4.2.
  • Bumpted “tested up to” version.
  • Fixed a bug that occurred if no locations were selected.
  • Minor standards adjustments.

1.2.3

  • Added composer.json and composer.lock that were missing.
  • Updated CMB2 to 2.3
  • Translation files generated.
  • Language path and text domain added to plugin header.
  • Bumped compatible WP version.

1.2

  • Added conditional logic.
  • Multiple actions can now be performed.
  • Scripts are bundled and minified.
  • Changes to settings structure.
  • Miscellaneous bugfixes.

1.1

  • Rewritten from the ground up for future extensibility.
  • Performance enhancements.
  • Improved UI.
  • Better handling for late calls to the Heartbeat API.
  • New condition settings for filtering on the frontend.

Available HA software

Much currently available software performs heartbeat monitoring and resource takeover functionality. Here is a list of available software for building high-availability clusters on various operating systems (see for links):

  • heartbeat (Linux)
  • High Availability Cluster Multiprocessing — HACMP (AIX)
  • IBM Tivoli System Automation for Multiplatforms (AIX, Linux)
  • Legato AAM 5.1 (AIX, HP-UX, Solaris, Linux, Windows)
  • SteelEye LifeKeeper (Linux, Windows)
  • Veritas Cluster Server (AIX, HP-UX, Solaris, Linux, Windows)

This series describes the open source HA software heartbeat. However, you can apply the concepts you learn here to any of the above software systems.

Descripción

Heartbeat Control by WP Rocket allows you to manage the frequency of the WordPress heartbeat API in a few clicks.

The WordPress Heartbeat API is a great feature that provides real-time communication between the server and the browser when you are logged into your WordPress admin panel. It uses the file /wp-admin/admin-ajax.php to run AJAX calls from the browser. By default, AJAX requests are sent every 15 seconds on post edit pages, and every 60 seconds on the dashboard.

This is indeed helpful; but if you usually leave your WordPress admin open for long periods (for example when you write or edit posts), the AJAX requests from the API can pile up and generate high CPU usage, leading to server performance issues and even hosting account suspensions.

With Heartbeat Control by WP Rocket, you can easily choose to limit or completely stop the activity of the WordPress Heartbeat API. You can also add rules for specific locations only (Dashboard, Frontend or Post Editor).

To learn more about WordPress performance optimization and make your website faster, join our WP Rocket Facebook Community!

6: Запуск Heartbeat

Теперь приложение Heartbeat настроено, все соответствующие сценарии готовы. Можно запустить кластер Heartbeat.

На обоих серверах введите эту команду для запуска кластера Heartbeat:

Настройка инфраструктуры высокой доступности завершена.

Тестирование высокой доступности

После настройки важно проверить работу инфраструктуры высокой доступности. В настоящее время плавающий IP присваивается первичной ноде (серверу 1)

Теперь плавающий IP-адрес просто покажет индексную страницу сервера 1. Если вы используете пример сценария пользовательских данных, она будет выглядеть примерно так:

В настоящее время плавающий IP присваивается первичной ноде (серверу 1). Теперь плавающий IP-адрес просто покажет индексную страницу сервера 1. Если вы используете пример сценария пользовательских данных, она будет выглядеть примерно так:

Теперь откройте локальный терминал и используйте curl, чтобы получить доступ к плавающему IP с помощью цикла. Используйте эту команду, но обязательно замените URL-адрес своим доменом или плавающим IP-адресом:


На данный момент команда тоже выведет имя и IP-адрес сервера 1. Если сервер 1 откажет (для этого можно, например, остановить сервис Heartbeat), плавающий IP будет переназначен серверу 2, и вы сможете убедиться в этом.

Перезапустите сервер 1. Для этого можно использовать панель управления или команду:

Через несколько секунд основной сервер станет недоступен

Обратите внимание на вывод цикла curl, который работает в терминале. Вы должны заметить вывод, который выглядит так:

То есть плавающий IP-адрес должен переназначиться на сервер 2. Это означает, что настройка высокой доступности работает, поскольку автоматический переход на другой ресурс прошел успешно.

Вы можете получить сообщение Connection refused. Оно возникает, если вы пытаетесь получить доступ к плавающим IP-адресам в период между сбоем основного сервера и завершением процесса переназначения плавающего IP-адреса.

Теперь можно включить сервер 1 через панель управления. Поскольку Heartbeat воспринимает сервер 1 как предпочтительный хост для запуска сценария переназначения плавающего IP, IP автоматически будет возвращен на сервер 1, как только он восстановит работу.

High availability concepts

High availability is the system management strategy of quickly restoring essential services in the event of system, component, or application failure. The goal is minimal service interruption rather than fault tolerance. The most common solution for a failure of a system performing critical business operations is to have another system waiting to assume the failed system’s workload and continue business operations.

The term «cluster» has different meanings within the computing industry. Throughout this article, unless noted otherwise, cluster describes a heartbeat cluster, which is a collection of nodes and resources (such as disks and networks) that cooperate to provide high availability of services running within the cluster. If one of those machines should fail, the resources required to maintain business operations are transferred to another available machine in the cluster.

The two main cluster configurations are:

  • Standby configuration: The most basic cluster configuration, in which one node performs work while the other node acts only as standby. The standby node does not perform work and is referred to as idle; this configuration is sometimes called cold standby. Such a configuration requires a high degree of hardware redundancy. This series of articles focuses on cold standby configuration.
  • Takeover configuration: A more advanced configuration in which all nodes perform some kind of work, and critical work can be taken over in the event of a node failure. In a one-sided takeover configuration, a standby node performs some additional, non-critical, non-movable work. In a mutual takeover configuration, all nodes are performing highly available (movable) work. This series of articles does not address takeover configuration.

You must plan for several key items when setting up an HA cluster:

  • The disks used to store the data must be connected by a private interconnect (serial cable) or LAN to the servers that make up the cluster.
  • There must be a method for automatic detection of a failed resource. This is done by a software component referred to as a heartbeat monitor.
  • There must be automatic transfer of resource ownership to one or more surviving cluster members upon failure.

Heartbeats and TCP Proxies

Certain networking tools (HAproxy, AWS ELB) and equipment (hardware load balancers) may terminate «idle» TCP connections when there is no activity on them for a certain period of time. Most of the time it is not desirable.

When heartbeats are enabled on a connection, it results in periodic light network traffic. Therefore heartbeats have a side effect of guarding client connections that can go idle for periods of time against premature closure by proxies and load balancers.

With a heartbeat timeout of 30 seconds the connection will produce periodic network traffic roughly every 15 seconds. Activity in the 5 to 15 second range is enough to satisfy the defaults of most popular proxies and load balancers. Also see the section on low timeouts and false positives above.

Set up NFS for a shared file system

As mentioned, I used NFS for shared data between nodes for the test setup.

  • The node nfsha.haw2.ibm.com is used as an NFS server.
  • The file system /ha is shared.

To get NFS up and running:

  1. Create a directory /ha on nfsha node.
  2. Edit the /etc/exports file. This file contains a list of entries; each entry indicates a volume that is shared and how it is shared. Listing 1 shows the relevant portion of the exports file for my setup.
    Listing 1. exports file
    ...
    /ha 9.22.7.48(rw,no_root_squash)
    /ha 9.22.7.46(rw,no_root_squash)
    /ha 9.22.7.35(rw,no_root_squash)
    /ha 9.22.7.49(rw,no_root_squash)
    /ha 9.22.7.50(rw,no_root_squash)
    ...
  3. Start the NFS services. If NFS is already running, you should run the command to force nfsd to re-read the /etc/exports file.
  4. Add the file system /ha to your /etc/fstab file, on both the HA nodes — ha1 and ha2 — the same way as local file systems. Listing 2 shows the relevant portion of the fstab file for my setup:
    Listing 2. fstab file

    Later on, we will configure heartbeat to mount this file system.

  5. Extract the code sample, hahbcode.tar.gz, on this file system using the commands shown in Listing 3. (First download the code sample from the section below.)
    Listing 3. Extract sample code

Приготовьте аппаратное обеспечение

Для работы кластера нам будут нужны: диски, сетевые карты для канала репликации, последовательный кабель и управляющие кабеля для ИБП.

  • Установите стандартным способом диски, но не создавайте на них файловые системы.
  • Теперь установите сетевые карты и настройте их так, чтобы они находились в одной подсети. Например, 192.168.0.0/16 или 10.0.0.0/8.
  • Приобретите последовательный кабель для соединения типа ПК-ПК. Это должен быть нуль-модемный кабель, поддерживающий сигналы CTS и RTS.
  • Подключите каждый компьютер к соответствующему ИБП.
  • Хотя наши инструкции несколько специфичны для архитектуры x86, все ПО работает на всех платформах Linux и вы не ограничены конкретным аппаратным обеспечением.

변경이력

1.2.5

  • Fixed issue caused by previous version deployment.
  • Added hbc_disable_notice hook to force dismissal of update notices.
  • Additional documentation added.
  • Minor standards adjustments.

1.2.4

  • Updated CMB2 to 2.4.2.
  • Bumpted “tested up to” version.
  • Fixed a bug that occurred if no locations were selected.
  • Minor standards adjustments.

1.2.3

  • Added composer.json and composer.lock that were missing.
  • Updated CMB2 to 2.3
  • Translation files generated.
  • Language path and text domain added to plugin header.
  • Bumped compatible WP version.

1.2

  • Added conditional logic.
  • Multiple actions can now be performed.
  • Scripts are bundled and minified.
  • Changes to settings structure.
  • Miscellaneous bugfixes.

1.1

  • Rewritten from the ground up for future extensibility.
  • Performance enhancements.
  • Improved UI.
  • Better handling for late calls to the Heartbeat API.
  • New condition settings for filtering on the frontend.

Reviews

http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>lass=»plugin-reviews»>

No matter what settings I use, this plugin makes the load time of «admin-ajax.php» 2-3x slower. Uninstalled immediately.

Saved my website which was killing process

Works fine and reduces unnecessary load on the server created by Heartbeat.

very confusing no instructions about how to use this plugin and up to what amount the plugin can help, settings are confusing

Does not show you what the settings of heartbeat should be.

Setting the plugin to change the interval does nothing. Looking at the network sources tab you can see the interval remains unchanged at 15 seconds.

Descriere

Heartbeat Control by WP Rocket allows you to manage the frequency of the WordPress heartbeat API in a few clicks.

The WordPress Heartbeat API is a great feature that provides real-time communication between the server and the browser when you are logged into your WordPress admin panel. It uses the file /wp-admin/admin-ajax.php to run AJAX calls from the browser. By default, AJAX requests are sent every 15 seconds on post edit pages, and every 60 seconds on the dashboard.

This is indeed helpful; but if you usually leave your WordPress admin open for long periods (for example when you write or edit posts), the AJAX requests from the API can pile up and generate high CPU usage, leading to server performance issues and even hosting account suspensions.

With Heartbeat Control by WP Rocket, you can easily choose to limit or completely stop the activity of the WordPress Heartbeat API. You can also add rules for specific locations only (Dashboard, Frontend or Post Editor).

To learn more about WordPress performance optimization and make your website faster, join our WP Rocket Facebook Community!

Configure heartbeat

You must configure three files to get heartbeat to work: authkeys, ha.cf, and haresources. I’ll show you the specific configuration I used for this implementation; if you need more information, please refer to the heartbeat Web site and read their documentation (see ).

1. Configure /etc/ha.d/authkeys

This file determines your authentication keys for the cluster; the keys must be the same on both nodes. You can choose from three authentication schemes: crc, md5, or sha1. If your heartbeat runs over a secure network, such as the crossover cable in the example, you’ll want to use crc. This is the cheapest method from a resources perspective. If the network is insecure, but you’re either not very paranoid or concerned about minimizing CPU resources, use md5. Finally, if you want the best authentication without regard for CPU resources, use sha1, as it’s the hardest to crack.

The format of the file is as follows:

For the test setup I chose the crc scheme. Listing 5 shows the /etc/ha.d/authkeys file. Make sure its permissions are safe, such as 600.

Listing 5. authkeys file
auth 2
2 crc

2. Configure /etc/ha.d/ha.cf

This file will be placed in the /etc/ha.d directory that is created after installation. It tells heartbeat what types of media paths to use and how to configure them. This file also defines the nodes in the cluster and the interfaces that heartbeat uses to verify whether or not a system is up. Listing 6 shows the relevant portion of the /etc/ha.d/ha.cf file for my setup.

Listing 6. ha.cf file
...
#	File to write debug messages to
debugfile /var/log/ha-debug
#
#
# 	File to write other messages to
#
logfile	/var/log/ha-log
#
#
#	Facility to use for syslog()/logger
#
logfacility	local0
#
#
#	keepalive: how long between heartbeats?
#
keepalive 2
#
#	deadtime: how long-to-declare-host-dead?
#
deadtime 60
#
#	warntime: how long before issuing "late heartbeat" warning?
#
warntime 10
#
#
#	Very first dead time (initdead)
#
initdead 120
#
...
#	Baud rate for serial ports...
#
baud	19200
#
#	serial	serialportname ...
serial	/dev/ttyS0
#	auto_failback:  determines whether a resource will
#	automatically fail back to its "primary" node, or remain
#	on whatever node is serving it until that node fails, or
#	an administrator intervenes.
#
auto_failback on
#
...
#
#	Tell what machines are in the cluster
#	node	nodename ...	-- must match uname -n
node	ha1.haw2.ibm.com
node	ha2.haw2.ibm.com
#
#	Less common options...
#
#	Treats 10.10.10.254 as a pseudo-cluster-member
#	Used together with ipfail below...
#
ping 9.22.7.1
#	Processes started and stopped with heartbeat.  Restarted unless
#		they exit with rc=100
#
respawn hacluster /usr/lib/heartbeat/ipfail
...

3. Configure /etc/ha.d/haresources

This file describes the resources that are managed by heartbeat. The resources are basically just start/stop scripts much like the ones used for starting and stopping resources in /etc/rc.d/init.d. Note that heartbeat will look in /etc/rc.d/init.d and /etc/ha.d/resource.d for scripts. The script file httpd comes with heartbeat. Listing 7 shows my /etc/ha.d/haresources file:

Listing 7. haresources file
ha1.haw2.ibm.com 9.22.7.46 Filesystem::nfsha.haw2.ibm.com:/ha::/ha::nfs::rw,hard httpd

This file must be the same on both the nodes.

This line dictates that on startup:

  • Have ha1 serve the IP 9.22.7.46
  • Mount the NFS shared file system /ha
  • Start Apache Web server

I will be adding more resources to this file in later articles. On shutdown, heartbeat will:

  • Stop the Apache server
  • Unmount the shared file system
  • Give up the IP

This assumes that the command displays ha1.haw2.ibm.com; yours may well produce ha1, and if it does, use that instead.

4: Настройка Heartbeat

Чтобы получить нужный кластер, необходимо создать и настроить следующие файлы Heartbeat на обоих серверах в каталогах /etc/ha.d.

ha.cf – глобальная конфигурация кластера Heartbeat, которая включает все ноды. authkeys – содержит ключ безопасности, который позволяет нодам пройти аутентификацию в кластере. haresources – определяет сервисы, которыми управляет кластер, и ноду, которая должна быть владельцем этих сервисов

Обратите внимание, этот файл не используется в настройке, в которой есть CRM, (например, Pacemaker).. Также необходимо предоставить сценарий, который будет выполнять переназначение плавающего IP-адреса в случае сбоя сервера 1

Также необходимо предоставить сценарий, который будет выполнять переназначение плавающего IP-адреса в случае сбоя сервера 1.

Сбор информации о ноде

Прежде чем настроить файл ha.cf, нужно узнать имя каждой ноды. Heartbeat требует, чтобы имя ноды совпадало с ее выводом uname –n.


Следующую команду нужно запустить на обоих серверах.

Обратите внимание на вывод команды. Ноды должны иметь имена primary и secondary

Также нужно найти сетевой интерфейс и IP-адрес, который использует каждая нода для связи с остальной частью кластера. Вы можете использовать любой сетевой интерфейс, если каждая нода может взаимодействовать с остальными нодами в кластере. В руководстве используется публичный интерфейс серверов, eth0.

Чтобы узнать IP-адрес интерфейса eth0, запустите следующую команду на обоих серверах:

Примечание: Также узнать IP-адрес можно с помощью панели управления.

Обратите внимание на IP-адрес сетевого интерфейса (в примере он выделен красным). Не забудьте получить IP-адреса обоих серверов

Создание файла ha.cf

На обоих серверах откройте /etc/ha.d/ha.cf в редакторе:

Этот файл будет пустым. Сюда нужно добавить сетевые интерфейсы и имена каждой ноды в кластере.

Скопируйте и вставьте эту конфигурацию в файл, а затем замените имена и IP-адреса нод соответствующими значениями. В этом примере сервер 1 имеет IP-адрес 198.51.100.5, а сервер 2 – 198.51.100.6:

Сохраните и закройте файл.

Создание файла authkeys

Ключ авторизации позволяет нодам присоединиться к кластеру. Для этого можно просто создать случайный ключ. На сервере 1 запустите эти команды, чтобы создать ключ авторизации в переменной среды AUTH_KEY:

Затем добавьте ключ в /etc/ha.d/authkeys:

Проверьте содержимое файла authkeys:

Файл будет выглядеть так (ключ будет отличаться):

Право чтения файла должно быть только у пользователя root.

Скопируйте файл /etc/ha.d/authkeys с сервера 1 на сервер 2. Это можно сделать вручную или с помощью scp.

На сервере 2 нужно обновить права на файл:

На этом этапе оба сервера должны иметь идентичные файлы /etc/ha.d/authkeys.

Создание файла haresources

Файл haresources указывает предпочтительные хосты в паре  сервисами, которыми управляет кластер. Предпочтительным хостом является нода, которая должна запускать тот или иной сервис, если она доступна. Если предпочтительный хост недоступен в кластере, сервис передается другому хосту. Другими словами, вторичный сервер возьмет работу на себя, если первичный сервер перестанет работать.

На обоих серверах откройте файл haresources в текстовом редакторе:

Добавьте в файл эту строку, указав имя первичной ноды:

Сохраните и закройте файл.

Этот параметр настроит сервер 1 как предпочтительный хост для сервиса floatip, который в настоящее время не определен. Теперь нужно настроить сервис floatip.


С этим читают