RE: Write Caching
- From: Charles Tolento <CharlesTolento@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 9 Jun 2005 13:52:02 -0700
If Node loses both paths to the disks I would venture to say you would see
FTDisk errors, however you have another node that has redundant paths to the
disks as well, failover should occurr in this situation. If the Other node
loses both paths to the disk as well, it will fail to arbitrate for the
Quorum. Your data in cache is still safe because it is held on the storage
processor. If you lose power, you typically have a battery backup that will
last long enough for the cache to flush before powering down. FTDisks can
also be casued by lose of network connectivity. If a regroup occurrs a scsi
bus reset is initiated and all nodes release their locks on the disks.
Regards
CT
"Cyberstorme" wrote:
> What happens in scenarios wherein both paths to the SAN backend does down on
> a node? I have seen FTDISK events being reported even for SAN volumes. The
> description is exactly the same as what John has indicated in his earlier
> posting. Could those FTDISK events for the SAN volumes, be due to any setting
> on the HBA? Queue Dept?
>
> "Charles Tolento" wrote:
>
> > John
> >
> > Accept the defaults for the PERC 4DC. If you enable write back caching in
> > your scenario, if NODE 1 has a failure and there is data in cache there is no
> > way for that data to replicate to NODE 2. In other words the cache between
> > the NODES Raid Controller cards has no way to update. You don't have this
> > problem in a SAN as the cache is held on the Storage Processor. Please not
> > the KB you referenced does not mention this particular recommendation in a
> > cluster. This is a major performance hit for your solution.
> >
> > Regards
> >
> > CT
> >
> > "John" wrote:
> >
> > > Not sure if I have my array setup correctly. Trying to setup Exchange 2003
> > > on Windows 2003 cluster. 2 poweredge 1850 with PERC 4DC to connect to a
> > > PowerVault 220s DAS. 3 raid arrays. 2 RAID 1 arrys and a RAID 5 array. The
> > > PERC 4DC are in cluster mode and by default set to write through caching.
> > > Article below indicates that write back caching on a controller is acceptable
> > > as long as you have battery backup on the controller. Not sure of the write
> > > back caching on the disks though.
> > >
> > > http://support.microsoft.com/default.aspx/kb/288700
> > >
> > > I have two questions.
> > >
> > > 1) I get the following errors sometime when I try and failover the cluster
> > >
> > > Event Type: Warning
> > > Event Source: Ftdisk
> > > Event Category: Disk
> > > Event ID: 57
> > > Date: 5/26/2005
> > > Time: 4:57:59 PM
> > > User: N/A
> > > Computer: NODE2
> > > Description:
> > > The system failed to flush data to the transaction log. Corruption may occur.
> > >
> > > Event Type: Warning
> > > Event Source: Ntfs
> > > Event Category: None
> > > Event ID: 50
> > > Date: 5/26/2005
> > > Time: 4:57:46 PM
> > > User: N/A
> > > Computer: NODE2
> > > Description:
> > > {Delayed Write Failed} Windows was unable to save all the data for the file
> > > . The data has been
> > >
> > > lost. This error may be caused by a failure of your computer hardware or
> > > network connection. Please
> > >
> > > try to save this file elsewhere.
> > >
> > > 2) Wouldn't write back caching even with battery backup still not be a good
> > > idea? If there is data in the write cache when a failover initiates,
> > > wouldn't there be a possiblity of data lose since the controller on the other
> > > node will not have the same data in its controller cache?
.
- References:
- Write Caching
- From: John
- RE: Write Caching
- From: Charles Tolento
- RE: Write Caching
- From: Cyberstorme
- Write Caching
- Prev by Date: RE: Are the same model nodes necessary?
- Next by Date: Cluster Service remain on starting state after quorum log corrupti
- Previous by thread: RE: Write Caching
- Next by thread: Re: Windows 2003 SP1(the official build) and MSCS
- Index(es):
Relevant Pages
|
