How to Ensure that SLD Data is Available during Maintenance

[wolf_hengevoss]

Availability of SLD Data

System Landscape Directory (SLD) data is used throughout most of the life-cycle of SAP’s applications such as SAP NetWeaver Process Integration or system monitoring in the SAP Solution Manager, and many of these uses can be business critical. This naturally puts high demand on the availability of SLD data. While a high-availability (HA) setup can avoid gaps caused by unplanned downtime, those caused by planned downtime – e.g. during maintenance of the SLD system – are hereby not addressed. This can, however, be achieved by the setup described in the following:During the last few months a new procedure has been used for SAP’s main SLD instance to come very near to the goal of continuous availability of SLD data. It consists of the following steps:

• Two SLDs run on two instances on SAP NetWeaver 7.1. They mutually update their content with bidirectional full automatic synchronization.
• All communication with the SLD from systems that register their data in the SLD or clients that read that data use a virtual IP address, which is assigned to one of the SLDs (naturally only one) and, in case that there is maintenance of that system required, it is manually switched to the other.
• To be armed against unplanned downtime these steps need to be combined with an HA setup, but can, of course, be used independently of HA techniques.

The Demo-Story

First Part: Full-Automatic Sync

The first part of the demonstration showing how to set up SLD's full automatic sync

has been published before. It shows the setup of the full automatic synchronization of two SLDs. It ends with both of them being coupled in bidirectional full automatic sync.

Just one hint: the changed look of the second SLD is achieved by using another Web Dynpro theme in the browser and does not indicate any difference between the two SLDs themselves.

Second Part: Using a Virtual IP Address

The second part starts where the first ended. The optical differentiation, however, is no longer used: The whole setup is done to make it feel like one system.

1. As a client simply the UI of the SLD is called to show the setup of the SLDs.
2. Then a reserved (virtual) IP address is assigned to SLD 1 manually. This is done on the host of SLD 1 directly.
3. The UI of SLD 2 is closed and for the remaining UI the virtual IP address is used – it still shows the content of SLD 1 – proved by opening the server details showing the SLD’s host.
4. To prepare a switch between the SLDs…
   1. The virtual IP address is entered for SLD 2 but not yet activated – using it on more than one system at a time would cause network errors.
   2. Now, the virtual IP address is removed from SLD 1 (a ping is used to simulate the downtime that would be experienced in any client trying to connect to the SLD.
   3. The virtual IP address is now activated on SLD 2 (only 3 pings timed out until this was done)
5. As before the SLD UI using the virtual IP address is used to prove that now clients connect to SLD 2 automatically.
   
   SLD 1 can go safely into any kind of maintenance procedure – when its over administration can switch back to SLD 1 and, for example, update SLD 2.
   
6. In the last steps switching back to SLD 1 is demonstrated.
   Again, take care that the virtual IP address is never active on more than one SLD instance at a time.

One huge advantage of this procedure is that once set up on SLDs and clients switching will only require changes on SLD systems.

 Figure 1 shows the final setup used in the demo: ABAP and Java stack of host pwdf2308 register themselves in two different SLDs (just to show it doesn’t matter where they do). SLD 1 and SLD 2 are connected with a bidirectional full-auto-sync so data is identical in both SLD instances.

What is new is the use of a virtual IP address for the clients – shown as applications and tools. To round things off the virtual IP address should also be used when configuring the data suppliers of ABAP and Java stacks. This is demonstrated in the new part 2 of the demo.

Figure 1: Using a virtual IP address you can switch between two synchronized SLDs during maintenance in a few seconds without any changes needed in the client applications

How to Use the Demo:

This is quite easy: The demo runs as a self-contained exe file including a narration. It will start in a full screen mode. To pause and restart the demo use the space bar or the menu bar of the demo. To start the demo of switching between SLDs, click here. Note that the demo is silent.

What You Need to Know

Prerequisites

• This scenario is valid as of SAP NetWeaver 7.1; if SLD’s name reservation is also needed, SP 2 of SAP NetWeaver 7.1 EHP1 is required (see How to Get an SAP NetWeaver 7.1 System Landscape Directory?How to Get an SAP NetWeaver 7.1 System Landscape Directory?”).
• A virtual IP address for the DNS host name has been reserved and is used.
• Both systems must be configured identically using:
  • Identical ports for productive and backup system.
  • Identical users on both systems. (You can also use one LDAP user store for both systems.)
  • Note that having identical SIDs is not required and would cause problems when the use of CTS+ is intended with SLD content
• Object Server Names:
  • Different object server names for both SLDs are required.
  • Beginning with 7.1 EHP1, SP2 you use identical external object server names to use name reservation also from the backup system SLD 2. Internal object server names must be different.
• Productive and backup system must be in the same IP subnet.
• Set up the full automatic content sync as follows:
  • Use the physical address of the systems.
  • When configuring the rank of the systems (used to solve any conflicts) the rank of the productive system should to be higher than the rank of the backup system.

The Switch Procedure

Switch Steps

• Note: Before you can start the switch procedure you need to wait for the initial “Full Sync” to have finished. To check this, in the SLD choose Administration à Content Synchronization. The sync connection between the productive system SLD1 and the backup system SLD2 must show the Incremental Sync link.
  • Remove the virtual IP address on the productive system (Host1).
  • Apply the virtual IP address on the backup system host (Host 2).
• After IP switch is done please note: Before shutting down the productive system SLD 1 ensure that all “pending changes” have been completed. To check this, in the backup system SLD 2 choose Administration à Content Synchronization à Incremental Sync (choose Incremental Sync link on the content sync connection).
• After the maintenance is over switch back virtual IP to the productive system SLD 1.

Switch Options

• The IP switch can be realized by several hard or software products
• The SAP web dispatcher and standalone RFC gateway can be used as alternative system switch.

Combination with an HA Setup

The key features of the scenario described here are the full automatic sync of SLD systems and the usage of a virtual IP address. As indicated in the beginning, it can be combined with an HA setup (in principle, it doesn't matter who does the switch, any process or a human administrator). To get things right, however, discuss your individual approach with an HA expert to take care of web dispatcher settings, port ranges to be used, etc. Since details may vary in diffrent landscapes, they cannot be discussed here.

Tips and Restrictions

• Name reservation requires an external object server name. Therefore prior to SP2 of SAP NetWeaver 7.10 EHP1 the use of name reservation is not possible in this setup
• Continuous data supply to other SLDs with data from productive SLD
  • Delta exports are always specific to an SLD – in other words they contain the individual data changes and thus the SLD internal object server name. For this reason the delta exports are disrupted during use of backup system SLD 2.
  • If you switch permanently to the backup system SLD 2, a new “Full Export” is required to continue the export lines.
  • Content sync connections reference the change log of the individual SLD. Therefore always use the physical host address to configure the content sync connection. This will avoid erroneously using the change log of the backup system
  • After switching from SLD 1 to SLD 2 any external content sync connection should be removed from SLD1 and configured against SLD2 instead. In this way external content sync processes are not harmed by the maintenance process of SLD 1. The only drawback is the full sync run against SLD 2, which is initiated during reconfiguration.
  • During maintenance (e.g. upgrade) of the productive system SLD1 we recommend to switch off (deactivate) the content sync connection. Just to avoid error logs while the system is not available several times during upgrade process. The deactivation should be restricted to the maintenance time to avoid too much loading of the content synchronization after reactivation.
• Log each configuration change in both systems to ensure that their state is equal.

Further Information

As usual, further information is available under quick link nw-sld in SDN (System Landscape Directory (SLD))