SLD change

[former_member233435]

Hello,

We need to change SLD layout from what is depicted on the left side on the picture below to the solution depicted on the right side.

The reason for this is that services in SAP Landscape that depend on SLD are stopped during Solution Manager maintenance/restart. I read SLD documentation and based on it I proposed solution (right side of picture) that will allow continuous availability of services in SAP Landscape during Solution Manager maintenance/restart.

I do not have experience with SLD so I would like to know what do you think about this solution.

Also, what would be correct steps to make this transition? I would say I should have to install central SLD first and then sync it with local SLD on Solution Manager, then redirect data suppliers of systems in SAP Landscape to central SLD. Later I can add backup SLD and sync it with central SLD. Can cutoff from Local SLD be done in such way or should I stop local SLD until I redirect data suppliers?

Regards,

Sasha

[Matt_Fraser · Accepted solution]

Hi Sasha,

I'm in the middle of doing this exact thing myself right now, for the same reasons you outline.  I'm separating our central SLD from Solution Manager.  I'm not finished yet, about halfway through the process, but from what I've read and what I've achieved so far, I think you have the gist of it.  Your outline looks reasonable to me.  I don't think you need to actually maintain a local SLD on Solution Manager anymore once you have migrated all the content and repointed all the data suppliers to your new central SLD.  You can configure LMDB to synchronize from a remote SLD, so once that last step is done, I think you can just 'abandon' the old local SLD on SolMan entirely.

So, here is what I've done so far:

1. Install new AS Java (version 7.4 SR1)
   1. Temporarily register it in existing 'old' SLD
2. Update AS Java to sps7
3. Enable SSL, create administrative users
   1. Configuring the Use of SSL on the AS Java - Network and Transport Layer Security - SAP Library
4. Initially configure new SLD
   1. Post-Installation Checklist - Configuring, Working with and Administering System Landscape Directory...
   2. Configuring System Landscape Directory - AS Java Configuration - SAP Library
      1. This included this step, and using it to configure the "System Landscape Directory" functional unit only:
         1. Java Functional Unit Configuration - SAP NetWeaver Library: Function-Oriented View - SAP Library
5. Migrate content from old SLD to new SLD (this is the step I'm in the middle of right now)

Once the initial unidirectional content sync is complete, the next steps will be:

1. Enable bidirectional content sync
2. Configure LMDB to sync with new SLD
3. Configure data suppliers to sync to new SLD
4. Disable bidirectional content sync

This method can be used to setup your backup SLD later as well, except you don't have to reconfigure LMDB or data suppliers, just install and set up the content sync.  In that circumstance, you may want to explore using a Virtual IP address as well.

Regards,

Matt

[Matt_Fraser · Accepted solution]

One last comment about the initial unidirectional content sync.  I was a little afraid it would cause so much load on the old SLD that web dynpro applications, such as ESS, would be impacted, but I haven't seen that to be the case.  ESS and a custom application we have both seem to keep operating just fine, so this can be a business hours operations, it seems.  It seems like it will take 1-2 hours total for the initial sync to complete for us (at 74% as I write this).

[former_member233435 · Accepted solution]

Hi Matt,

Thank you for sharing your experience, I really appreciate that. I am glad I am on the right track.

Cheers,

Sasha

[Matt_Fraser · Accepted solution]

I have an update about the content sync.  It appears that 's video demo (which is the only documentation I've found on this topic) assumes that you are using SLD's on both ends of the sync that are 7.1 or higher, which won't be the case when migrating from Solution Manager's local SLD (it's a 7.02 SLD at highest).  So, the unidirectional sync works just fine -- it took about an hour for mine, and everything came across just fine -- but there is no bidirectional sync.  This morning I removed the unidirectional sync connection with the intent of creating a new bidirectional sync, and I found that it would not do it; it always reverts back to unidirectional.  I assume this is because the source SLD, being on v7.02, isn't capable of receiving synchronized content, only of sending it.  So now I'm stuck repeating the unidirectional full sync.  I had hoped it would recognize that all the data already existed on the target and quickly go to incremental mode, but that didn't happen.

So this means step 1 of the 2nd part of my outline above is not relevant here.  It also means that we will definitely need to point the LMDB to the new SLD before pointing any of the data suppliers to it, otherwise there is a potential for missed data updates.

UPDATE:  To be fair, Wolf actually mentions in his written intro to the demo that his scenario is two SLDs both on 7.1, and that 7.0 sp12 and higher SLDs can be a source for unidirectional syncs.  I guess I just didn't read that carefully enough beforehand.

Message was edited by: Matt Fraser

[Matt_Fraser · Accepted solution]

Ok, I guess the 2nd time around the sync did recognize that the data was there, as it was much faster (about 10-15 minutes).

[former_member233435 · Accepted solution]

Hi Matt,

Great! Let me know when you finish how did everything go.

Regards,

Sasha

[Matt_Fraser · Accepted solution]

Hi Sasha,

I'm afraid I got a little sidetracked in my project by other operational concerns that came up. However, of the 'future' steps that I had listed above, 1 and 2 (enable unidirectional content sync and configure LMDB to sync with new SLD) are complete, no issues encountered. Step 3, configuring data suppliers to sync with the new SLD turned out to be problematic, and I was working on this issue when I got redirected by other realities in my office. I just returned to resolving it this past week, and have now done so.

The hold-up was that I hadn't seen any explicit documentation (except in Notes uncovered after I encountered the problem) about a change in the default behavior of the gateway with regard to permitting external systems to register with it. Solution Manager included its own SLD originally, of course, and it was on NetWeaver release 7.02, so the default behavior was to allow all external systems to register against the SLD_UC and SLD_NUC program IDs (equivalent to the profile parameter gw/acl_mode = 0).

The new SLD is on NetWeaver 7.4 (which includes its own RFC gateway in the Java SCS instance), and in this release (and a few earlier, but later than 7.02), the new default behavior is the same as setting the parameter gw/acl_mode = 1. This has the effect of denying all external registrations at the gateway by default, unless the external hosts are specifically permitted in a reginfo.dat file, which doesn't exist by default.

So, there's an extra step for the new, higher-release SLD. You can specifically set the parameter gw/acl_mode to 0, so that it mimics the old behavior, and I've seen some recommendations of this approach in answers to forum questions, but this isn't what SAP recommends as it is decreasing the security of your system. Instead, the preferred approach is to create a text file called reginfo.dat and place it in the folder \usr\sap\<SID>\SCS01\data. Edit the file and create lines similar to the following:

#VERSION=2

P TP=SLD_* HOST=<allowed hosts or IP ranges> ACCESS=<allowed hosts or IP ranges> CANCEL=<allowed hosts or IP ranges>

You can put lots of things in the HOST, ACCESS, and CANCEL lists, such as *.domain.org if you want to allow all hosts in your internal domain, or 10.50.15.* if you want to allow all hosts in that subnet, etc, or lists of specific hosts. Note 1069911 gives a good overview of this.

This worked for me. It solved the problem and I'm now proceeding to switch the remaining systems over to use the new SLD. I'm thinking to write up a short blog entry about it, because it took me a while to figure out that this was the problem, and I see lots of forum questions asking the same thing without too many good answers.

Regards,

Matt