Delphix Products

Expand all | Collapse all

During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

Mayank Ahluwalia

Mayank Ahluwalia03-15-2019 01:33:00 PM

Mayank Ahluwalia

Mayank Ahluwalia03-15-2019 02:00:00 PM

  • 1.  During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 11:30:00 AM
    Assume I have a Virtualization Engine (Engine V) and a masking engine (Engine M). Both are in the same subnet and hence reachable.

    I want to provision a vDB from a dSource using Engine V, but I want to mask the vDB before it is released post provisioning.

    Can I attach/link, masking jobs that reside on Engine M to the vDB provisioning that will happen on Engine V ?
    #Virtualization


  • 2.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:03:00 PM
    Hi Mayank,

    You sure can.  In fact this is considered a best practice approach - separating the virt engines from the masking engines.

    Using the CLI on the virt engine:

    MyEngine> maskingjob
    MyEngine maskingjob> serviceconfig
    MyEngine maskingjob serviceconfig> select 'MASKING_SERVICE_CONFIG-1
    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1'> update
    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1' update *> ls

    You'll see a list of all the configurable parameters here.  It's "server" you need to update - currently it will be set to localhost.  And maybe username and password (of the masking engine).

    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1' update *> set server=
    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1' update *> set credentials.password=
    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1' update *> set username=
    MyEngine maskingjob serviceconfig 'MASKING_SERVICE_CONFIG-1' update *> commit

    Once you've updated the host, username and password you can check to see if it is working:

    MyEngine maskingjob> fetch
    MyEngine maskingjob fetch *> commit
    MyEngine maskingjob> ls
    You should see a list of all available masking jobs.

    Cheers

    Matt


  • 3.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:07:00 PM
    Thank you Matt. Understood.

    Another question - Assume the DB is huge and that masking is split across more than 1 masking engine. So, is it possible to retrieve a list of jobs from more than 1 engine for each dSource ?

    Regards,
    Mayank


  • 4.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:26:00 PM
    It's not possible to attach more than one job to a VDB, which you would have if using the distributed execution model.  Therefore, in this scenario and any other that involves multiple jobs, you should use either the masking scheduler or a better solution, the API to script the job execution.

    If you're not comfortable with the API, use dmxtoolkit instead.


  • 5.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:29:00 PM
    By the way, there's a typo in my first post but I can't edit it.

    MyEngine maskingjob serviceconfig> select 'MASKING_SERVICE_CONFIG-1'

    should be

    MyEngine maskingjob serviceconfig> select 'MASKING_SERVICE_CONFIG-1


  • 6.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:33:00 PM
    Thanks Matt...is there a plan to implement this feature ?


  • 7.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:39:00 PM
    Hopefully one of the internal guys can answer that Mayank.  I'm interested to know the answer myself!


  • 8.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?
    Best Answer

    Posted 03-15-2019 01:55:00 PM
    Thanks for your response Matt.  This issue is also addressed in detail in another post.
    https://community.delphix.com/delphix/topics/cannot-associate-masking-job-to-dsource

    With regard to associating multiple masking jobs to a VDB - this has been raised a number of times in a number of guises, but is not yet on the roadmap.  The answer currently is to use the Masking API and scripting.
    Regards,
    Gary


  • 9.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 01:59:00 PM
    Hi Matt,
    I removed the trailing apostrophe in your select statement. If that was in error, please let me know. I don't usually edit posts, indeed, I am opposed to doing so, but in this case it seemed like I should.
    Please let me know if you are alright with the update.
    Thanks,
    Michael


  • 10.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 02:00:00 PM
    Thanks Gary :)


  • 11.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 03:06:00 PM
    Thanks Michael. Can you change the first apostrophe to a prime symbol as well please. (Not being able to edit posts is frustrating :-))


  • 12.  RE: During vDB provisioning, can masking jobs that reside on another engine than the one from which we will provision the vDB, be linked ?

    Posted 03-15-2019 03:27:00 PM
    Yes, sir. And, yes, understood.
    Total aside: We are actively looking at a new platform which will definitely be more flexible. I'll keep you posted on that.