|
Replies:
11
-
Last Post:
Feb 25, 2009 3:47 AM
by: gnr259
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
269
From:
US
Registered:
11/22/06
|
|
|
|
[ha-clusters-discuss] project colorado design documents available
for review
Posted:
Feb 13, 2009 2:59 PM
|
|
Hi folks,
The CLARC commitment review for project Colorado is scheduled for next
Thursday, February 19. See http://wiki.genunix.org/wiki/index.php/CLARC
for logistical details.
As such, the design documents are now available for review. See
http://www.opensolaris.org/os/project/colorado/Design/
There are four design documents. You should start with the "Main design."
The project team will appreciate feedback from anyone, not just CLARC
members. Please send your comments ahead of the CLARC meeting, if possible.
Thanks,
Nick
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
Posts:
460
From:
PL
Registered:
11/17/06
|
|
|
|
Re: [ha-clusters-discuss] project colorado design documents
available for review
Posted:
Feb 14, 2009 2:27 PM
in response to: nsolter
|
|
Hi,
from 'colorado-design-4.1.pdf':
"Unfortunately, NWAM is enabled by default in OpenSolaris. Two options
were considered:
1. Let scinstall check if NWAM is enabled when configuring the
cluster, and exit with an
error message telling the user to disable NWAM
2. Automatically disable the NWAM service when scinstall detects it
to be enabled."
I suggest option 1.
Automatically disable nwam would be also possible but not by default.
I think the best way is to add a new parameter to allow disable nwam
service.
On Fri, Feb 13, 2009 at 11:59 PM, Nicholas Solter
<Nicholas dot Solter at sun dot com> wrote:
> Hi folks,
>
> The CLARC commitment review for project Colorado is scheduled for next
> Thursday, February 19. See http://wiki.genunix.org/wiki/index.php/CLARC for
> logistical details.
>
> As such, the design documents are now available for review. See
> http://www.opensolaris.org/os/project/colorado/Design/
>
> There are four design documents. You should start with the "Main design."
>
> The project team will appreciate feedback from anyone, not just CLARC
> members. Please send your comments ahead of the CLARC meeting, if possible.
>
> Thanks,
> Nick
--
Regards,
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
460
From:
PL
Registered:
11/17/06
|
|
|
|
Re: [ha-clusters-discuss] project colorado design documents
available for review
Posted:
Feb 14, 2009 3:00 PM
in response to: estibi
|
|
Btw,
"2.7.2 Changes to Use Sun Studio 12 / Sun Studio Express
Sun Studio Express is the default compiler for OpenSolaris and
contains Studio12 plus new
features for the next Sun Studio release. Currently the code is built
with Studio 10 and switching
to Studio 12 and Studio Express required the following changes to the build:"
Studio 10? Should it be 'Studio 11'?
--
Regards,
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
102
From:
US
Registered:
6/1/07
|
|
|
|
Re: [ha-clusters-discuss] project colorado design
documents available for review
Posted:
Feb 17, 2009 11:46 AM
in response to: estibi
|
|
Hi Piotr,
Piotr Jasiukajtis wrote:
> Btw,
>
> "2.7.2 Changes to Use Sun Studio 12 / Sun Studio Express
> Sun Studio Express is the default compiler for OpenSolaris and
> contains Studio12 plus new
> features for the next Sun Studio release. Currently the code is built
> with Studio 10 and switching
> to Studio 12 and Studio Express required the following changes to the build:"
>
> Studio 10? Should it be 'Studio 11'?
Last year we switched our builds on Nevada from Studio 10 to Studio 11,
so yes it should be Studio 11.
Thanks for the feedback,
Jonathan
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
269
From:
US
Registered:
11/22/06
|
|
|
|
Re: [ha-clusters-discuss] project colorado design
documents available for review
Posted:
Feb 18, 2009 12:36 PM
in response to: jmellors
|
|
Jonathan Mellors wrote:
> Hi Piotr,
>
> Piotr Jasiukajtis wrote:
>> Btw,
>>
>> "2.7.2 Changes to Use Sun Studio 12 / Sun Studio Express
>> Sun Studio Express is the default compiler for OpenSolaris and
>> contains Studio12 plus new
>> features for the next Sun Studio release. Currently the code is built
>> with Studio 10 and switching
>> to Studio 12 and Studio Express required the following changes to the
>> build:"
>>
>> Studio 10? Should it be 'Studio 11'?
>
> Last year we switched our builds on Nevada from Studio 10 to Studio 11,
> so yes it should be Studio 11.
>
I've made this change, but I'll wait to see what other changes are
requested by CLARC before uploading a new version of the document.
Thanks,
Nick
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
269
From:
US
Registered:
11/22/06
|
|
|
|
Re: [ha-clusters-discuss] project colorado design documents
available for review
Posted:
Feb 18, 2009 12:32 PM
in response to: estibi
|
|
Piotr Jasiukajtis wrote:
> Hi,
>
> from 'colorado-design-4.1.pdf':
>
> "Unfortunately, NWAM is enabled by default in OpenSolaris. Two options
> were considered:
> 1. Let scinstall check if NWAM is enabled when configuring the
> cluster, and exit with an
> error message telling the user to disable NWAM
> 2. Automatically disable the NWAM service when scinstall detects it
> to be enabled."
>
> I suggest option 1.
> Automatically disable nwam would be also possible but not by default.
> I think the best way is to add a new parameter to allow disable nwam
> service.
>
Piotr,
Thanks for your comments. I really appreciate having some feedback from
non-Sun employees.
Option 1 is indeed what we implemented. I actually don't see much value
in option 2 because the user would still have to take the manual step of
configuring networking manually. So there's not much gained by just
disabling nwam.
Thanks,
Nick
> On Fri, Feb 13, 2009 at 11:59 PM, Nicholas Solter
> <Nicholas dot Solter at sun dot com> wrote:
>> Hi folks,
>>
>> The CLARC commitment review for project Colorado is scheduled for next
>> Thursday, February 19. See http://wiki.genunix.org/wiki/index.php/CLARC for
>> logistical details.
>>
>> As such, the design documents are now available for review. See
>> http://www.opensolaris.org/os/project/colorado/Design/
>>
>> There are four design documents. You should start with the "Main design."
>>
>> The project team will appreciate feedback from anyone, not just CLARC
>> members. Please send your comments ahead of the CLARC meeting, if possible.
>>
>> Thanks,
>> Nick
>
>
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
42
From:
Registered:
8/7/08
|
|
|
|
Re: [ha-clusters-discuss] project colorado design documents
available for review
Posted:
Feb 18, 2009 12:37 PM
in response to: nsolter
|
|
Comment below...
Nicholas Solter wrote:
> Piotr Jasiukajtis wrote:
>> Hi,
>>
>> from 'colorado-design-4.1.pdf':
>>
>> "Unfortunately, NWAM is enabled by default in OpenSolaris. Two options
>> were considered:
>> 1. Let scinstall check if NWAM is enabled when configuring the
>> cluster, and exit with an
>> error message telling the user to disable NWAM
>> 2. Automatically disable the NWAM service when scinstall detects it
>> to be enabled."
>>
>> I suggest option 1.
>> Automatically disable nwam would be also possible but not by default.
>> I think the best way is to add a new parameter to allow disable nwam
>> service.
>>
>
> Piotr,
>
> Thanks for your comments. I really appreciate having some feedback
> from non-Sun employees.
>
> Option 1 is indeed what we implemented. I actually don't see much
> value in option 2 because the user would still have to take the manual
> step of configuring networking manually. So there's not much gained by
> just disabling nwam.
>
> Thanks,
> Nick
When NWAM is turned off, any existing remote connections are broken. So,
if I'm not on actual console, but instead rsh'd in via an xterm, as soon
as NWAM is turned off my xterm disappears, also terminating scinstall
inself! Very rude to do this to users...
thx, --emk
>
>> On Fri, Feb 13, 2009 at 11:59 PM, Nicholas Solter
>> <Nicholas dot Solter at sun dot com> wrote:
>>> Hi folks,
>>>
>>> The CLARC commitment review for project Colorado is scheduled for next
>>> Thursday, February 19. See
>>> http://wiki.genunix.org/wiki/index.php/CLARC for
>>> logistical details.
>>>
>>> As such, the design documents are now available for review. See
>>> http://www.opensolaris.org/os/project/colorado/Design/
>>>
>>> There are four design documents. You should start with the "Main
>>> design."
>>>
>>> The project team will appreciate feedback from anyone, not just CLARC
>>> members. Please send your comments ahead of the CLARC meeting, if
>>> possible.
>>>
>>> Thanks,
>>> Nick
>>
>>
>>
>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
460
From:
PL
Registered:
11/17/06
|
|
|
|
Re: [ha-clusters-discuss] project colorado design documents
available for review
Posted:
Feb 14, 2009 3:49 PM
in response to: nsolter
|
|
Weak Membership design:
"6.4 To Switch from Weak to Strong membership model
1. In order to switch from Weak to Strong membership model, the
cluster must be fully
formed. In other words, both nodes must be up and both nodes must be
in the same cluster
partition. The transition cannot be done while the cluster is in a
split-brain condition.
2. Set the multiple_partitions property to false to switch to Strong
membership.
clq set -p multiple_partitions=false membership
3. Now add a quorum device (quorum server or a shared disk) to provide
high availability. Without a quorum device, any disconnect between
the cluster nodes or single
node failure will result in complete cluster panic.
clq add d3"
Well, I think 'clq add d3' should be in the first place so the proper
sequence would looks like:
# clq add d3
# clq set -p multiple_partitions=false membership
This prevents the cluster panic.
--
Regards,
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Sambit Nayak
Sambit.Nayak@Sun.COM
|
|
|
|
Re: [ha-clusters-discuss] project colorado design
documents available for review
Posted:
Feb 17, 2009 11:17 PM
in response to: estibi
|
|
Hi Piotr,
Thanks for the review. :)
The concept of "weak membership model" (which is equivalent to
multiple_partitions=true setting right now) has a requirement that the
cluster should have no quorum devices configured.
To put it differently, if there are any quorum devices configured, then
the cluster cannot be using "weak membership model"; it will be "strong
membership model".
So, the sequence of steps is as mentioned in the doc :
(i) first change to strong membership model by setting
multiple_partitions=false
(ii) add a quorum device for higher availability
I understand you are saying that if a node goes down in between steps
(i) and (ii) above, then there will be a loss of quorum.
But let me try to argue like this :
- going by the notion that weak membership means no quorum devices, the
CLI prevents addition of any quorum devices when cluster is running weak
membership. So how does CLI know that the user really intends to add a
quorum device with an intention to switch to strong membership?
- alternately, the software could have the behaviour that as soon as a
user adds a quorum device, the cluster switches to strong membership
automatically. But it is not very good to do such 'automated' actions
when we do not really know what the user was intending to do; I mean,
the user intends to do action1, but we also automatically perform
action2 additionally in the background.
- besides, removal of the last quorum device from a 2-node cluster is
anyway allowed under strong membership; let's trust the admin to know
what he/she is doing. :)
Hoping I could answer some of your queries...
Thanks & Regards,
Sambit
Piotr Jasiukajtis wrote:
> Weak Membership design:
>
> "6.4 To Switch from Weak to Strong membership model
> 1. In order to switch from Weak to Strong membership model, the
> cluster must be fully
> formed. In other words, both nodes must be up and both nodes must be
> in the same cluster
> partition. The transition cannot be done while the cluster is in a
> split-brain condition.
> 2. Set the multiple_partitions property to false to switch to Strong
> membership.
> clq set -p multiple_partitions=false membership
> 3. Now add a quorum device (quorum server or a shared disk) to provide
> high availability. Without a quorum device, any disconnect between
> the cluster nodes or single
> node failure will result in complete cluster panic.
> clq add d3"
>
> Well, I think 'clq add d3' should be in the first place so the proper
> sequence would looks like:
> # clq add d3
> # clq set -p multiple_partitions=false membership
>
> This prevents the cluster panic.
>
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
15
From:
DE
Registered:
10/3/08
|
|
|
|
Re: [ha-clusters-discuss] project colorado design
documents available for review
Posted:
Feb 18, 2009 7:09 AM
in response to: Sambit Nayak
|
|
My 2c:
Either give out a warning when one tries to change from weak to strong membership without an already defined quorum, e.g.
# clq set -p multiple_partitions=false membership
WARNING: Cluster has been set to strong membership, but no quorum defined....
Or we could combine the step of changing membership model and adding a quorum device (where -q would be optional):
# clq set -p multiple_partitions=false membership -q <quorumdevice>
Regards,
Rodger
On Wed, Feb 18, 2009 at 12:47:41PM +0530, Sambit Nayak wrote:
> Hi Piotr,
>
> Thanks for the review. :)
>
> The concept of "weak membership model" (which is equivalent to
> multiple_partitions=true setting right now) has a requirement that the
> cluster should have no quorum devices configured.
>
> To put it differently, if there are any quorum devices configured, then
> the cluster cannot be using "weak membership model"; it will be "strong
> membership model".
>
> So, the sequence of steps is as mentioned in the doc :
> (i) first change to strong membership model by setting
> multiple_partitions=false
> (ii) add a quorum device for higher availability
>
> I understand you are saying that if a node goes down in between steps
> (i) and (ii) above, then there will be a loss of quorum.
>
> But let me try to argue like this :
> - going by the notion that weak membership means no quorum devices, the
> CLI prevents addition of any quorum devices when cluster is running weak
> membership. So how does CLI know that the user really intends to add a
> quorum device with an intention to switch to strong membership?
> - alternately, the software could have the behaviour that as soon as a
> user adds a quorum device, the cluster switches to strong membership
> automatically. But it is not very good to do such 'automated' actions
> when we do not really know what the user was intending to do; I mean,
> the user intends to do action1, but we also automatically perform
> action2 additionally in the background.
> - besides, removal of the last quorum device from a 2-node cluster is
> anyway allowed under strong membership; let's trust the admin to know
> what he/she is doing. :)
>
> Hoping I could answer some of your queries...
>
> Thanks & Regards,
> Sambit
>
> Piotr Jasiukajtis wrote:
>> Weak Membership design:
>>
>> "6.4 To Switch from Weak to Strong membership model
>> 1. In order to switch from Weak to Strong membership model, the
>> cluster must be fully
>> formed. In other words, both nodes must be up and both nodes must be
>> in the same cluster
>> partition. The transition cannot be done while the cluster is in a
>> split-brain condition.
>> 2. Set the multiple_partitions property to false to switch to Strong
>> membership.
>> clq set -p multiple_partitions=false membership
>> 3. Now add a quorum device (quorum server or a shared disk) to provide
>> high availability. Without a quorum device, any disconnect between
>> the cluster nodes or single
>> node failure will result in complete cluster panic.
>> clq add d3"
>>
>> Well, I think 'clq add d3' should be in the first place so the proper
>> sequence would looks like:
>> # clq add d3
>> # clq set -p multiple_partitions=false membership
>>
>> This prevents the cluster panic.
>>
>>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Sambit Nayak
Sambit.Nayak@Sun.COM
|
|
|
|
Re: [ha-clusters-discuss] project colorado
design documents available for review
Posted:
Feb 19, 2009 3:44 AM
in response to: brownsen
|
|
Hi Rodger,
Thanks for the review.
Rodger Etz-Brown wrote:
> My 2c:
>
In a community, every 2c matters... thanks for the feedback :)
> Either give out a warning when one tries to change from weak to strong membership without an already defined quorum, e.g.
>
> # clq set -p multiple_partitions=false membership
> WARNING: Cluster has been set to strong membership, but no quorum defined....
>
I agree.
May be not print it as a "WARNING:" (after all, the software wants the
user to switch to strong membership first, and then add a quorum device).
We can say something like : "Cluster will use strong membership;
configure a quorum device to ensure high availability"
> Or we could combine the step of changing membership model and adding a quorum device (where -q would be optional):
>
> # clq set -p multiple_partitions=false membership -q <quorumdevice>
>
Though I am not familiar with the CLI part,
I think this may not align with the CLI design.
"clq set -p ..." changes a setting of a property (multiple_partitions)
while operating on the object "membership".
On the other hand, "clq add <quorumdevice>" operates on an object that
is a quorum device.
> Regards,
> Rodger
>
Thanks & Regards,
Sambit
> On Wed, Feb 18, 2009 at 12:47:41PM +0530, Sambit Nayak wrote:
>
>> Hi Piotr,
>>
>> Thanks for the review. :)
>>
>> The concept of "weak membership model" (which is equivalent to
>> multiple_partitions=true setting right now) has a requirement that the
>> cluster should have no quorum devices configured.
>>
>> To put it differently, if there are any quorum devices configured, then
>> the cluster cannot be using "weak membership model"; it will be "strong
>> membership model".
>>
>> So, the sequence of steps is as mentioned in the doc :
>> (i) first change to strong membership model by setting
>> multiple_partitions=false
>> (ii) add a quorum device for higher availability
>>
>> I understand you are saying that if a node goes down in between steps
>> (i) and (ii) above, then there will be a loss of quorum.
>>
>> But let me try to argue like this :
>> - going by the notion that weak membership means no quorum devices, the
>> CLI prevents addition of any quorum devices when cluster is running weak
>> membership. So how does CLI know that the user really intends to add a
>> quorum device with an intention to switch to strong membership?
>> - alternately, the software could have the behaviour that as soon as a
>> user adds a quorum device, the cluster switches to strong membership
>> automatically. But it is not very good to do such 'automated' actions
>> when we do not really know what the user was intending to do; I mean,
>> the user intends to do action1, but we also automatically perform
>> action2 additionally in the background.
>> - besides, removal of the last quorum device from a 2-node cluster is
>> anyway allowed under strong membership; let's trust the admin to know
>> what he/she is doing. :)
>>
>> Hoping I could answer some of your queries...
>>
>> Thanks & Regards,
>> Sambit
>>
>> Piotr Jasiukajtis wrote:
>>
>>> Weak Membership design:
>>>
>>> "6.4 To Switch from Weak to Strong membership model
>>> 1. In order to switch from Weak to Strong membership model, the
>>> cluster must be fully
>>> formed. In other words, both nodes must be up and both nodes must be
>>> in the same cluster
>>> partition. The transition cannot be done while the cluster is in a
>>> split-brain condition.
>>> 2. Set the multiple_partitions property to false to switch to Strong
>>> membership.
>>> clq set -p multiple_partitions=false membership
>>> 3. Now add a quorum device (quorum server or a shared disk) to provide
>>> high availability. Without a quorum device, any disconnect between
>>> the cluster nodes or single
>>> node failure will result in complete cluster panic.
>>> clq add d3"
>>>
>>> Well, I think 'clq add d3' should be in the first place so the proper
>>> sequence would looks like:
>>> # clq add d3
>>> # clq set -p multiple_partitions=false membership
>>>
>>> This prevents the cluster panic.
>>>
>>>
>>>
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
8
From:
Bangalore
Registered:
4/10/07
|
|
|
|
Re: [ha-clusters-discuss] project colorado
design documents available for review
Posted:
Feb 25, 2009 3:47 AM
in response to: brownsen
|
|
Hi Rodger,
Thanks a ton for reviewing the command line design. Please find my
answers inlined ..
Rodger Etz-Brown wrote:
> My 2c:
>
> Either give out a warning when one tries to change from weak to strong membership without an already defined quorum, e.g.
>
> # clq set -p multiple_partitions=false membership
> WARNING: Cluster has been set to strong membership, but no quorum defined....
>
>
This is will be a good way to let know the user what he/she is about to
do and there could be a potential outage if the quorum device is not
added any sooner. I shall make this fix.
> Or we could combine the step of changing membership model and adding a quorum device (where -q would be optional):
>
> # clq set -p multiple_partitions=false membership -q <quorumdevice>
>
>
This will be against the general object oriented command line policy.
Each command is designed to do operations on a
specific object. Hence we we need to add to quorum device to the
cluster, we need to use the "clq" command and use the "add" operation
with the operand being the new "quorum device".
Hope this answers your query !
> Regards,
> Rodger
>
> On Wed, Feb 18, 2009 at 12:47:41PM +0530, Sambit Nayak wrote:
>
>> Hi Piotr,
>>
>> Thanks for the review. :)
>>
>> The concept of "weak membership model" (which is equivalent to
>> multiple_partitions=true setting right now) has a requirement that the
>> cluster should have no quorum devices configured.
>>
>> To put it differently, if there are any quorum devices configured, then
>> the cluster cannot be using "weak membership model"; it will be "strong
>> membership model".
>>
>> So, the sequence of steps is as mentioned in the doc :
>> (i) first change to strong membership model by setting
>> multiple_partitions=false
>> (ii) add a quorum device for higher availability
>>
>> I understand you are saying that if a node goes down in between steps
>> (i) and (ii) above, then there will be a loss of quorum.
>>
>> But let me try to argue like this :
>> - going by the notion that weak membership means no quorum devices, the
>> CLI prevents addition of any quorum devices when cluster is running weak
>> membership. So how does CLI know that the user really intends to add a
>> quorum device with an intention to switch to strong membership?
>> - alternately, the software could have the behaviour that as soon as a
>> user adds a quorum device, the cluster switches to strong membership
>> automatically. But it is not very good to do such 'automated' actions
>> when we do not really know what the user was intending to do; I mean,
>> the user intends to do action1, but we also automatically perform
>> action2 additionally in the background.
>> - besides, removal of the last quorum device from a 2-node cluster is
>> anyway allowed under strong membership; let's trust the admin to know
>> what he/she is doing. :)
>>
>> Hoping I could answer some of your queries...
>>
>> Thanks & Regards,
>> Sambit
>>
>> Piotr Jasiukajtis wrote:
>>
>>> Weak Membership design:
>>>
>>> "6.4 To Switch from Weak to Strong membership model
>>> 1. In order to switch from Weak to Strong membership model, the
>>> cluster must be fully
>>> formed. In other words, both nodes must be up and both nodes must be
>>> in the same cluster
>>> partition. The transition cannot be done while the cluster is in a
>>> split-brain condition.
>>> 2. Set the multiple_partitions property to false to switch to Strong
>>> membership.
>>> clq set -p multiple_partitions=false membership
>>> 3. Now add a quorum device (quorum server or a shared disk) to provide
>>> high availability. Without a quorum device, any disconnect between
>>> the cluster nodes or single
>>> node failure will result in complete cluster panic.
>>> clq add d3"
>>>
>>> Well, I think 'clq add d3' should be in the first place so the proper
>>> sequence would looks like:
>>> # clq add d3
>>> # clq set -p multiple_partitions=false membership
>>>
>>> This prevents the cluster panic.
>>>
>>>
>>>
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
