Re: [mmm-devel] Using MMM on AWS (Amazon Cloud) with Virtual IP

[Arjen Lentz]

Hi

"xbeta" <s.x...@sta.samsung.com> wrote:

> I have the following AWS instances created and dedicated for MySQL MMM
> setup, but I'm failing to understand how these Virtual IPs work.
> I created a monitor/master1/master2 in the same region (west), and
> intended to keep a slave which is a back-up instance sits somewhere in
> another region. (Because everyone knows AWS region sometimes can go
> offline for hours).
>
> I understand the Virtual IPs are distributed by MMM as it was stated
> here:
> http://mysql-mmm.org/mmm2:guide
>
> But MMM is not a DHCP or a virtual ARP, so how does it assigned
> Virtual IP across different AWS regions? As far as I know, if I
> created an instance in Region-1 in AWS, it won't be visible to any
> other region in AWS unless I assigned a public IP to it (which is more
> costly)
>
> Can someone help me understand this?

In Amazon you'd need to use the "Elastic IP" to get a virtual IP address for MMM purposes.
The downside is that traffic no the Elastic IP address is charged as external rates, so that means that all the internal traffic between your webservers and your database servers would get charged as external. Makes it rather costly.

Whether you can do an Elastic IP across regions I do not know, as the above issue is already so annoying that we just tend to not deploy on AWS.


Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Australian peace of mind for your MySQL infrastructure.

Follow us at http://openquery.com/blog/ & http://twitter.com/openquery

[Marcus Bointon]

On 17 Sep 2012, at 05:56, Arjen Lentz <ar...@openquery.com> wrote:

> In Amazon you'd need to use the "Elastic IP" to get a virtual IP address for MMM purposes.
> The downside is that traffic no the Elastic IP address is charged as external rates, so that means that all the internal traffic between your webservers and your database servers would get charged as external. Makes it rather costly.

If you can use names instead of IPs, you can use EC2's generated hostnames. The trick with these is that on the outside these resolve to public IPs, but on the inside they resolve to EC2 internal IPs, so they will stay working if instances get new IPs. This fixes a lot of things that would otherwise require fixed (i.e. elastic) IPs.

Marcus

[Mike!]

That doesn't work. Mmm uses ip addresses which are linked to roles. If a role moves from one node to another, mmm agent removes the ip from one host and assignes it to another. Usually the nodes tend to be on the same network.

I think your problem is particulalry difficult to solve. The only solution I can think of is putting all your db and mmm nodes, as well as db clients in a vpn. That way you have full control of the ip addresses they usee, and you can just use any private range you like.

Mike

--
You received this message because you are subscribed to the Google Groups "MySQL Multi Master Manager Development" group.
To post to this group, send email to mmm-...@googlegroups.com.
To unsubscribe from this group, send email to mmm-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mmm-devel?hl=en.

[Arjen Lentz]

We worked out a few years ago how to implement this, just didn't need to use it in the end.

You can use hostname based as Marcus suggested, but it would require code changes/additions to MMM.
You can use /etc/hosts, and configure the local resolver library (OS wide setting) to check for mtime change on that file to reload. Then the MMM agent can modify the hosts file when there's a master switch, and you get failover in the same instant way the IP address shift works.

[Mike!]

How would this work for your mysql clients?

Mike

[Arjen Lentz]

Hi Mike

> How would this work for your mysql clients?

You'd need to have an extra hook in MMM control to also have an agent on each client machine that does the same as the regular agent in terms of adjusting /etc/hosts, but not worry about a local mysql server. Essentially extend the agent with a role that does less than the normal one.

However, as I mentioned, with Amazon Elastic IP the overall solution becomes very expensive, and in many cases the cost of running a DB-heavy infrastructure on Amazon is costly. The reason is that you pay for RAM and CPU time, and with MySQL a large chunk of RAM is globally allocated (InnoDB buffer pool, etc) and if you have a fairly busy site both the rest of the RAM (dealing with connections) as well as CPU time (queries) are highly utilised.
Amazon works out economically if you have medium or relatively low RAM/CPU use, otherwise it becomes horrendously costly.

You need to have some idea about the load profile of your app, understand how MySQL works (like above, but there's more to it), and then make projections of Amazon pricing versus another service such as Linode or another "cloud".
You may find that the Amazon option turns out vastly more expensive once you take your actual use into account.
Add to that the effort of adapting MMM for this purpose, and it just doesn't make sense any more.

Regards,
Arjen.