An idea being looked at, and one of the reasons management was looking at eJabberd, was the high availability option with the server cluster. Ok, I hae read and read that there is no server clustering in Wildfire. I understand that this is being looked at, but this is an item I need to look at seriously now for a proposed up grade (btw, off topic: the other issues I was facing worked well except the database dump from theold jabberd stuff to an XML format but that is another fish).
Has anyone heard of or actually attempted using OpenSSI as a viable option to cluster the Postgresql database across more than 2 nodes. The failover is what is really hot to the higher powers, so master slave node configs are out. it also allows for multiple machines, no matter what the domain names, all using the same db as actively syncing, with fail-over.
My thought on that was to play around with one db on a main server, and point the rest back to it (5 to 7 servers tops all runing wildfire). Problem would be latency, and single-point of failure. I am still going with LDAP for login, so the database itself is strictly holding MSN stuff and roster info.
maybe you use Wifi as a critical component for your business process, so using some or more mirrors came to your mind. Which valueable information is stored in the database?
Offline messages or the room history?
For me it’'s seems more easy to use two servers and install 2Wifi and 2DB, fill both databases with the needed users and use a layer-7-switch for complete failover.
Maybe using the shadow or master/slave option of the database if you’'re really interested in the temporary data.
Wifi caches a lot of information read from the database, so you don’'t want to have two Wifi processes accessing one database.
layer-7-switches … Nortel Network (Alteon), Foundry, Radware, F5 should be some manufacturers. You point your DNS entry jabber.xyz to it and it checks whether server1 is still active and connects all clients with server1. As soon as server1 becomes na it does the failover, of course this will kill the active sessions. But it takes only some seconds and the administrator has nothing to do. Afterwards one should of course check what happend, but as long as server2 is running one mustn’'t be in a hurry.
I shoud remove the following italic content, it only applies for HTTP(s) and not XMPP, Apache can not handle XMPP. But if one uses HTTP bind/JWChat or MUCkl than Apache is fine.
That’‘s probably a very easy scenario, one could do this also with Apache and mod_rewrite(map), while the map is created by a XMPP watch script - that’'d be the solution for the poor guys.[/i]
Actually, at present I still use Jabberd2s8, but am in the process of testing and migrating from that server to one I just built. Why I want to put sync’‘d db out there is for fail over world wide. the company is in China, Mexico, US, EU, Canada, South America. Want to put multiple boxes out, with same database so that if say my main us server goes down, with a virtual host name, it will automatically redirect to say Canada or Mexico which ever is the closer for that user. Gives me a huge advantage in scalability, plus I dont have users in Europe wondering what the user in Brazil’'s im server name is. One virtual server clustered allows everyone to have the same log in, and still see everyone in the world with the same jid scheme.
The switch idea is nice, but it doesn’'t fulfill the core requirement that I have load balanced performance worldwide. we have over 55K employees, and eventually are looking at going VoIP, SMS, etc with this. Over the last several days I have been attempting to put a test server in place and have had several issues relating to LDAP, PSQL, and other things, all critical for this architecture. I need to know if it is possible to do, so I can decide if all of the other issues are worth it.
Thank you for the suggestions though. It gives me an idea for a backup for a main in the datacenter.
maybe I don’'t understand about the synchronized databases. You store your users in LDAP, so which valuable information (rosters?) should be stored in every database? And what happens if the master database fails? Changes to slave databases are impossible, so if the master fails there is no option to use a slave database as Wifi stores MUC conversations and also last login time into the database, this would fail. So you must reconfigure a slave database as the new master, this will be funny.
In my opinion you could make your life more easy using a Wifi installation with a local database for every global area using s2s to communicate world wide.
The chances for hardware failures are below 1% so if you care about it you may set up a synchronization of all databases to the US and install seven Wifi backup instances on one physical server together with the seven slave/backup databases. So there is no GLSB possible but you still have a hot backup available.
Ok, That is good information. I believe that due to my inexperience with this particular xmmp suite I have been talking about something that might not be possible here.
Alright, background: On my present production server, I have J2s8. If I wanted to put a virtual name (foo.jabbercluster.com) on it, I could register in DNS, and then deploy 7 different clustered servers Worldwide, each syncing databases from one to another, More like a multi-master setup, not a master/slave. This would allow me, with some interesting SRV records to point a user anywhere to his/her closest jabber instance depending on his IP address. The databases being sync’‘d would allow any user from any country to log into a wildfire server close by, authenticate to LDAP and not only authenticate properly, but also retrieve his roster from that near wildfire server and it would be as if he was at his/her computer. Searching the forums, it looks like Wildfire isn’‘t capable of actually working like the other jabber instances , in that I mean authenticate to LDAP, but store user information like rosters, bookmarks, etc in the Postgresql database that is setup on each server. On my present Production Jabber server, I authenticate to LDAP, butstore info in the pgsql db, which makes searching TONS faster. Reading the forums, it would seem that it is an either/or situation. One cannot authenticate to LDAP, and store information in another database (from what I am reading in these forums atleast), which is sort of puzzling because if you can’‘t do this, where are the contacts stored if LDAP is read-only? Although the server is interesting with it’‘s support for new add-ons, and other things; I need to be able to authenticate to LDAP, but store user information locally, for retrieval at any station that someone may walk up to and login at. If I am incorrect in my thoughts on the capabilites of Wildfire please correct me, however I can’'t find anything in the forums that says that the dual database usage is possible. to clarify, LDAP is part of our eDirectory tree in ourold Novell instance. We are switching to AD2003, but LDAP and edirectory will be hanging around for a while doing mundane authentication for things like web access, Jabber, intranet, etc. The LDAP information/user info is multi purposed and not setup solely for wildfire, in that Wildfire will never be allowed to add information to the user stores in that database, hence the need for pgsql.