LampCluster Application

[BeckyHester]

This thread is dedicated to questions and comments related to the LampCluster - Scalable Lamp Cluster sample application.
The data sheet for the LampCluster application can be found at:
AppLogic 2.4.x: http://doc.3tera.net/AppLogic24/RefAppLampCluster.html
AppLogic 2.7.x: http://doc.3tera.net/AppLogic27/RefAppLampCluster.html (page will be published concurrently with 2.7 release)

Please post any questions and/or comments here.

[GridNote]

Broken Link

http://doc.3tera.net/AppLogic2/RefAppsLampCluster.html

[PeterNic]

GridNote, thanks! The broken link is fixed.

[jonesy]

The documentation for this application says to assign a "web_ip", which I imagine is what our DNS servers will point to. This seems pretty intuitive. However, I'm unclear as to the distinction between "net_ip" and "gateway", and I'm supposed to assign *both* apparently.

gateway seems intuitive enough. The IP is right on the dashboard. It needs to be routable, etc. However, I guess I'm unclear as to what net_ip is. Conceptually, it would seem to be the internal nic on a virtual gateway router, and then the 'gateway' ip would be the external nic. However, I don't have a pool of non-routable IP addresses on my dashboard, and I don't know what IP addressing scheme will be used by the internal network (the appliances) to talk to each other. On the apps I've done thus far, the "NET" device has had its internal network IP autoassigned, and I've just had to supply a gateway address.

How do I populate the value for "net_ip" so I can provision this app?
Thanks.

[PeterNic]

Brian,

The LampCluster application requires two public, routable IP addresses: the web_ip and the net_ip. The web_ip is the "service point" where users will point their browsers to use the app. The net_ip is an IP address that the application will use to reach services that it may use that are outside of the app; it is needed only if your app initiates outgoing service requests (e.g., to google, pool.ntp.org, S3, etc.).

If you open the editor and see the property redirections, you will see that in_web's ip_addr property is redirected to the web_ip property of the application; net's ip_addr property is redirected to the net_ip property of the application. (Maybe we need a feature to show the reverse mapping, like Excel highlights the cells used in a formula when you click on the formula.)

The web_ip and the net_ip *must* be different.

Regards,
-- Peter

[avantassel]

Hi,

I need DOM enabled in the PHP lamp cluster, seems the default has --disable-dom set in the configure.

Where is the source that this was installed from? I'm guessing I need to download it and run configure again. I was hoping there was a less painful way since we have live sites running.

any ideas? Thanks,

Andrew

[Jsmart]

I installed php in this appliance the old fashion way

"yum -y install php"

frankly, this is the way I installed all of the packages in the srvX and dbase appliances so that they would be as close to a standard install as possible.

You should be able to download the package and reinstall it with any options you need; the base appliance should have all the build tools and libs.

--Jessie

[avantassel]

I'm all about the old fashion way but the problem is I have a live website running and can't really bring it down to reinstall PHP.

So I will have to reinstall PHP on each server, srv1-srv4. How can I do this without affecting traffic? Is there a way to have say, srv4 up and running but to appear to the load balancer that it is down or to tell the HLB to not send traffic to it?

[PeterNic]

It would be better not to do this on a live site (esp. if you need to back out the changes), but if you must, you can do it.

You can make any of the web servers disappear from the HLB pool by simply "down"-ing the network interface that is its "in" terminal. ("ping in" will tell you the IP address, "ifconfig" will show you which interface it is to do "ifdown" on.).

Once upgraded, a 'comp restart' from the grid shell will reboot the server and bring it back into operation -- it takes HLB up to a minute to decide to use the server again, so you may want to wait until traffic is being forwarded to the server prior to taking down another server for upgrade.

Finally, it may make sense to leave one of the servers (e.g., srv1 or srv4) not upgraded for a week or so (and either keep it downed or turned off and marked as standby), so that if you find a problem with the upgraded PHP, you will have an easy way to keep the site running.

Let me know if this helps.

Regards,
-- Peter

[avantassel]

I went ahead and tried 'yum -y install php' on one of the servers, this seemed to upgrade php and php -i now shows that dom is enabled as shared, however this did not seem to update the libphp5.so which is used by apache (httpd) so phpinfo() still shows dom being disabled. any ideas how to update this? Do i need to rebuild apache and php to get this to work?