Hi,
I'm looking for some recommendations. I need to have some sort of high availability for a set of php & mysql web sites, they must be hosted on 2 servers, in separate data centres and obviously on differrent IPs. I can't use a load balancer because that will introduce a single point of failure making the "distributed setup" useless. I was thinking some sort of drbd/glusterfs/mysql-master-master replication and figure out how to make the dns system responsible with the fail over. Am I going too far with this?
Thanks.
Karanbir Singh writes:
On 11/14/2011 02:41 PM, nux@li.nux.ro wrote:
I'm looking for some recommendations. I need to have some sort of high availability for a set of php & mysql web sites,
I know this was discussed briefly on irc - what solution did you go with ?
- KB
I haven't gone with any due to time problems (that also keep back libreoffice btw :< ) but will do as wolfy suggested and try a rsync+mysql replication. high availability will be done at dns level (i know, it's not ideal but it's cheap and it seems to sort of work in most cases).
-- Nux! www.nux.ro
On 11/14/2011 09:41 AM, nux@li.nux.ro wrote:
Hi,
I'm looking for some recommendations. I need to have some sort of high availability for a set of php & mysql web sites, they must be hosted on 2 servers, in separate data centres and obviously on differrent IPs. I can't use a load balancer because that will introduce a single point of failure making the "distributed setup" useless. I was thinking some sort of drbd/glusterfs/mysql-master-master replication and figure out how to make the dns system responsible with the fail over. Am I going too far with this?
Thanks.
WAN/Stretch clustering suffers most for network latency. If you need to keep the data in sync across both nodes, using DRBD will limit your hard drives, effectively, to the speed and latency of the link between your nodes at the different DCs. This is rarely usable.
Stop by #linux-cluster and/or #drbd, I know there are folks there from Linbit and Hestaxo who could help you, but you're going to be facing rather expensive technical challenges. :)
Dne 19.11.2011 03:35, Digimer napsal(a):
WAN/Stretch clustering suffers most for network latency. If you need to keep the data in sync across both nodes, using DRBD will limit your hard drives, effectively, to the speed and latency of the link between your nodes at the different DCs. This is rarely usable.
Stop by #linux-cluster and/or #drbd, I know there are folks there from Linbit and Hestaxo who could help you, but you're going to be facing rather expensive technical challenges. :)
DRDB over WAN is nonsense. There are many scenarios expensive/non-expensive, depends on data you want to distribute. Being you I would start with the simplest one. I can name a few: - buy netapp and create metrocluster with RRDNS - have your subnet routed into both datacenters and use virtual IPs - webapp might be somewhat static, so files might be easy to sync, as to DB data, start with master-slave replica and M/S swap, try to read data from multiple source, write to only the one - you are talking about two nodes, with your scenario only one will serve the data in time, it's not horizontal scaling, try to use both in time - have low ttl for DNS with RRDNS, add/remove records by nodes' status - don't forget about webapp side of topic, webapp must be prepared to save nonDB content - start with two nodes in one dataceter to test your horizontal scenario, you can than split it into two DC or easily add the third/fourth nodes in another DC - ....
DH
Digimer writes:
On 11/14/2011 09:41 AM, nux@li.nux.ro wrote:
Hi,
I'm looking for some recommendations. I need to have some sort of high availability for a set of php & mysql web sites, they must be hosted on 2 servers, in separate data centres and obviously on differrent IPs. I can't use a load balancer because that will introduce a single point of failure making the "distributed setup" useless. I was thinking some sort of drbd/glusterfs/mysql-master-master replication and figure out how to make the dns system responsible with the fail over. Am I going too far with this?
Thanks.
WAN/Stretch clustering suffers most for network latency. If you need to keep the data in sync across both nodes, using DRBD will limit your hard drives, effectively, to the speed and latency of the link between your nodes at the different DCs. This is rarely usable.
Stop by #linux-cluster and/or #drbd, I know there are folks there from Linbit and Hestaxo who could help you, but you're going to be facing rather expensive technical challenges. :)
Hello Digimer,
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
Thanks again.
-- Nux! www.nux.ro
On Sat, Nov 19, 2011 at 5:11 AM, nux@li.nux.ro wrote:
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
It can be hard to get a client to switch locations by changing a single IP as your DNS response because the application may cache much longer than the TTL, but most web browsers are very good at dealing with receiving multiple IP addresses where one or more servers in the list do not respond. That is, if you always give out 2 IP's but only one target responds, most browsers will do the right thing most of the time, and you can improve it by either running both sites live or making the inactive site do a redirect to a site-specific name for the active site. And if you are writing your own client for a service it is usually much easier to make the client smart enough to find a working server than to keep a lot of data perfectly synchronized globally.
Les Mikesell writes:
On Sat, Nov 19, 2011 at 5:11 AM, nux@li.nux.ro wrote:
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
It can be hard to get a client to switch locations by changing a single IP as your DNS response because the application may cache much longer than the TTL, but most web browsers are very good at dealing with receiving multiple IP addresses where one or more servers in the list do not respond. That is, if you always give out 2 IP's but only one target responds, most browsers will do the right thing most of the time, and you can improve it by either running both sites live or making the inactive site do a redirect to a site-specific name for the active site. And if you are writing your own client for a service it is usually much easier to make the client smart enough to find a working server than to keep a lot of data perfectly synchronized globally.
Les, indeed, the idea is to not only use the replica server just as a spare but also send traffic to it. Thanks for suggesting it.
-- Nux! www.nux.ro
Dne 19.11.2011 12:11, nux@li.nux.ro napsal(a):
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
Thanks again.
Think about session store too. DH
David Hrbáč writes:
Dne 19.11.2011 12:11, nux@li.nux.ro napsal(a):
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
Thanks again.
Think about session store too. DH
Good point! Cheers
-- Nux! www.nux.ro
David Hrbáč writes:
Dne 19.11.2011 12:11, nux@li.nux.ro napsal(a):
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
Thanks again.
Think about session store too.
If I'll ever get this done I must write about how I did it. :)
-- Nux! www.nux.ro
On Sat, Nov 19, 2011 at 11:12 AM, nux@li.nux.ro wrote:
Thank you, however I decided to go for a less exotic setup and use a more passive way of sync (probably rsync and mysql replication) and I'll do the high availability part from DNS (yes, I know there are issues with this solution as well).
Thanks again.
Think about session store too.
If I'll ever get this done I must write about how I did it. :)
If the site is big/busy enough, you should think in terms of multiple levels of server groups - that is, sets at the same location that might be behind a load balancer with the option to make sessions 'sticky' by always directing to the same target or where you can use the server's session-sharing mechanism and/or a common database, and sets at different locations that may need to operation under conditions that can't be strictly kept in sync. It is also useful to split parts that are mostly static, change slowly, and don't need sessions (images, downloads, etc.) into separate DNS names that can be managed differently.
-
David Hrbáč -
Digimer -
Karanbir Singh -
Les Mikesell -
nux＠li.nux.ro