[Novalug] Software-based load balancing

[Dave Greene]

Metadata storage on the same system or a different system is  more architectural design and operational maintenance. You have chosen to put it on the same system for various logistical reasons.
It's not a requirement and there are various models of doing it. You can store it still off the server on different systems though a lot of it depends on actual performance models and what is going on.
For this particular application we have the data just about all data stored on different servers.  Some data is stored locally, but it's very minimal. 
There is always a trade off, and since our LAN performance is high our systems are spread out more. Patches are also a logistical problem and we will bring down an entire data center in order to deploy updates. Basically we will route all traffic away from a data center, deploy all updates to every component involved that needs updating, then bring that data center up after everything has been certified and bring the next one down.

It's actually an activity that starts Friday night and ends Sunday night a couple of weekends a month.


-----Original Message-----
From: Peter Larsen [mailto:plarsen at famlarsen.homelinux.com] 
Sent: Friday, March 09, 2012 9:44 AM
To: Omniplex
Cc: novalug at calypso.tux.org
Subject: Re: [Novalug] Software-based load balancing

On Thu, 2012-03-08 at 00:03 -0500, Omniplex wrote: 
> Phone sucks for inline responses.
> I think we are probably in agreement mostly then based on your statements. However our DBs are in a different zone behind the secure zone and we have additional firewalls between all the zones. The data is also not all stored in a database directly accessible from the secure zone servers. Sometimes they will need to make a web services call to something else or a connection to a different set of databases.

Let me be a bit more clear when we talk databases. A database is not just a database. It has a purpose. With quite a few technologies, like rules, SOA, Portal etc. etc. we have METADATA storages. On the other hand, we have operational data else-where. The two don't mix. The reason is, that metadata is so tightly integrated into the server, ie my business rules server metadata has to be in sync with the exact version/patch level I have on the business rules server. Also, as a developer I will NEVER EVER access the metadata server directly. I will, however access the operational data directly. 

For this reason, the DB that goes with the business rules server would be located DIRECTLY ON THE HOST that does the business rules. One get patched means the other gets patched. It also means, that for clustering reasons I do replication between the nodes (with Java we have a lot of technologies to do this easily through JCRs like ModeShape). For this reason, I don't see the backend storage for my business rules to be on part with my operational data and hence, not a separate tier.

Operational data is a different story. Many times it's not owned by "my"
project and I share it with other projects. So it automatically because a tier in itself, fully isolated behind separate walls etc. Even if I use federated datamodels I have to take into account that the data is not "local" and I may need to look at local caching for optimization and a lot of other issues. So my 3 tier model easily becomes more tiers as I add external operational data access. 

> 
> Our presentation zone runs about 45 servers for this example and a similar number of secure zone servers. Separation for both performance and security is a requirement.

Ahh yes. Again, scaling out groups piece-meal is necessary as you scale out. It allows you to trim a server to specific services only, less overhead and easier to optimize and patch. So if your app has 100s of APIs you may have group with a small subset of those APIs implemented, and again the LB's responsibility is to know which groups implement what APIs.

Systems like Amazon and Facebook have to do this - you cannot implement all features on a single server and expect easy scaleout and fast responding systems.


--
Best Regards
  Peter Larsen

Wise words of the day:
BTW: I have a better name for the software .... Microsoft Internet Exploder.
	-- George Bonser