We are currently an EV1/Planet customer with several highly and several mildly active servers on your network.
Our servers support an array of active domains (50+ips) with different configurations, most of which are AMP intensive.

A previous post mentions that any servers in your datacenters can be load balanced using what i assume are shared load balancers, and that a dedicated load balancing option is available. I would like to learn more about the possibility of either

a) using the "shared" load balancing to distribute loads between the active and inactive servers to ensure both performance and failover
b) converting our current flat architecture into a fully fledged cluster

I am trying to understand what is possible using the existing resources with the least amount of downtime / cost / and hardware / configuration changes.

some questions...

Networking
- Will it present a physical networking problem for you to cluster between our existing servers, seeing as they are on disparate class A's and probably in different datacenters?
- Will we have to change all of our domain IPs to the newly issued Virtual IPs or
- Can we preserve the existing IP's by simply pointing them at the LBs?
- If we are forced to change IPs - are SE rankings be affected by this? Has anyone had experience with this aspect of a migration?

MySQL Clustering
- if we go with a clustering solution, from what I understand MySQL cluster nodes run as a RAM ONLY databases. Assuming we are running less than 1G db(s) and applications simultaneously on each node, would we have enough RAM for both MySQL and the normal order of business (apache, php, etc) on nodes having 1G RAM total?
- will all of the databases need to be recreated usign the NDB type or is there any way to plug an existing MyIsam DB into a cluster?

I apologize ahead of time for my lack of understanding on the subject, and hope that my ignorance does not offend any h/a ultramonkey types.

Any feedback highly appreciated.

Hello inn3rflow!

Let me see if I can address some, if not all of these questions and concerns. First, we do not have a shared load balanced setup today. I do know that Product Management is in the works on this and we should be seeing this some time in the future.

With that said, we do offer dedicated load balancers by Foundry - the ServerIron XL and 4G. With that said, let me see if I can answer some of these questions you have:

Networking
- Will it present a physical networking problem for you to cluster between our existing servers, seeing as they are on disparate class A's and probably in different datacenters?

Yes, this is an issue. If you are on disparate class A's, then that more than likely means you are not running your servers in one of our private rack environments. The private rack does not just consolidate the servers into one physical location in the DC, it also does the pooled IP addressing so that you have one range of IP's for all of your servers. So, in order for us to setup a load balancer for you, you would need to "migrate" your existing servers to a private rack environment where we would have a load balancer setup for those servers you wish to load balance.

- Will we have to change all of our domain IPs to the newly issued Virtual IPs or

In this case, yes you will. The IP's you are running on are part of our General Population server "farm" and hence, moving from that area to a private rack will require you to switch the IP's of your domains.

- Can we preserve the existing IP's by simply pointing them at the LBs?

No, you cannot preserve the existing IP's by simply pointing them at the LB's. Note what I stated above - moving from the General Population server base to a private rack means that we allocate you a range of IP's that then be dedicated to all of the servers you place within that private rack and you can assign those IP's to those servers how ever you wish.

- If we are forced to change IPs - are SE rankings be affected by this? Has anyone had experience with this aspect of a migration?

Personally, I cannot tell you if this will affect your SE rankings. But I will get some one to take a look at this and let me know if and how this would affect your SE rankings.

MySQL Clustering
- if we go with a clustering solution, from what I understand MySQL cluster nodes run as a RAM ONLY databases. Assuming we are running less than 1G db(s) and applications simultaneously on each node, would we have enough RAM for both MySQL and the normal order of business (apache, php, etc) on nodes having 1G RAM total?

I'm not a 100% sure, so I'm going to consult with our Professional Services team to find out for you. But, if I had to take an educated guess from my past experience, I'd say that 1GB RAM will not be sufficient and you will need to do some upgrading to accommodate for the additional business you run on that server. From what I've seen in the past, most customers run the MySQL cluster nodes independent of their normal order of business so that there are no issues with running their databases as efficiently as possible. Can you run them all together? Sure, but the concern is how efficient will it be and can you take the performance hits? Again, let me double check on this and I will let you know for sure.

- will all of the databases need to be recreated usign the NDB type or is there any way to plug an existing MyIsam DB into a cluster?

Again, I'm not 100% sure and will consult with our Professional Services team, but, from what I understand, all of your MyIsam DB's will need to be converted to NDB after your cluster has been setup. At least, this is my understanding. Let me double check on this and verify what I'm saying is correct.

In the mean time, if you have any other questions, please feel free to let me know!

Thanks for posting up!
PD2

> a) using the "shared" load balancing to distribute loads between the active and inactive servers to ensure both performance and failover

In the past, we had a shared load balancing option, though even in that case they were special pairs of servers deployed behind a load balancer and were not set up to balance between servers in different parts of the network, or on different networks.

This solution is no longer being sold, though we are investigating some other options.

NDB does run from RAM on all of the MySQL nodes. The problem with NDB is that it does not support everything that MyISAM supports, which may or may not cause issues for you. I would recommend you stay away from having MySQL on the same servers as your web servers. We run a dedicated MySQL server using the regular MyISAM, HEAP, and InnoDB tables and our web servers access it over the private switch in our private rack.

To answer the second part of your question, you can take a MyISAM table to NDB so long as the tables are not using anything that the NDB can't handle. A "alter table tablename engine=NDBCLUSTER" will convert it to the NDBCLUSTER type if there is no conflicting options. If there is a conflict, then it will cancel the conversion.

inn3rflow,

I checked with my Professional Services team and they were for the most part in agreement with all of my statements above. Here were their additional comments:

As far as the load balancing, the servers would all have to be on the same layer 2 network as the load balancer. If you plan on running the NDB nodes on boxes with other applications, which is somewhat of a bad idea, you will definitely need more RAM than that. Say if you have 1GB of clustered data, you will need 2 nodes (replicas of each other) that have at least 1GB RAM dedicated to the node. I would suggest at least 4GB of RAM each.

Also, BlueFusion was right. You will also have to keep in mind that any time you create a table, “engine=NDBCLUSTER” will have to be added.
________________________________________________________

Hope this helps! Feel free to post any other comments or concerns!

Best Regards,
PD2