Koozali.org: home of the SME Server

Hardware for new server, Suggestions ?

Michiel

Re: Hardware for new server, Suggestions ?
« Reply #15 on: April 19, 2003, 12:21:43 PM »
For what it's worth: I've got update 3 running on software RAID 1 without any discernible slowdown or other side effect. The CPU is happily churning at 2% load.

Ed Form

Re: Hardware for new server, Suggestions ?
« Reply #16 on: April 19, 2003, 06:25:16 PM »
In article <30a2410517be4a02b7b55c3b7414e8bb.phorum-owner@e-smith.net>, charlieb@e-smith.com (Charlie Brady) wrote:

> This message was sent from: Experienced User Forum.
> http://forums.contribs.org/index.php?topic=17131.msg66515#msg66515
> ----------------------------------------------------------------
>
> Ed Form wrote:
>
> > It's certainly quicker, and with the major slowdown that you
> > guys have imposed on us with 5.6 update 3 that starts to look
> > very attractive.
>
> Excuse me, Ed, nobody has *imposed* anything on you. If you choose to
> use software which we make available, fine, but nobody is making you use it.

Point taken, and apart from one client system which I installed when I first discovered E-Smith 4.1.2 and the client will not allow me to change to an alternative OS, plus my internal test server, I don't.

> As to the slowdown you have experienced, I don't understand why a
> security fix to samba would make any difference at all.

Nor do I, but it is a fact. I gave details in a message a few days ago and saw some confirmatory messages from others, as well as one or two who saw no change.

> Nevertheless, any information you can provide about problems with
> the system can only help us, you and other users.

If you are involved with disk intensive file processing you may notice a distinct problem with Update 3. The example I supplied earlier is to do with graphics file conversions.

On my test server I routinely carry out work for our own document scanning bureau business. One of the processes involves reading multipage G4 tiff files from the server disk to a workstation [Windows XP Pro] and converting them to Scansoft Paperport *.max files using the file import procedure of PaperPort itself, before writing them back to the server in another directory. Each conversion run involves a selection of 12-15 files varying from 60KB to 6MB in size and perhaps totalling 12MB. As each file is processed the importer displays a thermometer bar progress meter.

On 5.5, 5.6b7 and 5.6 unsupported release, this proceedure will hesitate and run slowly for the first file or perhaps the first two, and then each conversion for the rest of the day will run at high speed, the thermometer bar moving smoothly at a speed proportional to the size of the file being processed.

On Update 3 the process runs very slowly, with each page of the multipage file taking 3 or 4 seconds and the workstation processor having time to write a thumbnail of the partially converted file to the screen. This wading-through-treacle pace will persist for three or four files and then the rapid progress mentioned above will start and the batch is completed quickly.

With earlier releases, as I said above, the next batch will begin running at full speed and this will continue for the rest of the session, but with update 3, and to some extent with update 2, the dog-slow condition returns at the beginning of each batch. The net effect is to add hours to the processing of a large tranche of files.

The other symptom of the problem is the appearance, since update 2, of events at the server which can be distinctly heard as bursts of intensive disk activity, and during which all workstations stop dead if they happen to be communicating with the server at the time. There seems to be a relationship between mail activity on the server and this problem.

Let me further add a note about permission and file property difficulties with SME.

Certain Windows programs can not have their files stored on SME servers, and possibly not on any kind of Samba based SMB provider. Critically for me with a number of clients in the accountancy business, these include all of the Sage professional accounting packages, particularly Sage Taxation Suite [the product formerly known as Apex Taxation] and Sage Accounts Production. In that first case, the software runs once installed with its data on an SME server, but, as of Version 6 released this month, it cannot be updated. In the second case, the product registration process does not persist beyond the day on which the registration is carried out and, before the product can be used the next day, it has to be registered all over again.

The final situation of which I am aware is that Microsoft Access databases *cannot* be successfuly stored on SME servers. At some point corruption will occur as I have seen, now, on several occasions. This isn't the end of the world, because the MySQL set up you provide does a more than adequate job of substituting. Sadly however, some of the Sage products are Access runtime programs and get into difficulties. One in particular is the Practice Management package which a lot of accountants use to bill their time.

These, and a number of concerns about the commercial model used by Mitel, are the reasons why I will not use SME in client installations at this time.

> And if you do know of reliability problems with linux software RAID, please let us
> know details.

I don't, except for one situation: if one of your disks goes down you will suffer down time putting it right. They also give about a 2% loss of speed relative to a single disk and don't compare for performance to a decent SCSI system.

Ed Form

Ed Form

Re: Hardware for new server, Suggestions ?
« Reply #17 on: April 19, 2003, 06:30:39 PM »
For some reason the following words did not make there way into the post I just sent...

> These, and a number of concerns about the commercial model
> used by Mitel, are the reasons why I will not use SME in
> client installations at this time.

I would like to do so, but I cannot.

Ed Form

Ed Form

Re: Hardware for new server, Suggestions ?
« Reply #18 on: April 19, 2003, 06:31:56 PM »
Michiel wrote:
>
> For what it's worth: I've got update 3 running on software
> RAID 1 without any discernible slowdown or other side effect.
> The CPU is happily churning at 2% load.

I also do not see high processor loads, but disk performance is distinctly reduced.

Ed Form

Kelvin

Re: Hardware for new server, Suggestions ?
« Reply #19 on: April 20, 2003, 07:45:19 AM »
I'm wading in on the RAID discussion here, mostly with grounds that have been covered before in previous posts.

Tom :
> The Adaptec 1200A is not supported by Adaptec for Linux.

Does not matter. The 1200A is based on a Highpoint HPT370A and the drivers from Highpoint's web site work just fine (and is supported out of the box with 5.6, I believe).

The 1200A does NOT support hot swap, though.

The Highpoint 404 does but is a more expensive card, as does the ACARD AEC-6885 (but have not worked with it on Linux though).

And, hotswap or not, they are easier to replace and bring back to operating status than S/W RAID. For one thing, I don't need to know any commands to do it, just follow the menu driven controller BIOS screens and we're up and running again.

For that matter, Adaptec will not even support the 2400A if your are not using the stock kernel that comes from the *STANDARD* download version of RH. Charlie Brady keeps insisting that SME kernels are standard, but from a hardware suppliers point of view, it is most certainly NOT. It matters little if RH recommends that you use kernel x,y or z. As long as it is NOT the kernel that ships with the normal downloadable ISO of RH, it is NOT supported by most hardware manufacturers.

Ed :
>The final situation of which I am aware is that Microsoft Access databases
>*cannot* be successfuly stored on SME servers.

I have a client whose entire inhouse system is a multiuser Access database application stored on an SME server and have been running it on SME 5.1.2 for more than a year and recently upgraded to 5.6U2 and continues to run it without encountering any database corruption so far (touching the biggest block of wood I can find !).

Kevin :
> but FAR more reliable

SCSI drives in in Compaq Server RAIDs die too (have clients using them). No more and no less than the many IDE RAID systems I have put in all over. IDE replacements are by far easier to come by.

If you want speed over simple redundancy, consider RAID 0+1 (more drives required but can still cost less than a SCSI based RAID !).

Kelvin

Charlie Brady

Re: Hardware for new server, Suggestions ?
« Reply #20 on: April 20, 2003, 10:03:27 AM »
Kelvin wrote:

> For that matter, Adaptec will not even support the 2400A if
> your are not using the stock kernel that comes from the
> *STANDARD* download version of RH. Charlie Brady keeps
> insisting that SME kernels are standard, but from a hardware
> suppliers point of view, it is most certainly NOT. It matters
> little if RH recommends that you use kernel x,y or z. As long
> as it is NOT the kernel that ships with the normal
> downloadable ISO of RH, it is NOT supported by most hardware
> manufacturers.

No, not most hardware manufacturers. Only those manufacturers who 1) don't open source their drivers and 2) don't update their drivers when RedHat issues an updated kernel (for instance, for a critical security issue). They sound like manufacturers to avoid.

Charlie

Kelvin

Re: Hardware for new server, Suggestions ?
« Reply #21 on: April 20, 2003, 10:20:19 AM »
Hi Charlie,

> They sound like manufacturers to avoid.

Oh rubbish !

3COM releases linux drivers but don't support any of them (even those on standard kernels). And they are not alone. I'm sure lots of e-smithers out there use Adaptec stuff too. You are basically saying to all of us, stuff these products because the manufacturers don't support Linux properly.

Hell, we might well say the same for QMail as well. As long as it is not the stock QMail, it is not supported. So should we avoid QMail as well ??

Kelvin

Tom Keiser

Re: Hardware for new server, Suggestions ?
« Reply #22 on: April 20, 2003, 07:23:27 PM »
Charlie wrote:

> No, not most hardware manufacturers. Only those manufacturers who >1) don't open source their drivers and 2) don't update their drivers >when RedHat issues an updated kernel (for instance, for a critical >security issue). They sound like manufacturers to avoid.

This is certainly true and correct, but misses the point, IMO. For those who provide source code, the driver still must be compiled. This should be an easy task, but sometimes drivers provided by those on this forum simply don't work. Charlie, I believe your driver for the Adaptec 2400A is an example. I have never heard anyone say it works, but lots of folks say it doesn't. You yourself said you had no way to test it.

As for updated kernels, I can honestly say I have never seen a vendor who provides binary drivers for any device also provide them for any but the original kernel. Such vendors *MUST* be avoided, if you want to use a kernel that fixes the security issues, but for some reason, there is no unanimity on what updated kernel level should be used. This is a problem for RedHat to fix -- one mainly caused by rushing a new version to market every six months. Its a shame that the good code can't be backported into the offending kernel.

Tom

Charlie Brady

Re: Hardware for new server, Suggestions ?
« Reply #23 on: April 20, 2003, 08:21:38 PM »
Tom Keiser wrote:

> For those who provide source code, the driver still must
> be compiled. This should be an easy task, but sometimes
> drivers provided by those on this forum simply don't work.

This then is an argument for using only hardware that RedHat and/or Mitel support out of the box, or hardware for which you yourself can build working drivers.

Charlie

Charlie Brady

Re: Hardware for new server, Suggestions ?
« Reply #24 on: April 20, 2003, 08:26:24 PM »
Kelvin wrote:

> > They sound like manufacturers to avoid.
>
> Oh rubbish !

You're a very argumentative chap, Kelvin.
 
> 3COM releases linux drivers but don't support any of them
> (even those on standard kernels).

I was referring only to proprietary, closed-source drivers.  And wasn't talking of "support" in any case.

> Hell, we might well say the same for QMail as well. As long
> as it is not the stock QMail, it is not supported. So should
> we avoid QMail as well ??

Last I checked qmail was open source. And you can avoid qmail if you choose, but I wouldn't recommend that you do.

Charlie

Charlie Brady

Promise RAID support (was Re: Hardware for new server, Sugge
« Reply #25 on: April 20, 2003, 11:02:17 PM »
Charlie Brady wrote:

> No, not most hardware manufacturers. Only those manufacturers
> who 1) don't open source their drivers and 2) don't update
> their drivers when RedHat issues an updated kernel (for
> instance, for a critical security issue). They sound like
> manufacturers to avoid.

Further to that, read this post:

https://listman.redhat.com/pipermail/ataraid-list/2002-August/001001.html

As I have reported previously, I'm running software RAID1 without any special drivers on a motherboard with Promise 20265 chipset. Just install using the non-Promise IDE connectors, then move the drives onto the Promise IDE connectors.

Regards

Charlie

Kelvin

Re: Promise RAID support (was Re: Hardware for new server, S
« Reply #26 on: April 21, 2003, 03:42:13 AM »
Hi Charlie,

> You're a very argumentative chap, Kelvin.

On the contrary. If you follow most of my postings, you should have found that I take a fairly light hearted approach to the forums. What I will not stand for is people who are up themselves (eg. hardcore die hard Mac Users who refuse to see the shortcomings of their systems as well as Linux people who do not live in the real world -- figure that one out yourself !).

> Last I checked qmail was open source

Perhaps. But there is open source and there is open source. Yes, you can get the source and modify it to your hearts content. But yet, you are not allowed to distribute a modified qmail binary and still call it QMail. As far as DB is concerned, that could have changed QMail to a form that is no longer working as expected and so he will not allow the new version to be called QMail (even if you are allowed to use it). This IMO is no different from the stance hardware vendors take.

Tom wrote :
>This is a problem for RedHat to fix

Actually, I believe this is a problem for Linux to address. Linux must find a way to reduce / remove driver dependence on kernel sub-versioning. Let's take a silly example :- M$ issues many security hot fixes. If each of the hot fixes requires the users / admins to have to recompile all the various drivers before they can be reused, Redmond would have a revolt on their hands.

Kelvin

Damien Ryan

Re: Hardware for new server, Suggestions ?
« Reply #27 on: April 21, 2003, 11:55:57 AM »
I hate to interrupt this lively debate, but I am looking for a practical
solution. Charlie, what is the solution for a raid 1 (ie data
reliability, no speed concerns) given a smallish budget.

Would you do
  software raid (I am impressed  it works out of the box on e-smith,
                      does it do the recovery just as easily ?)
  onboard motherboard raid (promise ?)
  Adaptec IDE Raid 1200A (cheap raid card)
  A more expensive IDE Raid card from 3Ware
  A scsi car and drives.

Damien

Kelvin

Re: Hardware for new server, Suggestions ?
« Reply #28 on: April 21, 2003, 01:43:49 PM »
Hi Damien,

If you are not afraid of spending a little bit, take a look at something like the Accusys ACS-7500. It is a self-contained, OS independant RAID-1 chassis (just add your own drives) that also supports hot-swap with battery backup to track the automatic rebuild status. Being OS independant, it side steps the entire issue about driver support for a controller card, etc (as long as your on board IDE is supported, of course !).

If your client ever has the misfortune to suffer a single drive failure in one of these, you will be very thankful at the ease with which you can replace the faulty drive and not need any down time at all to do so.

Kelvin

Greg Zartman

Re: Hardware for new server, Suggestions ?
« Reply #29 on: April 21, 2003, 10:11:55 PM »
Ed Form wrote:
> Let me further add a note about permission and file property
> difficulties with SME.

I thought I'd add my 2-cents here as I've run into various file issues stored on a Samba share over the years
 

> Certain Windows programs can not have their files stored on
> SME servers, and possibly not on any kind of Samba based SMB
> provider.

Ed, I highly recommend that you bring this to the Samba developers attention if you are truly having a problem.   The two driving concerns of the samba project is stability and transparency.  If after exhausting configuration options you still have a problem, let the developers know about it.   They are very responsive to things like this and will almost certainly fix the problem quickly if one exists.

 I don't have any experience with the Sage software that you mention in your post, but suspect that it uses some kind of a database.  The root of your problem may be with multi-user access of these datafiles.  I bet that a little tweaking of samba share configuration parameters were the data is stored will solve.  


> The final situation of which I am aware is that Microsoft
> Access databases *cannot* be successfuly stored on SME
> servers.

I think you are mistaken here Ed.  I have several access databases in excess of 200mb currently stored on my SME server.  Samba has never had a problem with storing database files (they are no different from any other binary file really), but it has had issues multi-user access of databases.    These issues were overcome with Samba configuration parameters targeted at oplocks.  I recommend that you search the samba mailing list archives for other experience: http://marc.theaimsgroup.com/

I'd also be happy to pass on my experience if you give me a little more info on that you are trying to do.

> These, and a number of concerns about the commercial model
> used by Mitel, are the reasons why I will not use SME in
> client installations at this time.

Why is that Ed?  If you pay for SME,  you certainly get what you pay for.  The same holds true if you don't pay.  I’ve played both fields with respect to which version of SME I run (i.e., pay vs free) and can honestly say that I got a better deal in paying for SME.  

When I first started using SME (just prior to the release of V5), it was the free version with several of Darrel May’s commercial contribs.  These commercial contribs were meant to simulate service link for the most part.  I paid ~$700 (ballpark) for these contribs and misc. support (Not all that much different from what one can now buy SME.).  For the most part these contribs worked great and the support was adequate (I’d be happy to comment more offlist).  Problem is, the developer of these contribs has pulled out of the mainstream SME community and has started his own mini-community.  What if he closes shop tomorrow?  Where would that leave the “mini-community” and those who rely on the third party contribs?  

Unless you are a wizard Linux/SME developer able to develop and/or fix third party add-ons, you are not wise to deploy SME for a clients.  If something goes wrong or a contrib becomes incompatible with the current SME, who are you going to call for help?