Pre-Sales Regarding Amazon EC2 Deployment

Hi Folks,

How does this deployment scenario for EC2 look to you? I have some technical questions below.

Load Balancer 1
ports 80 and 2443
Load Balancer Cust 1
port 443 forwards to 8443
Load Balancer Cust 2, etc
port 443 forwards to 8443
…(multi-master MySQL)…

Above describes the following deployement:

  • Two Interworx CP servers configured for web hosting only
  • Multiple load balancers handle:
    (1) port 80 and Nodeworx/Siteworx
    (2) An Elastic Load Balancer for each SSL domain (using load balancer port redirects)
  • DNS is handled by both Interworx instances, using FQDN independent of the load balancers

Questions I have:

  • AWS RDS offloads all siteworx/reseller database load
  • Is it possible to move the iworx internal database load to the AWS RDS instance?
  • what happens to my license in the event an instance dies and new one is loaded with a new IP address (amazon ec2 is a nat’d environment)? How long do I have to register the license at a new IP?

Thanks for any feedback.

We’re still looking into/playing around with the potential of EC2 and the InterWorx Control Panel. We aren’t anywhere near understanding it all, but I’ll try to answer your questions as best I can.

1.) Yes, you can do this. InterWorx allows you to specify a remote MySQL server, so you would just set this server to be the RDS.

2.) A number of connection strings would need to be updated. They include:

  • /home/interworx/iworx.ini (under [iworx], dsn)
  • /etc/proftpd.conf
  • /var/vpopmail/etc/vpopmail.mysql
So this may be possible, but it would not be supported and it has never been tested. If you are able to get this to work, or have any further questions please let us know.

3.) You can use the licensing API to reassign your license to the new IP address.

To expound on #3 - you’d have a 6-hour window to change it, and a 24-hour window before there are any real consequences other than a warning message. The license checks with the server every so often, and you have to miss several in a row before the system would lock you out.

Even once locked out, you can still use the license API to update it, but I’m assuming there would be some sort of failover script, and you’d just automate it.

Thanks guys. This seems very workable. I’ll test this during the week and post if I have any problems.

Hi Folks,

I have succeeded in moving the iworx databases and making connections from two EC2 instances connecting to a third MySQL instance. Am able to create a siteworx package with iworx instance 1 and see it immediately on iworx instance 2, but when I click on the accounts tab, I get error in nodeworx: nativecode=1054 ** Unknown column ‘spm.package_id’ in ‘on clause’

MySQL server is running 5.1.37 on Unbuntu 9.10

These errors seem to be common when hosting a v4.0.x mysql database on a MySQL 5 database server- what does the built-in iworx mysql-server use- 4.0.X or 4.1.X?

Yeah, that’d do it…we’re using 4.0, primarily due to licensing changes that MySQL made between 4.0.21 and 4.0.23.

OK- running on a Hardy Mysql 4.1 server with some finessing (fix privileges, run OLD_PASSWORDS command) gets me going. Looks like the topology will have to include a 4.1 multi-master setup for the internal interworx databases.

Hi Folks,

I’m not comfortable with the number of instances I would have to run to have a reliable fault-tolerant multi-master setup using MySQL 4.1 on Amazon. Seems the issue here is just syntax of join statements and how they changed in MySQL 5.X. Are those joins part of the encoded proprietary code? If not could you point me where I would edit them? If they are proprietary, is upgrading the iworx internals MySQL to version 5 on the horizon?

Here’s a nice summary of the syntax issue from the OSCommerce forums that I based by assumption on regarding the possible syntax problem:

They are part of the encoded bits, yes.

Unfortunately, due to the licensing issues I mentioned above, we’re unable to move to newer versions of MySQL, and the prospect of migrating 1000s of servers to another vendor’s DB is…daunting. :slight_smile:

However - we can still help make this easier for you. I’m logging this as a bug, I’ll take a look at how difficult it’ll be to change.


Ugh…so, that’s not the problem. At least, that’s not ALL of the problem. The query you mentioned doesn’t mix the comma and JOIN styles - we’re actually pretty good at not doing that - but you’re obviously still having the issue.

The only oddity I could find is that there was one table that is joined out of order - ie, it was used in a join to a third table before being joined to the first itself. It’s possible that they changed how the execution planner/processor does things - instead of optimizing the whole thing, it might just do it linearly, which would cause problems.

That seems unlikely, though, so there’s more to look in to.

[QUOTE=IWorx-Tim-Pgh;17203] the prospect of migrating 1000s of servers to another vendor’s DB is…daunting. :slight_smile:

Yes- I can imagine that would be a pretty complicated upgrade. Hope you can come up with another workaround.