Don't put all your eggs in one basket.

We all expect our favorite gadget vendors to cram more and more functionality into devices.  Clipped on just about everyone's hip thesedays are Phones that can send email, play music, socialize, take pictures and record movies.  Oh, and they make the occasional phone call. 

Sure, it's debatable if they actually do any of these really well. 

Are they convienent?  Yes. 

Would you be sad if all of  that fell into a puddle? No. YES!

But the same multifunctionality does not apply to what you can jam onto a server machine that is running your business' system of record.  A server, for all intents and purposes of this blog, should be a machine that provides a very specific set of functionality - A Mail server, a Database Server, a Web Server, a DNS Server, a PBX Server...  

Now, it is physically possible to combine everything into one server, and there are plenty of companies that do this, and maybe they haven't had anything catastrophic happen - yet.  But all it takes is some misdirected voltage, or some end of life hardware, or some slippery fingers on the commandline to take that whiz-bang powerhouse server to a blankly staring doorstop.

Suppose you had one server doing the following:

• PostgreSQL for xTuple and PBX
• MS SQL for exchange mail
• File/Print shares
• Active Directory Services
• PBX Services
• VirtualBox images

That's a whole lot of eggs to throw into one basket.  Suppose you walk in one Monday morning - or better yet a Friday morning before a long weekend which also happens to be a critical shipping day to meet the company's end of month numbers.  Maybe this day is so important because it means they get an extension on their lines of credit so that the owners won't close the doors.  There could be some serious ramifications to your choice in hardware...

Every IT person I know, loves to walk into work to a waiting and angry mob...

"I can't make a phone call"
"Is the email down? I can't check my email."
"Engineering can't access their CAD drawings"
"Where's the share for our G-code?  We can't do the machining without those files."
"I can't login to xTuple"
"Is the email down?"
"I can't print"
"The xtuple won't come on."
"The shop floor can't login to see what they need to make."
"My email's not working."
"Richard in shipping just went home."
"My icon's not working..."

A short while later, back in the server room...

"How's that backup lookin? Gonna be up again soon?"  
"Yeah, the backup looks pretty good. Shouldn't be too long..."  
"Yeah? Have you tried a restore before?"  
"No."  
"You better #$%^#$% hope you get this @#!$%^%$@# running again! I have 55 @#$%@%^ people sitting around because this @#$%@#$%%%@# decides not to @#$@%#$ work today..."

Backups are only as good as far as the restore process goes.  You can checksum the backup all you want, you can verify that the data is there.  Point is, unless you've done a bare metal recovery, it ain't gonna work like the backup vendor said.  There's going to be some downtime, you're going to have to use the installation media, your're going to have to get the OS at least up to recognizing the tape/cd/whatever drive.  If there is something seriously wrong with the hardware (i.e. fried)- did you buy a backup server to be on deck?  What are you going to restore your data to... your laptop?

 

Overloaded server, just like this guy...

Personally, if I have a choice in the matter, I'd rather be out one or two services rather than all services.  Several months ago, our webserver hardware (a major service indeed...) died after several long years of service.  Did anyone notice? Not hardly. Why?  Because we didn't cram every service we have into one box and we also had a machine we could spin up as a replacement.

If you really would like to put all of your services onto one server, be my guest, but I'm warning you - I've been there, done that, got a T-shirt and a shot-glass.

Ok. So, what is the best way to stand up a PostgreSQL server for xTuple?

The easiest way, since this has the potential to be near critical to the operation of your company, is to keep it simple.

• Use a Linux operating system.  It's flexible (backup schemes, remote access, secure), and more importantly, it's what I like best for this app.  And, it's pretty low maintenance for shops that have no real in-house IT.  It doesn't need a baby-sitter typically.
• Use a redundant set of disks.  RAID 10 preferably.
• Use a warm standby server.  It's easy to setup, reliable, and it can be brought online very quickly if the main server goes ka-put...
• Build your postgres from source.  Don't rely on your Linux distribution to keep you up to date.  You don't want xTuple to break because of some incompatibility introduced by the apt-get/YUM/deb version of PostgreSQL installed munged up your install.
• Subscribe to one of our handy-dandy XTN packages!  This point needs to be emphasized more, but really, it's a good thing to have, the remote nightly backup feature has saved numerous companies their data.
  
• Read Perry's Blog.
• DO NOT PUT UNNEEDED SERVICES ON THIS BOX.  KEEP IT JUST POSTGRESQL FOR XTUPLE.  To steal a slogan from GM.  Keep your xTuple server all xTuple server.
   

And, if anyone disapproves of my generally Pro-Linux comments and lack of recommending Virtualization, please discuss it below.  Flame on! :)