cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

SAN Client service takes a long time to start

Greetings,

We set up SAN client for the first time yesterday and it seems to work pretty good. SLES 11.3 master - 7.6.0.1, 5230 Appliance FT Media Server - 7.6.0.1, SLES 11.3 client - 7.5.0.5. However, I find that it takes up to an hour from the time I start the client service until the client is able to use FT. When I run /usr/openv/netbackup/bin/vxlogview -o 200 to look at the logs, I see these messages:

05/13/14 09:25:37.921 [FTClientMgrService::init] Client successfully started (FATClientMgrService.cpp:337)
05/13/14 09:25:37.960 [DiscoveryTaskThread]  DiscoveryTask Thread 119613184 Startup
05/13/14 09:25:37.964 [AddDevice] /dev/sg340
 Inquiry "SYMANTECFATPIPE 0.1     nbu05"
 TargetHBA:LUN:InitiatorHBA = 0:1:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.965 [AddDevice] /dev/sg339
 Inquiry "SYMANTECFATPIPE 0.0     nbu05"
 TargetHBA:LUN:InitiatorHBA = 0:0:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.966 [AddDevice] /dev/sg383
 Inquiry "SYMANTECFATPIPE 1.1     nbu04"
 TargetHBA:LUN:InitiatorHBA = 1:1:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.967 [AddDevice] /dev/sg382
 Inquiry "SYMANTECFATPIPE 1.0     nbu04"
 TargetHBA:LUN:InitiatorHBA = 1:0:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.967 [AddDevice] /dev/sg381
 Inquiry "SYMANTECFATPIPE 0.1     nbu04"
 TargetHBA:LUN:InitiatorHBA = 0:1:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.968 [AddDevice] /dev/sg380
 Inquiry "SYMANTECFATPIPE 0.0     nbu04"
 TargetHBA:LUN:InitiatorHBA = 0:0:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.969 [AddDevice] /dev/sg379
 Inquiry "SYMANTECFATPIPE 1.1     nbu05"
 TargetHBA:LUN:InitiatorHBA = 1:1:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.969 [AddDevice] /dev/sg378
 Inquiry "SYMANTECFATPIPE 1.0     nbu05"
 TargetHBA:LUN:InitiatorHBA = 1:0:0x50 State = 1 RefCount = 0
05/13/14 09:25:37.983 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 9 retries left
05/13/14 09:25:38.983 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 8 retries left
05/13/14 09:25:39.984 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 7 retries left
05/13/14 09:25:40.984 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 6 retries left
05/13/14 09:25:41.985 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 5 retries left
05/13/14 09:25:42.985 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 4 retries left
05/13/14 09:25:43.986 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 3 retries left
05/13/14 09:25:44.986 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 2 retries left
05/13/14 09:25:45.986 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 1 retries left
05/13/14 09:25:46.987 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg268 0 retries left

.


05/13/14 09:47:25.735 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 7 retries left
05/13/14 09:47:26.736 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 6 retries left
05/13/14 09:47:27.736 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 5 retries left
05/13/14 09:47:28.737 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 4 retries left
05/13/14 09:47:29.737 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 3 retries left
05/13/14 09:47:30.738 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 2 retries left
05/13/14 09:47:31.738 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 1 retries left
05/13/14 09:47:32.738 [DeviceInquiry] called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg123 0 retries left
 

And it goes on like this for some time. It appears as though it scans through every /dev/sg device on the system. Is there a way to exclude what it's scanning or reduce the retry attempts? It's only after it's completed this scan that I can use the client over FT. On larger servers with hundreds of SAN devices and multiple paths per device, client startup will take forever.

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

An nbftclnt bundle IS

An nbftclnt bundle IS available for 7.6.0.1 (are you at 7.6.0.1?) but I have no idea if it will help you or not (and nobody's documented it).

Ask your TSE to check out Etrack 3385322.

All those fixes are in 7.6.0.2, by the way, if you want to bypass the EEB route.

(If I should be looking for 7.5.0.5, let me know - I'm trying to multitask and failing on a Friday)

View solution in original post

6 Replies
Highlighted

Just to verify, how did you

Just to verify, how did you you configure the FT device entrys in the st.conf file? Page 94 of the Symantec NetBackup 7.5 Device Configuration Guide walks though the process of  adding to that file.

 

Highlighted

The section you refer to is

The section you refer to is for Solaris. The Linux SAN Client is able to discover and use the ARCHIVE PYTHON devices just fine, they are all listed in the /proc/scsi/scsi file. The unnecessary scanning of all of my SAN disk storage and delaying using the NBU SAN client every time the NBU client is cycled is my problem.

Highlighted

Probably best to log a

Probably best to log a Support call...

Highlighted

Marianne, I'll definitely log

Marianne,

I'll definitely log a call. So is it safe to assume that this is not normal behavior?

Highlighted

I cannot think that this is

I cannot think that this is normal behaviour. (Not that I have a lot of experience with SAN Client!)
Fortunately client startup will only happen when it is rebooted once in a blue moon....

 

Highlighted
Accepted Solution!

An nbftclnt bundle IS

An nbftclnt bundle IS available for 7.6.0.1 (are you at 7.6.0.1?) but I have no idea if it will help you or not (and nobody's documented it).

Ask your TSE to check out Etrack 3385322.

All those fixes are in 7.6.0.2, by the way, if you want to bypass the EEB route.

(If I should be looking for 7.5.0.5, let me know - I'm trying to multitask and failing on a Friday)

View solution in original post