Categories
jabber MetaNET WLUG

Upgrading jabber.meta.net.nz

I’ve finally gotten sick of the jabber.meta.net.nz services having a negative impact on the rest of the server due to the transports chewing up lots of ram, and so have put together another server and will start migrating things over. The new server is a dual 1GHz Coppermine P3, with 2 GB of ram and 36 GB of SCSI RAID-1 disks.

This seems like a great opportunity to tidy things up again. The server stack has been a bit messy since we upgraded to jabberd2, partly because of the server codebase, and at least partly because of gentoo. So, the new plan is to move jabber.meta.net.nz to ejabberd, sometime soon.  Along with the move will come a new webbased chat system ( jwchat ), and newer versions of the transports if they are available.

Ejabberd seems to be a pretty robust system. Jabber.org moved their system to it several years ago, and jabber.org.au made the switch more recently. I’ve seen some pretty impressive benchmarks regarding message latency / cpu loading / ram usage under high protocol load and it beats jabberd1.x and jabberd2.x hands down. Not that jabber.meta.net.nz really notices, or compares with jabber.org or jabber.org.au in terms of volume. We’ve currently got 112 clients connected, and someone noticed we had 203 clients connected a couple of weeks ago, but I have no idea what the high water mark for client connects is, much less any idea about message throughput statistics.

I aim to have the following done in the next few weeks:

  • Install and test base system – ejabberd, transports
  • Install and test jwchat
  • Script the migration of registration information and rosters from the jabberd2 pgsql database to something ejabberd can read.
  • Update the website with better information
  • Setup transports to prevent OOM issues (ulimit/regular restarts)
  • Test migration of registry/rosters
  • Pick a day and cutover.

The trickiest bit will be the migration of roster info from pgsql to ejabberd’s format, but I’ve already done at least three quarters of that already, as I considered doing this migration back in March.

Categories
NSP Xen

VMWare responds to XenSource, MS Threat?

Five weeks or so ago VMWare accounced massive price cuts for their existing products. Today I read that VMWare are redefining their product range completely.

The article has more detailed information, but the basic gist is that VMWare is releasing a new entry-level SKU, not manageable via VirtualCenter (and thus not suited for enterprise, but entirely suited for sites that just want one or two hosts), with SATA support.   SATA support has tradiationally been missing from VMWare’s products, and the presence of SATA support was one of the selling points for other virtualisation vendors such as Xensource and VirtualIron.

I asked in my last post “Has VMWare seen the writing on the wall?” I guess it has. It’s not end-game yet, of course: Gartner analysts peg virtualisation use at under 10% of the server market (I don’t have an exact reference for that, but there’s lots of references at 6% or so during late 2006). This is merely the point where VMWare realises that it’s not enough to be the big fish in the pond – Citrix and Microsoft are now in there too.