Now that SAP ASE comes with it own brand-new Always On option it is worth having a closer look at it.

Below is a peep-view at Sybase HADR Option.

HADR has three basic components:  ASE, RS and Fault Manager.  I skip the Fault Manager for the moment (although it reduces all of self-management to nil) and concentrate on the ASE|RS components. ASE setup with HADR enabled requires super user (sudo) credentials – for those who wishes to install the whole bundle at once.  It is also essential to remember that HADR is not designed to run on a single host.


Setup Phase:

Setup phase is pretty straightforward.  ASE 16 SP02 installation comes with a sample resource file for hadr in addition to the sample resource files it traditionally had for other ASE components ($SYBASE/$SYBASE_ASE/init/sample_resource_files/setup_hadr.rs).  You may need to make two copies of it – one for the primary side and another for the replicate – to make life easier.   The sample resource file is commented throughout – you just need to make sure that the resource file for each side is modified correctly following the guidelines in the template script.  Otherwise things may go wrong…

With the resource file fixed – the HADR setup consists of calling the setuphadr utility twice – once for the primary side and once for the replicate side.  DB synchronization is performed by the script itself (through calls to the RMA component – which has to be started on each host before calling setuphadr).

All in all it takes 2 simple steps to set things up (again, not counting FM installation).

When done, you may verify installation by connecting to RMA through its rma_tds_port – or you may connect to RS through its srs_port – both defined in the resource file.  To understand if all is good or not – beyond the success message setuphadr prints out – you will need to read documentation first.  RMA command line options are brand new set of sap_… commands.  RS has a lot of new components – some in suspended|down state even when the system is operating well.   There is also RS log file (to be found in $SYBASE/DM/{CID} directory.  And there is an RMA log file (to be found in $SYBASE/DM/RMA-15_5/instances/AgentContainer/logs).

Yet another option is … ASE Cockpit (you will have to start it first from $SYBASE/COCKPIT-4/bin/cockpit.sh – default port is 4283 for https connection – but connectivity information is printed out so you don’t need to worry remembering the right path)…


Monitoring Phase:

ASE 16 Sp02+ is now managed through ASE Cockpit – a new kid on the block.  The system that has HADR enabled will look like this:

You will find that under the system status there is another status:  site mode status.  This one indicates which side of the HADR system it is (primary|standby) and what is its health status (active|stopped|unknown).

HADR has its own screen in the Monitor section as well.  This will look like:

Here too one will see the state of the system (active|stopped|unknown) and in addition what the system components are with their corresponding states:

The “path” here is replicating from ASESRV1 to ASESRV2 for asedb, master and DA1 databases (master and DA1 are “default” databases to be replicated, with DA1 is the name of the cluster you choose in the hadr resource file).  one may see the direction of replication, state and health – across various parameters (components state, primary ASE log state, replication throughput, replication backlog and latency).

When the system will be up enough time to collect metrics ASE Cockpit will be able to show various handy statistics on the HADR.


Backlog:


RS Latency:

HADR_LATENCY


Primary ASE Log Status:

HADR_LOG_RECORDS


Replication Throughput:

HADR_THROUGHPUT

This is a pretty nice way to visualize your HADR health status – including a neat breakdown of latency into RS components – once visible through manual

rs_ticket interface.  STP state is also visible through primary log status.

In addition to this it is possible to see other HADR performance statistics through the ASE Cockpit “Statistics Chart” interface across various RS related metrics:

HADR_STATISTICS

I must confess that for those used to run manual commands to see what’s going on with the replicated environment this is a massive step forward.  Looks neat.  Still things to be polished but hey, this is just a start!  It already provides a decent way to monitor replicated environment “out-of-the-box”.



Operation Phase:

ASE Cockpit allows to manage the system as well as to monitor it.  This is done from the EXPLORE tab of the ASE Cockpit.

The management interface looks like this:

HADR_MANAGE_1

ASE Cockpit covers:

  • Manual fail over
  • Re-materialization
  • Forcing the server to become primary if HADR state is unknown
  • Stopping|starting basic RMA|RS components

For the fail over ASE Cockpit will also display the fail over status (log) during the operation:

For those attentive to detail… there is a blue-yellow motive adhered to….

Round Up:

HADR option looks like a valuable addition to ASE environment.   Although setting up replication server has never been a big issue for ASE DBAs  – an easily scripted task – having it all done for you is nice.  On the other hand, managing & monitoring the environment has been a thorny thing.  With HADR option this task has been addressed and elevated to a new level.  Everything ASE Cockpit displays may be still done manually (either using the new RMA interface or using the old good RS commands).  At the same time having the things in front of one’s eyes easily accessible has a great value.

There are still things to be improved – like having embedded RS to work on auto-expanding partition rather than a fixed size one, having the cluster id database auto-expanding rather than fixed size, having more technical documentation on how various components work and how the new system shall be troubleshooted in case things go wrong, having an ability to interact with ASE cockpit better, having more elastic licensing model, having more than one replicated nodes in the same configuration – but as a starting point this feature is definitely worth a try.  Big thumps to ASE & RS engineers  (I’ve heard rumors that the throughput is much faster for HADR than what we are used to and it looks like there are several ASO|HVAR options turned on by default).

I look forward to ASE 16 SP03…

ATM.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Manchikanti Kumar

    Hi Andrew,

    I came to know that Sybase V16 High Availability Is very good and works like Oracle dataguard which will eliminate the need to SRDF.

    Thanks and Regards
    Krishna

     

    (0) 
  2. Mahipal Marri

    Hi Andrew,

    Really thanks for nice article,we are planning implement the same but we have doubt,does fault manager handles fail back to its former primary which is companion now,i have red the guides but no where it is mentioned,if yes, then can you guide us.

    waiting for your reply.

    Thanks
    M Mahipal

    (0) 

Leave a Reply