[Asterisk-Users] Hard drive write cache

shadowym shadowym at hotmail.com
Tue Jun 13 15:52:20 MST 2006


 You still need a hard drive to run FreePBX as far as I know.  Either that
or burn out your 2GB CF drive after a couple months of constant writes.  I
would assume Apache and MySQL would need to go on the HD.  Voicemail can go
there as well.  Linux/Asterisk binaries and base config files can probably
go on the CF read only.  Would this work?  

Are there any how-to's around that have done something like this?  It is
starting to make a bit more sense to me to do it this way but I'm no expert.
If I did it this way I would not have a need for RAID so it will probably
come out to about the same price.


> -----Original Message-----
> From: Nicholas Kathmann 
> [mailto:nicholas.kathmann at kathmannconsulting.com] 
> Sent: Tuesday, June 13, 2006 1:22 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] Hard drive write cache
> 
> They have IDE and even some SATA (not easily available) flash 
> drives also, some of which are over 80GB.  The more space you 
> get, the quicker it goes up in price with the larger models 
> costing more than most servers.  If you want, you can also 
> use an IDE to CF adapter. 
> 
> For the locking plugs, google  NEMA-L5 or NEMA-L6 and that 
> will show you what they look like.  They are readily 
> available in most hardware stores for low cost.  On the 
> server side, you can tie wrap the power cable to the rail or 
> something like that, but I would suggest just getting a 
> server that has the thumbscrew and clamp to hold the power 
> cord in place.  They are available on most IBM servers.  If 
> the power cord is mounted to the wall with staples or those 
> nail in C clamps, someone would have to go out of their way 
> to pull the power cord out. 
> 
> Another option if it's a really small installation is to use 
> a mini-itx fanless system.  We have 2 set up here (in a test 
> lab for now) with 1Ghz Via processors running up to ten 
> (that's all we've tried) concurrent calls with no problems.  
> These is no transcoding and echo cancellation running on 
> these.  Next it to try some Digium and Sangoma PCI cards in 
> them and see how they work.  I'll post the results when we 
> finish.  Such systems are extremely reliable as long as you 
> don't pull too much from the small power supplies, etc.  
> Regardless of what you use or what you do, trying to achieve 
> 5 nines reliability is going to require a whole rack full of 
> systems, storage, batteries, etc and a whole lot of 
> configuration and testing.  Even PBX systems (not all) 
> require downtime for firmware upgrades, etc.  Most people 
> don't bother since the systems aren't connected to data networks.
> 
> It was actually easier to pull the power cables out of some 
> of the PBX equipment (such as the Definity G3si) than it is 
> to pull the equipment out of the Cisco VoIP or IBM servers 
> combined with the right PDUs, etc.  
> 
> Thanks,
> Nick
> 
> shadowym wrote:
> > Thanks for the suggestions.
> >
> > CF is not an option for FreePBX which is a requirement for the 
> > installs I have in mind.  Astlinux on CF is a great option 
> otherwise.  
> > That is by far the simplest, cheapest, and suprisingly most 
> reliable 
> > solution I have come across so far.  If there was a half 
> decent (open 
> > source) GUI that could run on Astlinux on CF it would be a 
> no brainer IMHO.
> >
> > Physically locking down the server is not an option.  It 
> will be hung 
> > on the wall in place of where a traditional PBX would normally go.  
> > This is a telecom closet NOT a server rack environment.  
> UPS with auto 
> > shut down is just one link in the chain.  Do you have any further 
> > information of locking plugs?  I have not come across those 
> before.  
> > Of course in order for that to make sense I would need 
> locking plugs 
> > on both the server AND UPS end.  It has to be idiot proof.
> >
> > Think PBX and/or network appliance not computer server.  They are 
> > idiot proof so it is quite reasonable IMHO to expect the 
> same from an 
> > Asterisk server (or in my way of thinking, Asterisk network 
> appliance).
> >
> >   
> >> -----Original Message-----
> >> From: Nicholas Kathmann
> >> [mailto:nicholas.kathmann at kathmannconsulting.com]
> >> Sent: Tuesday, June 13, 2006 11:04 AM
> >> To: Asterisk Users Mailing List - Non-Commercial Discussion
> >> Subject: Re: [Asterisk-Users] Hard drive write cache
> >>
> >> If all you are worried about is the write cache on the 
> disks, why not 
> >> just put the system on a UPS set to shutdown the system in 
> the event 
> >> of power failure, then place both the UPS and asterisk 
> servers in a 
> >> locked rack.  In the event of a power failure (or someone knocking 
> >> the plug loose, which you can use locking plugs to further 
> mitigate), 
> >> the system will stay up on battery power then shut itself down to 
> >> prevent data corruption.  I doubt you will get that level 
> of uptime, 
> >> but there are other options to help achieve higher 
> reliability.  You 
> >> can run the OS and asterisk on a solid state disk, and 
> have voicemail 
> >> and whatever else you want to go to rotating disks.  That 
> will also 
> >> help with power usage on the server when using the UPS.  
> Industrial 
> >> flash disks are said to have (but they really can't 
> promise this) a 3 
> >> million hour MTBF.
> >>
> >> Thanks,
> >> Nick
> >>
> >> shadowym wrote:
> >>     
> >>> The cold hard truth is that if Asterisk cannot achieve
> >>>       
> >> 99.999% uptime
> >>     
> >>> without becoming much more expensive that a traditional PBX
> >>>       
> >> then it is
> >>     
> >>> not a viable alternative.  Even elcheapo Key systems are
> >>>       
> >> rated for five nines.
> >>     
> >>> That is what the telco world requires unless your just
> >>>       
> >> using Asterisk
> >>     
> >>> in your basement as a hobby or as a one man company.
> >>>
> >>> Redundant Servers is moving into the realm of 
> non-competitive with 
> >>> Traditional PBX IMHO.
> >>>
> >>> I don't care about corruption of the CDR or any of the 
> >>> logging/database information.  All I care about is the 
> ability make 
> >>> phone calls after power failure.  That IS the MAIN function
> >>>       
> >> of a PBX.  
> >>     
> >>> Not call centers, databases, CDR, click 2 call, and all the
> >>>       
> >> other bells and whistles.
> >>     
> >>>  
> >>>
> >>>   
> >>>       
> >>>> -----Original Message-----
> >>>> From: Boris Bakchiev [mailto:boris at jildent.com.au]
> >>>> Sent: Tuesday, June 13, 2006 2:13 AM
> >>>> To: Asterisk Users Mailing List - Non-Commercial Discussion
> >>>> Subject: RE: [Asterisk-Users] Hard drive write cache
> >>>>
> >>>> These days you don't have to worry much about your write
> >>>>         
> >> cache unless
> >>     
> >>>> you're running application where once single byte changed
> >>>>         
> >> will affect
> >>     
> >>>> whole file.
> >>>>
> >>>> Look at it this way, the only corruption will occur is
> >>>>         
> >> whatever the
> >>     
> >>>> files were open by asterisk at the time of the crash. And
> >>>>         
> >> only up to
> >>     
> >>>> the point where the file was last open.
> >>>> As far as I know asterisk does not keep cdr or log files
> >>>>         
> >> open so you
> >>     
> >>>> would loose only the data that was written at the time of
> >>>>         
> >> the power
> >>     
> >>>> failure.
> >>>>
> >>>> Any journaling file system (ext3, resierfs, xfs, etc) 
> will easily 
> >>>> handle any power failure event. Your files will not be 
> corrupt but 
> >>>> could miss some of the data.
> >>>>
> >>>> At the most you will loose 10-50 cdr entries written to
> >>>>         
> >> you log files.
> >>     
> >>>> If you post CDR to a remote SQL database then you 
> asterisk install 
> >>>> and linux is more or less static and will not be affected by the 
> >>>> power failure.
> >>>>
> >>>> What you need to do is minimise the writes to hard disk's:
> >>>>
> >>>> 1 - Send syslog to remote server and do not do ANY syslogs
> >>>>     Or keep the circular buffer in memory if you have
> >>>>         
> >> plenty of it. 
> >>     
> >>>> 2 - Send CDR's to SQL server (or log to ramdisk and send 
> to remote 
> >>>> server every few minutes via SSH)
> >>>> 3 - Do not record any calls (or do that somewhere else)
> >>>> 4 - Stop any services that write/read data on regular intervals.
> >>>>
> >>>> If you have no writes you have nothing to worry about 
> during power 
> >>>> failure and journaling file system will take care of the rest.
> >>>>
> >>>> Keep your partition size really small so that fsck will
> >>>>         
> >> not take much
> >>     
> >>>> time.
> >>>>
> >>>> You have to be realistic, you cannot achieve 99.999% uptime. 
> >>>> That's 5 minutes per year downtime.
> >>>> You will have more or less 100% until your first 
> hardware failure.
> >>>>
> >>>> Even if you have all the hardware components 
> pre-purchased it will 
> >>>> still take you 2-12 hours to detect, diagnose and fix 
> the fault if 
> >>>> you lucky.
> >>>> So your 5 minuets
> >>>>
> >>>> If the business is demanding 99.999% then it should be 
> prepared to 
> >>>> invest into the hardware.
> >>>> I would recommend a cluster or even better a fault 
> tolerant server.
> >>>> Those are expensive but you can pretty much rule out the 
> hardware 
> >>>> failure and swap all of the failed components while the 
> system is 
> >>>> running (cpu, memory, hdd, etc).
> >>>>
> >>>> Look at Stratus or NEC FT servers if you need hardware 
> redundancy.
> >>>> They're expensive but will give you the hardware
> >>>>         
> >> reliability you need.
> >>     
> >>>> Or get a traditional PABX :)
> >>>>
> >>>>
> >>>>
> >>>>     
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: asterisk-users-bounces at lists.digium.com
> >>>>>       
> >>>>>           
> >>>> [mailto:asterisk-users-
> >>>>     
> >>>>         
> >>>>> bounces at lists.digium.com] On Behalf Of shadowym
> >>>>> Sent: Tuesday, 13 June 2006 10:34
> >>>>> To: asterisk-users at lists.digium.com
> >>>>> Subject: [Asterisk-Users] Hard drive write cache
> >>>>>
> >>>>>
> >>>>> I am looking at ways to harden my asterisk install to
> >>>>>       
> >>>>>           
> >>>> prevent computer
> >>>>     
> >>>>         
> >>>>> related issues from happening.  I am concerned about about
> >>>>>       
> >>>>>           
> >>>> disk write
> >>>>     
> >>>>         
> >>>>> cache.
> >>>>> That seems to be a major source of hard drive 
> corruption on power
> >>>>>       
> >>>>>           
> >>>> failure.
> >>>>     
> >>>>         
> >>>>> Hard Drive corruption is simply unacceptable for the
> >>>>>           
> >> 99.999% uptime
> >>     
> >>>>> requirements of my Asterisk install that needs to be as
> >>>>>       
> >>>>>           
> >>>> reliable as a
> >>>>     
> >>>>         
> >>>>> proprietary PBX.
> >>>>>
> >>>>> Of course I will be using redundant power supplies, raid
> >>>>>           
> >> 1 and use a
> >>     
> >>>>>       
> >>>>>           
> >>>> UPS.
> >>>>     
> >>>>         
> >>>>> None of those things mean much if the power cords 
> accidentally get
> >>>>>       
> >>>>>           
> >>>> pulled
> >>>>     
> >>>>         
> >>>>> from the back of the server.  Unlikely as it may be I have
> >>>>>       
> >>>>>           
> >>>> to consider
> >>>> ALL
> >>>>     
> >>>>         
> >>>>> possibilities.
> >>>>>
> >>>>> So is disabling the write cache a good way to reduce the
> >>>>>       
> >>>>>           
> >>>> risk of hard
> >>>>     
> >>>>         
> >>>>> drive corruption for an Asterisk server?  I am not too
> >>>>>       
> >>>>>           
> >>>> concerned about
> >>>>     
> >>>>         
> >>>>> the reduced performance/lifetime of hardrives with write cache 
> >>>>> disabled since
> >>>>>       
> >>>>>           
> >>>> Asterisk
> >>>>     
> >>>>         
> >>>>> is not a very write intensive environment.  Even with lot's of
> >>>>>       
> >>>>>           
> >>>> voicemail
> >>>>     
> >>>>         
> >>>>> going on.
> >>>>>
> >>>>> Any other recommendations/links for increasing the 
> reliability of
> >>>>>       
> >>>>>           
> >>>> Asterisk
> >>>>     
> >>>>         
> 
> 



More information about the asterisk-users mailing list