Gallery2 in a load balanced or clustered environment?

Gallery2 in a load balanced or clustered environment

Has anyone used Gallery2 in a load balanced or clustered environment? Have tips for the best approach to improving availability?

We have our two identical machines (SunFire 4600) ready for configuration.
Gallery2 is running well on one of them.
We'll be working on the second one this week. (We announce Snapshot in print July 15)

I. Web app tier

We can load balance through "round robin DNS" (some requests go to Gallery2-Box1; some requests go to Gallery2-Box2).

We'd have the same Gallery2 install / configuration on both boxes.
This evens the traffic at the web and database tiers.
We'd use replication (master / master) to keep the two dbs in sync.
There'd be the issue of persisting sessions across both Boxes.

II. Database tier

We could cluster the database.

A single instance of Gallery2 could point to a clustered mysql db.
This doesn't balance the web traffic load, but handles the db load better and provides needed redundance.

With hope, this second possibility is straightforward.

I appreciate any insights and tips.

(I've found precious little re replication in the forums; I'll certainly follow up with our solution once it's in place and working.)

Gallery version 2.2.1
PHP version 5.2.1 apache2handler
Webserver Apache/2.0.55 (Unix) DAV/2 PHP/5.2.1
Database mysqlt 5.0.27-log
Toolkits SquareThumb, ImageMagick
Operating system SunOS spardehg02 5.10 Generic_118855-19 i86pc

Thank you.

@All tiers to same db:
The db is really the bottleneck, as near as I can figure. Currently, when we have performance issues, it's when the db's under heavy load. I fear if I had two installs pointing to the same db, it would lighten load on apache2 and each of the boxes, but the db itself would still be at least as taxed. (like it is right now ...)

@alternatives:
perhaps I should run Box2 just as the db server. I can have a replica on Box1 (where Gallery2 runs) for backup purposes, but the primary db server would be Box2 (so I can apply more resources to mysql)

@sessions:
we've mucked around in there already, IIRC - that's how we get our j2ee / oracle user sessions to "become" gallery2 user sessions. so, perhaps we should look there, too.

"Alternatives" seems the best alternative for this week: getting the dedicated mysql host and beefing up allotted resources should be helpful ... with hope.

And what about memory_limit php.ini - does bumping that help, in general (we're at 128MB)?

again, thanks -

We have Multi Master Replication for mysql working well. Gallery2 is successfully running on two separate physical boxes.
The two databases are in sync in close enough to "real time." The Thumbnails and all images, however, are out of sync.

We can cron an rsync job between the image upload dir on the two boxes every minute or so. Is there a better way to handle this?

Valiant said:

I'll see if we can mount one g2data folder on both hosts.

I'll continue searching the forums; I appreciate any input.

Hello -

We're using database locking.

We're still seeing collisions in g2_CacheMap and g2_Entities that're breaking our Multi Master Replication.

So, we can't properly load balance two machine running Gallery2.

Any more info I can provide to make this more clear? Anyone have thoughts as to cause and possible solutions?

Gallery version = 2.2.1 core 1.2.0.1
PHP version = 5.2.1 apache2handler
Webserver = Apache/2.0.55 (Unix) DAV/2 PHP/5.2.1
Database = mysqlt 5.0.27-log, lock.system=flock
Toolkits = ImageMagick, SquareThumb
Acceleration = full/900, full/900
Operating system = SunOS spardehg02 5.10 Generic_118855-19 i86pc
Default theme = SnapshotV1
gettext = disabled
Locale = en_US
Browser = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Rows in GalleryAccessMap table = 20082
Rows in GalleryAccessSubscriberMap table = 3858
Rows in GalleryUser table = 9700
Rows in GalleryItem table = 3858
Rows in GalleryAlbumItem table = 38
Rows in GalleryCacheMap table = 80379

Thanks, Valiant -

@CacheMap - My presumption, then, is collisions here shouldn't preclude this set up from working. True statement?

@Entity collisions, what's the best way to operate (select, update, delete) on the same g2_Lock table across all db servers? Is this changing DB Locking preference code?

Currently, each db lock would be against its own g2_Lock table.

Per my notes above, the way we think it's CURRENTLY best for us to be set up (from handling load perspective) is two complete Gallery implementations on two physically distinct servers with clustered mysql dbs (Master / Master Replication). Web requests are load balanced between them.

Until our much beefier hardware comes in, this is what we have to work with.

again, many thanks -

1. Are you taking advantage of Solaris 10 zones?

If not, you should! Consider creating 3 non-root zones per server, all nodes in a MySQL 5 Cluster. You would have a six node cluster across both machines. Create a 4th non-root zone for apache on each server and use resource pools to manage memory/cpu across all the zones. Zones are lightweight and take advantage of the multi-threaded, multi-core cpus in your server.

2. Buy a hardware load balancer. If price is an issue, Coyote Point makes several models under $5k. There's numerous articles online about the the disadvantages of round-robin dns. A hardware load-balancer intelligently assigns requests based on several admin-chosen algorithms, and most provide client session migration/draining. There's great software solutions, but the excellent ones are only for linux, and you'd need to buy another server.

After this year, my next project involves global-geographically based load balancing, which will utilize Solaris 10 heavily. We already do load-balancing across dozens of zones on multiple machines at work.

Has anyone worked anymore with load balancing?

I am trying to do something somewhat similar in this post: http://gallery.menalto.com/node/90029