"Will" <westes-usc@noemail.nospam> wrote in message
news:O3pUeLQ3GHA.1608@TK2MSFTNGP04.phx.gbl...

> When working with a stand-alone server that is not going to be clustered,
> and the storage is mission critical, my normal instinct is to build a disk
> configuration on a fibre channel array that does RAID on the drives and
> presents a logical volume to the Windows OS over fibre channel. I then
> create a duplicate disk topology (separate fibre card, separate fibre
> switch, separate fibre array) and then use Windows RAID 1 to mirror
> between
> the two systems. I get the best of both worlds in that the individual
> fibre arrays give me hardware fault tolerance, and the software RAID
> protects me if one of the fibre arrays fails. I've never lost a volume
> doing things this way and I've learned to trust this a lot more than any
> one
> piece of equipment that claims to be "fault tolerant".
>
> Is this a safe configuration for the shared quorum storage in a clustered
> environment?

> It seems to me that getting two computers to share just one
> logical volume is plenty difficult enough.

"Will" <westes-usc@noemail.nospam> wrote in message
news:O3pUeLQ3GHA.1608@TK2MSFTNGP04.phx.gbl...
>I haven't used Microsoft (or Veritas) clustering software before, and I
> would like to understand better whether certain disk configurations are
> allowed, or recommended.
>
> When working with a stand-alone server that is not going to be clustered,
> and the storage is mission critical, my normal instinct is to build a disk
> configuration on a fibre channel array that does RAID on the drives and
> presents a logical volume to the Windows OS over fibre channel. I then
> create a duplicate disk topology (separate fibre card, separate fibre
> switch, separate fibre array) and then use Windows RAID 1 to mirror
> between
> the two systems. I get the best of both worlds in that the individual
> fibre arrays give me hardware fault tolerance, and the software RAID
> protects me if one of the fibre arrays fails. I've never lost a volume
> doing things this way and I've learned to trust this a lot more than any
> one
> piece of equipment that claims to be "fault tolerant".
>
> Is this a safe configuration for the shared quorum storage in a clustered
> environment? It seems to me that getting two computers to share just one
> logical volume is plenty difficult enough. If I am going to use Windows
> software RAID to replicate that volume and then share the two separate but
> synchronized volumes with a cluster host, I can imagine lots of strange
> cases where the failover might not be clean at all. Is the configuration
> I
> use for stand-alone hosts even allowed for a cluster? If there are any
> guidelines on this I would appreciate seeing them.
>
> --
> Will
>
>

"Will" <westes-usc@noemail.nospam> wrote in message
news:O3pUeLQ3GHA.1608@TK2MSFTNGP04.phx.gbl...
>I haven't used Microsoft (or Veritas) clustering software before, and I
> would like to understand better whether certain disk configurations are
> allowed, or recommended.
>
> When working with a stand-alone server that is not going to be clustered,
> and the storage is mission critical, my normal instinct is to build a disk
> configuration on a fibre channel array that does RAID on the drives and
> presents a logical volume to the Windows OS over fibre channel. I then
> create a duplicate disk topology (separate fibre card, separate fibre
> switch, separate fibre array) and then use Windows RAID 1 to mirror
> between
> the two systems. I get the best of both worlds in that the individual
> fibre arrays give me hardware fault tolerance, and the software RAID
> protects me if one of the fibre arrays fails. I've never lost a volume
> doing things this way and I've learned to trust this a lot more than any
> one
> piece of equipment that claims to be "fault tolerant".
>
> Is this a safe configuration for the shared quorum storage in a clustered
> environment? It seems to me that getting two computers to share just one
> logical volume is plenty difficult enough. If I am going to use Windows
> software RAID to replicate that volume and then share the two separate but
> synchronized volumes with a cluster host, I can imagine lots of strange
> cases where the failover might not be clean at all. Is the configuration
> I
> use for stand-alone hosts even allowed for a cluster? If there are any
> guidelines on this I would appreciate seeing them.
>
> --
> Will
>
>

"Will" <westes-usc@noemail.nospam> wrote in message
news:O3pUeLQ3GHA.1608@TK2MSFTNGP04.phx.gbl...
>I haven't used Microsoft (or Veritas) clustering software before, and I
> would like to understand better whether certain disk configurations are
> allowed, or recommended.
>
> When working with a stand-alone server that is not going to be clustered,
> and the storage is mission critical, my normal instinct is to build a disk
> configuration on a fibre channel array that does RAID on the drives and
> presents a logical volume to the Windows OS over fibre channel. I then
> create a duplicate disk topology (separate fibre card, separate fibre
> switch, separate fibre array) and then use Windows RAID 1 to mirror
> between
> the two systems. I get the best of both worlds in that the individual
> fibre arrays give me hardware fault tolerance, and the software RAID
> protects me if one of the fibre arrays fails. I've never lost a volume
> doing things this way and I've learned to trust this a lot more than any
> one
> piece of equipment that claims to be "fault tolerant".
>
> Is this a safe configuration for the shared quorum storage in a clustered
> environment? It seems to me that getting two computers to share just one
> logical volume is plenty difficult enough. If I am going to use Windows
> software RAID to replicate that volume and then share the two separate but
> synchronized volumes with a cluster host, I can imagine lots of strange
> cases where the failover might not be clean at all. Is the configuration
> I
> use for stand-alone hosts even allowed for a cluster? If there are any
> guidelines on this I would appreciate seeing them.
>
> --
> Will
>
>

"John Fullbright [MVP]" <fjohn@donotspamnetappdotcom> wrote in message
news:#2qQoVb3GHA.5040@TK2MSFTNGP02.phx.gbl...
> If you're going to create the volume on a SAN, that why not use the SAN to
> do the Mirroring?

> When I do designs that require replicated storage, I
> leverage the replication technology of the SAN platform I work with
> (SnapMirror) In doing this, the replication design for either MSCS or VCS
> (with the agent for NetApp SNapMirror) is exactly same and independent of
> the clustering technology used. Before going down the route of something
> like VVR, which would in essense be dynamic disks, you may want to look at
> the MS support for Dynamic Disks in an MSCS environment. If you go
VVR/VCS,
> I suppose it doesn't much matter on the dynamic disks but you're locked
into
> one solution set. By leveraging the native replication of the SAN
platform,
> you keep all of your options open.

"Will" <westes-usc@noemail.nospam> wrote in message
news:DcCdnSMxWLnWh47YnZ2dnUVZ_rqdnZ2d@giganews.com...
> "John Fullbright [MVP]" <fjohn@donotspamnetappdotcom> wrote in message
> news:#2qQoVb3GHA.5040@TK2MSFTNGP02.phx.gbl...
>> If you're going to create the volume on a SAN, that why not use the SAN
>> to
>> do the Mirroring?
>
> I guess you have never had the experience of EMC doing a firmware upgrade
> and then losing the entire array for three days?
>
> Stuff happens. Having options via a fully redundant piece of hardware is
> usually not something you usually regret. Getting that redundancy via
> Windows software RAID is extremely cheap. Getting that redundancy via
> proprietary vendor products, software licenses, and hardware, is extremely
> extremely extremely expensive.
>
> Using Windows software RAID for clustering quorum storage however doesn't
> appear to be an option.
>
>
>> When I do designs that require replicated storage, I
>> leverage the replication technology of the SAN platform I work with
>> (SnapMirror) In doing this, the replication design for either MSCS or
>> VCS
>> (with the agent for NetApp SNapMirror) is exactly same and independent of
>> the clustering technology used. Before going down the route of something
>> like VVR, which would in essense be dynamic disks, you may want to look
>> at
>> the MS support for Dynamic Disks in an MSCS environment. If you go
> VVR/VCS,
>> I suppose it doesn't much matter on the dynamic disks but you're locked
> into
>> one solution set. By leveraging the native replication of the SAN
> platform,
>> you keep all of your options open.
>
> I guess I see it the opposite way. By going with Dynamic disks, I can
> use
> different vendors for storage, and commoditize their products as cheaper
> products become available. If I rely on one vendor for all of that
> capability, that one vendor holds me hostage and can be very unreasonable
> in
> negotiating additional licenses.
>
> --
> Will
>
>
>

"Will" wrote:

> "John Fullbright [MVP]" <fjohn@donotspamnetappdotcom> wrote in message
> news:#2qQoVb3GHA.5040@TK2MSFTNGP02.phx.gbl...
> > If you're going to create the volume on a SAN, that why not use the SAN to
> > do the Mirroring?
>
> I guess you have never had the experience of EMC doing a firmware upgrade
> and then losing the entire array for three days?
>
> Stuff happens. Having options via a fully redundant piece of hardware is
> usually not something you usually regret. Getting that redundancy via
> Windows software RAID is extremely cheap. Getting that redundancy via
> proprietary vendor products, software licenses, and hardware, is extremely
> extremely extremely expensive.
>
> Using Windows software RAID for clustering quorum storage however doesn't
> appear to be an option.
>
>
> > When I do designs that require replicated storage, I
> > leverage the replication technology of the SAN platform I work with
> > (SnapMirror) In doing this, the replication design for either MSCS or VCS
> > (with the agent for NetApp SNapMirror) is exactly same and independent of
> > the clustering technology used. Before going down the route of something
> > like VVR, which would in essense be dynamic disks, you may want to look at
> > the MS support for Dynamic Disks in an MSCS environment. If you go
> VVR/VCS,
> > I suppose it doesn't much matter on the dynamic disks but you're locked
> into
> > one solution set. By leveraging the native replication of the SAN
> platform,
> > you keep all of your options open.
>
> I guess I see it the opposite way. By going with Dynamic disks, I can use
> different vendors for storage, and commoditize their products as cheaper
> products become available. If I rely on one vendor for all of that
> capability, that one vendor holds me hostage and can be very unreasonable in
> negotiating additional licenses.
>
> --
> Will
>
>
>