Re: Physical disk and cluster groups
- From: "Edwin vMierlo [MVP]" <EdwinvMierlo@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 22 Jul 2008 16:38:33 +0100
and ensure your clients are connecting to the Hostname in the group
(NOT to the cluster name, and NOT to the node names)
"Tim Walsh" <tmwalsh@xxxxxxx> wrote in message news:exShp8A7IHA.3696@xxxxxxxxxxxxxxxxxxxxxxx
You should add an IP Resource to each group. The cluster will work without it, but the group is unable to respond to a network failure that would be expected to fail the group over to the other node. Best practice is to have an IP Address and Hostname in each group on the cluster.
"Mike" <mike.brester@xxxxxxxxxxxxxx> wrote in message news:%23G6DeiA7IHA.2416@xxxxxxxxxxxxxxxxxxxxxxx
So with my current setup for clustering we already have a group called Cluster group that has the IP assigned and virtual name to it. You had mentioned I would need to assign the IP to my projects group in one of the posts. Well if I already have this assigned some place else I do not need to do this do I?
"Edwin vMierlo [MVP]" <EdwinvMierlo@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:eQkemx%236IHA.3652@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>> You can create the group as indicated, but keep in mind a couple potential
>> gotchas:
>>
>> 1) With all your disk and shares in one group your limiting yourself to
> an
>> active-passive arrangement. We did it this way for years, without a
> problem,
>> but the ability to go to an active-active configuration should load demand
>> is a good thing as well.
>
> agreed
>
>>
>> 2) The projects Group will need to have an IP Address and Network Name
>> resources as well as the Physical Disks and File Shares. If you omit this
>> step and you subsequently lose network connectivity on the active node,
> the
>> Cluster Group will fail over to the passive node, however the Projects
> Group
>> will remain on the active node and the Users won't be able to connect to
> it.
>> (Voice of experience here)
>
> yes, but stronger: a group called "Projects Group" which contains FileShare
> resources MUST have an IP and Network Name resource, as this will be THE
> network name your users will have to connect to.
>
>>
>> 3) When a disk or share fails, consider what you want to happen carefully.
>> Do you want it to affect the group or just try to restart. Keep in mind if
>> the Projects Group fails over, it might not bring the Cluster Group with
> it,
>> meaning the Users again won't be able to connect to the file shares.
>
> hold on a minute !
>
> if "Projects Group" fails over, it SHOULD NEVER bring the Cluster Group with
> it, unless the "fault" is also affecting the IsAlive or LooksAlive of a
> resource in the Cluster group.
>
> Groups are individual "units of failover" and are not interdependent.
>
> The whole point of unable to connect is academic, already answered in item 2
> above. The group containing FileShare resources MUST containg an IP and
> network name, hence the users can re-connect to this Network Name when the
> "Project Group" fails over or moves from node to node.
>
>>
>> We went with a single group for each Physical Disk, added the shares for
>> that disk to the Group. We also added IP Addresses and Network names to
> each
>> group. If I'm not mistaken this is the setup Microsoft recommends as a
> best
>> practice.
>
> That is indeed how you do it !
>
>> We then changed our login script to map to the groups Network name
>> and not the Cluster Name.
>
> Never use the "Cluster Name" for client connections... ever !
> (One exception: cluster administartor)
>
> Rgds,
> Edwin.
>
>
>
>
>
>>This way, should a group fail over to the other
>> node, the users remains connected. We still run Active-Passive, and you
> can
>> still see all the drives by calling up the cluster name, so we were able
> to
>> transition the log in script slowly over to the new names. One benefit we
>> saw immediately was that the failover appears to be much quicker with this
>> configuration, since only one disk per group has to come up before the
>> shares start turning back on.
>>
>> "Mike" <mike.brester@xxxxxxxxxxxxxx> wrote in message
>> news:uOAW2636IHA.4108@xxxxxxxxxxxxxxxxxxxxxxx
>> > Ok so I am getting ready to migrate to a new SAN. I have a couple of the
>> > posts on here in regards to moving my Quorum and msdtc. My question now
>> > comes with I want to have multiple disks in 1 group. For example. The
>> > cluster server I am migrating is a file server. So we currently have a
>> > group for projects. Managment wants us to break things out a little more
>> > for the specific groups in our office working on different types of
>> > projects. We are an architectural firm so I would like to break things
>> > down something like this.
>> > Projects Group
>> > Disk T Physical Disk
>> > Disk U Physical Disk
>> > Disk V Physical Disk
>> > International Share (File Share)
>> > Commercial Share Share (File Share)
>> > Retail Share (File Share)
>> >
>> > Is this something that is approved in clustering?
>> >
>> > Each of these disks would be presented to my server as their own disk
> but
>> > then all mounted together so when I put it in my log script the end user
>> > will see the same as they have always been seeing.
>> >
>> > Thanks
>> >
>>
>>
>
>
- Follow-Ups:
- Re: Physical disk and cluster groups
- From: Mike
- Re: Physical disk and cluster groups
- References:
- Physical disk and cluster groups
- From: Mike
- Re: Physical disk and cluster groups
- From: Tim Walsh
- Re: Physical disk and cluster groups
- From: Edwin vMierlo [MVP]
- Re: Physical disk and cluster groups
- From: Mike
- Re: Physical disk and cluster groups
- From: Tim Walsh
- Physical disk and cluster groups
- Prev by Date: Re: Paging File Location
- Next by Date: Re: Paging File Location
- Previous by thread: Re: Physical disk and cluster groups
- Next by thread: Re: Physical disk and cluster groups
- Index(es):
Relevant Pages
|
