HA cluster with DRBD and Heartbeat - Revision history

Kir: Reverted edits by 109.230.217.166 (talk) to last revision by Kir

2011-10-21T05:50:24Z

Reverted edits by 109.230.217.166 (talk) to last revision by Kir

Show changes

109.230.217.166: WpMJmIYJNBHprp

2011-10-21T03:58:32Z

WpMJmIYJNBHprp

Show changes

Kir: Reverted edits by 189.3.215.146 (talk) to last revision by Kir

2011-10-01T07:09:49Z

Reverted edits by 189.3.215.146 (talk) to last revision by Kir

189.3.215.146: 3wMokG xbjrbmuwoktf, [url=http://bxxlefalafkt.com/]bxxlefalafkt[/url], [link=http://zvxbehoiawye.com/]zvxbehoiawye[/link], http://djtxdwzhtuou.com/

2011-10-01T06:02:46Z

3wMokG <a href="http://xbjrbmuwoktf.com/">xbjrbmuwoktf</a>, [url=http://bxxlefalafkt.com/]bxxlefalafkt[/url], [link=http://zvxbehoiawye.com/]zvxbehoiawye[/link], http://djtxdwzhtuou.com/

Kir: Reverted edits by Davidbolton (Talk) to last revision by 80.99.109.81

2010-09-01T06:56:06Z

Reverted edits by Davidbolton (Talk) to last revision by 80.99.109.81

Davidbolton at 06:54, 1 September 2010

2010-09-01T06:54:18Z

Davidbolton at 06:30, 1 September 2010

2010-09-01T06:30:50Z

80.99.109.81: /* Setting up DRBD */

2010-05-06T18:28:55Z

‎Setting up DRBD

203.124.16.109: /* Installing the two nodes */

2010-02-08T13:12:53Z

‎Installing the two nodes

Neocodesoftware at 22:31, 15 December 2009

2009-12-15T22:31:44Z

← Older revision		Revision as of 07:09, 1 October 2011
Line 10:		Line 10:


−	~~3wMokG <~~a ~~href~~="http://~~xbjrbmuwoktf~~.~~com~~/">~~xbjrbmuwoktf~~</a>, [~~url=http~~://~~bxxlefalafkt~~.~~com~~/]~~bxxlefalafkt~~[/~~url~~], [~~link=http~~://~~zvxbehoiawye~~.~~com~~/]~~zvxbehoiawye[~~/~~link]~~, ~~http:~~//~~djtxdwzhtuou~~.~~com~~/	+	== Prerequisites ==
		+	The OpenVZ kernel already includes the DRBD module. The DRBD userspace tools and the cluster manager Heartbeat must be provided seperately. As the API version of the DRBD userspace tools must exactly match the API version of the module, compile them yourself. Also compile Heartbeat yourself, as at the time of this writing the CentOS extras repository only contained an old CVS version of Heartbeat.
		+
		+	On a hardware node for production use there should not be any application that is not really needed for running OpenVZ (any things which are not needed by OpenVZ should run in a VE for security reasons). As a result, compile DRBD and Heartbeat on another machine running CentOS 4.3 (in this example I used a virtual machine on a VMware Server).
		+
		+	=== Compiling Heartbeat ===
		+	Heartbeat version 1.2.* has successfully been used in a lot of two-node-clusters around the world. As the codebase used in version 1.2.* is in production use for many years now, the code is very stable. At the time of writing, Heartbeat version 1.2.4 is the current version of the 1.2.* branch.
		+
		+	Get the tar.gz of the current version of the 1.2.* branch from http://linux-ha.org/download/index.html, at the time of this writing this is http://linux-ha.org/download/heartbeat-1.2.4.tar.gz. Use rpmbuild to build the package:
		+	<pre>rpmbuild -ta heartbeat-1.2.4.tar.gz</pre>
		+	After that, you find four rpm packes in /usr/src/redhat/RPMS/i386 (heartbeat-1.2.4-1.i386.rpm, heartbeat-ldirectord-1.2.4-1.i386.rpm, heartbeat-pils-1.2.4-1.i386.rpm, heartbeat-stonith-1.2.4-1.i386.rpm). In this example only heartbeat-1.2.4-1.i386.rpm, heartbeat-pils-1.2.4-1.i386.rpm, and heartbeat-stonith-1.2.4-1.i386.rpm are needed.
		+
		+	=== Compiling DRBD userspace tools ===
		+	When compiling the DRBD userspace tools, you have to take care to take the version that matches the DRBD version that is included in the OpenVZ kernel you want to use. If you are unsure about the version, do the following steps while running the OpenVZ kernel that you want to use on a test machine (I used another virtual machine on a VMware server to try this):
		+	<pre>
		+	[root@testmachine ~]# cat /proc/version
		+	Linux version 2.6.8-022stab078.10 (root@rhel4-32) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)) #1 Wed Jun 21 12:01:20 MSD 2006
		+	[root@testmachine ~]# modprobe drbd
		+	[root@testmachine ~]# cat /proc/drbd
		+	version: 0.7.17 (api:77/proto:74)
		+	SVN Revision: 2093 build by phil@mescal, 2006-03-06 15:04:12
		+	0: cs:Unconfigured
		+	1: cs:Unconfigured
		+	[root@testmachine ~]# rmmod drbd
		+	[root@testmachine ~]#
		+	</pre>
		+	Here the version of the DRBD module is 0.7.17. So the userspace tools for 0.7.17 are neccessary.
		+
		+	Back on the buildmachine, do the following to create the rpm:
		+	<pre>
		+	[root@buildmachine ~]# yum install kernel-devel gcc bison flex
		+	Setting up Install Process
		+	Setting up repositories
		+	Reading repository metadata in from local files
		+	Parsing package install arguments
		+	Nothing to do
		+	[root@buildmachine ~]# tar xfz drbd-0.7.17.tar.gz
		+	[root@buildmachine ~]# cd drbd-0.7.17
		+	[root@buildmachine drbd-0.7.17]# make rpm
		+	[...]
		+	You have now:
		+	-rw-r--r-- 1 root root 288728 Jul 30 10:40 dist/RPMS/i386/drbd-0.7.17-1.i386.rpm
		+	-rw-r--r-- 1 root root 518369 Jul 30 10:40 dist/RPMS/i386/drbd-km-2.6.9_34.0.2.EL-0.7.17-1.i386.rpm
		+	[root@buildmachine drbd-0.7.17]#
		+	</pre>
		+	Note that in this way the kernel-devel from CentOS is used, but this does not matter as the created drbd-km rpm will not be used (the DRBD kernel module is already included in OpenVZ kernel). If the kernel-devel package is not the same version as the kernel package that is currently running, it is possible to execute 'make rpm KDIR=/usr/src/kernels/2.6.9-34.0.2.EL-i686/' to directly point to the kernel sources.

	== Installing the two nodes ==		== Installing the two nodes ==

← Older revision		Revision as of 06:02, 1 October 2011
Line 10:		Line 10:


−	~~== Prerequisites ==~~	+	3wMokG <a href="http://xbjrbmuwoktf.com/">xbjrbmuwoktf</a>, [url=http://bxxlefalafkt.com/]bxxlefalafkt[/url], [link=http://zvxbehoiawye.com/]zvxbehoiawye[/link], http://djtxdwzhtuou.com/
−	The OpenVZ kernel already includes the DRBD module. The DRBD userspace tools and the cluster manager Heartbeat must be provided seperately. As the API version of the DRBD userspace tools must exactly match the API version of the module, compile them yourself. Also compile Heartbeat yourself, as at the time of this writing the CentOS extras repository only contained an old CVS version of Heartbeat.
−
−	On a hardware node for production use there should not be any application that is not really needed for running OpenVZ (any things which are not needed by OpenVZ should run in a VE for security reasons). As a result, compile DRBD and Heartbeat on another machine running CentOS 4.3 (in this example I used a ~~virtual machine on a VMware Server).~~
−
−	~~=== Compiling Heartbeat =~~==
−	Heartbeat version 1.2.* has successfully been used in a lot of two-node-clusters around the world. As the codebase used in version 1.2.* is in production use for many years now, the code is very stable. At the time of writing, Heartbeat version 1.2.4 is the current version of the 1.2.* branch.
−
−	~~Get the tar.gz of the current version of the 1.2.* branch from http://linux-ha.org/download/index.html, at the time of this writing this is~~ http://~~linux-ha~~.~~org/download~~/~~heartbeat-1.2.4.tar.gz. Use rpmbuild to build the package:~~
−	~~<pre~~>~~rpmbuild -ta heartbeat-1.2.4.tar.gz~~</~~pre~~>
−	~~After that~~, you find four rpm packes in /usr/src/redhat/RPMS/i386 (heartbeat-1.2.4-1.i386.rpm, heartbeat-ldirectord-1.2.4-1.i386.rpm, heartbeat-pils-1.2.4-1.i386.rpm, heartbeat-stonith-1.2.4-1.i386.rpm). In this example only heartbeat-1.2.4-1.i386.rpm, heartbeat-pils-1.2.4-1.i386.rpm, and heartbeat-stonith-1.2.4-1.i386.rpm are needed.
−
−	=~~== Compiling DRBD userspace tools ===~~
−	When compiling the DRBD userspace tools, you have to take care to take the version that matches the DRBD version that is included in the OpenVZ kernel you want to use. If you are unsure about the version, do the following steps while running the OpenVZ kernel that you want to use on a test machine (I used another virtual machine on a VMware server to try this):
−	~~<pre>~~
−	~~[root@testmachine ~]# cat~~ /~~proc~~/~~version~~
−	~~Linux version 2~~.~~6.8-022stab078.10 (root@rhel4-32) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)) #1 Wed Jun 21 12:01:20 MSD 2006~~
−	~~[root@testmachine ~~~]~~# modprobe drbd~~
−	[~~root@testmachine ~]# cat /proc/drbd~~
−	~~version: 0.7.17 (api:77~~/~~proto:74)~~
−	~~SVN Revision: 2093 build by phil@mescal, 2006-03-06 15:04:12~~
−	~~0: cs:Unconfigured~~
−	~~1: cs:Unconfigured~~
−	~~[root@testmachine ~]# rmmod drbd~~
−	~~[root@testmachine ~~~]#
−	~~</pre>~~
−	~~Here the version of the DRBD module is 0.7.17. So the userspace tools for 0.7.17 are neccessary.~~
−
−	~~Back on the buildmachine~~, ~~do the following to create the rpm:~~
−	~~<pre>~~
−	[~~root@buildmachine ~]# yum install kernel-devel gcc bison flex~~
−	~~Setting up Install Process~~
−	~~Setting up repositories~~
−	~~Reading repository metadata in from local files~~
−	~~Parsing package install arguments~~
−	~~Nothing to do~~
−	~~[root@buildmachine ~]# tar xfz drbd-0.7.17.tar.gz~~
−	~~[root@buildmachine ~]# cd drbd-0.7.17~~
−	~~[root@buildmachine drbd-0.7.17]# make rpm~~
−	~~[...]~~
−	~~You have now~~:
−	~~-rw-r--r-- 1 root root 288728 Jul 30 10:40 dist~~/~~RPMS~~/~~i386/drbd-0.7.17-1.i386~~.~~rpm~~
−	~~-rw-r--r-- 1 root root 518369 Jul 30 10:40 dist~~/~~RPMS~~/~~i386/drbd-km-2.6.9_34.0.2.EL-0.7.17-1.i386.rpm~~
−	~~[root@buildmachine drbd-0.7.17~~]#
−	~~</pre>~~
−	~~Note that in this way the kernel-devel from CentOS is used~~, but this does not matter as the created drbd-km rpm will not be used (the DRBD kernel module is already included in OpenVZ kernel). If the kernel-devel package is not the same version as the kernel package that is currently running, it is possible to execute 'make rpm KDIR=/~~usr~~/~~src/kernels/2.6.9-34.0~~.~~2.EL-i686~~/~~' to directly point to the kernel sources.~~

	== Installing the two nodes ==		== Installing the two nodes ==

@@ Line 283: / Line 283: @@
 The installation of the cluster is finished at this point. Before putting the cluster in production it is very important to test the cluster. Because of all the possible different kinds of hardware that you may have, you may encounter problems when a failover is necessary. And as the cluster is about high availability, such problems must be found before the cluster is used for production.
-Here is one example: The e1000 driver that is included in kernels < 2.6.12 has a problem when a cable gets unplugged while broadcast packets are still being sent out on that interface. When using broadcast communication in Heartbeat on a crossover link, this fills up the transmit ring buffer on the adapter (the buffer is full after about 8 minutes after the cable got unplugged). Using unicast communication in Heartbeat fixes the problem for example. Details see: [http://essayacademia.com/ essay on custom communication writings] http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=699#c22
+Here is one example: The e1000 driver that is included in kernels < 2.6.12 has a problem when a cable gets unplugged while broadcast packets are still being sent out on that interface. When using broadcast communication in Heartbeat on a crossover link, this fills up the transmit ring buffer on the adapter (the buffer is full after about 8 minutes after the cable got unplugged). Using unicast communication in Heartbeat fixes the problem for example. Details see: http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=699#c22
 Without testing you may not be aware of such problems and may face them when the cluster is in production and a failover would be necessary. So test your cluster carefully!
@@ Line 303: / Line 303: @@
 New OpenVZ kernel often include driver updates. This kernel for examples includes an update of the e1000 module: http://openvz.org/news/updates/kernel-022stab078.21
 To avoid to overlook problems with new components (such as a newer kernel), it is necessary to re-do the tests mentioned above. But as the cluster is already in production, a second cluster (test cluster) with the same hardware as the main cluster is needed. Use this test cluster to test updates of the kernel or main OS updates for the hardware node before putting them on the production cluster.
 I know this is not an easy task, as it is time-consuming and needs additional hardware only for testing. But when really business-critical applications are running on the cluster, it is very good to now that the cluster works fine also with new updates installed on the hardware node. In many cases a dedicated test cluster and the time efford for the testing of updates may cause too much costs. If you cannot do such test of updates, keep in mind that over time (when you must install security updates of the OS or the kernel) you have a cluster that you have not tested in this configuration.
-If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: [http://research-essay-writing-examples.tumblr.com/ research essays], [http://contrastessay.wikidot.com/ contrastessay], http://www.thomas-krenn.com/cluster.
+If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: http://www.thomas-krenn.com/cluster
 == How to do OpenVZ kernel updates when it contains a new DRBD version ==

@@ Line 307: / Line 307: @@
 I know this is not an easy task, as it is time-consuming and needs additional hardware only for testing. But when really business-critical applications are running on the cluster, it is very good to now that the cluster works fine also with new updates installed on the hardware node. In many cases a dedicated test cluster and the time efford for the testing of updates may cause too much costs. If you cannot do such test of updates, keep in mind that over time (when you must install security updates of the OS or the kernel) you have a cluster that you have not tested in this configuration.
-If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: [http://criticalessay.weebly.com/ censorious essays], [http://classsification-essay-writing.blinkweb.com/ categorization essay], http://www.thomas-krenn.com/cluster.
+If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: [http://research-essay-writing-examples.tumblr.com/ research essays], [http://contrastessay.wikidot.com/ contrastessay], http://www.thomas-krenn.com/cluster.
 == How to do OpenVZ kernel updates when it contains a new DRBD version ==

@@ Line 283: / Line 283: @@
 The installation of the cluster is finished at this point. Before putting the cluster in production it is very important to test the cluster. Because of all the possible different kinds of hardware that you may have, you may encounter problems when a failover is necessary. And as the cluster is about high availability, such problems must be found before the cluster is used for production.
-Here is one example: The e1000 driver that is included in kernels < 2.6.12 has a problem when a cable gets unplugged while broadcast packets are still being sent out on that interface. When using broadcast communication in Heartbeat on a crossover link, this fills up the transmit ring buffer on the adapter (the buffer is full after about 8 minutes after the cable got unplugged). Using unicast communication in Heartbeat fixes the problem for example. Details see: http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=699#c22
+Here is one example: The e1000 driver that is included in kernels < 2.6.12 has a problem when a cable gets unplugged while broadcast packets are still being sent out on that interface. When using broadcast communication in Heartbeat on a crossover link, this fills up the transmit ring buffer on the adapter (the buffer is full after about 8 minutes after the cable got unplugged). Using unicast communication in Heartbeat fixes the problem for example. Details see: [http://essayacademia.com/ essay on custom communication writings] http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=699#c22
 Without testing you may not be aware of such problems and may face them when the cluster is in production and a failover would be necessary. So test your cluster carefully!
@@ Line 303: / Line 303: @@
 New OpenVZ kernel often include driver updates. This kernel for examples includes an update of the e1000 module: http://openvz.org/news/updates/kernel-022stab078.21
 To avoid to overlook problems with new components (such as a newer kernel), it is necessary to re-do the tests mentioned above. But as the cluster is already in production, a second cluster (test cluster) with the same hardware as the main cluster is needed. Use this test cluster to test updates of the kernel or main OS updates for the hardware node before putting them on the production cluster.
 I know this is not an easy task, as it is time-consuming and needs additional hardware only for testing. But when really business-critical applications are running on the cluster, it is very good to now that the cluster works fine also with new updates installed on the hardware node. In many cases a dedicated test cluster and the time efford for the testing of updates may cause too much costs. If you cannot do such test of updates, keep in mind that over time (when you must install security updates of the OS or the kernel) you have a cluster that you have not tested in this configuration.
-If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: http://www.thomas-krenn.com/cluster
+If you need a tested cluster (also with tested kernel updates), you may take a look on this Virtuozzo cluster: [http://criticalessay.weebly.com/ censorious essays], [http://classsification-essay-writing.blinkweb.com/ categorization essay], http://www.thomas-krenn.com/cluster.
 == How to do OpenVZ kernel updates when it contains a new DRBD version ==

@@ Line 99: / Line 99: @@
 == Setting up DRBD ==
-On each of the two nodes create a partition that acts as underlying DRBD device. The partitions should have exactly the same size (I created a 10 GB partition hda3 using fdisk on each node for this example). Note that it might be necessary to reboot the machines to re-read the partition table.
+'''On each of the two nodes create a partition that acts as underlying DRBD device.''' The partitions should have exactly the same size (I created a 10 GB partition hda3 using fdisk on each node for this example). Note that it might be necessary to reboot the machines to re-read the partition table.
 Install the rpm of the DRBD userspace tools on both nodes:

@@ Line 85: / Line 85: @@
 ! other install options
 | no firewall, no SELinux
-| no firewall, no SELinux
+| no firewall, no SELinuxt vim-enhanced
 |}

← Older revision		Revision as of 22:31, 15 December 2009
Line 7:		Line 7:
	Some other additional information can be found in the documentation of the Thomas-Krenn.AG cluster (The author of this howto is working in the cluster development there, that is the reason why he was able to write this howto :-). The full documentation with interesting illustrations is currently only [http://www.thomas-krenn.com/en/service-support/knowledge-center/cluster/documentation.html available in German]:		Some other additional information can be found in the documentation of the Thomas-Krenn.AG cluster (The author of this howto is working in the cluster development there, that is the reason why he was able to write this howto :-). The full documentation with interesting illustrations is currently only [http://www.thomas-krenn.com/en/service-support/knowledge-center/cluster/documentation.html available in German]:

−	An excellent presentation and overview by Werner Fischer is available here http://www.profoss.eu/index.php/main/content/download/355/3864/file/werner-fischer.pdf.	+	An excellent presentation and overview by Werner Fischer, Thomas-Krenn.AG is available here http://www.profoss.eu/index.php/main/content/download/355/3864/file/werner-fischer.pdf.