Firstly, apologies for the length of this post, however I thought it
probably most useful to fully outline the challenge and the desired
result...
Ok, so we're in the process of Puppetizing our Oracle/NetApp platform for
Live/DR running.
The current manual process, upon setting up a new database, a set of
volumes are created to contain the various Oracle DB elements, and these
are then SnapMirror'd to the DR site.
This SnapMirror process requires a period of time to copy the base data
over... This time period is directly relational to the amount of data
required... I.e. a copy of 20Gb may take an hour, 200Gb may take 10
hours...
During this period, the SnapMirror resource is in an 'initializing' state.
Once the data copy is complete, then the resource will change to an
'initialized' state.
The next step in the process is then to break the relationship so that the
DR end can be used in a R/W mode...
Now, in order to Puppetize this, I need to be able to replicate the above
behaviour...
I've got Puppet to create and initialize the relationship, and that works
as expected. However Puppet doesn't currently care about the relationship
state. Now that's easy enough to add in as a new property against the
type/provider.
However what I'm struggling to understand is how, or if it's even possible,
to automate the switch from 'Initialized' state to a 'Broken' state upon
completion of the initialization stage???
Now these databases definitions are currently driven from a YAML backend
which maintains information such as database name, volume information,
primary netapp controller, replication netapp controller, etc... Currently,
this YAML file is just a file on the puppet master... However there are
ambitions to move this into a more dynamic backend, such as CouchDB or
similar... So that opens the possibility to automatically update the YAML
resource state.. However Puppet still needs to be able to support updating
that backend based on the information it gets from the actual resource...
So to flow it out:
1. Create a new database in backend ->
2. Puppet creates volumes on primary ->
3. Data is added to volumes ->
4. Backend updated to indicate replication is required ->
5. Puppet creates volumes on Secondary and adds Snapmirror relationship
->
6. Snapmirror initializes in background ->
7. Puppet periodically runs against network device and checks resource
state ->
8. Backend resource state is updated following each run? ->
9. Snapmirror initialization completes ->
10. Puppet runs, detects new resource state and then triggers break?
11. Backend resource state updated to 'broken'?
Now 1 to 7 above are fine, but 8 to 11 are where I get a bit unsure...
So, that's the challenge... Am I barking up the wrong tree, or is this
something that Puppet could manage?
Cheers in advance for any responses.
Regards
Gavin
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.