Friday, July 24, 2009

Sun Directory Server Patch for MMR setup without downtime

We implemented Sun Portal solution for a local university 3 years ago and are now maintaining their systems. It is designed with high availability in mind. Every component involved requires redundancy support.



Part of the maintenance contract requires us to patch any component as and when they are made available. We know that Sun Directory Server 6.3.1 has been released since Feb 2009. We are only given the green light to patch tonight. :) And no downtime is expected.

Looking at the architecture above, we know we need to take care of 2 dependency components:
  • Multi-Master Replication between the 2 Directory Servers
  • Sun Access Manager
As long as the 2 components are taken care of, everything should be fine.


Multi-Master Replication between the 2 Directory Servers

MMR is designed such that if one server crashes and recovers later, the replication mechanism will synchronize the 2 nodes back to identical state again. Not too worrying.


Sun Access Manager 

The Users' information and Sun Access Manager configuration data are stored in Sun Directory Servers. If the connection from AM to DS is down, the AM will not work. And this implies the Portal will be down as well. Thus, it is very important that the Sun Directory service is always available.

Luckily, Sun Access Manager is designed such that we can designated a Primary and a Secondary Directory Server. So if one is unavailable, the other is always reachable.

2 places to modify to support HA DS in Sun Access Manager:
  1. Sun Access Manager Admin Console
  2. serverconfig.xml 
Read here for more detail.
 

So, it should not be a big problem for the patching to go ahead. We'll do it one node at a time, without disruption to the Portal service to the University users.

We took about 40 mins to finish the job. Below is the task list we followed closely:

0. Backup. Backup. Backup
    
1. Make sure portal is accessible via
    https://node1.university.sg/portal/dt
    https://node2.university.sg/portal/dt

2. Verify existing version is 6.0 on node2

    root@node2 # ./dsadm -V
    [slapd 32-bit]
    Sun-Java(tm)-System-Directory/6.0 B2007.025.1834 32-bit
    
3. Stop dsins1 on node2
    
4. Make sure portal is accessible via
    https://node1.university.sg/portal/dt
    https://node2.university.sg/portal/dt 
    
5. Patch on node2 using patchadd

    root@node2 # patchadd /var/spool/patch/125278-08

6. Verify latest version on node2

    root@node2 # /opt/SUNWdsee/ds6/bin/dsadm -V
    [slapd 32-bit]
    Sun-Java(tm)-System-Directory/6.3.1 B2008.1121.0308 32-bit
    
7. Start dsins1 on node2 

8. Ensure replication continues to work between node1 (6.0) and node2 (6.3.1)
    -> Need to wait a while for replication to be in-sync. DO NOT PANIC!!
    
9. Make sure portal is accessible via
    https://node1.university.sg/portal/dt
    https://node2.university.sg/portal/dt
 
10. Verify existing version is 6.0 on node1

    root@node1 # ./dsadm -V
    [slapd 32-bit]
    Sun-Java(tm)-System-Directory/6.0 B2007.025.1834 32-bit
 
11. Stop dsins1 on node1
    
12. Make sure portal is accessible via
    https://node1.university.sg/portal/dt
    https://node2.university.sg/portal/dt   

13. Patch on node1 using patchadd

    root@node1 # patchadd /var/spool/patch/125278-08

14. Verify latest version on node1

    root@node1 # /opt/SUNWdsee/ds6/bin/dsadm -V
    [slapd 32-bit]
    Sun-Java(tm)-System-Directory/6.3.1 B2008.1121.0308 32-bit

15. Start dsins1 on node1 
 
16. Ensure replication continues to work between node1 (6.3.1) and node2 (6.3.1)
    -> Need to wait a while for replication to be in-sync. DO NOT PANIC!!
    
17. Make sure portal is accessible via
    https://node1.university.sg/portal/dt
    https://node2.university.sg/portal/dt


If your organization requires a Portal solution, talk to us. We have an experienced team well-versed with Sun Portal technology. Not forgetting, LifeRay Portal technology. I'm reachable at cheechong @ azimuthlabs.com.sg


 

No comments:

Post a Comment