Need assistance with 5230 appliance and ACSLS SL8500 configuration

[TikkyTakk]

Hi guys,

I am trying to setup tapes drives on a 5230 Veritas appliance. The tapes drives are in a SL8500 which is controlled by an ACSLS server.

I have edited the vm.conf file on the appliance to what I think is the correct config.

When I try to inventory the robot I get error unable to initialize robot.

Doing a robtest on the appliance I get

acs_query_server() failed
Unable to query server taco, ACS status = 54, STATUS_IPC_FAILURE Robotic test utility /usr/openv/volmgr/bin/acstest
returned abnormal exit status (1).

Doing a acstest -rn 0 -r (ACSLS_SERVER) -s 30031

I get connection refused.

On the ACSLS server I have added the IP and server to the internet.addresses file and rebuilt the access config.

What am I doing wrong/missing??

[Marianne]

Please share Appliance vm.conf and device config:
tpconfig -l

Is there a firewall between Appliance and ACSLS?

[TikkyTakk]

MM_SERVER_NAME = appliance

ACS_TCP_RPCSERVICE

ACS_CSI_HOSTPORT = ACSSERVER 30031

ACS_SSI_INET_PORT = ACSSERVER 30031

ACS_SSI_HOSTNAME = APPLIANCE

ACS_SSI_SOCKET = ACSSERVER 30031

ACS_CSI_HOSTNAME = ACSSERVER

tpconfig -l

Device Robot Drive       Robot                    Drive                           Device      Second

Type     Num Index  Type DrNum Status  Comment    Name                            Path        Device Path

robot      0    -    ACS    -       -  -          -                               ACSLSGSU

  drive    -    0 hcart2    -      UP  -          HP.ULTRIUM5-SCSI.000            /dev/nst9   ACS=0, LSM=0, PANEL=1, DRIVE=11

  drive    -    1 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive029_BAY35  /dev/nst7   ACS=0, LSM=1, PANEL=1, DRIVE=7

  drive    -    2 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive026_BAY59  /dev/nst11  ACS=0, LSM=0, PANEL=1, DRIVE=5

  drive    -    3 hcart2    -      UP  T1         GSU_SL8500_LTO5_Drive031_BAY63  /dev/nst6   ACS=0, LSM=0, PANEL=1, DRIVE=4

  drive    -    4 hcart2    -      UP  -          HP.ULTRIUM5-SCSI.005            /dev/nst4   ACS=0, LSM=0, PANEL=1, DRIVE=0

  drive    -    5 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive015_BAY57  /dev/nst10  ACS=0, LSM=0, PANEL=1, DRIVE=13

  drive    -    6 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive006_BAY40  /dev/nst8   ACS=0, LSM=1, PANEL=1, DRIVE=2

  drive    -    7 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive013_BAY34  /dev/nst5   ACS=0, LSM=1, PANEL=1, DRIVE=11

  drive    -    8 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive010_BAY48  /dev/nst3   ACS=0, LSM=1, PANEL=1, DRIVE=0

  drive    -    9 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive030_BAY31  /dev/nst1   ACS=0, LSM=2, PANEL=1, DRIVE=4

  drive    -   10 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive028_BAY55  /dev/nst12  ACS=0, LSM=0, PANEL=1, DRIVE=6

  drive    -   11 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive025_BAY51  /dev/nst0   ACS=0, LSM=0, PANEL=1, DRIVE=7

  drive    -   12 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive023_BAY44  /dev/nst2   ACS=0, LSM=1, PANEL=1, DRIVE=1

  drive    -   14 hcart2    -      UP  -          GSU_SL8500_LTO5_Drive008_BAY62  /dev/nst13  ACS=0, LSM=0, PANEL=1, DRIVE=8

Yes there is a firewall between appliance and acsls but port 30031 and 1556 TCP have been opened and confirmed open.

[Marianne]

Was ACSLS configured for firewall access?
@Nicolai has published this excellent blog:

http://www.mass.dk/netbackup-quick-hints/netbackup-and-the-acsls-firewall-feature-2/

You will see that vm.conf are somewhat different - e.g CSI_HOSTNAME and not ACS_CSI_HOSTNAME 

Please perform the rpcinfo tests as well.

More about ACSLS over here: http://www.veritas.com/docs/000026984

Look for RPC comms (section 6) and interpreting and troubleshooting ACS error messages (section 7).

[Marianne]

Some additional reading matter:

https://vox.veritas.com/t5/NetBackup/NBU-SUN-ACS-and-RPC-problems/td-p/325679

Veritas TN with ACSLS config parameters: http://www.veritas.com/docs/000034584

[TikkyTakk]

 Yes ACSLS has been configured for firewall access. I should mention we have other windows media servers under the same master which are successfully using the same ACSLS server to control the SL8500 library.

I think Nicolai has just made a typo with the missinf ACS_ as all the documentation and even the appliance menus mention these variables with the ACS_.

One thing I did find reading through your links I don't seem to be running the acsssi service when I do a bpps -x

and doing an rpcinfo -p there is no binding to "1073741824    2   tcp  30031" or any other port for that matter.

Please see the output below (thanks!)

MM Processes

------------

root      94687      1  0 10:18 pts/1    00:00:00 /usr/openv/volmgr/bin/ltid

root      94710      1  0 10:18 pts/1    00:00:00 vmd

root      94851  94687  0 10:18 pts/1    00:00:00 acsd

root      94949  94687  0 10:18 pts/1    00:00:00 avrd

root      95043  94851  0 10:18 pts/1    00:00:00 acssel -s 13740

Shared Symantec Processes

-------------------------

root      62802      1  0 Nov23 ?        00:00:22 /opt/VRTSpbx/bin/pbx_exchange

root      62817      1  0 Nov23 ?        00:00:19 /opt/SYMCnbappws/eat/bin/vxatd -c /opt/SYMCnbappws/eat/data

home/maintenance # rpcinfo -p

   program vers proto   port

    100000    4   tcp    111  portmapper

    100000    3   tcp    111  portmapper

    100000    2   tcp    111  portmapper

    100000    4   udp    111  portmapper

    100000    3   udp    111  portmapper

    100000    2   udp    111  portmapper

    100005    1   udp  41673  mountd

    100005    1   tcp  45896  mountd

    100005    2   udp  41673  mountd

    100005    2   tcp  45896  mountd

    100005    3   udp  41673  mountd

    100005    3   tcp  45896  mountd

    100024    1   udp  51436  status

    100024    1   tcp  41873  status

    100021    1   udp  44277  nlockmgr

    100021    3   udp  44277  nlockmgr

    100021    4   udp  44277  nlockmgr

    100021    1   tcp  46022  nlockmgr

    100021    3   tcp  46022  nlockmgr

    100021    4   tcp  46022  nlockmgr

    100003    2   tcp   2049  nfs

    100003    3   tcp   2049  nfs

    100003    4   tcp   2049  nfs

    100003    2   udp   2049  nfs

    100003    3   udp   2049  nfs

    100003    4   udp   2049  nfs

[Nicolai · Accepted solution]

Hi

From the process list, I can see you are missing acsssi process.

From a media server with ACSLS connection:

root 34406 1 0 Nov14 ? 00:00:34 /usr/openv/volmgr/bin/ltid
root 34412 1 0 Nov14 ? 00:00:48 vmd
root 34589 34406 0 Nov14 ? 00:00:08 acsd
root 34592 34406 0 Nov14 ? 00:00:14 avrd
root 34595 34589 0 Nov14 ? 00:00:01 acssel -s 13740
root 34642 34589 0 Nov14 ? 00:01:01 acsssi 13741

Try the following in vm.conf

ACS_TCP_RPCSERVICE
ACS_CSI_HOSTPORT = {acsls_server_name} 30031
ACS_SSI_INET_PORT = {acsls server_name} 30031

Then ensure ALL acsls related process are stopped/killed. Then start Netbackup again. 

Your appliance, is it multihomned e.g. does it have more than one network interface connected ?

PS: Yes, the update is missing the ACS_ prefix. Updated

[Marianne]

I agree with Nicolai - those 3 vm.conf are the only really important ones.

ACS_SSI_HOSTNAME is only neccessary if comms with ACSLS is using an interface other than 'uname -a' output. 

I would also add VERBOSE entry.
After stopping NBU, check that ALL acs... processes have also stopped.

Restart rpc on Appliance for good measure... then start NBU. 
Check if acsd, acsssi and assel are all running. 

If still experiencing issues, check event.log in ACSLS as well as /var/log/messages on the Appliance. 

[Marianne]

One more thing... I haven't worked with ACSLS in close to 5 years, but 'ACS status = 54, STATUS_IPC_FAILURE' sort-of rings a bell...

Can you ping the ACSLS hostname from the Appliance? 

[Nicolai]

Yes - it smell of the firewall only allow traffic in one direction. But I could be wrong ...

[tikkytak]

testing access...

[TikkyTakk · Accepted solution]

Ignore the above post as I was having issues logging in.

With the help of Veritas support I was able to resolve this issue.

As I had mentioned earlier the absence of the acsssi process was an indication something was wrong.

When we restarted ltid and observed the acsssi debug long we saw the error message "unable to bind sicket to port 30031"

This was preventing the acsd service from firing off the acsssi process.

The issue lay within the vm.conf file.

ACS_SSI_SOCKET = ACSLSSERVER 30031

This socket has to be free and especially not configured to the firewall port.

After removing this line everything worked fine.