Topic
  • 4 replies
  • Latest Post - ‏2012-04-11T13:41:23Z by seroyer
Holgervk
Holgervk
14 Posts

Pinned topic death partition mobility

‏2012-04-05T10:50:17Z |
Hello,

for systems where PowerHA is too expensive, but a (simple) desaster protection is necessary we do the following:

Production system in data center 1. Storage mirrored to data center 2.
Test system in datacenter 2.
DR lpar in datacenter 2. Normally switched off. In case of data center 1 failure, test system in DC2 is switched off (to free up cpu/memory ressources) and this DR lpar is switched on.

I think this is a quite common setup.

Now, with NPIV, we have to configure the storage to all virtual fc adapters on the production system (DC1) and on the DR lpar (DC2).

It would be easier if I could simply use the wwpn of the production system on the DR lpar (as both are newer turned on simultaneously).
It might be possible to configure those (prod systems) wwpn on the DR lpar, but I dont want to do this. I dont want to risk having a wwn/wwpn two times in the san.

What would be great is kind of death partition mobility, where, in case of a desaster, I tell ios to move/start the prodution lpar of DR1 in DR2.
Then I would not even need a DR lpar in DC2, nor have its wwpn configured in the san.

Did anybody ever try this?
Am I overseeing something or should that work?

(There is a HMC in DC1 and one in DC2 and both see all managed systems).

Regs, Holger
Updated on 2012-04-11T13:41:23Z at 2012-04-11T13:41:23Z by seroyer
  • j.gann
    j.gann
    53 Posts

    Re: death partition mobility

    ‏2012-04-07T12:01:40Z  
    what you call "death pm" is actually an "inactive migration".
    but: in case of disaster, can you count on having a working system in DC1 to serve as a source? I'd say no.

    greets
    Joachim
  • Holgervk
    Holgervk
    14 Posts

    Re: death partition mobility

    ‏2012-04-07T23:13:25Z  
    • j.gann
    • ‏2012-04-07T12:01:40Z
    what you call "death pm" is actually an "inactive migration".
    but: in case of disaster, can you count on having a working system in DC1 to serve as a source? I'd say no.

    greets
    Joachim
    >in case of disaster, can you count on having a working system in DC1 to serve as a source

    No, I wouldnt. However, I would have a hmc in DC2 knowing the managed systems in DC1.
    I assum that would not be enough, however.
  • j.gann
    j.gann
    53 Posts

    Re: death partition mobility

    ‏2012-04-10T05:18:14Z  
    • Holgervk
    • ‏2012-04-07T23:13:25Z
    >in case of disaster, can you count on having a working system in DC1 to serve as a source

    No, I wouldnt. However, I would have a hmc in DC2 knowing the managed systems in DC1.
    I assum that would not be enough, however.
    ok, the hmc only stores a backup of the profile data of the systems it manages (see bkprofdata, rstprofdata). early p7 adopters with redundant hmcs will probably know the commands...
    I have not tested a restore of profile data to a different managed system (-m target system -f backup from different system) but even though this might work, I'd not build a production DR procedure on this somewhat "thin ice" of using the hmc appliance where you have restricted access for something not clearly supported and documented. how about writing your own script to query and recreate partition profiles? (lssyscfg, mksyscfg), that's what many customers use to create lpars efficiently in the first place.

    Greets
    Joachim Gann
  • seroyer
    seroyer
    352 Posts

    Re: death partition mobility

    ‏2012-04-11T13:41:23Z  
    Have you looked into VMControl? Standard and Enterprise Editions have support for "relocation" which is is the same as "mobility". In the installation and user's guide, it shows things like "Relocate all virtual servers on predicted failure" and "Relocation automation".

    Steve