Re: [Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions
On 3/28/07, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: > > On Mar 22, 2007, at 2:13 AM, Alan Robertson wrote: > >> Doug Knight wrote: >>> Hi Andrew, >>> I had just started reviewing both of thes scripts, and reviewed the >>> Multistate and clone resource pages on the web site. It looks like >>> multistate is how I need to handle it, but a couple of questions first. >>> >>> 1. I noticed that the write-up says the resource must come up on each of >>> the servers in "shadow" mode first, then one gets promoted. Does this >>> imply a "start" on both servers, and the OCF start function determining >>> which server is active vs shadow (I'm picturing a check in the OCF >>> script to determine postgresql standby mode = shadow/crm_master value >>> low, and postgresql active mode = active/crm_master value high), then a >>> promote to the active server? >>> >>> 2. I noticed that the drbd OCF script contains a "notify" function, >>> where the Stateful OCF script does not. The notify function looks to be >>> where the important actions are taken (calling drbd_start_phase_2, >>> pre/post, etc). Is the notify function necessary, or is it sufficient in >>> my case to handle it through the start|stop|promote|demote functions? >>> >>> Thanks for your help, >>> Doug >> >> Andrew's out for a while. >> >> The start function starts you up in slave/secondary mode. All resources >> initially start up in "slave" mode. >> >> A set of servers is chosen to run the resources on (it might be one, >> two, the whole set, etc. depending on clone_max and clone_node_max and >> the usual constraints). >> >> They are started on the selected nodes using "start" >> >> During the start operation, you are given the chance to declare yourself >> ready to become master or not by using the crm_master command line tool. >> >> I believe that your resource can run that command any time they like - >> for example at a monitor operation... But, it is mandatory that they >> run it when they first start up. > > mandatory in the sense that nothing will get promoted until someone, > somewhere runs it. > but the exact timing is completely up to the user/admin/RA... it is even > possible to run it manually if you have to I originally assumed what you said, but the docs contradict that by calling it mandatory (and not qualifying the term). And the code seems to indicate that you can ONLY run it from an RA. if you know which OCF environment variables to set, then you can potentially run it from anywhere... but most people wont need to run it outside of the RA ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions
Andrew Beekhof wrote: > > On Mar 22, 2007, at 2:13 AM, Alan Robertson wrote: > >> Doug Knight wrote: >>> Hi Andrew, >>> I had just started reviewing both of thes scripts, and reviewed the >>> Multistate and clone resource pages on the web site. It looks like >>> multistate is how I need to handle it, but a couple of questions first. >>> >>> 1. I noticed that the write-up says the resource must come up on each of >>> the servers in "shadow" mode first, then one gets promoted. Does this >>> imply a "start" on both servers, and the OCF start function determining >>> which server is active vs shadow (I'm picturing a check in the OCF >>> script to determine postgresql standby mode = shadow/crm_master value >>> low, and postgresql active mode = active/crm_master value high), then a >>> promote to the active server? >>> >>> 2. I noticed that the drbd OCF script contains a "notify" function, >>> where the Stateful OCF script does not. The notify function looks to be >>> where the important actions are taken (calling drbd_start_phase_2, >>> pre/post, etc). Is the notify function necessary, or is it sufficient in >>> my case to handle it through the start|stop|promote|demote functions? >>> >>> Thanks for your help, >>> Doug >> >> Andrew's out for a while. >> >> The start function starts you up in slave/secondary mode. All resources >> initially start up in "slave" mode. >> >> A set of servers is chosen to run the resources on (it might be one, >> two, the whole set, etc. depending on clone_max and clone_node_max and >> the usual constraints). >> >> They are started on the selected nodes using "start" >> >> During the start operation, you are given the chance to declare yourself >> ready to become master or not by using the crm_master command line tool. >> >> I believe that your resource can run that command any time they like - >> for example at a monitor operation... But, it is mandatory that they >> run it when they first start up. > > mandatory in the sense that nothing will get promoted until someone, > somewhere runs it. > but the exact timing is completely up to the user/admin/RA... it is even > possible to run it manually if you have to I originally assumed what you said, but the docs contradict that by calling it mandatory (and not qualifying the term). And the code seems to indicate that you can ONLY run it from an RA. -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions
On 2007-03-22T13:24:02, Doug Knight <[EMAIL PROTECTED]> wrote: Hi, I've been out a bit myself but now want to answer this. > Hi Alan, > I took a look at the drbd OCF script's notify function, and the online > documentation. I believe there is one circumstance where I need to make > use of the pre/post notify. The reason why drbd calls update_prefs (ie, crm_master) in the post(-start) notification, and not within start itself, is that by that time, start will have been completed on all (one or both) nodes. That means that by that time, it's safe to figure out which side is preferable for becoming master. > The last step in my development/testing has > to do with several steps I take to prepare the server that was primary > and is now becoming standby. First, the primary gets demoted, right? Yes. > Then the secondary gets promoted. The problem I have is that part of the > process of preparing the new standby requires that the new active server > process is up and accessible. If the demote has to complete before the > promote can begin, I cannot do the rsync in the demote, because the > promote hasn't started and placed the new primary in an accessible > state. That seems to be true for your scenario, yes. > So, if I understand the notify function, then I need a "post" process > section that looks for the master going "active" and accessible, so I > can do the rsync and start up the new standby, right? That you could do. The instances will get a post-promote notification, which could do what you want. > Can you expand a little on the notify processing? The web page just > lists the variables involved, and the drbd OCF script only makes use > of a few of them, and I need a more detailed explanation of how and > when they are used. Well, you get a pre-notification before start/stop/promote/demote happen anywhere and a post-notification after they have completed everywhere. That's basically the gist of it. Does that make it clearer, or do you have a specific question? Sincerely, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions
On Mar 22, 2007, at 2:13 AM, Alan Robertson wrote: Doug Knight wrote: Hi Andrew, I had just started reviewing both of thes scripts, and reviewed the Multistate and clone resource pages on the web site. It looks like multistate is how I need to handle it, but a couple of questions first. 1. I noticed that the write-up says the resource must come up on each of the servers in "shadow" mode first, then one gets promoted. Does this imply a "start" on both servers, and the OCF start function determining which server is active vs shadow (I'm picturing a check in the OCF script to determine postgresql standby mode = shadow/crm_master value low, and postgresql active mode = active/crm_master value high), then a promote to the active server? 2. I noticed that the drbd OCF script contains a "notify" function, where the Stateful OCF script does not. The notify function looks to be where the important actions are taken (calling drbd_start_phase_2, pre/post, etc). Is the notify function necessary, or is it sufficient in my case to handle it through the start|stop|promote|demote functions? Thanks for your help, Doug Andrew's out for a while. The start function starts you up in slave/secondary mode. All resources initially start up in "slave" mode. A set of servers is chosen to run the resources on (it might be one, two, the whole set, etc. depending on clone_max and clone_node_max and the usual constraints). They are started on the selected nodes using "start" During the start operation, you are given the chance to declare yourself ready to become master or not by using the crm_master command line tool. I believe that your resource can run that command any time they like - for example at a monitor operation... But, it is mandatory that they run it when they first start up. mandatory in the sense that nothing will get promoted until someone, somewhere runs it. but the exact timing is completely up to the user/admin/RA... it is even possible to run it manually if you have to After this, heartbeat will try and promote as many of these resources as is consistent with its configured properties, and the crm_master commands that were run. The notify command tells you when your peers come and go. Do you need to take actions if you know this? If so, then you need to implement the notify actions... -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
