Normally I would not jump in with the first answer because I'm not a hardware or networking guy. I would wait for someone at iAnywhere to answer. And normally, they would (where "normally" means "on the NNTP forums").

However, Dave Neudoerffer said this: "we have asked our staff to try to allow time for the community itself to provide the answer, rather than jumping right in with the first answer".

So... I'm going to "game the system" by jumping in first ( where "game the system" means "cheat" :)...

You should try to eliminate all single-points-of-failure. That means physically separate computer hardware for all three servers... nothing shared. That includes physically separate UPS's. That means physically separate network hardware for all three connection paths: arbiter to primary, arbiter to secondary, primary to secondary; separate NICs (6 total?), separate cabling, separate ... ( this is where the "not being a network guy" really kicks in, I don't even know how to spell "fiber" :)

Plus, two physically separate locations for primary and secondary. How "separate" depends on your budget but certainly not "separate slots in the same rack". Since you said "banking" in a sentence, separate buildings or even separate postal codes may be justified. Think fire, flood, windstorm, "civilian unrest".

Here's a major point: Backup is a separate issue from high availability. The backup destination should be in a third physically separate location, far far away. It is possible and probably recommended to have two or more backup destinations, one further away than the other. I haven't used live backup (dbbackup -l) together with high availability but I can't think of any reason why it wouldn't work to provide warm standby on top of hot failover... I have seen multiple live backups in operation (before the days of HA), one database with two warm standbys in different locations (local and co-location).

Since the arbiter has so little in the way of requirements, I don't see the advantage to putting it on the same box as any of the other components, including the backup destinations. Or anything else for that matter.

About virtualization...

As far as I can see, the one and only reason to virtualize anything is to save money. I have never heard anyone say that virtualization does anything to eliminate single-points-of-failure. In fact, it seems that when you virtualize anything, by definition you are creating a single-point-of-failure. I'm not saying virtualization isn't the greatest thing since indoor plumbing, I'm saying it doesn't apply to high availability or backup... saving money isn't the primary goal, saving your life is.

To continue the analogy: indoor plumbing is wonderful at home and in the office, but it's really not important when you're 1000 feet underground in a mine shaft... down there, you are thinking about safety, not comfort.

Having said all that, what I really think is that you should hire someone (on short-term contract?) to advise you on the hardware and networking configuration. Or, exploit the vendors, get Cisco to teach you what you need, for example. It's really important to get a second opinion, especially when the first opinion is your own... it's called due diligence. Be careful, however, the world is full of imposters... trust but verify, and Google Search is great for that.

The SQL Anywhere part's easy... the hardware part is scary-hard.