high availability ideas
 

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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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. :)

--
Digimer
E-Mail: digimer@alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"omg my singularity battery is dead again.
stupid hawking radiation." - epitron
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

high availability ideas
 

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos