Tag Info

Hot answers tagged

11

I am actually working on something very similar to what you described (a fail-over cluster on EC2), and after trying out Heartbeat, settled on Corosync as my messaging layer. Corosync will run on multiple servers and it does support Unicast (UDPU) as of version 1.3.0 (from Nov, 2010). I have setup and tested Corosync on Amazon's EC2 cloud (using Amazon's ...


9

I prefer to use keepalived for high-availability. I find it simpler to setup (one daemon and config) than heartbeat and company. The only drawback I run into, is that keepalived doesn't have a unicast option by default, and only uses VRRP for communication (The author of HAProxy has written a unicast patch for keepalived however)


8

Sorry, but the part about Pacemaker is not true. The Pacemaker regression and release tests make extensive use of automation. To configure without an active cluster, prefix all commands with CIB_file=/var/lib/heartbeat/crm/cib.xml or set it in your environment. Just be sure you remove the .sig file before starting the cluster. For clusters without quorum, ...


5

You can use RFC1918 IP addresses to test your configuration. Depending on the load balancing setup, the use of RFC1918 addresses may continue in some form into production.


3

you can enter the host ip in there. So on one server you'll have: bindnetaddr: 10.244.19.47 And on the other: bindnetaddr: 10.196.55.173 I had exactly the same setup with my two servers in EC2 and it worked well.


3

In the open source world, there's RedHat Cluster Suite. It's been several years since I've implemented RHCS so I don't have many relevant things to say about it today. Commercially, there is Veritas Cluster Server. No experience with it. A much simpler and open source HA tool is UCARP. UCARP doesn't provide nearly the same kind of "infrastructure" that ...


2

You do need to run them on the DB hosts as well as they are required to manage the resources (which are the database instances in your case). I assume that you could also create "remote resources" and remotely manage them but I'd say it is rather inefficient.


2

I think the easiest way out is to have 2 fail-over IPs. One for nginx and the other for pgpool + haproxy pair. That way it will work the way you intend it to. nginx can be configured to run from first machine and pgpool + haproxy pair from the second one.


2

I haven't seen how 6.1 changes things, I've only done it with 6.0, but this is what worked for me: Install the following patterns: Scalable File Systems Resilient Storage High Availability On each node, start the ricci service (service start ricci), entering a password when prompted Start the luci service (service start luci) on one node Go to port :8084 ...


2

I am late to reply to your question, but here goes: Yes heartbeat is deprecated. No this is not a distro specific problem There are a lot of benefits to using Corosync instead of heartbeat, the first and foremost is point number 1 above. Still, I will list as many as I know of here. Comparison of features: First off the only benefit(IMO) of using ...


2

Eureka! Both of us forgot a very very important log file, it's... /var/log/mysqld.log: socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Atomicorp [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000082' at position 58569, relay log './mysqld-relay-bin.000002' position: 58715 [Note] Slave I/O ...


1

By default, Corosync uses IP multicast to communicate between nodes: mcastaddr: 226.94.1.1 mcastport: 5405 Either configure your firewall to allow multicast traffic: # iptables -A INPUT -p igmp -j ACCEPT # iptables -A INPUT -m addrtype --dst-type MULTICAST -j ACCEPT # iptables -A INPUT -p udp -m state --state NEW -m multiport --dports 5404,5405 -j ...


1

Yes, that's right. See also here, an example configuration published by Florian Haas (one of the Linux HA guys): https://github.com/fghaas/corosync/blob/master/conf/corosync.conf.example.udpu And please read the Corosync man page, it's all explained in there.


1

Answer of question one bindnetaddr is the network address we want pacemaker/corosync(?) to bind to. So if your servers have A.B.C.x and A.B.C.y as IP address, then in corosync configuration file, you have to assign bindnetaddr to A.B.C.0. Answer of question two mcastaddr is the IP address to use for multicasting and mcastport is the port to use for cluster ...


1

This means: Monitor (i.e. check its status) the lsb service WowzaMediaServer every 30 seconds and timeout after 60 seconds. http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html/Clusters_from_Scratch/_adding_a_resource.html


1

The setting that is missing is the preferred node. You can first add the resource, and configure the preferred node to run it afterwards. It is recommended to assign a weight below the stickiness of the resource to avoid unwanted downtime in the case of failover. Check the pacemaker docs for a complete example.


1

Veritas Cluster is great (compared to Linux-Heartbeat, AIX-hacmp, HP-Serviceguard and Sun cluster), but it costs lots of money. The last time I did look at it its price was based on cpu-cores of the cluster. Current Vendor ist Symantec...


1

So now the script works when the system is already up but not during boot. Is there perhaps a third version of the corosync script? Is the version in /etc/rc2.d/ linked to the one in /etc/init.d/ or is it different? Incidentally, we have got this far without even considering your cluster setup. If this is part of a cluster, there may be clues in the log ...


1

If you are already using EC2, why not use Elastic Load Balancing ? It will let you achieve application level availability without having to configure failover yourself.


1

There is Oracle Clusterware for Oracle Unbreakable Linux, though I've not used it.


1

From the mailing list (that solved my problem), courtesy of Dan Friscu: "You're not supposed to use the same bindnetaddr in both places, it's relevant only at node level for UDPU (your use case). On the node where you have the 144.* address, use that as bindnetaddr." Hope that this is useful to someone.


1

I have do similar configuration to make sure the virtual IP to live along with Mysql master server. For your case, I think the steps should be: Add a primitive for two JBOSS intances (as your shareIP or MySQL servers) Add colocation configure for JBOSS primitive to live along with MySQL Master as example below: colocation mysql_co_jboss inf: jboss ...


1

With the two machines in different datcenters? You can't. This scenario assumes that both machines in the cluster are on the same subnet; the VIP is also in that subnet. To do what I think you want to do, you would need an anycast IP address. Then you'd still have to run your own AS so you could add and withdraw routes as the machines go online and offline. ...


1

You don't have to use multicast on corosync. You may use unicast to do your job. This can be done by using something like this in /etc/corosync/corosync.conf for a two-member cluster: compatibility: whitetank totem { version: 2 secauth: off interface { member { memberaddr: 10.23.55.201 ...


1

Same issue after upgrading i386 servers from 2.6.32 kernel and 1.25 ipvadm to 3.2.0 kernel and 1.26 ipvadm, while ipvsadm shows oly one /proc/net/ip_vs shows all real servers. On a newly installed amd64 all is working fine. To solve the issue i applied the patch posted here http://archive.linuxvirtualserver.org/html/lvs-users/2011-08/msg00033.html and ...


1

If you use multicast you can quickly and easily add new nodes to the cluster. Because of this I suspect that the developers may have never saw a need to allow dynamically adding nodes via UDP unicast. At least no "clean" way exist that I myself am aware of. However, you should be able to reload Corosync and apply the newly edited config files without ...


1

If I understand correctly what you need, you can do this by putting location constraints: pcs constraint location WanCluster101 prefers 11sch=10 pcs constraint location WanCluster101 prefers 10sch=5 What I did in the past was to put the constraint for both IPs, both ways. So that when one node goes down, the other takes both IPs, no matter which of them ...


1

1: before test your cluster connectivity, you need to configure you stonith device, the stonith is very important in cluster, for resolve the split-brain situation 2: for the less important question, you can try to use location constrains you can start from something like this: location mycol dummy1 \ rule $id="myrule" -inf: defined dummy2 and ...


1

This happen, because, you don't have the cluster fencing configured(stonith), now your cluster is in split-brain Now you have a cluster with two DC and every node are trying to start the resource


1

You have exchanged the values ​​of the options, you must use: crypto_cipher: aes256 crypto_hash: sha1 instead of crypto_cipher: sha1 crypto_hash: aes256



Only top voted, non community-wiki answers of a minimum length are eligible