Heavy-Duty System Administration Utilities? 44
leandrod asks: "I am in the process of helping a small software company define the infrastructure for their major client's new system. It is a big country, and it is a medium-sized client planning on going big. We are planning to standardize on Debian GNU/Linux. I am aware I can have IBM Tivoli Maestro for GNU/Linux for production scheduling, and BEA's Tuxedo TP monitor, but they are unsupported under Debian. I am also aware of one or two free TP monitors, but they are either incipient or stagnating. I couldn't find a production scheduler. I know I can do lots with the standard tools, but keep in mind I am targeting a transaction-processing bureau for a big operation with hundreds of thousands of terminals and millions of users, something like a poor man's Wal-Mart, or even Visa. Are there vendors out there willing to support Debian or just GNU/Linux in general? If not, are there free software projects that accomplish the same thing?"
Re:Think long-term stability... (Score:3, Informative)
Sun's N1 (Score:3, Informative)
I hear Sun offering suport for Linux as well, these days
Re:Think long-term stability... (Score:4, Informative)
ctrl+shift+(numpad Plus/minus)
UserLinux - "Debian Enterprise" (Score:5, Informative)
Possible Solution (Score:2, Informative)
Note: I'm not fully unbiased. I have a friend that works there.
scheduling tools (Score:5, Informative)
Add in : multiple platforms, vendors in different countries with different time zones, holidays, cultures and calendars, (try matching our Julian or Gregorian calendar to a Lunar calendar), with varying schedules, such as cyclical/hourly, daily, weekly, monthly, quarterly, annual. Matching them to accounting needs like a fiscal year that does not match the calendar year, production schedules that cross week and month boundaries, and online systems that are up or down different days of the week and things can get very crazy very fast.
I can point you to 2 companies that seem to offer the most complete solutions for multiple platform shops, other than IBM's Tivoli, which works fairly well from what I have heard:
First:
Cybermation in Canada makes a product called ESP:
http://www.cybermation.com/solutions/jobsch
They have a cute little site at:
http://www.replaceyourjobscheduler.com/sitel
I was at a very large company when they swapped over from the CA7 tool to this one on their MVS systems. I was impressed with the product and the company's support. That was 8 years ago or so, so I cannot vouch for the product or the company now, but I have heard only good things about them currently.
Second:
BMC markets a product called Control-M, with all kinds of modules including an Enterprise Manager: http://www.bmc.com/products/productlist/0,2831,19
I currently use this product in an MVS/Unix/WinNT/Oracle/SAP environment. It does work. It has it's issues and shortfalls, and we have some problems with support, but we have managed to complete our schedule across all platforms every day, with only a very few exceptions in the past 3 years I have worked with it. We run in excess of 10,000 batch/background processes per day across many platforms.
In all 3 cases, Tivoli, Cybermation, BMC, licensing can be a bit pricey. But if you research the products closely, and only license what you really need as opposed to what you think you need, you can get by.
I also strongly suggest you hire an experienced scheduler to help out. This is a very undervalued and complcated specialty. Like programming, many can muddle through but few are truely good at it.
Tom
Re:Sun's N1 (Score:3, Informative)
In fact, N1 does not support normal Solaris boxes right now.
It only supports Sun's blades. All of these other things will be supported in the bright, shining future, of course.
We use IBM & Debian (Score:4, Informative)
Re:Think long-term stability... (Score:4, Informative)
X is a *bad* example, easily attacked, but your argument is fundamentally wrong. The goal with production servers is stability and security, and the Debian stable approach is the hands-down best way to achieve that (though simply running stable isn't enough, it's a good start).
The only valid reason to upgrade production software is if you must have the features available in the new version, or if you can no longer get support for the old version. Outside of that, you keep what works. Debian stable is very well-supported and it's never more than two or three years behind the cutting edge. It's really ideal, with the caveat mentioned up a few posts that if you need to run closed source commercial software, you will get much better support on Red Hat and SuSE.
Re:WTF? (Score:2, Informative)
Re:Think long-term stability... (Score:3, Informative)
How about database clustering?
I'm not sure about that one - but it seems like either regular replication or 2-way replication oughtta get those needs taken care of. Or, read This article [mysql.com]
Or remote replication?
Replication in MySQL [mysql.com] is easy - I'm running a couple of replicas right now for backup purposes
Or security and access roles compatible with HIPPA regulations?
MySQL's access control can grant and deny access down to the column level. I assume that you mean HIPAA, though, and any access control problems introduced can be handled by the developer planning the database / managing access control, given MySQL's pretty granular control abilities. The job of managing HIPAA-compliant access control should be at the application level and not the database level, anyway.
Or reliable data recovery compatible with large-scale backup systems like Legato or TSM or Veritas?
MySQL uses files and directories that *any* backup system can use, even those that cost lots of money. Want a backup? Lock the table, dump the table, unlock the table. It's not hard. Read more about backing up MySQL [mysql.com]. It doesn't get much more reliable than that.
I have a replicated, reliably backed up pair of mysql servers behind me. They're not HIPAA compliant, because that's a pain, but it'd be largely trivial to implement. Com back when you've researched your gripes.